Re: [gentoo-dev] Re: eudev project announcement
On Fri, 2012-12-21 at 12:48 +0100, J. Roeleveld wrote: On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote: On Fri, 21 Dec 2012 12:31:28 +0100 J. Roeleveld jo...@antarean.org wrote: On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote: On Fri, 21 Dec 2012 11:24:45 +0100 J. Roeleveld jo...@antarean.org wrote: On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote: Just let me know when you have to maintain a lot of such systemd and upgrade, say, glibc. Then maybe you'll understand. A shared /usr means I need to update ALL the systems at once. When /usr is not shared, I can update groups at a time. Yes, and this is what disqualifies it for the general case. If you can't update one at some point, you can't update the others or it is going to likely get broken in a random manner. Yes, but do you want to find out when the entire production environment is down? Or would you rather do the upgrades in steps and only risk having to rebuild a few nodes and have a lower performance during that time? There is a big difference between 50% performance and 0%. Didn't you just state that you *have* to update all at the same time? Please re-read what I wrote. I said, with a *shared* /usr, then yes, I do need to update the entire environment at the same time. That's not true. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On Sun, 2012-11-18 at 17:19 +, Duncan wrote: Diego Elio Pettenò posted on Sun, 18 Nov 2012 07:47:22 -0800 as excerpted: On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote: And, by the way, I doubt, that people laugh about eudev (previously named udev-ng) creation. Mostly they just can't understand why gentoo devs created third udev's fork, where it was already done (and maintained) fork for LFS (somewhere on bitbucket) People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and IRC as well. There's worse things than being laughed it. In fact, what's the oft-used- in-MS/Linux-context quote (Gandi if I'm not mistaken), something along the lines of... First they ignore you, then they laugh at you, then they fight you, then you win! If they're laughing, they're beyond the ignore stage. And we see evidence of the fight stage now too. If the idea behind that quote is correct... People keep repeating that quote implying that whenever somebody laughs at an idea it's because the idea is worth something, but that's illogical and in fact false: just because B(worthy idea) was preceded by A(laughter) doesn't mean that whenever there's A(laughter) then B(worthy idea) ensues http://xkcd.com/386/ -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] UTF-8 locale by default
On Thu, 2012-08-02 at 08:42 +0200, Fabian Groffen wrote: On 01-08-2012 21:00:23 -0400, Mike Gilbert wrote: Diego mentioned the python issue. Honestly, if some asian person has whatever charset that I often find in spam messages, but is not UTF-8, are you then going to tell that person to switch to UTF-8 to get those python packages emerged? I hope not. Yes. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
On Tue, 2012-07-24 at 20:55 -0400, Walter Dnes wrote: On Tue, Jul 24, 2012 at 11:42:31AM +0200, Ralph Sennhauser wrote man 5 portage about files in /etc/portage make.conf The global custom settings for Portage. See make.conf(5). If present, this file will over??? ride settings from /etc/make.conf. 3. This news item is really useful, since the change has a potential to break automated builds. We aren't discussing dropping support for the old locations here but about makeing the new location the default. This has the potential to cause problems for people who do things the old way, and find that their settings in /etc/make.conf are not being applied. Instead of a news item, maybe we should be looking at warnings and/or errors in emerge... 1) If there is a /etc/make.conf, but no /etc/portage/make.conf, emerge should generate an ewarn message. Is emerge smart enough to generate only one ewarn even though it's emerging umpteen packages? 2) If there is a /etc/make.conf *AND* a /etc/portage/make.conf, emerge should halt immediately with an error message. If a user has made a /etc/make.conf, they will probably expect it to take effect, which is not what's going to happen. This will save the user forums from being hit with the same question over and over about settings in /etc/make.conf being ignored. I'd go for a little more sophistication: it should exit with an error if /etc/make.conf is present and is not a symlink to /etc/portage/make.conf, because until all tools support the new location such a symlink might be necessary 3) When support for /etc/make.conf is finally dropped, the presence of /etc/make.conf should make emerge halt immediately with an error message. 1+ -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? Today, it requires an initramfs if /usr is not physically on /. That is due in large part to the fact that it has been rolled into the systemd tarball, and inherited some of systemd's code and limitations, despite the fact that udev is still a separate binary. This is absolutely and definitely false. Where did you hear such nonsense ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] add global useflag: webkit
On Mon, 2012-05-07 at 11:11 -0700, Zac Medico wrote: On 05/06/2012 05:47 PM, Arfrever Frehtes Taifersar Arahesis wrote: 2012-05-06 02:34:26 hasufell napisał(a): # grep :webkit use.local.desc | wc -l 33 I would vote to make this a global useflag: webkit - Adds support for the webkit library/module I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. Another possible way to model this kind of relationship would be to us REQUIRED_USE to enforce relationships with the qt and gtk flags: REQUIRED_USE=webkit? ( qt ) !webkit? ( !qt ) qt? ( webkit ) !qt? ( !webkit ) versus REQUIRED_USE=webkit? ( gtk ) !webkit? ( !gtk ) gtk? ( webkit ) !gtk? ( !webkit ) It's pretty awkward with the existing operators, but we could extend the REQUIRED_USE syntax to support an equivalent operator in a future EAPI. Isn't it the time to make a new EAPI which no longer has USE flags but USE values ? Many of the really weird USE flags combinations would be much more clearly expressed if the possible types for a USE variable were: 1) member-of: for choosing the backend of certain functionality; e.g. all combinations of USE=ssl openssl gnutls nss would become e.g. in the ebuild: USE=ssl=[member-of: openssl,gnutls,nss] in make-conf: USE: ssl=openssl, as synonymous of old USE=ssl openssl, or USE: ssl=none, as synonymous of old USE=-ssl 2) subset-of: for selecting a number of modules to build. This would replace USE_EXPAND quite neatly 3) boolean: as alias for member-of: [true,false] 4) unsigned int: IIRC some (few) packages can take optional uint at configure-time. for example with dev-lisp/sbcl one can customize some hardcoded GC parameters suchs as the default heap size, generation size, etc... In the above case, one could have a USE variable named webkit of type member-of: [qt,gtk] -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
On Mon, 2012-04-30 at 22:00 +0300, Samuli Suominen wrote: [...] The answer I got from Gentoo's Mozilla Team when I proposed bumping it to latest from the Firefox tarball was that use npapi-sdk or spidermonkey instead. Some which have needed more than just npapi-sdk or spidermonkey have happily migrated to gtkhtml, or webkit-gtk. So I don't think it really makes sense to package and **maintain** something upstream doesn't support, therefore I'm agreeing with the Gentoo's Mozilla Team decision on this. So no xulrunner anymore, even if that means losing 'chmsee' and 'kiwix'. Upstream doesn't support it, but Debian, Fedora, openSuse and other distros do so the maintenance work would be shared -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, 2012-03-15 at 00:29 +, David Leverton wrote: On 14 March 2012 23:44, Greg KH gre...@gentoo.org wrote: Oh, and somehow consensus will work? No, sorry, it will not. No, logical analysis will, as I said in the rest of my post which you conveniently ignored - either we conclude with evidence that there are no issues, which should settle the matter for reasonable people, or we discover that there are, in which case they have to be dealt with one way or another. I really don't see how anyone can object to that, unless they're worried they won't like the result How about the basic FACT that today, such systems do not work This is debatable at best. You can keep screaming but bluetooth won't work! until you're blue in the face, but that's not relevant at all to people who don't use bluetooth. That's true, but given the need to have a one size fits all boot system(for obvious practical reasons), such boot system needs to work with bluetooth input devices -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Tue, 2012-03-13 at 20:29 -0400, Joshua Kinard wrote: On 03/13/2012 05:14, Canek Peláez Valdés wrote: And besides, genkernel and dracut are automatized; they *are* the simple (and proper, IMHO) solution. My contention is that I shouldn't need an initramfs loaded into my kernel to get my system into a minimally-usable state. I've been running separate /usr setups for 10+ years, and only now, such a setup breaks, hence my beef with Fedora's assertion that such a setup is wrong. You simply misunderstood their point -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: deprecate /usr/share/doc/$PF
On Mon, 2011-12-19 at 05:23 +0100, Ulrich Mueller wrote:
On Sun, 18 Dec 2011, Alexandre Rostovtsev wrote:
Can we please avoid the bloat of another directory level here?
${CATEGORY}/${PN} will be even longer than ${PF} in most cases.
The problem is that ($PN, $CATEGORY) pairs are not unique. Think of
x11-terms/terminal:0 and gnustep-apps/terminal:0, or
app-misc/beagle:0 and sci-libs/beagle:0, or app-misc/nut:0 and
sys-power/nut:0. I could not think of any better solution than using
$CATEGORY/$PN-$SLOT.
Thinking about it a little more, I believe that ${CATEGORY} shouldn't
appear anywhere in the path of installed files, for the following
reasons:
1. Users may not know the category of a package, therefore it's not
obvious for them where to find its documentation. (Think of it from
the perspective of a user on a multiuser system, who didn't install
the packages on that system.) OTOH, the name of the package (PN) is
obvious in most cases, since it will coincide with the upstream
name.
Every other distro includes the category in the package name, for
example Debian puts mod_fastcgi documentation
in /usr/share/doc/libapache2-mod-fastcgi and in practice it's really not
that big of a problem
2. It doesn't play well with bash completion. When searching for
documentation of a specific package (and only knowing PN), one can
currently type the pathname up to PN and press tab which will
complete PVR. With CATEGORY _before_ PN this would no longer work.
It's just an ls -d /usr/share/doc/*/$PN, not worth worrying about
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Calling unknown commands in an ebuild
Wouldn't it be a good idea to use set -e in the ebuild environment ? I've seen cases of ebuilds calling epatch without inheriting from eutils which compiled and installed (apparently) fine but possibly broken binaries. Examples of cases where set -e would have helped: 303849, 297063, 260279, 221257, https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found and perhaps others I haven't managed to find in bugzilla -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Calling unknown commands in an ebuild
On Sun, 2010-02-07 at 14:19 -0800, Zac Medico wrote:
On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
Wouldn't it be a good idea to use set -e in the ebuild environment ?
I've seen cases of ebuilds calling epatch without inheriting from eutils
which compiled and installed (apparently) fine but possibly broken
binaries. Examples of cases where set -e would have helped: 303849,
297063, 260279, 221257,
https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found
and perhaps others I haven't managed to find in bugzilla
I don't know what kind of side-effects set -e would introduce, but
we can easily add a repoman check for epatch calls without eutils
inherit.
Exit immediately if a pipeline (which may consist of a single simple
command), a subshell command enclosed in parentheses, or one of the
commands executed as part of a command list enclosed by braces (see
SHELL GRAMMAR above) exits with a non-zero status. The shell does not
exit if the com- mand that fails is part of the command list
immediately following a while or until keyword, part of the test
following the if or elif reserved words, part of any command executed
in a or || list except the command following the final or ||,
any command in a pipeline but the last, or if the command's return
value is being inverted with !. A trap on ERR, if set, is executed
before the shell exits. This option applies to the shell environment
and each subshell environment separately (see COMMAND EXECUTION
ENVIRONMENT above), and may cause subshells to exit before executing
all the commands in the subshell.
Portage already does a search of the build log for 'command not
found' messages and generates a QA warnings. Set
PORTAGE_ELOG_CLASSES=${PORTAGE_ELOG_CLASSES} qa in /etc/make.conf
if you want to have those warnings logged.
My point is that whenever the ebuild is trying to execute a command that
does not exist, it should die immediately because there's no way to know
how the failure to execute that command might affect the rest of the
build process
epatch was just an example because it's probably the most used function
from eutils.eclass
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). you can solve this right now, even if in a not very elegant way. For instance, if you need glibc with NPTL support, you can use elibc_glibc? ( =sys-libs/glibc-2.3 || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) ) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
On Wed, 2009-02-18 at 23:24 +, Ciaran McCreesh wrote: On Thu, 19 Feb 2009 00:03:24 +0100 Jeroen Roovers j...@gentoo.org wrote: On Wed, 18 Feb 2009 22:55:06 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: ...which is why you ask for 'paludis --info pkg', not 'paludis --info'. Spread the word! http://git.pioto.org/gitweb/paludis.git?a=commitdiff;h=86dc61e could the output of paludis --info be made a little less verbose by eliminating repository information - perhaps except then one containing the package's ebuild - and info about ebuild phases being executed(like Starting builtin_initmisc etc...) ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
On Tue, Jul 17, 2007 at 09:41:04AM +0300, Petteri Räty wrote: Alin Năstac kirjoitti: Marius Mauch wrote: Two questions: - are there more packages that could benefit from this? None that I know of. However, there might be other similar packages without a source tarball (slim chance, but quite possible). At first, I asked upstream to provide such tarball, but I got refused because SourceForge file release process is far too annoying. As a side note, if bitpim wasn't such a fairly popular package, I wouldn't even bother with it (personally I don't use it). This is not uncommon in the Java land. it's also quite common in CommonLisp land -- (sign :name Stelian Ionescu :aka fe[nl]ix :quote Quidquid latine dictum sit, altum videtur.) pgpWn02WOwyWY.pgp Description: PGP signature
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
On Thu, Oct 05, 2006 at 03:32:41PM -0500, Steev Klimaszewski wrote: [:snip:] Stop being stupid please, you're only making fun of yourself. I guess I don't have to explain you how useful a URL is to a _networkless_ installation, do I? No... but didn't one download and burn that CD that is being used for the _networkless_ install? One could also download the stage needed, actually, at least here in Italy many people buy Linux magazines only to have the latest distros, since the percentage of population not reached by *DSL lines is still quite high -- (sign :name Stelian Ionescu :aka fe[nl]ix :quote Quidquid latine dictum sit, altum sonatur.) pgpkZIRwO2Zbg.pgp Description: PGP signature
Re: [gentoo-dev] inetd/xinetd useflags
On Tue, Jul 05, 2005 at 08:34:20PM -0700, Donnie Berkholz wrote: Mike Frysinger wrote: personally i'd support a doxinetd func that would check to see if xinetd is installed rather than go with a USE flag ... This kind of auto-enabling stuff is our bane upstream, so I don't see that creating more of it ourselves is a good idea. yes, but since it's common practice to have all xinetd services disabled by default that won't hurt because the user will have to enable the service manually anyway. -- Stelian Ionescu aka fe[nl]ix Quidquid latine dictum sit, altum sonatur. pgp24K3lGC30i.pgp Description: PGP signature
