BuildRequires: redhat-rpm-config
by Richard W.M. Jones
I had a bug filed that a Python package I'm maintaining cannot be
rebuilt using 'rpmbuild --rebuild'. The failure was that the *.pyc
and *.pyo files are missing.
After a lot of head-scratching and debugging it turns out that
brp-python-bytecompile was not running, and that happens because the
RPM macro %{__os_install_post} didn't contain a call to
brp-python-bytecompile. This macro exists in base RPM, but is
overridden/extended when redhat-rpm-config is installed.
Installing redhat-rpm-config fixes the problem for the bug reporter.
However this raises some questions:
- Should this package explicitly BR redhat-rpm-config?
- Should all Python packages explicitly BuildRequire redhat-rpm-config?
- Should this package not be packaging up the *.py[co] files?
- Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
- Should I just ignore this because it builds fine in Koji?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
10 years, 4 months
[Test-Announce] Reminder: Fedora 18 end of life on 2014-01-14
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings.
This is a reminder email about the end of life process for Fedora 18.
Fedora 18 will reach end of life on 2014-01-14, and no further updates
will be pushed out after that time. Additionally, with the recent
release of Fedora 20, no new packages will be added to the Fedora 18
collection.
Please see http://fedoraproject.org/wiki/DistributionUpgrades for more
information on upgrading from Fedora 18 to a newer release.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSsiEoAAoJEH7ltONmPFDRwrEQAI59+ExbyhZrgr+K/iTDIvWV
LaDHsBsaDeQhV1IxgKN/H0fA84r+LiFTK6/+A5dBt28w9PpxFGGeDUmAF8Gvn3bx
Jlz+6MeuHt+Z3xJ6wRjIwjt7jGGG936tGk4Se/sbHYf33qyRid5gyGEYWHPFK2fV
HSt2/mh9+PTBcQzVbQBOimJsdvGO71FTBCqZBHhapctVsNnCQAGrnetb/yoPqAHY
Sa8K87H7gAWkPswp+w1yHVA7y8gOOjFErNU456N4ZK2h/4zor+dsflchbP9CCKZg
izolBKUOi1VVtaxS7wYV+l+PqV9vaa96/coi3TquLuEElwAG/HS1OzKj9gKH/xQq
PfV0vCyS+CnM3KnEKcz5jr06WNlY6lDp3h6B+JiPHwlGUD1Wdu6UwSWd2NGxt9c7
bkVpjiGcBpwJMM3G9EpoMCKln/JXRkOz9mxsT/4lha+yvPvIUlpWkl7qtMM3KExH
KecUA/JWc74S5a7aWLHRDc8frs1hqk7entkYtf59swFFO39DtDC20fVAm72ZHkig
8kNktOnr3Q19Mw15Dv4Q5UmLRuU36sCrFiF/23zOy7SHK26cnwWWZuCks9vZ81kR
eWP/HvP7Wnu8ahMQLzgXEVyDgCraRD8vcPsYg0oAK+HTcvk/+BTdpT/b/g94JUUU
h764UoIcaMf0NhSei5Yo
=booW
-----END PGP SIGNATURE-----
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
10 years, 4 months
Re: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?
by Andrew Lutomirski
On Wed, Dec 18, 2013 at 12:24 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
> On Wed, 2013-12-18 at 11:22 -0800, Andrew Lutomirski wrote:
>> OK, so I'll re-ask my original question. Fedora 20 was released with
>> a broken update path from F19. Should the release criteria be
>> amended? This particular issue would have been avoided if F19's fedup
>> were frozen along with F20 and if all of the destined-for-stable
>> versions were tested together as a release criterion.
>
> It really isn't that simple. There are more working parts to this than
> you realize.
>
> fedup uses a custom initramfs. A kernel and initramfs that are used for
> all fedup runs are built as part of repo compose. See:
>
> https://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/o...
>
> When you run fedup, its first stage downloads all packages, and
> downloads the vmlinuz and upgrade.img from there (well...not ALWAYS from
> there, see below) and puts them in /boot. The 'System Upgrade'
> bootloader menu entry uses that vmlinuz and upgrade.img (renamed); the
> upgrade.img is an initramfs with a special upgrade environment in it,
> implemented by the 'fedup' dracut module which is shipped in the
> fedup-dracut package.
>
> So the question of 'what version' you're using to do a fedup upgrade
> isn't as simple as 'rpm -q fedup'. It is significant - sometimes very
> significant - what version of the upgrade kernel and initramfs you're
> using.
>
> fedup-dracut has bugs and needs fixes just like any other bit of
> software. As well as the relatively late bump of fedup to 0.8, we got a
> relatively late bump of fedup-dracut to 0.8.
>
> When we're testing fedup, there's three significant pairs of
> kernel/initramfs to keep in mind: the one from the last milestone (so,
> when we're testing Final, Beta), the one in the current day's Branched
> compose, and the one in the current TC/RC (which will also be the one
> that goes to release). Each of these could potentially be different.
>
> fedup asks mirrormanager which location to get the kernel and initramfs
> from, if you don't tell it with --instrepo . Usually, during a
> pre-release period, it'll go and get the one from the last milestone if
> you don't pass it --instrepo . The test case currently instructs you to
> override it with the one from the current development branch.
>
> So why am I bringing up this morass? Because it's significant. We *did*
> test fedup 0.7 prior to release, and it *did* work. Multiple times, for
> multiple testers. You seem to be making the assumption that we never
> tested 0.7 because the test case says to use updates-testing and u-t
> currently has 0.8, but in practice we did (I know I did, personally) -
> 0.8 wasn't sent to updates-testing until quite late, so tests before
> that were with 0.7, and some of us do intentionally test without u-t,
> whatever the test case says. But it matters which kernel and initramfs
> you test with, too.
>
Hmm.
I wonder if fedup (the program) should bail, or at least warn, if the
kernel/initramfs version doesn't match. If I had gotten a message
that said something like "You are trying to use fedup 0.7.0 to upgrade
to a release that was composed with fedup-dracut 0.8.0. This may be
unreliable.", then I might have grumbled, but I wouldn't have spent a
bunch of time wondering why the upgrade silently failed.
I certainly understand that this stuff is *hard*, especially when you
factor in the combinatorial blowup of having multiple version to
upgrade from and to at the same time.
--Andy
10 years, 4 months
Should a working fedup in Fedora N's stable repository be a release criterion for N+1?
by Andrew Lutomirski
I have a tendency to upgrade to a new Fedora release as soon as it's
final, and I sometimes upgrade even sooner. ISTM that the official
upgrade process is almost always broken, often for known reasons.
Should one of the criteria for releasing Fedora N+1 be that a
fully-updated Fedora N must be able to successfully complete 'fedup'
or whatever the current preferred upgrade program is?
(FWIW, the current bug is particularly nasty -- fedup 0.7.0 apparently
can't actually update anything, and the sequence:
- Install fedup 0.7.0
- Try it and watch it fail or hang
- Update to fedup 0.8.0 from updates-testing
- Run fedup
ends up downloading all rpms *twice* a sucking up a correspondingly
immense amount of disk space.
--Andy
10 years, 4 months
ecryptfs alternatives
by Michał Piotrowski
Hi,
I have read in RHEL 7 beta release notes that ecryptfs will be deprecated
in this release. The problem is that I've got a system on Fedora19 (which I
want to move to EL7 after release) with some encrypted data. I'm looking
for realiable alternative to ecryptfs that will work on EL7 out of box or
will be relatively easy to build (without rebuilding kernel modules every
update).
Can you recommend any solutions?
--
Best regards,
Michal
http://eventhorizon.pl/
10 years, 4 months
Re: Inter-WG coordination: Stable application runtimes
by Andrew Lutomirski
On Tue, Dec 17, 2013 at 3:01 PM, Colin Walters <walters(a)verbum.org> wrote:
> On Tue, 2013-12-17 at 23:24 +0100, Miloslav Trmač wrote:
>
>> b) Which WG will take on the task of solving this? We shouldn't end
>> up with everybody agreeing that this needs to be solved, but no PRD
>> proposing to solve this. Is it the Base WG or the Env and Stacks WG?
>> Or is it up to Server and Cloud to do it?
>
> If the Server/Cloud groups follow the way Red Hat Enterprise Linux is
> currently developing, that'd be Docker (docker-io package).
>
> (These are "server applications", which should be distinct from
> client/workstation applications, for numerous reasons)
There will be a similar problem in the docker images, unless you're
suggesting that everyone use Ubuntu-in-docker-on-Fedora/RHEL.
(Also, docker is *far* from ready for prime time, especially in its
LVM incarnation.)
--Andy
10 years, 4 months
mechanism to retain system library versions
by Neal Becker
During the past few months, I've switched from building my software against a
bundled version of boost libraries, to building against the system boost libs.
On updating to f20, all of my software became broken, because the library
versions it was linked with were removed.
So I had to race to rebuild all my software, and hope nothing broke when
rebuilt.
I think this situation is unfortunate. We do have library versioning, so
different versions could coexist.
How do others solve this problem, or can anyone think of a solution?
10 years, 4 months
Split of bind-chroot package in Fedora rawhide branch
by Tomas Hozza
Hi.
I would like to prevent unpleasant surprises and announce,
that bind-chroot sub-package of bind has been split into
two sub-packages in the Fedora rawhide branch.
Previously the bind-chroot sub-package contained named-chroot.service
enabling users to run named in a chroot environment and also
named-sdb-chroot.service enabling users to run named-sdb
in a chroot environment.
From now on, there are two subpackages:
- 'bind-chroot' - for running named in a chroot (nothing changes)
- 'bind-sdb-chroot' - for running named-sdb in a chroot
User that want to run named-sdb in a chroot must install
the 'bind-sdb-chroot' package explicitly. This change is a part
of fixing Bug #997030. The package will be also NOT
installed if updating to Fedora rawhide, because it cannot
be currently done (AFAIK) without creating unwanted dependencies.
As an addition named-sdb now uses its own chroot path
'/var/named/chroot_sdb'.
Regards,
Tomas Hozza
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 4 months
