Re: [gentoo-dev] eselect-compiler updates and unmasking
Jeremy Huddleston wrote: > I finally had a few free cycles, so I fixed up the eselect-compiler > ebuild to better handle the transition from gcc-config and updated > toolchain.eclass to better work with multilib. I've had a bunch of help > from the amd64 devs/testers/users this past week testing it out, and I > think it's ready to be removed from package.mask sometime soon (next > week). Before that happens, I'd like to get some feedback from a > broader test base, so if you have some time and aren't using > eselect-compiler yet, I'd appreciate your testing. All you need to do > is add the following to /etc/portage/package.unmask: Couple of questions: 1) Can it handle non-gcc compilers? If so, how? 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. If neither of those are possible now, I would like to look into fixing this. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] eselect-compiler updates and unmasking
I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: app-admin/eselect-conmpiler sys-devel/gcc-config then just update gcc-config: $ emerge -uv --oneshot sys-devel/gcc-config gcc-config is just a wrapper which takes the same syntax as the older gcc-configs and makes the appropriate call to eselect-compiler. Please report any bugs you find in bugzilla and assign them directly to me ([EMAIL PROTECTED]). Also, if you've been using eselect-compiler, you may have an issue where your profiles don't get removed from /etc/eselect/compiler when you unmerge gcc. This problem is fixed now for future installs, but you'll have to manually remove the file when you unmerge any gcc that is on your system now. Thanks, Jeremy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 2006-06-02 at 19:48 +0200, Paul de Vrieze wrote: > On Friday 02 June 2006 18:47, Marius Mauch wrote: > > Actually this is probably the main problem of all the "package manager > > compability" gleps: We don't have a proper specification, all existing > > docs more or less are based on the existing portage implementation. So > > right now the implementation is the authorative specification, which of > > course creates some problems. > > IMO before any such glep can be considered we need a proper > > specification about our package and repository formats, otherwise you > > can't really validate any package manager (the statespace is a bit > > large for equivalence checks). > > The problem is actually that such a document is a living thing and it must > not > only exist initially but be maintained continuously. Yes and no. EAPI=0 is somewhat nailed down. We could nail it down further. Any future EAPI versions could easily be written as just the differences from the previous EAPI. fex. EAPI=1 (or whatever) could be something like: all of EAPI=0 + multiple repositories (and a definition of requirements), USE-based dependencies (and a definition of requirements/etc), and per-package use.mask (including all the necessary information. Honestly, it is really bad that we do *not* have a listing of what is and what is not allowed in ebuilds. We have lots of different places where such things exist, but no one clear definition. We really need a single, concise definition of what exactly *is* an ebuild before trying to proceed further. Things to consider: - required variables (SRC_URI, DESCRIPTION, HOMEPAGE) - disallowed variables (P, T, PN) - valid non-function abilities (inherit is all that comes to mind) - description of default functions (as in what they are, not so much what they do in detail) I'm sure there's *tons* and *tons* more stuff, but this is a start. We do have quite a bit of this in the ebuild man page, os it isn't like we'd have to start from scratch. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] User Relations Co-lead
Hi, It is my pleasure to inform you that after much discussion I can announce that Joshua Jackson (tsunam) has come onboard to act as my co-lead in Userrel[1]. Wish him luck, I suspect he will need it! [1] http://www.gentoo.org/proj/en/devrel/user-relations/index.xml -- $a="gentoo.org"; Christel Dahlskjaer | [EMAIL PROTECTED] | www.$a Gentoo Developeress - User Relations, Developer Relations, Gentoo/MIPS, Gentoo/Alpha, PR, Events, Release Engineering signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-core] Marking packages ~amd64 (or amd64) and no-multilib
On Fri, 2006-06-02 at 15:26 -0400, Chris Gianelloni wrote: > First off, I'd like to apologize for cross-posting this, but I've been > pestered by this enough recently to want to try to reach as much of the > developer pool as possible. > > If you add any amd64 KEYWORDS to *any* packages in the tree, make sure > you've updated your profiles directory before doing your repoman scan. > The profiles.desc file now lists default-linux/amd64/2006.0/no-multilib > as a valid profile. This means if you're committing something that > requires 32-bit libraries, you *MUST* mask the package in > default-linux/amd64/2006.0/no-multilib/package.mask *before* doing your > commit. This is like the 10th time in the past few weeks that I've been > contacted directly to fix broken masks in other people's packages. Everything Chris said but please don't overlook profiles/hardened/amd64 (our no-multilib) in addition to profiles/hardened/amd64/multilib (our multilib) The logic is a kinda inverted from what some of you may be used to when thinking of the how the default-linux profile deals with it, but we think it's proper the way we do it.. > It's pretty simple. If it uses ABI=x86 or any emul-linux-x86-* > packages, then it needs to be masked. > > Over and out. > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Marking packages ~amd64 (or amd64) and no-multilib
First off, I'd like to apologize for cross-posting this, but I've been pestered by this enough recently to want to try to reach as much of the developer pool as possible. If you add any amd64 KEYWORDS to *any* packages in the tree, make sure you've updated your profiles directory before doing your repoman scan. The profiles.desc file now lists default-linux/amd64/2006.0/no-multilib as a valid profile. This means if you're committing something that requires 32-bit libraries, you *MUST* mask the package in default-linux/amd64/2006.0/no-multilib/package.mask *before* doing your commit. This is like the 10th time in the past few weeks that I've been contacted directly to fix broken masks in other people's packages. It's pretty simple. If it uses ABI=x86 or any emul-linux-x86-* packages, then it needs to be masked. Over and out. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Glep 49 (g2boojum's version)
Stephen Bennett wrote: On Fri, 2 Jun 2006 19:48:39 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Must it? I'd be more inclined to say that if it needs to change, a new specification should be created based on the current one, and EAPI bumped. Each individual document should remain more or less unchanged once it's finalised, barring minor bugfixes. I think this is what he means by maintained...aka someone needs to either update the spec, or create a new one. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 2 Jun 2006 19:48:39 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > The problem is actually that such a document is a living thing and it > must not only exist initially but be maintained continuously. Must it? I'd be more inclined to say that if it needs to change, a new specification should be created based on the current one, and EAPI bumped. Each individual document should remain more or less unchanged once it's finalised, barring minor bugfixes. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Friday 02 June 2006 18:47, Marius Mauch wrote: > Actually this is probably the main problem of all the "package manager > compability" gleps: We don't have a proper specification, all existing > docs more or less are based on the existing portage implementation. So > right now the implementation is the authorative specification, which of > course creates some problems. > IMO before any such glep can be considered we need a proper > specification about our package and repository formats, otherwise you > can't really validate any package manager (the statespace is a bit > large for equivalence checks). The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsnabAA0l7F.pgp Description: PGP signature
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 02 Jun 2006 16:17:06 + Ferris McCormick <[EMAIL PROTECTED]> wrote: > Grant, > Apologies; I can't find your note from yesterday, so I can't respond > to the correct topic. > One question just occurred to me; if it's been addressed before, > apologies about that, too. Your requirement that any alternative > package manager support any ebuild which portage supports seems > essential, except for a boundary case. What about ebuilds which for > whatever reason are invalid (serious specification violation, for > example, to the extent that QA would reject them), but portage accepts > them anyway. Must the alternative accept them as well? In a case > like this, it seems to me that the ebuild works because of a bug in > portage, and there should be no complaint if as a side effect of > fixing this bug the ebuild in question quit working. > If memory serves me, things like this have indeed happened. I can't > recall a specific, however. Actually this is probably the main problem of all the "package manager compability" gleps: We don't have a proper specification, all existing docs more or less are based on the existing portage implementation. So right now the implementation is the authorative specification, which of course creates some problems. IMO before any such glep can be considered we need a proper specification about our package and repository formats, otherwise you can't really validate any package manager (the statespace is a bit large for equivalence checks). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 02 Jun 2006 16:17:06 + Ferris McCormick <[EMAIL PROTECTED]> wrote: > What about ebuilds which for > whatever reason are invalid (serious specification violation, for > example, to the extent that QA would reject them), but portage accepts > them anyway. Must the alternative accept them as well? Precedent says that a new (minor) Portage version can quite happily break such ebuilds, so I see no reason to say that any alternative should accept them. On a side note, this is part of the reason why we really need the ebuild/tree format properly defined somewhere. It would remove any worries about compatibility between ebuilds and package managers, as long as ebuilds conform to a given specification, and the package manager supports it. It also defines in a much better manner just what a broken ebuild is. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Glep 49 (g2boojum's version)
Grant, Apologies; I can't find your note from yesterday, so I can't respond to the correct topic. One question just occurred to me; if it's been addressed before, apologies about that, too. Your requirement that any alternative package manager support any ebuild which portage supports seems essential, except for a boundary case. What about ebuilds which for whatever reason are invalid (serious specification violation, for example, to the extent that QA would reject them), but portage accepts them anyway. Must the alternative accept them as well? In a case like this, it seems to me that the ebuild works because of a bug in portage, and there should be no complaint if as a side effect of fixing this bug the ebuild in question quit working. If memory serves me, things like this have indeed happened. I can't recall a specific, however. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites/mask notification: dev-libs/libvc, app-misc/rolo and mail-client/mutt-vc-query
Hi Gentoo, dev-libs/libvc, app-misc/rolo and mail-client/mutt-vc-query were masked because of the open security bug #127757. It also seems like there was no upstream release for like 3 years, so this packages are pretty much dead. If nobody speaks up or volunteers as maintainer for that cruft, then this will stay masked until complete removal $SOON. Thanks to mr_bones_ for masking the deps I forgot and halcy0n for the headsup in the bug. Kind regards, DerCorny -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Security/QA Spring Cleaning
On Sunday 28 May 2006 21:20, Ned Ludd wrote: > The following maintainers and maintaining herds are affected by this > in one way or another. This list is still far to large for me want to > file a bug for.. So please do what you can to help narrow this list > down. > > Granted not all cases can be solved easily especially when it's some > misc arch which is forcing you to keep a package in the tree when you > don't want to. For those cases please file an arch stabilization bug > where appropriate. > Package: net-analyzer/nagios-core Herd: netmon Maintainer: [EMAIL PROTECTED], [EMAIL PROTECTED] Description: ... Done. -- Eldad Zack <[EMAIL PROTECTED]> Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93 pgp7GxP1W34r7.pgp Description: PGP signature
Re: [gentoo-dev] UTF-8 encoding and file format of manuals
Paul de Vrieze wrote: > Would it be possible to do automatic detection and unicode conversion in the > portage install stage? I think that would probably be the best option. At a > later stage a simple detection and warning might be sufficient. Tricky. You can parse a file and check if it's valid UTF-8 but the problem is that you can't be sure if it isn't (eg) just a ISO8859-2 formatted one that happened to have interesting sequence of characters. That said, there are some tools that tries to perform some magic (statistical data analysis etc) and guess the correct encoding. [1] [1] app-i18n/enca, http://trific.ath.cx/software/enca/ HTH, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Simon Stelling wrote: > You forgot to mention which package uses the variable. > Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv ;) -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UTF-8 encoding and file format of manuals
On Thu, 1 Jun 2006 21:08:54 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > On Thursday 01 June 2006 20:19, Jan Kundrát wrote: > > Wiktor Wandachowicz wrote: > > > Summing up: > > > * UTF-8 manuals: good or bad? > > > > The Only Way To Go (tm), IMHO. Let's let the legacy encodings die > > in piece. > > Would it be possible to do automatic detection and unicode conversion > in the portage install stage? I think that would probably be the best > option. At a later stage a simple detection and warning might be > sufficient. > I'd imagine that glep31check could be easily adapted to do this. -- Tom Martin, http://dev.gentoo.org/~slarti AMD64, net-mail, shell-tools, vim, recruiters Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
You forgot to mention which package uses the variable. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
On Friday 02 June 2006 00:33, Mark Loeser wrote: > Mike Frysinger <[EMAIL PROTECTED]> said: > > 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. > > As I requested in an earlier email, I would like it to be discussed how > we want to handle alternative package managers. The GLEPs both touch on > the issue, but if neither of those proposals are liked, then we are > still left not knowing what to do. > > Here is my original email: > http://article.gmane.org/gmane.linux.gentoo.devel/38231 > > As I said in my email, I want there to be a discussion (and hopefully a > decision) as to whether or not adding these packages to *our* tree is > best for us and our users. In my opinion, it seems to make the most > sense for alternative package managers to be hosted on their own > infrastructure so they are free to introduce new features and write > ebuilds to take advantage of those features. > > If it is required for me to be present at the meeting to discuss this (I > don't believe I have to be), then could whoever does the scheduling get > in touch with me, because it will be difficult for me to be here during > the day since I just started a new job. I support this request, and in return am willing to incorporate suggestions by the council into my GLEP. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp1OzUoiuaFd.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
On Friday 02 June 2006 00:16, Stephen Bennett wrote: > On Thu, 1 Jun 2006 21:44:39 +0200 > > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > I would like the council to discuss GLEP 49 as has been discussed on > > the list some weeks ago. It is about the package manager requirements. > > Isn't it customary for issues raised on the list to be addressed before > a GLEP is submitted to the council? Besides the fact that the GLEP is long (overengineered?) there is one main point of disagreement. That point is the requirement of primary package manager hosting. As shown by various council members, they also have their disagreements. It should not be that all points have to be resolved before the council can take a look at a GLEP. Part of the job of the council is to make decisions, not just to rubberstamp things. I believe that currently all things concerning the GLEP have been discussed, so now it is time to get feedback from the council. I did not request a decision now. I requested the council to discuss the GLEP. On another point, the overengineering. Writing a package manager requires a big investment in time. The GLEP is detailed in various points to allow package manager writers to know what they can expect in the future. This gives them a hard target to work with. I agree with grant that the council will let sanity prevail. I do however think that the decisions by the council at such a time could lead to disappointments on the part of people who have written a replacement package manager that is not accepted. In general the document is intended as a guideline for package manager writers that describes their place within gentoo. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsV2lLD7n2P.pgp Description: PGP signature