(seemingly) declinging bug report numbers

[Christoph Anton Mitterer]

Hi.

Some days ago Christian reported[0] about #69 with the feeling that
bug report numbers in Debian were declining, which Don’s post[1] later
seemingly confirmed.

I wondered myself whether this is a problem for Debian and if so, what
we can do against it?


First declining bug numbers are not necessarily a problem, because it
could just mean that we're getting better and better, or that more and
more upstream issues are reported upstream (which would be a good thing
IMHO), or that the maintainers already catch many problems themselves.


On the other hand, some worries are there that this could imply some
decline in Debian itself.
Well I still think Debian is the best distro out there for most (if not
all cases), even though I'd like to see it putting more emphasis on
security.
But, admittedly me not being the biggest *buntu fan (diplomatically
said), things like [2] disturb me quite a lot. Gives me somehow the
feeling as if it was an invitation to leave Debian towards *buntu.
Anyway,... that might be another reason for a decline (if there is
any),... being slowly assimilated by *buntu (and even helping with that)


Another reason could be, that people have problems with the BTS.
Don't get me wrong, I personally like it a lot... and I wouldn't want to
have e.g. launchpad (if at all,... I'm quite a bugzilla fan)... but
especially for end-users BTS might be tricky to use and I know even some
fellow computer scientists which complained about it (and asked whether
there was a more bugzilla-ish web interface or so).


Well.. I'm curious what other people think. :)


Cheers,
Chris.


[0] http://www.perrier.eu.org/weblog/2012/10/09#69
[1] http://www.donarmstrong.com/posts/bug_reporting_rate/
[2] http://lists.debian.org/debian-devel-changes/2012/10/msg00539.html


smime.p7s
Description: S/MIME cryptographic signature

Re: (seemingly) declinging bug report numbers

[Mathieu Malaterre]

On Thu, Oct 11, 2012 at 2:46 AM, Christoph Anton Mitterer
 wrote:
> Some days ago Christian reported[0] about #69 with the feeling that
> bug report numbers in Debian were declining, which Don’s post[1] later
> seemingly confirmed.

I believe the script is incorrect. It does not count ubuntu bugs that
gets fixed in debian, without ever being referenced in debian BTS...

2cts
-M


--
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/ca+7wusxbt1bszp_tmevealhw_8d7uomxbeppdcwqnosq8an...@mail.gmail.com

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Gergely Nagy]

Lucas Nussbaum  writes:

> On 11/10/12 at 05:50 +, Bart Martens wrote:
>>   |  Anyone can mark a package as orphaned after the following steps have 
>> been
>>   |  completed : Someone submits an "intent to orphan" (ITO) in the bts with 
>> an
>>   |  explanation of why he/she thinks that the package needs a new 
>> maintainer.  The
>>   |  explanation should cover aspects like how long there was no visible 
>> activity,
>>   |  whether there are NMUs not yet acknowledged, wheter the package blocks 
>> progress
>>   |  elsewhere in Debian, release critical bugs, public comments from the 
>> maintainer
>>   |  revealing lack of interest in the package, ... etc.  The bug must have 
>> severity
>>   |  "serious" and a cc must be sent to the debian-qa mailing list.  Anyone 
>> can
>>   |  submit this "intent to orphan".  At least three DDs (not counting the 
>> initial
>>   |  submitter) second the "intent to orphan" on the same bug report with a 
>> cc to
>>   |  the maintainer.  If some DDs send NACKs instead, then a 3/1 majority is 
>> needed
>>   |  between ACKers and NACKers.
>
>> And the maintainer does not respond within one month after the the third 
>> second.
>
> I'm not sure about this delay. This procedure should be used for
> uncontroversial cases, where orphaning is obviously the right choice.

I strongly agree here. A package that's a salvaging candidate has
already been neglected far too long, requiring another extra month of at
most NMU-maintainance is counter productive.

A maintainer has many ways to signal in advance that he/she will be
unable to answer bug reports or mail for a longer period of time
(including VAC messages on -private, and/or setting a vacation message
in LDAP), many of which can and should be checked as soon as the
salvaging process starts, to make sure there's no accidental overlap.

With that done, I do not see the point of waiting an extra month. I
would, however, put a time limit on the NACKs: one week after 3 ACKs or
3/1 majority is reached, the decision's done, and further ACKs/NACKs
won't be counted. That is, we'd have a time limit on everyones ability
to contribute to the salvaging process, not just a ticking clock for the
maintainer.

> Maybe rephrase that into "Before taking action, it could also be a good
> idea to wait for comments from the maintainer, especially if he/she is
> otherwise active in Debian."

I'd rephrase that further, with a s/wait for/seek/, because in my
opinion, the person wanting to salvage a package should go to great
lengths to reach the maintainer. Merely waiting when the package is
obviously neglected sounds like a very passive thing to me.

-- 
|8]


-- 
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/87r4p58llk.fsf@algernon.balabit

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Arno Töll]

Hi,

On 11.10.2012 07:50, Bart Martens wrote:
>> - the submitter of the "intent to orphan" bug must Cc 
>>   debian...@lists.debian.org, and file the bug with severity:serious (this 
>>   was part of the "criterias" proposal).
>   |  Anyone can mark a package as orphaned after the following steps have been
>   |  completed : Someone submits an "intent to orphan" (ITO) in the bts with 
> an
>   |  explanation of why he/she thinks that the package needs a new 
> maintainer.  

I don't think "intend to orphan" (ITO) is a good name. First of all, it
is wrong, because if you file such a bug, you eventually don't want to
orphan a package, but quite the contrary revive its maintenance.
Moreover, its name suggests it would be a WNPP bug, which it isn't and
wouldn't be.

Aside I welcome Lucas and your initiative to move on with this
discussion. After all, I'm happy with any solution which finds
consensus, but I still don't like the DD seconding for the reasons
outlined before. At very least we could allow DMs to make votes too.
Eventually it's just some key in a keyring which is required to
authenticate people.

Some additional thoughts on the seconding:

*  can we really be sure that random developers flying by, care enough
to look into a package they may not care about, inspect its situation
and ack/nack? The whole new mechanism could be bypassed by feedback
timeout. Frankly, many packages which could be salvaged in future are
not on of these which draw much attraction.

* You cannot require a 3:1 majority without giving a time window to
raise objections. The way Bart proposed it in his draft, one couldn't
make sure a 3:1 majority is reached before 75% of *all* developers
agreed for the opened case. I don't think that's desired or realistic.

* How would you validate binding votes on a salvage process? You would
need to require to send signed mails to the list for seconding.
Otherwise we did not win anything over votes allowed by anyone.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Charles Plessy]

Le Thu, Oct 11, 2012 at 05:50:51AM +, Bart Martens a écrit :
> 
>   |  Anyone can mark a package as orphaned after the following steps have been
>   |  completed : Someone submits an "intent to orphan" (ITO) in the bts with 
> an
>   |  explanation of why he/she thinks that the package needs a new 
> maintainer.  The
>   |  explanation should cover aspects like how long there was no visible 
> activity,
>   |  whether there are NMUs not yet acknowledged, wheter the package blocks 
> progress
>   |  elsewhere in Debian, release critical bugs, public comments from the 
> maintainer
>   |  revealing lack of interest in the package, ... etc.  The bug must have 
> severity
>   |  "serious" and a cc must be sent to the debian-qa mailing list.  Anyone 
> can
>   |  submit this "intent to orphan".  At least three DDs (not counting the 
> initial
>   |  submitter) second the "intent to orphan" on the same bug report with a 
> cc to
>   |  the maintainer.  If some DDs send NACKs instead, then a 3/1 majority is 
> needed
>   |  between ACKers and NACKers.  And the maintainer does not respond within 
> one
>   |  month after the the third second.  During this process anyone is welcome 
> to add
>   |  comments on the bug.

Hi Bart,

here are some comments.

 - It would be more straight to the point to submit an "Intend To Salvage" 
