Re: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci

[intrigeri]

Hi again,

Thank you all for working both on workarounds for Debian CI and on
a proper upstream Linux kernel fix. Impressive cross-team work! :)

At this stage it seems clear that the bug and the corresponding ideal
fix are in the AppArmor part of src:linux, and the bug affects at
least src:apparmor and src:lxc. I'd like to reflect this in the
metadata of #1050256 by reassigning the bug to Linux, and adding
"affects" indications. I'll do so in the next few days unless someone
objects soon.

Doing so will also be an opportunity for me to sum up the problem for
the maintainers of src:linux, and let them know about our desired
timeline: ideally this would be fixed in the upcoming Bookworm
point-release.

This being said, if said timeline can't be met in src:linux, it'll be
up to the maintainers of LXC in Debian to decide what they want to do
in the upcoming Bookworm point-release.

If I misunderstood something important, please let me know.

Cheers,
-- 
intrigeri

Bug#933548: transition: gnome-desktop3

[intrigeri]

Hi,

Simon McVittie wrote:
> On Thu, 03 Oct 2019 at 08:48:35 +0200, Andreas Henriksson wrote:
>> The odd one out is libgtk2-perl which fails test 44:
> ...
>> GdkPixbuf [ warning ] Inline XPM data is broken: Invalid XPM header
>> not ok 44 - Don't crash on partial pixmap data

