Mailing List Archive

On P, 2007-07-29 at 18:44 +0200, Sven Köhler wrote:
> Hi,
>
> so today, pciutils-2.2.4-r3 went stable on x86.
> It's a known issue, that pciutils compiled with zlib use-flag turned on
> (which is default) doesn't work with the version of hal, which is
> currently stable on x86.
>
> So at the moment, hal-0.5.9-r1 is stable on x86. It went stable weeks or
> even months ago. Now, pciutils-2.2.4-r3 is compiled with zlib use-flag
> turned on. There are now warning, errors, or any other messages about
> the zlib use-flag - well, until you recompile hal.
>
> The hal-ebuild checks, whether pciutils has been built with or without
> the zlib use-flag. But what is this check worth, if people have already
> upgraded hal weeks ago and the uncompatibility between pciutils and hal
> is now unnoticed?
>
>
> Why did you provocate this breakage?
>
>
> This is not a good idea, IMHO.

No. And many gave up getting this sensible again.
As is, the default USE flags for a desktop profile lead to a compilation
failure when unattended due to this, which is very very bad.

At one point I thought I will simply not stabilize GNOME-2.18 until
pciutils is fixed to follow what upstream wants, what most other
maintainers wish, and what is sensible to do. I see no reason whatsoever
for this gzipping, not even for embedded devices as a gzipped file can't
be mmapped.
Then I realized GNOME-2.16 compilation for a fresh system with desktop
profiles is broken now also anyhow.

--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

On Sunday, 29. July 2007 18:44:23 Sven Köhler wrote:
> Why did you provocate this breakage?
> This is not a good idea, IMHO.

I think so, too. cf. http://bugs.gentoo.org/show_bug.cgi?id=166790

Best regards, Wulf

Don Sonntag, 29. Juli 2007, Sven Köhler wrote:
> Why did you provocate this breakage?

Which breakage? It didn't install a gzipped pci.ids here.


On the other hand, reading the utterly ridiculous bug 180554, I haven't read a
valid argument why it should at all. Bizarre.


Carsten

On Sonntag, 29. Juli 2007, Carsten Lohrke wrote:
> Don Sonntag, 29. Juli 2007, Sven Köhler wrote:
> > Why did you provocate this breakage?
>
> Which breakage? It didn't install a gzipped pci.ids here.

That is with USE=hal. Crap...


Carsten

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

2007-07-29 20:03:55 Sven Köhler napisał(a):
> >>> Why did you provocate this breakage?
> >>
> >> Which breakage? It didn't install a gzipped pci.ids here.
> >
> > That is with USE=hal. Crap...
>
> Oh! So USE="hal" forces pciutils not to use zlib?
>
> And so the check, which the hal ebuild performs, should be modified to
> check for USE="hal" rather than for USE="!zlib" ?

This check should be removed.

- --
Arfrever Frehtes Taifersar Arahesis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)

iD8DBQFGrNuc/axNJ4Xo/ZERAsM5AKCYKXU/Om0cm7/Y8DjJ8nrir+EKNQCfZWOm
QQWAUattsJEbi/de8p22tYQ=
=LJqQ
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Sven Köhler wrote:
>>>> Why did you provocate this breakage?
>>> Which breakage? It didn't install a gzipped pci.ids here.
>> That is with USE=hal. Crap...
>
> Oh! So USE="hal" forces pciutils not to use zlib?
>
> And so the check, which the hal ebuild performs, should be modified to
> check for USE="hal" rather than for USE="!zlib" ?
>
Except that ONLY that version that recently went stable has the useflag.
So the check will need to be modified (thanks carlo for that amazingly
useful bug report!) but will still need to make sure that its not built
with zlib for 2.2.6 until someone gets around to adding the hal useflag
there as well, apparently.
--
gentoo-dev@gentoo.org mailing list

On Sun, 2007-07-29 at 13:15 -0600, Ryan Hill wrote:
> Wulf C. Krueger wrote:
> >> Why did you provocate this breakage?
> >> This is not a good idea, IMHO.
> >
> > I think so, too. cf. http://bugs.gentoo.org/show_bug.cgi?id=166790
>
> That has got to be one of the stupidest bug reports i've ever seen.