(ITS) and
   focus on such takeovers, because merly orphaning the package does not 
guarantee
   that it will be actively maintained.

 - You may clarify that the bug is to be reported to the package, not to the
   wnpp pseudo-package.

 - How about requesting that the explanation contains the plans for future work 
on
   the package ?

 - I am not found of the voting procedure, and would rather propose to follow a
   similar process as for the modification of the Policy and the Developers
   Reference, where at least three DDs need to indicate that, in their 
conclusion,
   a consensus has been reached.  I think that if a package is orphaned with for
   instance a 16:3 majority, it indicates a problem rather than a consensus.  
Also
   if the maintainer opposes, this shows lack of consensus and a vote can only
   aggravate the situation.

 - For response delay, it think that one month after the bug is opened would be
   a good compromise.  It also makes the deadline more predictable, as opposed
   to voting or counting consensus assessments.  We can not use private
   information such as vacation flag of the LDAP database in public bug records,
   so we must assume that the maintainer may not be available.  This said 
perhaps
   we can request that DDs must not post ITS on pacakges where the maintainer 
has
   declared being on vacation in the LDAP ?

 - Lastly, how about an expiration date ?  If we all agree on a one-month delay
   for the maintainer's response, we can also use it as an expiration date.  If
   within a month there is no reaction of the maintainer, but on the other hand
   the proposer does not manage to attract support or even positive comments, 
then
   it either signals unwritten problems, or it asks the question whether the 
package
   should really stay in Debian.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20121011094453.gb27...@falafel.plessy.net

Re: (seemingly) declinging bug report numbers

[Christoph Anton Mitterer]

On Thu, 2012-10-11 at 09:15 +0200, Mathieu Malaterre wrote:
> I believe the script is incorrect. It does not count ubuntu bugs that
> gets fixed in debian, without ever being referenced in debian BTS...
Well but it's up to interpretation, whether that wouldn't be a worrying
sign, too. I mean that bugs are fixed rather via Ubuntu.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: (seemingly) declinging bug report numbers

[Paul Wise]

On Thu, Oct 11, 2012 at 5:51 PM, Christoph Anton Mitterer wrote:

> Well but it's up to interpretation, whether that wouldn't be a worrying
> sign, too. I mean that bugs are fixed rather via Ubuntu.

Where bugs are reported doesn't matter, as long as they get fixed.
Personally I look at the bug trackers for Ubuntu, Fedora, Gentoo and
other distributions (using whohas) when I'm preparing both new
upstream releases and also when preparing Debian uploads.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6FLxM=GMMM0nGtz+v8nLLpSQ-gNy_9v6x4W+J4j=g...@mail.gmail.com

Re: (seemingly) declinging bug report numbers

[Stefano Zacchiroli]

On Thu, Oct 11, 2012 at 11:51:50AM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2012-10-11 at 09:15 +0200, Mathieu Malaterre wrote:
> > I believe the script is incorrect. It does not count ubuntu bugs that
> > gets fixed in debian, without ever being referenced in debian BTS...
> Well but it's up to interpretation, whether that wouldn't be a worrying
> sign, too. I mean that bugs are fixed rather via Ubuntu.

I wonder: did upstream developers start to worry when the number of bugs
report they received *directly* started to decrease, due to Debian
distributing their software? (Note: that started to happen "a few" years
ago, like 15-20 :-)) They probably did worry, yes. But as long as Debian
play it right with them, by triaging/forwarding bug reports to them as
needed, no harm is done. In fact, the resulting ecosystem probably
brings *more* users and bug report to them than before, albeit now they
are mediated. Looks like the same situation.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: (seemingly) declinging bug report numbers

[Marco Nenciarini]

Il giorno gio, 11/10/2012 alle 02.46 +0200, Christoph Anton Mitterer ha
scritto:
> 
> On the other hand, some worries are there that this could imply some
> decline in Debian itself.
> Well I still think Debian is the best distro out there for most (if not
> all cases), even though I'd like to see it putting more emphasis on
> security.

I've seen recently several company I'm working with getting away from
Debian in favor of Ubuntu because they have a LTS version. However I
don't know if this is a general trend.

Ciao,
Marco

-- 
-
|Marco Nenciarini| Debian/GNU Linux Developer - Plug Member |
| mnen...@prato.linux.it | http://www.prato.linux.it/~mnencia   |
-
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4




signature.asc
Description: This is a digitally signed message part

Bug#690157: ITP: aptitude-robot -- Automate package choice management

[Elmar S. Heeb]

Package: wnpp
Owner: "Elmar S. Heeb" 
Severity: wishlist
X-Debbugs-CC: aptitude-de...@lists.alioth.debian.org,
debian-devel@lists.debian.org

* Package name: aptitude-robot
  Version : 1.0
  Upstream Author : "Elmar S. Heeb" 
* URL : https://github.com/elmar/aptitude-robot
* License : GPL-3+
  Programming Lang: Perl
  Description : Automate package choice management

Framework to use aptitude for automated package management including
upgrade, installation, removal, hold, etc.  Allows you to automate what
you would manually do with aptitude.


-- 
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/50758df7.7090...@heebs.ch

Re: (seemingly) declinging bug report numbers

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 11/10/2012 13:40, Stefano Zacchiroli a écrit :
> On Thu, Oct 11, 2012 at 11:51:50AM +0200, Christoph Anton Mitterer
> wrote:
>> On Thu, 2012-10-11 at 09:15 +0200, Mathieu Malaterre wrote:
>>> I believe the script is incorrect. It does not count ubuntu
>>> bugs that gets fixed in debian, without ever being referenced
>>> in debian BTS...
>> Well but it's up to interpretation, whether that wouldn't be a
>> worrying sign, too. I mean that bugs are fixed rather via
>> Ubuntu.
> 
> I wonder: did upstream developers start to worry when the number of
> bugs report they received *directly* started to decrease, due to
> Debian distributing their software? (Note: that started to happen
> "a few" years ago, like 15-20 :-)) They probably did worry, yes.
> But as long as Debian play it right with them, by
> triaging/forwarding bug reports to them as needed, no harm is done.
> In fact, the resulting ecosystem probably brings *more* users and
> bug report to them than before, albeit now they are mediated. Looks
> like the same situation.
> 

Users who get software through the Debian packages are still 100%
users of said software.

I guess the matter here is the recurring questions: are Ubuntu users
100% Debian users? Are we happy to provide high quality through
derivative distributions, or are we worried (or sad) that they don't
use Debian directly?

I personally really don't see a problem with having less bugs reported
in Debian proper, as long as the bugs are found and eventually fixed
in Debian (and further upstream). And I don't care much whether my
packages are used under Debian or rebuilt for Ubuntu, as long as they
are useful to somebody.

As a matter of fact, I consider it bonus if work I do for Debian also
benefits users of other distros, and being higher along the stream
means whatever we do trickles down to more users.

Kind regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQdrofAAoJEJOUU0jg3ChA+2MP/3DUG84rhIXSNFn6ZiiYD+1C
TgQt78wCvpQzp+Ept1ncuCuMFp8kVJE/D0UhOFhOVWnVJte9WGCWgsac1jSEBeFd
QHli9cQAsD9iq3ICuioWWVp2sHvptOmnP4z0Q1myT9RVQm9tmsyTWkPYw2sZsYme
ITy+B8VDHagqiFruxW9mj/1gD5+ePf0rILAuX4xHMFbI9vU0WqYRMT0sSLRW7D0k
SEHUP1P4P9ceAehr3ibOF3N1k0IIUhwpPGE7quZ9Z6aesDzNKusi2VABBoHWJm41
VbnwTYIXZ2MOC8F1z+ToXTAtfJw+O7hoIFelTokOL25q4Db7adFVl/VVCBQvbZt4
SeRd6a9cRRgO03rrV40KfhRM1mK5Wk6nSLuDUPvJXZ2ZqRyHrbzL+bAcNN8GGSLJ
+Z7vdNpV8KHm0CdLdOfQty9M/RaeWO+XT81ZbiI+tUJ3egDuArQiUFNxlv5nSQM7
30JV8fYpfuzxlZdonfwlofjYYe7vqaAyhL4I+uWpXO0WOxHk3bAK31uSlKcGwfQ7
IIM4sEwXiNTjmcnFVQQ7eqPmebEjD4JQ8qx8RS4bBsd7diLuzyedgmwjgSYaQuFo
PFWP9z1Uk6uB0/SR8Pf/REEu2H9mrqSNxl1QjZi3LCTKB6m8jxrJhv1KzQe4JTnf
EChnJm7LYXyx1vpuEwyk
=//DT
-END PGP SIGNATURE-


