Re: [gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
On 2019.06.07 06:24, Ilya Trukhanov wrote: On Fri, Jun 07, 2019 at 08:03:30AM +0100, Sergei Trofimovich wrote: > On Thu, 06 Jun 2019 18:49:48 -0400 > Jack wrote: > > > On 2019.06.06 18:38, Ilya Trukhanov wrote: > > > Namely x11-libs/libX11 and dev-libs/glib: > > > > > > - libX11 failed during configure because it couldn't find xcb; > > > - glib failed during configure because it couldn't find libmount. > > > > > > Looks like it is an order issue, because after rebuilding > > > x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built > > > just > > > fine. > > > > > > Should I report bugs for these? The news item says: > > > > > > >If you have any problems with the new profiles or the migration > > > >procedure, please report a bug and make it block the tracker. > > > > > > But I'm a little reluctant to do so for various reasons. > > > > > I'm in the same situation. I've had several rebuild failures that > > succeeded after re-emerging one/some of what they depend on, although I > > would have expected those to also be rebuilt. > > > > I wonder if the instructions should be "emerge -1 --deep /lib32 > > /usr/lib32" ? I'll have to try it once I'm done with the current set > > of emerges. > > > > Anyway - it probably does make sense to file the bug - the worst they > > will do is close it as not a bug, and hopefully at least tell you what > > you should have done to avoid the problem. > > > > I think the emerge command as stated in the news item is incomplete > as emerge does not pick correct rebuild order (it assumes all packages > are installed and in order, thus picks arbitrary rebuild order). > > Try to add --complete-graph to it: > emerge -1 --deep --complete-graph /lib32 /usr/lib32 > > -- > > Sergei > Unfortunately this still doesn't guarantee the correct build order for me. I wonder if running emerge with --keep-going a few times would work in this situation? It might be a good idea to mention this issue somewhere on the wiki or in a follow-up news item. I doubt we're the last to face this problem now that 17.1 profiles are stable. I opened bug 687600 to improve the New item for this. For me, adding --deep to the emerge command fixed the build order. I would guess that adding --keep-going, and running multiple times would eventually get everything rebuilt also. Jack
Re: [gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
On Fri, 7 Jun 2019 13:24:07 +0300 Ilya Trukhanov wrote: > On Fri, Jun 07, 2019 at 08:03:30AM +0100, Sergei Trofimovich wrote: > > On Thu, 06 Jun 2019 18:49:48 -0400 > > Jack wrote: > > > > > On 2019.06.06 18:38, Ilya Trukhanov wrote: > > > > Namely x11-libs/libX11 and dev-libs/glib: > > > > > > > > - libX11 failed during configure because it couldn't find xcb; > > > > - glib failed during configure because it couldn't find libmount. > > > > > > > > Looks like it is an order issue, because after rebuilding > > > > x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built > > > > just > > > > fine. > > > > > > > > Should I report bugs for these? The news item says: > > > > > > > > >If you have any problems with the new profiles or the migration > > > > >procedure, please report a bug and make it block the tracker. > > > > > > > > But I'm a little reluctant to do so for various reasons. > > > > > > > I'm in the same situation. I've had several rebuild failures that > > > succeeded after re-emerging one/some of what they depend on, although I > > > would have expected those to also be rebuilt. > > > > > > I wonder if the instructions should be "emerge -1 --deep /lib32 > > > /usr/lib32" ? I'll have to try it once I'm done with the current set > > > of emerges. > > > > > > Anyway - it probably does make sense to file the bug - the worst they > > > will do is close it as not a bug, and hopefully at least tell you what > > > you should have done to avoid the problem. > > > > > > > I think the emerge command as stated in the news item is incomplete > > as emerge does not pick correct rebuild order (it assumes all packages > > are installed and in order, thus picks arbitrary rebuild order). > > > > Try to add --complete-graph to it: > > emerge -1 --deep --complete-graph /lib32 /usr/lib32 > > > > -- > > > > Sergei > > > > Unfortunately this still doesn't guarantee the correct build order for > me. I wonder if running emerge with --keep-going a few times would work in > this situation? > > It might be a good idea to mention this issue somewhere on the wiki or in a > follow-up news item. I doubt we're the last to face this problem now > that 17.1 profiles are stable. Yeah, if these options help you it's totally worth reporting a bug to update news item. -- Sergei
Re: [gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
On Fri, Jun 07, 2019 at 08:03:30AM +0100, Sergei Trofimovich wrote: > On Thu, 06 Jun 2019 18:49:48 -0400 > Jack wrote: > > > On 2019.06.06 18:38, Ilya Trukhanov wrote: > > > Namely x11-libs/libX11 and dev-libs/glib: > > > > > > - libX11 failed during configure because it couldn't find xcb; > > > - glib failed during configure because it couldn't find libmount. > > > > > > Looks like it is an order issue, because after rebuilding > > > x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built > > > just > > > fine. > > > > > > Should I report bugs for these? The news item says: > > > > > > >If you have any problems with the new profiles or the migration > > > >procedure, please report a bug and make it block the tracker. > > > > > > But I'm a little reluctant to do so for various reasons. > > > > > I'm in the same situation. I've had several rebuild failures that > > succeeded after re-emerging one/some of what they depend on, although I > > would have expected those to also be rebuilt. > > > > I wonder if the instructions should be "emerge -1 --deep /lib32 > > /usr/lib32" ? I'll have to try it once I'm done with the current set > > of emerges. > > > > Anyway - it probably does make sense to file the bug - the worst they > > will do is close it as not a bug, and hopefully at least tell you what > > you should have done to avoid the problem. > > > > I think the emerge command as stated in the news item is incomplete > as emerge does not pick correct rebuild order (it assumes all packages > are installed and in order, thus picks arbitrary rebuild order). > > Try to add --complete-graph to it: > emerge -1 --deep --complete-graph /lib32 /usr/lib32 > > -- > > Sergei > Unfortunately this still doesn't guarantee the correct build order for me. I wonder if running emerge with --keep-going a few times would work in this situation? It might be a good idea to mention this issue somewhere on the wiki or in a follow-up news item. I doubt we're the last to face this problem now that 17.1 profiles are stable. signature.asc Description: Digital signature
Re: [gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
On Thu, 06 Jun 2019 18:49:48 -0400 Jack wrote: > On 2019.06.06 18:38, Ilya Trukhanov wrote: > > Namely x11-libs/libX11 and dev-libs/glib: > > > > - libX11 failed during configure because it couldn't find xcb; > > - glib failed during configure because it couldn't find libmount. > > > > Looks like it is an order issue, because after rebuilding > > x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built > > just > > fine. > > > > Should I report bugs for these? The news item says: > > > > >If you have any problems with the new profiles or the migration > > >procedure, please report a bug and make it block the tracker. > > > > But I'm a little reluctant to do so for various reasons. > > > I'm in the same situation. I've had several rebuild failures that > succeeded after re-emerging one/some of what they depend on, although I > would have expected those to also be rebuilt. > > I wonder if the instructions should be "emerge -1 --deep /lib32 > /usr/lib32" ? I'll have to try it once I'm done with the current set > of emerges. > > Anyway - it probably does make sense to file the bug - the worst they > will do is close it as not a bug, and hopefully at least tell you what > you should have done to avoid the problem. > I think the emerge command as stated in the news item is incomplete as emerge does not pick correct rebuild order (it assumes all packages are installed and in order, thus picks arbitrary rebuild order). Try to add --complete-graph to it: emerge -1 --deep --complete-graph /lib32 /usr/lib32 -- Sergei
Re: [gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
On 2019.06.06 18:38, Ilya Trukhanov wrote: Namely x11-libs/libX11 and dev-libs/glib: - libX11 failed during configure because it couldn't find xcb; - glib failed during configure because it couldn't find libmount. Looks like it is an order issue, because after rebuilding x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built just fine. Should I report bugs for these? The news item says: >If you have any problems with the new profiles or the migration >procedure, please report a bug and make it block the tracker. But I'm a little reluctant to do so for various reasons. I'm in the same situation. I've had several rebuild failures that succeeded after re-emerging one/some of what they depend on, although I would have expected those to also be rebuilt. I wonder if the instructions should be "emerge -1 --deep /lib32 /usr/lib32" ? I'll have to try it once I'm done with the current set of emerges. Anyway - it probably does make sense to file the bug - the worst they will do is close it as not a bug, and hopefully at least tell you what you should have done to avoid the problem.
[gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
Namely x11-libs/libX11 and dev-libs/glib: - libX11 failed during configure because it couldn't find xcb; - glib failed during configure because it couldn't find libmount. Looks like it is an order issue, because after rebuilding x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built just fine. Should I report bugs for these? The news item says: >If you have any problems with the new profiles or the migration >procedure, please report a bug and make it block the tracker. But I'm a little reluctant to do so for various reasons. signature.asc Description: Digital signature
