Re: Wanted: system/volunteer to do whole-archive rebuild (×3) to test sbuild

[Roger Leigh]

On Mon, Feb 14, 2011 at 11:36:55PM +, Roger Leigh wrote:
> sbuild, which does the job of building binary packages on our buildds,
> uses a built-in build-dependency resolver ("internal") to work out
> what packages need installing/removing in order to satisfy a package's
> Build-Depends and Build-Conflicts.  Unfortunately, this has a number
> of bugs, e.g. #403246, as well as serious maintainability issues which
> make it less than desirable.  Last year, we introduced two new
> resolvers, "apt" and "aptitude" which delegate the somewhat complex
> build dependency resolving to the tools which are best at it.
> 
> Now that squeeze is out, it would be great if we could revisit the
> discussion about which build dependency resolver we want to use on
> our buildds.  The main concern here is that switching resolvers will
> change exactly which packages are installed in some situations, mainly
> in the case of packages depending on alternatives, which could lead to
> different packages being installed, inconsistent selection of packages
> being installed, or broken package builds.  The intenal resolver was
> dumb: it just always chose the first dependency even if it was
> unsatisfiable.  aptitude is far cleverer; apt somewhere in between,
> though we've tweaked aptitude to behave as close to stupid as we can.

The results of this are below.  Many thanks to Tollef Fog Heen for
his kind donation of time on one of his big machines to run three
archive rebuilds.  A better quality PDF version is attached.

Due to the size limits of the lists, the full version is at
http://people.debian.org/~rleigh/squeeze-rebuild/report.pdf

Regards,
Roger


sbuild Build Dependency Resolver Comparison


1.  Introduction

 sbuild  has three different build dependency resolvers,
internal, apt  and  aptitude.   The  historical  default  is
internal, while apt and aptitude are much newer.  The inter‐
nal resolver  is  a  build‐dependency  resolver  implemented
directly  in  Perl,  and  which has a number of deficiencies
mainly relating to newer additions to the dependency format,
and  also  in  resolving  of  complex  versioned and virtual
dependencies.   The  apt  and  aptitude  resolvers  delegate
almost  all  dependency  resolution  to the apt and aptitude
tools, whose dependency resolution is far more  capable  and
better  tested.   However,  the  strict, simple, predictable
dependency resolution provided by internal must also be pro‐
vided  by  the alternative resolvers in order for them to be
suitable for use on our build dæmons.

 A goal for the wheezy release is to replace the  inter‐
nal  resolver  with  one  of  the apt or aptitude resolvers.
However, we had no hard information upon  which  to  base  a
decision.  I have consequently rebuilt the entire Debian ar‐
chive three times  using  the  internal,  apt  and  aptitude
resolvers,  using  the squeeze release since it’s stable and
unchanging between the runs.  The build logs have been  pro‐
cessed  and  the  build  status  and  dependency information
inserted into a PostgreSQL database in order to allow direct
comparison of the behaviour of the three resolvers.

 These tests all used the current version of sbuild from
unstable (0.60.9‐1), with a one line patch to  the  aptitude
resolver  to  make it use the same dpkg options as the other
resolvers when installing packages.  The  internal  resolver
has  a  bugfix the version on the buildds does not yet have,
allowing it to delegate  virtual  dependency  resolution  to
apt‐get  rather than failing outright (since older versions’
handling of virtual packages was completely broken).

 Many thanks to Tollef Fog Heen and freedesktop.org  for
the use of a big machine on which to do the builds.  This 24
core beast was able to rebuild  the  entire  archive  in  14
hours, taking four days in total for the three builds.

 The  build  logs, database schema and database dump are
all available  at  http://people.debian.org/~rleigh/squeeze‐
rebuild/.


2.  Build summary

 These are the summary statistics for all the builds:


   ┌─┬┬──┬───┐
   │Resolver │ Status │ Fail stage   │ Count │
   ├─┼┼──┼───┤
   │apt  │ attempted  │ build│38 │
   │apt  │ given‐back │ install‐deps │ 5 │
   │apt  │ skipped│ arch‐check   │  6195 │
   │apt  │ successful │  │  8372 │
   ├─┼┼──┼───┤
   │aptitude │ attempted  │ build│41 │
   │aptitude │ skipped│ arch‐check   │  6195 │
   │aptitude │ successful │  │  8374 │
   ├─┼┼──┼───┤
   │internal │ attempted  │ build│37 │
   │internal │ given‐back │ install‐deps │16 │
   │internal │ skipped│ arch‐check   │  6195 │
   │internal │ successful │  │  8362 │
   └─┴

