Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge

2013-08-17 Thread Arun Raghavan
On 17 August 2013 16:28, heroxbd hero...@gentoo.org wrote:
 Arun Raghavan ford_pref...@gentoo.org 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] desktop experience on smartphone: thoughts and plans against Ubuntu edge

2013-08-16 Thread Arun Raghavan
On 13 August 2013 10:51, heroxbd hero...@gentoo.org 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] Gnome Stabilization 3.6 or 3.8

2013-08-09 Thread Arun Raghavan
On 9 August 2013 20:20, Alon Bar-Lev alo...@gentoo.org wrote:
 On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
 Alon Bar-Lev schrieb:
 On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer patr...@gentoo.org 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] Re: devmanual moved to github

2013-05-12 Thread Arun Raghavan
On 12 May 2013 20:34, Markos Chandras hwoar...@gentoo.org 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] Making systemd more accessible to normal users

2013-05-08 Thread Arun Raghavan
On 8 May 2013 21:51, Ben de Groot yng...@gentoo.org 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] Global useflags zeroconf and avahi

2013-04-01 Thread Arun Raghavan
On 2 April 2013 08:17, Alex Xu alex_y...@yahoo.ca 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] Packages up for grabs due lack of time

2013-02-05 Thread Arun Raghavan
On 5 February 2013 23:58, Pacho Ramos pa...@gentoo.org wrote:
[...]
 media-sound/dbmeasure
[...]

I'll keep this one.

Cheers,
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo)  (arunsr | GNOME)



Re: [gentoo-dev] Time based retirements

2012-12-21 Thread Arun Raghavan
On 21 December 2012 17:36, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Fri, 21 Dec 2012 09:21:57 +
 Markos Chandras hwoar...@gentoo.org 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

2012-12-21 Thread Arun Raghavan
On 21 December 2012 18:02, Arun Raghavan ford_pref...@gentoo.org wrote:
 On 21 December 2012 17:36, Ciaran McCreesh
 ciaran.mccre...@googlemail.com wrote:
 On Fri, 21 Dec 2012 09:21:57 +
 Markos Chandras hwoar...@gentoo.org 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] Reminder: open season on robbat2's packages

2012-11-18 Thread Arun Raghavan
On 18 November 2012 16:41, Robin H. Johnson robb...@gentoo.org 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] UEFI secure boot and Gentoo

2012-06-14 Thread Arun Raghavan
On 15 June 2012 09:58, Greg KH gre...@gentoo.org 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

2012-06-14 Thread Arun Raghavan
On 15 June 2012 10:26, Greg KH gre...@gentoo.org wrote:
 On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
 On 15 June 2012 09:58, Greg KH gre...@gentoo.org 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

2012-06-14 Thread Arun Raghavan
On 15 June 2012 10:33, Ben de Groot yng...@gentoo.org wrote:
 On 15 June 2012 12:45, Arun Raghavan ford_pref...@gentoo.org wrote:
 On 15 June 2012 09:58, Greg KH gre...@gentoo.org 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] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Arun Raghavan
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] Stability of /sys api

2012-05-15 Thread Arun Raghavan
On 16 May 2012 05:21, Walter Dnes waltd...@waltdnes.org 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] epatch_user usage

2012-04-23 Thread Arun Raghavan
On 24 April 2012 09:15, Doug Goldstein car...@gentoo.org 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] rfc: locations of binaries and separate /usr

