On Monday 13 January 2014 09:53:45 Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700 "C. Bergström" wrote:
> > At the end of the day we have one codebase which is
> > "engineered" and another which has "evolved".
>
> Too broad generalization, too much assumption; both can be held as
> meanin
On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote:
> Maybe, a good solution is to introduce a special arch, "noarch", for such
> packages (similar to what's done in the rpm world). Then, if a package is
> ~noarch, it is automatically considered ~arch for all arches. Similar for
> stable. T
El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote:
> > Maybe, a good solution is to introduce a special arch, "noarch", for such
> > packages (similar to what's done in the rpm world). Then, if a package is
> > ~noarch, it is
> On Sun, 19 Jan 2014, Pacho Ramos wrote:
> El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
>> you mean * ? this already works today (at least with portage):
>> KEYWORDS="~*"
>> KEYWORDS="*"
Currently not allowed by policy:
http://devmanual.gentoo.org/keywording/ind
On Sunday 19 January 2014 04:28:33 Pacho Ramos wrote:
> El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> > On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote:
> > > Maybe, a good solution is to introduce a special arch, "noarch", for
> > > such packages (similar to what's do
Dion Moult writes:
> # Dion Moult (19 Jan 2014)
> # Mask for removal in 30 days. usleep is actually provided part of
> # app-admin/killproc (bug #467212)
> sys-apps/usleep
Veto. app-admin/killproc isn't even keyworded, yet. (Bug #494254).
--
Amadeusz Żołnowski
pgpv1V6GgHkQg.pgp
Descriptio
Reverted.
Amadeusz Żołnowski wrote:
>Dion Moult writes:
>
>> # Dion Moult (19 Jan 2014)
>> # Mask for removal in 30 days. usleep is actually provided part of
>> # app-admin/killproc (bug #467212)
>> sys-apps/usleep
>
>Veto. app-admin/killproc isn't even keyworded, yet. (Bug #494254).
>
>
>--
El dom, 19-01-2014 a las 10:46 +0100, Ulrich Mueller escribió:
> > On Sun, 19 Jan 2014, Pacho Ramos wrote:
>
> > El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> >> you mean * ? this already works today (at least with portage):
> >> KEYWORDS="~*"
> >> KEYWORDS="*"
>
with glibc-2.17 in stable now and glibc-2.19 release in like ~2 weeks, glibc
2.18 is heading to ~arch. there's been very little reported breakage reported
thus far ... i hope it's because there isn't any vs people aren't using it.
so if people want to try it out ahead of time, that'd be nice.
William Hubbs schrieb:
> When you say "drop keywords" do you mean:
>
> 1) revert the old version back to ~arch or
> 2) remove the old version.
>
> As a maintainer, I would rather do 2, because I do not want to backport
> fixes to the old version.
>
> William
>
With 1) users would still be usin
please check with maintainers, ie in this case me, before jumping in
and pushing, straight to stable, patches to the known to be fragile core
part of a whole herd... reviews below
On Sat, 18 Jan 2014 13:12:48 + (UTC)
"Mark Wright (gienah)" wrote:
> gienah 14/01/18 13:12:48
>
> Added:
> either the QA lead or two members of the QA team can require the Infra team
> to temporarily suspend commit access for the developer
-1 to that part
That sounds like you are able to make non-trivial decisions without the
approval of the lead.
On Sun, Jan 19, 2014 at 05:52:48AM -0500, Mike Frysinger wrote:
> with glibc-2.17 in stable now and glibc-2.19 release in like ~2 weeks, glibc
> 2.18 is heading to ~arch. there's been very little reported breakage
> reported
> thus far ... i hope it's because there isn't any vs people aren't us
On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs wrote:
> This is nothing new; the qa team has requested that commit rights be
> suspended before. I am just proposing that we actually add the parts of
> the old patch to the glep that spell out when and how this can happen.
>
> Thoughts?
Yes, thoug
On Thu, 16 Jan 2014 23:44:42 +0100
Tom Wijsman wrote:
> > If I don’t, why do I care if the package is a year old? I lose none
> > of my time to use the old version, since it does all I want;
>
> This is under the assumption that the old version has no further
> implications, which is a false ass
On Fri, 17 Jan 2014 19:53:44 +0100
Michał Górny wrote:
> Dnia 2014-01-17, o godz. 10:18:58
> Alec Warner napisał(a):
>
> > On Fri, Jan 17, 2014 at 8:27 AM, Michał Górny
> > wrote:
> >
> > > Hello, all.
> > >
> > > I'm using squashfs to hold my Gentoo repositories on all of my
> > > systems fo
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2014-01-19 23h59 UTC.
Removals:
app-office/rabbit 2014-01-13 02:33:48 mrueg
app-i18n/rskkserv 2014-01-13 02:35:05 mrueg
dev-ruby/postgres
On Sun, 19 Jan 2014 14:31:57 -0800
Christopher Head wrote:
> Right, of course things can become incompatible—but the distro handles
> that by either leaving old enough version of e.g. libraries around
> that the latest stable versions of their reverse dependencies don’t
> break, or, in exceptiona
On Sun, 19 Jan 2014 13:22:07 -0700
Denis Dupeyron wrote:
> On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs
> wrote:
> > This is nothing new; the qa team has requested that commit rights be
> > suspended before. I am just proposing that we actually add the
> > parts of the old patch to the glep t
On Sun, 19 Jan 2014 13:46:01 +0100
hasufell wrote:
> > either the QA lead or two members of the QA team can require the
> > Infra team to temporarily suspend commit access for the developer
>
> -1 to that part
>
> That sounds like you are able to make non-trivial decisions without
> the approva
On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman wrote:
> It is more of a "Do we want QA to delegate this through ComRel or not?".
Actually, no. What it is is a "Subject was thoroughly discussed in the
past, and a decision was made." More than once, in fact. What basis do
you have that would warrant
On Sat, Jan 18, 2014 at 9:02 PM, William Hubbs wrote:
> All,
>
> I would like to bring back for discussion an old patch to glep 48 [1]
> which was suggested by Jorge [2].
>
> That patch evolved into this one [3], and in the council meeting back
> then [4], parts of it made their way into glep 48,
On Sun, 19 Jan 2014 18:22:39 -0700
Denis Dupeyron wrote:
> On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman
> wrote:
> > It is more of a "Do we want QA to delegate this through ComRel or
> > not?".
>
> Actually, no. What it is is a "Subject was thoroughly discussed in the
> past, and a decision was
On Sun, 19 Jan 2014 17:24:30 -0800
Alec Warner wrote:
> We almost never suspend commit rights. I'm not really finding a
> situation where this is necessary. Certainly not in the streamlined
> fashion proposed here.
Well, the QA team has been inactive for a while; so, I guess this
might have been
On Sunday 19 January 2014 13:07:24 Robin H. Johnson wrote:
> On Sun, Jan 19, 2014 at 05:52:48AM -0500, Mike Frysinger wrote:
> > with glibc-2.17 in stable now and glibc-2.19 release in like ~2 weeks,
> > glibc 2.18 is heading to ~arch. there's been very little reported
> > breakage reported thus f
i finally got annoyed with the perl version (and its output and bugs and
limitations) and wrote a new version. it's fairly modular (and has pretty
good unittest coverage!?), so if we wanted to look at integrating it into
portage or other tools, that should be pretty easy now.
at any rate, if o
the awesome folks at Marist College in conjunction with the Linux Foundation
have upgraded our s390 VMs to newer hardware. faster/more CPUs, more RAM, and
more disk space. it's at the point where we aren't hurting to simply build
packages. so if devs are interested in ssh access, feel free to
this has all been fairly ad-hoc in the past, so formalize it in the one place
that impacts everyone -- profiles.desc.
-mike
###
# This is a list of valid profiles for each architecture. This file is used by
# repoman when
28 matches
Mail list logo
