date:20120817


* Vincent Bernat ber...@debian.org, 2012-08-16, 19:24:
1. The license allows redistribution and modification of the minified 
version without having the sources. Therefore, we are only dealing with 
DFSG here.


While jQuery license is permissive, it does impose certain conditions[0] 
on distributors. In my experience, upstreams often fail to fulfil these 
requirements.


3. Repacking the original tarball just to remove those files is extra  
work.


Part of the problem is that we lack good tools to do this extra work for 
us. Really, repacking shouldn't be a tedious operation, it shouldn't 
take more than 5 seconds, it shouldn't require writing two dozens lines 
of code and documentation. :(



[0] “The above copyright notice and this permission notice shall be 
included in all copies or substantial portions of the Software.”


--
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/20120817073904.ga3...@jwilk.net

Re: Bug#685064: ITP: non-daw -- please package non-things

2012-08-17 Thread Jon Dowland

On Thu, Aug 16, 2012 at 11:19:23AM +0200, rosea grammostolla wrote:
 Subject: Re: Bug#685064: ITP: non-daw -- please package non-things
   ^

You've filed an ITP (I Intent To Package) but your subject reads more
like a Request For someone else to Package (RFP).  Can you clarify
which you meant?

 * Package name: non-daw
…
 The Non DAW…
 The Non Mixer…
 The Non Sequencer…
 The Non Session Manager…

The package name suggests you are packaging the DAW but the description
covers the other three things too and suggests to some extent that they
are separate. Would the mixer, sequencer and session manager be provided
in the same package, or in separate packages?


-- 
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/20120817082430.GA17970@debian

Re: Minified javascript files

On Thu, Aug 16, 2012 at 08:59:55PM +0200, Marco d'Itri wrote:
 On Aug 16, Vincent Bernat ber...@debian.org wrote:
 
  I know this is tedious but what others think about this matter?
 This is another case in which the DFSG has become a religion to be 
 followed in a literalist interpretation instead of a tool to be used
 for the purpose of advancing software freedom.

I'd regard using an untouched source and using just the Debian packaged
version of the library (and thus ignoring the upstream shiped copy /
minimisation in the binary package) as common sense.  IMHO DFSG should
not conflict with common sense and if this is the case we might consider
fixing it.

Kind regards

  Andreas.  

-- 
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/20120817082412.gc2...@an3as.eu

Re: Change default PATH for Jessie / wheezy+1

2012-08-17 Thread Jon Dowland

On Wed, Aug 08, 2012 at 04:41:35AM +0200, Ulrich Dangel wrote:
 On 08/08/12 04:11, Marco d'Itri wrote:
  Fedora did it a few months ago, so probably we should do it as well to 
  minimize the pain.
 
 As far as I know (based on 
 https://bugzilla.redhat.com/show_bug.cgi?id=458176 /
 http://fedoraproject.org/wiki/Features/SbinSanity ) Fedora changed it in 2008.
 
 It seems that Ubuntu also has the sbin directories in PATH per default (via
 /etc/environment) since at least 2006.

In which case any pain we were likely to suffer has been suffered already,
so that's one fewer reason to make the change.


-- 
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/20120817082705.GB17970@debian

Re: Change default PATH for Jessie / wheezy+1

2012-08-17 Thread Jon Dowland

On Wed, Aug 08, 2012 at 12:40:42PM +0100, Roger Leigh wrote:
  Warning the user that they are using an obsolete tool is IMO entirely
  justified, particularly when there is a much better and more capable
  replacement.

And there's plenty of precedent:

$ ffmpeg
ffmpeg version 0.8.3-6:0.8.3-4, Copyright (c) 2000-2012 the Libav developers
  built on Jun 26 2012 09:26:41 with gcc 4.7.1
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a 
future release. Please use avconv instead.

(even if the above is somewhat misleading)
And the wodim/cdrecord messages.


-- 
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/20120817083717.GC17970@debian

Re: Minified javascript files

2012-08-17 Thread Bernd Zeimetz

On 08/17/2012 09:39 AM, Jakub Wilk wrote:
 * Vincent Bernat ber...@debian.org, 2012-08-16, 19:24:
 1. The license allows redistribution and modification of the minified
 version without having the sources. Therefore, we are only dealing
 with DFSG here.
 
 While jQuery license is permissive, it does impose certain conditions[0]
 on distributors. In my experience, upstreams often fail to fulfil these
 requirements.
 
 3. Repacking the original tarball just to remove those files is extra 
 work.
 
 Part of the problem is that we lack good tools to do this extra work for
 us. Really, repacking shouldn't be a tedious operation, it shouldn't
 take more than 5 seconds, it shouldn't require writing two dozens lines
 of code and documentation. :(

But it usually does and also results in a source tarball which is
missing essential pieces of the software, so people who download it for
non-Debian usage will fail to run the shipped source just because we
removed an otherwise free piece of software.


 [0] “The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.”
 


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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/502e0675.3040...@bzed.de

Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
 Part of the problem is that we lack good tools to do this extra work
 for us. 

As an unrelated idea which popped up when reading this:  Do you think it
would be a sensible enhancement to uupdate if it could deal with a list
of files (wildcard strings that could be feed to `rm -rf`) which should
be removed from the upstream tarball?  This could simplify repackaging
to a certain amount.

Kind regards

  Andreas.

-- 
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/20120817085859.gd2...@an3as.eu

Re: Minified javascript files

2012-08-17 Thread Thomas Goirand

On 08/17/2012 09:40 AM, Paul Wise wrote:
 On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote:

   
 What I didn't know until recently is that the minified version in the
 source package should be removed (or the appropriate full version should
 be appended).
 
 Do we also require that for say, precompiled DLLs of GTK+ or SDL for
 Windows platforms?
   
I had the OpenSSL dll for windows embedded in one of my source packages,
because there was some windows software together with it. I had to remove
it completely, as I was asked to have the source code for it, and I found
ridiculous to embed the sources of OpenSSL too.

So yes, we have the problem for precompiled windows DLLs in a source
package.

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/502e09bf.9030...@debian.org

Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

2012-08-17 Thread Ivan Shmakov

  Abstract

The non-data packages currently having an absolute dependency on
hicolor-icon-theme should consider downgrading it to Recommends:
at the least.  The list, and the explanation, are below.


  Chapter I
  imagemagick

Recently, Depends: hicolor-icon-theme was added to the
imagemagick's control file, which triggered my curiosity: does
it provide something that wasn't needed (or was missed) by the
previous versions of the package, but is strictly necessary to
run the newer ones?

Indeed, it doesn't.

To prove it, I've made a trivial control file for
equivs-build(1):

--cut: k1o7mjuxokuwghktzugfno8qib.ctl --
Package: k1o7mjuxokuwghktzugfno8qib
Provides: hicolor-icon-theme
Description: Pretend that hicolor-icon-theme is installed (dummy)
 A dummy package pretending to provide hicolor-icon-theme.
--cut: k1o7mjuxokuwghktzugfno8qib.ctl --

Having hicolor-icon-theme removed and this one installed, I've
proceeded to install imagemagick.  Unsurprisingly, I've found
/no/ issues with either installing or running it.  (I've tried
display(1), but I'm quite sure that there won't be any issues
with convert(1), either.)


  Chapter II
  A few packages more

Well, I've wondered, is this a singular issue with Depends:
hicolor-icon-theme, somehow creeped into Debian Wheezy “just
prior” to its scheduled release?

Indeed, it isn't.

I've examined the reverse dependencies of hicolor-icon-theme:

$ apt-cache rdepends  --no-suggests --no-recommends \
  hicolor-icon-theme 
hicolor-icon-theme
Reverse Depends:
  viridian
  tango-icon-theme
  synaptic
  rabbitvcs-core
  perlpanel
  oxygen-icon-theme
  openteacher
  kdelibs5-data
  imagemagick
  gnome-phone-manager
  gnome-icon-theme-symbolic
  gnome-icon-theme-extras
  gnome-icon-theme
  flush
  d-feet
$ 

Well, it doesn't seem suspicious for anything *-icon-* and
*-data to depend on an icon theme, but what about the rest?

For a start, I've omitted rabbitvcs-core and viridian, and
considered d-feet, flush, openteacher, perlpanel, and synaptic.
Unsurprisingly, all of them were able to install and run, but
while openteacher is seemingly unaffected by the absence of the
data in question, the rest have had obvious issues: almost all
of the icons were absent, resulting in blank space on the GUI,
missing controls, and warnings to stderr (stdout?)


  Conclusion

Since there're (as it seems) virtually no issues with running
imagemagick without a “real” hicolor-icon-theme installed, my
suggestion would be to downgrade the dependency to Suggests: (or
Recommends:, if there's some point I've missed.)

As for the other packages considered, my suggestion would be to
downgrade the dependencies to Recommends: (or, for openteacher,
to Suggests:, if it's indeed unaffected.)

Unless there'd be any objections, I'll consider filing a bug
against imagemagick, and perhaps the other aforementioned
packages as well.


  Post Scriptum

Curiously enough, the only “application” package having a
Recommends: dependency on hicolor-icon-theme is cheese.

-- 
FSF associate member #7257  http://sf-day.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/86ehn551jr@gray.siamics.net

Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

2012-08-17 Thread Bastien ROUCARIES

On Fri, Aug 17, 2012 at 11:07 AM, Ivan Shmakov oneing...@gmail.com wrote:
   Abstract

 The non-data packages currently having an absolute dependency on
 hicolor-icon-theme should consider downgrading it to Recommends:
 at the least.  The list, and the explanation, are below.


   Chapter I
   imagemagick

 Recently, Depends: hicolor-icon-theme was added to the
 imagemagick's control file, which triggered my curiosity: does
 it provide something that wasn't needed (or was missed) by the
 previous versions of the package, but is strictly necessary to
 run the newer ones?

 Indeed, it doesn't.

 To prove it, I've made a trivial control file for
 equivs-build(1):


first thanks for this but a bug report to imagemagick will be
morehelpful. Secondly I add depends on  hicolor-icon-theme in order to
use
the trigger on it for registering icon-cache.

Do you have checked if display on menu show the icons ?

Did you check if you install  hicolor-icon-theme after icon cache
trigger run correctly on the imagemagick icons ?

[...]
 Well, it doesn't seem suspicious for anything *-icon-* and
 *-data to depend on an icon theme, but what about the rest?

 For a start, I've omitted rabbitvcs-core and viridian, and
 considered d-feet, flush, openteacher, perlpanel, and synaptic.
 Unsurprisingly, all of them were able to install and run, but
 while openteacher is seemingly unaffected by the absence of the
 data in question, the rest have had obvious issues: almost all
 of the icons were absent, resulting in blank space on the GUI,
 missing controls, and warnings to stderr (stdout?)

Yes lack of icon. it the same on the gnome menu if I remove the

For imagemagick this will be solved in a future release with a non X
depend on the base version. But it is really too late on freeze.

Bastien


   Conclusion

 Since there're (as it seems) virtually no issues with running
 imagemagick without a “real” hicolor-icon-theme installed, my
 suggestion would be to downgrade the dependency to Suggests: (or
 Recommends:, if there's some point I've missed.)

 As for the other packages considered, my suggestion would be to
 downgrade the dependencies to Recommends: (or, for openteacher,
 to Suggests:, if it's indeed unaffected.)

 Unless there'd be any objections, I'll consider filing a bug
 against imagemagick, and perhaps the other aforementioned
 packages as well.


   Post Scriptum

 Curiously enough, the only “application” package having a
 Recommends: dependency on hicolor-icon-theme is cheese.

 --
 FSF associate member #7257  http://sf-day.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/86ehn551jr@gray.siamics.net



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cae2spabgkudj7acjbgks+y3ybita2jt4j2z792oxaaxfzoe...@mail.gmail.com

Re: Minified javascript files

2012-08-17 Thread Luca Capello

Hi there!

On Fri, 17 Aug 2012 10:53:09 +0200, Bernd Zeimetz wrote:
 On 08/17/2012 09:39 AM, Jakub Wilk wrote:
 * Vincent Bernat ber...@debian.org, 2012-08-16, 19:24:
 3. Repacking the original tarball just to remove those files is extra 
 work.
 
 Part of the problem is that we lack good tools to do this extra work for
 us. Really, repacking shouldn't be a tedious operation, it shouldn't
 take more than 5 seconds, it shouldn't require writing two dozens lines
 of code and documentation. :(

 But it usually does and also results in a source tarball which is
 missing essential pieces of the software, so people who download it for
 non-Debian usage will fail to run the shipped source just because we
 removed an otherwise free piece of software.

I fully agree with Bernd here: if what we want to remove is under a free
license, then I would not repack the original tarball simply because we
do not use it.

Thx, bye,
Gismo / Luca


pgpKpAjCBu2jJ.pgp
Description: PGP signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

2012-08-17 Thread Daniel Leidert

Andreas Tille wrote:
 On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
  Part of the problem is that we lack good tools to do this extra work
  for us. 
 
 As an unrelated idea which popped up when reading this:  Do you think it
 would be a sensible enhancement to uupdate if it could deal with a list
 of files (wildcard strings that could be feed to `rm -rf`) which should
 be removed from the upstream tarball?  This could simplify repackaging
 to a certain amount.

I use a script for this:

http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/watch?view=markup
http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/get-orig-source.sh?view=markup

There are several other examples in this tree. It is pretty simple. Just
replace line 20 in get-orig-source.sh with whatever you want to do here.
FYI: I don't make use of uupdate. I don't need it in my setup.

Regards, Daniel


-- 
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/20120817095502.134...@gmx.net

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

2012-08-17 Thread Mike Hommey

On Fri, Aug 17, 2012 at 11:55:02AM +0200, Daniel Leidert wrote:
Andreas Tille wrote:
On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
Part of the problem is that we lack good tools to do this extra work
for us.

As an unrelated idea which popped up when reading this: Do you think it
would be a sensible enhancement to uupdate if it could deal with a list
of files (wildcard strings that could be feed to `rm -rf`) which should
be removed from the upstream tarball? This could simplify repackaging
to a certain amount.

I use a script for this:

http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/watch?view=markup
http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/get-orig-source.sh?view=markup

There are several other examples in this tree. It is pretty simple. Just
replace line 20 in get-orig-source.sh with whatever you want to do here.
FYI: I don't make use of uupdate. I don't need it in my setup.

I'm using a more sophisticated script, that allows to filter at the same
time as the file is downloaded, without actually extracting to disk.
http://anonscm.debian.org/gitweb/?p=pkg-mozilla/iceweasel.git;a=blob;f=debian/repack.py;h=a797d5471f20e0f8de155d483e5ad2f1b2c3bdc5;hb=c1ebf8be93add288837377e4fdd87f9c9f1082cc

This can seem a worthless optimization, but when your source tarball is
more than 80MB bzipped, it makes a huge difference (especially when
downloading is rather slow, in which case the whole process is about as
fast as downloading alone)

It supports wildcards, and extra filters (sed-like). See, for example,
the filter used on iceweasel source:
http://anonscm.debian.org/gitweb/?p=pkg-mozilla/iceweasel.git;a=blob;f=debian/source.filter;h=ec7efac7b97add1f39480c07fecb4b70ae7a7ec8;hb=c1ebf8be93add288837377e4fdd87f9c9f1082cc

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/20120817102356.ga7...@glandium.org

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

2012-08-17 Thread Mike Hommey

On Fri, Aug 17, 2012 at 12:23:56PM +0200, Mike Hommey wrote:
On Fri, Aug 17, 2012 at 11:55:02AM +0200, Daniel Leidert wrote:
Andreas Tille wrote:
On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
Part of the problem is that we lack good tools to do this extra work
for us.

I use a script for this:

http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/watch?view=markup
http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/get-orig-source.sh?view=markup

Oh, and the script just works out of the box with uscan:

http://anonscm.debian.org/gitweb/?p=pkg-mozilla/iceweasel.git;a=blob;f=debian/watch;h=a81586cc891ab608c52717069c99703227e4d077;hb=c1ebf8be93add288837377e4fdd87f9c9f1082cc

Mike

Re: Minified javascript files

2012-08-17 Thread Simon Josefsson

Thomas Goirand z...@debian.org writes:

 On 08/17/2012 09:40 AM, Paul Wise wrote:
 On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote:

   
 What I didn't know until recently is that the minified version in the
 source package should be removed (or the appropriate full version should
 be appended).
 
 Do we also require that for say, precompiled DLLs of GTK+ or SDL for
 Windows platforms?
   
 I had the OpenSSL dll for windows embedded in one of my source packages,
 because there was some windows software together with it. I had to remove
 it completely, as I was asked to have the source code for it, and I found
 ridiculous to embed the sources of OpenSSL too.

 So yes, we have the problem for precompiled windows DLLs in a source
 package.

Interesting, that issue seems rather common.  Maybe a lintian check
could alarm packagers of this?

See below for a list of *.dll files in packages starting with 'a' only.
Overall, I found *.dll files in around 131 packages (of course not all
of those represent a problem).

/Simon

./abe_1.1.orig.tar.gz:abe-1.1/SDL.dll
./abe_1.1.orig.tar.gz:abe-1.1/SDL_mixer.dll
./activemq_5.6.0+dfsg.orig.tar.gz:activemq-5.6.0+dfsg/assembly/src/release/bin/win64/wrapper.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/alpine/ldap32.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/debug/ldap32.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/debug/libldap.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/release/ldap32.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/release/libldap.dll
./altos_1.0.3.tar.gz:altos-1.0.3/altosui/Instdrv/NSIS/Plugins/InstDrv.dll
./antlr_2.7.7+dfsg.orig.tar.gz:antlr-2.7.7/examples/csharp/csharp_v1/Tools/runtime.dll
./antlr_2.7.7.orig.tar.gz:antlr-2.7.7/examples/csharp/csharp_v1/Tools/runtime.dll
./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/ddk_make/sources_dll
./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/libusb0.dll
./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/libusb0_x64.dll
./armadillo_0.9.52.orig.tar.gz:armadillo-0.9.52/examples/lib_win32/blas_win32_MT.dll
./armadillo_0.9.52.orig.tar.gz:armadillo-0.9.52/examples/lib_win32/lapack_win32_MT.dll
./atanks_5.5.orig.tar.gz:atanks-5.5/alleg42.dll
./atanks_5.5.orig.tar.gz:atanks-5.5/src/alleg42.dll


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

Re: Minified javascript files

2012-08-17 Thread Andrey Rahmatullin

On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote:
  So yes, we have the problem for precompiled windows DLLs in a source
  package.
 
 Interesting, that issue seems rather common.  Maybe a lintian check
 could alarm packagers of this?
http://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Fri, Aug 17, 2012 at 12:26:49PM +0200, Mike Hommey wrote:
As an unrelated idea which popped up when reading this: Do you think it
would be a sensible enhancement to uupdate if it could deal with a list
of files (wildcard strings that could be feed to `rm -rf`) which should
be removed from the upstream tarball? This could simplify repackaging
to a certain amount.

I use a script for this:

http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/watch?view=markup
http://anonscm.debian.org/viewvc/debichem/unstable/openbabel/debian/get-orig-source.sh?view=markup

Sure, you need to replace uupdate by your own script and my suggestion
was to let uupdate do this for you by a unified interface instead of
having everybody writing its own debian/get-orig-source script.

Oh, and the script just works out of the box with uscan:

http://anonscm.debian.org/gitweb/?p=pkg-mozilla/iceweasel.git;a=blob;f=debian/watch;h=a81586cc891ab608c52717069c99703227e4d077;hb=c1ebf8be93add288837377e4fdd87f9c9f1082cc

So we finally have three independently developed solutions (we also have
several instances of a debian/get-orig-source script in Debian Med
team) and my suggestion was just to settle with a common and simple
solution. This should be pretty simple to implement (I'd volunteer to
do this but wanted to seek for comments before filing a bug report +
patch).

Kind regards

Andreas.

--
http://fam-tille.de

Re: Minified javascript files


* Bernd Zeimetz be...@bzed.de, 2012-08-17, 10:53:
3. Repacking the original tarball just to remove those files is extra 
work.


Part of the problem is that we lack good tools to do this extra work 
for us. Really, repacking shouldn't be a tedious operation, it 
shouldn't take more than 5 seconds, it shouldn't require writing two 
dozens lines of code and documentation. :(


But it usually does and also results in a source tarball which is 
missing essential pieces of the software, so people who download it for 
non-Debian usage will fail to run the shipped source just because we 
removed an otherwise free piece of software.


Meh. How is it different from the software failing to build/work because 
of other missing (build-)dependencies? Or: why did upstream stuffed this 
JavaScript blob into their tarballs in the first place? (These are 
serious questions, answers for which should bring us closer to a 
solution for the problem.)


Also, it should be noted that repacking is not the only way of 
satisfying DFSG§2. Others that come to my mind:


1) Ask upstream to include the full source in their tarballs! (I know, 
this is hard.)


2) Put the source somewhere in the debian/ directory. (Don't forget to 
mention this fact in the copyright file.)


3) Make a new source package containing every jQuery version existing in 
the wild, then build depend on that.


--
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/20120817111437.ga8...@jwilk.net

Re: Minified javascript files

On Fri, Aug 17, 2012 at 1:14 PM, Jakub Wilk jw...@debian.org wrote:

 3) Make a new source package containing every jQuery version existing in the
 wild, then build depend on that.

FTP Masters do not like that solution.

Vincent's question was due to FTP masters complaining about the
package 'witty', which I maintain and he sponsors.

http://packages.qa.debian.org/w/witty.html

Witty does build-depend on libjs-jquery (it has for a long time, way
before FTP masters expressed any concern), then minifies it, and
symlinks it. But FTP Masters say the jquery.min.js must be removed
from witty.orig.tar.gz because the non-minified version is not
included.

Given that I'm not using upstream's jquery.min.js at all, I wonder why
I should repackage the source package.

How is an unused jquery.min.js in the original tarball different from
any other unused file (a picture, a README, or anything?) The users is
not expected to modify jquery.min.js ever, if he wants to rebuild the
binaries for witty, he is expected to modify libjs-jquery.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


-- 
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/CAKcBokuzz_iZK9qOhLgW=x+mh02gr7jydsrusp34u6vtl4j...@mail.gmail.com

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:

 So we finally have three independently developed solutions (we also have
 several instances of a debian/get-orig-source script in Debian Med
 team) and 

pkg-perl variant:
http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=tree
repack.sh and repack.stub there

 my suggestion was just to settle with a common and simple
 solution.  This should be pretty simple to implement (I'd volunteer to
 do this but wanted to seek for comments before filing a bug report +
 patch).

Yup, that would be nice.
But I don't think it belongs into uupdate but in uscan.

Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Stevie Wonder: Your Are the Sunshine of My Life


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Fri, Aug 17, 2012 at 1:08 PM, Andreas Tille andr...@an3as.eu wrote:
 On Fri, Aug 17, 2012 at 12:26:49PM +0200, Mike Hommey wrote:
As an unrelated idea which popped up when reading this:  Do you think 
it
would be a sensible enhancement to uupdate if it could deal with a list
of files (wildcard strings that could be feed to `rm -rf`) which should
be removed from the upstream tarball?  This could simplify repackaging
to a certain amount.
  
   I use a script for this:
  
[...]

  I'm using a more sophisticated script, that allows to filter at the same
  time as the file is downloaded, without actually extracting to disk.
[...]

It's not a matter of using a better or worse script, having dpkg, or
uupdate, or some other tool do that for us. It's a matter of
repackaging. It's a matter of altering upstream's package for (IMHO)
no good reason. It's a matter of breaking user confidence: users are
no longer able to compare Debian's .orig.tar.gz with upstream's
tarball, or with Gentoo's traball, or with Fedora's tarball, etc just
because we are shipping a different source tarball.

I can understand repackaging when there are licensing issues,
copyright issues, etc (music files, unlicensed artwork, etc) but for
jQuery's minified JavaScript file, which is distributed under full
compliance with jQuery's license and we have the full source
(un-mininified) and the package build-depends on libjs-jquery and the
package does not use the minified file at all? Give me a break.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


-- 
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/CAKcBoktL5JJJVs=o450q9unv5sma7-nlvzde67etwrflwz7...@mail.gmail.com

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

Hi,

On Fri, Aug 17, 2012 at 01:55:23PM +0200, Pau Garcia i Quiles wrote:
 On Fri, Aug 17, 2012 at 1:08 PM, Andreas Tille andr...@an3as.eu wrote:
  On Fri, Aug 17, 2012 at 12:26:49PM +0200, Mike Hommey wrote:
 As an unrelated idea which popped up when reading this:  Do you 
 think it
   ^^

 would be a sensible enhancement to uupdate if it could deal with a 
 list
 of files (wildcard strings that could be feed to `rm -rf`) which 
 should
 be removed from the upstream tarball?  This could simplify 
 repackaging
 to a certain amount.
   
I use a script for this:
   
 [...]
 
   I'm using a more sophisticated script, that allows to filter at the same
   time as the file is downloaded, without actually extracting to disk.
 [...]
 
 It's not a matter of using a better or worse script, having dpkg, or
 uupdate, or some other tool do that for us. It's a matter of
 repackaging. It's a matter of altering upstream's package for (IMHO)
 no good reason.

Please read again my initial mail.  We all know that there are good
reasons to repack.  Simply assume I'd write about these cases.

Kind regards

   Andreas. 

-- 
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/20120817115851.gd6...@an3as.eu

Re: Minified javascript files

2012-08-17 Thread Raphael Hertzog

On Fri, 17 Aug 2012, Pau Garcia i Quiles wrote:
 Given that I'm not using upstream's jquery.min.js at all, I wonder why
 I should repackage the source package.

I agree with you that it's useless work. But the ftpmasters believe that
Debian is made of source and binary packages and that the content of the
source package should respect DFSG #2 “The program must include source
code[...]”.

Maybe we should fix DFSG #2 to say “The program must include source code
for all the files that gets installed in the Debian binary packages [...]“.

That way, there's no need to strip unused RFC, minified javascript, Flash files,
PDF without sources, etc. All this has been useless bureaucracy which has
drawn people away.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120817120337.gb23...@rivendell.home.ouaza.com

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

Hi Gregor,

On Fri, Aug 17, 2012 at 01:47:48PM +0200, gregor herrmann wrote:
 On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:
 
  So we finally have three independently developed solutions (we also have
  several instances of a debian/get-orig-source script in Debian Med
  team) and 
 
 pkg-perl variant:
 http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=tree
 repack.sh and repack.stub there

Solution 4. ;-)
 
  my suggestion was just to settle with a common and simple
  solution.  This should be pretty simple to implement (I'd volunteer to
  do this but wanted to seek for comments before filing a bug report +
  patch).
 
 Yup, that would be nice.
 But I don't think it belongs into uupdate but in uscan.

Right that's correct (and explains Daniel's hint there is no need for
uupdate).

Discussion:

 1. I propose a file debian/uscan.remove which contains regular expressions.
The deletion process will loop over every line and does

 rm -rf ${MAIN_SOURCE_DIR}/expression

 2. uscan just knows the option --repack.  Do we want to reuse this and start
deleting files in case the file debian/uscan.remove exists or do we
want to use an explicite option --repack-and-remove?  I have some
preference for just using --repack.

 3. If the tarball did not contained any of the strings in 
debian/uscan.remove it should be left untouched (except if the repackaging
is needed because of compression method anyway)

 4. In case something was removed the version string will be appended by
'~dfsg' to express the fact that the content of the original source
was changed.
  
What do you think?

Kind regards

  Andreas.

-- 
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/20120817121249.ge6...@an3as.eu

Re: Minified javascript files

2012-08-17 Thread Didier 'OdyX' Raboud

Le vendredi, 17 août 2012 14.03:38, Raphael Hertzog a écrit :
 Maybe we should fix DFSG #2 to say “The program must include source code
 for all the files that gets installed in the Debian binary packages [...]“.

With this modification, upstream might then include (distributable) win32 
executables (or whatever else) in their upstream tarballs and have them 
distributed by the Debian mirrors network without us taking a close look at 
them?

I don't see why we should only be looking at what we distribute in the 
binaries we distribute and not in the sources: we are also distributing 
blessed tarballs as a central part of our free software distribution. If we 
stop doing that in our source tarballs, then why should be care about non-
recompiled blobs in our binary packages?

Cheers,

OdyX


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

Re: Minified javascript files

2012-08-17 Thread Luca Falavigna

2012/8/17 Jakub Wilk jw...@debian.org:
 Part of the problem is that we lack good tools to do this extra work for us.
 Really, repacking shouldn't be a tedious operation, it shouldn't take more
 than 5 seconds, it shouldn't require writing two dozens lines of code and
 documentation. :(

ACK.

Should we write a tool that, once and for all, allows to automate the process?
I think workflow should something similar to:
* tool should receive an URI of the orig tarball
* tool should download and unpack the orig tarball
* tool should compare orig tarball with already clean sources
* tool should not consider file differences, just file removals
* tool should generate a policy-compliant get-orig-source target based
on the diff

Also, where to put this tool? Devscripts?


-- 
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/CADk7b0OpYe8HzYYFSxRZ7wbxhugj=k9o8sbkw5yuvcwfbo1...@mail.gmail.com

Re: Minified javascript files

2012-08-17 Thread Luca Falavigna

2012/8/17 Bernd Zeimetz be...@bzed.de:
 But it usually does and also results in a source tarball which is
 missing essential pieces of the software, so people who download it for
 non-Debian usage will fail to run the shipped source just because we
 removed an otherwise free piece of software.

This does not make sense if the removed pieces are useless, as the
core of this discussion is about.

I also don't see the point of providing dozens of convenience copies
of the very same third-party software bundled with every single pet
package. If a software really needs a third-party software, just warn
in $buildsystem_of_choice and in INSTALL file.
Upstream should be really taugth not to reinventing the wheel again
and again and again...


-- 
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/cadk7b0mxazk+ejmoe1u9fdbevimmkqx98r5gydywsma1bzx...@mail.gmail.com

Re: Minified javascript files

Hi Luca,

On Fri, Aug 17, 2012 at 03:01:12PM +0200, Luca Falavigna wrote:
 2012/8/17 Jakub Wilk jw...@debian.org:
  Part of the problem is that we lack good tools to do this extra work for us.
  Really, repacking shouldn't be a tedious operation, it shouldn't take more
  than 5 seconds, it shouldn't require writing two dozens lines of code and
  documentation. :(
 
 ACK.
 
 Should we write a tool that, once and for all, allows to automate the process?
 I think workflow should something similar to:
 * tool should receive an URI of the orig tarball
 * tool should download and unpack the orig tarball
 * tool should compare orig tarball with already clean sources
 * tool should not consider file differences, just file removals
 * tool should generate a policy-compliant get-orig-source target based
 on the diff
 
 Also, where to put this tool? Devscripts?

Did you read

   http://lists.debian.org/debian-devel/2012/08/msg00397.html

and do you agree that a (enhanced) uscan could be this tool?

Kind regards

  Andreas.

-- 
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/20120817131449.gi6...@an3as.eu

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

2012-08-17 Thread Bastien ROUCARIES

Le 17 août 2012 14:15, Andreas Tille andr...@an3as.eu a écrit :

 Hi Gregor,

 On Fri, Aug 17, 2012 at 01:47:48PM +0200, gregor herrmann wrote:
  On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:
 
   So we finally have three independently developed solutions (we also
have
   several instances of a debian/get-orig-source script in Debian Med
   team) and
 
  pkg-perl variant:
  http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=tree
  repack.sh and repack.stub there

 Solution 4. ;-)

   my suggestion was just to settle with a common and simple
   solution.  This should be pretty simple to implement (I'd volunteer to
   do this but wanted to seek for comments before filing a bug report +
   patch).
 
  Yup, that would be nice.
  But I don't think it belongs into uupdate but in uscan.

 Right that's correct (and explains Daniel's hint there is no need for
 uupdate).

 Discussion:

  1. I propose a file debian/uscan.remove which contains regular
expressions.
 The deletion process will loop over every line and does

  rm -rf ${MAIN_SOURCE_DIR}/expression

  2. uscan just knows the option --repack.  Do we want to reuse this and
start
 deleting files in case the file debian/uscan.remove exists or do we
 want to use an explicite option --repack-and-remove?  I have some
 preference for just using --repack.

  3. If the tarball did not contained any of the strings in
 debian/uscan.remove it should be left untouched (except if the
repackaging
 is needed because of compression method anyway)

  4. In case something was removed the version string will be appended by
 '~dfsg' to express the fact that the content of the original source
 was changed.

 What do you think?

I like this

Please add a flag for specifying recompression method

Bastien

 Kind regards

   Andreas.

 --
 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/20120817121249.ge6...@an3as.eu

Re: Minified javascript files

2012-08-17 Thread Luca Falavigna

2012/8/17 Andreas Tille andr...@an3as.eu:
http://lists.debian.org/debian-devel/2012/08/msg00397.html
 and do you agree that a (enhanced) uscan could be this tool?

Sounds good for the majority of the cases, I don't think there are too
many repacked sources in the archive for which it's impossible to
provide a watch file [0].

[0] maintainers' laziness is not a justification


-- 
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/cadk7b0p1s++rcirmn9fp7gr3yqo8mddo5w7gawz8uomf4w7...@mail.gmail.com

Re: Minified javascript files

On Fri, Aug 17, 2012 at 2:37 PM, Didier 'OdyX' Raboud o...@debian.org wrote:
 Le vendredi, 17 août 2012 14.03:38, Raphael Hertzog a écrit :
 Maybe we should fix DFSG #2 to say “The program must include source code
 for all the files that gets installed in the Debian binary packages [...]“.

 With this modification, upstream might then include (distributable) win32
 executables (or whatever else) in their upstream tarballs and have them
 distributed by the Debian mirrors network without us taking a close look at
 them?

The modification to DFSG #2 that Raphaël proposes is indeed not good
but I'd say this one would clear the issues:

The program ust include source code for all the files that are used
in building the Debian binary packages

Which means:
- If upstream is including jquery.min.js but I'm not using it because
I'm using libjs-jquery, I don't need to repack the source tarball
- If upstream is including a a Win32 DLL but I'm not using it for
anything, I don't need to repack the source tarball
etc

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
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/cakcbokv+hnafhtjkv2c7xtqgbeq2l8lcjk1fzqeozk6fhsk...@mail.gmail.com

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Fri, Aug 17, 2012 at 03:12:02PM +0200, Bastien ROUCARIES wrote:
 I like this
 
 Please add a flag for specifying recompression method

Noted.  On the other hand I wonder whether this should be separated from
the removal issue because we currently just do have a --repack option
and I think this should also regard a recompression method.

So this should probably end up in a different (wishlist) bug report and
I (personally) will concentrate first on the removal task.

Kind regards

   Andreas.

-- 
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/20120817135312.gj6...@an3as.eu

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On 12-08-17 at 02:12pm, Andreas Tille wrote:
 Hi Gregor,
 
 On Fri, Aug 17, 2012 at 01:47:48PM +0200, gregor herrmann wrote:
  On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:
  
   So we finally have three independently developed solutions (we also have
   several instances of a debian/get-orig-source script in Debian Med
   team) and 
  
  pkg-perl variant:
  http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=tree
  repack.sh and repack.stub there
 
 Solution 4. ;-)
  
   my suggestion was just to settle with a common and simple
   solution.  This should be pretty simple to implement (I'd volunteer to
   do this but wanted to seek for comments before filing a bug report +
   patch).
  
  Yup, that would be nice.
  But I don't think it belongs into uupdate but in uscan.
 
 Right that's correct (and explains Daniel's hint there is no need for
 uupdate).
 
 Discussion:
 
  1. I propose a file debian/uscan.remove which contains regular expressions.
 The deletion process will loop over every line and does
 
  rm -rf ${MAIN_SOURCE_DIR}/expression