-- 
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/5076ba29.8020...@debian.org

Re: Bug#690183: ITP: apt-fast -- shellscript wrapper for apt-get or aptitude

[Lisandro Damián Nicanor Pérez Meyer]

On Thu 11 Oct 2012 02:55:24 Marco d'Itri escribió:
> On Oct 11, Hideki Yamane  wrote:
> > > apt-fast is a shellscript wrapper for apt-get that can drastically
> > > improve apt download times by downloading packages in parallel, with
> > > multiple connections per package.
> >  
> >  well, isn't it huge load for repository servers?
> 
> As a mirror operator I consider this antisocial.

True.

> As a developer, I doubt that this can provide significant speed
> improvements other than for pathological cases.

Well, parallel download does **greatly** improves speed when you access 
international servers, like we had to do in Argentina until some few weeks 
ago.

Of course, being able to download stuff from two different servers at the same 
time had a better end result, and as long as is one download at a time per 
server, I think it can be considered socially acceptable.

Regards, Lisandro.

-- 
The generation of random numbers is too important to be left to chance.
  http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Bug#690183: ITP: apt-fast -- shellscript wrapper for apt-get or aptitude

[Lisandro Damián Nicanor Pérez Meyer]

On Thu 11 Oct 2012 09:59:35 Lisandro Damián Nicanor Pérez Meyer escribió:
[snip] 
> Well, parallel download does **greatly** improves speed when you access
> international servers, like we had to do in Argentina until some few weeks
> ago.

WRT non i386/amd64 archs.

-- 
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.
  Anonymous

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Scott Kitterman]

On Thursday, October 11, 2012 06:44:53 PM Charles Plessy wrote:
...
>  - I am not found of the voting procedure, and would rather propose to
> follow a similar process as for the modification of the Policy and the
> Developers Reference, where at least three DDs need to indicate that, in
> their conclusion, a consensus has been reached.  I think that if a package
> is orphaned with for instance a 16:3 majority, it indicates a problem
> rather than a consensus.  Also if the maintainer opposes, this shows lack
> of consensus and a vote can only aggravate the situation.
...

I am also concerned with this.  I think it should either be unanimous or there 
is a dispute the tech ctte should resolve.  I don't think we should introduce 
voting on the quality of other DD's package maintenance.

Scott K


-- 
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/7338961.iqtWnx2jL2@scott-latitude-e6320

Bug#690244: ITP: os-autoinst - cross-distribution-capable, fully automated testing framework

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
User: debian-de...@debian.or.jp
Usertags: debianjp
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org, 
debian-de...@debian.or.jp

   Package name: os-autoinst
Version: 1.0.0
Upstream Author: Bernhard M. Wiedemann 
URL: http://gitorious.org/os-autoinst/
License: GPL-2+
 
Description: cross-distribution-capable, fully automated testing framework

 OS-autoinst provides fully automated basic and low-level OS components 
tests
 as bootloader, kernel, installer and upgrade, which can not easily be 
tested
 with other automated testing frameworks.
 .
 However, it can just as well be used to test firefox and openoffice 
operation
 on top of a newly installed OS.
 .
 For detail example, see http://openqa.opensuse.org/


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane
-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20121011231728.e60aad7a5a0a73924c3ef...@debian.or.jp

Re: (seemingly) declinging bug report numbers

[Tollef Fog Heen]

]] Thibaut Paumard 

> Users who get software through the Debian packages are still 100%
> users of said software.

This might be your impression.  It does not at all match my impression.

Quite a few upstreams thinks Debian are working contrary to their design
and their goals and are actively hindering adoption of their software.
If you're interested in examples, just take a look at how rubygems was
handled in Debian until wheezy and all the silliness around node.js and
/usr/bin/node.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87bog9f2mo@xoog.err.no

Re: (seemingly) declinging bug report numbers

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 11/10/2012 17:29, Tollef Fog Heen a écrit :
> ]] Thibaut Paumard
> 
>> Users who get software through the Debian packages are still
>> 100% users of said software.
> 
> This might be your impression.  It does not at all match my
> impression.
> 
> Quite a few upstreams thinks Debian are working contrary to their
> design and their goals and are actively hindering adoption of their
> software. If you're interested in examples, just take a look at how
> rubygems was handled in Debian until wheezy and all the silliness
> around node.js and /usr/bin/node.
> 

Well, upstream may have bad feelings about it, but from my point of
view Debian did the right thing, and by helping realize that "node"
was a poor name choice for an executable, actually helped upstream on
the longer run.

In any case Debian users of node.js are users of node.js (welcome to
the tautology club).

As upstream, one reason I value packaging early my own software under
Debian is precisely that it helps me spot conflicts with unrelated
software.

Kind regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQduwEAAoJEJOUU0jg3ChAjb0QALKqLDnxmJPJ44X+lfHOGWOP
5TK4RUXS6AXodQhtkDQAK1lPdO8ykl7G008I7oG6chyIGy6wE1JrPutXRUSwtMIU
izZmxtamSm494em3Ehvt33wkDoMcHqfw0BaA/GI9/Ww+UedVZncjYZSQkwT6CeQx
OTdm0mb9oXPcsDKR89heRT2d9XZkgI8cUE9HdfKa+UGpQz32qZ28a9roPw+oxfZd
yFsJ2qbUHBvQRRoa768WitmfEZP2tGM6B/pfV+QWI1T3p/MoK8JCBhf/OKr3xk3P
Gi0V1kHIn1ZMSIj98/osvLWZHKUvdXEhIu/0/7khX/V3e7NjhZdyogqAofEz89TG
ydgY9bSrpVbi2fqA1+iUwLmZW2E3wJON+JNJ2dc7e65eJXdaB4cRz9dJxurQLOyo
ELSwH4UqIAHzduLGha7C6M+/j3K1rIENeQt4zb63jAoxO8tkrTAjdrT/6pXUYa/a
Yh3Q8TNR/PfsqwE+VnG97REGhhYBQJ0L2qR8MrDFBVumYMQrS83JCIfPUrJIUEO6
JNrhijV/gAV7eE+hUHdOG0ecZumJJn3ZfyUGH2HA8AOg4dcAvZcnr+BtGBl8Yrj8
qIbXvtpSaNWzrLDnQdwvrpUIA+P8GUja7njDXkVewCoAS6BYqKSJGPOC8rH3CIkv
EyLC44VPNkm4IolSQuWq
=g8ok
-END PGP SIGNATURE-


-- 
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/5076ec04.3000...@debian.org

Re: Bug#690183: ITP: apt-fast -- shellscript wrapper for apt-get or aptitude

[Wouter Verhelst]

On Thu, Oct 11, 2012 at 09:59:35AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Of course, being able to download stuff from two different servers at the 
> same 
> time had a better end result, and as long as is one download at a time per 
> server, I think it can be considered socially acceptable.

Yes, which is why there's

Acquire::Queue-Mode "host";

see apt.conf(5) for the full details on this one. You don't need shell
scripts and things like axel to get this.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
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/20121011162250.gd25...@grep.be

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Peter Samuelson]

[Christoph Anton Mitterer]
> Wouldn't it make sense to start discussions about moving to the
> "strongest" possible?

No.  What makes sense is to use a hash that has the properties that are
needed for a particular application.

