[gentoo-dev] Re: [gentoo-dev-announce] New Developer: Heather Cynede (cynede)
On 09/19/2013 04:00 PM, justin wrote: Hi all, I like to announce the newest addition from Russia to out dev team, Heather Cynede (cynede). It's the long awaited addition to the dotnet and haskell team, where there are already a couple of the contribution. The Gamerlay Overlay also got commits. So let us look forward to great progress in those areas. Here are some lines from the self description: I'm still beginner in gnu / linux world but I've got a time and entusiasm I like gentoo, and contribute own overlay, send some bugs, some patches, specially to gentoo-haskell overlay, gamerlay (popular unofficial overlay) and dotnet overlay. Please give him a warm welcome! Justin Welcome Heather! -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
[gentoo-dev] Last rites: www-plugins/mozplugger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Oops, didn't follow proper removal procedure; reset the counter on this one. # Ian Stakenvicius a...@gentoo.org (20 Sep 2013) # on behalf of mozi...@gentoo.org # Severely outdated, no interest in maintaining, # only a matter of time before it breaks, # major QA issues with newer versions # See bug #442122 for discussion # Masked for removal in 30 days www-plugins/mozplugger -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlI8bVgACgkQ2ugaI38ACPAf9gD8DnamsvOzGxczLXI/fNIspQYI 6sGwsNwB+ES2feZfDZ0BAKh4Kb9tiyS/dUl+omn9ayWWqqVrdgxW5oODxKmDq397 =iRc6 -END PGP SIGNATURE-
Re: [gentoo-dev] include files question
Paweł Hajdan, Jr. wrote: Also, it may be easier to change now when we only have two headers, than later. And you may even add compatibility symlinks or copies in /usr/include to give people more time to update. I think you should rip off the band-aid quickly. Move the files and update the .pc file. If someone is building against openrc without using pkg-config then they should fix their stuff. Putting $(shell pkg-config --cflags openrc) into a Makefile is very easy. //Peter pgpCJhEk_V821.pgp Description: PGP signature
Re: [gentoo-dev] include files question
Dnia 2013-09-20, o godz. 18:12:17 Peter Stuge pe...@stuge.se napisał(a): Paweł Hajdan, Jr. wrote: Also, it may be easier to change now when we only have two headers, than later. And you may even add compatibility symlinks or copies in /usr/include to give people more time to update. I think you should rip off the band-aid quickly. Move the files and update the .pc file. If someone is building against openrc without using pkg-config then they should fix their stuff. Putting $(shell pkg-config --cflags openrc) into a Makefile is very easy. Putting another includedir is even worse kind of band-aid. If we're to put them in a directory, I'd rather require 'more complete' includes, like: #include openrc/rc.h Otherwise, you're just fighting conflicts in the scope of a single application. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] include files question
On 9/20/13 9:27 AM, Michał Górny wrote: Putting another includedir is even worse kind of band-aid. If we're to put them in a directory, I'd rather require 'more complete' includes, like: #include openrc/rc.h Otherwise, you're just fighting conflicts in the scope of a single application. Exactly, with /usr/include/openrc added I think #includes should look like above. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] include files question
On 9/15/13 10:01 AM, William Hubbs wrote: All, here is another question wrt OpenRC's api. Currently we store two header files (rc.h and einfo.h) in /usr/include. Since we have more than one include file, wouldn't it be standard practice to store them in a sub directory of /usr/include? I'm leaning towards having a directory for them like /usr/include/openrc, but I'm also fine with having them in /usr/include . It's not so much about standard practice, but even say avoiding file collisions and weird issues with wrong headers being included (especially rc.h seems to be a fairly generic name). Also, it may be easier to change now when we only have two headers, than later. And you may even add compatibility symlinks or copies in /usr/include to give people more time to update. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
Hi, what is your opinion to set FEATURES=binchecks strip for all those packages which purely install files. For example python package only installing scripts, or perl packages or latex. There might be more. Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
As Michał said. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Sep 20, 2013 at 7:52 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-20, o godz. 19:58:51 Justin (jlec) j...@gentoo.org napisał(a): what is your opinion to set FEATURES=binchecks strip for all those packages which purely install files. For example python package only installing scripts, or perl packages or latex. There might be more. Not worth the effort, and definitely not worth the confusion it will introduce (why there's FEATURES=strip here? does it install weird executables under some circumstances? did it so in the past and someone forgot to drop it?). In other words, it's awful overuse of RESTRICT for pseudo-optimization. RESTRICT is to restrict features when the package can't handle it. It's not for skipping no-ops in the name of supposed performance gain. If you really want to play like this, show us some benchmarks. Prove that it gains anything. Because as far as I can see, this is nowhere near a bottleneck for ebuild installs. Unless you can prove it's a real gain, a strong 'don't do it' from me. -- Best regards, Michał Górny
Re: [gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
On Fri, Sep 20, 2013 at 10:58 AM, Justin (jlec) j...@gentoo.org wrote: what is your opinion to set FEATURES=binchecks strip for all those packages which purely install files. For example python package only installing scripts, or perl packages or latex. There might be more. It may help to describe what this would improve (presumably reduce the installation time?).
Re: [gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
Dnia 2013-09-20, o godz. 19:58:51 Justin (jlec) j...@gentoo.org napisał(a): what is your opinion to set FEATURES=binchecks strip for all those packages which purely install files. For example python package only installing scripts, or perl packages or latex. There might be more. Not worth the effort, and definitely not worth the confusion it will introduce (why there's FEATURES=strip here? does it install weird executables under some circumstances? did it so in the past and someone forgot to drop it?). In other words, it's awful overuse of RESTRICT for pseudo-optimization. RESTRICT is to restrict features when the package can't handle it. It's not for skipping no-ops in the name of supposed performance gain. If you really want to play like this, show us some benchmarks. Prove that it gains anything. Because as far as I can see, this is nowhere near a bottleneck for ebuild installs. Unless you can prove it's a real gain, a strong 'don't do it' from me. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
Justin (jlec) posted on Fri, 20 Sep 2013 19:58:51 +0200 as excerpted: what is your opinion to set FEATURES=binchecks strip for all those packages which purely install files. For example python package only installing scripts, or perl packages or latex. There might be more. In addition to what the others have said, FEATURES= ?? AFAIK, FEATURES is PM-implementation-specific and not part of PMS. It's not something ebuilds/eclasses should be messing with or care about at all, as it's PM- private-implementation domain, not ebuild domain. Unless you're suggesting changing the portage implementation to care about what specific package it's working on, and apply FEATURES based on that, and that doesn't sound like a good idea either. So I'm with the others. Just leave it alone. Being a NOOP for the packages in question means it's not hurting anything, and attempting to optimize it out is likely to be far more trouble than its worth. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
On 9/20/13 12:24 PM, Diego Elio Pettenò wrote: As Michał said. Please consider updating the documentation - ebuild(5): RESTRICT = [strip,mirror,fetch,userpriv] This should be a space delimited list of portage features to restrict. You may use conditional syntax to vary restrictions as seen above in DEPEND. binchecks Disable all QA checks for binaries. This should ONLY be used in packages for which binary checks make no sense (linux-headers and kernel-sources, for example, can safely be skipped since they have no binaries). If the binary checks need to be skipped for other reasons (such as proprietary binaries), see the QA CONTROL VARIABLES section for more specific exemptions. This is currently used at least by sys-apps/man-pages, as well as packages in x11-themes and sys-kernel. I'm fine either way, let's just make sure our mailing list advice matches documentation and established practice. Paweł signature.asc Description: OpenPGP digital signature
