Re: [gentoo-dev] Help offered - Portage tree
(I experimented with binpkgs a little while ago in Prefix) On 13-03-2008 10:15:33 -0400, Caleb Tennis wrote: > > +1 on that and if people who use binary pkgs don't tell us what breaks, > > we won't know. > > I'll kick it off, then. > > The binpkg format needs some way to store the actual versions of the > dependencies as they were on the machine the package was compiled on. > Then, when emerging the binpkg, someway to force those dependencies on > the new install machine would be nice. > > I'll give an example. Package A was built on machine 1, and has a dep on > >=openssl-0.9.7. Machine 1 has openssl-0.9.8 already installed. Binary > >package > built, no problem. > > Now, we attempt to install binary package A on machine 2, which has > openssl-0.9.7. It installs fine, deps met. But, whoops, there's some > symbols missing when we go to use package A on machine 2. After some > time, we finally realize it's because we need new openssl. Isn't that stored in the NEEDED file? > I use this example because it's actually hit me before, but it extends > to lots of other scenarios. The obvious fix is to either use --deep, > or just make sure you need machine 2 up to date with machine 1, though > that's difficult to do when you're talking about machine 301 and > machine 559. > > If there was a way to tell the bin package installer to make sure you > met all of the same minimum verisons of the deps as they were on the > original compiling machine, that would be fantastic. I guess ideally the SLOTs should match, as for instance libpcre 7.5 and 7.6 work fine as long as libpcre.so.0 is there. (No guarantees) But even, for platforms that need libgcc_s.so.1, any gcc that provides it should be fine. Though luckily gcc is almost never in DEPEND/RDEPEND. > Now, I'm happy to file a bug and assign it (to the portage team?), but > I view this really as a wishlist item, and since admittedly very few > devs use the binpkg stuff, I didn't see it as something that would > probably get acted upon anyway. I'm not complaining about that > either, just merely stating a fact. I think binpkgs store more information than you think. It's just that Portage doesn't fully use it (yet). -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On 21-03-2008 10:20:45 +, Roy Marples wrote: > Hi List. > > I've just removed the code to check for euid when running services and > instead relying on permissions of the service state dir and testing > errno. This is a good thing, but it does have one side effect. > > OpenRC can track daemons by how they were started. So every time you > run rc-status it tests each reported service to ensure all daemons are > up. This also works fine unprivileged on normal boxes - except for > hardened where users can only see their own processes. Assuming you would use libkvm, on Darwin this means as unprivileged user (not using suid) you can't see any processes at all. > This isn't really an easy answer, as we could have installed OpenRC in a > prefix where this wouldn't apply, but we don't know that either. > > Ideas anyone? Is there a way to just have some fallback method which is less functional, but just uses some pid file with a lock or something? -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On 21-03-2008 12:07:24 +, Roy Marples wrote: > On Friday 21 March 2008 10:37:11 Fabian Groffen wrote: > > Assuming you would use libkvm, on Darwin this means as unprivileged user > > (not using suid) you can't see any processes at all. > > That's different from FreeBSD and NetBSD then. Indeed. And I just found out that Leopard (10.5) dropped the entire kvm which wasn't working to funky anyway. I just made some implementation of walking through all running processes for portage-utils' `qlop -c` using sysctl calls -- the way to do it on Darwin, and that works even as normal unprivileged user, so I guess we can just use that. > > Is there a way to just have some fallback method which is less > > functional, but just uses some pid file with a lock or something? > > Not all services use pidfiles. Also, some services re-fork and re-write their > pidfiles and I'm not sure the lock would carry across in that instance. I was thinking of a wrapping process, but I only later realised that this isn't working since many/most daemons fork into the background, so you loose the control over it anyway. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On 02-04-2008 21:21:25 -0400, Richard Freeman wrote: > Would it make more sense to just make a policy that failure to maintain > packages that you're maintainer on will result in getting removed as the > maintainer, with said packages going up for grabs? Devs who keep claiming > packages only to allow them to bitrot can be booted. On other projects I sometimes see a remark such as: "Maintainer time-out, committing the fix as in bug #bla" Maybe that is a bit less intrusive as dropping the maintainer entirely. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New profiles
On 09-04-2008 10:15:26 -0700, Chris Gianelloni wrote: > Please remember to sync gentoo-x86/profiles before doing any further > commits. The new profiles need as much checking as possible. There > have been several commits made by people who have masked things and such > but forgot the new profiles. Also, if you make changes to any of the > new profiles, please let me know so I can sync the changes into the > snapshot tree. I may have missed some post, but do you have a short description, or a pointer to some documentation of how the profiles are structured now? I'd like to reorganise my prefix profiles in the same way. I see some big benefits in doing so, but before I do I'd like to make sure I understand the new structure correctly. Thanks! -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 27
On 10-04-2008 16:35:36 -0400, Doug Goldstein wrote: > How does everyone feel about the proposed layout and syntaxes of GLEP 27? > > Do we want to revisit this GLEP with an updated GLEP or status quo? > > http://www.gentoo.org/proj/en/glep/glep-0027.html See also: http://bugs.gentoo.org/show_bug.cgi?id=53269 -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] escaping variables in sed expressions
On 15-04-2008 13:05:26 +0200, Santiago M. Mola wrote:
> On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
> <[EMAIL PROTECTED]> wrote:
> >
> > Hi list,
> >
> > it seems I have been using some fragile sed expression and I'd like to tap
> > the collective
> > wisdom for avoiding doing that in the future.
> >
> > dev-scheme/slib-3.1.5-r1 currently does
> >
> > sed "s_prefix = /usr/local/_prefix = ${D}/usr/_" -i Makefile
> >
> > to make it not violate the sandbox. However a user had set
> > PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to
> > contain too may
> > underscores and failing.[1]
> >
> > There are several option to handle this. I could use a less common
> > delimiter or I could
> > escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that
> > doesn't suffer
> > from this problem (thanks to dleverton):
> >
> > sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile
> >
> > Comments?
> >
>
> Currently is use ':' as sed delimiter when paths are involved. I'd
> also like to hear from you about proper delimiters if you think ':' is
> not safe enough.
I met one case where : was indeed a problem, but that was in
CFLAGS/LDFLAGS replacements. Some linkers accept (and do require)
arguments that are like "-mg:2512s".
> AFAIK, the only corner case which would make this fail would be
> Windows paths (C:/gentoo-prefix).
C:\ iirc, but Cygwin seems to map this as /cygdrive/C, Interix as
/dev/fs/C, command prompt I have no clue how portage could ever normally
work there. SpikeSource's SpikeWAMP uses Cygwin underneath, so
Portage/ebuilds will see the mapped paths only, never heard of any
problems from them regarding this either.
--
Fabian Groffen
Gentoo on a different level
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] DevRel policy update
On 27-04-2008 22:06:30 +0200, Wulf C. Krueger wrote: > How to gain power the easy way and obsolete conflict resolution in just > one commit: > > http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.18&r2=1.19 I noticed the same, but there probably was a better way to put attention to this remarkable policy. I assume it is just a better, more explicit wording of already existing policy, considering the original version. The policy appears worrysome to me, but in my opinion seems not to be introduced by this commit. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 30-04-2008 13:35:40 +0200, Denis Dupeyron wrote: > It's my pleasure to introduce Markus Duft (mduft) as a new developer. > He will go among us under the name of mduft, and will work in the > Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that > means Gentoo on Win32. > Please everybody, give a very warm welcome to mduft. Yay, at last someone in our team that has the right to "feel blue" :) Welcome and enjoy! -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 30-04-2008 19:51:42 +0300, Alon Bar-Lev wrote: > On 4/30/08, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > > It's my pleasure to introduce Markus Duft (mduft) as a new developer. > > He will go among us under the name of mduft, and will work in the > > Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that > > means Gentoo on Win32. > > Welcome! > > I will love to see Windows support via cygwin and not commartial product. > Something like [1], [2]. Interix is free and these days bundled with Windwows, IIRC. Why do you want it to run on Cygwin? (Honest question...) -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 30-04-2008 20:44:50 +0300, Alon Bar-Lev wrote: > > > I will love to see Windows support via cygwin and not commartial product. > > > Something like [1], [2]. > > > > Interix is free and these days bundled with Windwows, IIRC. > > I couldn't understand it from [1], anyway the source is unavailable right? Heh, yeah, sort of. See [2]. As far as I understand it, Interix/Microsoft Services for UNIX plugs directly into the POSIX whatever of Windows. What you basically get is the environment where you can run a shell, and as a sort of bonus a ksh or csh to start off. What Markus did, was to get normal Gentoo Prefix working on top of that. To give you an indication of what it looks/feels like, if you start SFU's ksh (or login through telnet -- hey it still is Windows ;) ), you can just do a configure && make && make install of bash-3.2 to end up with a working bash. Of course Python does NOT compile. > > Why do you want it to run on Cygwin? (Honest question...) > > It is the only project I know providing good support for POSIX Windows > platform while having Open Source license. I think in that sense Cygwin is more Open Source, because how you get the primary shell/environment is available too. However, for me that doesn't matter, as the OS itself is inherently non-free in that sense, so that's what you have to accept first thing anyway. > But if you are correct and a good POSIX layer is provided built-in in > Windows, I will be happy to see stage3 for Windows. Just for your information, we don't do stages at the moment, not in the forseeable future from my point of view either. Binpkgs are in the planning. In general we just do a full bootstrap, on Interix you need extra help from "prefix-launcher". > [1] http://www.interix.com/products_services.htm [2] http://technet.microsoft.com/en-us/library/bb463204.aspx?wt.svl=2007resources -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 30-04-2008 21:21:06 +0300, Alon Bar-Lev wrote: > On 4/30/08, Fabian Groffen <[EMAIL PROTECTED]> wrote: > > I think in that sense Cygwin is more Open Source, because how you get > > the primary shell/environment is available too. However, for me that > > doesn't matter, as the OS itself is inherently non-free in that sense, > > so that's what you have to accept first thing anyway. > > I separate operating system and applications... Just like you run on > HPUX or AIX... There is Windows. Ok, then SFU is just your entry point to the system, like your "login" on AIX or HPUX. > > Just for your information, we don't do stages at the moment, not in the > > forseeable future from my point of view either. Binpkgs are in the > > planning. In general we just do a full bootstrap, on Interix you need > > extra help from "prefix-launcher". > > This is sad... I would really like to see fully operating portage on > Windows... It was more important to me in the past when I actually > used this OS... Well... making stages takes time, but more importantly, requires you to store them somewhere, and infra has no space for that. I do, but my internet connectivity is not sufficient for that. Besides, using Portage's binary support is more flexible, as the Prefix isn't fixed, but adjusted to your need(s). > I this sense [1] was a great idea! You could always use quickpkg to > extract binaries. I probably misunderstand. quickpkg creates binpkgs, doesn't it? > [1] http://gentoocygwin.sourceforge.net/ -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-dev-announce] New developer: Jeremy Olexa (darkside)
On 05-05-2008 23:32:53 +0300, Petteri Räty wrote: > Another one bites the dust. It's my usual pleasure to introduce to your > Jeremy "darkside" Olexa from Minneapolis, USA. On IRC he goes with the nick > name darsiide because darkside is taken. Let's see if the current owner > gives it up after the thousand ping marker. Jeremy will be working on > bringing Gentoo/Alt:Prefix to machines that many have never heard of and > some want to forget like ia64-hpux. His main hobbies are flying small > airplanes and skydiving. I guess he must have crashed his head at some > point. LOL. Welcome to the team! -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On 07-05-2008 16:23:12 +0300, Mart Raudsepp wrote: > This is a plea and also a request for comments on the matter of > using .tar.lzma tarballs or not, and for what packages this is > acceptable and for what not. Just as a little background: GNU chose to switch from bzip2 to lzma, for it produces smaller files (less bandwith) and decompresses faster. They no longer provide the bzip2 versions of archives for newer releases IIRC, so it's either tar.gz or tar.lzma. > I'd be happy if some other unpacker is used than lzma-utils - one that > does not depend on libstdc++ - I'm sure it can be done, heck it's done > in integrated form in some other projects in less than a couple > kilobytes of code for the unpacking from a VFS. Meanwhile please > consider using the upstream provided .tar.gz tarballs instead and not > roll patchsets in .lzma just cause you can. See above why it might not just be "'cause you can". > coreutils and linux-headers come to my mind out of system packages right > now. I'm sure more dragons await me. m4, that one gave me some headaches, because lzma-utils required some eautoreconf, which introduced a nice cycle. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On 08-05-2008 21:45:00 +0300, Mart Raudsepp wrote: > d) too early adoption in critical system packages - once above issues > are solved, higher levels should be using it first, before critical > system packages (for example shows in the circular dep hell with m4) been there, done that. > e) It has been suggested the support should have been added with new > EAPI instead of local build deps (some of which are missing, for > instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format > net-tools doesn't have a dep in addition to using lzma for no good > reason) Chill, relax and cool down. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On 10-05-2008 03:32:08 -0400, Mike Frysinger wrote: > On Wednesday 07 May 2008, Fabian Groffen wrote: > > m4, that one gave me some headaches, because lzma-utils required some > > eautoreconf, which introduced a nice cycle. > > must have been a prefix-only bug as the version in the tree never did Ehmm... you're right. Sorry about that. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
On 29-05-2008 08:54:48 +0200, Rémi Cardona wrote: > Marius Mauch a écrit : >> So, do you think it should be enabled by default? > > Does portage have a way to report which libraries it is keeping around > because of preserve-libs ? If there's an easy way to figure that out, > then enabling it by default is a very sane and sound idea. It does so after every merge IIRC, and you can also find them in a file somewhere. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On 05-06-2008 02:35:16 -0700, Josh Saddler wrote: > Now that nominations are officially open, I nominate the current council > members (again): I nominate: dertobi123 fmccor -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
On 05-06-2008 22:47:28 -0700, Donnie Berkholz wrote: > On 14:52 Thu 05 Jun , Samuli Suominen wrote: > > # Samuli Suominen <[EMAIL PROTECTED]> (05 Jun 2008) > > # Masked for removal in ~30 days by treecleaners. > > # Replaced by USE libffi in sys-devel/gcc. Bug 163724. > > dev-libs/libffi > > dev-lang/squeak > > x11-libs/gtk-server > > The latest version of g-wrap (1.9.11) requires the external libffi > released a month or two ago, because it looks for the pkgconfig file > installed by that and not gcc: > > - libffi is no longer distributed with g-wrap, as it is available > as a stand-alone package now (instead of being burried in the > GCC sources). > > Thoughts? They might refer to this: http://sourceware.org/libffi/ which had a "recent" release (3.0.5). The libffi that's in our tree right now (3.4.3) is pretty old, matching GCC-3.4.3. It originally was used for GNUstep, but that package can also work with GCC's libffi, and ffcall these days. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 09-06-2008 11:49:35 +0200, Luca Barbato wrote: > Ciaran McCreesh wrote: >> On Mon, 09 Jun 2008 10:50:11 +0200 >> Luca Barbato <[EMAIL PROTECTED]> wrote: >>>> So how, specifically, is PMS "wrongly written", and why hasn't >>>> anyone who thinks so bothered to provide details? >>> - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. >> >> What technical reason is there to use a markup that's more work for >> those of us doing the writing? Writing XML is a huge pain in the ass >> compared to latex. > > More people can understand those markups, they are consistent with the > gentoo documentation, they look better on screen than on paper, tex is a > great typesetting markup to write academic books. Right tool for the > right task. It address the problem "PMS is anything but accessible" I think this is a bit of a pointless discussion. If people insist on reading the source and are scared of LaTeX, then the same can happen for any other language. PMS is available as pdf (or can easily being made by typing `make`), which is readable IMO, and one could always try how far one gets with a LaTeX->XML translator and XSLT transformations afterwards. Still, what is the point of requiring language X over Y? I for one prefer LaTeX over any of the formats you mentioned before, but that should not be of any value here. >>> - use EBNF when describing a syntax. >> >> Is there any indication that this is any clearer? EBNF gets messy when >> it comes to describing the whitespace rules, for example. > > It is less ambiguous than natural language. That solves the issue "The > syntax is underspecified" Perhaps some examples showing the syntax could improve the situation here? -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 11-06-2008 20:24:18 +0100, Roy Marples wrote: > On Wednesday 11 June 2008 19:00:16 David Leverton wrote: > > On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote: > > > David Leverton <[EMAIL PROTECTED]> wrote: > > > > Since at least one ebuild has already been modified specifically to > > > > work around the bug, I'd say it's pretty real. > > > > > > For those of us trying to play along at home, which one is this? > > > > http://tinyurl.com/4w4t69 > > Why the need for EAPI=1? > A cursory glance shows nothing unusual. slot deps -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Re-Defining team and herd
On 17-06-2008 09:54:46 +0200, Tiziano Müller wrote: > From the GLEP: > *snip* > The biggest differences to the current system are: > * A team is not implicitly defined as the people who maintain the packages > in a certain herd > * A herd is really only a logical unit of packages and may therefore _not_ > possess any ressources > * A team may maintain more than one herd (respectively the packages within > them) > *snip* While you're at redefining the terms `herd' and `team', I'd like your GLEP to address the maintenance issue as well. With teams being allowed to maintain a package, and the team being ``a denoted group of people'' you block out potential maintenance from others. With Gentoo being a project with some devs, of which many quite limited involved, I argue productivity for some of our devs is limited by the barrier of the ``maintainer''. Recently I've noticed that maintainer-needed and maintainer-wanted ebuilds are outlawed and hence can be maintained by anyone. In particular treecleaners seem to have started handling the trivial bugs on those packages, which I consider a positive movement. While maintainer-needed and maintainer-wanted have a negative taste, I feel they potentially aren't as negative as they sound. I think there are many more devs just wasting their time in IRC because none of ``their'' packages have ``solveable'' bugs. Dropping explicit maintenance for packages that are not critical (which are many IMO) would allow for a new ``team'' consisting of all of our bored devs that feel like harvesting the low hanging fruit by doing trivial version bumps, cleanups and trivial patches. In other words, I would like your proposal to: - make a difference between ``must be maintained'' packages (e.g. base-system) and the rest - for the non-critical packages define a group of ``experts'' that does not exclude ``foreign'' maintenance -- what if a herd is understaffed? - have a structure (e.g. time-out rule) that allows the ``experts'' to do full maintenance of their packages if they are active Your GLEP as it is now doesn't have any added value to me, as it seems only to change things into other terminology, more files, and cause an avalanche of other GLEPs without a clear rationale. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] dev-python/setuptools as RDEPEND
On 23-06-2008 15:21:31 -0700, Rob Cakebread wrote: > Just a quick note here in case you work on Python packages. > Recently repoman started warning that setuptools may be suspicious as an > RDEPEND. > > A lot of Python packages use another namespace that setuptools provides, > 'pkg_resources', for plugin systems so it may not appear obvious that > setuptools is an RDEPEND. > > I've updated the Python Developer's Guide[1] with info on how you can > easily determine if it's an RDEPEND or not. Why not remove the check from repoman, if it is a false positive in many cases? > [1] http://www.gentoo.org/proj/en/Python/developersguide.xml -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
On 24-06-2008 14:15:10 +0200, Arfrever Frehtes Taifersar Arahesis wrote: > I would like to suggest that default LDFLAGS in Gentoo contain the following > flags: "-Wl,-O1,--hash-style=gnu,--sort-common". > > -O1 enables some basic optimizations. > --hash-style=gnu causes that ld creates only new GNU-style hash tables. > --sort-common causes that ld sorts the common symbols by size when it places > them in the appropriate output sections. > > These options don't cause any problems, so they should be less controversial > than --as-needed. > (These options don't conflict with --as-needed, so --as-needed can be still > added to default LDFLAGS, but this thread isn't about --as-needed.) as long as it doesn't go in /base, but in the linux/freebsd profiles instead, it's fine with me. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
On 29-06-2008 07:29:57 -0400, Mike Frysinger wrote: > On Saturday 28 June 2008, Petteri Räty wrote: > > Arfrever Frehtes Taifersar Arahesis kirjoitti: > > > I would like to suggest that default LDFLAGS in Gentoo contain the > > > following flags: "-Wl,-O1,--hash-style=gnu,--sort-common". > > > > > > -O1 enables some basic optimizations. > > > > At least adding -O1 should not be problematic. I think vapier was > > already suggesting this quite a while ago. > > imo -Wl,-O1 should go into base I prefer not. Please only on profiles that use GNU binutils as linker. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
On 29-06-2008 20:28:39 -0700, Donnie Berkholz wrote: > On 23:15 Sun 29 Jun , Fabian Groffen wrote: > > On 29-06-2008 07:29:57 -0400, Mike Frysinger wrote: > > > On Saturday 28 June 2008, Petteri Räty wrote: > > > > Arfrever Frehtes Taifersar Arahesis kirjoitti: > > > > > I would like to suggest that default LDFLAGS in Gentoo contain the > > > > > following flags: "-Wl,-O1,--hash-style=gnu,--sort-common". > > > > > > > > > > -O1 enables some basic optimizations. > > > > > > > > At least adding -O1 should not be problematic. I think vapier was > > > > already suggesting this quite a while ago. > > > > > > imo -Wl,-O1 should go into base > > > > I prefer not. Please only on profiles that use GNU binutils as linker. > > That's the rule, not the exception, so I think that profiles with > non-gnu linkers should revert it. In the current world of gentoo-x86 it is the rule. But what will you do once Sun Studio becomes open source, and you want to allow people that like to have better performance to use it? What if Gentoo Prefix ever gets merged back into gentoo-x86? How can you easily revert it in a profile? Using strip-ldflags alike? That feels nasty to me. If it is trivial to remove it again, considering there may be more in LDFLAGS, then it is less of a problem to me. Maybe there is such a way, and I just missed it. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
On 30-06-2008 17:35:08 +0200, Arfrever Frehtes Taifersar Arahesis wrote: > > How can you easily revert it in a profile? > > You can set LDFLAGS="" in a subprofiles's make.defaults. How elegant... but I guess I'll have no choice. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [OT] ecd function
On 08-07-2008 19:59:05 +0200, Robert Buchholz wrote:
> You can avoid the issue with the license directory by appending a / at
> the end. Grobian showed me that a function is useful for this, I just
> do "ecd xorg-server"
>
> $ grep -A 3 ecd ~/.bashrc
> function ecd () {
> cd ~/devel/gentoo/gentoo-x86/*/$@/
> }
errr, just because my name is involved...
% alias ecd
cd $EPREFIX/usr/portage/*-*/!*
I have it as alias, not as function. If you have a function you can
(and should) actually do more magic, like:
ecd() {
[[ -z $1 ]] && return
p=( $(echo /usr/portage/*/$1) )
if [[ ${p[*]} == *"/*/"* ]] ; then
echo "no such package: $1" > /dev/stderr
elif [[ [EMAIL PROTECTED] > 1 ]] ; then
echo "multiple options: ${p[*]}"
else
# we can't handle spaces in the paths here anyway
cd ${p[*]}
fi
}
And probably this can be done even better with respect to the glob...
--
Fabian Groffen
Gentoo on a different level
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] wget abuse of sources.g.o must stop
On 11-07-2008 16:16:42 -0700, Robin H. Johnson wrote: > I was tracing into why sources.gentoo.org is so slow at times, and > gives errors, timeouts etc. I found that there is wget being used > against the site, with a lot of rapid-fire requests for the *checkout* > URLs - most often for entire directories. And very often, right when > wget is being used, the sources.g.o performance sucks badly. I just changed the prefix script "ecopy" to use anon cvs instead of wget. I have no clue how often the script is used, but I really hope not that often that it could cause the problems on sources.g.o. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On 15-07-2008 19:53:47 +0200, Rémi Cardona wrote: > Marius Mauch wrote: >> Potential problems: >> - might cause trouble for some packages that use custom code for >> unpacking, or due to circular deps, this could simply be solved with a >> new RESTRICT value though. > > As long as this is done to allow a 100% manual override, then this is a > _very_ good idea. Manual override as in "emerge --nodeps" or something. I have no examples at hand, but during bootstrapping I have more than often a problem with dependencies, which requires careful manual emerging of packages (often ignoring deps) because those deps cannot be compiled or emerged yet. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] LDFLAGS=-Wl,--hash-style=gnu
On 15-07-2008 15:32:32 -0400, Doug Goldstein wrote: > all, > > I'm at the point that -Wl,-O1 appears to be successful. It's time to > toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or > higher and not mips. So one solution is to put the following: > > default/linux: LDFLAGS="-Wl,-O1,--hash-style=gnu" > default/linux/mips: LDFLAGS="-Wl,-O1" > > However, this means we'll have to put a has_version check in > profile.bashrc of default/linux, which seems a bit cludgy.. > > Any suggestions? Comments? I'm just wondering... unless it has changed since last time I installed Gentoo Linux, but isn't the installation manual on purpose conservative with CFLAGS? make.conf.example also does not much more than "-march -O2 -pipe". -O1 to the linker feels conservative to me. Still, do we really need to go any further? Why not make additional pointers to possible values for LDFLAGS like we do for C(XX)FLAGS in the installation manual? -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
On 06-08-2008 14:18:05 -0700, Robin H. Johnson wrote: > Getting the bot out there > - > If you would like to have the new bot in your #gentoo-* channel, would > each channel founder/leader please respond to this thread, stating the > channel name, and that they are the contact for any problems/troubles. #gentoo-alt -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 26-08-2008 15:41:07 -0500, Yuri Vasilevski wrote: > On Tue, 26 Aug 2008 13:40:36 -0700 > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > > > I'm doing some research on our usages of the $Header$ keyword in our > > main CVS repo. > > > > Q: Are there any other use-cases you have and actively use? > > I use the revision present in the header to identify changes in > ebuild files that didn't needed a revision dump. I do exactly the same (or, eupdate is doing that) to keep the Prefix tree in sync with gentoo-x86. That is, I use the CVS Header to determine if a change has occurred, retrieve that diff, and apply the patch on my Prefix version of the same file (ebuild, ChangeLog, patch, eclass, ...). For that reason I'd pretty much prefer to keep the CVS Header in place, unless there is a very good reason to remove it. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 27-08-2008 10:28:57 -0700, Robin H. Johnson wrote: > On Wed, Aug 27, 2008 at 06:35:57PM +0200, Fabian Groffen wrote: > > For that reason I'd pretty much prefer to keep the CVS Header in place, > > unless there is a very good reason to remove it. > As I wrote in the other thread, my reason for asking is that it's one of > the things that doesn't have clear mapping in the Git world. As a side > benefit, getting rid of it also makes the double-commit mess go away. For who is it a mess? Not for repoman users, I suppose, and everyone should be using it, right? As the one who personally played with the code in repoman that determines whether or not the "double commit" is necessary, I think it's mostly a repoman internal problem. The commit script problems put aside. > For your use case, it should be possible to just ask Git for updates to > the given directory, and apply those to your own tree. Another VCS is another story. If we're switching, it would be nice if the notion of overlays shadowing the main tree would be taken into account. Especially since I don't think Prefix will "merge" any time soon, but we are plagued by the thing called "growth". -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 27-08-2008 11:57:30 -0700, Alec Warner wrote: > > For who is it a mess? Not for repoman users, I suppose, and everyone > > should be using it, right? As the one who personally played with the > > code in repoman that determines whether or not the "double commit" is > > necessary, I think it's mostly a repoman internal problem. The commit > > script problems put aside. > > So you are saying we should do what? > > precompute the CVS header and inject it into $header$ ourselves > take the checksums > generate the manifest > revert the $header$ change > then commit the ebuild and manifest at once > > ? > > The only reason we have double commits right now is that the $header$ > replacement is done by cvs at commit time so if we don't do two > commits the checksums all break due to the substitution..how is that > repoman's fault? It's not. But I don't see the problem (apart from a "race condition" with rsync generation) with the two commits either. Incidently the $Header: $ "feature" just helps me a lot at the moment to keep the Prefix tree up-to-date. Hence, I'm against switching them off or removing them as long as we use CVS for gentoo-x86. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 27-08-2008 12:15:35 -0700, Robin H. Johnson wrote: > For those not using SSH ControlMaster, one of the side-effects of having > to do two separate commits is the SSH setup latency hitting twice. > > I wouldn't call it repoman's fault like Fabian did, but the Right. I thought I suggested that "it" (the double-commit) is a mess for repoman. Not that it is repoman's fault. > double-commit is why I called it a mess. If we drop the $Header$ in any > file covered by a developer-generated Manifest, it becomes a single > commit with contents+Manifest :-). It seems that what you call "mess" means needing a double commit for a single "repoman commit". That to me isn't a mess, but a performance issue, and as I indicated a possible point of corruption. But we've dealt long enough with the situation without problems to ignore that point. But to repeat: - no I'm not against removing the $Header: $ stuff - yes I'd even like to use another VCS which can make my life easer - but, as long as we're on CVS, I'd prefer it when you'd keep my life sort of bearable - so, keep the $Header: $ stuff for Prefix' sake (me) as long as we're using CVS -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Preventing $ARCH flags in USE
On 15-09-2008 13:20:23 -0700, Zac Medico wrote: > > For future EAPIs, ARCH could be a regular USE_EXPANDed flag as you > > suggest, and package managers could filter any flag in USE which is > > not listed in IUSE. > > While I don't necessarily disagree with you, my impression is that > most people tend to think that certain profile-specific flags such > as userland_* and kernel_* should be considered as implicit members > of IUSE and therefore they shouldn't be explicitly listed in in IUSE. Yes, IMO mainly because they should never explicitly be set by users, so they shouldn't get a hint they can set it either. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: Request for feedback on GNU Patch change
On 17-09-2008 09:59:42 +0200, "C. Bergström" wrote: >> Why not simply alias patch=gpatch in profile.bashrc? >> See the FreeBSD profile for an example. >> > I'd like to package portage for OpenSolaris and have it just drop-in > work so modifications like what you suggest wouldn't be required. > Hopefully, base-system maintainers don't mind my request, but I can > understand it's beyond the Linux use case. As I understood it, you want to package (Prefix) Portage for (Open)Solaris, but without USERLAND=GNU like Gentoo Prefix does. You want all eclasses, ebuilds and portage itself to work with the Solaris userland tools. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: Request for feedback on GNU Patch change
On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote: > >> Why not simply alias patch=gpatch in profile.bashrc? > >> See the FreeBSD profile for an example. > >> > > > > I'd like to package portage for OpenSolaris and have it just drop-in work so > > modifications like what you suggest wouldn't be required. > > You'd still need to create an OpenSolaris profile. While you're at it, > you can create a profile.bashrc with the required modifications. > > I don't see any reason to not do the gpatch change, but it looks like > unecessary to me because you already have simpler ways to solve the > problem. So, requiring others to do a significant useless amount of > work when you can solve it with just a line is not fair. >From some experience, I can tell that an alias is not sufficient to cover all cases, and will result in random failures because you only notice too late patch is used and not gpatch. By the way, I'm against this stuff. I rather see a PATH solution involved. Portage already has a DEFAULT_PATH, and if someone refuses to install patch, one could always use a special directory with symlinks to the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that Portage/eclass/ebuilds don't have to bother about this at all. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: Request for feedback on GNU Patch change
On 17-09-2008 10:41:07 +0200, "C. Bergström" wrote: >> By the way, I'm against this stuff. I rather see a PATH solution >> involved. Portage already has a DEFAULT_PATH, and if someone refuses to >> install patch, one could always use a special directory with symlinks to >> the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that >> Portage/eclass/ebuilds don't have to bother about this at all. >> > patch is installed and I would agree with you, but in certain > circumstances using the GNU tools are broken. Then if that is the case, Portage/eclass/ebuild relies on that brokenness. I'm not saying you should have the same PATH as Portage. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
On 21-09-2008 02:47:41 +0200, Thomas Sachau wrote:
> updated version:
> if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
> emake DESTDIR="${D}" install || einstall
> if [[ $?>0 ]]; then
Please either use POSIX or bash, mixing them looks so ugly and pointless
to me.
Apart from that I don't think calling einstall when emake install fails
makes sense. Ideally einstall should never be used IMO.
--
Fabian Groffen
Gentoo on a different level
[gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI
Hi all, The Prefix team has a separate Portage branch which implements the "prefix" extensions. In short, this encompasses the addition of the variables EPREFIX, ED and EROOT, and the function eprefixify to the ebuild/eclass environment, which may be used to make an ebuild work for a given prefix offset. I would like to get some input on how best to deal with these additions in the light of EAPI and the main (gentoo-x86) tree and Portage. Since the Prefix extensions can currently be applied on top of any existing EAPI, they are not requiring any special EAPI value as baseline. Currently in Prefix we implemented EAPI as being a set of tokens that are orthogonal to each other. In other words, while 0, 1 and 2 are mutual exclusive, "prefix" can be applied to 0, 1, or 2. The result is something like EAPI="prefix 1". Of course with this approach the recent introduction of EAPI=2, resulted in a problem with eclasses that do a blind check on the EAPI variable to be e.g. 2. An alternative is to create multiple new EAPIs, such as prefix-1 or 1-prefix, containing the Prefix extensions on top of EAPI=1. Same problem when checks on EAPI are done of course, but EAPI then always consists of a single value. Something that was raised in previous discussions was that maybe the Prefix extensions don't need an EAPI in itself, but that an ebuild has to be marked as Prefix-ready through e.g. the recently proposed PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be added variable. Please discuss. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms
Hi all, In the Prefix project we support a bunch of Linux and non-Linux platforms, for which we use GLEP53-style[1] keywords. The current list of keywords known in Prefix are (in no particular order): ppc-aix x86-freebsd ia64-hpux hppa-hpux x86-interix mips-irix amd64-linux x86-linux ppc-macos x86-macos x86-netbsd ppc-openbsd x86-openbsd x64-openbsd sparc-solaris sparc64-solaris x64-solaris x86-solaris x86-winnt Most notably, in Prefix all keywords are full GLEP53 style, which results in e.g. amd64-linux. We did this on purpose, because in Prefix we don't necessarily are on Gentoo Linux. We also chose to expand fbsd, nbsd and obsd to their long variants, mainly because the short variants might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD, polyBSD or DragonflyBSD, DesktopBSD. (At some point we were a bit over-enthausiastic.) I would like to hear some opinions on the keywords in general, as well as the particular problem of having Gentoo Linux, and a Linux supported by Gentoo Prefix. Right now there is just the difference of "-linux" appended, however this is not the clearest distinction between the two. Perhaps using KEYWORDS for Prefix keywords is not the best thing to do, and should we use something like PREFIX_KEYWORDS? [1] http://www.gentoo.org/proj/en/glep/glep-0053.html -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI
On 09-10-2008 19:15:26 +0100, Ciaran McCreesh wrote: > On Thu, 9 Oct 2008 19:46:55 +0200 > Fabian Groffen <[EMAIL PROTECTED]> wrote: > > Currently in Prefix we implemented EAPI as being a set of tokens that > > are orthogonal to each other. In other words, while 0, 1 and 2 are > > mutual exclusive, "prefix" can be applied to 0, 1, or 2. The result > > is something like EAPI="prefix 1". Of course with this approach the > > recent introduction of EAPI=2, resulted in a problem with eclasses > > that do a blind check on the EAPI variable to be e.g. 2. > > EAPI's defined as being a single value because mixing between EAPIs is > in general impossible. For example, I'm guessing prefix might need to > do something to econf / the default src_compile/configure functions at > some point, so it's not really truly independent. While that is true, currently Prefix is designed in such a way that an empty offset results in a fully "backwards" compatible Portage. > Is there anything stopping you from formalising your specification of > what you need? (The PMS team can probably help with the 'writing formal' > bit if necessary, given an informal description.) Could it be done in > such a way that non-prefix package managers can do minimal support to > get the current /usr behaviour, whilst optionally implementing > everything else? If this is the case, the best route's probably to get > the whole thing into the next EAPI, start using that EAPI for all your > overlay packages and persuade people to include the necessary prefixy > things in main-tree eclasses (which they should, once said EAPI is > Council approved). A problem I have with requiring a "next" EAPI for each ebuild, is that Prefix requires all base-system ebuilds to be "Prefix compatible". However, this category of ebuilds requires being conservative with EAPI requirements. I once started on an attempt to document the stuff[1], but it's pretty verbose, and it misses the necessary informal definitions of in particular chapter [2]. > > Something that was raised in previous discussions was that maybe the > > Prefix extensions don't need an EAPI in itself, but that an ebuild has > > to be marked as Prefix-ready through e.g. the recently proposed > > PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be > > added variable. > > What's the scope of the changes? I think it'd be easiest to discuss > this if you posted an informal summary describing the differences in > terms of which bits of PMS are affected. [2] sums it up for as much as I can recall for the moment, the non-privileged stuff is supposed to be separate, but its use is inherently related to offset installations. Our overlay[3] contains enough material to get an idea of what it looks like in practise. If you want specific pointers, I can give you them. [1] http://dev.gentoo.org/~grobian/gleps/glep-prefix.html [2] http://dev.gentoo.org/~grobian/gleps/glep-prefix.html#ebuild-changes-in-prefix [3] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On 10-10-2008 04:21:23 +0200, Marius Mauch wrote: > > >> amd64-linux > > >> x64-openbsd > > >> x64-solaris > > > > > > Is there a special reason why you're using "x64" instead of "amd64" > > > in those cases? (IMO x64 is the most stupid name for the x86_64 > > > architecture) > > > > AFAIK, that's not amd64/x86_64, but rather ia64, aka itanic aka > > itanium. At least, that's how I'd interpret them since I've seen that > > abbreviation made before, particularly since there's already amd64 in > > context. > > No, x64 is the marketing name Microsoft made up for x86_64 (aka amd64, > ia32e and Intel 64), as "Windows for x86_64" doesn't sound that sexy, > and was later adopted by Sun and others. > ia64/Itanium doesn't have any other alias names AFAIK. We simply found that: - amd64 is misleading - em64t would be more to the point for some? - x64 is what the vendors (Apple, Sun) advertise themselves - amd64 doesn't make any sense for a Mac - x64 is more like x86, whereas the complement of amd64 would more be i386 or ia32, but we wanted to avoid x86_64, x8664, so x64 - we were changing keywords anyway -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On 10-10-2008 14:40:13 +0200, Diego 'Flameeyes' Pettenò wrote: > Fabian Groffen <[EMAIL PROTECTED]> writes: > > > - x64 is what the vendors (Apple, Sun) advertise themselves > > Err I'm sure I haven't seen any x64 in the documentation or > advertisement of my MacBook Pro, are you sure _Apple_ uses that totally > bogus name? Ehm, no. So I must have been confused. > Anyway, em64t might be better, but then again you're to the same point: > an Opteron using an Intel name? I think amd64 is totally fine since it's > the first commercial name it got by uh, those who introduced it, I > guess, but the only thing I don't ever want to see officially is > endorsing the x64 commercial speak. Whatever. Some of you seem to have some quite agressive dislikement to it. In the end it's just a name/tag. I guess I could live with anything, including c3p0. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
> On Mon, 13 Oct 2008 06:16:01 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
> > Unless someone can say what using PROPERTIES=prefix would break, I'd
> > go with that. It's a /classic/ usage of that variable, as it's simply
> > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
> > support it. It'd be great to see the prefix branch finally merged so
> > we all get to play with it.
>
> It would break. Prefix ebuilds won't work unless ED is set, and a non
> PROPERTIES aware or non-prefix-property aware package manager won't set
> ED. Unless prefix is reimplemented to require no package manager
> changes for the install to / case, PROPERTIES is out.
Just to comment on this possibility; I see an option, given the
definition of ED and EROOT to do Prefix without them, by e.g. using
${D}${EPREFIX} instead of ${ED} as shorthand. When ${EPREFIX} would be
unset, this would result in simple ${D}, which is "backwards
compatible". This is not all what is necessary, but a big deal of it.
Question here, however, is whether this is worth it. Personally, I
prefer the shorthands, as they give a lot of readability.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] bison/flex extra runtime packages
On 16-10-2008 09:27:29 +0200, Duft Markus wrote: > Now some package of mine in a local overlay requires bison and flex. > It's quite hard to get those to build _and_ work on winnt, so I though > about splitting the bison ebuilds in dev-util/bison and > dev-libs/bison-runtime (and the same for flex). What do you think about > this? Before we started using portage at our company I built the > runtimes only for winnt, so I know this works (for me)... Not sure if I understand correctly, but if you're aiming for dev-libs/bison-bin, then I prefer to keep on using an overlay for winnt. It's too evasive, IMO. We can just create a new overlay either in gentoo-alt or a new top-level one on overlays.g.o. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On 21-10-2008 16:09:12 +0200, Tiziano Müller wrote:
> > As "Gentoo Solaris" would not be the same as "Gentoo Prefix on Solaris",
> > it should not share the *-solaris keywords used for Prefix via the same
> > KEYWORDS-setting.
> what about a new generic schema like: CPU-OS[-prefix] with the possibility
> of shell expansion in KEYWORDS to have something like this:
> KEYWORDS="{x86,sparc}-linux" or KEYWORDS="linux: x86 sparc ppc freebsd: x86
> sparc solaris-prefix: sparc" ?
Such thing sort of solve the problem with multi-line keywords, but might
complicate matters which do not justify the cosmetic advantage?
Having prefix as tag in a keyword isn't such a bad idea, perhaps, since
one should really see them as separate from non-prefixed in certain
cases. So far we just solved problems via the profiles or newly
introduced prefix? conditionals.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
On 26-10-2008 14:53:55 -0700, Robin H. Johnson wrote: > Willikins was not in the following channels, as nobody requested it here yet. > ... > #gentoo-osx ... > > Solar has requested that the bot joins the channels now, so if you have > complaints instead, please note them here. channel is dead for a long time, so no benefit of joining it. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> + # If this is a non-ELF system, chances are good that the .la files will
> be needed.
> + if type -P scanelf &> /dev/null
I think this is a not so cool way to check for an ELF system.
> + then
> + debug-print "Scanelf found, proceeding..."
> + ebegin "Removing useless .la files"
> + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec
> rm -f '{}' '+'
> + eend 0
> + else
> + debug-print "scanelf not found, this appears to be a non-ELF
> system."
> + debug-print "non-ELF systems are likely to need .la files."
> + debug-print ".la files not removed from ${TARGET}"
rationale?
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 18:34:31 +0200, Peter Alfredsen wrote:
> On Sunday 09 November 2008, Fabian Groffen wrote:
> > On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> > > + # If this is a non-ELF system, chances are good that the .la
> > > files will be needed. + if type -P scanelf &> /dev/null
> >
> > I think this is a not so cool way to check for an ELF system.
>
> Indeed, I think it's a horrid way. Please find a better one.
% uname -a
Darwin tefnut.cheops.ods.org 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
PowerMac8,2 Darwin
% scanelf --version
pax-utils-0.1.18_pre0004: scanelf.c compiled Oct 19 2008
$Id: scanelf.c,v 1.194 2008/09/29 06:05:55 vapier Exp $
scanelf written for Gentoo by
% scanmacho --version
pax-utils-0.1.18_pre0004: scanmacho.c compiled Oct 19 2008
$Id: scanmacho.c,v 1.5 2008/10/19 18:11:59 grobian Exp $
scanmacho written for Gentoo by
You could identify ELF a bit more reliable by running file on e.g.
"${ROOT}/bin/bash", or just by building a list of CHOSTs that you know
are ELF systems.
> > > + debug-print "scanelf not found, this appears to be a non-ELF
> > > system." +debug-print "non-ELF systems are likely to need
> > > .la
> > > files." + debug-print ".la files not removed from ${TARGET}"
> >
> > rationale?
>
> "I've been told" that .la files are really only needed on non-ELF
> systems and with plugin systems that use dlopen. I actually have no way
> of knowing that the .la files are needed on those arches, but I had
> your archs in mind when doing the patch.
Ok. What worries me though is that this would result in some systems
having libtool files whereas the majority does not. E.g. removing them
apparently fixes a problem that then crops up on those systems or
something. Can't think of any atm.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 19:46:12 +0200, Peter Alfredsen wrote:
> > Ok. What worries me though is that this would result in some systems
> > having libtool files whereas the majority does not. E.g. removing
> > them apparently fixes a problem that then crops up on those systems
> > or something. Can't think of any atm.
>
> I can. If you have .la files, you will need to revdep-rebuild a lot
> more. But c'est la vie.
I meant I can't think of an issue when there is no .la file.
> --- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
> +++ eutils1.eclass2008-11-09 18:26:44.0 +0100
> @@ -1805,5 +1805,37 @@
> ) || die
> else
> newbin "${tmpwrapper}" "${wrapper}" || die
> fi
> }
> +
> +# @FUNCTION: epunt_la_files
> +# @USAGE: [dir to scan]
> +# @DESCRIPTION:
> +# .la files can cause many unpleasantries when they disappear,
> +# forcing rebuilds of seemingly unrelated packages.
> +# This function removes the .la files from [dir to scan], "${D}" if not set.
> +# A good time to start punting .la files may be when a .so bump happens,
> +# so dependent packages do not have to be rebuilt twice.
> +#
> +# See also:
> +# bug 245889
> +#
> http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
> +
> +epunt_la_files() {
> + debug-print-function $FUNCNAME "$@"
> + local TARGET=$1
> + [ -z "${TARGET}" ] && TARGET="${D}"
> +
> + # If this is a non-ELF system, chances are good that the .la files will
> be needed.
> + if [[ "$(file ${ROOT}/bin/bash)" =~ " ELF " ]]
> + then
> + debug-print "ELF system found, proceeding..."
> + ebegin "Removing useless .la files"
> + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec
> rm -f '{}' '+'
> + eend 0
> + else
> + debug-print "This appears to be a non-ELF system."
> + debug-print "non-ELF systems are likely to need .la files."
> + debug-print ".la files not removed from ${TARGET}"
> + fi
> +}
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Re: bash version in ebuilds/eclasses...non-compliance and what to do?
On 20-12-2008 05:35:25 +, Steve Long wrote: > I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 > lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 > requires at least that version (only unstable on mips as against 2.1.1-r2) > It might be worth skipping to 3.2, since that would simplify regex handling. The only problem we have there is that bash-3.2.17 only comes in patches on top of 3.2. During bootstrap that's problematic, as gnu patch (or any other patch) might not be available, or simply b0rked. For that reason we bootstrap with a portage pre SVN revision 10460, which does not require >=3.2.17. See http://bugs.gentoo.org/show_bug.cgi?id=229677#c11 on why PMS should require 3.2.17 over plain 3.2 if you decide to push the requirement update. We can work around it by using a self-made pre-patched tarball, though. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
On 10-03-2009 13:15:36 +0100, Thilo Bangert wrote: > > Bugs aren't a good way to keep in touch with developers, that's what > > irc is for. > > while i dont necessarily think, that bugzi is the best way to stay in > contact with me, it surely is a better way than IRC - on which i am close > to never. > > the presumption seems to be, that as a dev one has to be available via > IRC. it has long been my feeling that Gentoo as a project could realize > more of its potential by better integrating people who dont do IRC. +1 -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [amd64-fbsd] remove charset.alias
On 11-03-2009 09:56:18 -0400, Mike Frysinger wrote:
> On Wednesday 11 March 2009 09:16:29 Timothy Redaelli wrote:
> > I'm creating the amd64 porting of Gentoo/FreeBSD (with multilib support).
> >
> > The problem is that some [1] ebuilds removes
> > directly "${D}"/usr/lib/charset.alias and
> > not "${D}"/usr/$(get_libdir)/charset.alias.
> >
> > May i fix all the packages or should I open a bug for every one?
>
> no. considering you're on the BSD alias, i would have thought you'd be
> seeing
> the bugs that go through them. refer to Bug 256129. so the profile needs
> fixing.
>
> as for the ebuilds, those lines should be dropped completely. ive been
> dropping them in newer versions of the packages rather than going back and
> deleting them all by hand ...
Aha, that explains why this recently started popping up for me and my
too many weird platforms. I guess this means all Prefix profiles should
have this rm code in place... :(
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 23-03-2009 11:41:08 +0100, Sebastian Pipping wrote:
> People split into three groups:
>
> - Friends of ${P}-fix-issue.patch naming
> - Friends of ${PN}-fix-issue.patch naming
> - Friends of ${PN}-1.2.3-fix-issue.patch naming
>
> Qualities
[snip]
I think what's missing is the following observation:
${PN}-fix-issue.patch naming is bad if you patch code that is (likely)
to change in newer releases. This is almost always the case. Ultimate
example, patch something in ffmpeg or mplayer, and the next snapshot
will break the patch. (i.e. doesn't apply any more.) Using
${PN}-fix-issue.patch in this case gets you into
${PN}-fix-issue-2.patch, which IMO is ugly.
If patches are named this way, they probably fall in the case where the
code it patches is unlikely to change. (assumption)
> Possible solutions
>
> - *Communicating* your likes to all co-maintainers
> in hope the will respect and remember your agreement
>
> - Add a related local comment (*documenting*) to ebuilds
> and expect other developers to act accordingly on a bump
probably best solution
> - Making a GLEP *enforcing* on of these and make people
> vote on which
very bad one.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] EAPI 3 PMS Draft
On 16-03-2009 20:47:17 +, Ciaran McCreesh wrote:
> I've got a very rough draft of what EAPI 3 might end up looking like,
> based upon discussion:
>
> http://github.com/ciaranm/pms/tree/eapi-3
I would like to request the following to be included in EAPI 3, as
preparation for more Prefix friendly ebuilds compatible with gentoo-x86:
- The variable EPREFIX to be set in all phases, and at all times.
Because this is a preparation stage, EPREFIX is just set and
intialised to the empty string.
- The variable ED, available in src_install, pkg_preinst and
pkg_postinst, and set to ${D}${EPREFIX}.
- The variable EROOT, available in pkg_*[1], set to ${ROOT}${EPREFIX}.
[1] this is copied from PMS, Table 11.1, in general, EROOT needs to be
available where currently ROOT is.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: portability.eclass
On 27-03-2009 01:34:36 +0100, Donnie Berkholz wrote:
> > + # - Linux needs -ldl
> > + if [[ ${CHOST} == *-linux-gnu ]]; then
> > echo "-ldl"
>
> How about uclibc?
Good catch, thanks for pointing out. And thanks drizzt for fixing it
before I could ;)
--
Fabian Groffen
Gentoo on a different level
[gentoo-dev] Please review: prefix.eclass
Hi,
This eclass facilitates in some of the needs of the Gentoo Prefix
project. For now it provides the 'eprefixify' function, which is
often used in Gentoo Prefix ebuilds to incorporate the used offset
prefix into files.
Next to this, the eclass sets the EPREFIX to the empty string, if unset.
Ideally we would have liked to set EROOT and ED, based on ROOT and D,
but since the latter variables need not to be available when the eclass
is sourced, EROOT and ED (which both consist of the E-less variable +
EPREFIX) might get set wrongly.
This eclass brings Gentoo Prefix ebuilds one step closer to gentoo-x86
ebuilds.
Please review.
--
Fabian Groffen
Gentoo on a different level
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id: prefix.eclass 40407 2009-03-27 11:51:37Z grobian $
# @ECLASS: prefix.eclass
# @MAINTAINER:
# Feel free to contact the Prefix team through if
# you have problems, suggestions or questions.
# @BLURB: Eclass to provide Prefix functionality
# @DESCRIPTION:
# Gentoo Prefix allows users to install into a self defined offset
# located somewhere in the filesystem. Prefix ebuilds require
# additional functions and variables which are defined by this eclass.
# @ECLASS-VARIABLE: EPREFIX
# @DESCRIPTION:
# The offset prefix of a Gentoo Prefix installation. When Gentoo Prefix
# is not used, ${EPREFIX} should be "". Prefix Portage sets EPREFIX,
# hence this eclass has nothing to do here in that case.
# Note that setting EPREFIX in the environment with Prefix Portage sets
# Portage into cross-prefix mode.
if [[ -z ${EPREFIX} ]]; then
export EPREFIX=''
fi
# @FUNCTION: eprefixify
# @USAGE:
# @DESCRIPTION:
# replaces @GENTOO_PORTAGE_EPREFIX@ with ${EPREFIX} for the given files,
# dies if no arguments are given, a file does not exist, or changing a
# file failed.
eprefixify() {
[[ $# -lt 1 ]] && die "at least one argument needed"
einfo "Adjusting to prefix"
for x in "$@" ; do
if [[ -e ${x} ]] ; then
ebegin " ${x##*/}"
sed -i -e "s|@GENTOO_PORTAGE_EPREFIX@|${EPREFIX}|g"
"${x}"
r=$?
eend ${r}
[[ ${r} != 0 ]] && die "failed to eprefixify ${x}"
else
die "${x} does not exist"
fi
done
return 0
}
# vim: tw=72:
Re: [gentoo-dev] Please review: prefix.eclass
On 27-03-2009 13:08:46 +0100, Ulrich Mueller wrote:
> >>>>> On Fri, 27 Mar 2009, Fabian Groffen wrote:
>
> > Please review.
>
> >r=$?
> >eend ${r}
> >[[ ${r} != 0 ]] && die "failed to eprefixify ${x}"
>
> Here you could save a variable, since eend returns the status:
it wasn't even declared local, so double FAIL.
> eend $? || die "failed to eprefixify ${x}"
Applied, thanks!
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On 01-04-2009 05:30:01 +, Mike Frysinger wrote:
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know ! Simply reply to this e-mail for the whole
> Gentoo dev list to see.
I would like the council to discuss the addition of three variables to
EAPI3.
- EPREFIX
The offset prefix of a Gentoo Prefix installation. When Gentoo Prefix
is not used, ${EPREFIX} should be "".
This variable should be available everywhere.
- EROOT
The offset prefix appended to ${ROOT}, e.g. ${ROOT%/}${EPREFIX}/
This variable is available where ROOT is, following PMS: pkg_*
- ED
The offset prefix appended to ${D}, e.g. ${D%/}${EPREFIX}/
This variable is available where D is, following PMS: src_install
While the first variable (EPREFIX) can be set using an eclass, the
latter two need to be set by the package manager. In particular ED,
because the value of D might not be known. EROOT and ED are convenience
variables. Making them available already now, even though initialised
as ROOT and D respectively, allows Prefix enabled ebuilds to be shared
between gentoo-x86 and Prefix trees without modifications.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 13:23:24 +0300, Petteri Räty wrote: > > > > However, we have toyed with other ideas. One of which is to introduce > > IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I > > don't really like this idea because it exposes the use flag and we > > don't want it exposed to the users. > > > > If you don't want it exposed to users, then use a USE_EXPAND variable. > Like zmedico said in EAPI 3 a normal use flag could be hidden but > probably better to not have to migrate everything with prefix support to > EAPI 3. Out of the existing USE_EXPAND variables USERLAND makes most > sense to me but we could also introduce a new one too. USE_EXPAND does something like: USERLAND="GNU" -> userland_GNU For Prefix, we just need the "prefix" USE-flag (not prefix_XXX), hence USE_EXPAND doesn't help us. Adding "prefix" to use.mask (and use.force in Prefix profiles) allows us to get the desired behaviour. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 14:54:20 +0300, Petteri Räty wrote: > Fabian Groffen wrote: > > On 04-04-2009 14:31:20 +0300, Petteri Räty wrote: > >> If prefix is in USERLAND then you have a userland_prefix use flag to use > >> that can be hidden. > > > > It is not. > > But can be added. I think we talk about different things here. "prefix" is not a "USERLAND". In Prefix, USERLAND=GNU. Neither do I think a something_prefix (use-expanded "SOMETHING") is a useful approach. You're either using Prefix, or you don't. Hence, "use prefix". Jeremy's question was about how to effectuate that, and we believe simply adding "prefix" to use.mask (and use.desc) in gentoo-x86 is the solution. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 14:31:20 +0300, Petteri Räty wrote: > If prefix is in USERLAND then you have a userland_prefix use flag to use > that can be hidden. It is not. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 15:21:23 +0300, Petteri Räty wrote: > You can set USERLAND="GNU PREFIX" Prefix is not a userland, please understand that. It's like pizza not being an elibc, or beer not being a kernel. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 14:22:09 +0200, Rémi Cardona wrote: > Le 03/04/2009 16:47, Jeremy Olexa a écrit : > > However, we have toyed with other ideas. One of which is to introduce > > IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I > > don't really like this idea because it exposes the use flag and we > > don't want it exposed to the users. > > Just of curiosity, with IUSE=prefix, how many packages would get the USE > flag? > > If we're only talking about a few packages, I don't mind it showing up > in portage. If anything, it'll help spread the word about Prefix :) It's more that you cannot sensibly set USE=prefix yourself, neither should you be suggested or encouraged to do so, hence it should never show up in Portage's pretend output. It's like Portage suggesting you that you can set ARCH or KERNEL to some other value yourself, and that if you emerge -e or something you can upgrade Linux to FreeBSD or x86 to ppc. While this would be great, it doesn't work. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 12:24:32 -0700, Zac Medico wrote: > > Sure it's not a user land like GNU or BSD but I can't see why we > > couldn't change what USERLAND means. > > But why change the meaning if it's confusing an unnecessary? > Perhaps it's more appropriate to set IUSE_IMPLICIT="prefix". This sounds like a good thing to make it explicit prefix is an implicit USE-flag. However, I would still prefer to see prefix being masked in base, and then unmasked and forced in the prefix profiles. Does that make any sense? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 20:41:34 +0100, Ciaran McCreesh wrote: > The two aren't mutually contradictory. Quite the contrary. > > For EAPI 3, we're aiming to make it illegal to do anything with a flag > unless it's either explicitly listed in IUSE or handled via a number of > special magic profile variables, so you'd either have to list it > everywhere or use one of the profile variables. Once you do that, how > you mask / force it is up to you, unless you need some kind of special > package manager handling for that flag. Sounds to me it would be ok then to add it now in use.mask, and then EAPI 3 is done, define it in whatever special variable it needs to be added to according to the specs then. IUSE_IMPLICIT -- assuming it can be defined in the profiles -- seems like a good way to prepare for that, since it makes explicit it is implicit, IMO. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On 04-04-2009 18:49:50 -0600, Ryan Hill wrote:
> > + # killing these two on OSX/Intel will disable SSE, resulting in failing
> > + # compilations, as the headers expect SSE to be enabled (Apple knows
> > what
> > + # hardware they run on afterall, don't they?)
> > + [[ ${CHOST} == i?86-apple-darwin* ]] \
> > + && ALLOWED_FLAGS="${ALLOWED_FLAGS} -march=prescott
> > -march=nocona"
> >
>
> Why do these have to be specifically included? Aren't they handed by
>
> 34 export ALLOWED_FLAGS="${ALLOWED_FLAGS} -O -O0 -O1 -O2 -mcpu
> -march -mtune"
Looking at the current code, it can't even work properly. Even in the
case when ALLOWED_FLAGS is already set.
if [[ -z ${ALLOWED_FLAGS} ]] ; then
export ALLOWED_FLAGS="-pipe"
export ALLOWED_FLAGS="${ALLOWED_FLAGS} -O -O0 -O1 -O2
-mcpu -march"
Weird enough, it /did/ enable compilations to succeed in the past, but
it just can't in the current eclass, so it's bogus, and I will remove it
again.
Thanks for the check, much appreciated!
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: toolchain-funcs.eclass
On 04-04-2009 23:53:29 -0400, Mike Frysinger wrote: > On Saturday 04 April 2009 13:17:56 Fabian Groffen (grobian) wrote: > > grobian 09/04/04 17:17:56 > > > > Modified: toolchain-funcs.eclass > > Log: > > Add support for all Prefix arches, in particular for gen_usr_ld_script, > > and add AIX specific function, backport from Prefix > > you really should have posted this to the toolchain alias before committing. > and done a whitespace check as there's incorrect mixing of leading > spaces/tabs, as well as trailing whitespace. I reverted the entire commit and will submit to toolchain after dealing with your comments. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Ciaran, On 02-04-2009 15:47:05 +0100, Ciaran McCreesh wrote: > On Thu, 2 Apr 2009 11:53:47 +0200 > Fabian Groffen wrote: >> While the first variable (EPREFIX) can be set using an eclass, the >> latter two need to be set by the package manager. In particular ED, >> because the value of D might not be known. EROOT and ED are >> convenience variables. Making them available already now, even >> though initialised as ROOT and D respectively, allows Prefix enabled >> ebuilds to be shared between gentoo-x86 and Prefix trees without >> modifications. > > Why not just do it properly? Come up with a full list of requirements, > propose a full solution, open it up for feedback and adapt it as > necessary. Then just move the whole thing into a future EAPI. Recently we changed our approach from being a new EAPI into blending into any existing EAPI. We can do this, since Prefix is orthogonal to any existing EAPI to date. The mentioned variables simply make life easier, but are not strictly necessary. Unfortunately we can't set them from an eclass, so we need help from the package manager for them. > My worry is we'll end up with more legacy mess that package managers > will have to carry on supporting indefinitely, but that won't be used > by anything once prefix goes through the necessary changes to make it > mainstream. Limiting Gentoo Prefix ebuilds to a future EAPI will not be acceptable with regards to system packages and we will still have a crappy overlay for a long multi-year period. The fact is, Prefix ebuilds can be used regardless of EAPI in use. We used to do EAPI="prefix <#>" but that was way too much maintance overhead and just recently EAPI=prefix has been killed in favour of full compatability. You seem to suggest there are issues, do you have any specific concerns that we can address? -- Fabian Groffen Gentoo on a different level
[gentoo-dev] An Introduction to Gentoo Prefix
resources for maintaining the fork, but also keeps a lot of work outside of the mainstream Gentoo infrastructure. As Prefix team, we feel that the current shape of the Gentoo Prefix implementation is mature. That is, it has been proven to be useful for a number of users/scenarios, and it has been able to work for a substantial number of different systems, without having to change the core part. Therefore, we plan to focus on merging back the many patches and extensions from our Prefix overlay into the Gentoo mainline tree. For us, this roadmap looks as follows: 1) get the prefix USE-flag masked in profiles/base We use a special USE-flag 'prefix' to conditionalise actions in ebuilds and eclasses that really depend on being in an offset installation or not. Obviously, this flag should be disabled in normal profiles. 2) move the prefix profiles to the mainline tree The Prefix project maintains a profiles/prefix directory with Gentoo Prefix specific profiles. They inherit from base, and in the Linux case even from the default/linux profiles. 3) add prefix-only ebuilds to the mainline tree Gentoo Prefix has different systems, which sometimes need different packages. Specialised ebuilds now live in the Prefix tree only. 4) file bugs for eclass changes to their maintainers Like ebuilds, eclasses need changes to work properly using an offset installation. These changes are usually related to dealing with the offset prefix, but sometimes also add specialised support for the Prefix architectures. 5) bring back trivial patches Different systems bring different compile or installation problems. These patches can be trivial, and hence non-intrusive. We like to move those patches to the Gentoo mainline tree. 6) solve complicated ebuild changes For a number of ebuilds, mostly for the toolchain, a set of extensive patches are applied in the Prefix tree. While our changes are mostly designed to be backwards compatible, we prefer to get them reviewed by the respective maintainers and get them merged with their blessings. 7) merging prefix branch of Portage into trunk Prefix Portage currently lives in its own branch of the Portage sources. With an empty offset string, Prefix Portage is equal in behaviour to trunk sources. We would like to merge the Prefix branch with trunk and have a release, instead of keeping the branch and adding a Prefix Portage ebuild. 8) add prefix bits to ebuilds Prefix involves some variables which need to be used in ebuilds to make them offset-aware. Often this is trivial, but requires understanding on what is exactly going on. We plan to provide information about this. At the same time we do this, we want to move over our Prefix arches keywords, such that we can start using the Gentoo mainline tree. We hope this informative email sheds a light on the activities of the Gentoo Prefix team, and the actions we aim to take in the near future. We are open for any questions or comments. [1] http://stats.prefix.freens.org/keywords-packages.png [2] http://www.gentoo.org/proj/en/gentoo-alt/prefix/usecases.xml [3] http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml [4] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay [5] http://stats.prefix.freens.org/rsync-usage.png -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
On 11-05-2009 11:26:46 +0200, Thilo Bangert wrote: > FEATURE-misuse.txt was generated by > $ find -name '*.ebuild' | xargs grep -nH FEATURES > FEATURES-misuse.txt > and sifting through the false positives. Have you checked if eclasses use it as well? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] An Introduction to Gentoo Prefix
On 12-05-2009 08:28:15 +0200, Mounir Lamouri wrote: > Fabian Groffen wrote: > > Therefore, we plan to focus on merging back the many patches and > > extensions from our Prefix overlay into the Gentoo mainline tree. For > > us, this roadmap looks as follows: > > [snip] > I used Gentoo on MacOS X (which is part of Gentoo Prefix, isn't it ?) > and it was very promising. I'm glad this project is now in a mature shape :) If you mean "Gentoo for Mac OS X", then no. "Gentoo Prefix on Mac OS X" is a different approach than the former. And, Gentoo Prefix is not "all about Mac OS X". Just to make this clear. > About the merge, does this mean we will have to care bout other-OS > specific options ? For example, mac os options. Or it will be the work > of the Prefix team ? To take your example of Mac OS X specific options, they are IMO part of the job of the Prefix/OSX "arch team". However, yes, we would like to ask you to "care" about other OSes. We don't expect you to solve the issues, but a bug or IRC ping would be nice. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] New app-eselect category?
On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: > As of today, app-admin contains 179 packages. > We could move the 27 eselect-* packages to a new app-eselect category > (eselect itself would stay in app-admin). > > Opinions? I hate package moves, so is it really *really* necessary? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [amd64-fbsd] remove charset.alias
On 11-03-2009 18:26:33 -0400, Mike Frysinger wrote: > > > as for the ebuilds, those lines should be dropped completely. ive been > > > dropping them in newer versions of the packages rather than going back > > > and deleting them all by hand ... > > > > Aha, that explains why this recently started popping up for me and my > > too many weird platforms. I guess this means all Prefix profiles should > > have this rm code in place... :( > > are bashrc scripts stackable ? if so, might be worth adding a frag for this It seems Portage sources all profile.bashrc files it finds in the chain to the active profile. That makes them sort of stackable, hence I added this snippet in the prefix top-level profile and it works for all sub-profiles as far as I can see. Thanks. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] Overlays and Metadata Cache
Just a FYI On 20-06-2009 18:46:33 +0200, Patrick Lauer wrote: > If I don't get distracted I might set up a proof of concept public > rsync server providing the main repo plus all overlays I can throw in, > but it'd have a low initial update frequency (6h to daily). Note that the Prefix rsync tree is generated sort of like you described, doing some extra voodoo of inserting news and glsas. An update takes about 2 minutes, most time spent in running cvs update and svn update. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Please use "eselect news" items!
On 25-06-2009 22:57:08 +0100, AllenJB wrote: > As a user, I'd like to encourage developers to make use of news items > (eselect news) for important changes. I find them much more noticeable > than elog messages (which, while I have set them up so they get emailed > to me, I admit I don't always read). I think they're also easier to go > back and re-read later (not everyone knows how to dig out old elog > messages). Maybe we should make an option to have portage not notice you of new news messages until you have read it to make the feature more popular. I personally felt after the java-config news message that it's more of a bugger than a help, since I have many systems, and on all of them I had to read it to get rid of the "waiting news message". And no, excluding them in the rsync sync is not the option, as I want to be able to read them if I don't recall the details any more... just my 2 cents why I am avoiding adding news messages these days -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Gentoo Council Elections Results for term 2009/2010
On 01-07-2009 22:00:23 +0100, Roy Bamford wrote: > On behalf of the Elections project, the next Gentoo Council will be > composed of:- > > Ned Ludd (solar) > Petteri Räty (betelgeuse) > Denis Dupeyron(calchan) > Tobias Scherbaum (dertobi123) > Ulrich Müller (ulm) > Mart Raudsepp (leio) > Luca Barbato (lu_zero) A big surprise! (is it a birthday present?) Congratulations to all of you! -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Exim and Sendmail need a maintainer
On 24-06-2009 13:51:37 +, Torsten Veller wrote: > | mail-mta/exim. I'm looking for users that want to help maintaining Exim. Especially if you feel like becoming a Gentoo developer at some time, contact me directly. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Exim and Sendmail need a maintainer
On 02-07-2009 22:06:33 +0100, AllenJB wrote: > Fabian Groffen wrote: > > On 24-06-2009 13:51:37 +, Torsten Veller wrote: > >> | mail-mta/exim. > > > > I'm looking for users that want to help maintaining Exim. Especially if > > you feel like becoming a Gentoo developer at some time, contact me > > directly. > > > I recommend you post this to planet, the forums, maybe the -user mailing > list and Gentoo's Newsletter... oh wait! Maybe not the newsletter then. =P > > It might be useful to include a summary of what you expect the users to > do, what knowledge they need and what help is available (Don't forget > that what's obvious to you may not be obvious to them!) > > More than 2 users might actually see it then =P Thanks for your suggestions, however, it seems there are more than two users reading -dev, so I'm not in need for more PR at the moment :) -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] New eclass for Python
On 28-02-2012 22:13:36 +0100, Krzysztof Pawlik wrote:
[good stuff]
Much appreciated!
From 2nd example ebuild:
> python_install_all() {
> rm -f "${D}/usr/bin"/*.py || die
s/D/ED/ here for Prefix :)
I haven't checked the eclass in detail, but did you intend to make it
Prefix aware at all? I guess someone from us should test your work.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] Packages up for grabs
On 01-03-2012 22:17:12 +, Markos Chandras wrote: > app-text/antiword I took this Mutt essential. Thanks, -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: virtual/shadow
On 12-03-2012 10:16:12 +0100, "Paweł Hajdan, Jr." wrote: > On 3/8/12 2:23 PM, "Paweł Hajdan, Jr." wrote: > > And then convert profiles to the new virtual (the relevant files; below > > are all occurrences of sys-apps/shadow): > > Because of no comments, I went ahead and checked in > sys-apps/hardened-shadow and virtual/shadow, and now made changes in > profiles/ > > Please let me know if you see any problems after those changes, > especially related to stage generation, prefix, bsd, and uclibc. My rsync0 now spits out this message: Virtual package in package.provided: virtual/shadow-0 See portage(5) for correct package.provided usage. I did not forsee this happening, but each and every Prefix user now gets this complaint on each and every emerge invocation. It does not seem to block any operation, but could we perhaps hold back further changes until I can sort this out with Zac? Thanks -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: virtual/shadow
On 12-03-2012 11:35:43 +0100, "Paweł Hajdan, Jr." wrote: > On 3/12/12 11:27 AM, Fabian Groffen wrote: > > My rsync0 now spits out this message: > > > > Virtual package in package.provided: virtual/shadow-0 > > See portage(5) for correct package.provided usage. > > > > I did not forsee this happening, but each and every Prefix user now gets > > this complaint on each and every emerge invocation. It does not seem to > > block any operation, but could we perhaps hold back further changes > > until I can sort this out with Zac? > > Ah, I read portage(5) now and adding a virtual to package.provided is > indeed explicitly prohibited. > > I removed it, but some further changes might be required for prefix > (i.e. version number >= 4.1 in package.provided to satisfy the virtual), > and I'll indeed hold back further changes in that area, > and preferably just let you do any necessary fixes for prefix. Thanks a lot for your swift actions! -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: location of portage tree
On 29-03-2012 22:12:40 +0100, Roy Bamford wrote: > > For example, my /usr/portage/ on this system looks like this: > > > > portage/ > > tree/ > > profiles/ -> tree/profiles/ > > distfiles/ > > packages/ > > layman/ > > > > it is a big improvement over the current > > distfiles-and-packages-mixed-with-tree-while-layman-wanders state :) > > Lets move packages/ out of there. I share /usr/portage over NFS to > several different arches. Sharing /usr/portage/packages is a really > bad idea in that set up. As they all run ~arch, they all build packages > so I can downgrade quickly. I always use packages/CHOST for that reason. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] suspicious code in gnustep eclasses
On 30-03-2012 13:00:33 +0200, "Paweł Hajdan, Jr." wrote:
> This is from gnustep-base.eclass:
>
> > egnustep_doc() {
> > if [[ -d ./Documentation ]] ; then
> > # Check documentation presence
> > cd "${S}"/Documentation
> > if [[ -f ./[mM]akefile || -f ./GNUmakefile ]] ; then
> > emake "${GS_ENV[@]}" all || die "doc make failed"
> > emake "${GS_ENV[@]}" install || die "doc install failed"
> > fi
> > cd ..
> > fi
> > }
>
> Shouldn't those cd calls above rather be pushd/popd? It seems the above
> assumes that CWD is "${S}" when egnustep_doc is executed, which is
> probably true, but pushd/popd seems just safer.
Go ahead.
> Also, instead of ./Documentation, "${S}/Documentation" could be used.
Given the following cd, I tend to agree.
> This is from gnustep-2.eclass:
>
> > RDEPEND="${DEPEND}
> > debug? ( >=sys-devel/gdb-6.0 )"
>
> Is there some gnustep crash-reporting tool that uses gdb? I think it's
> reasonable for USE="debug" to influence how things are compiled, but
> unless gdb is required for something to work, it should be up to the
> user to install or not install gdb.
>
> In case something is broken with
> - there is no - you could add a blocker on disrupt developers because there is no such version in the tree anyway,
> and we have up-to-date systems
I think the version is because GNUstep is written in Objective-C. That
said, I think your blocker approach would be fine.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] Council meeting summary for 3 April 2012
On 22-04-2012 21:25:40 -0400, Walter Dnes wrote: > BTW, how would a non-programmer (at least not C programmer) like me > forward these ideas to the Gentoo Council? Make sure you post pointers, with preferably a clear question, in reply to the next call for agenda items (this Tuesday). -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
On 06-05-2012 14:41:13 +0300, Samuli Suominen wrote: > eclass/ has a ChangeLog > > (and this is getting old that everyone keeps ignoring it, I've proposed > punting the ChangeLog from eclass/ directory once, and repeating it now) % head Changelog # ChangeLog for eclass directory # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.241 2012/05/06 10:41:48 grobian Exp $ 06 May 2012; Fabian Groffen +ELT-patches/sol2-conf/2.4.2, libtool.eclass: Add ELT patch for Solaris x64 libtool problem where the linker is set to 'ld_sol2' -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
On 06-05-2012 19:23:47 +0200, Pacho Ramos wrote: > El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: > > Maybe we could punt ChangeLogs generally and generate them from commit > > messages... > > > > err... hasn't this been discussed before? > > > > :o( > > Well, in this case I intentionally was referring only to eclass/ as > maybe it can be implemented for it even handling normal packages as > currently The implementation has never been the problem. It's that people want to be able to edit (correct) the messages. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
On 16-05-2012 12:36:03 +0300, Eray Aslan wrote: > On 2012-05-16 12:13 PM, Andreas K. Huettel wrote: > >>> make.conf(5) man page: > >>> This causes the CONFIG_PROTECT behavior to be skipped for files that > >>> have not been modified since they were installed. > > > > +1 very good idea > > Hmm, does that mean that when a default changes in (or some new setting > is added to) an app config file, I'll get no prompt and no warning > assuming I go with the default settings in the app? That presumes that > the new default or the new setting does not break my setup. That is a > big assumption. I'd think so, yes > Even if we go with enabling it by default, please have a news item so > that one can turn it off if necessary. Even then, new installs will > have to remember to turn it off. +1 -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
On 16-05-2012 11:48:20 +0200, Pacho Ramos wrote: > El mié, 16-05-2012 a las 11:42 +0200, Fabian Groffen escribió: > > On 16-05-2012 12:36:03 +0300, Eray Aslan wrote: > > > On 2012-05-16 12:13 PM, Andreas K. Huettel wrote: > > > >>> make.conf(5) man page: > > > >>> This causes the CONFIG_PROTECT behavior to be skipped for files that > > > >>> have not been modified since they were installed. > > > > > > > > +1 very good idea > > > > > > Hmm, does that mean that when a default changes in (or some new setting > > > is added to) an app config file, I'll get no prompt and no warning > > > assuming I go with the default settings in the app? That presumes that > > > the new default or the new setting does not break my setup. That is a > > > big assumption. > > > > I'd think so, yes > > But similar assumption applies to current behavior: if a user forgets to > run dispatch-conf after updating and machine is rebooted (by error, due > some power failure, due other users rebooting it...), they will probably > get failures when booting and, for example, some init.d scripts file to > start due obsolete conf.d files being preserved by default. True, but we currently have a message for this, telling you to update your config files, while I guess there is no (persistent) message that some of your config files were overwritten, with which unknown differences (if any) triggering different behaviour. IOW it is impossible to review changes with this setting. Maybe we can just keep backups of the older conf-files if they are different (besides comments), renamed like myapp.conf-myapp-1.0-r4 and have a tool (or reuse a tool) to review and/or cleanup this every once in a while? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: enewuser should force updates to shell and home
On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote: > Hey all - I'd like to propose that enewuser forces updates to a user's > home dir and shell whenever it is called, so that if this changes with > new versions of an ebuild it is dealt with automatically rather than > having to modify them in pkg_postinst/pkg_setup directly. What if some admin purposely changed home or shell for a system account? Would be quite annoying if every update would reset that, wouldn't it? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: esethome
On 15-06-2012 09:35:38 -0400, Ian Stakenvicius wrote:
> On 15/06/12 09:27 AM, Peter Stuge wrote:
> > Mike Frysinger wrote:
> >>> + # lets see if the username already exists + if [[
> >>> ! -n $(egetent passwd "${euser}") ]] ; then
> >>
> >> "! -n" -> "-z"
> >
> > Does the $() argument ever need to be double quoted, or do all
> > versions of bash actually have the string argument optional even
> > though that's not what the man page reads?
>
> Ever? Yes, but only if what is being returned can contain spaces (and
> this matters in the way that it's used). In the case of 'egetent
> passwd', afaict no as it doesn't return anything with whitespace in it.
>
> Examples -- this works:
>
> $ bubba="test thing" ; if [ -n "$(echo $bubba)" ]; then echo OK; fi
> OK
>
> Example -- this fails:
>
> $ bubba="test thing" ; if [ -n $(echo $bubba) ]; then echo OK; fi
> bash: [: test: binary operator expected
Yes, but this works:
$ bubba="test thing" ; if [[ -n $(echo $bubba) ]]; then echo OK; fi
OK
(and he's using [[, not [)
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] RFC: esethome
On 15-06-2012 15:41:03 +0200, Peter Stuge wrote:
> Ian Stakenvicius wrote:
> > > Mike Frysinger wrote:
> > >>> + # lets see if the username already exists + if [[
> > >>> ! -n $(egetent passwd "${euser}") ]] ; then
> > >>
> > >> "! -n" -> "-z"
> > >
> > > Does the $() argument ever need to be double quoted, or do all
> > > versions of bash actually have the string argument optional even
> > > though that's not what the man page reads?
> >
> > Ever? Yes, but only if what is being returned can contain spaces
>
> Sorry, I should have mentioned that I had the case of the empty
> string in mind.
Here for the same reason, the difference between [[ and [ is essential.
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
[gentoo-dev] Re: [RFC]flag-o-matic.eclass strip-flags change to support prefix
On 17-06-2012 16:13:33 +0400, Maxim Koltsov wrote:
> Hi,
> During prefix bootstrap i noticed that strip-flags removes -L and -I
> flags from *FLAGS while these flags are essential for prefix
> bootstrapping. Therefore i propose a fix for strip-flags function to
> make it preserve prefix-related flags. I have attached a patch, please
> review it. It works for me, but I'm unsure how it will work with
> spaces in ${EPREFIX}
https://bugs.gentoo.org/show_bug.cgi?id=414641
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
[gentoo-dev] Re: gentoo-x86 commit in profiles: ChangeLog package.mask
On 12-07-2012 14:50:18 -0400, Alexandre Rostovtsev wrote: > Shouldn't CVS have prevented my changes to profile.mask from being > overwritten by the next committer? How could CVS have done that (or git, hg, whatever VCS)? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Opinion against /usr merge
On 18-07-2012 14:11:07 -0400, Michael Mol wrote: > Worse, I think /home to /Users is an *egregiously* poor choice; any > native English speaker who has rudimenatry (or even intimate) > knowledge of how things previously worked would be very likely to > confuse /Users with the historical /usr. You *are* aware OSX uses this, right? > ... Heck, I know a local guy who > has to struggle to get newish versions of Python, CUPS and other > things onto an AIX box, because those are the tools he has to use to > satisfy company needs. Based on IRC conversations, it sounds like he > spends at least 5% of his time (that *I* know about, anyway) trying to > wedge new software into old systems. How is this related to something like a /usr merge? > Ugh. I've gone offtopic. This email went from having anything to do > with udev to being about filesystems layouts. Seems to me we're in a different thread here :) -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments
On 18-07-2012 15:58:18 -0400, Michael Mol wrote: > > along with all other commands can work like before. > > > > /etc/init.d/foo stop -- start > > > > can pass start as an argument to the stop command. > > I like this approach, because its use of -- continues expected > commandline parsing behaviors from other commands, making it > intuitive. > > I.e. > > touch -- -an-ugly-filename > ls -l -- -an-ugly-filename > rm -- -an-ugly-filename yeah, but it means something like "don't treat the '-' as anything special any more", so if you don't have something starting with -, you don't need --. Hence, following your "expected" behaviour argument, /etc/init.d/foo stop start would do the same as /etc/init.d/foo stop -- start or /etc/init.d/foo -- stop start Perhaps, one better makes it explicit, inspired by gdb /etc/init.d/foo stop --args aggressive-kill=yes (and when using --args, I'd probably disallow using multiple commands to keep it clear what's going on) Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
