To all using mixer-tools,
Please note the major version change on mixer-tools. This major release introduces some breaking changes to the CLI which are incompatible with the previous calling convention, so any scripts calling mixer should be updated. Functionality remains the same as before for the time being, but the CLI commands have been slightly modified.
See commit message below:
"Release v4.0.0
This release introduces a major version update with several new features
and package additions.
The original C swupd-server https://github.com/clearlinux/swupd-server and
bundle-chroot-builder https://github.com/clearlinux/bundle-chroot-builder
are now integrated into mixer itself under the swupd/ and builder/ packages,
and used as libraries instead of standalone binaries. The rewrite closely ties
the swupd-server and chroot-builder functionality directly into mixer, while
providing the benefits of the Go language. The new functionality lives side
by side with the original implementation for the time being, until further
testing is completed to guarantee consistent, stable behaviour. However,
the new features may (and should) be used by providing --new-swupd and
--new-chroots with the appropriate mixer subcommands. They will become the
default as the old standalone build programs are deprecated.
The second major update is a new CLI written using the Cobra framework.
Existing commands are only subtly different:
old new
---- ----
mixer build-chroots mixer build chroots
mixer build-update mixer build update
mixer init-mix mixer init
-flags --flags
In short, the command hierarchy is changed such that things like 'build'
are top level commands, and the things they build are exposed under them,
rather than making many hyphenated commands. Flags are implemented as
regular short and long options, where long options use two hyphens
instead of one.
New commands have been added to make bundle lifecycle management easier,
and to ensure bundles are manipulated correctly without manually copying
things in specific folders. See all new commands by typing "mixer" *enter*.
Miscellaneous fixes to things such as init creating the builder.conf and
doing more upfront work for the user have also been implemented. The
goal of these updates is to streamline the operation of mixer and
improve usability.
Many tests were added for the code base; unit tests for the new
swupd and chroot libraries, BAT tests to cover the interface and
functionality of the Mixer itself, and extensive linting were added to
catch regressions and enforce cleaner code."
Openjdk 9 is now available in “java9-basic” bundle. This release includes interesting features like a read-eval-print-loop (REPL) tool called jShell, a new modularity capabilities that offers an easier way to assemble and maintain the code, new HTTP Client with support for HTTP/2 protocol, etc.
“java9-basic” bundle can be easy installed with swupd as follows:
# swupd bundle-add java9-basic
Please notice that “java9-basic” bundle does NOT replace “java-basic” bundle, on the other hand both of them can be installed in the same system.
Openjdk 8 will remain as the default Java installation. The Openjdk 9 commands will be available with a “9” at the end of their names. Eg. java9, javac9, javadoc9.
Regards
Athenas
Hi,
as hopefully everyone in the pythonverse knows, the legacy Python 2 series maintenance is ending in about two years,
and even before then, more and more of pypi is turning Python 3+ due to the maintenance and functionality cost of keeping
legacy compatibility being too high.
In Clear Linux, we've been slowly but steadily switching more and more of the OS to be Python 3, by updating the
packaging rules and slowly splitting our OS content between python3 and legagcypython subpackages and now the split
is even visible on the bundle level (python3-basic versus python2-basic)
We have a long road ahead of us in the transition (many small steps) but I want to at least explain where we are marching
to as an end game, hopefully not more than 6 months from now. Our end point in 2018 is a setup where the OS is fully and only Python 3,
but where we still ship a minimal python 2 setup. At this point we're assuming a minimal setup is
* python 2.7 itself
* pip
* six (for python 3 compatibility)
* numpy (this is still under debate but seems to be a foundation for many things)
What we'll do when Python 2 fully reaches EOL we have not decided yet; like with any piece of software that is out of maintenance,
something is going to need to happen eventually....
On 2/20/2018 11:59 AM, Jorge Castro wrote:
> Hi everyone,
>
> I work in the Contributor Experience Special Interest Group (SIG) in
> Kubernetes. One of the problems we're trying to solve is how to best enable
> local developers to run Kubernetes on a cheap bare metal box so that they
> can do development on. I was looking around at the kubernetes bundle in
> Clear and figured that it would be a great building block for a "Kubernetes
> Developer Appliance" that people can run on NUCs and other similar
> machines.
>
> As I asked around I found other like-minded people, and eventually ran into
> Jose Palafox and William Douglas, who has been asking PMs internally at
> Intel to see if this is a good idea. So we decided to write it down here:
>
> https://docs.google.com/document/d/1vaMLw8sTEuZ2DlPpJsXNdevT7Q0VtfHzn8TkdU7…
>
> And we would love some input, specifically the user experience section.
we'd think it's a good idea; but the paper is a little fuzzy on what you'd want
in/from the OS.... we can make it so once it's a little bit more specific.
Hi everyone,
I work in the Contributor Experience Special Interest Group (SIG) in
Kubernetes. One of the problems we're trying to solve is how to best enable
local developers to run Kubernetes on a cheap bare metal box so that they
can do development on. I was looking around at the kubernetes bundle in
Clear and figured that it would be a great building block for a "Kubernetes
Developer Appliance" that people can run on NUCs and other similar
machines.
As I asked around I found other like-minded people, and eventually ran into
Jose Palafox and William Douglas, who has been asking PMs internally at
Intel to see if this is a good idea. So we decided to write it down here:
https://docs.google.com/document/d/1vaMLw8sTEuZ2DlPpJsXNdevT7Q0VtfHzn8TkdU7…
And we would love some input, specifically the user experience section.