To use your example of dpkg file checksums, their purpose has _nothing_
to do with security.  They cannot protect against a malicious attacker,
because an attacker who can corrupt /usr/bin/lsof can also corrupt
/var/lib/dpkg/info/lsof.md5sums.  (And /var cannot be read-only as /usr
sometimes is.)  If you need protection against a malicious attacker,
you need to generate and store your checksums in some other way.[1]

[1] Check out 'apt-cache search tripwire' for various ways to
reinvent that wheel.  tripwire was an early implementation of this
idea, so it is mentioned in other package descriptions.

Rather, the checksums are for integrity checking in the face of disk
corruption or administrative snafu.  Basically to answer the question
"Would it help to reinstall this package?"  MD5 is perfectly well
suited for that.  The presence of the md5sums file in control.tar.gz is
just a convenience so that end systems don't have to calculate it at
install time, much like providing .pyc or .elc files in a .deb (which
we don't do, but we could).

My point is not to pick on your specific example, but to suggest
actually _thinking_ about what a hash is used for, as opposed to the
common knee-jerk reaction "oooh, MD5 is weak, it must be replaced!"
every time someone sees MD5.  (Or SHA-1.)

Peter


-- 
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/20121011163521.gc4...@p12n.org

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote:
> What makes sense is to use a hash that has the properties that are
> needed for a particular application.
Well... I think that's only really required if performance is very
critical, e.g. when you're on embedded devices or so,... but the places
I've mentioned should have probably no disadvantages by using a "strong"
algo,... not to mention that newer algos like Keccack are quite fast.



> To use your example of dpkg file checksums, their purpose has _nothing_
> to do with security.
Well their _intended_ purpose,.. that's right.
But nothing keeps people from using it a security manner (e.g. by
replication it to a "secure" remote node or so) and in fact... e.g.
rkhunter already has a mode where it uses DPKG directly.


>   They cannot protect against a malicious attacker,
> because an attacker who can corrupt /usr/bin/lsof can also corrupt
> /var/lib/dpkg/info/lsof.md5sums.
Yeah see above... if you have "plain" dpkg,... then yes... but people
may impose further measure to secure these sums (replicating them to
other nodes or attaching MACs to these files as XATTRs, etc. pp..)...
this does not necessarily mean that I'd suggest such things (cause
people should rather use AIDE or friends then).


> Rather, the checksums are for integrity checking in the face of disk
> corruption or administrative snafu.  Basically to answer the question
> "Would it help to reinstall this package?"  MD5 is perfectly well
> suited for that.
In principle you're right here,... and I also use it just for that
purpose... but as said above,... we cannot know what people do... and if
dpkg would have generic mechanisms for storing the sums (e.g. all
in /var/lib/dpkg/info/lsof.sums)... nothing would IMHO speak against
using a "stronger" algo per default.


Anyway... I guess it was clear, that I rather meant secure APT... dsc
files, Release.gpg, etc. pp.

> the
> common knee-jerk reaction "oooh, MD5 is weak, it must be replaced!"
> every time someone sees MD5.  (Or SHA-1.)
Well I quite clearly said, that I wouldn't consider especially the later
as broken but experience has shown that such migrations can take
quite some time... and these estimations showed that collisions for even
SHA-1 are not out of the world...


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Martin Bagge / brother]

On 2012-10-11 19:38, Christoph Anton Mitterer wrote:
> On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote:
>> > What makes sense is to use a hash that has the properties that are
>> > needed for a particular application.
> Well... I think that's only really required if performance is very
> critical, e.g. when you're on embedded devices or so,... but the places
> I've mentioned should have probably no disadvantages by using a "strong"
> algo,... not to mention that newer algos like Keccack are quite fast.

Debian on a low power embedded system fits in the "normal" category I
assume?
What is "embedded device" then?

-- 
brother
http://sis.bthstudent.se


-- 
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/50770c0e.3010...@bsnet.se

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Kurt Roeckx]

On Thu, Oct 11, 2012 at 01:19:58AM +0200, Christoph Anton Mitterer wrote:
> Hi folks.
> 
> AFAICS, secure APT and similar things (e.g. dpkg's file hash sums) still
> use even MD5.

dpkg-genchanges and dak both generate md5, sha1 and sha256.  So
.deb files themself are hashed by all 3 of them.  A as far as I
know all tools that verify those files also check all 3 of those
hashes.

As far as I understand, there is no need to move away from sha256
to SHA-3 when it becomes available at this time.

So basicly the question is if we want to keep the md5 and sha1 in
those files or not.

MD5 is covered by policy, and it's the only mentioned in policy,
maybe that should change.

There are also the md5sums files that are stored in the .deb file.
I'm not really sure what the real use case for them is and
wouldn't have a problem with them going away.

Then there dpkg status file keeps track of config files with md5
to see if they changed on upgrade.  I can see no good reason to
change this.

> Wouldn't it make sense to start discussions about moving to the
> "strongest" possible?

I see no reason why we can't also add SHA-3 to the files when the
tools become available.

> Or, like in the case of package files (dsc and friends) make a policy of
> verifying all hashes, and fail if any single doesn't match?

As far that's already the case?



Kurt


-- 
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/20121011181855.ga8...@roeckx.be

Re: (seemingly) declinging bug report numbers

[Steve Langasek]

On Thu, Oct 11, 2012 at 05:29:51PM +0200, Tollef Fog Heen wrote:
> This might be your impression.  It does not at all match my impression.

> Quite a few upstreams thinks Debian are working contrary to their design
> and their goals and are actively hindering adoption of their software.
> If you're interested in examples, just take a look at how rubygems was
> handled in Debian until wheezy and all the silliness around node.js and
> /usr/bin/node.

When, as in the case of node.js, upstream is antisocial and has an
overinflated sense of self-importance, it's perfectly appropriate for Debian
to work contrary to their design.  Our job is not to make upstreams happy,
it's to make our *users* happy; and while being good Free Software citizens
means we try to respect the wishes of upstreams as well, there are
exceptions.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Andrey Rahmatullin]

On Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx wrote:
> There are also the md5sums files that are stored in the .deb file.
> I'm not really sure what the real use case for them is and
> wouldn't have a problem with them going away.
debsums(1) aka "what packages on my system are corrupt by a recent FS
failure"

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: (seemingly) declinging bug report numbers

[Tollef Fog Heen]

]] Steve Langasek 

> On Thu, Oct 11, 2012 at 05:29:51PM +0200, Tollef Fog Heen wrote:
> > This might be your impression.  It does not at all match my impression.
> 
> > Quite a few upstreams thinks Debian are working contrary to their
> > design and their goals and are actively hindering adoption of their
> > software. If you're interested in examples, just take a look at how
> > rubygems was handled in Debian until wheezy and all the silliness
> > around node.js and /usr/bin/node.

(Just to be very clear: I'm reporting what I see other people are
saying. I am not saying I agree with them.)

> When, as in the case of node.js, upstream is antisocial and has an
> overinflated sense of self-importance, it's perfectly appropriate for
> Debian to work contrary to their design.  Our job is not to make
> upstreams happy, it's to make our *users* happy; and while being good
> Free Software citizens means we try to respect the wishes of upstreams
> as well, there are exceptions.

In some cases, making one set of users happy means making another set of
users unhappy, so it always comes down to tradeoffs.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/874nm0g53b@xoog.err.no

Re: (seemingly) declinging bug report numbers

[Simon Josefsson]

Marco Nenciarini  writes:

> Il giorno gio, 11/10/2012 alle 02.46 +0200, Christoph Anton Mitterer ha
> scritto:
>> 
>> On the other hand, some worries are there that this could imply some
>> decline in Debian itself.
>> Well I still think Debian is the best distro out there for most (if not
>> all cases), even though I'd like to see it putting more emphasis on
>> security.
>
> I've seen recently several company I'm working with getting away from
> Debian in favor of Ubuntu because they have a LTS version. However I
> don't know if this is a general trend.

