Bug#825534: jessie-pu: package backuppc/3.3.0-2
On Thu, Jun 9, 2016 at 10:17:22 +0200, Ludovic Drolez wrote: > Hi! > > I'm ready to upload a new package without the patch below. > I'm kind of lost here, please re-send a full debdiff for the proposed upload. Cheers, Julien
Bug#782143: marked as done (pu: package stunnel4/3:5.06-2+deb8u1)
Your message dated Tue, 28 Jun 2016 10:20:49 +0200
with message-id <20160628082049.gd3...@betterave.cristau.org>
and subject line Re: Bug#782143: pu: package stunnel4/3:5.06-2+deb8u1
has caused the Debian Bug report #782143,
regarding pu: package stunnel4/3:5.06-2+deb8u1
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.)
--
782143: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782143
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: unblock
This is a pre-approval request for unblocking a RC bugfix upload of
stunnel4 that will fix two RC bugs:
- #771421 - makes stunnel unusable for some users in certain
configurations; not for everyone, but still, it happens too often to
be ignored
- #782030 - makes stunnel start and stop properly, checking whether
the action has actually succeeded
The full debdiff between version 3:5.06-2 (currently in unstable and
testing) and the proposed 3:5.06-3 is attached.
unblock stunnel4/3:5.06-3
Thanks in advance, and thanks for all your work!
G'luck,
Peter
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru stunnel4-5.06/debian/changelog stunnel4-5.06/debian/changelog
--- stunnel4-5.06/debian/changelog 2014-10-20 11:49:07.0 +0300
+++ stunnel4-5.06/debian/changelog 2015-04-08 14:00:56.0 +0300
@@ -1,3 +1,15 @@
+stunnel4 (3:5.06-3) unstable; urgency=medium
+
+ * Add the 17-upstream-hangup patch to fix prematurely closed
+connections when there is still data to be written.
+Thanks to Joachim Falk for backporting the patch!
+Closes: #771241
+ * Add the 18-lsb-startup patch to make the daemons' startup consistent
+with the way things are done in Debian.
+Among other things, Closes: #782030
+
+ -- Peter Pentchev Wed, 08 Apr 2015 14:00:54 +0300
+
stunnel4 (3:5.06-2) unstable; urgency=medium
* Limit the systemd build dependency to Linux architectures only,
diff -Nru stunnel4-5.06/debian/patches/17-upstream-hangup.patch
stunnel4-5.06/debian/patches/17-upstream-hangup.patch
--- stunnel4-5.06/debian/patches/17-upstream-hangup.patch 1970-01-01
02:00:00.0 +0200
+++ stunnel4-5.06/debian/patches/17-upstream-hangup.patch 2015-04-08
12:45:17.0 +0300
@@ -0,0 +1,74 @@
+Description: Fix premature data truncation in the POLLRDHUP handling
+DebianBug: https://bugs.debian.org/771241
+Origin: upstream;
https://www.stunnel.org/pipermail/stunnel-users/2014-November/004860.html
+Last-Update: 2015-03-04
+
+--- a/src/client.c
b/src/client.c
+@@ -515,6 +515,11 @@
+ int write_wants_read=0, write_wants_write=0;
+ /* actual conditions on file descriptors */
+ int sock_can_rd, sock_can_wr, ssl_can_rd, ssl_can_wr;
++#ifdef USE_WIN32
++unsigned long bytes;
++#else
++int bytes;
++#endif
+
+ c->sock_ptr=c->ssl_ptr=0;
+
+@@ -810,32 +815,44 @@
+ }
+
+ /** check for hangup conditions */
+-if(s_poll_rdhup(c->fds, c->sock_rfd->fd)) {
+-s_log(LOG_INFO, "Read socket closed (hangup)");
++/* http://marc.info/?l=linux-man&m=128002066306087 */
++/* readsocket() must be the last sock_rfd operation before FIONREAD */
++if(sock_open_rd && s_poll_rdhup(c->fds, c->sock_rfd->fd) &&
++(ioctlsocket(c->sock_rfd->fd, FIONREAD, &bytes) || !bytes)) {
++s_log(LOG_INFO, "Read socket closed (read hangup)");
+ sock_open_rd=0;
+ }
+-if(s_poll_hup(c->fds, c->sock_wfd->fd)) {
++if(sock_open_wr && s_poll_hup(c->fds, c->sock_wfd->fd)) {
+ if(c->ssl_ptr) {
+ s_log(LOG_ERR,
+-"Write socket closed (hangup) with %d unsent byte(s)",
++"Write socket closed (write hangup) with %d unsent
byte(s)",
+ c->ssl_ptr);
+ longjmp(c->err, 1); /* reset the socket */
+ }
+-s_log(LOG_INFO, "Write socket closed (hangup)");
++s_log(LOG_INFO, "Write socket closed (write hangup)");
+ sock_open_wr=0;
+ }
+-if(s_poll_hup(c->fds, c->ssl_rfd->fd) ||
+-s_poll_hup(c->fds, c->ssl_wfd->fd)) {
++/* SSL_read
Processed: Re: Bug#828186: transition: rtaudio
Processing control commands: > tags -1 confirmed Bug #828186 [release.debian.org] transition: rtaudio Added tag(s) confirmed. -- 828186: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828186 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#828186: transition: rtaudio
Control: tags -1 confirmed On 27/06/16 18:46, Jaromír Mikeš wrote: >> Did you test build them? > > Hi, > > I just did test build of packages above. > Location of header files changed from include to include/rtaudio so some easy > patching will be needed. > Otherwise they build fine. Alright, go ahead. Please file bugs for the rdeps that need patches and let me know which ones don't need any changes and can be rebuilt. Emilio
Processed: Re: Bug#828187: transition: rtmidi
Processing control commands: > tags -1 confirmed Bug #828187 [release.debian.org] transition: rtmidi Added tag(s) confirmed. -- 828187: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828187 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#828187: transition: rtmidi
Control: tags -1 confirmed On 27/06/16 18:44, Jaromír Mikeš wrote: > On 25/06/16 23:49, Jaromír Mikeš wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hi, >> new upstream rtmidi bumps SONAME, so we need to transition. >> >> Direct reverse dependencies are: >> >> stk >> giada >> midisnoop >> milkytracker >> >> Did you test build them? > > Hi, > > I just did test build of packages above. > Location of header files changed from include to include/rtmidi so some easy > patching will be needed. > I just get some trouble to build midisnoop but not because of rtmidi package. > I am also maintainer of midisnoop and I don't see it as stopper for > transition. Alright, go ahead. Please file bugs for the rdeps that need patches and let me know which ones don't need any changes and can be rebuilt. Emilio
Bug#784373: [Ceph-maintainers] Bug#784373: jessie-pu: package ceph/0.80.9-2 (pre approval)
On Sun, Jan 17, 2016 at 23:41:09 +0100, Gaudenz Steinlin wrote: > Gaudenz Steinlin writes: > > > Hi Julien > > > > Do you need any additional information? I would like to have a decision > > on this soon as I really want to get at least CVE-2015-5245 fixed in the > > next Debian stable release. This is a minor security issue which was > > defered by the Security Team to a stable update and there was no DSA > > issued for it. > > > > To be able to prepare the upload for the stable release I need to know > > if you agree to follow the upstream maintenance releases or if I have to > > do an upload with only the security issue fixed. If I got the timing > > right, the next point release is still scheduled for 24th January. So > > there is only little time left to prepare the upload. > > > > As this is now undecided for quite a long time I would even prefer a NACK > > to having this unresolved any longer if you don't feel comfortable with > > the idea of having the maintenance releases in stable. This way I at > > least know that I don't have to bother anymore. > > > > If you don't want to rush things but are in gernal fine with the idea. > > I'm also fine with only fixing the security bug now as the time is quite > > tight and uploading 0.80.11 for the Debian 8.4 point release. > > As I did not get any feedback I have now uploaded ceph/0.80.7-2+deb8u1 > with only the security bug fixed. I think this is really the minimum > that should go into the next stable point release and I don't think > there is any concern about this. I cloned the original bug report to > track this jessie-pu request. The debdiff to the version currently in > stable is attached. It's minimal. > > I would still appreciate an answer on #784373. Even if it's just the > stable team does not currently have the resources to evaluate this > request and therefore declines to make an exception to the usual stable > update rules. This would not be the answer I had hoped for, but at least > I then know that I don't have to invest more time into the 0.80.X series > of ceph. > Hi Gaudenz, I finally found some time to look at the 0.80.9 patch you provided (I don't think I saw one for 0.80.11?), and I'd be ok with that if you're still interested in updating the jessie package. Cheers, Julien
Processed: Re: Bug#789214: jessie-pu: package cloud-init/0.7.6~bzr976-2 -> -3
Processing control commands: > tag -1 moreinfo Bug #789214 [release.debian.org] jessie-pu: package cloud-init/0.7.6~bzr976-2 -> -3 Added tag(s) moreinfo. -- 789214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789214 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#789214: jessie-pu: package cloud-init/0.7.6~bzr976-2 -> -3
Control: tag -1 moreinfo On Mon, Nov 23, 2015 at 16:03:57 +0100, Thomas Goirand wrote: > On 11/23/2015 01:32 PM, Charles Plessy wrote: > >>> Le Sun, Oct 18, 2015 at 01:13:26AM +0200, Thomas Goirand a écrit : > > Ping? Is there anyone from the stable release team that could spend a > bit of time here? > > > >> On 11/12/2015 05:49 AM, Charles Plessy wrote: > >>> > >>> I propose that we declare time bankrupcy on that issue, give up on fixing > >>> it, > >>> and update Sid's package instead, which is now seriously outdated. > > > > Le Thu, Nov 12, 2015 at 03:19:54PM +0100, Thomas Goirand a écrit : > >> > >> I was also thinking about it, and though that we can't wait for more. > >> Many people are waiting for this update, including those from Azure. > >> Let's hope the release team accepts the fix anyway at some point. > > > > Hi everybody, > > > > this request for update is stalled, therefore I close it. > > > > Have a nice day, > > No, don't close it. It is a grave bug which I would like to fix. That > the release team don't care enough to investigate in time, or don't > understand the issue at all, isn't a reason good enough to close this > bug. If the release team needs more info, then I will do my best to > provide it, especially that we all do understand they are very busy with > complicated transitions. > > Keeping this bug open doesn't mean w should stop our work in Sid. That, > I agree, we can't delay it, it's been too long already. > I believe I have asked multiple times for a clear explanation of what this bug is, its effect, and why the proposed fix is the right one, and I don't remember seeing a satisfactory answer. If I missed it, I'd appreciate a pointer. Cheers, Julien
Bug#798969: jessie-pu: package qemu/1:2.1+dfsg-12+deb8u5
Control: tag -1 moreinfo On Sat, Feb 20, 2016 at 18:19:49 +, Julien Cristau wrote: > On Tue, Jan 26, 2016 at 15:37:41 +0300, Michael Tokarev wrote: > > > 26.01.2016 14:47, Michael Tokarev wrote: > > > I updated the patch to be based on current latest > > > jessie-security version, and also used git diff > > > instead of plain diff, which can detect renames, > > > so the difference become a bit smaller than before, > > > yet it is still large, still due to the same > > > diff reorganization (when we applied some individual > > > patches to debian package, but they later has been > > > incorporated to the upstream stable release). > > > > And here's one another diff which might be of help. > > It is a diff between current jessie version and > > the proposed version, with all the patches applied, > > but without the diff between debian/patches directories. > > > > Because there's a large overlap between the applied > > diffs due to diff file reorganization, it might be > > better to see the final _result_ of all the changes, > > instead of the changes themselves. That's what the > > diff below provides, just the actual changes to the > > actual source which is being compiled. > > > That should be helpful, thanks. Can you please provide a list of the > changes (not a gitweb link, actual text either in your debian/changelog > or at least in this bug) so we have a chance to match the diff with a > short explanation for each of the changes? > Ping, Michael? Cheers, Julien
Processed: Re: Bug#798969: jessie-pu: package qemu/1:2.1+dfsg-12+deb8u5
Processing control commands: > tag -1 moreinfo Bug #798969 [release.debian.org] jessie-pu: package qemu/1:2.1+dfsg-12+deb8u5 Added tag(s) moreinfo. -- 798969: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798969 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#807654: jessie-pu: package python-django/1.7.11-1
On Fri, Dec 11, 2015 at 11:56:58 +0100, Raphael Hertzog wrote: > I would like to update python-django in jessie to the latest upstream bug > fix release in the 1.7.x branch, aka 1.7.11. It should also be the last > upstream release in that branch since it's now unsupported upstream. > Please go ahead. Also note that these comments: > I already argued for that during the freeze but it's still the same now: > Django is a sane upstream that does not add new features in branches > of released versions, they only fix bugs and security issues. They have > a large test suite and it's easier for us to maintain Django over the > next 4 years to be as close as possible to the last released version. > [...] > (I want to do the same for wheezy with 1.4.22, but I'll wait the outcome > of this one before doing the work for wheezy, so it would be nice from you > to have a timely answer) On Tue, Jan 26, 2016 at 09:49:37 +0100, Raphael Hertzog wrote: > Hello dear release team, > > On Fri, 11 Dec 2015, Raphael Hertzog wrote: > > I would like to update python-django in jessie to the latest upstream bug > > fix release in the 1.7.x branch, aka 1.7.11. It should also be the last > > upstream release in that branch since it's now unsupported upstream. > > So I got no response in the 1.5 months between my submission and the > last point release. I hope that my request will be first in line for the > next round. > ... have the opposite effect of what you're saying you would like. They certainly don't motivate anyone to look at your requests with any kind of priority. On Sat, Feb 20, 2016 at 16:50:19 +0100, Raphael Hertzog wrote: > Please see the upstream release notes here for all versions between what's > in jessie and what I want to upload: > Thanks for the additional information. > https://docs.djangoproject.com/en/1.7/releases/1.7.8/ > https://docs.djangoproject.com/en/1.7/releases/1.7.9/ > https://docs.djangoproject.com/en/1.7/releases/1.7.10/ > https://docs.djangoproject.com/en/1.7/releases/1.7.11/ [...] > I have added the above links in debian/changelog in my debian/jessie-updates > branch. > Especially for stable updates, the changelog should include the actual useful information directly, not links (or not *just* links). Cheers, Julien
Bug#824872: jessie-pu: package nspr/2:4.12-2+deb8u1
On Sun, May 29, 2016 at 14:58:51 +0200, Guido Günther wrote: > Upstream has an internal test suite which we enabled for the package > builds in nspr as well as nss (+ some autopkg smoke test in nss > itself). Howver I don't know as to what extend ABI compatibility is > tested upstream. Hopefully Mike (cc:) may have some input on this. > > In order get some ideas about ABI compatibility myself I ran > abi-compliance-tester. The results for both NSS and NSPR are also > attached. We would do that on all point release updates. > > Note that the only (as to my understanding) serious regression has been > pointed out by Florian as well: > > https://lists.debian.org/debian-lts/2015/11/msg00037.html > https://bugzilla.redhat.com/show_bug.cgi?id=1260698 > > and it's unclear if this part of the ABI. The API break (removal of > CERT_FindCertURLExtension) is bogus since the symbol was not exported. > I don't understand why you seem to be talking about ABI stability issues. There are other kinds of bugs. Cheers, Julien
Processed: Re: Bug#826568: jessie-pu: package sendmail/8.14.4-8+deb8u1
Processing control commands: > tag -1 confirmed Bug #826568 [release.debian.org] jessie-pu: package sendmail/8.14.4-8+deb8u1 Added tag(s) confirmed. -- 826568: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826568 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#826568: jessie-pu: package sendmail/8.14.4-8+deb8u1
Control: tag -1 confirmed On Mon, Jun 6, 2016 at 15:25:09 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > Tags: jessie > User: release.debian@packages.debian.org > Usertags: pu > > Hi, > > I'd like to backport an LDAP-related patch for sendmail to jessie > (#826120: the queuerunner may abort with an assertion if the > connection to an LDAP server is lost). This was fixed upstream > in 8.14.5. The patch was cherry-picked from RHEL 6: RHBA-2015:1299-3. > The client port fix (fixed upstream in 8.15.1) also originates there. > > The bug reporter confirmed that the patch fixed his problems on jessie. > Please go ahead. Cheers, Julien
Bug#826607: jessie-pu: package clamav/0.99.2+dfsg-0+deb8u2
Control: tag -1 confirmed On Tue, Jun 7, 2016 at 00:13:36 +0200, Sebastian Andrzej Siewior wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: pu > Tags: jessie > Severity: normal > > The last version (0.99.2+dfsg-0+deb8u1) removed AllowSupplementaryGroups > and hit stable over the weekend. Now Hans van Kranenburg had an > unattended upgrade and the config file was not fixed up (i.e. the option > removed as suggested during the upgrade process). clamav did not start, > he fixed it manually and reported #826406. > This update will ignore the AllowSupplementaryGroups option whether set > or not and the behaviour will remain unchanged. All binaries will behave > the same except they won't complain about the AllowSupplementaryGroups > option. The plan is not to push this change into unstable so people > upgrading Jessie -> Stretch have to have this option removed at this > point. > > I am not sure if this update makes sense at this point since most people > got probably bitten by this, cursed my name and moved on. So if you > think that this update makes sense here it is - otherwise... > Please go ahead. Cheers, Julien
Processed: Re: Bug#826607: jessie-pu: package clamav/0.99.2+dfsg-0+deb8u2
Processing control commands: > tag -1 confirmed Bug #826607 [release.debian.org] jessie-pu: package clamav/0.99.2+dfsg-0+deb8u2 Added tag(s) confirmed. -- 826607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#827299: jessie-pu: package libxml2/2.9.1+dfsg1-5+deb8u3
Control: tag -1 confirmed On Tue, Jun 14, 2016 at 20:40:11 +0200, Salvatore Bonaccorso wrote: > Package: release.debian.org > Severity: normal > Tags: jessie > User: release.debian@packages.debian.org > Usertags: pu > > Hi SRM, > > It would be good to have libxml2 fixed as well in stable for #781232, > causing e.g. libsys-virt-perl FTBFS, or causing the problem for > libvirt as reported by Guido in #781232. > > Attached is the proposed debdiff, by cherry-picking commit > beb7281055dbf0ed4d041022a67c6c5cfd126f25 from upstream. > > Would that be accepted for the next jessie point release? > That seems fine, thanks. Feel free to upload. Cheers, Julien
Processed: Re: Bug#827299: jessie-pu: package libxml2/2.9.1+dfsg1-5+deb8u3
Processing control commands: > tag -1 confirmed Bug #827299 [release.debian.org] jessie-pu: package libxml2/2.9.1+dfsg1-5+deb8u3 Added tag(s) confirmed. -- 827299: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827299 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 807654
Processing commands for cont...@bugs.debian.org: > tags 807654 + confirmed Bug #807654 [release.debian.org] jessie-pu: package python-django/1.7.11-1 Added tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 807654: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807654 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#828177: jessie-pu: package unbound/1.4.22-3+deb8u2
On Sat, Jun 25, 2016 at 15:53:18 -0400, Robert Edmonds wrote:
> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
>
> Hi,
>
> The unbound package in jessie is affected by #807132 ("unbound-control
> breaks systemctl stop/start"). The bug report is long, but briefly, the
> unbound daemon can fail to start in several common scenarios, such as
> when the "unbound-control" utility is used to stop the daemon. One user
> reports that the unbound daemon is stopped but not subsequently started
> every time the unbound package is upgraded. This bug has been fixed in
> unstable by 1.5.9-1 and is currently marked severity important, though
> in my opinion this bug is severe enough to make it unsuitable for a
> release.
>
> The fix for this is shown below and is relatively simple, and was
> suggested by a member of the pkg-systemd team (Michael Biebl).
>
> I'd like to upload this to jessie.
>
May I take the opportunity to ask you to also fix the 'stop' action from
the init script?
We've been using this patch on the debian.org hosts for a year now.
Previously restarting the service would quite often result in no running
unbound, because (AIUI) systemd doesn't use the init script 'restart'
action (uses stop && start instead), the 'stop' action would not wait
for the process to actually die before returning, and then 'start' would
say "I'm already running, nothing to do".
--- /tmp/unbound-1.4.22/debian/unbound.init 2016-02-22 01:43:22.0
+0200
+++ modules/unbound/files/unbound.init 2015-05-17 16:50:09.699383800 +0200
@@ -121,7 +121,7 @@
stop)
if $UNBOUND_ENABLE; then
log_daemon_msg "Stopping $DESC" "$NAME"
-if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
--name $NAME; then
+if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
--name $NAME --retry 5; then
do_resolvconf_stop
log_end_msg 0
else
Cheers,
Julien
Processed: Re: Bug#827781: jessie-pu: package lxc/1:1.0.6-6+deb8u3
Processing control commands: > tag -1 confirmed Bug #827781 [release.debian.org] jessie-pu: package lxc/1:1.0.6-6+deb8u3 Added tag(s) confirmed. -- 827781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#827781: jessie-pu: package lxc/1:1.0.6-6+deb8u3
Control: tag -1 confirmed On Mon, Jun 20, 2016 at 17:26:33 -0300, Antonio Terceiro wrote: > Package: release.debian.org > Severity: normal > Tags: jessie > User: release.debian@packages.debian.org > Usertags: pu > > After init 1.34 dropped the `Essential: yes` bit, debootstrap will > produce systems that by default do not have /sbin/init (as intended). > This makes, however, lxc from jessie not able to produce a working > stretch/sid container. > > This has been fixed in 1:2.0.1-2 on unstable. > > Patch attached. > Ack. Please go ahead. Cheers, Julien
Bug#824872: jessie-pu: package nspr/2:4.12-2+deb8u1
Hi Julien, On Tue, Jun 28, 2016 at 11:46:06AM +0200, Julien Cristau wrote: > On Sun, May 29, 2016 at 14:58:51 +0200, Guido Günther wrote: > > > Upstream has an internal test suite which we enabled for the package > > builds in nspr as well as nss (+ some autopkg smoke test in nss > > itself). Howver I don't know as to what extend ABI compatibility is > > tested upstream. Hopefully Mike (cc:) may have some input on this. > > > > In order get some ideas about ABI compatibility myself I ran > > abi-compliance-tester. The results for both NSS and NSPR are also > > attached. We would do that on all point release updates. > > > > Note that the only (as to my understanding) serious regression has been > > pointed out by Florian as well: > > > > https://lists.debian.org/debian-lts/2015/11/msg00037.html > > https://bugzilla.redhat.com/show_bug.cgi?id=1260698 > > > > and it's unclear if this part of the ABI. The API break (removal of > > CERT_FindCertURLExtension) is bogus since the symbol was not exported. > > > I don't understand why you seem to be talking about ABI stability > issues. There are other kinds of bugs. The "other kind of bugs" were the reason why I enabled the test suites in nss/nspr and started to add some autpkg tests. What else would you expect? We could also add (and run) autopkg tests for reverse dependencies of nss/nspr over time. Cheers, -- Guido
Processed: tagging 807274, tagging 807274
Processing commands for cont...@bugs.debian.org:
> tags 807274 - moreinfo
Bug #807274 {Done: Jonathan Wiltshire } [release.debian.org]
wheezy-pu: package ca-certificates/20130119+deb7u2
Removed tag(s) moreinfo.
> tags 807274 + wontfix
Bug #807274 {Done: Jonathan Wiltshire } [release.debian.org]
wheezy-pu: package ca-certificates/20130119+deb7u2
Added tag(s) wontfix.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
807274: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807274
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
NEW changes in stable-new
Processing changes file: audiofile_0.3.6-2+deb8u1_arm64.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_armel.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_armhf.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_i386.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_mips.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_mipsel.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_powerpc.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_ppc64el.changes ACCEPT Processing changes file: audiofile_0.3.6-2+deb8u1_s390x.changes ACCEPT
Bug#827299: jessie-pu: package libxml2/2.9.1+dfsg1-5+deb8u3
Hi Julien, On Tue, Jun 28, 2016 at 11:59:37AM +0200, Julien Cristau wrote: > Control: tag -1 confirmed > > On Tue, Jun 14, 2016 at 20:40:11 +0200, Salvatore Bonaccorso wrote: > > > Package: release.debian.org > > Severity: normal > > Tags: jessie > > User: release.debian@packages.debian.org > > Usertags: pu > > > > Hi SRM, > > > > It would be good to have libxml2 fixed as well in stable for #781232, > > causing e.g. libsys-virt-perl FTBFS, or causing the problem for > > libvirt as reported by Guido in #781232. > > > > Attached is the proposed debdiff, by cherry-picking commit > > beb7281055dbf0ed4d041022a67c6c5cfd126f25 from upstream. > > > > Would that be accepted for the next jessie point release? > > > That seems fine, thanks. Feel free to upload. Thanks a lot for reviewing. I have uploaded it. Regards, Salvatore
Bug#827291: marked as done (transition: libpodofo)
Your message dated Tue, 28 Jun 2016 17:55:11 + with message-id <20160628175455.ge12...@chase.mapreri.org> and subject line Re: Bug#827291: transition: libpodofo has caused the Debian Bug report #827291, regarding transition: libpodofo 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.) -- 827291: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827291 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Forwarded: https://release.debian.org/transitions/html/auto-libpodofo.html User: release.debian@packages.debian.org Usertags: transition I've got another libpodofo soname bump, from libpodofo0.9.3 to libpodofo0.9.4. The 3 affected packages (scribus, calibre and krename) all builds fine. calibre is currently entangled with the Qt private abi bump, and currently can't be built due to pyqt5 not being rebuilt yet. With a rebuilt pyqt5 calibre builds fine and gains dependencies on both libpodofo0.9.4 and qtbase-abi-5-6-1; that means that you either prefer to hold calibre and rebuild it only once for both transitions, or rebuild it twice; please tell me what you prefer :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature --- End Message --- --- Begin Message --- On Mon, Jun 20, 2016 at 11:09:55AM +, Mattia Rizzolo wrote: > On Mon, Jun 20, 2016 at 01:07:42PM +0200, Emilio Pozuelo Monfort wrote: > > Go ahead. > > ta, uploaded. by now, new libpodofo entered testing, and the old one is gone. So, this is done. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature --- End Message ---
Bug#816389: transition: php7.0
On 27/06/16 10:27, Ondřej Surý wrote: > Hi release team, > > since we are down to: > > --cut here-- > Checking reverse dependencies... > # Broken Depends: > galette: galette > zeroc-ice: php-zeroc-ice > > # Broken Build-Depends: > php-guzzle: php5-cli > php5-curl > php-json: php5-dev > zeroc-ice: php5-dev (>= 5.4.0~rc6) > > Dependency problem found. > --cut here-- > > Could you perhaps force this to finally finish the transition? > > 1. push zeroc-ice+mumble to migrate together I asked for a decruft of zeroc-ice, which was blocking testing migration. That has migrated now. mumble can wait, it's not a blocker. > 2. remove galette and its rdeps from testing (it would be auto-removed > on June 30 anyway) Let's wait for that. > 3. remove php-guzzle + aws-sdk-for-php from testing (as auto-removal > doesn't seem to kick-in here) Hint added. > + gently push php-monolog from unstable into testing (perhaps just bump > severity of existing upload from 5 to 2 days) Hint added. > And then finally remove src:php5 and src:php-json from testing and > prevent it to migrate. (Strangely #815797 didn't stop src:php5 from > migrating new versions from unstable to testing.) Hint added. Cheers, Emilio
Bug#828630: jessie-pu: package libbusiness-creditcard-perl/0.33-1+deb8u1
On Sun, Jun 26, 2016 at 06:18:55PM +0200, gregor herrmann wrote:
> On Sun, 26 Jun 2016 17:00:36 +0100, Adam D. Barratt wrote:
>
> > On Sun, 2016-06-26 at 15:10 +0200, gregor herrmann wrote:
> > > I've prepared an update for libbusiness-creditcard-perl in
> > > jessie{,-updates} which fixes #814479 for stable users. The issue at
> > > hand is that the credit card ranges of several providers need to be
> > > updated.
> > That bug report says "[t]he most important change in this release is
> > recognition of new MasterCard ranges which will be issued starting in
> > October 2016". Given that (I'd really hope that) the next point release
> > will be well before October, are any of the other changes sufficiently
> > urgent to need a -updates release?
19 digit Visa cards are being issued already, but they do not appear to be
in widespread use yet.
None of the other changes are sufficiently urgent.
I do have concerns that we are "really hoping" a point release will be
in a specific timeframe. I'm not saying that it won't be or anything
bad about the release folks - I'm just concerned about _relying_ on such
a thing.
Are we tracking outstanding issues and their deadlines somewhere, and
have that list and our procedures/workflow documented such that we will
know to add the necessary packages -updates when point releases are
delayed? If not, I think that relying on an point update in a specific
future timeframe is a bad idea. It sets us up to fail.
All that said, I don't really have time or resources to push this
forward any more (I find this exhausting compared to writing code - I've
spent longer discusssing this than making the actual changes to the CPAN
module). So just go ahead and do whatever you think is best.
--
Ivan Kohler
President and Head Geek, Freeside Internet Services, Inc. http://freeside.biz/
Debian GNU/Linux developer | CPAN author | cat person | ski addict
Re: [Stretch] Status for architecture qualification
On 16/06/16 02:12, Hector Oron wrote: > I have put up the classical wiki page for Stretch at: > https://wiki.debian.org/ArchiveQualification/Stretch > > Please review and comment if required. That page is now outdated wrt mips concerns (see below). Do we need to duplicate the information that we already have on r.d.o/stretch/arch_qualify.html ? >>- s390, ppc64el and all arm ports have DSA concerns. > > I understand s390x and ppc64el DSA concerns have been clarified > in-list and those concerns are due to nature of the architecture. Sure, that's fine. > For the ARM ports, which have also been clarified, let me re-confirm: > * arm64 port has remote power and remote console available, plus > geo-redundancy, hardware is available and there is more hardware > coming in the pipeline. I am unsure why it is listed with multiple DSA > concerns, that surprises me (with DSA and ARM porter hats). The port > currently has 4 machines up, one down waiting to be replaced, in total > 5 and more coming. OK. I have removed the DSA concerns for arm64 from arch_qualify due to this. > * armhf/armel ports share hardware, we currently have 6 machines up > with remote power and remote console (of course that being development > boards is not so nice as server remote management goodies). Some > machines require a button press but local admins are great and always > happy to help. > > If none steps up explaining what are DSA concerns on the ARM > architectures, please update status requalification page dropping > those concerns. [DSA hat on] AIUI armhf/armel needing local admins should still be a concern, even if mild. Ideally that wouldn't be necessary. I have updated arch_qualify to reflect that. > I see armel has one porter listed, if more are needed, please add > myself and Riku Voipio (armel buildd maints). [ARM hat on] > I see arm64/armhf are covered porterwise however there should be more > porters available if needed. I have added you two as armel porters. >> * mips64el (NEW) >>- No DSA buildd (RT blocker) > > As far as I can see mips64el is using shared builds with mipsel port > hardware, those machines are DSA. We now got more hardware. This is no longer a concern. >>- Rebuild after import not complete (RT Blocker) > > Is there a list of packages that should be rebuilt? There's just one package missing, which is being worked on. See Aurelien's mail. >>- Not yet in testing (due to the above). > > Please let's work on getting it in testing ASAP I think the above > blockers can be worked out quite reasonably. Once db5.3 is rebuilt, we can enable mips64el in testing. > While working out ArchitectureQualification/Stretch wiki page I > believe everything is mostly fine for release, however I got a > personal concern on powerpc architecture. Is it well maintained? Does > it have porters? Does it have users? Does it still make sense to carry > along? Not sure about this one... I don't think anybody has stepped up as a porter. > Another concern (DSA) which I have added and explained in the wiki > page is the lack of georedundancy for the 'mips' port. Verbatim copy > from wiki follows: > "mips: It has 5 buildds in the same datacenter, current hardware are > routers or development boards which makes it very difficult to ship to > other places. The host providing redundancy (lucatelli) at UBC-ECE > must be decomissioned ASAP, leaving the port in a situation of not > geographic redundancy. However advanced plans exists to deploy mips > hardware in other data centers RSN." > > I'll keep you posted whenever there is progress on that area. I do not > believe it should be a blocker for release, but we must ensure geo > redundancy first. That's sorted out now. Cheers, Emilio
Bug#828630: jessie-pu: package libbusiness-creditcard-perl/0.33-1+deb8u1
On Tue, 2016-06-28 at 11:26 -0700, Ivan Kohler wrote:
> On Sun, Jun 26, 2016 at 06:18:55PM +0200, gregor herrmann wrote:
> > On Sun, 26 Jun 2016 17:00:36 +0100, Adam D. Barratt wrote:
> >
> > > On Sun, 2016-06-26 at 15:10 +0200, gregor herrmann wrote:
> > > > I've prepared an update for libbusiness-creditcard-perl in
> > > > jessie{,-updates} which fixes #814479 for stable users. The issue at
> > > > hand is that the credit card ranges of several providers need to be
> > > > updated.
> > > That bug report says "[t]he most important change in this release is
> > > recognition of new MasterCard ranges which will be issued starting in
> > > October 2016". Given that (I'd really hope that) the next point release
> > > will be well before October, are any of the other changes sufficiently
> > > urgent to need a -updates release?
[...]
> I do have concerns that we are "really hoping" a point release will be
> in a specific timeframe. I'm not saying that it won't be or anything
> bad about the release folks - I'm just concerned about _relying_ on such
> a thing.
I sense things may have got slightly lost in translation there - the
"really hope" wasn't an suggestion that it wouldn't have happened, more
that if it hasn't happened well before then, then something has gone
quite wrong.
In practical terms, given that the 8.5 point release was early this
month, 8.6 should be some time during August.
Regards,
Adam
prospective dates for next stable point release
Hi, does the stable release team already have a rough idea when the next stable release will be? Just asking so we (in pkg-systemd) can plan better ahead and don't need any last minute changes. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Next d-i alpha release: late June
Hi, Nicholas D Steeves (2016-06-28): > Could someone please tell me what the deadline is for adding expanded > partman-btrfs functionality? My proposal is in a thread on > debian-b...@lists.debian.org, subject: "Re: btrfs subvolume naming > scheme". A résumé of the read is: add the volume-manager-like > subvolume setup, and hopefully also add btrfs-style raid1 profile > support, and also the question of whether Debian should follow Ubuntu > and openSUSE subvolume naming conventions or Fedora/CentOS/RHEL ones. > The upstream wiki advocates Fedora/CentOS/RHEL-style. The upcoming release will use whatever is in testing at this point, so it'll be for a later release. KiBi. signature.asc Description: Digital signature
Re: Next d-i alpha release: late June
On 24 June 2016 at 18:22, Cyril Brulebois wrote: > Hi, > > I've just checked with Ben, it seems we could be getting a 4.6 kernel > suitable for testing (no regressions reported from previous version + > mips* FTBFS fix) shortly. We could think about urgenting it into testing > and releasing a new d-i early in the week, which seems OK on the -cd > side too. > > Glibc maintainers (esp. Aurélien): you should then have a clear path for > the new glibc in unstable. I'm not sure how much time it'll need to be > ready, that's why I'd slightly prefer if we could go for a d-i release > first (as outlined above). In case major blockers pop up, we would > probably let you go ahead with the new glibc upload and postpone d-i > until glibc reaches testing. > > Having checked with -release already, I'm freezing udebs right away. Could someone please tell me what the deadline is for adding expanded partman-btrfs functionality? My proposal is in a thread on debian-b...@lists.debian.org, subject: "Re: btrfs subvolume naming scheme". A résumé of the read is: add the volume-manager-like subvolume setup, and hopefully also add btrfs-style raid1 profile support, and also the question of whether Debian should follow Ubuntu and openSUSE subvolume naming conventions or Fedora/CentOS/RHEL ones. The upstream wiki advocates Fedora/CentOS/RHEL-style. Thank you, Nicholas
Bug#828177: jessie-pu: package unbound/1.4.22-3+deb8u2
Julien Cristau wrote: > May I take the opportunity to ask you to also fix the 'stop' action from > the init script? > > We've been using this patch on the debian.org hosts for a year now. > Previously restarting the service would quite often result in no running > unbound, because (AIUI) systemd doesn't use the init script 'restart' > action (uses stop && start instead), the 'stop' action would not wait > for the process to actually die before returning, and then 'start' would > say "I'm already running, nothing to do". Wow, thanks for pointing that out. Yes, I'd be happy to fix that one too in a stable update. > --- /tmp/unbound-1.4.22/debian/unbound.init 2016-02-22 01:43:22.0 > +0200 > +++ modules/unbound/files/unbound.init 2015-05-17 16:50:09.699383800 +0200 > @@ -121,7 +121,7 @@ > stop) > if $UNBOUND_ENABLE; then > log_daemon_msg "Stopping $DESC" "$NAME" > -if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE > --name $NAME; then > +if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE > --name $NAME --retry 5; then > do_resolvconf_stop > log_end_msg 0 > else > > Cheers, > Julien -- Robert Edmonds edmo...@debian.org
Re: Further perl-related candidates for stable-updates
On Thu, 2016-06-16 at 23:24 +0100, Dominic Hargreaves wrote: > On Sun, Jun 12, 2016 at 03:29:01PM +0100, Adam D. Barratt wrote: > > The update to Perl in the recent stable point release included a fix > > which broke backward compatibility, leading to issues in the > > libdevel-declare-perl package and, in turn, in other packages using > > Devel::Declare, such as libtrycatch-perl. > > Thanks for this. The test rebuilds have now completed. The other > notable issues which could warrant a stable-update were: > > - biber 1.9-3+deb8u1 - I was contacted by a user who has experienced > real world breakage due to this one. Ah, I thought this was just a test failure. Is it causing run-time issues as well? > - libcss-dom-perl 0.15-1+deb8u1 - possibly, although this was breakage > from the *previous* point release Indeed, the fact that this wasn't a new issue, and apparently wasn't affecting any users enough for them to bother reporting it, was why I hadn't pushed this one through -updates so far. Regards, Adam
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi Anton, Quoting Anton Gladky (2016-06-29 07:30:36) > are you planning to upload dose3 to jessie-backports? I would like to ask Ralf to do that because I never did a backport upload and would first have to familiarize myself with all the policies and technicalities for which I currently do not have time right now. Thanks! cheers, josch signature.asc Description: signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi Johannes, are you planning to upload dose3 to jessie-backports? Thanks Anton 2016-06-22 13:32 GMT+02:00 Johannes Schauer : > Hi all, > > Quoting Pietro Abate (2016-06-22 11:44:59) > > Hei josh, can you check this branch ? > > > > dose3.5.0-debian-jessie > > > > I don't have a vm with debian jessie ready, but I've used an opam > > switch that should be close enough to what we ave in jessie. > > thanks to Pietro we now have a patch that lets dose3 from experimental > work in > stable. I pushed it to the branch jessie-backports/master of the dose3 > packaging git. > > > https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/dose3.git/commit/?h=jessie-backports/master&id=e6b2a9b7321cf5639826ef73ff6f668dfc3fdf0d > > It builds fine inside a Jessie chroot with backports enabled (needed for > newer > librpm). > > Thanks! > > cheers, josch >
Re: prospective dates for next stable point release
Michael Biebl: > Hi, > > does the stable release team already have a rough idea when the next > stable release will be? Just asking so we (in pkg-systemd) can plan > better ahead and don't need any last minute changes. > > Regards, > Michael > Hi Michael, We do not have any exact (proposed) dates. Though: """ In practical terms, given that the 8.5 point release was early this month, 8.6 should be some time during August. """ (Cite: Adam[1]) Please keep in mind that we do not always keep a 2 month cadence, so the 8.6 might end up being slightly later than August. Thanks, ~Niels [1] <1467142488.16775.5.ca...@adam-barratt.org.uk>
