Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sun, 24 Feb 2013 05:22:43 +0100 hasufell hasuf...@gentoo.org wrote: Before people start asking I should explain why I started this: https://bugs.gentoo.org/show_bug.cgi?id=458638 I think having such an eclass has several advantages over autootools-multilib.eclass (which depends on autotools-utils.eclass) as it is now: a) Less eclass dependencies. One could argue: the more eclasses my ebuild uses the more prone to error and exposed to changes it is. b) easier conversion in some cases: often times a simple rename src_compile - multilib_src_compile will do c) it allows more custom definition of phase functions d) the previous point will also allow to convert go-mono.eclass packages without introducing yet another eclass for that Then don't put 'autotools' in the name. e) autotools-utils.eclass does a bit more than just calling default phase functions; the developer has little choice on this matter unless he wants to rewrite his ebuild based on multilib-build.eclass which will create a lot of code duplication in ebuilds, hence this proposition Yes, everyone sees 'a bit more' but nobody so far was able to point what it is exactly. Or people simply don't know what PMS does nowadays. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On 24/02/2013 11:06, Michał Górny wrote: Then don't put 'autotools' in the name. +1 Yes, everyone sees 'a bit more' but nobody so far was able to point what it is exactly. Or people simply don't know what PMS does nowadays. I've been trying to get myself to use autotools-utils more often lately, especially since I think at this point, with multilib support easier to wire in it than others, it would be the right way to proceed with (it's going to be a ruddy mess with orthogonal ABIs such as Ruby's but I don't want to go there right now). The only thing that would upset me in all of this is something that is unfortunately needed for multilib builds to not be completely idiotic, and that is the out-of-source builds. I had to fix one package for that already (lksctp-tools). On the other hand I usually fixed that stuff anyway because I use out-of-source builds when I'm developing them so... Btw, I know I've been more than rough on Michał before, so I guess I'd better say this out loud: I really like his roadmap toward multilib support. Kudos! -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-util/ciabot-svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (24 Feb 2013) # Not functional as cia.vc is gone # No maintainer, dead upstream, last bump in 2005 # See #445644. Removal in 30 days dev-util/ciabot-svn - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQJ8BAEBCgBmBQJRKftvXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88HBoP/jk5v8g29b6Aoaaoz7/uNHvT TYDVXwvZHVuV4/KLek7F2ZamLaOiwWj1ANuiXHFIa+db4ECHe1/qwhIqPaPPDurn C1rAzQ1BYo92mJejOa34SnT0gRPrE9n7p/0pKbEQGZtHgl9mz3L0lUUn2ylSkvbt e4Xf6Y0gd1qPM3xcztIo+CZrB1oUj+uqXnorop11dAKlxba13EK+Q7i3bR4T8Sph 7x8Hcl625Y3g/uZ2A6FUoCpRbATOj6UGbhVbxlGwATcYtoOi1xGYDqU3uq+wWkuh VdyWsQlQXtHuyq4QBh5ywsq5X/Lu2YpaMfi+Skg7tBmYFUiIlfHW4+hxABdI/yXF PVoVJAJvVahcdtCP3wSGo0ad6uXP1tL3y8S4KrjqcPW/vwd2A2Y2Wsd6Ghr1nPfB Ff5btsl1DuLMofPZanz63uqx92ZuwDNhYMNgr3dxXK9qqrXzKtSgIAGG7ALKRu04 ztUuxPxdh8/4YIapHiC+iELnS8DA8KXUUBIHDHy2m87sUxSei0cl+qPamItE1Osz baBiMXbEnLD1xzvODbLCY8PTbCCOkvsZOModO6SxGTxtCvWKBr4p4CoDqsHNT1YM zfmTNfyWp1JR4I67YgWG8qDkBZIQXrf5i7LUdJVySRJYpVGh3RZYec0GbivLQNhb +5BPvWfA2sFCIrKTLh2r =HEWU -END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote: On 24/02/2013 11:06, Michał Górny wrote: Then don't put 'autotools' in the name. +1 That would be multilib-minimal.eclass then? I find that name silly, but I don't have a better idea. ABCD also suggested something else: autotools-multilib.eclass - autotools-utils-multilib.eclass autotools-multilib-minimal.eclass - autotools-multilib.eclass that is more logical imo, but would maybe cause unnecessary hassle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRKiEPAAoJEFpvPKfnPDWzF+UIAJ13DlLh6dIfY9zvbd9v3z48 7jiW9z/aeiEWYxy9KxM5zLRfosnNPGNbUiTjiozVq1gLFA4anJiEDO86iSaQIYJa Uv5CoSNF7MZXFMEmNk0GoJqLQmzrhFyxYF27rqc+yt0B+unOcBlZ34DsUTJXTzQF CxZY7QKiLonN35zPK72uJxaAW12i+/0YDlgU/Sji7cO57JXW23nA7Gue7pBY6ACm rQi/aTzj2TEe+mWPoWFLgwPfk3EYeLPVev9ouVJMW6CHJRlf1gX6giVpMFnQQNfm TgfCYvQaVYgh+oaKzmz5Kg9xu0NdhdA5GQI8SEcf658sNYXj3/dco0oVJIF3DgI= =BHkt -END PGP SIGNATURE-
[gentoo-dev] About adding systemd to profiles/default/linux/x86/13.0/use.stable.mask
I would like to ask about adding systemd USE flag to use.stable.mask to let us stop needing to revbump packages with optional systemd support when stabilizing them. Are you ok with that? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
El dom, 24-02-2013 a las 15:17 +0100, hasufell escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote: On 24/02/2013 11:06, Michał Górny wrote: Then don't put 'autotools' in the name. +1 That would be multilib-minimal.eclass then? I find that name silly, but I don't have a better idea. Probably multilib-build-minimal.eclass :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding systemd to profiles/default/linux/x86/13.0/use.stable.mask
On Sun, Feb 24, 2013 at 9:23 AM, Pacho Ramos pa...@gentoo.org wrote: I would like to ask about adding systemd USE flag to use.stable.mask to let us stop needing to revbump packages with optional systemd support when stabilizing them. Are you ok with that? Am I interpreting the impacts of this correctly? I believe this would mean that if you ran systemd on an otherwise-stable system (that is, only systemd and possibly udev are in package.keywords) then you won't get systemd support in any of your other packages, even if it is available in a stable version of that package? My only VM running systemd just happens to be in that configuration, but I'm willing to admit that I'm a bit of an edge case. :) Why exactly do we need to revbump packages with optional systemd support when stabilizing them in the first place? ~arch users would already have systemd support compiled if they use it, and stable users would get it when it is stabilized. I freely admit that there might be some nuance that I'm simply not getting here... Rich
Re: [gentoo-dev] About adding systemd to profiles/default/linux/x86/13.0/use.stable.mask
El dom, 24-02-2013 a las 09:35 -0500, Rich Freeman escribió: On Sun, Feb 24, 2013 at 9:23 AM, Pacho Ramos pa...@gentoo.org wrote: I would like to ask about adding systemd USE flag to use.stable.mask to let us stop needing to revbump packages with optional systemd support when stabilizing them. Are you ok with that? Am I interpreting the impacts of this correctly? I believe this would mean that if you ran systemd on an otherwise-stable system (that is, only systemd and possibly udev are in package.keywords) then you won't get systemd support in any of your other packages, even if it is available in a stable version of that package? My only VM running systemd just happens to be in that configuration, but I'm willing to admit that I'm a bit of an edge case. :) Why exactly do we need to revbump packages with optional systemd support when stabilizing them in the first place? ~arch users would already have systemd support compiled if they use it, and stable users would get it when it is stabilized. I freely admit that there might be some nuance that I'm simply not getting here... Rich We need to revbump it because we cannot mark as stable a package that would pull a testing package when enabling a USE flag. Isn't there any way to unmask systemd USE flag on your local setup (running testing systemd)? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sun, 24 Feb 2013 05:22:43 +0100 hasufell hasuf...@gentoo.org wrote: Before people start asking I should explain why I started this: https://bugs.gentoo.org/show_bug.cgi?id=458638 I think having such an eclass has several advantages over autootools-multilib.eclass (which depends on autotools-utils.eclass) as it is now: You wanted the other points, so here you go. a) Less eclass dependencies. One could argue: the more eclasses my ebuild uses the more prone to error and exposed to changes it is. That's as good as bundling libraries. Really. b) easier conversion in some cases: often times a simple rename src_compile - multilib_src_compile will do Easy != good. The eclass switch is a good point to fix bugs which should have been fixed long ago. By making it unnecessary, you just keep those bugs live and hidden. c) it allows more custom definition of phase functions More custom than what? d) the previous point will also allow to convert go-mono.eclass packages without introducing yet another eclass for that So you're introducing a hacky eclass just because you're too lazy to convert go-mono packages properly and too impatient to let others do the work properly for you? e) autotools-utils.eclass does a bit more than just calling default phase functions; the developer has little choice on this matter unless he wants to rewrite his ebuild based on multilib-build.eclass which will create a lot of code duplication in ebuilds, hence this proposition And as I already told you, this argument just proves that you don't know the eclass in question and just throwing random accusations. I don't have a problem with the present eclasses, but I find this a logical enhancement. If that's logical, then please provide a graph showing where it logically fits. Because so far, it's either hate-built redundant eclass or quick draft eclass written for a single package. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About adding systemd to profiles/default/linux/x86/13.0/use.stable.mask
On Sun, 24 Feb 2013 15:23:52 +0100 Pacho Ramos pa...@gentoo.org wrote: I would like to ask about adding systemd USE flag to use.stable.mask to let us stop needing to revbump packages with optional systemd support when stabilizing them. Are you ok with that? Ok, committed that myself ;). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About adding systemd to profiles/default/linux/x86/13.0/use.stable.mask
On Sun, 24 Feb 2013 09:35:27 -0500 Rich Freeman ri...@gentoo.org wrote: On Sun, Feb 24, 2013 at 9:23 AM, Pacho Ramos pa...@gentoo.org wrote: I would like to ask about adding systemd USE flag to use.stable.mask to let us stop needing to revbump packages with optional systemd support when stabilizing them. Are you ok with that? Am I interpreting the impacts of this correctly? I believe this would mean that if you ran systemd on an otherwise-stable system (that is, only systemd and possibly udev are in package.keywords) then you won't get systemd support in any of your other packages, even if it is available in a stable version of that package? My only VM running systemd just happens to be in that configuration, but I'm willing to admit that I'm a bit of an edge case. :) Why exactly do we need to revbump packages with optional systemd support when stabilizing them in the first place? ~arch users would already have systemd support compiled if they use it, and stable users would get it when it is stabilized. I freely admit that there might be some nuance that I'm simply not getting here... You have to stable-unmask it in your /etc/portage/profile: use.stable.mask: -systemd -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2013 03:57 PM, Michał Górny wrote: On Sun, 24 Feb 2013 05:22:43 +0100 hasufell hasuf...@gentoo.org wrote: Before people start asking I should explain why I started this: https://bugs.gentoo.org/show_bug.cgi?id=458638 I think having such an eclass has several advantages over autootools-multilib.eclass (which depends on autotools-utils.eclass) as it is now: You wanted the other points, so here you go. a) Less eclass dependencies. One could argue: the more eclasses my ebuild uses the more prone to error and exposed to changes it is. That's as good as bundling libraries. Really. That analogy is flawed. It's about ebuild design and the fact that I don't just convert my ebuild to _multilib_, but also to _autotools-utils_, so I have to keep an eye on another provider. b) easier conversion in some cases: often times a simple rename src_compile - multilib_src_compile will do Easy != good. The eclass switch is a good point to fix bugs which should have been fixed long ago. By making it unnecessary, you just keep those bugs live and hidden. c) it allows more custom definition of phase functions More custom than what? Than autotools-multilib.eclass. d) the previous point will also allow to convert go-mono.eclass packages without introducing yet another eclass for that So you're introducing a hacky eclass just because you're too lazy to convert go-mono packages properly and too impatient to let others do the work properly for you? Please point out where the eclass is hacky. I haven't heard a technical argument against it despite that you think autotools-multilib.eclass is better. That might be true, but then I don't understand why people refuse to use it which is the only reason I am proposing this. Also, I am not too lazy to convert go-mono packages. I have already written the go-mono-multilib.eclass and it looks almost the same as autotools-multilib-minimal.eclass, so I am wondering why I want code-duplication in eclasses. e) autotools-utils.eclass does a bit more than just calling default phase functions; the developer has little choice on this matter unless he wants to rewrite his ebuild based on multilib-build.eclass which will create a lot of code duplication in ebuilds, hence this proposition And as I already told you, this argument just proves that you don't know the eclass in question and just throwing random accusations. No, I was just rephrasing other peoples concerns. I don't have a problem with the present eclasses, but I find this a logical enhancement. If that's logical, then please provide a graph showing where it logically fits. Because so far, it's either hate-built redundant eclass or quick draft eclass written for a single package. I don't understand you. It works on more than one package. Anyway... as I said, I don't care how this problem is solved. I only care about the availability of 32bit libs -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRKi3GAAoJEFpvPKfnPDWzkW4H/3uaQ++8Rky1GKi+Tvffz45i x+yNpPtje/gWFKjXVeWxQZfNV/tLsq1TZM0ruzixB6lO1vFD6Ql+8ZiuTrHHRvuV at3+iT2AycSTeNs0qRUHjICOn5V6fMNQyIxJsrFS+HNEEbYfE36+S91YvN9WwHr6 Q2PDBp+3jueJXNVeZh+zdSQL4eo2fEuJ39/pa42SPbeRGGm6aw1SnhD9RYBcRZuf GyuTOk7R+vwp55i4d7xXyb8eEDVh7uSqikb7OniNA15a7wrmpSLsfwonhZS/a3Qq R/pQDXGm+aDDk7ZwXGCWRvGd7ARLqED5A+5yKcfyQeZ99RP6KHW8+xEwkr8M54I= =3uKD -END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió: [...] d) the previous point will also allow to convert go-mono.eclass packages without introducing yet another eclass for that So you're introducing a hacky eclass just because you're too lazy to convert go-mono packages properly and too impatient to let others do the work properly for you? Would be nice to know what autotools-utils.eclass is doing differently that is showing this problem with go-mono.eclass packages :/ Only one question, what is the reason for us having base.eclass and autotools-utils.eclass? I still try to use plain ebuilds without inheritting autotools-utils.eclass as I usually don't need it, probably others do the same and refuse to have to inherit it only for multilib support :/ How do you plan to solve this problem? I would also like to hear why that people refuses to use autotools-utils.eclass... because I don't have a strong opinion on this topic signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding systemd to profiles/default/linux/x86/13.0/use.stable.mask
On Sun, Feb 24, 2013 at 9:43 AM, Pacho Ramos pa...@gentoo.org wrote: Isn't there any way to unmask systemd USE flag on your local setup (running testing systemd)? Wasn't aware that could be done. That makes sense all-around - it even allows you to run the stable packages with the unstable flag (which would be a real pain if we always revbumped them and removed the flag). Rich
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sun, 24 Feb 2013 16:12:18 +0100
Pacho Ramos pa...@gentoo.org wrote:
El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
[...]
d) the previous point will also allow to convert go-mono.eclass packages
without introducing yet another eclass for that
So you're introducing a hacky eclass just because you're too lazy to
convert go-mono packages properly and too impatient to let others do
the work properly for you?
Would be nice to know what autotools-utils.eclass is doing differently
that is showing this problem with go-mono.eclass packages :/
I already told that I'm going to look at this but I have too much work
to do right now so it's going to take a longer while.
Only one question, what is the reason for us having base.eclass and
autotools-utils.eclass?
I think that base.eclass is silently intended for removal at some point
in the future. While we're here, we should probably mark it deprecated.
autotools-utils does a bit more -- especially by using out-of-source
builds. The major reason to use autotools-utils so far was to support
those builds.
Believe me or not, the day I took over the maintenance of it I seen
the opportunity to use out-of-source builds for multilib. Today, both
python-r1 multilib-build were specifically designed to allow using
out-of-source builds with minimal effort.
I still try to use plain ebuilds without
inheritting autotools-utils.eclass as I usually don't need it, probably
others do the same and refuse to have to inherit it only for multilib
support :/ How do you plan to solve this problem?
You generally have two options on doing multilib builds: either using
out-of-source builds or in-source builds. If you decide on the latter,
you unnecessarily waste users' time and disk space to create two more
copies of sources. I don't think we should go this way.
If you decide on out-of-source builds, you basically need proper
src_{configure,compile,test,install} and that's what autotools-utils
does. Plus:
- prune_libtool_files in src_install() which most people want to do
anyway, so that doesn't hurt -- and the pkg-config dep is going to
be removed, by the patch I sent already.
- patch applying and autoreconf in src_prepare() -- which are
completely optional, you are free to write your own src_prepare().
If you wanted to apply patches by hand, you'd need to write
src_prepare() anyway.
- adding libtool args for shared/static libs if IUSE=static-libs --
which I wanted to remove but people considered it useful.
I would also like to hear why that people refuses to use
autotools-utils.eclass... because I don't have a strong opinion on this
topic
Well, the major argument was similar to yours -- why we should use
an eclass if default PMS functions work. But in the multilib case, they
do not work by design anymore.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
El dom, 24-02-2013 a las 16:53 +0100, Michał Górny escribió:
On Sun, 24 Feb 2013 16:12:18 +0100
Pacho Ramos pa...@gentoo.org wrote:
El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
[...]
d) the previous point will also allow to convert go-mono.eclass packages
without introducing yet another eclass for that
So you're introducing a hacky eclass just because you're too lazy to
convert go-mono packages properly and too impatient to let others do
the work properly for you?
Would be nice to know what autotools-utils.eclass is doing differently
that is showing this problem with go-mono.eclass packages :/
I already told that I'm going to look at this but I have too much work
to do right now so it's going to take a longer while.
In that case, sorry, I probably missed it for some reason :S
Only one question, what is the reason for us having base.eclass and
autotools-utils.eclass?
I think that base.eclass is silently intended for removal at some point
in the future. While we're here, we should probably mark it deprecated.
I agree, I though it was marked as deprecated time ago, but last time I
read it it appeared to be still active
[...]
You generally have two options on doing multilib builds: either using
out-of-source builds or in-source builds. If you decide on the latter,
you unnecessarily waste users' time and disk space to create two more
copies of sources. I don't think we should go this way.
If you decide on out-of-source builds, you basically need proper
src_{configure,compile,test,install} and that's what autotools-utils
does. Plus:
- prune_libtool_files in src_install() which most people want to do
anyway, so that doesn't hurt -- and the pkg-config dep is going to
be removed, by the patch I sent already.
- patch applying and autoreconf in src_prepare() -- which are
completely optional, you are free to write your own src_prepare().
If you wanted to apply patches by hand, you'd need to write
src_prepare() anyway.
- adding libtool args for shared/static libs if IUSE=static-libs --
which I wanted to remove but people considered it useful.
I would also like to hear why that people refuses to use
autotools-utils.eclass... because I don't have a strong opinion on this
topic
Well, the major argument was similar to yours -- why we should use
an eclass if default PMS functions work. But in the multilib case, they
do not work by design anymore.
OK, thanks for the info
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sun, 24 Feb 2013 01:34:47 +0100 hasufell hasuf...@gentoo.org wrote: Some people seem to feel uncomfortable with autotools-multilib, because it depends on autotools-utils. To be honest, I don't particularly like autotools-utils, I tend to consider it a useless bloat. However, Michal's work on autotools-multilib is IMHO the right thing to do: If you use the autotools-utils syntax then it's trivial to support multilib without useless duplication of code. I still believe such an eclass as the one you propose is useful, except it's not for autotools (at best temporary for broken autotools based build systems): For example, I have no clue how to do multilib with waf-based build systems without going the 'copy $S and run the usual src_* phases in each directory for each ABI', which is what your eclass is abstracting I think. A.
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sun, 24 Feb 2013 16:53:02 +0100
Michał Górny mgo...@gentoo.org wrote:
- prune_libtool_files in src_install() which most people want to do
anyway, so that doesn't hurt -- and the pkg-config dep is going to
be removed, by the patch I sent already.
A bit OT but that's one of the things I consider useless there, I
usually do 'find ${D} -name '*.la' -delete' which is more than
enough in most cases, faster and avoids calling a 90+ lines function
which may break or add a pkg-config dep.
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On 02/24/2013 05:22 PM, Alexis Ballier wrote:
On Sun, 24 Feb 2013 01:34:47 +0100
hasufell hasuf...@gentoo.org wrote:
Some people seem to feel uncomfortable with autotools-multilib,
because it depends on autotools-utils.
To be honest, I don't particularly like autotools-utils, I tend to
consider it a useless bloat. However, Michal's work on
autotools-multilib is IMHO the right thing to do: If you use the
autotools-utils syntax then it's trivial to support multilib without
useless duplication of code.
I still believe such an eclass as the one you propose is useful, except
it's not for autotools (at best temporary for broken autotools based
build systems): For example, I have no clue how to do multilib with
waf-based build systems without going the 'copy $S and run the usual
src_* phases in each directory for each ABI', which is what your eclass
is abstracting I think.
A.
I have no idea if it makes sense for this package (since it also
installs binaries), but as an example I have converted dev-libs/serd.
And yes, a rename of the eclass would probably be appropriate.
--- dev-libs/serd/serd-0.18.2.ebuild
+++ dev-libs/serd/serd-0.18.2-r1.ebuild
@@ -2,9 +2,9 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-libs/serd/serd-0.18.2.ebuild,v 1.1
2013/01/13 21:08:17 aballier Exp $
-EAPI=4
-
-inherit waf-utils
+EAPI=5
+AUTOTOOLS_IN_SOURCE_BUILD=1
+inherit waf-utils autotools-multilib-minimal
DESCRIPTION=Library for RDF syntax which supports reading and writing Turtle
and NTriples
HOMEPAGE=http://drobilla.net/software/serd/;
@@ -23,9 +23,10 @@
src_prepare() {
sed -i -e 's/^.*run_ldconfig/#\0/' wscript || die
+ prepabisources
}
-src_configure() {
+multilib_src_configure() {
waf-utils_src_configure \
--docdir=/usr/share/doc/${PF} \
$(use test echo --test) \
@@ -33,6 +34,14 @@
$(use static-libs echo --static)
}
-src_test() {
+multilib_src_test() {
./waf test || die
}
+
+multilib_src_compile() {
+ waf-utils_src_compile
+}
+
+multilib_src_install() {
+ waf-utils_src_install
+}
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On 24/02/13 17:53, Michał Górny wrote:
I still try to use plain ebuilds without
inheritting autotools-utils.eclass as I usually don't need it, probably
others do the same and refuse to have to inherit it only for multilib
support :/ How do you plan to solve this problem?
You generally have two options on doing multilib builds: either using
out-of-source builds or in-source builds. If you decide on the latter,
you unnecessarily waste users' time and disk space to create two more
copies of sources. I don't think we should go this way.
If you decide on out-of-source builds, you basically need proper
src_{configure,compile,test,install} and that's what autotools-utils
does. Plus:
- patch applying and autoreconf in src_prepare() -- which are
completely optional, you are free to write your own src_prepare().
If you wanted to apply patches by hand, you'd need to write
src_prepare() anyway.
It's that Plus part that is my problem with autotools-multilib.eclass
currently, it adds EXPORT_FUNCTIONS of src_prepare() from
autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass
adds just another eclass/phase function to worry about for inherit order
- prune_libtool_files in src_install() which most people want to do
anyway, so that doesn't hurt -- and the pkg-config dep is going to
be removed, by the patch I sent already.
but lacks a way to pass arguments to prune_libtool_files, like --all,
since prune_libtool_files isn't that smart it gets it right everytime
i propably prefer to stick to manually calling it with or without --all
and well, this is not related to the multilib conversion so it shouldn't
be executed anyway
- adding libtool args for shared/static libs if IUSE=static-libs --
which I wanted to remove but people considered it useful.
if it's not related to the multilib conversion, it shouldn't be executed...
I would also like to hear why that people refuses to use
autotools-utils.eclass... because I don't have a strong opinion on this
topic
Well, the major argument was similar to yours -- why we should use
an eclass if default PMS functions work. But in the multilib case, they
do not work by design anymore.
src_prepare() seems to be adequate from PMS for the multilib conversion
[gentoo-dev] Re: New eclass: autotools-multilib-minimal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/24/2013 10:53 AM, Michał Górny wrote: I think that base.eclass is silently intended for removal at some point in the future. While we're here, we should probably mark it deprecated. The problem with deprecating base.eclass and telling people to use autotools-utils.eclass instead is that base.eclass also defines a src_prepare that is used for eclasses that support *non*-autotools build systems, such as cmake-utils.eclass. Requiring that support to be copied around to each of the eclasses that currently inherits base would allow the usual issues with copying code around. - -- Jonathan Callen (abcd) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRKlZ+AAoJELHSF2kinlg4L0UP/24ETiIoXIVS9it65p2s/YER D/KCcgsbTMowWTrs488mQ8Vs/3T0Ij2sDuYRcOqqKEiDb6+aAeILhU3pDP9c8k7V L8jV1RpF2nafO4dexXU9FBMd6KYvz3Vsf4JQfiHzybdBsVW9HE0vrU/lrST91tm8 irDxPfOWFMPGM3r8YD+AuQ6DlkgaMdnJnT+c9Bu5xtoGrjZ5inmSCeskQkX9zP54 wFFuwyg3+Db08r+qTHkUqnAPc1t3fSsz7X4tgQfX5btBjVgDKKYm2dsScjNmhvxg 4Wnv+A5R4QAcce3CWUOp/BXTAg6PuYBbGWZWm+5WzQstsZRRo+hiGh7buyIctdix IRQaoNh7SRMiiV2STHJtjqz8+e28NsK16Na4PSbDM3GOYbiq+gb8dyDpvIQpzN6m 48G2dhETJpAvox6YnA6Ix9YDdoAl0Y25ynJSUajLbyQ9+rSiynIGnMT5UHFr9zaM 2zs9oXRaqO7Gj1A98nN0NwjC0U+sP7J2JidvcXbUO7YNx4exsgzUHdbrdG7gBpVd iPHpECyrgh3uqIRS0j3bCR6WQAOBGb708hXrNj5a/ldGvYTYlLmt2Tbq+mJapZmp uFLYrK1kwBmXj/3CSErO0Bg0lMspk8E0MnEljChdFPGYekkbPGhZKGp9EufczG+G C5L3dv7V1Nv2AyyFiYB3 =cyEa -END PGP SIGNATURE-
Re: [gentoo-dev] Re: New eclass: autotools-multilib-minimal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 24 Feb 2013 13:05:51 -0500 Jonathan Callen a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/24/2013 10:53 AM, Michał Górny wrote: I think that base.eclass is silently intended for removal at some point in the future. While we're here, we should probably mark it deprecated. The problem with deprecating base.eclass and telling people to use autotools-utils.eclass instead is that base.eclass also defines a src_prepare that is used for eclasses that support *non*-autotools build systems, such as cmake-utils.eclass. Requiring that support to be copied around to each of the eclasses that currently inherits base would allow the usual issues with copying code around. If something inherits base.eclass, it should stop. autotools-utils used to do that but I removed the inherit because of base_src_unpack() which was exported for no reason and caused trouble with VCS eclasses. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQJ8BAEBCgBmBQJRKlmBXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKiF4P/1L6vB7oSI5xIq6mrE82h7iW PNPWWRt+HBrLdK0u1uI/vuoGDs5/t02osGKNES0QVWRZz+70wRn8LBGoOp6A9Lz3 wEgguRDf6ppZc23Sr6uHXdr/mvAaTJezcJiME4eKoYXtda/eyZeiV22raZUktcGq wRXQIzTDGwyYZcmq454J5DfU7ANlYU2uCTMGwWgq8l1ObP55tpJuirKu8mLx+lH2 TOVNnZmWJfqlcjd0updTQjpI8ijlc7Dn42c/kd0P1SpiP6mn7qEGfYy2lfLJWnWh Z4LOnstwSlw1P6W09Htl8PHcLIGK1wA5ShvQVnfocnpuCpY8MXG+SrjYAA1RkWkZ dzPNzo8VKqR8wrI/WIqkPmrfRRqsUgx07uGiGkn2L4gkZiiM3zUMTQvqHI2oGhGl VE1xdG0Ca5O09U8FOdVJyUD8vO9xL7Ie5r8p35G6aRXrxEnQf8tYhCqbFyu/tq8V f7L4QY6I+Jivk1XvpAq217tdRDykl6zl9D0LmFzQTtPXq/HAJDLkS+qZg7JpZ6bz nsEv23jHPKeZ+WYOHvShFbgTUc1q+ky4F2qG7C4KrMJl7U6WRFqjCQdiDyfxLkNT SiQ1fzZDBSFSZZvEbDUpqjz4Aj2R7x0DZ/lUPd52U7KCeK4KBQaOHXD0hsihvG3C NJ3qcCqQWZYW9fR2wBP/ =huwA -END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sun, 24 Feb 2013 17:42:26 +0100 hasufell hasuf...@gentoo.org wrote: [...] I have no idea if it makes sense for this package (since it also installs binaries), but as an example I have converted dev-libs/serd. yes, that's the kind of usage of your eclass I was thinking about :) (it might make sense to convert it but there is no need for it I know about, there might arise some commercial binary-only package using it some day) And yes, a rename of the eclass would probably be appropriate. +1 Alexis.
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sun, 24 Feb 2013 18:58:08 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:
On 24/02/13 17:53, Michał Górny wrote:
I still try to use plain ebuilds without
inheritting autotools-utils.eclass as I usually don't need it, probably
others do the same and refuse to have to inherit it only for multilib
support :/ How do you plan to solve this problem?
You generally have two options on doing multilib builds: either using
out-of-source builds or in-source builds. If you decide on the latter,
you unnecessarily waste users' time and disk space to create two more
copies of sources. I don't think we should go this way.
If you decide on out-of-source builds, you basically need proper
src_{configure,compile,test,install} and that's what autotools-utils
does. Plus:
- patch applying and autoreconf in src_prepare() -- which are
completely optional, you are free to write your own src_prepare().
If you wanted to apply patches by hand, you'd need to write
src_prepare() anyway.
It's that Plus part that is my problem with autotools-multilib.eclass
currently, it adds EXPORT_FUNCTIONS of src_prepare() from
autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass
adds just another eclass/phase function to worry about for inherit order
I understand your concern but I see no way around it. The alternative
solution exports src_prepare() as well to copy the sources -- so it's
even more to worry about than the no-op-by-default.
- prune_libtool_files in src_install() which most people want to do
anyway, so that doesn't hurt -- and the pkg-config dep is going to
be removed, by the patch I sent already.
but lacks a way to pass arguments to prune_libtool_files, like --all,
since prune_libtool_files isn't that smart it gets it right everytime
i propably prefer to stick to manually calling it with or without --all
and well, this is not related to the multilib conversion so it shouldn't
be executed anyway
I can add the ability to pass arguments. So far, hasn't considered it
necessary since the single run doesn't really hurt anything noticeably.
- adding libtool args for shared/static libs if IUSE=static-libs --
which I wanted to remove but people considered it useful.
if it's not related to the multilib conversion, it shouldn't be executed...
It's not about multilib conversion solely.
Multilib conversion requires out-of-source build support. Out-of-source
build support is established using autotools-utils. The logical
conversion order is to:
1) convert the ebuild to autotools-utils, make sure that out-of-source
builds work,
2) convert the ebuild to autotools-multilib.
Some of my conversions actually follow that split, providing two
patches instead of one.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2013 07:56 PM, Michał Górny wrote: It's that Plus part that is my problem with autotools-multilib.eclass currently, it adds EXPORT_FUNCTIONS of src_prepare() from autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass adds just another eclass/phase function to worry about for inherit order I understand your concern but I see no way around it. The alternative solution exports src_prepare() as well to copy the sources -- so it's even more to worry about than the no-op-by-default. No, I don't export src_prepare. The developer has to call prepabisources at the end of src_prepare himself, but only if he wants to use IN_SOURCE_BUILD (this seems to be a requirement for waf-utils ebuilds at first glance). It's a bit similar to prepgamesdirs. I find it easier to require calling it explicitly since src_prepare is often times a very custom function. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRKmyaAAoJEFpvPKfnPDWzQNsH/iMfm5+k2CuFwX1MEIf28DAp 4onvA2zEKCZCDMU4+eTLr3he04Qhy1NJb2WIqK4ZsRMHZvrtLoDR1PlLSgBN1Zs7 pYOTtOama9M6ha50jZmDptsG6GlZEWkuDvhYloHa1nKmCUaQdUJ6Cks53vkT1WmX +Xaz/NJUCKARWj4yU6UzYxyh+kklLm/rSZPSDlpu329XD9aPUlRfH+QBQMY5S6gy 88VfbG0al+k0S7aB6Xj8gjCktj3ZLY0b4vMx6d0mrVw6sY1lJnz73Bd4NVCpW2QH UlLDMthlVLOhRDIxaLcJcSOkEJ4/LDANSR45zQviurqUKjQy68Ve3DztlFaVEXo= =lp6W -END PGP SIGNATURE-
Re: [gentoo-dev] New Python eclasses -- a summary and reminder
Looks like great work so far. On 11.02.2013 01:20, Michał Górny wrote: Secondly, I'd like to make it clear that the old python.eclass is 'almost' deprecated. We're in process of converting the in-tree packages to use the new eclasses but that's a lot of work [3]. [..] [3]:http://dev.gentoo.org/~mgorny/python-r1/conversion.xhtml I wonder what would be the best way to help with conversion for devs with a few hours to contribute? - Where does one go for peer review and how many eyes should be on related commits? - Should package owners be contacted in all cases? - Are there any conversion sprints already or in the future? Best, Sebastian
Re: [gentoo-dev] New Python eclasses -- a summary and reminder
On Sun, 24 Feb 2013 20:52:45 +0100 Sebastian Pipping sp...@gentoo.org wrote: Looks like great work so far. On 11.02.2013 01:20, Michał Górny wrote: Secondly, I'd like to make it clear that the old python.eclass is 'almost' deprecated. We're in process of converting the in-tree packages to use the new eclasses but that's a lot of work [3]. [..] [3]:http://dev.gentoo.org/~mgorny/python-r1/conversion.xhtml I wonder what would be the best way to help with conversion for devs with a few hours to contribute? Write docs ;). We need more complete, cleaner docs. - Where does one go for peer review and how many eyes should be on related commits? I guess #gentoo-python would be a good place. Look for me or floppym especially. - Should package owners be contacted in all cases? Well, I assumed that packages in Python herd can be converted without contacting other maintainers. For other packages, I opened a bug. - Are there any conversion sprints already or in the future? No. To be honest, I dislike unnecessary rush. The migration is a good moment to find bugs in Python ebuilds and fix them. Well, definitely better than 'review Python-related code' bugs :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On 24/02/13 02:34, hasufell wrote: Some people seem to feel uncomfortable with autotools-multilib, because it depends on autotools-utils. Instead of arguing whether it makes sense or not I'd propose a similar autotools related eclass. I also attach an example conversion of media-libs/libexif (the maintainer wants to keep the changes minimal). Effectively I am only (almost) changing the function names and not the ebuild code. looks good, seems exactly what I wanted Feel free to propose a different eclass name. whatever it will be, please make it shorter, like 'multiabi' maybe
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-02-24 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-02-24 23h59 UTC. Removals: www-apache/mod_vhs 2013-02-20 23:31:04 pinkbyte dev-haskell/wash2013-02-22 09:27:03 moult dev-libs/libole22013-02-22 10:42:30 moult www-apps/online-bookmarks 2013-02-22 23:14:56 moult Additions: games-arcade/notpacman 2013-02-18 01:01:45 hasufell sys-fs/ufsutils 2013-02-18 03:49:16 ryao net-misc/dhcpd-pools2013-02-19 16:46:30 cardoe net-analyzer/ipv6-toolkit 2013-02-19 19:22:31 robbat2 dev-libs/radlib 2013-02-19 23:00:27 flameeyes net-misc/teamviewer 2013-02-20 02:39:15 hasufell media-gfx/pngquant 2013-02-20 18:36:24 ssuominen games-simulation/flightgear-data2013-02-20 21:23:35 reavertm net-libs/libiscsi 2013-02-20 22:45:54 ryao dev-libs/log4cplus 2013-02-21 22:23:19 idl0r x11-misc/dunst 2013-02-22 14:12:34 wired net-libs/h323plus 2013-02-22 19:04:21 chithanh dev-ruby/deep_merge 2013-02-23 07:34:03 graaff net-misc/stargazer 2013-02-23 20:13:31 tomwij sys-process/crtools 2013-02-23 22:27:00 radhermit dev-util/peg2013-02-24 03:07:25 rafaelmartins app-text/peg-markdown 2013-02-24 04:26:36 rafaelmartins dev-python/hiredis 2013-02-24 09:50:34 swegener dev-python/ujson2013-02-24 09:56:11 swegener dev-python/squaremap2013-02-24 10:02:34 swegener dev-python/runsnakerun 2013-02-24 10:07:09 swegener sys-fs/f2fs-tools 2013-02-24 18:21:11 blueness -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: www-apache/mod_vhs,removed,pinkbyte,2013-02-20 23:31:04 dev-haskell/wash,removed,moult,2013-02-22 09:27:03 dev-libs/libole2,removed,moult,2013-02-22 10:42:30 www-apps/online-bookmarks,removed,moult,2013-02-22 23:14:56 Added Packages: games-arcade/notpacman,added,hasufell,2013-02-18 01:01:45 sys-fs/ufsutils,added,ryao,2013-02-18 03:49:16 net-misc/dhcpd-pools,added,cardoe,2013-02-19 16:46:30 net-analyzer/ipv6-toolkit,added,robbat2,2013-02-19 19:22:31 dev-libs/radlib,added,flameeyes,2013-02-19 23:00:27 net-misc/teamviewer,added,hasufell,2013-02-20 02:39:15 media-gfx/pngquant,added,ssuominen,2013-02-20 18:36:24 games-simulation/flightgear-data,added,reavertm,2013-02-20 21:23:35 net-libs/libiscsi,added,ryao,2013-02-20 22:45:54 dev-libs/log4cplus,added,idl0r,2013-02-21 22:23:19 x11-misc/dunst,added,wired,2013-02-22 14:12:34 net-libs/h323plus,added,chithanh,2013-02-22 19:04:21 dev-ruby/deep_merge,added,graaff,2013-02-23 07:34:03 net-misc/stargazer,added,tomwij,2013-02-23 20:13:31 sys-process/crtools,added,radhermit,2013-02-23 22:27:00 dev-util/peg,added,rafaelmartins,2013-02-24 03:07:25 app-text/peg-markdown,added,rafaelmartins,2013-02-24 04:26:36 dev-python/hiredis,added,swegener,2013-02-24 09:50:34 dev-python/ujson,added,swegener,2013-02-24 09:56:11 dev-python/squaremap,added,swegener,2013-02-24 10:02:34 dev-python/runsnakerun,added,swegener,2013-02-24 10:07:09 sys-fs/f2fs-tools,added,blueness,2013-02-24 18:21:11 Done.
[gentoo-dev] kerberos, virtuals, rattling cages
(I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol mike...@gmail.com wrote: (I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). I'm not familiar with anyone using Kerberos on Gentoo. I use it on Ubuntu; but we do not use it with Samba (or at least, if we do, I am not aware of it.) Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm fairly sure samba supports either kerberos implementation; is there something that makes you think differently? I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm not following you here. 'slot' means a very specific thing. You are not actually suggesting we use SLOT, you simply want both versions of the library to be installed in one ROOT? I would not advocate this approach. You should strive to have only one kerberos implementation on a given machine. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. It is likely that explicit dependencies are wrong, and are just bugs. -A
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On 02/24/2013 09:48 PM, Alec Warner wrote: On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol mike...@gmail.com wrote: (I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). I'm not familiar with anyone using Kerberos on Gentoo. I use it on Ubuntu; but we do not use it with Samba (or at least, if we do, I am not aware of it.) It's one of the core components of Active Directory, so anyone who puts a Gentoo machine on an AD domain will likely be using it. I'm playing around with Samba 4, which is supposed to have full support as a standalone AD controller. An AD controller is effectively a central box that manages and directs domain members to DNS (the host directory), LDAP (the user and authorization directory) and Kerberos (the authentication mechanism). Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm fairly sure samba supports either kerberos implementation; is there something that makes you think differently? The explicit dependency on app-crypt/heimdal in the ebuild, and comment 25 attached to b.g.o bug 195703. I've taken those at face value; I haven't followed up on them myself. I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm not following you here. 'slot' means a very specific thing. You are not actually suggesting we use SLOT, you simply want both versions of the library to be installed in one ROOT? I would not advocate this approach. You should strive to have only one kerberos implementation on a given machine. I'm really not certain, to be honest. It was my impression that slots allow for two different versions of a thing to be present on the same system, and that their different sonames on the system would lead to correct symbol resolution. (Although it would require that the soname being sought be adjusted in a dependent program to target the version required.) Even if it works, I acknowledge it's a nauseating hack for the circumstance. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. It is likely that explicit dependencies are wrong, and are just bugs. This is what I found in the ebuild for net-fs/nfs-utils: # kth-krb doesn't provide the right include # files, and nfs-utils doesn't build against heimdal either, # so don't depend on virtual/krb. # (04 Feb 2005 agriffis) Which I noted in a comment I attached to bug 231936 (relating to net-fs/nfs-util). In bug 195703 (relating to the samba-4 version bump), there's this: Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on virtual/krb5 but instead directly on heimdal after the com_err.h problem is fixed. in comment 25, dated 2009-11-24 23:07:18 UTC. Directly responded to later by this: Agreed. in comment 26, dated 2009-11-25 10:01:48 UTC signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: kerberos, virtuals, rattling cages
Michael Mol posted on Sun, 24 Feb 2013 22:17:56 -0500 as excerpted: I'm not following you here. 'slot' means a very specific thing. You are not actually suggesting we use SLOT, you simply want both versions of the library to be installed in one ROOT? I would not advocate this approach. You should strive to have only one kerberos implementation on a given machine. I'm really not certain, to be honest. It was my impression that slots allow for two different versions of a thing to be present on the same system, and that their different sonames on the system would lead to correct symbol resolution. (Although it would require that the soname being sought be adjusted in a dependent program to target the version required.) The issue is in one's definition of two different versions of a thing. Slot, in the gentoo sense, has the meaning of two different versions of the same package, say qt-3 (tho that's long out-of-tree, but alive in kde- sunset) and qt-4 and qt-5 (tho that's very new, but is or will soon be a problem as more packages dep on it), where there'd ordinarily be file and/ or functionality collisions, NOT two different packages containing the same functionality, which is the extended meaning it appears you're applying here, but which only confuses people when used within the gentoo context. -- 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
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Sun, Feb 24, 2013 at 7:17 PM, Michael Mol mike...@gmail.com wrote: On 02/24/2013 09:48 PM, Alec Warner wrote: On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol mike...@gmail.com wrote: (I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). I'm not familiar with anyone using Kerberos on Gentoo. I use it on Ubuntu; but we do not use it with Samba (or at least, if we do, I am not aware of it.) It's one of the core components of Active Directory, so anyone who puts a Gentoo machine on an AD domain will likely be using it. I'm playing around with Samba 4, which is supposed to have full support as a standalone AD controller. An AD controller is effectively a central box that manages and directs domain members to DNS (the host directory), LDAP (the user and authorization directory) and Kerberos (the authentication mechanism). Don't misunderstand, I know what all these things are ;) Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm fairly sure samba supports either kerberos implementation; is there something that makes you think differently? The explicit dependency on app-crypt/heimdal in the ebuild, and comment 25 attached to b.g.o bug 195703. I've taken those at face value; I haven't followed up on them myself. I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm not following you here. 'slot' means a very specific thing. You are not actually suggesting we use SLOT, you simply want both versions of the library to be installed in one ROOT? I would not advocate this approach. You should strive to have only one kerberos implementation on a given machine. I'm really not certain, to be honest. It was my impression that slots allow for two different versions of a thing to be present on the same system, and that their different sonames on the system would lead to correct symbol resolution. (Although it would require that the soname being sought be adjusted in a dependent program to target the version required.) mit-krb5 and heimdal are separate packages. They both provide krb headers and kerb libraries. You could easily patch them to be on the same system. The problem with doing so is that packages are expecting only one set of kerberos headers and kerberos shared libraries. We have the 'eselect' framework for switching between 'providers' which we could use in this case (similar to say, the opengl libraries your system might use.) It is not clear to me if switching providers is at all safe in the kerberos instance, or if software built against mit-krb5 would crash if you pointed the loader at some heimdal shared objects. Even if it works, I acknowledge it's a nauseating hack for the circumstance. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. It is likely that explicit dependencies are wrong, and are just bugs. This is what I found in the ebuild for net-fs/nfs-utils: # kth-krb doesn't provide the right include # files, and nfs-utils doesn't build against heimdal either, # so don't depend on virtual/krb. # (04 Feb 2005 agriffis) Which I noted in a comment I attached to bug 231936 (relating to net-fs/nfs-util). In bug 195703 (relating to the samba-4 version bump), there's this: Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on virtual/krb5 but instead directly on heimdal after the com_err.h problem is fixed. in comment 25, dated 2009-11-24 23:07:18 UTC. Directly responded to later by this: Agreed. in comment 26, dated 2009-11-25 10:01:48 UTC So nothing recent then ;p I think just 'eras' is the only person in the kerberos herd at this point. I only have a passing interest in it myself (and I'm not looking to maintain it in Gentoo ;)) -A
Re: [gentoo-dev] Re: kerberos, virtuals, rattling cages
On 02/24/2013 10:40 PM, Duncan wrote: Michael Mol posted on Sun, 24 Feb 2013 22:17:56 -0500 as excerpted: I'm not following you here. 'slot' means a very specific thing. You are not actually suggesting we use SLOT, you simply want both versions of the library to be installed in one ROOT? I would not advocate this approach. You should strive to have only one kerberos implementation on a given machine. I'm really not certain, to be honest. It was my impression that slots allow for two different versions of a thing to be present on the same system, and that their different sonames on the system would lead to correct symbol resolution. (Although it would require that the soname being sought be adjusted in a dependent program to target the version required.) The issue is in one's definition of two different versions of a thing. Slot, in the gentoo sense, has the meaning of two different versions of the same package, say qt-3 (tho that's long out-of-tree, but alive in kde- sunset) and qt-4 and qt-5 (tho that's very new, but is or will soon be a problem as more packages dep on it), where there'd ordinarily be file and/ or functionality collisions, NOT two different packages containing the same functionality, which is the extended meaning it appears you're applying here, but which only confuses people when used within the gentoo context. My presumption was that both app-crypt/heimdal and app-crypt/mit-krb5 used the same binary names. $ equery f app-crypt/mit-krb5|grep -e '\.so'|sed -e 's/\.so.*//'|sed -e 's/.*\///'|sort -u|grep -v debug db2 encrypted_challenge libgssapi_krb5 libgssrpc libk5crypto libkadm5clnt libkadm5clnt_mit libkadm5srv libkadm5srv_mit libkdb5 libkrb5 libkrb5support pkinit (on a different machine) $ equery f app-crypt/heimdal|grep -e '\.so'|sed -e 's/\.so.*//'|sed -e 's/.*\///'|sort -u|grep -v debug libasn1 libgssapi libhcrypto libhdb libheimbase libheimntlm libhx509 libkadm5clnt libkadm5srv libkafs libkdc libkrb5 libroken libsl libwind windc The overlap between the two includes libkrb5, libkadm5clnt and libkadm5srv. When I was thinking why not slots?, that was explicitly the part I was thinking of. The distinction between two versions of a thing, and two implementations of a thing, is a thorny epistemological issue; extended meaning is good way to put it. I've acknowledge that abusing slots in this way is pretty vile. I don't really care to advocate it; I merely brought it up as an alternative. (But it seems it's a difficult question to bridge.) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On 02/24/2013 10:46 PM, Alec Warner wrote: On Sun, Feb 24, 2013 at 7:17 PM, Michael Mol mike...@gmail.com wrote: On 02/24/2013 09:48 PM, Alec Warner wrote: On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol mike...@gmail.com wrote: (I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). I'm not familiar with anyone using Kerberos on Gentoo. I use it on Ubuntu; but we do not use it with Samba (or at least, if we do, I am not aware of it.) It's one of the core components of Active Directory, so anyone who puts a Gentoo machine on an AD domain will likely be using it. I'm playing around with Samba 4, which is supposed to have full support as a standalone AD controller. An AD controller is effectively a central box that manages and directs domain members to DNS (the host directory), LDAP (the user and authorization directory) and Kerberos (the authentication mechanism). Don't misunderstand, I know what all these things are ;) Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm fairly sure samba supports either kerberos implementation; is there something that makes you think differently? The explicit dependency on app-crypt/heimdal in the ebuild, and comment 25 attached to b.g.o bug 195703. I've taken those at face value; I haven't followed up on them myself. I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm not following you here. 'slot' means a very specific thing. You are not actually suggesting we use SLOT, you simply want both versions of the library to be installed in one ROOT? I would not advocate this approach. You should strive to have only one kerberos implementation on a given machine. I'm really not certain, to be honest. It was my impression that slots allow for two different versions of a thing to be present on the same system, and that their different sonames on the system would lead to correct symbol resolution. (Although it would require that the soname being sought be adjusted in a dependent program to target the version required.) mit-krb5 and heimdal are separate packages. They both provide krb headers and kerb libraries. You could easily patch them to be on the same system. The problem with doing so is that packages are expecting only one set of kerberos headers and kerberos shared libraries. We have the 'eselect' framework for switching between 'providers' which we could use in this case (similar to say, the opengl libraries your system might use.) It is not clear to me if switching providers is at all safe in the kerberos instance, or if software built against mit-krb5 would crash if you pointed the loader at some heimdal shared objects. Don't misunderstand, I know about eselect. ;) And, yeah, I don't know if thunking/shimming/redirecting is safe in the kerberos context. If it was, there should never have been any question of compatibility. Even if it works, I acknowledge it's a nauseating hack for the circumstance. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. It is likely that explicit dependencies are wrong, and are just bugs. This is what I found in the ebuild for net-fs/nfs-utils: # kth-krb doesn't provide the right include # files, and nfs-utils doesn't build against heimdal either, # so don't depend on virtual/krb. # (04 Feb 2005 agriffis) Which I noted in a comment I attached to bug 231936 (relating to net-fs/nfs-util). In bug 195703 (relating to the samba-4 version bump), there's this: Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on virtual/krb5 but instead directly on heimdal after the com_err.h problem is fixed. in comment 25, dated 2009-11-24 23:07:18 UTC. Directly responded to later by this: Agreed. in comment 26, dated 2009-11-25 10:01:48 UTC So nothing recent then ;p Which is exactly why I bring it up; the net-fs/nfs-utils bug is stale, and the reference in the samba package is ancient. (Things directly partaining to samba-4 get bounced into that bug, which really means a stale
[gentoo-dev] GCC 4.7 unmasking
I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs blocking the 4.7 tracker, so if any are yours now would be a good time to take a look at them. https://bugs.gentoo.org/390247 -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] GCC 4.7 unmasking
On 25 Feb 2013 06:53, Ryan Hill dirtye...@gentoo.org wrote: I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs blocking the 4.7 tracker, so if any are yours now would be a good time to take a look at them. https://bugs.gentoo.org/390247 Can't you just smell all those Gentoo systems gearing up for long emerge -e sessions? xD Thanks for working on this. Alex | wired
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On 02/24/13 20:25, Michael Mol wrote: (I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. so, read the thread so far, and I think you are over-complicating things with slotting. I use kerberos at home (more or less just to learn it, worksforme, etc). I chose MIT. From what I understand MIT and heimdal are mutually exclusive (can not operate with eachother) and that heimdal is what windows uses. What this seems to be is a simple case of blockers. So, the quesiton is, are you going to be using kerberos in nfs? if not, masking the flag may be what works for you (in the short term at least). Longer term it sounds like maybe seperate use flags are in order (or something, dunno). I don't think samba will support MIT, since it's kinda windows focused. On another note, I can't find bug 231936. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GCC 4.7 unmasking
On 02/24/13 23:45, Alex Alexander wrote: On 25 Feb 2013 06:53, Ryan Hill dirtye...@gentoo.org wrote: I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs blocking the 4.7 tracker, so if any are yours now would be a good time to take a look at them. https://bugs.gentoo.org/390247 Can't you just smell all those Gentoo systems gearing up for long emerge -e sessions? xD Thanks for working on this. Alex | wired Some of us are already on it :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Sun, Feb 24, 2013 at 09:25:37PM -0500, Michael Mol wrote: 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. You can't eselect the kerberos implementation under an application. These two packages do provide different symbols. And you can't just make both packages installable concurrently and hope everything works out. There are too many assumptions built into too many applications about what library from which package provides what symbol. That way lies madness. The bugs you mantion are old ones. I suggest you (and net-fs and samba herds) to check if they still apply and if they do see what prevents the said package from using the alternative implementation and solve it there - where it really belongs anyway. -- Eray Aslan e...@gentoo.org pgpAQ4UcXnyKi.pgp Description: PGP signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Sun, Feb 24, 2013 at 11:21 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 02/24/13 20:25, Michael Mol wrote: (I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. so, read the thread so far, and I think you are over-complicating things with slotting. I use kerberos at home (more or less just to learn it, worksforme, etc). I chose MIT. From what I understand MIT and heimdal are mutually exclusive (can not operate with eachother) and that heimdal is what windows uses. This is incorrect, or at least, was incorrect last time I looked (circa...uhh..2009?) They work 'ok' together. Heimdal clients could talk to MIT servers at least. Of course, there were quirks, and incompatible command line syntax, hence my fierce recommendation to 'not do that.' What this seems to be is a simple case of blockers. So, the quesiton is, are you going to be using kerberos in nfs? if not, masking the flag may be what works for you (in the short term at least). Longer term it sounds like maybe seperate use flags are in order (or something, dunno). Do not use Kerberized NFSv3. I'm unsure if nfsv4 is any better :/ -A I don't think samba will support MIT, since it's kinda windows focused. On another note, I can't find bug 231936. -- -- Matthew Thode (prometheanfire)
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On 02/25/13 01:43, Alec Warner wrote: On Sun, Feb 24, 2013 at 11:21 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 02/24/13 20:25, Michael Mol wrote: (I really don't have time to actively participate on this list right now, but I believe that if I bring it up on b.g.o, I'll be directed here, so...) So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to enable kerberos system-wide on my server. No joy, as net-fs/nfs-utils has an explicit dependency on app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on app-crypt/heimdal (for reasons noted in bug 195703, comment 25). Questions: 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 and kerberos demands that things with explicit dependencies on mit-krb5 either be fixed or not used at all. I'm the first activity on bug 231936 in two years...could someone please look into that one? 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them through a virtual? My suspicion is no, but I don't know enough about kerberos to say whether or not it would work, even as a hack. I'm sure explicit dependencies on mit-krb5 and heimdal will continue to crop up, so (and forgive the nausea this might cause) it might help to slot mit and heimdal, and have virtual/krb5 depend on the presence of at least one. so, read the thread so far, and I think you are over-complicating things with slotting. I use kerberos at home (more or less just to learn it, worksforme, etc). I chose MIT. From what I understand MIT and heimdal are mutually exclusive (can not operate with eachother) and that heimdal is what windows uses. This is incorrect, or at least, was incorrect last time I looked (circa...uhh..2009?) well, that was right around the time I installed it, so guess that makes sense. They work 'ok' together. Heimdal clients could talk to MIT servers at least. Of course, there were quirks, and incompatible command line syntax, hence my fierce recommendation to 'not do that.' What this seems to be is a simple case of blockers. So, the quesiton is, are you going to be using kerberos in nfs? if not, masking the flag may be what works for you (in the short term at least). Longer term it sounds like maybe seperate use flags are in order (or something, dunno). Do not use Kerberized NFSv3. I'm unsure if nfsv4 is any better :/ -A I don't think samba will support MIT, since it's kinda windows focused. On another note, I can't find bug 231936. -- -- Matthew Thode (prometheanfire) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