I can confirm the trend for a couple of organisations.  The primary
reason that I identified was the retirement of security support for
Lenny and that Lenny packages are removed from many Debian mirrors which
made it difficult to use Lenny machines.  IMHO, supporting an OS release
for only 3 years is not long enough.

/Simon


-- 
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/87sj9k23nt@latte.josefsson.org

Re: (seemingly) declinging bug report numbers

[Paul Tagliamonte]

On Thu, Oct 11, 2012 at 09:45:58PM +0200, Simon Josefsson wrote:
> Marco Nenciarini  writes:
> 
> > Il giorno gio, 11/10/2012 alle 02.46 +0200, Christoph Anton Mitterer ha
> > scritto:
> >> 
> >> On the other hand, some worries are there that this could imply some
> >> decline in Debian itself.
> >> Well I still think Debian is the best distro out there for most (if not
> >> all cases), even though I'd like to see it putting more emphasis on
> >> security.
> >
> > I've seen recently several company I'm working with getting away from
> > Debian in favor of Ubuntu because they have a LTS version. However I
> > don't know if this is a general trend.
> 
> I can confirm the trend for a couple of organisations.  The primary
> reason that I identified was the retirement of security support for
> Lenny and that Lenny packages are removed from many Debian mirrors which
> made it difficult to use Lenny machines.  IMHO, supporting an OS release
> for only 3 years is not long enough.

FWIW, it should be noted Ubuntu only supports most packages for 3 years
as well. The subset of packages considered for "Server" support is
supported for 5, but most people will suggest you follow the LTS upgrade
path, which is very similar to Debian Stable's.

My 2 cents.

> 
> /Simon
> 
> 
> -- 
> 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/87sj9k23nt@latte.josefsson.org
> 

-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq


signature.asc
Description: Digital signature

Re: (seemingly) declinging bug report numbers

[Benjamin Drung]

Am Donnerstag, den 11.10.2012, 16:14 -0400 schrieb Paul Tagliamonte:
> On Thu, Oct 11, 2012 at 09:45:58PM +0200, Simon Josefsson wrote:
> > Marco Nenciarini  writes:
> > 
> > > Il giorno gio, 11/10/2012 alle 02.46 +0200, Christoph Anton Mitterer ha
> > > scritto:
> > >> 
> > >> On the other hand, some worries are there that this could imply some
> > >> decline in Debian itself.
> > >> Well I still think Debian is the best distro out there for most (if not
> > >> all cases), even though I'd like to see it putting more emphasis on
> > >> security.
> > >
> > > I've seen recently several company I'm working with getting away from
> > > Debian in favor of Ubuntu because they have a LTS version. However I
> > > don't know if this is a general trend.
> > 
> > I can confirm the trend for a couple of organisations.  The primary
> > reason that I identified was the retirement of security support for
> > Lenny and that Lenny packages are removed from many Debian mirrors which
> > made it difficult to use Lenny machines.  IMHO, supporting an OS release
> > for only 3 years is not long enough.
> 
> FWIW, it should be noted Ubuntu only supports most packages for 3 years
> as well. The subset of packages considered for "Server" support is
> supported for 5, but most people will suggest you follow the LTS upgrade
> path, which is very similar to Debian Stable's.

Since Ubuntu 12.04 LTS, the LTS versions are supported for five years on
the desktop, too.

[1] https://wiki.ubuntu.com/LTS

-- 
Benjamin Drung
Debian & Ubuntu Developer


signature.asc
Description: This is a digitally signed message part

Popularity of bzr-builddeb and dh-make

[Benjamin Drung]

Hi,

How popular are bzr-builddeb and dh-make in Debian? The current
situation is that packaging-dev recommends bzr-builddeb and suggests
dh-make. It was requested to drop bzr-builddeb from Recommends and add
dh-make [1]. The recommended packages of packaging-dev should be
recommended by most of the Debian developer and not just by the
maintainer of packaging-dev or one single bug reporter. Therefore I am
asking you: How popular are bzr-builddeb and dh-make? Should they be
recommended or just suggested by packaging-dev?

[1] http://bugs.debian.org/688572

-- 
Benjamin Drung
Debian & Ubuntu Developer


signature.asc
Description: This is a digitally signed message part

Bug#690274: ITP: jampal -- mp3 song library management system and player

[Peter Bennett]

Package: wnpp
Severity: wishlist
Owner: Peter Bennett 

* Package name: jampal
  Version : 02.01.06
  Upstream Author : Peter Bennett 
* URL : http://jampal.sourceforge.net
* License : GPL
  Programming Lang: Java, C++
  Description : mp3 song library management system and player


-- 
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/20121011211151.2869.95953.reportbug@debiantest

Re: Popularity of bzr-builddeb and dh-make

[Matthias Klumpp]

Hi!
Have you considered making a poll for this? Because everyone will tell
you a different oppinion...
For me, I think: bzr-builddeb is specific to Bzr, if you don't use
Bzr, it is useless. Instead, dh_make can be used to generate Debian
templates quickly, so it might be useful for more people, even those
not using Bzr.
I use the Debian Git tools for packaging, I never touched the Bzr
stuff, so I don't need it. I also don't need dh-make often, but it
sometimes is useful.
I can't give any hint, because I am just one developer, but I would
probably prefer dh-make for the reason above.
But if I would need to decide, I would probably suggest both and
recommend none of them :-)
Cheers,
   Matthias

2012/10/11 Benjamin Drung :
> Hi,
>
> How popular are bzr-builddeb and dh-make in Debian? The current
> situation is that packaging-dev recommends bzr-builddeb and suggests
> dh-make. It was requested to drop bzr-builddeb from Recommends and add
> dh-make [1]. The recommended packages of packaging-dev should be
> recommended by most of the Debian developer and not just by the
> maintainer of packaging-dev or one single bug reporter. Therefore I am
> asking you: How popular are bzr-builddeb and dh-make? Should they be
> recommended or just suggested by packaging-dev?
>
> [1] http://bugs.debian.org/688572
>
> --
> Benjamin Drung
> Debian & Ubuntu Developer


-- 
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/caknhny_tdfonxay3elns1jn2e+ofxe03etmrwfsmgxgordm...@mail.gmail.com

Re: Popularity of bzr-builddeb and dh-make

[Benjamin Drung]

A poll is a good idea. Can you recommend a site that allows setting up a
poll?

Am Donnerstag, den 11.10.2012, 23:29 +0200 schrieb Matthias Klumpp:
> Hi!
> Have you considered making a poll for this? Because everyone will tell
> you a different oppinion...
> For me, I think: bzr-builddeb is specific to Bzr, if you don't use
> Bzr, it is useless. Instead, dh_make can be used to generate Debian
> templates quickly, so it might be useful for more people, even those
> not using Bzr.
> I use the Debian Git tools for packaging, I never touched the Bzr
> stuff, so I don't need it. I also don't need dh-make often, but it
> sometimes is useful.
> I can't give any hint, because I am just one developer, but I would
> probably prefer dh-make for the reason above.
> But if I would need to decide, I would probably suggest both and
> recommend none of them :-)
> Cheers,
>Matthias
> 
> 2012/10/11 Benjamin Drung :
> > Hi,
> >
> > How popular are bzr-builddeb and dh-make in Debian? The current
> > situation is that packaging-dev recommends bzr-builddeb and suggests
> > dh-make. It was requested to drop bzr-builddeb from Recommends and add
> > dh-make [1]. The recommended packages of packaging-dev should be
> > recommended by most of the Debian developer and not just by the
> > maintainer of packaging-dev or one single bug reporter. Therefore I am
> > asking you: How popular are bzr-builddeb and dh-make? Should they be
> > recommended or just suggested by packaging-dev?
> >
> > [1] http://bugs.debian.org/688572
> >
> > --
> > Benjamin Drung
> > Debian & Ubuntu Developer


-- 
Benjamin Drung
Debian & Ubuntu Developer


signature.asc
Description: This is a digitally signed message part

