2:34 p.m.
The grub2 package obsoletes grub, so there's no way to actually _use_ the
older package, but it's still in the tree. Is there a reason?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4:02 p.m.
On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
The grub2 package obsoletes grub, so there's no way to actually
_use_ the
older package, but it's still in the tree. Is there a reason?
Yes, virtualization.
I actually thought grub had been removed, so I removed the dependency
on it in libguestfs. However libguestfs certainly *could* use grub,
if it was available. There's some heated discussion of this here:
https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10
and also in the archives of the current mailing list.
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://et.redhat.com/~rjones/virt-top
4:25 p.m.
On Dec 6, 2012, at 3:02 PM, "Richard W.M. Jones" <rjones(a)redhat.com>
wrote:
On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
> The grub2 package obsoletes grub, so there's no way to actually _use_ the
> older package, but it's still in the tree. Is there a reason?
Yes, virtualization.
I actually thought grub had been removed, so I removed the dependency
on it in libguestfs. However libguestfs certainly *could* use grub,
if it was available. There's some heated discussion of this here:
https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10
and also in the archives of the current mailing list.
Why is a boot manager needed for a virtualized guest? It seems like all you need is to
point to a virtual disk (or current or past snapshot) and go directly to loading the
kernel.
If I could stuff < 1024 bytes of boot loader into ext4's two boot sectors, that
seems ways easier than dealing with grub.
http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html
And if there's a use case for UEFI VM's, why not use EFISTUB instead of grub?
Chris Murphy
4:25 p.m.
On Thu, Dec 06, 2012 at 10:02:20PM +0000, Richard W.M. Jones wrote:
On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
> The grub2 package obsoletes grub, so there's no way to actually _use_ the
> older package, but it's still in the tree. Is there a reason?
Yes, virtualization.
So, yeah, that's actually what I want to do. But since 2011, the grub2
package _obsoletes_ grub, which means that yum and friends will happily
substitute grub2 for grub on every opportunity (by default) including
building images with appliance-creator.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
5:48 p.m.
On Dec 6, 2012, at 3:25 PM, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Thu, Dec 06, 2012 at 10:02:20PM +0000, Richard W.M. Jones wrote:
> On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
>> The grub2 package obsoletes grub, so there's no way to actually _use_ the
>> older package, but it's still in the tree. Is there a reason?
> Yes, virtualization.
So, yeah, that's actually what I want to do. But since 2011, the grub2
package _obsoletes_ grub, which means that yum and friends will happily
substitute grub2 for grub on every opportunity (by default) including
building images with appliance-creator.
I haven't experienced this with F16, F17 or so far F18. What I'm seeing is:
yum install/update grub gets me grub legacy.
yum install/update grub-efi gets me grub legacy efi.
yum install/update grub2 gets me grub2.
yum install/update grub2-efi gets me grub2 efi.
Chris Murphy
1:41 a.m.
On Thu, 2012-12-06 at 16:48 -0700, Chris Murphy wrote:
On Dec 6, 2012, at 3:25 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Thu, Dec 06, 2012 at 10:02:20PM +0000, Richard W.M. Jones wrote:
>> On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
>>> The grub2 package obsoletes grub, so there's no way to actually _use_
the
>>> older package, but it's still in the tree. Is there a reason?
>> Yes, virtualization.
>
> So, yeah, that's actually what I want to do. But since 2011, the grub2
> package _obsoletes_ grub, which means that yum and friends will happily
> substitute grub2 for grub on every opportunity (by default) including
> building images with appliance-creator.
I haven't experienced this with F16, F17 or so far F18. What I'm seeing is:
yum install/update grub gets me grub legacy.
yum install/update grub-efi gets me grub legacy efi.
yum install/update grub2 gets me grub2.
yum install/update grub2-efi gets me grub2 efi.
If you have *both* installed, grub2 will want to nuke grub every time an
update shows up, IIRC.
pjones had a reason for doing it this way, my personal opinion is that
it's a dumb thing to do (I thought we should actually kill grub and only
ship grub-efi), but I'm just the monkey. He might catch this thread to
explain what his reasoning is/was.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:56 a.m.
On 12/07/2012 09:41 AM, Adam Williamson wrote:
On Thu, 2012-12-06 at 16:48 -0700, Chris Murphy wrote:
> On Dec 6, 2012, at 3:25 PM, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
>
>> On Thu, Dec 06, 2012 at 10:02:20PM +0000, Richard W.M. Jones wrote:
>>> On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
>>>> The grub2 package obsoletes grub, so there's no way to actually _use_
the
>>>> older package, but it's still in the tree. Is there a reason?
>>> Yes, virtualization.
>>
>> So, yeah, that's actually what I want to do. But since 2011, the grub2
>> package _obsoletes_ grub, which means that yum and friends will happily
>> substitute grub2 for grub on every opportunity (by default) including
>> building images with appliance-creator.
>
> I haven't experienced this with F16, F17 or so far F18. What I'm seeing is:
>
> yum install/update grub gets me grub legacy.
> yum install/update grub-efi gets me grub legacy efi.
> yum install/update grub2 gets me grub2.
> yum install/update grub2-efi gets me grub2 efi.
If you have *both* installed, grub2 will want to nuke grub every time an
update shows up, IIRC.
Yum and rpm refuse to install packages which are obsoleted by an
installed package, so you can't really have both. Unless you first
install grub2 and then grub with 'rpm --nodeps'...
- Panu -
9:26 a.m.
On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote:
>>I haven't experienced this with F16, F17 or so far F18.
What I'm seeing is:
>>
>>yum install/update grub gets me grub legacy.
>>yum install/update grub-efi gets me grub legacy efi.
>>yum install/update grub2 gets me grub2.
>>yum install/update grub2-efi gets me grub2 efi.
>
>If you have *both* installed, grub2 will want to nuke grub every time an
>update shows up, IIRC.
Yum and rpm refuse to install packages which are obsoleted by an
installed package, so you can't really have both. Unless you first
install grub2 and then grub with 'rpm --nodeps'...
But, it's not just if both installed, is it? The grub2 package obsoletes
grub, and yum follows obsoletes by default in dependency resolution.
Panu, you would know this better than I, so clearly I'm going crazy
somewhere. If you could explain how, I'd appreciate it. :)
Here's on an F17 image booted in a cloud service (so no grub at all
installed initially):
$ rpm -qa |grep grub
grubby-8.11-1.fc17.x86_64
(As expected, just grubby; nothing else matches.)
$ sudo yum install grub
[...]
Package grub is obsoleted by grub2, trying to install
1:grub2-2.0-0.39.fc17.x86_64 instead
Resolving Dependencies
--> Running transaction check
---> Package grub2.x86_64 1:2.0-0.39.fc17 will be installed
--> Processing Dependency: grub2-tools = 1:2.0-0.39.fc17 for package:
--> 1:grub2-2.0-0.39.fc17.x86_64
[...and so on]
Even "yum install grub-0.97" gets this behavior. Now, I can set
"obsoletes=0" in /etc/yum.conf if I _really_ want to get grub installed, but
a) I don't actually want to change the default behavior of yum on the final
image
b) I don't want users to get messed up if they innocently change that back
to its default
c) I'm not even sure how I would go about changing that pre-transaction in
appliance-creator and other tools
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:49 a.m.
On 12/07/2012 05:26 PM, Matthew Miller wrote:
On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote:
>>> I haven't experienced this with F16, F17 or so far F18. What I'm
seeing is:
>>>
>>> yum install/update grub gets me grub legacy.
>>> yum install/update grub-efi gets me grub legacy efi.
>>> yum install/update grub2 gets me grub2.
>>> yum install/update grub2-efi gets me grub2 efi.
>>
>> If you have *both* installed, grub2 will want to nuke grub every time an
>> update shows up, IIRC.
>
> Yum and rpm refuse to install packages which are obsoleted by an
> installed package, so you can't really have both. Unless you first
> install grub2 and then grub with 'rpm --nodeps'...
But, it's not just if both installed, is it? The grub2 package obsoletes
grub, and yum follows obsoletes by default in dependency resolution.
Panu, you would know this better than I, so clearly I'm going crazy
somewhere. If you could explain how, I'd appreciate it. :)
My comment was simply on the "if you have both" part: it's not really
possible to have both without playing dirty tricks, so even the "if" is
pretty moot.
Here's on an F17 image booted in a cloud service (so no grub at
all
installed initially):
$ rpm -qa |grep grub
grubby-8.11-1.fc17.x86_64
(As expected, just grubby; nothing else matches.)
$ sudo yum install grub
[...]
Package grub is obsoleted by grub2, trying to install
1:grub2-2.0-0.39.fc17.x86_64 instead
Resolving Dependencies
--> Running transaction check
---> Package grub2.x86_64 1:2.0-0.39.fc17 will be installed
--> Processing Dependency: grub2-tools = 1:2.0-0.39.fc17 for package:
--> 1:grub2-2.0-0.39.fc17.x86_64
[...and so on]
Even "yum install grub-0.97" gets this behavior. Now, I can set
"obsoletes=0" in /etc/yum.conf if I _really_ want to get grub installed, but
a) I don't actually want to change the default behavior of yum on the final
image
b) I don't want users to get messed up if they innocently change that back
to its default
c) I'm not even sure how I would go about changing that pre-transaction in
appliance-creator and other tools
Yes, I think we're both trying to say the same thing: there's no point
having 'grub' in the repositories as its not installable or usable in
practise. The same goes for bunch of other obsoleted packages as well.
- Panu -
10:54 a.m.
On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
On Dec 6, 2012, at 3:02 PM, "Richard W.M. Jones" <rjones(a)redhat.com>
wrote:
> On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
>> The grub2 package obsoletes grub, so there's no way to actually _use_ the
>> older package, but it's still in the tree. Is there a reason?
>
> Yes, virtualization.
>
> I actually thought grub had been removed, so I removed the dependency
> on it in libguestfs. However libguestfs certainly *could* use grub,
> if it was available. There's some heated discussion of this here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10
>
> and also in the archives of the current mailing list.
Why is a boot manager needed for a virtualized guest? It seems like
all you need is to point to a virtual disk (or current or past
snapshot) and go directly to loading the kernel.
If I could stuff < 1024 bytes of boot loader into ext4's two boot
sectors, that seems ways easier than dealing with grub.
http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html
Well this is a more general question about virtualization. I agree
that it's sometimes more convenient to use an external kernel and
initrd to boot a guest, and libvirt supports this mode (see the
<kernel> and <initrd> in libvirt XML). But:
(a) My understanding is this doesn't eliminate the need for a BIOS,
because I think early kernel code still calls into the BIOS, or at
least uses BIOS-created structures (eg. E820). It does however
eliminate the need to deal with grub.
(b) Maintaining a separate kernel and initrd outside the VM is a pain
when it comes to updates. How is 'yum' running in a VM supposed to
update a kernel stored outside the VM?
(c) It's generally better to remain as close as possible to baremetal,
just for ease of testing, reduced number of code paths, etc.
Note that none of this helps with libguestfs + grub. We want grub so
we can deal with existing guests, and they're already using grub
whether we like it or not :-(
And if there's a use case for UEFI VM's, why not use EFISTUB
instead of grub?
No idea sorry.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
11:24 a.m.
On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
Why is a boot manager needed for a virtualized guest? It seems like
all you need is to point to a virtual disk (or current or past snapshot) and go directly
to loading the kernel.
If I could stuff < 1024 bytes of boot loader into ext4's two boot sectors, that
seems ways easier than dealing with grub.
http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html
[My second answer, now that I've looked at that code and understand
better where you're going with this ...]
Yes, I think this is all possible, and probably better than emulating
what the BIOS does. Even better would be if you could get those 1024
bytes down to 512 bytes (and thus fit it in a boot sector). Then no
changes to existing hypervisors would be needed at all, and it would
run on baremetal.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
11:29 a.m.
On 12/07/2012 08:49 AM, Panu Matilainen wrote:
Yes, I think we're both trying to say the same thing: there's
no point having 'grub' in the repositories as its not installable or usable in
practise. The same goes for bunch of other obsoleted packages as well.
yum is not the only tool available.
Using rpm: erase grub2 if it is present; install grub [grub1].
There are other tools, too. rpm2cpio comes to mind.
--
11:58 a.m.
On Fri, Dec 07, 2012 at 09:29:28AM -0800, John Reiser wrote:
> Yes, I think we're both trying to say the same thing:
there's no point
> having 'grub' in the repositories as its not installable or usable in
> practise. The same goes for bunch of other obsoleted packages as well.
yum is not the only tool available.
But it is the package manager for the distro. More importantly, it's not
really about yum. *Any* package manager which respects what the packages say
("grub2 obsoletes grub") will do the same.
Using rpm: erase grub2 if it is present; install grub [grub1].
And then the next time you do a general package upgrade, presto, you've got
grub2 again. This is a kludge, basically, akin to installing firefox-12.0-1
from the F17 release tree even though firefox-17.0 is F17 updates.
There are other tools, too. rpm2cpio comes to mind.
Really???
And sure, you can build grub from source. But we're getting pretty far off
from being actually _Fedora_.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:59 a.m.
On Fri, Dec 07, 2012 at 06:49:25PM +0200, Panu Matilainen wrote:
My comment was simply on the "if you have both" part:
it's not
really possible to have both without playing dirty tricks, so even
the "if" is pretty moot.
My point is that it's not really possible to have *grub* without playing
tricks (maybe not dirty ones).
Yes, I think we're both trying to say the same thing: there's
no
point having 'grub' in the repositories as its not installable or
usable in practise. The same goes for bunch of other obsoleted
packages as well.
Are there other obsoleted packages in the F18 repo? Is there a good way to
look for them and to clean them up before release?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
1:15 p.m.
On 12/07/2012 07:59 PM, Matthew Miller wrote:
On Fri, Dec 07, 2012 at 06:49:25PM +0200, Panu Matilainen wrote:
> My comment was simply on the "if you have both" part: it's not
> really possible to have both without playing dirty tricks, so even
> the "if" is pretty moot.
My point is that it's not really possible to have *grub* without playing
tricks (maybe not dirty ones).
Sure, I'm not arguing to the contrary :)
> Yes, I think we're both trying to say the same thing: there's no
> point having 'grub' in the repositories as its not installable or
> usable in practise. The same goes for bunch of other obsoleted
> packages as well.
Are there other obsoleted packages in the F18 repo?
Yes there are, see
http://lists.fedoraproject.org/pipermail/buildsys/2012-November/004004.html
for a few examples of obsoleted packages that are not only in the
repositories but getting pulled into DVD images too (or at least were at
the time, haven't looked after that).
Is there a good way to
look for them and to clean them up before release?
Should be doable with repoquery, but a custom script is likely to do a
better job. I can have a look when I'm a bit more awake than now, its
not exactly rocket science anyway.
- Panu -
1:42 p.m.
On Dec 7, 2012, at 10:24 AM, "Richard W.M. Jones" <rjones(a)redhat.com>
wrote:
On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
> Why is a boot manager needed for a virtualized guest? It seems like all you need is
to point to a virtual disk (or current or past snapshot) and go directly to loading the
kernel.
>
> If I could stuff < 1024 bytes of boot loader into ext4's two boot sectors,
that seems ways easier than dealing with grub.
> http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html
[My second answer, now that I've looked at that code and understand
better where you're going with this …]
I'm casually suggesting a vastly simpler means of boot loading a VM that doesn't
have a dependency on grub. The host VM interface acting as the boot manager.
Yes, I think this is all possible, and probably better than emulating
what the BIOS does. Even better would be if you could get those 1024
bytes down to 512 bytes (and thus fit it in a boot sector). Then no
changes to existing hypervisors would be needed at all, and it would
run on baremetal.
ext[234] has two boot sectors for a total of 1024 bytes. XFS has none. Btrfs has 64KB.
It just seems like GRUB is a really familiar 4000 meter cargo train, compared to an
unfamiliar hand truck, for the task of moving half-dozen boxes. Maybe I'm
underestimating the size/weight of those boxes, but maintaining a grub installation, let
alone troubleshooting it if it breaks for some reason, is a lot more complicated than some
external source rewriting 1024 bytes to merely two sectors.
Chris Murphy
2:30 p.m.
On 12/07/2012 11:42 AM, Chris Murphy wrote:
ext[234] has two boot sectors for a total of 1024 bytes. XFS has
none. Btrfs has 64KB.
It just seems like GRUB is a really familiar 4000 meter cargo train, compared to an
unfamiliar hand truck, for the task of moving half-dozen boxes. Maybe I'm
underestimating the size/weight of those boxes, but maintaining a grub installation, let
alone troubleshooting it if it breaks for some reason, is a lot more complicated than some
external source rewriting 1024 bytes to merely two sectors.
Some real BIOS+MBR demand that the last 2 bytes in a boot sector be 0xAA55.
So sometimes the first sector has only 510 usable bytes. If the same code
reads the second sector, then that sector also might have only 510 usable bytes.
Those 2+2 bytes mattered to me when I wrote mine.
--
9:21 p.m.
Hi Rich,
On 07.12.2012 18:54, Richard W.M. Jones wrote:
Well this is a more general question about virtualization. I agree
that it's sometimes more convenient to use an external kernel and
initrd to boot a guest, and libvirt supports this mode (see the
<kernel> and <initrd> in libvirt XML). But:
We are using libvirt in the above fashion for a while - with a little
help from salt recently (on every yum (kernel) update the host changes
the dom definition for the appropriate guest via the python (libvirt)
bindings)
Our disks for the VMs are regular ext4 LVs (without partitions and
bootloaders)
Thank you for the great platform!
Alek
2:55 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On 12/07/2012 07:59 PM, Matthew Miller wrote:
Are there other obsoleted packages in the F18 repo?
Here's what I see on F18, it's quite a pile:
4ti2-1.3.2-12.fc18.x86_64
anyremote2html-1.4-4.fc18.noarch
chktex-1.6.4-11.fc18.x86_64
classads-1.0.8-5.fc18.i686
classads-1.0.8-5.fc18.x86_64
classads-devel-1.0.8-5.fc18.i686
classads-devel-1.0.8-5.fc18.x86_64
classads-static-1.0.8-5.fc18.i686
classads-static-1.0.8-5.fc18.x86_64
cura-account-0.0.4-1.fc18.x86_64
cura-fan-0.0.4-1.fc18.x86_64
cura-networking-0.0.4-1.fc18.x86_64
cura-powermanagement-0.0.4-1.fc18.x86_64
cura-providers-0.0.4-1.fc18.i686
cura-providers-0.0.4-1.fc18.x86_64
cura-providers-devel-0.0.4-1.fc18.i686
cura-providers-devel-0.0.4-1.fc18.x86_64
cura-service-0.0.4-1.fc18.x86_64
cura-storage-0.3-1.fc18.noarch
cura-tools-0.1-3.fc18.noarch
django-keyedcache-1.4.1-4.fc18.noarch
django-mako-0.1.4-0.5.pre.fc18.noarch
django-pylibmc-0.2.1-4.20110806gitb56e74.fc18.noarch
dvisvgm-1.0.12-2.fc18.x86_64
english-typing-booster-0.0.2-2.fc18.noarch
fcitx-keyboard-0.1.3-1.fc18.x86_64
gpxe-bootimgs-1.0.1-7.fc18.noarch
gpxe-roms-1.0.1-7.fc18.noarch
gpxe-roms-qemu-1.0.1-7.fc18.noarch
grc-0.70-9.fc18.noarch
1:grub-0.97-91.fc18.x86_64
gtksourceview2-sharp-1.0-10.svn89788.fc16.x86_64
gtksourceview2-sharp-devel-1.0-10.svn89788.fc16.i686
gtksourceview2-sharp-devel-1.0-10.svn89788.fc16.x86_64
ibus-european-table-1.1.6-2.fc18.noarch
ibus-hunspell-table-0.0.8-2.fc18.noarch
ibus-indic-table-1.3.1-23.fc17.noarch
ibus-table-array30-1.2.0.20090729-4.fc18.noarch
jadetex-3.13-12.fc18.noarch
jaffl-0.5.9-1.fc16.noarch
jaxen-bootstrap-1.1-6.2.fc18.noarch
kdirstat-2.5.3-13.fc18.x86_64
latexmk-4.35-1.fc18.noarch
libgssapi-0.11-11.fc18.i686
libgssapi-0.11-11.fc18.x86_64
libgssapi-devel-0.11-11.fc18.i686
libgssapi-devel-0.11-11.fc18.x86_64
lzma-4.32.7-8.fc18.x86_64
manaworld-0.5.2-9.fc18.x86_64
manaworld-music-0.3-3.fc18.noarch
maven-shared-artifact-resolver-1.1-24.fc18.noarch
maven-shared-common-artifact-filters-1.3-24.fc18.noarch
maven-shared-dependency-tree-1.3-24.fc18.noarch
module-init-tools-3.16-6.fc18.x86_64
netxen-firmware-4.0.534-6.fc18.noarch
nfs-utils-lib-1.1.5-7.fc18.i686
nfs-utils-lib-1.1.5-7.fc18.x86_64
nss_ldap-265-10.fc17.i686
nss_ldap-265-10.fc17.x86_64
pam_passwdqc-1.0.5-10.fc18.i686
pam_passwdqc-1.0.5-10.fc18.x86_64
pdfjam-2.08-4.fc18.noarch
pexpect-2.3-8.fc18.noarch
ps2eps-1.68-4.fc18.x86_64
pymongo-2.1.1-2.fc18.x86_64
pymongo-gridfs-2.1.1-2.fc18.x86_64
python-cryptsetup-0.1.4-4.fc18.x86_64
ql2100-firmware-1.19.38-6.fc18.noarch
ql2200-firmware-2.02.08-6.fc18.noarch
ql23xx-firmware-3.03.28-4.fc18.noarch
qxmpp-dev-0.6.3.1-1.fc18.i686
qxmpp-dev-0.6.3.1-1.fc18.x86_64
qxmpp-dev-devel-0.6.3.1-1.fc18.i686
qxmpp-dev-devel-0.6.3.1-1.fc18.x86_64
rt61pci-firmware-1.2-10.fc18.noarch
rt73usb-firmware-1.8-10.fc18.noarch
ruby-goocanvas-0.90.4-1.9.fc18.1.x86_64
ruby-goocanvas-devel-0.90.4-1.9.fc18.1.i686
ruby-goocanvas-devel-0.90.4-1.9.fc18.1.x86_64
ruby-gstreamer-0.90.4-1.9.fc18.1.x86_64
ruby-gstreamer-devel-0.90.4-1.9.fc18.1.i686
ruby-gstreamer-devel-0.90.4-1.9.fc18.1.x86_64
ruby-gtksourceview2-0.90.4-1.9.fc18.1.x86_64
ruby-gtksourceview2-devel-0.90.4-1.9.fc18.1.i686
ruby-gtksourceview2-devel-0.90.4-1.9.fc18.1.x86_64
seahorse-plugins-2.91.6-0.5.git1e35fd9.fc18.x86_64
sshfp-1.2.2-4.fc18.noarch
tetex-IEEEtran-1.7.1-6.fc18.noarch
texlive-texmf-2007-42.fc18.noarch
texlive-texmf-afm-2007-42.fc18.noarch
texlive-texmf-context-2007-42.fc18.noarch
texlive-texmf-doc-2007-42.fc18.noarch
texlive-texmf-dvips-2007-42.fc18.noarch
texlive-texmf-east-asian-2007-42.fc18.noarch
texlive-texmf-errata-2007-10.fc18.noarch
texlive-texmf-errata-afm-2007-10.fc18.noarch
texlive-texmf-errata-context-2007-10.fc18.noarch
texlive-texmf-errata-doc-2007-10.fc18.noarch
texlive-texmf-errata-dvips-2007-10.fc18.noarch
texlive-texmf-errata-east-asian-2007-10.fc18.noarch
texlive-texmf-errata-fonts-2007-10.fc18.noarch
texlive-texmf-errata-latex-2007-10.fc18.noarch
texlive-texmf-errata-xetex-2007-10.fc18.noarch
texlive-texmf-fonts-2007-42.fc18.noarch
texlive-texmf-latex-2007-42.fc18.noarch
texlive-texmf-xetex-2007-42.fc18.noarch
utouch-evemu-1.0.8-3.fc18.i686
utouch-evemu-1.0.8-3.fc18.x86_64
utouch-evemu-devel-1.0.8-3.fc18.i686
utouch-evemu-devel-1.0.8-3.fc18.x86_64
yum-plugin-downloadonly-1.1.31-6.fc18.noarch
Is there a good way to
look for them and to clean them up before release?
Here's the dumb little scriptlet used to produce the above list on my
F18 box. For "real world" purposes you'd want at least some control over
what repositories are enabled...
---
#!/usr/bin/python
import yum
if __name__ == '__main__':
my = yum.YumBase()
my.doConfigSetup()
my.doRepoSetup()
my.doSackSetup()
obsoleted = []
for p in my.pkgSack:
obsoleters = p.obsoletedBy(my.pkgSack.searchObsoletes(p.name))
if obsoleters:
obsoleted.append(p)
obsoleted.sort()
for o in obsoleted:
print o
---
- Panu -
3:18 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, 21 Dec 2012 10:55:15 +0200, Panu Matilainen wrote:
On 12/07/2012 07:59 PM, Matthew Miller wrote:
>
> Are there other obsoleted packages in the F18 repo?
Here's what I see on F18, it's quite a pile:
qxmpp-dev-0.6.3.1-1.fc18.i686
qxmpp-dev-0.6.3.1-1.fc18.x86_64
qxmpp-dev-devel-0.6.3.1-1.fc18.i686
qxmpp-dev-devel-0.6.3.1-1.fc18.x86_64
This has been renamed to "qxmpp" in review request bug 856114 without
completing the "After the review" steps, however:
https://fedoraproject.org/wiki/Package_Renaming_Process
--
Fedora release 18 (Spherical Cow) - Linux 3.6.11-3.fc18.x86_64
loadavg: 0.24 0.26 0.19
9:19 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 1:55 AM, Panu Matilainen
<pmatilai(a)laiskiainen.org> wrote:
Here's what I see on F18, it's quite a pile:
[snip]
latexmk-4.35-1.fc18.noarch
This one should not be obsoleted. See
https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate
Jindrich doing something about that before release.
--
Jerry James
http://www.jamezone.org/
9:28 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 08:19:58AM -0700, Jerry James wrote:
<pmatilai(a)laiskiainen.org> wrote:
> Here's what I see on F18, it's quite a pile:
[snip]
> latexmk-4.35-1.fc18.noarch
This one should not be obsoleted. See
https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate
Jindrich doing something about that before release.
This should be raised as a FESCO ticket.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:55 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 8:28 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Fri, Dec 21, 2012 at 08:19:58AM -0700, Jerry James wrote:
> <pmatilai(a)laiskiainen.org> wrote:
> > Here's what I see on F18, it's quite a pile:
> [snip]
> > latexmk-4.35-1.fc18.noarch
> This one should not be obsoleted. See
> https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate
> Jindrich doing something about that before release.
This should be raised as a FESCO ticket.
Sorry, it must be too early in the morning for my brain to work
properly. What would I be asking FESCO to do?
--
Jerry James
http://www.jamezone.org/
9:59 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 08:55:22AM -0700, Jerry James wrote:
>> > Here's what I see on F18, it's quite a pile:
>> > latexmk-4.35-1.fc18.noarch
>> This one should not be obsoleted. See
>> https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate
>> Jindrich doing something about that before release.
> This should be raised as a FESCO ticket.
Sorry, it must be too early in the morning for my brain to work
properly. What would I be asking FESCO to do?
Decide between the two redundant and conflicting packagings of the same
code.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:13 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 8:59 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Fri, Dec 21, 2012 at 08:55:22AM -0700, Jerry James wrote:
> Sorry, it must be too early in the morning for my brain to work
> properly. What would I be asking FESCO to do?
Decide between the two redundant and conflicting packagings of the same
code.
Ah, got it, thanks. Here's the ticket:
https://fedorahosted.org/fesco/ticket/983
--
Jerry James
http://www.jamezone.org/
10:24 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, 21 Dec 2012 09:13:27 -0700
Jerry James <loganjerry(a)gmail.com> wrote:
On Fri, Dec 21, 2012 at 8:59 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Fri, Dec 21, 2012 at 08:55:22AM -0700, Jerry James wrote:
>> Sorry, it must be too early in the morning for my brain to work
>> properly. What would I be asking FESCO to do?
>
> Decide between the two redundant and conflicting packagings of the
> same code.
Ah, got it, thanks. Here's the ticket:
https://fedorahosted.org/fesco/ticket/983
Well, IMHO reading the bug it just sounds like to me a mistake was made
and the obsoletes/conflicts was not removed as intended:
+* Sun Nov 4 2012 Jindrich Novy <jnovy(a)redhat.com> 2012-5-20121024
+- don't conflict with latexmk (#868996)
(but that version didn't change obsoletes/conflicts at all)
I'd suggest instead just mailing jnovy and asking if that was a mistake
and if he could push the correct fix before jumping to conclusions.
kevin
10:41 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 9:24 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
Well, IMHO reading the bug it just sounds like to me a mistake was
made
and the obsoletes/conflicts was not removed as intended:
+* Sun Nov 4 2012 Jindrich Novy <jnovy(a)redhat.com> 2012-5-20121024
+- don't conflict with latexmk (#868996)
(but that version didn't change obsoletes/conflicts at all)
Ah, that makes sense.
I'd suggest instead just mailing jnovy and asking if that was a
mistake
and if he could push the correct fix before jumping to conclusions.
Hmm, I didn't think I had jumped to any conclusions. That's why I was
patiently waiting for a response on the bug. I only spoke up because
I was afraid that the appearance of latexmk on this list meant that
its destruction was imminent. In any case, Jindrich has been CCed to
the FESCO ticket, so I'll just wait for a response there.
Or maybe you aren't talking to me. I think it's too late in the
morning for me to claim that it's too early in the morning for my
brain to be working properly. I think I have to admit now that my
brain is already entering full "Christmas vacation" mode. C'mon
brain, back to work....
--
Jerry James
http://www.jamezone.org/
11:28 a.m.
New subject: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 10:55:15AM +0200, Panu Matilainen wrote:
Here's what I see on F18, it's quite a pile:
I made a Rel-Eng ticket: https://fedorahosted.org/rel-eng/ticket/5427
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4167
days inactive
4182
days old
27 comments
10 participants
participants (10)
-
Adam Williamson -
Alek Paunov -
Chris Murphy -
Jerry James -
John Reiser -
Kevin Fenzi -
Matthew Miller -
Michael Schwendt -
Panu Matilainen -
Richard W.M. Jones