Re: [gentoo-dev] rsync mirrorstats page (generation and parsing)
On Sat, Jul 4, 2009 at 6:48 PM, Robin H. Johnsonrobb...@gentoo.org wrote: On Sun, Jul 05, 2009 at 02:44:07AM +0200, Sebastian Pipping wrote: When collecting information on the SYNC variable for my Summer of Code gentoo stats project I'd like to check if the URL in SYNC is publically known or some private/secret rsync mirror. The page behind http://mirrorstats.gentoo.org/rsync/ Mirrorstats is known to be out of date, because somebody needs to sit down and integrate it with the datasources, so manual updates aren't needed. Even better, would be hooking it into bouncer2 for the sentry output. It needs somebody to update it and hook at into the SOURCE of this data: http://www.gentoo.org/main/en/mirrors3.xml But wait, you say, that page is distfiles mirrors? Mirror-admin have a common data source, non-published as it contains private contact details for each administrator. From that data source, mirrors3 and rsync mirrors gets updated. mirrors.xml - old page, only used by mirrorselect now, manually updated. mirrors3.xml - new page, generated from internal dataset. mirrors2.xml - not a real page (See http://www.gentoo.org/main/en/mirrors2.xml?passthru=1 and the magic mirrorlist element. Relatedly, the original author of mirrorselect retired from Gentoo several years ago. The tools-portage team maintain it now, so you should co-operate with them. It would be nice if they implemented the mirrors3 usage too, I think mirror-admin asked them more than a year ago, but I can't find the bug. +cc tools-portage shit, I think I was the last one to touch that thing ;p Where is mirrorselect hiding these days, a private git repo? -A In the meantime, for your original question: is the URL in SYNC public or private Simply check by matching against gentoo.org$ in the hostname part of the field. P.S. Please report empty SYNC variables too ;-). These turn up when users/devs have their tree coming from a VCS instead of rsync. -- 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
Re: [gentoo-dev] rsync mirrorstats page (generation and parsing)
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)
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
http://bugs.gentoo.org/show_bug.cgi?id=250853 http://bugs.gentoo.org/show_bug.cgi?id=250853On 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
Hello Robson, On Mon, Jul 6, 2009 at 2:44 AM, Robson Roberto Souza Peixotorobsonpeix...@gmail.com 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
On Sun, Jul 5, 2009 at 8:59 PM, Mounir Lamourivolk...@gentoo.org 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
-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-
[gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
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
On Mon, Jul 6, 2009 at 1:48 PM, Denis Dupeyron calc...@gentoo.org wrote: Hello Robson, On Mon, Jul 6, 2009 at 2:44 AM, Robson Roberto Souza Peixotorobsonpeix...@gmail.com 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