Re: (seemingly) declinging bug report numbers

[Russ Allbery]

Simon Josefsson  writes:
> Marco Nenciarini  writes:

>> I've seen recently several company I'm working with getting away from
>> Debian in favor of Ubuntu because they have a LTS version. However I
>> don't know if this is a general trend.

> I can confirm the trend for a couple of organisations.  The primary
> reason that I identified was the retirement of security support for
> Lenny and that Lenny packages are removed from many Debian mirrors which
> made it difficult to use Lenny machines.  IMHO, supporting an OS release
> for only 3 years is not long enough.

I've heard lots of this too, and have seen multiple concrete examples.
However, they all uniformly seem to significantly misunderstand Ubuntu
security support and think that considerably more of the Ubuntu archive is
supported in LTS than is actually the case.

People don't seem to realize that Debian security support is rather more
comprehensive than Ubuntu's is for their LTS release.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87txu0wutz@windlord.stanford.edu

Re: Popularity of bzr-builddeb and dh-make

[Steve Langasek]

Hi Benjamin,

On Thu, Oct 11, 2012 at 10:38:08PM +0200, Benjamin Drung wrote:
> How popular are bzr-builddeb and dh-make in Debian? The current
> situation is that packaging-dev recommends bzr-builddeb and suggests
> dh-make. It was requested to drop bzr-builddeb from Recommends and add
> dh-make [1]. The recommended packages of packaging-dev should be
> recommended by most of the Debian developer and not just by the
> maintainer of packaging-dev or one single bug reporter.

I think this is a failing proposition.  There are as many different
preferences about packaging, to the nearest order of magnitude, as there are
Debian developers.  I'm fine with this package being one maintainer's
recommendations for some packages; I'm not at all ok with it being recast as
a blessed recommendation of the project, as I object to about a third of the
stuff in there.

> Therefore I am asking you: How popular are bzr-builddeb and dh-make? 
> Should they be recommended or just suggested by packaging-dev?

dh-make isn't so relevant now that debhelper 7 exists.  cp
/usr/share/doc/debhelper/examples/rules.tiny debian/rules && dch
--create, manually create debian/control and debian/copyright, and that's
about it.  

bzr is the fourth most popular version control system in Debian according to
.  If you're going to demote
bzr-builddeb (which doesn't bother me), I think you should also be demoting
svn-buildpackage, because svn is horrible and should die.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: (seemingly) declinging bug report numbers

[Vincent Bernat]

 ❦ 11 octobre 2012 20:26 CEST, Steve Langasek  :

>> Quite a few upstreams thinks Debian are working contrary to their design
>> and their goals and are actively hindering adoption of their software.
>> If you're interested in examples, just take a look at how rubygems was
>> handled in Debian until wheezy and all the silliness around node.js and
>> /usr/bin/node.
>
> When, as in the case of node.js, upstream is antisocial and has an
> overinflated sense of self-importance, it's perfectly appropriate for Debian
> to work contrary to their design.

About the first part of the sentence, this is a good way to get a whole
community against us if it becomes publicized. We'll be happy to work
for a distribution that nobody uses because nobody likes us any more.
-- 
printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n");
2.2.16 /usr/src/linux/fs/isofs/inode.c


pgpHzSMsyOtoi.pgp
Description: PGP signature

Re: Popularity of bzr-builddeb and dh-make

[John Paul Adrian Glaubitz]

On Thu, Oct 11, 2012 at 02:38:46PM -0700, Steve Langasek wrote: 
> bzr is the fourth most popular version control system in Debian according to
> .  If you're going to demote
> bzr-builddeb (which doesn't bother me), I think you should also be demoting
> svn-buildpackage, because svn is horrible and should die.

Well, you should also mention the numbers from this site. svn and git
are used about 20 and 40 times respectively more often than bzr for
packaging. Saying that bzr is popular is would be misleading
considering these numbers.

I actually heard of bzr-builddeb for the first time and my impression
always was that most packages using bzr are maintained by Ubuntu
developers.

In any case, the Recommends should be agnostic to the VCS being
used. Recommending dh_make is actually very sensible as it's always a
good start when packaging from scratch. I use it for all my packages
and gives a rough guideline for the packaging work.

Cheers,

Adrian


signature.asc
Description: Digital signature

Re: (seemingly) declinging bug report numbers

[Vincent Bernat]

 ❦ 11 octobre 2012 22:33 CEST, Benjamin Drung  :

>> > I can confirm the trend for a couple of organisations.  The primary
>> > reason that I identified was the retirement of security support for
>> > Lenny and that Lenny packages are removed from many Debian mirrors which
>> > made it difficult to use Lenny machines.  IMHO, supporting an OS release
>> > for only 3 years is not long enough.
>> 
>> FWIW, it should be noted Ubuntu only supports most packages for 3 years
>> as well. The subset of packages considered for "Server" support is
>> supported for 5, but most people will suggest you follow the LTS upgrade
>> path, which is very similar to Debian Stable's.
>
> Since Ubuntu 12.04 LTS, the LTS versions are supported for five years on
> the desktop, too.
>
> [1] https://wiki.ubuntu.com/LTS

 This only applies to "main", right?
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


pgpQ14Bo4x2r8.pgp
Description: PGP signature

Re: Popularity of bzr-builddeb and dh-make

[Benjamin Drung]

Am Donnerstag, den 11.10.2012, 14:38 -0700 schrieb Steve Langasek:
> Hi Benjamin,
> 
> On Thu, Oct 11, 2012 at 10:38:08PM +0200, Benjamin Drung wrote:
> > How popular are bzr-builddeb and dh-make in Debian? The current
> > situation is that packaging-dev recommends bzr-builddeb and suggests
> > dh-make. It was requested to drop bzr-builddeb from Recommends and add
> > dh-make [1]. The recommended packages of packaging-dev should be
> > recommended by most of the Debian developer and not just by the
> > maintainer of packaging-dev or one single bug reporter.
> 
> I think this is a failing proposition.  There are as many different
> preferences about packaging, to the nearest order of magnitude, as there are
> Debian developers.  I'm fine with this package being one maintainer's
> recommendations for some packages; I'm not at all ok with it being recast as
> a blessed recommendation of the project, as I object to about a third of the
> stuff in there.

The main purpose of this package is to help beginners to get ready for
packaging and not making a recommendation statement for the Debian
project. The question is: Will you recommend newcomers to install
packaging-dev to start packaging? Will installing packaging-dev be
enough or will you recommend to install bzr-builddeb or dh-make
afterwards?

> > Therefore I am asking you: How popular are bzr-builddeb and dh-make? 
> > Should they be recommended or just suggested by packaging-dev?
> 
> dh-make isn't so relevant now that debhelper 7 exists.  cp
> /usr/share/doc/debhelper/examples/rules.tiny debian/rules && dch
> --create, manually create debian/control and debian/copyright, and that's
> about it.  

That's my opinion, too.

> bzr is the fourth most popular version control system in Debian according to
> .  If you're going to demote
> bzr-builddeb (which doesn't bother me), I think you should also be demoting
> svn-buildpackage, because svn is horrible and should die.

I agree that Subversion should die, but it is still widely used.

-- 
Benjamin Drung
Debian & Ubuntu Developer


signature.asc
Description: This is a digitally signed message part

Re: (seemingly) declinging bug report numbers

[Benjamin Drung]

Am Freitag, den 12.10.2012, 00:00 +0200 schrieb Vincent Bernat:
> ❦ 11 octobre 2012 22:33 CEST, Benjamin Drung  :
> 
> >> > I can confirm the trend for a couple of organisations.  The primary
> >> > reason that I identified was the retirement of security support for
> >> > Lenny and that Lenny packages are removed from many Debian mirrors which
> >> > made it difficult to use Lenny machines.  IMHO, supporting an OS release
> >> > for only 3 years is not long enough.
> >> 
> >> FWIW, it should be noted Ubuntu only supports most packages for 3 years
> >> as well. The subset of packages considered for "Server" support is
> >> supported for 5, but most people will suggest you follow the LTS upgrade
> >> path, which is very similar to Debian Stable's.
> >
> > Since Ubuntu 12.04 LTS, the LTS versions are supported for five years on
> > the desktop, too.
> >
> > [1] https://wiki.ubuntu.com/LTS
> 
>  This only applies to "main", right?

main + restricted are supported by Canonical. universe + multiverse are
supported by the community (in a best effort manner).

-- 
Benjamin Drung
Debian & Ubuntu Developer


signature.asc
Description: This is a digitally signed message part

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Sam Hartman]

For myself, I'd feel a lot more comfortable with DDs seconding than DMs
seconding.

In my mind, when you sign up to be a DM, you're signing up to do a good
job of maintaining one or more packages.

In my mind a part of the additional commitment in agreeing to be a DD is
to think about the broader issues of the project, for example, the
social implications of your decision, to try and help build Debian as a
community and team.
I think that broader view is important when doing something that is
likely to have social consequences like an ITO.

So, I would prefer DD seconds to DM seconds.


-- 
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/013a51e8b51f-2190865a-4871-43ec-a362-56efe361e561-000...@email.amazonses.com

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Kurt Roeckx]

On Fri, Oct 12, 2012 at 12:42:57AM +0600, Andrey Rahmatullin wrote:
> On Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx wrote:
> > There are also the md5sums files that are stored in the .deb file.
> > I'm not really sure what the real use case for them is and
> > wouldn't have a problem with them going away.
> debsums(1) aka "what packages on my system are corrupt by a recent FS
> failure"

I know about debsums, I just don't find it useful.

For the case of corruption I would either use backups or
reinstall the whole thing.  If there is corruption it
ussually screws up more than the files covered by the md5sums.


Kurt


-- 
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/20121011223542.ga20...@roeckx.be

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Charles Plessy]

