Am Donnerstag, 5. Mai 2011 schrieb Cristian Rodríguez:

El 04/05/11 17:52, Stefan Seyfried escribió:

...

Hi,

bluez-4.93 got hid2hci back, it was on holiday in the udev sources for some time.

The rpmlintrc from udev in FACTORY looks innocent. Why did it build at all?

And how do I get rid of that error? I don't care about "separate /usr" crap.

This insanity is part of brp-check-suse, I think redefining macro %_suse_os_install_post (look at /etc/rpm/macros.brp) "somewhere" ;) to exclude /usr/lib/rpm/brp-rootfs should get rid of it.

In case someone reads this and does not understand irony: this is not a valid solution for something you want to submit to openSUSE:Factory Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Thu, 5 May 2011 11:34:17 +0200 Stephan Kulow wrote:

In case someone reads this and does not understand irony: this is not a valid solution for something you want to submit to openSUSE:Factory

care to explain what a valid solution is in your opinion? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Thu, 05 May 2011 01:13:32 +0200 Dave Plater wrote:

On 05/04/2011 10:52 PM, Stefan Seyfried wrote:

...

bluez-4.93 got hid2hci back, it was on holiday in the udev sources for some time.

Unfortunately, the test build fails:

+ /usr/lib/rpm/brp-rpath + /usr/lib/rpm/brp-pie + /usr/lib/rpm/brp-rootfs library /lib/udev/hid2hci is linked against libraries in /usr or /opt libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f77e36e7000) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007f77e2f5d000)

Stupid (or maybe inteligent) question, what happens if you reverse the situation in %install and have the target in in the directory where the link is and the link in the targets original directory?

It's not a symlink. It's a binary (/lib/udev/hid2hci) using a library from /usr/ And in general, the bluez package is one of the cleanest, best-housekept and distro compliant upstream package I have ever packaged, so I am very hesitant to patch around some distro crap in it, just in order to be laughed at later when I have to report a problem upstream. And udev in FACTORY does survive this check, even if I don't know how... But Cristians hint made the difference: redefining _suse_os_install_post fixes all those nasty annoyances and even speeds up the build significantly. I guess I have to do this in all my spec files :-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Thu, May 05, 2011 at 10:43:56AM +0200, Yamaban wrote:

On Thu, 5 May 2011 10:19, Stefan Seyfried wrote:

...

On Thu, 05 May 2011 01:13:32 +0200 Dave Plater wrote:

...

On 05/04/2011 10:52 PM, Stefan Seyfried wrote:

...

bluez-4.93 got hid2hci back, it was on holiday in the udev sources for some time.

Unfortunately, the test build fails:

+ /usr/lib/rpm/brp-rpath + /usr/lib/rpm/brp-pie + /usr/lib/rpm/brp-rootfs library /lib/udev/hid2hci is linked against libraries in /usr or /opt libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f77e36e7000) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007f77e2f5d000)

Stupid (or maybe inteligent) question, what happens if you reverse the situation in %install and have the target in in the directory where the link is and the link in the targets original directory? <snip>

What I don't really get is: why is libusb-1_0-0 / libusb-0_1-4 in /usr/{lib,lib64}/ and not in /{lib,lib64}/ ?

Isn't it defined the way that libs for boot should be in /{lib,lib64}/ ? the way bluez uses libusb, and also some lan/wlan/storage-over-usb, software, I can't find a point for libusb to reside in /usr/.

Is there some consens / thought / definition why libusb is in /usr/ beyond inerta / original-non-boot-usage ?

I'm asking because I can't find any docu why it is this way.

libusb just was not used during boot before, so this question did not came up. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Thu, 5 May 2011 12:01, Stefan Seyfried wrote:

On Thu, 5 May 2011 10:52:50 +0200 Marcus Meissner wrote:

...

libusb just was not used during boot before, so this question did not came up.

Of course it was. hid2hci from udev is the same as hid2hci from bluez-4.93, so I'm really not sure why bluez should be a second class citizen and not allowed to do that while udev is allowed.

Would it be the logical to move libusb to /lib{,64}/ to avoid further infractions against the "/lib link against /usr" rule? I do not see a great difference between /lib{,64}/ and /usr/lib{,64}/ after boot for the most if not all applications. (one run of ldconfig) Should there be a vote on the move? or just do the move and be happy? Regards, Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 05/05/11 05:19, Stefan Seyfried escribió:

But Cristians hint made the difference: redefining _suse_os_install_post fixes all those nasty annoyances and even speeds up the build significantly. I guess I have to do this in all my spec files :-)

LOL, I should keep my mouth shout it seems.. or maybe write a list of the most fugly misuses of the build system 0:-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stefan Seyfried wrote:

On Thu, 05 May 2011 20:41:44 -0300 Cristian Rodríguez wrote:

...

El 05/05/11 05:19, Stefan Seyfried escribió:

...

But Cristians hint made the difference: redefining _suse_os_install_post fixes all those nasty annoyances and even speeds up the build significantly. I guess I have to do this in all my spec files :-)

LOL, I should keep my mouth shout it seems.. or maybe write a list of the most fugly misuses of the build system 0:-)

I at least suppressed the instant desire to file a droprequest for the bluez-package, so I guess you certainly helped the project.

If openSUSE wants to make packagers run away screaming, such fascist build checks are a very good way to achieve that.

Note that nobody responded on the question how to do it right, so this ugly hack seems to be the best we have now.

Also nobody responded on why udev is allowed to do that (link against libusb in /usr) but bluez is not. That's clearly some new form of apartheid :-)

Want to invoke godwins law? Looking at the (not exactly new) brp-rootfs it runs a 'file' on all files in /lib and greps for "shared object". So binaries would slip through. So I would guess that the binary you have is compiled using -fpie so it gets caught by the check. So the answer to the question "why is udev allowed to do that" is "it isn't", the check just didn't catch it and noone noticed. If we'd fix the check to also search for binaries in /lib udev would fail too. The right fix would be to move libusb to /lib I guess. Independent of that the check should be ported to rpmlint for easier whitelist handling. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 06/05/11 13:37, Yamaban escribió:

No, please no whitelisting in this case.

Let's get back to the cause of BOTH failures: libusb

Is there any point in NOT moveing libusb to /lib intead of /usr/lib ?

Please, the rootfs check makes sense, so why, please, not to correct the source of the trouble?

No it doesn't, I dont know how many times or how many people have to say it, the scenario this check attempts to support is esentially doomed to failure, and can be worked around in even more creative ways than redefining _suse_os_install_post, dlopen() comes to my mind too :-D -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Fri, May 06, 2011 at 06:37:38PM +0200, Yamaban wrote:

No, please no whitelisting in this case.

Let's get back to the cause of BOTH failures: libusb

Is there any point in NOT moveing libusb to /lib intead of /usr/lib ?

I don't have a problem with moving it, as it would be nice to use it for some packages early in the boot process (i.e. this one.) I think I'm the libusb openSUSE maintainer, or at least one of them, so I can make this change if no one objects. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org