2012-01-05 Thread Arun Raghavan
On 6 January 2012 06:14, Patrick Lauer patr...@gentoo.org wrote:
 On 01/06/12 05:26, Olivier Crête wrote:
 [snip]
 The only thing I see them sacrificing is loose coupling, they provide
 more functionality than any other init system, more correctness
 (seriously, did you ever read most init scripts out there?), more well
 defined behavior (all systemd systems boot exactly the same), more
 stability (I'll claim that Lennart's C is better than any of the
 boot-time shell scripts I've seen) and well understandability depends
 who much you can understand C. Probably a bit less understandable for
 sysadmins, but since they can just play with config files, it's
 probably easier to understand in the end (and much less prone to
 breaking than mucking around shell scripts).
 As you apparently have no idea what a sysadmin does I'd appreciate it if
 people like you didn't try to guess what would make things better and
 instead listened to people that have more than their desktop to run.
 (Hint: It's not pressing reset buttons)

 Given the choice between a single line of shell ( cat $urandom_seed 
 /dev/urandom ) or 145 lines of undocumented C (which, if naively
 modified by me, might just make systemd segfault) ... there is no choice.

Seems straightforward and well-documented to me:
http://cgit.freedesktop.org/systemd/tree/src/random-seed.c. And the
if I naively modify things, they might explode argument holds for
anything.

These are basic things that you almost certainly would not be
modifying as a sysadmin anyway. I'd hope that the things that you
really do want to muck around with are provided as configuration, and
if they're not, you talk to upstream and make a case for this being
useful to users. Just like with every other open source project.

-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo)  (arunsr | GNOME)



Re: [gentoo-dev] rfc: locations of binaries and separate /usr

2012-01-04 Thread Arun Raghavan
On 3 January 2012 15:21, Walter Dnes waltd...@waltdnes.org wrote:
 On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote

 I see three options:

 1) Start migrating packages along with upstream and have everyone who
 has a separate /usr (including me by the way) start using an initramfs
 of some kind, either dracut or one that we generate specifically for
 gentoo. The reason I suggest the initramfs, is, unfortunately if we
 migrate everything, nothing else would work.

 2) Combine the sbin and bin directories both  on the root
 filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin
 to /usr/bin.

 3) Try to maintain  things the way they are as long as possible.

  4) Following pointers from Zac Medico and others, I've managed to get
 Gentoo running with busybox's mdev, instead of udev.  See
 http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml
 Executive summary... look Ma; no udev!

Does mdev support all the rules we have in /lib/udev/rules.d/? The
Internet is surprisingly mute on this subject, but a quick grep
through the busybox source doesn't turn up anything that suggests that
it might.

-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo)  (arunsr | GNOME)



Re: [gentoo-dev] Suggestion for getting rid of udev

2011-10-13 Thread Arun Raghavan
On 13 October 2011 20:58, Rich Freeman ri...@gentoo.org wrote:
 2011/10/13 Olivier Crête tes...@gentoo.org:
 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)



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

2011-10-02 Thread Arun Raghavan
On 2 October 2011 13:50, Samuli Suominen ssuomi...@gentoo.org 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] udev and /usr

2011-09-19 Thread Arun Raghavan
On 19 September 2011 16:07, Joshua Kinard ku...@gentoo.org 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-hotplugm=131206447302056w=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] [RFC] subprofiles for ARM architecture

2011-08-12 Thread Arun Raghavan
On 7 August 2011 17:20, Raúl Porcel armi...@gentoo.org 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] Ohloh statistics updated

2011-07-22 Thread Arun Raghavan
2011/7/22 Stanislav Ochotnicky sochotni...@gentoo.org:
 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)



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/pulseaudio: ChangeLog pulseaudio-0.9.23.ebuild

2011-07-09 Thread Arun Raghavan
On 9 July 2011 12:58, Samuli Suominen ssuomi...@gentoo.org 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] Make sound a global USE flag?

2011-02-24 Thread Arun Raghavan
On 8 February 2011 01:18, Petteri Räty betelge...@gentoo.org 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] [enhancement proposal] Per-file Manifest GPG signatures

2010-10-03 Thread Arun Raghavan
On 3 October 2010 13:28, Michał Górny mgo...@gentoo.org 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] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults

2010-07-05 Thread Arun Raghavan
On 5 July 2010 18:31, Peter Hjalmarsson x...@rymdraket.net 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] Council manifesto of sping

2010-07-02 Thread Arun Raghavan
Hey Sebastian,

On 30 June 2010 06:15, Sebastian Pipping sp...@gentoo.org 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] [git migration] The problem of ChangeLog generation