Le Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx a écrit :
> 
> MD5 is covered by policy, and it's the only mentioned in policy,
> maybe that should change.

Hi Kurt and everybody,

For control files, Checksums-Sha1 and Checksums-Sha256 are covered in chapter
5, where they are marked as recommended.

-
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums

  These multiline fields contain a list of files with a checksum and size for
  each one. Both Checksums-Sha1 and Checksums-Sha256 have the same syntax and
  differ only in the checksum algorithm used: SHA-1 for Checksums-Sha1 and
  SHA-256 for Checksums-Sha256.
  
  Checksums-Sha1 and Checksums-Sha256 are multiline fields. The first line of
  the field value (the part on the same line as Checksums-Sha1: or
  Checksums-Sha256:) is always empty. The content of the field is expressed as
  continuation lines, one line per file. Each line consists of the checksum, a
  space, the file size, a space, and the file name. For example (from a .changes
  file):

 Checksums-Sha1:
  1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc
  a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz
  5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz
  71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb
 Checksums-Sha256:
  ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 
example_1.0-1.dsc
  0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 
example_1.0.orig.tar.gz
  f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 
example_1.0-1.debian.tar.gz
  3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 
example_1.0-1_i386.deb

  In the .dsc file, these fields should list all files that make up the source
  package. In the .changes file, these fields should list all files being
  uploaded. The list of files in these fields must match the list of files in 
the
  Files field.
-

For MD5, it is only mentionned in the description of the Files field (same
chapter), in appendix D about other control fields (MD5sum), and in appendix E
about configuration file handling.

Please let us know if there is something else missing about SHA-1 or SHA-256
checksums.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20121011224310.ga12...@falafel.plessy.net

Re: (seemingly) declinging bug report numbers

[Steve Langasek]

On Thu, Oct 11, 2012 at 11:57:24PM +0200, Vincent Bernat wrote:
>  ❦ 11 octobre 2012 20:26 CEST, Steve Langasek  :

> >> Quite a few upstreams thinks Debian are working contrary to their design
> >> and their goals and are actively hindering adoption of their software.
> >> If you're interested in examples, just take a look at how rubygems was
> >> handled in Debian until wheezy and all the silliness around node.js and
> >> /usr/bin/node.

> > When, as in the case of node.js, upstream is antisocial and has an
> > overinflated sense of self-importance, it's perfectly appropriate for Debian
> > to work contrary to their design.

> About the first part of the sentence, this is a good way to get a whole
> community against us if it becomes publicized. We'll be happy to work
> for a distribution that nobody uses because nobody likes us any more.

I have no problem with the above statement being publicized.  The rude
behavior of node.js upstream in regard to their namespace handling is
already well known.  I'm not going to meekly pretend that their behavior is
ok for fear of angering whatever the node.js equivalent of the Slashdot
crowd is.  The TC resolution carefully balanced the needs of both sets of
users, but as for node.js upstream, they receive my full scorn for their
role in this as namespace hijackers.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Popularity of bzr-builddeb and dh-make

[Steve Langasek]

On Thu, Oct 11, 2012 at 11:57:55PM +0200, John Paul Adrian Glaubitz wrote:
> On Thu, Oct 11, 2012 at 02:38:46PM -0700, Steve Langasek wrote: 
> > bzr is the fourth most popular version control system in Debian according to
> > .  If you're going to demote
> > bzr-builddeb (which doesn't bother me), I think you should also be demoting
> > svn-buildpackage, because svn is horrible and should die.

> Well, you should also mention the numbers from this site. svn and git
> are used about 20 and 40 times respectively more often than bzr for
> packaging. Saying that bzr is popular is would be misleading
> considering these numbers.

I didn't say it was popular, I said it was the fourth most popular.

Being agnostic to the VCS being used fails in the stated purpose of making
this package useful to new packagers.  New packagers should be strongly
steered away from using subversion.  I don't care if bzr-builddeb gets
demoted; I care that new packagers are not encouraged to use subversion over
bzr solely because subversion is more popular.  The popularity of subversion
for packaging is a measure of inertia and/or ignorance, not of the
appropriateness of the tool.

bzr (especially with bzr-builddeb) is the best tool for the job, but I know
not everyone shares that opinion.  git is a tolerable second.  svn should be
taken out and shot.

> Recommending dh_make is actually very sensible as it's always a
> good start when packaging from scratch. I use it for all my packages
> and gives a rough guideline for the packaging work.

I find the .ex files that it generates in debian/ to be a major distraction
nowadays, and greatly prefer to build the package up by hand.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

On Thu, 2012-10-11 at 20:18 +0200, Kurt Roeckx wrote:
> dpkg-genchanges and dak both generate md5, sha1 and sha256.  So
> .deb files themself are hashed by all 3 of them.  A as far as I
> know all tools that verify those files also check all 3 of those
> hashes.
Ah? Ok... I somehow had in mind that a) generating the "stronger" ones
was just optional,... and that they were not yet everywhere verified.


> So basicly the question is if we want to keep the md5 and sha1 in
> those files or not.
Probably... and nothing speaks against adding sha512... or (once it has
been well introduced) Keccack.


> MD5 is covered by policy
:-/


> , and it's the only mentioned in policy,
> maybe that should change.
Guess so.


> There are also the md5sums files that are stored in the .deb file.
> I'm not really sure what the real use case for them is and
> wouldn't have a problem with them going away.
Well these are the ones for dpkg, aren't they?
Where it was mentioned before, that they are not primarily intended for
security (but where I replied, nothing keeps users from using them for
this purpose).


> I see no reason why we can't also add SHA-3 to the files when the
> tools become available.
:)


