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] 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
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
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] 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
[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
[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
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
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 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, 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)
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
[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
[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] 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
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] 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] 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-portage-dev] Does 2.1 retain eclass info in binpkgs?
I'm doing some testing of the latest eselect-compiler for eradicator, involving merging and unmerging gcc. He has made some recent changes to toolchain.eclass that are supposed to help it work with eselect-compiler, and that's what I'm trying to test. Obviously, gcc is a rather huge package to go thru the entire merge every time just to test a bit of the post-merge compiler selection script, and AFAIK, while the ebuild is stored with the binpkg, and both the ebuild and dependent classes are stored in the merged package database, merging a binpkg still uses the current in-tree eclasses. That's what I'm hoping, anyway. Is that a true summation or does portage 2.1 now retain build-time eclasses in the binpkg, rather than using those in the tree, when merging the binpkg? -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-portage-dev@gentoo.org mailing list