It is already required (or only recommended?) to document in 
debian/copyright when source has been altered, and for that file we 
already have a well defined format for listing file content as part of 
Copyright file format 1.0, a.k.a. DEP5.

I suggest instead of adding a new file to instead check if 
debian/copyright contains as first line a supported URL (i.e. currently 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
is the only valid URL), and if so parses the header paragraph for the 
undocumented-but-also-not-disallowed field Files-Excluded, like this:

Format: 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Susy
Upstream-Contact: Eric Meyer e...@oddbird.net
Source: http://susy.oddbird.net/
 Repackaged, excluding non-DFSG licensed fonts and source-less 
JavaScript
Files-Excluded:
  docs/source/fonts/*
  docs/source/javascripts/jquery-1.7.1.min.js
  docs/source/javascripts/modernizr-2.5.3.min.js


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)


* Jonas Smedegaard d...@jones.dk, 2012-08-17, 16:38:
It is already required (or only recommended?) to document in 
debian/copyright when source has been altered,


See bug #561494.

--
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/20120817151747.ga3...@jwilk.net

Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

2012-08-17 Thread Simon McVittie

On 17/08/12 10:07, Ivan Shmakov wrote:
   Unsurprisingly, all of them were able to install and run, but
   while openteacher is seemingly unaffected by the absence of the
   data in question, the rest have had obvious issues: almost all
   of the icons were absent, resulting in blank space on the GUI,
   missing controls, and warnings to stderr (stdout?)

hicolor-icon-theme is really the infrastructure for a theme, rather than
*being* a theme: it does not contain any icons of its own. It represents
the fallback icon theme for all desktops that use freedesktop.org themes
(GNOME, KDE, XFCE, etc.). The name hicolor is for historical reasons -
it was the default icon theme hard-coded into old versions of one of the
major desktop environments (KDE 2 or 3, I think?) and it stuck.

Its purpose is to be the theme into which applications install their
theme-neutral icons: anything that displays a themeable icon should
search for it in the configured theme, and then fall back to hicolor.
Its only file outside /usr/share/doc is metadata describing the
directories it provides (index.theme, 24K), and its postinst and dpkg
trigger maintain a Gtk icon cache for icons added to it by applications.

For instance, d-feet installs
/usr/share/icons/hicolor/24x24/apps/d-feet-icon.png, among others. In
principle, the author of an icon theme could ship their own
d-feet-icon.png (e.g. .../gnome/.../apps/d-feet-icon.png for the GNOME 3
icon theme) which would take precedence. If they don't, the menu
displaying the icon should automatically fall back to the
theme-neutral version in hicolor, provided by d-feet itself. The
result is that icon themes or desktop environments can re-theme
applications' icons if they want to, but any applications that they
don't cover will get a reasonable theme-neutral fallback icon.

   Since there're (as it seems) virtually no issues with running
   imagemagick without a “real” hicolor-icon-theme installed, my
   suggestion would be to downgrade the dependency to Suggests: (or
   Recommends:, if there's some point I've missed.)

Turning this round: what benefit would we derive from avoiding
depedencies on hicolor-icon-theme? It doesn't depend on anything, and
contains exactly one file (and a bunch of empty directories) outside
/usr/share/doc.

I don't think we could potentially save 24K on those rare systems that
have certain specific X apps, but no GUI menu is a very compelling
reason to change packages' dependencies?

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/502e6d3e.6010...@debian.org

Re: Minified javascript files

2012-08-17 Thread Vincent Bernat

 ❦ 17 août 2012 09:39 CEST, Jakub Wilk jw...@debian.org :

 1. The license allows redistribution and modification of the
 minified version without having the sources. Therefore, we are only
 dealing with DFSG here.

 While jQuery license is permissive, it does impose certain
 conditions[0] on distributors. In my experience, upstreams often fail
 to fulfil these requirements.

Unmodified minified versions (downloaded from the website or from a CDN)
keeps the appropriate copyright notice. Minifiers also keep the first
comment which happens to be the license block, unless instructed
otherwise.

 [0] “The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.”

That's true that the permission notice is not included in the copy. But,
this is also the case for the version provided by jQuery and for the
version we provide ourselves in libjs-jquery.
-- 
die_if_kernel(Kernel gets FloatingPenguinUnit disabled trap, regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c


pgpnEnxn0EQb6.pgp
Description: PGP signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On 12-08-17 at 05:17pm, Jakub Wilk wrote:
 * Jonas Smedegaard d...@jones.dk, 2012-08-17, 16:38:
 It is already required (or only recommended?) to document in
 debian/copyright when source has been altered,
 
 See bug #561494.

Thanks.  That bug is about it _both_ being required by Debian Policy to 
document in debian/copyright and it _also_ being documented in 
developers reference that such info should be in README.Source.

I recommend against storing it at yet another place.

I also happen to favor putting machine-readable information about 
copyright-related repackaging at, well, the machine-readable copyright 
file.


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)


* Jonas Smedegaard d...@jones.dk, 2012-08-17, 19:27:
It is already required (or only recommended?) to document in 
debian/copyright when source has been altered,

See bug #561494.
Thanks.  That bug is about it _both_ being required by Debian Policy to 
document in debian/copyright and it _also_ being documented in 
developers reference that such info should be in README.Source.


FWIW, it's the other way round: Policy says README.source, DevRef says 
debian/copyright.


--
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/20120817174101.ga3...@jwilk.net

Re: Minified javascript files

On 12-08-17 at 07:19pm, Vincent Bernat wrote:
  ❦ 17 août 2012 09:39 CEST, Jakub Wilk jw...@debian.org :

  [0] “The above copyright notice and this permission notice shall be 
  included in all copies or substantial portions of the Software.”
 
 That's true that the permission notice is not included in the copy. But,
 this is also the case for the version provided by jQuery and for the
 version we provide ourselves in libjs-jquery.

What jQuery does is less relevant: copyright holder need no license.

What we do[0] in libjs-jquery is to include the permission notice in 
debian/copyright - i.e. included in both source and binary package even 
if not embedded into the file itself.


 - Jonas


[0] if we don't it is a bug.

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source

2012-08-17 Thread Tollef Fog Heen

]] Pau Garcia i Quiles 

 It's not a matter of using a better or worse script, having dpkg, or
 uupdate, or some other tool do that for us. It's a matter of
 repackaging. It's a matter of altering upstream's package for (IMHO)
 no good reason. It's a matter of breaking user confidence: users are
 no longer able to compare Debian's .orig.tar.gz with upstream's
 tarball, or with Gentoo's traball, or with Fedora's tarball, etc just
 because we are shipping a different source tarball.

It's customary to add +dfsg or similar when repackaging, so it's pretty
clearly marked that it's not the exact same tarball as upstream's
released and I believe user confusion is small.

Also, I question whether people just check fingerprints instead of
actually diffing the contents of the tarballs themselves.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipch71cw@xoog.err.no

Re: Minified javascript files

2012-08-17 Thread Sam Morris

On Fri, 17 Aug 2012 16:43:51 +0600, Andrey Rahmatullin wrote:

 On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote:
  So yes, we have the problem for precompiled windows DLLs in a source
  package.
 
 Interesting, that issue seems rather common.  Maybe a lintian check
 could alarm packagers of this?
 http://lintian.debian.org/tags/source-contains-prebuilt-windows-
binary.html

This includes:

tcltrf (source)
 * win/msvcrt.dll

This is part of Windows. I don't expect Debian has been granted 
permission to distribute it. :)

I wonder how many of these DLLs and EXEs link together code licensed 
under the GPL with versions of the Microsoft Visual C++ Runtime that does 
not ship with Windows (and hence qualify for the 'major parts of the 
operating system' exception)?

«i686-w64-mingw32-objdump -p foo.dll | grep 'DLL Name'» will output a 
list of dependant DLLs. The bad ones to look for match at least «msvc[pr]
[0-9]+.dll» or «mfc[0-9]+.dll» (case-insensitively). I'd do this myself, 
but I don't have the hard drive space nor the bandwidth here, sorry.

Regards,

-- 
Sam Morris


-- 
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/pan.2012.08.17.19.50...@robots.org.uk

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

Hi,

On Fri, Aug 17, 2012 at 07:41:01PM +0200, Jakub Wilk wrote:
 Thanks.  That bug is about it _both_ being required by Debian
 Policy to document in debian/copyright and it _also_ being
 documented in developers reference that such info should be in
 README.Source.
 
 FWIW, it's the other way round: Policy says README.source, DevRef
 says debian/copyright.

I admit I really like the proposal from Jonas and for our purpose only a
machine readable format can be used - so debian/copyright is the only
(currently existing) file we can use.

I admit I'm not very experienced with Perl and reading RFC822 files - so
if somebody would help implementing this I'd be glad.

Kind regards

Andreas.

-- 
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/20120817201807.gk6...@an3as.eu

Re: Minified javascript files

2012-08-17 Thread Raphael Hertzog

Hi,

On Fri, 17 Aug 2012, Luca Falavigna wrote:
 2012/8/17 Bernd Zeimetz be...@bzed.de:
  But it usually does and also results in a source tarball which is
  missing essential pieces of the software, so people who download it for
  non-Debian usage will fail to run the shipped source just because we
  removed an otherwise free piece of software.
 
 This does not make sense if the removed pieces are useless, as the
 core of this discussion is about.

They are not useless if you take the pristine source which is the
situation that was described by Bernd. When we remove files we often have
to do supplementary modifications (debian/patches/ or add symlink at the
proper place) to get the software to work again... for example changing
the path where the libraries are expected to be found.

 I also don't see the point of providing dozens of convenience copies
 of the very same third-party software bundled with every single pet
 package.

The point is that they do mostly no harm and that saving those few
kilobytes cost human time. Our scarcest resource is human time...

 If a software really needs a third-party software, just warn
 in $buildsystem_of_choice and in INSTALL file.
 Upstream should be really taugth not to reinventing the wheel again
 and again and again...

Unfortunately Debian is not the only downstream of our upstream authors.
While we can try to suggest improvements, we can't always convince them.

That's a reality that we have to live with.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120817202100.ga3...@rivendell.home.ouaza.com

Re: Minified javascript files

On Fri, Aug 17, 2012 at 9:50 PM, Sam Morris s...@robots.org.uk wrote:

  So yes, we have the problem for precompiled windows DLLs in a source
  package.

 Interesting, that issue seems rather common.  Maybe a lintian check
 could alarm packagers of this?
 http://lintian.debian.org/tags/source-contains-prebuilt-windows-
 binary.html

 This includes:

 tcltrf (source)
  * win/msvcrt.dll

 This is part of Windows. I don't expect Debian has been granted
 permission to distribute it. :)

Are you sure it's not wine's?

http://source.winehq.org/WineAPI/msvcrt.html

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


-- 
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/CAKcBoksqu9z4f_3d6bE_EsRL4fvP9xLUqvPYH1s6=weL03EU=q...@mail.gmail.com

Re: Minified javascript files

2012-08-17 Thread Sam Morris

On Fri, 17 Aug 2012 22:35:07 +0200, Pau Garcia i Quiles wrote:

 On Fri, Aug 17, 2012 at 9:50 PM, Sam Morris s...@robots.org.uk wrote:
 
  So yes, we have the problem for precompiled windows DLLs in a
  source package.

 Interesting, that issue seems rather common.  Maybe a lintian check
 could alarm packagers of this?
 http://lintian.debian.org/tags/source-contains-prebuilt-windows-
 binary.html

 This includes:

 tcltrf (source)
  * win/msvcrt.dll

 This is part of Windows. I don't expect Debian has been granted
 permission to distribute it. :)
 
 Are you sure it's not wine's?
 
 http://source.winehq.org/WineAPI/msvcrt.html

Doesn't look like it:

$ strings -e l win/msvcrt.dll
...
VS_VERSION_INFO
StringFileInfo
040904B0
CompanyName
Microsoft Corporation
FileDescription
Microsoft (R) C Runtime Library
FileVersion
5.00.7128
InternalName
MSVCRT.DLL
LegalCopyright
Copyright (C) Microsoft Corp. 1981-1997
OriginalFilename
MSVCRT.DLL
ProductName
Microsoft (R) Visual C++
ProductVersion
5.00.7128
VarFileInfo
Translation

-- 
Sam Morris


-- 
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/pan.2012.08.17.20.41...@robots.org.uk

Re: Minified javascript files


* Pau Garcia i Quiles pgqui...@elpauer.org, 2012-08-17, 22:35:

http://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html

This includes:

tcltrf (source)
* win/msvcrt.dll

This is part of Windows. I don't expect Debian has been granted 
permission to distribute it. :)


Are you sure it's not wine's?


$ strings -e l win/msvcrt.dll | grep ^Copyright
Copyright (C) Microsoft Corp. 1981-1997

--
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/20120817204422.ga7...@jwilk.net

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On 12-08-17 at 10:18pm, Andreas Tille wrote:
 On Fri, Aug 17, 2012 at 07:41:01PM +0200, Jakub Wilk wrote:
  Thanks.  That bug is about it _both_ being required by Debian 
  Policy to document in debian/copyright and it _also_ being 
  documented in developers reference that such info should be in 
  README.Source.
  
  FWIW, it's the other way round: Policy says README.source, DevRef 
  says debian/copyright.

Thanks for clarifying, Jakub!


 I admit I really like the proposal from Jonas and for our purpose only 
 a machine readable format can be used - so debian/copyright is the 
 only (currently existing) file we can use.
 
 I admit I'm not very experienced with Perl and reading RFC822 files - 
 so if somebody would help implementing this I'd be glad.

  grep-dctrl -FFormat -n -sFiles-Excluded \
  http://www.debian.org/doc/packaging-manuals/copyright-format/1.0 \
   debian/copyright

Result should be a space-separated list of files or dirs consumable by 
find, as documented in copyright format.


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Fri, Aug 17, 2012 at 11:03:27PM +0200, Jonas Smedegaard wrote:
  I admit I'm not very experienced with Perl and reading RFC822 files - 
  so if somebody would help implementing this I'd be glad.
 
   grep-dctrl -FFormat -n -sFiles-Excluded \
   http://www.debian.org/doc/packaging-manuals/copyright-format/1.0 \
debian/copyright
 
 Result should be a space-separated list of files or dirs consumable by 
 find, as documented in copyright format.

Well, uscan makes some use of system so this could work - but I hoped
for a more Perl-ish solution (similar to the rfc822 reader in
python-debian).

Kind regards

 Andreas.

-- 
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/20120817223605.gm6...@an3as.eu

Re: Minified javascript files

2012-08-17 Thread Ben Hutchings

On Fri, Aug 17, 2012 at 07:50:39PM +, Sam Morris wrote:
 On Fri, 17 Aug 2012 16:43:51 +0600, Andrey Rahmatullin wrote:
 
  On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote:
   So yes, we have the problem for precompiled windows DLLs in a source
   package.
  
  Interesting, that issue seems rather common.  Maybe a lintian check
  could alarm packagers of this?
  http://lintian.debian.org/tags/source-contains-prebuilt-windows-
 binary.html
 
 This includes:
 
 tcltrf (source)
  * win/msvcrt.dll
 
 This is part of Windows. I don't expect Debian has been granted 
 permission to distribute it. :)
 
It's the run-time library for Microsoft Visual C++ and is, as I
recall, distributable along with applications that are built using
that compiler.  In fact, it is *recommended* to distribute it with
applications.  However, various applications bundled with Windows also
need it, so in practice you can get away without doing this if you're
sure your application doesn't depend on any newer features.

Now, distributing it *separately* from any application or other
library built with that compiler may well be copyright infringement.
But it's a long time since I had to think about this and actually
read the licence.  Anyway, I see no point in distributing the
library with source, since whatever compiler you use to build it
should come with the appropriate run-time library.

 I wonder how many of these DLLs and EXEs link together code licensed 
 under the GPL with versions of the Microsoft Visual C++ Runtime that does 
 not ship with Windows (and hence qualify for the 'major parts of the 
 operating system' exception)?

I don't believe any licence is required for dynamically linking some
program to a library that implements a standard interface that the
program was already written for.

Anyway, GPLv3 explicitly exempts run-time libraries from source
requirements (clause 1 paragraph 3).

Ben.

 «i686-w64-mingw32-objdump -p foo.dll | grep 'DLL Name'» will output a 
 list of dependant DLLs. The bad ones to look for match at least «msvc[pr]
 [0-9]+.dll» or «mfc[0-9]+.dll» (case-insensitively). I'd do this myself, 
 but I don't have the hard drive space nor the bandwidth here, sorry.

-- 
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/20120817224832.ge29...@decadent.org.uk

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Sat, 18 Aug 2012 00:36:05 +0200, Andreas Tille wrote:

 On Fri, Aug 17, 2012 at 11:03:27PM +0200, Jonas Smedegaard wrote:
   I admit I'm not very experienced with Perl and reading RFC822 files - 
   so if somebody would help implementing this I'd be glad.
  
grep-dctrl -FFormat -n -sFiles-Excluded \
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0 \
 debian/copyright
  
  Result should be a space-separated list of files or dirs consumable by 
  find, as documented in copyright format.
 
 Well, uscan makes some use of system so this could work - but I hoped
 for a more Perl-ish solution (similar to the rfc822 reader in
 python-debian).

Might be a job for Debian::Copyright, packaged as
libdebian-copyright-perl.

Cheers,
gregor, cc'ing Nicholas who might be able to lend a helping hand
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source

On Fri, 17 Aug 2012 14:12:49 +0200, Andreas Tille wrote:

   So we finally have three independently developed solutions (we also have
   several instances of a debian/get-orig-source script in Debian Med
   team) and 
  pkg-perl variant:
  http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=tree
  repack.sh and repack.stub there
 Solution 4. ;-)

:)

BTW, there's even documentation on how to use it (and what else is
needed):
http://pkg-perl.alioth.debian.org/howto/repacking.html
  
 Right that's correct (and explains Daniel's hint there is no need for
 uupdate).
 
  1. I propose a file debian/uscan.remove which contains regular expressions.
 The deletion process will loop over every line and does
 
  rm -rf ${MAIN_SOURCE_DIR}/expression

I also like Jonas' idea of using d/copyright.
 
  2. uscan just knows the option --repack.  Do we want to reuse this and start
 deleting files in case the file debian/uscan.remove exists or do we
 want to use an explicite option --repack-and-remove?  I have some
 preference for just using --repack.

Hm, not sure if changing the semantics of an existing option is a
good idea.

What I like about our current way is that I -- once d/watch is
adjusted -- I don't have to do anything besides calling uscan.
 
  4. In case something was removed the version string will be appended by
 '~dfsg' to express the fact that the content of the original source
 was changed.

+dfsg

What I also like about our current scripts is
- that the suffix is configurable if needed
- that it manipulates also MANIFEST (ok, that's perl-specific)
   

Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: The Dubliners: Champion at keeping them rolling


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On Sat, 18 Aug 2012 00:55:15 +0200, gregor herrmann wrote:

I admit I'm not very experienced with Perl and reading RFC822 files - 
so if somebody would help implementing this I'd be glad.

 Might be a job for Debian::Copyright, packaged as
 libdebian-copyright-perl.
 
 Cheers,
 gregor, cc'ing Nicholas who might be able to lend a helping hand

Now really :)


Quick test:

#v+
#!/usr/bin/perl

use Debian::Copyright;
use Data::Dumper;

my $copyright = Debian::Copyright-new();
$copyright-read('debian/copyright');
print Dumper $copyright-header-get('Format-Specification');
#v-

prints

$VAR1 = 
'http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?view=markuppathrev=135';


With Files-Excluded we currently get:
Invalid field given (Files_Excluded) at /usr/share/perl5/Debian/Copyright.pm 
line 113

After adding it to the known fields:

$VAR1 = 'doc/a src/b
 c';



Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bruce Springsteen: Tougher Than The Rest


signature.asc
Description: Digital signature

Re: Minified javascript files

2012-08-17 Thread Charles Plessy

Le Fri, Aug 17, 2012 at 01:19:05PM +0800, Thomas Goirand a écrit :
 On 08/17/2012 01:24 AM, Vincent Bernat wrote:
   3. Repacking the original tarball just to remove those files is extra
  work.

 Yeah, just annoying everyone for a minified jquery in upstream
 tarball is, to me, a bit too extreme to my taste as well, as we all know
 where it's coming from, and even it would be possible to check that
 its hash. However, I do respect this view, and I think you should as well.

Hi all,

I think that it would be great that in addition to respect from bottom to top,
respect also comes from top to bottom, in the form of a written documentation,
that would for instance indicate to what extent we need to reproduce copyright
notices, that would keep a track of why a license is accepted or rejected, etc.

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120818013554.gb32...@falafel.plessy.net

Priority field of xz-utils package

2012-08-17 Thread Jonathan Nieder

(please direct replies to debian-devel only)

Ever since dpkg started using liblzma directly (dpkg 1.16.4), the xz
command is no longer needed in a minimal Debian system.  Based on its
list of reverse-dependencies, it would presumably even be safe to
lower its priority to optional.

I think standard or optional is the correct priority.  To be
conservative I'd also be open to making the priority important.

Dear Debianites, what do you prefer?  I'm cc-ing the release team
because either change this late in the release cycle would require a
freeze exception (and I'd be interested in their advice) and the
installer team because of the effect on the installer size and the
installed package set.

Looking forward to your thoughts,
Jonathan


-- 
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/20120818022337.GA1305@mannheim-rule.local

Re: Priority field of xz-utils package

2012-08-17 Thread Charles Plessy

Le Fri, Aug 17, 2012 at 07:23:37PM -0700, Jonathan Nieder a écrit :
 
 Ever since dpkg started using liblzma directly (dpkg 1.16.4), the xz
 command is no longer needed in a minimal Debian system.  Based on its
 list of reverse-dependencies, it would presumably even be safe to
 lower its priority to optional.
 
 I think standard or optional is the correct priority.  To be
 conservative I'd also be open to making the priority important.
 
 Dear Debianites, what do you prefer?  I'm cc-ing the release team
 because either change this late in the release cycle would require a
 freeze exception (and I'd be interested in their advice) and the
 installer team because of the effect on the installer size and the
 installed package set.

Hello Jonathan,

given that the priorities are set by the Debian archive, (which imports
them from the Debian control files at the first upload only), it is not
needed to upload xz-utils to change its priority.

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120818024244.ge32...@falafel.plessy.net

Accepted logol 1.5.0-6 (source all amd64)

2012-08-17 Thread Olivier Sallou

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Aug 2012 08:00:58 +0200
Source: logol
Binary: logol logol-bin
Architecture: source all amd64
Version: 1.5.0-6
Distribution: unstable
Urgency: low
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Olivier Sallou osal...@debian.org
Description: 
 logol  - Pattern matching tool using Logol language
 logol-bin  - Pattern matching tool using Logol language
Closes: 685079
Changes: 
 logol (1.5.0-6) unstable; urgency=low
 .
   [ Olivier Sallou ]
   * debian/control: Fix typo in description (Closes: #685079).
 Thanks to Erik Esterer erik.este...@gmail.com
Checksums-Sha1: 
 3c835e5528419bd4798f1184ec9253412a2f213d 2370 logol_1.5.0-6.dsc
 f34faac08d0eea2792d27bd119a576cffb21112a 14102 logol_1.5.0-6.debian.tar.gz
 10eb1b552a5ec8260b336071d0e22c6fa1cf4614 1508386 logol_1.5.0-6_all.deb
 1d8b5f488e84f550db414137a6cf67960703731f 1160984 logol-bin_1.5.0-6_amd64.deb
Checksums-Sha256: 
 7e9840bff5445b7bc1d4ea5c8bb3a481070851dbbb6eb441347ddec2c6a59a21 2370 
logol_1.5.0-6.dsc
 0fe4eddefe531f5a12b69d805a96d06b81fdf87b5d97129c2e9d89ee802ff4ac 14102 
logol_1.5.0-6.debian.tar.gz
 d878dffd90618f71b8f4d5935c458c467396add4ac0e4d62da5e36bb23afda23 1508386 
logol_1.5.0-6_all.deb
 f008742d286df2821d452d7799eb8159890d1e4f50f10e117776a5264198c668 1160984 
logol-bin_1.5.0-6_amd64.deb
Files: 
 0996cb947f4812dee56994cbcb173270 2370 science optional logol_1.5.0-6.dsc
 4d46adcc1b4e2b08bf5d21a95c5913f7 14102 science optional 
logol_1.5.0-6.debian.tar.gz
 56c2034c2e0a56cec67313c3c76acf25 1508386 science optional logol_1.5.0-6_all.deb
 b18622b7d0c90124812b7862aeca9030 1160984 science optional 
logol-bin_1.5.0-6_amd64.deb

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

iQIcBAEBCAAGBQJQLd/2AAoJEHjcaNsybYQ4easQAJM4+4i90TpqE4dfjTMw+VVk
nVDMtMdWNVKuVeJz46C/uMZAh18WUzb67PBl5XzTej4gZvuyQQ5zLQUOJRsCLHUB
cOL4lJI+69DjWzQLnbbNMgkldYKljWf6dNGj63kAfw5vh5MPKZ4jv+OwIdmnIEP1
Y66FUb4XRKwXvM+HdP1vrLOa9q/HPaus3uoRNyiyw9xn3a47nqmtAaylKth2DYSC
oUEl9rer0GirxM4tv86Y9sHaff2IlFaT8+r3RSmlFRNyzwI9wTDiQMBC6SBYjr+O
QwNhhhmnZDZ9nCXN7jLix3KTrxhFjQHixBusQqfsN1Wu/hW9VXRL07mrfvG0bYWW
VWS9mrLW5SAaMqu525MJ45D2OTccKsDQJYsFRBlgpiXhiCMWcd6rrakyFcNE2yB2
zPh6/cJZmAzoiAENz7sXTXKtUTl6m1Lp0ZnBD9B9cImSnCFe/O2iRfBogKdcvp7B
O945lSosWunO6cK/LaGf/TIkxbUnvIPY06s6cs8scI5WOnJ3KvBbkascHY6Spx78
vOHfqCv7gj68KhkbXIaJMcTAycvtl/mEXHgoLfA2TBdXOrsiI/gdZp3hrATDvXUr
us4M24wtxWTXzpnWOdqFtlPMP4G2QMTG4hn0CBn4gdr9BESNdUswEW2tiUogjuJH
8UxgLGKC0CsVYVTz0SBy
=Vzpv
-END PGP SIGNATURE-


-- 
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/e1t2fse-0004gy...@franck.debian.org

Accepted zfs-fuse 0.7.0-9 (source amd64)

2012-08-17 Thread Asias He

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 17 Aug 2012 11:50:57 +0800
Source: zfs-fuse
Binary: zfs-fuse
Architecture: source amd64
Version: 0.7.0-9
Distribution: unstable
Urgency: low
Maintainer: Asias He asias.he...@gmail.com
Changed-By: Asias He asias.he...@gmail.com
Description: 
 zfs-fuse   - ZFS on FUSE
Closes: 650955 651873
Changes: 
 zfs-fuse (0.7.0-9) unstable; urgency=low
 .
   * Fix automated monthly scrubs (Closes: #650955)
   * Fix Automated ZFS snapshots using Hanoi algorithm (Closes: #651873)
   * Fix /proc/$pid/oom_adj is deprecated, please use
 /proc/$pid/oom_score_adj instead. issue
Checksums-Sha1: 
 fcffd7cbb4203643e6f3e401bd96c0ded52d77ea 1968 zfs-fuse_0.7.0-9.dsc
 440d39a4a559a766c62d8e70e040b1630f894a35 20704 zfs-fuse_0.7.0-9.debian.tar.gz
 c78213ad2bab0fefbba1609103d8a551f4f9b203 1256336 zfs-fuse_0.7.0-9_amd64.deb
Checksums-Sha256: 
 5d834ce32704720e351c5304a52f938ed74af71b96b1672956e959fc5fb511fe 1968 
zfs-fuse_0.7.0-9.dsc
 4d123e11f9c0c6c3eb8f95ee4094a3e36bed5dab4798147c1a838d9e86f5ed08 20704 
zfs-fuse_0.7.0-9.debian.tar.gz
 04c26671995979d86c177a93b93afbed56c4d61b6f9a2d5767eab42fc9f2ebbf 1256336 
zfs-fuse_0.7.0-9_amd64.deb
Files: 
 7992f9f21a1d82401d22c179e9377498 1968 otherosfs optional zfs-fuse_0.7.0-9.dsc
 1cd7936693faf11a853cf5e709e9e4ab 20704 otherosfs optional 
zfs-fuse_0.7.0-9.debian.tar.gz
 9c37249b3b03c83a807eb4d84b03565a 1256336 otherosfs optional 
zfs-fuse_0.7.0-9_amd64.deb

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

iQIcBAEBAgAGBQJQLcfzAAoJEK7JmSstf/GA3JUP+wbJJHH9Uh+mafmMYzHHVDxi
SYK+ZJr9xSSnjiv/zMELLYfHLhBwqk6CPC235vDx4awtZIQjtb3+Tsujfio4F2u4
0Ier6SmTXAFcQ0nYhF0vNCTx34jf2jdVlXUhDKx3hpBKkneodbfcpPgUSSSvyY2O
GXpgHL3NkQ5oecMJFAMbonpfbWrMzXuWAqIX79jcljBqu/JyC21LApJG3hKUwNRD
8NIZHDe422PwAafnYOBrIYpEBN6R/VVaV8V8NH8oo1qxu7NZDsOZeo43fS16n1eZ
A9bTOPDS0WN/bngIEdEa9GAR8Dv0vYf4QDw2QQP890VDYvUD6iCgJlbav6LY/Urs
DHXmRzG8gHN+gGrdelwT9qgbNPLXR0o7X8YnQBhoYNQflFGIu5jCFoT830XODj/0
huU4h3iQICcLufs+20WYNXHBmLNH0zTqq/kmFlBCkmA8y6MekU1QBaqoFt0pT70a
lT6BEONOkMTb6R8yrEThqZGZ14ttVnVxThgqsgxsf+GjaljRobVw8NcWbeeJrJIK
TVw+8qvzF3Hfp2IdLbMyt7tFvQjXa1/yugLir5ZbHVao2y+l5VKpGLsIiylwie3Q
gp02Xm25tmjkqR1wSgwyaoG0IUguCcb9pGzW1zghvosfHCQNKxTASayQ7un8X0FM
HKFB9N4q/PqgBOTNi3xj
=Vmx+
-END PGP SIGNATURE-


-- 
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/e1t2g6s-0007ha...@franck.debian.org

Accepted tkrat 1:2.2cvs20100105-true-dfsg-6 (source amd64)

2012-08-17 Thread Mattia Monga

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 10 Aug 2012 06:39:24 +0200
Source: tkrat
Binary: tkrat
Architecture: source amd64
Version: 1:2.2cvs20100105-true-dfsg-6
Distribution: unstable
Urgency: low
Maintainer: Mattia Monga mo...@debian.org
Changed-By: Mattia Monga mo...@debian.org
Description: 
 tkrat  - Mail user agent with POP, IMAP, mh support using Tk
Closes: 634584
Changes: 
 tkrat (1:2.2cvs20100105-true-dfsg-6) unstable; urgency=low
 .
   * Remove doc/Makefile
   * Adapt to current Debian tools
   * Make pkgIndex.tcl by hands (Closes: #634584).
   * Bump to new standards (3.9.3)
   * New compilation flags needed for hardening
Checksums-Sha1: 
 e3aa34afea944432ca0c43b2fe258c6df77e7cf5 1529 
tkrat_2.2cvs20100105-true-dfsg-6.dsc
 e239f0cf46a49e7de9134f7bb8310bacda127763 10980 
tkrat_2.2cvs20100105-true-dfsg-6.debian.tar.gz
 bc3368b1d5348602ad6d10ae8a18e2323539eb90 1196538 
tkrat_2.2cvs20100105-true-dfsg-6_amd64.deb
Checksums-Sha256: 
 2270b5522242460e1485ad3e6a94187a4b3fc4b01c5e47d41eb359269e872860 1529 
tkrat_2.2cvs20100105-true-dfsg-6.dsc
 a71e472749313e5b439b2b800e046aba2aa34b6f3fbaabbb32789fcbf7d3d9d7 10980 
tkrat_2.2cvs20100105-true-dfsg-6.debian.tar.gz
 20c3f3c34137a6773f4726ea23ac7629873cef516ccf80b3b438d19599ff3729 1196538 
tkrat_2.2cvs20100105-true-dfsg-6_amd64.deb
Files: 
 ce17874951cacf643fb1892b5b16f06b 1529 mail optional 
tkrat_2.2cvs20100105-true-dfsg-6.dsc
 c59ca3bd10333663aced5c964edd7846 10980 mail optional 
tkrat_2.2cvs20100105-true-dfsg-6.debian.tar.gz
 f79360c8ee3ab990d9aaf5a3ae22171d 1196538 mail optional 
tkrat_2.2cvs20100105-true-dfsg-6_amd64.deb

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

iJwEAQECAAYFAlAkv2AACgkQWdgbZnsNSML5FgP/bk59SLdqlK/FTZSrFykrjOZ1
BxYTyHvGxzPEiPcEdpmArNBE1+GA9rcz/S8P9AopxCDdB8AejYyxuY3ijnF8URmD
pp2wMYpOcCFYRLqa3EHQJGa7Dr2DUrrxoPd2y2B9ZOPsmAnlXLDsKmEh5spJ6hVf
LYAKHtMM75WwNFjWwh4=
=sKpy
-END PGP SIGNATURE-


-- 
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/e1t2gzt-0008fj...@franck.debian.org

Accepted grilo 0.1.20-1 (source i386 all)

2012-08-17 Thread Alberto Garcia

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Aug 2012 10:09:18 +0300
Source: grilo
Binary: libgrilo-0.1-0 libgrilo-0.1-dev libgrilo-0.1-bin libgrilo-0.1-doc 
gir1.2-grilo-0.1
Architecture: source i386 all
Version: 0.1.20-1
Distribution: experimental
Urgency: low
Maintainer: Alberto Garcia agar...@igalia.com
Changed-By: Alberto Garcia agar...@igalia.com
Description: 
 gir1.2-grilo-0.1 - Framework for discovering and browsing media - GObject 
introspect
 libgrilo-0.1-0 - Framework for discovering and browsing media - Shared 
libraries
 libgrilo-0.1-bin - Framework for discovering and browsing media - Binaries
 libgrilo-0.1-dev - Framework for discovering and browsing media - Development 
files
 libgrilo-0.1-doc - Framework for discovering and browsing media - Documentation
Changes: 
 grilo (0.1.20-1) experimental; urgency=low
 .
   * New upstream release.
Checksums-Sha1: 
 5be68ffcab28f47992a9e65b78608df504dc972c 2093 grilo_0.1.20-1.dsc
 a45c9451cd2c229f18cb74e550637d3f07df2257 477860 grilo_0.1.20.orig.tar.xz
 aebe0b659b765f7dd2b672bdd93b275acd86d375 3571 grilo_0.1.20-1.debian.tar.gz
 540ecbd6c9ceffaca19f2516f89f71c95c93bbf1 171842 
libgrilo-0.1-0_0.1.20-1_i386.deb
 0c159aa0894346888105304644c2d8b828ef38f0 222062 
libgrilo-0.1-dev_0.1.20-1_i386.deb
 eb5df48d27fcc47943e2affd2c970bcc422c291b 0 
libgrilo-0.1-bin_0.1.20-1_i386.deb
 e85e9251c6f78c7a71c94687b663599dbc295637 222020 
libgrilo-0.1-doc_0.1.20-1_all.deb
 73ddf738cfd8417a564ff56f9379d9e345edefbe 107654 
gir1.2-grilo-0.1_0.1.20-1_i386.deb
Checksums-Sha256: 
 8adcc05c8b0231f213c1067dfd376fd98750bbdb4b523d31e32e141d08d0d5cc 2093 
grilo_0.1.20-1.dsc
 3438e76a61c74302598c86d6978e67ca51e45440029b0440de5519cbd16e6da1 477860 
grilo_0.1.20.orig.tar.xz
 31fd10de9421a845d397ffedab7b63663f70b9c5ae7336f4fb51af5a8e9b2f95 3571 
grilo_0.1.20-1.debian.tar.gz
 fc8cf6945da66b229a8a38c1c25add5083071937f619a3d1df89e26e31f9b5a7 171842 
libgrilo-0.1-0_0.1.20-1_i386.deb
 26d3f8bd43b6a53eb5c90beb8a62ef3572963935d5eac1b83424fd97d6e75f00 222062 
libgrilo-0.1-dev_0.1.20-1_i386.deb
 be6aa31f9e70266bcc1b4b407e57a5f5774bddca6fb79253f057397055720417 0 
libgrilo-0.1-bin_0.1.20-1_i386.deb
 a6e96139b3777201a35fc4736e06628d10be6d19ca9f2ccc72173f8c900ef4b2 222020 
libgrilo-0.1-doc_0.1.20-1_all.deb
 c8ab3d5e92c9c7e33604dcdfc37defd080ed02ec6057e350ae018c9bc71913f8 107654 
gir1.2-grilo-0.1_0.1.20-1_i386.deb
Files: 
 56656ab733efb44f6e09a3799e016caf 2093 libs optional grilo_0.1.20-1.dsc
 92ccc6b6b35d93bcd4d29d620c0e279b 477860 libs optional grilo_0.1.20.orig.tar.xz
 3f55d925f9e1cec8d99ddda375f77c63 3571 libs optional 
grilo_0.1.20-1.debian.tar.gz
 8e2df4e8614a2e381547e3330cca9167 171842 libs optional 
libgrilo-0.1-0_0.1.20-1_i386.deb
 b2957c479584e5845aa09125a934d3e3 222062 libdevel optional 
libgrilo-0.1-dev_0.1.20-1_i386.deb
 e055ab2af366d7471365b76531bb63d6 0 libs optional 
libgrilo-0.1-bin_0.1.20-1_i386.deb
 c8b3ca120e29b888d703c2156abc6d39 222020 doc optional 
libgrilo-0.1-doc_0.1.20-1_all.deb
 06b86eaa0f205c8ce3cc09ec23d0af15 107654 introspection optional 
gir1.2-grilo-0.1_0.1.20-1_i386.deb

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

iQIVAwUBUC37iL4yGa8+1BNBAQgsjA/+LUyjsIN6A3bUPZ7kEQLrES1db+eOFCqi
a3b8CpULv1WTrGTyw/GyJT6GeSc+f+CBLymxwyEElS4eLQ3bGcre8CsyZgt+ZTQB
EdoXWiaEqLrqIX+nK41GQk0KTSU7mAo+DwQAIWkJFIRX81vDriDhWM3xfg4dEIUv
ps1DbwEGR2KVQ0Ucf6I85EIpT90bMtbHRczZDg6yKdf3nBTqys22wUIvrlbfuL14
xZT+Qi4vhKBcUJEVypgJUo8vql/Eu/G54EA+uhNdVb3xyNJlCyr+CMu8wjAGROsB
k6oXDjbr3Va/WDl1Yx80CdTcL8/YY2t89q7JuEHq3iy6tHcrj6DGL47OFrwoEGIP
PyQuTHA73ghIaMB8PhzkE2N0Ku69RCEeZnSW7bJNlUvq0TR0ZALLUGR/Bp+fzi4D
xiRC3hpEJXfRWWodg8zof8hfk43ok1dJiFAi2r1f+ralGcKm1FWtvU0tarzDhFWh
0pNKMMOUBCxq6GsUsA8q5u8uwt5drw8ynbTMtvRGs8QtUnpX9/kQg0n2LkASNHlE
yboRxClOx2H4o0wRxpHNlHTk2RNTUsfURqCMPD1VPFBCIAt1KND7eTnQXETxQi51
YPA+jI75HwZy9yYc4NQ7M6yZAxgLh6UPrbApmn3kykIJhN+SA8+sqzSJdUAcx1aF
VEoUfrA2e6o=
=iFNd
-END PGP SIGNATURE-


-- 
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/e1t2idu-00053u...@franck.debian.org

Accepted grilo-plugins 0.1.20-1 (source i386)

2012-08-17 Thread Alberto Garcia

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Aug 2012 10:25:35 +0300
Source: grilo-plugins
Binary: grilo-plugins-0.1
Architecture: source i386
Version: 0.1.20-1
Distribution: experimental
Urgency: low
Maintainer: Alberto Garcia agar...@igalia.com
Changed-By: Alberto Garcia agar...@igalia.com
Description: 
 grilo-plugins-0.1 - Framework for discovering and browsing media - Plugins
Changes: 
 grilo-plugins (0.1.20-1) experimental; urgency=low
 .
   * New upstream release.
   * debian/control: build depend on libgrilo 0.1.20.
   * debian/grilo-plugins-0.1.lintian-overrides: remove
 hardening-no-fortify-functions override, lintian no longer produces
 this false positive.
Checksums-Sha1: 
 684540bbafd90c135b5b7f208a4725ffdb7e3a72 2088 grilo-plugins_0.1.20-1.dsc
 de0d03b1c013263cd0a7b8e982d0e9cf06a60708 384188 
grilo-plugins_0.1.20.orig.tar.xz
 1d6888d0836296d5ed867351c8125c022f4abcb0 3185 
grilo-plugins_0.1.20-1.debian.tar.gz
 8109a1c661026710058679fb30e7abc2c5d84c91 233104 
grilo-plugins-0.1_0.1.20-1_i386.deb
Checksums-Sha256: 
 b7b2f7d9ca6c86337ad89381d06edc1d558bc48e8fe6afbf71335de3f2cdbc5a 2088 
grilo-plugins_0.1.20-1.dsc
 4b0bf0f502f7a21827e1de4b60e70376d49524c3859a69ebff28d829ab8ae5b5 384188 
grilo-plugins_0.1.20.orig.tar.xz
 8bea535fc38c9240c39858a35a4e247f1bf519a0f653587496470845a58ad86f 3185 
grilo-plugins_0.1.20-1.debian.tar.gz
 c02e1cf1c27a86ea498a91015e22a36bbae821f2c4f9390a745fbbcfb75ef0ad 233104 
grilo-plugins-0.1_0.1.20-1_i386.deb
Files: 
 2bd6ae99f32729a567ff512853f8f797 2088 libs optional grilo-plugins_0.1.20-1.dsc
 f0b7d78e2d306752fd00c898f2e87f0b 384188 libs optional 
grilo-plugins_0.1.20.orig.tar.xz
 8e9987540e061a814282c466f754bb2d 3185 libs optional 
grilo-plugins_0.1.20-1.debian.tar.gz
 f2bca21644786535d8bb23bfe2d536b1 233104 libs optional 
grilo-plugins-0.1_0.1.20-1_i386.deb

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

iQIVAwUBUC370r4yGa8+1BNBAQiMaQ/9G1i6Dkx/JA9ox2f5apIZca3Y20WsXagy
UwWPa0YWVZW1Y4IsZ3ggjMLgB+C1YkKT5s7bHYrlR2MkXnOVdW3kuVHxzChTI3y1
HA2A3nt9USOjD/Q1cXiHPaLhpnVSp5VecFrrB8Hn1DoGsv6rdRA5uH/9R7Ras6Gk
XYNc97HMvNaLzI/qel84HRBrA8pWtIx/Grk5xztzPZUYEkLysx0lRF59A+gcgZfr
+ic7gizg86PO5hSQPpFIw/l7vfOwA9VM985cX9fVzHqSD4vNXI6UrPdOnhDHI44b
CI2ntO3ksbsIHtP8yovx6sDvuvqX3JIwf4IGZYAQsCqw+Bo3gcUwhL2oUuG9Zis/
NN4c0YZHMd1bMWdyU945Rhb/NgngNxMXSoXrD2VXLL/RUM0F2/BPVZuCE7XsF/6W
mOVXDOlC95aEx+VAoLBtFdh68cufAFO9o+S4tYn7muD1dqFL7JIqbLM2DRvkisRA
Mvrc7cyvLGObzdYVQZ5w7I+94G2otzOn/UdrIzIseB26sxktYlF/ikJ6JXKsVbDO
7BdETBvsQs5ADZGDqI6wt7piBJNxu5OpswkIevnBqJ4dNrCsBgHe/HmiwR4KWElh
kJSXp7qFmW9kCh6dXakNENywaqb0iP477R0nrVFCVWBpgiTMzE04Z9AyWxPyYIgs
7425lhJTGbM=
=l5PA
-END PGP SIGNATURE-


-- 
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/e1t2idy-00054j...@franck.debian.org

Accepted abe 1.1+dfsg-1 (source all amd64)

2012-08-17 Thread Bart Martens

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Aug 2012 17:28:04 +
Source: abe
Binary: abe abe-data
Architecture: source all amd64
Version: 1.1+dfsg-1
Distribution: unstable
Urgency: low
Maintainer: Bart Martens ba...@debian.org
Changed-By: Bart Martens ba...@debian.org
Description: 
 abe- Side-scrolling game named Abe's Amazing Adventure
 abe-data   - Side-scrolling game named Abe's Amazing Adventure
Closes: 685150
Changes: 
 abe (1.1+dfsg-1) unstable; urgency=low
 .
   * Repackaged upstream tarball to remove libraries for Win32 in binary form
 without source code.  Closes: #685150.
Checksums-Sha1: 
 0c82da8585f27358ede5919c7f729fd9223b 1806 abe_1.1+dfsg-1.dsc
 d1b985d171e3e2bba0d102ba54e4744739fe56c6 3087231 abe_1.1+dfsg.orig.tar.gz
 340b40b62cc0a3355a71309617546f55a3d56b40 5902 abe_1.1+dfsg-1.diff.gz
 8a23793ce56876566f9e8b2587be6f0f46b84ee4 2862420 abe-data_1.1+dfsg-1_all.deb
 6b910e1271c6cf33b62972aa7e8c6c223fce3a1a 41316 abe_1.1+dfsg-1_amd64.deb
Checksums-Sha256: 
 f08a02b070d55c7383e5ecc81359fc83ab3e584889001596b36568a1a92ee83a 1806 
abe_1.1+dfsg-1.dsc
 7da9e237bd16448b6d9f79193a3898aaef52dd9d2653e30a67b817f6b4d47d48 3087231 
abe_1.1+dfsg.orig.tar.gz
 6f2cf4d1ec6439043134ef5e155e63dbe5b07cf4472f6ac88de3841bbf7dcc34 5902 
abe_1.1+dfsg-1.diff.gz
 81c43c3861533b65113345be619e0f5217682015d740fad0f514ed895e0371f0 2862420 
abe-data_1.1+dfsg-1_all.deb
 68f369cda3f72bf34133a571b994e789fbd64e49e5461e668930f04712650a34 41316 
abe_1.1+dfsg-1_amd64.deb
Files: 
 3cca00e38351d08ed95a892381c522d7 1806 games optional abe_1.1+dfsg-1.dsc
 0dbea531d34b078af0529f297df3eb6f 3087231 games optional 
abe_1.1+dfsg.orig.tar.gz
 09095c9491f0a7272c467348ad6afeda 5902 games optional abe_1.1+dfsg-1.diff.gz
 cd34e22acb4120c1103973a96fb4caad 2862420 games optional 
abe-data_1.1+dfsg-1_all.deb
 0ce5b64e54c65dd50cf306ed338ee20e 41316 games optional abe_1.1+dfsg-1_amd64.deb

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

iQIcBAEBCAAGBQJQLoWFAAoJEDNV9NY7WCHMm+MP+gMYuMAyYSf3QO4yjRYhHXN8
AMaPbiocCP0mQFztk1y2WL26KQwQs1E8rXo3yO2lGhUBmsPp2rKgGNP4vMC04hrb
QCvLY++TC5pzSHhsuJ3ovZgYEcKE43Y1+3nP/7ukjhTTeAwE0fLF16j0mIO23rGm
qwuW9ciIqK9DDc49dtfQnqkIV3qFxT/Twnsppy32XuxmzSc6BmgeoCmQ9Nd+iwGG
qUi9FprrrnSxRBv4ubzO23W7BLSaOUnhQU/dzq8ueyRIgtOgmNStlx72zf8tVQYa
InFa4TBUlBbOL23Ud6t0bnf29c2Q0TvlHjq9++EhS5rrVLp61IFMSGfLvZWFwEdt
CohlAWA5023mE3LM+/+NGaXQWRfT90UrMbyXpwAFSzXHLdPPn0Q3ckNjkNS7QlZx
JkNdlvrVsuEgOaPbYixD84zMroevCKSi5cJz5IIfTQWV2lIPzg8CEewXdm2nZzFF
9hw2lmdNPKvZrrS2WKMoAv/ntfzMRZ1YB4i7+BMhFOl5Y0PQ7uisyNKoQF2bZuvd
TpTqa/cQ/CWqWA+Oo4u2qob2+n4HATA8RfXsdKd8DLGrSBJGxuo1IzDu9bLWTkBl
7b4o77+qGvhDYc3RcjHz/OFjnZfgq0tKJ2bE2k6A4/TQs/v7ncBK4WQaQyBlrMns
IUTOCIfuAS0rl1gHVuEA
=He8e
-END PGP SIGNATURE-


-- 
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/e1t2v6b-95...@franck.debian.org

Accepted abiword 2.9.2+svn20120603-3 (source all amd64)

2012-08-17 Thread Dmitry Smirnov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 17 Aug 2012 20:16:51 +1000
Source: abiword
Binary: abiword-common abiword abiword-plugin-grammar abiword-plugin-mathview 
libabiword-2.9 libabiword-2.9-dev abiword-dbg
Architecture: source all amd64
Version: 2.9.2+svn20120603-3
Distribution: unstable
Urgency: low
Maintainer: Dmitry Smirnov only...@member.fsf.org
Changed-By: Dmitry Smirnov only...@member.fsf.org
Description: 
 abiword- efficient, featureful word processor with collaboration
 abiword-common - efficient, featureful word processor with collaboration -- 
common
 abiword-dbg - debugging symbols for abiword word processor
 abiword-plugin-grammar - grammar checking plugin for AbiWord
 abiword-plugin-mathview - equation editor plugin for AbiWord
 libabiword-2.9 - efficient, featureful word processor with collaboration -- 
shared
 libabiword-2.9-dev - efficient, featureful word processor with collaboration 
-- develo
Changes: 
 abiword (2.9.2+svn20120603-3) unstable; urgency=low
 .
   * Replace no-dbl-buf.patch with backported fix-dbl-buff.patch
 to fix 'Paste Unformatted' and re-enable double buffering.
Checksums-Sha1: 
 f81f5bec7fb486af8db157c9882dd9542f972d63 2804 abiword_2.9.2+svn20120603-3.dsc
 e6d1c1159f4abd48519c9baed94fe0d7eceb57fd 6687572 
abiword_2.9.2+svn20120603.orig.tar.xz
 e72110eef1cd710d8aa4f3601eac16ce7ce8cc01 41924 
abiword_2.9.2+svn20120603-3.debian.tar.xz
 9dfcbf7a619f1385617ea1b22f32a11646293ba4 3236346 
abiword-common_2.9.2+svn20120603-3_all.deb
 6136cc35b41749735c62017a4a22dc8a8d326ce1 2397132 
abiword_2.9.2+svn20120603-3_amd64.deb
 3303b370ed28e6cb2ce49f8c1a532fb33a2abe81 737724 
abiword-plugin-grammar_2.9.2+svn20120603-3_amd64.deb
 9cea7a63c596704b5083b33e56f1881d9a344be6 846130 
abiword-plugin-mathview_2.9.2+svn20120603-3_amd64.deb
 d7e342946fe03a720c12aca698204d6a2ef453e2 3462006 
libabiword-2.9_2.9.2+svn20120603-3_amd64.deb
 858edd3676330380e6950c201ee9cd6efc0d22fb 731822 
libabiword-2.9-dev_2.9.2+svn20120603-3_amd64.deb
 d563b4673f8439d44d76aab0d6d2c49afce75af4 36392730 
abiword-dbg_2.9.2+svn20120603-3_amd64.deb
Checksums-Sha256: 
 345ce871d6b0e5159702758eeff8d9dd24eb24deebb89f3277449523f5f7ce37 2804 
abiword_2.9.2+svn20120603-3.dsc
 6477d4b948725672ca81c3da27e0dfa6024d4e6f37c7dd341776a910d18fcd55 6687572 
abiword_2.9.2+svn20120603.orig.tar.xz
 2a7cd97bb6c7b8dcc3165ca32b06792ee1cc29c24fc3d506238cc399400b5480 41924 
abiword_2.9.2+svn20120603-3.debian.tar.xz
 3ae9ad78041f3371a673b9e35d4289a76f7e370e0f49c0e362329f8dabdbed46 3236346 
abiword-common_2.9.2+svn20120603-3_all.deb
 4cf1591bc6d8f6ad63cf5b2a685d03f7376f5b4a781beb2b582ebd529e48a76f 2397132 
abiword_2.9.2+svn20120603-3_amd64.deb
 2b531b6701c5736e9ea1263410e8f51f99ab938c0541bfacee13812c055bac91 737724 
abiword-plugin-grammar_2.9.2+svn20120603-3_amd64.deb
 52232ae5c335e8e883f3dd8baf92c05540d8ce65439b08314a4d2787da904b7f 846130 
abiword-plugin-mathview_2.9.2+svn20120603-3_amd64.deb
 f1a6445477c973f32039dec0878bb31907576ff53df3947b821fa12c6586354e 3462006 
libabiword-2.9_2.9.2+svn20120603-3_amd64.deb
 ddade4772b302ba784e72973b1838d09b2e0ea5c06609e72b35c769503548e77 731822 
libabiword-2.9-dev_2.9.2+svn20120603-3_amd64.deb
 c035a1025a2c7747abf211339ad68d99206d9ec46b3503acaa49776dc704b207 36392730 
abiword-dbg_2.9.2+svn20120603-3_amd64.deb
Files: 
 27cc1813a79abc1fffd9a7fe8fdc1261 2804 gnome optional 
abiword_2.9.2+svn20120603-3.dsc
 9ec052c1f385c11aac04ab1ba38c98d3 6687572 gnome optional 
abiword_2.9.2+svn20120603.orig.tar.xz
 077d1f38f11410be58ee6232dc4c86b9 41924 gnome optional 
abiword_2.9.2+svn20120603-3.debian.tar.xz
 7fb4eadb828b880f141bce70caf9b359 3236346 editors optional 
abiword-common_2.9.2+svn20120603-3_all.deb
 478cd0d9784e14c6d0ff895dbe0b00c2 2397132 editors optional 
abiword_2.9.2+svn20120603-3_amd64.deb
 352a69f848a56564f55a52416c58ae94 737724 editors optional 
abiword-plugin-grammar_2.9.2+svn20120603-3_amd64.deb
 71ea2be90a229e22f0a9af02c296e7cb 846130 editors optional 
abiword-plugin-mathview_2.9.2+svn20120603-3_amd64.deb
 a4feda6d301cd2be473306aaf1f6dce9 3462006 libs optional 
libabiword-2.9_2.9.2+svn20120603-3_amd64.deb
 0ceaa48922a7a683be12e914c471546f 731822 libdevel optional 
libabiword-2.9-dev_2.9.2+svn20120603-3_amd64.deb
 772ceb9fafc71e28035e850adb4f43f2 36392730 debug extra 
abiword-dbg_2.9.2+svn20120603-3_amd64.deb

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

iQIcBAEBAgAGBQJQLiBCAAoJEFK2u9lTlo0bJ5sP/01sM8goAelDnNWAfI/qIgmf
SN4qYMs9oFrlvVikvePwp6LFVA0smgeM1usiDRa3s14XjKmwLX9rBEZYtrreRrFE
zY2JubQ1XS+jfJ4l7Ar0RQcWHFzt7h4g7C6mBQBdcTdBCsW5Nke8jc0S6liWcRvK
qoH11oijDXXSmyNVgniQRisgXEo66jue9wbuOt0jrPRso6vom47ad/EwmmYt3T+H
/wkgy6u5LZnGqob8u6q5tVjRNEYb03gEvOTu5wNCFogoO7dTkwPc+31lf7/H14BO
ofUYcUuAb+b68SDNORMxOJDhmyvcnHpzKjO0zj/dU4rSodcK8g35ysCnt6PwgVBI
Uetfs2w4UAeKk01l2E/BRN1455eq9ngt76GTmdXbdHesU58J31zlT3lamtMqJg59
8HgNye5szdWBFj7F/KMhpCAy6kYoAg6nxgjP0jFA7p1s4/3aVMJmmPuq3zWBO1tm
R7O3o9VncRzQEHr9UJ9msEGWcuqSHRltFcili7BEEWOKAgbkhrCPIzzG0/yOGPAd

Accepted ball 1.4.1+20111206-4 (source all amd64)

2012-08-17 Thread Andreas Hildebrandt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 15 Aug 2012 00:50:32 +0200
Source: ball
Binary: libball1.4-data libball1.4 libball1.4-dev libballview1.4 
libballview1.4-dev python-ball python-ballview ballview libball1.4-doc 
ballview-dbg
Architecture: source all amd64
Version: 1.4.1+20111206-4
Distribution: unstable
Urgency: low
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Andreas Hildebrandt andreas.hildebra...@uni-mainz.de
Description: 
 ballview   - free molecular modeling and molecular graphics tool
 ballview-dbg - debug symbols for BALL and VIEW libraries
 libball1.4 - Biochemical Algorithms Library
 libball1.4-data - Biochemical Algorithms Library
 libball1.4-dev - Header files for the Biochemical Algorithms Library
 libball1.4-doc - documentation for the BALL library
 libballview1.4 - Biochemical Algorithms Library, VIEW framework
 libballview1.4-dev - Header files for the VIEW part of the Biochemical 
Algorithms Libr
 python-ball - Python bindings for the Biochemical Algorithms Library
 python-ballview - Python bindings for VIEW-parts of the Biochemical Algorithms 
Libr
Closes: 674226
Changes: 
 ball (1.4.1+20111206-4) unstable; urgency=low
 .
   * Fix compilation with g++ = 4.7 (Closes: 674226)
   * Updated policy to 3.9.3 (no changes required)
Checksums-Sha1: 
 7a9200c4adecbb7bba9f19b702334cb6f5d70098 3144 ball_1.4.1+20111206-4.dsc
 680d234cecab04b79dcc427060465cdc591b 30882 
ball_1.4.1+20111206-4.debian.tar.gz
 446ec629cc3b04a4911ea56c63f9201ee30afb78 15062204 
libball1.4-data_1.4.1+20111206-4_all.deb
 33f2249275236d325b28951a893d73ebbbcae395 16569506 
libball1.4-doc_1.4.1+20111206-4_all.deb
 2f6f4f0cd18e289c800f175a8fbf120d24dd8399 5687946 
libball1.4_1.4.1+20111206-4_amd64.deb
 7675b36b138956d762aa9a5dee785809dc40f445 717888 
libball1.4-dev_1.4.1+20111206-4_amd64.deb
 6b1705c5d1ed3dca9eb4b5827f1f2f92460adb63 2589534 
libballview1.4_1.4.1+20111206-4_amd64.deb
 276bd85994f476101a325ba79541b6020cdd3146 172504 
libballview1.4-dev_1.4.1+20111206-4_amd64.deb
 97eec464892f6c72fafb7a5b2741637f93d0ae57 1193108 
python-ball_1.4.1+20111206-4_amd64.deb
 39720fef84bfcfc7fd61a459440226f2e7dee79c 497736 
python-ballview_1.4.1+20111206-4_amd64.deb
 41dc26f35ecdca485c86eb1b67e670890c4f9da2 2571554 
ballview_1.4.1+20111206-4_amd64.deb
 8ca79fabd3ffde405a52b67d6ce3a5a7361bfbf4 3066254 
ballview-dbg_1.4.1+20111206-4_amd64.deb
Checksums-Sha256: 
 80242670a9c489d4c64468fb8670fa344a71f66137f2bfb9c466017eee3a7a47 3144 
ball_1.4.1+20111206-4.dsc
 2aef7f024a4c593fa09b3d22d51df8e7a71d3c78062408a21cc20565938c19e4 30882 
ball_1.4.1+20111206-4.debian.tar.gz
 f1ef108229dc33c0ccb96656f1bb102030f3414bc02426d34ddedc37b50f 15062204 
libball1.4-data_1.4.1+20111206-4_all.deb
 ecb10596f68906f8a8106f18588955fc241086f958b77aca2145cfa16e36cf3b 16569506 
libball1.4-doc_1.4.1+20111206-4_all.deb
 418239eed673e1ec8a562b56d687943953d4c278f5bd1390b2533621881eb6f9 5687946 
libball1.4_1.4.1+20111206-4_amd64.deb
 bbd03a6503c6610eb44148b583387579613402de9113481365f8801a3849446b 717888 
libball1.4-dev_1.4.1+20111206-4_amd64.deb
 65f0d0beb3b51bbb2ae49aec25a211b9cbfacfac916abcfe9eff9a74c9dac794 2589534 
libballview1.4_1.4.1+20111206-4_amd64.deb
 52aa57d07cdc79d8098b6beb2e3a76586d590c10afd866f8978c1000ca6792be 172504 
libballview1.4-dev_1.4.1+20111206-4_amd64.deb
 2dc45e080856fcc22670132283c24133d9b04dcefaa2a2b360b86f849a4e585e 1193108 
python-ball_1.4.1+20111206-4_amd64.deb
 34d68fcb71391ee3424948ca5c45d80ae26b2c44d8f1db54630fc0bcc508d01c 497736 
python-ballview_1.4.1+20111206-4_amd64.deb
 67e3b550a5d0ca0865127dbed32300ff16df51741cf03d35f3ee88f4b23d09a2 2571554 
ballview_1.4.1+20111206-4_amd64.deb
 02b05c937e5df98c1c3d9603165f194b970e126bba1059d231c96498f98eb14b 3066254 
ballview-dbg_1.4.1+20111206-4_amd64.deb
Files: 
 455b191a0fb7748efb91f9c7bd7a7844 3144 science optional 
ball_1.4.1+20111206-4.dsc
 7042053b6b97742b8f5adf3c543d14b0 30882 science optional 
ball_1.4.1+20111206-4.debian.tar.gz
 13c16c138079ac6dd69cbe6170d421c2 15062204 science optional 
libball1.4-data_1.4.1+20111206-4_all.deb
 e5bd7f3857d4f03dba4d0c510dcde368 16569506 doc optional 
libball1.4-doc_1.4.1+20111206-4_all.deb
 96680effae29cd43524e02677c981c41 5687946 science optional 
libball1.4_1.4.1+20111206-4_amd64.deb
 9287ff33d9c66d894a7428a164c080b5 717888 libdevel optional 
libball1.4-dev_1.4.1+20111206-4_amd64.deb
 23ff60ce611e114714eb01683f25edc1 2589534 science optional 
libballview1.4_1.4.1+20111206-4_amd64.deb
 e502a344918a6ce19dd5cab4136f16d0 172504 libdevel optional 
libballview1.4-dev_1.4.1+20111206-4_amd64.deb
 5e6e92c3d60ab1580d9491f68339f679 1193108 python optional 
python-ball_1.4.1+20111206-4_amd64.deb
 ff6c33a64d62bab8de815f837842718f 497736 python optional 
python-ballview_1.4.1+20111206-4_amd64.deb
 b82f63fff00016843888b873e48f74ab 2571554 science optional 
ballview_1.4.1+20111206-4_amd64.deb
 5e3d5e2956f22fc9f3a0a9388cdc0c64 3066254 debug extra

Accepted compass-susy-plugin 1.0~dfsg-1 (source all)