[gentoo-dev] Re: Linux 2.6.25 info
Luca Barbato wrote: > Daniel Drake wrote: >> 2.6.25 was released today, gentoo-sources-2.6.25 is now in portage. >> >> As usual this will break some packages in the portage tree (ones that >> include kernel code), the tracker for such issues is here: >> http://bugs.gentoo.org/show_bug.cgi?id=218127 >> >> Jakub normally does a wonderful job of herding all such bugs, but it >> looks like he isn't around at the moment. Please help out by adding your >> bugs there, assuming that your package is in the stable tree and the >> current stable one works on 2.6.24. >> >> As usual I hope to start thinking about 2.6.25 stabling in 3 weeks time >> (that'll be May 8th) but this is of course subject to the state of >> affairs when we get that far :) >> >> Daniel > > People using ati-drivers (and possibly other external drivers) as usual > do not upgrade if you aren't ready to help fixing the drivers. ^^ People using nvidia-drivers can upgrade and safely ignore those warnings: [ 94.858320] NVRM: bad caching on address 0x810070da7000: actual 0x173 != expected 0x17b [ 94.858523] NVRM: please see the README section on Cache Aliasing for more information [ 94.860898] NVRM: bad caching on address 0x810071ecf000: actual 0x173 != expected 0x17b [...] And in case you're on a laptop you might experience another Suspend2RAM-is-working/-is-broken switch (at least on my machine it's broken again). For the VirtualBox modules you find a link to updated drivers in bugzilla. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| I'm rewording the PMS sections on dependencies to avoid permitting
| overly lax circular dependency resolution. Which of these wordings is
| accurate, given that usable means "has its RDEPENDs installed and
| usable"?
|
| 1. During pkg_preinst and pkg_postinst, any package dependency that is
| in both DEPEND and RDEPEND must be installed and usable.
|
| 2. During pkg_preinst and pkg_postinst, at least one of the following
| conditions must be met:
| a. every package dependency in DEPEND must be installed and usable
| b. every package dependency in RDEPEND must be installed and usable
|
| Do not attempt to write on both sides of the paper at once.
Every package dependency in DEPEND is installed and usable before src_unpack
starts,
right? So is the question here whether or not they can be uninstalled right
before
pkg_{pre,post}inst starts?
I don't know what the general use of pkg_preinst is, but in pkg_postinst the
package
itself should be runnable, so its RDEPENDS should be installed and usable at
this point.
So perhaps we should define that "usable" means "each of its RDEPENDs is
installed and has
had its pkg_postinst function run". The recursion of that definition then comes
from the
requirement that RDEPENDs should be usable before pkg_postinst starts running.
| For why this matters:
|
| cat/a-1: RDEPEND cat/b
| cat/b-1: RDEPEND cat/a
|
| This is solvable. If package managers can't solve this, they can't
| install Gnome off a stage 3...
If only one of those packages has a pkg_postinst then it is still solvable.
If they both have a pkg_postinst then one of those is probably not essential
for the
actual usability of the package and should be removed. A final possibility is
that the
pkg_postinsts are both necessary for a fully functional package but not for the
functionality used in the other pkg_postinst. If this is the case, then perhaps
we should
specify deps according to which ebuild phase they are necessary for?
cat/a:
SRC_UNPACK_DEP="app-arch/unzip"
SRC_COMPILE_DEP="dev-scheme/bigloo"
SRC_INSTALL_DEP=""
PKG_PREINST_DEP=""
PKG_POSTINST_DEP="cat/b"
RDEPEND="cat/b"
and then cat/b would say:
PKG_PREINST_DEP=""
PKG_POSTINST_DEP=""
RDEPEND="cat/a"
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
[gentoo-dev] Removing .la files...
Hello! I think flameeyes should have sent this himself in the first place, but since he's clearly not going to do that and prefers to just force it on our users I'm mailing this... flameeyes talked about .la files in his blog recently: http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files Now he decided that simply removing them for several packages, resulting in http://bugs.gentoo.org/show_bug.cgi?id=218286 and its dupes. This is annoying for quite a few users as they will have to rebuild lots of stuff for KDE, Gnome and other packages and I'm not sure if this is really the way we want to fix --as-needed failures. Furthermore, such things should not be decided and pushed through unilaterally but be agreed upon here prior to doing this change. Especially since even though removing .la files might make sense (with exceptions, of course) we should think about either doing it distribution-wide or not at all. -- Best regards, Wulf signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Dependencies that're available at pkg_*inst
Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 19 Apr 2008 06:33:00 +0100: > On Fri, 18 Apr 2008 22:27:21 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: >> My interpretation is pkg_* counts as runtime (I can imagine a package >> wanting to run itself at this point), so packages in RDEPEND should be >> usable at that point. > > Which would be fine, except it makes the tree unusable. > >> Really, it seems to be an additional type of dependency that neither >> DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't >> quite capturing it either. > > Yup, and for future EAPIs labels can fix this. But we have to have a > sound solution for current EAPIs. It seems to me that at least for current EAPIs, RDEPEND simply cannot be depended upon during pkg_*inst without breaking things. I can't see a way around that. About the least-bad of multiple bad solutions I can see for Donnie's conceivable run scenario would be to print a message in pkg_postinst telling the user to run emerge --config before running the program normally, maybe even going to the point of renaming the runtime and installing a fake that reminds folks to run emerge --config first, if it's critical enough. (pkg_config would then kill the fake and rename the runtime back to its proper name.) Now consider binary packages. DEPEND can't be used as-is, which in the OR case would then mandate RDEPEND and again result in broken behavior due to circular dependencies, so that simply doesn't work. That leaves the intersection of both DEPEND and RDEPEND sets as the only possible logically consistent resolution... UNLESS we either (1) accept that binary package behavior simply can't be correctly defined under current EAPIs and declare it an indeterminate legacy exception, or (2) declare binary packages an exception that works by different rules, and then define them (somehow). Either alternative would then leave somewhat more flexibility for the ordinary build case, presumably enough to reasonably accurately describe current behavior deterministically. (I'll freely admit to not knowing enough about current tree behavior to pick the right option there.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing .la files...
Wulf C. Krueger wrote: Hello! I think flameeyes should have sent this himself in the first place, but since he's clearly not going to do that and prefers to just force it on our users I'm mailing this... Have we not learn't! I hardly think that revdep-rebuild is an obvious solution to this issue. So now we have doomed our users ( and some of our dev's ) to having to search for a solution. I note that within the ebuild there isn't even a elog explaining what to do. If we are going to make changes like this we need to provide an effective "news service". I'm sure this was one of the issues that arose during the "hot house months". I actually find this incident rather depressing. especially after we (seem to) have done so well with the baselayout/openrc migration. ( I do realise that one is significantly bigger than the other and therefore requires a bigger "fan fair" ). flameeyes talked about .la files in his blog recently: http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files Im sure everyone will find that Now he decided that simply removing them for several packages, resulting in http://bugs.gentoo.org/show_bug.cgi?id=218286 and its dupes. What a surprise. never could have guessed. This is annoying for quite a few users as they will have to rebuild lots of stuff for KDE, Gnome and other packages and I'm not sure if this is really the way we want to fix --as-needed failures. ++. We sure do like to annoy our users. Furthermore, such things should not be decided and pushed through unilaterally but be agreed upon here prior to doing this change. ++. I actually have no problem with agreeing with it, currently my problem is the complete and utter lack of any _planned_ upgrade path. What do we think users are going to be saying at the end of the year when after every sync they have to revdep-rebuild. Maybe, if we proceed with this, we investigate what can have its la files removed and do it all in one go. therefore ppl won't have to rebuild kde/gnome ( or any other large and time consuming package) over and over and over and over and over and over ... again. Hell it would even be better to "batch" a few conversions so that each revdep-rebuild fixes multiple breakages in one. Especially since even though removing .la files might make sense (with exceptions, of course) we should think about either doing it distribution-wide or not at all. ++ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing .la files...
Wulf C. Krueger wrote: Hello! I think flameeyes should have sent this himself in the first place, but since he's clearly not going to do that and prefers to just force it on our users I'm mailing this... flameeyes talked about .la files in his blog recently: http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files Now he decided that simply removing them for several packages, resulting in http://bugs.gentoo.org/show_bug.cgi?id=218286 and its dupes. This is annoying for quite a few users as they will have to rebuild lots of stuff for KDE, Gnome and other packages and I'm not sure if this is really the way we want to fix --as-needed failures. That or just remove the other .la. Furthermore, such things should not be decided and pushed through unilaterally but be agreed upon here prior to doing this change. Agreed, even if it is relatively low profile IMHO. Especially since even though removing .la files might make sense (with exceptions, of course) we should think about either doing it distribution-wide or not at all. I'll put as item for the council meeting if we don't reach consensus before. In the other news I advise to start asking library upstreams to provide pkgconfig files (and/or push patches providing that). lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing .la files...
Alistair Bush wrote: ++. I actually have no problem with agreeing with it, currently my problem is the complete and utter lack of any _planned_ upgrade path. What do we think users are going to be saying at the end of the year when after every sync they have to revdep-rebuild. Maybe, if we proceed with this, we investigate what can have its la files removed and do it all in one go. therefore ppl won't have to rebuild kde/gnome ( or any other large and time consuming package) over and over and over and over and over and over ... again. Hell it would even be better to "batch" a few conversions so that each revdep-rebuild fixes multiple breakages in one. Call that an experiment, do not start screaming but just try to help a bit. I think we could have those change masked now and unmasked once we got something sorted better. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing .la files...
Luca Barbato kirjoitti: Alistair Bush wrote: ++. I actually have no problem with agreeing with it, currently my problem is the complete and utter lack of any _planned_ upgrade path. What do we think users are going to be saying at the end of the year when after every sync they have to revdep-rebuild. Maybe, if we proceed with this, we investigate what can have its la files removed and do it all in one go. therefore ppl won't have to rebuild kde/gnome ( or any other large and time consuming package) over and over and over and over and over and over ... again. Hell it would even be better to "batch" a few conversions so that each revdep-rebuild fixes multiple breakages in one. Call that an experiment, do not start screaming but just try to help a bit. I think we could have those change masked now and unmasked once we got something sorted better. lu And remember folks that if you don't want to deal with regular breaks, you should not be using ~arch. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Removing .la files...
As those who _did_ ask me directly why I decided to do this did not think it was worth mailing - as they didn't - I suppose I should chime in now. Leaving alone what Petteri already said, this was intended to be a change on a series of single packages, the domino effect that happened I didn't foresee, on my system it was just a matter of five packages and a quick look at the revdeps didn't show _such_ an effect. Well maybe I expected a few problems with libogg, but yeah that doesn't seem to be the problem here, the problem seems to be with popt. For what popt is used (parsing of command-line options) I didn't expect it to creep in in so many libraries. And as the problem does not break any system - systems will still run perfectly - and can be solved with ease - just run a revdep-rebuild - I did consider this a pretty minor drawback on the whole. libogg and popt are now masked, and they'll wait a bit before return to ~arch that way. libmpcdec, libmad have very few library users so I don't expect major problems with those and I left them untouched. Same for libpam which should really _not_ be used by libraries beside a few very rare cases, if it was there is something _very_ broken. Probably the best thing would be to get a better tool than revdep-rebuild to handle broken .la files, as revdep-rebuild forces a timewasting rebuild, while a good fix could be just a sed -i -e 's:/usr/lib\(64\)\?/lib\(.*\).la:-l\2:' on all the .la files, installed and being-installed. By the way, asking a question is not poisonous. "Wulf C. Krueger" <[EMAIL PROTECTED]> writes: > Especially since even though removing .la files might make sense (with > exceptions, of course) we should think about either doing it > distribution-wide or not at all. Can't be done distribution-wide, as stuff would break way worse than this for sure (stuff is not going to link, or will fail at runtime). You _have_ to do it on a case-by-case basis. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpA75CPKwsyT.pgp Description: PGP signature
Re: [gentoo-dev] Re: Removing .la files...
Diego 'Flameeyes' Pettenò kirjoitti: Probably the best thing would be to get a better tool than revdep-rebuild to handle broken .la files, as revdep-rebuild forces a timewasting rebuild, while a good fix could be just a sed -i -e 's:/usr/lib\(64\)\?/lib\(.*\).la:-l\2:' on all the .la files, installed and being-installed. You would have to fix the vdb too. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Removing .la files...
Petteri Räty <[EMAIL PROTECTED]> writes: > You would have to fix the vdb too. Which is the tricky part, and the reason why I didn't instruct anybody to do the sed on my ChangeLogs.p -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Removing .la files...
> By the way, asking a question is not poisonous. Absolutely. Asking about it here was my suggestion. -- Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Removing .la files...
On Saturday 19 April 2008, Wulf C. Krueger wrote: > > By the way, asking a question is not poisonous. > > Absolutely. Asking about it here was my suggestion. his point was you should have asked him directly instead of starting a thread on a mailing list to talk about him. doesnt seem terribly unreasonable. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Removing .la files...
On Saturday 19 April 2008, Wulf C. Krueger wrote: > Furthermore, such things should not be decided and pushed through > unilaterally but be agreed upon here prior to doing this change. > > Especially since even though removing .la files might make sense (with > exceptions, of course) we should think about either doing it > distribution-wide or not at all. except that this wont work. the only workable solution is for libraries to opt-in after having been reviewed to make sure they truly are not needed. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Dependencies that're available at pkg_*inst
On Sat, 19 Apr 2008 18:53:27 + (UTC) Duncan <[EMAIL PROTECTED]> wrote: > It seems to me that at least for current EAPIs, RDEPEND simply cannot > be depended upon during pkg_*inst without breaking things. I can't > see a way around that. But DEPEND can't either. The point is, one of the two wordings in the original email is enough. In fact, both are, but they have different implications, and selecting the right one is important. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 19 Apr 2008 18:38:06 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> Every package dependency in DEPEND is installed and usable before
> src_unpack starts, right? So is the question here whether or not they
> can be uninstalled right before pkg_{pre,post}inst starts?
If we're using binaries, DEPEND is usually ignored.
> I don't know what the general use of pkg_preinst is, but in
> pkg_postinst the package itself should be runnable, so its RDEPENDS
> should be installed and usable at this point. So perhaps we should
> define that "usable" means "each of its RDEPENDs is installed and has
> had its pkg_postinst function run". The recursion of that definition
> then comes from the requirement that RDEPENDs should be usable before
> pkg_postinst starts running.
No good. That prevents RDEPEND <-> RDEPEND cycles from being solved,
and the package manager has to be able to solve that.
> If only one of those packages has a pkg_postinst then it is still
> solvable. If they both have a pkg_postinst then one of those is
> probably not essential for the actual usability of the package and
> should be removed. A final possibility is that the pkg_postinsts are
> both necessary for a fully functional package but not for the
> functionality used in the other pkg_postinst. If this is the case,
> then perhaps we should specify deps according to which ebuild phase
> they are necessary for?
Not with current EAPIs we can't.
> SRC_UNPACK_DEP="app-arch/unzip"
> SRC_COMPILE_DEP="dev-scheme/bigloo"
> SRC_INSTALL_DEP=""
Labels are a cleaner solution to this. But again, we're discussing
current EAPIs here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Removing .la files...
On Saturday 19 April 2008, Diego 'Flameeyes' Pettenò wrote: > libogg and popt are now masked, and they'll wait a bit before return to > ~arch that way. please dont leave it like this. revbump both packages in question minus the .la removal portion. libtool script scuttling is independent of version. -mike signature.asc Description: This is a digitally signed message part.