Re: Wanted: maintainer for git's emacs support

[Rémi Vanicat]

David Bremner  writes:

> On Fri, 18 Feb 2011 21:18:38 -0600, Jonathan Nieder  
> wrote:
>
>> None of the current Debian git maintainers seem to use emacs.  This
>> means git's emacs support[1] does not get as much care as it deserves:
>> see for example bugs #611936, #611931, #611932, #611933, #611934,
>> #577834, and #611935.
>
> FWIW, if I was going to put energy into something related to git and
> emacs, it would be into magit [1], which I use daily, and which is also
> pretty out of date in Debian.

If there should be a change in maintenance of magit, I would be very
interested because I'm one of the main upstream developer. 

About the .el of the git package, I might look at it this week, but I'm
not sure if I want to take responsibilities for them as I don't use
them. 


-- 
Rémi Vanicat


-- 
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/877hctr0ya@debian.org

Re: chromium-browser is taking over all URLs

[Norbert Preining]

On Fr, 18 Feb 2011, Daniel Leidert wrote:
> > [Added Associations]
> > x-scheme-handler/http=iceweasel.desktop;
> > x-scheme-handler/https=iceweasel.desktop;
> 
> into $HOME/.local/share/applications/mimeapps.list.


YEAHHH!!! Finally someone who stepped forward and *explained* what to
do instead of lazying around and ignoring complains.

BIG BIG THANKS:

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

BERKHAMSTED
The massive three-course midmorning blow-out enjoyed by a dieter who
has already done his or her slimming duty by having a teaspoonful of
cottage cheese for breakfast.
--- Douglas Adams, The Meaning of Liff


-- 
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/20110221134426.gc26...@gamma.logic.tuwien.ac.at

Re: Release file changes

[Joey Hess]

Joerg Jaspert wrote:
> until today our Release files included 3 Hashes for all their entries:
> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
> MD5SUM in *all* newly generated Release files.

When will that affect Release files for stable? Next point release?
Because that unfortunatly completly breaks debmirror..

Also, I'll see about getting d-i generating some stronger checksum files
now that it's been pointed out. Although I wonder if it would make more
sense to generate those checksums on the server side.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Release file changes

[brian m. carlson]

On Sun, Feb 20, 2011 at 07:03:11PM +0100, Joerg Jaspert wrote:
> I additionally opened a bug with apt to add support for SHA512SUM, so
> we can start using them. As soon as that is possible I intend to drop
> SHA256 and end up with SHA1/SHA512 only.

Unfortunately, the algorithm used for the GnuPG signatures (both in
InRelease and Release.gpg) is SHA-1.  Removing SHA-256 in favor of
SHA-512 does not increase security because the signatures are the
weakest point.  See #612657 for more details.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#614388: ITP: stardict-german-czech -- Stardict package for German-Czech dictionary

[Michal Čihař]

Package: wnpp
Severity: wishlist
Owner: "Michal Čihař" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: stardict-german-czech
  Version : 20110201
  Upstream Author : many contributors
* URL : http://cihar.com/software/slovnik
* License : GNU FDL
  Programming Lang: none (data)
  Description : Stardict package for German-Czech dictionary

This is a package of the GNU/FDL German-Czech dictionary
for Stardict.

It contains also automatically generated dictionary for reverse
direction.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJNYpJMAAoJEGo39bHX+xdNlXcQAMdvRTTHIC/fFX75bkNlmVqp
DgcqjBGAXKuBD3vbldY0uB9xk1iv1nRQcm5kl3a2B7GWG5SB/anilSf7S1iRTCLW
uebti/ZBSfFi6c7Mvw1Vh6S09Ha2jjun/+llbXDlSor8EUmzLu9oa3RDST15O7W3
NjFs/P2VkC/IIW4Ypt/+OcGq+mkWr1bur8qksvZEZOyIY6Nd3LhytSpG7gd7fxeZ
RB8BdrMmrTr0txFfvkrKcrTR0zCDUsqR3JLpT+2PELxlKfTF9EzA50Ol7za5nbNG
sgNYqRxTb1A+Taz8+H59yRTbu4zdLmRphACDXT6GG97jKYMO4M0EqkMnd3i2qkxg
k/RzMXsR0dzqSV9V44MhcOe+xNcAx7zik7OIu42GYqTdnlB+3TcRXySZ4xZfUGyz
LT8znQQo6pPG280rlATrVnu/05ieJnfvl0jSf2KEU1dZKXp7i+0GYYJoI5DArpX4
kNNoJCa+bapLHcaQL0jWiUaiQ+JHvneo8gKZIXxv4jOJAS+q1ZsvhwLgJ64SwN0R
G3uoKd9UUUtPYHjk8ARd2zA3GFzi9yZpH7UnIs1elpe0exHebQVnaHEI5zMyGtyR
syuYexOEvAgSJ+9dyOM8FWO//3Jx27ldYFWBrrGk6OmCn/Mllye9ogNk6vtgsUSz
ntaruKIzm65IJ/mKX2Xl
=Afal
-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/20110221162652.3372.62214.report...@rincewind.suse.cz