I further looked around:
e.g. the Release file seems to only use MD5 not so good :(



Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to
have a "special status" (Files vs. Checksums-).
That might be just historic, though.

Similarly the Packages files... MD5/SHA1/SHA256...

If they are all checked (and verification is considered to be failed if
a single one doesn't match)... then I guess I'm quite happy. Though I
would still think, that on a mid-/long-term-range it doesn't harm to
drop MD5/SHA1 e.g. in favour of SHA512/Keccack.



> > Or, like in the case of package files (dsc and friends) make a policy of
> > verifying all hashes, and fail if any single doesn't match?
> As far that's already the case?
That would be good :)



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Work-needing packages report for Oct 12, 2012

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 471 (new: 2)
Total number of packages offered up for adoption: 136 (new: 1)
Total number of packages requested help for: 65 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   lockout (#690140), orphaned yesterday
 Description: A self-imposed discipline and productivity enforcer
 Installations reported by Popcon: 9

   sysfsutils (#689879), orphaned 4 days ago
 Description: interface library to sysfs
 Installations reported by Popcon: 71800

469 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   pmount (#689854), offered 4 days ago
 Description: mount removable devices as normal user
 Installations reported by Popcon: 9289

135 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 983 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 58266

   asymptote (#517342), requested 1322 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3315

   athcool (#278442), requested 2907 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 73

   balsa (#642906), requested 382 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 266

   bastille (#592137), requested 796 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 202

   boinc (#511243), requested 1372 days ago
 Description: BOINC distributed computing
 Installations reported by Popcon: 1682

   cardstories (#624100), requested 535 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7

   chromium-browser (#583826), requested 865 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10677

   debtags (#567954), requested 983 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2497

   doc-central (#566364), requested 992 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 202

   elvis (#432298), requested 1921 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 381

   fbcat (#565156), requested 1002 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 142

   flightgear (#487388), requested 1573 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 820

   freeipmi (#628062), requested 504 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1905

   gnat-4.4 (#539633), requested 1640 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1630

   gnat-gps (#496905), requested 1505 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 421

   gnokii (#677750), requested 117 days ago
 Description: Datasuite for mobile phone management
 Installations reported by Popcon: 2389

   gnupg (#660685), requested 234 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 126577

   golang (#668870), requested 179 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 324

   gpa (#663405), requested 215 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 508

   gradle (#683666), requested 70 days ago
 Description: Groovy based build system
 Installations reported by Popcon: 24

   grub2 (#248397), requested 3076 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 117602

   hfsprogs (#557892), requested 1051 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1230

   horde4 (#686007), requested 45 days ago
 Description: web-based groupware and other applications

   hotkey-setup (#483107), requested 1598 days ago
 Description: auto-

Re: (seemingly) declinging bug report numbers

[Paul Wise]

On Fri, Oct 12, 2012 at 3:45 AM, Simon Josefsson wrote:

> I can confirm the trend for a couple of organisations.  The primary
> reason that I identified was the retirement of security support for
> Lenny and that Lenny packages are removed from many Debian mirrors which
> made it difficult to use Lenny machines.  IMHO, supporting an OS release
> for only 3 years is not long enough.

We don't have enough human power to fix all the RC bugs that crop up
in stable during its lifetime, I doubt maintainers are ever going to
want or be able to support oldstable for longer than we do already.

http://bugs.debian.org/release-critical/

As far as support for oldstable on security issues goes, you might
want to take a look at these pages:

http://wiki.debian.org/DebianSecurity/Meetings/2011-01-14
http://lists.debian.org/debian-devel-announce/2011/01/msg6.html
http://lists.debian.org/debian-security/2011/10/msg00029.html
http://lists.debian.org/debian-security/2011/10/msg00030.html
http://lists.debian.org/debian-security/2011/10/msg00033.html
http://lists.debian.org/debian-security/2011/10/threads.html#1

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6FBbk8smMq0=vGVmU0cpy_8gF0OmsM-15N1VyXaR==-v...@mail.gmail.com

Re: Popularity of bzr-builddeb and dh-make

[Paul Wise]

On Fri, Oct 12, 2012 at 5:35 AM, Benjamin Drung wrote:

> A poll is a good idea. Can you recommend a site that allows setting up a
> poll?

The Debian secretary was at one point going to setup devotee for this
sort of thing, don't think that ever happened though.

If you want some FSAAS (free-software-as-a-service), search for doodle
on this page:

https://wiki.debian.org/FreedomBox/LeavingTheCloud

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6fupbby+1sucgqjjk7nqbyfmo8y5zmocjvbuzdy8ad...@mail.gmail.com

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Bob Proulx]

Kurt Roeckx wrote:
> Andrey Rahmatullin wrote:
> > Kurt Roeckx wrote:
> > > There are also the md5sums files that are stored in the .deb file.
> > > I'm not really sure what the real use case for them is and
> > > wouldn't have a problem with them going away.
> > debsums(1) aka "what packages on my system are corrupt by a recent FS
> > failure"
> 
> I know about debsums, I just don't find it useful.
> 
> For the case of corruption I would either use backups or
> reinstall the whole thing.  If there is corruption it
> ussually screws up more than the files covered by the md5sums.

The use case for debsums is for *detection* of corruption.  And
neither is it a security mechanism.  But it is a useful integrity
check mechanism.

Bob


signature.asc
Description: Digital signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Paul Wise]

On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote:

> I further looked around:
> e.g. the Release file seems to only use MD5 not so good :(

Wrong, the Release file has had all 3 since sarge. woody had MD5 & SHA-1.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6f-37fuhwcgfnxmu-md-qutora6mwjewxhrzfuehg7...@mail.gmail.com

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Paul Wise]

On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote:

> Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to
> have a "special status" (Files vs. Checksums-).
> That might be just historic, though.
>
> Similarly the Packages files... MD5/SHA1/SHA256...

Only since wheezy has that been true for all files listed in
Packages/Sources though. squeeze Packages is missing SHA-1 and SHA-256
for 1905 binary packages.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6EHRFK2Qj7H7A4=UF3SqnroEMeAd4xA=Pfzum8=a7s...@mail.gmail.com

Re: Popularity of bzr-builddeb and dh-make

[Craig Small]

On Thu, Oct 11, 2012 at 02:38:46PM -0700, Steve Langasek wrote:
> dh-make isn't so relevant now that debhelper 7 exists.  cp
> /usr/share/doc/debhelper/examples/rules.tiny debian/rules && dch
> --create, manually create debian/control and debian/copyright, and that's
> about it.  
dh-make comes from the era when deb-make (anyone remember that) was
around which, I think, was before debhelper was around.  It was
basically written to fix a "problem" which was bad templates getting
into the Debian archive.

debhelper has gotten smarter with every release and gradually what
dh-make has had to do is getting reduced.  I'm not sure we're at the
point of removing dh-make (it's an open question; I'm really not sure)
but perhaps we will be there one day.  As it was written to solve a
problem, if the problem goes then we won't need it.

Steve with his years of packaging experience is not probably a good
sample of one to base this upon. I'd be curious to see if newer
packagers use it or not.

As far as what packaging-dev recommends or suggests, I've never used it
so don't really care either way.  I am curious why a specific tool is
recommended over a generic one (I don't use bzr anywhere so it would be
useless for me).

 - Craig
-- 
Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


-- 
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/20121012050353.ga26...@enc.com.au

Re: Popularity of bzr-builddeb and dh-make

[Raphael Hertzog]

On Fri, 12 Oct 2012, Craig Small wrote:
> Steve with his years of packaging experience is not probably a good
> sample of one to base this upon. I'd be curious to see if newer
> packagers use it or not.

I still use dh-make from time to time. Mainly to get a template for
debian/control and debian/copyright. It tend to be annoyed by the *.ex and
*.EX files though (IMO it would be better to have a debian/TODO listing
all the stuff that one should consider adding to the package with
appropriate pointers to the documentation).

In any case, I think it's a good idea to list dh-make in packaging-dev's
Recommends.

I have no opinion on bzr-builddeb.

> As far as what packaging-dev recommends or suggests, I've never used it
> so don't really care either way.  I am curious why a specific tool is
> recommended over a generic one (I don't use bzr anywhere so it would be
> useless for me).

The idea is that you get all the tools required to contribute to most of
the packaging teams in Debian.

It's not about endorsing a specific workflow.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20121012065035.gb12...@x230-buxy.home.ouaza.com