2010-06-25 Thread Arun Raghavan
On 25 June 2010 14:15, Peter Volkov p...@gentoo.org 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] New global USE flag: introspection

2010-06-22 Thread Arun Raghavan
On 21 June 2010 21:23, Arun Raghavan ford_pref...@gentoo.org 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

2010-06-22 Thread Arun Raghavan
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)



[gentoo-dev] Re: New global USE flag: introspection

2010-06-22 Thread Arun Raghavan
On 20 June 2010 20:12, Arun Raghavan ford_pref...@gentoo.org 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

2010-06-22 Thread Arun Raghavan
On 22 June 2010 22:03, Mike Auty ike...@gentoo.org 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

2010-06-22 Thread Arun Raghavan
On 23 June 2010 01:47, Mike Auty ike...@gentoo.org 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] Re: New global USE flag: introspection

2010-06-21 Thread Arun Raghavan
On 21 June 2010 11:43, Alexis Ballier aball...@gentoo.org 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

2010-06-21 Thread Arun Raghavan
On 21 June 2010 21:14, Maciej Mrozowski reave...@gmail.com 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

2010-06-21 Thread Arun Raghavan
On 22 June 2010 00:40, Mark Loeser halc...@gentoo.org 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

2010-06-21 Thread Arun Raghavan
Hi,

On 21 June 2010 22:03, Sebastian Pipping sp...@gentoo.org 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

2010-06-21 Thread Arun Raghavan
On 22 June 2010 00:57, Mark Loeser halc...@gentoo.org 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

2010-06-21 Thread Arun Raghavan
On 22 June 2010 03:06, Sebastian Pipping sp...@gentoo.org 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

2010-06-21 Thread Arun Raghavan
On 22 June 2010 03:06, Sebastian Pipping sp...@gentoo.org 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)



[gentoo-dev] New global USE flag: introspection

2010-06-20 Thread Arun Raghavan
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

2010-06-20 Thread Arun Raghavan
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-06-20 Thread Arun Raghavan
2010/6/21 Olivier Crête tes...@gentoo.org:
 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

2010-06-20 Thread Arun Raghavan
On 20 June 2010 20:12, Arun Raghavan ford_pref...@gentoo.org 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: [gentoo-core] (infra) rsync updates and distfile fetching offline for next 12-18 hours.

2010-05-20 Thread Arun Raghavan
On 20 May 2010 15:51, Petteri Räty betelge...@gentoo.org 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)



Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits

2010-04-24 Thread Arun Raghavan
On 24 April 2010 23:10, Petteri Räty betelge...@gentoo.org 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: [RFC] Gentoo Wiki Project

2010-04-12 Thread Arun Raghavan
On 12 April 2010 18:43, George Prowse george.pro...@gmail.com 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

2010-04-12 Thread Arun Raghavan
On 12 April 2010 18:49, George Prowse george.pro...@gmail.com wrote:
 On 12/04/2010 14:17, Arun Raghavan wrote:

 On 12 April 2010 18:43, George Prowsegeorge.pro...@gmail.com  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] Council meeting 19 April 2010

2010-04-07 Thread Arun Raghavan
Hi Ben,

On 7 April 2010 22:44, Ben de Groot yng...@gentoo.org 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] [Gentoo Phoenix] an official Gentoo wiki

2010-04-04 Thread Arun Raghavan
On 4 April 2010 13:01, Joshua Saddler nightmo...@gentoo.org 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

2010-04-04 Thread Arun Raghavan
On 5 April 2010 08:13, Ben de Groot yng...@gentoo.org wrote:
 On 5 April 2010 03:13, Joshua Saddler nightmo...@gentoo.org 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

2010-04-04 Thread Arun Raghavan
On 5 April 2010 10:34, Arun Raghavan ford_pref...@gentoo.org wrote:
 On 5 April 2010 08:13, Ben de Groot yng...@gentoo.org wrote:
 On 5 April 2010 03:13, Joshua Saddler nightmo...@gentoo.org 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] proxy maintainership and gentoo-x86 scm

