Re: [gentoo-dev] Putting edac and ipmi (and other server-related) packages in a herd
On Mon, Apr 21, 2008 at 12:52:01PM +0400, Peter Volkov wrote: sys-apps/ipmitool sys-apps/ipmiutil sys-libs/freeipmi sys-libs/openipmi sys-apps/edac-utils and most of them are maintained by robbat2. So Robin, please, comment! :) Please don't CC me since I am actually on the list. If you paid attention to my previous pleas looking for maintainers, you'd see that _all_ o the IPMI stuff is up for grabs, because I don't personally have any access to IPMI hardware anymore. (iSCSI stuff is up too). Thusly, as I've said several times, if you have the hardware, take the bugs, and put yourself in the metadata. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpoPBj2v0RPF.pgp Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Mon, 21 Apr 2008 10:52:57 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
| cat/a-1 is installed and has RDEPEND cat/b
| cat/a-2 is to be installed and has DEPEND cat/b and RDEPEND =cat/b-2
| cat/b-1 is installed and has RDEPEND cat/a
| cat/b-2 is to be installed and has DEPEND cat/a and RDEPEND =cat/a-2
|
| Solve this and enlightenment shall be yours!
|
| Or a headache.
This problem has the two obvious solutions: either install a-2 and
then b-2 or the other way around.
Bzzt, wrong! Once you've installed a-2, you can't install b-2 since it
DEPENDs upon cat/a, but cat/a's run dependencies aren't satisfied, so
the dependency isn't met. And likewise for the other way around.
This problem is nowhere near as simple as you think it is.
But to be relevant to the current discussion you need to specify
whether or not there are any pkg_{pre,post}inst functions. If there
are too many then it becomes unsolvable and is probably a bug, as I
already explained:
The package manager can't sanely know whether such functions exist. (It
could, theoretically, insanely know, but forcing package managers to
be able to work that out really isn't something we want to do.)
| Labels are a cleaner solution to this. But again, we're discussing
| current EAPIs here.
Labels seems to be another syntax for providing the same information
as I proposed AIUI, i.e. finer-grained deps.
Labels do that and a lot more, and without the explosion in number of
metadata keys. But they're a different discussion.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Putting edac and ipmi (and other server-related) packages in a herd
В Вск, 20/04/2008 в 20:02 +0200, Tiziano Müller пишет: What do you think of putting edac and ipmi stuff (and maybe other server-related monitoring/controlling stuff) into the sysadmin herd? Alternative: Create a new herd (name?) for such tools. Actually this thread follows discussion in bug #199284. This move is a good idea, and taking into account that sysadmin herd includes only one developer and two packages seems that it's better not to create new herd. Current list of packages to be included in herd is sys-apps/ipmitool sys-apps/ipmiutil sys-libs/freeipmi sys-libs/openipmi sys-apps/edac-utils and most of them are maintained by robbat2. So Robin, please, comment! :) -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: 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. Usually I rather see the specific problem before looking for solutions. If packages intertwine in strange ways _maybe_ we could work with upstream to fix the insanity at the source instead host it ourselves. 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] Dependencies that're available at pkg_*inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| On Sun, 20 Apr 2008 22:17:27 -0700
| Donnie Berkholz [EMAIL PROTECTED] wrote:
| I don't think I understand the difference between the effects of
| these two options.
|
| cat/a-1 is installed and has RDEPEND cat/b
| cat/a-2 is to be installed and has DEPEND cat/b and RDEPEND =cat/b-2
| cat/b-1 is installed and has RDEPEND cat/a
| cat/b-2 is to be installed and has DEPEND cat/a and RDEPEND =cat/a-2
|
| Solve this and enlightenment shall be yours!
|
| Or a headache.
|
This problem has the two obvious solutions: either install a-2 and then b-2 or
the other
way around. But to be relevant to the current discussion you need to specify
whether or
not there are any pkg_{pre,post}inst functions. If there are too many then it
becomes
unsolvable and is probably a bug, as I already explained:
| 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.
Labels seems to be another syntax for providing the same information as I
proposed AIUI,
i.e. finer-grained deps.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgMVekACgkQp/VmCx0OL2waMgCglvtOPnu1xBIpUn0EbG7jDNsf
xLQAoLfQR4s8hAvzhgfx5JuY4sj9gp7+
=Creb
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: 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... Which are the packages involved in such cycle? 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] Dependencies that're available at pkg_*inst
On Mon, 21 Apr 2008 12:10:53 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: 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. Usually I rather see the specific problem before looking for solutions. The specific problem is that ebuilds currently rely upon the package manager providing circular dependency resolution that works, so we need a good definition of just what's allowed to resolve cycles. But we can't take what Portage does as that definition, because Portage's behaviour is usually get it right by fluke, except when things go horribly wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Dependencies that're available at pkg_*inst
Donnie Berkholz [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 20 Apr 2008 22:17:27 -0700: I guess the RDEPEND+DEPEND case would save an ebuild dev the work of specifying the COMMON_DEPEND list, but other than that, I can't think of any benefits. It would force both RDEPEND and DEPEND to be installed for binpkgs, which sucks. If I read the original proposal correctly, it's not proposing a simple +, that BOTH RDEPEND and DEPEND be guaranteed installed at pkg_*inst, IOW by set theory, not the UNION of the two sets, but the INTERSECTION of the two sets, that is, packages that appear in both lists at once, not those appearing in one XOR the other. Thus a COMMON_DEPEND would still be useful as it would be the list appearing in both (thus effectively the list necessary for pkg_*inst, same as the OR case). Both lists could still exclusively include packages, and packages not listed in DEPEND only would not have to be installed for binpkgs. So it's not OR vs AND, but OR vs INTERSECTION. As I stated in my other post, RDEPEND alone can't be used without breaking things. That applies to binary package installation as well, where DEPEND along can't be used either as that would require installation of unwanted packages. Thus, the OR case doesn't seem to work for binary installation at all, since neither RDEPEND nor DEPEND can be relied upon alone, and the OR case proposes requiring at least one complete set of the two be installed. Thus, for current EAPIs, the INTERSECTION alternative is the only possibly working alternative if we are not to break binary package support and not force full DEPEND installation on binary targets. It's not ideal as it'll potentially force unwanted and otherwise unnecessary package installation on both the build-host and the binary target, due to fact that it forces pkg_*inst dependencies into both DEPEND and RDEPEND, but IMO it's better than forcing the whole set of DEPENDs to be installed on binary targets, which would be the only working alternative in the OR case above. As others have said, this is certainly a good candidate for future EAPI change, but it's not future EAPIs under current discussion, so that fact doesn't help the current discussion. -- 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] Dependencies that're available at pkg_*inst
2008-04-21 12:05 Luca Barbato [EMAIL PROTECTED] napisał(a): Ciaran McCreesh wrote: 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... Which are the packages involved in such cycle? Maybe app-admin/gamin and =dev-libs/glib-2.16[fam].
[gentoo-dev] Re: Re: Re: New global USE flag: keyring
Jeroen Roovers wrote: On Sun, 20 Apr 2008 18:06:07 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: I'd say we should convert it to a global use flag now with a good description and change it to gnome-keyring later in case we really have a package which needs 'keyring' for something else. Needless to say it would save quite a few users from needlessly rebuilding a few packages. That's green thinking. :) Sorry to get technical but how difficult is it really to change USE flag names? I appreciate that users are out of sync yadda yadda, but could this kind of thing not be considered out of band data similar to news? I accept that portage has to maintain compatibility but aiui the old way of doing this was simply depending on a version of portage that had the capability. Since we're only talking about ~10 packages, is that so much of a hardship? After all, I'm sure the other manglers don't lag behind emerge, based on the hyperbole. Do they? -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Reminder: re-run autotools if you change Makefile.am/configure.ac!
Please remember to re-run autotools if you change Makefile.am and/or configure.ac (or configure.in if the package uses the old name, or configure.in.in for KDE-based packages). Especially with autoconf 2.62 release this becomes important as some package might try to re-run autotools on its own and find different versions, dying of an horrible death. Also, remember that unless the package you're using is _not_ using automake (and thus aclocal), you should not run eautoconf, but eautoreconf instead. In general if you're unsure, just run eautoreconf. Exception can be made if you only touch Makefile.am, eautomake knows to run eautoreconf if the versions of the tools has changed, but again if you're unsure, just run eautoreconf. Yeah of course it makes waste time to the users to re-run autotools entirely, but it's better making every user waste those 30 seconds rather than having users complain that $foo doesn't build at the next autoconf bump. Or right now considering the amount of packages that fails with autoconf 2.62. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpCG22ilYd0X.pgp Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 2008-04-19 at 06:33 +0100, Ciaran McCreesh wrote: 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. I would agree that RDEPEND should likely be installed prior to pkg_preinst to satisfy the dependency. After all, PDEPEND is good enough for doing packages that aren't required at pkg_preinst/pkg_postinst. We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. I'd love to have some kind of functionality to allow some kind of optional dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Simple example: ODEPEND=video_cards_nvidia? ( x11-drivers/nvidia-drivers) would install x11-drivers/nvidia-drivers the first time it's ran with VIDEO_CARDS=nvidia, but if I removed x11-drivers/nvidia-drivers, it wouldn't get reinstalled. This would probably need some kind of --newuse like capability to allow for installing only *new* optional dependencies, but I think that the tracking would already allow that. The idea here would be to allow for installing recommended software along with others. We could even have --ask ask for the dependencies, since they are optional, after all. This way, we could ship a more robust configuration/setup for many popular applications without forcing software on people. It's an idea, anyway, and I hope that I didn't hijack the thread. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: Re: New global USE flag: keyring
On Mon, 21 Apr 2008 15:02:29 +0100 Steve Long [EMAIL PROTECTED] wrote: Sorry to get technical but how difficult is it really to change USE flag names? I appreciate that users are out of sync yadda yadda, but could this kind of thing not be considered out of band data similar to news? I accept that portage has to maintain compatibility but aiui the old way of doing this was simply depending on a version of portage that had the capability. Since we're only talking about ~10 packages, is that so much of a hardship? After all, I'm sure the other manglers don't lag behind emerge, based on the hyperbole. Do they? I'm deeply sorry. I read all of that three times and while it seemed to make sense the first time, by the third time I saw the error of my ways. Kind regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: escaping variables in sed expressions
Ciaran McCreesh wrote: Nor do most Unix apps, since they tend to be written in C using all those C library functions that work on null terminated strings. Null introduces far more problems than it solves, character-wise... ..but it's fine as a terminator, if you know what you're doing. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New global USE flag: keyring
On Sun, 2008-04-20 at 19:11 +0100, Peter Weller wrote: On Sun, 2008-04-20 at 19:36 +0200, Gilles Dartiguelongue wrote: Le dimanche 20 avril 2008 à 20:25 +0300, Alon Bar-Lev a écrit : On 4/20/08, Gilles Dartiguelongue [EMAIL PROTECTED] wrote: for what it's worth, as a gnome dev I didn't see any convincing arguments as to why it should be renamed. Gnome makes things optional for other to reuse (like xfce) but afaik no other keyring like programs are optional deps of another package in portage. Let's not cast a simple change into breakage for users already using it (even in stable, and yes I'm lazy :D). Lazy is the word. I cannot argue with this one, I just know that it won't be the gnome herd who do the work when the time come to fix this (resolve conflict). The gnome herd will re-introduce the lazy ticket, and make other herd use yet another confusing USE flag. This is not the right way to maintain long term constants. failure, you tried to argue ;) You asked for objections... You got some. You can leave this local USE flag, and stay with generic term. Or you can rename it when it goes global so it have proper name. You can also ignore this and force gnome onto all users. Seriously though, when I find stuff to fix, I try to fix it. I just don't see anything to fix right now. There are currently three options in my mind: to rename the USE flag as 'gnome-keyring', to just globalize the 'keyring' USE flag as is, or to remove the USE flag completely. Each have a number of downs and ups: Renaming 1) We have to change 9 ebuilds to reflect the change 2) Almost all Gnome users will be affected in one way or another 3) Technically correct 4) Reduces chances of future collisions 5) More work for developers Keeping it as is 1) Less headache for Gnome users in the short term (but possibly more if we rename it in the future 2) Less work for me/Gnome herd 3) Technically incorrect 4) Could result in conflicts in the future Removing 1) Nice and simple. Just force all packages to compile with --gnome-keyring 2) A large number of users will probably start complaining about all their packages being compiled with gnome-keyring support 3) Xfce people will hate hate hate, I will be crucified. After consideration of the above, and consultation with the Gnome herd, I think that the best option would be to rename the USE flag to gnome-keyring. If anyone has any objections to *that*, pipe up before tomorrow evening. All done. If anyone spots any missed packages/problems, feel free to fix or poke me to fix it. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] lastrite: net-fs/coda-kernel (treecleaners)
# Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked by treecleaners for bug 160267. Removed in ~60 days. # Has been included in 2.6 kernel series. net-fs/coda-kernel -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] lastrite: sys-apps/systrace (security/treecleaners)
# Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked for removal in 30 days. Doesn't build # wrt bug 178036 and has open CVE-2007-4773 wrt # security bug 203195. sys-apps/systrace -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last Rites: sys-fs/python-fuse
+# Markus Ullmann [EMAIL PROTECTED] (21 Apr 2008) +# Masked for removal in 30 days. +# unmaintained, broken and not used anywhere +# use dev-python/fuse-python instead +sys-fs/python-fuse -Jokey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] lastrite: sys-apps/systrace (security/treecleaners)
On Mon, Apr 21, 2008 at 9:01 PM, Samuli Suominen [EMAIL PROTECTED] wrote: # Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked for removal in 30 days. Doesn't build # wrt bug 178036 and has open CVE-2007-4773 wrt # security bug 203195. sys-apps/systrace -- gentoo-dev@lists.gentoo.org mailing list http://www.citi.umich.edu/u/provos/systrace/systrace-1.6e.tar.gz 1.6e solves the security problem. Just in case someone wants to fix it. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] lastrite: sys-apps/systrace (security/treecleaners)
On Monday 21 April 2008, Santiago M. Mola wrote: On Mon, Apr 21, 2008 at 9:01 PM, Samuli Suominen [EMAIL PROTECTED] wrote: # Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked for removal in 30 days. Doesn't build # wrt bug 178036 and has open CVE-2007-4773 wrt # security bug 203195. sys-apps/systrace -- gentoo-dev@lists.gentoo.org mailing list http://www.citi.umich.edu/u/provos/systrace/systrace-1.6e.tar.gz 1.6e solves the security problem. Just in case someone wants to fix it. I remember I tried bumping to 1.6e to fix the security bug, however it also does not compile and I had no intention to look into why. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
On Thursday 10 April 2008, Mike Frysinger wrote: gcc-4.3 seems to be standing up well. since the major gcc-ebuild-specific issues seem to be resolved now, i'll probably do a sweep of bugs to see if there's any patches i'm missing (if you guys know of a bug that should be addressed specifically in the gcc-4.3.0 ebuild, speak up now). then move on to the gcc 4.3 tracker bug (#198121). once this gets below a certain critical mass (i wont know what the critical mass is until it's been de-attained), then we'll be ~arching things. people are recommended to do a quick sweep of the lower hangers (many bugs have simple patches). i'll drop in ~ppc ~amd64 ~x86 as i use those every day. if any other arch is happy now with things, add your ~arch to the commented out list in cvs so i know to include it. the x86 cld revert is in now as well as some more upstream pr fixes. i'll probably let things settle for this week and pending any craziness, move gcc-4.3.0-r1 into ~arch in a week. i'll prob commit some obvious gcc-4.3 bugs at the same time. last chance to speak up peeps. -mike signature.asc Description: This is a digitally signed message part.
