Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 20:14:43 -0400 Alexis Ballier aball...@gentoo.org wrote: Ah, while we're at it. If a library has macros referring to the functions of another library (or just types) in its public API, it needs a pkg-config file. ELF dependencies are not enough, and the gold linker will refuse to work because of a missing explicit dependency. Eh, straight to the point where pkgconfig is not the solution to everything: a binary not using said macros but trusting pkgconfig will get overlinked. Documentation stating that when using these macros/functions one should link to the other lib would make things even better. The macros/types can change over time. Maintaining all indirect dependencies is not friendly nor useful. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Sat, 1 Sep 2012 00:07:38 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 31 Aug 2012 16:03:25 -0700 Zac Medico zmed...@gentoo.org wrote: runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. All suggested deps are not equal, so USE flags give you the ability to pick and choose the ones that you want. So does --take / --ignore with suggested dependencies, with the added advantage that suggested packages don't end up being brought in without user request just because a user has a particular use flag enabled globally. Yes because runtime SSL support is *so much* different than build-time one. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Sat, 1 Sep 2012 09:40:47 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 31 Aug 2012 20:14:43 -0400 Alexis Ballier aball...@gentoo.org wrote: Ah, while we're at it. If a library has macros referring to the functions of another library (or just types) in its public API, it needs a pkg-config file. ELF dependencies are not enough, and the gold linker will refuse to work because of a missing explicit dependency. Eh, straight to the point where pkgconfig is not the solution to everything: a binary not using said macros but trusting pkgconfig will get overlinked. Documentation stating that when using these macros/functions one should link to the other lib would make things even better. The macros/types can change over time. Maintaining all indirect dependencies is not friendly nor useful. So in this hypothetic case where your lib changes its ABI and API, it is not friendly and seen useless by consumers, I think I agree :)
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, Aug 31, 2012 at 11:50 PM, Ryan Hill dirtye...@gentoo.org wrote: On Fri, 31 Aug 2012 22:51:08 +0200 Michał Górny mgo...@gentoo.org wrote: Such a goals may be good for distributions like Exherbo which aim to make everything perfect. I believe that Gentoo aims more around 'good enough but at least realistic', instead of running for some kind of utopia which simply does not work. I don't understand your stance here, because to me 'good enough but realistic' means ignoring standards when they're stupid, embracing them when they're not, and forging your own where they don't yet exist. Perfection, by definition, requires an existing standard to hold yourself up against. In any case, I wasn't suggesting that a typical user would run without POSIX. I just think that we'd be better off if our dependencies were fully specified which will aid those doing unusual things with Gentoo. Keep in mind that unusual unix-like implementations are all around us. I doubt a Tivo even has a shell installed, and a typical Android phone has a very non-traditional set of tools available. I think the default Gentoo install should be pretty similar to what it is today. However, more flexibility to deviate isn't a bad thing. That said, having fully specified dependencies without giving headaches to maintainers is also a good goal. I think that absent better tools @system is always going to have to be a compromise. Rich
[gentoo-dev] Future Trends
Colleagues, I have been considering the current push to replace init with systemd for all Linux systems. systemd has been adopted by Fedora and openSuSE as the default init system - and to ensure it becomes the de facto standard, SysVInit has been deprecated to the extent it is now virtually unsupported by those distributions. To reinforce the necessity to convert to systemd udev source is now being offered as part of a package together with systemd source. Meanwhile, consolekit has disappeared to be replaced by systemd-loginctl. KDE build flags on Gentoo have traditionally been: consolekit udev policykit dbus As we all know d-bus provides userspace with a message bus system. This is not far removed from systemd in that systemd seeks to manage sockets and launch processes based on events communicated through the messaging system. udev creates devices on-the-fly and communicates these events using the message bus. Consequently I predicted that the necessity to bulld systemd together with udev will, in the next six months, become a necessity to build systemd, udev and d-bus as ONE ENTITY. At that point, systemd's coup-de-grace will be complete and to build KDE you will have to accept systemd as your default init system. In fact, to build virtually any Desktop machine you will have to accept systemd as your init system. Comments? Mike
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 18:45:59 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/31/2012 04:07 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 16:03:25 -0700 Zac Medico zmed...@gentoo.org wrote: runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. All suggested deps are not equal, so USE flags give you the ability to pick and choose the ones that you want. So does --take / --ignore with suggested dependencies, with the added advantage that suggested packages don't end up being brought in without user request just because a user has a particular use flag enabled globally. If the USE flags have ambiguous meanings doesn't that mean that they've been poorly named? It's not like that. It's that in practice, suggestions are mostly for a particular specific feature (such as git-send-email support), not for a general concept (such as email in general). It also defeats the point of suggestions, if they're not made visible. For users, suggestions should look like suggestions, and they should be able to see them easily. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Future Trends
Am Samstag, 1. September 2012, 17:09:59 schrieb llemike...@aol.com: Colleagues, I have been considering the current push to replace init with systemd for all Linux systems. [snip] Comments? Mike Please ignore. We've had enough pointless systemd threads already. -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 09/01/2012 09:00 AM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 18:45:59 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/31/2012 04:07 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 16:03:25 -0700 Zac Medico zmed...@gentoo.org wrote: runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. All suggested deps are not equal, so USE flags give you the ability to pick and choose the ones that you want. So does --take / --ignore with suggested dependencies, with the added advantage that suggested packages don't end up being brought in without user request just because a user has a particular use flag enabled globally. If the USE flags have ambiguous meanings doesn't that mean that they've been poorly named? It's not like that. It's that in practice, suggestions are mostly for a particular specific feature (such as git-send-email support), not for a general concept (such as email in general). It also defeats the point of suggestions, if they're not made visible. For users, suggestions should look like suggestions, and they should be able to see them easily. This sounds more like a user-interface issue than a problem with runtime-switchable USE flags (GLEP 62). The nice thing about runtime-switchable USE flags is that makes it possible to allow users to unify all of their optional dependency choices in their USE flag settings. You can still implement a --take / --ignore mechanism while allowing the use of runtime-switchable USE conditionals in SDEPEND. It's simply a matter of ignoring the USE conditionals and instead using your --take / --ignore mechanism to select atoms. -- Thanks, Zac
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Sat, 01 Sep 2012 11:15:16 -0700 Zac Medico zmed...@gentoo.org wrote: This sounds more like a user-interface issue than a problem with runtime-switchable USE flags (GLEP 62). The nice thing about runtime-switchable USE flags is that makes it possible to allow users to unify all of their optional dependency choices in their USE flag settings. The nice thing about GLEP 62 is that no-one has implemented it and tried it with lots of packages and a bunch of users, thus figuring out just how much of a pain in the ass getting this right is... Right now we're debating the merits of a tried and tested solution versus an entirely hypothetical idea. If you really think unification is an advantage, you could treat exheres-style suggestion names as a special USE_EXPAND group. But practical experience suggests that suggestions *shouldn't* be unified, and that the way to make the feature useful to users is to get the user to explicitly accept or reject suggestions, and to make suggestions look like suggestions. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] stripping escape sequences from build logs
All, I find the included escape sequences to be annoying when I am reading a build log. Is there a way to strip these? Thanks, William pgp5HadawgmHT.pgp Description: PGP signature
Re: [gentoo-dev] stripping escape sequences from build logs
On 01/09/2012 15:39, William Hubbs wrote: I find the included escape sequences to be annoying when I am reading a build log. Is there a way to strip these? I had that problem — you can find my script that does that (as well as other stuff) at https://github.com/gentoo/tboxanalysis -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] stripping escape sequences from build logs
On Sat, 1 Sep 2012 17:39:13 -0500 William Hubbs willi...@gentoo.org wrote: All, I find the included escape sequences to be annoying when I am reading a build log. Is there a way to strip these? I think the 'easy' way is to view them using 'less'. Not sure if it will work for you. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI usage
On Fri, Aug 31, 2012 at 03:49:43PM +0100, Ciaran McCreesh wrote: On Thu, 30 Aug 2012 23:58:00 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Of course an individual PM could choose to keep support for as long as they want, but unless I'm missing something, that'd let PMs drop support for old EAPIs if desired, with at least a reasonably sane upgrade path for both PM devs and users. It's irrelevant: the amount of package mangler code to be saved by removing old EAPIs is so small it's not worth discussing. Most EAPI changes so far have either been additions or very simple behaviour tweaks, not removals of annoying things. Just seconding this statement; no PM author has stated maintaining EAPIs is an undue burden- it's come everytime from folks who don't /actually do any PM code/. So please stop telling us what is, and isn't a burden in our code. :) There are things we might change in future EAPIs that will in the very long term make this discussion worthwhile. If we get rid of VDB access or unconstrained env saving, *then* it might be worth having this discussion. Realistically even then, that's just swivelling vars/functions exposed to the ebuild env- it would require the vast majority of ebuilds migrating to EAPI versions that hide VDB access for this to be worth discussing (else due to backwards compat, it's a pointless discussion). Either way, there's no reason to require devs use the latest EAPI; they migrate at their own pace as they need to, which is fine. Case in point, check gentoo-x86 eapi usage: repository '/var/db/repos/gentoo': eapi: '4' 13523 pkgs found, 42.58% of the repository eapi: '0' 8171 pkgs found, 25.73% of the repository eapi: '2' 5246 pkgs found, 16.52% of the repository eapi: '3' 4297 pkgs found, 13.53% of the repository eapi: '1' 520 pkgs found, 1.64% of the repository 0 is still in heavy usage since a lot of ebuilds don't need the newer EAPI functionality; 1 is mostly dead since the only gain of it (in comparison to 0) was slot deps, 2 had used use deps thus those same folk migrated to 2 (since if you need slot deps, it's semi likely you need use deps). As for 3... that was prefix and xz support. No reason to use it in comparison to 4 frankly. Personally, I don't have any problems if gentoo were to mandate that EAPI1 shouldn't be used for new ebuilds in gentoo-x86, eapi2 instead. That sort of standard would make sense. ~harring
Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)
On Fri, Aug 31, 2012 at 11:12:44AM -0400, Alexis Ballier wrote: On Fri, 31 Aug 2012 15:45:21 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Coming back to this old topic [1]. Is there still consensus that we should have such an EJOBS variable? (It shouldn't be called JOBS because this name is too generic, see the old discussion.) Then we could add it to EAPI 5. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml If we're doing this, do we tell users to stop setting MAKEOPTS for EAPIs 5 and greater? How can this work ? I cant think of any simple solution. Do we change the name of MAKEOPTS for EAPIs 5 and greater instead? Do we put fancy code in the package mangler to deal with it? IMHO EAPI-5 compliant PMs should do MAKEOPTS=$MAKEOPTS -j$EJOBS for every EAPI; using EJOBS from ebuilds/eclasses is allowed only in EAPI 5 and greater. This is retroactive but could be classified 'PM internals' so its fine imho. This approach is fine imo, although I'd *potentially* look at adding a magic $PROC_COUNT var that is the # of cpu threads on the system; either that or defaulting jobs to it. I rather dislike requiring users to go jam a 2/4/8 in there when it's easy to compute. That said, it's minor. Either way, yes, I think EJOBS should be in EAPI5. ~harring
Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)
On Sat, Sep 1, 2012 at 8:20 PM, Brian Harring ferri...@gmail.com wrote: On Fri, Aug 31, 2012 at 11:12:44AM -0400, Alexis Ballier wrote: On Fri, 31 Aug 2012 15:45:21 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Coming back to this old topic [1]. Is there still consensus that we should have such an EJOBS variable? (It shouldn't be called JOBS because this name is too generic, see the old discussion.) Then we could add it to EAPI 5. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml If we're doing this, do we tell users to stop setting MAKEOPTS for EAPIs 5 and greater? How can this work ? I cant think of any simple solution. Do we change the name of MAKEOPTS for EAPIs 5 and greater instead? Do we put fancy code in the package mangler to deal with it? IMHO EAPI-5 compliant PMs should do MAKEOPTS=$MAKEOPTS -j$EJOBS for every EAPI; using EJOBS from ebuilds/eclasses is allowed only in EAPI 5 and greater. This is retroactive but could be classified 'PM internals' so its fine imho. This approach is fine imo, although I'd *potentially* look at adding a magic $PROC_COUNT var that is the # of cpu threads on the system; either that or defaulting jobs to it. I rather dislike requiring users to go jam a 2/4/8 in there when it's easy to compute. That said, it's minor. On this point, I use dynamic load-based job counting. I'd be using distcc, too, but I don't have the spare hardware for a second build box right now. For a single box, I target a load average of $PROC_COUNT, with a max jobs in the vicinity of 2x$PROC_COUNT, to prevent I/O hangs from causing job count explosions. (Where I/O hiccups aren't a concern, I've found leaving --jobs open-ended worked fine, but builds always eventually expand to consume available I/O as upstream things get larger) I find this works very well; emerge and make both manage to lurk near the optimum point of keeping the CPU busy without spending too much time in context switches. In a distcc context, I would most likely target a load average of $LOCAL_PROC_COUNT, with a max jobs of (2*$LOCAL_PROC_COUNT+$REMOTE_PROC_COUNT). If ebuilds are try to be more aware of parallel-build contexts, I think it's important they're not limited to static job counts. -- :wq