Re: Release file changes

[Philipp Kern]

On 2011-02-21, Joey Hess  wrote:
> Joerg Jaspert wrote:
>> until today our Release files included 3 Hashes for all their entries:
>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>> MD5SUM in *all* newly generated Release files.
> When will that affect Release files for stable? Next point release?
> Because that unfortunatly completly breaks debmirror..

It did suddenly change for squeeze-updates without consultation with the
suite admins.  I expect that this is reverted.

The SRMs will not allow this change to affect oldstable's or stable's
Release files at point release time.  (Lucky enough they cannot be
changed without invalidating the signatures.)

Kind regards
Philipp Kern


-- 
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/slrnim55tg.9gd.tr...@kelgar.0x539.de

Bug#614392: ITP: libpoe-component-resolver-perl -- POE Component for domain name resolution

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libpoe-component-resolver-perl
  Version : 0.910
  Upstream Author : Rocco Caputo 
* URL : http://search.cpan.org/dist/POE-Component-Resolver/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : POE Component for domain name resolution

POE::Component::Resolver is a Perl module that provides nonblocking domain
name resolution by using Socket::GetAddrInfo's getaddrinfo() function in
subprocesses where they are permitted to block indefinitely.

By default, it will use a maximum of eight subprocesses and prefer address
families in whatever order Socket::GetAddrInfo returns them. These defaults
can be overridden with constructor parameters.

NOTES: this package is needed for the upgrade of
libpoe-component-client-keepalive-perl, which is needed for an upgrade
of libpoe-component-client-http-perl



-- 
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/aanlktincn_htcgy7ibxhoz-yw8wrqkhj7dy0h8rq1...@mail.gmail.com

Re: Release file changes

[Florian Weimer]

* Joerg Jaspert:

> I additionally opened a bug with apt to add support for SHA512SUM, so
> we can start using them. As soon as that is possible I intend to drop
> SHA256 and end up with SHA1/SHA512 only.

Please don't.  I have more faith in SHA-256 than SHA-512.


-- 
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/8762sdff26@mid.deneb.enyo.de

Re: Release file changes

[Michael Gilbert]

On Mon, 21 Feb 2011 18:55:13 +0100, Florian Weimer wrote:
> * Joerg Jaspert:
> 
> > I additionally opened a bug with apt to add support for SHA512SUM, so
> > we can start using them. As soon as that is possible I intend to drop
> > SHA256 and end up with SHA1/SHA512 only.
> 
> Please don't.  I have more faith in SHA-256 than SHA-512.

What indications are there that SHA-512 is weak?

Best wishes,
Mike


-- 
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/20110221130502.dfb4c885.michael.s.gilb...@gmail.com

Re: Release file changes

[The Fungi]

On Mon, Feb 21, 2011 at 01:05:02PM -0500, Michael Gilbert wrote:
> What indications are there that SHA-512 is weak?

It might be worth approaching from a pragmatic perspective... why
generate SHA-512 checksums when you're only going to be signing a
SHA-256 digest of that list (that is unless you want to alienate
users of OpenPGP-compliant tools which don't implement optional
algorithms). Is it because you feel SHA-512 is more
tamper-resistant, or because you're worried that you might wind up
with two entries accidentally colliding over the same SHA-256 hash
(which is pretty unlikely statistically speaking, and even then may
not be particularly relevant depending on the use case for the
hashes).
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110221192243.gk1...@yuggoth.org

Re: Release file changes

[Joerg Jaspert]

>>> until today our Release files included 3 Hashes for all their entries:
>>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>>> MD5SUM in *all* newly generated Release files.
>> When will that affect Release files for stable? Next point release?
>> Because that unfortunatly completly breaks debmirror..
> It did suddenly change for squeeze-updates without consultation with the
> suite admins.  I expect that this is reverted.

