[gentoo-dev] [RFC] unpacker.eclass extensions

2013-06-15 Thread Vadim A. Misbakh-Soloviov
As gamerlay maintainer, I'd be glad to introduce some changes to unpacker.eclass: 1) merging unpacker-nixstaller (Makeself subspecies) from gamerlay: # @FUNCTION: unpack_nixstaller # @USAGE: files to unpack # @DESCRIPTION: # Unpack nixstaller generated files # They're shell scripts with the

[gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Vadim A. Misbakh-Soloviov
Sometimes I find myself in a situation, when I need to use both RESTRICT=fetch for the main distfile and allow fetch for additional ones (langpacks, extensions and so on). Sometimes it is even impossible to split that additions into separate package, since they might want to replace some file (for

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.namewrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo Over my dead CVS

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Rich Freeman
On Sat, Jun 15, 2013 at 7:50 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On Sat, Jun 15, 2013 at 1:12 PM, Rich Freeman ri...@gentoo.org wrote: Grandstanding aside, it is probably best to take this in chunks. I just don't care to repeat for the Nth time the same reasoning for which I don't want to mainstream VCS fetching. It's just not going to happen as long as I

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Vadim A. Misbakh-Soloviov
15.06.2013 18:50, Diego Elio Pettenò пишет: Over my dead CVS access. Any reasonable/argumented objection? And, anyway, quoted part is optional behaviour that should just make ebuild-writing easy. Mandatory part is to be able to have restrict://foo.bar and downloadable things at the same time.

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Alexander V Vershilov
On 15 June 2013 15:50, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 13:48, Alexander V Vershilov wrote: Can you elaborate: do you object both proposals (about partial restrict and VCS-support) or only second one (VCS-support)? As I already said in my answer to Rich, the VCS support is XOR'd with my CVS access. And I've already spent too much

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Michał Górny
Dnia 2013-06-15, o godz. 15:56:53 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo It simply can't work.

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Rich Freeman
On Sat, Jun 15, 2013 at 8:14 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: It's just not going to happen as long as I got CVS access, it's not a threat or a grandstanding, it's a simple boolean logic statement. That IS grandstanding. I'm not saying I disagree with the position you

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Vadim A. Misbakh-Soloviov
15.06.2013 20:05, Michał Górny пишет: It simply can't work. Don't even try to implement, it's waste of time. As I already metioned to Diego — VCS part is just optional example of that things, that can be useful. Mainly idea in partial restricting. And I suggest you all (including Diego) to

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 14:06, Rich Freeman wrote: At work just about every boss I have had any respect for would have fired me on the spot for making such a statement and not retracting it At work you're also paid to for the time you spend justifying for the Nth time why a proposal is completely crazy

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 14:11, Vadim A. Misbakh-Soloviov wrote: And I suggest you all (including Diego) to discuss about that, instead of oppositing vcs-related SRC_URI ;) Then next time don't collapse two widely different proposals, especially considering that one of the two has been already discussed

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Andreas K. Huettel
Am Samstag, 15. Juni 2013, 15:15:57 schrieb Diego Elio Pettenò: On 15/06/2013 14:06, Rich Freeman wrote: At work just about every boss I have had any respect for would have fired me on the spot for making such a statement and not retracting it At work you're also paid to for the time you

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Ulrich Mueller
On Sat, 15 Jun 2013, Rich Freeman wrote: Over my dead CVS access. Grandstanding aside, it is probably best to take this in chunks. The all-or-nothing fetch restriction control does seem like a good place to start improving. I could certainly see where that could create needless problems.

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 14:34, Ulrich Mueller wrote: restrict+http: (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. nofetch+http and nomirror+http ? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Ulrich Mueller
On Sat, 15 Jun 2013, Diego Elio Pettenò wrote: restrict+http: (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. nofetch+http and nomirror+http ? Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT apply

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Luca Barbato
On 06/15/2013 02:34 PM, Vadim A. Misbakh-Soloviov wrote: 15.06.2013 18:50, Diego Elio Pettenò пишет: Over my dead CVS access. Any reasonable/argumented objection? to put in different words: We do not want to use untraceable/transient/ephemeral sources for main ebuilds, live ebuilds are corner

[gentoo-dev] Re: [RFC] SRC_URI behaviour

2013-06-15 Thread Michael Palimaka
On 15/06/2013 23:47, Ulrich Mueller wrote: On Sat, 15 Jun 2013, Diego Elio Pettenò wrote: restrict+http: (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. nofetch+http and nomirror+http ? Or the other way around:

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 14:47, Ulrich Mueller wrote: Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT apply to all of SRC_URI (as it is now) and use the new syntax to specify any exceptions from the restriction. WFM -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu —

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Pacho Ramos
El sáb, 15-06-2013 a las 12:50 +0100, Diego Elio Pettenò escribió: On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI=

Re: [gentoo-dev] [RFC] unpacker.eclass extensions

2013-06-15 Thread Markos Chandras
Hi Vadim, On 15 June 2013 09:39, Vadim A. Misbakh-Soloviov m...@mva.name wrote: # Make sure that file exists [[ -f ./$i ]] ( local type=$(file -b ${i}) case ${type} in data)

Re: [gentoo-dev] [RFC] unpacker.eclass extensions

2013-06-15 Thread Markos Chandras
On 15 June 2013 15:33, Markos Chandras hwoar...@gentoo.org wrote: Also || die does not work in subshells. http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html Sorry scratch that. I just realized || die is not inside the subshell -- Regards, Markos Chandras - Gentoo Linux

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Rick Zero_Chaos Farina
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 04:56 AM, Vadim A. Misbakh-Soloviov wrote: Sometimes I find myself in a situation, when I need to use both RESTRICT=fetch for the main distfile and allow fetch for additional ones (langpacks, extensions and so on). Sometimes it is

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Brian Dolbec
On Sat, 2013-06-15 at 15:05 +0200, Michał Górny wrote: Dnia 2013-06-15, o godz. 15:56:53 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Rich Freeman
On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with portage... Honestly, native support for

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Luca Barbato
On 06/15/2013 05:33 PM, Rich Freeman wrote: On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Rich Freeman
On Sat, Jun 15, 2013 at 11:43 AM, Luca Barbato lu_z...@gentoo.org wrote: On 06/15/2013 05:33 PM, Rich Freeman wrote: On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would

[gentoo-dev] Calling die in a subshell

2013-06-15 Thread Mike Gilbert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The devmanual warns that calling die in a subshell does not work. http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html This warning has been obsolete for some time; modern versions of Portage handle die in a subshell just fine. In

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 17:06, Mike Gilbert wrote: Are there any objections to removing this warning from the devmanual? Please, go for it. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Ulrich Mueller
On Sat, 15 Jun 2013, Mike Gilbert wrote: The devmanual warns that calling die in a subshell does not work. http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html This warning has been obsolete for some time; modern versions of Portage handle die in a subshell just fine. In

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread hasufell
On 06/15/2013 06:16 PM, Ulrich Mueller wrote: PMS doesn't guarantee that die works correctly in a subshell: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3 So the devmanual agrees with the spec, and the eclasses need to be fixed. How does that make any sense?

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 17:19, hasufell wrote: How does that make any sense? It does not, but I don't remember anybody trying to assert that PMS makes sense in quite a long time. (Yes I still think that the PMS is 90% a waste of time) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu —

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Mike Gilbert
On Sat, Jun 15, 2013 at 12:16 PM, Ulrich Mueller u...@gentoo.org wrote: Are there any objections to removing this warning from the devmanual? PMS doesn't guarantee that die works correctly in a subshell: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3 So the devmanual agrees with

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Ulrich Mueller
On Sat, 15 Jun 2013, hasufell wrote: PMS doesn't guarantee that die works correctly in a subshell: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3 So the devmanual agrees with the spec, and the eclasses need to be fixed. How does that make any sense? It makes perfect sense.

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Tom Wijsman
On Sat, 15 Jun 2013 18:16:32 +0200 Ulrich Mueller u...@gentoo.org wrote: On Sat, 15 Jun 2013, Mike Gilbert wrote: The devmanual warns that calling die in a subshell does not work. http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html This warning has been obsolete for

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Ciaran McCreesh
On Sat, 15 Jun 2013 15:56:53 +0700 Vadim A. Misbakh-Soloviov m...@mva.name wrote: Sometimes I find myself in a situation, when I need to use both RESTRICT=fetch for the main distfile and allow fetch for additional ones (langpacks, extensions and so on). Sometimes it is even impossible to split

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Ciaran McCreesh
On Sat, 15 Jun 2013 11:51:03 -0400 Rich Freeman ri...@gentoo.org wrote: The approach paludis uses just seems simpler all-around, minus the fact that it doesn't provide defaults for internals that need not be exposed (vdb and such - which admittedly aren't needed by exherbo). I've not heard

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 06:24 PM, Tom Wijsman wrote: Why not fix the specs? from council log http://www.gentoo.org/proj/en/council/meeting-logs/20120911.txt Chainsaw Okay for EAPI 5. *Nothing* gets applied retroactively. *EVER* So that means some

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Ciaran McCreesh
On Sat, 15 Jun 2013 18:24:13 +0200 Tom Wijsman tom...@gentoo.org wrote: What does it take to change future specifications to guarantee this? You can have it from EAPI 6 onwards. What's holding this from becoming guaranteed? Why not fix the specs? The specs accurately reflect Portage behaviour

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Ciaran McCreesh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Jun 2013 18:41:18 +0200 hasufell hasuf...@gentoo.org wrote: On 06/15/2013 06:24 PM, Tom Wijsman wrote: Why not fix the specs? from council log http://www.gentoo.org/proj/en/council/meeting-logs/20120911.txt Chainsaw Okay for EAPI

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 06:43 PM, Ciaran McCreesh wrote: On Sat, 15 Jun 2013 18:41:18 +0200 hasufell hasuf...@gentoo.org wrote: On 06/15/2013 06:24 PM, Tom Wijsman wrote: Why not fix the specs? from council log

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Ciaran McCreesh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Jun 2013 18:45:05 +0200 hasufell hasuf...@gentoo.org wrote: On 06/15/2013 06:43 PM, Ciaran McCreesh wrote: On Sat, 15 Jun 2013 18:41:18 +0200 hasufell hasuf...@gentoo.org wrote: On 06/15/2013 06:24 PM, Tom Wijsman wrote: Why not

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Mike Gilbert
On Sat, Jun 15, 2013 at 12:42 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 15 Jun 2013 18:24:13 +0200 Tom Wijsman tom...@gentoo.org wrote: What does it take to change future specifications to guarantee this? You can have it from EAPI 6 onwards. What's holding this from

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread hasufell
On 06/15/2013 06:56 PM, Mike Gilbert wrote: If we find that all known implementations of PMS/EAPI 4 have implemented a certain behavior, making a change to that version of PMS to properly document the behavior seems reasonable. Right, that's why my quote from the council log does not make

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Ciaran McCreesh
On Sat, 15 Jun 2013 12:56:00 -0400 Mike Gilbert flop...@gentoo.org wrote: If we find that all known implementations of PMS/EAPI 4 have implemented a certain behavior, making a change to that version of PMS to properly document the behavior seems reasonable. Part of the point of EAPI stability

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Mike Gilbert
On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 15 Jun 2013 12:56:00 -0400 Mike Gilbert flop...@gentoo.org wrote: If we find that all known implementations of PMS/EAPI 4 have implemented a certain behavior, making a change to that version of PMS

Re: [gentoo-dev] Calling die in a subshell

2013-06-15 Thread Michał Górny
Dnia 2013-06-15, o godz. 18:25:15 Ulrich Mueller u...@gentoo.org napisał(a): On Sat, 15 Jun 2013, hasufell wrote: PMS doesn't guarantee that die works correctly in a subshell: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3 So the devmanual agrees with the spec, and the

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Anthony G. Basile
On 06/15/2013 11:43 AM, Luca Barbato wrote: On 06/15/2013 05:33 PM, Rich Freeman wrote: On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is

[gentoo-dev] Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutecom, net-

2013-06-15 Thread Pacho Ramos
# Pacho Ramos pa...@gentoo.org (15 Jun 2013) # Upstream dead for ages, nothing requires it, wrongly # generated .la files (#201440). Removal in a month. rox-base/rox-clib # Pacho Ramos pa...@gentoo.org (15 Jun 2013) # No downstream maintainer for a long time, please move # to

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Michael Weber
On 06/15/2013 02:14 PM, Diego Elio Pettenò wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 22:15, Michael Weber wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. You know what? I really should just leave and see how people who think that a live ebild is a

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 22:17, Diego Elio Pettenò wrote: You know what? I really should just leave and see how people who think that a live ebild is a nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. Oh wait, I already know how that's going to happen.. bug #443448 is a nice

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Michael Weber
On 06/15/2013 11:17 PM, Diego Elio Pettenò wrote: On 15/06/2013 22:15, Michael Weber wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. You know what? I really should just leave and

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Markos Chandras
On 15 June 2013 22:21, Michael Weber x...@gentoo.org wrote: On 06/15/2013 11:17 PM, Diego Elio Pettenò wrote: On 15/06/2013 22:15, Michael Weber wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement.

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Diego Elio Pettenò
On 15/06/2013 22:21, Michael Weber wrote: Fine, we would all benefit from a environment without your snappy comments and cryptic responses. Seriously, learn some social skill in your free time. See, I cannot exactly voice what my opinion of you is on a public forum, or I would have done so.

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Michael Weber
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/15/2013 05:12 PM, Rick Zero_Chaos Farina wrote: There is currently no need for improvement in my eyes, and I'm not sure this could be considered improvement anyway. i.e. git-2.eclass provides support for environment override (and variables)

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Michael Weber
On 06/15/2013 11:24 PM, Markos Chandras wrote: Please both of you. Stop it now and take it elsewhere. Consider this a friendly warning. Agreed. Sorry for my impulsive response. I don't say thanks for the warning, but for your counseling of the mailing list. I'm on a borderline between

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Rick Zero_Chaos Farina
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 05:15 PM, Michael Weber wrote: On 06/15/2013 02:14 PM, Diego Elio Pettenò wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-15 Thread Zac Medico
On 06/15/2013 06:05 AM, Michał Górny wrote: Dnia 2013-06-15, o godz. 15:56:53 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo

[gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org

2013-06-15 Thread Robin H. Johnson
From the infra perspective, I would like to add that I support this move, I just have a few concerns on the conversion, one of which is dealt with here. I've committed my draft XSL to the gentoo/xml/htdocs/xsl location, named guidexml2wiki.xsl. It still requires some updates that I'll work on

[gentoo-dev] [23]/3 API files

2013-06-15 Thread Robin H. Johnson
Special pages and contents -- herds.xml, repositories.xml, etc.: As these are intended for other applications to use, these should go to a new site, possibly api.gentoo.org, initially fed from a git repository. This site should get backed by SSL. Here's a partial list

[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/cont

2013-06-15 Thread Patrick Lauer
On 06/16/2013 04:37 AM, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (15 Jun 2013) # Upstream dead for ages, nothing requires it, wrongly # generated .la files (#201440). Removal in a month. rox-base/rox-clib No :) I've commented out that mask in package.mask because:

Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org

2013-06-15 Thread Paweł Hajdan, Jr.
On 6/9/13 7:22 AM, Alex Legler wrote: I'd appreciate some input on below plan to move project pages to the Wiki: Alex, thanks for working on this! Some feedback: 1. How will the project pages be protected against unwanted edits? I think it's valuable to have some official pages where you know

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

2013-06-15 Thread Paweł Hajdan, Jr.
On 6/12/13 11:51 PM, Dirkjan Ochtman wrote: Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. +1 This works really well for the Gentoo