Bug#595479: Please unblock: openmotif/2.3.3-4

[Stefan Bauer]

Am 04.09.2010 18:13, Adam D. Barratt schrieb:
> On Sat, 2010-09-04 at 12:08 +0200, Stefan Bauer wrote:
>> Please add another freeze exception. The package would have been in
>> testing already but the buldd's are too busy. I'm waiting since 19. of
>> august for the appropriate builds.
> 
> out of date on hppa: libmotif-dev, libmotif3, motif-clients (from 2.2.3-4)
> out of date on ia64: libmotif-dev, libmotif4, motif-clients (from 2.3.3-2)
> out of date on mips: libmotif-dev, libmotif3, motif-clients (from 2.2.3-4)
> out of date on mipsel: libmotif-dev, libmotif3, motif-clients (from 
> 2.2.3-4)
> 
> Those missing builds all need resolving before the package will migrate.
> 
> hppa does not have non-free auto-builders right now; ia64 is now built
> and mipsel has hit #519006 (I would be astonished if mips does not also
> do so).

Build Problems on mips are now fixed. Please add an unblock exeption
for this package to enter testing.

This package is really required to run the citrix client.

Thanks!

Stefan
-- 
Stefan Bauer -
PGP: E80A 50D5 2D46 341C A887 F05D 5C81 5858 DCEF 8C34
 plzk.de - Linux - because it works --




-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c87307c.6000...@cubewerk.de

Bug#596039: RM: emacs22-non-dfsg/22.3+1-1

[Tommi Vainikainen]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
Severity: normal

Hi,

