Bug#679495: unblock: klibc/2.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package klibc once d-i beta is released, for the nfsmount wrong unwind in error path fix of: http://bugs.debian.org/679011 diff from 2.0 to 2.0.1 is minimal and just adds this two-liner for gethostname()/getdomainname(), plus a debian/watch correction. http://git.kernel.org/?p=libs/klibc/klibc.git;a=commitdiff;h=1a6f222b01cead2ec48556203f0e200107eb4c2f;hp=029622dfbfe25203275a385a5bf33d44c2409b00 unblock klibc/2.0.1-1 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.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/20120629073143.19692.47917.reportbug@shockwave
Bug#669348: [Pkg-phototools-devel] Bug#675773: Bug#675773: libopenjpeg2: Please make libopenjpeg2 multi-arch: same
On Thu, Jun 28, 2012 at 10:46 PM, Michael Gilbert mgilb...@debian.org wrote: Can I have a little context here? Why is it important enough to have multi-arch openjpeg to do an NMU just before the freeze? Hi Michael; It seems we need more time to discuss this, so I cancelled the upload for now. Personally I think it would be better to wait until after the openjpeg5 transition and then work on multiarchifying the latest version of the library, presumably after the freeze. If there is some urgent reason to push through multiarch at this time, I leave you and Mathieu (who is an upstream maintainer and the main person interested on the debian side) to sort that out. The goal was to get multiarch enabled in all of wine's dependencies. openjpeg 1.5 is already multiarched, but that has yet to hit unstable. There is a lot of apparent brokenness in that transition, so 1.3 may be with us for a while: http://release.debian.org/transitions/html/openjpeg.html There is not a single 'brokenness'. openjpeg 1.5 is still in experimental. It needs a source uploads in unstable and a couple of deps needs binNMU that is all. API is preserved not ABI that's all. The libopenjpeg2 dependency addition is a mistake, and I'll remove that. So, I would like to go ahead with the nmu again (with the above fixed). Would that be ok from your perspective? Well for me working on #669348 would be make so much more sense (fixing CVEs and tons of bugs), but if you have time for this, go ahead... -- 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/ca+7wuswakhnd5k+lgpun+7e6cfsrrjhjbv2wqr6z9yypukq...@mail.gmail.com
Bug#650601: Re: Bug#650601: transition: libpng 1.5
On Fri, Jun 29, 2012 at 02:45:14PM +0900, Nobuhiro Iwamatsu wrote: 2012/6/27 Julien Cristau jcris...@debian.org: On Wed, Jun 27, 2012 at 08:45:03 +0900, Nobuhiro Iwamatsu wrote: Hi, I am still correcting FTBFS. However, almost packages can shift to libpng 1.5. May I upload libpng 1.5 to unstable? Absolutely not. OK. Does that already mean that it is too late in wheezy? Yes, I'm afraid so. Neil -- signature.asc Description: Digital signature
Re: libetpan in wheezy
On Wed, Jun 27, 2012 at 04:28:04PM +0200, Ricardo Mones wrote: Dear Release Team, There's a new upstream version of libetpan (1.1) which seems to be a bugfix release mostly with only a couple of features added. (Un)fortunately upstream has bumped soname. It seems current libetpan maintainer is not going to have much time for it in the future [0] and wants somebody to take over. I've packaged new version and reverse dependencies build fine with it, though this was expected as the only symbol changed was not used. Anyway I've rebuilt them to be sure. Two of the rdeps are going to be source uploaded by me (claws-mail and claws-mail-extra-plugins) as announced previously in this list [1]. The other, cairo-dock-plug-ins, would require a binNMU. Sounds that OK or should I upload it to experimental instead? thanks in advance, [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678970 [1] http://lists.debian.org/debian-release/2012/06/msg00545.html It's already in experimental, thanks to fpt-masters quick approval, and source uploads were already done. I guess this micro-transition is still possible binNMUing: claws-mail claws-mail-extra-plugins cairo-dock-plug-ins Let me know if there's an opportunity to upload libetpan to unstable. thanks in advance, -- Ricardo Mones ~ Datei nicht gefunden Fehler 404 signature.asc Description: Digital signature
Bug#668008: marked as done (transition: uw-imap)
Your message dated Fri, 29 Jun 2012 14:21:19 +0200 with message-id 20120629122119.gq16...@jones.dk and subject line Re: Bug#668008: transition: uw-imap has caused the Debian Bug report #668008, regarding transition: uw-imap 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.) -- 668008: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668008 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: transition I have prepared a new upstream release of uw-imap. It includes libc-client which is requires recompilation of 5 other packages: libmail-cclient-perl mailsync php5 prayer asterisk First three build-depend on the virtual libc-client-dev so should do with a simple binNMU. Asterisk and prayer need a source change to depend on new development headers (or to switch to build-depending on virtual package instead). - Jonas ---End Message--- ---BeginMessage--- On 12-04-28 at 03:40pm, Adam D. Barratt wrote: On Sun, 2012-04-08 at 09:54 +0200, Jonas Smedegaard wrote: I have prepared a new upstream release of uw-imap. It includes libc-client which is requires recompilation of 5 other packages: libmail-cclient-perl mailsync php5 prayer asterisk First three build-depend on the virtual libc-client-dev so should do with a simple binNMU. Should? Are there any API changes in the new libc-client which are likely to affect those packages? Actually it turned out there wasn't even a need for a SONAME bump. I now released new uw-imap, and this transition is unneeded. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ---End Message---
Bug#673538: libobjc3 - libobjc4 transition
Hi, I just read that there might not be time to do the transition, but this bug actually combined two transitions: the libobjc transition and the gnustep transition. If the gnustep transition isn't going to happen, we still need to finish libobjc4 transition on the archs that have gcc 4.7 as default, right? Because at the moment there is a mix of packages depending on libobjc3 and libobjc4, which in the case of for example SOGo means that both libobjc3 and libobjc4 get pulled in. Kind regards, Jeroen Dekkers -- 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/87hatu1c2o.wl%jer...@dekkers.ch
Re: Patch for #660260 (gnudatalanguage FTBFS) from upstream may come only after the freeze
Hi, Axel Beckert wrote: I know it's late, but after quite some prodding by me and others, upstream of gnudatalanguage is finally working on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660260 Unfortunately so far the first two patch versions I received from upstream didn't completely solve this issue. They asked in their last mail if this is critical for this week, which makes me suspect that they may not be able to produce a complete patch in time for the freeze on Saturday. JFTR: I've got a working package again. Upload probably later today. So this should be no more be an issue for a freeze exception. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20120629151013.gl3...@sym.noone.org
Britney-tests git repository
[ Sending this message to known, to me, users of britney-tests.git ] Hi, The Git repository britney-tests.git grew significantly since we added live-data tests. (Its current size is, iirc, 1.3G). In many situations, and especially for people that want to just have a look at the test-suite, cloning the repository is quite a pita since the cloned data is pretty huge for no benefit. I've tried to enhance the situation by splitting the repository and creating a new one for the live-data tests. The two new Git repositories live in: - git+ssh://git.debian.org/git/collab-maint/britney2-tests.git - git+ssh://git.debian.org/git/collab-maint/britney-tests-live-data.git The latter is a submodule of the former. You may clone britney2-tests.git as usual: $ git clone git+ssh://git.debian.org/git/collab-maint/britney2-tests.git And, if you need live-data tests, you may do: $ git submodule update --init For your convenience, I've added a small paragraph about britney-tests-live-data.git in the README file in britney2-tests.git If we find this useful, we can replace the current britney-tests.git with britney2-tests.git. Comments are welcome. Best, -- Mehdi Dogguy مهدي الدڤي -- 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/4fedc61a.6030...@dogguy.org
Bug#669348: [Pkg-phototools-devel] Bug#675773: Bug#675773: libopenjpeg2: Please make libopenjpeg2 multi-arch: same
On Fri, Jun 29, 2012 at 3:50 AM, Mathieu Malaterre wrote: Well for me working on #669348 would be make so much more sense (fixing CVEs and tons of bugs), but if you have time for this, go ahead... What exactly needs working on for #669348? It seems like an immediate step to push forward that transition would be an upload to unstable (so at least all of the packages are ready for a testing transition when that's ready to go). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpb8fjuoewa8lmt7hcnv4nq+fojd2jn_mxhcqfdcfu...@mail.gmail.com
Bug#669348: [Pkg-phototools-devel] Bug#675773: Bug#675773: libopenjpeg2: Please make libopenjpeg2 multi-arch: same
On Fri, Jun 29, 2012 at 12:11 PM, Michael Gilbert wrote: On Fri, Jun 29, 2012 at 3:50 AM, Mathieu Malaterre wrote: Well for me working on #669348 would be make so much more sense (fixing CVEs and tons of bugs), but if you have time for this, go ahead... What exactly needs working on for #669348? It seems like an immediate step to push forward that transition would be an upload to unstable (so at least all of the packages are ready for a testing transition when that's ready to go). Of course given approval from the release team. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPFePCic-DwWqMTtTD9w5Ytv=kcgcj4keagczny_uy...@mail.gmail.com
Bug#673538: libobjc3 - libobjc4 transition
Hi, [Quoting and not breaking threading are generally appreciated... :-/] On 29.06.2012 14:29, Jeroen Dekkers wrote: I just read that there might not be time to do the transition, but this bug actually combined two transitions: the libobjc transition and the gnustep transition. If the gnustep transition isn't going to happen, we still need to finish libobjc4 transition on the archs that have gcc 4.7 as default, right? Because at the moment there is a mix of packages depending on libobjc3 and libobjc4, which in the case of for example SOGo means that both libobjc3 and libobjc4 get pulled in. My understanding was that if necessary (which given that the freeze is tomorrow it might be), this could be resolved without a transition by having gnustep-make explicitly depend on gobjc-4.6 for the wheezy cycle; see #676229. Yavor, is that correct? 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/33f6288d377b1a7f23b61643d...@mail.adsl.funky-badger.org
Re: libetpan in wheezy
On Fri, Jun 29, 2012 at 12:07:35 +0200, Ricardo Mones wrote: I guess this micro-transition is still possible binNMUing: claws-mail claws-mail-extra-plugins cairo-dock-plug-ins Let me know if there's an opportunity to upload libetpan to unstable. I'm afraid it's too late for new SONAME bumps. Cheers, Julien signature.asc Description: Digital signature
Bug#673538: libobjc3 - libobjc4 transition
Adam D. Barratt wrote: On 29.06.2012 14:29, Jeroen Dekkers wrote: I just read that there might not be time to do the transition, but this bug actually combined two transitions: the libobjc transition and the gnustep transition. If the gnustep transition isn't going to happen, we still need to finish libobjc4 transition on the archs that have gcc 4.7 as default, right? I don't think we *have* to, see below. My understanding was that if necessary (which given that the freeze is tomorrow it might be), this could be resolved without a transition by having gnustep-make explicitly depend on gobjc-4.6 for the wheezy cycle; see #676229. Yavor, is that correct? You are correct that if the Release Team decides to postpone the transition after the wheezy release, we we will resolve the current problem without a transition (neither libgnustep-* nor libobjc). You are not correct that we'll have to revert the change in gnustep-make (the dependency on gobjc-4.6). It was a hack in the first place, and depending on gobjc-4.6 implies a transition -- at least all GNUstep packages that were built since gcc-4.7 became the default need to be rebuilt. I don't see any benefit in doing this; we may as well have a full GNUstep libobjc transition instead. Uploading gnustep-base/1.22.1 with the libobjc4 patch will allow the package to be built with gcc-4.7 on x86 archs, and with gcc-4.6 on the other (where 4.6 is still the default). Thus, all GNUstep packages that were recently built will depend on libobjc4 on x86, and on libobjc3 on the rest of the architectures, as is expected. The patch is ABI compatible, so no recompilation should be necessary; I can confirm this after my runtime tests. Some GNUstep packages that were built with gcc-4.6 during the last transition and were not touched since then (such as gtamsanalyzer.app) will still depend on both libobjc3 on x86 (via their Depends:) and libobjc4 (indirectly via their libgnustep-base1.22 dependency), but libobjc.so.4 will be loaded first during GNUstep Base initialization, so there won't be runtime issues. The only problem for these apps is cosmetic (useless dependency on libobjc3), but since gcc-4.6 is going to be shipped in wheezy anyway and libobjc3 is of small size (presumably not a big problem for most users), it is in no way critical. -- 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/87txxuvv2v.GNUs_Not_Unix!%ya...@gnu.org
Bug#669348: [Pkg-phototools-devel] Bug#675773: Bug#675773: libopenjpeg2: Please make libopenjpeg2 multi-arch: same
On Fri, Jun 29, 2012 at 12:12:29 -0400, Michael Gilbert wrote: On Fri, Jun 29, 2012 at 12:11 PM, Michael Gilbert wrote: On Fri, Jun 29, 2012 at 3:50 AM, Mathieu Malaterre wrote: Well for me working on #669348 would be make so much more sense (fixing CVEs and tons of bugs), but if you have time for this, go ahead... What exactly needs working on for #669348? It seems like an immediate step to push forward that transition would be an upload to unstable (so at least all of the packages are ready for a testing transition when that's ready to go). Of course given approval from the release team. Said approval will not come before wheezy is released. Cheers, Julien signature.asc Description: Digital signature
Re: Bits from the Release Team: Final countdown!
❦ 21 juin 2012 11:16 CEST, Neil McGovern ne...@debian.org : As with the Squeeze freeze the process will be gradual, with a more liberal acceptance policy in the earlier stages. Precise details as to what that means will be available soon. Roundcube, an AJAX webmail, is scheduling its next major release soon. If its release is one or two weeks after the freeze, would an exception be granted? The rationale is that this kind of web applications is difficult to maintain for a long time on the security front (and since its a web app, the attack surface is quite important) since upstream supports only the latest version. Having the latest version when releasing would ease the work. Just a question. -- Don't over-comment. - The Elements of Programming Style (Kernighan Plauger) pgpE4boXeVevO.pgp Description: PGP signature
Bug#661078: britney: ignore additional packages in Sources index
On 2012-02-24 01:22, Ansgar Burchardt wrote:
Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: britney
I would like to include additional packages referenced by Built-Using in
the Sources index[1] at some undefined point in the future. This might
confuse britney which would need to just ignore them.
Ansgar
[1] http://bugs.debian.org/657212
Hi,
In light of our IRC chat in #d-ftp today and the asumption that the
Only-Extra-Source field will be implemented, I believe I have a
trivial patch that will work[1]. There is an updated test for it in the
britney2-tests[2] (the new repository announced today - not the old one).
The patch is backwards compatible and could be applied before the
extra sources appear in the Sources files (and without updating any of
the unrelated existing tests).
It is my understanding that the new field has only been proposed at this
point, but the field would greatly simplify the Britney changes and keep
the risks of regressions at a minimal.
~Niels
[1]
http://anonscm.debian.org/gitweb/?p=users/nthykier/britney.git;a=shortlog;h=refs/heads/bug-661078
(also attached)
[2] http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git
From 9c3622ece11b53467c33bc1dab2dfa5c3216aebe Mon Sep 17 00:00:00 2001
From: Niels Thykier ni...@thykier.net
Date: Fri, 29 Jun 2012 23:23:25 +0200
Subject: [PATCH] Ignore sources only referenced by Built-Using
Signed-off-by: Niels Thykier ni...@thykier.net
---
britney.py |3 +++
1 file changed, 3 insertions(+)
diff --git a/britney.py b/britney.py
index 5205f64..e3e1cdb 100755
--- a/britney.py
+++ b/britney.py
@@ -453,6 +453,9 @@ class Britney(object):
step = Packages.step
while step():
+if get_field('Only-Extra-Source', 'no') == 'yes':
+# Ignore sources only referenced by Built-Using
+continue
pkg = get_field('Package')
ver = get_field('Version')
# There may be multiple versions of the source package
--
1.7.10
Re: Britney-tests git repository
On 2012-06-29 17:13, Mehdi Dogguy wrote: [ Sending this message to known, to me, users of britney-tests.git ] Hi, Hi, Thanks for doing this. The Git repository britney-tests.git grew significantly since we added live-data tests. (Its current size is, iirc, 1.3G). In many situations, and especially for people that want to just have a look at the test-suite, cloning the repository is quite a pita since the cloned data is pretty huge for no benefit. Indeed. Though while our current test suite does cover some cases, I have found that the live-data are by far better regression tests. They have a lot of interesting cases left in them that has not been coverted to minimal tests. So for actual changes to Britney2, I would highly recommend also running them. Though I am not sure how useful they are to SAT-Britney (beyond performance testing), since the expected result is currently tailored for Britney2[1]. [1] Where tailored was the output of Britney2 a while back. It works for finding unexpected output changes. I've tried to enhance the situation by splitting the repository and creating a new one for the live-data tests. [...] For your convenience, I've added a small paragraph about britney-tests-live-data.git in the README file in britney2-tests.git If we find this useful, we can replace the current britney-tests.git with britney2-tests.git. Comments are welcome. Best, I believe it would be counter productive for us to have two active test repositories (e.g. people committing to the wrong repository), so I have disabled our old one (with a note). ~Niels -- 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/4fee2df7.2000...@thykier.net
