Re: Doesn't contain source for waf binary code
Do we have any idea how many packages in Debian currently use waf? Is waf growing in popularity? After reading [1] I get the impression it should die and we should try to hasten that outcome. [1] http://lists.debian.org/debian-devel/2010/02/msg00714.html -- Jon Dowland -- 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/20120208080237.GD29150@debian
Re: MATE Desktop Environment in Debian
Le mercredi 08 février 2012 à 00:53 +0100, Stefano Karapetsas a écrit : Many users are using it well. Now that this is enough stable, I begun the process for ask the inclusion in Debian. The first package is mate-common. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783 (ITP) http://lists.debian.org/debian-mentors/2012/02/msg00115.html (RFS) With this mail I wish to have opinions and suggestions about our work from Debian Developers. MATE introduces a lot of code duplication, which is considered bad in Debian, and is based on obsolete technologies - not just GTK2, which will of course remain for a long time, but also things like Bonobo which very few people really understand, and which are the cause of a lot of not-well-understood bugs. For these reasons I object to having MATE in Debian. OTOH I invite you to contribute to GNOME 3 packaging to make it look great and fix remaining regressions. I am of course not the one to decide whether your packages can be accepted; the FTP masters will. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1328691338.3202.364.camel@pi0307572
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 8 Feb 2012 12:05:44 +1100 Russell Coker russ...@coker.com.au wrote: On Wed, 8 Feb 2012, Riku Voipio riku.voi...@iki.fi wrote: If it turns out not reasonable to expect the compression results to be identical It was reported that sometimes the size differs. Surely if nothing else having gzip sometimes produce an unnecessarily large file is a bug! Expecting that the compression gives the smallest file every time is reasonable. By a single byte - I've not seen file size changes beyond that range. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp5AJFMdTw76.pgp Description: PGP signature
Re: Doesn't contain source for waf binary code
Hi! Am 08.02.2012 09:02, schrieb Jon Dowland: Do we have any idea how many packages in Debian currently use waf? Well, we opened about 55 bugs see http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=waf-unpack;users=ftpmas...@debian.org (The list was created by searching for waf files in all source packages.) However, in some package it just seems to have been leftover, and upstream already changed to an other build system. Is waf growing in popularity? I have no idea, but I'm not really sure if it's a good idea to remove samba either... Best regards, Alexander -- 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/4f3244a1.6030...@schmehl.info
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 8 Feb 2012 02:52:52 +0200
Riku Voipio riku.voi...@iki.fi wrote:
If it turns out not reasonable to expect the compression results to be
identical, we should probably look into using dpkg --path-exclude= with
/usr/share/{doc,man,info}/* when installing foreign-architecture packages.
That would be a suitable alternative to decompression checksums.
It sounds like an implicit Replaces: on the same package of any other
architecture for Multi-Arch: same packages limited
to /usr/share/{doc,man,info}/*.
Very few Multi-Arch: same packages need to install identical compressed
files outside these directories. In case it happens, the package needs to
use multiarch paths or split files to -common package.
It's not that ugly - with a few looks at the list of problematic files.
e.g. libslang2-dev, in common with a number of other -dev packages,
includes a few example files in the -dev instead of using a -doc
package. The compression of those files causes conflicts in the -dev
package, at which point creating a -doc package doesn't seem that bad
an idea. Other options would be to not compress example files when
packaged inside -dev packages - after all, if the example files are
large enough for a lack of compression to matter, the examples should
be in a -doc package.
http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
The ugliness of this
solution is that the specialness of /usr/share/doc and others needs to
embedded into the package system somewhere.
Packages can use multiarch paths for their own files, but there are
currently 80 occurrences of changelog.Debian.gz in the list of
problematic files. dpkg needs to handle that, packages have no option.
I'm wondering if /usr/share/{doc,man,info}/* is the right pattern.
Maybe it really is just /usr/share/*.
After all, this is how cross/foreign architecture packages have
*always* been handled in Debian via dpkg-cross. Nothing in /usr/share/
matters for a cross package created by dpkg-cross (with the possible
exception of /usr/share/pkg-config which was always anachronistic). Some
template files are added but the package name includes the
architecture, so these files are effectively in multiarch paths.
There is nothing useful in /usr/share of a Multiarch: same package
when installed as foreign architecture package. Emdebian dpkg-cross
have proved that by having nothing else until Multi-Arch. Anything you
might need is in the native architecture package, so the best thing to
do is widen the implicit exclusion to all of /usr/share in the incoming
Multi-Arch: same package.
In the list, the only listings in the above file which are not
in /usr/share do look like bugs:
usr/bin/kvirc
usr/bin/croco-0.6-config
usr/bin/croco-0.6-config
usr/include/dspam/auto-config.h
usr/include/isl/stdint.h
usr/bin/magics-config
usr/include/OGRE/OgreBuildSettings.h
usr/include/pci/config.h
usr/lib/pkgconfig/popt.pc
usr/bin/ppl_pl
usr/bin/ppl-config
usr/include/ppl.hh
usr/include/ppl_c.h
usr/bin/ppl-config
usr/include/ppl.hh
usr/include/ppl_c.h
usr/lib/sasl2/berkeley_db.txt
usr/lib/libwrap.a
usr/include/XdmfConfig.h
usr/bin/whiptail
usr/lib/pkgconfig/popt.pc - needs to be a multiarch path
usr/bin/* is just wrong - bug reports invited.
usr/include/* means that the package concerned needs to use a multiarch
path for that include file(s).
That leaves:
usr/lib/sasl2/berkeley_db.txt
usr/lib/libwrap.a
.a files need multiarch paths, clearly.
So, apart from /usr/share which I can't see as important for
Multi-Arch: same packages, the list of remaining conflicts are bugs and
the gzip bug doesn't matter anymore.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpJi9fyRhNvc.pgp
Description: PGP signature
Bug#659092: ITP: libapache2-mod-nss -- NSS-based SSL module for Apache2
Package: wnpp Severity: wishlist Owner: Timo Aaltonen tjaal...@ubuntu.com * Package name: libapache2-mod-nss Version : 1.0.8 Upstream Author : Red Hat, Inc. * URL : http://directory.fedoraproject.org/sources/ * License : GPL-2, Apache-2.0 Programming Lang: C Description : NSS-based SSL module for Apache2 This Apache module provides strong cryptography for the Apache 2.0 webserver via the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols by the help of the SSL/TLS implementation library NSS. -- 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/20120208101956.10508.26345.reportbug@eldon.tyrell
Re: MATE Desktop Environment in Debian
On 08/02/12 09:55, Josselin Mouette wrote: Le mercredi 08 février 2012 à 00:53 +0100, Stefano Karapetsas a écrit : Many users are using it well. Now that this is enough stable, I begun the process for ask the inclusion in Debian. The first package is mate-common. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783 (ITP) http://lists.debian.org/debian-mentors/2012/02/msg00115.html (RFS) With this mail I wish to have opinions and suggestions about our work from Debian Developers. MATE introduces a lot of code duplication, which is considered bad in Debian, and is based on obsolete technologies - not just GTK2, which will of course remain for a long time, but also things like Bonobo which very few people really understand, and which are the cause of a lot of not-well-understood bugs. Maybe this could benefit to both parties if MATE team tries to reduce usage of obsolete libraries to a bare minimum, and avoid using bug monsters (like Bonobo and others). I guess this means a lot of work, but that's the price to pay to ease its maintainability on the long term and having it packaged within Debian. Did MATE team consider such a plan? If yes, what was the outcome of the discussion? Regards, -- Mehdi -- 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/4f325217.8050...@dogguy.org
Re: Please test gzip -9n - related to dpkg with multiarch support
* Lars Wirzenius l...@liw.fi [120208 08:58]: On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote: But it's worse than this: even if dpkg decompresses before comparing, debsums won't (and mustn't, for backward compatibility). So it's potentially necessary to fix up the md5sums file for a package installed for multiple architectures, if it contains a file that was compressed differently. I'm uncomfortable with the idea of checking checksums only for uncompressed data. Compressed files have headers, and at least for some formats, it seems those headers can contain essentially arbitrary data. This allows compressed files to be modified in rather significant ways, without debsums noticing, if debsums uncompresses before comparing. On the other hand most uncompressors silently ignore unexpected data after end of file markers. So the compressed file is even more easily tempered with (especially as debsums only stores md5 without size and md5 does not include the size in the hash like the sha* do. So if one can append arbitrary stuff, it is easy prey). But the point is a bit moot, as debsums is not really useful for security (if you modify files, why not modify the md5sums files, too?). It is useful for reliability, as it checks for files being corrupted by bad discs[1], bad memory[1], bad DMA controlers[1], ... Bernhard R. Link [1] Been there, got bitten, learned to love debsums. -- 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/20120208103337.gb28...@client.brlink.eu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 8 Feb 2012, Neil Williams codeh...@debian.org wrote: Expecting that the compression gives the smallest file every time is reasonable. By a single byte - I've not seen file size changes beyond that range. It's a matter of principle. A compression program is supposed to reliably compress data. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201202082154.31137.russ...@coker.com.au
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 8 Feb 2012 21:54:30 +1100 Russell Coker russ...@coker.com.au wrote: On Wed, 8 Feb 2012, Neil Williams codeh...@debian.org wrote: Expecting that the compression gives the smallest file every time is reasonable. By a single byte - I've not seen file size changes beyond that range. It's a matter of principle. A compression program is supposed to reliably compress data. That doesn't mean to a specific size, the principle of reliable compression means that you always get back the file you put in, without compression causing losses or corruption. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp9pMVdVDcBr.pgp Description: PGP signature
Re: Please test gzip -9n - related to dpkg with multiarch support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/2012 11:04 PM, Neil Williams wrote: I'm not convinced that this is fixable at the gzip level, nor is it likely to be fixable by the trauma of changing from gzip to something else. while the original point of not considering compressors that are not producing identical output across all archs in dpkgs multi-arch implementation still stands, it might be worth noting (and at least jftr) that lzip does not suffer from that problem in the first place. - -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8yWOYACgkQ+C5cwEsrK57kRACg4LIBEB+Yn6bMC9E+xybh/doX FJAAn2Ufes5sZTMn4XHYQ2fr5ja/w6W6 =qbRU -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/4f3258e6.9060...@progress-technologies.net
Re: Please test gzip -9n - related to dpkg with multiarch support
On 08/02/12 10:22, Neil Williams wrote: Nothing in /usr/share/ matters for a cross package created by dpkg-cross (with the possible exception of /usr/share/pkg-config which was always anachronistic). I'd understood that /usr/share/pkgconfig should be used for the sort of packages that would now be Multi-Arch:foreign? Looking in my instance of that directory, I only see Architecture:all packages (like gnome-icon-theme and gtk-doc), and Architecture:any packages whose API is in terms of running executables or making D-Bus calls rather than linking libraries (like udev and systemd). udev and systemd both also ship libraries, as it happens, but those libraries have their own .pc files, which are correctly under /usr/lib. If this is a concern, maybe we should have a Lintian check that /usr/share/pkgconfig/*.pc must not have a non-trivial value in their Libs, Cflags or Libs.private fields? (Some arch-independent .pc files do have those fields, but their values are empty, as in gnome-icon-theme - that seems valid.) S -- 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/4f325d41.9030...@debian.org
Re: Doesn't contain source for waf binary code
On Wed, Feb 08, 2012 at 10:47:13AM +0100, Alexander Reichle-Schmehl wrote: I have no idea, but I'm not really sure if it's a good idea to remove samba either... Absolutely not. They might be persuade-able away from waf though. -- 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/20120208115150.GA22294@debian
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 07:57 +, Lars Wirzenius wrote: On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote: But it's worse than this: even if dpkg decompresses before comparing, debsums won't (and mustn't, for backward compatibility). So it's potentially necessary to fix up the md5sums file for a package installed for multiple architectures, if it contains a file that was compressed differently. I'm uncomfortable with the idea of checking checksums only for uncompressed data. Compressed files have headers, and at least for some formats, it seems those headers can contain essentially arbitrary data. This allows compressed files to be modified in rather significant ways, without debsums noticing, if debsums uncompresses before comparing. Further, uncompressors have the potential for security problems. See https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-2624 for example. In other words: debsums needs to decompress to verify that no files have been tampered with, but doing so can invoke an attack. Such an attack may be unlikely, but it would seem to be a better design to not open up the possibility for it. I wasn't suggesting debsums would do decompression. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Bug#659098: ITP: idm-console-framework -- IDM Console Framework for the 389 Directory Server Console
Package: wnpp Severity: wishlist Owner: Timo Aaltonen tjaal...@ubuntu.com * Package name: idm-console-framework Version : 1.1.7 Upstream Author : Red Hat, Inc. * URL : http://directory.fedoraproject.org/sources * License : LGPL Programming Lang: Java Description : IDM Console Framework for the 389 Directory Server Console A Java Management Console framework, used for 389 Directory Server remote management. -- 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/20120208114436.15218.79584.reportbug@eldon.tyrell
Re: Please test gzip -9n - related to dpkg with multiarch support
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote: Maybe the way to solve this properly is to remove compression from the uniqueness check - compare the contents of the file in memory after decompression. Yes, it will take longer but it is only needed when the md5sum (which already exists) doesn't match. Actually, I think the real way to fix this properly is to not compress files in the package at all. The contents.tar.gz is already a .tar.gz, which means it's compressed. Doubly-compressing files hardly ever nets a benefit, so we're not compressing files for the benefit of our mirrors. The only reason why we compress files in /usr/share/doc is so that that directory doesn't waste too much space. If that is the case, I think it makes much more sense for files to be packaged inside .debs uncompressed, and (optionally) for dpkg to compress them on the fly should the system administrator request it. It would then make much more sense for dpkg to consider the contents of the file, rather than the on-disk representation, and not cause this kind of issues. As an additional benefit, this will also allow those among us (like me) who hate having to use 'gunzip -c /usr/share/doc/foo/bar.pdf.gz /tmp/bar.pdf; xpdf /tmp/bar.pdf' in order to be able to read some documentation, to just request that files are not compressed. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120208131025.ga27...@grep.be
Re: Please test gzip -9n - related to dpkg with multiarch support
Neil Williams codeh...@debian.org (07/02/2012): I'd like to ask for some help with a bug which is tripping up my tests with the multiarch-aware dpkg from experimental - #647522 - non-deterministic behaviour of gzip -9n. For those not subscribed to that bug, how to reproduce[1] and possible fix[2] are available now. There might be other places where buffers are reused, I only spent a few minutes on this during my lunch break. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=55;bug=647522 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=647522 Mraw, KiBi. signature.asc Description: Digital signature
Re: Please test gzip -9n - related to dpkg with multiarch support
(Dropping everyone but dd@.) Wouter Verhelst wou...@debian.org (08/02/2012): As an additional benefit, this will also allow those among us (like me) who hate having to use 'gunzip -c /usr/share/doc/foo/bar.pdf.gz /tmp/bar.pdf; xpdf /tmp/bar.pdf' in order to be able to read some documentation, to just request that files are not compressed. Try: xpdf /usr/share/doc/debian-policy/policy.pdf.gz Mraw, KiBi. signature.asc Description: Digital signature
Re: MATE Desktop Environment in Debian
Il 2012-02-08 11:44 Mehdi Dogguy ha scritto: On 08/02/12 09:55, Josselin Mouette wrote: MATE introduces a lot of code duplication, which is considered bad in Debian, and is based on obsolete technologies - not just GTK2, which will of course remain for a long time, but also things like Bonobo which very few people really understand, and which are the cause of a lot of not-well-understood bugs. Maybe this could benefit to both parties if MATE team tries to reduce usage of obsolete libraries to a bare minimum, and avoid using bug monsters (like Bonobo and others). I guess this means a lot of work, but that's the price to pay to ease its maintainability on the long term and having it packaged within Debian. Did MATE team consider such a plan? If yes, what was the outcome of the discussion? Yeah. In our roadmap there is the dismissal of the obsolete libraries, like the replacement of MateConf (the fork of GConf) with GSettings, and so on. We are studying how replace Bonobo and ORBIT, too. About this point I talked some time ago with Karen Sandler to find a meeting point with GNOME3 developers to share more libraries possible between the two desktop environments, to reduce the duplicated work. I dont think work only on fallback session is the solution, because GNOME3 is based on a different idea. I saw some gnome design team mockups of all applications, and I find its far from GNOME2. -- 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/1c760a5fa4a51c4b2868ef9f9f288...@karapetsas.com
Re: MATE Desktop Environment in Debian
On 08/02/12 14:05, Stefano Karapetsas wrote: I saw some gnome design team mockups of all applications, and I find its far from GNOME2. Then, why don't you help them? (It is easier than re-packaging and maintaining Gnome2). Regards, -- Mehdi -- 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/4f327766.4010...@dogguy.org
Re: Doesn't contain source for waf binary code
On Wed, Feb 08, 2012 at 11:51:50AM +, Jon Dowland wrote: On Wed, Feb 08, 2012 at 10:47:13AM +0100, Alexander Reichle-Schmehl wrote: I have no idea, but I'm not really sure if it's a good idea to remove samba either... Absolutely not. They might be persuade-able away from waf though. Waf has worked very well for Samba, and I don't see us moving away any time soon. The main developer of Waf upstream is indeed often hard to work with - and I think that's been its main disadvantage so far - but with some patience we've always been able to work things out when we disagreed. I'd rather see if we can do something constructive that works for both waf upstream and Debian. Cheers, Jelmer signature.asc Description: Digital signature
Re: Please test gzip -9n - related to dpkg with multiarch support
Russ Allbery writes (Re: Please test gzip -9n - related to dpkg with multiarch support): Another possible solution is to just give any package an implicit Replaces (possibly constrained to /usr/share/doc) on any other package with the same name and version and a different architecture. This isn't as defensive, in that it doesn't catch legitimate bugs where someone has made a mistake and the packages contain different contents, but it also solves the binNMU issue (well, solves; the changelog will randomly swap back and forth between the packages, but I'm having a hard time being convinced this is a huge problem). Well, it does mean that you might be lacking important information because the other changelog wouldn't be present on the system. One thing which no-one yet seems to have suggested is to have multiarch:same packages put the changelog in a filename which is distinct for each architecture. (It wouldn't have to be the triplet; the shorter Debian arch would do.) Perhaps there are obvious reasons (which I have missed) why this is a terrible idea, but it seems to me that it's something we should consider. Ian. -- 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/20274.30293.295855.341...@chiark.greenend.org.uk
Re: MATE Desktop Environment in Debian
Le mercredi 08 février 2012 à 14:05 +0100, Stefano Karapetsas a écrit : Yeah. In our roadmap there is the dismissal of the obsolete libraries, like the replacement of MateConf (the fork of GConf) with GSettings, and so on. Sorry but what is the point of *forking* GConf? What does it bring, apart from more work for you and more processes for your users? -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1328708469.3202.417.camel@pi0307572
Re: Bug#658783: MATE Desktop Environment in Debian
Il 2012-02-08 14:23 Mehdi Dogguy ha scritto: I saw some gnome design team mockups of all applications, and I find its far from GNOME2. Then, why don't you help them? (It is easier than re-packaging and maintaining Gnome2). Regards, I just answered before. GNOME3 is a completely different desktop, and I dont think it can have two ideas in same environment. It should follow it main goal to have an attractive desktop. We started to work on MATE and we understand that it's possible and human to work and maintain it. Best regards, Stefano -- 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/1d1cccb7365b7c593fdac90c0fbb8...@karapetsas.com
Re: Doesn't contain source for waf binary code
On Wed, 8 Feb 2012 08:59:30 +1100, Karl Goetz k...@kgoetz.id.au wrote: I don't know anything about waf not mentioned in this thread, but would it be possible to patch the package to work with a packaged waf instead? thanks, kk See the reasons for removal previously referenced by Alexander: http://lists.debian.org/debian-devel/2010/02/msg00714.html and the URLs referenced from there. waf upstream is hostile to this idea to the point that he intentionally changed the documentation licence to a non-free license in order to discourage us. stew -- 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/87liodfn3p@cardinal.vireo.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote: For those not subscribed to that bug, how to reproduce[1] and possible fix[2] are available now. There might be other places where buffers are reused, I only spent a few minutes on this during my lunch break. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=647522 Even if you ensure a particular build behaves exactly the same on a given architecture, you're merely introducing future problems. gzip's output is likely to change: * on a new version * after a bugfix (including security ones) * on a different architecture * with different optimizations * with a different implementation (like those parallel ones) * possibly with a different moon phase Especially the first is pretty guaranteed to bite: whenever the upstream does a small improvement, binaries in the archive get invalidated until rebuilt with the new gzip. Breaking the ideas for diverting /bin/gzip by pigz is not nice, too. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20120208140646.gb25...@angband.pl
Re: Please test gzip -9n - related to dpkg with multiarch support
Wouter Verhelst wrote: On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote: Maybe the way to solve this properly is to remove compression from the uniqueness check - compare the contents of the file in memory after decompression. Yes, it will take longer but it is only needed when the md5sum (which already exists) doesn't match. Actually, I think the real way to fix this properly is to not compress files in the package at all. The contents.tar.gz is already a .tar.gz, which means it's compressed. s/contents/data/ Doubly-compressing files hardly ever nets a benefit, so we're not compressing files for the benefit of our mirrors. The only reason why we compress files in /usr/share/doc is so that that directory doesn't waste too much space. If that is the case, I think it makes much more sense for files to be packaged inside .debs uncompressed, and (optionally) for dpkg to compress them on the fly should the system administrator request it. It would then make much more sense for dpkg to consider the contents of the file, rather than the on-disk representation, and not cause this kind of issues. I agree with this entirely. Doing this would actually save *more* space in the .deb files, since it allows gzip (or xz, or whatever compresses the data.tar) to see the contents of multiple files at once. It also allows the administrator to set local policies for compression to cover cases like the one you mentioned below. Those local policies would also allow the use of compression formats other than .xz, as well as deciding to leave files uncompressed due to the use of a filesystem with built-in compression. It wouldn't work in all cases, since sometimes the package requires a compressed file in a certain location, but it should work for just about all files in /usr/share/doc. The only downside that I can see: packages couldn't refer to a particular file under /usr/share/doc/$package/ by path, because those packages wouldn't know how the administrator might choose to compress their files. Given the policy of not depending on files under /usr/share/doc/ to function, at most this will result in manpages and similar referencing paths that then need a .gz or .xz appended, and that doesn't seem like a big deal; people will cope and tools can learn to check for compressed variants. As an additional benefit, this will also allow those among us (like me) who hate having to use 'gunzip -c /usr/share/doc/foo/bar.pdf.gz /tmp/bar.pdf; xpdf /tmp/bar.pdf' in order to be able to read some documentation, to just request that files are not compressed. Try zrun from the moreutils package: zrun xpdf /usr/share/doc/foo/bar.pdf.gz Or use evince, which can handle compressed files directly. - Josh Triplett -- 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/20120208135032.GA21503@leaf
Re: Bug#658783: MATE Desktop Environment in Debian
Il 2012-02-08 14:41 Josselin Mouette ha scritto: Le mercredi 08 février 2012 à 14:05 +0100, Stefano Karapetsas a écrit : Yeah. In our roadmap there is the dismissal of the obsolete libraries, like the replacement of MateConf (the fork of GConf) with GSettings, and so on. Sorry but what is the point of *forking* GConf? What does it bring, apart from more work for you and more processes for your users? GConf is deprecated. MateConf is born to have a temporary solution until we choose the replacement for it. -- 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/9e93a1a64a5422eb07cefad74af92...@karapetsas.com
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 8 Feb 2012 14:14:22 +0100 Cyril Brulebois k...@debian.org wrote: Neil Williams codeh...@debian.org (07/02/2012): I'd like to ask for some help with a bug which is tripping up my tests with the multiarch-aware dpkg from experimental - #647522 - non-deterministic behaviour of gzip -9n. For those not subscribed to that bug, how to reproduce[1] and possible fix[2] are available now. There might be other places where buffers are reused, I only spent a few minutes on this during my lunch break. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=55;bug=647522 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=647522 Thanks for taking that one stage on, Cyril. I ran out of time to look at this any further yesterday, I've only just got back to the bug and noticed the hint about multiple files on the command line from Zack Weinberg. It makes sense that with a single file on the command line, the aberrant compressed file never appears when with more than one, it can. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp66v2fJQSo5.pgp Description: PGP signature
Re: Transition to PHP 5.4 starting soon (Re: PHP 5.4 transition in unstable)
On 02/08/2012 12:50 AM, Filipus Klutiero wrote: Thankfully there's a page being built to track problems in packages that contain PHP code: http://wiki.debian.org/PHP/54Transition This is very nice, but how come PHP Lint isn't in Debian? It seems to be shipped under a BSD license, so it shouldn't be an issue. Also, for one of the package I'm maintaining, extplorer (which is a nice web file manager), it seems to report a false positive, because it's not parsing correctly a traditional Chinese string. The fact that PHP Lint isn't in Debian prevents me from reporting a bug in the Debian BTS, and tracking issues (sure, I can report it upstream, but that's not same...). Filipus, do you think you'd have time to package PHP Lint? Thomas -- 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/4f327ff1.4050...@debian.org
Re: Bug#658783: MATE Desktop Environment in Debian
Le mercredi 08 février 2012 à 14:52 +0100, Stefano Karapetsas a écrit : GConf is deprecated. MateConf is born to have a temporary solution until we choose the replacement for it. GConf is deprecated, but it is still maintained. It is still used e.g. by evolution. I don’t see the point of renaming it, starting another daemon, and whatnot, if you provide the same functionality. If you want to keep maintaining GConf for longer than they plan, I don’t think upstream developers will prevent you from doing it. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1328710995.3202.429.camel@pi0307572
Re: Transition to PHP 5.4 starting soon (Re: PHP 5.4 transition in unstable)
On Wed, February 8, 2012 15:00, Thomas Goirand wrote: On 02/08/2012 12:50 AM, Filipus Klutiero wrote: Thankfully there's a page being built to track problems in packages that contain PHP code: http://wiki.debian.org/PHP/54Transition This is very nice, but how come PHP Lint isn't in Debian? It seems to be shipped under a BSD license, so it shouldn't be an issue. The string PHP Lint here refers to invoking php with the -l option, which is documented as lint mode: checking input files on PHP syntax. So if this fails with parse errors, normal execution will also fail on those same errors. Also, for one of the package I'm maintaining, extplorer (which is a nice web file manager), it seems to report a false positive, because it's not parsing correctly a traditional Chinese string. If I include() that file in an otherwise empty PHP script and execute that, I also get the same parse error (PHP from wheezy). Are you sure that it actually works? Thijs -- 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/fa965050a16316f0bd7ffa5dddb65fd4.squir...@wm.kinkhorst.nl
Re: Bug#658783: MATE Desktop Environment in Debian
Il 2012-02-08 15:23 Josselin Mouette ha scritto: GConf is deprecated, but it is still maintained. It is still used e.g. by evolution. I don’t see the point of renaming it, starting another daemon, and whatnot, if you provide the same functionality. If you want to keep maintaining GConf for longer than they plan, I don’t think upstream developers will prevent you from doing it. This is a good news. I didnt know that GConf is still maintained. This is a good point where we can start to share our forces! -- 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/85e5d3caf3db02ce87e346f3b460f...@karapetsas.com
Re: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
Hi Francesco, Do you recommend that we build the next NetCDF from 4.1.1 or should we use the 4.1.3 from experimental as the base? Regards Alastair On 2012-02-07 13:17, Francesco P. Lovergine wrote: On Tue, Feb 07, 2012 at 09:28:00AM +, Alastair McKinstry wrote: On 2012-02-02 01:43, Steve M. Robbins wrote: Hi, I'd like to contribute towards a solution for this. I'm forwarding to debian-devel to get some others' ideas. Naively, I don't understand why netcdf can't offer multiple variants, just as hdf5 does. Or, at least, one package libnetcdf-mpi-dev that links with the default MPI implementation. I am not involved in the netcdf. You should report a bug on this package. I'm prepared to do so, but I'd first like to get agreement that netcdf is where the problem lies. Netcdf maintainers, please chime in! I think we can no longer live in the status quo (see all the blockers of #631019), so something has to give. Even if it is painful, perhaps Debian could pioneer something and pass patches back to upstream? Thoughts? -Steve As of now, I have several packages (eg ADIOS, CDO) that used to build against netcdf and libhdf5-mpi-dev that don't. Without fixes to netCDF (I appreciate what Francesco says about netcdf upstream not giving the libraries proper names), there needs to be a regression: either the packages build with netcdf but no MPI, or MPI but no netcdf. The problem is the following: with latest update to hdf5, the chain of dependencies changed, so that now libnetcdf6 depends on the pure serial version of hdf5, while the previous one depended on serial or parallel: Version: 1:4.1.1-6+b1 Depends: libc6 (= 2.7), libcurl3-gnutls (= 7.16.2), libgcc1 (= 1:4.1.1), libgfortran3 (= 4.3), libhdf5-7 (= 1.8.7), libquadmath0 (= 4.6), libstdc++6 (= 4.4.0) Version: 1:4.1.1-6 Depends: libc6 (= 2.7), libcurl3-gnutls (= 7.16.2-1), libgcc1 (= 1:4.1.1), libgfortran3 (= 4.3), libhdf5-serial-1.8.4 | libhdf5-1.8.4, libquadmath0 (= 4.6), libstdc++6 (= 4.4.0) So at least at packaging level, that should be fixed to follow the previous criteria. That said, indeed NetCDF provides nc_create_par and nc_open_par in both serial and parallel versions, but needs to be built with --enable-parallel to take advantage of parallel I/O in HDF5, else it works in pure serial mode. -- Alastair McKinstry , alast...@sceal.ie , mckins...@debian.org http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- 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/4f328767.1060...@debian.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 11:33:37AM +0100, Bernhard R. Link wrote: On the other hand most uncompressors silently ignore unexpected data after end of file markers. So the compressed file is even more easily tempered with (especially as debsums only stores md5 without size and md5 does not include the size in the hash like the sha* do. So if one can append arbitrary stuff, it is easy prey). This is not true. MD5 and the SHA variants are all Merkle-Damgård constructions, which is what makes them vulnerable to length extension attacks if the compression function is not secure. Merkle-Damgård constructions include the number of bits hashed in the hash. But yes, MD5 is vulnerable to length extension attacks. -- 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
Re: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
On Wed, Feb 08, 2012 at 02:32:07PM +, Alastair McKinstry wrote: Hi Francesco, Do you recommend that we build the next NetCDF from 4.1.1 or should we use the 4.1.3 from experimental as the base? Regards Alastair AFAIK Sylvestre is going to reset the dependencies chain in hdf5 to avoid that kind of problem. About 4.1.3 in experimental, it still needs a bit of work, and I'm going to split in separate packages current netcdf 4.1.1 before, in order to have a decent organization of all solibs to have a smooth migration to 4.1.3. You have free access to the git repository, so a branch can be prepared for having a parallel flavor too. -- Francesco P. Lovergine -- 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/20120208152707.gb3...@gandalf.is-a-geek.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 8 Feb 2012 15:06:46 +0100 Adam Borowski kilob...@angband.pl wrote: On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote: For those not subscribed to that bug, how to reproduce[1] and possible fix[2] are available now. There might be other places where buffers are reused, I only spent a few minutes on this during my lunch break. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=647522 Even if you ensure a particular build behaves exactly the same on a given architecture, you're merely introducing future problems. gzip's output is likely to change: * on a new version * after a bugfix (including security ones) * on a different architecture * with different optimizations * with a different implementation (like those parallel ones) * possibly with a different moon phase Especially the first is pretty guaranteed to bite: whenever the upstream does a small improvement, binaries in the archive get invalidated until rebuilt with the new gzip. I don't get it. That would only affect packages which were built during the time that a new upload of gzip is made and all the buildd's making that new version available. Now, if there is a binNMU after a new version of gzip is uploaded, yes it is probably wise to rebuild all architectures if the package includes a Multi-Arch: same library. How often does that happen? It doesn't matter for other packages in the archive - it only matters for binary packages of the same Multi-Arch source which can install the same file in the same place from two or more architectures. Binaries in the archive already are completely unaffected by a new gzip - the only collision is between compressed files in the same location under /usr/share/doc and Policy already handles that with the exception of problems inherent to Multi-Arch. Breaking the ideas for diverting /bin/gzip by pigz is not nice, too. However, having said all that, I think that an approach which borrows / inherits from existing dpkg-cross behaviour by simply assuming that anything in /usr/share of a Multi-Arch: same package just doesn't matter for the functionality of the package is much better, much more reliable allowing any collisions to just get silently ignored. It avoids all of the gzip problems and the only remaining collisions can be fixed as bugs. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpV9cgoGAweg.pgp Description: PGP signature
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: Well, it does mean that you might be lacking important information because the other changelog wouldn't be present on the system. While the implicit Replaces seems the easy way out, it just seems even more fragile than the shared files approach. And while the binNMU changelog issues might seem like a corner case, it's just a symptom of something that's not quite right. And after this was brought up again I started considering that the shared file approach might have been flawed afterall, even if it might have seemed neat at the time (it's one of the reasons that part of the code has not been merged yet). The main reason it was enviaged was to handle the changelog and copyright files and to avoid needing to introduce an additional common package per source, for just those two/three files. As a side remark, I think at least those two are actual package metadata and do belong in the .deb control member [0], and as such in the dpkg database. But that's for discussion on another time, because that would not fix the issue as upstream changelogs do conflict too, for example. http://lists.debian.org/debian-dpkg/2011/09/msg00029.html One thing which no-one yet seems to have suggested is to have multiarch:same packages put the changelog in a filename which is distinct for each architecture. (It wouldn't have to be the triplet; the shorter Debian arch would do.) Perhaps there are obvious reasons (which I have missed) why this is a terrible idea, but it seems to me that it's something we should consider. Instead of this, I'd rather see the shared files approach just dropped completely, and /usr/share/doc/ files for “Multi-Arch: same” packages be installed under /usr/share/doc/pkgname:arch/. This would solve all these problems in a clean way for the common case with just the two or three mandated files (changelog, changelog.Debian and copyright), if a package provides lots more files then they should be split anyway into either a libfooN-common libfoo-doc, or similar. And finally this would not be really confusing, given that one of the last interface changes was to make all dpkg output for all “Multi-Arch: same” packages be always arch-qualified. regards, guillem -- 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/20120208161319.ga24...@gaara.hadrons.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 05:13:20PM +0100, Guillem Jover wrote: On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: Well, it does mean that you might be lacking important information because the other changelog wouldn't be present on the system. While the implicit Replaces seems the easy way out, it just seems even more fragile than the shared files approach. And while the binNMU changelog issues might seem like a corner case, it's just a symptom of something that's not quite right. And after this was brought up again I started considering that the shared file approach might have been flawed afterall, even if it might have seemed neat at the time (it's one of the reasons that part of the code has not been merged yet). The main reason it was enviaged was to handle the changelog and copyright files and to avoid needing to introduce an additional common package per source, for just those two/three files. As a side remark, I think at least those two are actual package metadata and do belong in the .deb control member [0], and as such in the dpkg database. But that's for discussion on another time, because that would not fix the issue as upstream changelogs do conflict too, for example. http://lists.debian.org/debian-dpkg/2011/09/msg00029.html One thing which no-one yet seems to have suggested is to have multiarch:same packages put the changelog in a filename which is distinct for each architecture. (It wouldn't have to be the triplet; the shorter Debian arch would do.) Perhaps there are obvious reasons (which I have missed) why this is a terrible idea, but it seems to me that it's something we should consider. Instead of this, I'd rather see the shared files approach just dropped completely, and /usr/share/doc/ files for “Multi-Arch: same” packages be installed under /usr/share/doc/pkgname:arch/. This would solve all these problems in a clean way for the common case with just the two or three mandated files (changelog, changelog.Debian and copyright), if a package provides lots more files then they should be split anyway into either a libfooN-common libfoo-doc, or similar. And finally this would not be really confusing, given that one of the last interface changes was to make all dpkg output for all “Multi-Arch: same” packages be always arch-qualified. If you remove the shared files approach, how do you handle files like lintian overrides, reportbug presubj and scripts, etc. ? 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/20120208162922.ga28...@glandium.org
Re: Help making r-cran-rsqlite use Debian's sqlite3 (Was: Re: Bug#657919: ITP: r-cran-digest - Create cryptographic hash digests of R objects)
[Moving a non-Debian Med related issue to debian-devel. (reply-to set)
The relevant part of this thread starts at
http://lists.debian.org/debian-med/2012/02/msg00074.html
and might be interesting for people building R packages. ]
On Wed, Feb 08, 2012 at 09:37:12AM -0600, Dirk Eddelbuettel wrote:
| Other examples can be viewed here:
|
| http://anonscm.debian.org/viewvc/debian-med/trunk/packages/R/
I asked you to email it. It's ten lines.
Sorry, I missed the email part - can perfectly do so in case we agree
about the requested patch makes sense or not.
| But a textual substitution by *what*?
Value of the most current R, which I am always running on the system I
prepare the debian/* files
A helper script could even have a _constant_ value (or in a dot.rc file)
which we update every six months.
Sorry, I do not get your point in how far this should help reducing the
effort.
| Then I am /much/ less interested in the patch as it doesn't really help
with
| the workflow for the maintainer. We're going from a manual edit of two
| fields on a file to one. Still leaves us needing to open/edit the file.
|
| Why? I do not need to edit the control file of r-cran-epi (and others)
| any more. Your statement is true if (and only if) the package in
Then you are doing it wrong. As soon as a new R forces changes, you *need to
build with those*.
I'm actually doing this by building in a recent unstable chroot:
$ sudo cowbuilder --update
$ pdebuild
How can you tell this the wrong approach? That's default that you build
against the R version recently available in unstable.
See eg the recent changes to the help system. Also, when
CRAN packages interdepend you often need the newest version, Build-Depends on
the newest R gets you that (albeit indirectly).
There is no need to Build-Depend from the newest R if it is determined
by the way you build the package. The best you gain when fixing the
Build-Depends to a certain version is that backporters will have to
touch the packaging. If you are not fixing the Build-Depends version
and rather make the Depends according to the version the package was
builded against, you can safely build it even as backport / other
distributions.
You may have too narrow a Debian focus here.
Sorry, I can not parse this. Please explain.
| question has some version constraint set upstream and you need a
| versioned Build-Depends. If you can use any recent R version it is
It's not. Sometimes we need a specific miminum version that may not have been
built on all arches etc pp.
So far as I understand this actual sometimes is determined by upstream
requirements as I wrote or am I missing something?
| fine to go with a non-versioned Build-Depends (and we are doing so in
| the majority if not all Debian Med packages). The ${R:Depends} just
| records which actual version of r-base-dev was used in the build
| process and you are done.
|
| A tool to more easily set the Build-Depends would be of use.
|
| *If* you need to adjust a versioned Build-Depends of an R package
| because upstream needs a specific version, you need to edit something
| anyway - so why not doing it at the usual place. I admit I do not
| really understand your feature request.
Yes, we are wasting each other's time. Let's keep things the way they are;
you guys add your snippet if you feel you need it.
What we have works reliably for over a hundred packages. No need for changes.
On the contrary there are about 50 packages using a method you are
calling builded the wrong way. If you are right I would see a need for
changes.
You initially said we found a Nice substvars trick.[1] I volunteered
to provide a patch to make it avialable for all R packages (BTW, when
not using ${R:depends} in your debian/control nothing happens at all -
so it is totally non-invasive to your packaging).
When discussing this more detailed you claim that we are doing things
wrong. I know that in Debian Science this method is used as well
(that's why I'm asking for the wider audience to make them aware of a
more general problem). So if we are really doing things wrong I would
love to read a better explanation I'm able to understand to fix things
(also bug reports are welcome).
Kind regards
Andreas.
[1] http://lists.debian.org/debian-med/2012/02/msg00023.html
--
http://fam-tille.de
--
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/20120208162735.gq9...@an3as.eu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote: If you remove the shared files approach, how do you handle files like lintian overrides, reportbug presubj and scripts, etc. ? The same principle that applies to all dpkg output to avoid ambiguity would apply everywhere, whenever there's a “Multi-Arch: same” package name that needs to be unambiguous, it just always gets arch-qualified. The rest would stay as they are. So, at least for lintian and reportbug, given that these file/dir names are package name based they would just get arch-qualified when needed. regards, guillem -- 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/20120208165611.ga25...@gaara.hadrons.org
Re: Please test gzip -9n - related to dpkg with multiarch support
Guillem Jover writes (Re: Please test gzip -9n - related to dpkg with multiarch support): On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: One thing which no-one yet seems to have suggested is to have multiarch:same packages put the changelog in a filename which is distinct for each architecture. (It wouldn't have to be the triplet; the shorter Debian arch would do.) Perhaps there are obvious reasons (which I have missed) why this is a terrible idea, but it seems to me that it's something we should consider. Instead of this, I'd rather see the shared files approach just dropped completely, and /usr/share/doc/ files for “Multi-Arch: same” packages be installed under /usr/share/doc/pkgname:arch/. Right, that's kind of what I was suggesting although you've generalised it. It doesn't seem like an unreasonable idea to me. Obviously it would mean that some (Debian-specific) software which currently doesn't need to be multiarch-aware would need to be taught about these new directory names. But that seems like a reasonable price to pay for solving the varying compressed shared files problem. Another relevant question is whether there are other files that are shared, and which don't want to move, besides ones in /usr/share/doc. I haven't been following this in detail but if there are then we may need to retain the possibility to have actually-identical shared files. Ian. -- 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/20274.43538.832430.612...@chiark.greenend.org.uk
Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
I want to speak up about endianness of data files, this is a suggestion but not a flaw which I just want to discover the possibility of improvement to current status by the chance of implementing Multi-Arch in Debian. Some packages come with data files that endianness matters, and many of them are large enough to split into a separate arch:all package if endianness were not something to care about. AFAIK some maintainers are not aware of endianness issues in their packages and then just ignored it (not sure how many, but if any of them are discovered it should lead to RC bug). It would be great to have some mechanism to handle such kind of problems in Debian, to avoid forcing those data to be placed into arch:any package. -- Regards, Aron Xu -- 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/CAMr=8w494xg1bwj3lr5rqnjrgrcung-e6igqb+xt6bdygpr...@mail.gmail.com
Re: Please test gzip -9n - related to dpkg with multiarch support
Ian Jackson wrote: Another relevant question is whether there are other files that are shared, and which don't want to move, besides ones in /usr/share/doc. One example is header files in /usr/include, from -dev packages. In the simple examples I've seen, putting them in /usr/include/triplet, works fine. It is always possible to split off a separate Multiarch: foreign -dev-common package if needed in order to save space. Another example is manpages, also in -dev packages. That's more fussy. -- 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/20120208172627.GA6712@burratino
Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
On 08/02/12 17:22, Aron Xu wrote: Some packages come with data files that endianness matters, and many of them are large enough to split into a separate arch:all package if endianness were not something to care about. AFAIK some maintainers are not aware of endianness issues in their packages and then just ignored it (not sure how many, but if any of them are discovered it should lead to RC bug). Hopefully Jakub Wilk's automatic checks for conflicting files http://people.debian.org/~jwilk/multi-arch/ will already be picking this up, in cases where the less-used-endianness architectures aren't broken already. If the less-used-endianness architectures are already broken, that's also a bug (potentially an RC one), just like code that compiles but doesn't work on a particular endianness due to other assumptions - and if nobody has noticed it yet, presumably the package doesn't have any users (or regression tests) on those architectures. It would be great to have some mechanism to handle such kind of problems in Debian, to avoid forcing those data to be placed into arch:any package. If the right endianness is critical: libfoo:i386 Depends: libfoo-data-le, libfoo:powerpc Depends: libfoo-data-be, both data packages arch:all, data files in /usr/share/foo/le and /usr/share/foo/be respectively? Or just make sure the data has an endianness marker, and enhance the reading package to do the right byteswapping based on the endianness marker - e.g. this has been discussed for gettext, which ended up just writing out the same endianness on all platforms. Many formats (particularly those that originated on Windows) are always little-endian, and big-endian platforms reading them just take the minor performance hit; formats that respect network byte order have the opposite situation. S -- 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/4f32b26f.8050...@debian.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote: On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote: If you remove the shared files approach, how do you handle files like lintian overrides, reportbug presubj and scripts, etc. ? The same principle that applies to all dpkg output to avoid ambiguity would apply everywhere, whenever there's a “Multi-Arch: same” package name that needs to be unambiguous, it just always gets arch-qualified. The rest would stay as they are. That is a major waste of space of having multiple copies of identical files with different arch-qualified names. Is that really better architecture to have multiple copies of identical files on user systems? So, at least for lintian and reportbug, given that these file/dir names are package name based they would just get arch-qualified when needed. Another major frustration your no-shared-files proposal adds, is the need to split the M-A: same libfoo-dev packages to libfoo-dev-common in order to avoid overwriting /usr/include contents and /usr/bin/foo-config binaries. Our packages are already heavily split slowing down Packages.gz downloads and all other apt operations. Riku -- 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/20120208175241.ga6...@afflict.kos.to
Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
On Thu, Feb 9, 2012 at 01:35, Simon McVittie s...@debian.org wrote:
On 08/02/12 17:22, Aron Xu wrote:
Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. AFAIK some maintainers
are not aware of endianness issues in their packages and then just
ignored it (not sure how many, but if any of them are discovered it
should lead to RC bug).
Hopefully Jakub Wilk's automatic checks for conflicting files
http://people.debian.org/~jwilk/multi-arch/ will already be picking
this up, in cases where the less-used-endianness architectures aren't
broken already.
If the less-used-endianness architectures are already broken, that's
also a bug (potentially an RC one), just like code that compiles but
doesn't work on a particular endianness due to other assumptions - and
if nobody has noticed it yet, presumably the package doesn't have any
users (or regression tests) on those architectures.
Or some of them just gave up because it is less-used architecture.
It would be great to have some mechanism to
handle such kind of problems in Debian, to avoid forcing those data to
be placed into arch:any package.
If the right endianness is critical: libfoo:i386 Depends:
libfoo-data-le, libfoo:powerpc Depends: libfoo-data-be, both data
packages arch:all, data files in /usr/share/foo/le and /usr/share/foo/be
respectively?
This looks not very nice, because we need to maintain a list of
architectures in debian/control, and when new architectures are added
the package is potentially broken.
Also, arch:all packages are usually generated by the uploading DD on
one architecture, mostly amd64 and i386 today, how can he managed to
generate be data files if he doesn't have access to such a machine?
Adding an option to the data generator/parser and make it able to
generate be/le data on any architecture seems not to be a reasonable
approach.
Or just make sure the data has an endianness marker, and enhance the
reading package to do the right byteswapping based on the endianness
marker - e.g. this has been discussed for gettext, which ended up just
writing out the same endianness on all platforms. Many formats
(particularly those that originated on Windows) are always
little-endian, and big-endian platforms reading them just take the minor
performance hit; formats that respect network byte order have the
opposite situation.
This is valid for most-used applications/formats like gettext, images
that are designed to behave in this way, but on the contrary there are
upstream that don't like to see such impact, especially due to the
complexity and performance impact.
Currently I am using arch:any for data files which aren't be affected
with multiarch, i.e. not same or foreign. For endianness-critical
data that is required to make a library working, I have to force them
to be installed into /usr/lib/triplet/$package/data/ and mark them
as Multiarch: same, this is sufficient to avoid breakage, but again
it consumes a lot of space on mirror.
I thought about something like /usr/share/$package/data/{be,le} in
arch:all, but appears to be not a reasonable solution because we need
to modify the data generator/parser.
--
Regards,
Aron Xu
--
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/CAMr=8w6s+itap8usgjaqf86mffypaop+qjodetjhdyumb7a...@mail.gmail.com
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 8 Feb 2012 17:13:20 +0100 Guillem Jover guil...@debian.org wrote: On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: Well, it does mean that you might be lacking important information because the other changelog wouldn't be present on the system. Instead of this, I'd rather see the shared files approach just dropped completely, and /usr/share/doc/ files for “Multi-Arch: same” packages be installed under /usr/share/doc/pkgname:arch/. This would solve all I agree with this for /usr/share but I don't think the shared files approach should be dropped entirely - /usr/include is one place where it will be very helpful and appears to be working properly already. these problems in a clean way for the common case with just the two or three mandated files (changelog, changelog.Debian and copyright), if a package provides lots more files then they should be split anyway This works for shared library packages - it is -dev packages which still need the shared files approach. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpOR6BFNxFXN.pgp Description: PGP signature
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 08 Feb 2012, Neil Williams wrote: I don't get it. That would only affect packages which were built during the time that a new upload of gzip is made and all the buildd's making that new version available. Now, if there is a binNMU after a new version of gzip is uploaded, yes it is probably wise to rebuild all architectures if the package includes a Multi-Arch: same library. How often does that happen? Isn't this something that we can test for in the archive, and require rebuilds for all affected packages before entering testing? [Multi-Arch: same with the same path that have differing md5sums?] Even outside of the gzip case, this would catch cases where maintainers had screwed up. Don Armstrong -- The sheer ponderousness of the panel's opinion [...] refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it---and is just as likely to succeed. -- Alex Kozinski, Dissenting in Silveira v. Lockyer (CV-00-00411-WBS p5983-4) http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20120208192528.gd6...@rzlab.ucr.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
Guillem Jover guil...@debian.org writes: On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: Well, it does mean that you might be lacking important information because the other changelog wouldn't be present on the system. While the implicit Replaces seems the easy way out, it just seems even more fragile than the shared files approach. Yes, this is definitely true. I was mentioning it as an easy way out, but it's aesthetically unappealing. And while the binNMU changelog issues might seem like a corner case, it's just a symptom of something that's not quite right. Also true. In fact, it's something that's been bothering me for a long time with linked doc directories. I'd like to prohibit them in more cases so that we get the binNMU changelogs on disk. Instead of this, I'd rather see the shared files approach just dropped completely, and /usr/share/doc/ files for “Multi-Arch: same” packages be installed under /usr/share/doc/pkgname:arch/. This would solve all these problems in a clean way for the common case with just the two or three mandated files (changelog, changelog.Debian and copyright), if a package provides lots more files then they should be split anyway into either a libfooN-common libfoo-doc, or similar. And finally this would not be really confusing, given that one of the last interface changes was to make all dpkg output for all “Multi-Arch: same” packages be always arch-qualified. The only thing I'm worried about here is that we lose something from the UI perspective. That's going to be a change historically from where we've told users to look, and it's a little awkward. But, thinking it over, the set of packages that we're talking about is fairly limited. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87liodrttk@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote: Guillem Jover guil...@debian.org writes: On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: And while the binNMU changelog issues might seem like a corner case, it's just a symptom of something that's not quite right. Also true. In fact, it's something that's been bothering me for a long time with linked doc directories. I'd like to prohibit them in more cases so that we get the binNMU changelogs on disk. Relating to binNMU changelogs: do they really serve any purpose? There are no source changes, so is there any real need for a changelog change at all? AFAICT the only reason we do for historical reasons, it being the only way previously to effect a version change. We briefly discussed on #debian-buildd last week whether it was possible to use --changes-option to override the distribution during building. If it is also possible to override the version of the generated .debs, this would make it possible to rebuild (NMU) without messing around editing the changelog. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120208195447.gi8...@codelibre.net
Re: Please test gzip -9n - related to dpkg with multiarch support
Riku Voipio riku.voi...@iki.fi writes: On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote: The same principle that applies to all dpkg output to avoid ambiguity would apply everywhere, whenever there's a “Multi-Arch: same” package name that needs to be unambiguous, it just always gets arch-qualified. The rest would stay as they are. That is a major waste of space of having multiple copies of identical files with different arch-qualified names. Is that really better architecture to have multiple copies of identical files on user systems? Is it really, though? The files we're talking about are not generally large. I have a hard time seeing a case where the files would be large enough to cause any noticable issue and you wouldn't want to move them into a separate -common or -doc package anyway. Another major frustration your no-shared-files proposal adds, is the need to split the M-A: same libfoo-dev packages to libfoo-dev-common in order to avoid overwriting /usr/include contents and /usr/bin/foo-config binaries. There are two main cases for libfoo-dev that I think cover most such packages: 1. The header files are architecture-dependent (definitions of data member sizes, for example), in which case they need to be arch-qualified anyway if you're going to allow multiple libfoo-dev packages to be installed for different architectures. 2. The header files are architecture-independent, and the only architecture-dependent content inside libfoo-dev is the static library. In this case, if you want to make libfoo-dev multi-arch, I would advocate seriously considering just dropping the static library and making the -dev package arch: all. I think static libraries are increasingly of very questionable utility on a Linux system. But, assuming that you do want to keep it, you could still move the header files to /usr/include/triplet instead, which is relatively painless. foo-config binaries, as opposed to pkg-config files, are indeed going to continue to be a problem in model 2, but they're a problem anyway, no? There's no guarantee that the amd64 and i386 version of a package will want the same flags, so we really need some way of having a multiarch-aware verson of the -config script. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87haz1rtex@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 11:25:28 -0800, Don Armstrong wrote: On Wed, 08 Feb 2012, Neil Williams wrote: I don't get it. That would only affect packages which were built during the time that a new upload of gzip is made and all the buildd's making that new version available. Now, if there is a binNMU after a new version of gzip is uploaded, yes it is probably wise to rebuild all architectures if the package includes a Multi-Arch: same library. How often does that happen? Isn't this something that we can test for in the archive, and require rebuilds for all affected packages before entering testing? [Multi-Arch: same with the same path that have differing md5sums?] This has for example the following implication: Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to sid generating a reproducible output across all current architectures. Time passes, compressor version N (and even O and P and Q etc) gets uploaded, which starts producing new ouput (on each of those versions). A new architecture gets added to Debian, and because previous compressor versions are not in the archive anymore, all packages built with them have different checksums than the new ones. This means *all* those packages have to be binNMUed across *all* the architectures, or the porters need to hunt down every specific compressor version used to build those packages to be able to reproduce the build on their arch. This seems highly suboptimal and “future-unproof”... regards, guillem -- 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/20120208200243.ga29...@gaara.hadrons.org
Comments on introducing a new Essential package: base-init?
This is regarding Bug #645540 (Essential package conflict between sysvinit and systemd-sysv). sysvinit is currently Essential. In order to permit the replacement of sysvinit with an alternative init system, I'd like to propose the creation of a new Essential package base-init, with a Depends on sysvinit | init, where init is a virtual package provided by all packages providing /sbin/init. This would be provided by sysvinit, systemd, upstart, etc. With this package in place, sysvinit could be removed from the Essential set, but remain the default init system. This would permit alternative init systems to entirely replace sysvinit. An alternative would be for an existing Essential package such as base-files to provide the Depends, which would save the need for a separate base-init package. Is there any reason this would be undesirable? (I note that it currently has no depends other than a pre-depends on awk.) Any comments? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120208200327.gj8...@codelibre.net
Re: Please test gzip -9n - related to dpkg with multiarch support
Guillem Jover guil...@debian.org writes: Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to sid generating a reproducible output across all current architectures. Time passes, compressor version N (and even O and P and Q etc) gets uploaded, which starts producing new ouput (on each of those versions). A new architecture gets added to Debian, and because previous compressor versions are not in the archive anymore, all packages built with them have different checksums than the new ones. This means *all* those packages have to be binNMUed across *all* the architectures, or the porters need to hunt down every specific compressor version used to build those packages to be able to reproduce the build on their arch. This seems highly suboptimal and “future-unproof”... Yes, agreed. I think this is a rather compelling argument against relying on reproducibility of compressor output. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87wr7xqdys@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
Roger Leigh rle...@codelibre.net writes: On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote: Also true. In fact, it's something that's been bothering me for a long time with linked doc directories. I'd like to prohibit them in more cases so that we get the binNMU changelogs on disk. Relating to binNMU changelogs: do they really serve any purpose? There are no source changes, so is there any real need for a changelog change at all? AFAICT the only reason we do for historical reasons, it being the only way previously to effect a version change. It seems weird not to have a record of *why* the package was rebuilt somewhere, but I guess I can't think of any reason why I would care off the top of my head. In the long run, I really like Guillem's point about making the changelog dpkg metadata. We could still put it somewhere on disk by default, but it would make things like this much cleaner conceptually, or at least it feels like it would on first glance. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874nv1rsko@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 08 Feb 2012 11:56:06 -0800
Russ Allbery r...@debian.org wrote:
There are two main cases for libfoo-dev that I think cover most such
packages:
1. The header files are architecture-dependent (definitions of data member
sizes, for example), in which case they need to be arch-qualified
anyway if you're going to allow multiple libfoo-dev packages to be
installed for different architectures.
2. The header files are architecture-independent, and the only
architecture-dependent content inside libfoo-dev is the static library.
So the symlink would have to move to the shared library alongside the
other symlink?
-dev:
./usr/lib/x86_64-linux-gnu/libgpelaunch.so - libgpelaunch.so.0.0.0
lib:
./usr/lib/x86_64-linux-gnu/libgpelaunch.so.0 - libgpelaunch.so.0.0.0
That's going to need a Replaces: in the lib against the -dev.
pkg-config files are also Multi-Arch sensitive:
libdir=${prefix}/lib/x86_64-linux-gnu
Those need to be in Multi-Arch paths:
./usr/lib/x86_64-linux-gnu/pkgconfig/libgpelaunch.pc
In this case, if you want to make libfoo-dev multi-arch, I would
advocate seriously considering just dropping the static library and
making the -dev package arch: all. I think static libraries are
increasingly of very questionable utility on a Linux system. But,
I would drop the .a but that doesn't mean I can make the -dev package
Multi-Arch: foreign.
foo-config binaries, as opposed to pkg-config files, are indeed going to
continue to be a problem in model 2, but they're a problem anyway, no?
... yes...
There's no guarantee that the amd64 and i386 version of a package will
want the same flags, so we really need some way of having a
multiarch-aware verson of the -config script.
It's not just amd64|i386, Multi-Arch - to me and probably Riku - is
about amd64|armel etc.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpbzC5ypYoUA.pgp
Description: PGP signature
Re: Please test gzip -9n - related to dpkg with multiarch support
Joey Hess jo...@debian.org writes: pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required to always produce the same compressed file for a given input file, and I can tell you from experience that there is a wide amount of variation. If multiarch requires this, then its design is at worst broken, and at best, there will be a lot of coordination pain every time there is a new/different version of any of these that happens to compress slightly differently. Maybe there was a reason for Guillem to want to tread carefully. I wanted to come back to this and make a quick comment on it since it's an important point. I completely agree there were very good reasons for Guillem to want to tread carefully. But I think that having a public alpha test and to have other people poking at it is critical, because otherwise that discussion has a tendency to only happen in the head of a few developers, with everyone else tending to assume there aren't problems. We collectively have a lot of wisdom and a lot of experience with edge cases, and I think we needed the project in general to get involved in this discussion. And in practice that usually doesn't happen until there's a thing that people can use and encounter problems with, and that feels like it might become the future unless people object or report bugs. And it also makes it clear what those problems are, so that people who are anxious to see the new features can see publicly what has to be dealt with first before they can be made available. My feeling is that this discussion is exactly the sort of outcome that I was hoping for from a public alpha test. We found a problem that wasn't completely thought-through, and now we're discussing it. It wasn't the *ideal* outcome, which would have been that everything was great and we could move forward into our happy Multi-Arch future, but it's an important and useful outcome. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87sjilqdrg@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 07:54:47PM +, Roger Leigh wrote: On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote: Guillem Jover guil...@debian.org writes: On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: And while the binNMU changelog issues might seem like a corner case, it's just a symptom of something that's not quite right. Also true. In fact, it's something that's been bothering me for a long time with linked doc directories. I'd like to prohibit them in more cases so that we get the binNMU changelogs on disk. Relating to binNMU changelogs: do they really serve any purpose? There are no source changes, so is there any real need for a changelog change at all? AFAICT the only reason we do for historical reasons, it being the only way previously to effect a version change. We briefly discussed on #debian-buildd last week whether it was possible to use --changes-option to override the distribution during building. If it is also possible to override the version of the generated .debs, this would make it possible to rebuild (NMU) without messing around editing the changelog. There are some source packages that always generate binary versions different from the source version, e.g. linux-latest. They must currently use dpkg-parsechangelog to get the default binary version. If the binNMU is not mentioned in the changelog they would get the source version and would not include any binNMU suffix in the generated binary versions. We could make dpkg-parsechangelog obey a version override too, but it's rather ugly! (Hmm, it looks like linux-latest runs dpkg-parsechangelog at source package build time so it's not binNMU-safe now. But this is fixable so long as dpkg-parsechangelog makes binNMUs recognisable.) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120208202317.gd12...@decadent.org.uk
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 11:56:06 -0800, Russ Allbery wrote: Riku Voipio riku.voi...@iki.fi writes: That is a major waste of space of having multiple copies of identical files with different arch-qualified names. Is that really better architecture to have multiple copies of identical files on user systems? Is it really, though? The files we're talking about are not generally large. I have a hard time seeing a case where the files would be large enough to cause any noticable issue and you wouldn't want to move them into a separate -common or -doc package anyway. Exactly, in addition this is already an “issue” with lots of packages (regardless of multi-arch) which do not use a common symlinked doc dir. These are some numbers I'm getting on my system (w/ the attached quickly hacked up script), all wild approximations, just to get a feel of it: Approx. installed m-a:same lib waste (w/o -dev,-doc): 20051501 Approx. installed m-a:same lib waste (w/ -dev,-doc): 23310229 Approx. installed m-a:same lib waste per package (23310229 / 293): 79557.09 Approx. predicted lib waste per arch (779 * 79557.09): 61974973.11 Approx. total lib waste per arch (4003 * 79557.09): 318467031.27 So, supposedly, if all possible libs were to be multiarchified I'd waste 60 MiB in case I wanted to have all of them installed for each architecture I enable. Which is not going to be the case. But if it was and 60 MiB were such a problem I could just as well use «dpkg --exclude-path» support. Also I think there's problably some room for improvement which would benefit non-multiarch installations too. For example TODO, USAGE and lots of similar files should be moved to the -dev packages. AUTHORS THANKS and CREDITS files should probably be already represented in copyright, etc. Provably a lintian warning could be introduced for this. regards, guillem #!/bin/sh echo List of files that might be candidates to be split out grep-status -n -sPackage -FMulti-Arch same | \ egrep -v -e '-(dev|doc)' | xargs dpkg -L | grep '\/usr\/share\/' | \ egrep -v '(copyright|changelog|NEWS|README)' | \ while read f; do test -f $f printf $f\0; done | \ du -bsch --files0-from - waste_libs=$(grep-status -n -sPackage -FMulti-Arch same | \ egrep -v -e '-(dev|doc)' | xargs dpkg -L | grep '\/usr\/share\/' | \ while read f; do test -f $f printf $f\0; done | \ du -bc --files0-from - | tail -n 1 | cut -f1) echo Approx. installed m-a:same lib waste (w/o -dev,-doc): $waste_libs waste_same=$(grep-status -n -sPackage -FMulti-Arch same | \ xargs dpkg -L | grep '\/usr\/share\/' | \ while read f; do test -f $f printf $f\0; done | \ du -bc --files0-from - | tail -n 1 | cut -f1) echo Approx. installed m-a:same lib waste (w/ -dev,-doc): $waste_same inst_same=$(grep-status -n -sPackage -FMulti-Arch same|wc -l) waste_per_lib=$(echo scale=2; $waste_same / $inst_same | bc -l) echo Approx. installed m-a:same lib waste per package ($waste_same / $inst_same): $waste_per_lib inst_libs=$(grep-status -n -r -sPackage -FSection libs| \ egrep -v '(common|data|-bin)'| wc -l) waste_inst=$(echo scale=2; $inst_libs * $waste_per_lib | bc -l) echo Approx. predicted lib waste per arch ($inst_libs * $waste_per_lib): $waste_inst total_libs=$(grep-aptavail -n -r -sPackage -FSection libs| \ egrep -v '(common|data|-bin)'| wc -l) waste_total=$(echo scale=2; $total_libs * $waste_per_lib | bc -l) echo Approx. total lib waste per arch ($total_libs * $waste_per_lib): $waste_total
Re: Please test gzip -9n - related to dpkg with multiarch support
* Ben Hutchings b...@decadent.org.uk, 2012-02-08, 20:23: Relating to binNMU changelogs: do they really serve any purpose? There are no source changes, so is there any real need for a changelog change at all? AFAICT the only reason we do for historical reasons, it being the only way previously to effect a version change. We briefly discussed on #debian-buildd last week whether it was possible to use --changes-option to override the distribution during building. If it is also possible to override the version of the generated .debs, this would make it possible to rebuild (NMU) without messing around editing the changelog. There are some source packages that always generate binary versions different from the source version, e.g. linux-latest. They must currently use dpkg-parsechangelog to get the default binary version. If the binNMU is not mentioned in the changelog they would get the source version and would not include any binNMU suffix in the generated binary versions. We could make dpkg-parsechangelog obey a version override too, but it's rather ugly! (Hmm, it looks like linux-latest runs dpkg-parsechangelog at source package build time so it's not binNMU-safe now. But this is fixable so long as dpkg-parsechangelog makes binNMUs recognisable.) Right. What we want to change is not how debian/changelog is being modified by build software, but what happens to it when it lands in /usr/share/doc/$pkgname/. Packages could simply split debian/changelog into two parts: /u/s/d/$p/changelog(.Debian).gz - the architecture-independent part; /u/s/d/$p/changelog.binNMU-$arch.gz - the binNMU part. That would have to be implemented in dh_installchangelogs and a few M-A:same that don't use debhelper. -- Jakub Wilk -- 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/20120208203432.ga4...@jwilk.net
Re: Comments on introducing a new Essential package: base-init?
On 2012-02-08 21:03 +0100, Roger Leigh wrote: This is regarding Bug #645540 (Essential package conflict between sysvinit and systemd-sysv). sysvinit is currently Essential. In order to permit the replacement of sysvinit with an alternative init system, I'd like to propose the creation of a new Essential package base-init, with a Depends on sysvinit | init, where init is a virtual package provided by all packages providing /sbin/init. This would be provided by sysvinit, systemd, upstart, etc. Assuming they all provide /sbin/init, they need to conflict with each other, right? In that case, switching init systems has the dangerous effect that apt will remove the current provider before unpacking the replacement, leaving a window where /sbin/init does not exist. Sounds rather dangerous to me. Cheers, Sven -- 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/874nv19hk9@turtle.gmx.de
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 09:02:43PM +0100, Guillem Jover wrote: Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to sid generating a reproducible output across all current architectures. Time passes, compressor version N (and even O and P and Q etc) gets uploaded, which starts producing new ouput (on each of those versions). A new architecture gets added to Debian, and because previous compressor versions are not in the archive anymore, all packages built with them have different checksums than the new ones. This means *all* those packages have to be binNMUed across *all* the architectures, or the porters need to hunt down every specific compressor version used to build those packages to be able to reproduce the build on their arch. You are making assumption that compressor versions M, N, O, P and Q happen during a timeframe shorter than libraries are uploaded/binNMU'd in debian. Gzip development is glacial. Last upstream version changing uploads in Debian were 1.3.12 in 2007 and 1.4 in 2011. Most changes in gzip code shouldn't even affect the output of gzip -n9, as they are mostly fixes to make gzip build in world changing around it. New architectures don't happen every day, while library maintaincene does. Throwing away the Allow identical files on Multi-Arch: same convinience for library maintainers to make including new architectures a bit easier is a bit daft tradeoff. -- 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/20120208205724.ga7...@afflict.kos.to
Re: Please test gzip -9n - related to dpkg with multiarch support
* Guillem Jover guil...@debian.org, 2012-02-08, 21:02: Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to sid generating a reproducible output across all current architectures. Time passes, compressor version N (and even O and P and Q etc) gets uploaded, which starts producing new ouput (on each of those versions). A new architecture gets added to Debian, and because previous compressor versions are not in the archive anymore, all packages built with them have different checksums than the new ones. This means *all* those packages have to be binNMUed across *all* the architectures, or the porters need to hunt down every specific compressor version used to build those packages to be able to reproduce the build on their arch. In practice, the only compressor we need to care is gzip, which is not actively maintained upstream[0]. Chances that a new version of it will break large number of packages are minute. But anyway, I believe that in the long run we should simply deprecate compressing stuff in /usr/share/doc/. [0] From http://lists.gnu.org/archive/html/bug-gzip/2010-02/msg00044.html: [...] gzip is in maintenance-only mode. [...] I am working on gzip solely to fix bugs and maintain a certain level of portability and robustness. -- Jakub Wilk -- 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/20120208210123.ga5...@jwilk.net
Re: Comments on introducing a new Essential package: base-init?
On Wed, Feb 08, 2012 at 09:49:26PM +0100, Sven Joachim wrote: On 2012-02-08 21:03 +0100, Roger Leigh wrote: This is regarding Bug #645540 (Essential package conflict between sysvinit and systemd-sysv). sysvinit is currently Essential. In order to permit the replacement of sysvinit with an alternative init system, I'd like to propose the creation of a new Essential package base-init, with a Depends on sysvinit | init, where init is a virtual package provided by all packages providing /sbin/init. This would be provided by sysvinit, systemd, upstart, etc. Assuming they all provide /sbin/init, they need to conflict with each other, right? In that case, switching init systems has the dangerous effect that apt will remove the current provider before unpacking the replacement, leaving a window where /sbin/init does not exist. Sounds rather dangerous to me. This is a good point, but is there a safer alternative? Upstart and systemd currently have a Replaces: sysvinit to replace it outright, but it still requires sysvinit to be installed in the first place, and it is still Essential. Any alternative init system is required to do this, and it would be ideal to have a means of removing sysvinit entirely. If there's a way which does not involve a virtual package, we could do that--I guess it's not strictly necessary, but it does avoid the need for init-providers to explicitly conflict/replace each other. For example, upstart currently conflicts/replaces sysvinit /anyway/, so it's not like the virtual package would introduce a window of breakage which is not already present today. Obviously, a perfectly safe and clean solution would be preferred! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120208210910.gl8...@codelibre.net
Re: Please test gzip -9n - related to dpkg with multiarch support
On 2012-02-08, Russ Allbery r...@debian.org wrote: There are two main cases for libfoo-dev that I think cover most such packages: 3) to ensure that things can keep working on slow archs while they build a new edition of src:foo /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/slrnjj5q48.p7v.nos...@sshway.ssh.pusling.com
Re: Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]
Hi, Am 08.02.2012 08:27, schrieb Raphael Hertzog: What's difficult in implementing this? I haven't found cocumentation how to correctly move conffiles from one package to another. Neither at [1] nor the dpkg-maintscript-helper man page. As mentioned, a simple Replaces in the newly split-off package is not sufficient, as you will have obsolete conffiles, in case the new split-off package is not installed. I've seen this problem a couple of times and I thought it would be worthwile getting a best practice for this case documented. You can't really use dpkg-maintscript-helper conditionnaly because the installation state of bootlogd might change between preinst and postinst but you could at least remove the (unmodified) files in postinst if you see that bootlogd is not at least unpacked (usage of dpkg-query in maintainer scripts is safe). It would be awesome, if the aforementioned wiki and/or the dpkg-maintscript-helper man page would document how to do this which a short example. Could you give a short example how postinst would look like for the case that package foo is split int foo in version 1.0-1 and bar takes over the conffile /etc/baz.conf from foo. I'm still not quite sure which states I should check for using dpkg-query. Cheers, Michael [1] http://wiki.debian.org/DpkgConffileHandling -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- 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/4f32e903.6080...@debian.org
Re: Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]
Am 08.02.2012 22:28, schrieb Michael Biebl: Could you give a short example how postinst would look like for the case that package foo is split int foo in version 1.0-1 Making the example a bit more verbose: before the split: binary package foo: /bin/foo /bin/bar /etc/foo.conf /etc/bar.conf (both marked as conffiles) after the split (done in version 1.0-1): binary package foo: /bin/foo /etc/foo.conf binary package bar: /bin/bar /etc/bar.conf Package foo in version 1.0-1 does not have a dependency on bar, so bar is not guaranteed to be installed. There is also the case, where bar has been split off upstream into a separate src package, but I assume this can be handled equally. Now I'm interested how the maintainer scripts have to look like, so we don't get any obsolete conffiles in foo. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- 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/4f32eae9.8040...@debian.org
Re: Please test gzip -9n - related to dpkg with multiarch support
Neil Williams codeh...@debian.org writes:
Russ Allbery r...@debian.org wrote:
There are two main cases for libfoo-dev that I think cover most such
packages:
1. The header files are architecture-dependent (definitions of data member
sizes, for example), in which case they need to be arch-qualified
anyway if you're going to allow multiple libfoo-dev packages to be
installed for different architectures.
2. The header files are architecture-independent, and the only
architecture-dependent content inside libfoo-dev is the static library.
So the symlink would have to move to the shared library alongside the
other symlink?
-dev:
./usr/lib/x86_64-linux-gnu/libgpelaunch.so - libgpelaunch.so.0.0.0
lib:
./usr/lib/x86_64-linux-gnu/libgpelaunch.so.0 - libgpelaunch.so.0.0.0
Oh, good point, I'd forgotten that for multiarch the symlink is
architecture-dependent. So yes, the -dev package is inherently
architecture-dependent.
We can't move the symlink to the shared library package because then the
shared library packages aren't co-installable.
pkg-config files are also Multi-Arch sensitive:
libdir=${prefix}/lib/x86_64-linux-gnu
Those need to be in Multi-Arch paths:
./usr/lib/x86_64-linux-gnu/pkgconfig/libgpelaunch.pc
Correct. Anyone converting a library to multiarch should already be
moving them, IMO. I have with all of mine.
I would drop the .a but that doesn't mean I can make the -dev package
Multi-Arch: foreign.
You're right. -dev packages are going to have to be multi-arch: same.
I think the hardest problem is then going to be the documentation
(including man pages) that are normally now in the -dev package, and any
-config scripts or the like. We already have multiarch path solutions for
header files and for the symlinks, although it requires duplicating the
header files for each architecture.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
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/87d39pq9ph@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 11:56:06AM -0800, Russ Allbery wrote: Riku Voipio riku.voi...@iki.fi writes: On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote: The same principle that applies to all dpkg output to avoid ambiguity would apply everywhere, whenever there's a “Multi-Arch: same” package name that needs to be unambiguous, it just always gets arch-qualified. The rest would stay as they are. That is a major waste of space of having multiple copies of identical files with different arch-qualified names. Is that really better architecture to have multiple copies of identical files on user systems? Is it really, though? The files we're talking about are not generally large. I have a hard time seeing a case where the files would be large enough to cause any noticable issue and you wouldn't want to move them into a separate -common or -doc package anyway. So I had a look at the Ubuntu archive, which already has a large collection of packages converted to Multi-Arch: same, to provide some hard facts for this discussion. - 1219 binary packages are marked Multi-Arch: same - 2197 files are shipped in /usr/share by these packages, outside of /usr/share/doc - which, by and large, are files that can actually be shared between architectures. - These files are distributed between 47 different subdirectories: 703 ./usr/share/man 604 ./usr/share/ada 187 ./usr/share/lintian 185 ./usr/share/locale 93 ./usr/share/alsa 70 ./usr/share/gtk-doc 53 ./usr/share/bug 36 ./usr/share/qt4 35 ./usr/share/libtool 22 ./usr/share/themes 16 ./usr/share/lua 16 ./usr/share/libphone-ui-shr 15 ./usr/share/aclocal 14 ./usr/share/icons 11 ./usr/share/pam-configs 11 ./usr/share/info 10 ./usr/share/vala 9 ./usr/share/gtk-engines 8 ./usr/share/qalculate 8 ./usr/share/OGRE 7 ./usr/share/xml 7 ./usr/share/libwacom 7 ./usr/share/gir-1.0 7 ./usr/share/dbconfig-common 6 ./usr/share/mupen64plus 6 ./usr/share/libgphoto2 5 ./usr/share/pixmaps 5 ./usr/share/openchange 4 ./usr/share/mime-info 4 ./usr/share/menu 4 ./usr/share/libofx4 4 ./usr/share/gstreamer-0.10 3 ./usr/share/java 3 ./usr/share/gconf 3 ./usr/share/gcc-4.6 3 ./usr/share/applications 2 ./usr/share/guile 2 ./usr/share/application-registry 1 ./usr/share/tdsodbc 1 ./usr/share/psqlodbc 1 ./usr/share/pascal 1 ./usr/share/libpam-ldap 1 ./usr/share/libmyodbc 1 ./usr/share/libaudio2 1 ./usr/share/kde4 1 ./usr/share/gst-plugins-base 1 ./usr/share/avahi - For many of these files, it would be actively harmful to use architecture-qualified filenames. Manpages included in -dev packages should not change names based on the architecture; having /usr/share/pam-config contain multiple files for the same profile, one for each architecture of the package that's installed, would not work correctly; etc. - If we needed to split the arch-indep contents out of the M-A: same package instead of reference counting in dpkg, that would be roughly 170 new binary packages. 139 of them would contain 10 files or less (exclusive of /usr/share/doc). I think there are pretty solid benefits to proceeding with a dpkg that allows sharing files across M-A: same packages. Even if we decided we couldn't rely on gzip, there are still lots of other cases where this matters. And besides, consider that a M-A: same package shipping contents in a non-architecture-qualified path that vary by architecture is *always* a bug in that package, which will need to be fixed. Requiring that M-A: same packages don't use non-architecture-qualified paths even for files which *don't* vary by architecture doesn't help much to ensure that we won't have bugs. It would be easier for lintian to spot errors in M-A: same packages if we can say that any file that doesn't have an architecture-qualified path is buggy, but at this point we already have Jakub's reports anyway, which we could make a regular part of our archive consistency checks. So I don't believe that having dpkg be more strict about files that *could* be shared will make the user experience any better; it just presents more occasions for packages to be regarded as buggy and for dpkg to error out. foo-config binaries, as opposed to pkg-config files, are indeed going to continue to be a problem in model 2, but they're a problem anyway, no? Yes, they definitely are. There's no guarantee that the amd64 and i386 version of a package will want the same flags, so we really need some way of having a multiarch-aware verson of the -config script. Preferably by s/foo/pkg/. pkgconfig gets this right, the standalone tools all get it wrong, there's no good reason not to just replace them with pkgconfig. -- Steve Langasek Give me a lever long
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 10:22:17AM +, Neil Williams wrote: After all, this is how cross/foreign architecture packages have *always* been handled in Debian via dpkg-cross. Nothing in /usr/share/ matters for a cross package created by dpkg-cross (with the possible exception of /usr/share/pkg-config which was always anachronistic). Some template files are added but the package name includes the architecture, so these files are effectively in multiarch paths. There is nothing useful in /usr/share of a Multiarch: same package when installed as foreign architecture package. Emdebian dpkg-cross have proved that by having nothing else until Multi-Arch. Anything you might need is in the native architecture package, so the best thing to do is widen the implicit exclusion to all of /usr/share in the incoming Multi-Arch: same package. The unfounded assumption here is that you will always install a foreign-arch M-A: same package together with the native-arch version. If I install libaudio2:i386 because I want to play a game that's only available as a 32-bit binary and has this lib as a dependency, and nothing else on my system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB installed. In general, anything that introduces assymetric handling between native and foreign arch packages at the dpkg level is probably going to be a bad idea. -- 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: Comments on introducing a new Essential package: base-init?
On Wed, Feb 08, 2012 at 08:03:27PM +, Roger Leigh wrote: An alternative would be for an existing Essential package such as base-files to provide the Depends, which would save the need for a separate base-init package. Is there any reason this would be undesirable? (I note that it currently has no depends other than a pre-depends on awk.) I think it would be better to avoid adding dependencies to base-files if possible. base-files is one of the super-Essential packages with special-case handling in debootstrap to install it very early indeed, unpacked and configured while even dpkg has still only been extracted; while that installation is done with --force-depends, I still think it would be worth keeping its dependency tree as trivial as possible. -- Colin Watson [cjwat...@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/20120208235309.gf3...@riva.dynamic.greenend.org.uk
Re: Please test gzip -9n - related to dpkg with multiarch support
Le Wed, Feb 08, 2012 at 07:54:47PM +, Roger Leigh a écrit : Relating to binNMU changelogs: do they really serve any purpose? There are no source changes, so is there any real need for a changelog change at all? AFAICT the only reason we do for historical reasons, it being the only way previously to effect a version change. Hi, I think that it is important for maintainers that who decided the binNMU and the reason for it are recorded in the changelog, because often these changes are not triggred or coordinated by the maintainers themselves. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med 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/20120209005416.gb17...@falafel.plessy.net
Re: Please test gzip -9n - related to dpkg with multiarch support
Steve Langasek vor...@debian.org writes: The unfounded assumption here is that you will always install a foreign-arch M-A: same package together with the native-arch version. If I install libaudio2:i386 because I want to play a game that's only available as a 32-bit binary and has this lib as a dependency, and nothing else on my system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB installed. How is that not a serious policy violation already? AuErrorDB isn't versioned with the SONAME, so libaudio2 and libaudio3 would not be coinstallable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874nv0n7vd@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: The unfounded assumption here is that you will always install a foreign-arch M-A: same package together with the native-arch version. If I install libaudio2:i386 because I want to play a game that's only available as a 32-bit binary and has this lib as a dependency, and nothing else on my system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB installed. How is that not a serious policy violation already? AuErrorDB isn't versioned with the SONAME, so libaudio2 and libaudio3 would not be coinstallable. Because libaudio2 is in the directory name. Also, it's not a policy violation for a library package to contain files that don't have sensibly versioned names; it's only a policy violation for the name to not change on soname bump. So even if this were called /usr/share/AuErrorDB, it could be changed to /usr/share/libaudio3/AuErrorDB on soname change and still be compliant. -- 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: Please test gzip -9n - related to dpkg with multiarch support
Steve Langasek vor...@debian.org writes: On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: The unfounded assumption here is that you will always install a foreign-arch M-A: same package together with the native-arch version. If I install libaudio2:i386 because I want to play a game that's only available as a 32-bit binary and has this lib as a dependency, and nothing else on my system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB installed. How is that not a serious policy violation already? AuErrorDB isn't versioned with the SONAME, so libaudio2 and libaudio3 would not be coinstallable. Because libaudio2 is in the directory name. Oh, duh. Sorry, I'm just blind. Also, it's not a policy violation for a library package to contain files that don't have sensibly versioned names; it's only a policy violation for the name to not change on soname bump. So even if this were called /usr/share/AuErrorDB, it could be changed to /usr/share/libaudio3/AuErrorDB on soname change and still be compliant. Good point. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87ty30iz9a@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
+++ Russ Allbery [2012-02-08 13:47 -0800]: Neil Williams codeh...@debian.org writes: Russ Allbery r...@debian.org wrote: Oh, good point, I'd forgotten that for multiarch the symlink is architecture-dependent. So yes, the -dev package is inherently architecture-dependent. I would drop the .a but that doesn't mean I can make the -dev package Multi-Arch: foreign. You're right. -dev packages are going to have to be multi-arch: same. I think the hardest problem is then going to be the documentation (including man pages) that are normally now in the -dev package, and any -config scripts or the like. We already have multiarch path solutions for header files and for the symlinks, although it requires duplicating the header files for each architecture. This part of the thread is getting into the general problem of what exactly the spec and guidelines to packagers should be for multi-arch -dev packages. We have purposely concentrated so far on the library packages in the detailed spec and left the -dev packaging details a bit vague to see exactly what the issues were. (and it is rather less important for -dev packages to actually be co-installable, because you can get by by just installing one or the other for cross- building purposes, although co-installability is definately desireable IMHO). I was thinking of starting a thread on this anyway soon, but as we are now discussing it anyway it might be a good time to go over the various issues. Some of the issues are already clear I think (moving arch-dependent headers into arch-qualified dirs, but leaving the others where they are), but the docs haven't cught up, and there are some trickier bits (like foo-config files where upstream don't want to move to pkg-config, and to what degree it is worthwhile making all -dev packages co-installable), that need some discusion and packages that probably just want splitting up (ones with a lot of binary utilities in). I'll start a new thread with some doc pointers and list of issues. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20120209013357.gh14...@dream.aleph1.co.uk
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 15:14:35 -0800, Steve Langasek wrote: So I had a look at the Ubuntu archive, which already has a large collection of packages converted to Multi-Arch: same, to provide some hard facts for this discussion. - 2197 files are shipped in /usr/share by these packages, outside of /usr/share/doc - which, by and large, are files that can actually be shared between architectures. - These files are distributed between 47 different subdirectories: 703 ./usr/share/man 11 ./usr/share/info 3 ./usr/share/java These three are always compressed so would need to be split anyway. 187 ./usr/share/lintian 53 ./usr/share/bug 4 ./usr/share/mime-info 4 ./usr/share/menu 3 ./usr/share/applications These should usually be pkgname based, thus can be just kept arch-qualified. I've not checked the rest in detail, but just with these, the 2197 files get reduced to 1229 which might not need moving out otherwise. - For many of these files, it would be actively harmful to use architecture-qualified filenames. Manpages included in -dev packages should not change names based on the architecture; having /usr/share/pam-config contain multiple files for the same profile, one for each architecture of the package that's installed, would not work correctly; etc. I said that arch-qualifying should apply for things that are currently pkgname based, but never that this should be used to avoid any file conflict, for the rest the correct solution would be to just split them out. - If we needed to split the arch-indep contents out of the M-A: same package instead of reference counting in dpkg, that would be roughly 170 new binary packages. 139 of them would contain 10 files or less (exclusive of /usr/share/doc). Given that several of those would need to be created regardless due to the many compressed files above, and several others do not need to be split at all, the resulting number of packages does not seem onerous to me at all, it actually seems like the right thing to do, after all. Riku mentioned as an argument that this increases the data to download due to slightly bigger Packages files, but pdiffs were introduced exactly to fix that problem. And, as long as the packages do not get updated one should not get pdiff updates. And with the splitting of Description there's even less data to download now. I think there are pretty solid benefits to proceeding with a dpkg that allows sharing files across M-A: same packages. Even if we decided we couldn't rely on gzip, there are still lots of other cases where this matters. While there's obviously some benefits, otherwise we'd not have considered shared files an option at all, I don't think they outweigh at all the problems and fragility they introduce. And besides, consider that a M-A: same package shipping contents in a non-architecture-qualified path that vary by architecture is *always* a bug in that package, which will need to be fixed. Requiring that M-A: same packages don't use non-architecture-qualified paths even for files which *don't* vary by architecture doesn't help much to ensure that we won't have bugs. It would be easier for lintian to spot errors in M-A: same packages if we can say that any file that doesn't have an architecture-qualified path is buggy, but at this point we already have Jakub's reports anyway, which we could make a regular part of our archive consistency checks. So I don't believe that having dpkg be more strict about files that *could* be shared will make the user experience any better; it just presents more occasions for packages to be regarded as buggy and for dpkg to error out. W/o automatic checks or actual installation testing any such issues can be introduced, this is not specific to M-A: same packages, we do have similar problems when moving files around two packages, or when stomping over other package namespaces, etc. Adding shared file support into dpkg, introduces additional uneeded complexity, that can never be taken out, and which seems clear to me should be dealt with at the package level instead. regards, guillem -- 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/20120209023428.ga6...@gaara.hadrons.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 22:01:23 +0100, Jakub Wilk wrote: In practice, the only compressor we need to care is gzip, which is not actively maintained upstream[0]. Chances that a new version of it will break large number of packages are minute. That assumes that we will never want to switch to a better/faster compressor for any gzip compressed file. Or that there's no existing files compressed with anything other than gzip. But anyway, I believe that in the long run we should simply deprecate compressing stuff in /usr/share/doc/. So the main reason people are arguing for shared files boils down to used size, either in installed files, or Packages files, etc, yet you want to fix the compression issue by not compressing them and using even more space? While this could benefit the multiarch installations (for which they can easily use --path-exclude), it would use lots more space on single arch installations. Also splitting files into new arch:all packages should usually reduce archive size usage for example. regards, guillem -- 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/20120209024549.gb6...@gaara.hadrons.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Feb 09, Steve Langasek vor...@debian.org wrote: I think there are pretty solid benefits to proceeding with a dpkg that allows sharing files across M-A: same packages. Agreed. Fix the tools instead of breaking the standard to adapt to broken tools. Myself, I like the idea of the implicit Replaces. -- ciao, Marco signature.asc Description: Digital signature
Accepted libcroco 0.6.4-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 09:03:04 +0100 Source: libcroco Binary: libcroco3-dev libcroco3 libcroco-tools Architecture: source amd64 Version: 0.6.4-1 Distribution: unstable Urgency: low Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org Changed-By: Martin Pitt mp...@debian.org Description: libcroco-tools - Cascading Style Sheet (CSS) parsing and manipulation toolkit - ut libcroco3 - Cascading Style Sheet (CSS) parsing and manipulation toolkit libcroco3-dev - Cascading Style Sheet (CSS) parsing and manipulation toolkit Changes: libcroco (0.6.4-1) unstable; urgency=low . [ Josselin Mouette ] * Stop marking libcroco3-dev as MA: same. * Mark libcroco-tools as MA: foreign. * Update repository URL. . [ Martin Pitt ] * debian/watch: Look for xz tarballs. * New upstream bug fix release. * Drop 02-format-security.patch, applied upstream. Checksums-Sha1: fa6a08af360639252ae34bde1bc96e8906d26662 2289 libcroco_0.6.4-1.dsc f9b8afed9e0b6b223128688b5de0e2c5a648bed5 461876 libcroco_0.6.4.orig.tar.xz bf1a11f533ce6cceae0cfab27e1269b772e7f4c2 4495 libcroco_0.6.4-1.debian.tar.gz 4cf8183c62aef314e9e723ae3fca57c56840d794 196910 libcroco3-dev_0.6.4-1_amd64.deb a59aaad9c92f2eef6ef6ac117421699f0a24512a 148972 libcroco3_0.6.4-1_amd64.deb 1c0876e4d8b26a7007800d3893449e079fa4ff9e 66494 libcroco-tools_0.6.4-1_amd64.deb Checksums-Sha256: dcca2b23cca618657ba4f9933d796525e1064c13385ae591b20871e1b0997b1a 2289 libcroco_0.6.4-1.dsc c816bad3406c52a98d84ac0e4a7b70ee0640b49cde4a236deaa02c4232ea 461876 libcroco_0.6.4.orig.tar.xz 7c97589b0ed5cf9e26cca5927f9e6fd2049f2bc7a3759b2adf8bc6afc5989f9a 4495 libcroco_0.6.4-1.debian.tar.gz 2a2ab1ae3e6ddb8ee388545bc6cbf7e3b8d2adc0f35afe0167fc41320b9c5c59 196910 libcroco3-dev_0.6.4-1_amd64.deb a87ba26935e0cef0f318c501f6cae2b81ed9bcc8a8275de5f3e7a0b29e45043f 148972 libcroco3_0.6.4-1_amd64.deb e41078f6d050c070cbb25abf7e7a700f56ee35b1322af782fc1e169b875779da 66494 libcroco-tools_0.6.4-1_amd64.deb Files: ac8c6de879ed266f1150e9d06717b0ad 2289 libs optional libcroco_0.6.4-1.dsc d49c20f1e9d9c85ac55429cd952af909 461876 libs optional libcroco_0.6.4.orig.tar.xz 59f8e46246dd7a02e1be2af533b26f58 4495 libs optional libcroco_0.6.4-1.debian.tar.gz 46d17a3d61c73630ad3f213a94253891 196910 libdevel optional libcroco3-dev_0.6.4-1_amd64.deb 1bf5ef7e38fc00bcc1324351514e4f36 148972 libs optional libcroco3_0.6.4-1_amd64.deb 574456f10ed694302771189153382b4e 66494 libs optional libcroco-tools_0.6.4-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMi0DAAoJEPmIJawmtHuf4PoP/Av+Sf6CRD1Lah1ZP6pH4HNz PSPfkX24oAR3XOEGNtVA+Y3WF8mHUFu9WrQ5NrRZyplDa9dAruDzJfxQ7UlpwwXs 6XE5C8C829+mMT6txrVyXFBB8ByF3tU4X5XuWsgvMkUd7bPBfI+LpEd6XXdZXnC6 3b0gxKg0WiDJ+5bx5BATCm+XHXPDw3ELnalYpPtWoLyYVqL+R+rqpPyMEFzuiJCx 5qMx2613ps0uQbzIqBKwF4gQWTHq2jQsRBdZXg0xd6vusZZn8CKXLjJr0ClkgqC/ bAE9arGgxcj7uN/I/i53A/uX/0V8fzG/SiAKoTK2mt5UfxRRWcTp9HOq3bsm5eID JW1FF+FgkxB6rtmn1s3bugeHKli+YRrmEsGeQumYQMwFf1pS5QGd8YLzTg/2xpnm BWtlSR4RGvuyaP0HkO99+VhpUr5lt6OFMmQUbgPgXeA0PSEuzbmmzVPDOhbXxqSJ zVKF6wltTwJOlkGn1vx/ZPD6rkFKtEWIN+t+FFSwrv2LpR/Ul8VMxEqU18Y3842g tTXTXTuWrjUhA/Bz97an6nA+AmmcfhTBVVRz5KFamoJE8dSmaSsCPazPFfv2aQdl makNjEQLEfhNw378A6EMCzYh1mNugiJCXlddJIeoMETir3f5rpuYISFLOsaW6ntR 4X361Hl+ysfWIllEATbm =8Vgn -END PGP SIGNATURE- Accepted: libcroco-tools_0.6.4-1_amd64.deb to main/libc/libcroco/libcroco-tools_0.6.4-1_amd64.deb libcroco3-dev_0.6.4-1_amd64.deb to main/libc/libcroco/libcroco3-dev_0.6.4-1_amd64.deb libcroco3_0.6.4-1_amd64.deb to main/libc/libcroco/libcroco3_0.6.4-1_amd64.deb libcroco_0.6.4-1.debian.tar.gz to main/libc/libcroco/libcroco_0.6.4-1.debian.tar.gz libcroco_0.6.4-1.dsc to main/libc/libcroco/libcroco_0.6.4-1.dsc libcroco_0.6.4.orig.tar.xz to main/libc/libcroco/libcroco_0.6.4.orig.tar.xz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv3fw-0005fh...@franck.debian.org
Accepted phpldapadmin 1.2.2-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 08 Feb 2012 08:52:18 +0100 Source: phpldapadmin Binary: phpldapadmin Architecture: source all Version: 1.2.2-1 Distribution: unstable Urgency: low Maintainer: Fabio Tranchitella kob...@debian.org Changed-By: Fabio Tranchitella kob...@debian.org Description: phpldapadmin - web based interface for administering LDAP servers Closes: 499862 502412 505575 505578 517802 521033 527070 605061 616305 622657 638680 642445 657458 Changes: phpldapadmin (1.2.2-1) unstable; urgency=low . [ Marcus Osdoba ] * Non-maintainer upload. * New upstream release (Closes: #605061,#499862,#505578,#517802,#642445) * Not reproducible in this version (Closes: #502412,#505575,#521033,#527070) * SF Bug #3477910 - XSS vulnerability in query * Remove dependency to unknown package libapache-mod-php5 * Fix lintian warnings in templates. * Remove apt-dependancy to apache2 (Closes: #622657) * Use | instead of # for sed used in config/postinst (Closes: #616305) * Add browser hint in package description (Closes: #527070) * Fix pending l10n issues. Debconf translations: - Danish (Joe Hansen). Closes: #638680 - Polish (Michał Kułach). Closes: #657458 * Bump standards to 3.9.2 * Use quilt as source format . [ Fabio Tranchitella ] * Uploaded work by Marcus Osdoba. Checksums-Sha1: 0bb28d6c81e5ed5a635ab6b5b51213646d4dda0b 1089 phpldapadmin_1.2.2-1.dsc 2904923eb25173d108b556c70fb3d42cd6e0e289 1415565 phpldapadmin_1.2.2.orig.tar.gz be0e24152a06fdf9918a99c3c7ccf9a07412755d 28741 phpldapadmin_1.2.2-1.debian.tar.gz 92f97aeda35508f6251063cbf45bb0f5d4456daf 1285776 phpldapadmin_1.2.2-1_all.deb Checksums-Sha256: 6e83aad1836abc4ab03fe0d3ffe9b65619ce04cfeae6abe9bf9ba367102dc983 1089 phpldapadmin_1.2.2-1.dsc 8629ea3f14630d4dd74099c997ac9795240a6417d5d124517ba5860c12d8a239 1415565 phpldapadmin_1.2.2.orig.tar.gz 07330328cf316d52646bb26ea794584038013224bdf11ab3e52d4c204900bcaf 28741 phpldapadmin_1.2.2-1.debian.tar.gz 99406b5e150b216d4d08e213e558d3904edf38ec9fe37d78c8f98fbdd10ba7e7 1285776 phpldapadmin_1.2.2-1_all.deb Files: acfce52a1ea0c86d35794f4320e9bb20 1089 admin extra phpldapadmin_1.2.2-1.dsc 78ca61eb5d7913963f8e42eb3b4f0e95 1415565 admin extra phpldapadmin_1.2.2.orig.tar.gz d0ec5c91f44734c519634a65cb8b632d 28741 admin extra phpldapadmin_1.2.2-1.debian.tar.gz d874a79a98f09f4ce62605be4b2ce5a6 1285776 admin extra phpldapadmin_1.2.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8yKhYACgkQK/juK3+WFWShjACZAd1NLL1uUikXPsAk0RV3stmv VMEAn1NRVQ3igEUzMkSZP61Qvn42Dlqr =ky8l -END PGP SIGNATURE- Accepted: phpldapadmin_1.2.2-1.debian.tar.gz to main/p/phpldapadmin/phpldapadmin_1.2.2-1.debian.tar.gz phpldapadmin_1.2.2-1.dsc to main/p/phpldapadmin/phpldapadmin_1.2.2-1.dsc phpldapadmin_1.2.2-1_all.deb to main/p/phpldapadmin/phpldapadmin_1.2.2-1_all.deb phpldapadmin_1.2.2.orig.tar.gz to main/p/phpldapadmin/phpldapadmin_1.2.2.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv3gh-0005lb...@franck.debian.org
Accepted pygtk 2.24.0-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 08:31:09 +0100 Source: pygtk Binary: python-gtk2 python-gtk2-dbg python-gtk2-dev python-glade2 python-gtk2-doc Architecture: source amd64 all Version: 2.24.0-3 Distribution: unstable Urgency: low Maintainer: Sebastien Bacher seb...@debian.org Changed-By: Michael Biebl bi...@debian.org Description: python-glade2 - GTK+ bindings: Glade support python-gtk2 - Python bindings for the GTK+ widget set python-gtk2-dbg - Python bindings for the GTK+ widget set (debug extension) python-gtk2-dev - GTK+ bindings: devel files python-gtk2-doc - Python bindings for the GTK+ widget set - documentation Closes: 659068 Changes: pygtk (2.24.0-3) unstable; urgency=low . [ Josselin Mouette ] * Replace python-gobject by python-gobject-2. * Update repository URL. . [ Michael Biebl ] * Tighten dependency between python-gtk2-dev and python-gtk2. Closes: #659068 Checksums-Sha1: b3ae5f1057b65d8057735c5dc2d4141724002d12 2797 pygtk_2.24.0-3.dsc 81cf6d9e57c34329b7cecfd3cf7a1a15ce04628e 16427 pygtk_2.24.0-3.debian.tar.gz 47631e1937cb517aacaf3ddcc522b2ebc56bdf06 1803524 python-gtk2_2.24.0-3_amd64.deb ae28ef6078803e0f960f0fa1604cbc25e12e838b 6930604 python-gtk2-dbg_2.24.0-3_amd64.deb 05bc57102961b935b2d452408ddf03c54b0538f0 45652 python-glade2_2.24.0-3_amd64.deb 5b92ee811a7f3315454505b869b5248c5565a39e 176880 python-gtk2-dev_2.24.0-3_all.deb 7237f810f2c109b5c37df25e88d739f254d278bf 1492712 python-gtk2-doc_2.24.0-3_all.deb Checksums-Sha256: 7cade3103bcf3ce7feecd8ded5d791abcd8d901c87b186781fa2c6edaf91705f 2797 pygtk_2.24.0-3.dsc 11cceb5a249c9f30fe62f4612d6f48a827f54944791c7eef8b2ad7382d65f5b3 16427 pygtk_2.24.0-3.debian.tar.gz e26cfa151968c85babeca7f2ad045e7c3e62dfcc3d7ecacd0c7287e133763498 1803524 python-gtk2_2.24.0-3_amd64.deb 766fc4813d4b3e3920e1de95a913835b870bd070f7a48cfb0691dedbaa48563f 6930604 python-gtk2-dbg_2.24.0-3_amd64.deb 4702f672ad333e9a8447d05417f08c0d928cbb533b770bd2c9418820941700cc 45652 python-glade2_2.24.0-3_amd64.deb 34006b0b2011f82c76cbea8f510188d9a0766ca5aae732382ecbe8a26fc818a7 176880 python-gtk2-dev_2.24.0-3_all.deb c86fdd40d51b880bffd562925215d3eaa406f89896af6eaedb8935c7949d56a7 1492712 python-gtk2-doc_2.24.0-3_all.deb Files: e783cfa3e885603a80aa6f9de1661513 2797 python optional pygtk_2.24.0-3.dsc b61cf079270ca1842b0cd92e1092be05 16427 python optional pygtk_2.24.0-3.debian.tar.gz 6c1dc23b53d5d1c2abb6841f4f9dda1d 1803524 python optional python-gtk2_2.24.0-3_amd64.deb b974d83bc34330c55d57150032481f8b 6930604 debug extra python-gtk2-dbg_2.24.0-3_amd64.deb 16ea1b4a8877446c7ac4df5127350f72 45652 python optional python-glade2_2.24.0-3_amd64.deb cfa2efdb149ef7d1a018fc4840c7ea86 176880 python optional python-gtk2-dev_2.24.0-3_all.deb 4fd26a8e1efb1853c0b45e6ecb4ff932 1492712 doc optional python-gtk2-doc_2.24.0-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMibuAAoJEGrh3w1gjyLcq40QAJHjAHOH9dgPk+EXrTPTNMb5 JPsQwNJ/UnqpHU2IQ2WzW1OSmfo6cl1G1g/CS9KCzLXo5vMBvV10uU02Myhqmgxp lMxDYHO4KtKmuSObf7SbmGKMsttvHbTwhe3JG3A9BBagHZk5Hl5az/k1ohjJl0JB p1NsnWzcmBe6crWzhNX0sLHR01QdQ87sq8VA7HUxF8MoGeAl7DytGE0R+E6qDFyx 9vtIsGq9qlCFYlVbUkh929oQJ0elmiGC3nYvjJBIvrf8kLeQZH8LI9e/VGjepJgt Epr3uaOUEnnsgODksivoZwKMeZ0spnvnwpbyyDhl6tr0KcMG18jEfwIBxcrams9N kN9EXOQXhX8rEpAKCrAoGVlqAf0iMdCLs6+Iwkn7jXlRWK1xxFlpsgEkhA56HyrD qR94c5bhn0/QQzA5g9NNCza7W2Lm7K1aBmcD8kDhIEzZtW34xUTAU4RfjNfM5hE3 Aeffb9yVw3VEclu8ed43hmtgs5GxfJTlF+0Q52sm3mnr+zhMVsMGep/BTieptODS peJ0J6x33TzDP/AKWUEKEiJZIdoBlhocnJnW1ipxyYnSBi/cocDk3l1jcViiJkRF d56TYx2XTR0HkN2ygURRFVeq+Whbedibxj5XqCF1hid+2MPMa7DmwM+Xph4dxC8H ssY95TKbNjzQcJfDiImp =uLUe -END PGP SIGNATURE- Accepted: pygtk_2.24.0-3.debian.tar.gz to main/p/pygtk/pygtk_2.24.0-3.debian.tar.gz pygtk_2.24.0-3.dsc to main/p/pygtk/pygtk_2.24.0-3.dsc python-glade2_2.24.0-3_amd64.deb to main/p/pygtk/python-glade2_2.24.0-3_amd64.deb python-gtk2-dbg_2.24.0-3_amd64.deb to main/p/pygtk/python-gtk2-dbg_2.24.0-3_amd64.deb python-gtk2-dev_2.24.0-3_all.deb to main/p/pygtk/python-gtk2-dev_2.24.0-3_all.deb python-gtk2-doc_2.24.0-3_all.deb to main/p/pygtk/python-gtk2-doc_2.24.0-3_all.deb python-gtk2_2.24.0-3_amd64.deb to main/p/pygtk/python-gtk2_2.24.0-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv3ho-0005zj...@franck.debian.org
Accepted dh-linktree 0.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:07:36 +0100 Source: dh-linktree Binary: dh-linktree Architecture: source all Version: 0.2 Distribution: unstable Urgency: low Maintainer: Raphaël Hertzog hert...@debian.org Changed-By: Raphaël Hertzog hert...@debian.org Description: dh-linktree - Create symlink trees within a Debian package Closes: 658423 Changes: dh-linktree (0.2) unstable; urgency=low . * dh_linktree(1): mention the requirement to use “dh --with linktree” if one wants dh to execute dh_linktree. Closes: #658423 Checksums-Sha1: e7b87e8bc137952993db6c2bd5d1fe22116b2ede 1600 dh-linktree_0.2.dsc 676cf6c6799361610eec387cf0e007468de522d7 5007 dh-linktree_0.2.tar.gz e15519dde4d0b6c52cdba1fc99332898516a6e0a 8950 dh-linktree_0.2_all.deb Checksums-Sha256: fcd8335a91817ee7d2dc9c75be000128775a05c55717c6b1d120148a9b28026a 1600 dh-linktree_0.2.dsc 078c2030aa818595ee63e1ae46906d9b0a124b26673c0984ab038dc612eb84cb 5007 dh-linktree_0.2.tar.gz c07feb5eabc9b6e443f04b7aa359d87e04f2657031437d3f2966201900d43014 8950 dh-linktree_0.2_all.deb Files: f3ae63ac294255910f23a03a7fbf3b04 1600 devel optional dh-linktree_0.2.dsc d360f8e7169e855fa69bef434470aa5c 5007 devel optional dh-linktree_0.2.tar.gz 4834ce1c29dab714caae0d096ccba133 8950 devel optional dh-linktree_0.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Signed by Raphael Hertzog iQIcBAEBCAAGBQJPMjwXAAoJEOYZBF3yrHKajL8P/0zuAVGGrXk2m/4R0aj7EMf1 8r7igX5uYTsNGUoz8bpCguNYDABr4LaQHNX+OgduhwG2csn+IFYC509ujF/tpDQm ydR0Pa+fWLDHXlonz7JgBjDwqi3oKNjgRjovmeWrycTksWioN34CfKH8qVpyvDG0 bCyJW6hY95jJ55pwfmOHOmbVz7E0QdnfVa92PuUMxTPd+YTUsQM/79uaBlY4J6Ny /qqVAsY7UcosgK122fYjeRzi8Spk74KATO7YH2sqjWu1DmGotyJy+h4QtwAGhi1L WFOcnCYofHr1b/EAUa5swicvXDOhgz6x0qZV72anqYXx6hFDNebtRg5zuJY/1Lbl 9qq0qIx0zNkYHYOdY+7bTfC6ePKG57iDnTr4La3P+7lpkYz2lrRcaPJI3Nu8APPV Bwi+P/tsljvUZpZdLgn2iIM6yFeSyEAmqK+tOgeYmGp8hGX+GCEde3VuhRKJiSi6 VA7p29aplw5Vwt+X2JWmPcemuGkkQabpN+gHS4CpTYhgoLch/78Ayp/Zm/VT4UiA ttFb746lGq0+G2+H4N+5hLNbYm66RK+y8wM075OJtC7zj4Uw5ZMhHbyjnoOcO+Ja lrDyxY9GhJc1EKTPagEpDw9OBoNTthwm8vp7BgUsgbSvgGrDgl8L3+MugBiJDzyf CduekRP2Fa3RRdjMzjGe =/81c -END PGP SIGNATURE- Accepted: dh-linktree_0.2.dsc to main/d/dh-linktree/dh-linktree_0.2.dsc dh-linktree_0.2.tar.gz to main/d/dh-linktree/dh-linktree_0.2.tar.gz dh-linktree_0.2_all.deb to main/d/dh-linktree/dh-linktree_0.2_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv3eq-8q...@franck.debian.org
Accepted pyabiword 0.8.0-10 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 08 Feb 2012 10:28:23 +0100 Source: pyabiword Binary: python-abiword Architecture: source amd64 Version: 0.8.0-10 Distribution: unstable Urgency: low Maintainer: Debian OLPC debian-olpc-de...@lists.alioth.debian.org Changed-By: Jonas Smedegaard d...@jones.dk Description: python-abiword - Python AbiWidget and TableWidget wrappers Closes: 658824 Changes: pyabiword (0.8.0-10) unstable; urgency=low . * Compile with --as-needed. Closes: bug#658824. Thanks to Dmitry Smirnov. * Drop build-dependencies now properly declared in libabiword*-dev and libwv*-dev (all of them except libjpeg-dev). See bug#656252, #656263. Checksums-Sha1: 83186e98fab759018b90aaa7510278e1ed915e7b 2073 pyabiword_0.8.0-10.dsc 265889bbad887f460f522faae3758b9da1d048d8 7569 pyabiword_0.8.0-10.debian.tar.gz 6179dd640fd0dc96e67b2d818ff83e8fd8d70253 52938 python-abiword_0.8.0-10_amd64.deb Checksums-Sha256: f28581303606d6fa98a3c9920a5bb8b48ea65032c6ea8801f37623114e1128db 2073 pyabiword_0.8.0-10.dsc fe2b823b82f460945b252964d0ad8e0d63aeb512b262e4f09dff562ee1e12576 7569 pyabiword_0.8.0-10.debian.tar.gz bf9435405dade63e9922b973b6c964d531759abbe9ac53da4f8cc6c5037b4b55 52938 python-abiword_0.8.0-10_amd64.deb Files: fa5a4affc75c3e6ea1f60fae4378c596 2073 python optional pyabiword_0.8.0-10.dsc fb3fd5f45ad6f5468cb24b1f7dd60551 7569 python optional pyabiword_0.8.0-10.debian.tar.gz 1f93a4669e7e324af671396a5d12fa9d 52938 python optional python-abiword_0.8.0-10_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPMkG/AAoJECx8MUbBoAEhRNAP/1NpNt1ZyI5gNfYZZ7j3EBRk ayU1hGRIgqp1tpSHJfDRB70DMVGmc+pu1D9PWeh2Z6obusx50hETXwKbOnwA5Kxl r9x7W6qBWmCCGKc4jjPSyk9wdeAcv97aCNFrhZxdWbS161ww75wuvesXf2HUKPuQ M5QLyL7A+D5iKzBdoDxNefQBBgNMBbipZxUez1Vg+IkDZr0kQDOkv/1UAN6B/tRF gORiUB8dodU0Z1SMpAiZf51Ijiel0mTcmXpQDGToUCcY0xMG1gIkChXmmzal8uzM +Kj1CaJlQ8Fu+wOSmcbDIoXlOt+/9TUfVDBHid+RRwCPM1h2pxZpIFps38PzF3bX iWlrVyu/rpv8dDLuNIkubZ0yl86mUes9C1NKIOWPz7HDKIC/SlXOoRuBr8Y/Z3/t G0ay9ELM1lCgVB4YZ80D85ndSmWRhtid3mIpK/f9X15VzGZaqTZCXuZr07+JsvqD StD9d+PzSZdHoSdTNwM8NhslJVXYPydk/ikMyhMh4U7KzC9/IZ13Ecq2APyD4ctR kzGLpgAjpBrwRuQuYr2bs0pu5Prc9GA1tV7XhjaVyZpusJ+Iv82VvxOzHLNblzff 4Vxfk5p1hTS5jStC4H4Wto6OPAbsWvtMJd3U5xZ+ZkeM8vdg8wa+vP1A1VTCmJpc Ayor0KXy2m2jSUx/Ge7Q =5Ugx -END PGP SIGNATURE- Accepted: pyabiword_0.8.0-10.debian.tar.gz to main/p/pyabiword/pyabiword_0.8.0-10.debian.tar.gz pyabiword_0.8.0-10.dsc to main/p/pyabiword/pyabiword_0.8.0-10.dsc python-abiword_0.8.0-10_amd64.deb to main/p/pyabiword/python-abiword_0.8.0-10_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv47y-0005ip...@franck.debian.org
Accepted swath 0.4.2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 08 Feb 2012 16:49:37 +0700 Source: swath Binary: swath Architecture: source amd64 Version: 0.4.2-1 Distribution: unstable Urgency: low Maintainer: Theppitak Karoonboonyanan t...@debian.org Changed-By: Theppitak Karoonboonyanan t...@debian.org Description: swath - Thai word segmentation program Changes: swath (0.4.2-1) unstable; urgency=low . * B-Dep on dpkg-dev 1.16.1, not 0.16.1. * Imported Upstream version 0.4.2 * Build-dep on debhelper = 9 and drop the lintian override * Update copyright years Checksums-Sha1: c1054b1526161d26910385fb88eb9e5e9ca637c0 1910 swath_0.4.2-1.dsc 9f57ffcad6a646b38994580f90383f1dbd9fe124 464268 swath_0.4.2.orig.tar.gz 7c2715a44d98dfb7f0c06e30a731de7909274d1a 4198 swath_0.4.2-1.debian.tar.gz 71654746eb6e13dea01ed11c6fac36b54005bb46 230588 swath_0.4.2-1_amd64.deb Checksums-Sha256: 90a57189d707472b12e507166854048faabcaa3cc593d86f51b752478124d9f6 1910 swath_0.4.2-1.dsc c306c979cb25103ee8fcf59d2f9e809a8b5e4da4a1bf49e6fe645803d389d133 464268 swath_0.4.2.orig.tar.gz 3dc14487757b34b50b275c6ee84354070114aebf77f9b243c8f9103ca69219e5 4198 swath_0.4.2-1.debian.tar.gz 5a6017e8a6946d561dfb27395007c061ec946263be42991b2876d92221c3319d 230588 swath_0.4.2-1_amd64.deb Files: 26603aa25902d7918a4521da54c37691 1910 text optional swath_0.4.2-1.dsc 9e82ff8ecc7a1b521d5098389fa8c70b 464268 text optional swath_0.4.2.orig.tar.gz d19c69e3eaacf629d7c21d21c52018e9 4198 text optional swath_0.4.2-1.debian.tar.gz ecec1caae31c47595eeb6c0ff024df1b 230588 text optional swath_0.4.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPMkeTAAoJEKLrrtG2+QJBpP0QAJpyAdhHv34J6FYvWMQj1EXM SvCzr4gH9SflKZxUqzevOj6qt3Tvs7vXoCTAtPPcGi+d7XpYplAFvmipnjJcuIlG KzD+cHOupgpbqnBUqhwECxy0S9iTNj/kqFcY7TdQePpRXMxEX0KhQlxbYM44RujP aGuFI8ebIXANQ0usHDHCB7fV/xOOPj7283LKcodEhR1QhtrSHepw553Nm3TQYTv5 wusYH4bo/dQfuQnJas/P673SF+OH0rden1WQpF4dJ/gsKXpKdaePMINE2NE7HOUb 1GtAWj+QttsAAfFV1urcTArzOOGSgkMx5YQSmTjbNGqsqTsvK/KLjRcxpv67rO3Y SUznSUTtMAib0ne2S5qVv6Co+UN1XBlrCXddE0Vc6yB1qjjkBw/kD6/73gJExgCp m/pu0SFG2EQlrr8ms4FdjLX3bMpOgNe161rEI3/BFXBUyXHIvJPufS3XIoJcokVC EBjyOCyA+yeHcyHLoYcNJYyPIJKnLIOR3WoJVKhnDB/LM1HdceoXI+LibsP7fMUl dABCGNNwYl/B3yozQYfIqaQ6hHppk9AgMajn2/wOrK26qH759DBrA4ZWKuxzoIYs EoLlGuvArmx12jEkSlubFw7kInXYE0ITvzSlV/GYsdmDK8f2rcrB5bHeiRTftxlp IJC+RRXh7Y/1eWK1hM7e =cJ5t -END PGP SIGNATURE- Accepted: swath_0.4.2-1.debian.tar.gz to main/s/swath/swath_0.4.2-1.debian.tar.gz swath_0.4.2-1.dsc to main/s/swath/swath_0.4.2-1.dsc swath_0.4.2-1_amd64.deb to main/s/swath/swath_0.4.2-1_amd64.deb swath_0.4.2.orig.tar.gz to main/s/swath/swath_0.4.2.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv4b0-0008eu...@franck.debian.org
Accepted zita-at1 0.2.3-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 08 Feb 2012 11:03:56 +0100 Source: zita-at1 Binary: zita-at1 Architecture: source amd64 Version: 0.2.3-2 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Changed-By: Alessio Treglia ales...@debian.org Description: zita-at1 - JACK autotuner Changes: zita-at1 (0.2.3-2) unstable; urgency=low . * Adapt to new zita-resampler's API. * Bump requirement on libzita-resampler-dev to 1.1.0. * Update debian/copyright. Checksums-Sha1: 71857d104b1d5afa8d018fe03150e91e5ff8b7d1 2162 zita-at1_0.2.3-2.dsc 55a9385e7c996d6c51078c3a82bf0407049a2334 3722 zita-at1_0.2.3-2.debian.tar.gz e9d405708ab5b8869efe36a4c096b1bc4102acca 54462 zita-at1_0.2.3-2_amd64.deb Checksums-Sha256: 3f915a8646b8035de9568ba52016f0f5e3d8bb67d962ed2361290d0b7673 2162 zita-at1_0.2.3-2.dsc 0c29dcfae77d5cc45acb31a9aab4464a279685b199c6e765589cefe10ca7e71a 3722 zita-at1_0.2.3-2.debian.tar.gz 285ec14c1dbc42da5d0a56b02383b984c6e34518a5949858e9dd9a0146623402 54462 zita-at1_0.2.3-2_amd64.deb Files: 203fdd7bf9fc268b89c13c9a55756f72 2162 sound optional zita-at1_0.2.3-2.dsc eddd7c052a3cd85f5ba91c7d9e74d34c 3722 sound optional zita-at1_0.2.3-2.debian.tar.gz f0d5d1f2dcc54a1fbe14f997206f672b 54462 sound optional zita-at1_0.2.3-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPMkpqAAoJEOikiuUxHXZac5IQAI8XYl+hZ/T820wr12XioudE OdWGI+auakcOXK0k+mUYEn2CFoW8hkXQdDAmaYsr5QmSoNavlRT+i4LROkfCpZz5 ta3qohXOM7VewbvVjkMpnIAeLZ4Ep3g34OZpmOs46a2igzr7ojqJ5aI0SSMyuKBS VNBDOiz8GC8CezCXW4Q+p2XwvxAmcxMqqrVIjQnSRdR2hql4vioP+6wPVVUYTPye FP272EZdgeOLJcoUNxpZb7K7dD53EkDI57Y12GcYQHT1l4JsGzBNDYOsBn19Ym+J 0bFhz5wVOEAKIVo4ts5DpJ4BFq2q/L8XBKbpVdKcKYxs9+SaEUPFY0aVIiq2eFZp AJVHouSKcP5K6s1cvK6m/dUzLGR9cTh298wWPDCRBPHaKui8Rh0P+uQ0K74ftSF8 rdFtLN/QCI0Oij5YJdMZHoE2heCVjkrjeCbb5Fw0jzn8MANPaXzG8bdtkY7gJAyp AsZlgirg9qwFiQhr/MPJZHhZSDxjg850nvlPoEYwcv4zlIUKbikKvIY0+MLhwwO2 v519H6mbji0GNJRZ4XBW3LqqFL6jhlys0vfKwh5mcGgkRoQTOC5DqPxYHKu1MRa7 1u3LqBg13QBfvwpZSU3nlvwSiO9U5tHI1GuLPSoR7Nt2bJkJiFF6mzUInnUNJnC0 UVGZPxW8LxZ1I1rEqVoz =Kzr3 -END PGP SIGNATURE- Accepted: zita-at1_0.2.3-2.debian.tar.gz to main/z/zita-at1/zita-at1_0.2.3-2.debian.tar.gz zita-at1_0.2.3-2.dsc to main/z/zita-at1/zita-at1_0.2.3-2.dsc zita-at1_0.2.3-2_amd64.deb to main/z/zita-at1/zita-at1_0.2.3-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv4bi-0008gh...@franck.debian.org
Accepted gxtuner 2.0-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 08 Feb 2012 11:19:27 +0100 Source: gxtuner Binary: gxtuner Architecture: source amd64 Version: 2.0-2 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Changed-By: Alessio Treglia ales...@debian.org Description: gxtuner- Tuner for Jack Changes: gxtuner (2.0-2) unstable; urgency=low . * Team upload. * Bump requirement on libzita-resampler-dev to 1.1.0. * Adapt gxtuner to zita-resampler's new API. Checksums-Sha1: 00afdd422f4f906ca6e43b7dad3a2c1dffbddaec 2022 gxtuner_2.0-2.dsc c427b325854bb946029b7e5e546d043e637fafd8 6486 gxtuner_2.0-2.debian.tar.gz e7da4bfdcf92a8bde58d3af34a038f718e9971c2 44240 gxtuner_2.0-2_amd64.deb Checksums-Sha256: 3447864048a63cdeb0ab509ad59ee0e3691c68be88fdd90b3a0c983b4d81bfb2 2022 gxtuner_2.0-2.dsc 26a3d8e5b421f0ebb070d5417f2611e321a6a7dd1ea0f42ef0d255a6fa7d518f 6486 gxtuner_2.0-2.debian.tar.gz 726a5e0995ef3ed4f25c11f57588922c16e2da9babba19060d354b75d10f0253 44240 gxtuner_2.0-2_amd64.deb Files: 1ca8867789c4827075b47e3b3c4fa5cc 2022 sound optional gxtuner_2.0-2.dsc dc2d856017395ef47862519060db0b38 6486 sound optional gxtuner_2.0-2.debian.tar.gz 4cdc2ed95398fe3c8219eaf32e534384 44240 sound optional gxtuner_2.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPMk4bAAoJEOikiuUxHXZa1u4P/3ahoXudVjMh1MFgav9v+L/T oijMJtgOyUpQtMjYn9lIBKr49Xchnp9yZ8N6iTuzfIQQUoELHSX9X0AONacMG56x GmDGIuIFH+2X+HJcL+jKycQLgNUn+ycYSNPIGS6RkSzFvW54SRu36ZKRLs4c2OAh MQdevPSJ7WAxD02jemVOLaf5QY89lrx/4KojoEEP+X83ahDmtmOn6mGzalnjpIZI onRNhBLwS4fnKeJlcWjQLdsO5A8kZUgIEKSGcyteloPMPe/XAtoBiR11nvXTN/5s uIeC5ESQpNqTcewb9nJwHz6hzKtPbgfMt6dYi2XHysGa7b5lk0cPT9btNEOqghHy +gRS28dS5z0+8n+sjH6JMWLl4++ZyJdblLte2f+iqLSjMPJkCONKhNtCKyTboOG9 slE3W56bpB1p5jHTrv90wWp9uZiHjm7BRQt4VUTNUb0T+DMMWg8UwIUOM7p64rb5 bLQ2tpYIXXm/zwUo0jkGR9rrBspwwXwf6aLp6V/PHC8N5QDMN7AN3CTkYJe5slgb e4ulkl/qVFjwUauySDmOPPHKkSN6o3dfcMDeIbMq5Dtm+GiHiuS38f08PIvNHXWe J7TESrwPPG2Hsi37tb3MUvvQ/w+ZDGNj6X11NsAuc8jfkVfQejKNzrD5VeG4NC4z fCQcIDk3rJeg+MKxrXIf =5t40 -END PGP SIGNATURE- Accepted: gxtuner_2.0-2.debian.tar.gz to main/g/gxtuner/gxtuner_2.0-2.debian.tar.gz gxtuner_2.0-2.dsc to main/g/gxtuner/gxtuner_2.0-2.dsc gxtuner_2.0-2_amd64.deb to main/g/gxtuner/gxtuner_2.0-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv4ou-00019q...@franck.debian.org
Accepted haskell-augeas 0.4.0-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:44:36 + Source: haskell-augeas Binary: libghc-augeas-dev libghc-augeas-prof libghc-augeas-doc Architecture: source all amd64 Version: 0.4.0-2 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-augeas-dev - Haskell bindings for the augeas library libghc-augeas-doc - Haskell bindings for the augeas library; documentation libghc-augeas-prof - Haskell bindings for the augeas library; profiling libraries Changes: haskell-augeas (0.4.0-2) unstable; urgency=low . * Sourceful upload to rebuild doc package Checksums-Sha1: a25703948babcf0ce0227e79b36ade4f7e95a664 2223 haskell-augeas_0.4.0-2.dsc 3c06883917c3caf6fa16d34407ece9255237eef7 2288 haskell-augeas_0.4.0-2.debian.tar.gz a94368ba98e2d40b7f6db73773892d50bac8a7dd 55834 libghc-augeas-doc_0.4.0-2_all.deb 7b42379609ef51f14d4a53d782d6e27423a163b5 53788 libghc-augeas-dev_0.4.0-2_amd64.deb 7e7489b5ae231fe75a083967f1ab9524b373ecf4 48722 libghc-augeas-prof_0.4.0-2_amd64.deb Checksums-Sha256: 0ebea45b245d87ea005bac7516df3056afb723956dc53c6f6995f758375c3a77 2223 haskell-augeas_0.4.0-2.dsc 59af2fde5adee6ed15fab9950885aab883c0368fb48eab5e0b1e1308c439a785 2288 haskell-augeas_0.4.0-2.debian.tar.gz 4fc4b6898df81e2996ddcc6014276378c55f274276a6911c6913f9eff693e681 55834 libghc-augeas-doc_0.4.0-2_all.deb 9a3b7f22d3c2220ae0fab0b318614fa1e85565db5dadab3d0a8172c244a58ab7 53788 libghc-augeas-dev_0.4.0-2_amd64.deb 6450e4c915a914ed5a55a4dc1200e02ee9ba53f37581cd3911624fb3da33455e 48722 libghc-augeas-prof_0.4.0-2_amd64.deb Files: 930dc40d16ced92ac2a139fc7b4545aa 2223 haskell extra haskell-augeas_0.4.0-2.dsc 32e49c6ac77890881f9639a6b98cb35e 2288 haskell extra haskell-augeas_0.4.0-2.debian.tar.gz e3a85d8b1e52b7bd9e52c6f18c9a2b33 55834 doc extra libghc-augeas-doc_0.4.0-2_all.deb 3aeca352fd1df3c1e3f399f41d6661a6 53788 haskell extra libghc-augeas-dev_0.4.0-2_amd64.deb 4e7f06017e03e0e98823d458a8d7a6ee 48722 haskell extra libghc-augeas-prof_0.4.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMlKiAAoJEONS1cUcUEHUR+8P/Rifc8wMw0ZMMkrIzz0fplkl I1Xiet/H/p1kL0ZOUxnXUZSuPORVeFVq/CZKVWh/QPzSR2PIzrcW9IRqK44WtlNi I+5+RyvCJmD9gbWzlZf1cr7sG8AwbfkstBWan0rmIgZ8QOFhH5Aa2BMGCiV04BqT TqvQVxj6dvewIPPx5aCY5VO6p7FOT0b8bMQnGpnk4LalfrIImNOlVhFff2500cIe fPk5J9/6nSZcmMjF9TbmnfmWb7sdgsdBQT5505IgpK1G/WecixfkZavX+2K39Pb4 FZqjzg+CHtfGE0tRbaWKTNsd9sH8weZ7vwwbcLMLvjiAAOkkQXCzc1jSSx1sycc+ jWQ3WRWZ9Ztph3IZaaFsj0P1h3LkibwfTxt4oEaToqzaAILSEXmfgMyMVBSXrBVu AsagE/gfv13AXZOh4FLiir84XUiCLWPjFD9uMHEvCI3zITttkPDeUebUxA7YLrfQ L1aHbhWvt8sd7cXPlkjXJ7vuoL3ucwhvKiKAqBI4EZxVpaJ2XpwI2UcqywJbYeFa zGDO2NJ1PHhSk0/4ZPssALOjvo2vwemYTLo3QKT2CmQdBi1XOhNvvCMSP+xc5qoE fWEsC0K6nQCjMJo5Zi3bL+Sz6i36ogkxbMnmbBpxVKfk+p08EHCqLISY9UC6MtPc MCQ84cPyfkE3BE7VpYKt =9vgp -END PGP SIGNATURE- Accepted: haskell-augeas_0.4.0-2.debian.tar.gz to main/h/haskell-augeas/haskell-augeas_0.4.0-2.debian.tar.gz haskell-augeas_0.4.0-2.dsc to main/h/haskell-augeas/haskell-augeas_0.4.0-2.dsc libghc-augeas-dev_0.4.0-2_amd64.deb to main/h/haskell-augeas/libghc-augeas-dev_0.4.0-2_amd64.deb libghc-augeas-doc_0.4.0-2_all.deb to main/h/haskell-augeas/libghc-augeas-doc_0.4.0-2_all.deb libghc-augeas-prof_0.4.0-2_amd64.deb to main/h/haskell-augeas/libghc-augeas-prof_0.4.0-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv5jh-0004wt...@franck.debian.org
Accepted electricsheep 2.7~b12+svn20091224-1.1 (source armhf)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 03 Feb 2012 11:50:38 +0200 Source: electricsheep Binary: electricsheep Architecture: source armhf Version: 2.7~b12+svn20091224-1.1 Distribution: unstable Urgency: low Maintainer: Roberto C. Sanchez robe...@connexer.com Changed-By: Konstantinos Margaritis mar...@debian.org Description: electricsheep - screensaver showing collective dream of sleeping computers Closes: 621985 Changes: electricsheep (2.7~b12+svn20091224-1.1) unstable; urgency=low . * Non-maintainer upload. * Patch from Ubuntu by Fabrice Coutadeur to fix FTBFS. (Closes: #621985) * fix_ftbfs_libav_0.7.patch: fix deprecated variable to fix a FTBFS with libav 0.7 * fix_link_as-needed.patch: fix Makefile.am and Makefile.in to avoid a FTBFS when as-needed is used with undefined gtk functions (LP: #770773) by moving libs from LDFLAGS to LDADD Checksums-Sha1: 1a1da5b89821a11f2a471a6aad982f4c37178e89 1965 electricsheep_2.7~b12+svn20091224-1.1.dsc d4b6051e79bde19f5bc6614691df420379605010 11455 electricsheep_2.7~b12+svn20091224-1.1.diff.gz 476cec9a3fb3f23b700b0da28f81d7ff134948c9 80838 electricsheep_2.7~b12+svn20091224-1.1_armhf.deb Checksums-Sha256: 347a9e6ddcc1f0ca8d2ce92b64b5459688007f03dafdb1d15c6588167041d8e3 1965 electricsheep_2.7~b12+svn20091224-1.1.dsc 24e172a087e7bc69dbbac1cc35a64edacf223f118e0e3667642a7f673e8b4313 11455 electricsheep_2.7~b12+svn20091224-1.1.diff.gz 9baed9f893cfa4dc0936c6d0b429945244558dc3f13a19b2bcfa574103229f4a 80838 electricsheep_2.7~b12+svn20091224-1.1_armhf.deb Files: 8cd05285841233f42691ad6711d69edb 1965 x11 optional electricsheep_2.7~b12+svn20091224-1.1.dsc 5fe7915611dcb6ebceb4cb84e80bc665 11455 x11 optional electricsheep_2.7~b12+svn20091224-1.1.diff.gz 36b01bc3ecc98eb6bebf72145d20bab7 80838 x11 optional electricsheep_2.7~b12+svn20091224-1.1_armhf.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPK+yqAAoJEGYGAn9kNxJMrmcQAJM0RwCbHZRxeu6gCcFrCpmw aVjigb3WVDO4kmSFmzMHXivqe7K6278NqzsbHPTzsk7nzo9ydS2IUjCi1+86W1rj fh7ps9ywmASSKF2E7VNC1Er3Nn1XwSsuu0sQt/i1UqBTVA8Rw8O3K1zNubBpqq62 j6LnKPdk1YDDjoZbJxVJ2+rpG6ng2gijV20ZIEOLcR6cTgXYeWH0IroNcICDY58D HHMy4T+4bybU23KOCAHEhvvo+T4k9Z7XPf5FEuQe8se26NpXoXsu5/tRYJ0mF8jQ WzX4BxTkr61rNuOdsdsrAu5oDiVJFW9sIibdzR9/tYx4Cp7YCsjJKO3wrooAVr03 mC8OXlrX9NwXPpY5gXNTnj5PTigz8kJqAsLNkKDDuy6hgwxGQSuoH0u8Jq+X4VU/ FndX4xUxhZAMLEZEM1uV+CjWG8wBCAAFX9oU2TjroUOo1pH91ywHOpjvszt37mTw i+peDpvAq8mVsqT3/w+uEhlsv4ARIYuDySYdzh8IrZq7jTlQ3DAVrlzuUp+jatGZ YFkQEytThGM9wspPjv3Yadd1ClQtZWLplvP7q3k8MPEMRbG972b6/reV/1zlsvWo DFzXHFVyB9B+gm9ittBBAGpQtduySWK91+ZEkOBi8OCJxeArEHRirfJBzLNpBYrT 4+wsHCuqqKVdiJlDFQ4w =UC+P -END PGP SIGNATURE- Accepted: electricsheep_2.7~b12+svn20091224-1.1.diff.gz to main/e/electricsheep/electricsheep_2.7~b12+svn20091224-1.1.diff.gz electricsheep_2.7~b12+svn20091224-1.1.dsc to main/e/electricsheep/electricsheep_2.7~b12+svn20091224-1.1.dsc electricsheep_2.7~b12+svn20091224-1.1_armhf.deb to main/e/electricsheep/electricsheep_2.7~b12+svn20091224-1.1_armhf.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv5ws-0005u1...@franck.debian.org
Accepted bzr-loom 2.1+bzr150-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 08 Feb 2012 12:13:10 +0100 Source: bzr-loom Binary: bzr-loom Architecture: source all Version: 2.1+bzr150-1 Distribution: unstable Urgency: low Maintainer: Debian Bazaar Maintainers pkg-bazaar-ma...@lists.alioth.debian.org Changed-By: Jelmer Vernooij jel...@debian.org Description: bzr-loom - Focused patch plugin support for Bazaar Changes: bzr-loom (2.1+bzr150-1) unstable; urgency=low . * New upstream snapshot. Checksums-Sha1: 9f3364b42e62b9e1f3e34358edf8c832ecbb934e 1502 bzr-loom_2.1+bzr150-1.dsc 714b27ae0f276787d3704bfd8db8da1c86a29307 49393 bzr-loom_2.1+bzr150.orig.tar.gz 08106accf5104426baa2cf0f41ade2ca3c17b55e 3132 bzr-loom_2.1+bzr150-1.debian.tar.gz 6e2e31a8f1eaaa3c69142ca1855a0da3cb25448c 45210 bzr-loom_2.1+bzr150-1_all.deb Checksums-Sha256: d45984ef0f1f16f807d8e451c933581766d37a245aeeec078e33f1e1257a0a01 1502 bzr-loom_2.1+bzr150-1.dsc 72f9195f91f888d184e1043b8814c6a4a68eae9059c29c72f79bb1abda1d79c8 49393 bzr-loom_2.1+bzr150.orig.tar.gz 291a6903f24563d763c26250d8ac12442485e2e903bd8758e2cefd1bb24651c5 3132 bzr-loom_2.1+bzr150-1.debian.tar.gz a618b84f7ae3999da0773dc8d3ee6ef7e77aff9fca385e4ab9a03fbc27b80d3b 45210 bzr-loom_2.1+bzr150-1_all.deb Files: cdee59c12e34e4d182021943df1f50ed 1502 vcs optional bzr-loom_2.1+bzr150-1.dsc 51b961073d4c0f35f73e6d2b365644a6 49393 vcs optional bzr-loom_2.1+bzr150.orig.tar.gz 79a0fd5f11d6be239120c6143bc279df 3132 vcs optional bzr-loom_2.1+bzr150-1.debian.tar.gz 872a8d405ac6a63e82072aace509add6 45210 vcs optional bzr-loom_2.1+bzr150-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8yWsMACgkQPa9Uoh7vUnaoSwCgilh2ouLQTI7/KXauKHv2dcv5 668An34CX7M2Uvrz6DAL8tnLtbhdcTm+ =onO1 -END PGP SIGNATURE- Accepted: bzr-loom_2.1+bzr150-1.debian.tar.gz to main/b/bzr-loom/bzr-loom_2.1+bzr150-1.debian.tar.gz bzr-loom_2.1+bzr150-1.dsc to main/b/bzr-loom/bzr-loom_2.1+bzr150-1.dsc bzr-loom_2.1+bzr150-1_all.deb to main/b/bzr-loom/bzr-loom_2.1+bzr150-1_all.deb bzr-loom_2.1+bzr150.orig.tar.gz to main/b/bzr-loom/bzr-loom_2.1+bzr150.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv5kx-0007yh...@franck.debian.org
Accepted gpe-expenses 0.1.9-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 07 Feb 2012 12:57:15 + Source: gpe-expenses Binary: gpe-expenses libqofexpensesobjects-doc libqofexpensesobjects1 libqofexpensesobjects-dev libqofexpensesobjects1-dbg libqofexpensesobjects-data Architecture: source all amd64 Version: 0.1.9-2 Distribution: unstable Urgency: low Maintainer: Neil Williams codeh...@debian.org Changed-By: Neil Williams codeh...@debian.org Description: gpe-expenses - Simple expense records for GPE libqofexpensesobjects-data - QOF expenses objects - translations libqofexpensesobjects-dev - QOF expenses objects - development files libqofexpensesobjects-doc - QOF expenses objects - documentation libqofexpensesobjects1 - financial QOF objects for expenses handling libqofexpensesobjects1-dbg - QOF expenses objects - debug support Changes: gpe-expenses (0.1.9-2) unstable; urgency=low . * Implement Multi-Arch paths Checksums-Sha1: 79797910c6cb7e094f5c1184462e7be75519b2ba 1912 gpe-expenses_0.1.9-2.dsc 424e62bd4ae1f356a5f8ae7ad14f2207695acead 4994 gpe-expenses_0.1.9-2.diff.gz e8339bb7e9bad5e5709e1db1b5f7addf538c0570 309982 libqofexpensesobjects-doc_0.1.9-2_all.deb e70f07669fd49b3f31e387ac29e7c8c6daf017e8 15228 libqofexpensesobjects-data_0.1.9-2_all.deb 879f57378f3eaad7bf35e6f7028a2ba37b1ba5d8 54624 gpe-expenses_0.1.9-2_amd64.deb 2f54e505b1c68b74bd750cf405a4580fd6c607f3 19528 libqofexpensesobjects1_0.1.9-2_amd64.deb 78d4676cf24325f50cb8501741a6f741830685b1 21950 libqofexpensesobjects-dev_0.1.9-2_amd64.deb 9c9ce84f0b09c00f83ed65b879da6c131e384fb3 73832 libqofexpensesobjects1-dbg_0.1.9-2_amd64.deb Checksums-Sha256: 254778882d7d5eaaf285c9491478a5351a2174cfef9724f8bb060252483fd782 1912 gpe-expenses_0.1.9-2.dsc 1404dd580644dfe0f3a37d6c44e896a97fd7ac6da9979fecbda20147c7383ba0 4994 gpe-expenses_0.1.9-2.diff.gz 053978f112fa72dffb44915d73633b2cf1684cc4477191c73ff48f8519ab23d7 309982 libqofexpensesobjects-doc_0.1.9-2_all.deb 023ed93bd081db994cb8e78e945fa358eb907f957b6ceda02503a2cbbe1ac111 15228 libqofexpensesobjects-data_0.1.9-2_all.deb 96d8ed0e499933631696e71315dbbd0b9ea32e4697d955cbe1f8698b140ee658 54624 gpe-expenses_0.1.9-2_amd64.deb 2c54840f43118d1fc2d87bcbf861a18072e7dbf3ceaf60380ba3d7d1c46dd0e7 19528 libqofexpensesobjects1_0.1.9-2_amd64.deb 7fb64ee25bca8ed74c757e6678001ce90175e72e29d7d882ca29eb699da28595 21950 libqofexpensesobjects-dev_0.1.9-2_amd64.deb e47b2d92de2330c6b361b8e57610c76defd24e301c173f522ff6efa9c8637252 73832 libqofexpensesobjects1-dbg_0.1.9-2_amd64.deb Files: 0cc2d035047bab60e6f7a6813d0acd3d 1912 utils optional gpe-expenses_0.1.9-2.dsc c6b82e385514d73ed87a6eac839361a8 4994 utils optional gpe-expenses_0.1.9-2.diff.gz 1d53ed1f9c85766aa51c55b42de5b20c 309982 doc optional libqofexpensesobjects-doc_0.1.9-2_all.deb d1890d82de75f35401b35db0d188eb5a 15228 localization optional libqofexpensesobjects-data_0.1.9-2_all.deb 23d6a02e689c51643a5305c71d33155e 54624 utils optional gpe-expenses_0.1.9-2_amd64.deb c468eae25bb3d70de786fd90f577faef 19528 libs optional libqofexpensesobjects1_0.1.9-2_amd64.deb bf8555f11183ce44c3547cdc8117eac9 21950 libdevel optional libqofexpensesobjects-dev_0.1.9-2_amd64.deb a5ae0bb748f126bc76e7fb6f1ba666f8 73832 debug extra libqofexpensesobjects1-dbg_0.1.9-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8yWkoACgkQiAEJSii8s+PuSwCdGbG8Yi2bgLovrmCuRiX1UEds mYIAnjD94/H6i+xBk/Vd22IYkQN6pekM =lzQr -END PGP SIGNATURE- Accepted: gpe-expenses_0.1.9-2.diff.gz to main/g/gpe-expenses/gpe-expenses_0.1.9-2.diff.gz gpe-expenses_0.1.9-2.dsc to main/g/gpe-expenses/gpe-expenses_0.1.9-2.dsc gpe-expenses_0.1.9-2_amd64.deb to main/g/gpe-expenses/gpe-expenses_0.1.9-2_amd64.deb libqofexpensesobjects-data_0.1.9-2_all.deb to main/g/gpe-expenses/libqofexpensesobjects-data_0.1.9-2_all.deb libqofexpensesobjects-dev_0.1.9-2_amd64.deb to main/g/gpe-expenses/libqofexpensesobjects-dev_0.1.9-2_amd64.deb libqofexpensesobjects-doc_0.1.9-2_all.deb to main/g/gpe-expenses/libqofexpensesobjects-doc_0.1.9-2_all.deb libqofexpensesobjects1-dbg_0.1.9-2_amd64.deb to main/g/gpe-expenses/libqofexpensesobjects1-dbg_0.1.9-2_amd64.deb libqofexpensesobjects1_0.1.9-2_amd64.deb to main/g/gpe-expenses/libqofexpensesobjects1_0.1.9-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv5lj-0007ft...@franck.debian.org
Accepted libreoffice-voikko 3.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 07 Feb 2012 20:54:27 +0200 Source: libreoffice-voikko Binary: libreoffice-voikko Architecture: source i386 Version: 3.3-1 Distribution: unstable Urgency: low Maintainer: Timo Jyrinki t...@debian.org Changed-By: Timo Jyrinki t...@debian.org Description: libreoffice-voikko - Finnish language tools for LibreOffice Changes: libreoffice-voikko (3.3-1) unstable; urgency=low . * New upstream release Checksums-Sha1: 173833f4775887cd3ec7e0b3668566f5f3e80ab1 1187 libreoffice-voikko_3.3-1.dsc 77db8536ac0f695155c569d9b4544b267c6b3c8d 42910 libreoffice-voikko_3.3.orig.tar.gz 07d37df9e54e5bd94556b4677620b38e8ccda25e 5395 libreoffice-voikko_3.3-1.debian.tar.gz 4c835ff5caa940065500dd2d4ed30e869a817eb3 70078 libreoffice-voikko_3.3-1_i386.deb Checksums-Sha256: 196c592783b9980ef1d69a6a24e15a541105a51a0f0fe223641e972188870799 1187 libreoffice-voikko_3.3-1.dsc 112fba331ab812524700ab7f09fdeb6dd8b07d20df235bceabbfa3119f74809a 42910 libreoffice-voikko_3.3.orig.tar.gz 86021a5ec599a7d1f15dff468681ebd7736914e5907f1578a46c179b44f6f2ea 5395 libreoffice-voikko_3.3-1.debian.tar.gz 260f7b67d73d040eae1f1888427b84ee9ab5627149fbad5da1791ddfcc2feb5f 70078 libreoffice-voikko_3.3-1_i386.deb Files: 6d949c6d762040166e53af94c83bf288 1187 text optional libreoffice-voikko_3.3-1.dsc 9b52dd9cb5bff1f382b2a8056fa973f3 42910 text optional libreoffice-voikko_3.3.orig.tar.gz 39e97efc98a5f40f2a32e8a3dadf781b 5395 text optional libreoffice-voikko_3.3-1.debian.tar.gz 7741c9e6f6d1602921d97992b3bad86c 70078 text optional libreoffice-voikko_3.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8yY1sACgkQgtffbfx/bQ+s/gCbBQI/E0c37pgg9/wf7SAURMW4 Hn4AnRsj462QTCbyy2IVAR6lfKTlwpbw =BTOV -END PGP SIGNATURE- Accepted: libreoffice-voikko_3.3-1.debian.tar.gz to main/libr/libreoffice-voikko/libreoffice-voikko_3.3-1.debian.tar.gz libreoffice-voikko_3.3-1.dsc to main/libr/libreoffice-voikko/libreoffice-voikko_3.3-1.dsc libreoffice-voikko_3.3-1_i386.deb to main/libr/libreoffice-voikko/libreoffice-voikko_3.3-1_i386.deb libreoffice-voikko_3.3.orig.tar.gz to main/libr/libreoffice-voikko/libreoffice-voikko_3.3.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6tt-00033u...@franck.debian.org
Accepted haskell-cautious-file 0.1.5-4 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:57:45 + Source: haskell-cautious-file Binary: libghc-cautious-file-dev libghc-cautious-file-prof libghc-cautious-file-doc Architecture: source all amd64 Version: 0.1.5-4 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-cautious-file-dev - Haskell library to write a file cautiously - GHC libraries libghc-cautious-file-doc - Haskell library to write a file cautiously - documentation libghc-cautious-file-prof - Haskell library to write a file cautiously - GHC profiling librar Changes: haskell-cautious-file (0.1.5-4) unstable; urgency=low . * Sourceful upload to rebuild documentation package Checksums-Sha1: ae2e6c802263fce124cdcc175c79dd5b3d30f1a4 2310 haskell-cautious-file_0.1.5-4.dsc ee286f7edde76bf54de6dda0e84fa9b4f4b61ba0 2748 haskell-cautious-file_0.1.5-4.debian.tar.gz 3801218fff880cb9db805b5f892721600269392c 31342 libghc-cautious-file-doc_0.1.5-4_all.deb 94690c89750243b82d129ba1b8b84d8922077ee9 24076 libghc-cautious-file-dev_0.1.5-4_amd64.deb 6b33848932a7c0de951eae16ca93dce87ce71775 21158 libghc-cautious-file-prof_0.1.5-4_amd64.deb Checksums-Sha256: a8dd6f475937ef6970359d1a6fc3e01da61df458e907abf8d515ace86adf436f 2310 haskell-cautious-file_0.1.5-4.dsc 6769ab4e29e7dd661775688f047f4650ecdd4e4288bddda444140231937d06a3 2748 haskell-cautious-file_0.1.5-4.debian.tar.gz bd2781698d0feff08bf09f8a1e3c741639dbcca1635ce76f02d60e159c7c549b 31342 libghc-cautious-file-doc_0.1.5-4_all.deb bac2d28fd2ef3e902dfb2e0de16bb33de8bc38a5df5a4f27956384bc88ee1468 24076 libghc-cautious-file-dev_0.1.5-4_amd64.deb 87d3e7ce5f3e02430894bf328d4bc0c737cbbc5bb0dce34630758f0ad382e458 21158 libghc-cautious-file-prof_0.1.5-4_amd64.deb Files: a443e68f292dc0f354651ce245497a9a 2310 haskell extra haskell-cautious-file_0.1.5-4.dsc 1c3b7c1a12523b87119d6e608065d836 2748 haskell extra haskell-cautious-file_0.1.5-4.debian.tar.gz ac6cc2b340360772e76eb9f73561ebd2 31342 doc extra libghc-cautious-file-doc_0.1.5-4_all.deb 5110335a5914b4b20dcff4469d0da50b 24076 haskell extra libghc-cautious-file-dev_0.1.5-4_amd64.deb bdc2ec515c67a86bddf4806e92699a00 21158 haskell extra libghc-cautious-file-prof_0.1.5-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMmegAAoJEONS1cUcUEHUfHEQAJOZObbU7+N/LnSaH8cSN8yQ aHmEawuN7Yj39yNCIo0bdy1FZnyXmJr4RVf1CUVdBJF5OFZuH5SYinFZKi2GNpZM 4SmP3woswuTNlz5TQrYFAgJPHp3PGu9yk+47o+y7oQy4uSu+dCJ4IYn7H0kdYkt+ /DDoh6TREg0zVfEP7XGqAaINS3M9ZfLDEZufTU+yhaYQ3dkNktd2j04WTCOkONMC YdKdmDa8jg6cqAE+WXQu8+2YQlK2LtPyyocbm5XMM6nrfw2RGsQdMnBVTPSyW8Qp pR9diYSO4KI6K6YEMAVZ2VmC5KB3sMNMrsO/Pysi+b/kval+jAU0NuaEstbfVHOX +k2bjg/K3K9OcBjAy5JZNvNHsUpHvpL59hwJH5Mx8ICpgc0M+Nh3Q9CItjqImRBJ iYxO82r/85HwsZvmdJbDoIZnfb0yBEjlI3vNqAIrrVwITngOoYd1UQnpofusdR5Q QuG0ifjN0fRTrnIz9AsbzaOEkhbsdoup8mE2x9aE2XAxeIvLPoBfUypjk6jt0mc1 hJluyvmXpYNjNWAOquZIaHN+2OPGW+Fd+thTmiFN8C6VhPDaSKfOnzG4DX0TXuUG yGPrjWAnTk9mvHmrVgARuTZGxcq+jPgyb+vhDN/A6tas6pe4f6abrJG7ligNF43l 5VrXVPSIcf0v5r2t/Ui+ =x4eQ -END PGP SIGNATURE- Accepted: haskell-cautious-file_0.1.5-4.debian.tar.gz to main/h/haskell-cautious-file/haskell-cautious-file_0.1.5-4.debian.tar.gz haskell-cautious-file_0.1.5-4.dsc to main/h/haskell-cautious-file/haskell-cautious-file_0.1.5-4.dsc libghc-cautious-file-dev_0.1.5-4_amd64.deb to main/h/haskell-cautious-file/libghc-cautious-file-dev_0.1.5-4_amd64.deb libghc-cautious-file-doc_0.1.5-4_all.deb to main/h/haskell-cautious-file/libghc-cautious-file-doc_0.1.5-4_all.deb libghc-cautious-file-prof_0.1.5-4_amd64.deb to main/h/haskell-cautious-file/libghc-cautious-file-prof_0.1.5-4_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6hu-0004rx...@franck.debian.org
Accepted haskell-clock 0.2.0.0-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:56:21 + Source: haskell-clock Binary: libghc-clock-dev libghc-clock-prof libghc-clock-doc Architecture: source all amd64 Version: 0.2.0.0-2 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-clock-dev - High-resolution clock and timer libghc-clock-doc - High-resolution clock and timer; documentation libghc-clock-prof - High-resolution clock and timer; profiling libraries Changes: haskell-clock (0.2.0.0-2) unstable; urgency=low . * Sourceful upload to rebuild documentation package Checksums-Sha1: a2492ee7999890ab45fdfa9027cf16916fb27458 2191 haskell-clock_0.2.0.0-2.dsc 053b175a4a242a1929904338326f0c3890e623bb 2146 haskell-clock_0.2.0.0-2.debian.tar.gz 6b3ddf346355eb9368145e680ec0dba81dce3890 32406 libghc-clock-doc_0.2.0.0-2_all.deb 4b49d75ebb10eebb790506ebfd4ab439ea812b6a 33592 libghc-clock-dev_0.2.0.0-2_amd64.deb c8e0e8b87fe566e50eb723c8d2b356c561c2de89 29232 libghc-clock-prof_0.2.0.0-2_amd64.deb Checksums-Sha256: 9d6dbd32e51944bdf384cbfa583664c0b8e96a98c9ffbf347fc5d4bfb4342cad 2191 haskell-clock_0.2.0.0-2.dsc cbb4d9d18d91fee16e5fc450d764e8e3a01dd8ecf621f8a142ea7aa8d0901136 2146 haskell-clock_0.2.0.0-2.debian.tar.gz 1be4386a759c4e15b7f69475a74cf335e217db12c3f71ade61aa6edc2091e5b4 32406 libghc-clock-doc_0.2.0.0-2_all.deb 043590b94612a39e1646978b5479cb8557b5b5ee629f10b4f114b38204a6d8fe 33592 libghc-clock-dev_0.2.0.0-2_amd64.deb 765d3f2511b2b2f8eadeb31170dd4970089737277c7465b47b9cea38f5fc4493 29232 libghc-clock-prof_0.2.0.0-2_amd64.deb Files: ae5e40938cd7537f6fa08ae0a27f95d3 2191 haskell extra haskell-clock_0.2.0.0-2.dsc 094d671eeb08e8b529c139077a121a50 2146 haskell extra haskell-clock_0.2.0.0-2.debian.tar.gz d580b6c01d0fce14e0663298901b 32406 doc extra libghc-clock-doc_0.2.0.0-2_all.deb e178753d47d02b5be6e7b6c5eec356d3 33592 haskell extra libghc-clock-dev_0.2.0.0-2_amd64.deb 300deccdefbbfa10a4fa0f4e3c52b736 29232 haskell extra libghc-clock-prof_0.2.0.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMmegAAoJEONS1cUcUEHU7lQP/RyxCURH4kmS0zIGJ8ODUTg9 EaqzYv0CMOhPNzdaTuxomkELaFUuO/cCY7lf05ecC/6m53D5ydVzbJZBH1riAPGi 9n4gox2obQ54Gm4D/KzNsBDH6qUYKdC+IM2NnqyW8V8M5VTu37DJOTb4p2+70SrQ a1taJTkr3qj0Gn3anmy9kouzspAg3rsncpQ8pRC4xkpa36wt4/8REU0E3RrbJiWK 0pQ08g6ugSEM3lo9xu4z3xXAfTK1yqIRXsxqrSAekCyGUqcTzFCvDnjYI1M+gAzN s9dBuOTLFoNcbseRWSJyWW6NTBLk2+/qXW3gVK7wH+ZjKEI7HoHeOwItcJAwziiG uNfJIMZkl6iTrFXHHAQRj6E1L8KrgkybgOo1FC4S+Fym/keLI0cp238KVjOOOgpz b7NEF6a7SC+lP7kBta7IVTWALoSDH6yG/e7b1N1YWFQdHHGPW01bR1tG9BAIqcr2 eSfAo28FeRWsUe1p7lDkD8tkW5LtdZ4NBSxlbVD5FHLFv7OoGKZobBIcPDR4VlL3 vATS1utJVDHdkqPjlmQ3PQqLKLqb6pO5NzS6ap+TXIpwFTEotBipJ1ZfFRfcTMDH /YeFHdc9Ygl18MnRnYH2n5+UQZM6FRr7yTzOhJIeIG/SI4JYlqpUjiWiIMEIxf9Y eoXQvhNO//niMu7IBvVQ =sZkc -END PGP SIGNATURE- Accepted: haskell-clock_0.2.0.0-2.debian.tar.gz to main/h/haskell-clock/haskell-clock_0.2.0.0-2.debian.tar.gz haskell-clock_0.2.0.0-2.dsc to main/h/haskell-clock/haskell-clock_0.2.0.0-2.dsc libghc-clock-dev_0.2.0.0-2_amd64.deb to main/h/haskell-clock/libghc-clock-dev_0.2.0.0-2_amd64.deb libghc-clock-doc_0.2.0.0-2_all.deb to main/h/haskell-clock/libghc-clock-doc_0.2.0.0-2_all.deb libghc-clock-prof_0.2.0.0-2_amd64.deb to main/h/haskell-clock/libghc-clock-prof_0.2.0.0-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6ic-0004wm...@franck.debian.org
Accepted haskell-lexer 1.0-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:56:47 + Source: haskell-lexer Binary: libghc-haskell-lexer-dev libghc-haskell-lexer-prof libghc-haskell-lexer-doc Architecture: source all amd64 Version: 1.0-3 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-haskell-lexer-dev - A fully compliant Haskell 98 lexer libghc-haskell-lexer-doc - Documentation for a fully compliant Haskell 98 lexer libghc-haskell-lexer-prof - Profiling libraries for a fully compliant Haskell 98 lexer Changes: haskell-lexer (1.0-3) unstable; urgency=low . * Sourceful upload to rebuild documentation package Checksums-Sha1: 3727f444eefb965839634094fe99e84fee81f9bd 2226 haskell-lexer_1.0-3.dsc 566208379dea12363e0a7450002421bffe4f73bc 2104 haskell-lexer_1.0-3.debian.tar.gz bf04a8c0fa40bd999291be264f0595d6e2432d9f 74830 libghc-haskell-lexer-doc_1.0-3_all.deb 98a36af1d3a06428556bcc8c85b2e920f96ef302 553554 libghc-haskell-lexer-dev_1.0-3_amd64.deb e4be02049273d787763642910be55977b7439ae5 655438 libghc-haskell-lexer-prof_1.0-3_amd64.deb Checksums-Sha256: af24f946492247678bcff2d1ee6f5712264aa826aae7dffdf5281912edb66224 2226 haskell-lexer_1.0-3.dsc 5a9dd26d80e56c79a64c36032a0636767661502bb6a13060b407e56d2f65117e 2104 haskell-lexer_1.0-3.debian.tar.gz ac279a46580fb5e94a89de5e17689da21a9e501785734f25cba0d09bc59ec41c 74830 libghc-haskell-lexer-doc_1.0-3_all.deb 3174586015eef5f364411326d50853be13c9857f30926075d4e703587df535db 553554 libghc-haskell-lexer-dev_1.0-3_amd64.deb cc707afd2e05ba6f9df3ef5dde518abb9dd66b57afaf8989312fd2052ee96236 655438 libghc-haskell-lexer-prof_1.0-3_amd64.deb Files: cd6d405e533fc16e5c0ef1e35e894f4a 2226 haskell extra haskell-lexer_1.0-3.dsc 5de41d1f7970ecdec89604b72a3992d0 2104 haskell extra haskell-lexer_1.0-3.debian.tar.gz 3c155a7578762e54d22e502445b018ed 74830 doc extra libghc-haskell-lexer-doc_1.0-3_all.deb 7a4d8a4ace78c1242c098eec24778e08 553554 haskell extra libghc-haskell-lexer-dev_1.0-3_amd64.deb bfbf7a329bfc4cc3f3c16de465849ae7 655438 haskell extra libghc-haskell-lexer-prof_1.0-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMmehAAoJEONS1cUcUEHU4jgP/2co/XYgfsVgES6zNyxXbBYU WyUlKecFMJsTbm8S+DXIh3+vs19LNKqoBEf2L4z/GlUn3W8hUJX1CjiAkg1vLNU+ 1Va77HocLcEaFaplcMcCH5/1re3yjU9gS6zHbsengwF42NpE1wtFFTarjlkuzRfU d/J6mGHdftS50DE+jrMdU/c1uibihn8jezawOn4XcG3/eQAWUQWNl2CB2VchnIA5 JTu1fX6VA9b5J1oHdHZQJs3JBXKvxYQeu7Z33S0adF/InZHeqLUy25kcD/8BnqgG /Wv9CJP6tsDuqXaNzmlBW+LxYbFMywgn3pxuMVlqq8Fid2nbEZ4Iylp+nHMMyLVp YvMS+dW2maYrtP0S0sMIPxnkPOdhEuXfyeiozmnbMDIbgYqzMbovl0NIBjJdexQH uOH+wEiRouSa7J3TOJCVaVScX+34SRKtymtnlondgYz/mH5ltxDsq4K6hXO8oawU DngIyKKDZuqNvEe1/t6zDvs00IdSVXTyKwExQ1A8DA656TenZ++TZddR4++/JH7s BKwZmJTxrT68QSvHDBsb5IHDNz1bDNBujIt/nukxsqRLM1A4vQsu8bHStjiBIcn5 6PMX294/Pgvsle9wdQCfs4o/HNnmd5RfuVj6s4mWdbV0nj5uTnKjEo8FMxuQiyI3 kM+eUhs5HRi83MJmN8SJ =OPOS -END PGP SIGNATURE- Accepted: haskell-lexer_1.0-3.debian.tar.gz to main/h/haskell-lexer/haskell-lexer_1.0-3.debian.tar.gz haskell-lexer_1.0-3.dsc to main/h/haskell-lexer/haskell-lexer_1.0-3.dsc libghc-haskell-lexer-dev_1.0-3_amd64.deb to main/h/haskell-lexer/libghc-haskell-lexer-dev_1.0-3_amd64.deb libghc-haskell-lexer-doc_1.0-3_all.deb to main/h/haskell-lexer/libghc-haskell-lexer-doc_1.0-3_all.deb libghc-haskell-lexer-prof_1.0-3_amd64.deb to main/h/haskell-lexer/libghc-haskell-lexer-prof_1.0-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6it-0004ak...@franck.debian.org
Accepted haskell-mersenne-random 1.0.0.1-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:50:48 + Source: haskell-mersenne-random Binary: libghc-mersenne-random-dev libghc-mersenne-random-prof libghc-mersenne-random-doc Architecture: source all amd64 Version: 1.0.0.1-2 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-mersenne-random-dev - SIMD Fast Mersenne Twister generator of pseudo-random numbers libghc-mersenne-random-doc - SIMD Fast Mersenne Twister generator of pseudo-random numbers; do libghc-mersenne-random-prof - SIMD Fast Mersenne Twister generator of pseudo-random numbers; pr Changes: haskell-mersenne-random (1.0.0.1-2) unstable; urgency=low . * Sourceful upload to rebuild documentation package Checksums-Sha1: 5142ae1a2990b9f827620cdc9264ed80d1ac4a3e 2347 haskell-mersenne-random_1.0.0.1-2.dsc 338f82ce3a8d5dfa259c2b981aeebf8057124a6c 2611 haskell-mersenne-random_1.0.0.1-2.debian.tar.gz 17420cdf234a37808d24a3ceebfe34af5f84ad51 41726 libghc-mersenne-random-doc_1.0.0.1-2_all.deb c5dfdc18e84d09eda6ec5671dfbf2d99e0171553 44056 libghc-mersenne-random-dev_1.0.0.1-2_amd64.deb d44c4522ecddfb6f6a552431f038956b5761cd5e 35694 libghc-mersenne-random-prof_1.0.0.1-2_amd64.deb Checksums-Sha256: 0b97642885be1218330c2d7b50e972a09360c8b745a8263b6641a1d4c9df8bbf 2347 haskell-mersenne-random_1.0.0.1-2.dsc 5498813c831b952b36ce5927b616198e0cd2b62d01503d69a67c81635577fb24 2611 haskell-mersenne-random_1.0.0.1-2.debian.tar.gz 9d0315f699d6a209ea4c1f83082a519c0d1fab4cc247a6141768084c97fa2a15 41726 libghc-mersenne-random-doc_1.0.0.1-2_all.deb cfc379ef1c50eb16954acefd522b47085ac640502f54ef78d6a82217d5424d5e 44056 libghc-mersenne-random-dev_1.0.0.1-2_amd64.deb f5c13247630b63cc8ebba9264829e0df9adb32ce34ec5f43d7bb0a1a43a072bb 35694 libghc-mersenne-random-prof_1.0.0.1-2_amd64.deb Files: a32278246dd59c96b81c94f4315ea8ba 2347 haskell extra haskell-mersenne-random_1.0.0.1-2.dsc 687df38531bdf36203779255df1f9d8f 2611 haskell extra haskell-mersenne-random_1.0.0.1-2.debian.tar.gz d8562365ca02edadc0fd67023f61710d 41726 doc extra libghc-mersenne-random-doc_1.0.0.1-2_all.deb 478a9ae2b3cb97cd0fadfa35849b1262 44056 haskell extra libghc-mersenne-random-dev_1.0.0.1-2_amd64.deb 095ac43f29f42f63f5847883f8394b76 35694 haskell extra libghc-mersenne-random-prof_1.0.0.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMmeiAAoJEONS1cUcUEHU0asQALJOxVlTA8JhIklLbDF13rr8 eHLHVPo5RTmMrGql3Ab6224x7tJLJfSz4A5EvsuwXfcqIb5UB2Ysw7xcp8pSCzQy 0hplF4K06Id1x0QKBCY7BnvwmzizG+bM6Pf5KweOG47Ore9iXEJyvXXixr1surg5 WSv7HkrKaa+kyA6YbzzslVpgmqkHHfjXJgX2yO5uD19jdtFbI/iX/osbpUJLVbqh qfQ54qwjIsNto7TcKUBN26/DeLUQ1P5P4zgbjkZCLWp59KJkkINki5037S3hhN+5 trzmyhztXvaF0bjuTEWvvmS+5iRI5+GhE6SG5i/vHWfJIFt2iWZnhabXoQCiv+vb mOan+9E9lSBTcPvVEa+salok07zI43Z4pCtjQ3fczWdAJhX0A+MumlG6k+KLK73x BTxdNIEbJ6wMctj35cbznZNftpuhI0NvQk1MFU+2qfzr6lr7cua0fhFBe8VtOaXc LYj6aN1NxBESxNBuLoRaIT0FLDLjiXH6e/BpAyntU/DkxoK8Nml+R39vOB1e9Fwt fxiA7m4RjmOQgFgHcgF0H6dYGDVY7/NReP1Nmcwegjz1W0yUywY4VN71Qx84 iZnVFycYT6QH2fBRUoS3OHUtQtf7bFq8DG3gYvJwkoETqWO4eW0b7Af52AD7ndnv oJRDtyU4+9NUsgj+b0ux =Lfni -END PGP SIGNATURE- Accepted: haskell-mersenne-random_1.0.0.1-2.debian.tar.gz to main/h/haskell-mersenne-random/haskell-mersenne-random_1.0.0.1-2.debian.tar.gz haskell-mersenne-random_1.0.0.1-2.dsc to main/h/haskell-mersenne-random/haskell-mersenne-random_1.0.0.1-2.dsc libghc-mersenne-random-dev_1.0.0.1-2_amd64.deb to main/h/haskell-mersenne-random/libghc-mersenne-random-dev_1.0.0.1-2_amd64.deb libghc-mersenne-random-doc_1.0.0.1-2_all.deb to main/h/haskell-mersenne-random/libghc-mersenne-random-doc_1.0.0.1-2_all.deb libghc-mersenne-random-prof_1.0.0.1-2_amd64.deb to main/h/haskell-mersenne-random/libghc-mersenne-random-prof_1.0.0.1-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6ik-0004ek...@franck.debian.org
Accepted haskell-numtype 1.0-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:57:32 + Source: haskell-numtype Binary: libghc-numtype-dev libghc-numtype-prof libghc-numtype-doc Architecture: source all amd64 Version: 1.0-2 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-numtype-dev - type-level (low cardinality) integers libghc-numtype-doc - type-level (low cardinality) integers; documentation libghc-numtype-prof - type-level (low cardinality) integers; profiling data Changes: haskell-numtype (1.0-2) unstable; urgency=low . * Sourceful upload to rebuild documentation package Checksums-Sha1: 067def379423562dab4e72c8438a40445c8adfd0 2212 haskell-numtype_1.0-2.dsc 596177a41fb1ed2187886f93d3ecb590511e3d0d 2437 haskell-numtype_1.0-2.debian.tar.gz 5bb830e080f6c16eb965620ab28ae1021f47506a 37832 libghc-numtype-doc_1.0-2_all.deb 86b0724133f0c69110b8fc9fdba9a1564d53da3d 57940 libghc-numtype-dev_1.0-2_amd64.deb ece1016aa80d974beaba7e32d67b66cde31e9869 57940 libghc-numtype-prof_1.0-2_amd64.deb Checksums-Sha256: 7e7f86af0ec08532cc370baf6183ba272a664cd467f937ee23b9ba8e43345aec 2212 haskell-numtype_1.0-2.dsc 104428f1f78766234c9e456c825b4ebb04f38595d2675d186f012d58ebc8f1dc 2437 haskell-numtype_1.0-2.debian.tar.gz 029d543b5b8ac21b77de0f6d0f261292e15ba32864c4722b92886b1072d0ac1c 37832 libghc-numtype-doc_1.0-2_all.deb a77b4d8cacd2c08dbb48d039071081821c2631dcb1b1d8f574eefe87e5b5368a 57940 libghc-numtype-dev_1.0-2_amd64.deb 7eda0b681a777460dfedeaf04863c3d80999cc47161b4c83cac5a6ba08c5ca3d 57940 libghc-numtype-prof_1.0-2_amd64.deb Files: 89b8268aadfb570325660fca341d27bf 2212 haskell extra haskell-numtype_1.0-2.dsc 8a81d00e467d3933fc732c4ec3890be7 2437 haskell extra haskell-numtype_1.0-2.debian.tar.gz 784af12d0ea4e93f3d36b4aee7b8cea6 37832 doc extra libghc-numtype-doc_1.0-2_all.deb 2597b813175fe7b513bd625effa10709 57940 haskell extra libghc-numtype-dev_1.0-2_amd64.deb c1b741fbd09c5df86af44bfc54791849 57940 haskell extra libghc-numtype-prof_1.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMmejAAoJEONS1cUcUEHUOCUP/jOAxJ19LHrGD3O+Zw2/bjno Jmd7rxJT9GRvSMxdT0oVdSqIg96x8oD+hkM9WNJHDnE6P3Xv+FqfH7dckvlvTwNd IN4kbzQCoycJmc8R7SQPNGW5/qfjnRBV+R4xLZpLO/rihcVBz+iUA66d6l2GAtyv n2H6hfZj+wQfxZwA+I8jihNnRL65JPVnQCGvyn0ENb7nMztlflPI1jPxJAqU4DGV sDxDGvU4eXzSAAvs17/pWaMujW0X7fiNmV6oOtWNqgpVhAMymdYTBNTB2Y57oiXA M/O+bXhWeTxfvRk0B4As8xfXDWEb8BFSOI6oZsGwWEiBrtTaYnAeaY0KQC+m51RC Fv5An299lXwL9cJAdQCF0N/nWt3/bDMdcJf/0FwqJfFIKTBDIvnVltdUieQ7I5mv JRHaWg4/RR/qm4SgfDuy9gRyPEnvOLGxkdORaHcJajvfzL1RJjAAOdFFSgiYExXU HRpDDCxXW8XcQIayUotdQDOeQ67eGsd/+6hn62m97/Goka7/Sri3/vmpQhnuvcTT 1t6NJ6418cYxDos6FbNyG98wngiSYK4MfClA4KvGZ3GLgM7EmTqoLB5mwV56ETOy h96vbys095AllCLg82kVu0e7H+8cFL/twdN/9fKAdymxK/P31CYsWbY92ZUJvrn3 WNQZx1GI2cJaARJKmDTV =jeF8 -END PGP SIGNATURE- Accepted: haskell-numtype_1.0-2.debian.tar.gz to main/h/haskell-numtype/haskell-numtype_1.0-2.debian.tar.gz haskell-numtype_1.0-2.dsc to main/h/haskell-numtype/haskell-numtype_1.0-2.dsc libghc-numtype-dev_1.0-2_amd64.deb to main/h/haskell-numtype/libghc-numtype-dev_1.0-2_amd64.deb libghc-numtype-doc_1.0-2_all.deb to main/h/haskell-numtype/libghc-numtype-doc_1.0-2_all.deb libghc-numtype-prof_1.0-2_amd64.deb to main/h/haskell-numtype/libghc-numtype-prof_1.0-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6j2-0004ir...@franck.debian.org
Accepted haskell-parsec2 2.1.0.1-6 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:50:34 + Source: haskell-parsec2 Binary: libghc-parsec2-dev libghc-parsec2-prof libghc-parsec2-doc Architecture: source all amd64 Version: 2.1.0.1-6 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-parsec2-dev - Haskell monadic parser combinator library for GHC libghc-parsec2-doc - Haskell monadic parser combinator library for GHC; documentation libghc-parsec2-prof - Haskell monadic parser combinator library for GHC; profiling libr Changes: haskell-parsec2 (2.1.0.1-6) unstable; urgency=low . [ Joachim Breitner ] * Drop Kaol from Uploaders, thx for your contributions . [ Iain Lane ] * Sourceful upload to rebuild documentation package Checksums-Sha1: 0f5c94358a03fd45648ed51a4e59f49213d22bf6 2203 haskell-parsec2_2.1.0.1-6.dsc 00c60f3af174b3f3bed121ce18a4c65aa91e1e65 2907 haskell-parsec2_2.1.0.1-6.debian.tar.gz d9cdc60641fcd9e122f576d8b5ab0b7ec14d5aca 76362 libghc-parsec2-doc_2.1.0.1-6_all.deb 72f86d4c714a96244db27cb63791491ef7fe1c09 325040 libghc-parsec2-dev_2.1.0.1-6_amd64.deb b459173627ba6335b0dad2849d9f3c56521d9325 318674 libghc-parsec2-prof_2.1.0.1-6_amd64.deb Checksums-Sha256: d75bfff44f6bdaed71a314340d0c68ef26652eee2208be44c253291fc177e76b 2203 haskell-parsec2_2.1.0.1-6.dsc dd14bfc9e4d00766df9e7f20e5b960f9f02d9e421969d7de8ef417779884ff51 2907 haskell-parsec2_2.1.0.1-6.debian.tar.gz 3a3e6b820f2a6d9c32a9d00aa2b1e8c7482c8e229b2df41a66593badf833975f 76362 libghc-parsec2-doc_2.1.0.1-6_all.deb a258f385d24ae6013c6b40ec3104e4191e59f713ece0e3479f99bdcccec7e02e 325040 libghc-parsec2-dev_2.1.0.1-6_amd64.deb 5513b758e0856bbd8baff724dd193c982dffa336f7a50e556d9817011b575f5e 318674 libghc-parsec2-prof_2.1.0.1-6_amd64.deb Files: 77bbd31a1486ca3da533000d205481ec 2203 haskell extra haskell-parsec2_2.1.0.1-6.dsc e9eac14e47b01eb391b6998823b4 2907 haskell extra haskell-parsec2_2.1.0.1-6.debian.tar.gz f76aa7116a11878d39393e12e15712c4 76362 doc extra libghc-parsec2-doc_2.1.0.1-6_all.deb 94667382ed3b14ec22b29865a526f2e9 325040 haskell extra libghc-parsec2-dev_2.1.0.1-6_amd64.deb a4ee67e775bcae28759d85690d474b48 318674 haskell extra libghc-parsec2-prof_2.1.0.1-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMmekAAoJEONS1cUcUEHU5OoP/3QUnH3h93zJFARP6FGnslFk DkmQN0Sejtk/pptLuoyiXUXIMBddtWYpbei31NI8ib/nmdC63ufX/HFeh0BL/eUC C+mwUKTDA6xWL+XpuZvnCA3plU55NmS2h2h413zlY40rsnI/mYdZfQqNtISp0rnj buJrby4ShC3tOKG8/MJ1HUqiYaAUV97peZ5ynu1Io9tlBODGXkZuODpplUB/dlCZ e8TGyX6w3OxqVcPiFY/FZ2SqIZPyuMxSRQnnpwtHUjYEOFCGpFtS/W5FkYnUlIUa apQUkKQwd9XOpQ0P/2fFaGTI4pXCEO5Sm6fP6O6+RmY+1mBH7Z4XNtkegVgtwhyZ 0GZgHayyhDAPRiMCov8H8BaYvtq9wVJU3Czrh1HhRKRNlA0M3oamso8HeEsQesDG 6wrct3JTIIgGoqYqr5TrLnKBqnwVfqlAmoHkSFbEAq5CyBR1MX0zZW7HzHnokuot tl8blAWLqTB5dvsbe3t63CnpKj+mmSv1h6JGDgluFF+pPVzjRXRigG8jIcY8s1nd RRlFuHCnCA7oF3MMhkSDpG7cueby9Yqh2+rrs+QlFe22L7hxzvNUMXhrig3XS3k9 22asLDpZAoA3lZLfDfFKH+KvmDEceteHzzSdpdKWlnDwi7olxt1hRbvi8LFc8bQ6 rpIp3SSDhbJpgtf2WmmT =FpAD -END PGP SIGNATURE- Accepted: haskell-parsec2_2.1.0.1-6.debian.tar.gz to main/h/haskell-parsec2/haskell-parsec2_2.1.0.1-6.debian.tar.gz haskell-parsec2_2.1.0.1-6.dsc to main/h/haskell-parsec2/haskell-parsec2_2.1.0.1-6.dsc libghc-parsec2-dev_2.1.0.1-6_amd64.deb to main/h/haskell-parsec2/libghc-parsec2-dev_2.1.0.1-6_amd64.deb libghc-parsec2-doc_2.1.0.1-6_all.deb to main/h/haskell-parsec2/libghc-parsec2-doc_2.1.0.1-6_all.deb libghc-parsec2-prof_2.1.0.1-6_amd64.deb to main/h/haskell-parsec2/libghc-parsec2-prof_2.1.0.1-6_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6jk-0004ov...@franck.debian.org
Accepted haskell-sfml-audio 0.2.1816.0-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Feb 2012 10:57:01 + Source: haskell-sfml-audio Binary: libghc-sfml-audio-dev libghc-sfml-audio-prof libghc-sfml-audio-doc Architecture: source all amd64 Version: 0.2.1816.0-2 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Iain Lane la...@debian.org Description: libghc-sfml-audio-dev - minimal bindings to SFML-Audio libghc-sfml-audio-doc - minimal bindings to SFML-Audio; documentation libghc-sfml-audio-prof - minimal bindings to SFML-Audio; profiling libraries Changes: haskell-sfml-audio (0.2.1816.0-2) unstable; urgency=low . * Sourceful upload to rebuild documentation package Checksums-Sha1: c276fe7db0c4b2d106d17986f7bb50d657388bea 2327 haskell-sfml-audio_0.2.1816.0-2.dsc 4975d0ececd4d957f4dfaceda63528762e22efaa 2130 haskell-sfml-audio_0.2.1816.0-2.debian.tar.gz 82db67f10a23a96a66c708260f5c3495d6086a1c 30506 libghc-sfml-audio-doc_0.2.1816.0-2_all.deb 17629595a080a9c9ede9cb17c437974dd39f9e67 81744 libghc-sfml-audio-dev_0.2.1816.0-2_amd64.deb 7d98bd39b7f4c7146a33a7b87b15cd1de00baa65 54360 libghc-sfml-audio-prof_0.2.1816.0-2_amd64.deb Checksums-Sha256: 32de306e82a1371d40cd4519938511e4d0df14fb6158a383cda4863d7a5a5cfe 2327 haskell-sfml-audio_0.2.1816.0-2.dsc 19aff4658b40492503ec887a51edc0471acac177610f34321fc0a3b11a617306 2130 haskell-sfml-audio_0.2.1816.0-2.debian.tar.gz fcb7857d384a46fdb42b9eb94bed5ba42b0c0a6b7949b61d31e9be6ecfc8e5a8 30506 libghc-sfml-audio-doc_0.2.1816.0-2_all.deb 59c33e8b63cdb0ad4cd4432c9b6db1d07f223174ec577c973cbc4ff8f6b4de38 81744 libghc-sfml-audio-dev_0.2.1816.0-2_amd64.deb c2f12cdb2e6e233ade4da534f04ba0b79bea75295da4a018c50b8c123249c230 54360 libghc-sfml-audio-prof_0.2.1816.0-2_amd64.deb Files: a04a79c539f5b988dfe312f597f282fd 2327 haskell extra haskell-sfml-audio_0.2.1816.0-2.dsc a182458fa45da47c6e0e1cd6124a4e29 2130 haskell extra haskell-sfml-audio_0.2.1816.0-2.debian.tar.gz 95fd8157b43a692f70f5110b2f8f86d0 30506 doc extra libghc-sfml-audio-doc_0.2.1816.0-2_all.deb 45d485051d5cfeb2f9582b1ec740a481 81744 haskell extra libghc-sfml-audio-dev_0.2.1816.0-2_amd64.deb dae6870bab479da29ec60aef11e08f77 54360 haskell extra libghc-sfml-audio-prof_0.2.1816.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMmelAAoJEONS1cUcUEHUwmQQALEH10ybbBut0xBApG3b++/L K9niIoi1XYCr/sdDwmuNXVCQGZsjorGqDSVLf4IAQ7zCEJYgg/WLqsd9AXsBNLlO Gm6c9rSiyCfKaN5EmRBrOXxOi63yX7e3nK9kz0U6AzMBXvyFwyYSKrES2/A0BcHD ZrjQR2tAGHXaHJQbn8nlel0D++y2jQmsErnJYFvfl12u65BY97GbfzgrbmKGjBEp hlxCY8rFQZpfY1pQ5OE4CmETbZvefaFbREfrHEUY2Fi1hd/alt3v3jN/40VQv5dj VCUJeoIWIzhJ1/yeEmAboYbu01LbEiNFULI6rlJOAp4iJorjK+106Kv3aT5LWnKT gMirsEaogSYrODumKsSa1WmfWjX9LXacQe7eGdKTds7yJE21zTVZQOcBFzX2gbwz 2lUFSiXRIqhGtnlflXBLCvKMJie/6WQZ/z+i6gaWKpt1G/Guq6XRrq9aMOou4OTr 12+Y1F7xLyxJ4GhfVtymTd3UxIWZIel2b2/RXPN1ZU4eNtYXz6/4fJFMGGs8sNK2 +iuotrNYPFKVRj1qnPAjfkMoTnku37DIpoW+IbcTfc6oHDuiYQ9V1VMcIZtBiRZX 6JIqVfqbrzZO5xvrXCeooKOO1Kuih+nAeh6MrHziuGDYLMJFIJ7sDd6oK+8IrvLg 79PjEl9TX1rXIr3VproB =6TUc -END PGP SIGNATURE- Accepted: haskell-sfml-audio_0.2.1816.0-2.debian.tar.gz to main/h/haskell-sfml-audio/haskell-sfml-audio_0.2.1816.0-2.debian.tar.gz haskell-sfml-audio_0.2.1816.0-2.dsc to main/h/haskell-sfml-audio/haskell-sfml-audio_0.2.1816.0-2.dsc libghc-sfml-audio-dev_0.2.1816.0-2_amd64.deb to main/h/haskell-sfml-audio/libghc-sfml-audio-dev_0.2.1816.0-2_amd64.deb libghc-sfml-audio-doc_0.2.1816.0-2_all.deb to main/h/haskell-sfml-audio/libghc-sfml-audio-doc_0.2.1816.0-2_all.deb libghc-sfml-audio-prof_0.2.1816.0-2_amd64.deb to main/h/haskell-sfml-audio/libghc-sfml-audio-prof_0.2.1816.0-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rv6jc-0004ty...@franck.debian.org