Good laugh that is.

-- 
bye, Joerg
Lisa, you’re a Buddhist, so you believe in reincarnation. Eventually,
Snowball will be reborn as a higher life form… like a snowman.


--
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/87y659tb18@gkar.ganneff.de

Re: Release file changes

[Joerg Jaspert]

On 12398 March 1977, Joey Hess wrote:

>> until today our Release files included 3 Hashes for all their entries:
>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>> MD5SUM in *all* newly generated Release files.
> When will that affect Release files for stable? Next point release?
> Because that unfortunatly completly breaks debmirror..

Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
tools that can't deal with this. The latter two are serious enough to
keep the change away from oldstable forever, and stable at least until
after next point release, should they get updated there.

> Also, I'll see about getting d-i generating some stronger checksum files
> now that it's been pointed out. Although I wonder if it would make more
> sense to generate those checksums on the server side.

Well, the files currently come from the d-i builds. Makes sense, it
shows what the build host expects them to be, not what a *possible*
corruption during transport to us and unpack made them. How likely such
a corruption is is a different topic, but the theoretical possibility is
there. And we ARE using the MD5SUMS file when we accept the d-i tarballs
to check if it actually matches, so I think we should keep that.

Please ping me when you start providing additional checksum files (if
possible before the debian-installer-images upload, so I can have the
byhand and release file generation script adjusted).

-- 
bye, Joerg
I'm having the best day of my life, and I owe it all to not going to Church!


-- 
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/87tyfxtap3@gkar.ganneff.de

Re: Release file changes

[Joerg Jaspert]

>> I additionally opened a bug with apt to add support for SHA512SUM, so
>> we can start using them. As soon as that is possible I intend to drop
>> SHA256 and end up with SHA1/SHA512 only.
> Unfortunately, the algorithm used for the GnuPG signatures (both in
> InRelease and Release.gpg) is SHA-1.  Removing SHA-256 in favor of
> SHA-512 does not increase security because the signatures are the
> weakest point.  See #612657 for more details.

Well, a slightly different point then reducing yourself to just 2
hashes, but yes, we should look to change that part too.


-- 
bye, Joerg
Son, when you participate in sporting events, it's not whether you win
or lose: it's how drunk you 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/87pqqltaid@gkar.ganneff.de

Re: Release file changes

[Joerg Jaspert]

>> I additionally opened a bug with apt to add support for SHA512SUM, so
>> we can start using them. As soon as that is possible I intend to drop
>> SHA256 and end up with SHA1/SHA512 only.
> Please don't.  I have more faith in SHA-256 than SHA-512.

Uhh, fine - why?

-- 
bye, Joerg
Well, it's 1 a.m. Better go home and spend some quality time with the kids.


-- 
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/87fwrhtadq@gkar.ganneff.de

Re: Release file changes

[Joerg Jaspert]

> It might be worth approaching from a pragmatic perspective... why
> generate SHA-512 checksums when you're only going to be signing a
> SHA-256 digest of that list (that is unless you want to alienate
> users of OpenPGP-compliant tools which don't implement optional
> algorithms). Is it because you feel SHA-512 is more
> tamper-resistant, or because you're worried that you might wind up
> with two entries accidentally colliding over the same SHA-256 hash
> (which is pretty unlikely statistically speaking, and even then may
> not be particularly relevant depending on the use case for the
> hashes).

Care to make a point for the gpg stuff around it within bug #612657? 

-- 
bye, Joerg
 sind jabber und icq 2 unterschiedliche netzwerke ?


-- 
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/87bp25tabk@gkar.ganneff.de

Re: Release file changes

[Philipp Kern]

On 2011-02-21, Joerg Jaspert  wrote:
 until today our Release files included 3 Hashes for all their entries:
 MD5SUM, SHA1, SHA256. I just modified the code to no longer include
 MD5SUM in *all* newly generated Release files.
>>> When will that affect Release files for stable? Next point release?
>>> Because that unfortunatly completly breaks debmirror..
>> It did suddenly change for squeeze-updates without consultation with the
>> suite admins.  I expect that this is reverted.
> Good laugh that is.

Seriously?  Child's play with productive stable suites, breaking tools in the
process and then not fixing it up?  And no, just telling people to update their
tools in stable is not the way to go here.

Kind regards
Philipp Kern


