Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Thu, 2008-10-02 at 22:24 +0200, Jeroen Roovers wrote: # Gen 2 Developer [EMAIL PROTECTED] (`date`) # Masked for testing. =rofl-cat/omgpkg-ver Please people, if you want to get something tested, then don't mask it. Stuff with high impact better be masked for initial testing, such as new versions of gcc, glibc and other parts of toolchain and build system, and other similar things affecting other packages than itself. ~arch is in my eyes something that updates shouldn't break vastly - a stable candidate. Of course when that initial testing is done with helping users, the reason could be modified to tell things broke and what the tracking bug is, or unmasked if it works fine with other packages. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Thu, Oct 2, 2008 at 8:16 PM, Jeroen Roovers [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008 04:23:33 +0200 Dawid Węgliński [EMAIL PROTECTED] wrote: I don't think it's ok. ~arch isn't training ground. It's supposed to work, so asking arch teams to keywords packages that are not supposed to work isn't good. We have a testing branch and a stable branch, defined by the KEYWORDS variable in the ebuilds. Package.masking stuff saying you're testing is at the least uninformative and highly confusing and unfriendly to would-be testers when in the very same context this already means something different (namely, it's been too short a while, wait one or two months for this version to go stable, as the ~arch keywords would suggest). ~arch has always been for testing ebuilds; not packages. You should not be using ~arch to test stuff you know doesn't work; that is what package.mask is for; to prevent users from accidentally installing broken shit. The same term shouldn't be used to denote two ways of masking ebuilds, but that's beside the point of providing good reasons to package.mask ebuilds. I completely agree that useful messages in package.mask are important. -Alec Even saying that it would kill puppies would be more valid. Just be honest and tell people what is going on. Tell them that if they use Opera snapshots, they shouldn't care about losing mail or experience frequent crashes while browsing. Anything really, just don't tell them you're testing or you find yourself excluding them from the party with a really bad excuse. This is the place i agree with you. Anyway i think package still should be p.masked with good explanation of why it is masked. Welcome to the starting point of this thread! ;-) Kind regards, JeR
[gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, This is a revised version of the PROPERTIES=set proposal which has been discussed previously [1]. Please consider a PROPERTIES=set value will serve to indicate that a given ebuild should be exposed within the package set framework as a package set. In order to expose such an ebuild as a package set, a new sets profile configuration file will serve to define mappings from set names to package atoms. Similar to the existing virtuals file which is already supported by profiles, the sets file will allow a given profile to override any mappings that have been defined by parent profiles. The bulk of the mappings will be defined in profiles/base/sets, since all profiles should inherit the same set mappings unless they need to be overridden for some reason. For the new sets profile configuration file format, the simplest possible layout could have a set name in the first column and a package atom in the second column. The package atom should match an ebuild which exhibits the set property. In addition to the set name and atom columns, we may also want to include an EAPI column which the package manager can use to ensure that it parses the atom syntax correctly. Similar to the proposed virtual property [2], the set property will indicate that dependency calculations should consider the ebuild to have zero installation cost. Similar to glep 37 [3], ebuilds that exhibit PROPERTIES=set should also define all of their dependencies in the RDEPEND variable. Other than these constraints, an ebuild which exhibits PROPERTIES=set should behave just like any other ebuild. It should be installed and uninstalled just like any other ebuild, including execution of all the normal ebuild phase functions that would be executed for any other ebuild that does not exhibit the set property. I order to determine which atoms correspond to a given set, the first step is to lookup the set name from the profile's sets configuration files. The corresponding package atom is then resolved to a specific ebuild which should exhibit the set property. The dependency atoms from this ebuild's RDEPEND variable will serve to make up the atoms of the package set. In cases when these atoms resolve to other ebuilds that exhibit he set property then those other ebuilds act as nested sets and this nesting process is recursive with no limit on the depth of nesting. The nested sets do not necessarily have to be mapped to specific set names by the profile's sets configuration files. If nested sets are anonymous in this sense then their atoms still become a part of the set that they are nested within, just as they would if they had been given a name by the profile's sets configuration files. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? [1] http://archives.gentoo.org/gentoo-dev/msg_02020c2650449920c941adf46dbf7d6f.xml [2] http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml [3] http://archives.gentoo.org/proj/en/glep/glep-0037.html - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjlxX4ACgkQ/ejvha5XGaMv2gCggj2YCW3MkcW/Y/EQUPX+V38E 4DgAnR3d4mD5Y4S2qGZRbq8md1NJnLE7 =AdHx -END PGP SIGNATURE-
[gentoo-dev] Re: proj/en/perl/outdated-cpan-packages.xml automatic update
* Robin H. Johnson [EMAIL PROTECTED]: On Fri, Oct 03, 2008 at 07:33:11AM +0200, Torsten Veller wrote: * Robin H. Johnson [EMAIL PROTECTED]: And something is broken with CPAN, just in time for us :-). Manually browsing give me: http://search.cpan.org/~rjbs/Email-MessageID-1.400/ This version was released yesterday. But using CPAN itself gives me: Email::MessageID 1.351 R/RJ/RJBS/Email-MessageID-1.351.tar.gz It's in here: Last-Updated: Fri, 03 Oct 2008 00:26:55 GMT Email::MessageID 1.400 R/RJ/RJBS/Email-MessageID-1.400.tar.gz If you look at the commits that the script made, some of the CPAN mirrors had Email-MessageID-1.400 in the index, but others didn't. http://cpan.org/misc/cpan-faq.html#Which_site_mirror: http://www.cs.uu.nl/stats/mirmon/cpan.html: The mirrors are not all syncing from the master site and sync at different times probably only once a day while the master gets update more often. So a new module can be missing on some servers. Then again some servers are not uptodate at all. archive.cs.uu.nl: Fri, 03 Oct 2008 00:26:55 GMT arwen.cs.dal.ca: Wed, 01 Oct 2008 08:28:05 GMT cpan.biz.net.id: Thu, 02 Oct 2008 14:27:30 GMT cpan.catalyst.net.nz: Fri, 03 Oct 2008 04:27:05 GMT cpan.mirror.ac.za:Thu, 02 Oct 2008 14:27:30 GMT cpan.mirrors.easynet.fr: Fri, 03 Oct 2008 03:26:50 GMT cpan.mirror.choon.net:Fri, 03 Oct 2008 04:27:05 GMT cpan.mirror.clemson.edu: Sat, 27 Sep 2008 22:26:48 GMT cpan.net.pl: Fri, 05 Sep 2008 00:02:47 GMT cpan.triplemind.com: Mon, 14 Jul 2008 03:02:58 GMT cpan.velug.org.ve:Fri, 03 Oct 2008 04:27:05 GMT For the scipt we should use a reliable mirror or the master site. Thanks.
[gentoo-dev] Re: Testing is not a valid reason to package.mask
Mart Raudsepp [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 03 Oct 2008 10:06:39 +0300: Of course when that initial testing is done with helping users, the reason could be modified to tell things broke and what the tracking bug is, or unmasked if it works fine with other packages. From previous discussions on this, that's really the point (besides the one about not masking it if testing is needed, which toolchain for instance pretty much has to do anyway). If it has a tracking bug, it has the necessary info. If it's just masked for testing, the necessary info isn't there. This helps me as a user who often does that sort of testing, too. Masked for testing simply isn't that useful. A tracking bug, where I can see how that testing is progressing and what other sorts of stuff I might expect to have issues with if I DO test, now THAT's actual practical info! Simply masked for testing is little better than no comment at all, or than a package revision bump without a changelog entry telling me what the big deal was that was worth the revision. (That's another irritating one, but fortunately it doesn't happen so often any more. Thanks guys!) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Testing is not a valid reason to package.mask
Alec Warner schrieb: On Thu, Oct 2, 2008 at 8:16 PM, Jeroen Roovers [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008 04:23:33 +0200 Dawid Węgliński [EMAIL PROTECTED] wrote: I don't think it's ok. ~arch isn't training ground. It's supposed to work, so asking arch teams to keywords packages that are not supposed to work isn't good. We have a testing branch and a stable branch, defined by the KEYWORDS variable in the ebuilds. Package.masking stuff saying you're testing is at the least uninformative and highly confusing and unfriendly to would-be testers when in the very same context this already means something different (namely, it's been too short a while, wait one or two months for this version to go stable, as the ~arch keywords would suggest). ~arch has always been for testing ebuilds; not packages. You should not be using ~arch to test stuff you know doesn't work; that is what package.mask is for; to prevent users from accidentally installing broken shit. Why do you need package.mask here? If you know, it does not work on that arch, dont keyword it. If you know it does not work anywhere, why would you even think about adding that package? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
On Fri, 03 Oct 2008 00:10:56 -0700 Zac Medico [EMAIL PROTECTED] wrote: For the new sets profile configuration file format, the simplest possible layout could have a set name in the first column and a package atom in the second column. The package atom should match an ebuild which exhibits the set property. In addition to the set name and atom columns, we may also want to include an EAPI column which the package manager can use to ensure that it parses the atom syntax correctly. We probably want to start putting a profile_eapi file in each profile directory or something like that... Get package managers to refuse to use any profile that contains a directory using an eapi it doesn't know. This'll help sort out the slot deps in profiles issue too. Similar to the proposed virtual property [2], the set property will indicate that dependency calculations should consider the ebuild to have zero installation cost. If we go this route, that needs to be a property of its own, really. Otherwise we'll end up with a dozen properties all of which imply particular different real properties. I order to determine which atoms correspond to a given set, the first step is to lookup the set name from the profile's sets configuration files. The corresponding package atom is then resolved to a specific ebuild which should exhibit the set property. The dependency atoms from this ebuild's RDEPEND variable will serve to make up the atoms of the package set. In cases when these atoms resolve to other ebuilds that exhibit he set property then those other ebuilds act as nested sets and this nesting process is recursive with no limit on the depth of nesting. The nested sets do not necessarily have to be mapped to specific set names by the profile's sets configuration files. If nested sets are anonymous in this sense then their atoms still become a part of the set that they are nested within, just as they would if they had been given a name by the profile's sets configuration files. Why not just invent a syntax that lets you take an arbitrary ebuild and use an arbitrary dep key from it as a set? Say, something like @RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping mess at all... Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? This looks to me as if you're trying to find uses for PROPERTIES, rather than trying to find ways to solve a problem. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Fri, 03 Oct 2008 00:10:56 -0700 Zac Medico [EMAIL PROTECTED] wrote: For the new sets profile configuration file format, the simplest possible layout could have a set name in the first column and a package atom in the second column. The package atom should match an ebuild which exhibits the set property. In addition to the set name and atom columns, we may also want to include an EAPI column which the package manager can use to ensure that it parses the atom syntax correctly. We probably want to start putting a profile_eapi file in each profile directory or something like that... Get package managers to refuse to use any profile that contains a directory using an eapi it doesn't know. This'll help sort out the slot deps in profiles issue too. That's a good idea. If we do that then we can assume that all atoms in the profile conform to the specified EAPI. Similar to the proposed virtual property [2], the set property will indicate that dependency calculations should consider the ebuild to have zero installation cost. If we go this route, that needs to be a property of its own, really. Otherwise we'll end up with a dozen properties all of which imply particular different real properties. Perhaps, but there's a trade-off in having to specify two properties when a single property can have compound meaning. For example, Donnie (dberkholz) has previously expressed some concern about PROPERTIES being more fine-grained than they need to be [1]. I order to determine which atoms correspond to a given set, the first step is to lookup the set name from the profile's sets configuration files. The corresponding package atom is then resolved to a specific ebuild which should exhibit the set property. The dependency atoms from this ebuild's RDEPEND variable will serve to make up the atoms of the package set. In cases when these atoms resolve to other ebuilds that exhibit he set property then those other ebuilds act as nested sets and this nesting process is recursive with no limit on the depth of nesting. The nested sets do not necessarily have to be mapped to specific set names by the profile's sets configuration files. If nested sets are anonymous in this sense then their atoms still become a part of the set that they are nested within, just as they would if they had been given a name by the profile's sets configuration files. Why not just invent a syntax that lets you take an arbitrary ebuild and use an arbitrary dep key from it as a set? Say, something like @RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping mess at all... Well, that wouldn't allow for nesting. The idea behind the PROPERTIES=set approach is to integrate meta-ebuilds into the sets framework in a way maximizes reuse of the advantages that meta-ebuilds have to offer [2]. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? This looks to me as if you're trying to find uses for PROPERTIES, rather than trying to find ways to solve a problem. No, I'm trying to integrate meta-ebuilds into the sets framework and it just happens the PROPERTIES metadata offers a convenient way to separate meta-ebuilds from normal ebuilds. [1] http://archives.gentoo.org/gentoo-dev/msg_10a7e736c3bd2dea4223f599a463994e.xml [2] http://archives.gentoo.org/gentoo-dev/msg_f0c6b1f3a047fc83ef237e0304af6697.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjmQBAACgkQ/ejvha5XGaP4sgCdEWuCSpUZKTwxKxOxZOTEIn3R bgkAnROJHVeYYG5K7rorJloHjvjNUkAe =fZP5 -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/anki: metadata.xml Manifest anki-0.9.8.1.ebuild ChangeLog
Hi,
welcome to your mentor reviews. :)
Heath Caldwell (hncaldwell) [EMAIL PROTECTED]:
Index: metadata.xml
flag name=kakasi
Enable pkgapp-i18n/kakasi/pkg support for
furigana generation /flag
I tend to call it furigana instead of kakasi, as USE flags should
describe a purpose/function not the needed software to achieve it.
Index: anki-0.9.8.1.ebuild
===
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
#
$Header: /var/cvsroot/gentoo-x86/app-misc/anki/anki-0.9.8.1.ebuild,v
1.1 2008/10/02 23:13:39 hncaldwell Exp $
EAPI=1
NEED_PYTHON=2.4
inherit eutils multilib python
DESCRIPTION=A spaced-repetition memory training program (flash
cards) HOMEPAGE=http://ichi2.net/anki/index.html;
SRC_URI=http://ichi2.net/anki/download/${P}.tgz;
LICENSE=GPL-3
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=+graph kakasi +sound
RDEPEND==dev-python/PyQt4-4.3
=dev-python/sqlalchemy-0.4.1
=dev-python/simplejson-1.7.3
=dev-python/pysqlite-2.3.0
pysqlite is included with Python 2.5 (USE=sqlite enabled), so you
might upgrade to EAPI=2 and use USE dependencies or add a
built_with_use check into pkg_config. Or ask the Python team how to
handle it in the best way.
src_install() {
dodoc CREDITS
python_version
insinto /usr/$(get_libdir)/python${PYVER}/site-packages
doins -r ankiqt libanki/anki
insinto /usr/$(get_libdir)/python${PYVER}/site-packages/anki
doins -r designer icons icons.qrc icons_rc.py libanki/samples
dobin ${PN}
doicon icons/${PN}.png
make_desktop_entry ${PN} ${PN} ${PN}.png Education
}
No installation routine available?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://www.faulhammer.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Fri, Oct 3, 2008 at 5:06 AM, Thomas Sachau [EMAIL PROTECTED] wrote: Alec Warner schrieb: On Thu, Oct 2, 2008 at 8:16 PM, Jeroen Roovers [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008 04:23:33 +0200 Dawid Węgliński [EMAIL PROTECTED] wrote: I don't think it's ok. ~arch isn't training ground. It's supposed to work, so asking arch teams to keywords packages that are not supposed to work isn't good. We have a testing branch and a stable branch, defined by the KEYWORDS variable in the ebuilds. Package.masking stuff saying you're testing is at the least uninformative and highly confusing and unfriendly to would-be testers when in the very same context this already means something different (namely, it's been too short a while, wait one or two months for this version to go stable, as the ~arch keywords would suggest). ~arch has always been for testing ebuilds; not packages. You should not be using ~arch to test stuff you know doesn't work; that is what package.mask is for; to prevent users from accidentally installing broken shit. Why do you need package.mask here? If you know, it does not work on that arch, dont keyword it. If you know it does not work anywhere, why would you even think about adding that package? Nuances ;) What does a lack of keyword mean? It means that no dev has bothered to test the package on said arch. It doesn't mean the package does not work properly on said arch. Users who run alt arches like sparc end up ~arch keywording stuff locally all the time; it would be unfortunate were they to keyword a totally broken package on sparc just because the dev didn't keyword it. Users often think this means 'lack of time' not 'does not function'. What does -arch mean? It means that the package *will* never work on said arch (64-bit binaries on x86 for example); it does not mean 'this package *may* not work'; so keywording broken packages with -arch is also not quite correct (although arguably you could move from -arch, to ~arch, to arch and maybe get away with it.) Package.mask can be used for evaluating packages. Many developers would suggest using overlays for these types of packages; however not everyone has an overlay and not everyone uses overlays so I don't think there should be a hard and fast rule here. -- Thomas Sachau Gentoo Linux Developer
[gentoo-dev] [RFC] Label profiles with EAPI for compatibility checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Please consider a new eapi profile configuration file that will designate the EAPI to which any package atoms within a given layer of the profile stack must conform. This will allow package managers to bail out with an informative error message if the user accidentally selects a profile containing an EAPI that is not supported by the currently installed package manager. In order to allow mixed EAPIs in the profiles, and to avoid having to configure the EAPI in every single layer, each directory of the profile stack should be able to either override or inherit the EAPI value that may have been defined in a previous layer of the profile stack. If no EAPI has been previously defined then it can be assumed to be 0. The format of the configuration file can be very simple, containing only the EAPI value and nothing more. For example, a file containing just a single 0 character, followed by a newline, could be created at profiles/base/eapi in order to explicitly declare that atoms in the base profile conform to EAPI 0. However, this particular declaration would be redundant since the base profile does not inherit from any other profile and therefore it's EAPI would be assumed to be 0 anyway. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjmtEYACgkQ/ejvha5XGaNtSQCfXb2OQAYCEAe0Uuuu7Ou+DxyV QZsAn0VpUbKqHJP0XRZSg6mhFKeUNXui =qR8c -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: Hi everyone, This is a revised version of the PROPERTIES=set proposal which has been discussed previously [1]. snip a detailed proposal about a new kind of set Let me try show some real examples of the type of sets I would like to use and how I'd like to use them, so that your proposal and the discussion on sets can take this into account. meta sets: - @kde # We don't include kdesdk on the global set kde-base/kate @kdeadmin @kdeartwork @kdebase @kdeedu @kdegames @kdegraphics @kdemultimedia @kdenetwork @kdepim @kdetoys @kdeutils - @kde simple sets (list of ebuilds) - @kdetoys kde-base/amor kde-base/kteatime kde-base/ktux kde-base/kweather - @kdetoys sets with conditional deps - @compiz-fusion dev-python/compizconfig-python x11-apps/ccsm x11-apps/simple-ccsm x11-libs/compiz-bcop x11-libs/libcompizconfig x11-plugins/compiz-fusion-plugins-main x11-plugins/compiz-fusion-plugins-extra x11-themes/emerald-themes x11-wm/compiz emerald? (x11-wm/emerald ) gnome? ( x11-libs/compizconfig-backend-gconf ) kde? ( x11-libs/compizconfig-backend-kconfig ) unsupported? ( x11-plugins/compiz-fusion-plugins-unsupported ) - @compiz-fusion It would also be important to have versioned sets (depending on a slot, for example). Marius Mauch (genone) suggested a very interesting way to solve this by using a set config file (portage specific) that, as he stated, should work if I got the syntax right from memory [current Portage svn] (something similar to): - sets.conf [slot-4.1] class=dbapi.VariableSet variable=SLOT include=4.1 [kdebase] class=files.StaticFileSet filename=kdebase [kdebase-4.1] class=base.DummyPackageSet extend=kdebase intersect=slot-4.1 - sets.conf Being able to take advantage of use deps for packages would be a bonus: kde? ( x11-libs/compizconfig-backend-kconfig x11-wm/compiz[kde] ) These type of sets cover what I need / would like to have at the moment. How would I like to use them? I would like to have the sets defined in the tree as base sets that users can tweak to their needs. So they should be able to use something similar to package.use (package.use itself?) to add desired conditional deps such as @compiz-fusion - -emerald -gnome kde unsupported. With the sets operators being defined by genone for Portage[1] '-', '/' users should also be able to create sets with a list of packages they don't want to install, so if someone wouldn't want to install kppp with @kdenetwork, they could create a @kdenetwork-unwanted set with kppp and run emerge -av @[EMAIL PROTECTED]. It would be really helpful if we could have a package.mask like structure that allowed users to mask deps from sets (does / could package.mask be used this way?) so that one wouldn't be forced to run emerge -av @[EMAIL PROTECTED] every time. Running emerge -av @kdenetwork/@installed to reinstall only installed deps or emerge -uDav @kdenetwork/@installed to update the existing deps are also interesting ideas. Perhaps we should start doing emerge -uDav @world/@installed. Marius suggests the following for the subtraction issue (the same warning as above): - sets.conf # assuming @kdenetwork is already defined in a higher level sets.conf [kdenetwork-ignore] class=base.DummyPackageSet packages=kde-extra/i-dont-want-this [kdenetwork] remove=kdenetwork-ignore - sets.conf So this is what I would like to see with sets. Am I crazy? Is it possible to do any of this? Anyone has some other needs? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE [1] - http://planet.gentoo.org/developers/genone/2008/09/29/more_extensions_to_package_set_support -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjm5yEACgkQcAWygvVEyAL6YwCZAaLiyKm8sUySAcgIgBdPDStT ZcQAn3+FGPlnmlxKPdKOkWQizs//vuKP =They -END PGP SIGNATURE-
[gentoo-dev] Re: Testing is not a valid reason to package.mask
On Thu, 2 Oct 2008 22:24:35 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: Please people, if you want to get something tested, then don't mask it. Um... no? One thing that package.mask has always been used for is temporarily masking a package until it can be tested and then unleashed on the general population. It's not like we're putting masked stuff in the tree with the hope that someone will find it and try it out. You mask a package, ask the user or whoever to test it, and unmask it when it's ready. We don't just throw untested stuff into the tree when we suspect problems with it. ~arch is not a playground. Already one of the major complaints we see against Gentoo time and time again is that it breaks too often and the maintenance burden is too high. Why would we want to exacerbate that? We don't /want/ ~arch systems to get automatically widely exposed to the stuff we're intending to get tested. That's the whole point of masking it! We want it tested by a few people before we expose it to the unwashed masses. So, no, I'll continue using package.mask for testing just as it always has been. Sorry. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-portage-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, This is a revised version of the PROPERTIES=set proposal which has been discussed previously [1]. Please consider a PROPERTIES=set value will serve to indicate that a given ebuild should be exposed within the package set framework as a package set. In order to expose such an ebuild as a package set, a new sets profile configuration file will serve to define mappings from set names to package atoms. Similar to the existing virtuals file which is already supported by profiles, the sets file will allow a given profile to override any mappings that have been defined by parent profiles. The bulk of the mappings will be defined in profiles/base/sets, since all profiles should inherit the same set mappings unless they need to be overridden for some reason. For the new sets profile configuration file format, the simplest possible layout could have a set name in the first column and a package atom in the second column. The package atom should match an ebuild which exhibits the set property. In addition to the set name and atom columns, we may also want to include an EAPI column which the package manager can use to ensure that it parses the atom syntax correctly. Similar to the proposed virtual property [2], the set property will indicate that dependency calculations should consider the ebuild to have zero installation cost. Similar to glep 37 [3], ebuilds that exhibit PROPERTIES=set should also define all of their dependencies in the RDEPEND variable. Other than these constraints, an ebuild which exhibits PROPERTIES=set should behave just like any other ebuild. It should be installed and uninstalled just like any other ebuild, including execution of all the normal ebuild phase functions that would be executed for any other ebuild that does not exhibit the set property. I order to determine which atoms correspond to a given set, the first step is to lookup the set name from the profile's sets configuration files. The corresponding package atom is then resolved to a specific ebuild which should exhibit the set property. The dependency atoms from this ebuild's RDEPEND variable will serve to make up the atoms of the package set. In cases when these atoms resolve to other ebuilds that exhibit he set property then those other ebuilds act as nested sets and this nesting process is recursive with no limit on the depth of nesting. The nested sets do not necessarily have to be mapped to specific set names by the profile's sets configuration files. If nested sets are anonymous in this sense then their atoms still become a part of the set that they are nested within, just as they would if they had been given a name by the profile's sets configuration files. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? [1] http://archives.gentoo.org/gentoo-dev/msg_02020c2650449920c941adf46dbf7d6f.xml [2] http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml [3] http://archives.gentoo.org/proj/en/glep/glep-0037.html - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjlxX4ACgkQ/ejvha5XGaMv2gCggj2YCW3MkcW/Y/EQUPX+V38E 4DgAnR3d4mD5Y4S2qGZRbq8md1NJnLE7 =AdHx -END PGP SIGNATURE-
[gentoo-portage-dev] [RFC] Label profiles with EAPI for compatibility checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Please consider a new eapi profile configuration file that will designate the EAPI to which any package atoms within a given layer of the profile stack must conform. This will allow package managers to bail out with an informative error message if the user accidentally selects a profile containing an EAPI that is not supported by the currently installed package manager. In order to allow mixed EAPIs in the profiles, and to avoid having to configure the EAPI in every single layer, each directory of the profile stack should be able to either override or inherit the EAPI value that may have been defined in a previous layer of the profile stack. If no EAPI has been previously defined then it can be assumed to be 0. The format of the configuration file can be very simple, containing only the EAPI value and nothing more. For example, a file containing just a single 0 character, followed by a newline, could be created at profiles/base/eapi in order to explicitly declare that atoms in the base profile conform to EAPI 0. However, this particular declaration would be redundant since the base profile does not inherit from any other profile and therefore it's EAPI would be assumed to be 0 anyway. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjmtEYACgkQ/ejvha5XGaNtSQCfXb2OQAYCEAe0Uuuu7Ou+DxyV QZsAn0VpUbKqHJP0XRZSg6mhFKeUNXui =qR8c -END PGP SIGNATURE-
Majordomo results: [gentoo-portage-dev] [RFC] Label profile
-- -BEGIN PGP SIGNED MESSAGE- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
Majordomo results: [gentoo-portage-dev] Majordomo results:
-- -- END OF COMMANDS
Majordomo results: Majordomo results: [gentoo-portage-dev]
-- -- END OF COMMANDS
[gentoo-portage-dev] Majordomo results: Majordomo results: Majordomo results: [g
-- -- END OF COMMANDS
[gentoo-portage-dev] Spam Redux
Somebody subscribed a bad list manager to the list, and caused a mail loop. I removed the offending list address now, but I don't know who did it in the first place. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
