Re: [gentoo-dev] rsync mirrorstats page (generation and parsing)

[Zac Medico]

Alec Warner wrote:
> Where is mirrorselect hiding these days, a private git repo?

Yeah, here's the history since I started maintaining it:

http://dev.gentoo.org/~zmedico/projects/mirrorselect.git/
-- 
Thanks,
Zac

Re: [gentoo-dev] rsync mirrorstats page (generation and parsing)

[Robin H. Johnson]

On Mon, Jul 06, 2009 at 12:28:59AM -0700, Zac Medico wrote:
> Alec Warner wrote:
> > Where is mirrorselect hiding these days, a private git repo?
> Yeah, here's the history since I started maintaining it:
> http://dev.gentoo.org/~zmedico/projects/mirrorselect.git/
I'll try to suck that down soon and build up a larger history with old
tarballs, and then push it somewhere useful.

Thanks for it.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpOCUHHnCBns.pgp
Description: PGP signature

[gentoo-dev] Bug #250853

[Robson Roberto Souza Peixoto]

http://bugs.gentoo.org/show_bug.cgi?id=250853
On bugzilla has the patch to
solve the problem

Thanks,
Robinho

-- 
Robson Roberto Souza Peixoto
Robinho
robsonpeix...@gmail.com
Telefone: (19) 8821-0396 (oi)
  (19) 9799-0135 (vivo)
Computer Science Master's degree student, University of Campinas
Linux Counter #395633

Re: [gentoo-dev] Bug #250853

[Denis Dupeyron]

Hello Robson,

On Mon, Jul 6, 2009 at 2:44 AM, Robson Roberto Souza
Peixoto wrote:
> http://bugs.gentoo.org/show_bug.cgi?id=250853
> On bugzilla has the patch to solve the problem

The people concerned by this already know about the bug and patch,
there is no need to remind us here. They will get to it soon as they
can. They're volunteers and do as much as possible in the free time
they have.

In addition, this mailing list isn't for specific issues such as this
one, please use bugzilla instead.

Thanks,
Denis.

Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit

[Nirbheek Chauhan]

On Sun, Jul 5, 2009 at 8:59 PM, Mounir Lamouri wrote:
> In addition, they should ask for a packagekit git access. It's easy to
> get one and surely better than working in your own playground.
>

I agree, Richard Hughes is really cool about this stuff, so lxnay, if
you're reading this, get in touch with him. He'd be delighted to give
you access :)


-- 
~Nirbheek Chauhan

[gentoo-dev] maintainer needed for app-accessibility/festival and app-accessibility/speech-tools

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

we have multiple open bugs for app-accessibility/festival and
app-accessibility/speech-tools.

These packages are very difficult to maintain and upstream appears to be
dead.

I am not interested in them, and I haven't heard from the accessibility
team member who joined to maintain them in many months.  So, after
several attempts to contact him, I am bringing these back to the list.

If someone wants to maintain them, please contact me.  Otherwise, I will
send them to the last rights graveyard this coming weekend.

Thanks,

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpSRgQACgkQblQW9DDEZThQFACgk30RfyB/1dQTgY3CdKwwPxLR
7z0AmwQOd4WAy1vnNsFw/yRNR6aHpQDq
=Zikj
-END PGP SIGNATURE-

Re: [gentoo-dev] About time to unify "cdda" and "cdaudio" USE flags and make the remaining one global?

[Josh Saddler]

Sebastian Pipping wrote:
> Rémi Cardona wrote:
>> And now for some bikeshedding fun, which flag are we going to keep? ;)
> 
> My vote would be for cdaudio as that
> 
>  - is more general (including analog playback)
>  - is more user friendly
> 
> but let those decide who "implement" it.

I'm also in favor of cdaudio: it's a bit more self-explanatory. I also
think it's better to have such a generic description for apps that use
libcdio/cdparanoia/cddb combinations, such as the package I maintain,
media-sound/decibel-audio-player.

I'm all for cdaudio over cdda.




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness

[Ciaran McCreesh]

EAPI 3 makes IUSE strict: flags not listed in IUSE can't be used in
dependency strings, use queries and so on. However, the specification
includes ways of implicitly adding things to the effective value of
IUSE via the base profile make.defaults. What the specification doesn't
say, and what hasn't been formally decided, is what exactly will be
implicit.

First up is ARCH. Most people don't seem to want to explicitly list
IUSE="x86" etc to make 'use x86' and 'x86? ( ... )' work. Also, people
seem to want to continue the existing unprefixed behaviour rather than
starting to write 'arch_x86'. So we'll need:

USE_EXPAND_UNPREFIXED="ARCH"
USE_EXPAND_IMPLICIT="ARCH"

In addition, all the implicit values need to be listed. According to
arch.list, the values are:

USE_EXPAND_VALUES_ARCH="alpha amd64 amd64-fbsd arm hppa ia64 m68k \
   mips ppc ppc64 s390 sh sparc sparc-fbsd x86 x86-fbsd ppc-aix \
   x86-freebsd x64-freebsd ia64-hpux x86-interix mips-irix \
   amd64-linux ia64-linux x86-linux ppc-macos x86-macos x64-macos \
   m68k-mint x86-netbsd ppc-openbsd x86-openbsd x64-openbsd \
   sparc-solaris sparc64-solaris x64-solaris x86-solaris x86-winnt"

I've no idea whether that list is accurate. With EAPI 3 it'll matter.

Of the normal USE_EXPAND flags, some appear to be routinely listed in
IUSE anyway, and some pretty much never are. I'd imagine USERLAND,
KERNEL and ELIBC will want to be implicit:

USE_EXPAND_IMPLICIT="${USE_EXPAND_IMPLICIT} USERLAND KERNEL ELIBC"

And again, the implicit values will have to be listed. According to the
desc files (which could be full of lies):

USE_EXPAND_VALUES_USERLAND="GNU BSD"
USE_EXPAND_VALUES_KERNEL="AIX Darwin FreeBSD freemint linux HPUX \
Interix IRIX NetBSD OpenBSD SunOS"
USE_EXPAND_VALUES_ELIBC="AIX Darwin DragonFly FreeBSD glibc HPUX \
Interix IRIX mintlib NetBSD OpenBSD SunOS uclibc"

Are there any other USE_EXPANDs that people want implicit behaviour
for? If so, which ones, and are the desc files accurate?

Finally, there's room to include plain old flags in IUSE automatically.
This was added to the specification as a hypothetical "we might want
this, and it's easy to specify and implement" rather than a "we'll
definitely be using this". Flags that I'm aware of that regularly get
abused are:

IUSE_IMPLICIT="build debug"

Are people wanting to make those implicit? Are there any other flags
that people really don't want to put in IUSE? Bear in mind that any
flag that's implicit can't ever be used for a use dependency default.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Bug #250853

[Robson Roberto Souza Peixoto]

On Mon, Jul 6, 2009 at 1:48 PM, Denis Dupeyron  wrote:

> Hello Robson,
>
> On Mon, Jul 6, 2009 at 2:44 AM, Robson Roberto Souza
> Peixoto wrote:
> > http://bugs.gentoo.org/show_bug.cgi?id=250853
> > On bugzilla has the patch to solve the problem
>
> The people concerned by this already know about the bug and patch,
> there is no need to remind us here. They will get to it soon as they
> can. They're volunteers and do as much as possible in the free time
> they have.
>

Sorry. It was not my intention to charge anything from anyone. Only warn
that there is a solution.


> In addition, this mailing list isn't for specific issues such as this
> one, please use bugzilla instead.
>

Ok.

Thanks,
Robinho


>
> Thanks,
> Denis.
>
>


-- 
Robson Roberto Souza Peixoto
Robinho
robsonpeix...@gmail.com
Telefone: (19) 8821-0396 (oi)
  (19) 9799-0135 (vivo)
Computer Science Master's degree student, University of Campinas
Linux Counter #395633

Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness

[Andrew D Kirch]

Ciaran,

I've talked with the pkgcore people and they don't use the EAPI's (or
PMS) in the first place.  This essentially leaves you writing documents
you're requiring for paludis support.  As this seems to be mostly a PM
issue, it should be taken elsewhere.  To that end, here is a
gentoo-portage-dev mailing list that is more appropriate for minor
process issues such as those brought up below.
I think that ending this discussion here and moving it over to a forum
more appropriate to package manager development would reduce the
temperature around your proposals and get them implemented (as Zac seems
willing to do so).  While I realize this is a general purpose mailing
list, it is general purpose, and there is a mailing list specifically
for portage development.

Andrew

Ciaran McCreesh wrote:
> *SNIP*

Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness

[Brian Harring]

On Tue, Jul 07, 2009 at 02:08:01AM -0400, Andrew D Kirch wrote:
> Ciaran,
> 
> I've talked with the pkgcore people and they don't use the EAPI's (or
> PMS) in the first place.  

No clue who you talked to, but they weren't speaking for pkgcore- I 
speak for pkgcore pretty much solely.  Pkgcore utilizes EAPIs- hell I 
added the original support to portage.  Not sure what info you got 
fed, but it was a bit off.

> I think that ending this discussion here and moving it over to a forum
> more appropriate to package manager development would reduce the
> temperature around your proposals and get them implemented (as Zac seems
> willing to do so).

I don't particularly care one way or another (subscribed to both 
MLs), just mostly correcting one large misstatement...

~harring


pgpqUyu7HYnmu.pgp
Description: PGP signature