-- 
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/slrnim5hrp.9ov.tr...@kelgar.0x539.de

Re: Release file changes

[Adam D. Barratt]

On Mon, 2011-02-21 at 20:58 +0100, Joerg Jaspert wrote:
> >>> until today our Release files included 3 Hashes for all their entries:
> >>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
> >>> MD5SUM in *all* newly generated Release files.
> >> When will that affect Release files for stable? Next point release?
> >> Because that unfortunatly completly breaks debmirror..
> > It did suddenly change for squeeze-updates without consultation with the
> > suite admins.  I expect that this is reverted.
> 
> Good laugh that is.

In any case, it would seem logical for squeeze and squeeze-updates to
use the same set of hashes, imho; similarly the -proposed-updates
suites.  Each of the "sister" suites would generally be expected to be
consumed (for want of a better word) by the tools in the corresponding
(old)stable suite.

Regards,

Adam


-- 
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/1298319528.14573.225.ca...@hathi.jungle.funky-badger.org

Re: Release file changes

[Florian Weimer]

* Joerg Jaspert:

>>> I additionally opened a bug with apt to add support for SHA512SUM, so
>>> we can start using them. As soon as that is possible I intend to drop
>>> SHA256 and end up with SHA1/SHA512 only.
>> Please don't.  I have more faith in SHA-256 than SHA-512.
>
> Uhh, fine - why?

I think this question is a bit rude if faith is involved, but here we
go: the number of rounds in SHA-512 is rather small, considering its
block size and internal state space, in particular in comparison with
SHA-256.

More practically speaking, SHA-512 would add about 450 kB of
incompressible junk to the Packages file, so we probably want to stick
to SHA-256 there.  But using different hashes in Release and Packages
files is just bloat.


-- 
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/87pqql9lla@mid.deneb.enyo.de

Re: Release file changes

[The Fungi]

On Mon, Feb 21, 2011 at 09:13:51PM +0100, Joerg Jaspert wrote:
> Care to make a point for the gpg stuff around it within bug
> #612657?

Gladly! Restating and Cc'ing...

While I agree that moving away from SHA-1 is necessary, SHA-512 is
not part of the compatibility set according to the gpg(1) manpage
and so may be hard for users of other OpenPGP implementations to
validate:

[...]
> > INTEROPERABILITY
> > 
> > GnuPG tries to be a very flexible implementation of the OpenPGP
> > standard. In particular, GnuPG implements many of the optional
> > parts of the standard, such as the SHA-512 hash, and the ZLIB
> > and BZIP2 compression algorithms. It is important to be aware
> > that not all OpenPGP programs implement these optional
> > algorithms and that by forcing their use via the --cipher-algo,
> > --digest-algo, --cert-digest-algo, or --compress-algo options in
> > GnuPG, it is possible to create a perfectly valid OpenPGP
> > message, but one that cannot be read by the intended recipient.
> > 
> > There are dozens of variations of OpenPGP programs available,
> > and each supports a slightly different subset of these optional
> > algorithms. For example, until recently, no (unhacked) version
> > of PGP supported the BLOWFISH cipher algorithm. A message using
> > BLOWFISH simply could not be read by a PGP user. By default,
> > GnuPG uses the standard OpenPGP preferences system that will
> > always do the right thing and create messages that are usable by
> > all recipients, regardless of which OpenPGP program they use.
> > Only override this safe default if you really know what you are
> > doing.
> > 
> > If you absolutely must override the safe default, or if the
> > preferences on a given key are invalid for some reason, you are
> > far better off using the --pgp6, --pgp7, or --pgp8 options.
> > These options are safe as they do not force any particular
> > algorithms in violation of OpenPGP, but rather reduce the
> > available algorithms to a "PGP-safe" list.
[...]

While it seems apparent that PGP 8 or older (and some other
compatible clients) will support SHA-256 but not SHA-512, I couldn't
find anything to back up the implication that one of them is
required by "the OpenPGP standard" while the other is optional. Both
are unmentioned in RFC 2440, and both are mentioned equally in RFC
4880. I'm guessing there were some intermediate standards in the 9
years between them where this would have been the case, but that
situation doesn't appear to have made it into an IETF RFC at least.

If it's only intended that modern implementations backending our
tools are going to need to validate the signatures and we don't
expect end users to do this themselves on other platforms, then I
don't suppose it's much of a concern but thought it worth mentioning
nonetheless.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110221205247.gl1...@yuggoth.org