2010-01-19 Thread Arun Raghavan
2010/1/15 Robin H. Johnson robb...@gentoo.org:
[...]
 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] Farewell, Gentoo.

2010-01-04 Thread Arun Raghavan
2010/1/2 David Shakaryan o...@gentoo.org:
[...]
 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] About udev-145: new features / extras and kernel requirements

2009-08-30 Thread Arun Raghavan
2009/8/30 Matthias Schwarzott z...@gentoo.org:
 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] Multimedia overlay

2009-08-11 Thread Arun Raghavan
2009/8/11 Sebastian Pipping webmas...@hartwork.org:
 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-08-11 Thread Arun Raghavan
2009/8/11 Nirbheek Chauhan nirbh...@gentoo.org:
 On Tue, Aug 11, 2009 at 11:08 PM, Arun Raghavanford_pref...@gentoo.org 
 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-08-11 Thread Arun Raghavan
2009/8/11 Markos Chandras hwoar...@gentoo.org:
[...]
 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-08-11 Thread Arun Raghavan
2009/8/12 Ben de Groot yng...@gentoo.org:
 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] Jun 11th, 2009 Council Meeting Format

2009-06-01 Thread Arun Raghavan
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] The fallacies of GLEP55

2009-05-17 Thread Arun Raghavan
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] The fallacies of GLEP55

2009-05-16 Thread Arun Raghavan
On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
 On Sat, 16 May 2009 17:43:32 +0200
 Tobias Klausmann klaus...@gentoo.org 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

2009-05-16 Thread Arun Raghavan
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

2009-05-16 Thread Arun Raghavan
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

2009-05-16 Thread Arun Raghavan
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

2009-05-16 Thread Arun Raghavan
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

2009-05-16 Thread Arun Raghavan
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

2009-05-15 Thread Arun Raghavan
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] license issue with fretsonfire

2009-05-03 Thread Arun Raghavan
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] New eclass proposal: auto-export

2009-04-22 Thread Arun Raghavan
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] GLI Officially Deprecated

2009-01-17 Thread Arun Raghavan
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] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Arun Raghavan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Long wrote:
[...]
 for ((i=0;i10;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] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-12 Thread Arun Raghavan
-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: [RFC] What features should be included in EAPI 2?

2008-08-19 Thread Arun Raghavan
-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] Suggestion: remove app-office/borg from portage.

2008-08-16 Thread Arun Raghavan
-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] metadata.xml USE flag descriptions

2008-07-28 Thread Arun Raghavan
-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

2008-07-28 Thread Arun Raghavan
-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 pkg or cat

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] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-19 Thread Arun Raghavan
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] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-12 Thread Arun Raghavan
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: GLEP 55

2008-06-11 Thread Arun Raghavan
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: GLEP 55

2008-06-10 Thread Arun Raghavan
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

2008-06-10 Thread Arun Raghavan
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

2008-06-10 Thread Arun Raghavan
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.

 !-- EAPI=3 --

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

2008-06-10 Thread Arun Raghavan
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] die/QA notice for do* failure?

2008-06-08 Thread Arun Raghavan
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?

2008-06-08 Thread Arun Raghavan
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?

2008-06-08 Thread Arun Raghavan
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?

2008-06-08 Thread Arun Raghavan
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] merging two packages - upgrade path?

2008-06-05 Thread Arun Raghavan
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] Re: [RFC] Eclass for gnome-python* split

2008-05-24 Thread Arun Raghavan
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

2008-05-24 Thread Arun Raghavan
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



[gentoo-dev] [RFC] Eclass for gnome-python* split

2008-05-23 Thread Arun Raghavan
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: About herds and their non-existant use

2008-05-22 Thread Arun Raghavan
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



Re: [gentoo-dev] why not player/stage/gazebo

2008-05-17 Thread Arun Raghavan
On Sat, May 17, 2008 at 2:37 PM, Zhu Sha Zang [EMAIL PROTECTED] wrote:
snip
 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