Re: [gentoo-dev] why not player/stage/gazebo
On Sat, May 17, 2008 at 2:37 PM, Zhu Sha Zang <[EMAIL PROTECTED]> wrote: > Ok, show me the path to be a gentoo's developer. > > Maybe i can do it now. 1. Pick up a part of Gentoo that you'd like to work on (clearly robotics packages in this case). 2. Work on it (fix bugs, add features, document, and so on -- more information at http://www.gentoo.org/doc/en/?catid=gentoodev and http://devmanual.gentoo.org/) 3. Once you have established your interest and ability to help, find a mentor 4. Your mentor will guide you through the recruitment process Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: About herds and their non-existant use
On Thu, May 22, 2008 at 2:34 PM, Diego 'Flameeyes' Pettenò
<[EMAIL PROTECTED]> wrote:
> Luis Francisco Araujo <[EMAIL PROTECTED]> writes:
>
>> Unless a team can maintain several herds, I find the term 'herd'
>> confusing and better understood as 'team' instead.
>
> +1 on this. I always thought that if almost every dev misuses the term
> herd, it was because the term had to be changed, rather than the devs
> corrected...
Till very recently, I too misunderstood the meaning of the term. I
think one problem is that the term really hasn't been defined anywhere
(at least I couldn't find a proper definition on [1]).
I really do like the herds terminology because it is unique and has
become a Gentoo-ism of sorts. It also is reminiscent of Larry, in some
sense (herds -> grazing -> moo -> cow -> larry). :)
[1] http://www.gentoo.org/proj/en/metastructure/herds/
Just my ${currency} 0.02,
--
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] [RFC] Eclass for gnome-python* split
Greetings All, I've been working on an ancient bug [1] requesting a split of the gnome-python, gnome-python-extras, and gnome-python-desktop ebuilds. The motivation behind the split is that packages that depend on a single module or a small set of modules from one of these packages end up pulling in the numerous dependencies required when pulling all the modules in the package (example -- nautilus gets pulled in because of a dep on the gnomeprint module). I have split these 3 packages into packages for the component modules. Since there was a lot of common functionality between these packages, and the 28 modules' ebuilds were basically very similar, I've split out a large amount of the required functionality into an eclass. The work is heavily based on Jim Ramsay's ([EMAIL PROTECTED]) work on splitting gnome-python-desktop. The split ebuilds are available via a git repository [2]. The actual eclass can be viewed online at: http://tinyurl.com/6z2ltc (full URL [3]) Feedback and comments (and even brickbats ;)) on the eclass are invited. [1] https://bugs.gentoo.org/show_bug.cgi?id=108479 [2] http://gitorious.org/projects/g-py-split/repos/mainline (branch is g-py-split) [3] http://gitorious.org/projects/g-py-split/repos/mainline/blobs/g-py-split/eclass/gnome-python-common.eclass Cheers! -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] Eclass for gnome-python* split
Hello! 2008/5/24 Ali Polatel <[EMAIL PROTECTED]>: > Attached is a patch for two minor issues with the eclass. First try to > remove py-compile only if it exists. Second, python_mod_optimize is > ROOT aware (since recently). Thanks for the feedback ... I've checked in your patch. Best, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] Eclass for gnome-python* split
On Sat, May 24, 2008 at 9:02 PM, Christian Faulhammer <[EMAIL PROTECTED]> wrote: > "Arun Raghavan" <[EMAIL PROTECTED]>: > >> Feedback and comments (and even brickbats ;)) on the eclass are >> invited. > > * Don't install the COPYING file via the DOCS variable. > * The LICENSE should be kept per ebuild in my opinion Changes made and committed -- thanks! There was one interesting observation while I was looking at the license for the gtkspell module. gtkspell-2 is licensed GPL-2, but gtkspell-3 (which is not yet released and has only recently picked up a little steam upstream) is licensed LGPL-2.1. Based on this gtkspell-python needs to be conditionally licensed based on which version of gtkspell it is linked against (GPL-2 if against gtkspell-2, LGPL-2.1 if against gtkspell-3). Something like: if has_version =dev-python/gtkspell-2*; then LICENSE="GPL-2" else LICENSE="LGPL-2.1" fi There is currently *no* way to express this in an ebuild without invalidating the cache. For now this is just a theoretical problem, but worthy of consideration nonetheless. Cheers! -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] merging two packages - upgrade path?
On Thu, Jun 5, 2008 at 4:11 PM, Ulrich Mueller <[EMAIL PROTECTED]> wrote: [...] >> #1 is the default used in the tree. > > With good reason, IMHO. This is a package manager issue which > shouldn't be "solved" by creating strange dummy ebuilds. Won't the new portage unmerge-on-blocker feature take care of this now? Cheers, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] threads vs. smp
On Sun, Jun 8, 2008 at 6:04 PM, Hanno Böck <[EMAIL PROTECTED]> wrote: > I got this bug and as I don't know if this is correct what the user says (no > idea about smp), I'm posting this here for comments: > > https://bugs.gentoo.org/show_bug.cgi?id=224729 Looks like there are 3 possible uses of the threads/smp USE flags: 1) Add support for a threading API in a library/language (for example in dev-lisp/sbcl) 2) Add support for threading in an application (www-servers/apache, for exmple) 3) Add support for a multi-processor machine -- this is different from (2) in that the application doesn't really gain anything if this is used on a uni-processor machine (sys-cluster/charm seems to fall in this category) I guess it would be consistent to use "threads" for (1) and (2), and "smp" for (3). Now, as for Gimp, grokking through the sources shows that "--with-mp" basically lets some processing stuff run in separate threads. This is clearly only useful on SMT/CMP/SMP machines, so I think USE=smp is fine. The user's complaint could be valid, though. Perhaps "smp" should be a global USE flag. Cheers, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] die/QA notice for do* failure?
Hello All, We were just discussing if it makes sense to either die or issue a QA notice if one of the do* functions fail. It turns out that there's already a bug for this [1]. This potentially applies to all helper functions that don't currently die on failure. I think this is a good thing to have (die if one of these functions fails). Otherwise, every ebuild needs to explicitly chalk out all its error paths which is cumbersome, and not really required, since a vast majority of ebuilds *should* fail if one of these functions fails. Another option is to throw a QA notice (possibly die only FEATURES="strict"). The bug basically seems only wanting in consensus on this matter, which is why I'm posting this here. [1] http://bugs.gentoo.org/show_bug.cgi?id=138792 Cheers, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] die/QA notice for do* failure?
On Sun, Jun 8, 2008 at 8:29 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] > This isn't as simple as you think, since quite a few of these utilities > are called using 'xargs' and so have to be binaries. Whilst Paludis can > deal with external binaries triggering a die because exheres needs it > (exheres has everything as fatal except where preceeded by 'nonfatal'), > I'm not sure that Portage can just now. I didn't understand you. Even if the external binary can't call die, what's to prevent the caller from dying based on the return value of the called binary? > Also note that quite a few packages rely upon the current nonfatal > behaviour, so it'd need to be an EAPI bump... It should not be necessary to define a new EAPI to make sure packages are not broken. If there really are a lot of packages that rely on the current behaviour, we can easily implement this in a phased manner: make it a QA notice to start with and make it default behaviour after 3-6 months or whatever time period is suitable. BTW, do you have any examples of packages relying on non-fatal behaviour for do* stuff? It'd be interesting to see why it might be necessary. Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] die/QA notice for do* failure?
On Sun, Jun 8, 2008 at 8:57 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
[...]
>> I didn't understand you. Even if the external binary can't call die,
>> what's to prevent the caller from dying based on the return value of
>> the called binary?
>
> Then we're back to having people do dobin || die, which is precisely
> what we're trying to solve.
Not really. Can't dobin be like so:
fail() {
if hasq strict FEATURES; then
die "$@"
else
ewarn "QA Notice: [EMAIL PROTECTED] blah foo"
}
dobin() {
dobin.sh "[EMAIL PROTECTED]" || fail "dobin failed"
}
>> It should not be necessary to define a new EAPI to make sure packages
>> are not broken.
>
> Yes it should. It's a change in behaviour in functionality upon which
> quite a lot of things depend.
This is not functionality. It is the lack thereof. Making this part of
an EAPI makes it opt-in, which it shouldn't be. It is important for QA
and should be mandatory for all ebuilds.
Regards,
--
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] die/QA notice for do* failure?
On Sun, Jun 8, 2008 at 10:21 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] > That's not how it works. We've seen plenty of times in the past > that forcing QA by making users' systems break (which is how far these > things get before they're fixed) just leads to lots of annoyed users. > EAPI, plus slowly moving things towards new EAPIs on version bumps once > newer EAPIs are widely supported, is the clean way of doing this. This might be the clean way to do it, but the unfortunate truth is that new EAPIs seem to be becoming "standard" pretty darn slowly, and counting on one to implement a feature that is definitely very useful for QA seems to be miring ourselves in unnecessary bureaucracy. Also, this does not have to cause breakage if done incrementally, so the net loss is nil, and the net gain is getting a useful feature in a relatively short, deterministic period of time rather than otherwise. -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] die/QA notice for do* failure?
On Sun, Jun 8, 2008 at 11:04 PM, Santiago M. Mola <[EMAIL PROTECTED]> wrote: [...] > There has been previous discussion on > https://bugs.gentoo.org/show_bug.cgi?id=138792 Right, I'd mentioned that in the original post. I posted here in order to get some general consensus on the matter and take it forward. Cheers, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] > - it doubles the number of file reads necessary during resolution. The first read will cause the file to be cached for subsequent reads anyway, so the performance hit boils down to an additional read() call (which will probably be buffered by your file I/O library anyway, so it's unlikely to even result in a context switch). And even without, it is well worth the lack of fugliness in the ebuild name. > - it heavily restricts future syntax and meaning of EAPIs Not by much. It's just a header. > - it makes comments have meaning Just as much as #!/bin/bash and # vim: ... do Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] >> I don't think that filename-vs-first-line is going to make a big >> difference in practical performance. > > It's about a factor of five difference in cold-cache resolution > performance for Paludis. Could you please share more details on the experiment that showed this kind of performance degradation and the numbers, if possible? Thanks, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 7:44 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] >> The first read will cause the file to be cached for subsequent reads >> anyway, so the performance hit boils down to an additional read() call >> (which will probably be buffered by your file I/O library anyway, so >> it's unlikely to even result in a context switch). And even without, >> it is well worth the lack of fugliness in the ebuild name. > > No, it results in a new open() on a file that's elsewhere on disk, which > results in two new seeks. You get about fifty seeks per second. Well, most file systems have a local structure for this data (=> block group), so it's not going to be a seek that's very far. Secondly, how many ebuilds do you need to read directly to get this data in a typical case? Isn't this what the metadata cache is for? >> > - it heavily restricts future syntax and meaning of EAPIs >> >> Not by much. It's just a header. > > Do we want to keep the spec so wide open that we support any format under the Sun that we fancy? Seems like overgeneralizing to me. Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] >> Why would you need the EAPI before the time when you actually want to >> interpret the contents? > > You need the EAPI before you use the metadata. But you don't need the > ebuild to get the metadata in the common case. Does the cache format _really_ need to be extensible the extent that we're jumping hoops to support arbitrary cache formats? -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 12:06 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Wed, 11 Jun 2008 08:31:45 +0200 > Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: >> On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: >> > You're missing the cases where the cache isn't usable. >> >> I was not talking about generating cache entries, and neither were >> you. I've replied to you because you were suggesting that the "EAPI in >> ebuilds contents" solution had extra cost when _using_ valid cache >> entries (need to extract the EAPI from the ebuild before reading this >> cache entry), which i think can be easily avoided. > > And it does, since EAPI has to be known to use the cache contents. The > way it's handled currently is a hack that doesn't work with future EAPIs > defining new metadata. Fix that, then. And I understand that the code is already there in both portage and pkgcore to store the cache as key-value pairs rather than one-slot-per-key, and would be relatively trivial to add to paludis. Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, Jun 13, 2008 at 6:43 AM, David Leverton <[EMAIL PROTECTED]> wrote: > 2008/6/13 Duncan <[EMAIL PROTECTED]>: >> In this instance, it's the "pulling teeth" to get info on a claimed known >> bug from PMS folks on pkgcore, while at the same time, complaints about >> the non-clarity of PMS is met with remarks (by the same group of people) >> of (paraphrased) "filed a patch yet?" > > In the case of the pkgcore bug, there was an objective statement of > the fact that a bug existed, including simple instructions for > reproducing it (which were dismissed by a certain person claiming he > had already done so and found no bug - clearly a lie). In the case There's a bug is an objective statement, I agree. Write some tests and figure it out for yourself is simply malice (yes, I realise it was you who provided the failing ebuild, and that is appreciated). And why do you have to be plain insulting about it? Nobody can magically spot every single bug in any piece of code presented to them. In fact it's why the "given enough eyes ..." adage is one of the bases of open source development. I _honestly_ do not understand why there is so much trouble in simple cooperation amongst adults. Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, Jun 13, 2008 at 10:56 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] >> I _honestly_ do not understand why there is so much trouble in simple >> cooperation amongst adults. > > I agree entirely. Why the pkgcore people refuse to do basic automated > tests is completely beyond me. This seems to be more of the kind of baiting that you use to cause threads to spiral into irrelevant bickering that more than enough people on this list are sick of having their mailboxes flooded with. So I'm out of this thread until there is a reasonable discussion happening. -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Thu, Jun 19, 2008 at 6:51 PM, Richard Brown <[EMAIL PROTECTED]> wrote: > http://en.wikipedia.org/wiki/Idiot This is the second time in 8 days that you are doing this. Please stop filling our inboxes with this puerile trolling. Devrel team: I do appreciate that the Gentoo Way has been to keep the communication channels as open as possible, but a line must be drawn *somewhere*. -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] metadata.xml USE flag descriptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug Goldstein wrote: [...] > Ford_Prefect is taking gnome-base And gnome-extra. Cheers, Arun -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiN/FIACgkQ+Vqt1inD4uyqkACghaEJjvUKUeNS1EFHUpoWih9M fW8AoIsW8a174NLcHsF/TvwkSlQMOuxF =4lg7 -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] metadata.xml USE flag descriptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug Goldstein wrote: > Please make sure you commit any changes to use.local.desc to > metadata.xml otherwise you risk the chance of having your changes lost. > I'm currently in the process of converting use.local.desc to > metadata.xml. After a category is converted, it will be auto-generated > EXCLUSIVELY from metadata.xml. This means it will be YOU QA error if you > only commit to use.local.desc from here on out. Quick howto from IRC logs for those who want to get started: Copy the stuff to metadata.xml, fix the typos and grammatical issues, and any package or category references need to be wrapped in or Cheers, Arun -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiOD+kACgkQ+Vqt1inD4uz/4gCdHWwzT/AY2n7/gSZmDTxqKM6W 1WcAn1parGcFWW/+VqpuawTbd/ZkjcAu =f18e -END PGP SIGNATURE-
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Bridge wrote: > On Sat, 16 Aug 2008 18:42:35 +0200 > Aniruddha <[EMAIL PROTECTED]> wrote: > >> I've filed the bugreport (version bump) a year ago. It looks like borg >> has no maintainer. > > So maintain it. You don't need to be a dev to write an ebuild, and > there are enough devs who are happy to throw an eye over user donated > ebuilds and commit them to the tree... And then there's the sunrise overlay [1]. Cheers, Arun [1] http://overlays.gentoo.org/proj/sunrise -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkinH2UACgkQ+Vqt1inD4uyUHQCfTtssO+sJ7DO3LB2acCvRoqAS znQAoI3eDIJQmDYcsoNfQNIQGHEIhUN6 =qewP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: [...] > The benefit is that it's a logically separate action, and will avoid > all the silliness of people repeatedly changing their minds about > which phase should do the eautoreconf calls and so on. a) Is this really an issue for maintainers? b) Does it really matter? c) So the flow will look like: ... src_unpack src_prepare src_configure src_compile ... To me this seems like an unnecessary overgeneralisation. The *only* potential "benefit" I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is "vanilla". This is not something I see as being useful to us. - -- Arun -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkirCm0ACgkQ+Vqt1inD4uyTvQCgjEPHRCJUFrIsoyk5EnYb/jNC Lu8An0KTbHP59UXa4UcShSC7VwLUgQpI =zwPv -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: > On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote: >> I personally agree with several others who have replied to this thread. >> The reduction in lines of code/characters seems to introduce an uglier >> syntax which is harder to read with questionable benefits. > > One of the great things about ebuilds is that they're very natural to > write in most cases, if you can manage to build the program by hand. > Raising this barrier of entry for questionable benefit seems like a bad > idea. We don't need to make it any harder to begin contributing to > Gentoo. +42 - -- Arun -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjKqLgACgkQ+Vqt1inD4uwD9ACfXJSvMQ2Xsj+IlXz9F3QrgKiC dSMAoKEPhM1KlL35fE7uxc6DZHegzIcW =qTCS -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Long wrote:
[...]
>>> for ((i=0;i<10;i++)); do echo /usr/share/doc/${P}/examples >
>>> /dev/null;
>>> real 11.25
>>> real 9.24
>> So that's what, on the order of 20 microseconds faster for each iteration?
>>
> Or ~18%. (You shouldn't use the first iteration in general, btw.)
I've not really got an opinion on the topic, per se, but fwiw, this is
really not a meaningful statistic. *If* parsing strings in the ebuild is
not a trivial part of the overall ebuild parsing process, then yes, this
is a significant gain and should be treated as such. I find it unlikely
that this would be the case.
I'm not sure how one can go about measuring the impact of this on ebuild
parsing as a whole. Maybe make take a few "typical" ebuilds, change
quoting style, and run it through ebuild.sh in a loop. All the inherited
eclasses would need to change too, though, I guess.
Regards,
Arun
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkj2sxgACgkQ+Vqt1inD4uzW3wCfancNcJxcyHerjSZdZfK9UKb7
k5oAn0186/lLTAS2+n1Z7egzhAP1kISV
=CkaZ
-END PGP SIGNATURE-
Re: [gentoo-dev] GLI Officially Deprecated
On Wed, 2009-01-14 at 17:05 +, Mike Auty wrote: > I realize it might be a bit obvious to us, but from reading it people > might wonder how they're supposed to carry out installs now. When the > notice finally goes out, it might be worth mentioning that just the > LiveCDs are no longer supported, and mention how often the install media > is produced, and basically how people should go about doing installs > these days. It's so easy to misread these things and for people to > start pushing out blogs and articles saying Gentoo's stopped producing > release media, etc, etc... +1 -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New eclass proposal: auto-export
On Wed, 2009-04-22 at 16:35 +0300, Petteri Räty wrote: > Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection > of functions. This way all eclasses don't have to duplicate the EAPI > detection code. If people find this useful, I will document it properly > with eclass-manpages etc. Looks like a nice way to avoid silly errors while writing eclasses. Would this make sense as a package manager feature? -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] license issue with fretsonfire
On Sat, 2009-05-02 at 18:17 +0200, Mounir Lamouri wrote: [...] > I think the code can be considered GPL-2 (i will check if there is no > header specifying something else) and for the fonts, I will have to add > 2 licenses not in the tree at the moment. > But what to do with the songs ? I suppose it's not the first GPL game > having "non very clear" license about data. How games team is managing > that ? The fonts license seems to be the same as licenses/BitstreamVera which is in-tree. As for the songs, does it make sense to put that in a separate package that the code package depends on? The package can have the restrictive license it is distributed under and RESTRICT="mirror bindist". -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote: [...] > So if you were a lazy Unix coder you'd just restrict the current rules a bit > so that there's only one line starting with EAPI= allowed (or maybe you just > take the first or last one, but that's annoying) and if no such line matches > you can safely assume EAPI0 > > Maybe you're very lazy, so you explicitly forbid eclasses from setting or > changing EAPI. That also avoids weird effects that make you lose lots of time > for debugging because you didn't think about what would happen if foo.eclass > set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ... > > And magically you haven't really changed current behaviour, can get the EAPI > without sourcing it and you can be lazy once more. Isn't it great? As I've stated a long time ago, I'm for this solution. My understanding is that there are 2 objections to this: 1) We can't change the ebuild format to XML or what have you. I think this is a problem to deal with *if it ever happens*. I am completely against trying to solve a problem that will not exist in the foreseeable future. 2) There might be a performance impact for cases where the metadata is uncached - I think the impact is acceptable in the face of the fugliness added by putting the EAPI in the ebuild's name (Joe Peterson summarise this quite well earlier [1]). Really, the key issue seems to be (1), because there's no other good reason to be trying to adopt this GLEP. -- Arun [1] http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg29311.html signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote: > On Sat, 16 May 2009 17:43:32 +0200 > Tobias Klausmann wrote: > > > That doesn't let us do version format changes. > > > > Or are we talking about the *ebuild* versions? I see that as > > different matter. Plus: You could change the version format with > > the changed extension. I sure do hope there are no plans on > > making those changes as often as new EAPIs. > > Yes, those. The current rules include some pointless arbitrary > restrictions that are only there for historical reasons and that mean > people have to mess with convoluted MY_PV things. So from all the debate that's going on, the current major issue seems to be being able to support '-scm' as per GLEP-54. What other restrictions in the version format are you referring to? -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote: [...] > For one, there's the restriction that all *-alpha/*-rc has to be > represented _rc/_alpha. I plan on doing more research into perhaps > lifting this restriction in a future EAPI, but this would of course > require glep 55's solution. As Tobias stated, I also prefer coming up with solutions to these problems *now*, and fixing them, rather than implementing (IMO) a fugly solution to make solving potential problems that we don't know exist easier. -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote: > > Ok, what are all the things requiring format-break changes that we'll > want in the next ten years? Please provide a complete list. Don't care. Let's fix the problems we have *now* using solutions that we can agree upon, rather than try to foist solutions that a reasonably large population of developers *don't* like (even after extended debate) to solve problems that don't exist yet. -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote: [...] > > Don't care. Let's fix the problems we have *now* using solutions that > > we can agree upon, rather than try to foist solutions that a > > reasonably large population of developers *don't* like (even after > > extended debate) to solve problems that don't exist yet. > > No, let's fix it so we don't have to do the whole thing again in > another year or two. I see nothing about the current problem that merits the fooling around with the ebuild extension. I've listened to and considered all the arguments that have been made, and I still stand by my opinion that it an unclean solution (meaning, we don't need to rehash those arguments again here). Bottom line, we (everyone who has been on this discussion from the beginning) disagree. Just as we did a year ago. Standing steadfast on the filename extension just means that all the version format problems that you're trying to solve are going to stand blocked because of it. I think it makes far more sense to work towards agreeing on a solution rather than restating the same arguments every 6 months and reaching the same impasse. -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote: [...] > You have yet to provide an alternative for fixing the arbitrary and > pointless version format restrictions that are currently in place. Create an EAPI for the required changes, fast track inclusion to a stable portage. If this is not viable, make an unrecognised version string cause the same fallback as an unsupported EAPI => ignore the ebuild. Again, fast track to stable portage, and not so long after, you're done. -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sat, 2009-05-16 at 20:21 +0100, Ciaran McCreesh wrote: [...] > Can't do that. The package manager has to barf on unrecognised .ebuild > files. I assume the reasons are the same as below. > > If this is not viable, make an unrecognised version string cause the > > same fallback as an unsupported EAPI => ignore the ebuild. Again, fast > > track to stable portage, and not so long after, you're done. > > Again, no good. First, it means a year or more wait before doing > anything. Second, it removes a whole level of error checking. Third, it > means a package manager can't know what versions are available for a > package without generating metadata for every potential version. 1) Why a year? I'd say 4-6 months after portage goes stable is fine. 2) Replace the errors with warnings. And these need to exist only at 'repoman manifest' time, so they're not end-user-visible (and don't need to be). -- Arun 3) This is again, when the metadata is uncached, which is not the normal case and can be ignored. And the (minor) performance penalty in the cached case, if any, is not reason enough to make this change. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sun, 2009-05-17 at 07:40 -0400, Thomas Anderson wrote: [...] > The difference is that putting the EAPI in the filename has backwards > compatibility because package managers not knowing about this change > won't even look at the those ebuilds. Putting EAPI as the fifth line > completely loses this, so as far as backwards compatibility goes putting > EAPI 55 in the filename really is the cleanest. That's not very hard to overcome without polluting the file name, as I've already pointed out. -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Hello, I haven't been able to attend a council meeting for a bit since it occurs at ~2:30 am my time, but for what it's worth: On Mon, 2009-06-01 at 23:15 -0500, Doug Goldstein wrote: [...] > 1) Agenda Topics are posted to the appropriate mailing lists at a > MINIMUM 7 days prior to the meeting. (That means the agenda must be > formed by this Thursday). > 1a) Any changes to the agenda should be ACK'd by the council members > (off list via the council alias). Changes can not occur less than 48 > hours from the meeting. Subject to common-sense w.r.t. making exceptions (which I presume will be few and far-apart), ++. > 2) The #gentoo-council channel become moderated as we had discussed > several times in the past. > 2a) Topics will be brought up and people wishing to address the > council and the developer body at large should speak to the day's > appointed moderator. We can take turns or I can do it (maybe it'll > keep my head from banging against the keyboard as it has in the past > watching the various non-council members argue completely non-agenda > items back and forth). > 2b) Requests are made in tells and honored in turn. The moderator will > announce to the channel who wishes to speak and the order they are in > and will efficiently work through the list. If you can not remain on > topic, you will lose your voice. I thought the intention was to have this as the policy whenever things got out of hand. Am I wrong, or is it just that this not been enforced? I'm all for this as a discretionary measure. > 3) Once discussion on the topic has concluded, the council members > will vote on the actions requested by the developer body. That does > not mean it is time for council members to concoct an entirely new > plan by the seat of their pants... which leads me to the next topic. ++ > 4) Council members will now be expected to ACK the agenda on the > appropriate mailing lists at least 48 hours prior to the meeting. If > you can't, let the council know. You should be able to do this without > relying on your proxy, but your proxy may do this for you as well if > you have an extended away. > 4a) Failure to ACK the agenda will be noted on the meeting minutes. I don't really see this as being strictly necessary. If we find ourselves having to use this measure often, there's definitely something wrong with the system. > 4b) Council members will be expected to formulate their thoughts in > reply to the agenda items and to research the discussion they wish to > have on the mailing list PRIOR to the meeting and not fly by the seat > of their pants. ++ > 4c) "The first I heard of this and I need 4 weeks to research this." > or any variation of the quoted statement is no longer a valid > statement. The point of the meeting is to weigh and debate the items > before us now. Do your research PRIOR to the meeting, not during. I guess 4 (c) can be made - if enough members of the council require more time to grok the issue, then just postpone the item? At one of the earlier meetings that I had attended, the modus operandi was to allocate some amount of time to discussion of the topic, and then either (a) make a decision (if things are reasonably clear), (b) defer till the next meeting (if they're not) Keeping things time-bound might sound a bit overboard, but for the more contentious topics, it's a good way to make sure that you don't just end up running around in circles. -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] epatch_user usage
On 24 April 2012 09:15, Doug Goldstein wrote: > So I've just had one reservation when using epatch_user for allowing > users to apply patches. And that's figuring out when to run > eautoreconf. I don't necessarily want to run it unconditionally but > sometimes users have patches which touch autoconf files but my > existing patch set doesn't so I'm not calling eautoreconf. Does anyone > have a suggested way to handle this? grub2 checks for a DO_AUTORECONF env. var. to decide whether to run eautoreconf. This does cause some QA warnings, though. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Stability of /sys api
On 16 May 2012 05:21, Walter Dnes wrote: > On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote >> 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 ? > > 1) Did you sleep through the /usr and initramfs flamewars? > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken You seem to have missed the bit that this has nothing at all to do with systemd. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 09:58, Greg KH wrote: > So, anyone been thinking about this? I have, and it's not pretty. > > Should I worry about this and how it affects Gentoo, or not worry about > Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? > Minor details like, "do we have a 'company' that can pay Microsoft to > sign our bootloader?" is one aspect from the non-technical side that I've > been wondering about. Sounds like something the Gentoo Foundation could do. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 10:26, Greg KH wrote: > On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: >> On 15 June 2012 09:58, Greg KH wrote: >> > So, anyone been thinking about this? I have, and it's not pretty. >> > >> > Should I worry about this and how it affects Gentoo, or not worry about >> > Gentoo right now and just focus on the other issues? >> >> I think it at least makes sense to talk about it, and work out what we >> can and cannot do. >> >> I guess we're in an especially bad position since everybody builds >> their own bootloader. Is there /any/ viable solution that allows >> people to continue doing this short of distributing a first-stage >> bootloader blob? > > Distributing a first-stage bootloader blob, that is signed by Microsoft, > or someone, seems to be the only way to easily handle this. > > Although all BIOSes will have the option to turn secure boot off, I > think it is something that we might not want to require for Gentoo to > work properly on those machines. > > Also, some people might really want to sign their own bootloader and > kernel, and kernel modules (myself included), so just getting that basic > infrastructure in place is going to take some work, no matter who ends > up signing the first-stage bootloader blob. I hadn't thought of that. I imagine the hardened team might be interested in making such infrastructure easily available as well. > Oh, and on the first-stage bootloader front, I already know of 2 simple, > and open source, examples that will work for Linux, so getting something > like that signed might not be very tough. It's the "where does the > chain-of-trust stop" question that gets tricky... For validating the chain of trust, it might be useful to make it possible for anyone to generate the same bootloader and verify the hashes themselves. For the truly paranoid maybe a signed stage3 + portage snapshot to generate the bootloader image from scratch. >> > Minor details like, "do we have a 'company' that can pay Microsoft to >> > sign our bootloader?" is one aspect from the non-technical side that I've >> > been wondering about. >> >> Sounds like something the Gentoo Foundation could do. > > Can they do that? I haven't been paying attention to if we are really a > legal entity still or not, sorry. I believe so, but quantumsummers is likely the best person to confirm. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 10:33, Ben de Groot wrote: > On 15 June 2012 12:45, Arun Raghavan wrote: >> On 15 June 2012 09:58, Greg KH wrote: >>> So, anyone been thinking about this? I have, and it's not pretty. >>> >>> Minor details like, "do we have a 'company' that can pay Microsoft to >>> sign our bootloader?" is one aspect from the non-technical side that I've >>> been wondering about. >> >> Sounds like something the Gentoo Foundation could do. > > I'm certainly not the only one who would be averse to paying Microsoft > any ransom money. And our refusal to pay for the signing affects precisely nobody except for our users, who will have to jump through an extra hoop to make their system work. On the flip side, having a simple way to use this infrastructure means that people who care about security can get a chain of trust from the firmware to the kernel (heck, maybe even userspace one day). This is something that is worth having as well. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On 18 November 2012 16:41, Robin H. Johnson wrote: [...] > media-sound/dbmeasure I'll take this one, since it's tangentially related to PulseAudio. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On 19 November 2012 11:00, Robin H. Johnson wrote: > On Mon, Nov 19, 2012 at 10:43:44AM +0530, Arun Raghavan wrote: >> On 18 November 2012 16:41, Robin H. Johnson wrote: >> [...] >> > media-sound/dbmeasure >> I'll take this one, since it's tangentially related to PulseAudio. > Speaking of PA, are you still upstream? If so, can you please merge the > patch I submitted to the -discuss list? Yep. It's on my review list for today. We've frozen master for now though, so might only go into the next release. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Time based retirements
On 21 December 2012 17:36, Ciaran McCreesh wrote: > On Fri, 21 Dec 2012 09:21:57 + > Markos Chandras wrote: >> Your tone is not appropriate for discussion. If you don't like the >> existing policy, bring it to the list with a better >> attitude so we can try and discuss it. But given that you want to pick >> a fight with your email, I will most likely ignore this >> thread and keep doing our job like we do for many years. > > http://25.media.tumblr.com/tumblr_m93x01rSVK1qjvxfho1_1280.jpg And that also makes a convenient way to always ignore the tone of an argument, regardless of whether it is justified or not. I find that Markos' objection is not unfounded and your argument is irrelevant here. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Time based retirements
On 21 December 2012 18:02, Arun Raghavan wrote: > On 21 December 2012 17:36, Ciaran McCreesh > wrote: >> On Fri, 21 Dec 2012 09:21:57 + >> Markos Chandras wrote: >>> Your tone is not appropriate for discussion. If you don't like the >>> existing policy, bring it to the list with a better >>> attitude so we can try and discuss it. But given that you want to pick >>> a fight with your email, I will most likely ignore this >>> thread and keep doing our job like we do for many years. >> >> http://25.media.tumblr.com/tumblr_m93x01rSVK1qjvxfho1_1280.jpg > > And that also makes a convenient way to always ignore the tone of an > argument, regardless of whether it is justified or not. > > I find that Markos' objection is not unfounded and your argument is > irrelevant here. To expand on that a bit -- it's fair game to discuss whether we should give more leeway before pinging idle devs, but pouncing on the people doing to work of trying to make sure packages don't fall off the radar and remain unmaintained is counter-productive and detrimental. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Packages up for grabs due lack of time
On 5 February 2013 23:58, Pacho Ramos wrote: [...] > media-sound/dbmeasure [...] I'll keep this one. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Global useflags zeroconf and avahi
On 2 April 2013 08:17, Alex Xu wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kill zeroconf and use "dnssd", "upnp", "ssdp". Problem solved? I'm not too enthusiastic about that. USE=zeroconf on pulseaudio is a bit easier to understand than USE=ssdp, for example. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On 8 May 2013 21:51, Ben de Groot wrote: [...] > Where upstreams ship systemd units, I don't think there is any issue. > The problem is you are asking Gentoo maintainers to add unit files > that upstream is not shipping. In this case we should test and > maintain these ourselves, which is an additional burden for very > little (if any) gain. The burden is not on the package maintainers, but on the systemd team. The perception of gain is entirely yours (and clearly biased). >>> Mostly the complaints against adding systemd units are that it would >>> unnecessarily clutter non-systemd installs. Users who complain are told >>> to set INSTALL_MASK but that is somewhat unwieldy. >> >> Cluttering a system by just installing 4kb files? The council has >> spoken. If you don't like the decision, I am sorry. >> I can say the same for init scripts, they are freaking cluttering my >> system and they're all over. >> Or perhaps all these man pages, I don't need man pages locally but >> still most ebuilds do install them. What do we do? >> >> Let's be serious here. > > You are forgetting that OpenRC is, and will remain for the foreseeable > future, the default on Gentoo. Any systemd related files are > completely useless for most of our users. And those of us who consider > systemd a cancer do not want to see such files installed at all. The overhead of the files' presence is trivial, and most users won't care. Those who do care have a trivial line to add in make.conf, and that is for the small number of people who share your vitriol for the systemd project. > Gentoo is about choice and configurability. This means we will > accommodate both sides: so those who want to use an alternative init > system can do so, and those who want to avoid it can also keep doing > so. This is a strawman. What Fabio is doing provides more choice, so fits your "Gentoo is about choice" criterion. Making the people who wish to provide this choice jump through hoops merely for personal dislike of the project on the other hand violates this tenet that we all seem to be so fond of. -- Arun
Re: [gentoo-dev] Re: devmanual moved to github
On 12 May 2013 20:34, Markos Chandras wrote: [...] > Besides, most fixes come from users (maybe not the actual patches but > they spot most of the problems) so providing an easier way for them to > contribute is preferred. Moreover, github provides other facilities Is it easier because they already have github accounts or ...? > such as code reviews, which the Gentoo's gitolite interface does not have. GNOME and others provide Splinter as a review system on bugzilla. Coupled with git bz, that should make the patch submission + review process comparably simple. Thoughts? Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 9 August 2013 20:20, Alon Bar-Lev wrote: > On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn > wrote: >> Alon Bar-Lev schrieb: >>> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman wrote: >>>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer wrote: >>>>> You just removed the upgrade path for users. >>>>> >>>> Just install systemd. There really isn't any practical alternative. >>>> Gentoo with systemd is as Gentooish a configuration as Gentoo with >>>> OpenRC, or Gentoo with libav, or Gentoo with emacs. >>> Again, I repeat my-self. >>> >>> Please stop writing these statements! >>> >>> There was no decision to support Gentoo using any other layout than >>> openrc (baselayout). >> >> I think there may be a misunderstanding here. He only said that if you >> want to run Gnome 3.8, then switch to systemd. Because the Gnome team >> will not support any other configuration. >> >> He did not say that everyone should install systemd, nor that you need >> to support such a configuration. > > So users will have gnome working but not any other component? How can > this a good service for users? What do you mean by "any other component" here? -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
On 13 August 2013 10:51, heroxbd wrote: > Dear Fellows, > > Canonical is raising money by pushing their concept of Ubuntu for > Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland) > in parallel to Android to drive the external HDMI output with X11 > protocal, so that desktop applications can run on the smartphone. > > The idea is cool, but not new. The idea is general to all android > devices, while Canonical is binding the concept with its own new device. > > The project is developed underground by Canonical, so far nothing, not > to say repository, is available except advertisements and the call for > people to donate. There are images available for this, btw, if you want to see how it works and poke around. I'd seen some repositories, but don't know if there's enough public to do your own build. > As a natual consequence of the on-going Google Summer of Code project, > Gentoo on Android[3], we can run native Gentoo on *all* the Android > devices. Compiling out an Xorg and output to HDMI has no theoretical > difficulty. Furthermore, sharing of graphic output with Android (instead > of a separate HDMI output) can be explored with wayland x11[4]. There are a lot of _hard_ problems here (display, audio, input, codecs), not to even begin on proper policy integration (your phone is hooked up, voice call starts, what do you do). That's not to discourage your effort at all - I think it's great that you're kicking this off and that there is so much enthusiasm for this. I look forward to seeing the solutions that emerge to solve all of these, and am happy to offer to test on a device or two. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
On 17 August 2013 16:28, heroxbd wrote: > Arun Raghavan writes: > >> There are images available for this, btw, if you want to see how it >> works and poke around. I'd seen some repositories, but don't know if >> there's enough public to do your own build. > > I am very interested in such an image. Would you please dig out a link > for me? I searched the web in vain. None of these worked for you? https://wiki.ubuntu.com/Touch/Install I believe there were efforts to port to arbitrary non-Nexus devices as well. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Multimedia overlay
2009/8/11 Sebastian Pipping : > Josh Saddler wrote: >> I'm well aware of that. It's A Dumb Policy(tm). :) > > What advantage do you see in forcing people to have their overlays > hosted on http://git.overlays.gentoo.org/gitweb/ ? The advantage is primarily that we retain control of the infrastructure on which it (the official Gentoo project) is hosted. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Multimedia overlay
2009/8/11 Nirbheek Chauhan : > On Tue, Aug 11, 2009 at 11:08 PM, Arun Raghavan > wrote: >> The 1-2 times that I asked for access to overlays, time taken was a >> non-issue. If others have had problems, let's fix that instead. > > How much effort do you estimate would need to be invested to have a > webinterface (or similar) which lets overlay owners directly edit > access to their overlay(s)? One (easy) possibility I can think of is > ssh commands. I say "easy" because the service (ssh) and auth (ssh > keys) are already there. Doable, I think, but more man-power (I volunteer to help, btw) might be, on the whole, a lower-effort and more secure option. That said, Robin -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Multimedia overlay
2009/8/11 Markos Chandras : [...] >> The advantage is primarily that we retain control of the >> infrastructure on which it (the official Gentoo project) is hosted. > Sorry but IMHO this is not an argument. By hosting projects/overlays on > gitorious/github we can administer them more quickly without bothering infra > team for minor issues such as giving access to users/developers. This still does not address the original problem - if $external_service shuts down, is bought out, has arbitrary terms about content that are not immediately clear as being unfavourable to us, (at least) that part of the project which is hosted on is negatively affected. The 1-2 times that I asked for access to overlays, time taken was a non-issue. If others have had problems, let's fix that instead. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Multimedia overlay
2009/8/12 Ben de Groot : > Arun Raghavan wrote: >> This still does not address the original problem - if >> $external_service shuts down, is bought out, has arbitrary terms about >> content that are not immediately clear as being unfavourable to us, >> (at least) that part of the project which is hosted on is negatively >> affected. > > As this is a git overlay, it's not a problem. It would be very easy to > move the public repo to another location. Which still does not address concerns about (admittedly paranoid) concerns about terms of use and content. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
2009/8/30 Matthias Schwarzott : > Hi there! > > The new udev-145 and newer have some new kernel requirements. How should the > ebuild verify they are met? > Some possible ways: > 1. Check config under /usr/src/linux > 2. Check /proc/config.gz > 3. Print message for user in pkg_postinst All of the above? Rationale being (1) is required to check against the kernel you're supposedly using, (2) for the kernel you definitely are using, and (3) to make sure people remember. An alternative to (2) and (3), though is to add a check to the udev initscript. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Farewell, Gentoo.
2010/1/2 David Shakaryan : [...] > Once again, thank you for everything, but my time has come. Adieu! Nomp! All the best for the future, and hope the irresistible urge to omp just one more ebuild brings you back. :) Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] proxy maintainership and gentoo-x86 scm
2010/1/15 Robin H. Johnson : [...] > pre-upload-hook: ford_prefect, can I have something by Jan 21st please? > Even just the core C infrastructure for the hook. Sorry about dropping the ball on this for so long - 21st would be hard, but I should be able to get this to you by the weekend. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 13:01, Joshua Saddler wrote: [...] >> I am not pushing for our existing documentation to be migrated into a >> wiki at this point. But I think that once the place is there, and it >> functions well, it would be the obvious next step to do so. As I said >> before, the barrier to contributing and maintaining documentation is >> much higher in the case of GuideXML, so it doesn't really make sense >> to keep that around when we have a better solution. >> >> I know there are people who do not agree with me on this last point [... lots of good reasons to keep the documentation in GuideXML ...] I think the docs team has put in a huge amount of effort for a long time now to make well-formatted, easily readable documentation, and there really isn't a wiki solution out there that is remotely comparable. GuideXML isn't that hard to pick up, and I'm sure the docs team would be happy to help someone who's having trouble figuring out how to do something with it. So I *really* don't see "ease-of-use" being a good excuse for replacing GuideXML with a wiki. The difference in ease is not that high. [...] > I ain't out to stop ya'll from using a wiki. I do agree that they have some > advantages. However, I will point out how limited wikis are. They're not a > magic bullet that will solve all our problems. Again, I agree. We _should_ have a wiki for easy note-taking, maintaining todo lists, possibly even meeting minutes. But our official documentation should go through sufficient review and formatting to make sure we maintain the quality of documentation that we have had so far. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 5 April 2010 08:13, Ben de Groot wrote: > On 5 April 2010 03:13, Joshua Saddler wrote: [...] >> Really, you're mostly making a case for a graphical XML editor like Beacon, >> rather than making a case for a wiki. :) > > That would already be a big improvement, yes. > >> That's your problem, then. Do you know what semantic means? > > Yes, I do. No need to be condescending. > >> But you're not a web author, > > I am, altho not as active lately. > >> Why the hell do you keep bringing up HTML? Stop comparing GuideXML with >> HTML. Treat them as two separate languages, please. > > Because clearly GuideXML is based on HTML. And anyone who knows HTML > will likely be confused by some features of GuideXML. I can't treat > them as completely separate, as there is too much overlap. > >> I only mentioned GuideXML in the context of "it's easier to learn because it >> has fewer tags than HTML" -- you operate under the mistaken assumption that >> GuideXML should be *like* HTML, > > No, I wish it weren't, but it *is* like HTML. > >> and that HTML has too many tags. > > I never said that. > >> You assume that everyone comes from an HTML background and thus will be >> confused by GuideXML. > > I would think that most people that become involved with Gentoo have > most likely been exposed to some HTML coding. You guys should take a while to cool off at this stage. Quite frankly, the documentation project is just another open source project - if anyone wants to change how things are done, the only real way to do that is join the team, prove that you are dedicated and committed, and promote change from the inside. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 5 April 2010 10:34, Arun Raghavan wrote: > On 5 April 2010 08:13, Ben de Groot wrote: >> On 5 April 2010 03:13, Joshua Saddler wrote: [...] > You guys should take a while to cool off at this stage. Never mind me. I missed Ben's last email. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Council meeting 19 April 2010
Hi Ben, On 7 April 2010 22:44, Ben de Groot wrote: [...] > "1. Project Description > The elected Gentoo Council decides on global issues and policies that > affect multiple projects in Gentoo." > > GLEP 39 also says "Global issues will be decided by an elected Gentoo > council." > > So all I'm asking is to do your job and make decisions on issues that > affect all of Gentoo. The issues I brought up are wider than a single > individual project. I don't understand what you expect the council to do in some of these cases. Taking the website redesign or consolidation of documentation as examples, do you want them to: a) Decide that this should be done? b) Call for volunteers? (they obviously cannot force anyone to do it) c) Do it themselves? d) What you probably mean that I fail to see Regards, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12 April 2010 18:43, George Prowse wrote: [...] > If you are arguing that the name is ambiguous then I think you are wrong. > Gentoo knows about the unofficial wiki and knows it's mission is to help > Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like > litigation when trying to protect it's logo. I think the argument is that the wiki is not always accurate, and if perceived as the official documentation, can put is in bad light. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12 April 2010 18:49, George Prowse wrote: > On 12/04/2010 14:17, Arun Raghavan wrote: >> >> On 12 April 2010 18:43, George Prowse wrote: >> [...] >>> >>> If you are arguing that the name is ambiguous then I think you are wrong. >>> Gentoo knows about the unofficial wiki and knows it's mission is to help >>> Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like >>> litigation when trying to protect it's logo. >> >> I think the argument is that the wiki is not always accurate, and if >> perceived as the official documentation, can put is in bad light. >> > There is *always* a chance of that, official or otherwise Which the Wiki team should really be addressing before making a world-editable wiki. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 24 April 2010 23:10, Petteri Räty wrote: > 17:34 < Betelgeuse> robbat2|na: how easy to it to prevent commits to CVS > if the commit message doesn't match a certain pattern? > 17:36 <@robbat2|na> go and checkout the CVSROOT and there should be an > example there > 17:37 < Betelgeuse> robbat2|na: Ok so doable then. Thanks. > > What do you think about not allowing commits to eclasses without > mentioning an another developer who has reviewed and approved the diff > in the commit message? There's enough people on gentoo-dev for urgent > stuff too. Were there recent breakages to make this necessary? Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: [gentoo-core] (infra) rsync updates and distfile fetching offline for next 12-18 hours.
On 20 May 2010 15:51, Petteri Räty wrote: > On 20.5.2010 5.43, Robin H. Johnson wrote: >> On Thu, May 20, 2010 at 01:41:58AM +, Robin H. Johnson wrote: >>> Most critically, osprey, the box that does CVS->rsync generation and >>> master distfile fetching, has been affected. >> Osprey has returned to service. >> > > If you are using gentoo-dev please use the combination of > gentoo-dev-announce and gentoo-dev to reach all devs instead of > gentoo-dev and gentoo-core. Why is gentoo-core is not enough? I thought all devs were expected to follow -core, no exceptions made. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
[gentoo-dev] New global USE flag: introspection
Hi folks, I'd like to propose a new global USE-flag: introspection. The purpose of the flag is to enable the building of GIR for the package using dev-libs/gobject-introspection. gobject-introspection is going to be quite important in upcoming GNOME releases, allowing for the automated generation of bindings for several languages. We already have 13 packages using this flag, with several more to come. The current description being used in packages' metadata.xml sucks - I'll put something more descriptive in the final flag. Any objections? I'll wait till Wed (June 23rd) before adding this if there aren't any. Cheers! -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Tone in Gentoo
If this thread started out at some point as being constructive, it's certainly stopped being so now. Please kill this, take some cool-off time, and come back if there is something *constructive* to be said. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] New global USE flag: introspection
2010/6/21 Olivier Crête : > On Sun, 2010-06-20 at 20:12 +0530, Arun Raghavan wrote: >> I'd like to propose a new global USE-flag: introspection. > ... >> Any objections? I'll wait till Wed (June 23rd) before adding this if >> there aren't any. > > Do we really want it to be a USE flag ? I would force it on always for > everyone. Due to the direction in which GNOME is heading, it will be > required by the core desktop anyway. In addition to what Nirbheek pointed out, I think a USE flag would be useful for embedded setups where you might only want introspection for a subset of libraries. I do agree with you about it being part of the core desktop and required by most users, so it will be enabled by default for all ebuilds. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
[gentoo-dev] Re: New global USE flag: introspection
On 20 June 2010 20:12, Arun Raghavan wrote: [...] > We already have 13 packages using this flag, with several more to > come. The current description being used in packages' metadata.xml > sucks - I'll put something more descriptive in the final flag. Here's the description I'm planning to add: introspection: Add gobject-introspection support, allowing for the dynamic generation of bindings for various languages Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: New global USE flag: introspection
On 21 June 2010 11:43, Alexis Ballier wrote: [...] >> introspection: Add gobject-introspection support, allowing for the >> dynamic generation of bindings for various languages > > why not naming the useflag gobject-introspection then ? Mostly because it seems exceedingly verbose to me (yes, I know we have longer USE flags, and I find them too long as well). -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] New global USE flag: introspection
On 21 June 2010 21:14, Maciej Mrozowski wrote: [...] > If that's the case (they are essential for Gnome or whatever to work, just two > files per package, not bringing any additional dependencies nor probability of > causing compilation failures), I find it rather odd to make it optional at > all. As I explained, the reason I think it makes sense to make it optional is for embedded systems, where you want to enable introspection for only the subset of your package where you need the dynamically generated bindings. I agree that this is a tenuous argument in itself, but I figure that now that we've started this way, and there /is/ a benefit to it, we might as well carry it through. I'm still trying to think of a good name. I understand the concerns about "introspection" being too generic and non GNOME-y, but "gir" is likely to cause confusion. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] My council manifesto
On 22 June 2010 00:40, Mark Loeser wrote: > Its quite simple. I want to get innovation starting in Gentoo again. I > am tired of seeing pointless arguments and threads that don't actually > make Gentoo any better. Improving QA, improving our documentation, > making it easier for people to recognize how they can contribute, and > improving Gentoo as a whole, are all things that the Council should be > taking an active role in, and I want to be a part of making that happen. Do you have any concrete ideas on how you will be doing these things? Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Council manifesto of sping
Hi, On 21 June 2010 22:03, Sebastian Pipping wrote: > Hello! > > > My manifesto up here now: > http://dev.gentoo.org/~sping/council-manifesto-2010-sping.txt For all your points where you do not have a concrete proposal of how you intend to tackle the problem, could you please elaborate? """ (w.r.t. git migration) I hope to see Robin integrate me with the conversion process. """ How have you contributed to the effort thus far? Regards, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] My council manifesto
On 22 June 2010 00:57, Mark Loeser wrote: [...] > Hope that helps, Indeed - thanks for the detailed response. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Council manifesto of sping
On 22 June 2010 03:06, Sebastian Pipping wrote: > Arun, > > > On 06/21/10 21:25, Arun Raghavan wrote: >>> My manifesto up here now: >>> http://dev.gentoo.org/~sping/council-manifesto-2010-sping.txt >> >> For all your points where you do not have a concrete proposal of how >> you intend to tackle the problem, could you please elaborate? > > please take your time to formulate concrete questions. On reading again, you do have suggestions on how you would deal with most of what you've spoken. The only one that I think could use more details (other than all the references to "tone" which I think we should let rest for a while) is "Opening up documentation" - do you have any ideas for this process that might help with this while maintaining the quality the docs team has maintained thus far? As a follow up question, for documentation, PR, the website redesign, and templates, do you feel that these are tasks that need to be addressed by council members? Is there anything preventing you from taking the ball and running with it if you don't get elected into the council? And another one for "More direct democracy": a) How would you decide what questions go up for public vote and which ones stay with the council? b) For questions like "- Should Python 3.x be stable?", isn't that for team leads to decide? And for the council to resolve in case of conflicts? c) For questions like "- Should developer X be banned?", would you be willing to do this if it meant a lot of washing of dirty linen in public, or protracted flamewars (and other reasons why we have a bunch of level-headed people in place to deal with this calmly and quietly)? If no, where would you draw the line? If yes, how would you deal with the fallout? Regards, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Council manifesto of sping
On 22 June 2010 03:06, Sebastian Pipping wrote: >> """ (w.r.t. git migration) >> I hope to see Robin integrate me with the conversion process. >> """ >> >> How have you contributed to the effort thus far? > > I would like to re-phrase this question to > "how come you are able to help", okay? That is not the question I asked. I would like to know why you have chosen not to help with the effort so far and have not voiced your opinion on gentoo-scm which is where the migration has been discussed, even though it is clearly important to you. In general, the way to participate in any open source project (and I believe this holds for a team in Gentoo as well) is not - "You're doing it wrong, let me show you how". It's a combination of, "How can I help?" and "Why don't we try to do things this other way?" Regards, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] New global USE flag: introspection
On 21 June 2010 21:23, Arun Raghavan wrote: [...] > I'm still trying to think of a good name. I understand the concerns > about "introspection" being too generic and non GNOME-y, but "gir" is > likely to cause confusion. "gir" is not good because it gives near-zero information. I can still not think of short enough USE flag. I propose we stick to "introspection". There isn't anything on the horizon that might overlap with this flag, and I don't see why we should drop using a simpler flag for the *possibility* that it might overlap with something else in the future. We can deal with this if it happens. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: Council manifesto of sping
On 22 June 2010 15:32, Duncan <1i5t5.dun...@cox.net> wrote: > Arun Raghavan posted on Tue, 22 Jun 2010 10:43:42 +0530 as excerpted: > >> b) For questions like "- Should Python 3.x be stable?", isn't that for >> team leads to decide? And for the council to resolve in case of >> conflicts? > > Wouldn't the point for specifically pointing out python 3.x as an example, > that there is in fact quite some conflict on it, as demonstrated by the > threads discussing it right here? If I'm not mistaken, sping has in fact > mentioned that as an example in his "tone" thread, as well. If I read him > correctly, the implication is that before it got to the level it did, > council should have voted on it, thus providing a final answer, as an > alternative to the simmering level of discontent that's not quite at the > boiling over point, that we seem to have with the situation now. He does, > after all, make a strong statement in favor of an "activist" council. I did say questions like this one, not only this one. Also, the context of that quote was from the bit of the manifesto that advocates putting such questions to a global vote, which is what I was enquiring about. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: New global USE flag: introspection
On 22 June 2010 16:54, Peter Hjalmarsson wrote: > tis 2010-06-22 klockan 15:17 +0530 skrev Arun Raghavan: >> On 21 June 2010 21:23, Arun Raghavan wrote: >> [...] >> > I'm still trying to think of a good name. I understand the concerns >> > about "introspection" being too generic and non GNOME-y, but "gir" is >> > likely to cause confusion. >> >> "gir" is not good because it gives near-zero information. >> >> I can still not think of short enough USE flag. I propose we stick to >> "introspection". There isn't anything on the horizon that might >> overlap with this flag, and I don't see why we should drop using a >> simpler flag for the *possibility* that it might overlap with >> something else in the future. We can deal with this if it happens. >> >> Cheers, > > Why not just gintrospection? I still think "introspection" is easier to grok. It's unlikely that it's going to be used in a completely different sense by other packages in the future, so let's stick with "introspection" please. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
[gentoo-dev] Re: New global USE flag: introspection
On 20 June 2010 20:12, Arun Raghavan wrote: [...] > Any objections? I'll wait till Wed (June 23rd) before adding this if > there aren't any. Is anyone here vehemently against "introspection". -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: New global USE flag: introspection
On 22 June 2010 22:03, Mike Auty wrote: [...] >> I still think "introspection" is easier to grok. It's unlikely that >> it's going to be used in a completely different sense by other >> packages in the future, so let's stick with "introspection" please. > > Gintrospection gives more information (things starting with g are > generally gnome related, which this is), and grepping for introspection It is not a GNOME-only flag. It affects several non-GNOME-only packages as well (udev, upower, udisks, dbus, gstreamer, other freedesktop projects, pulseaudio). > will still turn it up. It also solves the concerns that all the people > on this thread have voiced about introspection being too generic. I Which should not be an issue since any library that has some sort of introspection can use this flag (and the use.desc can be changed appropriately at that time if it does not use gobject-introspection). -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: New global USE flag: introspection
On 23 June 2010 01:47, Mike Auty wrote: [...] >> Which should not be an issue since any library that has some sort of >> introspection can use this flag (and the use.desc can be changed >> appropriately at that time if it does not use gobject-introspection). > > Why have to change it in the future (and probably split it into two > flags then), when the choice hasn't been made yet? Or, to put your own > question to you, why are you vehemently for "introspection" when others > have shown concern with the choice? As far as I can see, the only > difference is requiring a slightly longer use_enable line. Mostly because I don't want to coin a new term if it's not absolutely necessary. That said, you're right - more people seem to be comfortable with "gintrospection" than plain "introspection". If no further objections arise, we'll go with "gintrospection". Thanks, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 25 June 2010 14:15, Peter Volkov wrote: > В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет: [...] >> Or you could review the changes before pushing (since in git these >> operations are separate). And live with the consequences of your >> mistakes! > > No. We are humans and thus mistakes are unavoidable. He didn't say don't make mistakes. He said, be careful and if mistakes happen, so be it. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Council manifesto of sping
Hey Sebastian, On 30 June 2010 06:15, Sebastian Pipping wrote: > Arun, [...] >> And another one for "More direct democracy": >> >> a) How would you decide what questions go up for public vote and which >> ones stay with the council? > > Good question! I think a few voices from developers (say three) > requesting a vote should force a global vote. If the council were > deciding on that, the concept would be useless. At least that's my > current understanding. > > >> b) For questions like "- Should Python 3.x be stable?", isn't that for >> team leads to decide? And for the council to resolve in case of >> conflicts? > > It's too important to leave it to the Python team alone in my eyes. > Previous threads have shown that consensus is hard to find on Python 3.x > related topics. A direct vote from all developers would reveal what the > majority really wants for that topic. It is my opinion that dismissing the opinions of the people who are actually doing the work is not a good way to motivate the same people (I don't even disagree with you about the Python team's approach to 3.x in the tree, but I disagree with how you think it should be handled). >> c) For questions like "- Should developer X be banned?", would you be >> willing to do this if it meant a lot of washing of dirty linen in >> public, or protracted flamewars (and other reasons why we have a bunch >> of level-headed people in place to deal with this calmly and quietly)? >> If no, where would you draw the line? If yes, how would you deal with >> the fallout? > > I'm not understanding all of that, honestly. > On a part I understood: Solving isues on that front may be worth extra > "noise" as the goal is to noticably improve atmosphere after. > Please help me to understand the rest of your question. The problem is not noise. The problem is that an issue that needs to be escalated to Devrel could not be resolved by the involved developers or the people who were present at the time. Moreover, there are strong emotions from the devs (and often their friends too), and people will end up saying things that they may eventually regret. Dragging this out in public /will/ polarise the community, result in more public conflict, very likely without a complete picture of the story on both sides being available. Devrel's purpose is to avoid this, and I believe this does work (we can debate their efficacy or how things can improve, but saying it doesn't work is unfair, IMO). I don't see how your proposal would deal with this fallout. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 5 July 2010 18:31, Peter Hjalmarsson wrote: [...] > 1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know > how to round numbers, and that 2 can be rounded from everything between > 1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.) Just to take this threat as far off-topic as I can, http://en.wikipedia.org/wiki/2_%2B_2_%3D_5 :p Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] New global use flag: vpx or vp8
On 1 August 2010 01:32, Steve Dibb wrote: [...] > The description is misleading, and needs to be changed. Just because > something has an mp3 and a lame use flag, it does not mean that flipping on > lame means that the application will prefer lame over mad or mpg123. lame (the MP3 encoder) has nothing to do with mad or mpg123 (which are used to decode MP3s) -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] [enhancement proposal] Per-file Manifest GPG signatures
On 3 October 2010 13:28, Michał Górny wrote: > Hello, > > I would like to propose a new attempt at Manifest signatures. Instead > of using a single per-Manifest signature, we would keep separate > signatures for each of the files, as an additional (optional) hash > type. > > > Motivation > -- > The current signing approach gives all the responsibility for Manifest > signature to the developer who committed last update to the ebuild > directory regardless of the actual commit significance. > > Consider the following: Dev A is the primary package maintainer. He/she > reviewed all the ebuilds and committed a signed Manifest. Then Dev B > performs a slight cleanup of the ebuild directory. He/she modifies > metadata.xml a little and/or removes an old ebuild. > > The actual ebuilds weren't modified -- yet Dev B has to sign all > of them once again. Moreover, if Dev B doesn't use Manifest signing, > the signature from Dev A is lost. If we make the GPG signatures mandatory at some point of time, that addresses the second of your concerns. I do not understand why the first a problem - could you clarify? Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Make "sound" a global USE flag?
On 8 February 2011 01:18, Petteri Räty wrote: > On 02/07/2011 08:08 PM, Samuli Suominen wrote: [...] >> The "means" are commonly used as USE flag names with "result" in USE >> flag description. Think of "gstreamer", or "xine" for example. Both of these are reasonably well-known, libcanberra is not. Moreover, when these are available, they might represent a choice of backends, with maintainers ideally picking one that is preferable, leaving the picking an alternative choice to users. >> But I'm open to suggestions... >> > > How about event-sounds? > > "libcanberra is an implementation of the XDG Sound Theme and Name > Specifications, for generating event sounds on free desktops, such as > GNOME." > > http://0pointer.de/lennart/projects/libcanberra/#overview This sounds reasonable. Did I miss some conversation somewhere, because it appears that "libcanberra" got finalised [1] on (even though I believe it's a horribly unintuitive name to foist on users). [1] https://bugs.gentoo.org/show_bug.cgi?id=354585 Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Make libevent a global use flag?
On 16 March 2011 15:00, Dirkjan Ochtman wrote: > Local use flags so far: > > dev-db/mariadb:libevent - Use libevent for connection handling > net-dns/unbound:libevent - Use dev-libs/libevent instead of internal > select based events > net-im/bitlbee:libevent - Use libevent for event handling > x11-misc/bmpanel:libevent - Use the libevent event loop interface > net-im/prosody:libevent - Use libevent for event handling As before with libcanberra, I don't think it makes sense to have basic libraries like this as USE-flags. AFAICT, this should just become a hard-dep in most cases, and where there's a compelling reason for the ebuild to provide an alternative (or internal) event system, have this as a default-enabled USE-flag. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/pulseaudio: ChangeLog pulseaudio-0.9.23.ebuild
On 9 July 2011 12:58, Samuli Suominen wrote:
> On 07/09/2011 10:54 PM, Arun Raghavan (ford_prefect) wrote:
>> ford_prefect 11/07/09 19:54:34
>> - --with-udev-rules-dir="${EPREFIX}/$(get_libdir)/udev/rules.d" \
>> + --with-udev-rules-dir="${EPREFIX}/$(get_libdir)/udev/rules.d"
>
> Should be /lib/udev, without $(get_libdir)
Fixed - thanks for pointing this out.
Cheers,
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Ohloh statistics updated
2011/7/22 Stanislav Ochotnicky : > Hello fellow devs, > > some of you know that our commit statistics at Ohloh[1] have been > outdated because they were not able to process our huge CVS tree for > some reason :-) > > One way or the other I managed to reuse robbat2's previous work on > cvs->git conversion and keep our experimental conversion repository > up-to-date (I don't have cron job, but it's still completely automated). > > After 3 weeks of crunching (or was it more?) Ohloh machines finally spit > out updated statistics, removing few warnings from our project page > (such as "Decreasing year-over-year development activity""). Updates are > faster of course so our stats shouldn't be outdated anymore. > > So go claim your commits, Nice! Thanks for taking this up! -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] [RFC] subprofiles for ARM architecture
On 7 August 2011 17:20, Raúl Porcel wrote: [...] > With subprofiles we could keyword such packages, mask them globally on > arm and unmask it on the subprofile of the subarchitecture that supports it. I think this makes sense. What would the policy be on initial keywords if upstream doesn't explicitly specify what sub-arches are supported? Just enable on all till someone says it doesn't work or test on all of them first or ...? Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] udev and /usr
On 19 September 2011 16:07, Joshua Kinard wrote: [...] > Yes, but some of us don't even want to have that initramfs built into our > kernels. And no one, other than freedesktop.org* and a few people on > linux-hotplug-devel*, said everything belongs in /usr. FHS clearly defines > the roles for /, /bin, /sbin, /lib*, /usr, /var, /home, /tmp and the virtual > fses. Plus others. > > http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > http://marc.info/?l=linux-hotplug&m=131206447302056&w=2 > > Really, MacOS's filesystem layout is not something anyone in their right > mind should deign to mimic/copy. I didn't get that from either of the links you posted. Seems to me the systemd developers are looking at the split as a host-specific / vs host-independent /usr. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On 2 October 2011 13:50, Samuli Suominen wrote: > On 10/02/2011 02:44 AM, Chí-Thanh Christopher Nguyễn wrote: [...] >> Bug 361181 is certainly on my TODO list, just not very high up to now. >> If you think that there is some urgency in getting rid of the package, >> please do explain so in advance. > > The time ran out with opening of http://bugs.gentoo.org/384733 for > linux-headers reverse deps to be tracked stable. > > I've removed qutecom for you again. Removing the package again seems to just be unnecessary when the maintainer has stated that he'll fix the problem. Would masking it till it was fixed not suffice? Seems like a bit unjustified to me (from information on this thread alone). Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Suggestion for getting rid of udev
On 13 October 2011 20:58, Rich Freeman wrote: > 2011/10/13 Olivier Crête : >> We're imposing our deep integration because it's the only way to make a >> compelling platform that "just works", forcing users to tell the >> computer something the computer already knows is just plain lazy and >> stupid. > > I'd also look at it another way. It is a lot easier to take a > well-integrated platform and chop out the parts that you don't need, > than to take a million pieces and build yourself an integrated > platform. While it has been the way just about all platform development on Linux has taken place, what this mode of thinking ignores is that gratuitously supporting as many corner cases as you can means that you need to support a combinatorial explosion of pieces, which so far has only managed to keep our stack fragmented and an enormous pita to work with. I'm not saying we should narrow our focus too much, but every decision to support weird ways of doing things has a cost, and if you're going to support it, you (as an upstream developer) are spending time that could possibly have been spent making the whole system better. (that's to set some perspective on why things are heading the way they are, and discussing whether this is sensible or not probably is going to spin offtopic for gentoo-dev really quickly) While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say "these packages install rules that need / and /usr on the same partition". -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
