On Thu, Jun 14, 2012 at 1:07 PM, Julien Cristau wrote:
> On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote:
>
>> Wouldn't the ideal solution be non-architecture-specific changelogs?
>
> No, that would be very much non-ideal. One should be able to schedule
&g
On Thu, Jun 14, 2012 at 3:43 PM, Philipp Kern wrote:
> On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote:
>> I did not suggest that. Anyway, maybe this will be a bit clearer.
>> Let's say an existing package is at version +b1 on amd64, and it needs
>> t
On Mon, Jul 2, 2012 at 1:59 PM, Petter Reinholdtsen wrote:
>
> [Silvio Cesare]
>> I recently ran the tool and cross referenced identified code copies with
>> Debian's security tracking of affected packages by CVE. I did this for all
>> CVEs in 2010, 2011, and 2012.
>
> This sound like a job that co
On Thu, Jul 26, 2012 at 3:44 PM, Svante Signell wrote:
>> If a you see an out-of-date package, please volunteer your time to
>> help fix it. If you're not a DD, you can do the work and send a
>> message to debian-mentors.
>
> I have tried several times and I can give you a recent example, see
> #
On Thu, Jul 26, 2012 at 6:09 PM, Russ Allbery wrote:
>> While it's nice that you've prepared a package for the new mlocate
>> upstream version, getting it done after the freeze is simply far too
>> late. Also, for packages that haven't been updated in a very long time
>> (two years in this case),
On Thu, Jul 26, 2012 at 7:20 PM, Svante Signell wrote:
>> Yeah, I guess that makes sense, *if* the person doing the NMU then owns
>> any bugs they introduce and of course doesn't do anything drastic like
>> rewriting the build system. And provides plenty of warning.
>
> Please, what can I do being
On Thu, Jul 26, 2012 at 6:58 PM, Russ Allbery wrote:
>> True. Part of the problem is appropriate terminology. This is a case
>> of what I would call an "undermaintained" package. Even though the
>> maintainer is still around, and may be quite active elsewhere, this
>> package has not gotten any
On Tue, Aug 28, 2012 at 12:53 PM, Paul Tagliamonte wrote:
>> If a package fails to build with an alternate compiler (that is, it
>> correctly *uses* the compiler, but the compiler reports a fatal error),
>> is that considered a bug, and what severity does it have?
>
> I'd not consider a FTBFS with
On Tue, Sep 11, 2012 at 1:22 PM, Wookey wrote:
> I'd be happy if xfce was the default. Which is better depends if one
> prefers 'dull-but-works-everywhere' over
> 'shiny-but-not-universaly-liked'. I can see reasonable arguments in
> favour of either.
Robustness is a rather important/lofty goal es
On Tue, Sep 11, 2012 at 6:19 PM, Philipp Kern wrote:
> On Tue, Sep 11, 2012 at 01:38:08PM -0400, Michael Gilbert wrote:
>> On Tue, Sep 11, 2012 at 1:22 PM, Wookey wrote:
>> > I'd be happy if xfce was the default. Which is better depends if one
>> > prefers
On Wed, Sep 12, 2012 at 6:16 AM, Josselin Mouette wrote:
> Le mercredi 12 septembre 2012 à 11:03 +0100, Darac Marjal a écrit :
>> Isn't the whole concept of "default desktop" just a matter of "which
>> desktop is included on CD1"? Are you proposing that Debian switches to a
>> series of "CD1s" (Deb
On Thu, May 16, 2013 at 5:52 AM, Neil McGovern wrote:
> On Thu, May 16, 2013 at 12:29:11AM +0200, Kurt Roeckx wrote:
>> Some upstreams have a testing branch of there software and a
>> release branch. It's sometimes useful to have people test the
>> version in from the testing branch, and having it
On Tue, May 21, 2013 at 4:19 AM, Helmut Grohne wrote:
> On Tue, May 21, 2013 at 01:21:41AM +0200, Andreas Beckmann wrote:
>> That might be possible with DPAs and if upload management is changed
>> generally to get less "broken" packages into unstable. E.g.
>
> I think that most of the ideas you pre
On Sat, May 25, 2013 at 11:52 AM, Ben Hutchings wrote:
> On Sat, 2013-05-25 at 10:41 +0200, Ondřej Surý wrote:
>> > examples would be useful
>>
>>
>> I have no big problem pointing fingers on d-d.
>>
>>
>> Example 1: Dan Jacobson
>
> Often writes poor bug reports, but is not abusive.
>
> [...]
>>
On Mon, Aug 19, 2013 at 5:12 PM, Vincent Bernat wrote:
> ❦ 19 août 2013 22:19 CEST, Clint Byrum
>
>>> Many people seem to justify a switch to Ubuntu LTS with the argument of
>>> 5-year security support. This support only applies for packages in
>>> main. A common example is nginx which is in unive
On Tue, Aug 27, 2013 at 4:50 PM, Pau Garcia i Quiles wrote:
> On Tue, Aug 27, 2013 at 7:18 PM, Russ Allbery wrote:
>
>> > IMHO the Security Team should not act as fixers themselves but more as
>> > proxies, passing information about a security issue to the maintainer of
>> > the package.
>>
>> And
On Tue, Aug 27, 2013 at 9:58 AM, Simon McVittie wrote:
> On 27/08/13 14:32, Pau Garcia i Quiles wrote:
>> What do you do with the 1 year of support Debian currently gives to
>> oldstable? It's also 1 year you stopped using that version, so no
>> technical challenge either.
>
> There does need to be
On Sun, Sep 1, 2013 at 6:04 AM, Paul Wise wrote:
> On Sat, Aug 31, 2013 at 5:57 PM, Michael Gilbert wrote:
>
>> I've been meaning to add more informative info to the security-tracker
>> about end-of-lifed packages. Right now you can see that info in the
>> raw track
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
I am pleased to announce the unofficial Debian monthly testing snapshot
release for October 2011 (version 2011.10). This release is currently
available for i386 and amd64 as iso images downloadable from:
http://alioth.debian.org/~gilbert-g
Correct gpg signature this time:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
I am pleased to announce the unofficial Debian monthly testing snapshot
release for October 2011 (version 2011.10). This release is currently
available for i386 and amd64 as iso images downloadable from:
h
On Sat, Oct 22, 2011 at 5:46 PM, Matthias Klose wrote:
>> Two hardening features are not enabled by default: PIE and bindnow.
>> If your package supports PIE, you might want to consider enabling it.
>
> You should not blindly enable PIE, even if the package seems to support it.
> PIE
> can ha
On Wed, Oct 26, 2011 at 1:08 PM, Raphael Hertzog wrote:
> Hi,
>
> On Sun, 23 Oct 2011, Paul Wise wrote:
>> One of the other problems with embedded JavaScript libraries is that
>> often only the pre-compiled/obfuscated/minified version is
>> distributed, which would be a violation of DFSG item 2.
>
On Wed, Oct 26, 2011 at 6:29 PM, Zygmunt Krynicki wrote:
> If anything, having one version of a javascript library *hurts*
> Debian-as-a-platform. I would encourage a different approach altogether:
> explicit mutli-versioning (ideally for all upstream releases or for all
> upstream releases that ar
On Wed, Oct 26, 2011 at 6:55 PM, Zygmunt Krynicki wrote:
> Is there anyone that would like to mentor me for a while to help me get
> started? I'm quite interested in solving this problem.
You can certainly work on anything in Debian (including this) and
present your work to mentors [0] and/or the
On Sun, Nov 20, 2011 at 7:01 PM, peter green wrote:
>> Or he can repackage 14.xxx as "15.xxx.1" but then other
>> packages depending on > 14 etc. will get the version wrong and the
>> numbering will be misleading.
>
> It's possible to use a version number like 15.xxx+really14.xxx but it's ugly
> to
On Wed, Nov 23, 2011 at 7:12 PM, wrote:
>> "YP" == Yves-Alexis Perez writes:
>
> YP> I'm not sure telling people to use --no-sandbox without telling them
> YP> what they lose is a good idea. Sandboxing is here for a reason.
I find the "no-sandbox" label sufficiently descriptive, but for
compl
On Wed, Nov 23, 2011 at 7:43 PM, Michael Gilbert wrote:
> On Wed, Nov 23, 2011 at 7:12 PM, wrote:
>>>>>>> "YP" == Yves-Alexis Perez writes:
>>
>> YP> I'm not sure telling people to use --no-sandbox without telling them
>> YP> what t
On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:
> The question is: who decides? I have a bunch of packages and an established
> workflow that served me well over the last years. I don't want to learn
> another *censored* system, just because someone said its the new standard or
> it is bette
On Mon, Nov 28, 2011 at 7:32 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:
>
>>> The question is: who decides? I have a bunch of packages and an
>>> established workflow that served me well over the last ye
On Fri, Dec 2, 2011 at 3:41 PM, Cyril Brulebois wrote:
> BTW, what ever happened to the Constantly Usable Trolling effort?
Trolling: http://catb.org/jargon/html/T/troll.html
> I see some “Call for Testing” from time to time, but what happens next?
Use it: http://cut.debian.net
The calls for tes
On Fri, Feb 17, 2012 at 11:09 PM, Christoph Anton Mitterer wrote:
> For many of those I've reported bugs (and I'm sure I didn't found a lot of
> them, and I'm further sure
> that new cases were introduced).
> Some where closed, some where just ignored or denied.
Fortunately, this is rather uncommo
On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote:
> On 10/08/2012 01:21 AM, Julien Cristau wrote:
>>> Would it be appropriate to file RC bugs against all the packages
>>> shipping anything in /var/run, /var/lock or /run?
>>>
>> No, there's nothing wrong with that.
>>
>> Cheers,
>> Julien
>
> Li
On Wed, Oct 10, 2012 at 6:04 PM, Lucas Nussbaum wrote:
> So, reading this thread (which was surprisingly quiet, given the topic),
> it seems that everybody agrees that such a procedure would be a good
> thing (nobody had fundamental concerns). But now we have two proposed
> procedures:
> - one wh
On Fri, Oct 12, 2012 at 4:31 PM, Christoph Anton Mitterer wrote:
> But it's a general security paradigm, that one shouldn't just focus on
> the attack vectors one can think of... but rather trying to secure
> "everything" ;)
Which is impossible, or at least man-powerwise insurmountable. There
are
On Fri, Oct 12, 2012 at 4:45 PM, Christoph Anton Mitterer wrote:
> On Fri, 2012-10-12 at 16:37 -0400, Michael Gilbert wrote:
>> Which is impossible, or at least man-powerwise insurmountable. There
>> are something like 500 million lines of code in a Debian release.
> I wasn&#x
On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote:
>> If so, please submit
>> bugs, and we will look at fixing them. Otherwise, speculation gets us
>> nowhere and actually wastes time.
> Well I had once a discussion (around March this year) here about
> blockin/downgrade attacks... w
I know this subject has been discussed on and off in the past, but
there's new evidence that it's simply the right thing to do.
Due to changes in upstream's build system, isc-dhcp recently started
including build system paths in dhclient's search path. This got a
security identifier, and we've fi
On Wed, Oct 17, 2012 at 4:07 PM, Bernhard R. Link wrote:
> * Michael Gilbert [121016 04:59]:
>> Anyway, all of these build system path sanitization issues can be
>> eliminated by using the buildds for all architectures, since paths
>> will start with at least /build tha
On Wed, Oct 17, 2012 at 4:55 PM, Bernhard R. Link wrote:
> * Michael Gilbert [121017 22:19]:
>> Anyway, reading again, I not sure that your reply actually considers
>> build path sanitization problems, which is what my statement was
>> about.
>
> I'm stating that
On Wed, Oct 17, 2012 at 5:23 PM, Michael Gilbert wrote:
> That is true: if there is a build path sanitization issue, then if the
> user chooses to rebuild the package they will get their own rogue
> paths. So, yes, we should always fix those issues when they're found,
> but at
On Wed, Oct 17, 2012 at 10:22 PM, Matthew Grant wrote:
> On Wed, Oct 17, 2012 at 1:57 PM, Michael Gilbert
>> No. We're in the freeze now. Fixes need to be backported.
>
>
> If backporting a fix is not possible with the certainty of no introduced
> bugs, we have n
On Wed, Oct 17, 2012 at 2:56 AM, Joerg Jaspert wrote:
> On 13001 March 1977, Michael Gilbert wrote:
>
>> So, are we ready to do this?
>
> No.
> Its for after wheezy, definitely.
> Also, there are some open issues to be solved for this to happen.
> The most important is b
On Thu, Oct 18, 2012 at 9:19 PM, Christoph Anton Mitterer wrote:
> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These a
On Thu, Oct 25, 2012 at 9:50 AM, Ian Jackson
wrote:
> Scott Kitterman writes ("Re: [SUMMARY/PROPOSAL] Orphaning another
> maintainer's packages"):
>> Why not start with a "without objection" standard and see how it
>> works?
>
> I absolutely agree with this.
>
> If we adopt a "without objection"
On Thu, Oct 25, 2012 at 6:05 PM, Jean-Michel Vourgère wrote:
> On Thursday 25 October 2012 19:09:55 Michael Gilbert wrote:
>> (...)
>> I would prefer to see even more autonomy for the salvager and less
>> bugging of various lists (ITPs on -devel are already distracting
>
On Thu, Oct 25, 2012 at 6:15 PM, Michael Gilbert wrote:
>> When fixing non important bugs, or improving the package quality, like
>> switching to format 3 source, arranging the rules file, and so on, I fear
>> it will be very difficult to find a sponsor for these nmus.
>
&g
On Thu, Oct 25, 2012 at 6:50 PM, Arno Töll wrote:
> On 25.10.2012 21:09, Michael Gilbert wrote:
>> 2. Salvager uploads liberal (10-day delayed) nmus as needed to bring
>> the package into a better maintained state.
>
> Please let's not go that road. Mixi
On Thu, Oct 25, 2012 at 7:19 PM, Russ Allbery wrote:
>> As I've said many times now, the liberal NMU would not be a license for
>> packaging style changes. In fact, no NMU is allowed to make those
>> changes (the fact that people are doing it is apparently a social issue,
>> and solutions to those
On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Thu, Oct 25, 2012 at 7:52 PM, Russ Allbery wrote:
>
>>> I certainly have no objection to people doing this, but I'm not sure
>>> that's really what we're discussing he
On Thu, Oct 25, 2012 at 9:14 PM, Russ Allbery wrote:
>> I respect your opinion, so I'm just curious which part do you believe
>> won't work in common cases? It's just applying existing NMU rules with
>> a little more liberalism to increase activity in under-maintained
>> packages, so I personally
On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
> On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
>> I think this is where language is important. In my opinion, the term
>> "adoption" will continue to mean taking on full responsibility fo
On Fri, Oct 26, 2012 at 7:46 AM, Arno Töll wrote:
> *) we have consensus that we are in need of such a rule set - which ever
> it may be
>
> *) we have three orthogonally different ideas:
>a) Bart's approach which was reformulated and proposed by Lucas in
> this thread [1]
>b) Mine - which
On Fri, Oct 26, 2012 at 6:06 PM, Steve Langasek wrote:
> On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote:
>> On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
>> > On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
>> >> I t
On Fri, Oct 26, 2012 at 8:19 PM, Steve Langasek wrote:
> On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote:
>
>> We already orphan packages without the maintainer's consent, and it's
>> already called "orphaning".
>
>> Salvaging is sti
On Sat, Oct 27, 2012 at 10:19 AM, Bart Martens wrote:
> So maybe we could simply allow
> anyone, including non-DDs, to submit O-bugs for packages which seem abandoned
> by the maintainer, and to submit ITA-bugs for packages he/she wishes to
> salvage. Sounds revolutionary, but in reality this is m
On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote:
>> maybe we could simply allow anyone, including non-DDs, to submit O-bugs for
>> packages which seem abandoned by the maintainer, and to submit ITA-bugs for
>> packages he/she wishes to salvage.
>
> I think that this misses one of the reasons
On Sun, Oct 28, 2012 at 12:25 PM, Wouter Verhelst wrote:
> If not, why are you claiming to replace their code? It's fine to be
> writing "something else" to replace older code; but it's fairly rude to
> be claiming that whatever you're writing is the "next generation" of
> that older code
Any rewr
On Sun, Oct 28, 2012 at 12:07 PM, Russ Allbery wrote:
>>> If, as Bart has found, such mistakes are quite rare, then why worry so
>>> much? We don't need new formal processes for rarely occurring social
>>> problems. We need more people willing to help those that make social
>>> mistakes to learn
On Tue, Oct 30, 2012 at 12:47 PM, Jerome BENOIT wrote:
>> Is this not something best managed on a case-by-case basis?
>
> my experience as potential sponsoree for such a package answers me no
> because
> it is hard to get a sponsor.
If it fixes *only* rc bugs, then send a bug to sponsorship-reques
On Wed, Oct 31, 2012 at 3:05 AM, Andreas Tille wrote:
>> Unless we're having some heavyweight process with multiple pings
>> etc. (which we IMO shouldn't) the way the maintainer might first
>> discover that someone feels the package needs to be orphaned is by the
>> ITO bug. The maintainer needs
On Wed, Oct 31, 2012 at 2:34 PM, Bart Martens wrote:
> On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote:
>> How to solve the following problem: Assume a package with wishlist bugs
>> filed lagging behind upstream and the maintainer refuses to package any
>> newer upstream, not even in
On Thu, Nov 1, 2012 at 5:51 AM, Tollef Fog Heen wrote:
> ]] Michael Gilbert
>
>> mlocate: http://bugs.debian.org/669368 (new upstream could have been
>> pushed via nmu before the freeze, but it was prepared too late)
>>
>
> The suggested NMU that does random chang
On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote:
>> wine: http://bugs.debian.org/585409 (new upstream pushed via nmu)
>
> This is a good example where talking helped to gather all views on all aspects
> from all involved people. My impression is that finally the maintainer
> allowed
> new co-m
On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote:
>> > The new upstream release did not include any particularly compelling
>> > changes for wheezy, which is why I did not update to the newer
>> > upstream version.
>>
>> It may not have include changes interesting to you, but there was
>> cert
On Thu, Nov 1, 2012 at 3:29 PM, Russ Allbery wrote:
>> That's where nmus help. Someone that does care and does have the time
>> can go ahead and get the features interesting them (and likely many
>> other users) to work.
>
> That's only true if you're happy with all of the changes being reverted
On Thu, Nov 1, 2012 at 5:00 PM, Stefano Zacchiroli wrote:
> On Thu, Nov 01, 2012 at 04:30:51PM -0400, Michael Gilbert wrote:
>> > You're still making the maintainer take explicit action to stop
>> > something that he already said they didn't want to happen.
>&g
On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote:
> On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
>> Maybe an example will help get us on the same page. Russ seems to
>> have the impression that my proposal is somehow a license to push
>> unwanted ch
On Thu, Jan 10, 2013 at 3:21 AM, Andreas Beckmann wrote:
> Excluding shipped files from .md5sums looks seriously wrong for files
> in /usr and at least questionable in /var/lib.
What is so "serious" about that? Please no more rc mbf's.
Thanks,
Mike
--
To UNSUBSCRIBE, email to debian-devel-req
On Sat, Jan 5, 2013 at 12:36 AM, Thomas Goirand wrote:
> On 01/05/2013 01:28 AM, alberto fuentes wrote:
>> The few people on the list seems happy with it. If this is working
>> well, it needs a little more love on debian.org and a 'testing-cut'
>> link in the repos pointing to latest cut, so it ca
On Thu, Jan 24, 2013 at 12:39 AM, martin f krafft wrote:
> Hey folks,
>
> For a while now, the backports archive sets "ButAutomaticUpdates:
> yes" in its Release file, causing packages in the archive to be
> pinned with priority 100, rather than 1 (which was previously the
> case).
>
> The effect o
> I wonder in how far I could do my share in the bug count reduction
> business. Perhaps in helping finding bugs belonging into such
> categories to attract the right people to the right bug and help
> reducing the time for people to detect a reasonable target for
> squashing?
There are always se
On Fri, Mar 1, 2013 at 8:36 PM, Russ Allbery wrote:
>> They may seem intimidating, but they're usually fairly straightforward
>> with a little research.
>
> While I certainly don't want to discourage people from working on
> security-related bugs, note that security-related bugs don't block the
> r
On Wed, Mar 6, 2013 at 7:46 AM, Holger Levsen wrote:
>> IMO it's better to leave it in dput-ng and not moving it into
>> devscripts.
>
> why? I don't want dput-ng (yet?) but I'd like to have a dm command in
> devscripts. Whats your reasoning not to?
It's up to people interested dcut(classic) to su
On Wed, Mar 6, 2013 at 11:56 AM, Michael Gilbert wrote:
> On Wed, Mar 6, 2013 at 7:46 AM, Holger Levsen wrote:
>>> IMO it's better to leave it in dput-ng and not moving it into
>>> devscripts.
>>
>> why? I don't want dput-ng (yet?) but I'd like t
On Sun, Mar 31, 2013 at 11:56 AM, Wookey wrote:
> +++ Benjamin Drung [2013-03-30 22:49 +0100]:
>> Hi,
>>
>> devscripts ships a bunch of scripts to make the life of a Debian Package
>> maintainer easier. Not every script in there is Debian packaging
>> specific. Some of them are used on other non-De
On Fri, Apr 5, 2013 at 7:45 PM, carlos wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Thanks for your time and job!
> I've trying to use Chromiun latest trunk but its requires libc-bin > 2.15,
> even I use Debian Testing I do not have this package.
> Is thought to have libc 2.17 o
On Fri, May 3, 2013 at 9:25 AM, Thijs Kinkhorst wrote:
> On Fri, May 3, 2013 15:09, Wouter Verhelst wrote:
>>> > No, it's not. Source only uploads were banned many years ago, mainly
>>> due
>>> > to problems with maintainers not even build testing their packages.
>
>> They do. They just ignore the
On Sat, May 4, 2013 at 6:09 AM, Jakub Wilk wrote:
> We've always treated "FTBFS if built twice in a row" bugs as important:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-doublebuild
The real question is whether or not there is a consensus within the
project
On Sat, May 4, 2013 at 11:48 AM, Michael Gilbert wrote:
> On Sat, May 4, 2013 at 6:09 AM, Jakub Wilk wrote:
>> We've always treated "FTBFS if built twice in a row" bugs as important:
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;t
On Sat, May 4, 2013 at 11:58 AM, Andrey Rahmatullin wrote:
> On Sat, May 04, 2013 at 11:53:04AM -0400, Michael Gilbert wrote:
>> >> We've always treated "FTBFS if built twice in a row" bugs as important:
>> >> http://bugs.debian.org/cgi-bin/pkgreport.c
On Sat, May 4, 2013 at 12:14 PM, Andrey Rahmatullin wrote:
> On Sat, May 04, 2013 at 12:05:06PM -0400, Michael Gilbert wrote:
>> Again, as Thijs argued somewhat eloquently already earlier in this
>> thread, computational time is not the scarce resource to worry about;
>> hum
On Mon, May 6, 2013 at 8:49 AM, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNMUs
> * disca
On Thu, May 9, 2013 at 3:49 PM, Lars Wirzenius wrote:
> The wheezy freeze has been much too long. At ten months, it's four
> months longer than what we've gotten used to in several previous
> releases. Had we managed to keep the freeze at six months, it would
> still have been too long. I believe t
On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I disagree that there is something fundamentally wrong with how
>> development is done. The primary problems with this cycle were that
>> there were something like 400 or 500 extra rc
On Sun, May 12, 2013 at 4:00 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
>
>>> Right. Which is why we should immediately (for definitions of
>>> immediately that involve the release team taking a much-d
On Sun, May 12, 2013 at 4:42 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Or the project could end up in a perpetual freeze. Every time the
>> floodgates are opened, another 1,000 bugs could get reported due to all
>> of the new transitions, and another freeze wi
control: affects -1 src:poppler
On Fri, Nov 22, 2013 at 3:56 AM, Josselin Mouette wrote:
> I fully agree with Adrian that your “fix” is absolutely incorrect.
Thanks for the feedback. I've canceled the nmu.
> It will temporarily make xpdf work again, and break many other packages
> that have bee
On Sun, Dec 1, 2013 at 12:53 PM, Stephen Gran wrote:
> Can you explain why you think it would be a good idea to remove the
> power to decide their own goals from a team, and why you think it would
> be good for Debian to have one team drive another team's goals? This is
> so different to how we us
On Fri, Dec 27, 2013 at 2:23 AM, Charles Plessy wrote:
> I would welcome clearer rules to decide what is strictly required to be built
> from source. In particular, I would welcome something like "The maintainer
> decides, and can be overruled by the Technical Comittee if needed". What
> follows
On Tue, Dec 31, 2013 at 4:34 AM, Niels Thykier wrote:
>> I wonder, how is the release team measuring this? For the other ports that
>> you mention, you've pointed to concrete technical problems that are in line
>> with the previously-documented release qualification guidelines. kfreebsd,
>> OTOH,
On Mon, Jan 6, 2014 at 7:59 AM, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
>> On 06/01/14 at 11:56 +, Neil McGovern wrote:
>> > Explicitly again: Please see the last 7 years worth of bits mails, where
>> > the release team have lowered this without advan
On Wed, Feb 26, 2014 at 12:36 PM, Peter Samuelson wrote:
>
> [micah]
>> it feels like a bit too aggressive pressure for my tastes. I've seen
>> a lot of developers of packages who have found out their package will
>> be removed from testing, but don't have the time to resolve the
>> situation befor
Hi,
I am pleased to announce the unofficial Debian monthly testing snapshot
release candidate for April 2011. This release is currently available
in two flavors, i386 and amd64, as mini iso images (16 MiB each)
downloadable from:
http://alioth.debian.org/~gilbert-guest/snapshots/2011.04/debian-tes
On Sun, Apr 3, 2011 at 2:31 PM, Harald Dunkel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Ben,
>
> On 03/31/11 15:22, Ben Hutchings wrote:
>> On Thu, 2011-03-31 at 10:59 +0200, Harald Dunkel wrote:
>> [...]
>>> Of course I understand that this is highly complex. Maybe it would h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
I am pleased to announce the unofficial Debian monthly testing snapshot
release for April 2011 (version 2011.04). This release is currently
available in two flavors, i386 and amd64, as mini iso images (16 MiB
each) downloadable from:
http:
Scott Kitterman wrote:
> I noticed that this is still listed at http://wiki.debian.org/ReleaseGoals.
>
> Obviously that was a Squeeze goal. The equivalent goal for Wheezy should be
> python2.7 as default and python2.5 and python2.6 removed.
Is it out of the question to target python3.x as the
Scott Kitterman wrote:
> On Wednesday, April 13, 2011 09:22:44 AM Barry Warsaw wrote:
> > On Apr 11, 2011, at 07:22 PM, Scott Kitterman wrote:
> > >Hopefully it will gain additional sanity before approval (the authors did
> > >improve it based on comments I sent them it could still be better). The
Piotr Ożarowski wrote:
> [Michael Gilbert, 2011-04-13]
> > Can't that be solved in the release notes when that happens? Something
> > like:
> >
> > python3 is now the default /usr/bin/python, so if you have existing
> > python2 scripts you will nee
Raphael Hertzog wrote:
> If the release team is open to try this out, I'm volunteering
> to help implement this (i.e. at the very least managing transitions
> while the rest of the release team is concentrated on patch review for
> finalizing the stable release). I'am also happy to invest some effo
Stefano Zacchiroli wrote:
> On Fri, Apr 29, 2011 at 06:50:04PM -0400, Michael Gilbert wrote:
> > Look at the "welcoming new contributors" GR; what did that actually
> > accomplish? There isn't anything new to show for it, there are no new
> > means to bring co
101 - 200 of 233 matches
Mail list logo
