On Sun, 2014-02-16 at 09:03 -0500, Rich Freeman wrote:
> On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos wrote:
> > Also, keeping the bugs assigned to package maintainers will still allow
> > them to try to get that pending bugs fixed (or resolved in some way) as
> > they will take care more about th
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2014-02-16 23h59 UTC.
Removals:
dev-php/PEAR-HTML_BBCodeParser 2014-02-13 21:21:47 mabi
dev-php/PEAR-HTML_QuickForm_ElementGrid 2014-02-13 21:23:01 mabi
dev-php/PEAR-HTTP_Uplo
On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote:
> On Sun, 16 Feb 2014 09:41:03 +0100
> Pacho Ramos wrote:
>
> > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
> > [...]
> > > > If we want a separate assignee for old stabilizations, what about
> > > > a separate projec
Hello Naohiro,
Saturday, January 11, 2014, 7:00:58 PM, you wrote:
This one was close.
It would be great to have your help. Can you if need be
write a plugin for portage to send|receive portage data from|to
the servers?
I'm not well with Python. We would need a plug-in for the
portage to send
On 02/17/2014 05:36 AM, Andreas K. Huettel wrote:
> Am Sonntag, 16. Februar 2014, 18:18:56 schrieb Michael Palimaka:
>> On 02/17/2014 03:58 AM, Andreas K. Huettel wrote:
>>> Why not make it possible to keep an ~arch only deptree consistent?!
>>
>> amd64-fbsd already does this with a stable profile.
Am Sonntag, 16. Februar 2014, 18:18:56 schrieb Michael Palimaka:
> On 02/17/2014 03:58 AM, Andreas K. Huettel wrote:
> > Why not make it possible to keep an ~arch only deptree consistent?!
>
> amd64-fbsd already does this with a stable profile. They just choose to
> not actually have any stable ke
On Sun, 16 Feb 2014 15:46:23 +0100
Jeroen Roovers wrote:
> > But, I guess there are two major cases:
> > - Versions that cannot be stabilized due they not working on that
> > arch any longer
>
> It's probably a good idea to package.mask the affected versions on the
> arch profile(s) (with refere
On Sun, 16 Feb 2014 09:41:03 +0100
Pacho Ramos wrote:
> El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
> [...]
> > > If we want a separate assignee for old stabilizations, what about
> > > a separate project that handles this, or maybe we could assign
> > > the bugs to m-n or some
On Sun, 16 Feb 2014 15:04:30 +0100
Jeroen Roovers wrote:
> On Sun, 16 Feb 2014 09:00:16 +0100
> Tom Wijsman wrote:
>
> > In this case the maintainer isn't needed on the bug anymore.
>
> You can't simply drop your old toys when you get bored with them.
> You're leaving a mess in the tree and bl
On Sun, Feb 16, 2014 at 09:38:20AM -0500, Rich Freeman wrote:
> Well, if they make no choice then the maintainer deletes the package.
> That's what you want, right? The package would only stay around if
> the minor arch asked them to. If they don't do that, then nobody can
> complain.
>
> Howeve
On Sun, 16 Feb 2014 14:48:57 +0100
Jeroen Roovers wrote:
> On Sun, 16 Feb 2014 08:23:27 +0100
> Tom Wijsman wrote:
>
> > > > While it was not explained here, the idea can also move the
> > > > actual maintenance of the ebuild to the arch team; such that it
> > > > becomes the arch team's respon
On 02/17/2014 03:58 AM, Andreas K. Huettel wrote:
> Why not make it possible to keep an ~arch only deptree consistent?!
amd64-fbsd already does this with a stable profile. They just choose to
not actually have any stable keywords.
In my opinion, the profile type is better as a description of that
# Ulrich Müller (16 Feb 2014)
# Last upstream release in 2005.
# Does not work with Emacs 24.
# Masked for removal in 30 days, bug 501502.
app-emacs/eperiodic
pgpsAqoo1MHHa.pgp
Description: PGP signature
Hi all,
Right now we have arches maintaining a stable keyword and we have arches that
don't do that.
This makes me think that the classification of profiles as "exp", "dev",
"stable" in profiles.desc does not really cover all usecases.
[Current meaning:
"stable" - repoman checks it, arch h
On Sun, 16 Feb 2014 15:53:57 +0100
Pacho Ramos wrote:
In this case:
> > > - Versions that are not stabilized because arch team doesn't have
> > > the man power to do that.
> >
> > As above, package.mask would be a good intermediate solution,
> > communicating the problem to the arch users for,
On Sun, 16 Feb 2014 09:38:20 -0500
Rich Freeman wrote:
> Basically that one version of the package is now maintained by the
> arch team. Yes, I know they won't maintain it. The only people that
> impacts are those who use the arch, who are free to join the arch
> team and help out. My sense is
El dom, 16-02-2014 a las 15:46 +0100, Jeroen Roovers escribió:
> On Sun, 16 Feb 2014 15:18:42 +0100
> Pacho Ramos wrote:
>
> > I think that, if they delete del old version without breaking the tree
> > (and, then, moving the package to testing for that arch), the
> > situation is improved. But, i
On Sun, 16 Feb 2014 15:18:42 +0100
Pacho Ramos wrote:
> I think that, if they delete del old version without breaking the tree
> (and, then, moving the package to testing for that arch), the
> situation is improved. But, if the bug is assigned to the same team
> that cannot handle its stabilizati
On Sun, Feb 16, 2014 at 9:31 AM, Jeroen Roovers wrote:
> On Sun, 16 Feb 2014 09:22:49 -0500
> Rich Freeman wrote:
>
>> Well, they can assign the burden to an understaffed team if the team
>> wants them to.
>
> Achieving nothing in the process, even if the understaffed team
> actually responds.
I
On Sun, 16 Feb 2014 09:22:49 -0500
Rich Freeman wrote:
> Well, they can assign the burden to an understaffed team if the team
> wants them to.
Achieving nothing in the process, even if the understaffed team
actually responds.
> Perhaps an intermediate solution is that when a STABLEREQ gets stal
On Sun, 16 Feb 2014 09:03:31 -0500
Rich Freeman wrote:
> Well, that depends on your perspective. If they fix them by deleting
> the old version, then whether they've made things better or worse is a
> matter of philosophy.
When you've cut the understaffed arch team out of the loop and removed
t
On Sun, Feb 16, 2014 at 8:48 AM, Jeroen Roovers wrote:
> The (slightly rhetorical) question was how an understaffed team could
> be realistically expected to start maintaining ebuilds. Your entire
> reply missed that point.
>
> The answer to the question is that you can't. A package maintainer
> c
El dom, 16-02-2014 a las 09:03 -0500, Rich Freeman escribió:
> On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos wrote:
> > Also, keeping the bugs assigned to package maintainers will still allow
> > them to try to get that pending bugs fixed (or resolved in some way) as
> > they will take care more ab
On Sun, 16 Feb 2014 09:00:16 +0100
Tom Wijsman wrote:
> In this case the maintainer isn't needed on the bug anymore.
You can't simply drop your old toys when you get bored with them.
You're leaving a mess in the tree and blaming others. You have achieved
nothing else.
> > Or when another arch a
On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos wrote:
> Also, keeping the bugs assigned to package maintainers will still allow
> them to try to get that pending bugs fixed (or resolved in some way) as
> they will take care more about that specific package status. If we get
> that bugs assigned to a
> On Sun, 16 Feb 2014, Samuli Suominen wrote:
> wasn't the whole argument for not allowing binary files in tree the
> problems it causes w/ version control history, web interface, and
> such? then, what problems does .xpm or .svg cause? none, far as I
> know, so why disallow them?
That seems
On Sun, 16 Feb 2014 08:23:27 +0100
Tom Wijsman wrote:
> > > While it was not explained here, the idea can also move the actual
> > > maintenance of the ebuild to the arch team; such that it becomes
> > > the arch team's responsibility to deal with it, or rather don't
> > > deal with it
> >
> > H
# Jeroen Roovers (16 Feb 2014)
# Unmaintained, has several problems on modern systems,
# superseded by net-analyzer/ifststatus (bug #501432)
net-analyzer/ethstatus
Removal in about 30 days.
On 13/02/14 17:12, Ulrich Mueller wrote:
> When rewriting the script scanning for binary files in the Portage
> tree [1], I noticed that there are some 25 XPM and SVG image files,
> with sizes up to 13 kB.
>
> For the time being, I've added exceptions for MIME types image/svg+xml
> and image/x-xpm
Due elvanor lack of time:
app-misc/basenji
dev-libs/dbus-c++
dev-libs/log4c
net-voip/sflphone
x11-libs/hippo-canvas
El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
[...]
> > If we want a separate assignee for old stabilizations, what about a
> > separate project that handles this, or maybe we could assign the bugs
> > to m-n or something until the arch teams catch up?
>
> Again, where is the man
On Sat, 15 Feb 2014 19:05:56 -0600
William Hubbs wrote:
> On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote:
> > On Sat, 15 Feb 2014 16:53:22 -0600
> > William Hubbs wrote:
> >
> > > The problem with this is, what if it is more than one arch team?
> > > Which one do you assign it t
On Sun, 16 Feb 2014 00:37:03 +0100
Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 16:53:22 -0600
> William Hubbs wrote:
>
> > The problem with this is, what if it is more than one arch team?
> > Which one do you assign it to?
>
> Oh the fun we had in the past when bugs got assigned to one arch te
33 matches
Mail list logo
