Re: [gentoo-dev] glibc-2.17: nscd is optional
On Mon, Dec 31, 2012 at 11:13 PM, Maxim Kammerer m...@dee.su wrote: On Tue, Jan 1, 2013 at 2:10 AM, Alec Warner anta...@gentoo.org wrote: flatfile lookups are 2-4ms with hot cache. How much faster is the db option? I guess it depends on the implementation and how close is the system's operational situation to an ideal one (whether swap started thrashing, etc.). A DB is the proper solution that can be improved if necessary (e.g., keeping often-used parts in RAM). Filesystem where it resides can be offered hardware with lower seek time or better cache. But I agree that it is easy to rationalize bad solutions. I don't like waiting on an ls -l in addition to the system not being responsive due to some other reason, though. But maybe I am expecting too much, with even PolKit delegating each query to a full-blown Javascript library nowadays. You realize that files are cached in RAM right? There's a page cache and pages are ejected when the system needs that RAM for something else and they're ejected in an LRU fashion. More than likely those pages are always in cache. I say pages very liberally here because most of the files we're dealing with are less than 4096 bytes (yep, I'm making that assumption) so its really 1 page per file. The result is that the request for the data (assuming mmap here) is handled by just doing a bounds/range check and converting the virtual address to the physical address the data is wired in. The time required to parse the average GNOME single user desktop machine (I've got 44 users and 69 groups on that box) is likely smaller than the overhead of a DB. -- Doug Goldstein
Re: [gentoo-dev] glibc-2.17: nscd is optional
On Tue, Jan 1, 2013 at 10:49 AM, Doug Goldstein car...@gentoo.org wrote: You realize that files are cached in RAM right? Yes, I know how operating systems work. More than likely those pages are always in cache. Did you read my reply at all? You are assuming ideal conditions (enough free RAM), for a specific kind of desktop (low seek time for root filesystem is one assumption), where the solution you are relying upon is a generic one, and will fail under high load. I prefer removing potential problems instead of relying on optimal behavior and having to figure what went wrong down the road. The time required to parse the average GNOME single user desktop machine (I've got 44 users and 69 groups on that box) is likely smaller than the overhead of a DB. No, since the DB can have frequent pages locked into memory. Should I also ask: “you realize that not all DBs are MySQL and Oracle, right”? I think this branch of discussion became pretty off-topic, so I suggest stopping it. I just wanted people to know about the optional glibc database functionality, which is a nice alternative for those of us that are used to nscd with NIS+, and which doesn't work at the moment (so maybe someone feels like figuring it out on the glibc bug opened by vapier). I certainly have no desire to read condescending replies. If I wanted a flamewar, I would have probably mentioned that glibc uses /var/db for the database, which is not FHS-compliant. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] glibc-2.17: nscd is optional
On Tue, Jan 1, 2013 at 2:24 AM, Maxim Kammerer m...@dee.su wrote: On Tue, Jan 1, 2013 at 10:49 AM, Doug Goldstein car...@gentoo.org wrote: You realize that files are cached in RAM right? Yes, I know how operating systems work. More than likely those pages are always in cache. Did you read my reply at all? You are assuming ideal conditions (enough free RAM), for a specific kind of desktop (low seek time for root filesystem is one assumption), where the solution you are relying upon is a generic one, and will fail under high load. I prefer removing potential problems instead of relying on optimal behavior and having to figure what went wrong down the road. There are tons of built-in assumptions regarding system state on this thread. I believe the argument being offered is that for the vast majority of desktop users, the default upstream approach of flatfiles serves the common use case fine. If you think the majority of desktop users are using more than one machine, or NIS+ or anything complicated, then we already disagree on the base case ;) The time required to parse the average GNOME single user desktop machine (I've got 44 users and 69 groups on that box) is likely smaller than the overhead of a DB. No, since the DB can have frequent pages locked into memory. Should I also ask: “you realize that not all DBs are MySQL and Oracle, right”? I think this branch of discussion became pretty off-topic, so I suggest stopping it. I just wanted people to know about the optional glibc database functionality, which is a nice alternative for those of us that are used to nscd with NIS+, and which doesn't work at the moment (so maybe someone feels like figuring it out on the glibc bug opened by vapier). I certainly have no desire to read condescending replies. If I wanted a flamewar, I would have probably mentioned that glibc uses /var/db for the database, which is not FHS-compliant. There are a ton of nss modules users can enable if they so choose. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Gentoo and Root CAs
On Tue, Jan 1, 2013 at 1:44 AM, Rich Freeman ri...@gentoo.org wrote: The certificates that Gentoo distributes have at least been vouched for by somebody who is a part of our community, which is more than can be said for most of the upstream certificates. And you think vouched for by some community member is better than Mozilla's audit process, however limiting it may be? Yes, the CA system is broken, but it's what we've got for now. It seems obvious that including fewer CA roots in our base package is a better solution than including more of them, since (a) it's pretty easy for our users to install more of them, including at scale (via an overlay), and (b) actual security of a CA probably goes down exponentially as you move towards CA's with a lower level of trust placed in them by organizations like Mozilla. Speaking of which, say what you will about Mozilla's broken criteria for root inclusion, but Mozilla has no commercial interests, pretty competent security staff, and is already spending lots of staff time at managing their selection of CA roots. So I think we could do worse than tracking them closely (and in fact, I'd say we *are*, currently doing just that -- doing worse). IMO it would probably be good to limit our CA roots to Mozilla's libnss selection by default and perhaps add a packaged selection of secondary CA's (like CACert) for those who are so inclined. And if Debian's process is somewhat broken, it might be best to try not to rely on them. It can't be too hard, if Mozilla is already packaging the certificates somehow. Cheers, Dirkjan
Re: [gentoo-dev] Gentoo and Root CAs
On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman d...@gentoo.org wrote: On Tue, Jan 1, 2013 at 1:44 AM, Rich Freeman ri...@gentoo.org wrote: The certificates that Gentoo distributes have at least been vouched for by somebody who is a part of our community, which is more than can be said for most of the upstream certificates. And you think vouched for by some community member is better than Mozilla's audit process, however limiting it may be? Yes. It certainly is no worse. To date I'm not aware of a single security incident involving a certificate introduced by a Gentoo maintainer, but I'm certainly aware of a few involving Mozilla-originated certs. (b) actual security of a CA probably goes down exponentially as you move towards CA's with a lower level of trust placed in them by organizations like Mozilla. Care to substantiate that claim? The fact that Mozilla trusts a certificate does not confer security in and of itself. IMO it would probably be good to limit our CA roots to Mozilla's libnss selection by default and perhaps add a packaged selection of secondary CA's (like CACert) for those who are so inclined. And if Debian's process is somewhat broken, it might be best to try not to rely on them. It can't be too hard, if Mozilla is already packaging the certificates somehow. I've yet to see any evidence that Debian's process is broken. There is simply the claim that Mozilla's process is somehow better. I could see the logic in requiring regular Gentoo audits for any certificates we bundle, in which case we likely wouldn't be bundling any certificates at all (and would be stripping any provided by upstream). However, the only thing following the Mozilla process ensures is that a few commercial entities make lots of money (even if Mozilla isn't one of them). For a company with deep pockets like Mozilla I can see why they do this - even if it provides no security they can just say they're doing what everybody else is doing and it will likely hold up in court. The appearance of security matters more than actual security to them. Rich
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 31-12-2012 a las 14:53 -0800, Zac Medico escribió:
On 12/31/2012 05:21 AM, Pacho Ramos wrote:
pkg_postinst() {
Some improvements I am not sure how to implement just now:
- What would be the proper way to elog contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:
if ! has_version 'sys-power/acpid'; then
elog
elog You may wish to read the Gentoo Linux Power Management
Guide,
elog which can be found online at:
elog http://www.gentoo.org/doc/en/power-management-guide.xml;
elog
fi
?
Thanks for your help
It seems that you're allowed to call the unpack() function in any phase,
so something like this should work:
cd ${T}
cp ${EROOT}/usr/share/doc/${PF}/CONFIGURATION* ./
[ -f ./CONFIGURATION ] || unpack ./CONFIGURATION*
elog $( ./CONFIGURATION)
Thanks a lot for the tip :)
On the other hand, I have seen another way of doing that looking at
kernel-2.eclass:
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2013-01-01 14:30:18.0 +0100
@@ -17,6 +17,11 @@
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
+CONFIGURATION_INSTRUCTIONS=
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml;
+
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
@@ -37,6 +42,9 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
+ dodoc CONFIGURATION
}
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
[...]
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2013-01-01 14:30:18.0 +0100
@@ -17,6 +17,11 @@
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
+CONFIGURATION_INSTRUCTIONS=
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml;
+
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
@@ -37,6 +42,9 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
+ dodoc CONFIGURATION
}
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo and Root CAs
On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman d...@gentoo.org wrote: On Tue, Jan 1, 2013 at 1:44 AM, Rich Freeman ri...@gentoo.org wrote: The certificates that Gentoo distributes have at least been vouched for by somebody who is a part of our community, which is more than can be said for most of the upstream certificates. And you think vouched for by some community member is better than Mozilla's audit process, however limiting it may be? Yes, the CA system is broken, but it's what we've got for now. It seems obvious that including fewer CA roots in our base package is a better solution than including more of them, since (a) it's pretty easy for our users to install more of them, including at scale (via an overlay), and (b) actual security of a CA probably goes down exponentially as you move towards CA's with a lower level of trust placed in them by organizations like Mozilla. Speaking of which, say what you will about Mozilla's broken criteria for root inclusion, but Mozilla has no commercial interests, Wait, what? How does taking income during a process not constitute a commercial interest? That money goes to something that's in the interest of the Mozilla Foundation, whether it's paying for infrastructure, paying for developers to do their thing, sponsoring this, that or the other thing... Without money Mozilla wouldn't exist, ergo Mozilla is interested in money, ergo taking money in exchange for bundling a root cert carries its own interest outside of the security properties of bundling the root cert. So if Mozilla has an interest in cert security, and an interest in money, than including certs for money carries with it an inherent conflict of interest. Such as the world is, things cannot be done without money to exchange for goods and services, so any entity with interests beyond money needs to manage such a conflict, one way or another. So, the question comes around to how well the entity manages that conflict of interest, via things like ombudsmen or independent (how?) audit processes. Or how it's managed for them, via things like reputation. (And it sounds to me like Rich is making a strong argument about the reputation angle, both in favor of vouching, and for observing security problems with people Mozilla still bundles.) (That's all I've got for this thread. Going back to lurking.) -- :wq
Re: [gentoo-dev] glibc-2.17: nscd is optional
On Monday 31 December 2012 18:23:06 Maxim Kammerer wrote: On Mon, Dec 31, 2012 at 10:45 PM, Mike Frysinger wrote: On Sunday 30 December 2012 13:47:40 Maxim Kammerer wrote: Desktop users would probably benefit more from glibc databases, if they worked: https://bugs.gentoo.org/show_bug.cgi?id=432020 http://sourceware.org/bugzilla/show_bug.cgi?id=14498 (1) i doubt it and (2) this isn't a discussion of bugs in nscd It's relevant to the discussion, because glibc databases are an alternative to running nscd. As a desktop user, I run nscd even on a desktop without YP/NIS+, because I don't like the idea of glibc functions parsing plain text files on each related query. I would use glibc databases instead of nscd if that was a reliable option. one uncommonly used feature on the desktop vs another uncommonly used feature on the desktop doesn't really add much -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.17: nscd is optional
On Saturday 29 December 2012 20:24:16 Mike Frysinger wrote: rough poll: how many people actually care about nscd ? i'm making it into a USE flag for glibc-2.17 and it's easiest for me to do IUSE=nscd which means it'd default to off. sounds like people can handle this, so i've added it to 2.17 -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo and Root CAs
On 1/1/13 2:51 AM, Dirkjan Ochtman wrote: IMO it would probably be good to limit our CA roots to Mozilla's libnss selection by default and perhaps add a packaged selection of secondary CA's (like CACert) for those who are so inclined. I think that's a good idea: make it easy to only use the Mozilla CA roots, and also make it easy to use the other roots like CACert. Seems like it could be just a USE flag for affected packages. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] [brainstorm] dev-lang internal package managers and portage
Hi there! Long time ago I discovered that many language-specific packages (libraries, webapps) written on languages like PHP, Ruby, Lua and so on has (often) almost hardcoded dependence to be installed via their native package managers (pecl, cpan, luarocks, gem, bundler and so on). More of that, I discovered quite spiked way to install lang-specific packages in portage (fakegem eclass, pecl-php eclass and so on). Thinking in that way guided me to suggest to develop some kind of compatibility layer between portage (and sandboxed installation) and that lang-specific package managers. So then it will be almost unneeded to, for example, write tons of new local ebuilds when installing, for example new version of redmine. Or to write tons of spikes when installing some PHP or Lua apps, designed for pecl or luarocks respectively. But on the other hand — QA issues. I afraid, that it will make us responsible to upstream failures (in users eyes). Anyway, let's discuss some ideas on that behaviour. BTW, this post is mainly sponsored by great PITA about deploying rails applications and trying to get them to work with system-wide dev-ruby/* things installed (while upstream REQUIRES to use bundler). It is also minor-sponsored by some kepler-project apps (Lua) and some PHP apps. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
On 2 January 2013 08:14, Vadim A. Misbakh-Soloviov m...@mva.name wrote: Hi there! Long time ago I discovered that many language-specific packages (libraries, webapps) written on languages like PHP, Ruby, Lua and so on has (often) almost hardcoded dependence to be installed via their native package managers (pecl, cpan, luarocks, gem, bundler and so on). More of that, I discovered quite spiked way to install lang-specific packages in portage (fakegem eclass, pecl-php eclass and so on). Thinking in that way guided me to suggest to develop some kind of compatibility layer between portage (and sandboxed installation) and that lang-specific package managers. So then it will be almost unneeded to, for example, write tons of new local ebuilds when installing, for example new version of redmine. Or to write tons of spikes when installing some PHP or Lua apps, designed for pecl or luarocks respectively. But on the other hand — QA issues. I afraid, that it will make us responsible to upstream failures (in users eyes). Anyway, let's discuss some ideas on that behaviour. BTW, this post is mainly sponsored by great PITA about deploying rails applications and trying to get them to work with system-wide dev-ruby/* things installed (while upstream REQUIRES to use bundler). It is also minor-sponsored by some kepler-project apps (Lua) and some PHP apps. My experience with Perl is that, at least for now, what you propose is impossible. There's no hard coded dependence on Package Managers, its really a choice, at least, For Perl that is. Upstream Perl basically tell users: Use entirely distro tools, or use entirely perl tools, don't try mixing them. And this advice generally works out well. ie: either you rely on Gentoo mapping Perl packages to dists , or you use a user-installed copy of perl ( ie: using Perlbrew ), and leave the System perl to be there for other system perl stuff. Essentially, the Perl installed by your package manager should be used for System Perl tasks, ie: other programs that you happen to be running on your system that are also installed by package management. For programming and project development, its generally recommended to use a user install instead, and install that perl in ~/ , and its dependencies in ~/ , and not mingle it with system Perl. Perhaps this advice should also be more widely disseminated for other languages? I know that at least with things like Maven ( Java development ), using a system install of Maven is a nightmare and a exercise in futility, while a local user install works quite nicely. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
If it was something feasible to do, it would have been done already. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Tue, Jan 1, 2013 at 8:14 PM, Vadim A. Misbakh-Soloviov m...@mva.namewrote: Hi there! Long time ago I discovered that many language-specific packages (libraries, webapps) written on languages like PHP, Ruby, Lua and so on has (often) almost hardcoded dependence to be installed via their native package managers (pecl, cpan, luarocks, gem, bundler and so on). More of that, I discovered quite spiked way to install lang-specific packages in portage (fakegem eclass, pecl-php eclass and so on). Thinking in that way guided me to suggest to develop some kind of compatibility layer between portage (and sandboxed installation) and that lang-specific package managers. So then it will be almost unneeded to, for example, write tons of new local ebuilds when installing, for example new version of redmine. Or to write tons of spikes when installing some PHP or Lua apps, designed for pecl or luarocks respectively. But on the other hand — QA issues. I afraid, that it will make us responsible to upstream failures (in users eyes). Anyway, let's discuss some ideas on that behaviour. BTW, this post is mainly sponsored by great PITA about deploying rails applications and trying to get them to work with system-wide dev-ruby/* things installed (while upstream REQUIRES to use bundler). It is also minor-sponsored by some kepler-project apps (Lua) and some PHP apps.
[gentoo-dev] Switching order of packages in virtual/pkgconfig
I would like to propose a switch of the order of DEPENDs in virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default choice for new installations. dev-util/pkgconf has less external dependencies, is lighter and is faster than dev-util/pkgconfig while being now 100% compatible This switch has already been made by Funtoo, Alpine Linux and FreeBSD with very little in the way of ill effects recently from any of those 3 camps. There are no more pending bugs against pkgconf (and Diego did a tinderbox run with it a while back) in Gentoo. pkgconf also has a upstream that is more than happy to work with us specifically (or anyone for that matter) and I (a Gentoo developer) am one of the upstream developers. If this is approved, I will make the change in ~2 weeks. I'm not planning on making a news item because users should notice little difference. Thanks Jeff
Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/01/2013 02:14 PM, Vadim A. Misbakh-Soloviov wrote: Hi there! Long time ago I discovered that many language-specific packages (libraries, webapps) written on languages like PHP, Ruby, Lua and so on has (often) almost hardcoded dependence to be installed via their native package managers (pecl, cpan, luarocks, gem, bundler and so on). More of that, I discovered quite spiked way to install lang-specific packages in portage (fakegem eclass, pecl-php eclass and so on). Thinking in that way guided me to suggest to develop some kind of compatibility layer between portage (and sandboxed installation) and that lang-specific package managers. So then it will be almost unneeded to, for example, write tons of new local ebuilds when installing, for example new version of redmine. Or to write tons of spikes when installing some PHP or Lua apps, designed for pecl or luarocks respectively. But on the other hand — QA issues. I afraid, that it will make us responsible to upstream failures (in users eyes). Anyway, let's discuss some ideas on that behaviour. BTW, this post is mainly sponsored by great PITA about deploying rails applications and trying to get them to work with system-wide dev-ruby/* things installed (while upstream REQUIRES to use bundler). It is also minor-sponsored by some kepler-project apps (Lua) and some PHP apps. I'm in the process of rolling out the latest Redmine. First, bundler et al. are happy to use the system stuff. You just need to make sure all of the dependencies for your app are installed. Your problem isn't that you need a general solution to the upstream packaging problem -- it's that redmine is basically unmaintained in Gentoo, so you have to do it yourself. And maintaining rails packages is hard, so it sucks even more that the effort is duplicated. As a user I don't care where the ebuilds come from or what they do, just that they're up-to-date, in the main tree, and work. If Redmine was being properly maintained, you could just `emerge redmine` to pull in its dependencies. Then you could download Redmine yourself, stick it somewhere, and bundler would be happy. In lieu of that, what we do is create ebuilds like www-apps/redmine-dependencies. I manually parse the Gemfile for the (R)DEPENDs. My life would be a lot easier if we had something like gentoo-haskell's hackport that could parse a Gemfile and spit out an ebuild. But in any case, it's a poor substitute for doing it right. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQ41FCAAoJEBxJck0inpOirF4P/jQXyZyMz8Q88pQrNY5Zs2sF xgG6SvRUDO0cq73AW+M2P7GNgRHwoUGfoTb5q1C4lCbJfq3ZFUj1YKmVrTuqURo0 hfgUETWIsaV7fXS3sdkvXijT6N7tf5SHWFC9cQkP0q+T2JXwlhNZXb9gg076jofg NHNUMzKkqgWxfFLa3R2cLaCpDnB25Hug86K8heIUbQn6sH1CVu8CMYesCqFYQbms /3gyN1NDKpDSqu1TTjG0fsA1bvZjjB7Mm+crZYGvFx7pwCtX8q48eMr7dEXt7UPG TjHWBaBK5aoCIud0xHDfIjHvTIlG1LEwRhaAJjt+aVHMpNQ68ZWNZrAcOJGpEMwE 2lIxgimC6M/qSsPvR3n0C9MbHDwk8gkjGMijabzGle4WZDdPnohZ8mpQuJiWtvB5 gtxi29FfYvsKQBQcVxLPYM7cMNEOq5O4BV1dqv2B9e194ONwcTLBPcenGHE1WIBP QK8xRgDqz1HoZW+av9IlhVy8BcUk8kRo3kFSC8zZG+by5L0i+sMk4EGzcJuiXxE1 cfXAiLeNtoD1NZjSutfbb55B8hdfwak3B15cH6DrZj0N6SK35+mULHiaBN9ywG5q gRUJ0HIzrzhpLRtT7ahEtqlF6lmtjYZNTyl3nmc11uyhtAjUsXH5cMT4b0m3MAz/ UJp7IGdFwG6IMQY3xI1y =kXHU -END PGP SIGNATURE-
Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
On Wed, 02 Jan 2013 02:14:17 +0700 Vadim A. Misbakh-Soloviov m...@mva.name wrote: Long time ago I discovered that many language-specific packages (libraries, webapps) written on languages like PHP, Ruby, Lua and so on has (often) almost hardcoded dependence to be installed via their native package managers (pecl, cpan, luarocks, gem, bundler and so on). More of that, I discovered quite spiked way to install lang-specific packages in portage (fakegem eclass, pecl-php eclass and so on). Thinking in that way guided me to suggest to develop some kind of compatibility layer between portage (and sandboxed installation) and that lang-specific package managers. The problem here is that CPAN, Gems etc don't follow their own specifications. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On Tue, 2013-01-01 at 16:01 -0500, Jeff Horelick wrote: dev-util/pkgconf has less external dependencies, is lighter and is faster than dev-util/pkgconfig while being now 100% compatible That sounds like a clear win. If it has survived the tinderboxing there likely isn't much to hold you back. As non-contentious topics sometimes end up with no replies at all... consider 48 hours of radio silence an implicit yes. Regards, Tony V.
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 01/01/2013 22:29, Tony Chainsaw Vroon wrote: That sounds like a clear win. If it has survived the tinderboxing there likely isn't much to hold you back. As non-contentious topics sometimes end up with no replies at all... consider 48 hours of radio silence an implicit yes. It didn't survive. I'm not sure if all the bugs have been fixed now but at some point I had to stop the tinderboxing because it was hitting package failures, and then it was fixed for next version — which was difficult to test. So I would veto this _for the moment_. (I'd be happy to run another test _after_ the glibc-2.17 one.) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
On 01/01/2013 22:12, Michael Orlitzky wrote: In lieu of that, what we do is create ebuilds like www-apps/redmine-dependencies. I manually parse the Gemfile for the (R)DEPENDs. My life would be a lot easier if we had something like gentoo-haskell's hackport that could parse a Gemfile and spit out an ebuild. But in any case, it's a poor substitute for doing it right. If it could be possible, we would have done. Really, Gemfiles and .gemspecs are just a pain in the ass and most of the time they don't really represent what they purport to. As Ciaran said (wth? do I start 2013 agreeing with Ciaran?), they don't follow their own rules half the times, which is why we still hand-craft Ruby ebuilds, and why we often can't update to the latest and greatest package out there: sometimes the latest and greatest is also broken. In general, for what concerns Rails app, packaging them in any form is a bad idea. How do you actually manage it, when the source code of the app _is_ the app itself? It's not like you can say here are the configuration file for webapp X.. It could be possible for webapp-config to come to our help there, but it would require for it to be rewritten to take Rails into account, as right now it doesn't. I know because it was trying to get an ebuild for Typo that I came to install my own blog (instead of using Gentoo Infra's b2evo) and thus create the monstrosity that you all know nowadays. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/01/2013 04:53 PM, Diego Elio Pettenò wrote: On 01/01/2013 22:12, Michael Orlitzky wrote: In lieu of that, what we do is create ebuilds like www-apps/redmine-dependencies. I manually parse the Gemfile for the (R)DEPENDs. My life would be a lot easier if we had something like gentoo-haskell's hackport that could parse a Gemfile and spit out an ebuild. But in any case, it's a poor substitute for doing it right. If it could be possible, we would have done. Really, Gemfiles and .gemspecs are just a pain in the ass and most of the time they don't really represent what they purport to. As Ciaran said (wth? do I start 2013 agreeing with Ciaran?), they don't follow their own rules half the times, which is why we still hand-craft Ruby ebuilds, and why we often can't update to the latest and greatest package out there: sometimes the latest and greatest is also broken. Understandable, and fine with me as long as someone actually does hand-craft them. I don't *want* to create my own local ebuilds for these things. But you have to for most rails apps. In general, for what concerns Rails app, packaging them in any form is a bad idea. How do you actually manage it, when the source code of the app _is_ the app itself? It's not like you can say here are the configuration file for webapp X.. It could be possible for webapp-config to come to our help there, but it would require for it to be rewritten to take Rails into account, as right now it doesn't. I know because it was trying to get an ebuild for Typo that I came to install my own blog (instead of using Gentoo Infra's b2evo) and thus create the monstrosity that you all know nowadays. I don't really get the webapp-config thing, but if we could all pretend that it works long enough to get some modern apps in the tree, that would solve my problem. Then I could either, a) Emerge redmine, ignore it, and install copies manually for my vhosts. b) Copy the (R)DEPENDs and IUSE out of that ebuild and into a local one installing only the dependencies. Fundamentally I prefer this since it doesn't install unused files on my system, but it is more work. Having them in the tree is important -- whether I use them or not -- because it catches conflicting dependencies. Trying to manage rails-2, rails-3, ruby18, and ruby19 by oneself right now is a nightmare. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQ42FeAAoJEBxJck0inpOitg8P+gNtVCQyKAfA9rflYRDZVgqB YKvXvAueeTarzKD41vY5V2ndebm1fPAtXTn8thm0CFk2H4AfYRN2Cm1MkjCNjpZi ezBU2hfk7c5z/eo1zd4Pfka6t3j241bAGKqTIYX8VipuePMQWjxoNswk65KPprSD 5mOx+a7yAoJwlDMnwP+UITxjQblSw6xVpPcm4/RUd/R6mqMvW2PzouqPqpR0XmHI Tx0EDXoe2gIRxVrlCNkdh/kjHR5FlwTJC1nb0pBfXV6xGuQD+AOjSSmjofw/7rMW 7Mnxl34llcjhwz0o2SBrLr2ggjD8byG815IKHE+vOF5U3B8BId1+nMB18gWKmzM+ kyJic4ocqiFYvLY25pq6Yzhel1xXZg4fg+7pbNhoh6qGOYYy7ou5P2fL2A+kAGar FYSYiwXVIP+Rza+LKscdwJD/V4oKfxnJwobprlwVZSouBC3tLtabJfbykknY16XD RLJUKddlr144d3f8r/Jz4gNE9zrsBSuasoTOhcqzl7MccZUI582FdyFKgooEbgWh OnykgrFzlfPMSZ8R0Sl/LGS1sJJZK1CX9MZiLAwgCRoyaZEzEb/6A8sWVuw8Fe7r ueVdla6hP+Vb8lL8v9esKp4m8qnoj6k7VkHzGLd9sxg7pKxt2XuPIcw2OP2xOFiU 352K6bD6SoJSQLYNmECt =d7sM -END PGP SIGNATURE-
Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 01 Jan 2013 17:21:18 -0500 Michael Orlitzky mich...@orlitzky.com wrote: Understandable, and fine with me as long as someone actually does hand-craft them. I don't *want* to create my own local ebuilds for these things. But you have to for most rails apps. Last time I looked at it, Gems' YAMLs file weren't legal YAML, and couldn't be parsed by anything except Ruby's hacked version of Syck. So yes, you have to. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlDjZXYACgkQ96zL6DUtXhG7ngCdEZfcOM/YTR9H+TJP5rqOv4Ax M10AoMVvTUvycGP3Qkx/oboL0XKu6UyK =ydSo -END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
Not that `has_version ${CATEGORY}/${PN}` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:
1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead
--
Thanks,
Zac
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On Tuesday 01 January 2013 16:46:49 Diego Elio Pettenò wrote: On 01/01/2013 22:29, Tony Chainsaw Vroon wrote: That sounds like a clear win. If it has survived the tinderboxing there likely isn't much to hold you back. As non-contentious topics sometimes end up with no replies at all... consider 48 hours of radio silence an implicit yes. It didn't survive. I'm not sure if all the bugs have been fixed now but at some point I had to stop the tinderboxing because it was hitting package failures, and then it was fixed for next version — which was difficult to test. So I would veto this _for the moment_. (I'd be happy to run another test _after_ the glibc-2.17 one.) yes, we need real data first before we can make a proper decision -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Gentoo and Root CAs
Michael Mol mikemol at gmail.com writes: On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman djc at gentoo.org wrote: Speaking of which, say what you will about Mozilla's broken criteria for root inclusion, but Mozilla has no commercial interests, Wait, what? How does taking income during a process not constitute a commercial interest? There seems to be some confusion about Mozilla's cert inclusion process. Mozilla does not make any money by including CA certificates. Per its own policy [1], We will not charge any fees to have a CA's certificate(s) distributed with our software products. [1] https://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
Re: [gentoo-dev] Re: Gentoo and Root CAs
On Tue, Jan 1, 2013 at 9:37 PM, Benjamin Peterson benja...@python.org wrote: Michael Mol mikemol at gmail.com writes: On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman djc at gentoo.org wrote: Speaking of which, say what you will about Mozilla's broken criteria for root inclusion, but Mozilla has no commercial interests, Wait, what? How does taking income during a process not constitute a commercial interest? There seems to be some confusion about Mozilla's cert inclusion process. Mozilla does not make any money by including CA certificates. Per its own policy [1], We will not charge any fees to have a CA's certificate(s) distributed with our software products. [1] https://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Fair enough. I took Rich's email as an indication they did. -- :wq
Re: [gentoo-dev] Re: Gentoo and Root CAs
On Tue, Jan 1, 2013 at 9:49 PM, Michael Mol mike...@gmail.com wrote: On Tue, Jan 1, 2013 at 9:37 PM, Benjamin Peterson benja...@python.org wrote: Michael Mol mikemol at gmail.com writes: On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman djc at gentoo.org wrote: Speaking of which, say what you will about Mozilla's broken criteria for root inclusion, but Mozilla has no commercial interests, Wait, what? How does taking income during a process not constitute a commercial interest? There seems to be some confusion about Mozilla's cert inclusion process. Mozilla does not make any money by including CA certificates. Per its own policy [1], We will not charge any fees to have a CA's certificate(s) distributed with our software products. [1] https://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Fair enough. I took Rich's email as an indication they did. To be trusted by Mozilla you do indeed need to pay substantial sums of money (in almost all cases), but you don't actually pay them to Mozilla. Typically you pay them to an auditor who specializes in such things, such as webtrust. The fact that they don't even publish their fees tells you all you need to know - I've heard they are in the neighborhood of $10k. My concern is that the approach chosen by Mozilla (and most other software distributions produced by large corporations) is mostly about having lots of paperwork and audting, and is not about actual security. If a certificate authority has a pile of paperwork saying they operate one way, it won't stop them from issuing certificates to the NSA or whoever if they get a national security letter, or the equivalent in one of the 400 other jurisdictions that these companies reside in (many of which make the Patriot Act seem quite tame). And that is just considering cases where the CA cooperates with legal authorities. Factor in incompetence and just about anything can happen. Incompetence happens in industries that have heavy government scrutiny, such as in pharmaceuticals and aircraft maintenance. Certificate authorities are almost completely unregulated in comparison. Basically the whole system is one big CYA maneuver. DNSSEC is far more promising as a certificate distribution system, and the legacy SSL system really is just standing in the way. Rich
Re: [gentoo-dev] Gentoo and Root CAs
On Monday 31 December 2012 19:44:32 Rich Freeman wrote: The certificates that Gentoo distributes have at least been vouched for by somebody who is a part of our community, which is more than can be said for most of the upstream certificates. mmm, Gentoo ships ca-certificates which comes directly from Debian. when people request modification (add/remove/whatever), we bounce them to Debian. we specifically don't want to deal with this mess and instead unload it onto Debian :). we don't modify openssl in any way wrt cert management. it uses the certs the user themselves have installed, or other packages have installed into /etc/ssl/ (which atm is just ca-certificates afaik). as for nss, i can't vouch for it directly since i haven't worked on it. a cursory glance looks like we add cacert.org and spi (software in the public interest) root certs. i don't know if it's possible, but it seems like nss should just look in the common /etc/ssl store. either way, i don't see a problem here. i don't know much about gnutls, but it doesn't seem like we do anything there other than package it up. -mike signature.asc Description: This is a digitally signed message part.