Do you think you might add something productive to this thread by
explaining why? Really, if you're just sharing your opinion like this,
it's not conducive to discussion, and it rather belongs on -project or
your blog.

thanks,

Seemant

>>>>> "Sven" == Sven Köhler <skoehler@upb.de> writes:

Sven> Oh! So USE="hal" forces pciutils not to use zlib?

There are many more ebuilds than just hal which fail with a compressed
pci.ids file. And many of them are non-obvious. It took me more than
I little bit of effort after the zlib USE flag was first added to the
pciutils ebuild to figure out why so many packages where failing...

(On an old enough install, with enough disparate packages installed, a
naïve emerge world will always fail. *Something* is guaranteed to be
unhappy.)

The lunacy is that compressing pci.ids and usb.ids helps no-one. On a
system running from a spinning disk the size difference is lost in the
noise. On embedded systems one knows in advance what devices exist on
the motherboard and can edit the ids file down to just those. Most
embedded systems don't even need the ids files on the production load.
No developer worth his salt would waste space on names where the numbers
work just as well. They'd use the names on the development platform, of
course, but those would be complied to just the ints on the final load.

So, simply put, compressing pci.ids benefits no-one, and harms many.

A cool hack perhaps, but misguided and useless.

The pciutils ebuild should be re-engineered to use separate USE flags
for linking to libz and compressing the database. Or the database
should be an ebuild of its own, using a custom flag (compressed?) to
request compression of the ids file, and not the zlib flag.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
--
gentoo-dev@gentoo.org mailing list

On Thu, Aug 02, 2007 at 05:19:02PM -0600, Ryan Hill wrote:
> > Oh! Really? Which ones?
> app-laptop/smcinit
> app-misc/ddccontrol
> sys-apps/hwsetup
> sys-apps/{lib,}kudzu
> sys-apps/vbetool
> sys-boot/efibootmgr
> sys-power/athcool
>
> are some we have on file so far.
> > So it seems, there are many many handwritten parsers out there?

From the bugs I've fixed because of pciutils zlib support, it's not much
in the way of custom parsers, it's rather just a lot of getting zlib
included in the linker call.

--
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

On Thu, 2007-08-02 at 08:23 -0400, James Cloos wrote:
> There are many more ebuilds than just hal which fail with a compressed
> pci.ids file. And many of them are non-obvious. It took me more than
> I little bit of effort after the zlib USE flag was first added to the
> pciutils ebuild to figure out why so many packages where failing...

This might have been the case way back then, but we've been cleaning up
any ebuilds since. I know that there is nothing that we've been made
aware of anymore that *doesn't* work with a compressed pci.ids file,
since most use the library and simply required linking with zlib to
build/link.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On Thu, 2007-08-02 at 14:15 +0100, Steve Long wrote:
> James Cloos wrote:
> > The pciutils ebuild should be re-engineered to use separate USE flags
> > for linking to libz and compressing the database.
> ++
> It may be what upstream (pciutils) do by default, but no other distro ships
> with compressed ids for the reasons you outline (and you can't mmap the
> file). It breaks a default desktop installation (aiui) so it really
> shouldn't use a default system-wide USE flag, but a local one. Anyone who
> really wants it can set it, and everyone else's machines will still work.
> As Mr Gianelloni spelt out on bugzilla[1]:
> "when you install from stage3, then immediately type "emerge [blah]", I
> would expect it to work. If it does not, then it is a failure in the
> ebuild and a bug... it is your responsility to ensure that your package is
> not broken with a default installation."

That isn't policy, as much as I would like it to be.

Also, both hal and zlib are in USE in the default profiles, so it does
work out of the box right now.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

>>>>> "Sven" == Sven Köhler <skoehler@upb.de> writes:

JimC> There are many more ebuilds than just hal which fail with a
JimC> compressed pci.ids file.

Sven> Oh! Really? Which ones?

I didn't keep a list, but Ryan's post lists some packages I remember
having had problems.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6


--
gentoo-dev@gentoo.org mailing list

