Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/05/2012 10:31 PM, Ciaran McCreesh wrote: > On Tue, 05 Jun 2012 16:07:40 -0700 > Zac Medico wrote: >> The "SLOT operator" dependencies that Ciaran has been advocating are >> very close to a good solution. However, if we want it to work with >> unslotted packages, then we need to introduce a separate ABI_SLOT >> variable as discussed here: >> >> https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 >> >> It's really no more difficult to do than "SLOT operator" dependencies, >> it's more flexible, and we can do it in EAPI 5. > > I still don't get what problem you're trying to solve with that. Well, I guess it's easy enough to use blockers to handle cases where two SLOTs can't be installed simultaneously. > SLOT > operator dependencies are known to work for the problem, and have > received extensive testing both on Gentoo (with the old KDE packages) > and elsewhere. Why not just go with those plus blockers initially, and > then add in ABI_SLOT only if it turns out that developers really can't > handle using SLOT correctly? Sounds good, especially considering the possibility of using blockers as mentioned. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Tue, 05 Jun 2012 15:31:01 +0200 Pacho Ramos wrote: > We all know what would be the "ideal solution", the problem is how to > implement it (and how many years we need to wait to get it working). We do? Please tell us. I was under the impression that we still didn't fully know what the problem was. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Tue, 05 Jun 2012 16:07:40 -0700 Zac Medico wrote: > The "SLOT operator" dependencies that Ciaran has been advocating are > very close to a good solution. However, if we want it to work with > unslotted packages, then we need to introduce a separate ABI_SLOT > variable as discussed here: > > https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 > > It's really no more difficult to do than "SLOT operator" dependencies, > it's more flexible, and we can do it in EAPI 5. I still don't get what problem you're trying to solve with that. SLOT operator dependencies are known to work for the problem, and have received extensive testing both on Gentoo (with the old KDE packages) and elsewhere. Why not just go with those plus blockers initially, and then add in ABI_SLOT only if it turns out that developers really can't handle using SLOT correctly? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] x32 release candidate
On Tuesday 05 June 2012 14:44:13 Mike Frysinger wrote: > i'm pleased to announce the initial x32 release candidate: > http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz to be kind to infra, i've put this on the mirrors: http://distfiles.gentoo.org/experimental/amd64/x32/ this URL will continue to work as i setup an apache redirect, but please use the new one anyways -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
On 06/05/2012 05:51 PM, Michael Weber wrote: > Is there any chance to detect this ZLIB_VERSION problem with > revdep-rebuild (worst case: add a list of possibly broken packages > with tests)? I'd suggest a special ebuild phase to check for ABI changes, like the pre_pkg_preinst_abi_check phase suggested here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 -- Thanks, Zac
Re: [gentoo-dev] x32 release candidate
compiler wise, you do not need to specify -mx32 yourself. the toolchain defaults to the x32 ABI (and all programs in there are compiled as x32). you only need -mx32 if you want to do something like distcc and execute with toolchains that aren't targeting x32 by default. as for what are valid flags, pretty much everything that works with your amd64 target will work with x32. very little is different between them. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/05/2012 02:44 PM, Aaron W. Swenson wrote: > "There's never anything important in all that text." - Anonymous > Gentoo User The bad part is, that even reading of these messages can result in a breakage. I update a bunch of machines with these steps (maybe we should place instructions like these on a prominent place). (this is multi user, multi session). #preparations eix-sync cd /etc/portage git pull ; [ git stash ; git pull ; git stash pop ; git commit -a ; git push ] #on kernel updates emerge -av1 --nodeps gentoo-sources cd /usr/src/linux ; zcat /proc/config.gz > .config make oldconfig time ( make -j8 && make install_modules && make install && module-rebuild -X rebuild && eclean-kernel -n 2 -x config && grub2-config -o /boot/grub2/grub2.cfg ) #regular packages emerge -avuND world dispatch-conf/etc-update emerge -a --depclean revdep-rebuild --ignore -- -av revdep-rebuild --ignore -- -av (second run) #on xorg-server updates emerge -av1 $(qlist -IC x11-drivers) Nice, isn't it? [1] if you forget the -X on module-rebuild, you might no longer have the virtualbox-modules version installed in the tree (no packages satisfy ...). virtualbox does remove old versions real quick. The fun part comes with non-root users trying to log in: [2] You've updated nvidia-drivers (kernel module providers in general) userland and kernel modules, but forget to `rmmod nvidia`, or you can't without terminating user sessions, it impossible to start new X servers due to version mismatch between userland and kernel (applies for virtualbox as well) [3] You've updated zlib, but failed to recognize it in the emerge -av output. You get angry reports about broken luatex and inkscape (imagemagik) because of some nasty zlib abi version mismatch, hidden from revdep-rebuild. [5] lafilefixer (funny) [4] python-updater (rare) [6] ocaml gets broken after update w/o lablgl rebuild https://bugs.gentoo.org/385869 Well, I'm lazy, and do this in the backgound, half asleep. And I admit that [1] and [2] are my faults, but [3] is very annoying (just like libdl related stuff) and esp. kernel+module updates take a lot more than just a few 'REBUILD' packages. Is there any chance to detect this ZLIB_VERSION problem with revdep-rebuild (worst case: add a list of possibly broken packages with tests)? = I understand the urge for `eupdate` but that needs an agreement on the implementation, and I see some rought edges here, where unattended script magic most likely fails. Michael -- half asleep - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF0EAREIAAYFAk/OqZ4ACgkQknrdDGLu8JCZTgD2MXNld64l2D9jdko5sDQ1RedO hDDGT1frS210sIkG5AD+M0N08Ru0FrVmqarkxec6N71egAmrmRUmcMMhtWCcUK0= =0Xwl -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/05/2012 06:31 AM, Pacho Ramos wrote: > El mar, 05-06-2012 a las 08:44 -0400, Aaron W. Swenson escribió: >> The ideal solution is for the Ebuild to instruct the PMS to rebuild >> the dependent packages. >> >> We can have a variable called REBUILD. All packages that would need to >> be rebuilt can be listed in it. Only those packages that are installed >> would be built. The actual list of the packages to be rebuilt would be >> determined at dependency checking time. That way, the user can approve >> the rebuild of the packages. > > We all know what would be the "ideal solution", the problem is how to > implement it (and how many years we need to wait to get it working). This REBUILD variable is the first idea that pops into the head of anyone who's never worked on a dependency resolver before. It's backwards because it requires a package to have knowledge of *all* of its reverse dependencies, and it should not need to know about *any* of them. The "SLOT operator" dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than "SLOT operator" dependencies, it's more flexible, and we can do it in EAPI 5. -- Thanks, Zac
Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)
On Tue, Jun 05, 2012 at 09:04:33AM +0200, Micha?? G??rny wrote: > On Mon, 4 Jun 2012 15:57:53 -0700 > Brian Harring wrote: > > > Btw, good catch on package.mask. Hhadn't thought of that, that > > *will* be the most contentious point. That can be dealt w/ via > > having git on portage-1 profile format so we'd have package.mask as > > directories (which Ciaran will validly hate, and I won't like > > due to having to write the portage-1 -> PMS translater for > > rsync distribution), or coming up w/ a different way to split the > > commits across multiple files, rather than a single. > > That doesn't like a 'lesser evil' to me. I'd rather see those few > conflicts and fix them once in a while rather than having to lookup > multiple package.mask files with entries split in a semi-random manner. The rate of package.mask commits was calculated yesterday- it's around 4.5 a day. Non issue, move along... ~harring
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 05 Jun 2012 08:44:08 -0400 "Aaron W. Swenson" wrote: > "There's never anything important in all that text." - Anonymous > Gentoo User To be fair, most einfo and elog messages are useless spam. When elog was introduced, it was supposed to be only for *important* messages, but nearly everything sent to it now is a waste of users' time. Perhaps the solution is to implement an ethisisimportanthonestlog function, and require developers to get approval before using it, as per news items. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/Oa+MACgkQ96zL6DUtXhHDhwCgpf1C/k//ecx21gcsCiCy6MK1 GRwAoNhvMaJSFxAbTdOGcqMcYhI5JuXN =SNPn -END PGP SIGNATURE-
[gentoo-dev] x32 release candidate
i'm pleased to announce the initial x32 release candidate: http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz the x32 ABI is the default one, and includes x86/amd64 ABIs. it is not using /lib32/ (and /lib is not a symlink) like our existing amd64 multilib as that is being phased out, and the x32 port allows me to do a clean break. i call this a release candidate as it is using glibc-2.15 with backported patches. the ABI however should be the same as glibc-2.16, so hopefully the upgrade will go smooth. but i don't want to make an official release on the chance that things aren't smooth, so this is a release candidate. once glibc-2.16 is released upstream, we should have x32 stages released alongside the existing x86/amd64 stages. caveats: - you have to be running linux-3.4+ with the x32 ABI enabled in your config - the x32 profile has marked toolchain packages stable ahead of other arches: - linux-headers-3.4 - binutils-2.22 - glibc-2.15 (and will have stable glibc-2.16) - gcc-4.7.0 - strace-4.7 - gdb-7.4.1 - gdb will probably be flaky, but the new gdb-7.5 release should address that so if you try running stable amd64, you will hit some failures unrelated to x32, but related to the newer toolchain packages. this will get better over time as other packages go stable, and i'll be trying to push at least binutils/linux-headers stable soonish. for the adventurous souls, please review the existing x32 tracker bug: https://bugs.gentoo.org/show_bug.cgi?id=x32 and file new bugs for packages you come across that aren't yet known more reading: https://sites.google.com/site/x32abi/ -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing
On Tue, Jun 5, 2012 at 2:50 AM, Michał Górny wrote: > On Mon, 4 Jun 2012 16:57:42 -0400 > Rich Freeman wrote: > >> If you go back and look at the tree you see a bunch of signed and >> unsigned commits. How do you easily detect how the unsigned ones got >> there (via a dev with a merge commit, or via other means)? > > Well, that's not a very good solution but the server-side hooks could > also verify the tree state before applying new commits. The obvious problem with this is that it makes the git server a single point of failure - if it is compromised the hooks will not help. Hooks should nevertheless be there to eliminate mistakes. Note that in no way are any of these git flaws any worse than the status quo. I just want to avoid any false sense of security. I think these are flaws that are worth fixing, and I think that was why many have labored to get the signing enabled in git in the first place. My suggestion is to keep working on this, but it shouldn't be considered a blocker for adoption, since these are not new security flaws, and if anything despite its holes git is an improvement. Rich
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mar, 05-06-2012 a las 08:44 -0400, Aaron W. Swenson escribió: [...] > "There's never anything important in all that text." - Anonymous > Gentoo User > > We've already determined that the users don't read the output. This is > a known fact. Something I repeat in #gentoo more often than I care to > admit is "Seriously, read the output." I agree with the users that > there's too much output, and some of the output is indeed useless. > > The output they aren't reading isn't just rebuild commands, but also > the next step they're supposed to take after the emerge has finished, > groups their users need to be in to use a particular feature, et cetera. > > The ideal solution is for the Ebuild to instruct the PMS to rebuild > the dependent packages. > > We can have a variable called REBUILD. All packages that would need to > be rebuilt can be listed in it. Only those packages that are installed > would be built. The actual list of the packages to be rebuilt would be > determined at dependency checking time. That way, the user can approve > the rebuild of the packages. We all know what would be the "ideal solution", the problem is how to implement it (and how many years we need to wait to get it working). > > Just placing the commands in a separate log won't really solve a whole > lot. Further, it will bump any elog messages even further down in the > importance ranking. > It will allow administrators to easily automate via scripts rebuilding of packages, allowing them to get system more solid after a big update. Also, currently I usually need to surf in big summary.log to directly find commands to rebuild things because most of elog messages are useless to me (a lot of them because they are always shown in every update and are useful only the first time you read them, other times you already remember, for example, how to setup e4rat). Current situation of breaking systems when people don't read summary.log JUST AFTER update completes won't help to force people to read them, will simply break their systems and give a really poor impression of Gentoo breaking easily when updating. Think, for example, on a lot of people that leaves system updating at night time, then, when he/she tries to use it next morning he sees some things are broken and need to be rebuilt. All that rebuilding work could be done during the same night but, due current way of handling things, he needs to have his system broken during more hours (when he needs to use it) until things are rebuilt. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/2012 05:26 PM, Pacho Ramos wrote: > Hello, will send this to gentoo-dev mailing list per Zac's > suggestion ;): > > ...They usually do a good job maintaining them, the only issue I > see they hit from time to time is forgetting to run JUST AFTER > updating their systems revdep-rebuild (well, this is so common that > they usually don't forget to), rebuild > dbus-glib/gobject-introspection after major glib update, rebuild > X11 drivers... > > This is because, even if all this information is recorded in > /var/log/portage/elog/summary.log, currently, that log file is > cluttered of a lot of other elog lines that are not related at all > with this important task of rebuilding packages. This is why I > suggested: https://bugs.gentoo.org/show_bug.cgi?id=413619 > > That would create a new "erebuild" (or whatever the name you > prefer) to ONLY contain exact command to run by admin to have a > safe system after update. It would have as main advantage: - Looks > easier to implement. - It relies in current and existing tools > (python-updater, perl-cleaner, "q", equery...), then, they could be > used just now via a script running all of them. - It also looks > much more "professional" to try to unify a bit what commands to run > ;) (currently, some ebuilds tells you to manually re-emerge > packages and some people wrongly run "emerge dbus-glib" when they > should run "emerge -1 dbus-glib". Telling us to people what exact > command they need to copy&paste&run will help to get their systems > cleaner also. > > ... > > The problem of that one is that, even if it would be "the perfect > solution": - Looks to be stalled for a long time. - Looks to need a > lot of functions (like revdep-rebuild, python-updater...) to be > merged in portage itself. It will then probably take a lot of time > to get them integrated (specially seeing we are still not able to > use preserve-libs because it looks to cause some other problems) - > In that bug report I have also seen discussion about whether > handle this only via SLOTs (that personally think it will be even > harder to achieve for all packages in the tree showing this kind of > problems when updating, for example, I doubt how "glib" - > "dbus-glib/g-i" case could be handled in this way. - Looks like > there is no consensus about what to do and, then, this could > probably be implemented on eapi... 7? While former could probably > be implemented much sooner (probably even in eapi5) > > This is why I think we should try to push a bit my first suggestion > for the short term until "the perfect one" is ready as, until then, > we are having for years a problem that, personally, I think it > should be handled a bit better. > > Thanks a lot for your attention > "There's never anything important in all that text." - Anonymous Gentoo User We've already determined that the users don't read the output. This is a known fact. Something I repeat in #gentoo more often than I care to admit is "Seriously, read the output." I agree with the users that there's too much output, and some of the output is indeed useless. The output they aren't reading isn't just rebuild commands, but also the next step they're supposed to take after the emerge has finished, groups their users need to be in to use a particular feature, et cetera. The ideal solution is for the Ebuild to instruct the PMS to rebuild the dependent packages. We can have a variable called REBUILD. All packages that would need to be rebuilt can be listed in it. Only those packages that are installed would be built. The actual list of the packages to be rebuilt would be determined at dependency checking time. That way, the user can approve the rebuild of the packages. Just placing the commands in a separate log won't really solve a whole lot. Further, it will bump any elog messages even further down in the importance ranking. - -- Mr. Aaron W. Swenson Gentoo Linux Developer Email: titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/N/xgACgkQVxOqA9G7/aBGGwD/TNRbZNie6J1RkI0DETgcUlwG VXBY2UamMijjKLFPluEA/jwo9B7qejNkiko/xDvecUq8CaF02Qc4tKMf/MbWs7LW =ysgF -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > But could there be a case where fixing a build in the engine > wouldn't require data being rereleased? Or having the tag pointing > to the same commit it was pointing to previously? > > If upstream splits a package, and supports building/installing the > two parts separately, we should do that as well. No. That is convenience for the minetest developer to have those split. There is not much sense to have it split unless you don't want to use the game and it adds further maintenance time for me. It is also crucial to have the same version for both repos, cause mixing engine and game-versions may lead to unexpected behavior. But I don't understand how that discussion is related to this topic. > > Does splitting the package benefit user? Gentoo has a long history > of overusing USE flags out of laziness. If upstream explicitly > allows building GTK+ part separately of core, we shouldn't merge > that. We should rather be grateful they don't force us to end up > like Fedora, splitting build tree into smaller packages. Please have a look at those packages. It makes perfectly sense to introduce a gtk useflag since they use almost the same perl core-script, but it is not necessary. This way I could conditionally install one version, since upstream syncs this core-script between both variants. > > As I see the purpose of vcs-snapshot, it is more likely to be used > in various overlays than in the gx86 tree. I don't believe you are > able to fix *all* the occurrences. Alright, that may be true. I will have a look if it's possible to enhance this without causing breakage for existing packages. We may as well have this discussion later. As for your current suggestion you have my ++ However the description stuff inside the eclass might need adjustment too. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPzfrbAAoJEFpvPKfnPDWzgAQH/1PdtK2RVRy8M43hW/s2v+wh hRT3FZdEyFYmjMcOyNbzWlu0Y4DnFfbJIYbVWKrr892NQB4o+o4kaEpHmB0wX/gI Igu1ojGkntpfH9NFFXvZDTSwcCLV6ZAtnfq/CAfl5Y100Xdnz64D3nhvse/kXUFH 6KYwUX7llsGGKFT3BU/w8i+PXecHDKNrqY48H3XnzTYxk92D6jMkXcSk6PXqVYJQ C1Ug5mjWSBd4ZIPl3CIxxkVXQMFYOgRmM38/vztMNaAt7ypXVJL1sdmR4VHr7k2S WnBtw+eKwTuYJb/M/vHfANhudIOtNOfvCQPZA9nmU5qKpgJ2/iyZAYnhN/WfAd4= =965z -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
On Mon, 04 Jun 2012 22:47:33 +0200 hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/04/2012 10:06 PM, Michał Górny wrote: > > On Mon, 04 Jun 2012 21:26:00 +0200 hasufell > > wrote: > > > >> But minetest in sunrise for example which has two different > >> repos, one for the engine, one for the data. It's currently split > >> in two, but I guess I will merge those soon. > > > > Why? Is there a good reason to merge two repos into one ebuild? > > Does upstream guarantee that the releases will always be synced? > > Does it benefit users? > > In this case yes. They are released with the exact same tags as you > can see in those ebuilds. But could there be a case where fixing a build in the engine wouldn't require data being rereleased? Or having the tag pointing to the same commit it was pointing to previously? If upstream splits a package, and supports building/installing the two parts separately, we should do that as well. > >> It would also enable me to use gtk-youtube-viewer and > >> youtube-viewer in one ebuild with vcs-snapshot eclass while > >> adding a gtk useflag (currently split too). Otherwise I will have > >> to fix it on my own again. > > > > Once again: does it benefit user? Or just does it imply that > > starting or stopping to use gtk part requires user to rebuild the > > whole thing? > > Eclasses do not benefit any user. They benefit developers. I would > simply do similar stuff on my own in the ebuild instead of using > vcs-snapshot eclass then. Does splitting the package benefit user? Gentoo has a long history of overusing USE flags out of laziness. If upstream explicitly allows building GTK+ part separately of core, we shouldn't merge that. We should rather be grateful they don't force us to end up like Fedora, splitting build tree into smaller packages. > > I really don't mind the logic. I'm just aware that it is a little > > late to introduce such a destructive change, especially that you > > yourself mentioned that it will break existing ebuilds. > > So? We fix it. As I see the purpose of vcs-snapshot, it is more likely to be used in various overlays than in the gx86 tree. I don't believe you are able to fix *all* the occurrences. And while we're at it, changing eclass APIs doesn't benefit users nor developers. It can cause breakages which will hurt users, and forces developers to do more work when they don't have time to. > > I will be happy to implement it if you can get more approval for > > that change. Or else we should consider jumping with the eclass to > > -r1 while it isn't widespread too much. > > I don't see the point in bumping it, because it's not widespread. There are still more packages that it breaks than those which it would actually benefit. But I like the idea of using filename for the location. Could you look up PMS for me to see if it's guaranteed that it will be preserved in $A? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)
On Mon, 4 Jun 2012 15:57:53 -0700 Brian Harring wrote: > Btw, good catch on package.mask. Hhadn't thought of that, that > *will* be the most contentious point. That can be dealt w/ via > having git on portage-1 profile format so we'd have package.mask as > directories (which Ciaran will validly hate, and I won't like > due to having to write the portage-1 -> PMS translater for > rsync distribution), or coming up w/ a different way to split the > commits across multiple files, rather than a single. That doesn't like a 'lesser evil' to me. I'd rather see those few conflicts and fix them once in a while rather than having to lookup multiple package.mask files with entries split in a semi-random manner. -- Best regards, Michał Górny signature.asc Description: PGP signature
