We're wrapping up the first phase of the Fedora Docker Layered Image
Build Service and the time has come to start thinking about what we as a
Project need to do to formalize what it means to be shipping Docker Layered
Images once we are capable of building and distributing them.
These are effectively going to compliment their RPM counterpart at least
in the beginning since we as a Project have never shipped any build artifact
other than RPMs as a part of the distribution before. We can grow organically
from there if we want to extend beyond the initial offering for Docker
Layered Images but I thought following RPM as a guide in the beginning was a
reasonable goal to achieve. Some areas that seemed pertinant right off the
bat are below, for each of them I have alread created a Draft document that
I would appreciate feedback on.
Docker Layered Image "packaging" Guidelines 
Package Review Process with a Docker Containers section 
Docker Layered Images Naming Guildelines 
The Fedora Cloud SIG has done a first-pass review of these (thanks Cloud
SIG!) so hopefully there's a certainly level of sanity to them but I'm
absolutely open to new ideas and extending the content with more coverage.
Another point to note is that we need to determine how this should be handled
in BZ components for bug reporting as well as for filing review requests.
Something else what was brought up when I originally submitted these ideas to
FESCo (aside from the fact that this should go to devel list first) was
that it is probably a good idea to establish a Container-centric Guidelines
Committee much in the way there is a Fedora Packaging Committee (which focuses
on RPMs). My question to everyone on that topic is, would there be enough
interest to establish such a committee?
As a side note and just a matter of opinion but I think the idea of forming
a Committee to help shepherd these new types of deliverables through Fedora
will help to enable aspects of Fedora Modularization which ultimately will
be good for the whole of the Fedora Project.
I look forward to questions and feedback.
 - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
 - https://fedoraproject.org/wiki/PackagingDrafts/Containers
 - https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_wit...
 - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGu...
 - https://fedorahosted.org/fesco/ticket/1573
I'm pretty much stumped on a problem where freecad (really python-pivy)
segfaults on F24 but seems to run fine on F23 and I can't find any
substantive difference between any of the packages.
Strangely installing Coin3 from f23 on a f24 system seems to fix the
Any pointers/help would be appreciated.
audacious-plugins-3.7.2 in Rawhide koji failed to build with constexpr
errors in various plugins.
What exactly has changed?
metronom.cc:50:30: in constexpr expansion of 'InputPlugin::InputInfo(0).InputPlugin::InputInfo::with_schemes(((const char* const*)(& Metronome::schemes)))'
metronom.cc:50:30: error: accessing uninitialized array element
OK folks, it's Bad Decision Time.
Today, Node.js 6.0 was released. This is a significant ABI-breaking release,
which means there is no guarantee that existing modules will work with it at all.
Better still, Node.js 5.x is only going to be supported until sometime this
summer, because they're aiming for the 6.x branch to become the new LTS in
October. This puts us in quite a bind.
Fedora disallows major ABI changes in a stable release, so if Fedora 24 Final
ships with Node.js 5.x, we will be stuck with maintaining it until Fedora 24 EOL
(which is probably going to mean until approximately June 2017, or almost a full
year after upstream drops support). This means manually backporting any security
issues that come up without the benefit of a new version to rebase to and with
an increasing likelihood of the patches diverging from upstream.
On the flip side, the major ABI break is hitting us post-Beta Freeze for Fedora
24, which is a really terrible time to be switching to a new major version of a
language runtime (particularly since we don't actually know if any of the other
packages on the system will work with it at all).
We don't have any particularly good options here. A downgrade back to 4.x (which
will be supported until at least April 2018, well past F24 EOL) would be very
difficult at this point, since node modules may have updated to newer,
Furthermore, this came at a time where I was planning to write to the nodejs
list and let people know that due to my changing work responsibilities, I'm not
going to be able to be the primary maintainer of the main package any longer.
(I'd be able to swing the occasional minor- or point-release update, but
wrangling a major release won't be possible.)
I realize this is inopportune, but it's best if we figure out *immediately* how
we're going to handle this.
1) Downgrade back to 4.x, downgrading or dropping any modules in the collection
that don't run on that LTS version.
2) Stick with 5.x for the life of Fedora 24, handling security backports
ourselves once it hits EOL this summer.
3) Upgrade to 6.x, fixing or dropping any modules in the collection that don't
run on it yet.
I'll stick around to help with this major effort (since it's partly my fault
we're in this mess; I didn't realize that the release schedule for 5.x was so
poorly aligned with Fedora 24), but after that I'm going to need someone else to
step up and handle the primary maintenance.
I don't like any of the choices, but I'm going to suggest that option 3) may be
our best choice if we can manage it; we will want to be doing the same work for
Fedora 25/Rawhide anyway, so it's not wasted effort. Also, a lot of the node
modules in Fedora are only there because originally we needed them as
dependencies for npm. Since we recently switched to carrying the embedded npm
(and its rat's-nest of dependencies) inside the main nodejs package, we can
probably get away with breakage in a lot of the modules in the collection.
We may only need to focus in the short term on those packages that are required
by other parts of the Fedora Project (like nodejs-less, which is consumed in the
build process for many web apps).
Option 2) is the path of least resistance in the immediate short-term, but once
we run up against the upstream EOL, the maintenance burden could be prohibitive.
In theory, we could petition FESCo for permission to break ABI in the stable
release, but I wouldn't recommend it (and would probably be voting against it
were it to come from anywhere else; I'd abstain in this case due to conflict of
interest). Given that we know about the potential risk in advance, I doubt we'd
see much sympathy either. So we should realistically assume that if we choose
this option, someone is going to need to maintain the security backports (and it
will not be me, sorry).
As for Option 1)? I think someone with more knowledge of the individual modules
in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many modules
would be broken if we downgraded. If it's sufficiently small, I suppose we could
epoch-bump nodejs and its virtual npm Provides: and go that route. I don't love
that we will effectively been playing yo-yo with the version in F24, but it
would be a solution...
Thoughts, other ideas? Please skip the rotten fruit; I'm on a diet.
Nice to me you.
I have posted a review request for python-jinja2-27 in EPEL6.
I'm an infrastructure engineer of web systems in Japan.
I almost don't have experiments of open source. and... I'm not fluent
but I want to provide jinja-2.7 that is very useful by having many functions.
I'm waiting for my sponsor.