[devel-xorg-modular] Master bug (Bug #423)


Added by Sukneet Basuta almost 3 years ago. Updated 5 months ago.


Status:In Progress Start date:03/17/2013
Priority:Normal Due date:
Assignee:Eric Sandall % Done:

0%

Category:**master**
Target version:0.63
Grimoire:Test

Description

Main spell(s) of interest:
All the xorg spells.
libpthread-stubs

issues:
ABI incompatible update of libpthread-stubs. All dependent spells need to be recast in UP_TRIGGERS.

Notes:
None.

What is needed to get it merged into master?

David Kowis wrote:

I'd like for someone with experience in the X branch to come up with a
list of criteria, maybe search the list history for issues people have
had upgrading, and then build a test plan, or a checklist to verify that
we won't have these issues on this upgrade.

Then once that passes, we'll merge it. Sound good?


0001-libpthread-stubs-added-a-bunch-of-spells.patch - The patch proposal from Sukneet (2.4 kB) Thomas Orgis, 08/29/2014 02:42 am

0001-libpthread-stubs-Force-the-build-of-the-library.patch (1.2 kB) Ismael Luceno, 01/02/2015 08:53 pm


Issue hierarchy

Bug #423: [devel-xorg-modular] Master bugIn ProgressEric Sandall

Bug #531: [devel-xorg-modular] mesalibNew


Related issues

blocks Grimoire - Bug #376: nvidia_driver does not work if compiled with gcc 4.7.0 New 03/28/2012

History

Updated by Sukneet Basuta over 2 years ago

  • Start date changed from 08/03/2012 to 03/17/2013

Updated by Thomas Orgis 10 months ago

I wonder how bad this issue really is ... I did not encounter it from upgrading from a bare-bones (but X11 desktop with fluxbox running) system on test grimoire to devel-xorg-modular. But it may be hidden in the lots of other issues I encountered due to spell rot.

Oh, and the reason for upgrading to the devel branch: libxft in test doesn't build with freetype2 anymore as the latter like to move headers around and think that's normal. You are supposed to use special macros to allow them to continue shifting header structure. My neck hurts from head-shaking. The libxft in the devel branch works. Back-port? I'd rather just merge.

In case I was extremely lucky with my upgrade (this time from the chroot tarball we offer, not as ancient as the ISO), wouldn't it be a solution to compile the list of affected spells and prepare a script that dispels and then casts again? I don't expect anything automatic .. that's what gentoo or other normal distros are for.

Updated by Thomas Orgis 10 months ago

I hit the pthread-stubs issue just now: pango install failed (nasty that it's not in the building stage), re-casting cairo fixed that.

Updated by Eric Sandall 6 months ago

I'm building up a test VM for Sukneet's patch, but I think a better fix would be to set the proper DEPENDS on packages and then use show_up_depends in libpthread-stubs/UP_TRIGGERS.

  • Grimoire changed from Stable to Test
  • Target version set to 0.63
  • Assignee set to Eric Sandall
  • Category set to **master**
  • Status changed from New to In Progress

Updated by Ismael Luceno 6 months ago

Thomas Orgis was interested in keeping the library around, so am I.

We can, in fact, force 0.3 to build the library. Patch attached.

Updated by Sukneet Basuta 6 months ago

Rather than using my patch, it's probably better trying to rebuild everything with "-as-needed" and seeing if that solves the issue.

However, if we can just force building the library, that may be the easiest route.

@Ismael
Is there any issues forcing the build of the library? As far as I understand, libpthread-stubs doesn't really do anything on linux.

Updated by Ismael Luceno 6 months ago

No issues.

Actually the only difference is that applications depending on it will still find the .so, but that's all. Applications compiled after the upgrade will not link against it, because the pkg-config file isn't altered in any way.

Updated by Eric Sandall 6 months ago

Personally, I'd prefer we have the spells with the correct dependencies (which is what was missing originally; incomplete dependencies on libpthreads-stubs for a proper UP_TRIGGERS) and fix UP_TRIGGERS with show_up_depends. However, fixing DEPENDS also requires a PATCHLEVEL++ for each spell modified for show_up_depends to see it. I don't mind rebuilding packages if a dependency changes (if you don't like compiling, source-based is the wrong distro ;)), however this fix would require two recompiles (one for DEPENDS update, then again for libpthreads-stubs/UP_TRIGGERS). If forcing the library to be installed by glibc (IIRC this is where libpthreads-stubs .so file now exists) and has no affect as Ismael mentions in #8 other than fixing the bug, we should probably just do that.

My test VM almost has XFCE, KDE 4, and GNOME 3 installed for testing. I'm fixing compile issues as I find them. :) After that, it's snapshot time and then testing upgrading to devel-xorg-modular, but I could just as well test the glibc/libpthreads-stubs always build .so fix. I believe I misunderstood the 'quick fix' that Ismael was mentioning in IRC.

Updated by Eric Sandall 6 months ago

Or, based on your sm-discuss post ( http://lists.ibiblio.org/pipermail/sm-discuss/2015-January/021793.html ), you're talking about installing the bad/defunct library via libpthreads-stubs 0.3 (the version which breaks from 0.2 ABI), but which has a pkg-config entry that doesn't mention the library. So spells that haven't been recompiled against libpthreads-stubs-0.3 will continue to work, and once they're rebuild against libpthreads-stubs-0.3 they won't rely on the now defunct .so file, correct? To me, this just masks the problem instead of fixing it, which is what the DEPENDS + UP_TRIGGERS are to do. Assuming, of course, that we have a complete list of all packages affected by this, but I think Sukneet's list is complete enough to go forward with the DEPENDS + UP_TRIGGERS plan, if we want.

Updated by Thomas Orgis 6 months ago

Given that we have barely any visible manpower to get things going, I think that the hack to just build that library has much charm. If that's not the way to go, I hope we get the proper solution going quick. If you make it happen, please do so.

Updated by Sukneet Basuta 6 months ago

Eric Sandall wrote:

Personally, I'd prefer we have the spells with the correct dependencies (which is what was missing originally; incomplete dependencies on libpthreads-stubs for a proper UP_TRIGGERS) and fix UP_TRIGGERS with show_up_depends. However, fixing DEPENDS also requires a PATCHLEVEL++ for each spell modified for show_up_depends to see it. I don't mind rebuilding packages if a dependency changes (if you don't like compiling, source-based is the wrong distro ;)), however this fix would require two recompiles (one for DEPENDS update, then again for libpthreads-stubs/UP_TRIGGERS). If forcing the library to be installed by glibc (IIRC this is where libpthreads-stubs .so file now exists) and has no affect as Ismael mentions in #8 other than fixing the bug, we should probably just do that.

My test VM almost has XFCE, KDE 4, and GNOME 3 installed for testing. I'm fixing compile issues as I find them. :) After that, it's snapshot time and then testing upgrading to devel-xorg-modular, but I could just as well test the glibc/libpthreads-stubs always build .so fix. I believe I misunderstood the 'quick fix' that Ismael was mentioning in IRC.

The problem is that there is no way to fix DEPENDS and UP_TRIGGERS so everything casts properly when upgrading libpthread-stubs, or, at least, I couldn't find a way. Having a "complete" list results in cyclical dependencies because things are indirectly linked. As a result, you need to recast libpthread-stubs a bunch of times before everything builds correctly. IMO, that's not a good upgrade path. I haven't tried it yet, but using "-as-needed" should supposedly solve the issue. My patch isn't complete btw, there is still a bunch of spells missing from that list.

Updated by Ismael Luceno 6 months ago

Sukneet Basuta wrote:

The problem is that there is no way to fix DEPENDS and UP_TRIGGERS so everything casts properly when upgrading libpthread-stubs, or, at least, I couldn't find a way. Having a "complete" list results in cyclical dependencies because things are indirectly linked. As a result, you need to recast libpthread-stubs a bunch of times before everything builds correctly. IMO, that's not a good upgrade path. I haven't tried it yet, but using "-as-needed" should supposedly solve the issue. My patch isn't complete btw, there is still a bunch of spells missing from that list.

I tried that long ago, it didn't work, even with as-needed. I've been trying to solve this in other ways to no avail.

Updated by Ismael Luceno 6 months ago

Eric Sandall wrote:

Or, based on your sm-discuss post ( http://lists.ibiblio.org/pipermail/sm-discuss/2015-January/021793.html ), you're talking about installing the bad/defunct library via libpthreads-stubs 0.3 (the version which breaks from 0.2 ABI), but which has a pkg-config entry that doesn't mention the library. So spells that haven't been recompiled against libpthreads-stubs-0.3 will continue to work, and once they're rebuild against libpthreads-stubs-0.3 they won't rely on the now defunct .so file, correct? To me, this just masks the problem instead of fixing it, which is what the DEPENDS + UP_TRIGGERS are to do. Assuming, of course, that we have a complete list of all packages affected by this, but I think Sukneet's list is complete enough to go forward with the DEPENDS + UP_TRIGGERS plan, if we want.

Yes, it does build the "defunct" library.

Now, think about it, the breakage is gratuitous, the library was useless from the very beginning of it existence.

If avoiding the breakage costs even less than the "proper" fix, why not? The only reason to keep the package around is to make configure scripts happy, so why shouldn't we do the same with binaries?

Those weak symbols should have been managed locally on each package, if it were just a header file it would avoid the issue completely.

Since the circumstances are very special, I see no reason to not mask the problem and move forward.

Updated by Sukneet Basuta 6 months ago

Ismael Luceno wrote:

Yes, it does build the "defunct" library.

Now, think about it, the breakage is gratuitous, the library was useless from the very beginning of it existence.

If avoiding the breakage costs even less than the "proper" fix, why not? The only reason to keep the package around is to make configure scripts happy, so why shouldn't we do the same with binaries?

Those weak symbols should have been managed locally on each package, if it were just a header file it would avoid the issue completely.

Since the circumstances are very special, I see no reason to not mask the problem and move forward.

If that's the case, why don't we just remove the spell from the grimoire? That way new installs won't have it and people who already have it installed will be able to keep it.

Updated by Eric Sandall 6 months ago

Sukneet Basuta wrote:

Ismael Luceno wrote:

Yes, it does build the "defunct" library.

Now, think about it, the breakage is gratuitous, the library was useless from the very beginning of it existence.

If avoiding the breakage costs even less than the "proper" fix, why not? The only reason to keep the package around is to make configure scripts happy, so why shouldn't we do the same with binaries?

Those weak symbols should have been managed locally on each package, if it were just a header file it would avoid the issue completely.

Since the circumstances are very special, I see no reason to not mask the problem and move forward.

If that's the case, why don't we just remove the spell from the grimoire? That way new installs won't have it and people who already have it installed will be able to keep it.

I like both options, though I prefer the former as just leaving spells behind leaves cruft, IMO. Make it (make libpthreads-stubs-0.3 install the dummy .so file) so and I'll run a test on my VM install (I'd forgotten how much I dislike gobject-introspection and its mess).

The DEPENDS+UP_TRIGGERS fix would require DEPENDS+PATCHLEVEL on all packages, make sure they're all run to register their dependencies, before the UP_TRIGGERS is added to libpthreads-stubs. Or just include Sukneet's UP_TRIGGERS for recasting the hardcoded spells rather than relying on DEPENDS and show_up_depends, but we may be missing rare/missed packages, while both other proposed fixes just "fix" it for all time. :)

I'm back to work on 1/5 and won't have the free time that I had this week to help out with SMGL.

Updated by Ismael Luceno 6 months ago

Sukneet Basuta wrote:

<...>
If that's the case, why don't we just remove the spell from the grimoire? That way new installs won't have it and people who already have it installed will be able to keep it.

We can't remove it easily, because several Xorg packages depend on it at build time anyway.

Eric Sandall wrote:

I like both options, though I prefer the former as just leaving spells behind leaves cruft, IMO. Make it (make libpthreads-stubs-0.3 install the dummy .so file) so and I'll run a test on my VM install (I'd forgotten how much I dislike gobject-introspection and its mess).
<...>

Pushed.

Updated by Ismael Luceno 5 months ago

Besides some issues with GCC 4.9.2, the upgrade went fine.

I will be working on these issues so we can have a merge soon, but would not mind some help ;).

Also available in: Atom PDF