Bug#593435: unblock: poppler/0.12.4-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package poppler This NMU fixes a serious bug #586620 which is blocking migration of xpdf packages to testing. unblock poppler/0.12.4-1.1 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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/20100818070531.ga4...@debian.org
Re: RM: openntpd from squeeze
On Wed, Aug 18, 2010 at 02:24:04 -0300, Ulises Vitulli wrote: On 10/08/10 21:46, Julien Cristau wrote: Please file a serious bug against it documenting why it's not releasable. I'll add a remove hint. Cheers, Julien Filed, #593429. Removal hint added, thanks. Cheers, Julien signature.asc Description: Digital signature
NEW changes in proposedupdates
Processing changes file: libapache-dbi-perl_1.07-1+lenny2_amd64.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/e1oldwb-0001ld...@franck.debian.org
Re: Freeze exception: roaraudio, muroard, libao
On Tue, Aug 17, 2010 at 22:50:34 +0200, Philipp Schafft wrote: reflum, On Tue, 2010-08-17 at 13:22 +0100, Mark Brown wrote: On Mon, Aug 16, 2010 at 09:07:37PM +0200, Patrick Matth??i wrote: It is not oss-only; roaraudio just fucks up in the current code base if there is ONLY alsa available. Could you be more specific please? One of the biggest motiviations for removing OSS is to get rid of the need for the OSS compatibility bodges which cause all sorts of pain for ALSA. Patrick and I talked about this a bit more and I found a solution which makes everyone happy I hope: we remove the OSS backend completly and use the libao plugin and because of this use OSS or ALSA or whatever is selected by libao. This removes all depends on the actual soundsystem completly from the package. The package is unchanged expect a small patch updating a single line in the configuration header and one line in the Makefile. If this is ok with you we will upload by tomorrow I guess. Sounds good to me, fwiw. Cheers, Julien signature.asc Description: Digital signature
Re: Freeze exception: roaraudio, muroard, libao
On 08/17/2010 10:50 PM, Philipp Schafft wrote: If this is ok with you we will upload by tomorrow I guess. Did you see my mail about removing it from testing? 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/4c6b9964@debian.org
Re: IRC Release Team Meeting on Mon, Aug 23rd, 20 UTC
On Wed, Aug 18, 2010 at 12:29:27AM +0200, Philipp Kern wrote: Well, for upstream support there is: at the bottom of the page. According to doko sparc32 code generation is unmaintained upstream, and he doesn't want to step up to maintain it any longer. Well, that is no less of a problem than it was before, no? I don't recall seeing many sparc32 compiler bugs over the last few years. I do recall some sparc kernel bugs, which were incidentally all eventually fixed. Furthermore I found the following thread dated back to 2007: http://lists.debian.org/debian-sparc/2007/07/msg00049.html I think the only result from this was that a sparc32 kernel and installer was dropped, as Jurij said there. That was during a time when that kernel was particularly problematic, which has actually improved a lot upstream and they had no problem keeping it - though it probably still lags a bit behind because there's maybe one person regularly testing, the rest are on-and-off, but it remains in the tree and is covered by all the generic changes and testing. Few people have been affected by this, because the remaining non-64-bit machines (which can't run the 64-bit kernel) are both fairly scarce and very slow by today's standards. OTOH, if we missed the squeeze release altogether, all users of the port would be affected. Still not a whole lot of people, but at the same time, it's a huge chunk of the users of Linux on SPARC in general. We shouldn't do this for reasons that are based on what boils down to a rational fear of bit rot. It it certain that the problem can cause bugs over the years. But at this rate, a dozen bugs is pretty much a drop in the sea. So far nobody stepped up to provide us with a working sparc64 port. I know that aurel32 did some work on zee.debian.org, but was hurt by bad RAM in that box (AFAIR). That sounds like a reason why a sparc64-only port would be unreleasable, which bodes well for the actually working mixed port :) What we are currently struggling with are build failures that happen on one class of the builders, while not happening on the other, and IIRC this is happening vice-versa. Hopefully others can fill in the gaps I left here. Are these failures connected to the compiler issue, or is it just a manpower issue in tracking it down? -- 2. That which causes joy or happiness. -- 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/20100818083047.ga27...@entuzijast.net
Re: Freeze exception: eric_4.4.7-1 (missing debdiff added)
On Tue, Aug 17, 2010 at 23:28:56 +0200, Gudjon I. Gudjonsson wrote: Hi team I would like to ask if there is a possibility to make a freeze exception for eric_4.4.7-1 which is a bug fix release since version 4.4.6. The debdiff is attached. Thanks in advance Gudjon [...] diff -Nru eric-4.4.6/eric/Documentation/Source/eric4.QScintilla.QsciScintillaCompat.html eric-4.4.7/eric/Documentation/Source/eric4.QScintilla.QsciScintillaCompat.html --- eric-4.4.6/eric/Documentation/Source/eric4.QScintilla.QsciScintillaCompat.html 2010-05-22 12:52:53.0 +0200 +++ eric-4.4.7/eric/Documentation/Source/eric4.QScintilla.QsciScintillaCompat.html 2010-08-01 12:56:23.0 +0200 @@ -238,6 +244,9 @@ tda href=#QsciScintillaCompat.setCurrentIndicatorsetCurrentIndicator/a/td tdPublic method to set the current indicator./td /trtr +tda href=#QsciScintillaCompat.setCursorFlashTimesetCursorFlashTime/a/td +tdPublic method to get the flash (blink) time of the cursor in milliseconds./td +/trtr tda href=#QsciScintillaCompat.setEolModeByEolStringsetEolModeByEolString/a/td tdPublic method to set the eol mode given the eol string./td /trtr s/get/set/ here. [...] @@ -933,6 +969,20 @@ dd the indicator or style are not valid /dd +/dla NAME=QsciScintillaCompat.setCursorFlashTime ID=QsciScintillaCompat.setCursorFlashTime/a +h4QsciScintillaCompat.setCursorFlashTime/h4 +bsetCursorFlashTime/b(itime/i) +p +Public method to get the flash (blink) time of the cursor in milliseconds. +/pp +The flash time is the time required to display, invert and restore the +caret display. Usually the text cursor is displayed for half the cursor +flash time, then hidden for the same amount of time. +/pdl +dtitime/i/dt +dd +flash time of the cursor in milliseconds (integer) +/dd /dla NAME=QsciScintillaCompat.setEolModeByEolString ID=QsciScintillaCompat.setEolModeByEolString/a h4QsciScintillaCompat.setEolModeByEolString/h4 bsetEolModeByEolString/b(ieolStr/i) same here. [...] Rest looks ok. Cheers, Julien signature.asc Description: Digital signature
Re: libvirt 0.4.6-10+lenny1 stable update
Hi Adam, On Mon, Aug 02, 2010 at 04:11:28PM -0400, Adam D. Barratt wrote: Hi, On Thu, July 29, 2010 10:02, Guido Günther wrote: I'd like to upload a new version of libvirt to stable fixing two issues: * CVE-2010-2242: Apply a source port mapping to virtual network masquerading * Fix path to hvmloader. (Closes: #573808) The first fixes a minor security issue, the update is the backport of an upstream fix: So far as I can see, the fix for this hasn't been applied to the unstable packages yet? libvirt 0.8.3 is in unstable and the testing period is over. It'd didn't catch any new RC or important bugs that arent in 0.8.2 (currently in testing) already. Could you hint that package through, that would fix the following CVEs: CVE-2010-2242, CVE-2010-2237, CVE-2010-2238, CVE-2010-2239 Where fixes are applicable to both the unstable and stable packages, the preferred procedure is that the fix is applied to unstable first and then to stable if no issues are found in unstable. Stable is only affeceted by CVE-2010-2242. Cheers, -- Guido -- 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/20100818091544.ga23...@bogon.sigxcpu.org
Re: Freeze exception: roaraudio, muroard, libao
reflum, On Wed, 2010-08-18 at 10:27 +0200, Mehdi Dogguy wrote: On 08/17/2010 10:50 PM, Philipp Schafft wrote: If this is ok with you we will upload by tomorrow I guess. Did you see my mail about removing it from testing? Yes. Will answer to it soon. As I said in the original mail the devels are on holidays (some are back, but I'm not) so I takes some time discuss what we can do to help the process. Also I don't see a relation between problems in the roaraudio package and this small bug in muroard package. I just asked for both in a mail to not need to send too much mails for packages with simular names. The packages do not share code or something. also muroard is considered stable in upstream and by users. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: libvirt 0.4.6-10+lenny1 stable update
On Wed, August 18, 2010 10:15, Guido Günther wrote: Hi Adam, On Mon, Aug 02, 2010 at 04:11:28PM -0400, Adam D. Barratt wrote: [...] So far as I can see, the fix for this hasn't been applied to the unstable packages yet? libvirt 0.8.3 is in unstable and the testing period is over. It'd didn't catch any new RC or important bugs that arent in 0.8.2 (currently in testing) already. Could you hint that package through, that would fix the following CVEs: CVE-2010-2242, CVE-2010-2237, CVE-2010-2238, CVE-2010-2239 Please could you send a new mail regarding the unblock request? That will allow us to keep track of it from a freeze point of view rather than having it inside a different thread. From a very quick look at the diff, there's at least libvirt-0.8.3/src/esx/esx_driver.c| 1192 +- libvirt-0.8.3/src/esx/esx_vi.c| 911 + libvirt-0.8.3/src/util/storage_file.c | 762 - which would need more careful review. 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/eedb27489469b049e4aa0dd51b0f5902.squir...@adsl.funky-badger.org
Re: Freeze exception: roaraudio, muroard, libao
On 08/18/2010 11:53 AM, Philipp Schafft wrote: Also I don't see a relation between problems in the roaraudio package and this small bug in muroard package. I just asked for both in a mail to not need to send too much mails for packages with simular names. I just wanted to be sure that you actually saw my message. That's all. (fwiw, the removal will be only for roaraudio). The packages do not share code or something. also muroard is considered stable in upstream and by users. The popcon is 2 o_O 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/4c6baf66.5040...@debian.org
Re: misc unblocks
* Betr.: Re: misc unblocks (Sun, 15 Aug 2010 21:50:32 +0200): * Betr.: Re: misc unblocks (Sat, 14 Aug 2010 21:10:29 +0200): On 08/14/2010 08:47 PM, Adam D. Barratt wrote: tryton-client (1.6.1-1) unstable; urgency=low tryton-server (1.6.1-1) unstable; urgency=low Were there any particular changes which make these upstream versions more release-worthy than those already in testing? There are quick a few changes in the upstream repository and the changelog just says see the hg repo doesn't help identify whether any are particularly important when one doesn't know the software. they fix all sorts of tiny things and glitches, i'll let mathias (upstream and co-maintainer) comment on that in more detail. Generally the Tryton maintainers are very strict with the backport of fixes from trunk into release branches. Which means, that only 'real' bug fixes are merged into a release branch, but never features. Additionally new releases are only done on really important and well tested fixes. So generally it is always in the interest of the user to run the latest release. For the special case of release 1.6.1: Release 1.6 contained some heavy rewrites and cleanup of version 1.4. Unfortunately there was lost just one really important functionality of 1.4 in 1.6.0, which made unluckily this release almost unusable for some special implementations relying on this functionality. This essential fix (besides important others) is included in 1.6.1 and should be contained by all means in the next Debian stable release. Summary: Version 1.6.1 contains essential fixes, that should be included any case in squeeze. Sorry for pinging again, since I don't see any reaction so far and just would not want to miss anything to have tryton client and server unblocked for squeeze. Please let me know, if my mail was not explicit enough and if I can do anything to advance this issue. Thanks for your work, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://mbsolutions.selfip.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: RFC: SQLite3 in Squeeze
On Tue, Aug 17, 2010 at 07:49:49PM +0200, Laszlo Boszormenyi wrote: Hi Release Team, There's a problem with SQLite3 3.7.0 in Squeeze. The version in testing (3.6.23.1-4) was suitable to release. Next major upstream version (3.7.0) was released, which was uploaded to unstable. Then freeze happened. The latest release came with problems, like slow song change with Banshee (reported as #591298 [1]). In that bugreport I noted that v3.7.0 has a database corruption issue as well and I'm waiting for v3.7.0.1 to be released. Then I had to travel for some days. The bad thing is, that Iain Lane was so disappointed with the slow Banshee song change that he prepared an NMU of SQLite3 with a backported fix of that slowness. Julien Cristau uploaded his NMU, with high urgency. Both of them ignored the fact that there's an unfixed database corruption issue in that NMU. The bad thing is, somehow 3.7.0-1.1 migrated to Squeeze, even if it was not affected by this bug. As 3.7.0.1 was released (fixing an other performance regression and the potential database corruption), I have uploaded it to unstable and it's ready to migrate. The problem is, the performance regression hit by Banshee is still present. While it would be good to have 3.7.0.1-1 in testing, it's still not suitable to release because of the latter problem. What should I do? I don't have package version 3.6.23.1-4 anymore and I don't know when this bug will be fixed or if it will be easily backportable. FWIW, the corruption may also happen 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/20100818101524.gb5...@glandium.org
Re: initramfs-tools 0.98
On Tue, Aug 17, 2010 at 19:17:17 +0100, Adam D. Barratt wrote:
On Tue, 2010-08-17 at 16:42 +0200, maximilian attems wrote:
It contains several worthwile fixes for Squeeze and
most importantly full fills the new initramfs policy.
please unblock.
A quick question on the diff:
+# Common case: /sbin/init is present
+if [ ! -x ${rootmnt}/sbin/init ]; then
+ # ... if it's not available search for valid init
+ if [ -z ${init} ] ; then
+ for inittest in /sbin/init /etc/init /bin/init /bin/sh; do
+ if validate_init ${inittest}; then
+ init=$inittest
+ break
+ fi
+ done
+ fi
+
+ # No init on rootmount
+ if ! validate_init ${init} ; then
+ panic No init found. Try passing init= bootarg.
+ fi
fi
So far as I can see, if /sbin/init is present and executable, but $init
is set to something else, then the init which will be executed is not
checked via validate_init(). If so then should the no init on
rootmount block be moved outside of the if block?
There's this just above, though:
+# Check init bootarg
+if [ -n ${init} ]; then
+ if ! validate_init $init; then
+ echo Target filesystem doesn't have requested ${init}.
+ init=
+ fi
fi
Cheers,
Julien
signature.asc
Description: Digital signature
Re: initramfs-tools 0.98
On Wed, August 18, 2010 11:28, Julien Cristau wrote:
On Tue, Aug 17, 2010 at 19:17:17 +0100, Adam D. Barratt wrote:
A quick question on the diff:
[...]
So far as I can see, if /sbin/init is present and executable, but $init
is set to something else, then the init which will be executed is not
checked via validate_init(). If so then should the no init on
rootmount block be moved outside of the if block?
There's this just above, though:
+# Check init bootarg
+if [ -n ${init} ]; then
+ if ! validate_init $init; then
Hmmm, yes.
Unblocked.
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/0e805199ae59f7ce1da232e38954d649.squir...@adsl.funky-badger.org
Bug#592616: pu: package bgoffice/3.0-9+lenny1
On Wed, Aug 11, 2010 at 15:42:24 +0300, Yavor Doganov wrote: diff -u bgoffice-3.0/debian/rules bgoffice-3.0/debian/rules --- bgoffice-3.0/debian/rules +++ bgoffice-3.0/debian/rules @@ -102,6 +102,9 @@ # $WORDLIST is the wordlist filename minus the .*wl.gz extension) install -d debian/aspell-bg/var/lib/aspell/ debian/aspell-bg/var/lib/aspell/bg.rws +# Make sure dpkg knows about bg-en.rws too, otherwise the file is not +# deleted upon remove/purge. + debian/aspell-bg/var/lib/aspell/bg-en.rws # Add a symlink /usr/lib/aspell/$WORDLIST.rws - /var/lib/aspell/$WORDLIST.rws Shipping such a file in the package means it'll get emptied every time the package in re-installed or upgraded. That sounds wrong. Cheers, Julien signature.asc Description: Digital signature
Re: Freeze for LLVM packages
2010/8/18, Adam D. Barratt a...@adam-barratt.org.uk: As I said, my primary concern from a release point of view is whether there are good reasons for doing the changes now, rather than waiting for squeeze+1. As Matthias said, the reason is to get the good llvm version installed when users type apt-get install llvm, which is 2.7. Version 2.6 is just there for the two packages that still need it for now, and will be removed for squeeze+1. Very most users want to use 2.7 rather that 2.6. It would just make their life easier by just asking them to install llvm-dev and use unversioned binaries. Has the current configuration confused people that you know of or is this more of a of course people want to use the latest version by default? Both. This package still needs a bit of work, but not on this side. Ah, I'd assumed everything was basically ready to go and just waiting to be uploaded. How much is a bit of work? One issue I did notice is that llvm-defaults is missing a build-dependency on m4 (having tried building it in a clean(ish) chroot). The source package was given in its current state, so not ready to be uploaded yet. The bit of work remaining is quite small (partly done locally already). I will probably give you the finished version later today. Thanks, Arthur. -- 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/aanlktik7tbn7vze4mzhzs9hsbe4cujcb4edehnlaj...@mail.gmail.com
Bug#593147: marked as done (unblock: tcsh/6.17.02-3)
Your message dated Wed, 18 Aug 2010 12:49:32 +0200 with message-id 4c6bbabc.9040...@dogguy.org and subject line Re: Bug#593147: unblock: tcsh/6.17.02-3 has caused the Debian Bug report #593147, regarding unblock: tcsh/6.17.02-3 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.) -- 593147: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593147 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package tcsh. Compared to the version in testing (6.17.00-3), tcsh 6.17.02-3 has quite a lot of changes, but many of them were the result of me adopting the package and pushing many Debian bugs and patches upstream. From the changelog: * Merged patches: + 01_build.1.patch + 06_man.patch + 10_hurd.patch * Removed patches: + 02_fix.patch - no longer needed + 12_unknown_lscolors.patch - upstream says: rejected - will not apply now, I'd rather see the error and fix $LS_COLORS than eat it up silently. * Bug fixes: + Crash with autoexpand and no histchars (LP: #96490) + tcsh history file fails to save commands with ! properly (LP: #139537) + tcsh's sending of HUPs to children is broken (Closes: #314641) + tcsh doesn't support CR/LF end-of-lines in some cases, contrary to csh (Closes: #462346) + complete.tcsh bug in postmap (Closes: #552632) Version 6.17.02-1 was uploaded to experimental on 2010-05-18, because it was supposed to be an upstream prerelease that would be followed by a new real upstream release. This never happened, so I finally uploaded 6.17.02-3 to unstable. I think that 6.17.02-3 should go to testing, because: - it will be much easier to support due to the reduced number of Debian patches - it fixes quite a lot of bugs, some of them important - it already received some testing (3 months in experimental, then unstable) - users are usually quick to report tcsh bugs, as it's quite critical software for them :-) It's very likely that we can shake out all the bugs before the release. unblock tcsh/6.17.02-3 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (700, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | ---End Message--- ---BeginMessage--- On 08/15/2010 09:40 PM, Lucas Nussbaum wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package tcsh. Unblocked. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ ---End Message---
Re: Unblock request: opendnssec 1.1.1-2
On Mon, Aug 16, 2010 at 10:54:52 +0200, Ondřej Surý wrote: Could you please unblock 1.1.1-2, I have only changed packaging. Only upstream change is a patch to fix manpage (lines starting with dot). Unblocked. Cheers, Julien signature.asc Description: Digital signature
Bug#593435: marked as done (unblock: poppler/0.12.4-1.1)
Your message dated Wed, 18 Aug 2010 12:52:33 +0200 with message-id 4c6bbb71.1030...@dogguy.org and subject line Re: Bug#593435: unblock: poppler/0.12.4-1.1 has caused the Debian Bug report #593435, regarding unblock: poppler/0.12.4-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.) -- 593435: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593435 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package poppler This NMU fixes a serious bug #586620 which is blocking migration of xpdf packages to testing. unblock poppler/0.12.4-1.1 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- On 08/18/2010 09:05 AM, Osamu Aoki wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package poppler Unblocked. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ ---End Message---
Re: Bug#506809: oolite: new upstream release (1.73)
On 08/17/2010 09:36 PM, Ludovic Brenta wrote: My other questions re: the Uploaders field remain. If you have changes fixing rc bugs, then you might add this change. Otherwise, no. 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/4c6bbce3.6000...@dogguy.org
Re: Please unblock git-buildpackage 0.5.4
On Tue, Aug 17, 2010 at 08:50:46 +0200, Guido Günther wrote: Hi, please unblock the above version. It fixes a nasty bug regarding dsc imports (which didn't get reported to the bts though): * [f63c4ed] git-import-dsc: Don't add superfluous parents to imports on the Debian branch. Only set a parent on the first import per upstream version. has doc updates: * [407b614] docs: Drop git_load_dirs reference we're not using it anymore. * [dbc7fe3] docs: We don't only support .gz tarballs And minor updates: * [88afa61] git-dch: Pass --multimaint-merge on to dch (Closes: #586165) * [e8b6b49] gbp-pq: Use the maintainer of the Debian package as fallback patch author Not sure I understand why this is better than using git's default as author. * [af2a435] gbp-pull: Don't update already up to date branches Since this is a leaf package with no reverse dependencies it should be safe. Well, if people use it to prepare their package it's better if it keeps working... Quick question: --- git-buildpackage-0.5.3/gbp/gbp_version.py 1970-01-01 00:00:00.0 + +++ git-buildpackage-0.5.4/gbp/gbp_version.py 2010-08-06 20:14:08.0 + @@ -0,0 +1 @@ +gbp_version=0.5.4~1.gbp88afa6 what is this for? (is it intended?) Cheers, Julien signature.asc Description: Digital signature
Re: Please unblock git-buildpackage 0.5.4
On 08/17/2010 08:50 AM, Guido Günther wrote: Hi, please unblock the above version. In git-buildpackage-0.5.2/gbp-pq: +maintainer=$(sed -n -e 's/Maintainer: \+\(.*\)/\1/p' debian/control) +QUILT_PATCHES=$patches run_git quiltimport --author $maintainer What happens when the rest of the line is empty (maintainers listed starting from the next line) or if you have several maintainers listed on the same line. Wouldn't $DEBFULLNAME $DEBEMAIL be ok for this? 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/4c6bc010.4080...@dogguy.org
Re: libvirt 0.4.6-10+lenny1 stable update
Dear release team, please unblock libvirt 0.7.3-1. The version should have hit the archive before the freeze got delayed by a couple of days. The upload fixes: CVE-2010-2242, CVE-2010-2237, CVE-2010-2238, CVE-2010-2239 On Wed, Aug 18, 2010 at 11:01:31AM +0100, Adam D. Barratt wrote: Please could you send a new mail regarding the unblock request? That will allow us to keep track of it from a freeze point of view rather than having it inside a different thread. From a very quick look at the diff, there's at least libvirt-0.8.3/src/esx/esx_driver.c| 1192 +- libvirt-0.8.3/src/esx/esx_vi.c| 911 + libvirt-0.8.3/src/util/storage_file.c | 762 - which would need more careful review. We don't have the ESX driver currently enabled in libvirt. The file backend hat quiet some changes to fix the security issues. That's why it's actually safer to pull in this version instead of backporting for 0.8.2 given that 0.8.3 is what we aimed for in Squeeze anyway. Cheers, -- Guido -- 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/20100818105935.ga13...@bogon.sigxcpu.org
Re: wesnoth-1.8 freeze exception
On Tue, Aug 17, 2010 at 09:56:59 +0200, Gerfried Fuchs wrote:
Hi!
Please allow wesnoth-1.8 (1:1.8.3-3) to move over to squeeze. The
update now finally contains the unversioned wesnoth and wesnoth-core
packages for transitional purpose (#586291) and to ease upgrades to
later upstream versions. It also addresses the broken .desktop files
(#588712).
The diff[1] is not the tinies but it contains the development that I
was doing over the last few months and was only recently able to
finalize it.
Few questions:
diff -u wesnoth-1.8-1.8.3/debian/branchcheck
wesnoth-1.8-1.8.3/debian/branchcheck
--- wesnoth-1.8-1.8.3/debian/branchcheck
+++ wesnoth-1.8-1.8.3/debian/branchcheck
@@ -1,16 +1,18 @@
#!/bin/sh
# Copyright (C) 2009-2010 Gerfried Fuchs rho...@debian.at
-# Licenced under BSD style
+# Licenced under WTFPLv2
set -ex
BRANCH=$(dpkg-parsechangelog | grep ^Version: | cut -d -f2 | cut -d.
-f1,2 | cut -d: -f2 | cut -d- -f1 | sed -e 's/[a-z].*//')
+BRANODOT=$(echo $BRANCH | tr -d .)
if head -1 debian/control | grep -v ^Source: wesnoth-$BRANCH /dev/null ;
then \
for i in debian/*.in debian/patches/*.in; do
new=$(basename $i .in | sed -e s/BRANCH/$BRANCH/)
dir=$(dirname $i)
cp $i $dir/$new
- sed -i -e s/BRANCH/$BRANCH/g $dir/$new
+ sed -i -e s/BRANCH/$BRANCH/g $dir/$new
+ sed -i -e s/BRANODOT/$BRANCH/g $dir/$new
done
fi
$BRANODOT isn't used anywhere.
[...]
diff -u wesnoth-1.8-1.8.3/debian/control wesnoth-1.8-1.8.3/debian/control
--- wesnoth-1.8-1.8.3/debian/control
+++ wesnoth-1.8-1.8.3/debian/control
[...]
@@ -33,16 +33,30 @@
wesnoth-1.8-data (= ${source:Version})
Suggests: wesnoth
Description: fantasy turn-based strategy game (branch 1.8)
+ This package does contain the main program for wesnoth. It can be used to
play
+ multiplayer games. If you want to play campaigns you will have to install
+ them individually, but if you prefer to have all the official campaigns
+ installed please be advised to install the wesnoth-1.8 package which depends
+ on all of them.
+ .
Battle for control of villages, using variety of units which have advantages
and disadvantages in different types of terrains and against different types
of attacks. Units gain experience and advance levels, and are carried over
from one scenario to the next in a campaign.
s/does contain/contains/?
[...]
diff -u wesnoth-1.8-1.8.3/debian/rules wesnoth-1.8-1.8.3/debian/rules
--- wesnoth-1.8-1.8.3/debian/rules
+++ wesnoth-1.8-1.8.3/debian/rules
@@ -147,7 +146,7 @@
debian/wesnoth-$(BRANCH_VERSION)-data/usr/share/icons/wesnoth-$(BRANCH_VERSION)_editor-icon.png
# /usr/share/doc symlinks
- for i in wesnoth-$(BRANCH_VERSION); do \
+ for i in wesnoth-$(BRANCH_VERSION) wesnoth wesnoth-core; do \
install -p -d -m755 debian/$$i/usr/share/doc; \
ln -s wesnoth-$(BRANCH_VERSION)-data
debian/$$i/usr/share/doc/$$i; \
done
[...]
is the directory-symlink transition for wesnoth handled somewhere
(assuming stable had it as a directory)?
diff -u wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
--- wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
+++ wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
@@ -3,8 +3,8 @@
# Provides: wesnoth-1.8-server
# Required-Start:$remote_fs
# Required-Stop: $remote_fs
-# Default-Start: 2 3 4 5
-# Default-Stop: 0 1 6
+# Default-Start:
+# Default-Stop: 0 1 2 3 4 5 6
# Short-Description: Starts Wesnoth server (1.8)
# Description: Starts the Wesnoth server (1.8) used for multiplayer
games.
### END INIT INFO
is this reflected in the dh_installinit invocation (if any)?
Cheers,
Julien
signature.asc
Description: Digital signature
Re: wesnoth-1.8 freeze exception
Hi!
* Julien Cristau jcris...@debian.org [2010-08-18 13:26:28 CEST]:
On Tue, Aug 17, 2010 at 09:56:59 +0200, Gerfried Fuchs wrote:
Few questions:
diff -u wesnoth-1.8-1.8.3/debian/branchcheck
wesnoth-1.8-1.8.3/debian/branchcheck
--- wesnoth-1.8-1.8.3/debian/branchcheck
+++ wesnoth-1.8-1.8.3/debian/branchcheck
@@ -1,16 +1,18 @@
#!/bin/sh
# Copyright (C) 2009-2010 Gerfried Fuchs rho...@debian.at
-# Licenced under BSD style
+# Licenced under WTFPLv2
set -ex
BRANCH=$(dpkg-parsechangelog | grep ^Version: | cut -d -f2 | cut -d.
-f1,2 | cut -d: -f2 | cut -d- -f1 | sed -e 's/[a-z].*//')
+BRANODOT=$(echo $BRANCH | tr -d .)
if head -1 debian/control | grep -v ^Source: wesnoth-$BRANCH /dev/null
; then \
for i in debian/*.in debian/patches/*.in; do
new=$(basename $i .in | sed -e s/BRANCH/$BRANCH/)
dir=$(dirname $i)
cp $i $dir/$new
- sed -i -e s/BRANCH/$BRANCH/g $dir/$new
+ sed -i -e s/BRANCH/$BRANCH/g $dir/$new
+ sed -i -e s/BRANODOT/$BRANCH/g $dir/$new
done
fi
$BRANODOT isn't used anywhere.
It is, in the debian/wesnoth-BRANCH-core.postinst.in file from which
this helper script generates debian/wesnoth-1.8-core.postinst
#v+
update-alternatives --install /usr/games/wesnoth wesnoth \
/usr/games/wesnoth-BRANCH BRANODOT \
$slaves
#v-
Given that the branches are increasing its version constantly I chose
to use that for calculating the priority for the alternative handling.
[...]
diff -u wesnoth-1.8-1.8.3/debian/control wesnoth-1.8-1.8.3/debian/control
--- wesnoth-1.8-1.8.3/debian/control
+++ wesnoth-1.8-1.8.3/debian/control
[...]
@@ -33,16 +33,30 @@
wesnoth-1.8-data (= ${source:Version})
Suggests: wesnoth
Description: fantasy turn-based strategy game (branch 1.8)
+ This package does contain the main program for wesnoth. It can be used to
play
+ multiplayer games. If you want to play campaigns you will have to install
+ them individually, but if you prefer to have all the official campaigns
+ installed please be advised to install the wesnoth-1.8 package which
depends
+ on all of them.
+ .
Battle for control of villages, using variety of units which have
advantages
and disadvantages in different types of terrains and against different
types
of attacks. Units gain experience and advance levels, and are carried
over
from one scenario to the next in a campaign.
s/does contain/contains/?
Right, thanks, will improve that in a later upload, I wouldn't though
see this as something for which I solely would want to do another upload
round.
# /usr/share/doc symlinks
- for i in wesnoth-$(BRANCH_VERSION); do \
+ for i in wesnoth-$(BRANCH_VERSION) wesnoth wesnoth-core; do \
install -p -d -m755 debian/$$i/usr/share/doc; \
ln -s wesnoth-$(BRANCH_VERSION)-data
debian/$$i/usr/share/doc/$$i; \
done
[...]
is the directory-symlink transition for wesnoth handled somewhere
(assuming stable had it as a directory)?
Doh, right, this is an issue I usually forget. You are right, I'll
produce a postinst snippet like I have in other packages already. Thanks
for catching that!
diff -u wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
--- wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
+++ wesnoth-1.8-1.8.3/debian/wesnoth-1.8-server.init.d
@@ -3,8 +3,8 @@
# Provides: wesnoth-1.8-server
# Required-Start:$remote_fs
# Required-Stop: $remote_fs
-# Default-Start: 2 3 4 5
-# Default-Stop: 0 1 6
+# Default-Start:
+# Default-Stop: 0 1 2 3 4 5 6
# Short-Description: Starts Wesnoth server (1.8)
# Description: Starts the Wesnoth server (1.8) used for multiplayer
games.
### END INIT INFO
is this reflected in the dh_installinit invocation (if any)?
Yes, it is. Actually it was in there before already, I just hadn't
adjusted the header yet.
I have two or three more things pending that I'd like to push in with
the next update fixing the package description improvement and fixing
the symlink doc dir transition:
-) The wesnoth server package should ship an default file for the
init.d script with documentation. It will only contain comments so I
don't see an objection here.
-) Adding a debian/NEWS entry about the transition and how people are
able to keep their old wesnoth version side-by-side with this update to
be able to continue to play their already started campaigns.
-) And this is the thing I would like to see your comments about:
Upstream released a 1.8.4 version within the last week. The even minor
numbers are their stable releases and they are pretty strict about what
they allow into them, they are bound to be compatible
Re: Freeze for LLVM packages
On Wed, August 18, 2010 11:50, Arthur Loiret wrote:
2010/8/18, Adam D. Barratt a...@adam-barratt.org.uk:
As I said, my primary concern from a release point of view is whether
there are good reasons for doing the changes now, rather than waiting
for squeeze+1.
As Matthias said, the reason is to get the good llvm version installed
when users type apt-get install llvm, which is 2.7. Version 2.6 is
just there for the two packages that still need it for now, and will
be removed for squeeze+1.
Matthias also mentioned trying to remove 2.6 for Squeeze, which is rather
less likely.
So far as I can see, the current split of 2.6 vs 2.7 using packages in the
archive is
2.6 - ldc, llvm-py, llvm-gcc-4.2 (i386)
2.7 - clang, haskell-llvm, llvm-gcc-4.2 (amd64), openjdk-6
Which of those packages will not work with 2.7? Of the remainder which,
if any, are you proposing changing the {build-,}dependencies of? Any
depending on llvm (= 2.6) which will also work with 2.7 shouldn't
require changes and there's certainly an argument that for squeeze uploads
which simply changed the llvm-2.7 dependencies to be llvm (= 2.7)
wouldn't qualify for exceptions on their own.
llvm-gcc-4.2 also has a new upstream version in unstable which was
uploaded after the freeze and does not have an exception (and ftbfs on
i386), which doesn't help.
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/feb26b55b4d4c2e70d105ec86c47452d.squir...@adsl.funky-badger.org
Bug#592300: future unblock: xz-utils/4.999.9beta+20100810-1
On Wed, August 11, 2010 03:29, Jonathan Nieder wrote: Jonathan Nieder wrote: Diffstat follows, diff attached. Oops, forgot to attach. Here is the debdiff. I see that this has been uploaded already. It would have been appreciated if you'd pinged us about the lack of response rather than assuming that it was equivalent to a go-ahead for upload. In any case, please get back to us once the package has reached its 10 days. 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/130e63b3469284ba2b5600415a7a0806.squir...@adsl.funky-badger.org
Bug#592300: future unblock: xz-utils/4.999.9beta+20100810-1
Adam D. Barratt wrote: I see that this has been uploaded already. It would have been appreciated if you'd pinged us about the lack of response rather than assuming that it was equivalent to a go-ahead for upload. Ah, sorry. My thought process was that (1) it is better to get more testing in sid than less and (2) if you consider the changes too invasive it is possible to make another upload to scale them back. So your input is still welcome. In any case, please get back to us once the package has reached its 10 days. Will do. 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/20100818121653.ga25...@burratino
Re: Freeze exception: manpages-fr
On 08/17/2010 09:20 PM, Nicolas François wrote: Dear release team, I'd like to ask for a freeze exception regarding the manpages-fr package, which produces two arch all binary packages containing manpages. Can I trade this unblock with an upload of src:shadow? :) It has 3 RC bugs tagged as pending since months. Here are the changelog entries for this new version: [...] Looks ok for me. 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/4c6bd112.2070...@dogguy.org
Re: Please unblock git-buildpackage 0.5.4
On Wed, Aug 18, 2010 at 01:12:16PM +0200, Mehdi Dogguy wrote: On 08/17/2010 08:50 AM, Guido Günther wrote: Hi, please unblock the above version. In git-buildpackage-0.5.2/gbp-pq: +maintainer=$(sed -n -e 's/Maintainer: \+\(.*\)/\1/p' debian/control) +QUILT_PATCHES=$patches run_git quiltimport --author $maintainer What happens when the rest of the line is empty (maintainers listed starting from the next line) or if you have several maintainers listed on the same line. Wouldn't $DEBFULLNAME $DEBEMAIL be ok for this? Can we have several maintainers? I thought we only allow for several uploaders? I see the point about the next line though. Cheers, -- Guido -- 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/20100818125515.ga14...@bogon.sigxcpu.org
Re: Please unblock git-buildpackage 0.5.4
On Wed, Aug 18, 2010 at 12:08:53PM +0100, Julien Cristau wrote: On Tue, Aug 17, 2010 at 08:50:46 +0200, Guido Günther wrote: Hi, please unblock the above version. It fixes a nasty bug regarding dsc imports (which didn't get reported to the bts though): * [f63c4ed] git-import-dsc: Don't add superfluous parents to imports on the Debian branch. Only set a parent on the first import per upstream version. has doc updates: * [407b614] docs: Drop git_load_dirs reference we're not using it anymore. * [dbc7fe3] docs: We don't only support .gz tarballs And minor updates: * [88afa61] git-dch: Pass --multimaint-merge on to dch (Closes: #586165) * [e8b6b49] gbp-pq: Use the maintainer of the Debian package as fallback patch author Not sure I understand why this is better than using git's default as author. Note that this is only for patches that don't carry any header information in the patch header - which is often that case if patches aren't generated from git. In this case git-quiltimport would ask for the patch author, that's why we default to the maintainer. In case we can't determine the maintainer (like in the case Mehdi pointed out) we fall back to prompting. Once the patches got imported they cary correct author information and the passed information is ignored by git-quiltimport. * [af2a435] gbp-pull: Don't update already up to date branches Since this is a leaf package with no reverse dependencies it should be safe. Well, if people use it to prepare their package it's better if it keeps working... Quick question: --- git-buildpackage-0.5.3/gbp/gbp_version.py 1970-01-01 00:00:00.0 + +++ git-buildpackage-0.5.4/gbp/gbp_version.py 2010-08-06 20:14:08.0 + @@ -0,0 +1 @@ +gbp_version=0.5.4~1.gbp88afa6 what is this for? (is it intended?) The file is autogenerated, so it doesn't matter. -- Guido -- 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/20100818130545.ga14...@bogon.sigxcpu.org
Bug#592721: unblock: embassy-* and emboss.
On 08/12/2010 12:40 PM, Charles Plessy wrote: Possible solutions are: - Remove the embassy-* packages, - Upload emboss 6.2 from the snapshots to testing-proposed-updates, - unblock the emboss and embassy packages from Sid. I'm ok with the last solution (mainly because emboss was granted a freeze exception for 6.3.1-3. The diff was easier to study from that point). Nevertheless, there is an issue with embassy-phylip: embassy-phylip | 3.69-1 | testing/non-free | source, amd64, ia64, mips, mipsel, s390, sparc embassy-phylip | 3.69-1 | unstable/non-free | source, ia64, mips, mipsel, s390, sparc embassy-phylip | 3.69+20100721-1 | unstable/non-free | source, amd64 I guess it was built by mistake for 3.69-1 and wasn't for 3.69+20100721-1. It has to be whitelisted to be able to build there. Did you ask for that? Otherwise, you can request for their removal or ask us to remove it from testing : 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/4c6bde36@dogguy.org
Re: Please unblock git-buildpackage 0.5.4
On 08/18/2010 02:55 PM, Guido Günther wrote: On Wed, Aug 18, 2010 at 01:12:16PM +0200, Mehdi Dogguy wrote: On 08/17/2010 08:50 AM, Guido Günther wrote: Hi, please unblock the above version. In git-buildpackage-0.5.2/gbp-pq: +maintainer=$(sed -n -e 's/Maintainer: \+\(.*\)/\1/p' debian/control) + QUILT_PATCHES=$patches run_git quiltimport --author $maintainer What happens when the rest of the line is empty (maintainers listed starting from the next line) or if you have several maintainers listed on the same line. Wouldn't $DEBFULLNAME $DEBEMAIL be ok for this? Can we have several maintainers? I thought we only allow for several uploaders? You're right. I made an assumption without even thinking about this special case. Unblocked. Cheers, -- 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/4c6bdfb8.2090...@dogguy.org
Re: Please unblock git-buildpackage 0.5.4
On Wed, Aug 18, 2010 at 15:05:45 +0200, Guido Günther wrote: On Wed, Aug 18, 2010 at 12:08:53PM +0100, Julien Cristau wrote: On Tue, Aug 17, 2010 at 08:50:46 +0200, Guido Günther wrote: * [e8b6b49] gbp-pq: Use the maintainer of the Debian package as fallback patch author Not sure I understand why this is better than using git's default as author. Note that this is only for patches that don't carry any header information in the patch header - which is often that case if patches aren't generated from git. In this case git-quiltimport would ask for the patch author, that's why we default to the maintainer. In case we can't determine the maintainer (like in the case Mehdi pointed out) we fall back to prompting. Once the patches got imported they cary correct author information and the passed information is ignored by git-quiltimport. Fair enough. * [af2a435] gbp-pull: Don't update already up to date branches Since this is a leaf package with no reverse dependencies it should be safe. Well, if people use it to prepare their package it's better if it keeps working... Quick question: --- git-buildpackage-0.5.3/gbp/gbp_version.py 1970-01-01 00:00:00.0 + +++ git-buildpackage-0.5.4/gbp/gbp_version.py 2010-08-06 20:14:08.0 + @@ -0,0 +1 @@ +gbp_version=0.5.4~1.gbp88afa6 what is this for? (is it intended?) The file is autogenerated, so it doesn't matter. Then presumably it shouldn't be in the source package? Cheers, Julien signature.asc Description: Digital signature
Re: Please unblock git-buildpackage 0.5.4
On Wed, Aug 18, 2010 at 02:55:15PM +0200, Guido Günther wrote: On Wed, Aug 18, 2010 at 01:12:16PM +0200, Mehdi Dogguy wrote: On 08/17/2010 08:50 AM, Guido Günther wrote: Hi, please unblock the above version. In git-buildpackage-0.5.2/gbp-pq: +maintainer=$(sed -n -e 's/Maintainer: \+\(.*\)/\1/p' debian/control) +QUILT_PATCHES=$patches run_git quiltimport --author $maintainer What happens when the rest of the line is empty (maintainers listed starting from the next line) or if you have several maintainers listed on the same line. Wouldn't $DEBFULLNAME $DEBEMAIL be ok for this? Can we have several maintainers? I thought we only allow for several uploaders? I see the point about the next line though. Just checked policy. Section 5.6.2 looks to me as if there can only be a single maintainer. As for the line break: in this case gbp-pq would fall back to prompting as be before so unblocking should be o.k. Cheers, -- Guido -- 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/20100818131639.ga15...@bogon.sigxcpu.org
Re: wesnoth-1.8 freeze exception
On Wed, Aug 18, 2010 at 13:48:50 +0200, Gerfried Fuchs wrote: Hi! * Julien Cristau jcris...@debian.org [2010-08-18 13:26:28 CEST]: On Tue, Aug 17, 2010 at 09:56:59 +0200, Gerfried Fuchs wrote: Few questions: diff -u wesnoth-1.8-1.8.3/debian/branchcheck wesnoth-1.8-1.8.3/debian/branchcheck --- wesnoth-1.8-1.8.3/debian/branchcheck +++ wesnoth-1.8-1.8.3/debian/branchcheck @@ -1,16 +1,18 @@ #!/bin/sh # Copyright (C) 2009-2010 Gerfried Fuchs rho...@debian.at -# Licenced under BSD style +# Licenced under WTFPLv2 set -ex BRANCH=$(dpkg-parsechangelog | grep ^Version: | cut -d -f2 | cut -d. -f1,2 | cut -d: -f2 | cut -d- -f1 | sed -e 's/[a-z].*//') +BRANODOT=$(echo $BRANCH | tr -d .) if head -1 debian/control | grep -v ^Source: wesnoth-$BRANCH /dev/null ; then \ for i in debian/*.in debian/patches/*.in; do new=$(basename $i .in | sed -e s/BRANCH/$BRANCH/) dir=$(dirname $i) cp $i $dir/$new - sed -i -e s/BRANCH/$BRANCH/g $dir/$new + sed -i -e s/BRANCH/$BRANCH/g $dir/$new + sed -i -e s/BRANODOT/$BRANCH/g $dir/$new done fi $BRANODOT isn't used anywhere. It is, in the debian/wesnoth-BRANCH-core.postinst.in file from which this helper script generates debian/wesnoth-1.8-core.postinst #v+ update-alternatives --install /usr/games/wesnoth wesnoth \ /usr/games/wesnoth-BRANCH BRANODOT \ $slaves #v- Given that the branches are increasing its version constantly I chose to use that for calculating the priority for the alternative handling. But this script replaces BRANODOT with $BRANCH, not $BRANODOT. [...] I have two or three more things pending that I'd like to push in with the next update fixing the package description improvement and fixing the symlink doc dir transition: -) The wesnoth server package should ship an default file for the init.d script with documentation. It will only contain comments so I don't see an objection here. -) Adding a debian/NEWS entry about the transition and how people are able to keep their old wesnoth version side-by-side with this update to be able to continue to play their already started campaigns. Sounds ok. -) And this is the thing I would like to see your comments about: Upstream released a 1.8.4 version within the last week. The even minor numbers are their stable releases and they are pretty strict about what they allow into them, they are bound to be compatible with their other stable releases from the branch - and thus they only contain bugfixes and (mostly) translation updates. I wonder if you would be willing to accept that update into squeezes and wether I should base above mentioned changes on that new upstream bugfix release or wether you would want me to base them on the 1.8.3 version and consider 1.8.4 at a later time. Can we first get 1.8.3 in testing, and then look at 1.8.4? Cheers, Julien signature.asc Description: Digital signature
Bug#592616: pu: package bgoffice/3.0-9+lenny1
On Wed, Aug 18, 2010 at 16:30:56 +0300, Yavor Doganov wrote: On Wed, Aug 18, 2010 at 11:44:58AM +0100, Julien Cristau wrote: On Wed, Aug 11, 2010 at 15:42:24 +0300, Yavor Doganov wrote: +# Make sure dpkg knows about bg-en.rws too, otherwise the file is not +# deleted upon remove/purge. + debian/aspell-bg/var/lib/aspell/bg-en.rws Shipping such a file in the package means it'll get emptied every time the package in re-installed or upgraded. That sounds wrong. Yes, but I don't know why you think it's wrong. These files are supposed to be regenerated in postinst by update-dictcommon-aspell; that's a feature. AFAIK all other aspell packages work in a similar way. Here, bg-en.rws should be treated exactly as bg.rws. Then why is it shipped in the package? Is it just so that dpkg removes it automatically? Cheers, Julien signature.asc Description: Digital signature
Re: wesnoth-1.8 freeze exception
Hi! * Julien Cristau jcris...@debian.org [2010-08-18 15:37:27 CEST]: On Wed, Aug 18, 2010 at 13:48:50 +0200, Gerfried Fuchs wrote: * Julien Cristau jcris...@debian.org [2010-08-18 13:26:28 CEST]: On Tue, Aug 17, 2010 at 09:56:59 +0200, Gerfried Fuchs wrote: Few questions: $BRANODOT isn't used anywhere. It is, in the debian/wesnoth-BRANCH-core.postinst.in file from which this helper script generates debian/wesnoth-1.8-core.postinst #v+ update-alternatives --install /usr/games/wesnoth wesnoth \ /usr/games/wesnoth-BRANCH BRANODOT \ $slaves #v- Given that the branches are increasing its version constantly I chose to use that for calculating the priority for the alternative handling. But this script replaces BRANODOT with $BRANCH, not $BRANODOT. Second DOH, you're right, that's clearly a bug in the script. Though, the file in the source does contain the correct value and the script isn't called automatically (and wouldn't do anything when called in the source right now anyway because the branch version is still the same) - it wouldn't affect the release right now. :) [...] I have two or three more things pending that I'd like to push in with the next update fixing the package description improvement and fixing the symlink doc dir transition: -) The wesnoth server package should ship an default file for the init.d script with documentation. It will only contain comments so I don't see an objection here. -) Adding a debian/NEWS entry about the transition and how people are able to keep their old wesnoth version side-by-side with this update to be able to continue to play their already started campaigns. Sounds ok. Thanks. -) And this is the thing I would like to see your comments about: Upstream released a 1.8.4 version within the last week. The even minor numbers are their stable releases and they are pretty strict about what they allow into them, they are bound to be compatible with their other stable releases from the branch - and thus they only contain bugfixes and (mostly) translation updates. I wonder if you would be willing to accept that update into squeezes and wether I should base above mentioned changes on that new upstream bugfix release or wether you would want me to base them on the 1.8.3 version and consider 1.8.4 at a later time. Can we first get 1.8.3 in testing, and then look at 1.8.4? Sure, definitely - thanks for responding quickly, I'll address your concerns and get them fixed by hopefully tomorrow, will knock again then. Thanks for your outstanding proofreading (and sorry for the need for it), it's truly appreciated! Enjoy! Rhonda -- Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder Mensch auch ein Privatleben haben sollte. -- http://www.karriere.at/artikel/884/ -- 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/20100818134216.ga11...@anguilla.debian.or.at
Re: libgc + the ecl situation
Julien Cristau jcris...@debian.org writes: On Mon, Aug 16, 2010 at 22:06:08 +0200, Christoph Egger wrote: Hi all! The ecl package currently is still affected by [0] -- RC bug caused by a build failure / embedded copy of libgc. The upload to experimental, where a new enough libgc is already available did improve definitely. As I'm going to adopt libgc (do we want it in pkg-common-lisp btw?) I could have put that into unstable if the freeze didn't happen. The libgc update shouldn't change the API but there are rather some reverse-depends so I'm not sure the release team is happy to see that update still. Alternative would probably be to patch the included libgc. I don't think updating libgc to a new major release in squeeze is a viable option at this point. OK that's what I've suspected, thanks for confirming. I'll try to work out another solution then (hopefully soon). Regards Christoph -- 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/87iq38xd5s@chillida.ipv6.sieglitzhof.net
Re: Freeze exception: cron 3.0pl1-114
On 08/16/2010 12:21 PM, Christian Kastner wrote: Hello, I'd like to ask for a freeze exception for cron 3.0pl1-114. 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/4c6be3b7.1080...@dogguy.org
Bug#592616: pu: package bgoffice/3.0-9+lenny1
On Wed, Aug 18, 2010 at 11:44:58AM +0100, Julien Cristau wrote: On Wed, Aug 11, 2010 at 15:42:24 +0300, Yavor Doganov wrote: +# Make sure dpkg knows about bg-en.rws too, otherwise the file is not +# deleted upon remove/purge. + debian/aspell-bg/var/lib/aspell/bg-en.rws Shipping such a file in the package means it'll get emptied every time the package in re-installed or upgraded. That sounds wrong. Yes, but I don't know why you think it's wrong. These files are supposed to be regenerated in postinst by update-dictcommon-aspell; that's a feature. AFAIK all other aspell packages work in a similar way. Here, bg-en.rws should be treated exactly as bg.rws. -- 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/20100818133056.ga23...@yavor.doganov.org
Re: Please unblock git-buildpackage 0.5.4
On Wed, Aug 18, 2010 at 02:31:02PM +0100, Julien Cristau wrote: On Wed, Aug 18, 2010 at 15:05:45 +0200, Guido Günther wrote: On Wed, Aug 18, 2010 at 12:08:53PM +0100, Julien Cristau wrote: On Tue, Aug 17, 2010 at 08:50:46 +0200, Guido Günther wrote: * [e8b6b49] gbp-pq: Use the maintainer of the Debian package as fallback patch author Not sure I understand why this is better than using git's default as author. Note that this is only for patches that don't carry any header information in the patch header - which is often that case if patches aren't generated from git. In this case git-quiltimport would ask for the patch author, that's why we default to the maintainer. In case we can't determine the maintainer (like in the case Mehdi pointed out) we fall back to prompting. Once the patches got imported they cary correct author information and the passed information is ignored by git-quiltimport. Fair enough. * [af2a435] gbp-pull: Don't update already up to date branches Since this is a leaf package with no reverse dependencies it should be safe. Well, if people use it to prepare their package it's better if it keeps working... Quick question: --- git-buildpackage-0.5.3/gbp/gbp_version.py 1970-01-01 00:00:00.0 + +++ git-buildpackage-0.5.4/gbp/gbp_version.py 2010-08-06 20:14:08.0 + @@ -0,0 +1 @@ +gbp_version=0.5.4~1.gbp88afa6 what is this for? (is it intended?) The file is autogenerated, so it doesn't matter. Then presumably it shouldn't be in the source package? Yes. I'll remove this in further uploads. Thanks for pointing this out. -- Guido -- 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/20100818133526.ga15...@bogon.sigxcpu.org
Re: Bug#592616: pu: package bgoffice/3.0-9+lenny1
Julien Cristau writes: On Wed, Aug 18, 2010 at 16:30:56 +0300, Yavor Doganov wrote: On Wed, Aug 18, 2010 at 11:44:58AM +0100, Julien Cristau wrote: On Wed, Aug 11, 2010 at 15:42:24 +0300, Yavor Doganov wrote: +# Make sure dpkg knows about bg-en.rws too, otherwise the file is not +# deleted upon remove/purge. + debian/aspell-bg/var/lib/aspell/bg-en.rws Shipping such a file in the package means it'll get emptied every time the package in re-installed or upgraded. That sounds wrong. Yes, but I don't know why you think it's wrong. These files are supposed to be regenerated in postinst by update-dictcommon-aspell; that's a feature. AFAIK all other aspell packages work in a similar way. Here, bg-en.rws should be treated exactly as bg.rws. Then why is it shipped in the package? Is it just so that dpkg removes it automatically? I agree, that 'automatically removed by dpkg' games are best to be avoided for regenerated files, and it is saner to remove them in the postrm, since now debsums aspell-bg lists these three regenerated files as FAILED, which is to be expected. I failed to catch that, so sorry for the noise and thank you for the sharp eye on it. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- 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/201008181720.39047.danc...@spnet.net
Bug#592616: pu: package bgoffice/3.0-9+lenny1
On Wed, Aug 18, 2010 at 02:39:04PM +0100, Julien Cristau wrote: On Wed, Aug 18, 2010 at 16:30:56 +0300, Yavor Doganov wrote: These files are supposed to be regenerated in postinst by update-dictcommon-aspell; that's a feature. Then why is it shipped in the package? Is it just so that dpkg removes it automatically? That's the sole reason, yes. From aspell-autobuildhash(8): | Dictionaries-common scripts will call internally this script and | create a single hash file at /var/lib/ispell/$lang.rws, or hash files | at /var/lib/ispell/$subdict.rws. You must set a symlink to that files | from /usr/lib/aspell/$lang.rws or /usr/lib/aspell/$subdict.rws as | appropriate. You are also suggested to create empty files at | /var/lib/aspell/$lang.rws or for all of the | /var/lib/aspell/$subdict.rws in the install target of your package | build process. This empty file will be overwritten when the real hash | is created, but will make the hash be removed at package removal | without any magic being done in the postrm and will also help to keep | track about which package owns that file. -- 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/20100818140122.ga23...@yavor.doganov.org
Please unblock wl-beta 2.15.9+0.20100801-2
Hi the release team, Please unblock wl-beta, I have uploaded 2.15.9+0.20100801-2 which fixes an important bug #593396. wl-beta (2.15.9+0.20100801-2) unstable; urgency=medium . * debian/patches/30_elmo-folder-open.patch: Fix that elmo database gets out of sync, patch from upstream. (closes: #593396) Thanks, -- Tatsuya Kinoshita pgpoEjdHZWuD5.pgp Description: PGP signature
Please unblock eblook 1:1.6.1-9
Hi the release team,
eblook (1:1.6.1-8) unstable; urgency=medium
* debian/patches/30_codeconv-size.patch: Patch to fix codeconv problems
(size_t vs int, etc.), from the upstream mailing list [edict 2711], on
2010-08-15, provided by Kazuhiro Ito. (closes: #593006)
A similar problem has been fixed. Please unblock eblook 1:1.6.1-9
for squeeze to fix the important bug #593476.
eblook (1:1.6.1-9) unstable; urgency=medium
.
* debian/patches/40_eb-read-ssize.patch: Patch to fix incompatible pointer
type ('ssize_t *' vs 'int *') for eb_read_* functions. (closes: #593476)
Thanks,
--
Tatsuya Kinoshita
pgpDMvSoBReEt.pgp
Description: PGP signature
Re: RFC: SQLite3 in Squeeze
On Tue, Aug 17, 2010 at 19:49:49 +0200, Laszlo Boszormenyi wrote: While it would be good to have 3.7.0.1-1 in testing, it's still not suitable to release because of the latter problem. What should I do? I don't have package version 3.6.23.1-4 anymore and I don't know when this bug will be fixed or if it will be easily backportable. Sounds like we should go back to 3.6.x in testing and sid. Cheers, Julien signature.asc Description: Digital signature
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Mon, Aug 16, 2010 at 12:36:34PM +0200, Matthias Klose wrote: On 11.08.2010 23:16, Neil McGovern wrote: Hi Matthias, Sorry for not getting back to you sooner. On Sat, Aug 07, 2010 at 11:42:42PM +0200, Matthias Klose wrote: gcc-4.5 should be released with squeeze, at least on amd64 and i386. gcc-4.5.1 was released a week ago, the first bug and regression fix release after the initial gcc-4.5.0 release. Do you have any information as to why this is needed for squeeze, as opposed to squeeze+1? Would this be a nice-to-have, or does it solve a specific problem? it's more than nice-to-have. See the reasons in my original posting (which you didn't include here in the reply). I'm not sure there are any in the original, plugins and a greater optimisation level certainly aren't things which will solve specific problems. Could you highlight them for me? - gcc-4.5 will be an optional compiler, not replacing the current defaults. Ok, but if it can be used, it probably will be by at least some things. correct. but it should not introduce rc issues; if it does, then fall back to 4.4, or don't use 4.5 in the first place. Unless things FTBFS on some arches and not others, and thus cause delays in the freeze. If port maintainers do want to enable gcc-4.5 on a port, they should make sure that no regressions are introduced by building the runtime libraries from 4.5 and ensure that possible regressions are fixed. This is the bit that worries me. Although it is optional, it can (and IMO will probably) be used by at least some things. This could lead to odd bugs. If there's a problem in GCC 4.5 that isn't in 4.4, and it comes to a security upload, there could be a mismatch between the requirements. sorry, I don't understand this reasoning and the implications for security uploads. If a package is explicitely built with 4.5, it will be built with 4.5 for security uploads too. Ok, assume that gcc4.5 has some major bug that causes FTBFSes in certain circumstances, and a package has been modified in a way to take advantage of gcc4.5, specifically so it won't build with 4.4; then a problem would occur. Do you have details as to the (previously mentioned) unit/regression tests? not besides the test results included in the packages prepared for upload. Is there anything more you would expect? You mentioned: - the upload will build several runtime libraries from the 4.5 sources. Regression tests did pass for the runtime libs built from the 4.5 sources and for 4.4 using the runtime libs from 4.5. At the moment, I'm still not sure on the actual advantage of introducing this new package at this stage in the release cycle. Neil -- * stockholm bangs head against budget h01ger outsch stockholm h01ger: it is still very soft, i did not hurt myself gwolf stockholm: But you bled on the budget, and now it's red again! -- 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/20100818143615.gn7...@halon.org.uk
Re: Please unblock eblook 1:1.6.1-9
On 08/18/2010 04:28 PM, Tatsuya Kinoshita wrote: Hi the release team, eblook (1:1.6.1-8) unstable; urgency=medium * debian/patches/30_codeconv-size.patch: Patch to fix codeconv problems (size_t vs int, etc.), from the upstream mailing list [edict 2711], on 2010-08-15, provided by Kazuhiro Ito. (closes: #593006) A similar problem has been fixed. Please unblock eblook 1:1.6.1-9 for squeeze to fix the important bug #593476. Done. -- 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/4c6befcd.9040...@dogguy.org
Re: Bug#592616: pu: package bgoffice/3.0-9+lenny1
Yavor Doganov writes: On Wed, Aug 18, 2010 at 02:39:04PM +0100, Julien Cristau wrote: On Wed, Aug 18, 2010 at 16:30:56 +0300, Yavor Doganov wrote: These files are supposed to be regenerated in postinst by update-dictcommon-aspell; that's a feature. Then why is it shipped in the package? Is it just so that dpkg removes it automatically? That's the sole reason, yes. From aspell-autobuildhash(8): | Dictionaries-common scripts will call internally this script and | create a single hash file at /var/lib/ispell/$lang.rws, or hash files | at /var/lib/ispell/$subdict.rws. You must set a symlink to that files | from /usr/lib/aspell/$lang.rws or /usr/lib/aspell/$subdict.rws as | appropriate. You are also suggested to create empty files at | /var/lib/aspell/$lang.rws or for all of the | /var/lib/aspell/$subdict.rws in the install target of your package | build process. This empty file will be overwritten when the real hash | is created, but will make the hash be removed at package removal | without any magic being done in the postrm and will also help to keep | track about which package owns that file. long forgotten... and it seems to me that we have 'double head': good practices vs. what is suggested/implemented/recommended in aspell- autobuildhash(8). I only mourn for hashsums (debsums) being different after regeneration! So, should we proceed with that package the way it is? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- 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/201008181739.57611.danc...@spnet.net
Re: RFC: SQLite3 in Squeeze
On 08/18/2010 04:34 PM, Julien Cristau wrote: Sounds like we should go back to 3.6.x in testing and sid. If we go that way, we will have to rebuild some packages [1] (red ones). [1] http://release.debian.org/transitions/Sqlite3.html 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/4c6bf3cd.9010...@dogguy.org
Re: Bug#592616: pu: package bgoffice/3.0-9+lenny1
On Wed, Aug 18, 2010 at 17:39:57 +0300, George Danchev wrote: So, should we proceed with that package the way it is? I'd rather you didn't introduce that bug in stable (I'm no SRM though). Cheers, Julien signature.asc Description: Digital signature
Bug#592616: pu: package bgoffice/3.0-9+lenny1
Yavor Doganov writes: Георги Данчев wrote: I agree, that 'automatically removed by dpkg' games are best to be avoided for regenerated files, and it is saner to remove them in the postrm, since now debsums aspell-bg lists these three regenerated files as FAILED, which is to be expected. I failed to catch that, so sorry for the noise and thank you for the sharp eye on it. I disagree, it is me who failed to catch that and forgot to pass -Xvar/lib/aspell to dh_md5sums while preparing -11. Good. Sounds like a deal to. It should be nest if changelogs always document 'weirdness' ;-) Julien, that should unweird the thing somehow as the mortal users won't see files with unmatching hashsums. Do you agree that we fix that in -12 with what Yavor suggested, and eventually bring you a bottle of bulgarian wine at DebConf11, Bosnia ;-) or should we leave the package as it is in -11, and let the release team devote its time to more critical tasks? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- 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/201008181805.33252.danc...@spnet.net
Bug#592616: pu: package bgoffice/3.0-9+lenny1
Георги Данчев wrote: I agree, that 'automatically removed by dpkg' games are best to be avoided for regenerated files, and it is saner to remove them in the postrm, since now debsums aspell-bg lists these three regenerated files as FAILED, which is to be expected. I failed to catch that, so sorry for the noise and thank you for the sharp eye on it. I disagree, it is me who failed to catch that and forgot to pass -Xvar/lib/aspell to dh_md5sums while preparing -11. -- 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/87wrronffv.gnus_not_unix!%ya...@gnu.org
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On 18.08.2010 16:36, Neil McGovern wrote: On Mon, Aug 16, 2010 at 12:36:34PM +0200, Matthias Klose wrote: On 11.08.2010 23:16, Neil McGovern wrote: Hi Matthias, Sorry for not getting back to you sooner. On Sat, Aug 07, 2010 at 11:42:42PM +0200, Matthias Klose wrote: gcc-4.5 should be released with squeeze, at least on amd64 and i386. gcc-4.5.1 was released a week ago, the first bug and regression fix release after the initial gcc-4.5.0 release. Do you have any information as to why this is needed for squeeze, as opposed to squeeze+1? Would this be a nice-to-have, or does it solve a specific problem? it's more than nice-to-have. See the reasons in my original posting (which you didn't include here in the reply). I'm not sure there are any in the original, plugins and a greater optimisation level certainly aren't things which will solve specific problems. Could you highlight them for me? Having these features available for developers, and having not to wait two years until these appear in a stable release is worth the update. Exposing a new compiler version to upstream developers helps reducing the delta between upstream and debian packages. Yes I think this is worth having it in squeeze. - gcc-4.5 will be an optional compiler, not replacing the current defaults. Ok, but if it can be used, it probably will be by at least some things. correct. but it should not introduce rc issues; if it does, then fall back to 4.4, or don't use 4.5 in the first place. Unless things FTBFS on some arches and not others, and thus cause delays in the freeze. Please specify things. Remember that I did only propose to enable this for amd64 and i386. I can't see how your statement is specific for this upload, and not for any other package. If port maintainers do want to enable gcc-4.5 on a port, they should make sure that no regressions are introduced by building the runtime libraries from 4.5 and ensure that possible regressions are fixed. This is the bit that worries me. Although it is optional, it can (and IMO will probably) be used by at least some things. This could lead to odd bugs. If there's a problem in GCC 4.5 that isn't in 4.4, and it comes to a security upload, there could be a mismatch between the requirements. sorry, I don't understand this reasoning and the implications for security uploads. If a package is explicitely built with 4.5, it will be built with 4.5 for security uploads too. Ok, assume that gcc4.5 has some major bug that causes FTBFSes in certain circumstances, and a package has been modified in a way to take advantage of gcc4.5, specifically so it won't build with 4.4; then a problem would occur. Then reverting back to build it with 4.4 should be possible. Again, I don't see this as an argument against it. Do you have details as to the (previously mentioned) unit/regression tests? not besides the test results included in the packages prepared for upload. Is there anything more you would expect? You mentioned: - the upload will build several runtime libraries from the 4.5 sources. Regression tests did pass for the runtime libs built from the 4.5 sources and for 4.4 using the runtime libs from 4.5. This didn't answer my question. Is there anything more you would expect? At the moment, I'm still not sure on the actual advantage of introducing this new package at this stage in the release cycle. well, currently I don't see any arguments against the upload, just some feelings that could apply to any package. Matthias -- 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/4c6bf98c.90...@debian.org
unblock barnowl 1.6.2-1 for #593299
Hi. I'm asking for an unblock of barnowl in order to fix a security problem. Under certain error conditions an attacker or malicious IM server could potentially exploit the vulnerabilities and run arbitrary code. Note that this unblock would move testing from 1.5.1 to 1.6.2. I came very close to uploading 1.6.2 during debconf but wanted to do some additional testing, then the freeze was announced. However after thinking about this particular bug, I do think that squeeze would be far better with these changes than without. I can backport the change, but especially given that it is early in the freeze and that there are a lot of very useful bug fixes between 1.5.1 and 1.6.2, I believe squeeze would be a better release if you unblocked the new upstream. If you do unblock, I'd prefer that you up the urgency of the upload I made yesterday rather than waiting 10 days; I should have uploaded with higher urgency. Attached is the upstream changelog. 1.6.2 * Use a uniquified debug file location. -nelh...@mit.edu * Open the debug file using O_EXCL and an explicit mode. -nelh...@mit.edu * Don't send AIM passwords to the debug log. -geo...@mit.edu * Remove some dead AIM code that sends local files to the server. -geo...@mit.edu * Handle errors from ZPending and ZReceiveNotice (CVE-2010-2725). -nelh...@mit.edu * Include the public repository URL in the README -ale...@mit.edu * Install the documentation in 'make install'. -nelh...@mit.edu * Add a configure flag to enable/disable building with krb4. -wthr...@mit.edu * Fix an infinite loop on 'view -r args'. -nelh...@mit.edu * Free paths to Zephyr dot-files when non-existant -david...@mit.edu * Jabber: Accept a -m argument to jwrite to set the message. -nelh...@mit.edu 1.6.1 * Jabber: Explain how to set your nick when joining a MUC. -ande...@mit.edu * Jabber: Make smartnarrow -i filter on subject. -ande...@mit.edu * Jabber: Fix completion of MUC names. -nelh...@mit.edu * Improve help for bindkey and unbindkey -leon...@mit.edu * Fix a segfault in smartnarrow. -nelh...@mit.edu * Fix a race in handling of resize events. -ande...@mit.edu 1.6 * Add :vp and :viewperson aliases for :viewuser. -kev...@free-dissociation.com * Fix some bugs related to resize. -david...@mit.edu * Don't auto-wrap text in command lines. -nelh...@mit.edu * Wrap input at 70 columns by default. -ande...@mit.edu * Support filtering on whether a message has been deleted. -nelh...@mit.edu * Properly quote strings containing newlines or tabs. -nelh...@mit.edu * Check for an unset mark in owl_editwin_replace_region. -nelh...@mit.edu * Add the narrow-related variable. -geo...@mit.edu * Fix a display bug under perl 5.12. -nelh...@mit.edu * Only use typewindelta when opening multiline editwins. -nelh...@ksplice.com * Add some checks to ./configure. -nelh...@mit.edu * Fix a use-after-free in popexec.c -nelh...@mit.edu * Make pseudologins asynchronous -ased...@mit.edu * Fix some bugs in editwin handling and clean up code. -nelh...@ksplice.com * Add new command unbindkey for removing keybindings -leon...@mit.edu * zcrypt: Implement AES encryption support using GPG. -nelh...@mit.edu * Add 2usage messages to everything in scripts/ -nelh...@mit.edu * Split zcrypt into an external, standalong binary. -nelh...@mit.edu * Fix minor documentation typo -ale...@mit.edu * Document the init/cleanup vs. new/delete naming conventions. -ande...@mit.edu * Clean up code naming conventions to help avoid memory leaks.. -ande...@mit.edu * Add edit:help command for zsh-style in-edit help -david...@mit.edu * Use libpanel to simplify and improve display layer. -david...@mit.edu * Jabber: Mention [-a account] in :help jwrite. -ande...@mit.edu * Fix zcrypt when compiling without krb4 -orem...@mit.edu * Send multiple PRIVMSGs for IRC messages entered as multiple paragraphs -orem...@mit.edu * Require automake ⥠1.7.0, and donât warn about portability to non-GNU make. -ande...@mit.edu * Makefile.am: Use only direct children in SUBDIRS, to appease automake 1.7. -ande...@mit.edu * IRC: irc-disconnect on a pending reconnect should cancel it. -nelh...@mit.edu * Complete several commands that accept a filename. -nelh...@mit.edu * Complete the 'print' and 'bindkey' commands. -nelh...@mit.edu pgpsM8fW79MbR.pgp Description: PGP signature
synaptic and squeeze
Hi Michael, synaptic 0.70~pre1 was uploaded to unstable a few days ago, do you consider it a candidate for squeeze? I'm asking because it's one of the reverse dependencies of libapt-pkg and xapian which both have scheduled ABI bumps in the near future, so having synaptic out of the way would be nice. The ~pre1 version seems to imply you have more changes lined up, and with squeeze now frozen it'd be nice to know where things stand. Thanks! Julien signature.asc Description: Digital signature
Re: Freeze exception: roaraudio, muroard, libao
reflum, On Mon, 2010-08-16 at 22:46 +0200, Mehdi Dogguy wrote: On 08/16/2010 09:04 PM, Patrick Matthäi wrote: There are also no installations in Lenny which may break, just because this package is quite new in Debian at all, we were just not 100% ready at the time where Squeeze has been frozen. :( That's what I suspected. So, basically, the sources in the archive are not ready and you want to push as much as possible changes from upstream's trunk. IMO, roaraudio is not in a releasable state and didn't get much testing… it's only less than one month old (in the archive) and doesn't have any reverse dependency. Maybe it's worth considering whether we really want to include the package in a stable release at the moment. yes we had a bad release. We figured that out and fixed things. As we do not patches in the debian package we tryed to fix everything upstream. we also got fixes from others so we fixed some more things. for example the ALSA plugin which is not build by the debian package nor the upstream package. I also said that we can offer a version which is free of those changes. However I think as they are minor the effect of a 'strange' version (with backported bugfixes) may be more confusing. If you require us to do so, we will even if we do not like that. About the usage by other packages: As you noted the package is new in debian but the project is much older (started June 2008). Some packages did not yet updated the depends, for example: #589756 (Audacious), #589760 (libao), #591636 (ices2). Those are bugs I reported because I know the upstream version has working support. There may be more reports and some devels haven't yet noticed the presense of RoarAudio in Debian for sure. Audacious for example includes very good support in 2.4, but Debian still has 2.3 (devel version) because they missed the freeze themselfs. Maybe they will do a unblock request or maybe they will do a backport or something later. Don't know. Backporting of RoarAudio would be on the list again. Also there is something I would like to call 'implecide depends' indroduced by roarify. roarify (part of libroar-compat0) is a tool to make other software use RoarAudio without them needing native support. roarify is not yet another OSS emulation but much more. It also emulates other sound systems and provides emulation for binarys to help with shell scripts and such using binarys of some sound system. It currently includes emulation for: OSS, DMX4Linux, PulseAudio (parts), EsounD, aRtsc, sndio (handled more directly by the Debian package), YIFF Sound System and RSound (not part of debian yet). Also some tools for NAS are handled. If you do a rdepends for them I'm sure you get a no that short list of tools what can use RA. The daemon it self (roard as part of the roaraudio binary package) also includes protocol emulation. Basicly the same applys for it, too. Another thing why I think the package should be in is OpenBSD's sndio API. libroarsndio (part of libroar-compat0) is developed to emulate it in a very nice way. We are in close contact with OpenBSD's upstream devels to ensure it is a good emulation. It is very helpfull to have it around for porters so they can test sndio support without needing a OpenBSD box around. (I hope it's OK to answer to the other mail as part of this as this ha snothing to do with µRoarD package) The popcon is 2 o_O It's very simple: first of all the package is not very old. Currently most uses use a version compiled from source. You know yourself people do not upgrade as often as they should. also It's not yet in stable nor oldstable so the user basis is limited anyway. And as long as I'm not sure about if this package is inlcuded and in which state I can't realy recommend users to upgrade to the RA package and tell them later they need to upgrade again because it is removed. So what to do? Option 0: let the upstream which is (nearly) bugfix-only release in Option 1: backport bugfixes and let such a package in in this case I need to know which parts exactly you dislike so we know what to backport. Option 2: remove the package. We do dislike this most (I'm sure every package maintainer would ;) See above why we think this is bad to do. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: RFC: SQLite3 in Squeeze
On Wed, Aug 18, 2010 at 04:53:01PM +0200, Mehdi Dogguy wrote: On 08/18/2010 04:34 PM, Julien Cristau wrote: Sounds like we should go back to 3.6.x in testing and sid. If we go that way, we will have to rebuild some packages [1] (red ones). [1] http://release.debian.org/transitions/Sqlite3.html If only sqlite had a symbols file... 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/20100818171036.ga7...@glandium.org
Re: Ampache Freeze exception
On Tue, 2010-08-17 at 18:56 +0100, Adam D. Barratt wrote: On Tue, 2010-08-17 at 11:15 -0500, Charlie Smotherman wrote: [...] On Mon, 16 Aug 2010 23:15:32 -0500 Charlie Smotherman cj...@cableone.net wrote: I have prepared a updated version of ampache which fixes RC bugs #593181, and #593182. Attached is a diff of the proposed changes. [...] http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.5.4-7.dsc Please go ahead and let us know once the package has been accepted. Done Best regards Charlie Smotherman -- 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/1282151708.11478.11.ca...@debian
Re: Ampache Freeze exception
On 08/18/2010 07:15 PM, Charlie Smotherman wrote: On Tue, 2010-08-17 at 18:56 +0100, Adam D. Barratt wrote: On Tue, 2010-08-17 at 11:15 -0500, Charlie Smotherman wrote: [...] On Mon, 16 Aug 2010 23:15:32 -0500 Charlie Smotherman cj...@cableone.net wrote: I have prepared a updated version of ampache which fixes RC bugs #593181, and #593182. Attached is a diff of the proposed changes. [...] http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.5.4-7.dsc Please go ahead and let us know once the package has been accepted. Done Unblocked. -- 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/4c6c1532.2080...@dogguy.org
Re: Please unblock wl-beta 2.15.9+0.20100801-2
On Wed, Aug 18, 2010 at 23:26:42 +0900, Tatsuya Kinoshita wrote: Hi the release team, Please unblock wl-beta, I have uploaded 2.15.9+0.20100801-2 which fixes an important bug #593396. wl-beta (2.15.9+0.20100801-2) unstable; urgency=medium . * debian/patches/30_elmo-folder-open.patch: Fix that elmo database gets out of sync, patch from upstream. (closes: #593396) Unblocked by Mehdi. Cheers, Julien signature.asc Description: Digital signature
Re: freeze exception for gcc-4.5 (i386, amd64 only)
Personally, I'd be comfortable with gcc-4.5 in Squeeze except for this part: - the upload will build several runtime libraries from the 4.5 sources. Regression tests did pass for the runtime libs built from the 4.5 sources and for 4.4 using the runtime libs from 4.5. This really gives me the creeps. I would propose that gcc-4.5 be allowed in testing, with priority extra, but not that the several runtime libraries (which ones are they?) be built from the gcc-4.5 sources. Would that be acceptable to everyone? -- Ludovic Brenta. -- 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/87vd77sv3u@ludovic-brenta.org
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Wed, Aug 18, 2010 at 19:12:37 +0200, Ludovic Brenta wrote: Personally, I'd be comfortable with gcc-4.5 in Squeeze except for this part: - the upload will build several runtime libraries from the 4.5 sources. Regression tests did pass for the runtime libs built from the 4.5 sources and for 4.4 using the runtime libs from 4.5. This really gives me the creeps. I would propose that gcc-4.5 be allowed in testing, with priority extra, but not that the several runtime libraries (which ones are they?) be built from the gcc-4.5 sources. Would that be acceptable to everyone? I assume gcc-4.5 needs libgcc1 from gcc-4.5. Cheers, Julien signature.asc Description: Digital signature
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On 2010-08-18 19:49 +0200, Julien Cristau wrote: On Wed, Aug 18, 2010 at 19:12:37 +0200, Ludovic Brenta wrote: Personally, I'd be comfortable with gcc-4.5 in Squeeze except for this part: - the upload will build several runtime libraries from the 4.5 sources. Regression tests did pass for the runtime libs built from the 4.5 sources and for 4.4 using the runtime libs from 4.5. This really gives me the creeps. I would propose that gcc-4.5 be allowed in testing, with priority extra, but not that the several runtime libraries (which ones are they?) be built from the gcc-4.5 sources. Would that be acceptable to everyone? I assume gcc-4.5 needs libgcc1 from gcc-4.5. As well as libgomp1, and g++-4.5 needs libstdc++6 from gcc-4.5. 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/87aaojiyqs@turtle.gmx.de
Re: please give back shogun on mipsel
On Tue, 2010-08-17 at 18:58 +0200, Mehdi Dogguy wrote: On 08/17/2010 09:16 AM, Soeren Sonnenburg wrote: Hi, shogun fails to build on mipsel (150 minute inactivity timeout compiling a .cxx file of size 5.6MB: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592748 I also see that your package FTBFS on kfreebsd-i386 and hppa. It's killed while generating the documentation. Do you intend to fix those failures as well? You could you change your packaging so that documentation is not generated on buildds. It's a workaround but also a way to save some resources on buildds since arch:all packages are not uploaded when built there. Would it be possible to reschedule a build on a bigger machine ? We can't choose the buildd. I'll give it back and see what will happen. Regards, Mehdi, your cdbs tip helped, shogun built fine on mipsel on most other archs now https://buildd.debian.org/~luk/status/package.php?suite=unstablep=shogun Could you please unblock shogun 0.9.3-4 such that it can enter squeeze after its dependencies enter squeeze? Thanks! 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
Re: please give back shogun on mipsel
On 08/18/2010 08:10 PM, Soeren Sonnenburg wrote: your cdbs tip helped, shogun built fine on mipsel on most other archs now I'm glad I've been helpful. https://buildd.debian.org/~luk/status/package.php?suite=unstablep=shogun Could you please unblock shogun 0.9.3-4 such that it can enter squeeze after its dependencies enter squeeze? I'll make sure it enters Squeeze. 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/4c6c27a3.4040...@dogguy.org
Re: approval request for php-suhosin 0.9.32.1-1
Hi Adam, On Friday, 13. August 2010, Jan Wagner wrote: On Thursday, 12. August 2010, Adam D. Barratt wrote: On Thu, 2010-08-12 at 10:12 +0200, Jan Wagner wrote: php-suhosin (0.9.32.1-1) UNRELEASED; urgency=low * New upstream version (Closes: #584509) - Improved random number seed generation more by adding /dev/urandom juice Which is the upstream change which fixes #584509? The description above doesn't obviously match up with the bug subject (Seeding doesn't produce identical sequences) but I didn't immediately spot another change in the diff which was relevant. I asked upstream, if it got fixed and I got back no idea. could be. there where fixes in these area. So I did build the new package on lenny amd64 and was unable to reproduce the bug there, while with 0.9.31-1 I was. If you wish, I could document that in the bugreport. I documented as stated into the bug. Is there anything you need to know? Thanks and with kind regards, Jan. -- Never write mail to w...@spamfalle.info, you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part.
Re: Freeze exception: cron 3.0pl1-114
On Mon, 2010-08-16 at 12:21 +0200, Christian Kastner wrote: I'd like to ask for a freeze exception for cron 3.0pl1-114. We were looking to upload this version prior to Debconf, but ran into some personal time issues. I realise this has already been unblocked, but fwiw... * debian/control: - Bumped Standards-Version to 3.9.1 (no changes needed) - Added Pre-Depends for dpkg (= 1.15.7.2) for a dpkg-maintscript-helper with support for safely removing conffiles I think you meant = :-) 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/1282157683.23574.12.ca...@kaa.jungle.aubergine.my-net-space.net
Re: Freeze exception: shadow
On 08/18/2010 08:31 PM, Nicolas François wrote: More seriously, I need to find what would be the preferred next shadow release: [1] Prepare an upstream release and a Debian package based on it [2] Package the current upstream trunk (this is mostly ready but must be tested, and I need to check if I raised my hand in the middle of a patch) [2] is ok for me (unless someone yells). [3] Retrofit fixes for Debian bugs [4] Retrofit fixes for Debian release critical bugs only Could you explain more [3] and [4] please? 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/4c6c2fb2.4000...@dogguy.org
Re: approval request for php-suhosin 0.9.32.1-1
On Wed, 2010-08-18 at 20:48 +, Jan Wagner wrote: Hi Adam, On Friday, 13. August 2010, Jan Wagner wrote: On Thursday, 12. August 2010, Adam D. Barratt wrote: On Thu, 2010-08-12 at 10:12 +0200, Jan Wagner wrote: Which is the upstream change which fixes #584509? The description above doesn't obviously match up with the bug subject (Seeding doesn't produce identical sequences) but I didn't immediately spot another change in the diff which was relevant. I asked upstream, if it got fixed and I got back no idea. could be. there where fixes in these area. So I did build the new package on lenny amd64 and was unable to reproduce the bug there, while with 0.9.31-1 I was. If you wish, I could document that in the bugreport. I documented as stated into the bug. Is there anything you need to know? Thanks for the reminder; please go ahead with the upload and let us know once it's been accepted. 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/1282159389.23694.137.ca...@kaa.jungle.aubergine.my-net-space.net
Re: misc unblocks
On Sun, 2010-08-15 at 21:50 +0200, Mathias Behrle wrote: For the special case of release 1.6.1: Release 1.6 contained some heavy rewrites and cleanup of version 1.4. Unfortunately there was lost just one really important functionality of 1.4 in 1.6.0, which made unluckily this release almost unusable for some special implementations relying on this functionality. This essential fix (besides important others) is included in 1.6.1 and should be contained by all means in the next Debian stable release. What was the really important functionality which was affected? 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/1282160456.23694.231.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#593505: unblock: dynare/4.1.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package dynare, it contains only debconf translation updates. Changelog below: dynare (4.1.2-2) unstable; urgency=low * debian/po/da.po: new Danish debconf translation (closes: #589866) Thanks Thomas unblock dynare/4.1.2-2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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/20100818192344.ga10...@atlan
Re: Pre-approval of kcemu bugfix upload
Hi Mehdi, On Aug 16, 2010, at 3:37 PM, Mehdi Dogguy wrote: On 08/15/2010 09:33 PM, Jan Dittberner wrote: Hello, Adrian Glaubitz (CCed) prepared an upload for kcemu (debdiff attached) to fix #592978, a FTBFS on kfreebsd and hurd-i386. Would you unblock the package if I'd sponsor the upload? I see that kcemu never compiled on those architectures. Before considering granting a freeze exception, I'd like to know if you did test your program on kbsd*|hurd? Do you know if there are any issues there? Thank you very much for your quick reply. Indeed, I have tested kcemu on both kfreebsd-i386 and hurd-i386. I have setup virtual machines in a kvm to my Debian packages there. You can take a quick look at the screenshots I took on Debian kfreebsd and hurd-i386: http://users.physik.fu-berlin.de/~glaubitz/kcemu-kfreebsd.png http://users.physik.fu-berlin.de/~glaubitz/kcemu-hurd.png I didn't experience any problems with the package on these two architectures, so I think it's a very good idea to push the fixed version of kcemu, 0.5.1-2 into Debian Squeeze/testing. Thanks alot, Adrian -- 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/e82695ff-70a1-443f-8eb0-b2ac6283a...@physik.fu-berlin.de
Re: Packaging mlt git snapshot and kdenlive trunk for squeeze
On Tue, 2010-08-17 at 19:21 +0200, Patrick Matthäi wrote: Am 17.08.2010 00:17, schrieb Adam D. Barratt: On Sat, 2010-08-14 at 13:46 +0200, Patrick Matthäi wrote: mlt: $ diff -Naur mlt-0.5.6/ /home/me/Coding/mlt/ --exclude=.git|diffstat [...] 27 files changed, 391 insertions(+), 309 deletions(-) This doesn't look unreasonable. Ok After an off-list discussion, a slightly smaller package was uploaded as 0.5.6+git20100727-1; I've just unblocked 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/1282161003.24458.36.ca...@kaa.jungle.aubergine.my-net-space.net
Re: want to get packages into Sqeeze [UPDATE]
Hi, yesterday, I uploaded a new package of roundup which fixes this problem, reported against upstream: http://issues.roundup-tracker.org/issue2550665 Kind regards, --Toni++ signature.asc Description: Digital signature
Re: What to do about libtest-harness-perl?
On Sun, 2010-08-15 at 15:43 +0100, nicho...@periapt.co.uk wrote: The differences between 3.21 and 3.22 are more substantial. From what I can see however the area of the bug was being worked on almost right up until the release. In other words it looks to me as if the patch forms a large part of what happened between 3.21 and 3.22. [...] The bug concerns how the prove utility handles testing scripts directly. Anyway other members of the Debian Perl group will want to express an opinion. Did any of them do so and simply fail to Cc -release? :-) 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/1282161776.24458.97.ca...@kaa.jungle.aubergine.my-net-space.net
please update approx in squeeze
Version 4.5-1 of approx, which I just uploaded to DELAYED/1, fixes two important bugs (#589937 and #593428). Each fix is only one line. Please consider allowing it into testing during the freeze. Thank you. -- Eric Cooper e c c @ c m u . e d u -- 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/20100818194231.gg2...@localhost
Re: want to get packages into Sqeeze [UPDATE]
On Wed, 2010-08-18 at 21:52 +0200, Toni Mueller wrote: yesterday, I uploaded a new package of roundup which fixes this problem, reported against upstream: http://issues.roundup-tracker.org/issue2550665 Thanks for the update. There's also a packaging change which wasn't mentioned in the changelog, although it's a no-op for Debian (changing the python (= 2.4) build-dep to simply python). 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/1282162345.24458.153.ca...@kaa.jungle.aubergine.my-net-space.net
Re: Freeze exception: python-defaults 2.6.5-13
[Adam D. Barratt, 2010-08-17] Let me know if you'd like to correct any or all of those in a -14 upload, otherwise I'll just unblock -13. please unblock it. It's fixed in bzr, but we'll wait for more changes before uploading... -- 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 signature.asc Description: Digital signature
Re: Freeze exception: shadow
On Wed, Aug 18, 2010 at 09:08:34PM +0200, Mehdi Dogguy wrote: On 08/18/2010 08:31 PM, Nicolas François wrote: More seriously, I need to find what would be the preferred next shadow release: [1] Prepare an upstream release and a Debian package based on it [2] Package the current upstream trunk (this is mostly ready but must be tested, and I need to check if I raised my hand in the middle of a patch) [2] is ok for me (unless someone yells). [3] Retrofit fixes for Debian bugs [4] Retrofit fixes for Debian release critical bugs only Could you explain more [3] and [4] please? In [3] and [4], the proposal was to fix Debian bugs, and Debian bugs only. Starting from the last Debian package, without new feature or other bug fixes from the upstream trunk. Best Regards, -- Nekral -- 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/20100818204053.ga12...@nekral.nekral.homelinux.net
Re: Freeze exception: python-defaults 2.6.5-13
On Wed, 2010-08-18 at 22:40 +0200, Piotr Ożarowski wrote: [Adam D. Barratt, 2010-08-17] Let me know if you'd like to correct any or all of those in a -14 upload, otherwise I'll just unblock -13. please unblock it. It's fixed in bzr, but we'll wait for more changes before uploading... Unblocked. 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/1282165049.24458.379.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#593505: marked as done (unblock: dynare/4.1.2-2)
Your message dated Wed, 18 Aug 2010 23:36:48 +0200 with message-id 4c6c5270.8080...@dogguy.org and subject line Re: Bug#593505: unblock: dynare/4.1.2-2 has caused the Debian Bug report #593505, regarding unblock: dynare/4.1.2-2 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.) -- 593505: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593505 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package dynare, it contains only debconf translation updates. Changelog below: dynare (4.1.2-2) unstable; urgency=low * debian/po/da.po: new Danish debconf translation (closes: #589866) Thanks Thomas unblock dynare/4.1.2-2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- On 08/18/2010 09:23 PM, Thomas Weber wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package dynare, it contains only debconf translation updates. Changelog below: dynare (4.1.2-2) unstable; urgency=low * debian/po/da.po: new Danish debconf translation (closes: #589866) Unblocked. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ ---End Message---
Freeze exception: nunit 2.4.7+dfsg-6 (RC bug #591600)
This upload fixes RC bug #591600, by deleting RC-buggy postinst/prerm scripts which are nowadays handled by a dpkg trigger. No other significant changes have been made to this upload. signature.asc Description: This is a digitally signed message part
Re: Freeze exception: nunit 2.4.7+dfsg-6 (RC bug #591600)
On 08/18/2010 11:47 PM, Jo Shields wrote: This upload fixes RC bug #591600, by deleting RC-buggy postinst/prerm scripts which are nowadays handled by a dpkg trigger. No other significant changes have been made to this upload. Is it already uploaded or an intent to upload? I don't see it anywhere, yet. 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/4c6c55e2.3070...@dogguy.org
Re: Freeze exception: nunit 2.4.7+dfsg-6 (RC bug #591600)
On Wed, 2010-08-18 at 23:51 +0200, Mehdi Dogguy wrote: On 08/18/2010 11:47 PM, Jo Shields wrote: This upload fixes RC bug #591600, by deleting RC-buggy postinst/prerm scripts which are nowadays handled by a dpkg trigger. No other significant changes have been made to this upload. Is it already uploaded or an intent to upload? I don't see it anywhere, yet. Uploaded it about ten minutes ago, so it's probably sat in a queue somewhere waiting to appear on incoming.d.o signature.asc Description: This is a digitally signed message part
Re: Freeze exception: cron 3.0pl1-114
On 08/18/2010 08:54 PM, Adam D. Barratt wrote: On Mon, 2010-08-16 at 12:21 +0200, Christian Kastner wrote: I realise this has already been unblocked, but fwiw... Indeed - thanks! * debian/control: - Bumped Standards-Version to 3.9.1 (no changes needed) - Added Pre-Depends for dpkg (= 1.15.7.2) for a dpkg-maintscript-helper with support for safely removing conffiles I think you meant = :-) ouch! fix committed. Christian -- 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/4c6c58e7.5070...@kvr.at
Re: misc unblocks
* Betr.: Re: misc unblocks (Wed, 18 Aug 2010 20:40:55 +0100): On Sun, 2010-08-15 at 21:50 +0200, Mathias Behrle wrote: For the special case of release 1.6.1: Release 1.6 contained some heavy rewrites and cleanup of version 1.4. Unfortunately there was lost just one really important functionality of 1.4 in 1.6.0, which made unluckily this release almost unusable for some special implementations relying on this functionality. This essential fix (besides important others) is included in 1.6.1 and should be contained by all means in the next Debian stable release. What was the really important functionality which was affected? The most important fix is for https://bugs.tryton.org/roundup/issue1609: Passing values to fields with the python context was broken, thus breaking the functionality of entire modules, because default values were not be set any more. The fixes are in http://hg.tryton.org/hgwebdir.cgi/tryton/rev/6e20571014d2 and http://hg.tryton.org/hgwebdir.cgi/tryton/rev/b57982ac70d2 Other important fixes are https://bugs.tryton.org/roundup/issue1619: Fix of fingerprint check for ssl connections. With python implementations lacking getpeercert functionality (python2.6) secure connections were impossible. Fixed with http://hg.tryton.org/hgwebdir.cgi/tryton/rev/7ce317af1658 https://bugs.tryton.org/roundup/issue1521: Wizard sizes were not stored any more, introducing an important regression in usability, thus making this release almost unusable for implementations making heavy usage of wizards. Fixed with http://hg.tryton.org/hgwebdir.cgi/tryton/rev/dc7b75fd798a https://bugs.tryton.org/roundup/issue1575: Fixing the usage of Decimal and Float for XML-RPC, which was broken for on_change calls via XML-RPC. Fixed with http://hg.tryton.org/trytond/rev/15c673a1072d https://bugs.tryton.org/roundup/issue1507: Enabling the compatibility for the printing of reports with OpenOffice.org 3.2. Without this fix it is impossible to use the OOo contained in squeeze. Fixed with http://hg.tryton.org/trytond/rev/3888542922ca Those are the most important fixes being indeed essential for the usage and functionality of Tryton. From my point of views it is even not advisable to recommend the usage of version 1.6.0 of Tryton. It is really important to get 1.6.1 into squeeze. Regards, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://mbsolutions.selfip.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: What to do about libtest-harness-perl?
The group definitely knows about the issue. What other information apart from opinions would be of use? Quoting Adam D. Barratt a...@adam-barratt.org.uk: On Sun, 2010-08-15 at 15:43 +0100, nicho...@periapt.co.uk wrote: The differences between 3.21 and 3.22 are more substantial. From what I can see however the area of the bug was being worked on almost right up until the release. In other words it looks to me as if the patch forms a large part of what happened between 3.21 and 3.22. [...] The bug concerns how the prove utility handles testing scripts directly. Anyway other members of the Debian Perl group will want to express an opinion. Did any of them do so and simply fail to Cc -release? :-) Regards, Adam -- To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282161776.24458.97.ca...@kaa.jungle.aubergine.my-net-space.net -- 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/20100818230249.pak0ydtz0kckc...@webmail.periapt.co.uk
Unblock request: Cherokee
Hi,
Squeeze currently has version 1.0.4-1 of the Cherokee webserver. This
version suffers from a series of SSL/TLS problems (worst of all is
that it just won't work with Firefox).
I am uploading version 1.0.8-1 - Upstream's release notices since
1.0.4 include:
1.0.5
- NEW: Much better UTF-8 encoding
- NEW: Templates support slicing now (as in Python str)
- NEW: 'TLS/SSL' matching rule
- NEW: Reverse HTTP proxy can overwrite Expire: entries
- NEW: Redirection handler support the ${host} macro now
- FIX: POST support in the HTTP reverse proxy
- FIX: Some SSL/TLS were fixed. [unfinished]
- FIX: X-Forwarded-For parsing bug fixed
- FIX: Better php-fpm support in the PHP wizard
- FIX: Bundled PySCGI bumped to 1.14
- DOC: Documentation updates
- i18n: Spanish translation updated
- i18n: Dutch translation updated
- i18n: Polish translation updated
1.0.6
- FIX: Random 100% CPU usage
- FIX: POST management regression in the proxy
- FIX: Connection RST/WAIT_FIN related fixes
- FIX: Dirlist bugfix: symbolic links handling
- FIX: POST status report bug-fixes
- i18n: German translation updated
1.0.7
- NEW: Improved extensions rule
- FIX: POST management issue
- FIX: PHP wizard, better configuration
- FIX: admin, unresponsive button
- DOC: Misc improvements
- i18n: French translation updated
1.0.8
- FIX: SSL/TLS works with Firefox again
- FIX: Better SSL/TLS connection close
- NEW: Enhanced 'Header' rule match
- FIX: Range requests work better now
- FIX: Hot-linking wizard w/o Referer
- FIX: Hot-linking wizard usability
- FIX: Minor CSS fix in the default dirlist theme
- DOC: Misc improvements
So, as you can see, the NEW characteristics are quite minor - Most of
what has been added are FIXes.
I have a couple of open bugs on Cherokee, but mostly regarding aspects
of my packaging - I prefered to change as little as possible so as not
to disturb the freeze.
Please allow 1.0.8-1 into Squeeze.
Thanks!
signature.asc
Description: Digital signature
OpenTTD in Squeeze
Dear Debian release team, I'm Remko 'Rubidium' Bijker, the release manager of (upstream) OpenTTD. I've got good contact with the Debian package maintainer of OpenTTD; he has actually read and commented on this before sending it to you. As I am not the Debian package maintainer the diffs and diffstats that I give/link to do not include changes to the packaging. As it stand now you are to release OpenTTD 1.0.3 with Squeeze [1]. The problem with this release is that there are two small, but easily triggerable, regressions in 1.0.3 over 1.0.2. On the other hand 1.0.3 fixes as (CVE) vulnerability. Due to the design of OpenTTD (the client performs the exact same tasks as the server and only the actions of the players are send over the internet) the fixes for these regressions in 1.0.3 require a modification of both the server and client side of OpenTTD which means that patching 1.0.3 is not advisable; such a patch would mean that the Debian patched OpenTTD is unable to keep in-sync with a non-patched version regardless of which is the server. So we hope that you are willing to release with OpenTTD 1.0.4. After reading the Non-recompilable binaries in source and binary packages thread of debian-devel [2] I came to the conclusion that we (upstream) do not package the sources of two of our binary files together with the rest of the sources. This means that two binary files are not compiled by the Debian package and that you are, in effect, shipping a non-recompilable binary. We maintained the source of these two binary files in a separate branch of our vcs as most users did not have the tools, GRFCodec and NFORenum, to compile these. We will ship the sources of these binary files starting from the 1.0.4 release. The binary files will be automatically recompiled whenever they are removed as e.g. make distclean does. This will require that GRFCodec and NFORenum need to be added as build-dependencies. One big caveat is that we have not released OpenTTD 1.0.4 yet, or started with release candidates, which means that it will take at least two weeks before the final 1.0.4 release will be made. Given that we like to maintain somewhat regular interval in release cycles 1.0.4 is currently planned for 2010-10-01, which I reckon might be too late to consider including this release into Squeeze. However, for us releasing before 2010-09-01 is out of the question due to the need of a release candidate and testing. The question therefore that if you allow the OpenTTD 1.0.4 release to migrate to Squeeze what the latest moment for us to release would be, assuming that once released it gets immediately added to unstable by the Debian package maintainer? I'm asking this because I don't want to unnecessarily rush the release of OpenTTD 1.0.4 and thus possibly introduce more regressions, but I would like to have the fixes into Debian Squeeze and as such I'm looking for some break-even point where all parties can agree on. The diffstat [3] from 1.0.3 in the 1.0 branch is already quite huge: 145 files changed, 14829 insertions(+), 1948 deletions(-) However, much of this are translation updates changes: 56 files changed, 6646 insertions(+), 1576 deletions(-) and the addition of the sources of the binary files: 39 files changed, 7575 insertions(+), 21 deletions(-) leaving not much for the actual fixes [4] as can be seen in the summary of the diffstat [5]: 50 files changed, 608 insertions(+), 351 deletions(-) This the above data is a snapshot as the final release of 1.0.4 has not been made. The upstream changelog for 1.0.4 currently contains 35 fixes, 1 addition (i.e. the missing source code) and the translation updates are not mentioned. We generally use the point releases for bug fixes only, although sometimes very small features (by some seen as bug fixes) get in. For the 1.0.4 we do not intend to include these very small features. My next request is about openttd-openmsx [6]. This is a (small) set of MIDI files that can be played from within OpenTTD. This set was dual-licensed under GPLv2 and Creative Commons Sampling Plus (i.e. non-free), with the note that if not enough GPLv2 material could be found the set would use Creative Commons Sampling Plus material and thus drop the GPLv2 license. This lead to the decision to not package the set until a clear choice regarding the license was made. The set is now complete and has had a few GPLv2-only licensed releases. We would like that openttd-openmsx becomes a Recommends of the OpenTTD package, which would mean allowing the migration of openttd-openmsx into Squeeze and OpenTTD. Hopefully the latter can be combined with the upload of 1.0.4. openttd-openmsx resides at the moment of writing in NEW. My final requests are about the packages grfcodec and nforenum. These packages had their last stable releases in 2007. Those versions were totally unable to compile the openttd-opengfx and as such nightlies were put into Debian's archives. The original upstream developer did
Bug#592721: unblock: embassy-* and emboss.
Le Wed, Aug 18, 2010 at 03:20:54PM +0200, Mehdi Dogguy a écrit : Nevertheless, there is an issue with embassy-phylip: embassy-phylip | 3.69-1 | testing/non-free | source, amd64, ia64, mips, mipsel, s390, sparc embassy-phylip | 3.69-1 | unstable/non-free | source, ia64, mips, mipsel, s390, sparc embassy-phylip | 3.69+20100721-1 | unstable/non-free | source, amd64 I guess it was built by mistake for 3.69-1 and wasn't for 3.69+20100721-1. It has to be whitelisted to be able to build there. Did you ask for that? Otherwise, you can request for their removal or ask us to remove it from testing : Dear Mehdi, thank you for your review. I do not remember having asked for autobuilder whitelisting and therefore submitted #593531 for the removal of the 3.69-1 packages. After this, 3.69+20100721-1 should be able to migrate if you unblock it. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100819005749.ga26...@merveille.plessy.net
Re: Bug#592616: pu: package bgoffice/3.0-9+lenny1
Julien Cristau jcris...@debian.org writes: Shipping such a file in the package means it'll get emptied every time the package in re-installed or upgraded. That sounds wrong. This is weird, but the aspell packages have been doing this for quite some time, long enough that there's an explicit exception in Lintian for it. I think we should revisit this, but I wouldn't worry about it as a release issue. I think all the aspell packages are doing this right now, and squeeze+1 is soon enough to sort it out. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87hbir8jt7@windlord.stanford.edu
Re: Please unblock git-buildpackage 0.5.4
Mehdi Dogguy me...@dogguy.org writes: On 08/17/2010 08:50 AM, Guido Günther wrote: Hi, please unblock the above version. In git-buildpackage-0.5.2/gbp-pq: +maintainer=$(sed -n -e 's/Maintainer: \+\(.*\)/\1/p' debian/control) +QUILT_PATCHES=$patches run_git quiltimport --author $maintainer What happens when the rest of the line is empty (maintainers listed starting from the next line) or if you have several maintainers listed on the same line. Wouldn't $DEBFULLNAME $DEBEMAIL be ok for this? I see from subsequent discussion that you had mostly already realized this, but Maintainer is not a multiline field (unlike Uploaders, which is). Either of those formats would be Policy violations. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d3tf8jmb@windlord.stanford.edu
Re: Bug#592616: pu: package bgoffice/3.0-9+lenny1
Russ Allbery writes: Julien Cristau jcris...@debian.org writes: Shipping such a file in the package means it'll get emptied every time the package in re-installed or upgraded. That sounds wrong. This is weird, but the aspell packages have been doing this for quite some time, long enough that there's an explicit exception in Lintian for it. I think we should revisit this, but I wouldn't worry about it as a release issue. I think all the aspell packages are doing this right now, and squeeze+1 is soon enough to sort it out. Hi Russ, I filed a wishlist bug #593487 against dictionaries-common, which aspell- autobuildhash(8) suggests that approach, in order to have that tracked and sorted out. I'm not quite satisfied with such a suggestion as given in the man- page without it being clearly justified by very strong reasoning, and as it turned out, it might be completely unneeded. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- 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/201008190501.24169.danc...@spnet.net
NEW changes in proposedupdates
Processing changes file: smarty_2.6.20-1.3_amd64.changes ACCEPT Processing changes file: lxr-cvs_0.9.5+cvs20071020-1+lenny1_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/e1olumn-0007wc...@franck.debian.org
emacs23: bugfix suitable for squeeze?
Would this fix be appropriate for squeeze, or should I hold off? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586459 The bug's probably not important since the circumstances involved are likely to be rare, but the consequences are fairly severe. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- 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/87iq37jow1@raven.defaultvalue.org
Re: Freeze exception: nunit 2.4.7+dfsg-6 (RC bug #591600)
On 08/18/2010 11:47 PM, Jo Shields wrote: This upload fixes RC bug #591600, by deleting RC-buggy postinst/prerm scripts which are nowadays handled by a dpkg trigger. No other significant changes have been made to this upload. 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/4c6cbf0f.3030...@dogguy.org
Re: updated packages for squeeze
On Tue, 2010-08-17 at 21:19 +0200, Julien Cristau wrote: Thanks, please ping us again when the package is accepted to get the unblock. Both cvsd 1.0.19 and nss-pam-ldapd 0.7.8 are now both in unstable. Translations for nss-pam-ldapd are coming in now. Is there a date before which you prefer to have the version with all translations included (I've put Friday, 27th of August in the call for translations)? -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
