Bug#714140: pu: package tgt/1.0.17-1
On 09/30/2013 06:48 AM, Cyril Brulebois wrote: > Hi Thomas, > > Thomas Goirand (2013-06-26): >> Dear release team, >> >> Wheezy has been released with a version of tgt which doesn't have an init >> script. I fixed the version in Sid on the 2013-05-21 (adding the missing >> init.d script). >> >> Now, I would like to upload a fix for Wheezy. The debdiff between >> 1:1.0.17-1 and 1:1.0.17-1.1 is attached. >> >> Would you allow me to upload the fixed tgt package into s-p-u? > > if I get the picture right, that package reached the archive on 2011-06-21 > but no bug was reported about that missing init script, and that was only > implemented on 2013-05-21. It doesn't appear to have been a huge lack, so > I don't think it's worse a stable upload. Waiting a bit to see if other > team members disagree. > > Mraw, > KiBi. Hi, Thanks for reviewing this PU bug. I'm very surprised that dates of bug reports come into consideration here. I don't see why they should. In fact, that's one more reason why we should speed up things: it has taken really too long to fix already. A missing init script is very annoying for our users. So I do think it's worse it. I personally would not use the Stable package if it doesn't include a correct init script, and it seems I'm not alone thinking this way. I had to point some TGT users to my corrected package in a private Debian repository. I would like to avoid doing this in the future: explaining that Debian can't fix such an issue within 9 months after the release doesn't feel great. Also, I don't see how adding an init script makes it a disruptive or dangerous patch. It has been successfully tested by many already, including Julien Cristau who is the original author of it (IIRC, I just added a few things in the script, but that's too long ago, so I wouldn't be able to tell what I added). I would find it very disappointing if Debian couldn't address this kind of issue in an existing package in the stable distribution, only because the release team think "it's not worse a stable upload". I already find it frustrating that it has taken 3 months to get an answer to this pu bug (even though I understand everyone is busy...). Cheers, Thomas Goirand (zigo) -- 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/524920ce.1080...@debian.org
NEW changes in stable-new
Processing changes file: libdigest-sha-perl_5.71-2+deb7u1_mipsel.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/e1vqxg5-000470...@franck.debian.org
NEW changes in oldstable-new
Processing changes file: tntnet_1.6.3-4+deb6u1_mipsel.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/e1vqxgy-0004ev...@franck.debian.org
NEW changes in stable-new
Processing changes file: tntnet_2.1-2+deb7u1_armhf.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/e1vqxub-0006ea...@franck.debian.org
Please hint TeX Live packages into testing
Dear release managers, the TeX Live packages seem to be stuck in sid, the excuses pages list all of them as valid candidates (texlive-bin/base/lang) but none of it has transitioned to testing after 12 days. Could you please hint them into testing. Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- 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/20130930075622.ga17...@gamma.logic.tuwien.ac.at
Re: Please hint TeX Live packages into testing
On 2013-09-30 09:56, Norbert Preining wrote: > Dear release managers, > > the TeX Live packages seem to be stuck in sid, the excuses pages > list all of them as valid candidates (texlive-bin/base/lang) > but none of it has transitioned to testing after 12 days. > > Could you please hint them into testing. > > Thanks > > Norbert > > [...] Hi, I have added a hint for it. ~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/52492fe9.80...@thykier.net
Re: Please hint TeX Live packages into testing
Hi Niels, > I have added a hint for it. Thanks for the prompt action, great! Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- 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/20130930080408.gc17...@gamma.logic.tuwien.ac.at
Re: Roll call for porters of architectures in sid and testing
Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For hurd-i386, I - maintain buildds (as a backup) I am a DD. Michael Banck signature.asc Description: Digital signature
Bug#709028: marked as done (nmu: linphone_3.5.2-10)
Your message dated Mon, 30 Sep 2013 10:44:33 +0200 with message-id <20130930084433.gm8...@betterave.cristau.org> and subject line Re: Bug#709028: nmu: linphone_3.5.2-10 has caused the Debian Bug report #709028, regarding nmu: linphone_3.5.2-10 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.) -- 709028: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709028 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please schedule a binNMU for linphone. It's one of the last two packages still depending on libexosip2-7. (The other is sipwitch which currently fails to build, #707450.) nmu linphone_3.5.2-10 . ALL . -m "Rebuild against libexosip2-10." Ansgar --- End Message --- --- Begin Message --- On Mon, May 20, 2013 at 12:59:44 +0200, Ansgar Burchardt wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Please schedule a binNMU for linphone. It's one of the last two packages still > depending on libexosip2-7. (The other is sipwitch which currently fails to > build, #707450.) > > nmu linphone_3.5.2-10 . ALL . -m "Rebuild against libexosip2-10." > This is probably obsolete by now. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Processed: Re: Bug#712604: nmu: python-scientific_2.9.2-4
Processing control commands: > tag -1 moreinfo Bug #712604 [release.debian.org] nmu: python-scientific_2.9.2-4 Added tag(s) moreinfo. -- 712604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712604 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b712604.1380530795408.transcr...@bugs.debian.org
Bug#712604: nmu: python-scientific_2.9.2-4
Control: tag -1 moreinfo On Mon, Jun 17, 2013 at 22:04:27 +0200, Picca Frédéric-Emmanuel wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Hello > > It seems that with the latest python the extensions are expected to be under > /usr/lib/python2.x/site-package//gnukfreebsd9 instead of > gnukfreebsd8 (when the package was uploaded) > the first effect is that the package is broken under kfreebsd but also that > it cause FTBFS for other packages. > like the current state of mmtk. > > I do not know if other packages are affected by this problem, and I do not > know if this nmu is the > right way to deal with this issue. > I am trying to find a better to way to deal with this with the upstream (move > the Extension in the right > namespace instead of building this kind of Extension) > Where is the version number picked? If it depends on the running kernel on the build/runtime host then this needs to be fixed properly, not worked around with binNMUs on kernel version changes. Cheers, Julien signature.asc Description: Digital signature
Bug#723953: marked as done (nmu: gtk+3.0_3.8.4-1)
Your message dated Mon, 30 Sep 2013 10:35:49 +0200 with message-id <20130930083549.gl8...@betterave.cristau.org> and subject line Re: Bug#723953: nmu: gtk+3.0_3.8.4-1 has caused the Debian Bug report #723953, regarding nmu: gtk+3.0_3.8.4-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.) -- 723953: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723953 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please schedule a binNMU for gtk+3.0 so the -udeb gets a proper depdency on libatk-bridge2.0-0-udeb, which has been added in the mean time. nmu gtk+3.0_3.8.4-1 . ALL . -m "Rebuild against libatk-bridge2.0-0-udeb. Closes: #723557" -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On Sat, Sep 21, 2013 at 17:47:53 +0200, Cyril Brulebois wrote: > Michael Biebl (2013-09-21): > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > Please schedule a binNMU for gtk+3.0 so the -udeb gets a proper depdency > > on libatk-bridge2.0-0-udeb, which has been added in the mean time. > > > > nmu gtk+3.0_3.8.4-1 . ALL . -m "Rebuild against libatk-bridge2.0-0-udeb. > > Closes: #723557" > > FWIW, while it shouldn't hurt to get that fixed, that won't be > sufficient for it to be installable just yet, because of #723948 > which I've just filed. > Should be good enough to have that fixed with the next upload then. d-i doesn't yet use gtk3 anyway. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Processed: Re: Bug#714355: nmu: djview4_4.9-3
Processing control commands: > tags -1 moreinfo Bug #714355 [release.debian.org] nmu: djview4_4.9-3 Added tag(s) moreinfo. -- 714355: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714355 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b714355.13805310922121.transcr...@bugs.debian.org
Bug#712771: nmu: dynare_4.3.3-4 vips_7.28.5-1 nip2_7.28.4-1
On Wed, Jun 19, 2013 at 13:13:10 +0200, Sébastien Villemot wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-CC: sylves...@debian.org > > Dear Release Team, > > In order to complete the ongoing libmatio transition, the following binNMUs > are > needed: > > nmu dynare_4.3.3-4 . armel sparc . -m "Rebuild against libmatio-dev >= 1.5" > nmu vips_7.28.5-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" > nmu nip2_7.28.4-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" > Looks like these got sourceful uploads in the mean time, but vips FTBFS on armhf. Can this be sorted? (Getting the FTBFS tracked in the BTS would be a good first step :) ) Cheers, Julien signature.asc Description: Digital signature
Bug#714355: nmu: djview4_4.9-3
Control: tags -1 moreinfo On Fri, Jun 28, 2013 at 10:45:51 +0100, Barak A. Pearlmutter wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu djview4_4.9-3 . ALL . -m "unify libtiff dependency, thanks to Harald > Jenny for noting the issue" > What does that mean? What issue? Cheers, Julien signature.asc Description: Digital signature
Bug#715043: marked as done (nmu: omake_0.9.8.5-3-8)
Your message dated Mon, 30 Sep 2013 10:54:11 +0200 with message-id <20130930085411.gq8...@betterave.cristau.org> and subject line Re: Bug#715043: nmu: omake_0.9.8.5-3-8 has caused the Debian Bug report #715043, regarding nmu: omake_0.9.8.5-3-8 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.) -- 715043: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715043 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu omake_0.9.8.5-3-8 . ALL . -m "Rebuild against current libfam0." adequate omake reports: adequate: ldd -r /usr/bin/omake: /usr/bin/omake: Symbol `FamErrlist' has different size in shared object, consider re-linking So let's rebuild this against the current libfam0 ... Andreas --- End Message --- --- Begin Message --- On Fri, Jul 5, 2013 at 19:34:44 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu omake_0.9.8.5-3-8 . ALL . -m "Rebuild against current libfam0." > > adequate omake reports: > > adequate: ldd -r /usr/bin/omake: /usr/bin/omake: Symbol `FamErrlist' has > different size in shared object, consider re-linking > > So let's rebuild this against the current libfam0 ... > NAK, sorry. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#715223: marked as done (nmu: libaws_2.10.2-4)
Your message dated Mon, 30 Sep 2013 10:55:08 +0200 with message-id <20130930085508.gr8...@betterave.cristau.org> and subject line Re: Bug#715223: nmu: libaws_2.10.2-4 has caused the Debian Bug report #715223, regarding nmu: libaws_2.10.2-4 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.) -- 715223: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715223 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libaws_2.10.2-4 . ALL . -m "Rebuild in a current sid environment." adequate reports adequate: ldd -r /usr/bin/ada2wsdl: /usr/bin/ada2wsdl: Symbol `asis__errors__error_kindsS' has different size in shared object, consider re-linking adequate: ldd -r /usr/bin/ada2wsdl: /usr/bin/ada2wsdl: Symbol `a4g__int_knds__internal_element_kindsN' has different size in shared object, consider re-linking adequate: ldd -r /usr/bin/ada2wsdl: /usr/bin/ada2wsdl: Symbol `a4g__int_knds__internal_element_kindsS' has different size in shared object, consider re-linking This seems to be caused by libasis2010 and another library, but none has changed recently. Rebuild anyway to fix this. Andreas --- End Message --- --- Begin Message --- On Sun, Jul 7, 2013 at 07:24:19 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu libaws_2.10.2-4 . ALL . -m "Rebuild in a current sid environment." > > adequate reports > > adequate: ldd -r /usr/bin/ada2wsdl: /usr/bin/ada2wsdl: Symbol > `asis__errors__error_kindsS' has different size in shared object, consider > re-linking > adequate: ldd -r /usr/bin/ada2wsdl: /usr/bin/ada2wsdl: Symbol > `a4g__int_knds__internal_element_kindsN' has different size in shared object, > consider re-linking > adequate: ldd -r /usr/bin/ada2wsdl: /usr/bin/ada2wsdl: Symbol > `a4g__int_knds__internal_element_kindsS' has different size in shared object, > consider re-linking > > This seems to be caused by libasis2010 and another library, but none has > changed recently. Rebuild anyway to fix this. > I don't think this warrants a rebuild. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#715458: marked as done (nmu: condor_7.8.7~dfsg.1-1)
Your message dated Mon, 30 Sep 2013 10:56:40 +0200 with message-id <20130930085640.gs8...@betterave.cristau.org> and subject line Re: Bug#715458: nmu: condor_7.8.7~dfsg.1-1 has caused the Debian Bug report #715458, regarding nmu: condor_7.8.7~dfsg.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.) -- 715458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715458 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu condor_7.8.7~dfsg.1-1 . ALL . experimental . -m "Rebuild against libgsoap3." libgsoap2 is only in stable, rendering condor uninstallable in experimental. Andreas --- End Message --- --- Begin Message --- On Tue, Jul 9, 2013 at 10:55:15 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu condor_7.8.7~dfsg.1-1 . ALL . experimental . -m "Rebuild against > libgsoap3." > > libgsoap2 is only in stable, rendering condor uninstallable in > experimental. > condor is no longer in experimental. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#714140: pu: package tgt/1.0.17-1
[ Dropping -release, which gets this conversation through the bug already. ] Thomas Goirand (2013-09-30): > I'm very surprised that dates of bug reports come into consideration > here. I don't see why they should. In fact, that's one more reason why > we should speed up things: it has taken really too long to fix already. The idea is to figure out on which side of the balance between fixing things and risking breaking things we are. The fact that nobody bothered reporting this issue for so long seems to point out it isn't a showstopper. (Also, assuming both of us meant "worth" below.) > A missing init script is very annoying for our users. So I do think > it's worse it. I personally would not use the Stable package if it > doesn't include a correct init script, and it seems I'm not alone > thinking this way. I had to point some TGT users to my corrected > package in a private Debian repository. I would like to avoid doing > this in the future: explaining that Debian can't fix such an issue > within 9 months after the release doesn't feel great. How can you explain nobody reported the missing script for so long? > Also, I don't see how adding an init script makes it a disruptive or > dangerous patch. It has been successfully tested by many already, > including Julien Cristau who is the original author of it (IIRC, I > just added a few things in the script, but that's too long ago, so I > wouldn't be able to tell what I added). There's no authoring info whatsoever, and no bug report to track what happened, so that's not too nice… Besides, we already saw dependency loop issues when init scripts got added or modified, so yes, it can be dangerous. > I would find it very disappointing if Debian couldn't address this > kind of issue in an existing package in the stable distribution, only > because the release team think "it's not worse a stable upload". I > already find it frustrating that it has taken 3 months to get an > answer to this pu bug (even though I understand everyone is busy...). Yes, we could probably do better on the pu reply latency front. But that's orthogonal to the actual decision (which I already said I was waiting feedback from other team members for, so I'll be quiet now). Mraw, KiBi. signature.asc Description: Digital signature
Bug#722897: marked as done (nmu: openscap_0.9.8-2, mrs_6.0.4+dfsg-1)
Your message dated Mon, 30 Sep 2013 11:03:15 +0200 with message-id <20130930090315.gt8...@betterave.cristau.org> and subject line Re: Bug#722897: nmu: openscap_0.9.8-2, mrs_6.0.4+dfsg-1 has caused the Debian Bug report #722897, regarding nmu: openscap_0.9.8-2, mrs_6.0.4+dfsg-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.) -- 722897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722897 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu openscap_0.9.8-2 . amd64 . -m "Rebuild against perl 5.18" nmu mrs_6.0.4+dfsg-1 . amd64 . -m "Rebuild against perl 5.18" The maintainer uploads were done against perl 5.14 in parallel to the ongoing perl 5.18 transition. Andreas --- End Message --- --- Begin Message --- On Sat, Sep 14, 2013 at 12:53:55 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu openscap_0.9.8-2 . amd64 . -m "Rebuild against perl 5.18" > nmu mrs_6.0.4+dfsg-1 . amd64 . -m "Rebuild against perl 5.18" > > The maintainer uploads were done against perl 5.14 in parallel to > the ongoing perl 5.18 transition. > AFAICT this got sorted. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#711551: pu: package redmine/1.4.4+dfsg1-2
On 30/09/2013 00:42, Cyril Brulebois wrote: > Control: tag -1 -moreinfo +confirmed > > Jérémy Lal (2013-06-10): >> --- redmine-1.4.4+dfsg1/debian/changelog 2013-01-19 15:54:09.0 >> +0100 >> +++ redmine-1.4.4+dfsg1/debian/changelog 2013-06-10 01:01:48.0 >> +0200 >> @@ -1,3 +1,14 @@ >> +redmine (1.4.4+dfsg1-2+deb7u1) proposed-updates; urgency=low > > Even though that would work, I'd be happy to see "wheezy" in there, > which can be useful after a while to figure out which suite was targeted > at that point (without having to look at the version number, and its > meaning). Do you mean it'd be better to use "wheezy-proposed-updates" as distribution ? >> + [ Ondřej Surý ] >> + * Pull upstream fixes for Ruby 1.9 as default interpreter: >> ++ Use DateTime.parse as alternative to ParseDate.parsedate, >> + fixing time series and schedule SVG graphs. (Closes: #700754) >> ++ Use ::Time from global namespace, fixing REST Issue API. >> + (Closes: #79) > > Assuming the latter change doesn't break the Ruby 1.8 use case (and > doesn't need a dance similar to the respond_to one in the former), > please upload (with or without an edit for the above mentioned point). I'm going to recheck that because i only remember doing it on irb, not on redmine code. Thanks for looking into this. Jérémy. -- 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/52493e3f.4090...@melix.org
Re: automake transition breakages
Hi Eric, On Mon, Sep 30, 2013, at 4:50, Eric Dorland wrote: > * Ondřej Surý (ond...@sury.org) wrote: > > Hi, > > > > recent automake transition to 1.14 broke (FTBFS) at least two of my > > packages. > > > > Would it be possible to coordinate the (next) transition better than > > upload&deal with breakages like we do with the rest of our packages? > > Did the transition from automake 1.13 to automake 1.14 cause your > package to FTBFS? Can you point me at logs because that's not supposed > to happen under the new versioning scheme upstream is following (ie > 1.X versions should now be backwards compatible). > > If you were going from an earlier version to 1.14 (or 1.13) I have > seen a few reports of problems with unit test framework. I have seen these two breakages (so far): libgd2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724841 gyrus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724917 both packages has been successfully built in wheezy (gyrus) or jessie (libgd2). > Right now the automake package is always tracking the latest upstream > version and new versions sometimes break things. If you're worried > about that kind of breakage then build depending on a specific version > of automake might be a better bet. If people don't like this current > scheme we can discuss if the current scheme is a bad idea. I am not worried about the scheme, but about the process. I don't know if this was an one time fling, or it will happen more frequently, but if the updates starts breaking things more often then uploading the new automake version to experimental and then trying to rebuild (at least part of) the archive, or adding an lintian checks, etc. would be a good way how to improve the process. But maybe I am just an exception to the rule with my two out of ~80 packages breaking. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- 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/1380532166.5916.28054821.3053b...@webmail.messagingengine.com
Bug#711551: pu: package redmine/1.4.4+dfsg1-2
Jérémy Lal (2013-09-30): > > Jérémy Lal (2013-06-10): > >> --- redmine-1.4.4+dfsg1/debian/changelog 2013-01-19 15:54:09.0 > >> +0100 > >> +++ redmine-1.4.4+dfsg1/debian/changelog 2013-06-10 01:01:48.0 > >> +0200 > >> @@ -1,3 +1,14 @@ > >> +redmine (1.4.4+dfsg1-2+deb7u1) proposed-updates; urgency=low > > > > Even though that would work, I'd be happy to see "wheezy" in there, > > which can be useful after a while to figure out which suite was targeted > > at that point (without having to look at the version number, and its > > meaning). > > Do you mean it'd be better to use "wheezy-proposed-updates" as distribution ? That or just "wheezy" :-) > > Assuming the latter change doesn't break the Ruby 1.8 use case (and > > doesn't need a dance similar to the respond_to one in the former), > > please upload (with or without an edit for the above mentioned point). > > I'm going to recheck that because i only remember doing it on irb, > not on redmine code. Thanks for that. Mraw, KiBi. signature.asc Description: Digital signature
NEW changes in stable-new
Processing changes file: perl_5.14.2-21+deb7u1_armel.changes ACCEPT Processing changes file: tntnet_2.1-2+deb7u1_mipsel.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/e1vqa4k-0007hn...@franck.debian.org
Re: Please hint TeX Live packages into testing
On 2013-09-30 10:04, Norbert Preining wrote: > Hi Niels, > >> I have added a hint for it. > > Thanks for the prompt action, great! > > Norbert > > [...] For the record, the hint was successful and you should receive a mail about the package having migrated later today (in about 5 hours, if my memory serves). ~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/52494ee9.3000...@thykier.net
NEW changes in stable-new
Processing changes file: libdigest-sha-perl_5.71-2+deb7u1_mips.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/e1vqaxk-00075r...@franck.debian.org
NEW changes in oldstable-new
Processing changes file: tntnet_1.6.3-4+deb6u1_powerpc.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/e1vqaxp-0007iy...@franck.debian.org
NEW changes in stable-new
Processing changes file: tntnet_2.1-2+deb7u1_powerpc.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/e1vqalq-0003xu...@franck.debian.org
NEW changes in stable-new
Processing changes file: perl_5.14.2-21+deb7u1_armhf.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/e1vqb0n-0008qj...@franck.debian.org
NEW changes in stable-new
Processing changes file: perl_5.14.2-21+deb7u1_mipsel.changes ACCEPT Processing changes file: perl_5.14.2-21+deb7u1_powerpc.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/e1vqbes-0002n7...@franck.debian.org
Re: automake transition breakages
Hi! On Mon, 2013-09-30 at 11:09:26 +0200, Ondřej Surý wrote: > I have seen these two breakages (so far): > > libgd2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724841 This uses -Werror in AM_INIT_AUTOMAKE, don't do that. > gyrus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724917 (gweled) This one is calling autoreconf in debian/rules w/o --install (or --force), and as such will miss needed scripts at build time. I don't see any problem with automake here, just upstream or packaging problems. Thanks, Guillem -- 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/20130930132009.ga15...@gaara.hadrons.org
Updating xloadimage to libtiff5
Hi, I have prepared xloadimage for upload to assume maintainership for it, and the PTS tells me I should prepare it for the libtiff5 transition. My understanding is that I should make it build against libtiff5 rather than libtiff4, and that is what I did. My understanding is that this will bring forward the transition. However, my sponsor says that the libtiff5 transition means that I must under no circumstances upload any changes that deal with libtiff. Could you please explain to me what is the correct way of dealing with the libtiff5 transition? Cheers, Nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Updating xloadimage to libtiff5
Hi, > My understanding is that I should make it build against libtiff5 rather > than libtiff4, and that is what I did. My understanding is that this > will bring forward the transition. another DD now explained to me that problems may arise with library packages that have reverse dependencies, because those might break when I rebuild against libtiff5. However, as xloadimage is a leaf package, except for electricsheep, which most likely does not use xloadimage as a dynamic object, I was told that the change might not be critical. I thus ask for permission to have xloadimage with a libtiff5 dependency uploaded. Cheers, Nik -- # apt-assassinate --help Usage: apt-assassinate [upstream|maintainer] PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Updating xloadimage to libtiff5
On 2013-09-30 15:50, Dominik George wrote: > Hi, > > I have prepared xloadimage for upload to assume maintainership for it, > and the PTS tells me I should prepare it for the libtiff5 transition. > > My understanding is that I should make it build against libtiff5 rather > than libtiff4, and that is what I did. My understanding is that this > will bring forward the transition. > > However, my sponsor says that the libtiff5 transition means that I must > under no circumstances upload any changes that deal with libtiff. > > Could you please explain to me what is the correct way of dealing with > the libtiff5 transition? > > Cheers, > Nik > Hi, In your "average transition", ensuring your package in sid can be rebuilt against the (new) version of the library and is able to migrate is desirable[1]. Failing that, being ready to upload a patched version that builds against the new version of the library (and otherwise be ready to migrate, see [1]) is a good fallback. Once the transition starts, packages should be rebuild (usually binNMUs or, where those fail/does not work, sourceful uploads). After that, we prefer to wait for binaries to migrate. Once testing contains the rebuild binaries, packages are usually (but not always) out of the transition. We consider a transition complete when the old shared library package has been removed from testing (in this case, that would be libtiff4). Now, I am not sure tiff counts as your "average transition". Since it involves two source packages instead of just one. If your (patched) package can be build against either the new or the old version of libtiff, then I suspect an upload is not a problem at this time. But disclaimer; I am not in charge of that transition[2]. ~Niels [1] It should not introduce new RC bugs, have out of date binaries etc. [2] Actually, I am not sure anyone of us have picked it up yet. -- 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/52498921.5070...@thykier.net
Re: Updating xloadimage to libtiff5
Hi Niels, > Now, I am not sure tiff counts as your "average transition". Since it > involves two source packages instead of just one. If your (patched) > package can be build against either the new or the old version of > libtiff, then I suspect an upload is not a problem at this time. That means, I should Build-Depend on neither libtiff4-dev or libtiff5-dev, but libtiff-dev, and patch hthe code so it builds with either? Or is it ok to have the code build only against libtiff5-dev, and depend on that one explicitly? -nik -- Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Updating xloadimage to libtiff5
On 2013-09-30 16:29, Dominik George wrote: > Hi Niels, > >> Now, I am not sure tiff counts as your "average transition". Since it >> involves two source packages instead of just one. If your (patched) >> package can be build against either the new or the old version of >> libtiff, then I suspect an upload is not a problem at this time. > > That means, I should Build-Depend on neither libtiff4-dev or > libtiff5-dev, but libtiff-dev, and patch hthe code so it builds with > either? Or is it ok to have the code build only against libtiff5-dev, > and depend on that one explicitly? > > -nik > Let me clarify, "build against either" here being the source code can compile against either (not having Build-Depends that allow either). > another DD now explained to me that problems may arise with library > packages that have reverse dependencies, because those might break when > I rebuild against libtiff5. However, as xloadimage is a leaf package, > except for electricsheep, which most likely does not use xloadimage as a > dynamic object, I was told that the change might not be critical. electricsheep does not appear to link against libtiff either. :) I think three is one final argument that you have omitted for this to make sense. That is, xloadimage should not have any dependencies which are linked against libtiff (otherwise, you could have xloadimage linked against libtiff5 and $dependency linked against libtiff4 => "$fun"). That said, I'll leave it to more experienced members to review the situation and give you the actual "ack" or "nack". ~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/52498ce0.9030...@thykier.net
Re: Updating xloadimage to libtiff5
Hi, > Let me clarify, "build against either" here being the source code can > compile against either (not having Build-Depends that allow either). Huh? That means, if I Build-Depend on libtiff5-dev, it still has to build against libtiff4? I do not get that… Cheers, Nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Bug#723641: pu: package xen/4.1.4-5
On Mon, September 23, 2013 10:47, Bastian Blank wrote: > On Mon, Sep 23, 2013 at 09:47:32AM +0200, Thijs Kinkhorst wrote: >> Do you have a message ID for me? I'd rather try to see what the problems >> with the wheezy-security route are and how we can resolve them, rather >> than try to work around them via pu. > > <20130512113628.GA16136@elende> > <20130512200941.ga10...@waldi.eu.org> Thanks. I've read them. My conclusion is that there are two problems: 1/ On a previous upload, someone from the security team added extra changes without coordination or reporting them back. 2/ It took long to process the upload and there was no feedback on problems. Agreed? On the first point, although I don't know exactly what changes were added by whom, I fully agree that if such is the case that's not good and understanding that it's annoying to you. I'm sure that we can agree that this was a mistake and that this should not happen again. The second point is indeed unfortunate, reading back it seems related to two different problems with DAK. I have no ready-made solution for this. The DAK instance we use is not run by us so we cannot influence the shortcomings it has, we'll just have to work with them the best we can and hope for the hard work of ftpmaster to solve issues when they pop up. I'm sure we can do better with keeping you posted about any delay, and I hope you would ping us (on irc for example) if you expected a response but it's not there yet. Given the limitations of tools and manpower and the large number of issues that we need to deal with, the process will probably never be perfect. But I hope that when a bumb arises we can just talk directly on irc to avoid misunderstandings and frustraction. Do you think we could just try to start anew? In the end it benefits our users most if Xen updates would come through the security channel. Cheers, Thijs -- 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/6367f639a63007fb478955437c644c71.squir...@aphrodite.kinkhorst.nl
Re: automake transition breakages
* Guillem Jover (guil...@debian.org) wrote: > Hi! > > On Mon, 2013-09-30 at 11:09:26 +0200, Ondřej Surý wrote: > > I have seen these two breakages (so far): > > > > libgd2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724841 > > This uses -Werror in AM_INIT_AUTOMAKE, don't do that. Ah yes, this has bitten a few other people as several new warnings have been added in the last couple of releases so this is basically guaranteed to cause a failure. > > gyrus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724917 > > (gweled) > > This one is calling autoreconf in debian/rules w/o --install (or > --force), and as such will miss needed scripts at build time. > > > I don't see any problem with automake here, just upstream or packaging > problems. Thanks for the analysis Guillem. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: Updating xloadimage to libtiff5
On 2013-09-30 16:40, Dominik George wrote: > Hi, > >> Let me clarify, "build against either" here being the source code can >> compile against either (not having Build-Depends that allow either). > > Huh? That means, if I Build-Depend on libtiff5-dev, it still has to > build against libtiff4? I do not get that… > > Cheers, > Nik > I meant, you upload your package built against libtiff4-dev, which is the status quo. However, you do a build-test where you swap libtiff4-dev with libtiff5-dev to see if your package would compile if libtiff5-dev had been used instead of libtiff4-dev. So when the time comes, all you have to do, is to swap libtiff4-dev with libtiff5-dev. I believe we prefer having unversioned -dev packages and the "new" version in experimental. Had the tiff-transition been like that, I would have asked you to prepare for the transition by testing your package against the version of libtiff that would have been in experimental. ~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/52498f5d.2030...@thykier.net
Re: Updating xloadimage to libtiff5
Hi, > I meant, you upload your package built against libtiff4-dev, which is > the status quo. However, you do a build-test where you swap > libtiff4-dev with libtiff5-dev to see if your package would compile if > libtiff5-dev had been used instead of libtiff4-dev. So when the time > comes, all you have to do, is to swap libtiff4-dev with libtiff5-dev. I conclude from that, that I should *in general* not use libtiff5-dev right now? Having a apckage build *only* against libtiff5-dev is not acceptable, although the package is there and already has dependencies? I'd like to get a clear answer from the release team, if I: a) should upload the package without touching anything libtiff-related, b) should upload the package with a versioned libtiff5 dependency, c) should patch the code to build against both and use an unversioned Build-Depends. Cheers, Nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Updating xloadimage to libtiff5
> I conclude from that, that I should *in general* not use libtiff5-dev > right now? Having a apckage build *only* against libtiff5-dev is not > acceptable, although the package is there and already has dependencies? I should add that I plan to implement a new feature in xloadimage, which will not work with libtiff4-dev anyway, so as of then xloadimage would need libtiff5 anyway. -nik -- Auf welchem Server liegt das denn jetzt…? Wenn es nicht übers Netz kommt bei Hetzner, wenn es nicht gelesen wird bei STRATO, wenn es klappt bei manitu. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: automake transition breakages
* Ondřej Surý (ond...@sury.org) wrote: > Hi Eric, > > On Mon, Sep 30, 2013, at 4:50, Eric Dorland wrote: > > * Ondřej Surý (ond...@sury.org) wrote: > > > Hi, > > > > > > recent automake transition to 1.14 broke (FTBFS) at least two of my > > > packages. > > > > > > Would it be possible to coordinate the (next) transition better than > > > upload&deal with breakages like we do with the rest of our packages? > > > > Did the transition from automake 1.13 to automake 1.14 cause your > > package to FTBFS? Can you point me at logs because that's not supposed > > to happen under the new versioning scheme upstream is following (ie > > 1.X versions should now be backwards compatible). > > > > If you were going from an earlier version to 1.14 (or 1.13) I have > > seen a few reports of problems with unit test framework. > > I have seen these two breakages (so far): > > libgd2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724841 > gyrus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724917 > > both packages has been successfully built in wheezy (gyrus) or jessie > (libgd2). > > > Right now the automake package is always tracking the latest upstream > > version and new versions sometimes break things. If you're worried > > about that kind of breakage then build depending on a specific version > > of automake might be a better bet. If people don't like this current > > scheme we can discuss if the current scheme is a bad idea. > > I am not worried about the scheme, but about the process. > > I don't know if this was an one time fling, or it will happen more > frequently, but if the updates starts breaking things more often then > uploading the new automake version to experimental and then trying to > rebuild (at least part of) the archive, or adding an lintian checks, > etc. would be a good way how to improve the process. Doing a rebuild is something I could try for next time. I'm not really familiar with how to do that though, can you point me in the right direction? What sort of lintian checks did you have in mind? > But maybe I am just an exception to the rule with my two out of ~80 > packages breaking. > > Ondrej -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#724306: Bug #724306: pu: package dpkg/1.16.11
Hi!
On Sat, 2013-09-28 at 08:13:29 +0100, Adam D. Barratt wrote:
> Control: tags -1 + pending
>
> On Sat, 2013-09-28 at 05:47 +0200, Guillem Jover wrote:
> > On Thu, 2013-09-26 at 05:37:30 +0100, Adam D. Barratt wrote:
> > > On Thu, 2013-09-26 at 04:46 +0200, Guillem Jover wrote:
> > > > On Tue, 2013-09-24 at 19:47:16 +0100, Adam D. Barratt wrote:
> > > > > This looks okay overall; thanks. I'm assuming that the changes have
> > > > > been
> > > > > tested on a stable system, particularly the Replaces.
> > > >
> > > > Yes. Let me know if and when you want this uploaded to the stable
> > > > queue.
> > >
> > > Please feel free to go ahead.
> >
> > Done, thanks!
>
> Flagged for acceptance.
Thanks, unfortunately 724949 just came in a day after the upload, it
involves improper caching of the «dpkg --print-architecture» and
«gcc -dumpmachine» output, affecting the performance of wanna-build.
This was already fixed in 1.17.0, so it has been tested for a while.
I was wondering if you'd be fine with a quick 1.16.12 upload, with the
attached diff?
(Just for future reference, would you have preferred a separate bug
report?)
Thanks,
Guillem
diff --git a/debian/changelog b/debian/changelog
index a8c0c87..1f4d107 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dpkg (1.16.12) stable; urgency=low
+
+ * Fix value caching in Dpkg::Arch by not shadowing the variables.
+Closes: #724949
+
+ -- Guillem Jover Mon, 30 Sep 2013 16:52:37 +0200
+
dpkg (1.16.11) stable; urgency=low
[ Raphaël Hertzog ]
diff --git a/scripts/Dpkg/Arch.pm b/scripts/Dpkg/Arch.pm
index bfc19f4..bfee423 100644
--- a/scripts/Dpkg/Arch.pm
+++ b/scripts/Dpkg/Arch.pm
@@ -59,7 +59,7 @@ my %debarch_to_debtriplet;
# dpkg-architecture itself, by avoiding computing the DEB_BUILD_
# variables when they are not requested.
- my $build_arch = `dpkg --print-architecture`;
+ $build_arch = `dpkg --print-architecture`;
syserr("dpkg --print-architecture failed") if $? >> 8;
chomp $build_arch;
@@ -75,7 +75,7 @@ my %debarch_to_debtriplet;
{
return $gcc_host_gnu_type if defined $gcc_host_gnu_type;
- my $gcc_host_gnu_type = `\${CC:-gcc} -dumpmachine`;
+ $gcc_host_gnu_type = `\${CC:-gcc} -dumpmachine`;
if ($? >> 8) {
$gcc_host_gnu_type = '';
} else {
commit dbe1c7762def447088c3d3a29eea0d7012af525f
Author: Guillem Jover
Date: Mon Sep 30 16:52:53 2013 +0200
Release 1.16.12
commit 8dafb822bb93de1ababd850360844986c9e0e900
Author: Guillem Jover
Date: Tue Jan 1 19:30:36 2013 +0100
Dpkg::Arch: Fix value caching by not shadowing the variables
Cherry picked from commit a64bfa733075a7140193f5a4b9d4292234dd230e.
The effect of not caching the values has a severe impact on
performance on code repeatedly calling (directly or indirectly)
the get_raw_build_arch() and get_raw_host_arch() functions.
Addresses Variables::ProhibitReusedNames.
Closes: #724949
Re: Roll call for porters of architectures in sid and testing
Apologies for delayed response - work trips and VAC got in the way a little. On Sun, Sep 01, 2013 at 09:33:51AM +0200, Niels Thykier wrote: > > >If you are (or intend to become) an active porter for the lifetime of >jessie, then please send a signed email explaining your involvement in >the port to the Release Team before >1st of October 2013. Please explain the level of your involvement in >the port. I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: armel, armhf, arm64 (still bootstrapping) For each architecture, I expect to - test some packages on this architecture - triage and fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - maintain buildds (local hw admin rather than buildd admin) I am a DD, and I am employed by ARM and working in Linaro, tasked with helping the arm* ports. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers" signature.asc Description: Digital signature
Proposed release goal: piuparts clean archive
Hi, On Mittwoch, 25. September 2013, Jonathan Wiltshire wrote: > To propose a goal, you should create a page on the wiki [WIKI] with a short > goal description, details of the advocate(s) and how the goal will be > achieved. I've now created https://wiki.debian.org/ReleaseGoals/piuparts which is still somewhat at a draft stage but OTOH it should be quite obvious. Is it really good enough like this, or what should we add there? And, more advocates and helpers would be helpful though, so please subscribe yourself there! cheers, Holger signature.asc Description: This is a digitally signed message part.
NEW changes in stable-new
Processing changes file: tntnet_2.1-2+deb7u1_mips.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/e1vqgoe-0004gt...@franck.debian.org
Re: automake transition breakages
On 30.09.2013 16:58, Eric Dorland wrote: > Doing a rebuild is something I could try for next time. I'm not really > familiar with how to do that though, can you point me in the right > direction? What sort of lintian checks did you have in mind? At minimum the packages using Werror should be test rebuilt before each new upload: http://codesearch.debian.net/search?q=AM_INIT_AUTOMAKE.*-Werror The list is small enough that it can be done by hand / small script. -- 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/5249ad15.40...@googlemail.com
Bug#723641: pu: package xen/4.1.4-5
On Mon, Sep 30, 2013 at 04:38:24PM +0200, Thijs Kinkhorst wrote: > Thanks. I've read them. My conclusion is that there are two problems: > 1/ On a previous upload, someone from the security team added extra > changes without coordination or reporting them back. > 2/ It took long to process the upload and there was no feedback on problems. > Agreed? No. This are symptoms, not problems. The main problem is _communication_. > On the first point, although I don't know exactly what changes were added > by whom, I fully agree that if such is the case that's not good and > understanding that it's annoying to you. I'm sure that we can agree that > this was a mistake and that this should not happen again. I don't think this will work. The current security process ignores any communitation that is otherwise part of the NMU process. As long as the security team does not have some policy to cummunicate first and do later, especially if the maintainer is already in the loop or, worse, did it herself, I see not why this should work now. > The second point is indeed unfortunate, reading back it seems related to > two different problems with DAK. My main problem are the missing mails on uploads. If the ftp-masters refuses to accept a patch---did they?---you have to do it by human relay. > Given the limitations of tools and manpower and the large number of issues > that we need to deal with, the process will probably never be perfect. If you lack manpower, why don't I remember any calls for help like the ftp-team or ctte did? All the cases in the last years actually made them _more_ work. Preparing and _testing_ a package is way more work then sending a mail "I don't like it, please …" or "I haven't seen an upload, I'll do it". > Do you think we could just try to > start anew? In the end it benefits our users most if Xen updates would > come through the security channel. There where three points in my mail … Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1 signature.asc Description: Digital signature
Bug#724254: nmu: gst-plugins-bad1.0_1.0.10-3 and yatm_0.8-1
Control: retitle -1 nmu: yatm_0.8-1 On 2013-09-23 02:38:30, Sebastian Ramacher wrote: > nmu gst-plugins-bad1.0_1.0.10-3 . armel . -m "Rebuild against soundtouch > 1.7.1-3" > nmu yatm_0.8-1 . armel . -m "Rebuild against soundtouch 1.7.1-3" gst-plugins-bad1.0 has been uploaded in the meantime. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Processed: Re: Bug#724254: nmu: gst-plugins-bad1.0_1.0.10-3 and yatm_0.8-1
Processing control commands: > retitle -1 nmu: yatm_0.8-1 Bug #724254 [release.debian.org] nmu: gst-plugins-bad1.0_1.0.10-3 and yatm_0.8-1 Changed Bug title to 'nmu: yatm_0.8-1' from 'nmu: gst-plugins-bad1.0_1.0.10-3 and yatm_0.8-1' -- 724254: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724254 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b724254.13805599654917.transcr...@bugs.debian.org
Bug#720426: pu: package openssl/1.0.1e-2
On Mon, Sep 30, 2013 at 01:46:41AM +0200, Cyril Brulebois wrote:
> Control: tag -1 moreinfo
>
> Kurt Roeckx (2013-09-23):
> > I actually consider the arm assembler and nistp curves to be
> > important, even if the bugs might only be filed at severity
> > level wishlist. The nistp curves are even security related
> > since they are then implemented with constant time removing
> > a side channel attack.
>
> Then the BTS should know, and/or you should have mentioned it in your
> pu request.
I wouldn't bother trying to get those to stable if I didn't think
they were important.
> You also didn't attach the source debdiff we should be
> considering, and a manual debdiff between -2 and -3 shows unrelated
> things.
For #698447 it's this part:
--- openssl-1.0.1e/debian/rules 2013-03-10 21:54:40.0 +0100
+++ openssl-1.0.1e/debian/rules 2013-05-20 17:06:14.0 +0200
@@ -26,6 +27,10 @@
OPTS = $($(ARCHOPTS))
WANTED_LIBC_VERSION = 2.3.1-10
+ifeq ($(DEB_HOST_ARCH_CPU), amd64)
+ CONFARGS += enable-ec_nistp_64_gcc_128
+endif
+
build: build-arch build-indep
build-arch: build-stamp
build-indep: build-stamp
For #676533 it's this part:
openssl-1.0.1.orig/Configure 2012-03-17 15:37:54.0 +
-+++ openssl-1.0.1/Configure2012-03-17 16:13:49.0 +
+--- openssl-1.0.1e.orig/Configure 2013-05-20 16:54:11.0 +0200
openssl-1.0.1e/Configure 2013-05-20 16:54:11.0 +0200
@@ -105,6 +105,10 @@
my $gcc_devteam_warn = "-Wall -pedantic -DPEDANTIC -Wno-long-long
-Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror
-DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED";
@@ -13,7 +13,7 @@
my $strict_warnings = 0;
my $x86_gcc_des="DES_PTR DES_RISC1 DES_UNROLL";
-@@ -338,6 +342,48 @@
+@@ -340,6 +344,48 @@
"osf1-alpha-cc", "cc:-std1 -tune host -O4
-readonly_strings::(unknown):::SIXTY_FOUR_BIT_LONG
RC4_CHUNK:${alpha_asm}:dlfcn:alpha-osf1-shared:::.so",
"tru64-alpha-cc", "cc:-std1 -tune host -fast
-readonly_strings::-pthread:::SIXTY_FOUR_BIT_LONG
RC4_CHUNK:${alpha_asm}:dlfcn:alpha-osf1-shared::-msym:.so",
@@ -21,9 +21,8 @@
+"debian-alpha","gcc:-DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1
DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-alpha-ev4","gcc:-DTERMIO ${debian_cflags}
-mcpu=ev4::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1
DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-alpha-ev5","gcc:-DTERMIO ${debian_cflags}
-mcpu=ev5::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1
DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"debian-armeb","gcc:-DB_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL
BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"debian-armel","gcc:-DL_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL
BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"debian-armhf","gcc:-DL_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL
BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"debian-armel","gcc:-DL_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL
BF_PTR:${armv4_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"debian-armhf","gcc:-DL_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL
BF_PTR:${armv4_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-amd64", "gcc:-m64 -DL_ENDIAN -DTERMIO ${debian_cflags}
-DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::",
+"debian-avr32", "gcc:-DB_ENDIAN -DTERMIO ${debian_cflags}
-fomit-frame-pointer::-D_REENTRANT::-ldl:BN_LLONG_BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-kfreebsd-amd64","gcc:-m64 -DL_ENDIAN -DTERMIOS ${debian_cflags}
-DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
@@ -58,6 +57,7 @@
+"debian-sparc-v8","gcc:-DB_ENDIAN -DTERMIO ${debian_cflags} -mcpu=v8
-DBN_DIV2W::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR:${sparcv8_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-sparc-v9","gcc:-DB_ENDIAN -DTERMIO ${debian_cflags} -mcpu=v9
-Wa,-Av8plus -DULTRASPARC -DBN_DIV2W::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR
RC4_CHUNK DES_UNROLL
BF_PTR:${sparcv9_asm}:dlfcn:linux-shared:-fPIC::.so.\$(
Bug#724306: Bug #724306: pu: package dpkg/1.16.11
On Mon, 2013-09-30 at 16:59 +0200, Guillem Jover wrote: > On Sat, 2013-09-28 at 08:13:29 +0100, Adam D. Barratt wrote: > > Flagged for acceptance. > > Thanks, unfortunately 724949 just came in a day after the upload, it > involves improper caching of the «dpkg --print-architecture» and > «gcc -dumpmachine» output, affecting the performance of wanna-build. > This was already fixed in 1.17.0, so it has been tested for a while. > > I was wondering if you'd be fine with a quick 1.16.12 upload, with the > attached diff? Yes, that looks okay. > (Just for future reference, would you have preferred a separate bug > report?) Where the changes are distinct from those in the original report, separate bug are definitely preferable; so in this case, yes. 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/1380563835.29203.11.ca...@jacala.jungle.funky-badger.org
Bug#724254: marked as done (nmu: yatm_0.8-1)
Your message dated Mon, 30 Sep 2013 19:01:33 +0100 with message-id <1380564093.29203.12.ca...@jacala.jungle.funky-badger.org> and subject line Re: Bug#724254: nmu: gst-plugins-bad1.0_1.0.10-3 and yatm_0.8-1 has caused the Debian Bug report #724254, regarding nmu: yatm_0.8-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.) -- 724254: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724254 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, libsoundtouch0 broke its ABI on armel in 1.7.1-1 (#723681). This got fixed in 1.7.1-3. After the upload of 1.7.1-2 to unstable, only gst-bplugins-bad1.0 and yatm have been built against the broken version of libsoundtouch0. Please binNMU these two packages on armel: nmu gst-plugins-bad1.0_1.0.10-3 . armel . -m "Rebuild against soundtouch 1.7.1-3" nmu yatm_0.8-1 . armel . -m "Rebuild against soundtouch 1.7.1-3" Regards -- Sebastian Ramacher signature.asc Description: Digital signature --- End Message --- --- Begin Message --- On Mon, 2013-09-30 at 18:52 +0200, Sebastian Ramacher wrote: > On 2013-09-23 02:38:30, Sebastian Ramacher wrote: > > nmu gst-plugins-bad1.0_1.0.10-3 . armel . -m "Rebuild against soundtouch > > 1.7.1-3" > > nmu yatm_0.8-1 . armel . -m "Rebuild against soundtouch 1.7.1-3" > > gst-plugins-bad1.0 has been uploaded in the meantime. yatm scheduled. Regards, Adam--- End Message ---
Bug#706798: transition: Libav 9
Control: unblock -1 by 694143 694131 718125 721148 721047 713197 720814 (Removing bugs of packages no longer in testing from the list of blocking bugs.) Some weeks have passed and we are down to the following bugs: #720783 dvswitch (with patch) #720796 gsteamer0.10-ffmpeg (patch WIP) #720816 openscenegraph #722486 spek #722610 yorick-av #723099 taoframework (with patch) vxl is affected by #718047. dvd-slideshow, dvdwizard, tribler and videotrans still depend on ffmpeg. dvd-slideshow would make a good removal candidate. #710411 is open since May and has not received a reply from the maintainer. dvdwizard and videotrans appear on the list of auto-removal candidates. tribler has been uploaded recently but still depends on ffmpeg. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Processed: Re: Bug#706798: transition: Libav 9
Processing control commands: > unblock -1 by 694143 694131 718125 721148 721047 713197 720814 Bug #706798 [release.debian.org] transition: Libav 9 706798 was blocked by: 694143 713354 722610 720828 694131 720801 721544 694299 720779 720785 721025 720727 723099 692505 720820 720796 693639 693641 720668 721577 692809 720790 720826 720799 720797 692980 720816 721026 677959 722486 693106 713276 722493 720823 718125 721148 721047 720809 693560 720783 720808 720805 720661 720810 720824 713197 723803 720814 721164 720802 721493 706798 was blocking: 716735 Removed blocking bug(s) of 706798: 694143, 713197, 721047, 694131, 718125, 721148, and 720814 -- 706798: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706798 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b706798.13805655993686.transcr...@bugs.debian.org
Bug#712771: nmu: dynare_4.3.3-4 vips_7.28.5-1 nip2_7.28.4-1
Le lundi 30 septembre 2013 à 10:50 +0200, Julien Cristau a écrit : > On Wed, Jun 19, 2013 at 13:13:10 +0200, Sébastien Villemot wrote: > > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > X-Debbugs-CC: sylves...@debian.org > > > > Dear Release Team, > > > > In order to complete the ongoing libmatio transition, the following binNMUs > > are > > needed: > > > > nmu dynare_4.3.3-4 . armel sparc . -m "Rebuild against libmatio-dev >= 1.5" > > nmu vips_7.28.5-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" > > nmu nip2_7.28.4-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" > > > Looks like these got sourceful uploads in the mean time, Indeed. You can therefore close this binnmu request, unless you want to keep it for tracking the status of libmatio transition. > but vips FTBFS > on armhf. Can this be sorted? (Getting the FTBFS tracked in the BTS > would be a good first step :) ) FTBFS reported as #725032. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Re: Please hint TeX Live packages into testing
On Mo, 30 Sep 2013, Niels Thykier wrote: > For the record, the hint was successful and you should receive a mail > about the package having migrated later today (in about 5 hours, if my > memory serves). THanks. Strangely enough I only got emails for tex-common and one more, but not for the texlive-*, although the debian-qa page lists them as already in testing. Anyway, all fine now ;-) Thanks a lot Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- 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/20130930184312.ga2...@gamma.logic.tuwien.ac.at
Bug#714140: pu: package tgt/1.0.17-1
Hi, Sorry, I didn't remember the exact details, now I do. There *was* a bug report earlier than you (and I) thought. On 09/30/2013 04:59 PM, Cyril Brulebois wrote: > [ Dropping -release, which gets this conversation through the bug > already. ] > > Thomas Goirand (2013-09-30): >> I'm very surprised that dates of bug reports come into consideration >> here. I don't see why they should. In fact, that's one more reason why >> we should speed up things: it has taken really too long to fix already. > > The idea is to figure out on which side of the balance between fixing > things and risking breaking things we are. The fact that nobody bothered > reporting this issue for so long seems to point out it isn't a > showstopper. > > (Also, assuming both of us meant "worth" below.) I believe you missed this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577925 This bug report was sent to the BTS in 2010. Here, we just had a careless maintainer, IMO, and *me* who didn't care about it until recently: others cared before I did and NMU-ed the package in Sid, at least these 5 other people in this bug report, including one who would have like it to be fixed in ... squeeze!!! >> A missing init script is very annoying for our users. So I do think >> it's worse it. I personally would not use the Stable package if it >> doesn't include a correct init script, and it seems I'm not alone >> thinking this way. I had to point some TGT users to my corrected >> package in a private Debian repository. I would like to avoid doing >> this in the future: explaining that Debian can't fix such an issue >> within 9 months after the release doesn't feel great. > > How can you explain nobody reported the missing script for so long? See above. >> Also, I don't see how adding an init script makes it a disruptive or >> dangerous patch. It has been successfully tested by many already, >> including Julien Cristau who is the original author of it (IIRC, I >> just added a few things in the script, but that's too long ago, so I >> wouldn't be able to tell what I added). > > There's no authoring info whatsoever, and no bug report to track what > happened, so that's not too nice… See above. > Besides, we already saw dependency > loop issues when init scripts got added or modified, so yes, it can be > dangerous. # Required-Start:$remote_fs $syslog # Required-Stop: $remote_fs $syslog # Should-Start: zfs # Should-Stop: zfs I don't see how this could do a dependency loop. >> I would find it very disappointing if Debian couldn't address this >> kind of issue in an existing package in the stable distribution, only >> because the release team think "it's not worse a stable upload". I >> already find it frustrating that it has taken 3 months to get an >> answer to this pu bug (even though I understand everyone is busy...). > > Yes, we could probably do better on the pu reply latency front. But > that's orthogonal to the actual decision Yes. Though that's not orthogonal to the frustration of not seeing things fixed fast enough in Debian. Cheers, Thomas Goirand (zigo) -- 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/5249ce06.3070...@debian.org
Re: Bug#724678: RM: flightgear [kfreebsd-*] -- RoM; ANAIS due to missing systemd
Hi, On 09/27/2013 10:44 PM, Michael Biebl wrote: > Am 27.09.2013 22:05, schrieb Steven Chamberlain: >> Control: block 724678 by 724686 >> >> On 26/09/13 15:34, Markus Wanner wrote: >>> as correctly reported by Rebecca N. Palmer, flightgear no longer builds >>> on kfreebsd-* (due to systemd dependency). Please remove the kfreebsd >>> variants of the flightgear binary package from testing. >> >> I'm a little concerned by this: >> >> * that a package can 'Build-Depend' on systemd seems rather odd, > > It build-depends on libudev-dev, which is not quite the same. Thanks for this correction. >> * that the package's removal is requested, AFAIK without mentioning this >> to debian-bsd@, or Cc'ing us on a FTBFS bug for example so that someone >> might take a look at this. Sorry, it's the first time I'm filing an RM request. I tried to follow the guidelines here: https://wiki.debian.org/ftpmaster_Removals Does it make sense to extend that to mention the procedure requested above (for port specific RMs, that is)? >> But thankfully Pino Toscano contributed a patch that can fix this, by >> simply changing the Build-Depends, therefore I hope the removal is not >> needed now: http://bugs.debian.org/724686 > > Does the package also actually work on non-Linux ? No idea. I'd appreciate testing. What's the status of accelerated 3D graphics on freebsd-*? > What I'm concerned about is, that we are building software which isn't > actually runnable. > A good example is gnome-shell, which takes a lot of effort to keep > building on non-Linux but ttbomk is totally non-functional on e.g. > kfreebsd. Removing software for those architectures is imho more honest. Agreed. Regards Markus Wanner signature.asc Description: OpenPGP digital signature
NEW changes in stable-new
Processing changes file: perl_5.14.2-21+deb7u1_mips.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/e1vqjcq-0007gh...@franck.debian.org
Bug#706798: transition: Libav 9
On Mon, Sep 30, 2013 at 20:26:30 +0200, Sebastian Ramacher wrote: > vxl is affected by #718047. > Why doesn't vxl stop using --as-needed? Cheers, Julien signature.asc Description: Digital signature
Bug#725043: pu: package mutt/1.5.21-6.2+deb7u1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I would like to update mutt in wheezy to fix a segfault (#626294) and
a data-loss (#721860) bug. Both patches have been in unstable since
13.09.2013 and noone complained so far.
The debdiff between -6.2 and -6.2+deb7u1 is attached.
Regards
Evgeni
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u mutt-1.5.21/debian/changelog mutt-1.5.21/debian/changelog
--- mutt-1.5.21/debian/changelog
+++ mutt-1.5.21/debian/changelog
@@ -1,3 +1,17 @@
+mutt (1.5.21-6.2+deb7u1) stable; urgency=low
+
+ * Non-maintainer upload with maintainer approval.
+ * Update 584138-mx_update_context-segfault.patch
+Stop segfaulting when listing folders with new mails over imap.
+Thanks: Nikolaus Schulz
+Closes: #626294
+ * Update features/imap_fast_trash
+Don't send saved messages to trash
+Thanks: Chow Loong Jin
+Closes: #721860
+
+ -- Evgeni Golov Mon, 30 Sep 2013 22:00:22 +0200
+
mutt (1.5.21-6.2) unstable; urgency=low
* Non-maintainer upload.
diff -u mutt-1.5.21/debian/patches/upstream/584138-mx_update_context-segfault.patch mutt-1.5.21/debian/patches/upstream/584138-mx_update_context-segfault.patch
--- mutt-1.5.21/debian/patches/upstream/584138-mx_update_context-segfault.patch
+++ mutt-1.5.21/debian/patches/upstream/584138-mx_update_context-segfault.patch
@@ -26,7 +26,15 @@
ctx->hdrs[idx] = imap_hcache_get (idata, h.data->uid);
if (ctx->hdrs[idx])
{
-@@ -282,13 +282,14 @@
+@@ -211,6 +211,7 @@
+ dprint (3, (debugfile, "bad cache entry at %d, giving up\n", h.sid - 1));
+ imap_free_header_data((void**) (void*) &h.data);
+ evalhc = 0;
++ idx--;
+ }
+ }
+ while (rc != IMAP_CMD_OK && mfhrc == -1);
+@@ -273,18 +274,20 @@
{
dprint (2, (debugfile, "msg_fetch_header: ignoring fetch response with no body\n"));
mfhrc = -1;
@@ -44,0 +53,15 @@
+ "unknown message number %d\n", h.sid));
+ mfhrc = -1;
++idx--;
+ continue;
+ }
+ /* May receive FLAGS updates in a separate untagged response (#2935) */
+@@ -292,6 +295,7 @@
+ {
+ dprint (2, (debugfile, "imap_read_headers: message %d is not new\n",
+ h.sid));
++idx--;
+ continue;
+ }
+
+
diff -u mutt-1.5.21/debian/patches/features/imap_fast_trash mutt-1.5.21/debian/patches/features/imap_fast_trash
--- mutt-1.5.21/debian/patches/features/imap_fast_trash
+++ mutt-1.5.21/debian/patches/features/imap_fast_trash
@@ -14,7 +14,7 @@
+ if (hdrs[n]->purged)
+ break;
+ if (hdrs[n]->deleted != HEADER_DATA(hdrs[n])->deleted)
-+match = invert ^ hdrs[n]->deleted;
++match = invert ^ (hdrs[n]->deleted && !hdrs[n]->appended);
+ break;
case M_FLAG:
if (hdrs[n]->flagged != HEADER_DATA(hdrs[n])->flagged)
Bug#706798: transition: Libav 9
On Sat, Sep 28, 2013 at 11:38:33 +0200, Rémi Vanicat wrote: > Hello, > > A recent change in a build dependency (libmodplug 1:0.8.8.4-4[1]) of > xmms2 make it FTBS[2]. As it is part of the libav transition and already > have been rebuilt for it, I wanted to have you OK to upload the fixed > version now > I'm hoping to get new libav and most of its rdeps migrated within the next couple of days. Can you check back after that (or just upload after you see xmms2 0.8+dfsg-6+b1 in testing)? Thanks, Julien signature.asc Description: Digital signature
Re: Updating xloadimage to libtiff5
On Mon, Sep 30, 2013 at 15:50:33 +0200, Dominik George wrote: > Hi, > > I have prepared xloadimage for upload to assume maintainership for it, > and the PTS tells me I should prepare it for the libtiff5 transition. > > My understanding is that I should make it build against libtiff5 rather > than libtiff4, and that is what I did. My understanding is that this > will bring forward the transition. > > However, my sponsor says that the libtiff5 transition means that I must > under no circumstances upload any changes that deal with libtiff. > > Could you please explain to me what is the correct way of dealing with > the libtiff5 transition? > Please only ever use libtiff-dev, not the versioned ones. Cheers, Julien signature.asc Description: Digital signature
Bug#725046: Bugs in packages meep-* (fwd)
Package: release.debian.org Severity: normal Tags: wheezy User: release.debian@packages.debian.org Usertags: pu Hi, unfortunately the packages meep-* contain bugs that makes it impossible to develop own software with libmeep. As directory names are wrong, especially users of Live CDs might have problems using these packages now (actually I got the initial bug report from a user of such a CD). I attached four debdiffs for packages meep-lam4[1], meep-openmpi[2], meep-mpich2[3] and meep-mpi-default[4]. As my first email probably slipped your attention, I already uploaded the packages to unstable. As the versions in sid and wheezy are the same (except for this patch), this should be no problem. Best regards Thorsten [1] meep-lam4: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711767 [2] meep-openmpi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711766 [3] meep-mpich2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711768 [4] meep-mpi-default: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711765diff -Nru meep-openmpi-1.1.1/debian/changelog meep-openmpi-1.1.1/debian/changelog --- meep-openmpi-1.1.1/debian/changelog 2011-12-13 10:23:17.0 +0100 +++ meep-openmpi-1.1.1/debian/changelog 2013-06-09 19:12:33.0 +0200 @@ -1,3 +1,10 @@ +meep-openmpi (1.1.1-9) unstable; urgency=low + + * debian/rules: mv /usr/include/meep-openmpi to /usr/include/meep + (Closes: #711766) + + -- Thorsten Alteholz Sun, 09 Jun 2013 11:00:00 +0200 + meep-openmpi (1.1.1-8) unstable; urgency=low * debian/control: depend on debhelper >=8 diff -Nru meep-openmpi-1.1.1/debian/rules meep-openmpi-1.1.1/debian/rules --- meep-openmpi-1.1.1/debian/rules 2011-12-13 19:48:52.0 +0100 +++ meep-openmpi-1.1.1/debian/rules 2013-06-09 19:13:06.0 +0200 @@ -69,6 +69,7 @@ $(MAKE) -C debian/build-openmpi/ install prefix=$(CURDIR)/debian/build-openmpi/tmpinst/usr /usr/bin/chrpath -d debian/build-openmpi/tmpinst/usr/lib/libmeep_openmpi.so /usr/bin/chrpath -d debian/build-openmpi/tmpinst/usr/bin/meep-openmpi + mv debian/build-openmpi/tmpinst/usr/include/meep-openmpi debian/build-openmpi/tmpinst/usr/include/meep dh_install -pmeep-openmpi -p$(lm) -p$(lmd) \ --sourcedir=debian/build-openmpi/tmpinst diff -Nru meep-mpi-default-1.1.1/debian/changelog meep-mpi-default-1.1.1/debian/changelog --- meep-mpi-default-1.1.1/debian/changelog 2012-06-27 21:30:46.0 +0200 +++ meep-mpi-default-1.1.1/debian/changelog 2013-06-09 19:03:13.0 +0200 @@ -1,3 +1,10 @@ +meep-mpi-default (1.1.1-10) unstable; urgency=low + + * debian/rules: mv /usr/include/meep-mpi-default to /usr/include/meep + (Closes: #711765) + + -- Thorsten Alteholz Sun, 09 Jun 2013 11:00:00 +0200 + meep-mpi-default (1.1.1-9) unstable; urgency=low * debian/control: add more Conflicts: (Closes: #677459, #677462) diff -Nru meep-mpi-default-1.1.1/debian/rules meep-mpi-default-1.1.1/debian/rules --- meep-mpi-default-1.1.1/debian/rules 2012-06-06 14:52:01.0 +0200 +++ meep-mpi-default-1.1.1/debian/rules 2013-06-09 19:04:01.0 +0200 @@ -72,6 +72,7 @@ $(MAKE) -C debian/build-mpi-default/ install prefix=$(CURDIR)/debian/build-mpi-default/tmpinst/usr /usr/bin/chrpath -d debian/build-mpi-default/tmpinst/usr/lib/libmeep_mpi-default.so /usr/bin/chrpath -d debian/build-mpi-default/tmpinst/usr/bin/meep-mpi-default + mv debian/build-mpi-default/tmpinst/usr/include/meep-mpi-default debian/build-mpi-default/tmpinst/usr/include/meep dh_install -pmeep-mpi-default -p$(lm) -p$(lmd) \ --sourcedir=debian/build-mpi-default/tmpinst diff -Nru meep-mpich2-1.1.1/debian/changelog meep-mpich2-1.1.1/debian/changelog --- meep-mpich2-1.1.1/debian/changelog 2012-06-28 21:51:24.0 +0200 +++ meep-mpich2-1.1.1/debian/changelog 2013-06-09 19:05:22.0 +0200 @@ -1,3 +1,10 @@ +meep-mpich2 (1.1.1-10) unstable; urgency=low + + * debian/rules: mv /usr/include/meep-mpich2 to /usr/include/meep + (Closes: #711768) + + -- Thorsten Alteholz Sun, 09 Jun 2013 11:00:00 +0200 + meep-mpich2 (1.1.1-9) unstable; urgency=low * debian/control: add more Conflicts: diff -Nru meep-mpich2-1.1.1/debian/rules meep-mpich2-1.1.1/debian/rules --- meep-mpich2-1.1.1/debian/rules 2012-06-06 13:05:36.0 +0200 +++ meep-mpich2-1.1.1/debian/rules 2013-06-09 19:06:01.0 +0200 @@ -72,6 +72,7 @@ $(MAKE) -C debian/build-mpich2/ install prefix=$(CURDIR)/debian/build-mpich2/tmpinst/usr /usr/bin/chrpath -d debian/build-mpich2/tmpinst/usr/lib/libmeep_mpich2.so /usr/bin/chrpath -d debian/build-mpich2/tmpinst/usr/bin/meep-mpich2 + mv debian/build-mpich2/tmpinst/usr/include/meep-mpich2 debian/build-mpich2/tmpinst/usr/include/meep dh_install -pmeep-mpich2 -p$(lm) -p$(lmd) \ --sourcedir=debian/build-mpich2/tmpi
Re: Roll call for porters of architectures in sid and testing (Status update)
Hi, Nothing motivates like a deadline... I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For kfreebsd-amd64 and kfreebsd-i386, I - test many packages on this architecture - triage arch-specific bugs - fix arch-related bugs - keep an eye on buildds - stay current with debian-bsd@lists.d.o - help with wheezy security support for arch-specific packages Furthermore I run kfreebsd-amd64 on a development machine, and on a number of production servers. I use kfreebsd-i386 on some embedded systems in a production environment. I am not a DD/DM, but maybe someday... Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#725050: nmu: mail-notification_5.4.dfsg.1-8+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear release team, mail-notification's last binNMU (for the Evolution 3.8 transition) pulled in libgmime-2.6-dev 2.6.17-1, and the resulting package built without GMime support thanks to #722609, because gmime-2.6.pc couldn't be found (yay for configuration systems which build in spite of missing build-dependencies). I'd appreciate a binNMU now that the gmime bug is fixed! nmu mail-notification_5.4.dfsg.1-8+b1 . ALL . -m "Rebuild using fixed libgmime-2.6-dev." Thanks in advance, Stephen -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/8 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/20130930210848.4977.77149.report...@heffalump.sk2.org
Bug#706798: transition: Libav 9
On Mon, Sep 30, 2013 at 20:26:30 +0200, Sebastian Ramacher wrote: > dvd-slideshow, dvdwizard, tribler and videotrans still depend on ffmpeg. > dvd-slideshow would make a good removal candidate. #710411 is open since May > and > has not received a reply from the maintainer. > > dvdwizard and videotrans appear on the list of auto-removal candidates. > tribler > has been uploaded recently but still depends on ffmpeg. > So, err, dvd-slideshow, dvdwizard and videotrans have the same Maintainer as libav. How is this still unfixed? If these packages are unmaintained, can the pkg-multimedia team please take care of cleaning up its cruft? Cheers, Julien signature.asc Description: Digital signature
Bug#706798: transition: Libav 9
On Mon, Sep 30, 2013 at 20:26:30 +0200, Sebastian Ramacher wrote: > dvd-slideshow, dvdwizard, tribler and videotrans still depend on ffmpeg. > dvd-slideshow would make a good removal candidate. #710411 is open since May > and > has not received a reply from the maintainer. > > dvdwizard and videotrans appear on the list of auto-removal candidates. > tribler > has been uploaded recently but still depends on ffmpeg. > I've added removal hints for those 4, thanks. Cheers, Julien signature.asc Description: Digital signature
ports and multiarch
On Thu, Sep 19, 2013 at 10:38:29AM +0200, Niels Thykier wrote: > We also got a number of people interested in architectures not currently > in unstable. These are: > > alpha: Bill MacAllister (!DD), Kieron Gillespie (!DD) > arm64: Wookey (DD) > parisc/hppa: Helge Deller (!DD) > ppc64: Steven Gawroriski (!DD) > sparc64: Steven Gawroriski (!DD), Kieron Gillespie (!DD) We should add official support for ppc64 and maybe sparc64 at least for use as a multiarch extension to ppc/sparc, even if we do not have time to make a full port. Otherwise the introduction of multiarch will likely result in a regression of functionnality on ppc system. Indeed, lib64* packages are superceded by multiarch and often are removed due to file conflict with the multi-arch equivalent. However this leads to a regression for nominally-32bit but 64bit-capable architectures that do not have a 64bit suit to draw from. This is especially an issue for ppc, which has a fast 64bit arithmetic. Cheers, -- Bill. Imagine a large red swirl here. -- 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/20130930212206.ga5...@master.debian.org
Bug#721509: marked as done (nmu: binNMU for libgtkdatabox rdepends)
Your message dated Mon, 30 Sep 2013 23:23:28 +0200 with message-id <20130930212328.gb8...@betterave.cristau.org> and subject line Re: Bug#721509: nmu: binNMU for libgtkdatabox rdepends has caused the Debian Bug report #721509, regarding nmu: binNMU for libgtkdatabox rdepends 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.) -- 721509: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721509 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, afaics, the rdeps of libgtkdatabox are currently blocking the cruft removal of libgtkdatabox-0.9.1-1 [1] and in turn glade-3 Both libgtkdatabox-0.9.1-dev and libgtkdatabox-0.9.2-dev provide libgtkdatabox-dev, so I think a binNMU should be sufficient. nmu brp-pacu_2.1.1+git20111020-3 . amd64 . -m "Rebuild against libgtkdatabox-0.9.2-0" nmu klavaro_1.9.7-1 . ALL . -m "Rebuild against libgtkdatabox-0.9.2-0" Thanks, Michael [1] http://qa.debian.org/excuses.php?package=libgtkdatabox -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On Sun, Sep 1, 2013 at 15:05:22 +0200, Michael Biebl wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Hi, > > afaics, the rdeps of libgtkdatabox are currently blocking the cruft removal of > libgtkdatabox-0.9.1-1 [1] and in turn glade-3 > > Both libgtkdatabox-0.9.1-dev and libgtkdatabox-0.9.2-dev provide > libgtkdatabox-dev, so I think a binNMU should be sufficient. > I think this is obsolete now. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#724252: marked as done (nmu: brp-pacu_2.1.1+git20111020-3)
Your message dated Mon, 30 Sep 2013 23:25:35 +0200 with message-id <20130930212535.gc8...@betterave.cristau.org> and subject line Re: Bug#724252: nmu: brp-pacu_2.1.1+git20111020-3 has caused the Debian Bug report #724252, regarding nmu: brp-pacu_2.1.1+git20111020-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.) -- 724252: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724252 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu brp-pacu_2.1.1+git20111020-3 . amd64 . -m "Rebuild against libgtkdatabox 0.9.2" Old maintainer upload depending on unavailable libgtkdatabox-0.9.1-1, all other architectures should have been built against the newer one. Andreas --- End Message --- --- Begin Message --- On Mon, Sep 23, 2013 at 01:16:50 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu brp-pacu_2.1.1+git20111020-3 . amd64 . -m "Rebuild against libgtkdatabox > 0.9.2" > > Old maintainer upload depending on unavailable libgtkdatabox-0.9.1-1, > all other architectures should have been built against the newer one. > Looks like this has happened. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#712771: marked as done (nmu: dynare_4.3.3-4 vips_7.28.5-1 nip2_7.28.4-1)
Your message dated Mon, 30 Sep 2013 23:28:25 +0200 with message-id <20130930212825.ge8...@betterave.cristau.org> and subject line Re: Bug#712771: nmu: dynare_4.3.3-4 vips_7.28.5-1 nip2_7.28.4-1 has caused the Debian Bug report #712771, regarding nmu: dynare_4.3.3-4 vips_7.28.5-1 nip2_7.28.4-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.) -- 712771: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712771 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-CC: sylves...@debian.org Dear Release Team, In order to complete the ongoing libmatio transition, the following binNMUs are needed: nmu dynare_4.3.3-4 . armel sparc . -m "Rebuild against libmatio-dev >= 1.5" nmu vips_7.28.5-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" nmu nip2_7.28.4-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" The openmeeg package is also affected by the transition, but needs a sourceful upload due to API changes. A NMU is on its way in the DELAYED queue. In case you want to setup a transition tracker, here is a ben file: title = "libmatio"; is_affected = .build-depends ~ /libmatio-dev/; is_good = .depends ~ /libmatio2/; is_bad = .depends ~ /libmatio0/; Cheers, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: Digital signature --- End Message --- --- Begin Message --- On Mon, Sep 30, 2013 at 20:29:09 +0200, Sébastien Villemot wrote: > Le lundi 30 septembre 2013 à 10:50 +0200, Julien Cristau a écrit : > > On Wed, Jun 19, 2013 at 13:13:10 +0200, Sébastien Villemot wrote: > > > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: binnmu > > > X-Debbugs-CC: sylves...@debian.org > > > > > > Dear Release Team, > > > > > > In order to complete the ongoing libmatio transition, the following > > > binNMUs are > > > needed: > > > > > > nmu dynare_4.3.3-4 . armel sparc . -m "Rebuild against libmatio-dev >= > > > 1.5" > > > nmu vips_7.28.5-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" > > > nmu nip2_7.28.4-1 . ALL . -m "Rebuild against libmatio-dev >= 1.5" > > > > > Looks like these got sourceful uploads in the mean time, > > Indeed. You can therefore close this binnmu request, unless you want to > keep it for tracking the status of libmatio transition. > Alright, thanks! Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#724725: nmu: pinba-engine-mysql_1.0.0-2
On Fri, Sep 27, 2013 at 09:20:33 +0200, Vincent Bernat wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu pinba-engine-mysql_1.0.0-2 . ALL . -m "recompile against new > mysql-source-5.5" > ... because? Cheers, Julien signature.asc Description: Digital signature
Bug#724725: nmu: pinba-engine-mysql_1.0.0-2
❦ 30 septembre 2013 23:26 CEST, Julien Cristau : >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: binnmu >> >> nmu pinba-engine-mysql_1.0.0-2 . ALL . -m "recompile against new >> mysql-source-5.5" >> > ... because? MySQL does not provide any stable ABI for additional engines and therefore they to be recompiled for each binary change. -- Modularise. Use subroutines. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#724725: marked as done (nmu: pinba-engine-mysql_1.0.0-2)
Your message dated Mon, 30 Sep 2013 23:32:35 +0200 with message-id <20130930213235.gf8...@betterave.cristau.org> and subject line Re: Bug#724725: nmu: pinba-engine-mysql_1.0.0-2 has caused the Debian Bug report #724725, regarding nmu: pinba-engine-mysql_1.0.0-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.) -- 724725: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724725 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 nmu pinba-engine-mysql_1.0.0-2 . ALL . -m "recompile against new mysql-source-5.5" Thanks! - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSRTG9AAoJEJWkL+g1NSX5CeoP/3U/GVlcMZlm6Er8ChG4ncAS tj/tNKnMCtuU5KySHpSLoD5emyIw2Pu5HB7x6VquGumbZymvbXUDKeNqeEVLyj1C OzbbUyDd1nULMvmKFOM2T1OlRTB3vEUJFhYCufUV90173w6KemBQ4bObZHb9B+tt bUCpCCXSWQFyb2Yo3w2KyUYNNu1b/wjKTjALQhZow5A92yTXf/XpN0s1GbTLu998 9UUgbUjSs1WjmRb1+7gXiMdQmGWp0w41/B3zLJNAFLsYWDP0iI7UzuSekr0sldM+ k3Wvw7Q3ELPjCejOlheF7MWMxLTpgZ9KgrN6EmtJELe1OIiXwMpH7+VwDatdE/LN ljyPcIhMHlA0GQhvWwXkqv3rKhhIqctP4a+fXDD0BxZVxEwjBF6K9DVHSHkflcNR CXQDYZJCWER2VtBOHTGO8C1x53bKzABHy7kHk/GANDIRbNoZ8J4zAxO6bL+LVJtl EnBF1ZPcl8M+GCoBWYqMifjKYO5PLngZ6i0ItrdD6MzKwNd8G95Aahm5Rl+VI4wp BLhKXBQNCuHaPfLYVVzQTE4pcX7tZhOgpBiZHlGQNpfIvok4uu4Ood2JlzZq3/x+ vFo9jX51WBSnr4i6iNnfHkmytfKcyKDerl9lJnWW0npz9+LnayfIIUH3Z2HsIiyg yrQ0sZ3jqpBTnOgv3PkI =81G8 -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On Mon, Sep 30, 2013 at 23:29:12 +0200, Vincent Bernat wrote: > ❦ 30 septembre 2013 23:26 CEST, Julien Cristau : > > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: binnmu > >> > >> nmu pinba-engine-mysql_1.0.0-2 . ALL . -m "recompile against new > >> mysql-source-5.5" > >> > > ... because? > > MySQL does not provide any stable ABI for additional engines and > therefore they to be recompiled for each binary change. Thanks. Scheduled. Cheers, Julien signature.asc Description: Digital signature --- End Message ---
Bug#711551: pu: package redmine/1.4.4+dfsg1-2
On 30/09/2013 11:09, Cyril Brulebois wrote: > Jérémy Lal (2013-09-30): >>> Jérémy Lal (2013-06-10): --- redmine-1.4.4+dfsg1/debian/changelog 2013-01-19 15:54:09.0 +0100 +++ redmine-1.4.4+dfsg1/debian/changelog 2013-06-10 01:01:48.0 +0200 @@ -1,3 +1,14 @@ +redmine (1.4.4+dfsg1-2+deb7u1) proposed-updates; urgency=low >>> >>> Even though that would work, I'd be happy to see "wheezy" in there, >>> which can be useful after a while to figure out which suite was targeted >>> at that point (without having to look at the version number, and its >>> meaning). >> >> Do you mean it'd be better to use "wheezy-proposed-updates" as distribution ? > > That or just "wheezy" :-) > >>> Assuming the latter change doesn't break the Ruby 1.8 use case (and >>> doesn't need a dance similar to the respond_to one in the former), >>> please upload (with or without an edit for the above mentioned point). >> >> I'm going to recheck that because i only remember doing it on irb, >> not on redmine code. > > Thanks for that. There was a small error. Now both bugs i reproduced today are fixed. Uploading in a moment. Jérémy. -- 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/5249fabc.7090...@melix.org
Re: Roll call for porters of architectures in sid and testing
Hi! [ Had forgotten about this one, sorry. ] I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For kfreebsd-*, I - co-maintain arch-related packages under the hat of the GNU/kFreeBSD Maintainers. - maintain a portability guide to help others with the task. - test packages on this architecture. - assist (reviews, suggestions, etc) with arch-related bugs. - fix arch-related bugs. - read debian-bsd@l.d.o every few days I am a semi-active porter for the following architecture, I'm pondering about my future involvement though: For hurd-i386-*, I - maintain a portability guide to help others with the task. - assist (reviews, suggestions, etc) with arch-related bugs from time to time. - fix arch-related bugs from time to time. - read debian-hurd@l.d.o every few days. I am a DD. Thanks, Guillem signature.asc Description: Digital signature
Proposed release goal: UTF-8 support
Hi! As previously (https://lists.debian.org/debian-devel/2013/08/msg00217.html) discussed, I'd like to propose improving support for UTF-8. All material shipped with Debian should be encoded this way, or, for media with an opaque format, as something capable of storing any Unicode character, without need for any extra steps. There are four sub-goals: * user-accessible interfaces (GUI, stdin, stdout, stderr, command line, reading/writing plain-text files) should be able to pass through UTF-8 data uncorrupted, by default * UTF-8 should be properly displayed * all filenames in Debian packages, binary and source, must use UTF-8 (obviously, 7-bit ASCII satisfies this requirement) * all text files shipped by Debian should be encoded in UTF-8 The wiki entry: https://wiki.debian.org/ReleaseGoals/utf-8 -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ signature.asc Description: Digital signature
Release goal: Cross Toolchains in the Archive
Hooray for deadlines: https://wiki.debian.org/ReleaseGoals/CrossToolchains Cross Toolchains in the archive === Debian has long had useful cross-building support, but has never had general cross-compilers for release architectures in the archive. They have always been built by users, or by outside entities like the long-standing emdebian.org cross-compiler collection. It would be a lot more convenient for users if cross-toolchains were available within the archive like any other package. We already have good support in dpkg, apt and sbuild for cross-building, and installation of cross build-dependencies. And support for autotools and cmake cross-setup in dpkg-cross. It just needs the cross-toolchain packages themselves and some support bit and pieces to make cross-building very slick in Debian. Much of this work has already been demonstrated in Ubuntu and it would be good to get it properly upstream. The Cross Toolchain team on Alioth was re-invigorated at Debconf13 to get this work done. Details --- The thing that has kept cross-compilers out for many years is that the build has cross-architecture dependencies (needs libc:$DEB_HOST_ARCH and libgcc:$DEB_HOST_HOST). Now that Multi-arch is done this problem can be cleanly solved. It is possible to build cross-compilers without multiarch support, as has been demonstrated in Ubuntu but using it provides cleaner support and simpler packaging. Implementation -- * The hard parts have already been done in the Multiarch support. * The cross-toolchain builds should not be part of the normal binutils and gcc packaging, as the large matrix of builds (potentially up to the square of all architectures, fortunately many are not really useful) provides too many opportunities for build failures which would get in the way of normal gcc and binutils updates. * Buildds need to allow cross-architecture dependencies. This was agreed in a multi-arch meeting at Banja Luka * Adding a crossbuild-essential package to easily bring in the right packages is very helpful, but not essential. * A crossbuild-support package (or similar name) should be made from the useful parts of dpkg-cross, keeping the autoconf and cmake variable setup and cache seeding, but dropping the library-munging functionality. Resources Advocates: Wookey Doko Pabs mailing list: debian-cr...@list.debian.org Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20130930225950.gy32...@stoneboat.aleph1.co.uk
release goal: Make the base system cross-buildable
Make the base system cross-buildable It is very useful to be able to cross-build packages in Debian for many reasons, especially around faster dev times on slow architectures, and new ports. Making the whole archive crossbuildable is a huge goal, but making the bottom 140 or so packages needed for a port bootstrap cross-buildable is a reasonable goal. This work has already been done in Ubuntu (Raring) and should be upstreamed into Debian. This goal is (somewhat) dependent on the CrossToolchains in the Archive goal. (It can still be done with external toolchains if need be, but it makes much more sense to have everything necessary maintained in the archive). Details --- This needs: * all the build-deps of the bottom 140 packages to be multiarchified (should be largely done already, or at least bugs filed) * cross-building bugs in those packages fixed (many bugs already filed, copy the rest over from ubuntu). * autoconf cache variables to be set to supply info which can not be correctly determined in a cross environment (using dpkg-cross/cross-support) (Already done - needs testing) * preferably availability of crossbuild-essential packages, and corresponding toolchains in the archive. optional extras --- A cross-buildd running to check cross-buildability of packages should be set up so that maintainers get timely info on breakages, otherwise builds are quite likely to be broken when you want to use them. Like this one: http://people.linaro.org/~wookey/buildd/ Targets --- In principle (and practice) this goal is architecture independent, but in practice the scope can be limited to amd64->arm(hf/el) building if it helps as that is where most current interest lies. The package set needs to be checked but should be very close to: eglibc pcre3 attr acl zlib hostname libsepol gpm ifupdown insserv module-init-tools python-defaults libselinux ncurses bash libpciaccess libpng slang base-files mawk makedev make xz-utils dpkg netbase base-files time manpages libxau libxdmcp libpthread-stubs diffutils tar cpio diffutils gmp gdbm sed tzdata base-passwd coreutils findutils libnfnetlink libffi iptables libelf debconf debianutils ucf xtrans x11proto-kb x11proto-input x11proto-render x11proto-xf86bigfont x11proto-core expat net-tools tcl8.5 tcp-wrappers ubuntu-keyring scowl postgresql-common openslp-dfsg procps psmisc phpmyadmin libusb mcrypt pixman libice bzip2 flex db4.8 dash iptables keyutils less sysvinit nano db-defaults grep dbconfig-comon linux-atm util-linux e2fsprogs ustr kmod dbus libsm cunit glib2.0 udev openssl initramfs-tools libgcrypt11 libidn wget sysfsutils iputils ppl binutils busybox libtasn1-3 libfribidi tcl8.5 sqlite3 db cracklib2 pam libcap2 libsemanage shadow iproute ppl cloog-ppl libbsd libedit dbus libgpg-error popt p11-kit gnutls26 libxau check perl libjpeg initramfs-tools debconf lsb tzdata makedev pam mountall readline cron glib2.0 nspr klibc nano less gcc-4.8 Resources - Advocates: * Wookey * Colin Watson Mailing list: debian-cr...@lists.debian.org Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20130930230159.gz32...@stoneboat.aleph1.co.uk
Bug#724306: Bug #724306: pu: package dpkg/1.16.11
On Mon, 2013-09-30 at 18:57:15 +0100, Adam D. Barratt wrote: > On Mon, 2013-09-30 at 16:59 +0200, Guillem Jover wrote: > > Thanks, unfortunately 724949 just came in a day after the upload, it > > involves improper caching of the «dpkg --print-architecture» and > > «gcc -dumpmachine» output, affecting the performance of wanna-build. > > This was already fixed in 1.17.0, so it has been tested for a while. > > > > I was wondering if you'd be fine with a quick 1.16.12 upload, with the > > attached diff? > > Yes, that looks okay. Thanks, uploaded. > > (Just for future reference, would you have preferred a separate bug > > report?) > > Where the changes are distinct from those in the original report, > separate bug are definitely preferable; so in this case, yes. Ok, sorry then, will do that next time. Regards, Guillem -- 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/20131001041149.ga4...@gaara.hadrons.org
Re: Proposed release goal: UTF-8 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, >As previously >(https://lists.debian.org/debian-devel/2013/08/msg00217.html) >discussed, I'd like to propose improving support for UTF-8. All >material >shipped with Debian should be encoded this way I absolutely second this proposal. Why haven't you added it to https://wiki.debian.org/ReleaseGoals ? What is the usertag for it? Cheers, Nik - - -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSSmIfMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJW+dB/4iU+HvetAzVUlAd8UqG7CN DyMKgp02BftFclxiuoIO1bWlIznFspJoCPS9jaVFyps34PacAlQXBj6eZ3mS7aEv EBKQ5jvw07WKdiSDwghRCCsAX8QKfBMSeTI3d/3EdGecqUpnpAFghD7ZEaZHX/R8 qZ0LPxxl/28kJB7VjTCRk1f6kDv1CW1d05jI81nRnDNz+KdXX5g+i7+7qf79AzWg UFHLxgYjfdcdvZnuagVGkoHcsvxZdi1IwzcZEjfBS3Kit6IDxSBDVR8/bVa5tREo tX93WfT/bfZqNCy3IXl5MRPAAjF020mbQT4jXQctrOXMY5SxwDnrMbLdytG8hkF0 =gxzJ -END PGP SIGNATURE- -- 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/99dad22f-316b-49b3-98f0-07478a2b3...@email.android.com
Re: Proposed release goal: UTF-8 support
On 2013-10-01 00:54, Adam Borowski wrote: > Hi! > > As previously (https://lists.debian.org/debian-devel/2013/08/msg00217.html) > discussed, I'd like to propose improving support for UTF-8. All material > shipped with Debian should be encoded this way, or, for media with an opaque > format, as something capable of storing any Unicode character, without need > for any extra steps. > Hi, Thanks for your interest in improving Debian Jessie. I appreciate the idea behind this goal, but I have a few concerns with some of the sub-goals. > There are four sub-goals: > > * user-accessible interfaces (GUI, stdin, stdout, stderr, command line, > reading/writing plain-text files) should be able to pass through UTF-8 > data uncorrupted, by default Do we have a number of GUIs/tools that needs update here? If not, I am affraid this fails the "Measurable" requirement. Even then, I doubt it is realistic to assume there will be time to test all interfaces, so perhaps put a limit on for Jessie (e.g. "All interfaces of/in $classification") > * UTF-8 should be properly displayed Can you be a bit more specific here? Is this still for "usre-accessible interfaces", then my concerns from above also apply here. > * all filenames in Debian packages, binary and source, must use UTF-8 > (obviously, 7-bit ASCII satisfies this requirement) Okay, thanks to the Lintian check, I think we can say this satisfies the SMART requirements at least for binary packages (the check is not done on source packages as I recall)[1]. > * all text files shipped by Debian should be encoded in UTF-8 > I suspect this is suffering from the same problems as the "user-accessible interface". Though I suspect most of the problematic files should be easier to detect then a bug in a user-interface (and re-encoding is probably easier than fixing bugs in user-interfaces). For this particular sub-goal, it is also possible to reduce the scope by file type (e.g. "For Jessie, we will fix all POD,$A,... and $N files"). > The wiki entry: https://wiki.debian.org/ReleaseGoals/utf-8 > By the way, this link does not appear to be included on https://wiki.debian.org/ReleaseGoals. Once again, I like the idea behind the goal. However, I would like to see some numbers of how much work there is (or how much work we/you decide to target for Jessie) to ensure this goal is Attainable. ~Niels [1] http://lintian.debian.org/tags/file-name-is-not-valid-UTF-8.html Lists 5 packages and 15 affected files. Technically, there is also: http://lintian.debian.org/tags/file-name-in-PATH-is-not-ASCII.html But there are no instances of that. -- 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/524a657d.9010...@thykier.net
Processed: xine-lib-1.2: FTBFS on kfreebsd (missing vaapi)
Processing control commands: > block 706798 with -1 Bug #706798 [release.debian.org] transition: Libav 9 706798 was blocked by: 713354 720828 722610 720801 694299 721544 720779 720727 721025 720785 723099 720820 692505 720796 693639 720668 693641 692809 721577 720790 720799 720826 692980 720797 720816 677959 721026 722486 693106 713276 722493 720823 720809 693560 720783 720808 720805 720661 720810 720824 723803 721493 720802 721164 706798 was blocking: 716735 Added blocking bug(s) of 706798: 725071 -- 706798: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706798 725071: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725071 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b.13806084984453.transcr...@bugs.debian.org