Bug#614415: ITP: libregexp-reggrp-perl -- groups a regular expression collection

[USB]

Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)" 


* Package name: libregexp-reggrp-perl
  Version : 1.000
  Upstream Author : Merten Falk 
* URL : http://search.cpan.org/dist/Regexp-RegGrp/
* License : Artistic
  Programming Lang: Perl
  Description : groups a regular expression collection

Regexp::RegGrp is a pure Perl library providing an object-oriented
API for grouping regular expressions into a single group of regular
expressions.



--
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/20110221203233.28458.92458.report...@deepthought.ius.cc

Re: Release file changes

[Joerg Jaspert]

>> >>> until today our Release files included 3 Hashes for all their entries:
>> >>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>> >>> MD5SUM in *all* newly generated Release files.
>> >> When will that affect Release files for stable? Next point release?
>> >> Because that unfortunatly completly breaks debmirror..
>> > It did suddenly change for squeeze-updates without consultation with the
>> > suite admins.  I expect that this is reverted.
>> Good laugh that is.
> In any case, it would seem logical for squeeze and squeeze-updates to
> use the same set of hashes, imho; similarly the -proposed-updates
> suites.  Each of the "sister" suites would generally be expected to be
> consumed (for want of a better word) by the tools in the corresponding
> (old)stable suite.

Sure, and thats a reason I happily follow. Instead of that useless we
had before. :)
Done.

-- 
bye, Joerg
 vorlon: would it be less subtle if we replaced red, green and
 yellow with black, white and a shade of grey?
 aj: "and this is what a necrotic port looks like"?
 vorlon: the arch qualification table, halloween edition?
 vorlon: "i heard a faint pinging, and went to the firewall and what
 greeted my eyes? AN m68k RISED FROM THE GRAVE!!!"


-- 
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/877hctt6z6@gkar.ganneff.de

Re: Release file changes

[Joerg Jaspert]

 I additionally opened a bug with apt to add support for SHA512SUM, so
 we can start using them. As soon as that is possible I intend to drop
 SHA256 and end up with SHA1/SHA512 only.
>>> Please don't.  I have more faith in SHA-256 than SHA-512.
>> Uhh, fine - why?
> I think this question is a bit rude if faith is involved, but here we
> go:

Not intended rude, but you asked to not do something. So I want to know
why, as I'm not of the faith... :)

> the number of rounds in SHA-512 is rather small, considering its block
> size and internal state space, in particular in comparison with
> SHA-256.

Thanks.

> More practically speaking, SHA-512 would add about 450 kB of
> incompressible junk to the Packages file, so we probably want to stick
> to SHA-256 there.  But using different hashes in Release and Packages
> files is just bloat.

We are not (yet?) speaking about the other files, *right* now this is
about the Release file. Yes, in the future the rest has to come up too.
Though, 450k in a Packages file of nearly 7mb, bz2 compressed...

-- 
bye, Joerg
If God didn’t want us to eat in church, he would’ve made gluttony a sin.


--
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/87zkpprs52@gkar.ganneff.de

Re: Release file changes

[Joey Hess]

Joerg Jaspert wrote:
> Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
> tools that can't deal with this. The latter two are serious enough to
> keep the change away from oldstable forever, and stable at least until
> after next point release, should they get updated there.

It's also desirable that stable's debootstrap be able to bootstrap
unstable chroots.

> > Also, I'll see about getting d-i generating some stronger checksum files
> > now that it's been pointed out. Although I wonder if it would make more
> > sense to generate those checksums on the server side.
> 
> Well, the files currently come from the d-i builds. Makes sense, it
> shows what the build host expects them to be, not what a *possible*
> corruption during transport to us and unpack made them. How likely such
> a corruption is is a different topic, but the theoretical possibility is
> there. And we ARE using the MD5SUMS file when we accept the d-i tarballs
> to check if it actually matches, so I think we should keep that.

The debian-installer .changes file should list the byhand tarball
with sha1 and sha256 just like any other file in a changes file.
Those would be the right checksums to verify, not the md5sums inside the
tarball.

Also, it seems like the Releases file is already including sha1 and
sha256 for all the d-i files.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Release file changes

[Sune Vuorela]

On 2011-02-21, Joey Hess  wrote:
>
> --qMm9M+Fa2AknHoGS
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Joerg Jaspert wrote:
>> Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
>> tools that can't deal with this. The latter two are serious enough to
>> keep the change away from oldstable forever, and stable at least until
>> after next point release, should they get updated there.
>
> It's also desirable that stable's debootstrap be able to bootstrap
> unstable chroots.