the package emacs22-non-dfsg in non-free should be removed from squeeze,
because it is just GFDL material splitted from emacs22 package, which
has been removed also from squeeze (so it would be part of squeeze, see
#573486 if needed).

I'm not associated with the package in any way. I tried first to contact
the maintainer Rob Browning, but he did not react to my mail (spam
filter?).

PS. You might want to check if emacs21-non-dfsg needs removal hint, it
was removed from sid yesterday.

-- 
Tommi Vainikainen



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bp88d8ev@thv.iki.fi

Re: Please unblock coinutils / coinor-symphony / coinor-cbc

[Soeren Sonnenburg]

On Tue, 2010-09-07 at 23:24 +0200, Julien Cristau wrote:
> On Tue, Sep  7, 2010 at 23:00:47 +0200, Soeren Sonnenburg wrote:
> 
> > On Tue, 2010-09-07 at 21:09 +0100, Adam D. Barratt wrote:
> > > On Tue, 2010-09-07 at 21:22 +0200, Soeren Sonnenburg wrote:
> > > > I am not really sure what to do. I forgot to build depend on a newer
> > > > version of coinutils in the package coinor-cbc causing a FTBS in squeeze
> > > > (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595847 ).
> > > > 
> > > > However, coinutils and coinor-symphony both are waiting to enter squeeze
> > > > for 65 / 117 days now due to atlas not entering squeeze.
> > > > 
> > > > So what now? Shall I fix the build-depends in cbc and do a new upload or
> > > > could someone hint all of the coinor-* / coinutils packages to enter
> > > > squeeze (which would also fix the above FTBS) even though atlas is not
> > > > yet through?
> > > 
> > > Forcing the current coin* packages in to testing wouldn't resolve the RC
> > > bug; if coinor-cbc requires a minimum version of coinutils in order to
> > > build then that needs to be specified in the build-dependencies.
> > > 
> > > It would also need a very large britney hammer, as it would render the
> > > armel packages of coin* uninstallable; they depend on libatlas3gf-base
> > > which doesn't exist on armel in testing.
> > 
> > OK, I've uploaded coinor-cbc_2.5.0-2 fixing the build depends. Please
> > unblock such that it can enter testing after 2 days.
> > 
> Does that mean you expect to have fixed atlas to build on all
> architectures in 2 days?

No, it means that coinor-cbc needs to be unblocked to be able to enter
testing when atlas does. Your sentence is a bit cryptic to me - do you
want me to drop the dependency on atlas?

Soeren
-- 
For the one fact about the future of which we can be certain is that it
will be utterly fantastic. -- Arthur C. Clarke, 1962


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

NEW changes in proposedupdates

[Archive Administrator]

Processing changes file: linux-kernel-di-mipsel-2.6_1.8lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-alpha-2.6_0.37lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-s390-2.6_0.37lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-arm-2.6_1.37lenny9_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-amd64-2.6_1.53lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-mips-2.6_1.9lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-armel-2.6_1.32lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-powerpc-2.6_1.48lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-i386-2.6_1.76lenny8_i386.changes
  ACCEPT
Processing changes file: linux-kernel-di-ia64-2.6_1.42lenny8_multi.changes
  ACCEPT
Processing changes file: linux-kernel-di-sparc-2.6_1.41lenny8_multi.changes
  ACCEPT


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1otfaw-0008r3...@franck.debian.org

Re: Please unblock coinutils / coinor-symphony / coinor-cbc

[Julien Cristau]

On Wed, Sep  8, 2010 at 09:32:24 +0200, Soeren Sonnenburg wrote:

> No, it means that coinor-cbc needs to be unblocked to be able to enter
> testing when atlas does. Your sentence is a bit cryptic to me - do you
> want me to drop the dependency on atlas?
> 
No, I want atlas fixed.  atlas won't enter testing in two days, so
coinor-cbc won't either.  Once atlas is fixed, then sure...

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please allow python-poker-network-1.7.7-3 into Squeeze (was Please allow python-poker-network-1.7.7-2 into Squeeze )

[Loic Dachary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mehdi Dogguy wrote:
> On 09/07/2010 04:23 PM, Loic Dachary wrote:
>> Hi,
>>
>> I advocate for the acceptance of python-poker-network-1.7.7-2[1]
>> into
> 
>
> poker-network.
>
>> Squeeze because:
>>
>> * init script in 1.7.7-1.1 now in squeeze fails to run (it is
>> incompatible with the version of twisted[2] * postrm was fixed
>> because it failed to purge in some cases * 1.7.7-1.1 misses
>> critical patches that were in 1.7.6 and accidentaly removed
>>
>
> you forgot:
>
> * removes da.po and ru.po
>
>> I believe it is worth updating python-poker-network with this
>> maintainance release because it fixes a simple problem
>> (compatibility with twisted) that prevents the current version to
>> run. And it also fixes a few bugs and improves the stability of
>> the application.
>>
>> This maintainance release also contains updated translations.
> ^^^
>
> By "updated", you mean "removed"?
>
This was my mistake, I apologize for wasting your time with it.
> Please fix the translations issue and get back to us when ready.
>
I have just uploaded 1.7.7-3 which adds the translation files that
were accidentaly removed in 1.7.7-2
>> [1]
>> http://packages.qa.debian.org/p/poker-network/news/20100906T162714Z.html
>>  [2] twisted http://qa.debian.org/developer.php?packages=twisted
>>
>
> Putting bugreport numbers is much more useful than those two links.
>
>
This maintainance packages fixes the following bugs:

In Debian

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586756

In Ubuntu

https://bugs.launchpad.net/ubuntu/+source/poker-network/+bug/630870

Thanks for your help.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkyHTkAACgkQ8dLMyEl6F20KQwCeLTmkzzog+2QYxqD2Zb1/vsNU
2X0AmwRqwEb6KkzEJivFQntjFc2rrwqU
=tvo5
-END PGP SIGNATURE-

<>

Re: Please allow python-poker-network-1.7.7-3 into Squeeze (was Please allow python-poker-network-1.7.7-2 into Squeeze )

[Mehdi Dogguy]

On 09/08/2010 10:50 AM, Loic Dachary wrote:
> 
> I have just uploaded 1.7.7-3 which adds the translation files that
> were accidentaly removed in 1.7.7-2

Unblocked.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8758bb.2020...@dogguy.org

Bug#596039: marked as done (RM: emacs22-non-dfsg/22.3+1-1)

[Debian Bug Tracking System]

Your message dated Wed, 08 Sep 2010 11:44:02 +0200
with message-id <4c875ae2.3030...@dogguy.org>
and subject line Re: Bug#596039: RM: emacs22-non-dfsg/22.3+1-1
has caused the Debian Bug report #596039,
regarding RM: emacs22-non-dfsg/22.3+1-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
596039: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596039
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
Severity: normal

Hi,

the package emacs22-non-dfsg in non-free should be removed from squeeze,
because it is just GFDL material splitted from emacs22 package, which
has been removed also from squeeze (so it would be part of squeeze, see
#573486 if needed).

I'm not associated with the package in any way. I tried first to contact
the maintainer Rob Browning, but he did not react to my mail (spam
filter?).

PS. You might want to check if emacs21-non-dfsg needs removal hint, it
was removed from sid yesterday.

-- 
Tommi Vainikainen


--- End Message ---
--- Begin Message ---
On 09/08/2010 09:03 AM, Tommi Vainikainen wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: rm
> Severity: normal
> 
> Hi,
> 
> the package emacs22-non-dfsg in non-free should be removed from squeeze,
> because it is just GFDL material splitted from emacs22 package, which
> has been removed also from squeeze (so it would be part of squeeze, see
> #573486 if needed).
> 

Removal hint added.

> PS. You might want to check if emacs21-non-dfsg needs removal hint, it
> was removed from sid yesterday.
> 

It's already gone.

Cheers,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/

--- End Message ---

Bug#596016: marked as done (unblock: intel-microcode/0.20100826-1)

[Debian Bug Tracking System]

Your message dated Wed, 08 Sep 2010 11:55:31 +0200
with message-id <4c875d93.8040...@dogguy.org>
and subject line Re: Bug#596016: unblock: intel-microcode/0.20100826-1
has caused the Debian Bug report #596016,
regarding unblock: intel-microcode/0.20100826-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
596016: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596016
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package intel-microcode

This package contains a data file with microcode for Intel CPUs.  The
update script for users to get that updates for that file has been
broken for a while, and was not fixed yet.  Therefore, the only way an
user will get an update of the microcode datafile is by directly
downloading it from Intel, or through a intel-microcode package update.

Intel doesn't disclose much about what the microcode updates do, and
they often correct very hard-to-hit bugs with low impact.  However, that
is not always true, and some of these updates do fix critical processor
bugs.

Based on the release dates, this update is known to have microcode that
fixes critical bugs on several processors:

http://h2.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02078984&lang=en&cc=us&taskId=101&prodSeriesId=3718668&prodTypeId=12454

unblock intel-microcode/0.20100826-1

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32.21 (SMP w/8 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--- End Message ---
--- Begin Message ---
On 09/08/2010 01:22 AM, Henrique de Moraes Holschuh wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: freeze-exception
> 
> Please unblock package intel-microcode
> 

Unblocked.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/

--- End Message ---

Re: Security bugfix #595248: please unblock libnusoap-php

[Mehdi Dogguy]

On 09/08/2010 06:02 AM, Thomas Goirand wrote:
> Hi,
> 
> […]
> 

Please, get your propaganda out of here. I understand why he was
pissed off.

> 
> As this upload includes a security fix, I would be great if it was 
> given a higher priority by the release team (btw, I've set 
> urgency=high).
> 

You want higher than "high"? Having it in unstable for 2 days won't harm.

Unblocked :(

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c876112.6010...@dogguy.org

Re: Security bugfix #595248: please unblock libnusoap-php

[Philipp Kern]

On Wed, Sep 08, 2010 at 12:02:02PM +0800, Thomas Goirand wrote:
> I took over maintainership of libnusoap-php after the current maintainer
> loosely sent an RFA in the middle of the freeze only few months after he
> had his packages in the archive, because he was pissed by the discussion
> in #595346 (so I had no choice but to adopt, but if anyone wants to
> maintain, I'd happily give-up maintainership as I maintain quite a lot
> of packages already). That leads me to say that I would suggest any DD
> to *not* sponsor any package from Olivier Berger in the future, as he
> really had a bad attitude on this case.

I would suggest any person to be very cautious when dealing with bug reports
from you, then.

Kind regards,
Philipp Kern


signature.asc
Description: Digital signature

Re: [Pkg-clamav-devel] Please unblock clamav-data

[Michael Tautschnig]

Hi all,

Sorry for a very late reply on this one.

> Marc,
> 
> On 08/16/2010 10:56 AM, Marc Haber wrote:
> >Please unblock clamav-data as this will bring more virus signatures
> >into lenny. The package is built and tested automatically inside the
> >debian-volatile infrastructure.
> 
> well, it's neither built nor tested inside the debian-volatile
> infrastructure, but outside of it.  Apart from that, please see [0].
> 
> The volatile infrastructure for squeeze will be hosted on
> ftp-master.  Unless ftp-master agrees (Cc'ed) to have automatic
> building and testing somewhere trusted and installed into the main
> archive without a developer's signature, I don't see how we can
> continue this service.  Technically it might work for data packages
> like this to ensure they only contain data, on the other hand,
> setting up a local mirror for clamav isn't hard.  (Basically setting
> up freshclam and pointing a vhost to it, then pointing the clamav
> hosts to it.)  It might be better documented in the packaging of
> clamav, though (maintainers Cc'ed).
> 

[...]

I have no idea whether you have already come to a conclusion regarding
clamav-data. Noting a fairly high number of users as counted via popcon I think
that removing clamav-data should at least be worth a note in the release notes.

Speaking as clamav maintainer, that might also be a proper place for the
suggested documentation of setting up a local mirror. The only other option
seems to be the freshclam man page, but if we specifically want to target prior
users of the clamav-data package, that might not be the best place. And yes, it
really is a simple as pointing some $webserver to /var/lib/clamav on a host
running freshclam. Two sentences in whatever documentation should suffice.

Best regards,
Michael



pgp560ONr8j30.pgp
Description: PGP signature

Re: ClamAV supportability in stable release (was: Unidentified subject!)

[Michael Tautschnig]

Sorry, debian-rele...@bugs.d.o really doesn't exist...

> Hi all,
> 
> (Dared to fix CC/Subject which seemed to be somewhat broken in initial email.)
> 
> > The release team have been asked to remove ClamAV from testing (and
> > hence the next stable release. See bug #587058.
> > 
> > The issue seems to be that it's not supportable in stable due to the
> > upstream maintainers deciding to upgrade their data files in a way that
> > isn't binary compatable with previous versions.
> > 
> > A couple of options have been mentioned for what to do with this,
> > including volatile. I'm opening this mail thread for discussion, and if
> > no one comments then I'll go ahead and action the bug report in two
> > weeks. For avoidance of doubt, this will also affect reverse
> > depends, see dd-list below.
> > 
> 
> [...]
> 
> Has there been feedback other than Christian's idea of adding a
> kind-of-transitional package? Speaking as clamav maintainer, we'll happily
> continue to upload to unstable, and if migration to testing (and stable) is
> permitted - so be it, but the volatile-path seems to be a lot more promising 
> and
> future-proof. That said, the clamav ABI/API is surely stabilizing and hence
> users of clamav packages from stable might be better off than before. But
> there's no guarantee that they really get all the latest&greatest detection
> capabilities. 
> 
> One clear volatile-only advantage is added cleanliness: No need to mess around
> with different versions that actually are the same packages, and it just 
> feels a
> lot better if we can have a package in volatile only, and not in unstable as
> well.
> 
> Best,
> Michael
> 




pgpHXZbqX6R1E.pgp
Description: PGP signature

Bug#587058: ClamAV supportability in stable release (was: Unidentified subject!)

[Michael Tautschnig]

Hi all,

(Dared to fix CC/Subject which seemed to be somewhat broken in initial email.)

> The release team have been asked to remove ClamAV from testing (and
> hence the next stable release. See bug #587058.
> 
> The issue seems to be that it's not supportable in stable due to the
> upstream maintainers deciding to upgrade their data files in a way that
> isn't binary compatable with previous versions.
> 
> A couple of options have been mentioned for what to do with this,
> including volatile. I'm opening this mail thread for discussion, and if
> no one comments then I'll go ahead and action the bug report in two
> weeks. For avoidance of doubt, this will also affect reverse
> depends, see dd-list below.
> 

[...]

Has there been feedback other than Christian's idea of adding a
kind-of-transitional package? Speaking as clamav maintainer, we'll happily
continue to upload to unstable, and if migration to testing (and stable) is
permitted - so be it, but the volatile-path seems to be a lot more promising and
future-proof. That said, the clamav ABI/API is surely stabilizing and hence
users of clamav packages from stable might be better off than before. But
there's no guarantee that they really get all the latest&greatest detection
capabilities. 

One clear volatile-only advantage is added cleanliness: No need to mess around
with different versions that actually are the same packages, and it just feels a
lot better if we can have a package in volatile only, and not in unstable as
well.

Best,
Michael



pgpFWqaTMMXsm.pgp
Description: PGP signature

Re: Security bugfix #595248: please unblock libnusoap-php

[Sebastian Harl]

Hi Thomas,

On Wed, Sep 08, 2010 at 12:02:02PM +0800, Thomas Goirand wrote:
[…]
> That leads me to say that I would suggest any DD
> to *not* sponsor any package from Olivier Berger in the future, as he
> really had a bad attitude on this case.

I would like to kindly ask you to take it down a notch and take a deep
breath. Imho, your behavior has not been very friendly -- at the very
least -- and not only in this case. This might be due to English not
being your first language (it isn't in my case either) but some of what
you said sounds rather dismissive and, thus, very unmotivating. Please
respect that other people have their own opinions as well and try to
calmly discuss such issues. Please take this the way it's meant -- as a
friendly hint to let people get along well with each other. Thanks!

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

djvulibre exception request

[Barak A. Pearlmutter]

I've uploaded djvulibre 3.5.23-1 and am hoping to have it allowed to
migrate into testing.  Reason: the substantive changes from the
current version in testing are almost entirely bug fixes, including
two rather nasty ones.

One of these bugs (562156) causes incorrect PDF to be generated in
some locales.  Another (582961) is a thread-related race condition
which causes mysterious silent crashes of the tools.  A third (539272)
causes silent (exit condition 0) failure for tiny images.  The first
two of these could easily be considered RC, as they are the sort of
thing that cause automated image processing toolchains and scripts to
silently give incorrect output.  I am happy to raise their severity in
the BTS if the release team so desires.

Having looked through the changes in some detail, I do not think it is
worth trying to tease out just those changes related to the above
bugs: the other changes are either minor, or only active at build
time, or are to documentation.  And trying to tease things apart could
result in breaking code, because the individual patches sometimes
contain straggler typo fixes and such.  I think the odds of
accidentally introducing a problem that way exceed the odds of their
being a problem lurking in the very tiny number of substantive
non-critical changes.

A broken-down diffstat with comments appears below.

--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/



diffstat of djvulibre from 3.5.22-9 to 3.5.23-2, broken down by
category, with summary of changes in each category.

Replicate, or examine diff in detail, with, eg:

 git clone git://git.debian.org/git/collab-maint/djvulibre.git
 cd djvulibre
 git diff --stat debian/3.5.22-9..debian/3.5.23-2 -- NEWS *.spec tools/*.1
 git diff debian/3.5.22-9..debian/3.5.23-2 -- */*.h */*.c */*.cpp


DETAILS



Autotools refresh

 (vast bulk of the diff; does not require examination.)

 aclocal.m4   |7 +-
 config/acinclude.m4  |   16 +-
 config/config.guess  |  149 +-
 config/config.h.in   |   12 +-
 config/config.sub|   47 +-
 config/install-sh|  560 +-
 config/libtool.m4| 8728 --
 config/ltmain.sh | 8452 --
 config/ltoptions.m4  |  368 +
 config/ltsugar.m4|  123 +
 config/ltversion.m4  |   23 +
 config/lt~obsolete.m4|   92 +
 configure|30932 +-
 configure.ac |   97 +-

 Subtotal: 14 files changed, 22311 insertions(+), 27295 deletions(-)



Documentation

 (does not require serious examination; the change to djvulibre.spec
 is just the version number; most other documentation updates
 correspond to code already present in 3.5.22-9.)

 NEWS |   12 +-
 djvulibre.spec   |2 +-
 tools/cjb2.1 |2 +-
 tools/ddjvu.1|6 +

 Subtotal: 4 files changed, 17 insertions(+), 5 deletions(-)



Upstream build changes

 (previously used "convert" aka imagemagick to generate bitmaps from
 svg files; changed to try "rsvg" first, with fail-back to "convert".
 This change was made in response to changes in the way imagemagick
 was modularized, which increased its brittleness for this purpose.)

 desktopfiles/Makefile.in |7 +-

 Subtotal:  1 files changed, 5 insertions(+), 2 deletions(-)



Upstream code changes

 (mainly bug fixes: thread race condition bug, tiny image bug,
 locale-related PDF output bug, an ARM thumb port issue which is
 #ifdef'ed out on other architectures, and some MS Windows fixes that
 are #ifdef'ed in only on MS Windows.)

 libdjvu/ddjvuapi.h   |1 +
 libdjvu/GThreads.cpp |   10 +-
 tools/bzz.cpp|1 +
 tools/c44.cpp|1 +
 tools/cjb2.cpp   |1 +
 tools/cpaldjvu.cpp   |1 +
 tools/csepdjvu.cpp   |1 +
 tools/ddjvu.cpp  |   50 +-
 tools/djvm.cpp   |1 +
 tools/djvmcvt.cpp|1 +
 tools/djvudump.cpp   |1 +
 tools/djvuextract.cpp|1 +
 tools/djvumake.cpp   |1 +
 tools/djvused.cpp|   10 +-
 tools/djvuserve.cpp  |2 +-
 tools/tiff2pdf.c |   11 +-

 Subtotal: 16 files changed, 64 insertions(+), 30 deletions(-)



Network script bug fix

 (Fix small but annoying bash script bug.)

 tools/any2djvu   |2 +-

 Subtotal: 1 files changed, 1 insertions(+), 1 deletions(-)



debian/

 (Addition of --enable-djview during configuration to counteract
 change in upstream default, build dependency on rsvg to take
 advantage of upstream icon generation improvement, minor debian
 packaging updates 

chromium not in Squeeze: a bit of communication needed?

[Stefano Zacchiroli]

I've been following the chromium-browser saga a bit, who has ended up
with the removal of the package from testing [1,2]. While I'm a
chromium-browser user myself, and hence I'm saddened of seeing it go,
I'm not here to question the choice as I'm sure it's been made as the
right one and that it hasn't been an easy one to make.

  [1] http://lists.debian.org/debian-release/2010/09/msg00582.html
  [2] 
http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/

Still I think we need, as Debian, to communicate about that choice. As
you can imagine, I particularly care about that as sooner or later
someone will ask me « why Debian doesn't ship Chromium? », and I'd like
to know the right answer to that question, so that I can provide it,
rather than offering my personal view only :-)
That's all I care about. [3]

>From the exchange on -release, I *guess* that the reason is that
Chromium 5 is not meant to be supportable security-wise and at the same
time that it's too late to get Chromium 6 into Squeeze. If this is the
case, I welcome explicit comments in that direction by the security and
release teams. If there are other reasons, please let me know.

Such an answer will be even more useful as, say, a kind of "public
statement" toward upstream, explaining why their practices are not
something that suite the quality requirements we have in Debian.

Many thanks in advance to all involved teams, and in particular to
Giuseppe who put a shitload of work in the packaging.
Please help me out in answering tricky questions like this one!
Cheers.


[3] A question you might have at this point is: "why you bother about
Chromium and not other packages?". Well, I do bother about all
packages and I'm just trying to anticipate questions I'll might be
asked as soon as Squeeze get released. For instance and for the same
reason, I've proposed just yesterday to mention the removal of Plone
from Squeeze, and the maintainer has kindly agreed to explain the
reasons in the Squeeze release notes. So, I'm not special casing
anything here, and I encourage you to point me to other similar
cases.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908114849.ga7...@upsilon.cc

Re: Python 3 support in Squeeze

[Neil McGovern]

On Mon, Sep 06, 2010 at 10:54:45PM +0200, Piotr Ożarowski wrote:
> [Adam D. Barratt, 2010-09-06]
> > So upstream have verified the result of 2to3 on their software?
> 
> yes
> 
> > On a related note, will the build system allow for the result of 2to3 to
> > be easily overridden?  For example, if whilst building an update the
> > security team discover that there's a problem with the 2to3-generated
> > patch, will they be able to add a fixed patch to the package and have
> > that used in preference?
> 
> Most of the times (all of them?) it can be fixed in Python 2.x code.
> You can also extend 2to3 tool (see f.e. sqlalchemy's sa2to3 or jinja2's
> custom_fixers)
> 

I'm slightly worried by:
Sometimes 2to3 will find a place in your source code that needs to be
changed, but 2to3 cannot fix automatically. In this case, 2to3 will
print a warning beneath the diff for a file. You should address the
warning in order to have compliant 3.x code.

and:
Note The lib2to3 API should be considered unstable and may change
drastically in the future.

I'm copying in the security team; could you have a look at the thread
starting at
http://lists.debian.org/debian-release/2010/08/msg01107.html and pass
any comments?

Thanks,
Neil
-- 
<+Mulligan> Your folk tale is inconsistent and confusing.
<+Mulligan> I shall round up your local population and tell them good CHRISTIAN 
folk tales.
<+Mulligan> Then build churches on all your pagan temples in order to stamp out 
your heathen idolatry.
<@Ulthar> How about I give you the finger, and you give me my temples back?
<+Mulligan> Tell me Mr Ulthar. How will you gather faith when you have no 
followers?
 * Mulligan makes a gesture and converts everyone to Christianity.
<+Mulligan> Wow. I think we just summarised 800 years of history in about six 
sentences.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908114853.gj17...@halon.org.uk

Re: live-* packages

[Holger Levsen]

Hi,

On Mittwoch, 8. September 2010, Daniel Baumann wrote:
> > Well, it was the case during lenny's freeze because (if I'm not
> > mistaken) the packages were still brand new at that time, which doesn't
> > apply anymore.
>
> this is not what luk said to me last release cycle.
>
> > Besides, I don't see changes having something related to
> > the archive's state. If there are any, please comment on them.
>
> people (including me) can't really do wide tests of images that can't be
> build in the first place if not all tasks are installable. that's why
> some bugs only turn up quite late in the release cycle.

a few packages are in this boat: debian-cd, live-* packages, debian-edu, fai 
and probably others. 

what they also have in common is that breakage in them doesnt affect other 
packages.

so IMHO all these kind of packages should be treated differently then the 
rest. equally to the rest they should also only be updated with care and sane 
diffs :)


cheers,
Holger


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

Bug#596063: unblock: pacemaker-mgmt/2.0.0+hg1141-2

[Martin Gerhard Loschwitz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Ladies and Gentlemen,

Please unblock the package pacemaker-mgmt. Right now, it is not present
in Squeeze at all. The tool included in this package, which is called
"hb_gui",
used to live in the heartbeat-gui package in Lenny. Due to numerous
changes in the package's source, it was split out of the heartbeat code and
is a single project now. It got updated meanwhile and is in a decent shape
now. Additionally, it is the only graphical user tool present at all in
Debian
at the moment to manipulate a pacemaker-based cluster's configuration.

Best regards
Martin G. Loschwitz





-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c87784e.2020...@debian.org

Re: chromium not in Squeeze: a bit of communication needed?

[Mike Hommey]

On Wed, Sep 08, 2010 at 01:48:49PM +0200, Stefano Zacchiroli wrote:
> [3] A question you might have at this point is: "why you bother about
> Chromium and not other packages?". Well, I do bother about all
> packages and I'm just trying to anticipate questions I'll might be
> asked as soon as Squeeze get released. For instance and for the same
> reason, I've proposed just yesterday to mention the removal of Plone
> from Squeeze, and the maintainer has kindly agreed to explain the
> reasons in the Squeeze release notes. So, I'm not special casing
> anything here, and I encourage you to point me to other similar
> cases.

I think a section of the release notes should include such information.
It could also include hints at what we plan to do. I don't know what
Giuseppe plans for chromium, but I for one plan to upload newer versions
of iceweasel as soon as I can (which might not be as soon as one could
hope, due to the xulrunner transition that goes with it).

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908121103.ga31...@glandium.org

Re: live-* packages

[Steve McIntyre]

On Wed, Sep 08, 2010 at 01:52:18PM +0200, Holger Levsen wrote:
>Hi,
>
>On Mittwoch, 8. September 2010, Daniel Baumann wrote:
>> > Well, it was the case during lenny's freeze because (if I'm not
>> > mistaken) the packages were still brand new at that time, which doesn't
>> > apply anymore.
>>
>> this is not what luk said to me last release cycle.
>>
>> > Besides, I don't see changes having something related to
>> > the archive's state. If there are any, please comment on them.
>>
>> people (including me) can't really do wide tests of images that can't be
>> build in the first place if not all tasks are installable. that's why
>> some bugs only turn up quite late in the release cycle.
>
>a few packages are in this boat: debian-cd, live-* packages, debian-edu, fai 
>and probably others. 

True. I'm expecting to continue my long-standing tradition of
debian-cd being one of the last packages uploaded before the
release...

>what they also have in common is that breakage in them doesnt affect other 
>packages.
>
>so IMHO all these kind of packages should be treated differently then the 
>rest. equally to the rest they should also only be updated with care and sane 
>diffs :)

Of course!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908121730.ga25...@einval.com

Re: chromium not in Squeeze: a bit of communication needed?

[Mike Hommey]

On Wed, Sep 08, 2010 at 02:11:03PM +0200, Mike Hommey wrote:
> On Wed, Sep 08, 2010 at 01:48:49PM +0200, Stefano Zacchiroli wrote:
> > [3] A question you might have at this point is: "why you bother about
> > Chromium and not other packages?". Well, I do bother about all
> > packages and I'm just trying to anticipate questions I'll might be
> > asked as soon as Squeeze get released. For instance and for the same
> > reason, I've proposed just yesterday to mention the removal of Plone
> > from Squeeze, and the maintainer has kindly agreed to explain the
> > reasons in the Squeeze release notes. So, I'm not special casing
> > anything here, and I encourage you to point me to other similar
> > cases.
> 
> I think a section of the release notes should include such information.
> It could also include hints at what we plan to do. I don't know what
> Giuseppe plans for chromium, but I for one plan to upload newer versions
> of iceweasel as soon as I can (which might not be as soon as one could
> hope, due to the xulrunner transition that goes with it).

into backports, that is.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908130618.ga...@glandium.org

Re: chromium not in Squeeze: a bit of communication needed?

[Julien Cristau]

On Wed, Sep  8, 2010 at 13:48:49 +0200, Stefano Zacchiroli wrote:

> I've been following the chromium-browser saga a bit, who has ended up
> with the removal of the package from testing [1,2]. While I'm a
> chromium-browser user myself, and hence I'm saddened of seeing it go,
> I'm not here to question the choice as I'm sure it's been made as the
> right one and that it hasn't been an easy one to make.
> 
We were given a choice between removing chromium-browser from testing,
or accepting a diff of
22161 files changed, 8494803 insertions(+), 1202268 deletions(-)
That didn't seem like much of a choice.  I don't have any reason to
believe the new version won't have the same problem 2 months (or a year)
from now, and as far as I know neither the security team nor the stable
release managers usually accept that kind of changes in stable.  If they
say they'll be happy to accept random chromium code dumps in released
squeeze, then I guess we can let it back in, but until then I don't
think keeping a version the maintainer doesn't want to support in
testing helps anyone.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Python 3 support in Squeeze

[Piotr Ożarowski]

[Neil McGovern, 2010-09-08]
> I'm slightly worried by:
> Sometimes 2to3 will find a place in your source code that needs to be
> changed, but 2to3 cannot fix automatically. In this case, 2to3 will
> print a warning beneath the diff for a file. You should address the
> warning in order to have compliant 3.x code.
> 
> and:
> Note The lib2to3 API should be considered unstable and may change
> drastically in the future.

once again, we are NOT going to add python3-foo binary packages for code
not tested with Python 3 by upstream. I ask about packages for which
upstream claims 2to3 did a good job or it wasn't needed at all.

Adam: I uploaded my packages that support Python 3 (beaker and mako).
Let me know if I will not waste my time and I will work on docutils,
cython and lxml next.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908131211.gg15...@piotro.eu

Re: live-* packages

[Philipp Kern]

On Wed, Sep 08, 2010 at 01:52:18PM +0200, Holger Levsen wrote:
> > people (including me) can't really do wide tests of images that can't be
> > build in the first place if not all tasks are installable. that's why
> > some bugs only turn up quite late in the release cycle.
> a few packages are in this boat: debian-cd, live-* packages, debian-edu, fai 
> and probably others. 

fai?  Ew, I don't think so.

> what they also have in common is that breakage in them doesnt affect other 
> packages.

That also applies to most of the leaf packages in prio:optional.

Kind regards,
Philipp Kern


signature.asc
Description: Digital signature

Re: live-* packages

[Mehdi Dogguy]

On 08/09/2010 00:14, Daniel Baumann wrote:
> 
> if you judge bugs only by it's reported severity, i can upgrade it to 
> serious :)
> 

I won't play that game. It's just useless.

>> 
>> Why asking for an unblock if there are still changes to be 
>> uploaded/worked on?
> 
> because i was told that the release team preferes to 'review'
> revisions instead of one huge diff.
> 

We do understand that those packages need some special casing… but, some
changes seem really gratuitous and you cannot say that they are needed
because you maintain special packages.

Such changes are (for example) changing the packaging. Please avoid them
in future revisions. Restrict changes to those fixing real issues.

>> and by entries, you mean?
> 
> the entries in the syslinux bootmenu, that's the thing where you
> select what to start when booting from the live media.
> 

*sigh*

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c879120.9000...@dogguy.org

Re: chromium not in Squeeze: a bit of communication needed?

[Giuseppe Iuculano]

On 09/08/2010 03:22 PM, Julien Cristau wrote:
> I don't have any reason to
> believe the new version won't have the same problem 2 months (or a year)
> from now

Note that this isn't a chromium specific issue, please see the opened
issues in webkit:

http://security-tracker.debian.org/tracker/source-package/webkit


Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Re: chromium not in Squeeze: a bit of communication needed?

[Giuseppe Iuculano]

On 09/08/2010 03:22 PM, Julien Cristau wrote:
> and as far as I know neither the security team nor the stable
> release managers usually accept that kind of changes in stable.  If they
> say they'll be happy to accept random chromium code dumps in released
> squeeze, then I guess we can let it back in, but until then I don't
> think keeping a version the maintainer doesn't want to support in
> testing helps anyone.

I never wrote that I will propose random chromium code dumps in released
squeeze, I wrote I plan to backport security fixes and for this reason I
realized that backporting patches in chromium 5 is not feasible.

Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Re: Security bugfix #595248: please unblock libnusoap-php

[Thomas Goirand]

Philipp Kern wrote:
> On Wed, Sep 08, 2010 at 12:02:02PM +0800, Thomas Goirand wrote:
>> I took over maintainership of libnusoap-php after the current maintainer
>> loosely sent an RFA in the middle of the freeze only few months after he
>> had his packages in the archive, because he was pissed by the discussion
>> in #595346 (so I had no choice but to adopt, but if anyone wants to
>> maintain, I'd happily give-up maintainership as I maintain quite a lot
>> of packages already). That leads me to say that I would suggest any DD
>> to *not* sponsor any package from Olivier Berger in the future, as he
>> really had a bad attitude on this case.
> 
> I would suggest any person to be very cautious when dealing with bug reports
> from you, then.
> 
> Kind regards,
> Philipp Kern

You didn't have all the private email exchanges I had with him. I tried
to tell him nicely, really.

Thomas


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c87931f.5040...@goirand.fr

Re: Security bugfix #595248: please unblock libnusoap-php

[Thomas Goirand]

Mehdi Dogguy wrote:
> Please, get your propaganda out of here. I understand why he was
> pissed off.

I quite feel sorry about the issue too, and maybe even a bit guilty.
I'll try my best to ask things in a better way next time, trying to
avoid sensitivity of maintainers.

I tried everything, and he didn't want to listen to any of my points. He
wouldn't even trust what PHP displayed to him on the screen. What could
I do in such case? Just give-up and do an NMU? I think that's what I
should have do, but then what's the point in having a maintainer if he
refuses to fix issues he is supposed to handle?

Feel free to advise me so I wont do the same mistake again (but please,
don't add worth to the bad that happened already).

Thomas


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8794be.4080...@debian.org

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 8 Sep 2010 13:48:49 +0200, Stefano Zacchiroli wrote:
> I've been following the chromium-browser saga a bit, who has ended up
> with the removal of the package from testing [1,2]. While I'm a
> chromium-browser user myself, and hence I'm saddened of seeing it go,
> I'm not here to question the choice as I'm sure it's been made as the
> right one and that it hasn't been an easy one to make.
> 
>   [1] http://lists.debian.org/debian-release/2010/09/msg00582.html
>   [2] 
> http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/
> 
> Still I think we need, as Debian, to communicate about that choice. As
> you can imagine, I particularly care about that as sooner or later
> someone will ask me « why Debian doesn't ship Chromium? », and I'd like
> to know the right answer to that question, so that I can provide it,
> rather than offering my personal view only :-)
> That's all I care about. [3]

I think that this need is justification to declare backports "officially
supported by the debian project".  Thus when asked this question, you
can point to the fact that chromium is indeed supported on stable, just
via a different model than folks are used to.  That is of course
assuming someone is willing to support the backport.  I may do that if
Giuseppe isn't interested.

Having chromium not present in stable proper helps the security team
immensely.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908101035.d733418c.michael.s.gilb...@gmail.com

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 08 Sep 2010 15:58:17 +0200, Giuseppe Iuculano wrote:
> On 09/08/2010 03:22 PM, Julien Cristau wrote:
> > I don't have any reason to
> > believe the new version won't have the same problem 2 months (or a year)
> > from now
> 
> Note that this isn't a chromium specific issue, please see the opened
> issues in webkit:
> 
> http://security-tracker.debian.org/tracker/source-package/webkit

That isn't a very good list wrt to squeeze's webkit since that includes
the multitude of lenny issues.  See [0] of which half of the webkit
issues still open i've commited fixes to git last night, and hopefully
a new package will be uploaded soon.

Best wishes,
Mike

[0] 
http://security-tracker.debian.org/tracker/status/release/unstable?show_undetermined_urgency=1


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908101528.a2ba539b.michael.s.gilb...@gmail.com

Re: live-* packages

[Holger Levsen]

On Mittwoch, 8. September 2010, Philipp Kern wrote:
> > a few packages are in this boat: debian-cd, live-* packages, debian-edu,
> > fai and probably others.
> fai?  Ew, I don't think so.

then I suggest you do your homework and read past years archives.


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

Re: chromium not in Squeeze: a bit of communication needed?

[Giuseppe Iuculano]

On 09/08/2010 04:15 PM, Michael Gilbert wrote:
> That isn't a very good list wrt to squeeze's webkit since that includes
> the multitude of lenny issues.

That was the point, the number of webkit opened issues in lenny.


Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 08 Sep 2010 16:23:59 +0200, Giuseppe Iuculano wrote:
> On 09/08/2010 04:15 PM, Michael Gilbert wrote:
> > That isn't a very good list wrt to squeeze's webkit since that includes
> > the multitude of lenny issues.
> 
> That was the point, the number of webkit opened issues in lenny.

That isn't really a fair comparison.  I campaigned (unsuccessfully) to
keep webkit out of lenny at the time since it was so
experimental/unsupportable.  Thus I had no interest in supporting
that.  However, I'm planning to help support webkit in squeeze, so I
don't foresee such an issue in the future.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908102616.42b7f7c1.michael.s.gilb...@gmail.com

Re: [Pkg-clamav-devel] Please unblock clamav-data

[Marc Haber]

On Wed, Sep 08, 2010 at 01:11:42PM +0200, Michael Tautschnig wrote:
> I have no idea whether you have already come to a conclusion regarding
> clamav-data.

We have. Clamav-data is dead, the host that was building it retired
and decommissioned, all monitoring jobs disabled, a lot of work
flushed down the drain. Frustration stays.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908143808.gc12...@torres.zugschlus.de

Re: Security bugfix #595248: please unblock libnusoap-php

[Mehdi Dogguy]

On 08/09/2010 15:50, Thomas Goirand wrote:
> 
> I tried everything, and he didn't want to listen to any of my points. 
> He wouldn't even trust what PHP displayed to him on the screen.

How this sentence is supposed to enhance the situation? Can't you just stop?

> Just give-up and do an NMU? I think that's what I should have do, but 
> then what's the point in having a maintainer if he refuses to fix 
> issues he is supposed to handle?
> 

The bug you submitted wasn't RC and thus, you shouldn't NMU in this case.
All you can do is to convince the maintainer to fix it, not forcing it.

FTR, I unblocked the package only because there was an RC bug to fix.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c879fd0.9090...@dogguy.org

Re: chromium not in Squeeze: a bit of communication needed?

[Sven Joachim]

On 2010-09-08 16:10 +0200, Michael Gilbert wrote:

> On Wed, 8 Sep 2010 13:48:49 +0200, Stefano Zacchiroli wrote:
>> I've been following the chromium-browser saga a bit, who has ended up
>> with the removal of the package from testing [1,2]. While I'm a
>> chromium-browser user myself, and hence I'm saddened of seeing it go,
>> I'm not here to question the choice as I'm sure it's been made as the
>> right one and that it hasn't been an easy one to make.
>> 
>>   [1] http://lists.debian.org/debian-release/2010/09/msg00582.html
>>   [2] 
>> http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/
>> 
>> Still I think we need, as Debian, to communicate about that choice. As
>> you can imagine, I particularly care about that as sooner or later
>> someone will ask me « why Debian doesn't ship Chromium? », and I'd like
>> to know the right answer to that question, so that I can provide it,
>> rather than offering my personal view only :-)
>> That's all I care about. [3]
>
> I think that this need is justification to declare backports "officially
> supported by the debian project".  Thus when asked this question, you
> can point to the fact that chromium is indeed supported on stable, just
> via a different model than folks are used to.  That is of course
> assuming someone is willing to support the backport.

It also means that users need to be taught how to change the apt pinning
priority for backports, because in the default configuration backported
packages are never updated automatically.  Which is very bad from a
security point of view.

Sven


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwxkmgib@turtle.gmx.de

Re: chromium not in Squeeze: a bit of communication needed?

[Giuseppe Iuculano]

On 09/08/2010 04:26 PM, Michael Gilbert wrote:
> That isn't really a fair comparison.  I campaigned (unsuccessfully) to
> keep webkit out of lenny at the time since it was so
> experimental/unsupportable.  Thus I had no interest in supporting
> that.  However, I'm planning to help support webkit in squeeze, so I
> don't foresee such an issue in the future.

Ok, so you campaigned to keep webkit out of lenny because now it is
unsupportable. Now I have the same question you made for chromium. Are
you sure this will not happen again?

Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Bug#596082: unblock: libcrypt-openssl-x509-perl/1.4-1

[Ansgar Burchardt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock libcrypt-openssl-x509-perl/1.4-1.  It fixes a segfault in
the fingerprint_sha1 method[1] and a bug that causes new_from_string to
fail for some certificates[2].

  unblock libcrypt-openssl-x509-perl/1.4-1

Regards,
Ansgar

PS: Please CC: debian-p...@lists.debian.org in replies.

[1] 
[2] 
Index: X509.pm
===
--- X509.pm	(.../1.2-1)	(revision 62408)
+++ X509.pm	(.../1.4-1)	(revision 62408)
@@ -5,7 +5,7 @@ use vars qw($VERSION @EXPORT_OK);
 use Exporter;
 use base qw(Exporter);
 
-$VERSION = '1.2';
+$VERSION = '1.4';
 
 @EXPORT_OK = qw(
   FORMAT_UNDEF FORMAT_ASN1 FORMAT_TEXT FORMAT_PEM FORMAT_NETSCAPE
Index: debian/control
===
--- debian/control	(.../1.2-1)	(revision 62408)
+++ debian/control	(.../1.4-1)	(revision 62408)
@@ -2,13 +2,13 @@ Source: libcrypt-openssl-x509-perl
 Section: perl
 Priority: optional
 Build-Depends: debhelper (>= 7.2.13), libssl-dev, libtest-pod-perl,
- perl (>= 5.10.0)
+ perl
 Maintainer: Debian Perl Group 
 Uploaders: Micah Anderson ,
  gregor herrmann , Niko Tyni ,
  Damyan Ivanov , Ansgar Burchardt ,
  Salvatore Bonaccorso 
-Standards-Version: 3.8.4
+Standards-Version: 3.9.1
 Homepage: http://search.cpan.org/dist/Crypt-OpenSSL-X509/
 Vcs-Svn: svn://svn.debian.org/pkg-perl/trunk/libcrypt-openssl-x509-perl/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-perl/trunk/libcrypt-openssl-x509-perl/
Index: debian/changelog
===
--- debian/changelog	(.../1.2-1)	(revision 62408)
+++ debian/changelog	(.../1.4-1)	(revision 62408)
@@ -1,3 +1,21 @@
+libcrypt-openssl-x509-perl (1.4-1) unstable; urgency=low
+
+  * New upstream release
+  * Refresh debian/copyright file wording.
+
+ -- Salvatore Bonaccorso   Tue, 31 Aug 2010 17:35:33 +0200
+
+libcrypt-openssl-x509-perl (1.3-1) unstable; urgency=low
+
+  * New upstream release
+  * debian/control: Substitute versioned Build-Depends on perl (>=
+5.10.0) with unversioned one, as stable has already this version and
+oldstable is gone.
+  * debian/copyright: Explicitly point to GPL-1 text in common-licenses.
+  * Bump Standards-Version to 3.9.1.
+
+ -- Salvatore Bonaccorso   Fri, 06 Aug 2010 19:05:21 +0200
+
 libcrypt-openssl-x509-perl (1.2-1) unstable; urgency=low
 
   * New upstream release
Index: debian/copyright
===
--- debian/copyright	(.../1.2-1)	(revision 62408)
+++ debian/copyright	(.../1.4-1)	(revision 62408)
@@ -27,8 +27,8 @@ License: Artistic
  This program is free software; you can redistribute it and/or modify
  it under the terms of the Artistic License, which comes with Perl.
  .
- On Debian GNU/Linux systems, the complete text of the Artistic License
- can be found in `/usr/share/common-licenses/Artistic'
+ On Debian systems, the complete text of the Artistic License can be
+ found in `/usr/share/common-licenses/Artistic'.
 
 License: GPL-1+
  This program is free software; you can redistribute it and/or modify
@@ -36,5 +36,5 @@ License: GPL-1+
  the Free Software Foundation; either version 1, or (at your option)
  any later version.
  .
- On Debian GNU/Linux systems, the complete text of the GNU General
- Public License can be found in `/usr/share/common-licenses/GPL'
+ On Debian systems, the complete text of version 1 of the GNU General
+ Public License can be found in `/usr/share/common-licenses/GPL-1'.
Index: t/x509.t
===
--- t/x509.t	(.../1.2-1)	(revision 62408)
+++ t/x509.t	(.../1.4-1)	(revision 62408)
@@ -1,5 +1,5 @@
 
-use Test::More tests => 43;
+use Test::More tests => 46;
 
 BEGIN { use_ok('Crypt::OpenSSL::X509') };
 
@@ -8,6 +8,7 @@ ok(my $x509 = Crypt::OpenSSL::X509->new_from_file(
 ok($x509->serial() eq '325033CF50D156F35C81AD655C4FC825', 'serial()');
 
 ok($x509->fingerprint_md5() eq '51:86:E8:1F:BC:B1:C3:71:B5:18:10:DB:5F:DC:F6:20', 'fingerprint_md5()');
+ok($x509->fingerprint_sha1() eq '78:E9:DD:06:50:62:4D:B9:CB:36:B5:07:67:F2:09:B8:43:BE:15:B3', 'fingerprint_sha1()');
 
 ok($x509->exponent() eq '10001', 'exponent()');
 ok($x509->pub_exponent() eq '10001', 'pub_exponent()'); # Alias
@@ -71,3 +72,13 @@ is($x509->subject_name()->get_index_by_long_type("
 isa_ok($x509->subject_name()->get_entry_by_type("ST"),"Crypt::OpenSSL::X509::Name_Entry",'Name->get_entry_by_type');
 ok($x509->subject_name()->get_entry_by_type("ST")->is_printableString(),'Name_Entry->is_printableString');
 ok(not($x509->subject_name()->get_entry_by_type("ST")->is_asn1_type(Crypt::OpenSSL::X509::V_ASN1_UTF8STRING)),'Name_Entry->is_asn1_type');
+
+# Check new_from_string / as_string round trip.
+{
+  my $x509 = Crypt::OpenSSL::X509->new_from_string(
+

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 08 Sep 2010 16:55:40 +0200, Sven Joachim wrote:
> On 2010-09-08 16:10 +0200, Michael Gilbert wrote:
> 
> > On Wed, 8 Sep 2010 13:48:49 +0200, Stefano Zacchiroli wrote:
> >> I've been following the chromium-browser saga a bit, who has ended up
> >> with the removal of the package from testing [1,2]. While I'm a
> >> chromium-browser user myself, and hence I'm saddened of seeing it go,
> >> I'm not here to question the choice as I'm sure it's been made as the
> >> right one and that it hasn't been an easy one to make.
> >> 
> >>   [1] http://lists.debian.org/debian-release/2010/09/msg00582.html
> >>   [2] 
> >> http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/
> >> 
> >> Still I think we need, as Debian, to communicate about that choice. As
> >> you can imagine, I particularly care about that as sooner or later
> >> someone will ask me « why Debian doesn't ship Chromium? », and I'd like
> >> to know the right answer to that question, so that I can provide it,
> >> rather than offering my personal view only :-)
> >> That's all I care about. [3]
> >
> > I think that this need is justification to declare backports "officially
> > supported by the debian project".  Thus when asked this question, you
> > can point to the fact that chromium is indeed supported on stable, just
> > via a different model than folks are used to.  That is of course
> > assuming someone is willing to support the backport.
> 
> It also means that users need to be taught how to change the apt pinning
> priority for backports, because in the default configuration backported
> packages are never updated automatically.  Which is very bad from a
> security point of view.

So, I think the solution for that is relatively straightforward.  I
think that an important part of making backports official would be
adding an option to the installer that automatically sets up backports
in the sources.list with a reasonable priority (similar to what is
done for volatile and security now).

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908110210.930e8bc9.michael.s.gilb...@gmail.com

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 08 Sep 2010 17:02:33 +0200, Giuseppe Iuculano wrote:
> On 09/08/2010 04:26 PM, Michael Gilbert wrote:
> > That isn't really a fair comparison.  I campaigned (unsuccessfully) to
> > keep webkit out of lenny at the time since it was so
> > experimental/unsupportable.  Thus I had no interest in supporting
> > that.  However, I'm planning to help support webkit in squeeze, so I
> > don't foresee such an issue in the future.
> 
> Ok, so you campaigned to keep webkit out of lenny because now it is
> unsupportable. Now I have the same question you made for chromium. Are
> you sure this will not happen again?

I campaigned to keep webkit out of lenny because I foresaw it as
unsupportable then (and now we have evidence that confirms that).  I
think its come a long way since then, and I think it is indeed
supportable now for squeeze.

On the other hand, I don't think chromium is supportable yet, which is
why I don't think it should be in squeeze.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908110457.07015063.michael.s.gilb...@gmail.com

Re: chromium not in Squeeze: a bit of communication needed?

[Giuseppe Iuculano]

On 09/08/2010 05:04 PM, Michael Gilbert wrote:

> I think it is indeed supportable now for squeeze.

What was changed from lenny to now?


Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Re: chromium not in Squeeze: a bit of communication needed?

[Teodor MICU]

On Wed, Sep 8, 2010 at 5:55 PM, Sven Joachim  wrote:
> On 2010-09-08 16:10 +0200, Michael Gilbert wrote:
>> I think that this need is justification to declare backports "officially
>> supported by the debian project".  Thus when asked this question, you
>> can point to the fact that chromium is indeed supported on stable, just
>> via a different model than folks are used to.  That is of course
>> assuming someone is willing to support the backport.
>
> It also means that users need to be taught how to change the apt pinning
> priority for backports, because in the default configuration backported
> packages are never updated automatically.  Which is very bad from a
> security point of view.

Yes, but it is not the best solution. Someone already proposed in
another thread (about 'backports') to change the default archive pin
from '1' to '200' (in fact any value >=100 and <500, 200 is just my
favorite) so that packages from backports will still have a lower
priority over the packages from stable/security/volatile but also to
be able to install them without pinning all the involved packages if
the package only exists on backports.

Thanks


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

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 08 Sep 2010 17:09:32 +0200, Giuseppe Iuculano wrote:
> On 09/08/2010 05:04 PM, Michael Gilbert wrote:
> 
> > I think it is indeed supportable now for squeeze.
> 
> What was changed from lenny to now?

The are now many very usable webkit frontends, which I can use on a
daily basis, so I now have interest in using webkit itself, and thus
have interest in closing security issues; whereas with lenny there is
no usable frontend, and thus no reason for anyone to be interested in
security support.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908111558.935f2781.michael.s.gilb...@gmail.com

Re: live-* packages

[Holger Levsen]

/me likes to apologize for the style in my previous mail again.

that said...

On Mittwoch, 8. September 2010, Holger Levsen wrote:
> then I suggest you do your homework and read past years archives.

 phil, i can see [requests for unblocking of] 3.2.16 in 2009, 3.2.15, 
.14 and .11 in 2008, 4 more in 2007, 3 in 2006, 3 in 2005. i'm only subscribed 
to -release since december 2004 indeed ;)



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

Re: chromium not in Squeeze: a bit of communication needed?

[Josselin Mouette]

Le mercredi 08 septembre 2010 à 17:09 +0200, Giuseppe Iuculano a écrit :
> On 09/08/2010 05:04 PM, Michael Gilbert wrote:
> 
> > I think it is indeed supportable now for squeeze.
> 
> What was changed from lenny to now?

What has changed is that webkit is widely deployed inside and outside
Debian, and for that has undergone a large scrutiny that got rid of much
maintainability issues.

Furthermore we are shipping the 1.2 branch in squeeze, for which
upstream has explicitly committed to long term support.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283959080.22754.1.ca...@meh

Re: chromium not in Squeeze: a bit of communication needed?

[Joey Hess]

Michael Gilbert wrote:
> I think that this need is justification to declare backports "officially
> supported by the debian project".  Thus when asked this question, you
> can point to the fact that chromium is indeed supported on stable, just
> via a different model than folks are used to.

Do you really think that desktop users[1] should be expected to learn about
backports, and manually configure them, and learn how to convince apt to
install from them, in order to get the best web browser available[2]? If
the preceding sounds simple, think again; you're suggesting that users
have to either dig up some faq or forum post, or post to debian-user, just
in order to get a good web browser.

If backports are really officially supported, and we encourage users to
install a web browser from them, which is not available in stable, how
is that truely different than shipping the same web browser in stable?
AFAICS the only difference is that only 10 to 25% [3] of users will find
the web browser in backports, while some other percentage will
install Ubuntu instead. The security team will still be left responsible
for supporting the former users' systems.

(BTW, have you considered that apt does not automatically upgrade packages
installed from backports? That the majority of documentation, including
the documentation on wiki.debian.org, about installing flashplugin-nonfree
from backports does not take this into account, and will leave the user with
a never-upgraded package?)

-- 
see shy jo

[1] As opposed to the server administrators who seem to be backports'
main current audience.
[2] Chromium or iceweasel; take your pick since backports is being
suggested as a delivery mechanism for both.
[3] Estimate based roughly on percentage of stable users who manage to
install flashplugin-nonfree, whose installation is similarly obfuscated.


signature.asc
Description: Digital signature

Re: chromium not in Squeeze: a bit of communication needed?

[Mike Hommey]

On Wed, Sep 08, 2010 at 05:17:55PM +0200, Josselin Mouette wrote:
> Le mercredi 08 septembre 2010 à 17:09 +0200, Giuseppe Iuculano a écrit :
> > On 09/08/2010 05:04 PM, Michael Gilbert wrote:
> > 
> > > I think it is indeed supportable now for squeeze.
> > 
> > What was changed from lenny to now?
> 
> What has changed is that webkit is widely deployed inside and outside
> Debian, and for that has undergone a large scrutiny that got rid of much
> maintainability issues.
> 
> Furthermore we are shipping the 1.2 branch in squeeze, for which
> upstream has explicitly committed to long term support.

*hum* the 1.0 branch was supposed to come with long term support, too.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908152647.gb2...@glandium.org

Re: chromium not in Squeeze: a bit of communication needed?

[Mike Hommey]

On Wed, Sep 08, 2010 at 11:14:33AM -0400, Joey Hess wrote:
> [2] Chromium or iceweasel; take your pick since backports is being
> suggested as a delivery mechanism for both.

There is a difference with Iceweasel, though, in that squeeze will ship
with Iceweasel.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908153039.gc2...@glandium.org

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 8 Sep 2010 11:14:33 -0400, Joey Hess wrote:
> Michael Gilbert wrote:
> > I think that this need is justification to declare backports "officially
> > supported by the debian project".  Thus when asked this question, you
> > can point to the fact that chromium is indeed supported on stable, just
> > via a different model than folks are used to.
> 
> Do you really think that desktop users[1] should be expected to learn about
> backports, and manually configure them, and learn how to convince apt to
> install from them, in order to get the best web browser available[2]? If
> the preceding sounds simple, think again; you're suggesting that users
> have to either dig up some faq or forum post, or post to debian-user, just
> in order to get a good web browser.

A an option in the installer like volatile/security should address a
lot of this concern.

> If backports are really officially supported, and we encourage users to
> install a web browser from them, which is not available in stable, how
> is that truely different than shipping the same web browser in stable?

The difference is that there is no arduous backporting/dsa process to
push that update, and as an added benefit, it gets a ton of testing by
going through unstable/testing first.  Plus, there is a subset of users
that want to always have the latest/greatest browser, and stable can
never meet that need.

> AFAICS the only difference is that only 10 to 25% [3] of users will find
> the web browser in backports, while some other percentage will
> install Ubuntu instead. The security team will still be left responsible
> for supporting the former users' systems.

Adding an option in the installer would significantly help
discoverability.

> (BTW, have you considered that apt does not automatically upgrade packages
> installed from backports? That the majority of documentation, including
> the documentation on wiki.debian.org, about installing flashplugin-nonfree
> from backports does not take this into account, and will leave the user with
> a never-upgraded package?)

Maybe the decision about backports priority should be reconsidered?
Give it an appropriately higher priority due to its "official" nature
now.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908113429.e1f18c56.michael.s.gilb...@gmail.com

Re: chromium not in Squeeze: a bit of communication needed?

[Giuseppe Iuculano]

On 09/08/2010 05:15 PM, Michael Gilbert wrote:
> I now have interest in using webkit itself, and thus
> have interest in closing security issues; whereas with lenny there is
> no usable frontend, and thus no reason for anyone to be interested in
> security support.

I think it is more honest to say that webkit in lenny has a lot of
opened issue because backporting is a pain, and not because you haven't
interest in fixing them.

Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 08 Sep 2010 17:42:37 +0200, Giuseppe Iuculano wrote:
> On 09/08/2010 05:15 PM, Michael Gilbert wrote:
> > I now have interest in using webkit itself, and thus
> > have interest in closing security issues; whereas with lenny there is
> > no usable frontend, and thus no reason for anyone to be interested in
> > security support.
> 
> I think it is more honest to say that webkit in lenny has a lot of
> opened issue because backporting is a pain, and not because you haven't
> interest in fixing them.

No, my interest right now is removing webkit from lenny because no one
has any interest in using/supporting it there.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908114328.22327289.michael.s.gilb...@gmail.com

Bug#596090: unblock: brasero/2.30.3-1

[Josselin Mouette]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

brasero (2.30.3-1) unstable; urgency=low
 .
   * Recommend cdrdao 1.2.3 so that it can actually work.
 + This restores CD copying functionality. Closes: #587408.
 + And audio CD burning without brasero-cdrkit. Closes: #580874.
   * New upstream bugfix and translation release.
 + Drops CD text support. Closes: #578366.
   * 90_relibtoolize.patch: updated for the new version.

The upstream changes are only bug fixes and translation updates:

30-08-2010 2.30.3

Bug fix release:

#627687 - Rhythmbox create audio CD does not work
#627005 - Starting brasero with --device=/dev/sr0 floating point 
exception
#606010 - crashes at audio CD insertion
#622394  - make check fails: The following files contain translations 
and are currently not in use
#622968  - Add File Selector mis-behaves: No Places pane. Ctrl/click 
action wrong
#623484  - No estimated drive speed shown
+ miscellaneous other fixes.

Translations:

Updated Hungarian translation (Gabor Kelemen )
Updated Indonesian translation (Andika Triwidada )
Update Simplified Chinese translation (lainme )

The diff for non-{documentation,translation} files is attached. 

Cheers,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling
--- brasero-2.30.2/libbrasero-burn/brasero-blank-dialog.c	2010-06-18 00:10:26.0 +
+++ brasero-2.30.3/libbrasero-burn/brasero-blank-dialog.c	2010-08-30 13:53:49.0 +
@@ -44,6 +44,7 @@
 #include "burn-basics.h"
 
 #include "brasero-session.h"
+#include "brasero-session-helper.h"
 #include "brasero-burn.h"
 
 #include "burn-plugin-manager.h"
@@ -202,6 +203,7 @@
 	priv = BRASERO_BLANK_DIALOG_PRIVATE (self);
 
 	burn = brasero_tool_dialog_get_burn (dialog);
+	brasero_burn_session_start (priv->session);
 	result = brasero_burn_blank (burn,
  priv->session,
  &error);
--- brasero-2.30.2/libbrasero-burn/brasero-burn-lib.h	2010-06-22 00:14:35.0 +
+++ brasero-2.30.3/libbrasero-burn/brasero-burn-lib.h	2010-08-30 14:03:40.0 +
@@ -48,7 +48,7 @@
 #define LIBBRASERO_BURN_VERSION_MINOR		\
 	30
 #define LIBBRASERO_BURN_VERSION_MICRO		\
-	2
+	3
 #define LIBBRASERO_BURN_AGE			\
 	202
 
--- brasero-2.30.2/libbrasero-burn/brasero-session.c	2010-06-21 22:56:08.0 +
+++ brasero-2.30.3/libbrasero-burn/brasero-session.c	2010-08-30 13:53:49.0 +
@@ -2135,6 +2135,7 @@
 			   va_list arg_list)
 {
 	int len;
+	int wlen;
 	gchar *message;
 	gchar *offending;
 	BraseroBurnSessionPrivate *priv;
@@ -2156,8 +2157,14 @@
 		*offending = '\0';
 
 	len = strlen (message);
-	if (write (priv->session, message, len) != len)
-		g_warning ("Some log data couldn't be written: %s\n", message);
+	wlen = write (priv->session, message, len);
+	if (wlen != len) {
+		int errnum = errno;
+
+		g_warning ("Some log data couldn't be written: %s (%i out of %i) (%s)\n",
+		   message, wlen, len,
+		   strerror (errnum));
+	}
 
 	g_free (message);
 
--- brasero-2.30.2/libbrasero-burn/brasero-sum-dialog.c	2010-06-18 00:10:26.0 +
+++ brasero-2.30.3/libbrasero-burn/brasero-sum-dialog.c	2010-08-30 13:53:49.0 +
@@ -60,6 +60,8 @@
 
 #include "brasero-tags.h"
 #include "brasero-track-disc.h"
+
+#include "brasero-session-helper.h"
 #include "brasero-burn.h"
 
 G_DEFINE_TYPE (BraseroSumDialog, brasero_sum_dialog, BRASERO_TYPE_TOOL_DIALOG);
@@ -622,6 +624,7 @@
 	self = BRASERO_SUM_DIALOG (dialog);
 	priv = BRASERO_SUM_DIALOG_PRIVATE (dialog);
 
+	brasero_burn_session_start (priv->session);
 	if (!gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (priv->md5_check)))
 		result = brasero_sum_dialog_check_disc_sum (self, brasero_medium_get_drive (medium));
 	else
--- brasero-2.30.2/libbrasero-burn/brasero-tool-dialog.c	2010-06-18 00:10:26.0 +
+++ brasero-2.30.3/libbrasero-burn/brasero-tool-dialog.c	2010-07-05 18:24:32.0 +
@@ -45,7 +45,6 @@
 
 #include "brasero-misc.h"
 
-#include "brasero-session.h"
 #include "brasero-burn.h"
 
 #include "brasero-medium.h"
--- brasero-2.30.2/libbrasero-burn/brasero-track-data.c	2010-06-18 00:10:26.0 +
+++ brasero-2.30.3/libbrasero-burn/brasero-track-data.c	2010-07-05 19:14:42.0 +
@@ -479,7 +479,7 @@
 		BraseroGraftPt *graft;
 		gchar newpath [MAXPATHLEN];
 
-		graft = grafts->data;
+		graft = iter->data;
 		mangle = brasero_track_data_mangle_joliet_name (mangle,
 graft->path,
 newpath);
--- brasero-2.30.2/libbrasero-burn/burn-dbus.c	2010-06-18 00:10:26.0 +
+++ brasero-2.30.3/libbrasero-burn/burn-dbus.c	2010-08-30 13:53:49.0 +
@@ -118,7 +118,7 @@
 
 	res = dbus_g_proxy_call (proxy,

Bug#596093: unblock: dmz-cursor-theme/0.4.2

[Josselin Mouette]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock dmz-cursor-theme for squeeze.

dmz-cursor-theme (0.4.2) unstable; urgency=low
 .
   * Standards version is 3.9.1.
   * Update to latest git version.
   * Update copyright, with new license: CC BY-SA 3.0.
   * Build the theme from the PNG files. Keep the SVG around so that
 all the source is here.
   * Require x11-apps (for xcursorgen) for the build.
   * Bump DMZ-White priority to 90, since it is very neutral.

The source changes are the following:
70a6589 add a new cursor - color-picker
0359f22 replace the small dag had with the same size as the default.
Avoids cursor jumping. Remove the original dmz and dmz-aa
themes with the SLE spinner. vanilla-dmz is the new dmz.
(Note: we already used vanilla-dmz so the last sentence is not a change
for us.)

The really important changes are:
  * DFSG-conformance: the source package didn’t include the PNG
sources nor the SVG that was used to generate them.
  * Priority bump for DMZ-White, to avoid using oxygen (with is very
un-neutral) as the default when both KDE and GNOME are
installed.

Thanks for your work,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling




--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283962085.22754.25.ca...@meh

Re: chromium not in Squeeze: a bit of communication needed?

[Joey Hess]

Michael Gilbert wrote:
> A an option in the installer like volatile/security should address a
> lot of this concern.

Unless it installs the package from backports, the most the installer
can do is eliminate one or two of the three or four things users must
do to use it. All my comments about user discoverability/usability still
apply.

> > If backports are really officially supported, and we encourage users to
> > install a web browser from them, which is not available in stable, how
> > is that truely different than shipping the same web browser in stable?
> 
> The difference is that there is no arduous backporting/dsa process to
> push that update

If we're encouraging users to install a web browser from an officially
supported part of Debian, then the security support requirements are not
lessened *at all*.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#596095: unblock: epiphany-extensions/2.30.2-1

[Josselin Mouette]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock epiphany-extensions for squeeze.

epiphany-extensions (2.30.2-1) unstable; urgency=low
 .
   [ Josselin Mouette ]
   * Drop obsolete dependencies on w3c-dtd-xhtml and sgml-data.
 .
   [ Sebastian Dröge ]
   * New upstream bugfix release:
 + debian/patches/01_fix_html5tube.patch:
   - Dropped, merged upstream.

The upstream changes are translation updates and the one change that was
already patched in Debian:

==
Epiphany Extensions 2.30.2
==

Update html5tube to work with new youtube layout.

Which means there are no code changes.

Thanks,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling




--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283962892.22754.34.ca...@meh

Bug#596096: unblock: gdm/2.20.11-2

[Josselin Mouette]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock gdm for squeeze.

gdm (2.20.11-2) unstable; urgency=low
 .
   * Use linux-any wildcard instead of listing non-linux architectures.
   * Bump standards version accordingly.
   * 23_xsession-errors.patch: disable the obnoxious behavior that stops
 filling .xsession-errors when there is too much output.
   * Update watch file.

It’s only one simple code change that I’m attaching, and I saw enough
people complain of that behavior to think it’s worth it, even without a
bug report on its own.

Thanks,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling
Index: gdm-2.20.11/daemon/slave.c
===
--- gdm-2.20.11.orig/daemon/slave.c	2010-07-04 15:16:55.919565088 +0200
+++ gdm-2.20.11/daemon/slave.c	2010-07-04 15:17:11.559565073 +0200
@@ -373,10 +373,6 @@ run_session_output (gboolean read_until_
 			break;
 		}
 
-		if G_UNLIKELY (d->xsession_errors_bytes >= MAX_XSESSION_ERRORS_BYTES ||
-			   got_xfsz_signal)
-			continue;
-
 		/* write until we succeed in writing something */
 		VE_IGNORE_EINTR (written = write (d->xsession_errors_fd, buf, r));
 		if G_UNLIKELY (written < 0 || got_xfsz_signal) {
@@ -397,13 +393,6 @@ run_session_output (gboolean read_until_
 
 		d->xsession_errors_bytes += r;
 
-		if G_UNLIKELY (d->xsession_errors_bytes >= MAX_XSESSION_ERRORS_BYTES &&
-			   ! got_xfsz_signal) {
-			VE_IGNORE_EINTR (write (d->xsession_errors_fd,
-		"\n...Too much output, ignoring rest...\n",
-		strlen ("\n...Too much output, ignoring rest...\n")));
-		}
-
 		/* there wasn't more then buf available, so no need to try reading
 		 * again, unless we really want to */
 		if (r < sizeof (buf) && ! read_until_eof)

Re: chromium not in Squeeze: a bit of communication needed?

[Mike Hommey]

On Wed, Sep 08, 2010 at 12:19:40PM -0400, Joey Hess wrote:
> Michael Gilbert wrote:
> > A an option in the installer like volatile/security should address a
> > lot of this concern.
> 
> Unless it installs the package from backports, the most the installer
> can do is eliminate one or two of the three or four things users must
> do to use it. All my comments about user discoverability/usability still
> apply.
> 
> > > If backports are really officially supported, and we encourage users to
> > > install a web browser from them, which is not available in stable, how
> > > is that truely different than shipping the same web browser in stable?
> > 
> > The difference is that there is no arduous backporting/dsa process to
> > push that update
> 
> If we're encouraging users to install a web browser from an officially
> supported part of Debian, then the security support requirements are not
> lessened *at all*.

Arguably, it's easier to get newest releases of the software as security
support into testing and thus backports, than it is to get them in
stable.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908164117.gb3...@glandium.org

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 8 Sep 2010 12:19:40 -0400, Joey Hess wrote:
> Michael Gilbert wrote:
> > A an option in the installer like volatile/security should address a
> > lot of this concern.
> 
> Unless it installs the package from backports, the most the installer
> can do is eliminate one or two of the three or four things users must
> do to use it. All my comments about user discoverability/usability still
> apply.

Here's what I think could be done:

1.  Provide debian-backports-desktop which has a limited set of
bleeding edge packages that desktop users want
2.  Make the priority of this release higher than that of stable, and
have some high standards for the ftpmaster to control what gets in
3.  Provide debian-backports-server which is the current backports,
just renamed, and operates the same way
4.  Provide an option in the installer called "I want bleeding edge
desktop updates (provided via debian-backports-desktop)"
5.  Provide an option called "I want server backports (provided via
debian-backports-server)"

> > > If backports are really officially supported, and we encourage users to
> > > install a web browser from them, which is not available in stable, how
> > > is that truely different than shipping the same web browser in stable?
> > 
> > The difference is that there is no arduous backporting/dsa process to
> > push that update
> 
> If we're encouraging users to install a web browser from an officially
> supported part of Debian, then the security support requirements are not
> lessened *at all*.

Testing is currently declared "officially supported" and those updates
go through the same unstable->testing process proposed here.  They
receive no announcement other than the automated daily testing security
postings [0].  Perhaps those announcements could be made a bit more
professional, and perhaps done on a per-package basis. It may also be
that they should be posted to debian-security-announce as well.

Best wishes,
Mike

[0]
http://lists.debian.org/debian-testing-security-announce/2010/09/threads.html


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908125728.48380d5f.michael.s.gilb...@gmail.com

Re: chromium not in Squeeze: a bit of communication needed?

[Moritz Muehlenhoff]

On Wed, Sep 08, 2010 at 03:22:29PM +0200, Julien Cristau wrote:

> from now, and as far as I know neither the security team nor the stable
> release managers usually accept that kind of changes in stable.  If they
> say they'll be happy to accept random chromium code dumps in released
> squeeze, 

The plan for Chromium is to update it with the Chromium stable releases, i.e.
the same way Xulrunner has been updated during the supported life time of 
xulrunner 1.9.0. Once these updates have stopped, the plan is apply 
backported patches (again, like xulrunner is handled for lenny).

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908170829.ga22...@inutil.org

maxima 'serious' bug fix missed freeze

[Camm Maguire]

Greetings!  I uploaded a fix for 591862 together with a minor upstream
point release that just missed the freeze.  Would it be possible to
permit the fixed version in unstable to migrate, or should a patch to
the testing version be prepared?  In case of the latter, I cannot
upload such to unstable due to the version number mismatch, yet

http://lists.debian.org/debian-devel-announce/2010/09/msg0.html

seems to instruct thus.

I would greatly appreciate letting the unstable version migrate if
possible.  This is a leaf package, and a notable bug upstream has been
fixed as well.

Take care,

Kumar Appaiah  writes:

> (Resent to the BTS, as I sent to Camm separately)
>
> Dear Camm,
>
> I have observed that you have combined the fix for maxima's #591862
> bug along with a new upstream version. As the release team does not
> accept new upstream versions without adequate justification for
> migration to testing during the freeze, could you please tell me if
> you propose to:
>
> - Write to the release team, requesting them to review and unblock the
>   new version?
> - or prepare an upload with just the bug fixes to
>   testing-proposed-updates?
>
> If you don't have time for these, I can volunteer to do the latter for
> you.
>
> Thanks!
>
> Kumar
>
>
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aans9opy@maguirefamily.org

squid: simple typo with bad effects

[Holger Levsen]

found 591839 2.7.STABLE3-4.1lenny1
found 591839 2.7.STABLE9-2
thanks

Hi Luigi,

do you plan to address 591839 before the release of squeeze?

Hi release-team,

would an NMU with the following patch to squid.conf be acceptable?

-refresh_pattern (Release|Package(.gz)*)$   0   20% 2880
+refresh_pattern (Release|Packages(.gz)*)$  0   20%  2880

This bug is affecting Debian Edu badly, as we use squid as a default proxy for 
installations...


cheers,
Holger, who would really prefer a maintainer upload


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

Re: maxima 'serious' bug fix missed freeze

[Kumar Appaiah]

Hi!

On Wed, Sep 08, 2010 at 12:36:41PM -0400, Camm Maguire wrote:
> Greetings!  I uploaded a fix for 591862 together with a minor upstream
> point release that just missed the freeze.  Would it be possible to
> permit the fixed version in unstable to migrate, or should a patch to
> the testing version be prepared?  In case of the latter, I cannot
> upload such to unstable due to the version number mismatch, yet
> 
> http://lists.debian.org/debian-devel-announce/2010/09/msg0.html
> 
> seems to instruct thus.
> 
> I would greatly appreciate letting the unstable version migrate if
> possible.  This is a leaf package, and a notable bug upstream has been
> fixed as well.

While I support this request, I am afraid that the changes look to be
too many, at least to me. I tried to isolate the relevant changes, but
it has become very difficult since a lot of files (several possibly
autogenerated). I was also unable to figure out which bug was fixed,
in order to try and isolate the bug fix.

Should the latter option (t-p-u) be chosen, I have attached the
relevant patch, which might prove helpful to Camm.

Thanks!

Kumar
-- 
`When you say "I wrote a program that crashed Windows", people just stare at
you blankly and say "Hey, I got those with the system, *for free*".'
(By Linus Torvalds)
diff -u maxima-5.21.1/debian/maxima-emacs.emacsen-startup maxima-5.21.1/debian/maxima-emacs.emacsen-startup
--- maxima-5.21.1/debian/maxima-emacs.emacsen-startup
+++ maxima-5.21.1/debian/maxima-emacs.emacsen-startup
@@ -25,11 +25,6 @@
 
 (autoload 'maxima "maxima" "" t)
 
-
-; For emaxima.lisp to be found and tex update mode to be enabled.
-;
-(debian-pkg-add-load-path-item "/usr/share/emacs/site-lisp/maxima")
-;
 (autoload 'emaxima-mode "emaxima" "" t)
 
 (autoload 'imaxima "imaxima" "" t)
diff -u maxima-5.21.1/debian/maxima-emacs.emacsen-install maxima-5.21.1/debian/maxima-emacs.emacsen-install
--- maxima-5.21.1/debian/maxima-emacs.emacsen-install
+++ maxima-5.21.1/debian/maxima-emacs.emacsen-install
@@ -12,12 +12,9 @@
 
 echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
 
-#FLAVORTEST=`echo $FLAVOR | cut -c-6`
-#if [ ${FLAVORTEST} = xemacs ] ; then
-#SITEFLAG="-no-site-file"
-#else
-#SITEFLAG="--no-site-file"
-#fi
+# Do not load startup files when byte-compiling.
+SITEFLAG="-no-site-file"
+
 FLAGS="${SITEFLAG} -q -batch -l path.el -f batch-byte-compile"
 
 ELDIR=/usr/share/emacs/site-lisp/${PACKAGE}
@@ -34,12 +31,12 @@
 cd ${ELDIR}
 FILES=`echo *.el`
-cp ${FILES} ${ELCDIR}
 cd ${ELCDIR}
+ln -sf ${ELDIR}/*.el ${ELDIR}/*.lisp .
 
 cat << EOF > path.el
 (setq load-path (cons "." load-path) byte-compile-warnings nil)
 EOF
 ${FLAVOR} ${FLAGS} ${FILES}
-rm -f *.el path.el
+rm -f path.el
 
 exit 0
only in patch2:
unchanged:
--- maxima-5.21.1.orig/interfaces/emacs/emaxima/maxima.el
+++ maxima-5.21.1/interfaces/emacs/emaxima/maxima.el
@@ -2494,7 +2494,7 @@
 (define-key map "\C-c\)" 'maxima-check-parens)
 (define-key map [(control c) (control \))] 'maxima-check-form-parens)
 ;(define-key map "\C-cC-\)" 'maxima-check-form-parens)
-(define-key map "\177" 'backward-delete-char-untabify)
+;(define-key map "\177" 'backward-delete-char-untabify)
 (setq maxima-mode-map map)))
 
  Menu
@@ -3321,7 +3321,7 @@
 (define-key inferior-maxima-mode-map [(meta control tab)] 
   'inferior-maxima-input-complete)
 (define-key inferior-maxima-mode-map "\e\t" 'inferior-maxima-complete)
-(define-key inferior-maxima-mode-map "\177" 'backward-delete-char-untabify)
+;(define-key inferior-maxima-mode-map "\177" 'backward-delete-char-untabify)
 (define-key inferior-maxima-mode-map "\C-c\C-k" 'maxima-stop)
 (define-key inferior-maxima-mode-map "\C-c\C-d" maxima-help-map)
 

unblock request: knowledgeroot 0.9.9.5-5

[Frank Habermann]

Hi,

please unblock knowledgeroot 0.9.9.5-5.

It fixes Cross-site scripting (XSS) vulnerability in HTML Purifier 
[CVE-2010-2479] .

regards,
Frank


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

Re: Permission to upload maxima to testing-proposed-updates for fixing #591862

[Kumar Appaiah]

On Wed, Sep 08, 2010 at 12:25:11AM -0500, Kumar Appaiah wrote:
> Dear Release Team,
> 
> Maxima has an RC bug in squeeze (#591862). Unfortunately, the fix for
> that bug was made along with a new upstream release. I have just made
> a request to the maintainer to handle this issue[1]. However, in the
> mean while, I was wondering if there would be any objections if I
> proposed a DELAYED/7 upload to testing-proposed-updates to fix this
> bug, since this is an RC bug which has been open for quite a while.

I withdraw this request, since the maintainer will handle this
(another thread started).

Thank you.

Kumar
-- 
Linux poses a real challenge for those with a taste for late-night
hacking (and/or conversations with God).
-- Matt Welsh


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908180010.ga28...@146653177.ece.utexas.edu

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 8 Sep 2010 12:57:28 -0400, Michael Gilbert wrote:
> On Wed, 8 Sep 2010 12:19:40 -0400, Joey Hess wrote:
> > Michael Gilbert wrote:
> > > A an option in the installer like volatile/security should address a
> > > lot of this concern.
> > 
> > Unless it installs the package from backports, the most the installer
> > can do is eliminate one or two of the three or four things users must
> > do to use it. All my comments about user discoverability/usability still
> > apply.
> 
> Here's what I think could be done:
> 
> 1.  Provide debian-backports-desktop which has a limited set of
> bleeding edge packages that desktop users want
> 2.  Make the priority of this release higher than that of stable, and
> have some high standards for the ftpmaster to control what gets in
> 3.  Provide debian-backports-server which is the current backports,
> just renamed, and operates the same way
> 4.  Provide an option in the installer called "I want bleeding edge
> desktop updates (provided via debian-backports-desktop)"
> 5.  Provide an option called "I want server backports (provided via
> debian-backports-server)"

This solution may be more complicated than necessary.  I just re-read
backports' documentation.  It looks like automatic updates are prevented
due to the use of the 'NotAutomatic' flag in the release file.  I'd be
interested in understanding the logic for that setting and debating
whether it could be disabled.

As for the need for pinning, that can be solved by judiciously choosing
package names.  The current instructions say to append '~bpo' to all
packages, which makes backport versions older than stable versions.  For
chromium and other fast-moving packages that should stay up to date, the
instructions could say to use '+bpo' which would make that a newer
version than stable.

Again, it should be up to the ftpmaster to review and OK (via request)
all '+bpo' uploads due to the risk of breakage on automatic updates.
Combine this solution with disabling 'NotAutomatic', and I think all of
the concerns are addressed.  Thoughts?

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908141526.eec0b342.michael.s.gilb...@gmail.com

Re: chromium not in Squeeze: a bit of communication needed?

[Julien Cristau]

On Wed, Sep  8, 2010 at 14:15:26 -0400, Michael Gilbert wrote:

> As for the need for pinning, that can be solved by judiciously choosing
> package names.  The current instructions say to append '~bpo' to all
> packages, which makes backport versions older than stable versions.  For
> chromium and other fast-moving packages that should stay up to date, the
> instructions could say to use '+bpo' which would make that a newer
> version than stable.
> 
> Again, it should be up to the ftpmaster to review and OK (via request)
> all '+bpo' uploads due to the risk of breakage on automatic updates.
> Combine this solution with disabling 'NotAutomatic', and I think all of
> the concerns are addressed.  Thoughts?
> 
That makes absolutely no sense.  Package names and package version
numbers are not the same thing.  And backports already have higher
versions than stable, that's kind of the whole point.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#596120: unblock: gtksourceview2/2.10.4-1

[Josselin Mouette]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock gtksourceview2 for squeeze.

gtksourceview2 (2.10.4-1) unstable; urgency=low
 .
   * New upstream bugfix and documentation release.

The upstream changes are only bug fixes and translation updates:
 Release 2.10.4
 gtk-doc comments should be spellchecked
 Bug 618820 - Add new javascript keywords
 Added documentation for drawing leading/text/trailing whitespaces
 Added documentation for the ::move-lines signal
 Enabling silent_rules compilation.
 Fix trailing/leading space determination
 Added new C++0x types
 Add C++0x keywords. Fixes bug #618132.
 Updated Latvian translation.
 Updated Thai translation.

The diff for C files and language files is attached.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling
--- gtksourceview-2.10.3/gtksourceview/gtksourceview.c	2010-05-28 19:30:08.0 +
+++ gtksourceview-2.10.4/gtksourceview/gtksourceview.c	2010-06-20 21:05:16.0 +
@@ -542,6 +542,22 @@
 			  GTK_TYPE_TEXT_ITER,
 			  GDK_TYPE_EVENT | G_SIGNAL_TYPE_STATIC_SCOPE);
 
+	/**
+	 * GtkSourceView::move-lines:
+	 * @view: the #GtkSourceView which received the signal
+	 * @copy: %TRUE if the line should be copied,
+	 *%FALSE if it should be moved
+	 * @count: the number of lines to move over.
+	 *
+	 * The ::move-lines signal is a keybinding which gets emitted
+	 * when the user initiates moving a line. The default binding key
+	 * is Alt+Up/Down arrow. And moves the currently selected lines,
+	 * or the current line by @count. For the moment, only
+	 * @count of -1 or 1 is valid.
+	 *
+	 * Since: 2.10
+	 *
+	 */
 	signals [MOVE_LINES] =
 		g_signal_new ("move-lines",
 			  G_TYPE_FROM_CLASS (klass),
@@ -2480,7 +2496,9 @@
 	{
 		gunichar ch = gtk_text_iter_get_char (&start);
 
-		if (!g_unichar_isspace (ch) ||
+		/* NOTE: ch can be 0 when iter is at the end
+		   of the buffer */
+		if (!(g_unichar_isspace (ch) || ch == 0) ||
 		 gtk_text_iter_starts_line (&start) ||
 		!gtk_text_iter_backward_char (&start))
 		{
@@ -2496,6 +2514,7 @@
 GtkTextIter   *leading,
 GtkTextIter   *trailing)
 {
+	gint flags = 0;
 	gint location = view->priv->draw_spaces & (GTK_SOURCE_DRAW_SPACES_LEADING |
 	   GTK_SOURCE_DRAW_SPACES_TEXT |
 	   GTK_SOURCE_DRAW_SPACES_TRAILING);
@@ -2506,20 +2525,25 @@
 		return TRUE;
 	}
 
-	/* If leading > trailing we are in an empty line so we paint also
-	   for leading spaces */
 	if (gtk_text_iter_compare (iter, trailing) >= 0)
 	{
-		return location & (GTK_SOURCE_DRAW_SPACES_TRAILING |
-   GTK_SOURCE_DRAW_SPACES_LEADING);
+		flags |= GTK_SOURCE_DRAW_SPACES_TRAILING;
 	}
 
 	if (gtk_text_iter_compare (iter, leading) < 0)
 	{
-		return location & GTK_SOURCE_DRAW_SPACES_LEADING;
+		flags |= GTK_SOURCE_DRAW_SPACES_LEADING;
 	}
 
-	return location & GTK_SOURCE_DRAW_SPACES_TEXT;
+	if (flags == 0)
+	{
+		/* Neither leading nor trailing, must be in text */
+		return location & GTK_SOURCE_DRAW_SPACES_TEXT;
+	}
+	else
+	{
+		return location & flags;
+	}
 }
 static void
 draw_tabs_and_spaces (GtkSourceView  *view,
--- gtksourceview-2.10.3/gtksourceview/gtksourceview.h	2010-05-28 19:30:08.0 +
+++ gtksourceview-2.10.4/gtksourceview/gtksourceview.h	2010-06-20 21:05:16.0 +
@@ -108,9 +108,15 @@
  * @GTK_SOURCE_DRAW_SPACES_TAB: whether the tab character should be drawn.
  * @GTK_SOURCE_DRAW_SPACES_NEWLINE: whether the line breaks should be drawn.
  * @GTK_SOURCE_DRAW_SPACES_NBSP: whether the non-breaking whitespaces should be drawn.
+ * @GTK_SOURCE_DRAW_SPACES_LEADING: whether leading whitespaces should be drawn.
+ * @GTK_SOURCE_DRAW_SPACES_TEXT: whether whitespaces inside text should be drawn.
+ * @GTK_SOURCE_DRAW_SPACES_TRAILING: whether trailing whitespaces should be drawn.
  * @GTK_SOURCE_DRAW_SPACES_ALL: wheter all kind of spaces should be drawn.
  *
- * GtkSourceDrawSpacesFlags determine what kind of spaces whould be drawn.
+ * GtkSourceDrawSpacesFlags determine what kind of spaces whould be drawn. If none
+ * of GTK_SOURCE_DRAW_SPACES_LEADING, GTK_SOURCE_DRAW_SPACES_TEXT or
+ * GTK_SOURCE_DRAW_SPACES_TRAILING is specified, whitespaces at any position in
+ * the line will be drawn (i.e. it has the same effect as specifying all of them).
  */
 typedef enum
 {
--- gtksourceview-2.10.3/gtksourceview/gtksourceview-typebuiltins.h	2010-05-28 19:32:02.0 +
+++ gtksourceview-2.10.4/gtksourceview/gtksourceview-typebuiltins.h	2010-06-20 21:09:58.0 +
@@ -1,5 +1,5 @@
 
-
+/* Generated data (by glib-mkenums) */
 
 #ifndef __GTKSOURCEVIEW_TYPEBUILTINS_H__
 #define __GTKSOURCEVIEW_TYPEBUILTINS_H__ 1
@@ -40,5 +40,5 @@
 
 #endif /* __GTKSOURCEVIEW_TYPEBUILTI

Processed: 593943 still not fixed

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 593943
Bug #593943 {Done: Mehdi Dogguy } [release.debian.org] 
unblock: python-virtualenv/1.4.9-3
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
593943: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593943
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.12839706226260.transcr...@bugs.debian.org

Re: chromium not in Squeeze: a bit of communication needed?

[Michael Gilbert]

On Wed, 8 Sep 2010 20:30:21 +0200, Julien Cristau wrote:
> On Wed, Sep  8, 2010 at 14:15:26 -0400, Michael Gilbert wrote:
> 
> > As for the need for pinning, that can be solved by judiciously choosing
> > package names.  The current instructions say to append '~bpo' to all
> > packages, which makes backport versions older than stable versions.  For
> > chromium and other fast-moving packages that should stay up to date, the
> > instructions could say to use '+bpo' which would make that a newer
> > version than stable.
> > 
> > Again, it should be up to the ftpmaster to review and OK (via request)
> > all '+bpo' uploads due to the risk of breakage on automatic updates.
> > Combine this solution with disabling 'NotAutomatic', and I think all of
> > the concerns are addressed.  Thoughts?
> > 
> That makes absolutely no sense.  Package names and package version
> numbers are not the same thing.  And backports already have higher
> versions than stable, that's kind of the whole point.

Right.  It would require backport uploads to have versions something
like +bpo- for stuff that should
automatically update and ~bpo-, but
that's just messy.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908143315.0db74d6c.michael.s.gilb...@gmail.com

Bug#596122: unblock: gvfs/1.6.3-2

[Josselin Mouette]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Hi,

please unblock gvfs for squeeze, it is only a trivial RC bug fix.

gvfs (1.6.3-2) unstable; urgency=low
 .
   * Depend on fuse-utils 2.8.4. Closes: #585648.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


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

Bug#596123: unblock: libwnck/2.30.3-1

[Josselin Mouette]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Hi,

please unblock libwnck for squeeze.

libwnck (2.30.3-1) unstable; urgency=low
 .
   [ Emilio Pozuelo Monfort ]
   * debian/control.in:
 - Standards-Version is 3.9.0, no changes needed.
 .
   [ Josselin Mouette ]
   * New upstream translation and bugfix release.

The upstream changes follow:
[release] 2.30.3
 [screen] Wrap gtk-doc comments
 Add introspection annotations
 Updated the Kannada translations
 Updated Slovenian translation
 Fix failure to build outside source tree
 [pager] And really use the right version for gseal check
 Oops, use the right version check
 bgo#612490 - Use gtk_accessible_set_widget() for the GSEAL()ed field
 [release] post-release bump to 2.30.3
 [release] 2.30.2
 Revert "[build] Fix build when building out of source tree"
 [build] Do not dist gir_DATA
 [build] Fix build when building out of source tree
 Added Norwegian bokmål translation
 Updated Galician translations
 Updated Latvian translation.
 [all] More GSeal work
 updated breton translation
 updated breton translation
 updated breton translation
 updated breton translation
 updated breton translation
 Updated Shavian transliteration
 Updated Galician translations
 Updated Kannada translations
 Revert part of last commit
 Fix a few issues when building with GSEAL_ENABLED. See bug 612490.
 Fixes to Catalan translation
 Updated Basque language
 [release] post-release bump to 2.30.1

I’m attaching the diff for C files.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling
--- libwnck-2.30.0/libwnck/application.c	2009-06-30 00:41:44.0 +0200
+++ libwnck-2.30.3/libwnck/application.c	2010-08-04 13:22:28.0 +0200
@@ -208,9 +208,10 @@ wnck_application_finalize (GObject *obje
  * Gets the #WnckApplication corresponding to the group leader with @xwindow
  * as X window ID.
  *
- * Return value: the #WnckApplication corresponding to @xwindow, or %NULL if
- * there no such #WnckApplication could be found. The returned #WnckApplication
- * is owned by libwnck and must not be referenced or unreferenced.
+ * Return value: (transfer none): the #WnckApplication corresponding to
+ * @xwindow, or %NULL if there no such #WnckApplication could be found. The
+ * returned #WnckApplication is owned by libwnck and must not be referenced or
+ * unreferenced.
  */
 WnckApplication*
 wnck_application_get (gulong xwindow)
@@ -243,9 +244,9 @@ wnck_application_get_xid (WnckApplicatio
  * 
  * Gets the list of #WnckWindow belonging to @app.
  * 
- * Return value: the list of #WnckWindow belonging to @app, or %NULL if the
- * application contains no window. The list should not be modified nor freed,
- * as it is owned by @app.
+ * Return value: (element-type WnckWindow) (transfer none): the list of
+ * #WnckWindow belonging to @app, or %NULL if the application contains no
+ * window. The list should not be modified nor freed, as it is owned by @app.
  **/
 GList*
 wnck_application_get_windows (WnckApplication *app)
--- libwnck-2.30.0/libwnck/class-group.c	2009-04-19 19:40:32.0 +0200
+++ libwnck-2.30.3/libwnck/class-group.c	2010-08-04 13:22:28.0 +0200
@@ -165,10 +165,10 @@ wnck_class_group_finalize (GObject *obje
  *
  * Gets the #WnckClassGroup corresponding to @res_class.
  *
- * Return value: the #WnckClassGroup corresponding to @res_class, or %NULL if
- * there is no #WnckClassGroup with the specified @res_class. The returned
- * #WnckClassGroup is owned by libwnck and must not be referenced or
- * unreferenced.
+ * Return value: (transfer none): the #WnckClassGroup corresponding to
+ * @res_class, or %NULL if there is no #WnckClassGroup with the specified
+ * @res_class. The returned #WnckClassGroup is owned by libwnck and must not be
+ * referenced or unreferenced.
  *
  * Since: 2.2
  **/
@@ -500,9 +500,10 @@ _wnck_class_group_remove_window (WnckCla
  * 
  * Gets the list of #WnckWindow that are grouped in @class_group.
  * 
- * Return value: the list of #WnckWindow grouped in @class_group, or %NULL if
- * the group contains no window. The list should not be modified nor freed, as
- * it is owned by @class_group.
+ * Return value: (element-type WnckWindow) (transfer none): the list of
+ * #WnckWindow grouped in @class_group, or %NULL if the group contains no
+ * window. The list should not be modified nor freed, as it is owned by
+ * @class_group.
  *
  * Since: 2.2
  **/
--- libwnck-2.30.0/libwnck/pager-accessible.c	2010-02-22 20:14:20.0 +0100
+++ libwnck-2.30.3/libwnck/pager-accessible.c	2010-06-22 19:56:33.0

Processed: closing 593943

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 593943
Bug#593943: unblock: python-virtualenv/1.4.9-3
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Piotr Ożarowski 

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
593943: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593943
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.128397210816006.transcr...@bugs.debian.org

Bug#596122: unblock: gvfs/1.6.3-2

[Adam D. Barratt]

block 596122 by 590274
thanks

On Wed, 2010-09-08 at 20:32 +0200, Josselin Mouette wrote:
> please unblock gvfs for squeeze, it is only a trivial RC bug fix.
> 
> gvfs (1.6.3-2) unstable; urgency=low
>  .
>* Depend on fuse-utils 2.8.4. Closes: #585648.

While the gvfs fix is indeed trivial, fuse 2.8.4-1 is unable to migrate
due to a FTBFS on kfreebsd-* (#590274); marking this bug as blocked by
that.

Regards,

Adam



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1283972185.30713.367.ca...@kaa.jungle.aubergine.my-net-space.net

Processed: Re: Bug#596122: unblock: gvfs/1.6.3-2

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 596122 by 590274
Bug #596122 [release.debian.org] unblock: gvfs/1.6.3-2
Was not blocked by any bugs.
Added blocking bug(s) of 596122: 590274
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
596122: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596122
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.128397219616777.transcr...@bugs.debian.org

Bug#596125: unblock: mpg123/1.12.1-3

[Daniel Kobras]

Package: release.debian.org
Severity: normal

Hi!

mpg123 1.12.1-3 fixes a problem playing mp3 streams from the web, leading to
choppy or corrupted output. No Debian bug was filed, but I consider the fix
important enough to make it into the next stable release. The patch is taken
from upstream version 1.12.3, the small debdiff to the version in testing is
attached. Please unblock.

Regards,

Daniel.
diff -u mpg123-1.12.1/debian/changelog mpg123-1.12.1/debian/changelog
--- mpg123-1.12.1/debian/changelog
+++ mpg123-1.12.1/debian/changelog
@@ -1,3 +1,10 @@
+mpg123 (1.12.1-3) unstable; urgency=low
+
+  * src/libmpg123/readers.c: Fix fast reading of ICY streams via http.
+Patch from upstream version 1.12.3.
+
+ -- Daniel Kobras   Mon, 30 Aug 2010 20:05:09 +0200
+
 mpg123 (1.12.1-2) unstable; urgency=low
 
   * configure.ac, src/libmpg123/frame.c: Apply backport of upstream patch
only in patch2:
unchanged:
--- mpg123-1.12.1.orig/src/libmpg123/readers.c
+++ mpg123-1.12.1/src/libmpg123/readers.c
@@ -120,7 +120,7 @@
 			if(fr->icy.next > 0)
 			{
 cut_pos = fr->icy.next;
-ret = fr->rdat.fdread(fr,buf,cut_pos);
+ret = fr->rdat.fdread(fr,buf+cnt,cut_pos);
 if(ret < 1)
 {
 	if(ret == 0) break; /* Just EOF. */
@@ -128,7 +128,8 @@
 
 	return READER_ERROR;
 }
-fr->rdat.filepos += ret;
+
+if(!(fr->rdat.flags & READER_BUFFERED)) fr->rdat.filepos += ret;
 cnt += ret;
 fr->icy.next -= ret;
 if(fr->icy.next > 0)

Please add freeze exception for darcs-monitor

[Marco Túlio Gontijo e Silva]

Hi.

I just found a grave bug in darcs-monitor (#596127), which makes it unusable
for everyone.  It's a simple issue, the patch is attached.  I've made an upload
of the 0.3.8-2 version to sid.  Can you please unblock it?

Thanks.
-- 
marcot
http://marcot.eti.br/


darcs-monitor_0.3.8-2.patch
Description: Binary data


signature.asc
Description: PGP signature

Bug#596130: unblock: doom-wad-shareware/1.9.fixed-1

[Jon Dowland]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

Please unblock package doom-wad-shareware.

This is possibly the simplest possible Debian package: it
installs precicely one upstream file, plus the changelog
and copyright files.  Amazingly, it turns out it has been
installing the wrong upstream file for the last ten years.

The original maintainer resigned in December last year. I've
taken over maintenance and packaged the correct file.  Due
to the trivial nature of the package, the fact that the
testing version installs the wrong file, and to prevent the
former maintainer being bugged about the package for the
duration of the next release, I am requesting this unblock.

unblock doom-wad-shareware/1.9.fixed-1

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


signature.asc
Description: Digital signature

Bug#596132: nmu: ia32-libs_20090808

[Goswin von Brederlow]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

the build of ia32-libs for ia64 on the recent upload was broken and the
dependencies of the package are wrong. This was a problem of the build
environment and it should work fine on the buildds.


nmu ia32-libs_20100905 . ia64 . -m "Rebuild to fix dpkg-shlibs generated 
dependencies"


Thanks
Goswin

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100908200728.5500.27917.report...@frosties.localdomain

NEW changes in proposedupdates

[Archive Administrator]

Processing changes file: typo3-src_4.2.5-1+lenny5_i386.changes
  ACCEPT


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1otqom-0004af...@franck.debian.org

Freeze exception for the python-tornado package

[Carl Chenet]

Hi,

I'm requiring an freeze exception to get the new python-tornado package
currently in Sid into Squeeze. It would allow the "bup" package to get
rid of a embedded python-tornado library and to depend on the new
python-tornado package, which is a cleaner situation. It's not currently
possible that "bup" depends on the Squeeze python-tornado because of
version issues. 

Bye, 
-- 
Carl Chenet

Blog: http://carlchenet.wordpress.com
Identi.ca: http://identi.ca/carlchenet


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283977201.26549.120.ca...@bureau

Bug#595779: unblock: cvsd/1.0.20

[Arthur de Jong]

retitle 595779 unblock: cvsd/1.0.21
thanks

On Tue, 2010-09-07 at 23:03 +0200, Julien Cristau wrote:
> On Tue, Sep  7, 2010 at 21:50:14 +0200, Arthur de Jong wrote:
> > The daemon does a call to getaddrinfo() to figure out which addresses it
> > should listen on and tries each one. Currently at least one bind() of
> > the returned addresses should succeed, other failures are ignored.
>
> I can't see any reason for bind() failure to not be fatal...

I think when the original code was written I implemented in a similar
fashion as other daemons at the time. At least sshd currently still only
logs bind() failures and doesn't bail out. It only bails out if no
address can be bound at all (which cvsd also does).

> > Ignoring bind() failures used to be necessary when not using
> > IPV6_V6ONLY. Without it both IPv6 and IPv4 addresses were returned and
> > the bind on the IPv4 address would always fail if the IPv6 one
> > succeeded. cvsd 1.0.20 only changes which failures are ignored.
>  
> They should both succeed if done in the right order, iirc (meaning the
> order they're returned from getaddrinfo() with AI_PASSIVE).  And in any
> case they should both succeed with IPV6_V6ONLY set.

If getaddrinfo() returns an IPv6 address and an IPv4 address the bind()
for the IPv4 address will fail unless IPV6_V6ONLY is set or the
net.ipv6.bindv6only sysctl is set to 1.

Between lenny and squeeze getaddrinf() was changed to return the IPv4
address first. Without IPV6_V6ONLY and the sysctl the second bind() will
still fail.

Anyway, I've uploaded cvsd 1.0.21 to unstable that logs an error on any
bind() failure and bails out.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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

Processed: Re: Bug#595779: unblock: cvsd/1.0.20

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 595779 unblock: cvsd/1.0.21
Bug #595779 [release.debian.org] unblock: cvsd/1.0.20
Changed Bug title to 'unblock: cvsd/1.0.21' from 'unblock: cvsd/1.0.20'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
595779: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595779
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.12839781084579.transcr...@bugs.debian.org

Bug#595779: unblock: cvsd/1.0.20

[Julien Cristau]

On Wed, Sep  8, 2010 at 22:34:58 +0200, Arthur de Jong wrote:

> If getaddrinfo() returns an IPv6 address and an IPv4 address the bind()
> for the IPv4 address will fail unless IPV6_V6ONLY is set or the
> net.ipv6.bindv6only sysctl is set to 1.
> 
Argh, you're right.  I should have tested this, sorry.  Somehow I
thought the ipv6 bind() would still work if an ipv4 socket was bound to
the same port.

> Between lenny and squeeze getaddrinf() was changed to return the IPv4
> address first. Without IPV6_V6ONLY and the sysctl the second bind() will
> still fail.
> 
> Anyway, I've uploaded cvsd 1.0.21 to unstable that logs an error on any
> bind() failure and bails out.
> 
Thanks.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Freeze exception for the python-tornado package

[Adam D. Barratt]

On Wed, 2010-09-08 at 22:20 +0200, Carl Chenet wrote:
> I'm requiring an freeze exception to get the new python-tornado package
> currently in Sid into Squeeze.

Requesting, one hopes. ;-)

> It would allow the "bup" package to get
> rid of a embedded python-tornado library and to depend on the new
> python-tornado package, which is a cleaner situation.

It's also quite a large debdiff for a package which has only ever had
one other upload:

 141 files changed, 1969 insertions(+), 37871 deletions(-)

0.2 -> 1.0.1 seems a large jump to be making during freeze. :-/

Regards,

Adam


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1283980024.30713.1031.ca...@kaa.jungle.aubergine.my-net-space.net

Re: Freeze exception for the python-tornado package

[Jon Dowland]

On Wed, Sep 08, 2010 at 10:07:04PM +0100, Adam D. Barratt wrote:
> > It would allow the "bup" package to get
> > rid of a embedded python-tornado library and to depend on the new
> > python-tornado package, which is a cleaner situation.

It is my intention (bup maintainer - hello!) to request a freeze exception to
bup, pending decision on this one.  There will be a painful change to backup
format between bup-in-testing as it stands, and present day bup, which I want
to prevent exposing Debian users to. I haven't yet decided whether to request
removal of the current version of bup from testing yet.

Note that neither python-tornado nor bup existed in lenny.

> It's also quite a large debdiff for a package which has only ever had
> one other upload:
> 
>  141 files changed, 1969 insertions(+), 37871 deletions(-)
> 
> 0.2 -> 1.0.1 seems a large jump to be making during freeze. :-/

I asked debian-python whether they would be requesting a freeze exception for
python-tornado, and was told that this freeze exception was going to be 
requested:

Additionally, quoting Piotr:

> If they will not accept it, we'll most probably ask to remove python-tornado
> from Squeeze


-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908212650.gc31...@deckard.alcopop.org

Bug#596063: unblock: pacemaker-mgmt/2.0.0+hg1141-2

[Martin Zobel-Helas]

Hi, 

On Wed Sep 08, 2010 at 13:49:34 +0200, Martin Gerhard Loschwitz wrote:
> 
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: freeze-exception
> 
> Ladies and Gentlemen,
> 
> Please unblock the package pacemaker-mgmt. Right now, it is not present
> in Squeeze at all. The tool included in this package, which is called
> "hb_gui",
> used to live in the heartbeat-gui package in Lenny. Due to numerous
> changes in the package's source, it was split out of the heartbeat code and
> is a single project now. It got updated meanwhile and is in a decent shape
> now. Additionally, it is the only graphical user tool present at all in
> Debian
> at the moment to manipulate a pacemaker-based cluster's configuration.

not in testing, harder rules for unblock apply, so: NO.

Cheers,
Martin
-- 
 Martin Zobel-Helas   | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870




-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908223310.ge3...@ftbfs.de

Please unblock dojo for squeeze

[Jason Morawski]

Dear Release Managers:

I would like to request you to unblock dojo to allow 1.4.3+dfsg1-1 into
squeeze.

This package version resolves a release critical bug (#591961) that involved a
DFSG policy violation.

Thank you.


pgp7R1SPhYml5.pgp
Description: PGP signature

transitional package question

[Harald Jenny]

Dear release team,

I'm new to Debian package maintainership so please forgive me if this question
is dumb: A package I maintain (amavisd-milter) is recommend by amavisd-new
upstream as a replacement for their amavisd-new-milter program which got
removed. Talking with Debian amavisd-new maintainer we came to the conclusion
that we should provide a upgrade path for amavisd-new-milter, but the problem
is that the Debian amavisd-new maintainer already removed amavisd-new-milter
from his package and told me I would have to care for providing a transitional
package. As squeeze is already freezed I wanted to ask if this is still
possible?

Kind regards
Harald Jenny


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100909010200.gd17...@harald-has.a-little-linux-box.at

Re: chromium not in Squeeze: a bit of communication needed?

[Ansgar Burchardt]

Michael Gilbert  writes:

> This solution may be more complicated than necessary.  I just re-read
> backports' documentation.  It looks like automatic updates are prevented
> due to the use of the 'NotAutomatic' flag in the release file.  I'd be
> interested in understanding the logic for that setting and debating
> whether it could be disabled.

APT now has a wishlist bug[1] to support setting a pin of 100 from the
archive (just as the NotAutomatic flag).  This would enable updates to
be installed if the user choose to install the backported version.

Regards,
Ansgar

[1] 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwxjadou@marvin.43-1.org

Fixing issues in php-xml-serializer

[Thomas Goirand]

Hi team,

I've been trying to fix issues in php-xml-serializer. I think I managed
to fix the PHP 5.3 deprecation issue, however, after my last upload to
SID, I realized that there was still quite some issues in it, noticeably
that the package is still sending some docs in
/usr/share/php/{docs,tests}, which potentially could lead to upgrade
issues (like I just fixed for php-mail-mime in SID, for which I will ask
for another unblock).

It would have been an easy fix, if the package wasn't using CDBS that I
quite dislike. Why isn't the CDBS "magic" fixing the issue by itself?

I quite don't understand CDBS to do a good enough work. Would the
release team allow me to re-write the package using my usual debhelper
debian/rules type of thing instead of CDBS?

This question also goes to Federico Gimenez Nieto, the current
maintainer: Frederico, would you mind if your package were to debhelper
instead of CDBS from now on? I can do that work if you don't have enough
time to fix it.

Please let me know so that I can fix this issue,

Thomas


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8864cc.30...@debian.org

Gajim 0.13.4-2

[Yann Leboulanger]

Hi,

A recent RC bug has been opened against my package gajim, so I fixed it 
and a new package has been uploaded.
The difference with the one currently in squeeze is only in rules file 
and in control files. Nothing has changed in sources (same upstream 
release).


Could you include it in squeeze?

Thanks,
--
Yann


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8868d2.3080...@lagaule.org

Bug#596194: Freeze exception for ppl 0.10.2-8

[Michael Tautschnig]

Package: release.debian.org

Hi release team,

Please grant a freeze exception for ppl, version 0.10.2-8, which is now built
on all architectures. The changelog entries read as follows (also including
0.10.2-7 as that never entered testing):

ppl (0.10.2-8) unstable; urgency=low

  * Ignore testsuite failures on armel as these seem to be caused by
miscompilation, see #593324.
  * No more swi-prolog on mips, don't build PPL Prolog interface on mips.
Closes: #593393.

 -- Michael Tautschnig   Mon, 06 Sep 2010 12:31:59 +0200

ppl (0.10.2-7) unstable; urgency=low

  * Drop xpdf-utils from build depends to fix FTBFS. Closes: #591155.
  * Bumped Standars-Version to 3.9.1 (no changes).
  * Specifically require automake1.10 as we modify some Makefile.am.
  * swi-prolog now ships executable linker as swipl-ld.

 -- Michael Tautschnig   Sun, 01 Aug 2010 12:22:05 +0200

Furthermore, any version later than 0.10.2-7 also fixes #595884, which is an
FTBFS in squeeze because the swi-prolog linker has been renamed (see last
changelog entry line above).

Please let me know if you need further information.

Thanks a lot for all your work,
Michael



pgpMzxr58uXqQ.pgp
Description: PGP signature

Bug#596195: unblock: weborf/0.12.3-1

[Salvo 'LtWorf' Tomaselli]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please unblock package weborf

The upstream release fixes RC bug #596112

unblock weborf/0.12.3-1

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34.6-era (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100909062742.27923.81121.report...@localhost

Re: Fixing issues in php-xml-serializer

[Federico Gimenez Nieto]

Hi Thomas,

Thomas Goirand wrote:
> 
> This question also goes to Federico Gimenez Nieto, the current
> maintainer: Frederico, would you mind if your package were to debhelper
> instead of CDBS from now on? I can do that work if you don't have enough
> time to fix it.
> 
Feel free to make any changes if they are really needed and worth the
effort right now.

Cheers,
Federico





signature.asc
Description: OpenPGP digital signature