[gentoo-dev] Last rites: dev-tex/vntex
Hi, dev-tex/vntex will be removed in 30 days. Reason: Masked since early 2007. Included in tetex-3, ptex and texlive-langvietnamese. If someone wanted to keep the ebuild around for single package updates, he had plenty of time to do it. Now it is old and unmaintained and therefore will be removed on 06 Oct 2008. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] LXDE project
On 14:16 Sun 31 Aug , Ben de Groot wrote: I have therefor created an LXDE project page[2] under the Desktop top-level project. My idea is to initially start an official overlay and develop the needed packages in there. I am actively encouraging users to participate in development and maintenance, and of course I am extending the invitation to any Gentoo developers who would like to join. I don't want to spread myself too thin, and having more experienced developers involved with the project would be a good thing. Any constructive feedback is welcome! Great, thanks! For future reference, please get in touch with me to talk about new desktop subprojects. Let me know whether there's anything I can do as desktop lead to make your work easier. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpLgr1dWTntK.pgp Description: PGP signature
Re: [gentoo-dev] global USE flag overrides in metadata.xml (bug 235708)
On 00:19 Wed 03 Sep , Peter Volkov wrote: Personally I think that this is good idea to specialize global USE flags description in metadata.xml. In such case global USE flag description still correct, and we just adjust their meaning for specific package. What others think? Yes, an override is OK iff it remains consistent with the global description. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpQ1qSVxXJys.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 2 Draft
2008/9/4 Zac Medico [EMAIL PROTECTED]:
* The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
extensions, for interoperability with gitweb.
* SRC_URI supports a syntax extension which allows customization
of output file names by using a - operator.
Is it useful to have both of these? The former seems awfully
specialised for a general format like ebuilds, and can be replaced
with
COMMIT=1234...
SRC_URI=http://git.example.org/?p=foo.git;a=snapshot;h=${COMMIT};sf=tbz2
- foo-${COMMIT}.tar.bz2
Re: [gentoo-dev] [RFC] EAPI 2 Draft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
2008/9/4 Zac Medico [EMAIL PROTECTED]:
* The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
extensions, for interoperability with gitweb.
* SRC_URI supports a syntax extension which allows customization
of output file names by using a - operator.
Is it useful to have both of these? The former seems awfully
specialised for a general format like ebuilds, and can be replaced
with
COMMIT=1234...
SRC_URI=http://git.example.org/?p=foo.git;a=snapshot;h=${COMMIT};sf=tbz2
- foo-${COMMIT}.tar.bz2
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file name.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkjA3WUACgkQ/ejvha5XGaOpJgCbBUuFc2POX2nE9An065fC+b2z
zTsAoIXp+CyP6Dy15OlcdYjNktoo7/Hq
=xJss
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] EAPI 2 Draft
2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers?
Re: [gentoo-dev] [RFC] EAPI 2 Draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Leverton wrote: 2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers? Well, it's not much different from the existing file extension logic that's already built into the unpack function. I think what really matters is whether or not the majority of people see it as a useful extension. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjA4iMACgkQ/ejvha5XGaOPxwCfWolOw1zC+VbgrGrFQXqRwoXn vDoAoOLGL+PXhyCb2+cmAI4INLfO9reS =TXwO -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote: David Leverton wrote: 2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers? Well, it's not much different from the existing file extension logic that's already built into the unpack function. I think what really matters is whether or not the majority of people see it as a useful extension. I'm wondering why would one fetch a tarball instead of using git.eclass which is much better for both upstream and users (in terms of bandwidth and resources usage). - ferdy pgp4InFxofziD.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] EAPI 2 Draft
Hi,
Zac Medico [EMAIL PROTECTED]:
David Leverton wrote:
2008/9/4 Zac Medico [EMAIL PROTECTED]:
* The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
extensions, for interoperability with gitweb.
* SRC_URI supports a syntax extension which allows customization
of output file names by using a - operator.
Is it useful to have both of these? The former seems awfully
specialised for a general format like ebuilds, and can be replaced
with
COMMIT=1234...
SRC_URI=http://git.example.org/?p=foo.git;a=snapshot;h=${COMMIT};sf=tbz2
- foo-${COMMIT}.tar.bz2
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file
name.
One needs exceptions for all kind of systems, for example I had to
workaround Trac which adds ?format=raw to a tarball URI. There seems
to be a solution in Trac as the guys from fedarahosted fixed the two I
needed (tmpwatch, mlocate). So the - operator is quite useful and I
agree with David that the functionality is doubled.
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] [RFC] EAPI 2 Draft
On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Leverton wrote: 2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers? Well, it's not much different from the existing file extension logic that's already built into the unpack function. I think what really matters is whether or not the majority of people see it as a useful extension. I think the question isn't 'why is this functionality being made available'; I think to me it is useful piece of code. I question its inclusion in the PM though; I would rather see it in eutils or something similar. Arguably you could inherit a function from eutils that does SRC_URI transformation for you. SRC_URI=foo bar baz;sf=tbz2 src_uri_gitize would transform baz;sf=tbz2 into baz;sf=tbz2 - baz.tar.bz2 - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjA4iMACgkQ/ejvha5XGaOPxwCfWolOw1zC+VbgrGrFQXqRwoXn vDoAoOLGL+PXhyCb2+cmAI4INLfO9reS =TXwO -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Friday 05 September 2008, Fernando J. Pereda wrote: On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote: David Leverton wrote: 2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers? Well, it's not much different from the existing file extension logic that's already built into the unpack function. I think what really matters is whether or not the majority of people see it as a useful extension. I'm wondering why would one fetch a tarball instead of using git.eclass which is much better for both upstream and users (in terms of bandwidth and resources usage). How is using the eclass better for bandwidth usage? It won't allow for mirroring, and all users would have to checkout the repository from one place. Furthermore, you cannot have (signed) Manifests that allow integrity checks. I wonder if that is an issue in gitweb in general: Will it generate the same tarball every time? If not, that will create issues with users not using gentoo mirrors, or the mirroring system itself (because the dev could commit a Manifest for another file than the server delivers later). For what it's worth, I also see no reason to double functionality for one special case where we also create a solution for the more general one. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] EAPI 2 Draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Buchholz wrote: How is using the eclass better for bandwidth usage? It won't allow for mirroring, and all users would have to checkout the repository from one place. Furthermore, you cannot have (signed) Manifests that allow integrity checks. - From what I understand of the idea, the eclass will just change the SRC_URI field from the first case (sf=tgz) to the second case (-). Eclasses have to be sourced before the SRC_URI is determined because they can already add (and presumably alter) elements of the SRC_URI variable. So I'm not sure how this would directly affect mirroring or manifests any more than simply using the - notation? Could you explain what you mean when you say it won't allow for mirroring? Generating different tarballs is much more of an issue, and would impact on manifests too. I guess it's a try-it-and-see situation... Either way, it seems like the eclass idea would be a good compromise for those that don't want gitweb specific workarounds in the package manager, but would like to allow the flexibility for people who do? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC =crVS -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] EAPI 2 Draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Buchholz wrote: How is using the eclass better for bandwidth usage? It won't allow for mirroring, and all users would have to checkout the repository from one place. Furthermore, you cannot have (signed) Manifests that allow integrity checks. - From what I understand of the idea, the eclass will just change the SRC_URI field from the first case (sf=tgz) to the second case (-). Eclasses have to be sourced before the SRC_URI is determined because they can already add (and presumably alter) elements of the SRC_URI variable. So I'm not sure how this would directly affect mirroring or manifests any more than simply using the - notation? Could you explain what you mean when you say it won't allow for mirroring? Generating different tarballs is much more of an issue, and would impact on manifests too. I guess it's a try-it-and-see situation... Either way, it seems like the eclass idea would be a good compromise for those that don't want gitweb specific workarounds in the package manager, but would like to allow the flexibility for people who do? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC =crVS -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Friday 05 September 2008, Mike Auty wrote: From what I understand of the idea, the eclass will just change the SRC_URI field from the first case (sf=tgz) to the second case (-). Eclasses have to be sourced before the SRC_URI is determined because they can already add (and presumably alter) elements of the SRC_URI variable. So I'm not sure how this would directly affect mirroring or manifests any more than simply using the - notation? Could you explain what you mean when you say it won't allow for mirroring? I was under the impression ferdy meant to use live checkouts instead of tarballs. I might have misunderstood that. Generating different tarballs is much more of an issue, and would impact on manifests too. I guess it's a try-it-and-see situation... I think it would be a better idea to check whether this feature actually works before implementing. I just don't know a gitweb site that tars up revisions / tags to test. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
On Sat, 23 Aug 2008 13:39:58 -0700 Zac Medico [EMAIL PROTECTED] wrote: Do the name and definition of this PROPERTIES=live value seem good? Would anybody like to discuss any changes to the name, definition, or both? Not sure if 'live' is really the best choice here, as many things also apply to e.g. automated daily/nightly snapshots/builds that might also be useful to support. Maybe 'unversioned' is more accurate. Marius
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Sun, 24 Aug 2008 14:01:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: Do the name and definition of this PROPERTIES=virtual value seem good? Would anybody like to discuss any changes to the name, definition, or both? If it's only used to indicate that the package doesn't install any files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual' somehow implies that it's only applicable to packages in the 'virtual' category, which isn't the case with the given definition (as you said). Marius
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Tue, 26 Aug 2008 14:20:07 + (UTC) Duncan [EMAIL PROTECTED] wrote: I therefore believe I like just moving them all to a *virtual*/ category better, thus obviating the need for that particular property in the first place. I strongly belive that it's a horrible idea to add special meanings to certain (hardcoded) category names in the package manager. Technically, names (including categories) should only be used as identifiers, not as classifiers. Marius
Re: [gentoo-dev] News item: World file handling changes in Portage-2.2
On Sat, 16 Aug 2008 22:39:41 +0300 Petteri Räty [EMAIL PROTECTED] wrote: As per glep 42 (http://www.gentoo.org/proj/en/glep/glep-0042.html) here is the required email for a new news item. This news item is important because otherwise users will be missing updates to the system set if they continue updating their system with the usual emerge --update --deep world. Unless objections come out the new news item will be committed at the same time as rc8 (rc8 will have an update man portage page describing world_sets). Title: World file handling changes in Portage-2.2 Author: Petteri Räty [EMAIL PROTECTED] Author: Zac Medico [EMAIL PROTECTED] Content-Type: text/plain Posted: 2008-XX-XX Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/portage-2.2_rc8 As of Portage 2.2 the world set does not include the system set any more. If you want emerge --update --deep @world to update the system set too, you need to add @system to the new world_sets file in /var/lib/portage/. For more information on world_sets see man portage. Sorry for not replying earlier, I was without mail access for the last few weeks. First, regarding the news item, I'd suggest that instead of telling users to modify world_sets manually to use `emerge --noreplace @system`. Also there have been more changes that might not be as obvious and only affect people with unusual usage patterns, namely `emerge @world` without using --update or --noreplace will rebuild packages contained in @world (same is true for all other sets). Second for the suggestions on how to handle the transition: - treating 'world' and '@world' differently is a no go from my POV. One of the main reasons to implement them as sets was to remove special case code in emerge, so I'm quite opposed to adding new special cases instead. And I'm quite sure that such a separation would cause confusion, and some isues regarding (end-user) documentation. - adding a new @worldfile set to get the new behavior, and use @world for the old. That one is quite interesting, and should actually be rather simple to implement: rename the existing @world to @worldfile, create a new StaticFileSet @world that just contains @worldfile and @system (stored in /usr/share/portage), change most references in emerge from @world to @worldfile (for technical reasons, the WorldSet class is somewhat special), and add world-candidate=False to the default sets.conf - issuing a warning if 'world' is the only argument would also be a special case, but by far not as invasive as the first suggestion. I've actually considered to mark 'world' and 'system' without the set prefix as deprecated but thought it would be too invasive/annoying at this time. - another idea that hasn't been mentioned yet is that we could simply inject @system into world_sets in the portage ebuild when we detect a 2.1-2.2 upgrade (the ebuild already does a few other migrations that way). That would be the least-invasive way to keep the old behavior, but only works for poeple who haven't upgraded to 2.2 yet (not sure if that's a pro or contra) Though honestly I don't think this issue is as big as some other people make it. People might miss some updates. The same would happen if we remove packages from @system, or people switch profiles (so @system changes). Marius
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Marius Mauch wrote: If it's only used to indicate that the package doesn't install any files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual' somehow implies that it's only applicable to packages in the 'virtual' category, which isn't the case with the given definition (as you said). I like virtual, since it really gets at the spirit of what the ebuild does. empty sounds like it does nothing at all, and nocontents sounds that way to, to me. An analogy to virtual is a virtual method in OO programming - it sits at a high level, does nothing in itself, but causes underlying methods to perform the work. -Joe
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
Marius Mauch wrote: Not sure if 'live' is really the best choice here, as many things also apply to e.g. automated daily/nightly snapshots/builds that might also be useful to support. Maybe 'unversioned' is more accurate. I think the most important thing to convey with this property is that the source code can change at any time, since it is pulled live from upstream. unversioned doesn't really imply this - it makes it sound like it simply has no version. Maybe something akin to volatile would work, but I still like live, personally. -Joe
Re: [gentoo-dev] News item: World file handling changes in Portage-2.2
Marius Mauch wrote: First, regarding the news item, I'd suggest that instead of telling users to modify world_sets manually to use `emerge --noreplace @system`. ++ Second for the suggestions on how to handle the transition: - treating 'world' and '@world' differently is a no go from my POV. One of the main reasons to implement them as sets was to remove special case code in emerge, so I'm quite opposed to adding new special cases instead. And I'm quite sure that such a separation would cause confusion, and some isues regarding (end-user) documentation. +++ -Joe
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Fri, 05 Sep 2008 09:38:32 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Marius Mauch wrote: If it's only used to indicate that the package doesn't install any files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual' somehow implies that it's only applicable to packages in the 'virtual' category, which isn't the case with the given definition (as you said). I like virtual, since it really gets at the spirit of what the ebuild does. empty sounds like it does nothing at all, and nocontents sounds that way to, to me. Except it doesn't. A virtual ebuild: * installs nothing * does nothing * should be treated as being very quickly installable * should be treated as having zero cost for installs The property proposed corresponds to only the last of these. An analogy to virtual is a virtual method in OO programming - it sits at a high level, does nothing in itself, but causes underlying methods to perform the work. Virtual methods in OO can do lots. You're thinking 'pure virtual' or 'abstract'. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: Except it doesn't. A virtual ebuild: * installs nothing * does nothing I'd say that virtual does indeed do something: it pulls in other packages. * should be treated as being very quickly installable * should be treated as having zero cost for installs The property proposed corresponds to only the last of these. Still, the term virtual fits the spirit of the idea well. Virtual methods in OO can do lots. You're thinking 'pure virtual' or 'abstract'. Yes, you are correct (pure virtual is what I was thinking). -Joe
Re: [gentoo-dev] [RFC] EAPI 2 Draft
Alec Warner kirjoitti: On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico [EMAIL PROTECTED] wrote: David Leverton wrote: 2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers? Well, it's not much different from the existing file extension logic that's already built into the unpack function. I think what really matters is whether or not the majority of people see it as a useful extension. I think the question isn't 'why is this functionality being made available'; I think to me it is useful piece of code. I question its inclusion in the PM though; I would rather see it in eutils or something similar. Arguably you could inherit a function from eutils that does SRC_URI transformation for you. SRC_URI=foo bar baz;sf=tbz2 src_uri_gitize would transform baz;sf=tbz2 into baz;sf=tbz2 - baz.tar.bz2 I think this is better than having it in EAPI2. You could even move SRC_URI above inherit and automatically transform the URI. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Friday 05 September 2008 00:58:05 Zac Medico wrote: * Default phase function implementations for older EAPIs are accessible via functions having names that start with 'eapi', followed by the EAPI value. Based on the lack of use cases or further responses to [1] I would suggest removing this feature from eapi 2. [1] http://archives.gentoo.org/gentoo-dev/msg_419885810c399b4cebbc62bd96081f87.xml -- Bo Andresen signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Questions about stabilization requests
Some of the packages that I use are ~arch keyworded right now and I was wanting to ask some questions about when to file stabilization requests and about how much information needs to be provided when filling them. 1) How long do you recommend using a package before filing a stabilization request? 2) Should I file stabilization requests on software that works mostly as in everything that I use it for normally but I can force it to fail if I feed it some really strange input or contrive a specific set of options that will cause invalid or incorrect output. 3) Should I provide a patch that removes the ~arch keyword when I file the stabilization request? Thanks.
Re: [gentoo-dev] Questions about stabilization requests
On Fri, Sep 5, 2008 at 12:06 PM, Robert R. Russell [EMAIL PROTECTED] wrote: Some of the packages that I use are ~arch keyworded right now and I was wanting to ask some questions about when to file stabilization requests and about how much information needs to be provided when filling them. 1) How long do you recommend using a package before filing a stabilization request? 2) Should I file stabilization requests on software that works mostly as in everything that I use it for normally but I can force it to fail if I feed it some really strange input or contrive a specific set of options that will cause invalid or incorrect output. 3) Should I provide a patch that removes the ~arch keyword when I file the stabilization request? 3) No, we have tools that do this for us. -Alec Thanks.
[gentoo-dev] Re: Questions about stabilization requests
Hi, Robert R. Russell [EMAIL PROTECTED]: 1)How long do you recommend using a package before filing a stabilization request? Usually 30 days in ~arch and no bugs open. Though this can differ, for example for big software as Gnome, KDE or Mozilla products. 2)Should I file stabilization requests on software that works mostly as in everything that I use it for normally but I can force it to fail if I feed it some really strange input or contrive a specific set of options that will cause invalid or incorrect output. Try to sort it out with upstream (original package author). Depends on the problem, if an older stable version shows the same behavior it should be no show-stopper. 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] Jeeves IRC replacement now alive - Willikins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jorge Manuel B. S. Vicetto wrote: | On Wed, 6 Aug 2008, 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. | Hi once again. Robin seems like we forgot to ask you to add Willikins to #gentoo-userrel. The lead is tsunam and either him or me can be your points of contact there. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjBwPIACgkQcAWygvVEyAJrswCeNpnMOEskkqJ0+VHUx7BglYFd nQkAnjUNNTksze32SjYNvJdrQDihZuZ6 =jBsH -END PGP SIGNATURE-
[gentoo-dev] Re: Questions about stabilization requests
Christian Faulhammer [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 05 Sep 2008 21:47:59 +0200: 2) Should I file stabilization requests on software that works mostly as in everything that I use it for normally but I can force it to fail if I feed it some really strange input or contrive a specific set of options that will cause invalid or incorrect output. Try to sort it out with upstream (original package author). Depends on the problem, if an older stable version shows the same behavior it should be no show-stopper. Also, consider merging with FEATURES=test and the test USE flag if appropriate as well. If a package fails its tests and doesn't have RESTRICT=test turned on in the ebuild, and if the previous version passed the tests, it's not likely to be stabilized. If the previous version failed the tests as well, for everyone, then in theory, RESTRICT=test should be on, and the fact that it isn't indicates a problem with your specific installation (either of that package or something else). However, theory doesn't always match reality as I'm sure you've observed by now. In any case, it's certainly worth checking for stabilization bugs for previous versions and seeing what the comments on testing were for them, then either exploring the problem locally or filing a bug as appropriate. -- 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