> I think this might be caused by better error handling in gdk-pixbuf 2.38.2
> (<https://gitlab.gnome.org/GNOME/gdk-pixbuf/commit/855ff36b933c078967ebbcf6d31799efccf9485d>),
> which I uploaded to make gdk-pixbuf silence the GTimeVal deprecation
> warnings in its own animation API, so that it wouldn't trigger -Werror
> in other packages if they don't actively use the animation API.

FWIW, libgtk2-perl is going away in Bullseye; most of its
reverse-dependencies were either ported to GTK 3, or not shipped in
Buster thanks to RC bugs I had filed, or removed from the archive.
What's left is tracked there:

 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912860
 - 
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=gtk2-removal=debian-perl%40lists.debian.org

The only reason why this set of packages was not automatically removed
from testing yet is that libgtk2-perl is still on the list of key
packages, because it's installed on many machines ("popcon").
I believe this is explained by historical reasons that are invalid
nowadays: this package used to have major reverse dependencies.

So, if it helps make the GNOME 3.34 transitions smoother, IMO it would
be fine to remove libgtk2-perl and its reverse-dependencies from
testing. Some might see this as a heavy hammer approach, but this was
announced a year ago to all affected maintainers; either way, it will
happen during the Bullseye cycle, eventually.

Cheers,
-- 
intrigeri

Bug#927199: unblock: gnome-shell/3.30.2-6

[intrigeri]

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

Please unblock package gnome-shell.

Changes are:

1. Vcs-Git, gbp.conf: point to the correct, Buster-specific, branches.

2. Avoid test failures on buildd environments where HOME, XDG_RUNTIME_DIR might
   be invalid. This allows the tests to run a bit further on s390x. The package
   still FTBFS there but as Simon McVittie wrote, "The remaining test failures
   on s390x look to me more like a bug in mozjs60 or gjs than a bug in
   gnome-shell" — which I guess is #927081.

3. Add missing French layouts to on screen keyboard (Closes: #926452)

   Due to a bug in the code that generates on screen keyboard layouts, the
   French layout ends up being generated from the French-Canadian layout (which
   is qwerty rather than azerty). This is a regression compared to Stretch.

   Fixed by cherry-picking the relevant upstream (3.32.0) commit.

4. Fix on screen keyboard language's menu closing the keyboard (Closes: #926453)

   GNOME Shell 3.30's on screen keyboard now offers a menu that allows selecting
   among the supported keyboard layouts. But moving the pointer over this menu
   closes the keyboard. This is a regression from Stretch, where that menu did
   not exist yet.

   Fixed by cherry-picking the relevant upstream (3.32.0) commits.

unblock gnome-shell/3.30.2-6
diff -Nru gnome-shell-3.30.2/debian/changelog 
gnome-shell-3.30.2/debian/changelog
--- gnome-shell-3.30.2/debian/changelog 2019-02-06 10:46:52.0 +0100
+++ gnome-shell-3.30.2/debian/changelog 2019-04-15 13:23:31.0 +0200
@@ -1,3 +1,33 @@
+gnome-shell (3.30.2-6) unstable; urgency=medium
+
+  * Team upload
+  * d/p/keyboard-Make-items-in-language-menu-unfocusable.patch,
+d/p/popupMenu-Respect-items-can-focus-property.patch:
+Add patches from upstream to fix the on-screen keyboard language's menu
+closing said keyboard (Closes: #926453)
+  * d/p/osk-layouts-Fix-French-layout.patch:
+Add patches from upstream to add missing French layouts to
+the on-screen keyboard (Closes: #926452)
+
+ -- intrigeri   Mon, 15 Apr 2019 11:23:31 +
+
+gnome-shell (3.30.2-5) unstable; urgency=medium
+
+  * Team upload
+  * Really create a suitable temporary XDG_RUNTIME_DIR for the unit tests
+  * Clean up debian/home with d/clean, not a dh_clean override
+
+ -- Simon McVittie   Sun, 14 Apr 2019 15:33:47 +0100
+
+gnome-shell (3.30.2-4) unstable; urgency=medium
+
+  * Team upload
+  * d/rules: Create a temporary HOME, XDG_RUNTIME_DIR for the unit tests.
+This hopefully fixes test failures and FTBFS on the s390x buildd.
+  * d/.gitignore: Add
+
+ -- Simon McVittie   Sun, 14 Apr 2019 10:40:33 +0100
+
 gnome-shell (3.30.2-3) unstable; urgency=medium
 
   * Team upload
diff -Nru gnome-shell-3.30.2/debian/clean gnome-shell-3.30.2/debian/clean
--- gnome-shell-3.30.2/debian/clean 1970-01-01 01:00:00.0 +0100
+++ gnome-shell-3.30.2/debian/clean 2019-04-15 13:23:31.0 +0200
@@ -0,0 +1 @@
+debian/home
diff -Nru gnome-shell-3.30.2/debian/control gnome-shell-3.30.2/debian/control
--- gnome-shell-3.30.2/debian/control   2019-02-06 10:46:52.0 +0100
+++ gnome-shell-3.30.2/debian/control   2019-04-15 13:23:31.0 +0200
@@ -55,7 +55,7 @@
 Rules-Requires-Root: no
 Standards-Version: 4.3.0
 Homepage: https://wiki.gnome.org/Projects/GnomeShell
-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-shell.git
+Vcs-Git: https://salsa.debian.org/gnome-team/gnome-shell.git -b debian/buster
 Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-shell
 
 Package: gnome-shell
diff -Nru gnome-shell-3.30.2/debian/control.in 
gnome-shell-3.30.2/debian/control.in
--- gnome-shell-3.30.2/debian/control.in2019-02-06 10:46:52.0 
+0100
+++ gnome-shell-3.30.2/debian/control.in2019-04-15 13:23:31.0 
+0200
@@ -51,7 +51,7 @@
 Rules-Requires-Root: no
 Standards-Version: 4.3.0
 Homepage: https://wiki.gnome.org/Projects/GnomeShell
-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-shell.git
+Vcs-Git: https://salsa.debian.org/gnome-team/gnome-shell.git -b debian/buster
 Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-shell
 
 Package: gnome-shell
diff -Nru gnome-shell-3.30.2/debian/gbp.conf gnome-shell-3.30.2/debian/gbp.conf
--- gnome-shell-3.30.2/debian/gbp.conf  2019-02-06 10:46:52.0 +0100
+++ gnome-shell-3.30.2/debian/gbp.conf  2019-04-15 13:23:31.0 +0200
@@ -1,7 +1,7 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/buster
+upstream-branch = upstream/3.30.x
 upstream-vcs-tag = %(version)s
 
 [buildpackage]
diff -Nru 
gnome-shell-3.30.2/debian/patches/keyboard-Make-items-in-language-menu-unfocusable.patch
 
gnome-shell-3.30.2/debian/patches/keyboard-Make-items-in-language-menu-unfocusable.patch
--- 
gnome-shell-3.30.2/debian/patches/keyboard-Make-items-in-language-menu-unfocusable.patc

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u2

[intrigeri]

Adam D. Barratt:
> Please feel free to upload.

Uploaded, thanks.

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u2

[intrigeri]

Hi,

Adam D. Barratt:
> What's the difference between this and +deb9u1? Is it simply this
> change:

> -++features-file=/etc/apparmor/features
> +++features-file=/usr/share/apparmor-features/features

> and the equivalent in debian/install?

Yes (modulo the timing matter regarding the Linux 4.14.x bug, which
was the only reason why +deb9u1 could not make it into a stable
release last time).

> The changelog going from -3 to -3+deb9u2 is confusing, particularly
> given that +deb9u1 has been available to users of proposed-updates for
> some time. If the above is correct, please keep the previous changelog
> stanza for +deb9u1 as-is and add a new entry for +deb9u2 describing the
> path change.

Done and accordingly adjusted the maintainer scripts to remove
the old (now obsolete) /etc/apparmor/features conffile from systems
that had +deb9u1 installed.

I'm attaching 2 updated debdiffs: one from the version in Stretch and
the other one from the version that's already in stable p-u.

Cheers,
-- 
intrigeri

diff -Nru apparmor-2.11.0/debian/apparmor.install apparmor-2.11.0/debian/apparmor.install
--- apparmor-2.11.0/debian/apparmor.install	2017-03-28 12:23:08.0 +0200
+++ apparmor-2.11.0/debian/apparmor.install	2018-02-27 07:46:39.0 +0100
@@ -1,4 +1,5 @@
 debian/apport/source_apparmor.py /usr/share/apport/package-hooks/
+debian/features /usr/share/apparmor-features/
 debian/lib/apparmor/functions /lib/apparmor/
 debian/lib/apparmor/profile-load /lib/apparmor/
 etc/apparmor/parser.conf
diff -Nru apparmor-2.11.0/debian/apparmor.maintscript apparmor-2.11.0/debian/apparmor.maintscript
--- apparmor-2.11.0/debian/apparmor.maintscript	2015-08-13 21:25:45.0 +0200
+++ apparmor-2.11.0/debian/apparmor.maintscript	2018-02-27 07:46:39.0 +0100
@@ -1,3 +1,4 @@
 rm_conffile /etc/apparmor/functions 2.5.1-0ubuntu4
 rm_conffile /etc/apparmor/rc.apparmor.functions 2.5.1-0ubuntu4
 rm_conffile /etc/apparmor.d/abstractions/ubuntu-sdk-base 2.8.0-0ubuntu20~
+rm_conffile /etc/apparmor/features 2.11.0-3+deb9u2~
diff -Nru apparmor-2.11.0/debian/changelog apparmor-2.11.0/debian/changelog
--- apparmor-2.11.0/debian/changelog	2017-03-28 12:29:15.0 +0200
+++ apparmor-2.11.0/debian/changelog	2018-02-27 07:46:39.0 +0100
@@ -1,3 +1,24 @@
+apparmor (2.11.0-3+deb9u2) UNRELEASED; urgency=medium
+
+  * Move the features file to /usr/share/apparmor-features;
+accordingly remove the old (now obsolete) '/etc/apparmor/features'
+conffile (Closes: #883682).
+  * Configure gbp for DEP-14 and avoid gbp-pq prefixing patches
+with numbers.
+
+ -- intrigeri <intrig...@debian.org>  Tue, 27 Feb 2018 06:46:39 +
+
+apparmor (2.11.0-3+deb9u1) stretch; urgency=medium
+
+  * Pin the AppArmor feature set to Stretch's kernel (Closes: #879585).
+This ensures Stretch systems, even when running a newer kernel (e.g.
+from backports), have their AppArmor feature set pinned to the one
+supported by the AppArmor policy shipped in Stretch. Otherwise they
+would experience breakage due to new AppArmor mediation features
+introduced in recent kernels.
+
+ -- intrigeri <intrig...@debian.org>  Sat, 25 Nov 2017 18:04:05 +
+
 apparmor (2.11.0-3) unstable; urgency=medium
 
   * Fix CVE-2017-6507: don't unload unknown profiles during package
diff -Nru apparmor-2.11.0/debian/features apparmor-2.11.0/debian/features
--- apparmor-2.11.0/debian/features	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/features	2018-02-27 07:46:39.0 +0100
@@ -0,0 +1,23 @@
+caps {mask {chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
+}
+}
+rlimit {mask {cpu fsize data stack core rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime
+}
+}
+capability {0xff
+}
+file {mask {create read write exec append mmap_exec link lock
+}
+}
+domain {change_profile {yes
+}
+change_onexec {yes
+}
+change_hatv {yes
+}
+change_hat {yes
+}
+}
+policy {set_load {yes
+}
+}
diff -Nru apparmor-2.11.0/debian/gbp.conf apparmor-2.11.0/debian/gbp.conf
--- apparmor-2.11.0/debian/gbp.conf	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/gbp.conf	2018-02-27 07:46:39.0 +0100
@@ -0,0 +1,6 @@
+[DEFAULT]
+pristine-tar = True
+debian-branch = debian/stretch
+upstream-branch = upstream/latest
+upstream-vcs-tag = v%(version)s
+patch-numbers = False
diff -Nru apparmor-2.11.0/debian/patches/pin-feature-set.patch apparmor-2.11.0/debian/patches/pin-feature-set.patch
--- apparmor-2.11.0/debian/patches/pin-feature-set.patch	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/patches/pin-feature-set.patch	2018-02

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u2

[intrigeri]

Control: tag -1 - moreinfo
Control: retitle -1 stretch-pu: package apparmor/2.11.0-3+deb9u2

Hi,

here's the updated debdiff; I've bumped the version in order to
avoid confusion.

This will now work fine except for Linux 4.14 to 4.14.12 that have the
bug which prevented us from including apparmor 2.11.0-3+deb9u1 in the
previous point release. The kernel fix has been in sid since
2018-01-15, in stretch-backports since 2018-01-16, and in testing
since 2018-01-20. So IMO the benefit (repairing stuff for Stretch
users running an up-to-date backported kernel) is worth the risk
(breaking stuff for Stretch users running an outdated Linux 4.14.x).

May I upload (with s/UNRELEASED/stretch/ of course)?

Cheers,
-- 
intrigeri

diff -Nru apparmor-2.11.0/debian/apparmor.install apparmor-2.11.0/debian/apparmor.install
--- apparmor-2.11.0/debian/apparmor.install	2017-03-28 12:23:08.0 +0200
+++ apparmor-2.11.0/debian/apparmor.install	2018-02-25 11:21:24.0 +0100
@@ -1,4 +1,5 @@
 debian/apport/source_apparmor.py /usr/share/apport/package-hooks/
+debian/features /usr/share/apparmor-features/
 debian/lib/apparmor/functions /lib/apparmor/
 debian/lib/apparmor/profile-load /lib/apparmor/
 etc/apparmor/parser.conf
diff -Nru apparmor-2.11.0/debian/changelog apparmor-2.11.0/debian/changelog
--- apparmor-2.11.0/debian/changelog	2017-03-28 12:29:15.0 +0200
+++ apparmor-2.11.0/debian/changelog	2018-02-25 11:21:24.0 +0100
@@ -1,3 +1,16 @@
+apparmor (2.11.0-3+deb9u2) UNRELEASED; urgency=medium
+
+  * Pin the AppArmor feature set to Stretch's kernel (Closes: #879585).
+This ensures Stretch systems, even when running a newer kernel (e.g.
+from backports), have their AppArmor feature set pinned to the one
+supported by the AppArmor policy shipped in Stretch. Otherwise they
+would experience breakage due to new AppArmor mediation features
+introduced in recent kernels.
+  * Configure gbp for DEP-14 and avoid gbp-pq prefixing patches
+with numbers.
+
+ -- intrigeri <intrig...@debian.org>  Sun, 25 Feb 2018 10:21:24 +
+
 apparmor (2.11.0-3) unstable; urgency=medium
 
   * Fix CVE-2017-6507: don't unload unknown profiles during package
diff -Nru apparmor-2.11.0/debian/features apparmor-2.11.0/debian/features
--- apparmor-2.11.0/debian/features	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/features	2018-02-25 11:21:24.0 +0100
@@ -0,0 +1,23 @@
+caps {mask {chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
+}
+}
+rlimit {mask {cpu fsize data stack core rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime
+}
+}
+capability {0xff
+}
+file {mask {create read write exec append mmap_exec link lock
+}
+}
+domain {change_profile {yes
+}
+change_onexec {yes
+}
+change_hatv {yes
+}
+change_hat {yes
+}
+}
+policy {set_load {yes
+}
+}
diff -Nru apparmor-2.11.0/debian/gbp.conf apparmor-2.11.0/debian/gbp.conf
--- apparmor-2.11.0/debian/gbp.conf	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/gbp.conf	2018-02-25 11:21:24.0 +0100
@@ -0,0 +1,6 @@
+[DEFAULT]
+pristine-tar = True
+debian-branch = debian/stretch
+upstream-branch = upstream/latest
+upstream-vcs-tag = v%(version)s
+patch-numbers = False
diff -Nru apparmor-2.11.0/debian/patches/pin-feature-set.patch apparmor-2.11.0/debian/patches/pin-feature-set.patch
--- apparmor-2.11.0/debian/patches/pin-feature-set.patch	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/patches/pin-feature-set.patch	2018-02-25 11:21:24.0 +0100
@@ -0,0 +1,18 @@
+Description: pin the AppArmor feature set to the one shipped by the apparmor package
+ .
+ Let's smooth UX on kernel upgrades and allow ourselves to update the AppArmor
+ policy in a relaxed manner.
+Bug-Debian: https://bugs.debian.org/879585
+Forwarded: not-needed
+Author: intrigeri <intrig...@debian.org>
+
+--- a/parser/parser.conf
 b/parser/parser.conf
+@@ -59,3 +59,7 @@
+ ## Adjust compression
+ #Optimize=compress-small
+ #Optimize=compress-fast
++
++## Pin feature set (avoid regressions when policy is lagging behind
++## the kernel)
++features-file=/usr/share/apparmor-features/features
diff -Nru apparmor-2.11.0/debian/patches/series apparmor-2.11.0/debian/patches/series
--- apparmor-2.11.0/debian/patches/series	2017-03-28 12:24:44.0 +0200
+++ apparmor-2.11.0/debian/patches/series	2018-02-25 11:21:24.0 +0100
@@ -2,6 +2,7 @@
 # Debian-specific patches
 #
 
+pin-feature-set.patch
 notify-group.patch
 
 #

Bug#884571: [Pkg-privacy-maintainers] Bug#884571: RM: torbrowser-launcher/0.1.9-1+deb8u3

[intrigeri]

Adam D. Barratt:
> # Broken Depends:
> onionshare/contrib: onionshare

So I guess Jessie should first get the fix we applied to onionshare in
testing/sid, i.e. move torbrowser-launcher to Recommends.

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi Adam & other release managers,

Adam D. Barratt:
> Any news on this?

Yes: the main blocker (in src:linux) has been fixed a few weeks ago
so it's now feasible to make progress on the src:apparmor side.
The next steps are tracked on #879585 that I've kept up-to-date.

> We're likely to be looking at freezing p-u for the next point
> release in a couple of weeks time.

I've been following the Stretch 9.4 scheduling thread with this in
mind. My current plan is to prepare an updated stable p-u around
February 24-25.

Thanks for the ping! :)

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Control: tag -1 + moreinfo

The issue in Linux 4.14 with feature set pinning vs. mount operations
was not fixed yet so the 2.11.0-3+deb9u1 package that was accepted in
the proposed-updates stable queue is not suitable for Stretch
currently ⇒ dear release team, feel free to reject or delete it if it
helps you ensure it does not land in the next point release.

Also, after some discussion with Fabian the proposed change was
re-implemented slightly differently in testing/sid; I want to do the
same for the Stretch proposed update ⇒ tagging "moreinfo".

I'm not sure if I should remove the "confirmed" and/or "pending" tag
so in doubt I'll leave it to you to do the right thing.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

intrigeri:
> At first glance this very much looks like a bug in the custom kernel
> you're using.

According to #883703 this bug affects the mainline Linux kernel as
well so this stretch-pu may break as many use cases at it'll repair
when running Linux 4.13+ on Stretch :/

Dear release team, how can we revert this s-p-u? Should I upload
2.11.0-3+deb9u2 that reverts to what we had in 2.11.0-3?

I'm very sorry for the mess.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi again Fabian & release team,

Fabian Grünbichler:
> On Wed, Dec 06, 2017 at 03:28:03PM +0100, intrigeri wrote:
>> > it potentially breaks systems using a custom/backports/newer kernel
>> > and AA profiles requiring features not supported by the pinned 4.9
>> > feature set.
>> 
>> In this case, "breaks" == the AppArmor confinement becomes weaker,
>> but the application keeps working.

> not the case for all scenarios unfortunately. LXC containers using the
> upstream profiles (and a kernel supporting the needed features) don't
> start anymore:

> apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 
> profile="/usr/bin/lxc-start" name="/" pid=21550 comm="lxc-start" flags="rw, 
> rslave"

Wow, Assuming you're indeed running with the 4.9 feature set I've
uploaded, that's definitely a bug: the 4.9 feature set is supposed to
fully disable mount mediation, so a mount denial should never happen.
At first glance this very much looks like a bug in the custom kernel
you're using.

If you can reproduce this with a pristine 4.13 or 4.14 Debian kernel,
then I'm very sorry and I agree we should revert this s-p-u until this
kernel bug is fixed in mainline; I'll gladly help you report this bug
upstream. If, however, you can't reproduce this bug with a Debian
kernel, well, then it's a bug in the kernel patches you've applied and
I think we should leave s-p-u as-is.

Possibly helpful: can you please share the content of
/etc/apparmor.d/cache/.features on the system that exposes
this problem?

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi,

I'll first clarify because it seems to me you're using the same word
with very different meanings in a comparison:

Fabian Grünbichler:
> TL;DR: while pinning the features prevents breakage for people using
> AA who install a more recent kernel from backports,

In this case, "breakage" == application stops working after installing
a newer kernel.

> it potentially breaks systems using a custom/backports/newer kernel
> and AA profiles requiring features not supported by the pinned 4.9
> feature set.

In this case, "breaks" == the AppArmor confinement becomes weaker,
but the application keeps working.

> since
> both the AA config file itself and the feature set file are conffiles,
> overriding is not easily possible without conffile modification.

Right. Sorry I did not think about this Debian derivative use case.

> I'll of course defer to intrigeri and the release team on whether to go
> ahead as-is, include the patch to allow easier overriding or postpone
> the apparmor stable update until the next cycle to allow for further
> discussion.

I slightly prefer fixing ASAP a non-default use case I want to support
in Debian (that's what we did in s-p-u already), even if it makes
a derivative's life slightly harder temporarily when using an much
more non-default configuration. I would understand if the release team
prefers to delay this update to a future point release though.

But I can live with both approaches. The vast majority of Stretch
users are not affected by either of the problems described
above anyway.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Adam D. Barratt:
> Please go ahead, bearing in mind that the window for getting fixes into
> the 9.3 point release closes during this weekend.

Thanks, uploaded.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi!

this update avoids breakage for Stretch users who have enabled AppArmor and run
Linux 4.14+ (e.g. from backports once it's there), by pinning the AppArmor
feature set in the kernel to the Stretch kernel's feature set, i.e. the feature
set the AppArmor policy shipped in Stretch supports (it's not ready to deal with
new AppArmor mediation features brought in recent kernels).

We already have exactly the same thing in current testing/sid, albeit with Linux
4.13's feature set for now.

Cheers!
diff -Nru apparmor-2.11.0/debian/apparmor.install 
apparmor-2.11.0/debian/apparmor.install
--- apparmor-2.11.0/debian/apparmor.install 2017-03-28 12:23:08.0 
+0200
+++ apparmor-2.11.0/debian/apparmor.install 2017-11-25 19:01:04.0 
+0100
@@ -1,4 +1,5 @@
 debian/apport/source_apparmor.py /usr/share/apport/package-hooks/
+debian/features /etc/apparmor/
 debian/lib/apparmor/functions /lib/apparmor/
 debian/lib/apparmor/profile-load /lib/apparmor/
 etc/apparmor/parser.conf
diff -Nru apparmor-2.11.0/debian/changelog apparmor-2.11.0/debian/changelog
--- apparmor-2.11.0/debian/changelog2017-03-28 12:29:15.0 +0200
+++ apparmor-2.11.0/debian/changelog2017-11-25 19:04:05.0 +0100
@@ -1,3 +1,14 @@
+apparmor (2.11.0-3+deb9u1) stretch; urgency=medium
+
+  * Pin the AppArmor feature set to Stretch's kernel (Closes: #879585).
+This ensures Stretch systems, even when running a newer kernel (e.g.
+from backports), have their AppArmor feature set pinned to the one
+supported by the AppArmor policy shipped in Stretch. Otherwise they
+would experience breakage due to new AppArmor mediation features
+introduced in recent kernels.
+
+ -- intrigeri <intrig...@debian.org>  Sat, 25 Nov 2017 18:04:05 +
+
 apparmor (2.11.0-3) unstable; urgency=medium
 
   * Fix CVE-2017-6507: don't unload unknown profiles during package
diff -Nru apparmor-2.11.0/debian/features apparmor-2.11.0/debian/features
--- apparmor-2.11.0/debian/features 1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/features 2017-11-25 18:55:55.0 +0100
@@ -0,0 +1,23 @@
+caps {mask {chown dac_override dac_read_search fowner fsetid kill setgid 
setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw 
ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct 
sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease 
audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm 
block_suspend audit_read
+}
+}
+rlimit {mask {cpu fsize data stack core rss nproc nofile memlock as locks 
sigpending msgqueue nice rtprio rttime
+}
+}
+capability {0xff
+}
+file {mask {create read write exec append mmap_exec link lock
+}
+}
+domain {change_profile {yes
+}
+change_onexec {yes
+}
+change_hatv {yes
+}
+change_hat {yes
+}
+}
+policy {set_load {yes
+}
+}
diff -Nru apparmor-2.11.0/debian/patches/pin-feature-set.patch 
apparmor-2.11.0/debian/patches/pin-feature-set.patch
--- apparmor-2.11.0/debian/patches/pin-feature-set.patch1970-01-01 
01:00:00.0 +0100
+++ apparmor-2.11.0/debian/patches/pin-feature-set.patch2017-11-25 
18:59:40.0 +0100
@@ -0,0 +1,18 @@
+Description: pin the AppArmor feature set to the one shipped by the apparmor 
package
+ .
+ Let's smooth UX on kernel upgrades and allow ourselves to update the AppArmor
+ policy in a relaxed manner.
+Bug-Debian: https://bugs.debian.org/879585 
+Forwarded: not-needed
+Author: intrigeri <intrig...@debian.org>
+
+--- a/parser/parser.conf
 b/parser/parser.conf
+@@ -59,3 +59,7 @@
+ ## Adjust compression
+ #Optimize=compress-small
+ #Optimize=compress-fast
++
++## Pin feature set (avoid regressions when policy is lagging behind
++## the kernel)
++features-file=/etc/apparmor/features
diff -Nru apparmor-2.11.0/debian/patches/series 
apparmor-2.11.0/debian/patches/series
--- apparmor-2.11.0/debian/patches/series   2017-03-28 12:24:44.0 
+0200
+++ apparmor-2.11.0/debian/patches/series   2017-11-25 18:59:40.0 
+0100
@@ -2,6 +2,7 @@
 # Debian-specific patches
 #
 
+pin-feature-set.patch
 notify-group.patch
 
 #

Bug#870911: stretch-pu: package torsocks/2.2.0-1+deb9u1

[intrigeri]

Adam D. Barratt:
> Control: tags -1 + pending

> On Tue, 2017-08-08 at 12:00 -0400, Adam D. Barratt wrote:
>> Please go ahead.

> Uploaded and flagged for acceptance.

Thanks!

Bug#870911: stretch-pu: package torsocks/2.2.0-1+deb9u1

[intrigeri]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi!

A few Debian users let me know that the upgrade to Stretch broke some important
use cases of torsocks (most notably, the way some ISPs have set up
SMTP-over-Tor-Onion-Services between their email servers); the upstream author
(X-Debbugs-Cc'ed) says a great number of people also complained about various
bugs that share the same root cause.

I would like to fix this in Stretch.

To my request, the upstream author has started maintaining a maint-2.2.x branch
with only fixes to such serious bugs. Currently that branch has one single
commit, that fixes the root cause of the aforementioned issues. One of the
affected users (X-Debbugs-Cc'ed) has tested it and confirms the fix works
for him.

Can I upload to stretch-pu with the attached debdiff?

Cheers,
-- 
intrigeri
diff -Nru torsocks-2.2.0/debian/changelog torsocks-2.2.0/debian/changelog
--- torsocks-2.2.0/debian/changelog 2016-10-19 16:48:08.0 -0400
+++ torsocks-2.2.0/debian/changelog 2017-08-05 11:37:43.0 -0400
@@ -1,3 +1,14 @@
+torsocks (2.2.0-1+deb9u1) stretch; urgency=medium
+
+  * Fix-check_addr-to-return-either-0-or-1.patch: new patch, from upstream
+maint-0.2.x branch, to fix a serious bug reported many times upstream
+and to me (privately) since the Stretch release
+(http://bugs.torproject.org/20871).
+  * Adjust debian/gbp.conf to ease working on our Git branch dedicated
+to Stretch.
+
+ -- intrigeri <intrig...@debian.org>  Sat, 05 Aug 2017 15:37:43 +
+
 torsocks (2.2.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #805741)
diff -Nru torsocks-2.2.0/debian/gbp.conf torsocks-2.2.0/debian/gbp.conf
--- torsocks-2.2.0/debian/gbp.conf  2016-10-19 16:48:08.0 -0400
+++ torsocks-2.2.0/debian/gbp.conf  2017-08-05 11:37:43.0 -0400
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = master
+debian-branch = stretch
 upstream-branch = upstream
diff -Nru 
torsocks-2.2.0/debian/patches/Fix-check_addr-to-return-either-0-or-1.patch 
torsocks-2.2.0/debian/patches/Fix-check_addr-to-return-either-0-or-1.patch
--- torsocks-2.2.0/debian/patches/Fix-check_addr-to-return-either-0-or-1.patch  
1969-12-31 19:00:00.0 -0500
+++ torsocks-2.2.0/debian/patches/Fix-check_addr-to-return-either-0-or-1.patch  
2017-08-05 11:37:43.0 -0400
@@ -0,0 +1,97 @@
+Bug: http://bugs.torproject.org/20871
+Origin: upstream, 
https://gitweb.torproject.org/torsocks.git/commit/?h=maint-2.2.x=15465aa7ace1d5e6dbb58e7adf37933b48e20250
+From: David Goulet <dgou...@ev0ke.net>
+Date: Fri, 24 Feb 2017 11:02:13 -0500
+Subject: Fix check_addr() to return either 0 or 1
+
+This function is used by utils_is_address_ipv4/6 and has to return 0 on
+error or 1 on success.
+
+Fixes #20871
+
+Signed-off-by: David Goulet <dgou...@ev0ke.net>
+---
+ src/common/utils.c| 11 ++-
+ tests/unit/test_config-file.c |  4 ++--
+ tests/unit/test_utils.c   |  8 
+ 3 files changed, 12 insertions(+), 11 deletions(-)
+
+diff --git a/src/common/utils.c b/src/common/utils.c
+index 82479af..8fe9c6e 100644
+--- a/src/common/utils.c
 b/src/common/utils.c
+@@ -45,8 +45,8 @@ static const char *localhost_names_v6[] = {
+ };
+ 
+ /*
+- * Return 1 if the given IP belongs in the af domain else return a negative
+- * value.
++ * Return 1 if the given IP belongs in the af domain else return 0 if the
++ * given ip is not a valid address or the af value is unknown.
+  */
+ static int check_addr(const char *ip, int af)
+ {
+@@ -56,9 +56,10 @@ static int check_addr(const char *ip, int af)
+   assert(ip);
+ 
+   ret = inet_pton(af, ip, buf);
+-  if (ret != 1) {
+-  ret = -1;
+-  }
++  if (ret == -1) {
++/* Possible if the af value is unknown to inet_pton. */
++ret = 0;
++  }
+ 
+   return ret;
+ }
+diff --git a/tests/unit/test_config-file.c b/tests/unit/test_config-file.c
+index 59e3115..b48094c 100644
+--- a/tests/unit/test_config-file.c
 b/tests/unit/test_config-file.c
+@@ -104,13 +104,13 @@ static void test_config_file_read_invalid_values(void)
+ 
+   memset(, 0x0, sizeof(config));
+   ret = config_file_read(fixture("config4"), );
+-  ok(ret == -1 &&
++  ok(ret == 0 &&
+   config.conf_file.tor_address == NULL,
+   "TorAddress invalid IPv4 returns -1");
+ 
+   memset(, 0x0, sizeof(config));
+   ret = config_file_read(fixture("config5"), );
+-  ok(ret == -1 &&
++  ok(ret == 0 &&
+   config.conf_file.tor_address == NULL,
+   "TorAddress invalid IPv6 returns -1");
+ 
+diff --git a/tests/unit/test_utils.c b/tests/unit/test_utils.c
+index dc5b0ca..95469d8 100644
+--- a/tests/unit/test_utils.c
 b/tests/unit/test_utils.c
+@@ -36,10 +36,10 @@ static void test_is_address_ipv

Re: Coordinating Debian Stretch & Tails 3.0 releases?

[intrigeri]

Hi,

intrigeri:
> Tails 3.0 will be released either on June 13 or on June 17.

We've decided to release Tails 3.0 on June 13: we have to release
_something_ on that day anyway (Firefox security update), so moving
the Tails 3.0 release to June 17 would have added a substantial amount
of work on our plate, and forced our users to upgrade twice in just
a few days.

> In any case, the Debian & Tails releases will be very close to each
> other :)

Still true! I hope this will benefit both projects from
a communication/publicity point of view :)

Cheers,
-- 
intrigeri

Re: Coordinating Debian Stretch & Tails 3.0 releases?

[intrigeri]

Hi Niels & others,

Niels Thykier:
> intrigeri:
> Apologies for the late reply on our part.

That's totally fine; thanks for caring! :)

> At this point we have now announced our planned release date as June
> 17th (https://lists.debian.org/debian-devel-announce/2017/05/msg2.html)

> I hope that date (still) works for you. :)

Tails 3.0 will be released either on June 13 or on June 17. In any
case, the Debian & Tails releases will be very close to each other :)

I'll let the release + publicity teams know as soon as we've reached
a conclusion on Tails' side:
https://mailman.boum.org/pipermail/tails-dev/2017-May/011451.html

Cheers,
-- 
intrigeri

Bug#863222: unblock: bilibop/0.5.2.1

[intrigeri]

Hi,

quidame:
> Version 0.5.2 (currently in testing) is affected
> by a bug [1] with severity "important", which now
> is fixed in version 0.5.2.1 (currently in unstable).

FWIW, this bug was discovered as it affected Tails, and we're shipping
the proposed diff there; it works fine for us :)

Cheers,
-- 
intrigeri

Re: Coordinating Debian Stretch & Tails 3.0 releases?

[intrigeri]

Hi,

here's one (and last) gentle ping about what follows:

> Tails 3.0 will be the first Tails release based on Stretch.
> It's currently scheduled for June 13, but we are somewhat flexible
> and would love to try and coordinate with the release of Debian
> Stretch: this would be interesting for communication and publicity,
> both for Debian and for Tails IMO. More precisely, if Debian Stretch
> is going to be release between June 10 and July 2, then we can
> probably release Tails 3.0 at the same time.

> I understand that Debian release date is not announced publicly in
> advance, and I think I understand why. So I guess this discussion
> needs to happen privately. On the Tails side, the only people who
> really need to be in the loop are ano...@riseup.net (my fellow Tails
> release manager) and myself. If that's fine with you, then I'll have
> anonym swear secrecy, and we will do our best to avoid leaking the
> info any further.

> If you prefer not to add this variable to the Debian release schedule
> equation: understood, don't bother, fine :)

> I also understand that this proposal may be premature at this point,
> and I can come back to it in a month if you prefer.

Cheers,
-- 
intrigeri

Re: Bug#861591: Bug#862071: password-store: FTBFS when built in a path with >= 74 characters

[intrigeri]

Dominic Hargreaves:
> Please could you rule on whether the above class of bugs should be RC
> for stretch? It doesn't seem productive at this late stage.

Indeed: I'll be happy to fix that in Buster or in a Stretch
point-release (also because I've noticed it breaks autopkgtests for
some packages of "mine"), but IMO this shouldn't block the Stretch
release, so a stretch-ignore tag would seem suitable to me.

Cheers,
-- 
intrigeri

Coordinating Debian Stretch & Tails 3.0 releases?

[intrigeri]

Hi,

Tails 3.0 will be the first Tails release based on Stretch.
It's currently scheduled for June 13, but we are somewhat flexible
and would love to try and coordinate with the release of Debian
Stretch: this would be interesting for communication and publicity,
both for Debian and for Tails IMO. More precisely, if Debian Stretch
is going to be release between June 10 and July 2, then we can
probably release Tails 3.0 at the same time.

I understand that Debian release date is not announced publicly in
advance, and I think I understand why. So I guess this discussion
needs to happen privately. On the Tails side, the only people who
really need to be in the loop are ano...@riseup.net (my fellow Tails
release manager) and myself. If that's fine with you, then I'll have
anonym swear secrecy, and we will do our best to avoid leaking the
info any further.

If you prefer not to add this variable to the Debian release schedule
equation: understood, don't bother, fine :)

I also understand that this proposal may be premature at this point,
and I can come back to it in a month if you prefer.

Cheers,
-- 
intrigeri

Bug#858900: unblock: apparmor/2.11.0-3

[intrigeri]

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

Hi!

please unblock package apparmor, that fixes CVE-2017-6507
aka. Debian bug #858768.

unblock apparmor/2.11.0-3
diff -Nru apparmor-2.11.0/debian/apparmor.init 
apparmor-2.11.0/debian/apparmor.init
--- apparmor-2.11.0/debian/apparmor.init2016-10-14 22:22:00.0 
+0200
+++ apparmor-2.11.0/debian/apparmor.init2017-03-28 12:23:08.0 
+0200
@@ -190,7 +190,6 @@
clear_cache
load_configured_profiles
rc=$?
-   unload_obsolete_profiles
 
log_end_msg "$rc"
;;
diff -Nru apparmor-2.11.0/debian/apparmor.install 
apparmor-2.11.0/debian/apparmor.install
--- apparmor-2.11.0/debian/apparmor.install 2016-10-14 22:14:49.0 
+0200
+++ apparmor-2.11.0/debian/apparmor.install 2017-03-28 12:23:08.0 
+0200
@@ -6,6 +6,7 @@
 sbin/apparmor_parser
 usr/bin/aa-enabled
 usr/bin/aa-exec
+usr/sbin/aa-remove-unknown
 usr/sbin/aa-status
 usr/sbin/apparmor_status
 etc/apparmor.d/tunables/alias
diff -Nru apparmor-2.11.0/debian/apparmor.manpages 
apparmor-2.11.0/debian/apparmor.manpages
--- apparmor-2.11.0/debian/apparmor.manpages2017-01-09 13:40:08.0 
+0100
+++ apparmor-2.11.0/debian/apparmor.manpages2017-03-28 12:23:08.0 
+0200
@@ -5,5 +5,6 @@
 debian/tmp/usr/share/man/man7/apparmor.7
 debian/tmp/usr/share/man/man1/aa-enabled.1
 debian/tmp/usr/share/man/man1/aa-exec.1
+debian/tmp/usr/share/man/man8/aa-remove-unknown.8
 debian/tmp/usr/share/man/man8/aa-status.8
 debian/tmp/usr/share/man/man8/apparmor_status.8
diff -Nru apparmor-2.11.0/debian/apparmor.postinst 
apparmor-2.11.0/debian/apparmor.postinst
--- apparmor-2.11.0/debian/apparmor.postinst2015-08-13 21:25:45.0 
+0200
+++ apparmor-2.11.0/debian/apparmor.postinst2017-03-28 12:23:08.0 
+0200
@@ -113,7 +113,6 @@
 if aa-status --enabled 2>/dev/null; then
 clear_cache || true
 load_configured_profiles || true
-unload_obsolete_profiles || true
 fi
 
 # Discard the return code and just make sure the md5sums are updated
diff -Nru apparmor-2.11.0/debian/apparmor.upstart 
apparmor-2.11.0/debian/apparmor.upstart
--- apparmor-2.11.0/debian/apparmor.upstart 2016-10-14 22:14:49.0 
+0200
+++ apparmor-2.11.0/debian/apparmor.upstart 2017-03-28 12:23:08.0 
+0200
@@ -83,7 +83,6 @@
 if [ "$ACTION" = "reload" ] || [ "$ACTION" = "force-reload" ]; then
 clear_cache
 load_configured_profiles
-   unload_obsolete_profiles
 exit 0
 fi
 
diff -Nru apparmor-2.11.0/debian/changelog apparmor-2.11.0/debian/changelog
--- apparmor-2.11.0/debian/changelog2017-01-21 11:05:51.0 +0100
+++ apparmor-2.11.0/debian/changelog2017-03-28 12:29:15.0 +0200
@@ -1,3 +1,19 @@
+apparmor (2.11.0-3) unstable; urgency=medium
+
+  * Fix CVE-2017-6507: don't unload unknown profiles during package
+configuration or when restarting the apparmor init script, upstart job, or
+systemd unit as this could leave processes unconfined (Closes: #858768).
+Changes cherry-picked from Ubuntu's 2.11.0-2ubuntu3:
+- debian/apparmor.postinst, debian/apparmor.init, debian/apparmor.upstart:
+  Remove calls to unload_obsolete_profiles()
+- debian/patches/utils-add-aa-remove-unknown.patch,
+  debian/apparmor.install debian/apparmor.manpages: Include a new utility,
+  aa-remove-unknown, which can be used to unload unknown profiles. Based
+  on an upstream patch but adjusted to source the /lib/apparmor/functions
+  shipped in Debian/Ubuntu.
+
+ -- intrigeri <intrig...@debian.org>  Tue, 28 Mar 2017 10:29:15 +
+
 apparmor (2.11.0-2) unstable; urgency=medium
 
   * Drop the apparmor-docs package (Closes: #851118).
diff -Nru apparmor-2.11.0/debian/patches/series 
apparmor-2.11.0/debian/patches/series
--- apparmor-2.11.0/debian/patches/series   2017-01-09 12:46:20.0 
+0100
+++ apparmor-2.11.0/debian/patches/series   2017-03-28 12:24:44.0 
+0200
@@ -18,6 +18,9 @@
 #profiles-grant-access-to-systemd-resolved.patch
 # Not adapted to Debian packaging of Chromium (Debian#742829)
 #add-chromium-browser.patch
+# Adapted to use debian/lib/apparmor/functions instead of
+# parser/rc.apparmor.functions
+utils-add-aa-remove-unknown.patch
 
 #
 # Patches not yet upstream
diff -Nru apparmor-2.11.0/debian/patches/utils-add-aa-remove-unknown.patch 
apparmor-2.11.0/debian/patches/utils-add-aa-remove-unknown.patch
--- apparmor-2.11.0/debian/patches/utils-add-aa-remove-unknown.patch
1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/patches/utils-add-aa-remove-unknown.patch
2017-03-28 12:26:56.0 +0200
@@ -0,0 +1,214 @@
+Description: utils: Add aa-remove-unknown utility to unload unknown profile

Bug#858115: unblock: mat/0.6.1-4

[intrigeri]

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

Please unblock package mat 0.6.1-4, that fixes:

 * a bug with security implications (Jessie is not affected): one of the
   operation modes of MAT silently fails to clean metadata;
 * the --backup option, which is required to fix the aforementioned
   bug.

Both patches are minimal, trivial fixes cherry-picked from upstream; but to be
fair, I have authored them upstream in the first place. I've asked the current
upstream maintainer to request a CVE and put a new upstream release out.

autopkgtests pass locally, ci.debian.net hasn't tested the package yet.

unblock mat/0.6.1-4

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
 changelog|   13 ++
 patches/Make-the-Nautilus-extension-work-again.patch |   31 +++
 patches/Revert-Improves-a-bit-portability.patch  |   38 +++
 patches/series   |2 +
 4 files changed, 84 insertions(+)

diff -Nru mat-0.6.1/debian/changelog mat-0.6.1/debian/changelog
--- mat-0.6.1/debian/changelog  2016-08-26 08:40:53.0 +
+++ mat-0.6.1/debian/changelog  2017-03-18 11:28:06.0 +
@@ -1,3 +1,16 @@
+mat (0.6.1-4) unstable; urgency=medium
+
+  * New patch (Make-the-Nautilus-extension-work-again.patch) cherry-picked
+from upstream: fix the Nautilus extension silently failing
+(Closes: #858058).
+  * New patch (Revert-Improves-a-bit-portability.patch), cherry-picked
+from upstream: fix the --backup option. This option is not only available
+in all interfaces (CLI, GUI), but it's forcibly enabled in the Nautilus
+extension, so it has to work for the Nautilus extension to work.
+Thus, this additional change is needed to fully fix #858058.
+
+ -- intrigeri <intrig...@debian.org>  Sat, 18 Mar 2017 11:28:06 +
+
 mat (0.6.1-3) unstable; urgency=medium
 
   * Update documentation of recommended packages in README.Debian.
diff -Nru mat-0.6.1/debian/patches/Make-the-Nautilus-extension-work-again.patch 
mat-0.6.1/debian/patches/Make-the-Nautilus-extension-work-again.patch
--- mat-0.6.1/debian/patches/Make-the-Nautilus-extension-work-again.patch   
1970-01-01 00:00:00.0 +
+++ mat-0.6.1/debian/patches/Make-the-Nautilus-extension-work-again.patch   
2017-03-18 11:28:06.0 +
@@ -0,0 +1,31 @@
+From: intrigeri <intrig...@boum.org>
+Date: Sat, 18 Mar 2017 08:31:27 +
+Debian-Bug: https://bugs.debian.org/858058
+Origin: 
https://0xacab.org/mat/mat/commit/94ca62a429bb6a3a5f293de26053e54bbfeea9f9
+Subject: Make the Nautilus extension work again.
+
+It was broken since commit 0d1fe2555e90db35eeb531a1b6026ff64f1f5ae5,
+i.e. in the MAT 0.6 and 0.6.1 releases.
+
+The impact is: the MAT extension for Nautilus fails to clean metadata,
+without making the user aware of it.
+
+This bug was discovered by the Tails contributor sajolida, and initially
+reported to Debian as https://bugs.debian.org/858058.
+---
+ nautilus/nautilus-mat.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/nautilus/nautilus-mat.py b/nautilus/nautilus-mat.py
+index 0974bef..7c2d740 100644
+--- a/nautilus/nautilus-mat.py
 b/nautilus/nautilus-mat.py
+@@ -77,7 +77,7 @@ class MatExtension(GObject.GObject, Nautilus.MenuProvider):
+ :param current_file: Name of the selected file
+ :param menu: Menu id from which the callback was activated. Unused.
+ """
+-if file.is_gone():
++if current_file.is_gone():
+ return
+ 
+ # files url in nautilus are starting with 'file://', of length 7
diff -Nru mat-0.6.1/debian/patches/Revert-Improves-a-bit-portability.patch 
mat-0.6.1/debian/patches/Revert-Improves-a-bit-portability.patch
--- mat-0.6.1/debian/patches/Revert-Improves-a-bit-portability.patch
1970-01-01 00:00:00.0 +
+++ mat-0.6.1/debian/patches/Revert-Improves-a-bit-portability.patch
2017-03-18 11:28:06.0 +0000
@@ -0,0 +1,38 @@
+From: intrigeri <intrig...@boum.org>
+Date: Sat, 18 Mar 2017 11:21:57 +
+Origin: 
https://0xacab.org/mat/mat/commit/8f6303a1f26fe8dad83ba96ab8328dbdfa3af59a
+Bug-Upstream: https://0xacab.org/mat/mat/issues/11526
+Subject: Revert "Improves a bit portability"
+
+This reverts commit d054e313d7d83ec0089f7e0efe6b8a988fe99b3a.
+
+os.path.join is *not* suitable for concatenating parts of the basename of
+a file.
+
+Closes: #11526
+---
+ libmat/parser.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libmat/parser.py b/libmat/parser.py
+index 2a82a25..1b58f87 100644
+--- a/libmat/

Bug#857334: unblock: onioncat/0.2.2+svn569-2

[intrigeri]

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

Please unblock package onioncat, that fixes one RC bug (#857262)
and adds another missing dependency (no bug report).

unblock onioncat/0.2.2+svn569-2
diff -Nru onioncat-0.2.2+svn569/debian/changelog 
onioncat-0.2.2+svn569/debian/changelog
--- onioncat-0.2.2+svn569/debian/changelog  2016-01-24 18:36:57.0 
+0100
+++ onioncat-0.2.2+svn569/debian/changelog  2017-03-09 19:44:16.0 
+0100
@@ -1,3 +1,12 @@
+onioncat (0.2.2+svn569-2) unstable; urgency=medium
+
+  * Add missing dependency on net-tools: OnionCat hard-codes
+ifconfig usage (Closes: #857262).
+  * Add missing dependency on lsb-base (>= 3.0-6): the onioncat
+initscript sources the /lib/lsb/init-functions utility functions.
+
+ -- intrigeri <intrig...@debian.org>  Thu, 09 Mar 2017 18:44:16 +
+
 onioncat (0.2.2+svn569-1) unstable; urgency=medium
 
   [ Ximin Luo ]
diff -Nru onioncat-0.2.2+svn569/debian/control 
onioncat-0.2.2+svn569/debian/control
--- onioncat-0.2.2+svn569/debian/control2016-01-24 18:36:57.0 
+0100
+++ onioncat-0.2.2+svn569/debian/control2017-03-09 19:44:16.0 
+0100
@@ -16,7 +16,9 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- adduser
+ adduser,
+ lsb-base (>= 3.0-6),
+ net-tools
 Recommends: tor
 Description: IP-Transparent Tor hidden service connector
  OnionCat creates a transparent IP layer on top of Tor hidden

Re: Uploaded Boost 1.63 -- to be included in upcoming release

[intrigeri]

Hi,

[disclaimer: I'm not part of the release team]

Steve Robbins:
> Just a heads-up for the release and ftp-masters: I have uploaded Boost 1.63 
> and it is currently awaiting processing in the NEW queue.  It is very close 
> to 
> the deadline for accepting new packages, so I thought I should outline my 
> rationale for this upload.

My understanding of what the release team explained [1] is that
January 5 is the deadline for "New (source) packages in stretch", and
"New packages must be in testing before January 5th". So I think we're
already past the deadline for accepting new packages, given the
10-days migration delay.

[1] https://lists.debian.org/debian-devel-announce/2016/11/msg2.html

Cheers,
-- 
intrigeri

Please reject mat 0.5.2-3+deb8u1

[intrigeri]

Hi!

I've uploaded mat 0.5.2-3+deb8u1 by mistake to the "jessie-security"
distribution on ssh.upload.debian.org, while it should have gone to
security-master.d.o. Looks like it has therefore landed in stable-new.
Please reject/remove it, and sorry for the burden!

Cheers,
-- 
intrigeri

Re: libgnupg-interface-perl not migrating to testing

[intrigeri]

Hi again,

Adam D. Barratt:
> Therefore unstable's libgnupg-interface-perl and testing's
> libmail-gnupg-perl are not co-installable, but the latter depends on the
> former.

Got it. I've taught the BTS that #836259 affects gnupg2 2.1.11-7,
which should help gnupg2 2.1.15-2 migrate to testing, which should in
turn fix the root cause of this co-installability problem.

Thanks again!

Cheers,
-- 
intrigeri

Re: libgnupg-interface-perl not migrating to testing

[intrigeri]

Hi release team!

gregor herrmann:
> On Sun, 11 Sep 2016 11:33:26 +0200, intrigeri wrote:

>> I need help to understand why libgnupg-interface-perl 0.52-3 has not
>> made its way into testing yet.
>> https://qa.debian.org/excuses.php?package=libgnupg-interface-perl
>> says it's a valid candidate.

> grep-excuses says the same, tracker as well.

>> Any clue?

> Sorry, no idea either.
> Maybe ask the release team?

Can anyone please help me understand about why libgnupg-interface-perl
is not migrating to testing?

Thanks in advance!

Cheers,
-- 
intrigeri

Bug#805634: tbl: auto-updating & apparmor

[intrigeri]

Hi,

Holger Levsen wrote (06 Dec 2015 10:17:48 GMT) :
> On Freitag, 20. November 2015, intrigeri wrote:
>> Holger Levsen wrote (20 Nov 2015 13:10:46 GMT) :
>> > * Tor Browser Lanucher no longer attempts to auto-update, now that
>> Is Tor Browser's self-upgrade feature compatible with the AppArmor
>> profiles shipped by the package? It doesn't look like it at first
>> glance, but I didn't tested this yet.

> did you have a chance to test this by now?

Sorry I gave the impression I was going to do it, this wasn't my
intention. I didn't test it yet. Like any torbrowser-launcher
0.2.2 + AppArmor user I will have to go through it for the next Tor
Browser update (December 15). Expect bug reports :)

Cheers,
-- 
intrigeri

Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1

[intrigeri]

Hi,

Holger Levsen wrote (20 Nov 2015 13:10:46 GMT) :
> * Tor Browser Lanucher no longer attempts to auto-update, now that
>   Tor Browser has this feature

Is Tor Browser's self-upgrade feature compatible with the AppArmor
profiles shipped by the package? It doesn't look like it at first
glance, but I didn't tested this yet.

Cheers,
-- 
intrigeri

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[intrigeri]

Hi,

Emilio Pozuelo Monfort wrote (30 Oct 2015 13:34:21 GMT) :
> #787446 - libdevel-findref-perl: has one rdep and one build-rdep:

> Checking reverse dependencies...
> # Broken Depends:
> libtest-bdd-cucumber-perl: libtest-bdd-cucumber-perl

> # Broken Build-Depends:
> libtest-bdd-cucumber-perl: libdevel-findref-perl

Thanks fot the heads up.

Devel::FindRef is optional since Test::BDD::Cucumber 0.36 ⇒ I've just
pushed changes to Vcs-Git that drop the hard {build,run}time
dependencies. Lots of Tails -specific code is tested with
Test::BDD::Cucumber, so I'll try to keep it in the archive.

Cheers,
-- 
intrigeri

Bug#796088: jessie-pu: package libvirt/1.2.9-9+deb8u1

[intrigeri]

Control: tag -1 - moreinfo

Hi,

Guido Günther wrote (20 Aug 2015 11:57:36 GMT) :
 On Wed, Aug 19, 2015 at 04:53:32PM +0100, Adam D. Barratt wrote:
 I have to admit that I'm also confused by the patch for #786650:
[...]
 That seems to make sense...
 
 +   # for hostdev
 +   /sys/devices/ r,
 +   /sys/devices/** r,
 ++  deny /dev/sd* r,
 ++  deny /dev/vd* r,
 ++  deny /dev/dm-* r,
 ++  deny /dev/mapper/ r,
 ++  deny /dev/mapper/* r,
 
 ... these not so much.

 According to Felix (cc:) these are only here to silence some denials
 filling the logs otherwise. So they cause not harm but are not mentioned
 in the changelog. I could fix that up before an upload.

We've discussed this on #786650, and as a result here's an updated
debdiff: the only change, compared to the one Guido submitted
initially, is that Allow-access-to-libnl-3-config-files.patch now does
not include these changes, that are unrelated to #786650, that this
patch as meant to fix.

I've just built and tested on Jessie, and could successfully start
a VM with AppArmor enforced.

Cheers,
--
intrigeri

diff -Nru libvirt-1.2.9/debian/changelog libvirt-1.2.9/debian/changelog
--- libvirt-1.2.9/debian/changelog	2015-02-06 15:43:48.0 +0100
+++ libvirt-1.2.9/debian/changelog	2015-08-24 16:21:08.0 +0200
@@ -1,3 +1,28 @@
+libvirt (1.2.9-9+deb8u1) jessie; urgency=medium
+
+  [ Guido Günther ]
+  * [8e4cf5a] Teach virt-aa-helper to use TEMPLATE.qemu if the domain is kvm
+or kqemu.
+Thanks to Luke Faraone for the report (Closes: #786650)
+  * [ad1ff0b] Adjust gbp.conf for jessie
+  * [c830a54] Disable test suite due to libxml2 bug #781232 in jessie
+  * [be70aec] Fix crash on live migration
+this supplements 07dbec0a64783f644854a22aa0355720f0328d17.
+Thanks to Eckebrecht von Pappenheim (Closes: #7788171)
+
+  [ Felix Geyer ]
+  * [9fb6c59] Allow access to libnl-3 configuration (Closes: #786652)
+
+  [ intrigeri ]
+  * Allow-access-to-libnl-3-config-files.patch: revert changes that are
+unrelated to the bug this patch is meant to fix.
+
+  [ Daniel P. Berrange ]
+  * [afae69a] Report original error when QMP probing fails with new QEMU
+(Closes: #780093)
+
+ -- Guido Günther a...@sigxcpu.org  Thu, 13 Aug 2015 15:56:49 +0200
+
 libvirt (1.2.9-9) unstable; urgency=medium
 
   * [4c14b83] qemu: Don't try to parse -help for new QEMU.
diff -Nru libvirt-1.2.9/debian/gbp.conf libvirt-1.2.9/debian/gbp.conf
--- libvirt-1.2.9/debian/gbp.conf	2015-02-05 21:22:11.0 +0100
+++ libvirt-1.2.9/debian/gbp.conf	2015-08-24 16:21:08.0 +0200
@@ -1,6 +1,7 @@
 [DEFAULT]
 upstream-branch=upstream/sid
-debian-branch=master
+debian-branch=debian/jessie
+dist=jessie
 
 [gbp-pq]
 patch-numbers = False
diff -Nru libvirt-1.2.9/debian/patches/Allow-access-to-libnl-3-config-files.patch libvirt-1.2.9/debian/patches/Allow-access-to-libnl-3-config-files.patch
--- libvirt-1.2.9/debian/patches/Allow-access-to-libnl-3-config-files.patch	1970-01-01 01:00:00.0 +0100
+++ libvirt-1.2.9/debian/patches/Allow-access-to-libnl-3-config-files.patch	2015-08-24 16:21:08.0 +0200
@@ -0,0 +1,22 @@
+From: Felix Geyer fge...@debian.org
+Date: Sat, 13 Jun 2015 10:22:40 +0200
+Subject: Allow access to libnl-3 config files
+
+Closes: #786650
+---
+ examples/apparmor/usr.lib.libvirt.virt-aa-helper | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/examples/apparmor/usr.lib.libvirt.virt-aa-helper b/examples/apparmor/usr.lib.libvirt.virt-aa-helper
+index bceaaff..a3c9938 100644
+--- a/examples/apparmor/usr.lib.libvirt.virt-aa-helper
 b/examples/apparmor/usr.lib.libvirt.virt-aa-helper
+@@ -16,6 +16,8 @@
+   owner @{PROC}/[0-9]*/status r,
+   @{PROC}/filesystems r,
+ 
++  /etc/libnl-3/classid r,
++
+   # for hostdev
+   /sys/devices/ r,
+   /sys/devices/** r,
diff -Nru libvirt-1.2.9/debian/patches/Fix-crash-on-live-migration.patch libvirt-1.2.9/debian/patches/Fix-crash-on-live-migration.patch
--- libvirt-1.2.9/debian/patches/Fix-crash-on-live-migration.patch	1970-01-01 01:00:00.0 +0100
+++ libvirt-1.2.9/debian/patches/Fix-crash-on-live-migration.patch	2015-08-24 16:21:08.0 +0200
@@ -0,0 +1,25 @@
+From: =?utf-8?q?Guido_G=C3=BCnther?= a...@sigxcpu.org
+Date: Sat, 13 Jun 2015 10:38:26 +0200
+Subject: Fix crash on live migration
+
+this supplements 07dbec0a64783f644854a22aa0355720f0328d17.
+
+Closes: #7788171
+Thanks: Eckebrecht von Pappenheim
+---
+ src/qemu/qemu_migration.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
+index e18556f..87f3f1a 100644
+--- a/src/qemu/qemu_migration.c
 b/src/qemu/qemu_migration.c
+@@ -2746,7 +2746,7 @@ qemuMigrationPrepareAny(virQEMUDriverPtr driver,
+ QEMU_ASYNC_JOB_MIGRATION_IN)  0)
+ goto stop;
+ 
+-if (STREQ(protocol, rdma) 
++if (STREQ_NULLABLE(protocol, rdma) 
+ virProcessSetMaxMemLock(vm-pid, vm-def-mem.hard_limit  10)  0) {
+ goto stop

Bug#796112: jessie-pu: package syslinux/3:6.03+dfsg-5+deb8u1

[intrigeri]

Adam D. Barratt wrote (19 Aug 2015 15:41:26 GMT) :
 Please go ahead; thanks.

Uploaded. Thanks!

Bug#796088: jessie-pu: package libvirt/1.2.9-9+deb8u1

[intrigeri]

Hi,

Guido Günther wrote (19 Aug 2015 11:22:58 GMT) :
 the I'd like to update libvirt in unstable to fix the broken AppArmor
 support, [...]

I'd like to add that it feels important to me to fix these bugs in
Jessie, in order to avoid creating a culture of just disable
AppArmor among Debian users (see e.g. how many, if not most, RHEL
users relate to SELinux). Sorry this has to be handled via s-p-u.

FWIW, I've reviewed and successfully tested the AppArmor changes on
sid. Also, I seem to remember that someone else (Felix Geyer?) has
tested these patches on Jessie as well.

Cheers,
-- 
intrigeri

Bug#796112: jessie-pu: package syslinux/3:6.03+dfsg-5+deb8u1

[intrigeri]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi release team,

as reported on #780765, syslinux fails to boot on some Chromebooks.

This was fixed in Ubuntu, Tails and Debian unstable between March and May, with
the patches that the debdiff applies. Ubuntu and Tails users have reported that
it indeed fixed the problem for them, and I could not find any trace of
regression reports.

These patches made it to upstream Git a few months ago:

  http://repo.or.cz/w/syslinux.git/commit/0a2dbb3
  http://repo.or.cz/w/syslinux.git/commit/83aad4f

I'd like to see this fixed in Jessie. The syslinux package maintainer ack'ed the
idea on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780765#62

Cheers!
diff -Nru syslinux-6.03+dfsg/debian/changelog syslinux-6.03+dfsg/debian/changelog
--- syslinux-6.03+dfsg/debian/changelog	2015-01-07 07:49:34.0 +0100
+++ syslinux-6.03+dfsg/debian/changelog	2015-08-18 17:23:09.0 +0200
@@ -1,3 +1,12 @@
+syslinux (3:6.03+dfsg-5+deb8u1) jessie; urgency=low
+
+  * Cherry-pick upstream patches that fix booting on some Chromebooks
+(Closes: #780765):
+- 0005-load-linux-correct-type.patch
+- 0006-load-linux-protected-mode.patch
+
+ -- intrigeri intrig...@debian.org  Tue, 18 Aug 2015 17:21:55 +0200
+
 syslinux (3:6.03+dfsg-5) unstable; urgency=low
 
   * Moving source lintian-overrides to newer location.
diff -Nru syslinux-6.03+dfsg/debian/patches/0005-load-linux-correct-type.patch syslinux-6.03+dfsg/debian/patches/0005-load-linux-correct-type.patch
--- syslinux-6.03+dfsg/debian/patches/0005-load-linux-correct-type.patch	1970-01-01 01:00:00.0 +0100
+++ syslinux-6.03+dfsg/debian/patches/0005-load-linux-correct-type.patch	2015-08-18 17:18:52.0 +0200
@@ -0,0 +1,20 @@
+Author: Scot Doyle lkm...@scotdoyle.com
+Origin: upstream, http://repo.or.cz/w/syslinux.git/commit/83aad4f
+Description: load_linux: correct a type
+ Correct base's type to match its initialization from prot_mode_base and
+ passage to syslinux_memmap_find(). Tested with extlinux.
+
+diff -Naurp syslinux.orig/com32/lib/syslinux/load_linux.c syslinux/com32/lib/syslinux/load_linux.c
+--- syslinux.orig/com32/lib/syslinux/load_linux.c
 syslinux/com32/lib/syslinux/load_linux.c
+@@ -155,8 +155,8 @@ int bios_boot_linux(void *kernel_buf, si
+ 		char *cmdline)
+ {
+ struct linux_header hdr, *whdr;
+-size_t real_mode_size, prot_mode_size, base;
+-addr_t real_mode_base, prot_mode_base, prot_mode_max;
++size_t real_mode_size, prot_mode_size;
++addr_t real_mode_base, prot_mode_base, prot_mode_max, base;
+ addr_t irf_size;
+ size_t cmdline_size, cmdline_offset;
+ struct setup_data *sdp;
diff -Nru syslinux-6.03+dfsg/debian/patches/0006-load-linux-protected-mode.patch syslinux-6.03+dfsg/debian/patches/0006-load-linux-protected-mode.patch
--- syslinux-6.03+dfsg/debian/patches/0006-load-linux-protected-mode.patch	1970-01-01 01:00:00.0 +0100
+++ syslinux-6.03+dfsg/debian/patches/0006-load-linux-protected-mode.patch	2015-08-18 17:18:38.0 +0200
@@ -0,0 +1,26 @@
+Author: Scot Doyle lkm...@scotdoyle.com
+Origin: upstream, http://repo.or.cz/w/syslinux.git/commit/0a2dbb3
+Description: load_linux: relocate protected-mode code as intended
+ If the kernel is relocatable and the protected mode code will not fit
+ in the initially determined location, that code will be moved to the
+ next available location. However, beginning with commit 8f470e7b, the
+ code is moved to the initially determined location instead of the next
+ available location because prot_mode_base is no longer updated to the
+ correct location. Since whdr-code32_start is updated, it is pointing
+ to the wrong execution start location, random code is executed and
+ the machine is rebooted.
+ .
+ Restore the old behavior by assigning prot_mode_base the value of
+ base. Tested on a machine that exposed this behavior.
+
+diff -Naurp syslinux.orig/com32/lib/syslinux/load_linux.c syslinux/com32/lib/syslinux/load_linux.c
+--- syslinux.orig/com32/lib/syslinux/load_linux.c
 syslinux/com32/lib/syslinux/load_linux.c
+@@ -323,6 +323,7 @@ int bios_boot_linux(void *kernel_buf, si
+ }
+ 
+ whdr-code32_start += base - prot_mode_base;
++prot_mode_base = base;
+ 
+ /* Real mode code */
+ if (syslinux_memmap_find(amap, real_mode_base,
diff -Nru syslinux-6.03+dfsg/debian/patches/series syslinux-6.03+dfsg/debian/patches/series
--- syslinux-6.03+dfsg/debian/patches/series	2014-12-07 20:51:56.0 +0100
+++ syslinux-6.03+dfsg/debian/patches/series	2015-08-18 17:13:25.0 +0200
@@ -2,3 +2,5 @@
 0002-gfxboot-menu-label.patch
 0003-extlinux-manpage.patch
 0004-gnu-efi-git.patch
+0005-load-linux-correct-type.patch
+0006-load-linux-protected-mode.patch

Bug#778704: unblock: libgtk2-perl/1.2492-4

[intrigeri]

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

Please unblock package libgtk2-perl

The only change it contains is a security fix cherry-picked from upstream,
and the corresponding test case.

I'm in the process of convincing them to ask a CVE, and of preparing
a security upload for Wheezy.

unblock libgtk2-perl/1.2492-4

Thanks!
diff -Nru libgtk2-perl-1.2492/debian/changelog libgtk2-perl-1.2492/debian/changelog
--- libgtk2-perl-1.2492/debian/changelog	2014-08-29 23:46:41.0 +0200
+++ libgtk2-perl-1.2492/debian/changelog	2015-02-18 19:53:25.0 +0100
@@ -1,3 +1,10 @@
+libgtk2-perl (2:1.2492-4) unstable; urgency=high
+
+  * Fix-incorrect-memory-management-in-Gtk2-Gdk-Display-list_devices.patch:
+new patch, cherry-picked from upstream, that fixes a security issue.
+
+ -- intrigeri intrig...@debian.org  Wed, 18 Feb 2015 19:45:09 +0100
+
 libgtk2-perl (2:1.2492-3) unstable; urgency=medium
 
   [ Salvatore Bonaccorso ]
diff -Nru libgtk2-perl-1.2492/debian/patches/Fix-incorrect-memory-management-in-Gtk2-Gdk-Display-list_devices.patch libgtk2-perl-1.2492/debian/patches/Fix-incorrect-memory-management-in-Gtk2-Gdk-Display-list_devices.patch
--- libgtk2-perl-1.2492/debian/patches/Fix-incorrect-memory-management-in-Gtk2-Gdk-Display-list_devices.patch	1970-01-01 01:00:00.0 +0100
+++ libgtk2-perl-1.2492/debian/patches/Fix-incorrect-memory-management-in-Gtk2-Gdk-Display-list_devices.patch	2015-02-18 19:53:25.0 +0100
@@ -0,0 +1,47 @@
+From: Torsten Schönfeld kaffeeti...@gmx.de
+Date: Sat, 17 Jan 2015 14:59:24 +0100
+Origin: https://git.gnome.org/browse/perl-Gtk2/commit/?id=4856da628ce37099b27b66a88141dc6daad693b0
+Applied-Upstream: 1.2495
+Subject: Fix incorrect memory management in Gtk2::Gdk::Display::list_devices
+
+We do not own the returned list.
+---
+ t/GdkDisplay.t   | 4 +++-
+ xs/GdkDisplay.xs | 2 --
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/t/GdkDisplay.t b/t/GdkDisplay.t
+index d290446..f4aef59 100644
+--- a/t/GdkDisplay.t
 b/t/GdkDisplay.t
+@@ -1,7 +1,7 @@
+ #!/usr/bin/perl -w
+ use strict;
+ use Gtk2::TestHelper
+-  tests = 26,
++  tests = 27,
+   at_least_version = [2, 2, 0, GdkDisplay is new in 2.2];
+ 
+ # $Id$
+@@ -32,6 +32,8 @@ ok(!$display - pointer_is_grabbed());
+ # $display - beep();
+ $display - sync();
+ 
++# Do this twice to ensure we did not damage the list.
++isa_ok(($display - list_devices())[0], Gtk2::Gdk::Device);
+ isa_ok(($display - list_devices())[0], Gtk2::Gdk::Device);
+ 
+ $display - put_event(Gtk2::Gdk::Event - new(button-press));
+diff --git a/xs/GdkDisplay.xs b/xs/GdkDisplay.xs
+index f558f1d..a019eee 100644
+--- a/xs/GdkDisplay.xs
 b/xs/GdkDisplay.xs
+@@ -69,8 +69,6 @@ gdk_display_list_devices (display)
+ 	devices = gdk_display_list_devices (display);
+ 	for (i = devices ; i != NULL ; i = i-next)
+ 		XPUSHs (sv_2mortal (newSVGdkDevice (i-data)));
+-	g_list_free (devices);
+-	
+ 
+ GdkEvent* gdk_display_get_event (GdkDisplay *display) 
+ 
diff -Nru libgtk2-perl-1.2492/debian/patches/series libgtk2-perl-1.2492/debian/patches/series
--- libgtk2-perl-1.2492/debian/patches/series	2014-08-29 23:46:41.0 +0200
+++ libgtk2-perl-1.2492/debian/patches/series	2015-02-18 19:53:25.0 +0100
@@ -1,3 +1,4 @@
 Make_t_GtkCellRenderer.t_more_robust.patch
 30-disable_libgtk_version_check.patch
 fix-typo.patch
+Fix-incorrect-memory-management-in-Gtk2-Gdk-Display-list_devices.patch

Bug#767476: transition: tilda

[intrigeri]

Hi Sebastian,

Niels Thykier wrote (21 Nov 2014 18:10:31 GMT) :
 Unfortunately, as intrigeri suggests in his mail, we are not willing to
 accept this large a changeset up to or during the freeze.  However, we
 are still willing to accept targeted fixes for important bugs for
 another 14 days, provided that they go through unstable.  Admittedly, it
 would mean that you would have to revert your tilda/1.2 upload(s).

This didn't happen, and the window for fixing important bugs is now
closed. Sebastian, are you interested in uploading targeted fixes for
RC bugs only? If not, please let the release team know, or simply
close this bug report yourself.

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85vblfpzmp@boum.org

Bug#770772: unblock: ruby-twitter-text/1.10.0+gem-1

[intrigeri]

Hi Hideki Yamane,

Pirate Praveen wrote (24 Nov 2014 16:31:26 GMT) :
 On Monday 24 November 2014 03:45 AM, Jonathan Wiltshire wrote:
 Unfortunately that diff is not against the version in testing, which
 includes a new upstream release. Please assess whether you think that
 new upstream is suitable, and follow up with a full diff.

 Do you think the new upstream version is suitable for jessie? Is it a
 bug fix only release?

Ping?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85mw6rpzfx@boum.org

Bug#769961: hard-coded UIDs and GIDs

[intrigeri]

Hans-Christoph Steiner wrote (12 Dec 2014 12:32:59 GMT) :
 First of all, please don't break threads.

 Sorry, I don't understand what you mean by this.

I think that Ivo meant that your previous email
(54874ee7.9020...@eds.org) was a reply to his
(20141119190826.ga19...@ugent.be), but was lacking References and
In-Reply-To headers.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85fvcjpzb2@boum.org

Bug#771374: unblock: macchanger/1.7.0-3.1

[intrigeri]

Control: tag -1 - moreinfo

Hi,

Niels Thykier wrote (29 Nov 2014 09:37:55 GMT) :
 The actual change itself is fine, but why is the Closes from the NMU
 undone?

Because I blindly trusted the debian/1.7.0-3 Git tag Hans-Christoph
had signed in Vcs-Git to actually match what he had uploaded into the
archive, and then failed to notice this change when I debdiff'ed it
before uploading :/

I've now fixed it in Vcs-Git. I guess it's not worth re-uploading,
is it?

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/858uiul3p9@boum.org

Bug#771374: unblock: macchanger/1.7.0-3.1

[intrigeri]

Control: retitle -1 unblock: macchanger/1.7.0-3.2
Control: tag -1 + moreinfo

Hi Niels,

Niels Thykier wrote (29 Nov 2014 10:31:54 GMT) :
 On 2014-11-29 11:08, intrigeri wrote:
 I've now fixed it in Vcs-Git. I guess it's not worth re-uploading,
 is it?

 I would prefer if it was. [...]

Fair enough, thanks for the explanation!

Uploaded -3.2, new debdiff attached.

I'll remove the moreinfo tag once the package is accepted in sid and
has been built everywhere.

Cheers,
-- 
intrigeri

diff -Nru macchanger-1.7.0/debian/changelog macchanger-1.7.0/debian/changelog
--- macchanger-1.7.0/debian/changelog	2014-11-07 13:03:50.0 +0100
+++ macchanger-1.7.0/debian/changelog	2014-11-29 13:50:42.0 +0100
@@ -1,3 +1,19 @@
+macchanger (1.7.0-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Reintroduce the changelog entry for 1.7.0-3 as it was uploaded:
+the previous NMU replaced it with the one that was tagged in Git.
+
+ -- intrigeri intrig...@debian.org  Sat, 29 Nov 2014 13:49:01 +0100
+
+macchanger (1.7.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change the non-vendor bytes, and only them, on automatic run.
+(Closes: #768325)
+
+ -- Jean-Michel Nirgal Vourgère jmv_...@nirgal.com  Thu, 27 Nov 2014 10:52:16 +0100
+
 macchanger (1.7.0-3) unstable; urgency=low
 
   * update debian/watch to point to new github repository
diff -Nru macchanger-1.7.0/debian/if-pre-up.d/macchanger macchanger-1.7.0/debian/if-pre-up.d/macchanger
--- macchanger-1.7.0/debian/if-pre-up.d/macchanger	2014-10-21 21:38:32.0 +0200
+++ macchanger-1.7.0/debian/if-pre-up.d/macchanger	2014-11-29 13:50:42.0 +0100
@@ -29,4 +29,4 @@
 	exit 0
 fi
 
-/usr/bin/${package} -A $IFACE  $LOGFILE 21
+/usr/bin/${package} -e $IFACE  $LOGFILE 21

Bug#769358: closed by Jonathan Wiltshire j...@debian.org (Re: Bug#769358: unblock: libjson-java/2.3-3)

[intrigeri]

Control: reopen -1

Hi Jonathan,

Debian Bug Tracking System wrote (15 Nov 2014 12:09:09 GMT) :
 #769358: unblock: libjson-java/2.3-3
 It has been closed by Jonathan Wiltshire j...@debian.org.

$ curl -s https://release.debian.org/britney/hints/jmw | grep -B1 '^unblock 
libjson-java' 
#20141115
unblock libjson-java/

= the PTS says Unblock request by jmw ignored due to version mismatch:.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85mw7rrxym@boum.org

Bug#769612: unblock: bcache-tools/1.0.7-1

[intrigeri]

Control: tag -1 + moreinfo

Hi Filippo, hi bcache-tools maintainers,

[I'm not on the release team, just trying to give a hand.]

Filippo Giunchedi wrote (15 Nov 2014 00:30:48 GMT) :
 This package didn't make it in time for the freeze, however jessie ships with 
 a
 bcache-capable kernel so I think it is important to have userspace tools
 available.

I acknowledge that giving Debian Jessie users the means to use bcache
feels somewhat important strategically, which *might* be a good enough
reason to make an exception to the freeze policy on this one.

On the other hand:

  * Is there any strong reason why this use case cannot be addressed
via jessie-backports? (if it were *that* important to have in
Jessie, I guess the maintainers would probably have had it
uploaded way earlier)

  * This package was accepted into Debian for the first time less than
3 weeks ago. What kind of testing has it seen?

 See also #708132 for more context.

OK, so it has taken ages to get a package in good shape and uploaded
to Debian. Hmm, this doesn't make me wish the release team lets this
package go into Jessie despite the freeze policy.

I would instead suggest maintaining bcache-tools in jessie-backports,
and getting it in good shape early enough for the Stretch freeze :)

What do the bcache-tools maintainers think?

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/858ujboyt1@boum.org

Bug#769612: unblock: bcache-tools/1.0.7-1

[intrigeri]

Ooops, sorry, Jonathan had already replied.
You can thus ignore my previous email on this bug.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85sihjnjya@boum.org

Bug#769680: unblock: ntfs-3g/2014.2.15AR.3-1

[intrigeri]

László Böszörményi (GCS) wrote (16 Nov 2014 16:49:43 GMT) :
 If you say Jessie only should support kernels later than 3.2.x while
 do not allow users to keep their old kernels (from Wheezy or
 earlier) then sure, this is a no go. Then it should be noted in the
 release notes that some programs, like ntfs-3g requires
 3.2.x+ kernels.

Data point: Wheezy ships with Linux 3.2.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85zjbrnk0s@boum.org

Bug#769680: unblock: ntfs-3g/2014.2.15AR.3-1

[intrigeri]

László Böszörményi (GCS) wrote (16 Nov 2014 18:15:34 GMT) :
 Question still remains, should ntfs-3g support Jessie userland and
 2.6.x kernel combo like the bug reporter has or not.

Lack of support for this combination shouldn't be RC, in my opinion.

Cheers,
-- 
intrigeri


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85vbmfkmr5@boum.org

Bug#767074: unblock: taurus/3.3.1+dfsg-1

[intrigeri]

Hi Frederic-Emmanuel,

Jonathan Wiltshire wrote (30 Oct 2014 18:28:58 GMT) :
 On Tue, Oct 28, 2014 at 08:19:36PM +, PICCA Frederic-Emmanuel wrote:
 I would say that 251 and 221 deserve an upgrade of both package.
 
 Do you need more informations ?

 I think what Adam meant was that with no release team relationship with
 upstream, no prior knowledge of the code, no Debian bugs and just a bunch
 of links to upstream bug reports, we have absolutely no way to assess the
 impact of:

  49 files changed, 745 insertions(+), 190 deletions(-) (taurus)
  43 files changed, 684 insertions(+), 580 deletions(-) (sardana)

 That's where you come in. You're the maintainer and the expert in this
 package. Are 251 and 221 that common and important that the other
 changes are worth less testing than usual?

Ping?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85lhnciux0@boum.org

Bug#767398: unblock: itools/1.0-4

[intrigeri]

Hi,

Niels Thykier wrote (31 Oct 2014 20:14:35 GMT) :
 Unfortunately, I cannot accept the proposed changes as they do not
 comply with our freeze policy (see [1]).

 [...]
 +  * Bumped compat level to 9

 Explicitly mentioned as reject reason[1]:
  * change debhelper compat version (bad)

 I presume it was done for getting hardening flags; here you have
 alternatives (e.g. include the dpkg makefile for this purpose).

 [...]

 The rest of the changes should be okay at this point of the freeze.
 That said, we will not remain this liberal for very long.

Do you intend to upload a -5 that takes into account Niels' feedback,
or shall this unblock request be closed?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85d28oiuoz@boum.org

Bug#768315: unblock: util-linux/2.25.2-3

[intrigeri]

Hi Andreas,

Martin Pitt wrote (10 Nov 2014 09:19:06 GMT) :
 I agree. In Ubuntu we've carried this for a while now:

 | $ cat /etc/cron.weekly/fstrim
 | #!/bin/sh
 | # trim all mounted file systems which support it
 | /sbin/fstrim --all || true

 This is init system agnostic, and with anacron it also works nicely on
 desktops.

 Of course, if in your view as a maintainer this functionality isn't ready
 for jessie or you don't want to support it, just backing out of the change
 also works.

 It also took us quite some time in Ubuntu to enable it by default, and
 we did extensive measurements to see which approach is best. But not
 trimming SSDs is really quite bad these days, so from my POV it would
 be quite prudent to include either the timer or the cron job in
 jessie.

Agreed. I think we should ship the cronjob by default in Jessie.
Andreas, what do you think?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85389kisva@boum.org

Bug#767074: unblock: taurus/3.3.1+dfsg-1

[intrigeri]

Hi,

PICCA Frederic-Emmanuel wrote (15 Nov 2014 12:08:49 GMT) :
 Here the answer of the taurus upstream (he forgot to CC the the bts)

[... snipping general explanation of the upstream dev process ...]

 Do you need more informations ?

It's good to know that upstream seems very confident that this release
is better than the previous one (although it's rare to see any
upstream tell the contrary, so moderately useful IMO) but it
doesn't answer the specific questions that Jonathan asked you on
October 20.

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85fvdkhc1i@boum.org

Bug#769323: unblock: libaudio-mpd-perl/2.000-2

[intrigeri]

Hi,

gregor herrmann wrote (12 Nov 2014 20:13:24 GMT) :
 libaudio-mpd-perl (2.000-2) unstable; urgency=medium

   * Add patch to make tests work with mpd = 0.19.

 One tests checks for the accumulated playtime of the audio samples.
 Test::Corpus::Audio::MPD contains 5 tracks just over 1.8 seconds each.
 mpd  0.19 rounded each track up to 2 seconds then added the lengths in
 seconds to get 10s, but mpd = 0.19 adds up the lengths in ms and then
 rounds it down to 9s.
 Change this test to look for = 9 and = 10 seconds.

 Thanks to Simon McVittie for the patch. (Closes: #768692)

  -- gregor herrmann gre...@debian.org  Wed, 12 Nov 2014 20:52:49 +0100

Looks good to me: the patch is minimal, the code makes sense, and
I confirm it fixes the FTBFS it's supposed to fix.

(No reply from upstream, to whom the bug was submitted, yet.)

 unblock libaudio-mpd-perl/2.000-2

Yay.

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85mw7see8z@boum.org

Bug#769404: unblock: grilo-plugins/0.2.13-2

[intrigeri]

Hi Alberto,

[I'm not on the release team, so take my comments with a grain of salt.]

Alberto Garcia wrote (13 Nov 2014 12:56:29 GMT) :
 I'm about to upload the new package, which contains the following
 fixes:
[...]

Both the scope of the proposed upload and the size of the diff look
appropriate to me. I can't comment on the actual code changes, though.

 In addition to that, I added a build dependency on librest-dev. This
 is a hard requirement for one of the plugins and the dependency is
 explicitly checked in the configure script. If it's working at the
 moment it's because it's coincidentally being pulled by other build
 dependencies. I don't have any bug for this, so if this change is not
 appropriate I'll revert it.

IMO it's appropriate, but I would suggest documenting this change more
thoroughly in debian/changelog before uploading.

 I haven't uploaded the package yet, I'll do it as soon as I get the
 confirmation that the changes are fine.

Given the changes are small, seem to match the freeze policy, and can
anyway be reverted later if needed: if I were you, I would skip the
pre-approval procedure, upload to sid and then ping this bug to avoid
more round-trips.

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85y4rccz4f@boum.org

Bug#769668: wheezy-pu: package showfoto/4:2.6.0-1

[intrigeri]

Hi Jean-Michel,

Jean-Michel Nirgal Vourgère wrote (15 Nov 2014 13:36:15 GMT) :
 +  * Added showfoto Breaks/Replaces (Closes: #767570)

I would suggest Add versioned Breaks/Replaces on digikam-doc, that
fixes the Squeeze to Wheezy upgrade instead.

Cheers,
-- 
intrigeri


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85zjbsbjhl@boum.org

Bug#769090: unblock: torsocks/2.0.0-3

[intrigeri]

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

Please unblock package torsocks 2.0.0-3, to an important bug (#766306)
that can potentially result in data loss.

This bug is fixed by Fix-improve-Unix-socket-passing-detection.patch
(cherry-picked from upstream), which implied to add the test it creates
(test_fd_passing test) to exclude_test_requiring_network.patch, and later on to
cherry-pick Fix-use-getsockname-instead-of-getsockopt-to-get-soc.patch as well
since the first patch made the package FTBFS on kfreebsd-*.

The debdiff is not absolutely tiny, but you'll notice that most of the lines
added are in the test suite, and more precisely in the test that we disable when
building the Debian package (that test passes here if I temporarily enable
network access in my pbuilder, though).

If it would help to show you the diff resulting from the two cherry-picked
patches combined, so that you don't have to review a diff-of-diff and then
a diff-of-diff that touches the code already modified in the previous one, just
let me know and I'll prepare that.

unblock torsocks/2.0.0-3
diff -Nru torsocks-2.0.0/debian/changelog torsocks-2.0.0/debian/changelog
--- torsocks-2.0.0/debian/changelog	2014-08-24 23:24:58.0 +0200
+++ torsocks-2.0.0/debian/changelog	2014-11-10 23:39:39.0 +0100
@@ -1,3 +1,22 @@
+torsocks (2.0.0-3) unstable; urgency=medium
+
+  * Fix-use-getsockname-instead-of-getsockopt-to-get-soc.patch:
+new patch, cherry-picked from upstream, that fixes the FTBFS
+kfreebsd-* that was introduced by
+Fix-improve-Unix-socket-passing-detection.patch (Closes: #768140).
+
+ -- intrigeri intrig...@debian.org  Mon, 10 Nov 2014 23:39:19 +0100
+
+torsocks (2.0.0-2) unstable; urgency=medium
+
+  * Fix-improve-Unix-socket-passing-detection.patch: new patch,
+cherry-picked from upstream (Closes: #766306).
+  * Amend exclude_test_requiring_network.patch to add test_fd_passing test,
+introduced by the new aforementioned patch, to the list of excluded
+tests: it requires network access.
+
+ -- intrigeri intrig...@debian.org  Tue, 28 Oct 2014 10:41:10 +0100
+
 torsocks (2.0.0-1) unstable; urgency=low
 
   * New upstream release. The 2.0 rewrite is considered stable.
diff -Nru torsocks-2.0.0/debian/patches/exclude_test_requiring_network.patch torsocks-2.0.0/debian/patches/exclude_test_requiring_network.patch
--- torsocks-2.0.0/debian/patches/exclude_test_requiring_network.patch	2014-08-24 23:24:58.0 +0200
+++ torsocks-2.0.0/debian/patches/exclude_test_requiring_network.patch	2014-11-10 23:39:39.0 +0100
@@ -5,9 +5,10 @@
 
 --- a/tests/test_list
 +++ b/tests/test_list
-@@ -1,5 +1,4 @@
+@@ -1,6 +1,4 @@
  ./test_connect
 -./test_dns
+-./test_fd_passing
  ./test_socket
  ./unit/test_onion
  ./unit/test_connection
diff -Nru torsocks-2.0.0/debian/patches/Fix-improve-Unix-socket-passing-detection.patch torsocks-2.0.0/debian/patches/Fix-improve-Unix-socket-passing-detection.patch
--- torsocks-2.0.0/debian/patches/Fix-improve-Unix-socket-passing-detection.patch	1970-01-01 01:00:00.0 +0100
+++ torsocks-2.0.0/debian/patches/Fix-improve-Unix-socket-passing-detection.patch	2014-11-10 23:39:39.0 +0100
@@ -0,0 +1,759 @@
+From: David Goulet dgou...@ev0ke.net
+Date: Wed, 22 Oct 2014 15:25:23 -0400
+Bug-Debian: https://bugs.debian.org/766306
+Origin: upstream, https://gitweb.torproject.org/torsocks.git/commit/eb80d5cd10d10158b39c344ad035afe8d31a899f
+Subject: Fix: improve Unix socket passing detection
+
+This commit adds the support for the torsocks recvmsg wrapper to detect
+multiple FDs being passed through a Unix socket.
+
+Furthermore, we now don't exit anymore but simply fire a debug message
+and return EACCES to the caller.
+
+Finally, a test is added for inet socket passing detection called
+test_fd_passing.
+
+Signed-off-by: David Goulet dgou...@ev0ke.net
+---
+ src/lib/recv.c  | 132 +---
+ tests/Makefile.am   |   5 +-
+ tests/test_fd_passing.c | 520 
+ tests/test_list |   1 +
+ 4 files changed, 631 insertions(+), 27 deletions(-)
+ create mode 100644 tests/test_fd_passing.c
+
+diff --git a/src/lib/recv.c b/src/lib/recv.c
+index 036fa91..b034d72 100644
+--- a/src/lib/recv.c
 b/src/lib/recv.c
+@@ -26,21 +26,60 @@
+ TSOCKS_LIBC_DECL(recvmsg, LIBC_RECVMSG_RET_TYPE, LIBC_RECVMSG_SIG)
+ 
+ /*
++ * This is the maximum hardcoded amount of fd that is possible to pass through
++ * a Unix socket in the Linux kernel. On FreeBSD for instance it's MLEN which
++ * is defined to MSIZE (256) minus the msg header size thus way below this
++ * Linux limit. Such a shame there is no way to dynamically get that value or
++ * get it in an exposed ABI...
++ */
++#define SCM_MAX_FD  253
++
++/*
++ * Close all fds in the given array of size count.
++ */
++static void close_fds(int *fds, size_t count)
++{
++	int i;
++
++	for (i = 0; i  count; i

Bug#768886: unblock: beignet/0.9.3~dfsg-1

[intrigeri]

Control: merge 767961 -1

Hi Simon,

Simon Richter wrote (09 Nov 2014 21:57:06 GMT) :
 unblock beignet/0.9.3~dfsg-1

This was asked on #767961 already = merging those bugs.

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/857fz3lbat@boum.org

Bug#768544: unblock: apparmor/2.9.0-2

[intrigeri]

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

Please unblock package apparmor 2.9.0-2, that fixes one RC bug (#768211), an
important one (#768357), and avoids the latter from occurring in another area.
Note that the added and affected confinement profiles are shipped in complain
mode by default, so there's little risk of AppArmor-caused breakage that could
be caused by them. Details can be found in debian/changelog.

unblock apparmor/2.9.0-2
diff -Nru apparmor-2.9.0/debian/apparmor-profiles.install apparmor-2.9.0/debian/apparmor-profiles.install
--- apparmor-2.9.0/debian/apparmor-profiles.install	2014-10-18 11:27:36.0 +0200
+++ apparmor-2.9.0/debian/apparmor-profiles.install	2014-11-07 11:10:25.0 +0100
@@ -5,13 +5,22 @@
 etc/apparmor.d/sbin.syslogd
 etc/apparmor.d/sbin.syslog-ng
 etc/apparmor.d/usr.bin.chromium-browser
+etc/apparmor.d/usr.lib.dovecot.anvil
+etc/apparmor.d/usr.lib.dovecot.auth
+etc/apparmor.d/usr.lib.dovecot.config
 etc/apparmor.d/usr.lib.dovecot.deliver
+etc/apparmor.d/usr.lib.dovecot.dict
 etc/apparmor.d/usr.lib.dovecot.dovecot-auth
+etc/apparmor.d/usr.lib.dovecot.dovecot-lda
 etc/apparmor.d/usr.lib.dovecot.imap
 etc/apparmor.d/usr.lib.dovecot.imap-login
+etc/apparmor.d/usr.lib.dovecot.lmtp
+etc/apparmor.d/usr.lib.dovecot.log
+etc/apparmor.d/usr.lib.dovecot.managesieve
 etc/apparmor.d/usr.lib.dovecot.managesieve-login
 etc/apparmor.d/usr.lib.dovecot.pop3
 etc/apparmor.d/usr.lib.dovecot.pop3-login
+etc/apparmor.d/usr.lib.dovecot.ssl-params
 etc/apparmor.d/usr.sbin.avahi-daemon
 etc/apparmor.d/usr.sbin.dnsmasq
 etc/apparmor.d/usr.sbin.dovecot
@@ -20,6 +29,7 @@
 etc/apparmor.d/usr.sbin.nmbd
 etc/apparmor.d/usr.sbin.nscd
 etc/apparmor.d/usr.sbin.smbd
+etc/apparmor.d/usr.sbin.smbldap-useradd
 etc/apparmor.d/usr.sbin.traceroute
 usr/share/doc/apparmor-profiles/extras/README
 usr/share/doc/apparmor-profiles/extras/bin.netstat
diff -Nru apparmor-2.9.0/debian/changelog apparmor-2.9.0/debian/changelog
--- apparmor-2.9.0/debian/changelog	2014-10-18 19:37:02.0 +0200
+++ apparmor-2.9.0/debian/changelog	2014-11-07 11:37:49.0 +0100
@@ -1,3 +1,17 @@
+apparmor (2.9.0-2) unstable; urgency=medium
+
+  * Add versioned Breaks/Replaces from python-apparmor to apparmor-utils.
+We have the same in place already for python3-apparmor, that deals
+with the move of the Python 3 bits. This change does the same for
+the Python 2 bits (Closes: #768211).
+  * Install all upstream Dovecot profiles: the usr.sbin.dovecot one,
+that we install already, needs them (Closes: #768357).
+  * Install the upstream usr.sbin.smbldap-useradd profile: the usr.sbin.smbd
+one, that we install already, needs it. This prevents the same kind
+of bug as #768357 from occurring when one uses the smbd profile.
+
+ -- intrigeri intrig...@debian.org  Fri, 07 Nov 2014 11:37:45 +0100
+
 apparmor (2.9.0-1) unstable; urgency=medium
 
   * Import new upstream release: 2.9.0.
diff -Nru apparmor-2.9.0/debian/control apparmor-2.9.0/debian/control
--- apparmor-2.9.0/debian/control	2014-10-18 12:29:20.0 +0200
+++ apparmor-2.9.0/debian/control	2014-11-07 11:23:09.0 +0100
@@ -143,6 +143,8 @@
 Section: python
 Architecture: any
 Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, python-libapparmor, python-pkg-resources
+Breaks: apparmor-utils (  2.8.95~2385-0ubuntu1 )
+Replaces: apparmor-utils (  2.8.95~2385-0ubuntu1 )
 XS-Python-Version: ${python:Versions}
 Description: AppArmor Python utility library
  This provides the Python modules that implement the higher-level AppArmor

Bug#767750: unblock: libnet-dns-perl/0.81-1

[intrigeri]

Hi,

Emilio Pozuelo Monfort wrote (07 Nov 2014 15:38:12 GMT) :
 Sorry but I'm not very fluent with perl,

I am, so I had a look. Most changes are indeed very simple and minor
style changes (mostly noop's in practice) that don't feel too risky to
me. Not exactly the right time for such changes, but oh well.

The changes to lib/Net/DNS/RR.pm and lib/Net/DNS/RR/TSIG.pm are small,
don't look too scary, but they are a little bit more involved, and
without prior knowledge of the code I would need more time to
seriously evaluate them than what I'm willing to put into it.

So, Emilio's questions still hold.

 and there is no changelog.

Indeed, the upstream changelog from 0.80.2 to 0.81 is empty.

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85wq75v1yz@boum.org

Bug#767476: transition: tilda

[intrigeri]

Hi,

Sebastian Geiger wrote (31 Oct 2014 14:59:44 GMT) :
 The complete changelog can be found directly in the package's
 ChangeLog file [1]
 [...]
 [1] https://github.com/lanoxx/tilda/blob/master/ChangeLog

version 1.2.2 (2014-10-28):
* Fixed an error where Tilda failed to start when the lock
  file directory did not exist or could not be opened.

version 1.2.1 (2014-10-16):
* Readded empty NEWS file to fix debian packaging
* Updated po/ folder

version 1.2.0 (2014-10-15):
* Fixed background option
* Updated README, HACKING and TODO files
* Fixed bug in focus/pull-up selection
* Made tilda icon themable

version 1.2~rc1 (2014-09-25):
* Fixed an issue with drop-to-default shell option
* Added light and dark solarized schemes
* Custom color selection improved
* New option to set the maximum tab title length
* The fullscreen hotkey is now configurable in the
  preferences.
* Its now possible to compile with clang
* Fixed some focus issues
* Its now possible to open the context menu with the context-menu
  button on the keyboard if such a key is present. This provides
  improved usability for people with disabilities.
* Tabs can now be switches using the mouse history buttons.
* Tilda now uses non-recursive automake, there have been
  many improvements to the build system and some code cleanups.
  Its now also possible to make out-of-tree builds.
  The debugging output has also been improved and now shows
  in which file a log message was printed.
* There is a new unlimited scrollback option.
* A positioning bug when unfullscreening was fixed.
* Some improvements for different window managers were made.
* Tilda can no be focuses with the hotkey instead of hiding it
  when it is currently not focused. This new behavior is configurable.
* A locking issue has been fixed if multiple tilda instances were 
started
  at the same time, which caused a race condition to appear and could
  delete the configuration file.
* The UI file from GtkBuilder is now being compiled into the tilda 
binary.
* There is a new option to hide the tab bar and the border when multiple
  tabs are open.
* When a new tab is opened the tab will now inherit its working 
directory
  from the old tab. This behavior is active by default and can only be
  disabled from an option in the config file.

version 1.1.13 (2014-09-22):
* Fixed focus stealing issue
  on mouse enter. This caused
  the tilda window to become
  active when the mouse
  entered the window.
* Fixed two functions which prevented
  building on systems with
  '-Wreturn-type' enabled in the
  compiler.

 In summary, there are many bug fixes a few new options in the user interface, 
 some
 cleanups in the build system and then some new color themes. Nothing which is
 particularaly complex. But all in all it makes tilda more usable and
 more configurable.

These are a lot of changes. I suggest you point the release team to
the specific fixes that are important enough to warrant an unblock
(and the risk of bringing regressions more important that the fixes
from 1.12..1.2.2) at this point.

Cheers!


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85a941v1c6@boum.org

Bug#767743: unblock: blitz++/0.10-3

[intrigeri]

Hi,

Andreas Tille wrote (02 Nov 2014 10:59:20 GMT) :
 The only reason to upload this package is a missing Breaks to fix
 bug #767564.

According to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767564#15, 0.10-3
still doesn't fix that RC bug.

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/851tpdv169@boum.org

Bug#768402: unblock: simplesamlphp/1.13.1-1

[intrigeri]

Hi,

Thijs Kinkhorst wrote (07 Nov 2014 13:46:40 GMT) :
 On Fri, November 7, 2014 12:52, Jonathan Wiltshire wrote:
 Are there corresponding Debian bugs so we can assess severity please?

 These are the issues fixed in this release.
 [...]
 Does it add much value to re-file them in the Debian BTS?

I doubt it would add much value, but Jonathan's point was about
getting enough information to assess severity, so perhaps you could
tell the release team what severity you _would_ set for each of these
bugs in the Debian BTS, if they were reported there?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85oashtme3@boum.org

Bug#699806: unblock: dlocate/1.02+nmu3

[intrigeri]

Hi,

John Paul Adrian Glaubitz wrote (08 Sep 2014 22:50:44 GMT) :
 Sure, will do once I am back from vacation. I am currently in Japan
 until next week. Will get back to this after my journey.

Ping?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85bnohpc8s@boum.org

Bug#757342: PHP 5.4.34 released

[intrigeri]

Hi,

Ondřej Surý wrote (17 Oct 2014 14:28:17 GMT) :
 Do you think, that in line what has been said in #757342, we could try
 updating this as 5.4.34 instead of cherry-picking the changes?

I see that 5.4.34-0+deb7u1 is in wheezy-security, and was also
accepted in wheezy-p-u. Shall we then close this bug, or are stable pu
bugs handled differently? (e.g. I could imagine that bugs are only
closed at point-release time, or tagged in some way)

Cheers,
--
intrigeri


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85389tpbyu@boum.org

Bug#717420: update reSIProcate in stable from 1.8.5 - 1.8.12

[intrigeri]

Hi,

intrigeri wrote (22 Jan 2014 10:35:56 GMT) :
 Daniel Pocock wrote (21 Jan 2014 17:55:15 GMT) :
 On 21/01/14 18:43, intrigeri wrote:
 Jonathan Wiltshire wrote (25 Sep 2013 21:59:15 GMT) :
 I could provide a diff that eliminates changes in such files.
 
 Yes, please.
 
 AFAICT, this stable proposed update has been blocking on the lack of
 a filtered diff for almost 4 months. Daniel, do you still intend to
 follow-up on this?
 

 There have been more upstream improvements, we now have 1.8.14 and may
 make up 1.8.15 just to backport any final bugs that were fixed in the
 1.9.0 testing

You might want to retitle this bug accordingly, then.

 If I provide a filtered diff between 1.8.5 and 1.8.15 will that
 definitely be considered for stable?

 I'm not a member of the release team, but in my experience all
 not-too-crazy pu diffs are at least considered, once they are actually
 shown to the release team.

Ping?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85r3xdnww6@boum.org

Bug#699806: unblock: dlocate/1.02+nmu3

[intrigeri]

Hi,

John Paul Adrian Glaubitz wrote (08 Nov 2014 22:23:11 GMT) :
 You want an unblock for Wheezy?

I realize the subject is misleading (and the bug title was changed
since then), but #699806 is actually a wheezy pu bug you filed. And,
two months ago, you said you would upload the package shortly.
Hence this friendly ping :)

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/858ujlnvvq@boum.org

Bug#768441: unblock: parcimonie/0.8.4-1

[intrigeri]

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

Hi,

please unblock package parcimonie.

I've prepared and uploaded a new upstream release to address the #768174
important bug, that makes the package unusable when using an encoding that's
handled by Encode::XS, as opposed to Encode::Encoding.

For your convenience, I'm attaching a filtered debdiff, skipping most of the
boilerplate and auto-generated bits.

unblock parcimonie/0.8.4-1
diff -Nru parcimonie-0.8.3/Changes parcimonie-0.8.4/Changes
--- parcimonie-0.8.3/Changes	2014-06-08 01:06:16.0 +0200
+++ parcimonie-0.8.4/Changes	2014-11-07 12:50:12.0 +0100
@@ -1,6 +1,25 @@
-==
--99-99 99:99:99 + HEAD
-==
+==
+2014-11-07 11:49:35 + parcimonie_0.8.4
+==
+
+  commit 9d20ef1aef9107a992a3b099576dc1a384a821c5
+  Author: intrigeri intrig...@boum.org
+  Date:   Fri Nov 7 11:49:35 2014 +
+  
+parcimonie 0.8.4
+
+  commit 14339a88178d16d4d7ece93af468d4dedb81f6a1
+  Author: intrigeri intrig...@boum.org
+  Date:   Fri Nov 7 11:44:37 2014 +
+  
+Support encodings that are handled by Encode::XS (Closes: #768174).
+
+Encode's find_encoding can return either an Encode::Encoding or
+Encode::XS object, depending on the actual encoding. 
+
+==
+2014-06-07 23:06:01 + parcimonie_0.8.3
+==
 
   commit 0a48d0b47579431389ee9f2826f9018e0c12984f
   Author: intrigeri intrig...@boum.org
diff -Nru parcimonie-0.8.3/debian/changelog parcimonie-0.8.4/debian/changelog
--- parcimonie-0.8.3/debian/changelog	2014-06-08 01:23:40.0 +0200
+++ parcimonie-0.8.4/debian/changelog	2014-11-07 12:52:54.0 +0100
@@ -1,3 +1,9 @@
+parcimonie (0.8.4-1) unstable; urgency=medium
+
+  * Support encodings that are handled by Encode::XS (Closes: #768174).
+
+ -- intrigeri intrig...@debian.org  Fri, 07 Nov 2014 12:51:29 +0100
+
 parcimonie (0.8.3-1) unstable; urgency=medium
 
   * New upstream release: don't store the results of (up to the) 1000 last
diff -Nru parcimonie-0.8.3/lib/App/Parcimonie/Role/HasEncoding.pm parcimonie-0.8.4/lib/App/Parcimonie/Role/HasEncoding.pm
--- parcimonie-0.8.3/lib/App/Parcimonie/Role/HasEncoding.pm	2014-06-08 01:06:16.0 +0200
+++ parcimonie-0.8.4/lib/App/Parcimonie/Role/HasEncoding.pm	2014-11-07 12:50:12.0 +0100
@@ -24,7 +24,7 @@
 use namespace::clean;
 
 has 'encoding' = (
-isa= 'Encode::Encoding',
+isa= 'Encode::Encoding|Encode::XS',
 is = 'ro',
 lazy_build = 1,
 );

Bug#767916: unblock: libotr/4.1.0-2

[intrigeri]

Julien Cristau wrote (03 Nov 2014 22:41:53 GMT) :
 +libotr (4.1.0-2) unstable; urgency=medium

 Unblocked.

Thanks!


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85oasmiyu0@boum.org

Bug#767916: unblock: libotr/4.1.0-2

[intrigeri]

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

Hi,

here's a follow-up to the discussion that I've started in
the libotr transition started by mistake :-/ thread on -release@,
about #767230.

Thanks to the guidance I got both on-list and off-list (thanks everyone!),
here's an updated debdiff (against the version in sid, as requested by Niels).

Changes since my last submitted patch, in case someone already has
looked at it:

  * Add symbols file: now that we have removed upstream's version
check at runtime, let's use the symbols mechanism to detect (most)
ABI changes automatically, and let reverse-dependencies pick up
the version of libotr they should depend on (Closes: #767652).

  * debian/README.source: document how to detect and handle ABI changes.

  * I'm now removing the runtime check entirely. Keeping the warning
message made sense back when this patch was meant to be temporary,
but with the introduction of a symbols file, it's here to stay.

I'd like to upload libotr with this patch applied to sid,
and will then ask you to unblock and/or age it.

Shall I proceed with the upload?
diff -Nru libotr-4.1.0/debian/changelog libotr-4.1.0/debian/changelog
--- libotr-4.1.0/debian/changelog	2014-10-21 22:26:51.0 +0200
+++ libotr-4.1.0/debian/changelog	2014-11-03 14:34:06.0 +0100
@@ -1,3 +1,19 @@
+libotr (4.1.0-2) unstable; urgency=medium
+
+  * New patch:
+0001-Do-not-error-out-when-an-application-is-run-against-.patch
+Do not error out when an application is run against an older libotr
+than the one it was built against: given libotr 4.1 is API- and
+ABI-compatible with libotr 4.0, let's prevent this runtime check
+from breaking packages that were built against 4.0 (Closes: #767230).
+  * Add symbols file: now that we have removed upstream's version check
+at runtime, let's use the symbols mechanism to detect (most) ABI changes
+automatically, and let reverse-dependencies pick up the version
+of libotr they should depend on (Closes: #767652).
+  * debian/README.source: document how to detect and handle ABI changes.
+
+ -- intrigeri intrig...@debian.org  Sat, 01 Nov 2014 18:36:49 +0100
+
 libotr (4.1.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libotr-4.1.0/debian/libotr5.symbols libotr-4.1.0/debian/libotr5.symbols
--- libotr-4.1.0/debian/libotr5.symbols	1970-01-01 01:00:00.0 +0100
+++ libotr-4.1.0/debian/libotr5.symbols	2014-11-03 14:34:06.0 +0100
@@ -0,0 +1,125 @@
+libotr.so.5 libotr5 #MINVER#
+ otrl_api_version@Base 4.0.0
+ otrl_auth_clear@Base 4.0.0
+ otrl_auth_copy_on_key@Base 4.0.0
+ otrl_auth_handle_commit@Base 4.0.0
+ otrl_auth_handle_key@Base 4.0.0
+ otrl_auth_handle_revealsig@Base 4.0.0
+ otrl_auth_handle_signature@Base 4.0.0
+ otrl_auth_handle_v1_key_exchange@Base 4.0.0
+ otrl_auth_new@Base 4.0.0
+ otrl_auth_start_v1@Base 4.0.0
+ otrl_auth_start_v23@Base 4.0.0
+ otrl_base64_decode@Base 4.0.0
+ otrl_base64_encode@Base 4.0.0
+ otrl_base64_otr_decode@Base 4.0.0
+ otrl_base64_otr_encode@Base 4.0.0
+ otrl_context_find@Base 4.0.0
+ otrl_context_find_fingerprint@Base 4.0.0
+ otrl_context_find_recent_instance@Base 4.0.0
+ otrl_context_find_recent_secure_instance@Base 4.0.0
+ otrl_context_force_finished@Base 4.0.0
+ otrl_context_force_plaintext@Base 4.0.0
+ otrl_context_forget@Base 4.0.0
+ otrl_context_forget_all@Base 4.0.0
+ otrl_context_forget_fingerprint@Base 4.0.0
+ otrl_context_is_fingerprint_trusted@Base 4.0.0
+ otrl_context_priv_force_finished@Base 4.0.0
+ otrl_context_priv_new@Base 4.0.0
+ otrl_context_set_trust@Base 4.0.0
+ otrl_context_update_recent_child@Base 4.0.0
+ otrl_dh_cmpctr@Base 4.0.0
+ otrl_dh_compute_v1_session_id@Base 4.0.0
+ otrl_dh_compute_v2_auth_keys@Base 4.0.0
+ otrl_dh_gen_keypair@Base 4.0.0
+ otrl_dh_incctr@Base 4.0.0
+ otrl_dh_init@Base 4.0.0
+ otrl_dh_keypair_copy@Base 4.0.0
+ otrl_dh_keypair_free@Base 4.0.0
+ otrl_dh_keypair_init@Base 4.0.0
+ otrl_dh_session@Base 4.0.0
+ otrl_dh_session_blank@Base 4.0.0
+ otrl_dh_session_free@Base 4.0.0
+ otrl_init@Base 4.0.0
+ otrl_instag_find@Base 4.0.0
+ otrl_instag_forget@Base 4.0.0
+ otrl_instag_forget_all@Base 4.0.0
+ otrl_instag_generate@Base 4.0.0
+ otrl_instag_generate_FILEp@Base 4.0.0
+ otrl_instag_get_new@Base 4.0.0
+ otrl_instag_read@Base 4.0.0
+ otrl_instag_read_FILEp@Base 4.0.0
+ otrl_instag_write@Base 4.0.0
+ otrl_instag_write_FILEp@Base 4.0.0
+ otrl_mem_differ@Base 4.1.0
+ otrl_mem_init@Base 4.0.0
+ otrl_message_abort_smp@Base 4.0.0
+ otrl_message_disconnect@Base 4.0.0
+ otrl_message_disconnect_all_instances@Base 4.0.0
+ otrl_message_free@Base 4.0.0
+ otrl_message_initiate_smp@Base 4.0.0
+ otrl_message_initiate_smp_q@Base 4.0.0
+ otrl_message_poll@Base 4.0.0
+ otrl_message_poll_get_default_interval@Base 4.0.0
+ otrl_message_receiving@Base 4.0.0
+ otrl_message_respond_smp@Base 4.0.0
+ otrl_message_sending@Base 4.0.0
+ otrl_message_symkey@Base 4.0.0

Re: libotr transition started by mistake :-/

[intrigeri]

Hi,

Niels Thykier wrote (30 Oct 2014 22:05:20 GMT) :
 On 2014-10-29 17:09, intrigeri wrote:

 Plan A -- ship Jessie with libotr 4.1, drop the version check temporarily
 =
 
 1. Patch libotr to loosen this version check on Jessie: assuming the
no API/ABI break assumption is true, this should work just fine.

 I suspect this will be the least intrusive method assuming the no
 ABI/API assertion holds.

I'll check this the best I can (I'll try my best with the readelf
command you provided and also will generate shlibs files for both 4.0
and 4.1, and compare what's in there). I'll also test, as a practical
usecase, that e.g. pidgin-otr built against libotr 4.0 works fine with
libotr 4.1.

 2. For Jessie+1, re-add the version check, and get proper shlibs
support so that we get proper transition handling next time.
 

 As I recall, we generally prefer libraries do not have unnecessary
 strictly equal runtime version checks, since they tend to be wrong.
   Proper use of shlibs (or symbols) and SONAME bumping (with package
 renaming) makes such checks redundant (for Debian maintained reverse
 dependencies).

Actually, the way I understand the code, what we have here is not
a strictly equal runtime version check, but rather runtime version
greater or equal to the build-time one, which is better in that it
doesn't require binNMUs.

But anyway, for Jessie+1 I'll add shlibs support, so indeed this check
will be redundant; and then, my understanding is that it'll also
become fully harmless.

 I generally agree with plan A (with the a minor remark mentioned above).

OK, I'll do that. Thanks!

 Please also prepare a debdiff between libotr/4.1.0-1 and the proposed
 version[1] and send it to us (to this thread), so we can review the
 additional changes we will accept.

Sure, will do.

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85d296ly1t@boum.org

Re: libotr transition started by mistake :-/

[intrigeri]

Hi,

[It's probably too late already, but if you prefer I can move this
discussion to a dedicated bug filed against release.d.o.]

Here's my analysis of the potential ABI/API breakage in libotr
4.0-4.1, and attached the debdiff (implementing plan A) that I could
upload to sid (and then request to be aged or unblocked so that it
migrates to testing eventually).

Functions added to context.h


otrl_context_find_recent_instance
-

ConnContext * otrl_context_find_recent_instance(ConnContext * context,
   otrl_instag_t recent_instag);

This one is not modified at all in context.c

otrl_context_find_recent_secure_instance


ConnContext * otrl_context_find_recent_secure_instance(ConnContext * context);

This one is slightly changed in context.c. Ignoring the typo fix in
a comment, the change is:

  -   if (context-msgstate != OTRL_MSGSTATE_PLAINTEXT) return 1;
  +   if (c_iter-msgstate != OTRL_MSGSTATE_PLAINTEXT) return 1;

I doubt this breaks the API or ABI.

Function added to both mem.c and mem.h
==

int otrl_mem_differ(const unsigned char *buf1, const unsigned char *buf2,
size_t len);

My (limited) understanding is that adding a function does not break
the API nor ABI.

readelf
===

I've diff'ed the output of the following command run on the one hand
on current Jessie (libotr 4.0.0-3) and current sid (libotr 4.1.0-1):

  readelf -Ws /usr/lib/libotr.so.5 | awk '{print $8}' | sort

The result is that two symbols were added in 4.1:

  gcry_mpi_snew@GCRYPT_1.6
  otrl_mem_differ

The full output lines from readelf -Ws, regarding the added or modified
functions, is:

  * 4.0:

117: 7a50   123 FUNCGLOBAL DEFAULT   11 
otrl_context_find_recent_instance
185: 7b20   292 FUNCGLOBAL DEFAULT   11 
otrl_context_find_recent_secure_instance

  * 4.1:

118: 7af0   123 FUNCGLOBAL DEFAULT   11 
otrl_context_find_recent_instance
181: bd50   100 FUNCGLOBAL DEFAULT   11 otrl_mem_differ
187: 7bc0   292 FUNCGLOBAL DEFAULT   11 
otrl_context_find_recent_secure_instance

I lack the background to tell if the differences seen in the 1st (Num)
and 2nd (Value) columns matter. Do they indicate ABI breakage?

symbols
===

I've extracted the libotr5 binary packages from Jessie and sid, and
then run:

  dpkg-gensymbols -v4.0.0 -plibotr5 -P/tmp/intrigeri/4.0-extracted -Osymbols
  dpkg-gensymbols -v4.1.0 -plibotr5 -P/tmp/intrigeri/4.1-extracted -Osymbols

The second command tells me:

  --- symbols (libotr5_4.1.0_amd64)
  +++ dpkg-gensymbolsjwu_Lf 2014-11-01 17:42:21.409469548 +0100
  @@ -51,6 +51,7 @@
otrl_instag_read_FILEp@Base 4.0.0
otrl_instag_write@Base 4.0.0
otrl_instag_write_FILEp@Base 4.0.0
  + otrl_mem_differ@Base 4.1.0
otrl_mem_init@Base 4.0.0
otrl_message_abort_smp@Base 4.0.0
otrl_message_disconnect@Base 4.0.0

... which seems to confirm the fact that there was no
API/ABI breakage.

Applications built against libotr 4.0 and running with 4.1
==

  * pidgin-otr 4.0.1-1 rebuilt in a Jessie chroot: works fine on
current sid

= seems to confirm that applications built against the old version
still work fine with the new one.

The attached patch
==

I've gone with the smallest possible change (removing one single
line), and left the warning be printed on stderr, in the hope it may
help debugging issues in case something is wrong with this analysis.
If the RT prefers, I can drop the warning too.

I've successfully tested the resulting libotr5 binary package with:

  * pidgin-otr 4.0.1-1 built in a Jessie chroot (against libotr 4.0)
  * pidgin-otr 4.0.1-1 from sid (that was built against libotr 4.1)

... but I could not directly test the actual intended effect of the
patch (it would require building an _older_ version of libotr with
this patch, building a package against the new version, and running it
with the patched old version). This leads me to think that perhaps
this patch may not be as useful as I used to think.

Conclusion
==

Unless the differences I've found in readelf output indicate ABI
breakage, it seems equally safe to either:

  * upload with the attached debdiff to sid, wait for it to build on
all architectures, and then let it migrate to testing;
  * just let libotr migrate to testing as is (my current understanding
is that it should fix two RC bugs, without introducing any new
breakage).

So, whatever the release team feels more comfortable with :)

[Regarding the plans for Jessie+1, I've filed #767652 so we (pkg-otr
team) don't forget about it.]

Cheers,
-- 
intrigeri

diff -Nru libotr-4.1.0/debian/changelog libotr-4.1.0/debian/changelog
--- libotr-4.1.0/debian/changelog	2014-10-21 22:26:51.0 +0200
+++ libotr-4.1.0/debian

libotr transition started by mistake :-/ [Was: Bug#767230: bitlbee-plugin-otr: bitlbee no longer starts: libotr API version 4.1.0 incompatible with actual version 4.0.0]

[intrigeri]

 libotr 4.0,
   and either will be buggy (by missing the correct versioned runtime
   deps) or won't be able to get freeze exceptions (because they'll
   depend, for all practical means, on a package that we'll want to
   keep out of testing).
2. binNMU (against libotr 4.0) any reverse-build-deps that has been
   built against libotr 4.1 already.

Pros:

  * less disrupting changes for Jessie, that is left in its current
state
  * Not much work needed for the RT right now (only a few binNMUs).

Cons:

  * I'll have to find other ways to get the bugfixes from libotr 4.1
and pidgin-otr 4.0.1 into Jessie. Lots of wasted time for me.
I'd rather spend it on reviewing unblock requests ;)
  * More future unblock requests for libotr and pidgin-otr to deal
with on the RT's side.

My preferred option is plan A, because it seems to be simpler for
everyone affected. Plan B would be fine with me too. Option C would
make me sad, and add painful work for everyone involved further along
the road.

Dear RT, what option(s) would be acceptable for you?

Sorry for the burden again..

Cheers!
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85vbn297st@boum.org

Bug#767238: unblock: camitk/3.4.0-1

[intrigeri]

Hi Andreas,

Andreas Tille wrote (29 Oct 2014 14:17:27 GMT) :
 Here you can reas the reasons given by upstream why Debian should
 take over this well more tested version:

It's good to know that upstream has expanded the scope of their
automated test suite. OTOH, considering the new release to be more
tested seems to be a little bit far-fetched, given it has not been
announced on the upstream website yet :)

Additional info for whoever will make the decision:

  * The version currently in testing has no bug known to Debian,
except a wishlist one flagged as wontfix.
  * The debian/changelog entry for 3.4.0-1 doesn't close any bug.
  * Low popcon: 10 for libcamitk3.

 as far as I understood no debdiff is needed for this request.

My understanding of the freeze policy is different:
https://release.debian.org/jessie/freeze_policy.html

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85y4ryy5ba@boum.org

Bug#767238: unblock: camitk/3.4.0-1

[intrigeri]

Andreas Tille wrote (29 Oct 2014 20:52:06 GMT) :
 We are before Freeze and I was explicitly asked to follow [...]

Thanks :)


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/854mumwpsv@boum.org

Bug#767074: unblock: taurus/3.3.1+dfsg-1

[intrigeri]

Control: tags -1 + moreinfo

Hi,

Picca Frédéric-Emmanuel wrote (28 Oct 2014 09:36:55 GMT) :
 Hello, me and the upstream of taurus worked last week to prepare
 a release of taurus specifically for debian8.
 this is mostly a bug fix.

My understanding is that you would like the release team to unblock
this package without looking at the actual (debdiff) data. I doubt
it'll work, but I'm pretty sure that it won't work unless they're
given at least basic information about the proposed changes.

Sadly, the last Debian upload doesn't close any bug, the 3.3.1 release
isn't announced on the upstream website, and I could not find any
upstream changelog in the Debian source tree.

So, please point to the relevant bug reports closed by 3.3.1, that
might help convincing the release team that accepting this last-minute
upstream release is worth it. Thanks!

Cheers,
-- 
intrigeri


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85tx2o8lx8@boum.org

Re: Libvirt testing migration [was: Increasing the testing migration delay]

[intrigeri]

Hi,

Guido Günther wrote (05 Oct 2014 10:17:07 GMT) :
 Are there any plans to unblock systemd anytime soon?

The udeb block was lifted a few hours ago, as announced by kibi.

Cheers,
-- 
intrigeri


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/858ukuer7h@boum.org

Re: Bug#752275: FYI: torbrowser-launcher might require updates during point releases

[intrigeri]

Hi,

Holger Levsen wrote (19 Aug 2014 18:41:30 GMT) :
 I'm not sure how likely this is, [...]

Data point: the certificate that's currently in use, and hard-coded,
is valid for ~2.5 years. It expires in May, 2016. So, it seems that
we'll need at least one stable update during the lifetime of Jessie.

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85egwcxpyu@boum.org

Re: Updating tor

[intrigeri]

Hi,

Peter Palfrader wrote (16 Jun 2014 18:53:13 GMT) :
 I propose to update Tor in stable to the version that is now in jessie.

We've been shipping Tor 0.2.4.x in Tails since last September, back
when it was still a release candidate. This means that this branch of
Tor has been started 6-11k times a day in this environment (i386,
Squeeze-based) for 9 months. No problem so far.

This experience, added to the reasons mentioned by weasel, and to the
fact that I've not seen regressions caused by Tor 0.2.4.x in the few
reverse-deps I'm maintaining in Debian, makes me positive that it's
the way to go for Wheezy.

Cheers,
-- 
intrigeri


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85mwdcpqr6@boum.org

binNMU in wheezy-backports? [Was: Advice needed: uploading hledger to wheezy-backports?]

[intrigeri]

Dear release team,

Joachim Breitner wrote (11 Feb 2014 16:43:56 GMT) :
 is it actually possible to binNMU in wheezy-backports?

Skipping the context and summing up the requirements, the question is:

Is it possible to use the regular wanna-build / binNMU process to
rebuild, and include into wheezy-backports a package:

  * coming from Wheezy
  * (re)built against the current state of wheezy-backports
  * that is not part of wheezy-backports yet

?

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85a9dv8dnq@boum.org

Re: binNMU in wheezy-backports? [Was: Advice needed: uploading hledger to wheezy-backports?]

[intrigeri]

Julien Cristau wrote (13 Feb 2014 12:53:52 GMT) :
 There's no way to do cross-suite binNMU, you need the source in
 wheezy-backports first.

Thanks!

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85iosjyu5p@boum.org

Bug#736257: pu: package libglib-object-introspection-perl/0.009-1+deb7u1

[intrigeri]

Adam D. Barratt wrote (22 Jan 2014 21:35:55 GMT) :
 Please go ahead; thanks.

Uploaded.

Regards,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85zjmlwjsq@boum.org

Bug#728906: Build on unstable requires changes

[intrigeri]

Hi,

Joachim Zobel wrote (06 Dec 2013 07:20:30 GMT) :
 The issue has been discussed on the debian java mailing list, see the
 discussion following 
 http://lists.debian.org/debian-java/2013/11/msg00100.html
 http://lists.debian.org/debian-java/2013/12/msg2.html

 It was found that a build on unstable would require further changes to
 the package. It might also be difficult to do. The reason are changes in
 build dependencies on unstable.

 It would in any case increase the size of the change and thereby make it
 less suitable for stable. The change is currently small (half a dozen
 lines plus in the startup script, one line changed in the control file).
 When adapted to unstable it is likely to end up with a multiple of that.

 As a result I am back to request a direct pu.

 Be aware that git currently holds changes after the debian/7.0.1+dfsg1-6
 tag that are not relevant.

It's unclear to me whose court the ball is in (IOW, if the moreinfo
tag still applies) after this answer.

Joachim, is the situation still that complicated in unstable that the
problems cannot be fixed there?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/851u00l4du@boum.org

Bug#728575: pu: package calendarserver/3.2.dfsg-4

[intrigeri]

Hi,

Adam D. Barratt wrote (04 Dec 2013 20:31:44 GMT) :
 On Sun, 2013-11-03 at 14:05 +0530, Rahul Amaram wrote:
 Updated zoneinfo data

 Is there a plan for doing so in unstable?

Ping?

Regards,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85txcwjprr@boum.org

Bug#725661: pu: opencv/2.3.1+dfsg-1

[intrigeri]

Hi,

Cyril Brulebois wrote (07 Oct 2013 08:41:17 GMT) :
 Nobuhiro Iwamatsu iwama...@debian.org (2013-10-07):
 I'd like to propose an upgrade of opencv.
 
 opencv distributed in wheezy includes source code of non-free (#724920).
 I want to solve this problem.
 Source code of the target is the code for test. It does not affect the 
 actual working.
 
 I attached debdiff. Could you consider this change suitable for 
 stable-proposed-updates?

 (for the records, we usually prefer when bugs are fixed in testing /
 unstable before considering updates in stable.) Anyway, if the files
 indeed got relicensed under a suitable license, why should they get
 removed from an earlier release? At best we could ship a package with
 updated headers and licensing info to reflect the facts all those files
 are actually OK?

Ping?

Regards,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85fvogjpow@boum.org

Bug#725142: pu: package totem-plugin-arte/3.2.1-1~wheezy1

[intrigeri]

Control: tag -1 - moreinfo

Nicolas Delvaux wrote (19 Dec 2013 22:46:25 GMT) :
 Here is a new version proposal, this time taking the traditional path
 of patching the current stable package.

 The debdiff is shorter/easier to review than the one based on the new
 upstream version, but I would still prefer the 3.2.1-1~deb7u1 version
 mainly because it would be easier to maintain for me.

 However, this fix is pending for a much too long time. Now I just want
 the package to be usable again :-)

 All packages are available on mentors:
 http://mentors.debian.net/package/totem-plugin-arte

AFAICT Nicolas has addressed all concerned raised by the release team,
hence I'm dropping the moreinfo tag.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/858uu8jpjg@boum.org

Bug#717420: update reSIProcate in stable from 1.8.5 - 1.8.12

[intrigeri]

Hi,

Daniel Pocock wrote (21 Jan 2014 17:55:15 GMT) :
 On 21/01/14 18:43, intrigeri wrote:
 Jonathan Wiltshire wrote (25 Sep 2013 21:59:15 GMT) :
 I could provide a diff that eliminates changes in such files.
 
 Yes, please.
 
 AFAICT, this stable proposed update has been blocking on the lack of
 a filtered diff for almost 4 months. Daniel, do you still intend to
 follow-up on this?
 

 There have been more upstream improvements, we now have 1.8.14 and may
 make up 1.8.15 just to backport any final bugs that were fixed in the
 1.9.0 testing

 If I provide a filtered diff between 1.8.5 and 1.8.15 will that
 definitely be considered for stable?

I'm not a member of the release team, but in my experience all
not-too-crazy pu diffs are at least considered, once they are actually
shown to the release team.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85txcwgv77@boum.org

Bug#714355: nmu: djview4_4.9-3

[intrigeri]

Hi,

Julien Cristau wrote (30 Sep 2013 08:51:28 GMT) :
 On Fri, Jun 28, 2013 at 10:45:51 +0100, Barak A. Pearlmutter wrote:
[...]
 nmu djview4_4.9-3 . ALL . -m unify libtiff dependency, thanks to Harald 
 Jenny for noting the issue
 
 What does that mean?  What issue?

I see djview4 4.9-4+b1 is now in testing. Can this binnmu request be
closed, then? If not, you'll surely want to answer the question
Julien asked.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/8561pcguu0@boum.org

Bug#731902: nmu: transmission_2.82-1

[intrigeri]

Hi,

Niels Thykier wrote (11 Dec 2013 18:42:44 GMT) :
 On 2013-12-11 07:54, Thomas Goirand wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: binnmu
 
 nmu transmission_2.82-1 . ALL . -m rebuild with newer libminiupnpc

 Not convinced this will work; transmission is OOD on several
 architectures because qt5-qmake is uninstallable/missing.

This still seems to be the case. Thomas, what's the plan?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85d2jkguxv@boum.org

Bug#706488: Aw: Re: Bug#706488: RM: boinc-server-maker/7.0.27

[intrigeri]

Hi,

Thijs Kinkhorst wrote (02 May 2013 07:51:28 GMT) :
 Isn't it possible to fix these vulnerabilities through a DSA or in the
 first point release? Or alternatively remove the binary package in the
 first point release?

Steffen, what are your plans regarding this (now kind of old)
RM request?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85ob34fg0z@boum.org

Bug#712604: nmu: python-scientific_2.9.2-4

[intrigeri]

Hi,

PICCA Frederic-Emmanuel wrote (15 Nov 2013 16:40:40 GMT) :
 Ping?

 Yes the upstream is working on a clean solution.
 So I am waiting for the next release which should fix this problem.

Did I understand correctly that this won't be fixed via a binnmu?
If so, I suppose that this request could be closed.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85y528fg5v@boum.org

Bug#706488: Aw: Re: Bug#706488: Re: Bug#706488: RM: boinc-server-maker/7.0.27

[intrigeri]

Hi,

Steffen Möller wrote (22 Jan 2014 11:11:02 GMT) :
 I would happily see the binary removed. Who do I do this?
 Through reportbug?

My understanding is that it requires a stable proposed update, with
a debdiff that stops building the binary package you want to
see removed.

 Is there also a way to get recent BOINC clients into a point
 release, possibly?

Possibly. See Suite update policy on https://release.debian.org/.
You'll want to file a stable pu bug with reportbug, attaching
a debdiff, making it clear what important bugs it fixes, making sure
not to include unrelated changes, and making sure the bugs are fixed
in testing/sid already. Any not-too-crazy debdiff that satisfies these
basic requirements is usually at least considered.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


--
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/85ob34b63k@boum.org

Bug#736257: pu: package libglib-object-introspection-perl/0.009-1+deb7u1

[intrigeri]

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

Hi,

as described on #736254, a memory allocation bug in Wheezy's
libglib-object-introspection-perl causes segfaults in
reverse-dependencies (#695838).

I've tracked this down to a single upstream commit, that has been part
of sid since last June, and fixes the bug once applied on top of the
Wheezy version. That's why I'm proposing to apply this patch on Wheezy
(debdiff attached).

The only reverse-dependencies of libglib-object-introspection-perl in
Wheezy are libclutter-perl (that itself has no reverse-dependencies)
and libgtk3-perl (whose only reverse-dependency is parcimonie, which
I have successfully tested on a system with the proposed package
update applied). So, the scope of potential adverse effect on packages
included in stable seems very limited.

May I upload libglib-object-introspection-perl 0.009-1+deb7u1 to stable?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

diff -Nru libglib-object-introspection-perl-0.009/debian/changelog libglib-object-introspection-perl-0.009/debian/changelog
--- libglib-object-introspection-perl-0.009/debian/changelog	2012-05-24 13:36:25.0 +0200
+++ libglib-object-introspection-perl-0.009/debian/changelog	2014-01-21 17:13:12.0 +0100
@@ -1,3 +1,12 @@
+libglib-object-introspection-perl (0.009-1+deb7u1) stable; urgency=medium
+
+  * 0001-Use-the-correct-allocator-for-caller-allocated-boxed.patch:
+new patch, cherry-picked from upstream. This fixes incorrect memory
+allocation that causes segfaults in reverse-dependencies
+(Closes: #736254).
+
+ -- intrigeri intrig...@debian.org  Tue, 21 Jan 2014 17:10:07 +0100
+
 libglib-object-introspection-perl (0.009-1) unstable; urgency=low
 
   * Imported Upstream version 0.009
diff -Nru libglib-object-introspection-perl-0.009/debian/patches/0001-Use-the-correct-allocator-for-caller-allocated-boxed.patch libglib-object-introspection-perl-0.009/debian/patches/0001-Use-the-correct-allocator-for-caller-allocated-boxed.patch
--- libglib-object-introspection-perl-0.009/debian/patches/0001-Use-the-correct-allocator-for-caller-allocated-boxed.patch	1970-01-01 01:00:00.0 +0100
+++ libglib-object-introspection-perl-0.009/debian/patches/0001-Use-the-correct-allocator-for-caller-allocated-boxed.patch	2014-01-21 17:13:12.0 +0100
@@ -0,0 +1,62 @@
+From: Torsten Schönfeld kaffeeti...@gmx.de
+Date: Tue, 14 Aug 2012 21:23:35 +0200
+Origin: upstream, https://git.gnome.org/browse/perl-Glib-Object-Introspection/commit/?id=1e4f04c1fea19e4d04b0ccf6d7bfc0b353e57562
+Bug-Debian: https://bugs.debian.org/736254
+Bug-GNOME: https://bugzilla.gnome.org/show_bug.cgi?id=680380
+Applied-Upstream: 0.012
+Subject: Use the correct allocator for caller-allocated boxed out-args
+
+Previously, we simply always used malloc().  But for a boxed type, which has an
+associated custom free function, this might not be the correct allocator.  For
+example, GtkTreeIter uses GSlice.  Make an extra copy of the malloc()-ed block
+to ensure consistency.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=680380
+---
+ gperl-i11n-invoke-c.c | 22 --
+ 1 file changed, 20 insertions(+), 2 deletions(-)
+
+diff --git a/gperl-i11n-invoke-c.c b/gperl-i11n-invoke-c.c
+index 1b3d57f..6ff6478 100644
+--- a/gperl-i11n-invoke-c.c
 b/gperl-i11n-invoke-c.c
+@@ -284,10 +284,16 @@ allocate_out_mem (GITypeInfo *arg_type)
+ {
+ 	GIBaseInfo *interface_info;
+ 	GIInfoType type;
++	gboolean is_boxed = FALSE;
++	GType gtype = G_TYPE_INVALID;
+ 
+ 	interface_info = g_type_info_get_interface (arg_type);
+ 	g_assert (interface_info);
+ 	type = g_base_info_get_type (interface_info);
++	if (GI_IS_REGISTERED_TYPE_INFO (interface_info)) {
++		gtype = get_gtype (interface_info);
++		is_boxed = g_type_is_a (gtype, G_TYPE_BOXED);
++	}
+ 	g_base_info_unref (interface_info);
+ 
+ 	switch (type) {
+@@ -295,8 +301,20 @@ allocate_out_mem (GITypeInfo *arg_type)
+ 	{
+ 		/* No plain g_struct_info_get_size (interface_info) here so
+ 		 * that we get the GValue override. */
+-		gsize size = size_of_interface (arg_type);
+-		return g_malloc0 (size);
++		gsize size;
++		gpointer mem;
++		size = size_of_interface (arg_type);
++		mem = g_malloc0 (size);
++		if (is_boxed) {
++			/* For a boxed type, malloc() might not be the right
++			 * allocator.  For example, GtkTreeIter uses GSlice.
++			 * So use g_boxed_copy() to make a copy of the newly
++			 * allocated block using the correct allocator. */
++			gpointer real_mem = g_boxed_copy (gtype, mem);
++			g_free (mem);
++			mem = real_mem;
++		}
++		return mem;
+ 	}
+ 	default:
+ 		g_assert_not_reached ();
diff -Nru libglib-object-introspection-perl-0.009/debian/patches/series libglib-object-introspection-perl-0.009/debian/patches/series
--- libglib-object-introspection-perl

Bug#711736: pu: package vimperator/3.3-2

[intrigeri]

Hi,

Cyril Brulebois wrote (23 Sep 2013 04:02:26 GMT) :
 Adam D. Barratt a...@adam-barratt.org.uk (2013-06-09):
 Control: tags -1 + moreinfo wheezy

 it's been 3+ months now.

... and now 7+ months.

 Is it still compatible with Iceweasel 10.0, which is still in stable
 for the moment at least?

 Same question with s/10/17/ now I guess…

... and soon with Iceweasel 24, presumably.

François: ping?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


--
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/85zjmpp7z3@boum.org

Bug#725968: pu: package libvirt/0.9.12.2-1

[intrigeri]

Hi,

Guido Günther wrote (10 Oct 2013 15:22:45 GMT) :
 On Thu, Oct 10, 2013 at 03:38:33PM +0200, Cyril Brulebois wrote:
 [..snip..] 
 For the record, we tend to prefer having debdiff (or at least debian
 changelogs) posted to the BTS. Right now I have absolutely no idea which
 bugs you're trying to get fixed, and whether fixes landed in testing or
 unstable.

 libvirt (0.9.12.2-1) wheezy-proposed-updates; urgency=low

   * [77a7135] Adjust gbp.conf for Wheezy point releases
   * [b457e3f] New upstream version 0.9.12.1
   * [ae6e265] New upstream version 0.9.12.2
   * [2d07b5c] Drop patches fixed upstream.
 Include-stdint.h-for-uint32_t.patch
 Revert-rpc-Discard-non-blocking-calls-only-when-nece.patch
 fix-leak-virStorageBackendLogicalMakeVol.patch
 qemu-Add-support-for-no-user-config.patch
 qemu-Fix-off-by-one-error-while-unescaping-monitor-s.patch
 rpc-Fix-crash-on-error-paths-of-message-dispatching.patch
 security/CVE-2012-3445.patch
 security/Fix-crash-in-remoteDispatchDomainMemoryStats.patch
 security/security-Fix-libvirtd-crash-possibility.patch
 upstream/Fix-libvirtd-crash-when-destroying-a-domain-with-att.patch
 upstream/Fix-race-condition-when-destroying-guests.patch

  -- Guido Günther a...@sigxcpu.org  Tue, 01 Oct 2013 21:45:08 +0200

 This also fixes CVE-2013-4311 once we have a fixed polkit in wheezy.

 But seriously, a 15MB diff is nowhere reviewable. Even if most of it is
 automake bootstrap and patches moving around.

 The patches (outside debian/) were all reviewed by upstream and mostly
 incorporate the diff Debian was carrying back upstream so we can release
 further updates from that branch.

I suspect that the changelog snippet that Guido sent does not address
what Cyril was asking (more specifically: which bugs you're trying to
get fixed, and whether fixes landed in testing or unstable).

On the positive side, I can see one thing that could possibly help:
a diff between the current version in stable, with the Debian patches
applied, and the proposed update. It would automatically filter out
the move of Debian-specific patches to the upstream source, and
hopefully it will be of a size that the release team is happy
to review.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


--
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/85y529nsm8@boum.org

Bug#717420: update reSIProcate in stable from 1.8.5 - 1.8.12

[intrigeri]

Hi,

Jonathan Wiltshire wrote (25 Sep 2013 21:59:15 GMT) :
 I could provide a diff that eliminates changes in such files.

 Yes, please.

AFAICT, this stable proposed update has been blocking on the lack of
a filtered diff for almost 4 months. Daniel, do you still intend to
follow-up on this?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85mwipnsd4@boum.org

Bug#707550: opu: package php-mdb2/2.5.0b2-1

[intrigeri]

Hi,

Cyril Brulebois wrote (01 Oct 2013 23:07:36 GMT) :
 Teodor mteo...@gmail.com (2013-05-09):
 This is a follow up on one email thread from debian-release list:
   http://lists.debian.org/debian-release/2012/05/msg00182.html
 
 Please apply the attached patch to php-mdb2 package version 2.5.0b2-1
 from Debian 6.0 (squeeze) in a future point release (6.0.8 or later).

 what you attached was only the upstream part, with no debian changelog
 update, and no documentation at all. Following the steps I mentioned in
 my initial reply would be nice:
   http://lists.debian.org/debian-release/2012/05/msg00188.html

 Most importantly:
   You're supposed to send a source debdiff against the package currently
   in stable, properly versioned.

Teodor, ping?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85sishmdbe@boum.org

Bug#698778: preapproval of expect/5.45-3

[intrigeri]

Hi,

Sergei Golovan wrote (29 Sep 2013 22:07:34 GMT) :
 On Mon, Sep 30, 2013 at 1:59 AM, Cyril Brulebois k...@debian.org wrote:
 Sergei Golovan sgolo...@nes.ru (2013-09-30):
 I've uploaded this change to unstable (and it already hit testing). No
 complains whatsoever.

 yes, I saw that, and that's nice. That doesn't buy us squeeze→wheezy
 upgrade testing, though, which is what we would like to avoid breaking
 or worsening.

 True. But as far as I see, the current situation with this upgrade is
 far from perfect. It silently breaks expectk and packages which depend
 on it. With conflict the user can choose whether to remove expectk or
 to retain the old expect.

My understanding is that this 1-year old proposed update will be
blocked as long as no super-serious testing of its effect on the
Squeeze-Wheezy upgrade is done.

Does anyone here intend to do so at some point, or should we close
this bug?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


--
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/8561pdmcuk@boum.org

Bug#717445: pu: package ndiswrapper/1.57-1+deb7u1

[intrigeri]

Hi,

Cyril Brulebois wrote (29 Sep 2013 23:07:34 GMT) :
 + my $modconf;
 + if (`uname -r` =~ /(\d+)\.(\d+)\.(\d+)/) {
 +-if ($2  4) {
 ++if (($2  4) || ($1  2)) {

 The regex isn't anchored (^) and wants 3 components. The third one was
 dropped a while ago, but maybe in a version higher than what this module
 supports anyway. Just thought I'd mention it…

Julian, Andreas: ping? It seems to me that Cyril was asking for
a clarification at least, and quite possibly for a (trivial) regexp
improvement. Do you still plan to follow-up on this at some point?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


--
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/85k3dtky1u@boum.org

Re: Release sprint results - team changes, auto-rm and arch status

[intrigeri]

Hi,

Robert Millan wrote (12 Jan 2014 12:35:56 GMT) :
 For example, I've been trying to assess the state of GNOME in
 general by trying to find bugs myself. I will report my findings
 soon, however this is clearly not optimal. My quick kick the tires
 testing is much less reliable than day-to-day usage in production
 done by real users.

I'm somewhat surprised that such real Debian/kFreeBSD users (who
I expect to be a bit more tech-savvy than the average Debian user) who
use GNOME on a day-to-day basis are not reporting such bugs to the BTS.

This makes me curious. Assuming these real users actually exist, what
steps can be taken within the Debian/kFreeBSD community to improve
this? I've no idea what kind of communication channels the porters
have with the corresponding users, so I'm wondering.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/85k3e5e50j@boum.org

Bug#732842: pu: package libotr/3.2.1-1

[intrigeri]

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

As discussed on #725779 in more details, the OTRv1 protocol has serious security
issues. Clients supporting it (in addition to more recent, safer versions of the
protocol) are subject to protocol downgrade attacks.

This is why I have proposed to drop support for OTRv1 in libotr in Wheezy.
As the discussion on the aforementioned bug indicates, the maintainer agrees and
the lead upstream developer confirms it is totally fine.

I have therefore backported the relevant bits of the upstream commit that does
just the same in libotr 4.x (currently in testing/sid). The resulting package
was successfully tested with pidgin-otr on Wheezy, and inter-operates correctly
with sid's pidgin-otr and irssi-otr 1.0.0~alpha2-1~bpo70+1.

FTR, testing/sid has libotr 4.x that is not affected by these issues.

May I upload libotr 3.2.1-1+deb7u1 to stable?
diff -Nru libotr-3.2.1/debian/changelog libotr-3.2.1/debian/changelog
--- libotr-3.2.1/debian/changelog	2012-08-07 12:25:12.0 +0200
+++ libotr-3.2.1/debian/changelog	2013-12-22 12:06:00.0 +0100
@@ -1,3 +1,10 @@
+libotr (3.2.1-1+deb7u1) stable; urgency=medium
+
+  * Non-maintainer upload with maintainer's agreement.
+  * Disable insecure OTRv1 protocol (Closes: #725779)
+
+ -- intrigeri intrig...@debian.org  Sun, 22 Dec 2013 11:35:06 +0100
+
 libotr (3.2.1-1) unstable; urgency=high
 
   * Fix potential buffer overflow in base64 routines (Closes: #684121)
diff -Nru libotr-3.2.1/debian/patches/disable_otr_v1.patch libotr-3.2.1/debian/patches/disable_otr_v1.patch
--- libotr-3.2.1/debian/patches/disable_otr_v1.patch	1970-01-01 01:00:00.0 +0100
+++ libotr-3.2.1/debian/patches/disable_otr_v1.patch	2013-12-22 11:34:40.0 +0100
@@ -0,0 +1,39 @@
+Author: Rob Smits rdfsm...@cs.uwaterloo.ca
+Date: Sun Jun 3 22:38:05 2012 -0400
+Subject: Disable OTRv1 protocol.
+Origin: http://sourceforge.net/p/otr/libotr/ci/7ffba65fa42052795523924279bc94e7c80fb0f7/
+Bug: http://bugs.debian.org/725779
+Forwarded: not-needed
+Reviewed-by: intrigeri intrig...@debian.org
+Last-Update: Sun Dec 22 11:30:00 2013 +0100
+Applied-Upstream: 4.0.0
+
+diff --git a/src/proto.h b/src/proto.h
+index d7b0ae6..e96e2f2 100644
+--- a/src/proto.h
 b/src/proto.h
+@@ -45,20 +45,17 @@ typedef unsigned int OtrlPolicy;
+ 
+ #define OTRL_POLICY_VERSION_MASK (OTRL_POLICY_ALLOW_V1 | OTRL_POLICY_ALLOW_V2)
+ 
+-/* For v1 compatibility */
++/* Analogous to v1 policies */
+ #define OTRL_POLICY_NEVER			0x00
+ #define OTRL_POLICY_OPPORTUNISTIC \
+-	( OTRL_POLICY_ALLOW_V1 | \
+-	OTRL_POLICY_ALLOW_V2 | \
++	( OTRL_POLICY_ALLOW_V2 | \
+ 	OTRL_POLICY_SEND_WHITESPACE_TAG | \
+ 	OTRL_POLICY_WHITESPACE_START_AKE | \
+ 	OTRL_POLICY_ERROR_START_AKE )
+ #define OTRL_POLICY_MANUAL \
+-	( OTRL_POLICY_ALLOW_V1 | \
+-	OTRL_POLICY_ALLOW_V2 )
++	( OTRL_POLICY_ALLOW_V2 )
+ #define OTRL_POLICY_ALWAYS \
+-	( OTRL_POLICY_ALLOW_V1 | \
+-	OTRL_POLICY_ALLOW_V2 | \
++	( OTRL_POLICY_ALLOW_V2 | \
+ 	OTRL_POLICY_REQUIRE_ENCRYPTION | \
+ 	OTRL_POLICY_WHITESPACE_START_AKE | \
+ 	OTRL_POLICY_ERROR_START_AKE )
diff -Nru libotr-3.2.1/debian/patches/series libotr-3.2.1/debian/patches/series
--- libotr-3.2.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libotr-3.2.1/debian/patches/series	2013-12-22 11:34:40.0 +0100
@@ -0,0 +1 @@
+disable_otr_v1.patch

Bug#732842: pu: package libotr/3.2.1-1

[intrigeri]

Hi,

Cyril Brulebois wrote (22 Dec 2013 16:51:49 GMT) :
 intrigeri intrig...@debian.org (2013-12-22):
 This is why I have proposed to drop support for OTRv1 in libotr in
 Wheezy.

 This makes me wonder whether there are some packages only supporting
 OTRv1 in wheezy. If there are, I suspect they want to get a serious
 bug since they won't work at all anymore.

I kinda doubt there's any such thing in the archive, as libotr 4.x
clients (that only support OTRv2 and later) have been around for
a while already, so users of clients that only support OTRv1 would
have noticed the breakage already. Maybe even maintainers would have
noticed :)

 FTR, testing/sid has libotr 4.x that is not affected by these issues.

 The BTS wants to be taught that.

Done.

 May I upload libotr 3.2.1-1+deb7u1 to stable?

 Looks fine to me.

Thanks, uploaded.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/8561qgq00a@boum.org