>> Why did you provocate this breakage?
>> This is not a good idea, IMHO.
>
> No. And many gave up getting this sensible again.
> As is, the default USE flags for a desktop profile lead to a compilation
> failure when unattended due to this, which is very very bad.

I'm not even complaining about that.

I will get a message, that i have to edit /etc/portage/package.use. So i
do that, and after that i'm happy and everything compiles.


But now, x86 users out there, will upgrade pciutils. They will not get
any message about the breakage. They will not realize what's wrong.

The hal-maintainers did their job: they checked, whether the zlib
use-flag is set properly for pciutils. But this check is not executed,
since hal has not been revbumbed on x86.

And the pciutils-maintainers? They should check, where hal is installed
- or maybe they should simply check the hal use-flag.
And then, they should output a message, that the zlib use-flag would
actually do harm. But the ebuild doesn't do that.



So i think, right now, during these hours, clueless x86 gentoo users
will upgrade their pciutils, not even realizing, that should do that
with disabled zlib use-flag.


I'm becoming a little sarcastic, but i hope, the problems with
disharmony causes, will be noticed soon by others.

>>> Why did you provocate this breakage?
>> Which breakage? It didn't install a gzipped pci.ids here.
>
> That is with USE=hal. Crap...

Oh! So USE="hal" forces pciutils not to use zlib?

And so the check, which the hal ebuild performs, should be modified to
check for USE="hal" rather than for USE="!zlib" ?

Wulf C. Krueger wrote:
>> Why did you provocate this breakage?
>> This is not a good idea, IMHO.
>
> I think so, too. cf. http://bugs.gentoo.org/show_bug.cgi?id=166790

That has got to be one of the stupidest bug reports i've ever seen.

--
dirtyepic you'd be tossed up or wash up, the narrator relates
gentoo org in a spartan antarctican walk for many days
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)

--
gentoo-dev@gentoo.org mailing list

James Cloos wrote:
> The pciutils ebuild should be re-engineered to use separate USE flags
> for linking to libz and compressing the database.
++
It may be what upstream (pciutils) do by default, but no other distro ships
with compressed ids for the reasons you outline (and you can't mmap the
file). It breaks a default desktop installation (aiui) so it really
shouldn't use a default system-wide USE flag, but a local one. Anyone who
really wants it can set it, and everyone else's machines will still work.
As Mr Gianelloni spelt out on bugzilla[1]:
"when you install from stage3, then immediately type "emerge [blah]", I
would expect it to work. If it does not, then it is a failure in the
ebuild and a bug... it is your responsility to ensure that your package is
not broken with a default installation."

I don't know if that's policy or not, but imo it should be.

On a wider note, it seemed to me from the bug to be more of a dispute
between HAL upstream and pciutils upstream. I wonder how many such disputes
are actually resolved within Gentoo, since it seems the kind of thing that
would show up most in a source distro.
(And as such shows another reason why Gentoo is so important to the wider
community. Certainly devs from other projects i've met on IRC who use
Gentoo seem a lot less stressed than those on other distros.. ;)

[1] http://bugs.gentoo.org/show_bug.cgi?id=120088#c3


--
gentoo-dev@gentoo.org mailing list

> There are many more ebuilds than just hal which fail with a compressed
> pci.ids file. And many of them are non-obvious. It took me more than
> I little bit of effort after the zlib USE flag was first added to the
> pciutils ebuild to figure out why so many packages where failing...

Oh! Really? Which ones?

So it seems, there are many many handwritten parsers out there?

Sven Köhler wrote:
>> There are many more ebuilds than just hal which fail with a compressed
>> pci.ids file. And many of them are non-obvious. It took me more than
>> I little bit of effort after the zlib USE flag was first added to the
>> pciutils ebuild to figure out why so many packages where failing...
>
> Oh! Really? Which ones?

app-laptop/smcinit
app-misc/ddccontrol
sys-apps/hwsetup
sys-apps/{lib,}kudzu
sys-apps/vbetool
sys-boot/efibootmgr
sys-power/athcool

are some we have on file so far.


--
dirtyepic you'd be tossed up or wash up, the narrator relates
gentoo org in a spartan antarctican walk for many days
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)

--
gentoo-dev@gentoo.org mailing list