and desireable that you can run your mirroring software (reprepro or
demirror or others) on a stable machine, even mirroring unstable or
testing.

/Sune


-- 
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/slrnim5oi4.rvp.nos...@sshway.ssh.pusling.com

Re: Release file changes

[Eduard Bloch]

#include 
* Joey Hess [Mon, Feb 21 2011, 05:32:00PM]:
> Joerg Jaspert wrote:
> > Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
> > tools that can't deal with this. The latter two are serious enough to
> > keep the change away from oldstable forever, and stable at least until
> > after next point release, should they get updated there.
> 
> It's also desirable that stable's debootstrap be able to bootstrap
> unstable chroots.

I don't like this change either because users of my apt-cacher-ng daemon
might use the stable version for unstable archives. Without installing a
backport version that will be fun.

Do we really need to drop the MD5 version? It's less than 20KiB which we
are talking about.

> Also, it seems like the Releases file is already including sha1 and
> sha256 for all the d-i files.

Nope. Those Release files in debian-installer subdir are just stubs and
don't contain checksum information. And there was nothing for
installer-$ARCH subdirs and the image files therein. Instead, there are
MD5SUMS files there which were not covered by signatures in the main
Release file.

Regards,
Eduard.

-- 
 Du kannst mit mir machen, was du willst. Ihr hab mich schließlich
gekauft. :)


signature.asc
Description: Digital signature

Re: Release file changes

[Bernd Zeimetz]

On 02/21/2011 09:05 PM, Joerg Jaspert wrote:
> On 12398 March 1977, Joey Hess wrote:
> 
>>> until today our Release files included 3 Hashes for all their entries:
>>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>>> MD5SUM in *all* newly generated Release files.
>> When will that affect Release files for stable? Next point release?
>> Because that unfortunatly completly breaks debmirror..
> 
> Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
> tools that can't deal with this. The latter two are serious enough to
> keep the change away from oldstable forever, and stable at least until
> after next point release, should they get updated there.

Please keep them away even longer - not everybody has the spare time to update
the machines which run the mirror scripts to Squeeze - or at least make sure
that debmirror and friends are updated in an oldstable pointrelease.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4d62f03c.1080...@bzed.de

Bug#614424: ITP: landside -- tool to generate HTML5 slideshow from lightweight markup

[Damien Raude-Morvan]

Package: wnpp
Severity: wishlist
Owner: "Damien Raude-Morvan" 

* Package name: landside
  Version : 0.8.2
  Upstream Author : Adam Zapletal
* URL : https://github.com/adamzap/landslide
* License : Apache-2.0
  Programming Lang: Python
  Description : tool to generate HTML5 slideshow from lightweight markup

 Landside is a tool which can generates an HTML5 slideshow using lightweight
 markup as input.
 .
 You can write your slide contents easily using two syntaxes:
  * Markdown
  * ReStructuredText
 .
 This tool support CSS/JS theming, PDF export (using PrinceXML python library),
 embed images with Base64 (for stand-alone document) and fancy transitions.
 .
 Sample presentation is visible here : .



-- 
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/20110221215254.12632.86010.report...@gauloise.lan.drazzib.com

Re: Release file changes

[Joerg Jaspert]

>> Also, it seems like the Releases file is already including sha1 and
>> sha256 for all the d-i files.
> Nope. Those Release files in debian-installer subdir are just stubs and
> don't contain checksum information. And there was nothing for
> installer-$ARCH subdirs and the image files therein. Instead, there are
> MD5SUMS files there which were not covered by signatures in the main
> Release file.

They are since yesterday.

-- 
bye, Joerg
 "Memory is like gasoline. You use it up when you are running. Of
 course you get it all back when you reboot..."; Actual explanation
 obtained from the Micro$oft help desk.


-- 
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/87tyfxotku@gkar.ganneff.de

re buildd's resolver and package's build deps

[Raphael Geissert]

[explicit BCC to Roger]

Hi everyone, Roger,

Roger Leigh has filed a few bug reports related to how the buildd's resolver 
(either internal or any of the new ones: apt{,itude}) and I'm not sure I quiet 
agree.
Let's take for example the one filed against php5 [#614413]:

[...]
> Severity: important
> 
> php5 is using these alternative build dependencies:
> 
> automake (>= 1.11) | automake1.11
> libcurl4-openssl-dev | libcurl-dev
> libdb-dev (>= 4.7) | libdb4.8-dev | libdb4.6-dev,
> libjpeg-dev | libjpeg62-dev
> libmysqlclient-dev | libmysqlclient15-dev
> 
> The build dependency resolver is currently only using the first
> alternative.  Newer resolvers use the other alternatives, and
> this can potentially lead to inconsistency between builds.

Agreed that it can lead to build-deps inconsistencies.

> Please only use one package, the one you specifically want for
> the build, and drop the alternatives.  The use of alternatives
> in build dependencies is not supported.  In particular, you really
> only want one specific version of libdb (4.8?); there must be no
> uncertainty about this when the build dæmon installs the build
> dependencies.  The same thing applies to automake and the other
> packages using alternatives.

I disagree here.
Alternatives in build-* relationships *are* mentioned by policy. In fact, 
there's even an example in section 7.1.

There's also no stated guarantee *anywhere* (including release policy) that 
the package's build deps should be consistent, much less the result.

Also, alternatives have been used ever since I joined the project for making  
backporting easier. Requiring stricter build-deps also affects that use case.


After thinking about it for a while, my opinion is that if anyone wants 
consistency to be guaranteed (e.g. in php's case that a rebuild doesn't end up 
linking php to libdb4.6 instead of libdb4.8) it should be handled on 
buildd/release team's side. The build deps as provided by the source package 
are valid.

If the package fails to build because the dependencies were resolved in a non-
standard way then an RC bug should be filed and fixed.

I abhor the idea of uselessly tightening dependencies.

Regards,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


--
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/201102211942.33509.geiss...@debian.org

Bug#614413: Info received (re buildd's resolver and package's build deps)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian PHP Maintainers 

If you wish to submit further information on this problem, please
send it to 614...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
614413: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614413
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.614413.b614413.1298338965633.acki...@bugs.debian.org

Re: for those who care about unbound (resolvconf and DNSSEC)

[Robert Edmonds]

Robert Edmonds wrote:
> i'd like to get some feedback on whether i should implement some changes
> in the unbound debian packaging:

i'm also looking into building the python bindings for libunbound.
unfortunately upstream uses autotools / libtool to build and link the
python module, which results in the python extension module being linked
against every library the configure script can find.

short of rewriting the upstream build system i could only come up with
the following to make the build link against only the required
libraries:

   # XXX gross hack to prevent python module from linking against everything
   rm -f _unbound.la
   sed -i -e 's/^dependency_libs=.*/dependency_libs=''/' libunbound.la
   make _unbound.la LIBS=""
   install -m 0644 .libs/_unbound.so.2.*.* \
   debian/python-unbound/usr/lib/pyshared/python2.6/_unbound.so

but that's really gross.

-- 
Robert Edmonds
edmo...@debian.org


signature.asc
Description: Digital signature

Re: Release file changes

[Michael Gilbert]

On Mon, Feb 21, 2011 at 3:05 PM, Joerg Jaspert wrote:
> On 12398 March 1977, Joey Hess wrote:
>
>>> until today our Release files included 3 Hashes for all their entries:
>>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>>> MD5SUM in *all* newly generated Release files.
>> When will that affect Release files for stable? Next point release?
>> Because that unfortunatly completly breaks debmirror..
> Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
> tools that can't deal with this. The latter two are serious enough to
> keep the change away from oldstable forever, and stable at least until
> after next point release, should they get updated there.

Can we get this reverted at least until the major tools can actually
cope with the change (i.e. for the next point release)?  The fact that
this causes a regression in stable's debootstrap is rather
unfortunate.  Stable is called "stable" because its functionality
isn't supposed to suddenly change.

Best wishes,
Mike


-- 
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/aanlktinkmmpqjigr3tmgzurozl5izbjx0rwue+35f...@mail.gmail.com

Bug#614517: ITP: libgit2 -- Git core methods library

[NIIBE Yutaka]

Package: wnpp
Severity: wishlist
Owner: NIIBE Yutaka 


* Package name: libgit2
  Version : 0.3.0
  Upstream Author : Vicent Mart«¿ 
* URL : http://libgit2.github.com/
* License : GPL2 with linking exemption
  Programming Lang: C
  Description : Git core methods library

libgit2 is a portable, pure C implementation of the Git core methods
provided as a re-entrant linkable library with a solid API, allowing
you to write native speed custom Git applications in any language
with bindings.



-- 
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/20110222050126.15828.6076.reportbug@localhost.localdomain