whatever happened to yum + btrfs snapshotting?
by Neal Becker
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
--
-- Those who don't understand recursion are doomed to repeat it
3 months, 2 weeks
Validity of i686 as a release blocker
by Josh Boyer
Hello,
Over the past week, we've been dealing with a kernel bug[1] that
prevents i686 machines from booting. Help was requested and given,
and it has been excellent and most welcome. This email has no
reflection on that, and is instead focused on the reality of where
i686 stands today.
In February[2] we sent out an email highlighting that the kernel team
was not going to treat i686 bugs as a priority. Since that time, we
have held true to our word and have not focused on fixing i686 bugs at
all. It seems that the wider community is also treating i686
similarly. The kernel bug that was made automatic blocker because of
existing criteria was present in Fedora since the 4.1-rc6 kernel,
which was released May 31. It has been in every boot.iso created
since that date. Not a single person reported this issue until last
week. That is a timespan of two months.
The kernel team has autotesting for i686 kernels, but the environment
there does not utilize boot.iso so it did not detect this. The QA
team has automated testing for some of this, but nothing for the i686
architecture at all. It is not a priority there either.
Perhaps it is time that we evaluate where i686 stands in Fedora more
closely. For a starting suggestion, I would recommend that we do not
treat it as a release blocking architecture. This is not the same as
demotion to secondary architecture status. That has broader
implications in both buildsys and ecosystem. My suggestion is
narrowly focused so that builds still proceed as today, but if there
is something broken for i686 it does not block the release of whatever
milestone we are pursuing.
(To be clear, I would support a move to secondary arch status for
i686, but I am not suggesting it at this time.)
Making i686 non-release blocking would actually match reality. None
of the Fedora Editions appear at all concerned with i686. Cloud is
demoting[3] i686 from its offering. Workstation has been fairly
ambivalent about it and recommends x86_64. Server does the same.
Given the lack of focus on it, and the fact that the broader community
is not testing the development releases for i686, I believe this would
be a good first step.
josh
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382
[2] https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
[3] https://fedorahosted.org/cloud/ticket/106
1 year, 2 months
OCaml plans on POWER7/POWER8 (ppc64, ppc64le) in Rawhide
by Richard W.M. Jones
OCaml is a statically-safe programming language derived from ML which
compiles to very fast native code. It contains native code backends
for most architectures (all Fedora primary & secondary arches except
s/390x in fact).
Currently Fedora downstream carries two non-upstream backends:
For ppc64 (big endian), a backend was written many years ago by David
Woodhouse and was upstream for a time, but was dropped when the
PlayStation 3 stopped supporting Linux. For ppc64le (little endian /
POWER8) IBM's Michel Normand contributed a native code backend last
year. The upstream project always carried a ppc (32 bit) backend, but
we didn't use it and it's not very interesting for us.
https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-24-4.02
Red Hat and IBM have provided help and loaned equipment to the
upstream project, and as a result upstream have now added ppc64 and
ppc64le backends. This work was merged at the end of August. These
backends were inspired by the Red Hat & IBM work but are not
derivatives. For details see:
https://github.com/ocaml/ocaml/pull/225
So what I want to do is add the new backends [actually it's a single,
combined and extended ppc/ppc64/ppc64le backend] to Fedora Rawhide,
and drop our non-upstream backends.
I have so far cherry-picked the merge commit on top of our Fedora
OCaml tree, and I have dropped the downstream ppc64/ppc64le commits
from our tree. (This is not pushed yet so doesn't appear in the
git.fedorahosted.org link above.)
I have tested it on ppc64le to check that the compiler compiles
itself. A scratch build of the compiler with the new backend is here
(I reserve the right to make further changes, this is just a
preliminary test build):
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2741551
I used this to compile some ocaml-* packages on ppc64le, with -- it
has to be said -- mixed results. There are two compiler bugs
revealed. This compiler won't be able to compile all the ocaml-*
packages on POWER. However because of the depth of dependencies, I
cannot easily do scratch builds to find out which packages will be
broken.
Hence I'd like to do a full rebuild, again, to see what breaks. This
*shouldn't affect primary architectures at all*, but will probably
leave some broken ocaml-* packages on the ppc64/ppc64le secondary
arches.
We've actually done two complete rebuilds during the F24 development
cycle already, which in a way is good because it means I know how long
it should take, and I'm confident that the scripts I use will work
again:
http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=13...
So I'm pretty confident the primary arch rebuild will go fine, since
it's not affected by any of the above changes - it's basically just a
release bump. We don't even need to use a side tag for this because
the "old" and "new" packages can be mixed on x86 - they are the same.
The plan for ppc64/ppc64le would then be to fix the bugs revealed in
the rebuild with upstream help.
Any comments?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
1 year, 3 months
Packaging of PlayOnLinux
by Jiří Konečný
Hello,
I want to ask if PlayOnLinux could be packaged to Fedora. This program
has list of proprietary programs which are not downloaded but could be
installed if you give it setup.exe file.
Also it downloads Windows redistributable when user explicitly wants to
install program (which using this redist) or given redistributable.
If this is not "legal" in terms of Fedora how it's differ from
OpenSource software which are using not-OpenSource addons? Example of
this could be https://marketplace.firefox.com .
I think it's sad that this good LGPL wine prefix manager software is
not part of the Fedora and I like to change this.
Thank you for answers,
Jirka Konecny
1 year, 3 months
Seeking a package sponsor for Firefox Developer Edition
by Andrew Toskin
Hello! I'm interested in learning about RPM packaging for Fedora, and I'd like to see the "Developer Edition" release channel for Firefox (formerly called Firefox Aurora) available in the Fedora repositories. So my partner Bob and I are working on packaging firefox-dev. Our spec file repository is forked from the Fedora package for the regular release of Firefox. It's not in a working state yet, but you can see our progress on GitHub -- https://github.com/Bob131/firefox-dev/
And we have a Copr here -- https://copr.fedoraproject.org/coprs/bob131/firefox-dev/
Firefox Developer Edition and regular Firefox are able to share the same user profile (the bookmarks, preferences, etc) or use separate profiles, we're aiming to allow both versions of Firefox to coexist on the same system.
Bob and I are both fairly new to the packaging process, so any help will be appreciated.
Thanks,
~Andrew Toskin
("terrycloth" on GitHub and FAS)
1 year, 3 months
kmods and Fedora
by Neal Gompa
Hello all,
I've recently been wondering why we haven't allowed kernel module
packages in Fedora since Fedora 8. I've tried searching through our
wiki and the mailing list, but I haven't come up with any concrete
reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we
provide (that is, maintainers didn't/couldn't keep up with new kernels
being pushed during a release cycle), then I think the situation has
changed.
We have two tools that can help us in this regard: akmod and Koschei,
both came after our policy change to disallow kernel modules.
akmod is essentially DKMS except that instead of just building the
kernel module, it'll build a kernel module package that matches an
exact kernel release. Some of the weird problems that happen with DKMS
don't seem to happen with akmod because of this. There's an argument
for the akmod functionality being part of RPM and perhaps that should
be the case. In any case, I don't see any particular reason akmod
couldn't be brought into Fedora.
On the other end, we have Koschei, which tracks and rebuilds things
automatically (but doesn't submit automatically). It should be
possible to adapt what Koschei does to be able to automatically
generate new kmod packages tied to a particular kernel release and
make it easy for a maintainer to turn that into something that can be
submitted as part of a kernel update bundle to Bodhi.
The biggest blocker I know of with kmods (at least dkms and akmod
style ones) is we have a bug where DNF picks the wrong kernel-devel
package at depsolve time[0] (this also appears to affect installing
kernel-modules-extras too).
Aside from the DNF issue, is there anything else I'm missing in
relation to kmods in Fedora?
Best regards,
Neal
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897
--
真実はいつも一つ！/ Always, there's only one truth!
1 year, 4 months
Intent to orphan shorewall
by Orion Poplawski
I'm planning on moving our firewall from a Fedora/shorewall system to a
pfsense based one. Since I will no longer be using shorewall, I will be
orphaning it. If you are interested in it, let me know and I would be happy
to hand it off.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
1 year, 4 months
nss_myhostname as default in Fedora
by Orion Poplawski
See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well
For a while (from 197-1 until 228-5), systemd added "myhostname" to the end of
the hosts line in /etc/nsswitch.conf in %post via sed. This has been removed
as it is error prone, and the above request filed to add it by default to
/etc/nsswitch.conf in glibc. The glibc maintainer would like to see
discussion of this on the devel list, hence this email.
My interest in this stems from build issues with mpich using programs. This
may have been triggered by a combination of the above change as well as
changes in mpich, I'm not sure. In any case, mpich uses gethostbyname() on
the hostname of the machine it is running on in order to configure itself
properly, and fails if it cannot do this. So the mpich tests run by netcdf
are currently failing on the builders, and has since Nov 27 when systemd
dropped adding myhostname took place.
So:
- Is the change to nsswitch.conf in glibc (back to behavior that was the
default for quite a while) desired?
- If not, is there some other way we can get the koji builders' mock
configuration to be setup so they can at least resolve their own hostname?
Thanks.
PS - There is some other discussion around "mymachines" which seems much more
problematic. I'd like to just focus on myhostname for now. The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
1 year, 4 months
