Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
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 Chromium team, where we have just hard masked packages and ~arch packages right in the tree. It helps with earlier detection of problems, especially with ~arch packages. I also know there are developers who are using the hard masked packages (thanks!) and I'd like to make that as easy as possible. Also, because no overlays are needed, we are all on the same page about other packages installed on the system. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
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 only Gentoo devs can edit them. 2. How will the staffing needs page be updated after dropping gorg? 3. How secure is the wiki? Do we have regular backups and security updates procedures in place? I know you're member of the security team and infra team is doing its job well, but I just wanted to check. Dynamic web applications arguably have bigger attack surface than effectively a bunch of static files only editable after you gain server access. Paweł signature.asc Description: OpenPGP digital signature
[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
On 06/16/2013 04:37 AM, Pacho Ramos wrote: > # Pacho Ramos (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: dependency.bad136 rox-base/pager/pager-1.1-r2.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: amd64(default/linux/amd64/13.0) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: amd64(default/linux/amd64/13.0/desktop) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: amd64(default/linux/amd64/13.0/desktop) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: amd64(default/linux/amd64/13.0/desktop/gnome) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: amd64(default/linux/amd64/13.0/desktop/gnome) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: amd64(default/linux/amd64/13.0/desktop/kde) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: amd64(default/linux/amd64/13.0/desktop/kde) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: amd64(default/linux/amd64/13.0/developer) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: amd64(default/linux/amd64/13.0/developer) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: sparc(default/linux/sparc/13.0) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: sparc(default/linux/sparc/13.0) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: sparc(default/linux/sparc/13.0/desktop) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: sparc(default/linux/sparc/13.0/desktop) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: sparc(default/linux/sparc/13.0/desktop/gnome) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: sparc(default/linux/sparc/13.0/desktop/gnome) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: sparc(default/linux/sparc/13.0/desktop/kde) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: sparc(default/linux/sparc/13.0/desktop/kde) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: DEPEND: sparc(default/linux/sparc/13.0/developer) ['>=rox-base/rox-clib-2.1.9-r2'] rox-base/pager/pager-1.1-r2.ebuild: RDEPEND: sparc(default/linux/sparc/13.0/developer) ['>=rox-base/rox-clib-2.1.9-r2']
[gentoo-dev] [2&3]/3 API & files
> 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 of the ones I know about: http://www.gentoo.org/proj/en/overlays/repositories.xml http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml http://www.gentoo.org/main/en/mirrors3.xml Both of these are broken I think: http://www.gentoo.org/proj/en/perl/outdated-cpan-packages.xml http://www.gentoo.org/proj/en/perl/outdated-cpan-packages-perl-experimental.xml - Do you know of more? - How can we better encourage these to move to an API site? - Some of these are meant for human consumption, others are meant for tool consumption, should be differentiate? > Image resources: > These can be uploaded to the Wiki. How can we ensure later that the media files don't get deleted? > Other files and downloads: > Until proper project file hosting is implemented, again a simple > git-backed static site, possibly projects.gentoo.org. Please don't put lots of binary files in Git. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] [1/3] Automatic *XML->Wiki wiki.gentoo.org
>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 soon > (such as handling internal links) as I'll be using it more and more for the > guides on gentoo.org/doc/en to move to the wiki as well. > ProjectXML generates towards GuideXML, so should be usable chained. It would be nice to move the foundation/ content to the Wiki as well I think. > PS An ebuild for a single stylesheet seems like overkill to me, but i've > been proven incorrect in the past... I think it would help a lot of the devs that are put off by the concept of XML/XSLT. Just give them a little wrapper script to generate wiki output. One of my large concerns was how to handle some of the tag conversion. We have a lot of custom tags, plus some interesting behavior in some tags. Sven's XSL makes a very good start, but somebody needs to put in some TLC for the following tags in conversion, and/or can we have it emit something useful so we know when we hit a tag that's missing in the XSLT. Here's my list of tags found in proj/ that aren't in the XSLT so far: (the "/>" is just because I collapsed the tag of any attributes, there probably needs to be an audit of how the XSL handles attributes). 179 145 74 (optional attribute link) 27 25 18 15 (optional attribute position) 9 (attribute resource) 7 7 7 7 7 6 (attribute ref) 4 2 2 2 2 2 2 2 1 1 1 1 1 (attribute name) 1 -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 06:05 AM, Michał Górny wrote: Dnia 2013-06-15, o godz. 15:56:53 "Vadim A. Misbakh-Soloviov" 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. Don't even try to implement, it's waste of time. Just grep the tree, see how various packages use VCS-es. There's too many differences, too many needs and -- most importantly -- VCS-es change over time much more quickly than, say, unpackers. Even *if* we get a SRC_URI VCS support that works for all consumers, and that'd be awfully hard to do properly, it will eventually stop being 'good enough' and require further changes. It will just become never-ending story for a minor benefit. How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 -- Thanks, Zac
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-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 then. > Okay now we are grandstanding the grandstanding. Please, let's keep to technical issues and not intentionally antagonize people. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvOz1AAoJEKXdFCfdEflK3UEP/i/Y+LCRRkZ3w6D+45BVhmVr VDpEiTZMt1DhJpm/Wu9eYwyfB/dVDHu027KNRWlyrPnBA/nwo0KqYR8lnqZFVcvS mLXf5dIy0MarVO1AsbyOFpbkSfujhlZwFLOl7lCk2fh/biPVdMjaSnOoP9K1Ii0X mhrh2B84kSgRgsLonp1pMdtP4u+jnpMxA82UOxe62tzw04WroOh1BZsc7opQM3t/ ex7td5lfkQJv8kH03+GoxhV1svORo9zoXpbQtvPGvYDBOGY2l/6kmDMCOOZKVl9A h1xC4VGUPElp6h88lHkMXOfR6RazdXt380e/vXwONdc3ciaG1Z/ilNAVv1DLZTFD rowXf0imuo9INCwsTPYPwWYP/wfHfZ3TMPkhz7j9BV7mJqkfbvpI6uPU5CJNQNls I79N0RBWp+oeMVF9CXee2s7JEmwOAvsMPPTpe0fI/UHJntnEBTWdCOlnfyFK2C/9 9/BlI3Jnc6y/bDCzleavEEWql7ZDDUac6JBC3hl29lbqrIulLk5HzI7FgfP/8x+/ 6482AeNlpE/xPXuTiwEK0NWeHtbECzqA8u2XA3EGFzEQ9bZQ0xxojH+Z+XZW6ak0 Na6ShPu3P0PNH0PYCazgS5kfyvpoS0fXpPyfO1UVNpGi4bQx1DjKBlgWstdrgh7b PKVCPTD/xh/ia6qHzbjM =EP39 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 advocation against "abusive" or "destructive" behavior leeding to the last two retirements and just leaving these people. I hate the overlay/fork symptomatic, and I have put a lot of effort into making Gentoo into my personal understanding of Linux, but i'm considering stepping down to a overlay basis and avoid all the bitching and alpha-male stupidity. Bye, Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-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) for branches, commits and repos, for example EGIT_REPO_URI= Hard to cover/encode this functionality in your proposed urls. These look - by the way - a lot like the "new" packer-4.something git url in Archlinux/AUR. "our" VCS eclasses should still be superior in functionality. ++ for global RESTRICT="fetch|mirror" with overrides in both ways on per url basis as prefix to the protocol, like nomirror+http:// and fetch+git:// . But this needs tivial (?) adaption in every VCS eclass. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlG83TcACgkQknrdDGLu8JAq/wEAmUQkeQaLY8FVGZpO9YNShR43 DQ4hrgT1TNSnUQcwzZQBAImK9nurCVcUn4LJSBD0mtCQah2VVo1VfTUzeoMJs1Tt =B9vk -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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. Maybe you should think twice about what _you_ have been doing, rather than worrying about my social skills. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15 June 2013 22:21, Michael Weber 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. >>> Step away then. >> >> 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. > Fine, we would all benefit from a environment without your snappy > comments and cryptic responses. Seriously, learn some social skill in > your free time. > Please both of you. Stop it now and take it elsewhere. Consider this a friendly warning. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 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. Fine, we would all benefit from a environment without your snappy comments and cryptic responses. Seriously, learn some social skill in your free time. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 example. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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
[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-
# Pacho Ramos (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 (15 Jun 2013) # No downstream maintainer for a long time, please move # to sys-kernel/linux-firmware that is actively maintained # (#232043). Removal in a month. sys-firmware/iwl3945-ucode # Pacho Ramos (15 Jun 2013) # Doesn't start (#298056), upstream dead for ages and # not distribution still providing it. Removal in a month. rox-extra/downloadmanager # Pacho Ramos (15 Jun 2013) # Fails to build with latest automake (#426524), upstream # dead. Removal in a month. sys-cluster/mpi-dotnet # Pacho Ramos (15 Jun 2013) # Needs a downstream maintainer, bundles a lot of libs # (#432508), it's not clear on what is really depending # (#466830). Removal in a month. media-tv/livestation # Pacho Ramos (15 Jun 2013) # Upstream unresponsive, building problems (#435684), # incompatible with mono-3. Removal in a month. dev-lang/boo # Pacho Ramos (15 Jun 2013) # Dead since 2009, doesn't compile with eds >= 3.6 # (#448898). Removal in a month. gnome-extra/contacts # Pacho Ramos (15 Jun 2013) # Not compatible with current kernels as it doesn't # support v4l2 (#452956). Removal in a month. net-im/qutecom # Pacho Ramos (15 Jun 2013) # Upstream dead and doesn't compile anymore (#455784), # removal in a month. net-fs/djmount # Pacho Ramos (15 Jun 2013) # Unmaintained and still requiring old gtkhtml (#458952). # Removal in a month. dev-python/gtkhtml-python =gnome-extra/gtkhtml-2.11.1 app-office/osmo # Pacho Ramos (15 Jun 2013) # Discontinued in 2012 (#470760). Removal in a month. app-office/taxbird # Pacho Ramos (15 Jun 2013) # Upstream stalled, improper rendering (#470818), # use app-editors/efte instead. Removal in a month. app-editors/fte # Pacho Ramos (15 Jun 2013) # Not used for years and dead (#471180). Removal in a month. dev-util/monodoc # Pacho Ramos (15 Jun 2013) # Finally banshe didn't use it and, then, it's obsolete and # dead (#471190). Removal in a month. dev-dotnet/njb-sharp # Pacho Ramos (15 Jun 2013) # Dead for ages, use iwl3945 from kernel instead (#472296). # Removal in a month. net-wireless/ipw3945 net-wireless/ipw3945-ucode net-wireless/ipw3945d signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 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 overlays is something paludis gets right - the main tree is just another tree and you prioritize them. Not sure it is a great idea in practice. lu There was a period where Zorry and I were working on the hardened toolchain off the hardened-dev overlay. Migrating it back to the tree was a pita. Unless the stuff in the overlay is orthogonal to the main tree, you will effectively be creating forks which are not easily merged. Repositories in other distros (eg debian) normally just add new .debs. They don't override deeper structures such as toolchains and core utilities. We can overrride *anything* in the portage tree like eclasses making overlays a more serious matter. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Calling die in a subshell
Dnia 2013-06-15, o godz. 18:25:15 Ulrich Mueller 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 eclasses need to be > >> fixed. > > > How does that make any sense? > > It makes perfect sense. The specification doesn't require that the > package manager's die function works in a subshell, so ebuilds and > eclasses cannot rely on such behaviour. > > If you want a different behaviour for future EAPIs, then PMS needs to > be changed. And there's a bug open for it already: https://bugs.gentoo.org/show_bug.cgi?id=465008 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh wrote: > On Sat, 15 Jun 2013 12:56:00 -0400 > 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. > > Part of the point of EAPI stability is that it doesn't just apply to > current versions of package manglers. > So look back at the first versions which implemented EAPI 4 support, and see what the behavior was implemented at the point in time.
Re: [gentoo-dev] Calling die in a subshell
On Sat, 15 Jun 2013 12:56:00 -0400 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. Part of the point of EAPI stability is that it doesn't just apply to current versions of package manglers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
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 sense.
Re: [gentoo-dev] Calling die in a subshell
On Sat, Jun 15, 2013 at 12:42 PM, Ciaran McCreesh wrote: > On Sat, 15 Jun 2013 18:24:13 +0200 > Tom Wijsman 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 at the time the specs > were approved. The point of a stable EAPI is that once approved it > doesn't change. > >From the council log, the main objection I saw was that we didn't want to change the behavior of existing ebuilds. In this particular case, we know that Portage has been properly handling die in a subshell since at least EAPI 4 was approved. I don't use Paludis, but we may have a similar situation there. 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.
Re: [gentoo-dev] Calling die in a subshell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Jun 2013 18:45:05 +0200 hasufell wrote: > On 06/15/2013 06:43 PM, Ciaran McCreesh wrote: > > On Sat, 15 Jun 2013 18:41:18 +0200 hasufell > > 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 > > > >> Okay for EAPI 5. *Nothing* gets applied > >> retroactively. *EVER* > > > >> So that means some people think it doesn't even matter what the > >> issue is. We never fix the spec, we just enhance it. > > > >> Oh, you asked for reasoning... > > > > If you want the reasoning for that decision, you should look at > > the entire log, and not just one line of it. > > > > > > I was not talking about that decision. Stop derailing threads on -dev. Then I appear to have misunderstood what you wanted reasoning for. Please explain further. Chances are I can give you an answer, since I've been involved in most of the policy-related discussions for EAPIs and PMS. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlG8m0IACgkQ96zL6DUtXhETyACg0WVMQ4QslQezKtzOCpo+gGys tNsAoLq4a15J0hhNG657HvLckBXw++f3 =+LFr -END PGP SIGNATURE-
Re: [gentoo-dev] Calling die in a subshell
-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 > 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 > >> Okay for EAPI 5. *Nothing* gets applied >> retroactively. *EVER* > >> So that means some people think it doesn't even matter what the >> issue is. We never fix the spec, we just enhance it. > >> Oh, you asked for reasoning... > > If you want the reasoning for that decision, you should look at > the entire log, and not just one line of it. > > I was not talking about that decision. Stop derailing threads on -dev. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRvJoRAAoJEFpvPKfnPDWzSE4H/iFVg/nfbMczic8xj7h/46A5 noMJ29KdJYaT9CKan9gD3vEpH8GuPwaZYSXIrfagPI3FV7ovJS6+hluGuTuzoaiQ FL9Zh3aam4mO6P5ds7yKz53Her5uM6N/wf58/81EFy4bVtNebWDbYmD8xvC/oe7i U6k4gH/PWxSd8HJCngA5lRk4/xLPeR5YKfWsvOOiQEJ+908s8Vw7nEtGIvlXKRjN +ujTlxW182jauWlV0S92KgNdsMqWk8OctJnWT2G02PqqQ6DzXkxUeKbakN9STbVM SVVbWJLTTKvQ+lfYGcIJroaA7RhR0GQqQ6HvebfIrgQiTY6kfzHpQqElA9iH6qs= =2cmH -END PGP SIGNATURE-
Re: [gentoo-dev] Calling die in a subshell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Jun 2013 18:41:18 +0200 hasufell 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 > > Okay for EAPI 5. *Nothing* gets applied retroactively. > *EVER* > > So that means some people think it doesn't even matter what the issue > is. We never fix the spec, we just enhance it. > > Oh, you asked for reasoning... If you want the reasoning for that decision, you should look at the entire log, and not just one line of it. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlG8mb0ACgkQ96zL6DUtXhFoiQCaA5Y+T4UY2lvzGFg8VZXcl4df 0VMAoJf2dqE3T6ztIKCaMc/jXzTUxJOw =bD6A -END PGP SIGNATURE-
Re: [gentoo-dev] Calling die in a subshell
On Sat, 15 Jun 2013 18:24:13 +0200 Tom Wijsman 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 at the time the specs were approved. The point of a stable EAPI is that once approved it doesn't change. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
-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 Okay for EAPI 5. *Nothing* gets applied retroactively. *EVER* So that means some people think it doesn't even matter what the issue is. We never fix the spec, we just enhance it. Oh, you asked for reasoning... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRvJkuAAoJEFpvPKfnPDWz3tQH/2obXhpX8yDpmJJdzu5xdEOK I5K+RM8FJoqdNwTe/V1DPvr/aNfr8dUBCisge6mjJ999pb1jVG3FhTNIwFBOI2UE HZeMdnUtvSv3ind6FyL4bpRYGLbk9iTHEvOrZd0P92cEhtawyLwjDx4r2Ux+0ucM y5UaLXQlFw9tu8bW/eyouY7an0hg6CzMbGzImjAWGgb6O/PtTzcm0UWPZrNiQWZ7 jORvS1m/MHrJLM3EGabUsgp+ak6QOEeVKILC2YNe3XjWWhMlLNKt14BWLiWngkog LUnVDJ7eDyJjbMAcAqAW48rHE0dxUVgexQC7bMd5pLSRTuucOQGQmf9mrFoiVeo= =gerD -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, 15 Jun 2013 11:51:03 -0400 Rich Freeman 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 people ask for defaults like that before. Most people, when configuring, get these files created automatically for them anyway, and they're useful to have around so you know what to tweak. *shrug* It would be trivial to do a per-distribution default config that gets overridden. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, 15 Jun 2013 15:56:53 +0700 "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 even impossible to split that additions into separate > package, since they might want to replace some file (for example, Dear > Esther's translations). > > So, in that case, I think, it'd be useful to change SRC_URI > behaviour a bit: > > for example: > > SRC_URI=" > restrict://dearesther-linux-06082013-bin #fetch restrict > linguas_ru? > ( http://www.dear-esther.com/translations/DE_Russian.rar ) > linguas_hu? > ( http://www.dear-esther.com/translations/DE_Hungarian.rar ) > linguas_hu2? > ( http://www.dear-esther.com/translations/DE_Hungarian2.rar ) " > Alternatively it can be even: > > SRC_URI=" > restrict+http://foo.bar/moo-123.run # mirror-restrict or > specifying a link for fetch-restrict (like for oracle-jdk) Syntax-wise, one of the proposals for dealing with the explosion of *DEPEND variables is a single variable plus labels. The same syntax could be used here, so you'd do: SRC_URI="http://blah/blah restrict: http://blah/other"; and so on, with the usual parentheses for restricting scope of labels. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
On Sat, 15 Jun 2013 18:16:32 +0200 Ulrich Mueller 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 some time; modern versions of > > Portage handle die in a subshell just fine. > > > In fact, at least a couple of eclasses rely on this behavior. For > > example, python-r1 uses subshells created by multiprocessing.eclass > > to implement parallel "sub-phase" functions, any of which may call > > die on failure. > > > 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 the spec, and the eclasses need to be > fixed. What does it take to change future specifications to guarantee this? What's holding this from becoming guaranteed? Why not fix the specs? When we're considering changing this, just a reference isn't enough; please state why it is "_not_ guaranteed". What is the reasoning? Thank you in advance. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
> 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. The specification doesn't require that the package manager's die function works in a subshell, so ebuilds and eclasses cannot rely on such behaviour. If you want a different behaviour for future EAPIs, then PMS needs to be changed. Ulrich
Re: [gentoo-dev] Calling die in a subshell
On Sat, Jun 15, 2013 at 12:16 PM, Ulrich Mueller 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 the spec, and the eclasses need to be > fixed. > > Ulrich > I see mgorny has already filed a bug. https://bugs.gentoo.org/show_bug.cgi?id=465008 So, I guess I will just patiently wait for EAPI 6.
Re: [gentoo-dev] Calling die in a subshell
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 — http://blog.flameeyes.eu/
Re: [gentoo-dev] Calling die in a subshell
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
> 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 fact, at least a couple of eclasses rely on this behavior. For > example, python-r1 uses subshells created by multiprocessing.eclass > to implement parallel "sub-phase" functions, any of which may call > die on failure. > 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 the spec, and the eclasses need to be fixed. Ulrich
Re: [gentoo-dev] Calling die in a subshell
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/
[gentoo-dev] Calling die in a subshell
-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 fact, at least a couple of eclasses rely on this behavior. For example, python-r1 uses subshells created by multiprocessing.eclass to implement parallel "sub-phase" functions, any of which may call die on failure. Are there any objections to removing this warning from the devmanual? Also, I believe there may be a question or two on the recruiting quizzes that would need to be updated. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlG8kQUACgkQC77qH+pIQ6RMcAD/Ub0qkpXi/6tjNC/vHTXr2lLu iprwtszsDnZGLOkmVKcA/R85pTIBT3Udo0Gc2/g2TJo6uzG8ppDbMc9bSHMgQtFf =1qx7 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 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 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 overlays is something paludis gets right >> - the main tree is just another tree and you prioritize them. > > Not sure it is a great idea in practice. This is how virtually all other distros operate - they ship with a list of repositories and the user controls which ones are in use. All such a change would do is make it easier to manage overlays - you'd certainly not be required to use them. Plus, right now with Gentoo there is no way to set an overlay as being LOWER priority than the main tree - so that you can grab packages not supported in main from an overlay but still use the main packages when available. That is, unless you set up the overlay as your main tree and set up portage as an overlay. 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). Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 05:33 PM, Rich Freeman wrote: > On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec 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 overlays is something paludis gets right > - the main tree is just another tree and you prioritize them. Not sure it is a great idea in practice. lu
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec 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 overlays is something paludis gets right - the main tree is just another tree and you prioritize them. What I don't like about paludis is that it exposes a lot of implementation details in its config files that are probably best defaulted away (unless that has changed), but having /etc/portage/repositories.d with a bunch of files that each contain a URI and a priority and maybe other optional parameters would be nice. Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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" 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. Don't even try to implement, it's waste of time. > Just grep the tree, see how various packages use VCS-es. There's too > many differences, too many needs and -- most importantly -- VCS-es > change over time much more quickly than, say, unpackers. > Well, there is an app in gentoo that can already handle every VCS type. It could easily be modified to handle the above syntax. The portage mods would also not be difficult to interface to it. The BAD!!! part is that it would require even more time for portage to sort out the VCS deps that would need to be added to it's dep calculations after checking the SRC_URI. GOD!, it's already getting slower than it was many years ago before Brian's pkgcore optimizations began to be applied. Not to mention GB's of memory and multiple cores now available that wasn't those many years ago... 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... > Even *if* we get a SRC_URI VCS support that works for all consumers, > and that'd be awfully hard to do properly, it will eventually stop > being 'good enough' and require further changes. It will just become > never-ending story for a minor benefit. > also, agreed
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-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 even impossible to split that additions into separate > package, since they might want to replace some file (for example, Dear > Esther's translations). > > So, in that case, I think, it'd be useful to change SRC_URI behaviour a > bit: > > for example: > > SRC_URI=" > restrict://dearesther-linux-06082013-bin #fetch restrict > linguas_ru? ( http://www.dear-esther.com/translations/DE_Russian.rar ) > linguas_hu? ( http://www.dear-esther.com/translations/DE_Hungarian.rar ) > linguas_hu2? ( > http://www.dear-esther.com/translations/DE_Hungarian2.rar ) > " > Alternatively it can be even: > > SRC_URI=" > restrict+http://foo.bar/moo-123.run # mirror-restrict or specifying a > link for fetch-restrict (like for oracle-jdk) > " I think something like this would be extremely valuable. Sometimes one file is fetch restricted and the rest are not and we currently don't handle that at all. If you want to write an implementation for it, I think it's great. > > 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 > " > > And it can also be extendable: > > SRC_URI=" > hg+http://prosody.im/trunk > modules? ( hg+https://prosody-modules.googlecode.com/hg ) > " I don't quite agree with "Over my dead CVS access" but yeah, this isn't really a great idea or needed. The current way to fetch live things is both functional and simple enough to be in very wide use. There is currently no need for improvement in my eyes, and I'm not sure this could be considered improvement anyway. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvIR6AAoJEKXdFCfdEflKns8QAJq4N0VDwoLTda5ptmEXhrH9 O6CBNAvz+f4cG/lA9bKRxqjWfce44KQbSCO/nieabLLNTNEtNn+xbdz5AHGJxEKa muxJNhHiUNjqN6J9IyXNqlpV1hC0mrxroN9hTL7HnryJKzLXx7t+IIpnjyFZDdho bw9PH1boAt7YN4FRctoV3ALAXU3zY+v/rJNAoDAwfajteZRipRPEnfGEVeuKjm7o 8PY39eBGmgKzQLoz67RTVVgNwOnsyHeJWJX8XWXaURK/2Lh/jBOdSP23xgh50K20 e4zDdRYHP6YH0vFraIjo9d17NtuuzI3SW78BL8JMHdNbQl7XY5khN/Z/KuKy3ydH ccQba25Snkuz0tL+DBnpMb5JkLz02Jup2ug6VqTPwCTtCykRvDF9jf0JLEcNfEd2 8Tkqn4Jah5+zqYox0xIxlJmwLvnlH8Jc7OLuZEIEjt4x3tEXf8mDSSpWV90aI+A2 7dHi9ealEPAPTdt7LqHuJ6ic7akPH4o/lTE+Yp/OcSIUrAfWThxiLUkgD3vbBh/E ZzQFuIqrtptXWP8jGhw01bcqRp6MfOSuCe5G6pEdR0N8Ud5qnyZyPWeMf/1hUxMy g4RMge28KDscnQy+Z0D0BNGSyYuru5mP+vLnfqKHnUjNzxSSbIXj3F98nXykhVvQ SyGs/KBmBdtLVGqrqVWl =gBw2 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On 15 June 2013 15:33, Markos Chandras 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 Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
Hi Vadim,
On 15 June 2013 09:39, Vadim A. Misbakh-Soloviov wrote:
> # Make sure that file exists
> [[ -f "./$i" ]] && (
> local type=$(file -b ${i})
> case ${type} in
> data)
> tar -xJf "./$i"
> ;;
> gzip*)
> tar -xzf "./$i"
> ;;
> esac
> ) || die "Failed to unpack $i"
> done
> }
>
I have a couple of questions. Why sub-shell here? My understanding is
that first you need to make sure the
file exists and then unpack it. Also || die does not work in subshells.
http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html
> 2) It'd be also nice to detect mojo installers (most of the time,
> they're "*-bin" or "*Installer" ELF32 sfx-archives) and pass them to
> unpack_zip by default.
> Unfortunately, I've no free time ATM, but if it is needed, I can write
> prototype for Mojo unpacking.
>
We can only merge what you show us for review :)
--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 > wrote: > > 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 access. > > > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ Could you please reply with some reasoning instead of that kind of reply? At least for me, it seems pretty authoritative :/ Thanks a lot
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 — http://blog.flameeyes.eu/
[gentoo-dev] Re: [RFC] SRC_URI behaviour
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: {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.
Ulrich
I like this idea.
Best regards,
Michael
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 cases. Ruby related stuff had it worst regarding mis-packaging and total reliance on git with horrid stories they might tell you later over a large coffee. > 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. In fact the restrict part got some proposals and not a terse and stern reject. lu
Re: [gentoo-dev] [RFC] SRC_URI behaviour
> 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 to all of SRC_URI (as it is now) and use the new syntax to
specify any exceptions from the restriction.
Ulrich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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
> 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. It just hasn't been much of an issue > because fetch restriction is rare. Mirror restriction is likely a > bigger problem even if it is somewhat user-invisible. Do we really > want to hammer something like dev.gentoo.org for patches that aren't > properly mirrored because the original source cannot be? Trying to get this thread back on track: This part was already proposed in bug 371413. I guess the main problem is to come up with a good syntax for SRC_URI or RESTRICT. "restrict+http:" (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. Ulrich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 spend justifying for the > Nth time why a proposal is completely crazy and something that no sane > people would accept. > > Nobody pays me to waste my time in explaining *again* why VCS ebuilds > should be a corner case and not something to spend time making easier to > create (because that's what it boils down to). How about a blog link or a pointer to an old thread instead? -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 to death. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 and something that no sane people would accept. Nobody pays me to waste my time in explaining *again* why VCS ebuilds should be a corner case and not something to spend time making easier to create (because that's what it boils down to). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 discuss about that, instead of oppositing vcs-related SRC_URI ;) Actually, I've some more words to protect VCS links in SRC_URIs, but I'd be quiet on that, untill discussion will go in right way ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 8:14 AM, Diego Elio Pettenò 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 advocate, but saying "do it my way or I'll quit" is basically saying that reasoning besides the community has to add to the balance of the choice their desire to have your contributions. 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 (regardless of whether they ended up making the decision I was advocating for). They'd have been right to do so - the cost to an organization of tolerating such behavior is higher than the benefits any individual can offer. It is possible to agree with your argument and fault your communication style at the same time. Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
Dnia 2013-06-15, o godz. 15:56:53 "Vadim A. Misbakh-Soloviov" 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. Don't even try to implement, it's waste of time. Just grep the tree, see how various packages use VCS-es. There's too many differences, too many needs and -- most importantly -- VCS-es change over time much more quickly than, say, unpackers. Even *if* we get a SRC_URI VCS support that works for all consumers, and that'd be awfully hard to do properly, it will eventually stop being 'good enough' and require further changes. It will just become never-ending story for a minor benefit. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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 time on it again, so don't expect further mail from me on the topic. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15 June 2013 15:50, Diego Elio Pettenò wrote: > > On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov > wrote: >> >> >> 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 access. > Can you elaborate: do you object both proposals (about partial restrict and VCS-support) or only second one (VCS-support)? It seems that there were no technical discussions about first one and it seems quite reasonable. -- Alexander
Re: [gentoo-dev] [RFC] SRC_URI behaviour
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 1:12 PM, Rich Freeman 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 got CVS access, it's not a threat or a grandstanding, it's a simple boolean logic statement. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 7:50 AM, Diego Elio Pettenò wrote: > > On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov > wrote: >> >> >> 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 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. It just hasn't been much of an issue because fetch restriction is rare. Mirror restriction is likely a bigger problem even if it is somewhat user-invisible. Do we really want to hammer something like dev.gentoo.org for patches that aren't properly mirrored because the original source cannot be? Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov wrote: > > 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 access. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] [RFC] SRC_URI behaviour
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 example, Dear Esther's translations). So, in that case, I think, it'd be useful to change SRC_URI behaviour a bit: for example: SRC_URI=" restrict://dearesther-linux-06082013-bin #fetch restrict linguas_ru? ( http://www.dear-esther.com/translations/DE_Russian.rar ) linguas_hu? ( http://www.dear-esther.com/translations/DE_Hungarian.rar ) linguas_hu2? ( http://www.dear-esther.com/translations/DE_Hungarian2.rar ) " Alternatively it can be even: SRC_URI=" restrict+http://foo.bar/moo-123.run # mirror-restrict or specifying a link for fetch-restrict (like for oracle-jdk) " 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 " And it can also be extendable: SRC_URI=" hg+http://prosody.im/trunk modules? ( hg+https://prosody-modules.googlecode.com/hg ) " Any thoughts? signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] unpacker.eclass extensions
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:
# @DESCRIPTION:
# Unpack nixstaller generated files
# They're shell scripts with the blob package tagged onto
# the end of the archive. In the blob placed tarballs with
# actual content.
#
# Please note, if you need additional dependecies make sure to unpack
subarch
# archive as first argument.
#
nixstaller_unpack() {
unpack_makeself
local unpack_files="$@"
for i in $unpack_files ; do
unpack_banner "$i"
# Make sure that file exists
[[ -f "./$i" ]] && (
local type=$(file -b ${i})
case ${type} in
data)
tar -xJf "./$i"
;;
gzip*)
tar -xzf "./$i"
;;
esac
) || die "Failed to unpack $i"
done
}
Original author is Azamat Hackimov aka winterheart (in CC).
2) It'd be also nice to detect mojo installers (most of the time,
they're "*-bin" or "*Installer" ELF32 sfx-archives) and pass them to
unpack_zip by default.
Unfortunately, I've no free time ATM, but if it is needed, I can write
prototype for Mojo unpacking.
signature.asc
Description: OpenPGP digital signature
