Le 02/04/2013 08:40, Jukka Ruohonen a écrit :
> On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote:
>> When I said "peripheral" I meant in the sense that none of the Depends are
>> used by anything else beyond R. I know it is "not small" -- there are now
>> 4400 R packages on CRAN, a
[moving to debian-devel as Neil suggested]
On Mon, Apr 01, 2013 at 04:52:30PM +0100, Neil McGovern wrote:
>
> As a general hint, requests that are "obviously correct" get approved
> very quicky.
I can confirm this - thanks for the release team.
> Things that are "obviously wrong" get rejected v
On Mon, Apr 01, 2013 at 12:48:08AM +0300, Uoti Urpala wrote:
> IMO it's important to remember that it's fundamentally the release team
> that is at fault for problems here, not the R maintainer.
Can you please remind me what you do for Debian? Aside from flame debian-devel.
I've forgotten.
> Unst
Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez
* Package name: nfacct
Version : 1.0.1
Upstream Author : Pablo Neira Ayuso - Netfilter
* URL : http://netfilter.org/projects/nfacct/
* License : GPL
Programming Lang: C
Description : comma
On Mon, Apr 01, 2013 at 12:15:17AM +0200, Arno Töll wrote:
> So help speeding up the release process.
The universal rebuttal to all complaints about the release process. Sadly
it misses the point at the heart of most complaints: far too much work is
needed to become release-ready, and there is not
On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote:
> I don't think the time for this discussion is now, so I'll restrain
> myself from saying more. The release is near, and there's going to
> be plenty of time until the next freeze :)
When the pain of the freeze will be a fast-fadin
On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote:
> You seem to believe that unstable is more important than stable
> releases. I do not. One of us is in the wrong project.
If, you are suggesting here, that the release process in Debian is utterly
set in stone and nobody may raise obj
Le mardi 02 avril 2013 à 09:15 +0100, Jonathan Dowland a écrit :
> The universal rebuttal to all complaints about the release process. Sadly
> it misses the point at the heart of most complaints: far too much work is
> needed to become release-ready, and there is not enough resource to do it.
>
>
On Mon, Apr 1, 2013 at 11:16 PM, Daniel Pocock wrote:
> On 01/04/13 22:04, John Paul Adrian Glaubitz wrote:
>> On 04/01/2013 09:59 PM, Daniel Pocock wrote:
>>> Agreed, but that doesn't complete the picture, as libgl1-mesa-glx
>>> doesn't depend on libgl1-mesa-dri:
>>>
>>> $ apt-cache depends libgl
Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez
* Package name: libnetfilter-acct
Version : 1.0.2
Upstream Author : Pablo Neira Ayuso
* URL : http://netfilter.org/projects/libnetfilter_acct/index.html
* License : GPL
Programming Lang: C
Des
Package: wnpp
Severity: wishlist
Owner: Benda Xu
Please readopt the removed scim-bridge package[1]. I have made a package in
mentors.debian.org[2].
The reason for removal of the package was that no one wanted to work on this
and upstream was inactive.
Now upstream has one or two active mainta
Hi,
Am Montag, den 01.04.2013, 17:06 +0200 schrieb Luca Falavigna:
> Just for the record, FTP Team managed to keep the NEW queue around ten
> packages for more than one year and a half, average processing time
> was less than two days.
I did a few uploads during that time and really enjoyed the
On 02/04/13 09:24, Andreas Tille wrote:
> [moving to debian-devel as Neil suggested]
>
> On Mon, Apr 01, 2013 at 04:52:30PM +0100, Neil McGovern wrote:
>> As a general hint, requests that are "obviously correct" get approved
>> very quicky.
> I can confirm this - thanks for the release team.
>
>> T
Daniel Pocock (02/04/2013):
> To put this in context, I recently found that one of the packages I
> depend on (libasio-dev) is actually orphaned. It is mentioned in
> PTS, but I was never proactively alerted by anything such as
> lintian. There are probably many cases like this (orphaned library
On 02.04.2013 08:24, Andreas Tille wrote:
The only thing I'm wondering about is: Will all unblock requests be
handled before the release (either by an unblock or a refusal)?
That's the plan, yes. As Neil said, we've unfortunately not been as
good as we should have been at saying "no" (we don't
On Thu, Mar 28, 2013 at 12:07:43PM +0100, John Paul Adrian Glaubitz wrote:
> On 03/28/2013 11:47 AM, Daniel Pocock wrote:
> >Would you provide a guarantee to all users of wheezy that you will pay
> >for their laptop repair if this issue causes damage?
>
> > Debian GNU/Linux comes with ABSOLUTELY N
On 2013-03-31 23:20:23 +0100, Neil Williams wrote:
> The length of the freeze is not the fault of the release team.
>
> The length of the freeze is down to all of the contributors to Debian
> not fixing enough RC bugs - I count myself in that, I've managed to get
> massively less done for this rel
On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote:
> This is indeed Debian’s problem and needs discussion, but the roots lie
> in upstreams. It mostly comes down to the fact that upstreams of a
> growing number of projects are not able to synchronize their releases so
> that a single set of vers
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
> On 2013-03-31 23:20:23 +0100, Neil Williams wrote:
> > The length of the freeze is not the fault of the release team.
> >
> > The length of the freeze is down to all of the contributors to Debian
> > not fixing enough RC bugs - I coun
On 02.04.2013 13:52, Vincent Lefevre wrote:
I suspect that the
length of the freeze is due to the fact that the freeze occurred
while too many RC bugs were already open.
If so, there was a good reason for that (i.e. pre-announced time-based
freeze). As others have said (although ymmv) I don't
On Tue, 2 Apr 2013 14:52:35 +0200
Vincent Lefevre wrote:
> On 2013-03-31 23:20:23 +0100, Neil Williams wrote:
> > The length of the freeze is not the fault of the release team.
> >
> > The length of the freeze is down to all of the contributors to Debian
> > not fixing enough RC bugs - I count m
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
> Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
> > I disagree. If the freeze occurred only once (almost) all RC bugs
> > were fixed,
>
> Problem is: until you freeze, new RC bugs keep getting introduced.
But I would say, not ma
On Mon, Apr 01, 2013 at 01:13:29PM +0100, Neil Williams wrote:
> On Mon, 1 Apr 2013 17:42:29 +0600
> Andrey Rahmatullin wrote:
>
> > On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote:
> > > > Thanks for trading the R release cycle with Debian's and for
> > > > delaying the release.
On Tue, 2 Apr 2013 15:09:33 +0200
Vincent Lefevre wrote:
> On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote:
> > This is indeed Debian’s problem and needs discussion, but the roots lie
> > in upstreams. It mostly comes down to the fact that upstreams of a
> > growing number of projects are no
Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit :
> On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
> > Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
> > > I disagree. If the freeze occurred only once (almost) all RC bugs
> > > were fixed,
> >
> > Problem is: until
On Tue, 2 Apr 2013 15:15:38 +0200
Vincent Lefevre wrote:
> On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
> > Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
> > > I disagree. If the freeze occurred only once (almost) all RC bugs
> > > were fixed,
> >
> > Problem is: until yo
Hi Adam,
On Tue, Apr 02, 2013 at 01:32:50PM +0100, Adam D. Barratt wrote:
> On 02.04.2013 08:24, Andreas Tille wrote:
> >The only thing I'm wondering about is: Will all unblock requests be
> >handled before the release (either by an unblock or a refusal)?
>
> That's the plan, yes. As Neil said, w
On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote:
> Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit :
> > Having latest upstream versions easily available to users is important
> > for the development of many projects,
>
> That's what experimental is for.
There are various problems wit
On 2013-04-02 14:17:17 +0100, Neil Williams wrote:
> The release happens when (almost) all RC bugs are fixed, the freeze is
> to allow the existing bugs to be fixed whilst *protecting* the other
> packages from breakage caused by new software being uploaded.
You can still fix bugs while new softwa
On 2013-04-02 15:23:18 +0200, Samuel Thibault wrote:
> Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit :
> > On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
> > > Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
> > > > I disagree. If the freeze occurred only once (alm
On Mon, Apr 1, 2013 at 4:45 PM, Ben Hutchings wrote:
>
> Apparently there are, but aside from that: should a 'bts' command on
> $DERIVATIVE interact with the Debian bug-tracking system, or the
> $DERIVATIVE bug-tracking system?
This can/should preferably be configurable, defaulting to the Debian
On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
> That is not how it actually works out. Policy changes are made which
> require old packages to build with new flags, compilers and toolchain
> packages get upgraded and introduce new failure modes, QA tools improve
> and catch more corner cases.
Vincent Lefevre, le Tue 02 Apr 2013 17:20:52 +0200, a écrit :
> This is also due to the fact that more people are working on fixing RC
> bugs *now* instead of doing that before.
Which is one of the goals of freezing.
I'm just tired of argumenting over something that was already
discussed. Let's
On Tue, 2013-04-02 at 16:29 +0200, Vincent Lefevre wrote:
> On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote:
> > Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit :
> > > Having latest upstream versions easily available to users is important
> > > for the development of many projects,
> >
On Tue, Apr 02, 2013 at 05:18:53PM +0200, Reinhard Tartler wrote:
> This can/should preferably be configurable, defaulting to the Debian
> BTS. Derivatives should be encouraged to override the defaults
> accordingly.
In the case of "our" bts tool, I think it would be rather too much work
to re-arc
On Tue, Apr 2, 2013 at 11:18 PM, Reinhard Tartler wrote:
> This can/should preferably be configurable, defaulting to the Debian
> BTS. Derivatives should be encouraged to override the defaults
> accordingly.
Only EmDebian is using debbugs and they use bugs.d.o. I didn't think
the bts command had
On 02.04.2013 16:35, Svante Signell wrote:
The best solution would be having unstable _never_ frozen, at the
cost
of another repository during the freeze period. This was proposed
some
time ago, see
http://lists.debian.org/debian-devel/2013/01/msg00273.html
repeated here for convenience:
Tha
On 04/02/2013 07:52 PM, Daniel Pocock wrote:
> The problem is, how to pass this benefit on to users without either (a)
> marking every bug RC
There is absolutely no point doing that. Unless we are really
really close from releasing (like right now), even non-RC
bugs can be unblocked during the free
On Tue, 02 Apr 2013, Jukka Ruohonen wrote:
> On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote:
> > When I said "peripheral" I meant in the sense that none of the Depends are
> > used by anything else beyond R. I know it is "not small" -- there are now
> > 4400 R packages on CRAN, a
Jonathan Dowland writes:
> On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote:
>> I don't think the time for this discussion is now, so I'll restrain
>> myself from saying more. The release is near, and there's going to be
>> plenty of time until the next freeze :)
> When the pain
Vincent Lefevre writes:
> On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
>> That is not how it actually works out. Policy changes are made which
>> require old packages to build with new flags, compilers and toolchain
>> packages get upgraded and introduce new failure modes, QA tools improve
Vincent Lefevre writes:
> There are various problems with experimental, in particular dependencies
> are not necessarily listed,
Huh? I have no clue what you could possibly be talking about, unless
you're just saying that some packages in experimental are critically
buggy.
> and upgrade from a
On 02/04/13 14:00, Cyril Brulebois wrote:
> Daniel Pocock (02/04/2013):
>> To put this in context, I recently found that one of the packages I
>> depend on (libasio-dev) is actually orphaned. It is mentioned in
>> PTS, but I was never proactively alerted by anything such as
>> lintian. There are
Vincent Bernat writes ("Re: Bug#455769: same problem on wheezy + Thinkpad
X220T"):
> ❦ 28 mars 2013 20:38 CET, Thomas Goirand :
> > Unless you are the original reporter and you need to
> > decide in order to fill the bug, please don't. That's the
> > role of the maintainer to do that triaging wo
On Tue, Apr 02, 2013 at 04:58:20PM +0100, Jonathan Dowland wrote:
> On Tue, Apr 02, 2013 at 05:18:53PM +0200, Reinhard Tartler wrote:
> > This can/should preferably be configurable, defaulting to the Debian
> > BTS. Derivatives should be encouraged to override the defaults
> > accordingly.
>
> In
[Jonathan Dowland]
> On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote:
> > You seem to believe that unstable is more important than stable
> > releases. I do not. One of us is in the wrong project.
>
> If, you are suggesting here, that the release process in Debian is utterly
> set i
[Vincent Lefevre]
> I disagree. If the freeze occurred only once (almost) all RC bugs
> were fixed, there would be (almost) no delay. I suspect that the
> length of the freeze is due to the fact that the freeze occurred
> while too many RC bugs were already open.
Agreed: in July 2012, many - too
Package: general
Severity: normal
on the bottom of my gnome session i can't click on the open application
all other functions work fine like:
change workspace
scrol over the taskbar to switch applications
the application switcher on top of the screen (near by the clock)
-- System Information:
D
]] Russ Allbery
> > and this doesn't prevent developers from fixing RC bugs.
>
> Nothing prevents developers from fixing RC bugs at any time. They just
> don't in sufficient numbers to keep ahead of the incoming rate except
> during a freeze, both because the freeze drops the incoming rate (by,
Vincent,
am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben:
> I don't think that the status even of a big package like iceweasel
> is satisfactory.
I pretty much agree. But what's the problem here? That xulrunner and iceweasel
have rdeps in the archive that aren't necessarily
Goswin,
am Tue, Apr 02, 2013 at 03:18:24PM +0200 hast du folgendes geschrieben:
> And not, we do not have epochs to temporarily downgrade a package
> after a botched upload.
c.f. imagemagick
I'm pretty sure we do.
SCNR
Philipp Kern
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: "Sébastien Villemot"
* Package name: einspline
Version : 0.9.2
Upstream Author : Kenneth P. Esler, Jr.
* URL : http://einspline.sourceforge.net/
* License : GPL-2+
Programming Lang: C, Fortran
Description : libra
Package: wnpp
Severity: wishlist
Owner: Robie Basak
* Package name: pifacedigitalio
Version : 1.1
Upstream Author : Thomas Preston
* URL : https://github.com/piface/pifacedigitalio
* License : GPL-3+
Programming Lang: Python
Description : Python librar
On 04/01/2013 11:06 PM, Luca Falavigna wrote:
> On the other hand, FTP Team is willing to fast-track NEW packages
> anytime, if needed.
That's simply not truth. I can't let you say that and not reply.
And I'm happy we come to this topic.
I've sent a mail to the FTP masters last January (IIRC) abo
On Tue, Apr 02, 2013 at 07:13:05PM +0100, Ben Hutchings wrote:
> My point.
Sorry Ben!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130402204348.GC5048@debian
On 04/02/2013 12:16 AM, Luca Falavigna wrote:
> In a perfect world there wouldn't be any need for a NEW queue at all.
> But we have to face with the reality.
> We try to do our best to improve things where we can. From the FTP
> Team side, we always try to be quick and helpful with our fellow
> dev
On Tue, Apr 02, 2013 at 09:50:23AM -0700, Russ Allbery wrote:
> Vincent Lefevre writes:
>
> > and upgrade from an experimental package is not supported (it generally
> > works, but the maintainer doesn't have to take that into account).
>
> This is a bizarre statement to me. Why would you not t
Niko Tyni writes:
> FWIW, I've done ABI-incompatible uploads of perl to experimental in the
> past without changing the perlapi-* virtual package name or the libperl
> SONAME. The aim was to experiment with different configuration options,
> particularly 64-bit integers and 128-bit long doubles.
On 02/04/13 19:57, Ian Jackson wrote:
> Vincent Bernat writes ("Re: Bug#455769: same problem on wheezy + Thinkpad
> X220T"):
>> ❦ 28 mars 2013 20:38 CET, Thomas Goirand :
>>> Unless you are the original reporter and you need to
>>> decide in order to fill the bug, please don't. That's the
>>>
❦ 2 avril 2013 19:57 CEST, Ian Jackson :
>> > Unless you are the original reporter and you need to
>> > decide in order to fill the bug, please don't. That's the
>> > role of the maintainer to do that triaging work (as
>> > already stated multiple times!).
>>
>> We encourage people to help tri
On 02/04/13 18:35, Thomas Goirand wrote:
> On 04/02/2013 07:52 PM, Daniel Pocock wrote:
>> The problem is, how to pass this benefit on to users without either (a)
>> marking every bug RC
> There is absolutely no point doing that. Unless we are really
> really close from releasing (like right now)
Daniel Pocock writes ("Re: Bug#455769: same problem on wheezy + Thinkpad
X220T"):
> On 02/04/13 19:57, Ian Jackson wrote:
> > I agree. But such triage should be done in a way that the maintainer
> > will agree with. Fighting with the maintainer's view of severities is
> > not "triage", it is abu
Anyone else get a Knotify crash on startup on Debian 7 but only if all
power has been removed during shutdown?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013040
On 2 April 2013 16:18, Reinhard Tartler wrote:
> On Mon, Apr 1, 2013 at 4:45 PM, Ben Hutchings wrote:
>>
>> Apparently there are, but aside from that: should a 'bts' command on
>> $DERIVATIVE interact with the Debian bug-tracking system, or the
>> $DERIVATIVE bug-tracking system?
>
> This can/sho
64 matches
Mail list logo
