Bug#1049902: raspi-firmware on non-rpi arm64

[Adam Borowski]

gwolf wrote:
> The only risk I can think of is that the bug might still impact users of
> non-Raspberry ARM systems. However, the likelihood of having it installed is
> minor (due to the available hardware being different).

Given that the laptop I use on the DebConf right now has 100% likelihood of
having this firmware installed (because of no network otherwise), you might
want to test stuff on it.

On the other hand, while the package can't be removed nor upgraded without
manually messing with both the hook and the postinst, it couldn't be
installed in the first place without doing so as well, thus people are at
least aware.  Thus, my priority is in getting rid of raspi-only bits...

In any case, I'd be glad helping test -- and you can put your hands on
this box if you fancy so.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
⠈⠳⣄

Bug#1021406: nmu: * against debhelper 13.9.1

[Adam Borowski]

Package: release.debian.org
Severity: normal

Hi!
The following packages in unstable still have binaries built against
debhelper 13.9, which adds spurious dependencies on "systemd |
systemd-tmpfiles".  This causes at least the following problems:
 * forced init switch with !systemd (with an obscure workaround)
 * makes small containers fatter
 * dependencies will unexpectedly change on a rebuild (incl. security)
The relevant bug is #1017441 -- but it'd be probably a waste of your time
to read it now that a resolution has been found; all we need is to rebuild
the stragglers.

I've verified "at home" that all of these currently build successfully on
amd64.

nmu connman 1.41-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu cyrus-imapd 3.6.0~beta2-5 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu drbd-utils 9.21.4-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu etbemon 1.3.6-3 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu json2file-go 1.15 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu krb5 1.20-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu libpod 3.4.7+ds1-3 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu lvm2 2.03.16-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu mpd 0.23.9-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu myproxy 6.2.14-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu nagios-nrpe 4.1.0-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu nsd 4.6.0-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu open-vm-tools 2:12.1.0-1 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu opendkim 2.11.0~beta2-7 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu opendmarc 1.4.2-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu openvpn 2.6.0~git20220818-1 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu php8.1 8.1.7-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu pushpin 1.35.0-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu rpcbind 1.2.6-6 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu screen 4.9.0-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu sudo 1.9.11p3-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu tirex 0.7.0-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu xrootd 5.5.0-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"


Meow!

Re: Porter roll call for Debian Bookworm

[Adam Borowski]

On Sat, Oct 02, 2021 at 11:57:07AM +0200, Graham Inggs wrote:
> We are doing a roll call for porters of all prospective release
> architectures.

While I'm not anywhere near being a core porter, I guess riff-raff porters
are not completely worthless.  Thus:

"""
  Hi,

  I am an active porter for the following architectures and I intend to
  continue for the development cycle of Debian Bookworm
  (est. release mid-2023):

  For riscv64, I
  - test random packages on this architecture
  - run (currenly 2) Debian unstable systems on port that I use regularly
  - triage arch-specific bugs
  - fix arch-related bugs
  ~~
  - have ported and regularly test the persistent memory stack
  - regularly troll the IRC channel

  I am a DD.

  Adam Borowski
"""

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄


signature.asc
Description: PGP signature

Bug#995304: bullseye-pu: package pmdk/1.10-2

[Adam Borowski]

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

[ Reason ]
There's a bug in pmdk versions 1.9..1.11, that can cause data loss when
power to the CPU is lost (ie, an unclean shutdown of the machine).

It's caused by a clash between a macro named "barrier" vs function pointers
also named "barrier".

buster (1.5) has an ancient version of this code from before it was
reworked, and thus doesn't contain this bug.
buster-bpo (1.9.2) has a full upstream bugfix release (1.9.3) waiting in
BACKPORTS-POLICY.
bullseye (1.10) can be fixed either via the full upstream bugfix release
(1.10.1) or via a single cherry-picked commit; this p-u has just the
single fix.
bookworm (1.11) has already been updated to 1.11.1.

[ Impact ]
With missing barriers, a power loss at an unfortunate moment can cause
data corruption: eg. a pointer to a new version of the data may survive
the crash but the data hasn't been made durable yet, etc.

[ Tests ]
It's hard to test power loss behaviour -- the persistent vs volatile state
isn't distinguishable without an actual power loss.  There's a valgrind
fork (pmemcheck) that is supposed to look for this kind of bugs, but it
didn't catch this one.

On the other hand, non-temporal memcpy has same visible effects as regular
(cached) memcpy, and testing whether it actually works is well-covered by
the testsuite, ran at build time.

[ Risks ]
The compiler barriers (the macro) were introduced long after function
pointers thus re-exposing the proper code is well tested.  And, a store
barrier too much can't hurt anything but a bit of performance.

[ Checklist ]
  [✓] *all* changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in (old)stable
  [✓] the issue is verified as fixed in unstable

[ Changes ]
I've cherry-picked commit 55ec1b24ac89371e1dd0544a17662c738075041e from
upstream.  The patch renames all uses of the macro, converting it to an
inline function as well.

[ Other info ]
The bug was introduced in 75ba8a54b3e7045dbbdc2cf7324fe71d8d24069a.
diff -Nru pmdk-1.10/debian/changelog pmdk-1.10/debian/changelog
--- pmdk-1.10/debian/changelog  2021-07-02 17:02:37.0 +0200
+++ pmdk-1.10/debian/changelog  2021-09-28 17:41:00.0 +0200
@@ -1,3 +1,9 @@
+pmdk (1.10-2+deb11u1) bullseye; urgency=high
+
+  * Fix missing barriers after non-temporal memcpy.
+
+ -- Adam Borowski   Tue, 28 Sep 2021 17:41:00 +0200
+
 pmdk (1.10-2) unstable; urgency=high
 
   * Fix insufficient flushing on ARMv8.2+ (closes: #990573).
diff -Nru 
pmdk-1.10/debian/patches/0001-common-fix-missing-sfence-in-non-temporal-memcpy.patch
 
pmdk-1.10/debian/patches/0001-common-fix-missing-sfence-in-non-temporal-memcpy.patch
--- 
pmdk-1.10/debian/patches/0001-common-fix-missing-sfence-in-non-temporal-memcpy.patch
1970-01-01 01:00:00.0 +0100
+++ 
pmdk-1.10/debian/patches/0001-common-fix-missing-sfence-in-non-temporal-memcpy.patch
2021-09-28 17:41:00.0 +0200
@@ -0,0 +1,188 @@
+From e67ca1ee3089d28e5945bc4a3e33ac525e313b5b Mon Sep 17 00:00:00 2001
+From: Piotr Balcer 
+Date: Wed, 1 Sep 2021 14:12:49 +0200
+Subject: [PATCH] common: fix missing sfence in non-temporal memcpy
+
+The implementation of hardware fencing for non-temporal
+memcpy variants is done using a function pointer. Some
+of those pointers are called "barrier" which unfortunately
+overlaps with a function-like macro that's used for compiler
+barriers. This meant that a compiler barrier was being used
+instead of a hardware store barrier.
+
+This patch changes the compiler barrier to a static inline
+function called "compiler_barrier" to avoid name conflicts.
+
+Fixes #5292
+Reported-by: @Transpeptidase
+---
+ src/core/util.h| 17 ++---
+ src/libpmem2/x86_64/memcpy/memcpy_nt_avx.c |  4 ++--
+ src/libpmem2/x86_64/memcpy/memcpy_nt_avx512f.c |  4 ++--
+ src/libpmem2/x86_64/memcpy/memcpy_nt_sse2.c|  4 ++--
+ src/libpmem2/x86_64/memset/memset_nt_avx.c |  4 ++--
+ src/libpmem2/x86_64/memset/memset_nt_avx512f.c |  4 ++--
+ src/libpmem2/x86_64/memset/memset_nt_sse2.c|  4 ++--
+ 7 files changed, 26 insertions(+), 15 deletions(-)
+
+diff --git a/src/core/util.h b/src/core/util.h
+index 542047a17..1ce575dfa 100644
+--- a/src/core/util.h
 b/src/core/util.h
+@@ -1,5 +1,5 @@
+ /* SPDX-License-Identifier: BSD-3-Clause */
+-/* Copyright 2014-2020, Intel Corporation */
++/* Copyright 2014-2021, Intel Corporation */
+ /*
+  * Copyright (c) 2016-2020, Microsoft Corporation. All rights reserved.
+  *
+@@ -133,13 +133,24 @@ void util_set_alloc_funcs(
+ #ifdef _MSC_VER
+ #define force_inline inline __forceinline
+ #define NORETURN __declspec(noreturn)
+-#define barrier() _ReadWriteBarrier()
+ #else
+ #define force_inline __attribute__((always_inline)) inline
+ #define NORETURN __attribute__((nor

Bug#992193: RM: birdtray/1.5-1

[Adam Borowski]

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

Hi!
As thunderbird is an animal more equal than others and gets to update to
major new upstream releases inside stable, related packages are likely to
get broken.  This happened over a year ago to birdtray.  Naturally, it
got updated upstream -- but that's a mix of support for new thunderbird
and unrelated new developments.

That made birdtray ineligible for a stable update as-is -- unless I argued
for uploading to a major new upstream, or did the work of unentangling
changes to somehow extract just the needed bits.  Neither has happened,
and by now we have Bullseye released.

Cf. #959927

Thus, let's get rid of birdtray/buster -- and hope this won't happen again.


Meow!

Bug#991062: unblock: apache2/2.4.48-3.1

[Adam Borowski]

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

Hi!
Please unblock package apache2.  After a bunch of random changes from
experimental got into testing, there were regressions.  Forbidding such
changes is pretty much the point of the freeze after all...

One of the regressions (#990580) causes cron mails on every logrotate run. 
Thorsten Glaser has, with permission of the maintainer, made a NMU
containing an one-line fix.


[ Reason ]
The change that caused the regression shouldn't have been included into
testing so late in the freeze; let's fix the nastiest bit.

[ Impact ]
A very popular package with massive deployments would send a mail once per
day per machine, severely annoying admins.

[ Tests ]
No automated tests; to test manually wait a night with the default
configuration to see if you'll receive a mail; can logrotate -v -f and
see if there's output.

[ Risks ]
It's a simple one-line fix.

[ Checklist ]
  [✓] all changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in testing


unblock apache2/2.4.48-3.1
diff -Nru apache2-2.4.48/debian/apache2.logrotate 
apache2-2.4.48/debian/apache2.logrotate
--- apache2-2.4.48/debian/apache2.logrotate 2021-06-20 13:55:24.0 
+0200
+++ apache2-2.4.48/debian/apache2.logrotate 2021-07-10 23:31:24.0 
+0200
@@ -14,7 +14,7 @@
 endscript
 postrotate
if pgrep -f ^/usr/sbin/apache2 > /dev/null; then
-   invoke-rc.d apache2 reload
+   invoke-rc.d apache2 reload 2>&1 | logger -t apache2.logrotate
fi
 endscript
 }
diff -Nru apache2-2.4.48/debian/changelog apache2-2.4.48/debian/changelog
--- apache2-2.4.48/debian/changelog 2021-06-20 16:39:33.0 +0200
+++ apache2-2.4.48/debian/changelog 2021-07-10 23:31:28.0 +0200
@@ -1,3 +1,11 @@
+apache2 (2.4.48-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Direct init script reload output from logrotate to syslog, to
+avoid mail-spamming the local admin (Closes: #990580)
+
+ -- Thorsten Glaser   Sat, 10 Jul 2021 23:31:28 +0200
+
 apache2 (2.4.48-3) unstable; urgency=medium
 
   * Fix debian/changelog

Bug#988500: unblock: btrfs-progs/5.10.1-2

[Adam Borowski]

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

Please unblock package btrfs-progs

The version in Bullseye suffers from a regression that breaks adding new
devmapped devices to btrfs filesystems.  The bug has been fixed in 5.11
shortly after, but that version is not targetted at Bullseye, thus here
comes a cherry-picked patch to 5.10.

The patch is an one-liner:
+-  char *dm = path_canonicalize(p + 1);
++  char *dm = path_canonicalize_dm_name(p + 1);

[ Reason ]
A large portion of users use lvm and friends, the bug breaks multi-device
btrfs for them.  It would be nasty to have such a regression in a popular
filesystem in Bullseye.

[ Impact ]
There's a non-obvious workaround: the user can find the canonical path
for the given dm device; the error message doesn't suggest where to look
at.  We're supposed to allow using user-friendly path names.

[ Tests ]
No automated tests at this time, sorry (on my TODO list, but that'd
require qemu wrangling or possibly breaking the test system).
A manual test is described in the bug report:
Create a pair of LVM devices.  mkfs.btrfs one of them, mount.  Then
btrfs dev add /dev/mapper/vg-test2 /mnt/test1

[ Risks ]
It's a simple fix, and well-tested in 5.11 and 5.12 used in experimental
and other distributions (as they aren't frozen at this time).

[ Checklist ]
  [✓] all changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in testing


unblock btrfs-progs/5.10.1-2
diff -Nru btrfs-progs-5.10.1/debian/changelog 
btrfs-progs-5.10.1/debian/changelog
--- btrfs-progs-5.10.1/debian/changelog 2021-02-06 00:04:21.0 +0100
+++ btrfs-progs-5.10.1/debian/changelog 2021-05-14 02:52:17.0 +0200
@@ -1,3 +1,9 @@
+btrfs-progs (5.10.1-2) unstable; urgency=medium
+
+  * Fix failure to add new devices via a devmapper path.  Closes: #982990
+
+ -- Adam Borowski   Fri, 14 May 2021 02:52:17 +0200
+
 btrfs-progs (5.10.1-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru btrfs-progs-5.10.1/debian/patches/devmapper-path 
btrfs-progs-5.10.1/debian/patches/devmapper-path
--- btrfs-progs-5.10.1/debian/patches/devmapper-path1970-01-01 
01:00:00.0 +0100
+++ btrfs-progs-5.10.1/debian/patches/devmapper-path2021-05-14 
02:50:25.0 +0200
@@ -0,0 +1,24 @@
+commit dcfda5527538993dc7b2291cb9b9b9967f3b3c4a
+Author: David Sterba 
+Date:   Wed Feb 10 16:36:50 2021 +0100
+
+btrfs-progs: fix device mapper path canonicalization
+
+Commit 922eaa7b5472 ("btrfs-progs: build: fix linking with static
+libmount") broke path canonicalization, that prevented eg 'device add
+/dev/dm-0' to properly recognize the device mapper names.
+
+Issue: #339
+Signed-off-by: David Sterba 
+
+--- btrfs-progs-5.10.1.orig/common/path-utils.c
 btrfs-progs-5.10.1/common/path-utils.c
+@@ -325,7 +325,7 @@ char *path_canonicalize(const char *path
+   return strdup(path);
+   p = strrchr(canonical, '/');
+   if (p && strncmp(p, "/dm-", 4) == 0 && isdigit(*(p + 4))) {
+-  char *dm = path_canonicalize(p + 1);
++  char *dm = path_canonicalize_dm_name(p + 1);
+ 
+   if (dm) {
+   free(canonical);
diff -Nru btrfs-progs-5.10.1/debian/patches/series 
btrfs-progs-5.10.1/debian/patches/series
--- btrfs-progs-5.10.1/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ btrfs-progs-5.10.1/debian/patches/series2021-05-14 02:49:40.0 
+0200
@@ -0,0 +1 @@
+devmapper-path

Bug#980832: nmu: tor_0.4.4.6-1

[Adam Borowski]

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

Hi!
The tor package is paranoid about version of libzstd, and currently says:

[warn] Tor was compiled with zstd 1.4.5, but is running with zstd 1.4.8.
↪ For safety, we'll avoid using advanced zstd functionality.

Whether or not this warning is dubious (#963151), for the lifetime of
Bullseye we can assume the upstream version of libzstd won't change.
Thus, a simple rebuild against bullseye's libzstd is a good enough
workaround.

nmu tor_0.4.4.6-1 . ANY . unstable . -m "Rebuild against libzstd 1.4.8"


Meow!
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0-rc4-00014-gc9b56d9c1053 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#968502: buster-pu: arch-test needs to be updated in stable to include s390x fix

[Adam Borowski]

On Mon, Aug 17, 2020 at 07:31:01PM +0100, Adam D. Barratt wrote:
> On Sun, 2020-08-16 at 15:43 +0200, Adam Borowski wrote:
> 
> +arch-test (0.15-2+deb10u1) buster; urgency=medium
> +
> +  * Fix s390x detection sometimes failing (Alexander Efremkin).
> 
> Please go ahead.

Thanks, uploaded.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄

Bug#968502: buster-pu: arch-test needs to be updated in stable to include s390x fix

[Adam Borowski]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: Philipp Kern 


On Sun, Aug 16, 2020 at 03:05:14PM +0200, Philipp Kern wrote:
> Hey Adam,
> 
> It looks like the commit in [1] to fix up the string length on s390x is
> missing from Debian stable. Without it debootstrap's arch-test call
> fails and thus it refuses to bootstrap. The binary from the current git
> tree works for me:
> 
> > pkern@ldebpk02:~/arch-test$ make arch-test-s390x
> > s390x-linux-gnu-as s390x.s -o s390x.o
> > s390x-linux-gnu-ld -s s390x.o -o arch-test-s390x
> > pkern@ldebpk02:~/arch-test$ ./arch-test-s390x 
> > ok
> 
> Could you try to get a stable update ready for this? It's actually
> severe enough, me thinks. If you (or the Release team) want me to file a
> bug against debootstrap being broken, I can do that, of course. The
> evidence:
> 
> > + arch-test -c /srv/chroots/sid s390x
> > /usr/bin/arch-test: line 59: warning: command substitution: ignored null 
> > byte in input
> > s390x: not supported on this machine/kernel
> 
> Kind regards and thanks
> Philipp Kern
> 
> [1]
> https://github.com/kilobyte/arch-test/commit/c0a700015221af5ec7e1f104b0646c0d0f6f2dd3

Sounds good to me -- I've cherry-picked that patch, and here's the stable
update request.  Debdiff attached.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄
diff -Nru arch-test-0.15/debian/changelog arch-test-0.15/debian/changelog
--- arch-test-0.15/debian/changelog 2019-02-27 13:41:50.0 +0100
+++ arch-test-0.15/debian/changelog 2020-08-16 15:25:50.0 +0200
@@ -1,3 +1,9 @@
+arch-test (0.15-2+deb10u1) buster; urgency=medium
+
+  * Fix s390x detection sometimes failing (Alexander Efremkin).
+
+ -- Adam Borowski   Sun, 16 Aug 2020 15:25:50 +0200
+
 arch-test (0.15-2) unstable; urgency=medium
 
   * Don't check for SWP on armel; it's not needed in the vast majority of
diff -Nru arch-test-0.15/debian/patches/s390x_lghi 
arch-test-0.15/debian/patches/s390x_lghi
--- arch-test-0.15/debian/patches/s390x_lghi1970-01-01 01:00:00.0 
+0100
+++ arch-test-0.15/debian/patches/s390x_lghi2020-08-16 15:25:50.0 
+0200
@@ -0,0 +1,11 @@
+--- arch-test-0.15.orig/s390x.s
 arch-test-0.15/s390x.s
+@@ -9,7 +9,7 @@ base:
+   sr  %r1, %r2
+   lhi %r2, 1
+   la  %r3, msg(%r1)
+-  lhi %r4, 3
++  lghi%r4, 3
+   svc 4
+ 
+   xr  %r2, %r2
diff -Nru arch-test-0.15/debian/patches/series 
arch-test-0.15/debian/patches/series
--- arch-test-0.15/debian/patches/series2019-02-27 13:41:00.0 
+0100
+++ arch-test-0.15/debian/patches/series2020-08-16 15:25:50.0 
+0200
@@ -1 +1,2 @@
 armel_no_swp
+s390x_lghi

Bug#933605: nmu: pmdk-convert_1.5.1-1

[Adam Borowski]

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

Hi!
Because of the new "binary upload needed for NEW but banned for migration",
the package is stuck in unstable.  Please rebuild.

I uploaded with arm64 as a sacrificial arch with no build log for the same
reason as the new rule is for, but since the rule is mandatory, please:

nmu pmdk-convert_1.5.1-1 . arm64 . unstable . -m "Rebuild on a buildd."


Meow!
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 4.4.167-1213-rockchip-ayufan-g34ae07687fce (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Adam Borowski]

On Thu, Jul 11, 2019 at 09:34:07PM +0200, gregor herrmann wrote:
> You indeed missed someone (for obvious reasons): I'd like to thank
> the release team for their excellent work!

+1

> On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote:
> > The release of buster also means the bullseye release cycle is about to 
> > begin.
> > From now on, we will no longer allow binaries uploaded by maintainers to
> > migrate to testing. This means that you will need to do source-only uploads 
> > if
> > you want them to reach bullseye.

> But this part not so much.
>  
> Forcing hundreds of maintainers to do two uploads for a new package
> seems to me like the wrong solution for the conflicting interests of
> the ftp team (wants to see binary packages for review in NEW) and the
> release team (doesn't want to see binary packages in testing not
> built by buildds).

There's also a third concern: we need a way to bootstrap B-Depend cycles. 
Such as a self-hosting compiler, cyclical dependencies within an ecosystem,
importing a whole new architecture, etc.

> I hope that there will be a better solution for this dilemma in the
> not too distant future. If throwing away binaries is too problematic,
> as Niels mentioned, maybe SomeThing™ could build a binary package for
> the ftp-masters for source-only uploads to NEW. Or people knowing the
> whole infrastructure better than me have smarter ideas :)

The -ports team has an "unreleased" suite that buildds can use both for
Deps and B-Deps, and people can use before patches are upstreamed.
Something of this kind could be done for binary uploads.

Some dude named Ken Thompson had an insightful comment here, but that's
the easiest solution for now.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋  by a hacker".  So what's the problem?
⠈⠳⣄

Bug#925489: marked as done (unblock: elogind/241.1-1+debian1)

[Adam Borowski]

On Mon, Apr 08, 2019 at 02:57:03PM +, Debian Bug Tracking System wrote:
> > I am aware that the debdiff against testing (239.3+20190131-1+debian1) is
> > significantly larger than you would normally want at this stage in the 
> > release
> > cycle. However, I believe it is warranted and ask for your consideration.
> 
> > The benefits of migration centre around this version of elogind providing 
> > ABI
> > compatibility between libelogind0 and libsystemd0 (see #923244). This means 
> > that
> > packages compiled against libsystemd-dev headers work correctly with either
> > libsystemd0 or libelogind0 runtime libraries. This is particularly 
> > important for
> > policykit-1 authorization of many desktop functions (particularly restart, 
> > halt,
> > suspend and for pkexec which is essential for synaptic) on non-systemd init
> > installations.

> This change is way to big to be unblocked.

I agree -- but this approach was what was requested for policykit-1.

What would you suggest instead?


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Bug#925489: unblock: elogind/241.1-1+debian1

[Adam Borowski]

On Tue, Mar 26, 2019 at 06:52:11PM +0100, Michael Biebl wrote:
> Just to set the record straight here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244
> 
> This bug report is from Mon, 25 Feb 2019 11:49:14 +

That's the "plan 3" bug.  We had plan 1 over a year ago.

> That this all is getting rushed on the last minute is not the fault of
> the policykit-1 maintainers and I'm not amused that Adam tries to paint
> it like that.

I'm not amused either how long it takes to get any response to even a
single-line patch that had been discussed before.  But, the blame game is
counterproductive.  Could we please discuss how to fix present state?

It had been requested that the point of alternative gets moved.  That
request is now fulfilled, the code is uploaded, and has seen 12 days of
testing.  At this point, I kindly request your review.  Is the current
version of elogind, as packaged by Mark Hindley, good enough for you?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Bug#925489: unblock: elogind/241.1-1+debian1

[Adam Borowski]

It's not a "niche" area.  Without this, any modern GUI desktop environments
are not installable with any pid 1 other than systemd.  That'd be a massive
regression that's certainly not acceptable (and it's caused by removal of a
systemd component with a hard dependency).

This regression had a plan, with coded and tested patches by January 2018
(with a refresh + retesting in June, then November, December).  In that
plan, policykit packages had alternatives built against elogind.  Yet
patches did not get applied.  Plan 2 was to dlopen() relevant libraries.

Then, once a required one-line patch was finally applied to src:systemd
(already in testing), policykit maintainers requested plan 3: to change
libelogind0 to implement 100% of libsystemd0's ABI, so the alternative
works at a different level:

Plan 1:
 ├─ policykit-systemd ─── libsystemd0 ─── systemd
 │
 └─ policykit-elogind ─── libelogind0 ─── elogind

Plan 2:
 └─ policykit ─── libsystemd0 ─┬─ systemd
   │
   └─ elogind

Plan 3:
 └─ policykit ─┬─ libsystemd0 ─── systemd
   │
   └─ libelogind0 ─── elogind

(Consumers of logind API other than policykit go mostly via libpam-*d).

With help of elogind's upstream, this request has been implemented.  Of
course, such a change has a pretty large debdiff.  Yet, with no reports of
regression within 12 days of testing in unstable, I believe it should be
relatively safe.

I'm not really happy with asking for an unblock for such a debdiff -- but
if this can't go in, we'd need to use one of the other plans.  Please say
if you consider that to be better.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Adam Borowski]

[Oy vey, crosspost list from hell -- not sure how to trim...]

On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote:
> I do think this just reinforces the point that second-class architectures
> should have better, more robust support from the Debian project.

> For example, arch-specific packages most decidedly have a place in Debian

> The build and package delivery infrastructure should offer the same features
> for both first and second class archs, including installer image building for
> all "tiers" (stable, testing, unstable).

It seems to me that the important bit is the testing suite.  As a (now
lapsed) x32 porter, I tried to implement that on my own (goal being an
unofficial, weakly security supported[1] Jessie for x32).  And tracking
testing on my own proved to be too hard.  What directly defeated me were
binNMUs: with every arch having its own NMU counter and hidden triggers,
this is already a mess.  Add NMUs due to private ported packages, and all
hell breaks loose.

The rest is easy in comparison: a porter team can decide whether to snapshot
testing as unofficial stable; point releases are a matter of running a
buildd job (and fixing failures), same for security.  We'd be able to
concentrate on actual arch-specific issues.

> The main difference should (IMHO) be the amount of support you get: While a
> first-class arch will get faster fixes and a more stable dependency tree,
> other archs will be more "sloppy", for example by not blocking stable releases
> with their own RC bugs etc.

Yeah, a completely one-way relationship: no issue on second-class would
block first-class.

> If this can be fulfilled, I don't think being a second-class arch will be such
> a big deal. Not sure how far Debian is from this goal, but I can understand
> that many DDs and DMs would rather invest their time into projects they have a
> stake in, rather than hardware they don't (or don't want to?) understand.

Yes, x32 suffers from needing obscure and hard to get hardware. :)


Meow!

[1]. The vast majority of security issues are non arch dependent, so blindly
tracking and building first-class security updates gets us nearly all the
way, reducing the work to babysitting buildds and looking into FTBFSes or
yet another whole-new-language-ecosystem getting allowed into stable.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#909007: stretch-pu: package firetray/0.6.1+dfsg-1

[Adam Borowski]

On Sat, Oct 27, 2018 at 09:46:19PM +0100, Adam D. Barratt wrote:
> On Sat, 2018-10-27 at 22:44 +0200, Adam Borowski wrote:
> > On Sat, Oct 27, 2018 at 04:21:09PM +0100, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > 
> > In the meantime, another upload of thunderbird broken the version check,
> > which was "up to 60.0".  Turns out 60.2.1 does not match that anymore. 
> > Details in #910973; no one from the maintainer team responded thus I
> > scheduled a NMU, it'll go in tomorrow evening.
> 
> It sounds fine, as long as it's uploaded in time.

I've uploaded as 0.6.1+dfsg-1.2~deb9u1 -- with a changelog written to be a
backport of the unstable version rather than as one patch.  There's no
actual difference, as there were no unrelated uploads between stretch and
current buster.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Bug#909007: stretch-pu: package firetray/0.6.1+dfsg-1

[Adam Borowski]

On Sat, Oct 27, 2018 at 04:21:09PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2018-09-17 at 13:09 +0200, Adam Borowski wrote:
> > I'm afraid that the security update of thunderbird from 52 to 60
> > broke firetray, which, despite being a mere "extension", includes
> > some quite essential functionality for thunderbird (described below).
> 
> Apologies for the delay in getting back to you regarding this. The
> general response so far from the Security Team has been that they see
> these as stable issues, so let's go with fixing it via p-u. Please use
> the version suggested later in the thread, if the package is
> essentially a backport from unstable.

In the meantime, another upload of thunderbird broken the version check,
which was "up to 60.0".  Turns out 60.2.1 does not match that anymore. :/
Details in #910973; no one from the maintainer team responded thus I
scheduled a NMU, it'll go in tomorrow evening.

Unlike the first patch which required quite large code changes, this is just
a version bump.  I guess you have no problems with that, but stretch-pu bugs
are version-marked so we'd still need to coordinate on it.


And wrt the future: some people went angry about Thunderbird breaking
extensions again and again, and made https://github.com/gyunaev/birdtray
Obviously, it's not an option for Stretch, but there's hope we'll avoid this
unpleasantness for Buster.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Bug#909007: please include in stretch-updates

[Adam Borowski]

Hi!
The upstream bug includes reports from users who tried the updated package
on stable (stretch and ascii).  Minus some confusion they had wrt apt
source, it sounds like all is ok.  Discussed in later parts of
https://github.com/foudfou/FireTray/issues/238

Thus, it would be nice if you could include it in volatile as well, as
without firetray, new mail notifications don't persist in thunderbird since
the security update.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 10 people enter a bar:
⣾⠁⢰⠒⠀⣿⡁ • 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ • 1 who doesn't,
⠈⠳⣄ • and E who tend to write it as hex.

Bug#909007: stretch-pu: package firetray/0.6.1+dfsg-1

[Adam Borowski]

On Mon, Sep 17, 2018 at 08:02:10AM -1000, David Prévot wrote:
> Le 17/09/2018 à 01:09, Adam Borowski a écrit :
> 
> > The updated package is 100% identical to the version in unstable, only the
> > version number differs (+deb9u1).
> 
> Please, use ~deb9u1 instead: you don’t want to push a higher version
> than in unstable.

Sorry for being unclear; the debdiff has:
• stretch  0.6.1+dfsg-1
• proposed 0.6.1+dfsg-1+deb9u1<=
• unstable 0.6.1+dfsg-1.1
which sort this way.

Would you prefer 0.6.1+dfsg-1.1~deb9u1 instead?  Probably indeed better as
it makes it more clear it's the same thing as in unstable.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Bug#909007: stretch-pu: package firetray/0.6.1+dfsg-1

[Adam Borowski]

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


Hi!
I'm afraid that the security update of thunderbird from 52 to 60 broke
firetray, which, despite being a mere "extension", includes some quite
essential functionality for thunderbird (described below).

Unlike Firefox, Thunderbird did not drop XUL even in "Quantum" versions
(although there's a discussion whether to drop it or not in the future). 
This allows firetray to work, although it required quite a bit of fixing. 
The original author has discontinued his work (with nasty rants about
Mozilla development which I agree with), the extension has been fixed by
others.  The fork hasn't been officially released because it's still broken
on Windows, but that's not a problem for us.

Thus, we should fix this regression.  Do you think a regression caused by a
security update should go via security or via stable-pu?  I'm sending it
your way first.

As the maintainers had no tuits to assist me, this is a NMU.  I'm also
afraid that the debdiff is quite hairy: not only the changes required due to
Quantum are non-trivial, but I also don't know the packaging scripts
adequately -- it's possible the diff could have been smaller.  Still, a good
part of it is due to missing images that caused FTBFS for newer mozillas.

The updated package is 100% identical to the version in unstable, only the
version number differs (+deb9u1).


And why firetray is more important than other extensions?  While "minimize
to tray" is mostly a nicety (non-negligible one: if you have ~two programs
per workspace, extending the taskbar/alt-tab set from two to three is
noticeable), persistent notification of new mail is essential.  Without
firetray, Thunderbird pops up a small window in a corner of one of monitors
then hides it after a few seconds -- if you're away from the screen or even
not looking at that particular monitor at that moment, you don't know you
have new, potentially urgent, mail.


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.8+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru firetray-0.6.1+dfsg/debian/changelog 
firetray-0.6.1+dfsg/debian/changelog
--- firetray-0.6.1+dfsg/debian/changelog2016-05-04 22:45:17.0 
+0200
+++ firetray-0.6.1+dfsg/debian/changelog2018-09-17 12:36:49.0 
+0200
@@ -1,3 +1,12 @@
+firetray (0.6.1+dfsg-1+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix for Thunderbird 60 (by Fritjof Toelstede, Gabriele, and me).
+Closes: #906852, #895451.
+  * Firefox and Iceweasel are no longer supported.
+
+ -- Adam Borowski   Mon, 17 Sep 2018 12:36:49 +0200
+
 firetray (0.6.1+dfsg-1) unstable; urgency=medium
 
   [ foudfou ]
diff -Nru firetray-0.6.1+dfsg/debian/control firetray-0.6.1+dfsg/debian/control
--- firetray-0.6.1+dfsg/debian/control  2016-05-04 22:45:14.0 +0200
+++ firetray-0.6.1+dfsg/debian/control  2018-09-17 00:50:10.0 +0200
@@ -17,7 +17,9 @@
 Breaks: ${xpi:Breaks}
 Provides: ${xpi:Provides}
 Enhances: ${xpi:Enhances}
-Description: system tray extension for Firefox, Thunderbird, etc.
- FireTray is a system tray extension for Firefox and related
- applications. It supports setting up a custom icon, hiding to the tray
- instead of closing, displaying the number of unread mails, and more.
+Description: system tray extension for Thunderbird
+ FireTray is a system tray extension for Thunderbird.  It supports setting
+ up a custom icon, hiding to the tray instead of closing, displaying the
+ number of unread mails, and more.
+ .
+ FireFox and versions of Thunderbird prior to 57 are no longer supported.
diff -Nru 
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch 
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch
--- 
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch   
2016-05-04 22:45:39.0 +0200
+++ 
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch   
2018-09-09 12:40:48.0 +0200
@@ -6,11 +6,11 @@
  src/Makefile | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)
 
-diff --git a/src/Makefile b/src/Makefile
-index 512f2f7..ff81aed 100755
 a/src/Makefile
-+++ b/src/Makefile
-@@ -97,8 +97,6 @@ chrome_sources := $(chrome_sources_js)   
\
+Index: firetray-0.6.1+dfsg/src/Makefile
+===
+--- firetray-0.6.1+dfsg.orig/src/Makefile
 firetray-0.6.1+dfsg/src/Makefile
+@@

Re: Bug#873733: RFC: whitelist isa-support to allow it to abort installation?

[Adam Borowski]

On Mon, Sep 18, 2017 at 11:55:28AM +, Holger Levsen wrote:
> Dear release team,
> 
> I would like to ask you for your opinion on "#873733: please whitelist
> isa-support so it's allowed to fail piuparts testing" to prevent piuparts
> results from blocking isa-support's migration to testing. (See the (short)
> bug log for details.)
> 
> I still think that's the right thing to do (and thus to close #873733 as
> wontfix), but I also think it's up to you to decide, not the piuparts
> maintainers.

Actually, this doesn't block isa-support from migrating, it merely makes it
fail roughly half the time, as you apparently have more than one machine,
and only one has an inadequate CPU.  The last time this happened, it worked
well when retried elsewhere.

This particular binary, sse4.2-support, has not even been requested by
anyone in previous discussions; I added it merely because it makes testing
more convenient: x86 computers without sse4.2 are not a rarity (heck, this 6
years old AMD box I'm typing these words on has no 4.2) while pre-sse3 have
been purged even from storage closets by most people.

Thus, if you think so, I can drop this binary or Volkswagenize it.

So there are solutions for the piuparts testing that don't hassle its
maintainers.


The second question is: is Depends:isa-support the right solution for
software that requires above-baseline CPU extensions?  It has upsides and
downsides; in any case code common to such cases should be kept in one place
instead of being reinvented differently (like, chromium displays an xmessage
window then aborts while pcsx2 just SIGILLs).  This has been discussed twice
on debian-devel and it seemed this solution was favoured by those who
commented.  Since then, Adrian Bunk raised a different issue: that making
it too easy to violate baseline ISA risks fragmenting architectures.

That issue is worth discussing.  I wonder, should I describe use cases and
possible solutions here with the Release Team, or on a wider forum of
debian-devel or elsewhere?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Bug#865390: nmu: fonts-fantasque-sans_1.7.1~dfsg-1

[Adam Borowski]

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

Hi!
This font has some issues when built with fontforge 20120713, that have been
solved in 20160404.  All it takes is a clean rebuild against the version in
stretch or unstable.  Obviously, it's too late to do it for stretch (the bug
is nowhere near important enough), so let's do so for buster.

#827045 has the details, but you're probably too busy to bother reading. 
I tested a binNMU at home, it worked fine for me.

nmu fonts-fantasque-sans_1.7.1~dfsg-1 . ANY . unstable . -m "Rebuild with new 
fontforge (#827045)."


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-rc6-debug-00024-gff389e3ae048 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#851435: 0.11~beta4-1 -> 0.11-1

[Adam Borowski]

Control: retitle -1 unblock: duperemove/0.11-1

Hi!
On Jan 26 (ie, 10 days before the hard freeze) I've sponsor-uploaded Peter's
update, which replaces a beta with a regular upstream release, plus misc
changes to the packaging.  The rationale being, if you agree to let it pass,
we want the package to be in a good shape.

Dates of the uploads:
versionmaintainer   sponsored
0.11~beta4-1   2016.09.28   2016.12.24 (2¾+10 days before NEW freeze)
0.11-1 2016.12.31   2017.01.26 (10 days before hard freeze)
(I've intentionally delayed the latter, as having been eligible to pass NEW
makes is easier to argue an exception, followed by a regular upload without
bothering you -- but that's no longer an option.)


unblock duperemove/0.11-1


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#851435: unblock: duperemove/0.11~beta4-1

[Adam Borowski]

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

Hi!
Would it be possible to unblock duperemove for stretch?  It was uploaded 2¾
days before the 10-day deadline, but somehow it sat in NEW until now.  Yeah,
it's our fault -- the ITP was worked on by multiple non-DDs, with large gaps
between any actions; when I finally intervened and forced the issue it was
close to the deadline, and ftpmasters don't operate on a FIFO.

Multiple people expressed interest in this package; I for one use it
heavily.  Without it, those elebenty billion deduplicators we have in the
archive are mostly worthless -- all they can do is to notify the user or at
most hard- or symlink duplicates which tends to be a pretty bad idea
(modifying one of the copies tramples all others).  On the other hand, BTRFS
(since kernel 3.13) and XFS (experimentally in 4.9) have in-kernel support
for CoW shared extents.  That support needs an userspace tool.

Thus, it'd be nice if you allowed it in.


unblock duperemove/0.11~beta4-1

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.3+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#840378: another stable update

[Adam Borowski]

On Sun, Nov 13, 2016 at 05:42:57PM +, Adam D. Barratt wrote:
> On Mon, 2016-10-17 at 10:16 +0200, Salvatore Bonaccorso wrote:
> > JFTR, I'm perfectly fine if -- in case accepted by the SRM -- my
> > proposed debdiff just get squashed in in Mateusz upload, or if he
> > want's to do the upload. In fact I have X-Debbug-CC'ed on my first
> > request, just in case he would like to take over.
> 
> That sounds good, thanks; sorry for the delay in getting back to you
> both.
> 
> Please could someone prepare and test a package including both fixes,
> and send the debdiff to this report.

Mateusz already prepared a debdiff, it's in #841017; I've attached a copy.

It looks sane, and does build successfully on amd64, i386 and armhf.
I don't know anything about either bug so I don't know if the upload fixes
them, but as it's a simple merge I have no reason to suspect otherwise.
It's up to maintainer to do such tests, and I suspect it's already done.


-- 
A true bird-watcher waves his tail while doing so.
diff -Nru openbox-3.5.2/debian/changelog openbox-3.5.2/debian/changelog
--- openbox-3.5.2/debian/changelog  2014-10-25 14:39:18.0 +0200
+++ openbox-3.5.2/debian/changelog  2016-10-23 18:36:47.0 +0200
@@ -1,3 +1,17 @@
+openbox (3.5.2-8+deb8u1) jessie; urgency=medium
+
+  [ Mateusz Łukasik ]
+  * debian/control:
++  Add libxcursor-dev to B-D for fix load startup notifications.
+(Closes: #838326)
+
+  [ Salvatore Bonaccorso ]
+  * Add 808138_Replace-getgrent-with-getgroups.patch patch.
+Replace getgrent with getgroups for not enumerate all groups at startup.
+Thanks to Simon  (Closes: #808138)
+
+ -- Mateusz Łukasik   Sun, 23 Oct 2016 18:36:47 +0200
+
 openbox (3.5.2-8) unstable; urgency=high
 
   * debian/openbox.install:
diff -Nru openbox-3.5.2/debian/control openbox-3.5.2/debian/control
--- openbox-3.5.2/debian/control2014-09-23 11:08:38.0 +0200
+++ openbox-3.5.2/debian/control2016-10-15 13:59:38.0 +0200
@@ -6,7 +6,7 @@
  libxrender-dev, pkg-config, libglib2.0-dev, libxml2-dev (>= 2.6.0), perl, 
  libxt-dev, libxinerama-dev, libxrandr-dev, libpango1.0-dev, libx11-dev, 
  autoconf, automake (>= 1:1.11), python-xdg, libimlib2-dev, dh-autoreconf, 
- autopoint, librsvg2-dev, libxi-dev
+ autopoint, librsvg2-dev, libxi-dev, libxcursor-dev
 Standards-Version: 3.9.6
 Homepage: http://www.openbox.org
 Vcs-Browser: https://github.com/mati75/openbox-debian
diff -Nru 
openbox-3.5.2/debian/patches/808138_Replace-getgrent-with-getgroups.patch 
openbox-3.5.2/debian/patches/808138_Replace-getgrent-with-getgroups.patch
--- openbox-3.5.2/debian/patches/808138_Replace-getgrent-with-getgroups.patch   
1970-01-01 01:00:00.0 +0100
+++ openbox-3.5.2/debian/patches/808138_Replace-getgrent-with-getgroups.patch   
2016-10-23 18:36:04.0 +0200
@@ -0,0 +1,63 @@
+>From e0cb404f53c9b21a521ea2f14c8cd66fdfb68ea7 Mon Sep 17 00:00:00 2001
+From: Simon 
+Date: Tue, 15 Dec 2015 15:46:18 +0100
+Subject: [PATCH] Replace getgrent with getgroups. Fixes #5978.
+
+---
+ obt/paths.c | 34 +-
+ 1 file changed, 21 insertions(+), 13 deletions(-)
+
+diff --git a/obt/paths.c b/obt/paths.c
+index 25cb6b0..d526936 100644
+--- a/obt/paths.c
 b/obt/paths.c
+@@ -108,25 +108,33 @@ static void find_uid_gid(uid_t *u, gid_t **g, guint *n)
+ const gchar *name;
+ struct group *gr;
+ 
++gid_t gmain;
++unsigned int maininc;
++int i;
++
+ *u = getuid();
+ pw = getpwuid(*u);
+ name = pw->pw_name;
+ 
+-*g = g_new(gid_t, *n=1);
+-(*g)[0] = getgid();
+-
+-while ((gr = getgrent())) {
+-if (gr->gr_gid != (*g)[0]) { /* skip the main group */
+-gchar **c;
+-for (c = gr->gr_mem; *c; ++c)
+-if (strcmp(*c, name) == 0) {
+-*g = g_renew(gid_t, *g, ++(*n)); /* save the group */
+-(*g)[*n-1] = gr->gr_gid;
+-break;
+-}
++gmain = getgid();
++
++*n = getgroups(0, *g);
++*g = g_new(gid_t, *n);
++*n = getgroups(*n, *g);
++
++/* Check if the effective group ID of the calling process is already
++   included in the returned list. Add it otherwise. */
++maininc = 0;
++for (i = 0; i < *n; i++) {
++if ( (*g)[i] == gmain ) {
++maininc = 1;
++break;
+ }
+ }
+-endgrent();
++if (!maininc) {
++*g = g_renew(gid_t, *g, ++(*n));
++(*g)[*n-1] = gmain;
++}
+ 
+ qsort(*g, *n, sizeof(gid_t), gid_cmp);
+ }
+-- 
+2.1.4
+
diff -Nru openbox-3.5.2/debian/patches/series 
openbox-3.5.2/debian/patches/series
--- openbox-3.5.2/debian/patches/series 2014-08-22 22:32:09.0 +0200
+++ openbox-3.5.2/debian/patches/series 2016-10-23 18:36:04.0 +0200
@@ -11,3 +11,4 @@
 fix_rsvg_missing_include.patch
 update_pl_po.patch
 754207_use-scrot.patch

Bug#840378: #840378: another stable update

[Adam Borowski]

On Mon, Oct 17, 2016 at 08:34:05AM +0100, Adam D. Barratt wrote:
> On 2016-10-17 1:03, Adam Borowski wrote:
> >I see we have two different stable update attempts for openbox, both
> >versioned 3.5.2-8+deb8u1:
> >* NMU by Salvatore Bonaccorso fixing #808138
> >* maintainer upload by Mateusz Łukasik fixing #838326 (RFS #841017)
> >
> >I have no opinion about appropriateness of both updates, but as they seem
> >to be independent, combining them is trivial.  Could we have a word from
> >the SRMs as to whether both, or any, of these updates would be acked?
> 
> If you're more patient, sure. The older of the two requests appears to be
> less than a week old.

Yeah, my point is to avoid you having to do a full review just to have the
request amended.  It'd be nice to hear a preliminary response, in case one
of these bugs is going to be rejected.

And there's no hurry, it's not like the next point release is tomorrow...

> >I guess two updates in a single point release would be a bad idea, thus
> >there's a need to coordinate.
> 
> Two updates is fine, but would indeed need co-ordination as one would have
> to build on top of the other.

Ie, no gain over combining them into a single upload.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#840378: #840378: another stable update

[Adam Borowski]

Hi guys!

I see we have two different stable update attempts for openbox, both
versioned 3.5.2-8+deb8u1:
* NMU by Salvatore Bonaccorso fixing #808138
* maintainer upload by Mateusz Łukasik fixing #838326 (RFS #841017)

I have no opinion about appropriateness of both updates, but as they seem to
be independent, combining them is trivial.  Could we have a word from the
SRMs as to whether both, or any, of these updates would be acked?

I guess two updates in a single point release would be a bad idea, thus
there's a need to coordinate.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#822487: jessie-pu: package mathematica-fonts/17+deb8u1

[Adam Borowski]

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

Hi!
Mathematica-fonts is a downloader for a set of fonts from Wolfram.
The version in jessie wants upstream version 7, however, it's no longer
available on their website.  This makes the package uninstallable.
The proposed fix is to point the downloader to upstream version 10.

The debdiff is quite hefty, this includes changed sha512 sums and dropping
no longer provided Type1 fonts.

There are two unrelated changes:
* adopting the package (Maintainer: the Fonts Team, Uploader: me)
* missing dependency on wget (also RC)

Debdiff attached, but you probably prefer git:
ssh://git.debian.org/git/pkg-fonts/fonts-mathematica.git -b jessie
https://anonscm.debian.org/cgit/pkg-fonts/fonts-mathematica.git/log/?h=jessie

dget 
https://angband.pl/debian/pool/main/m/mathematica-fonts/mathematica-fonts_17+deb8u1.dsc


As the version in jessie is currently completely useless, if this update is
too big for stable please instead RM it.
diff -Nru mathematica-fonts-17/debian/README.Debian mathematica-fonts-17+deb8u1/debian/README.Debian
--- mathematica-fonts-17/debian/README.Debian	2010-03-26 04:54:21.0 +0100
+++ mathematica-fonts-17+deb8u1/debian/README.Debian	1970-01-01 01:00:00.0 +0100
@@ -1,26 +0,0 @@
-mathematica-fonts for Debian
--
-
-Installer of Mathematica Fonts.  It might help to use Mathematica from 
-a remote terminal.
-
-Important Note:
-When one starts Mathematica from remote machine, one will see an error 
-messages something as follows:
-
-xset:  bad font path element (#23), possible causes are:
-Directory does not exist or has wrong permissions
-Directory missing fonts.dir
-Incorrect font server address or syntax
-
-It seems Mathematica searches its fonts only in a predefined directory
-so one might do the following steps.
-
-1. mkdir -p /usr/local/Wolfram/Mathematica/7.0/SystemFiles/Fonts
-2. ln -s /usr/share/fonts/type1/mathematica /usr/local/Wolfram/Mathematica/7.0/SystemFiles/Fonts/Type1
-
-The directory depends on a version of Mathematica so please check
-a directory structure of Mathematica on a server and change the above
-directory correspondingly.
-
- -- Atsuhito KOHDA <ko...@debian.org>  Fri, 14 Mar 2008 10:39:25 +0900
diff -Nru mathematica-fonts-17/debian/changelog mathematica-fonts-17+deb8u1/debian/changelog
--- mathematica-fonts-17/debian/changelog	2014-10-22 08:46:55.0 +0200
+++ mathematica-fonts-17+deb8u1/debian/changelog	2016-04-25 00:28:58.0 +0200
@@ -1,3 +1,15 @@
+mathematica-fonts (17+deb8u1) jessie; urgency=medium
+
+  * Adopt the package.
+  * New upstream release (10).
++ Version 7 is no longer downloadable (closes: #789211)
++ Server-side fonts are no longer included (closes: #573479)
++ Neither is a copy of Bitstream Vera (closes: #670216)
+  * Drop README.Debian, it talked about type1 X integration.
+  * Add missing Depends: wget (closes: #817820).
+
+ -- Adam Borowski <kilob...@angband.pl>  Mon, 25 Apr 2016 00:06:16 +0200
+
 mathematica-fonts (17) unstable; urgency=medium
 
   * Updated Debconf Dutch translations.  Thanks to Frans Spiesschaert
diff -Nru mathematica-fonts-17/debian/control mathematica-fonts-17+deb8u1/debian/control
--- mathematica-fonts-17/debian/control	2012-09-25 02:22:53.0 +0200
+++ mathematica-fonts-17+deb8u1/debian/control	2016-04-25 00:28:58.0 +0200
@@ -1,13 +1,14 @@
 Source: mathematica-fonts
 Section: contrib/fonts
 Priority: extra
-Maintainer: Atsuhito KOHDA <ko...@debian.org>
+Maintainer: Debian Fonts Task Force <pkg-fonts-de...@lists.alioth.debian.org>
+Uploaders: Adam Borowski <kilob...@angband.pl>
 Build-Depends: debhelper (>= 7), po-debconf
 Standards-Version: 3.8.0
 
 Package: mathematica-fonts
 Architecture: all
-Depends: ${misc:Depends}, unzip
+Depends: ${misc:Depends}, unzip, wget
 Pre-Depends: debconf (>= 0.5) | debconf-2.0
 Provides: ttf-mathematica4.1
 Conflicts: ttf-mathematica4.1 (<< 9)
@@ -18,7 +19,7 @@
  Please note that it may fail if the web site no longer offers them for
  download.
  .
- This package will currently only install AFM, TTF, and Type1 fonts.
+ Only TTF fonts are available in this version.
 
 Package: ttf-mathematica4.1
 Architecture: all
diff -Nru mathematica-fonts-17/debian/dirs mathematica-fonts-17+deb8u1/debian/dirs
--- mathematica-fonts-17/debian/dirs	2012-07-13 06:45:59.0 +0200
+++ mathematica-fonts-17+deb8u1/debian/dirs	2016-04-25 00:28:58.0 +0200
@@ -1,3 +1,2 @@
 usr/share/mathematica-fonts
 usr/share/fonts/truetype/mathematica
-usr/share/fonts/type1/mathematica
diff -Nru mathematica-fonts-17/debian/md5-t1 mathematica-fonts-17+deb8u1/debian/md5-t1
--- mathematica-fonts-17/debian/md5-t1	2009-06-11 07:29:23.0 +0200
+++ mathematica-fonts-17+deb8u1/debian/md5-t1	1970-01-01 01:00:00.0 +0100
@@ -1,135 +0,0 @@
-488f5705a3

Bug#807639: nmu: clementine_1.2.3+git1354-gdaddbde+dfsg-1

[Adam Borowski]

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

nmu clementine_1.2.3+git1354-gdaddbde+dfsg-1 . ANY . unstable . -m "Rebuild 
against libechonest2.3"

Hi!
Due to a transition done wrong, clementine built against libechonest2.1
crashes on startup.  This could be fixed by re-uploading a working version
of echonest2.1, but as clementine is its only user, it'd be much less work
to simply transition to libechonest2.3 immediately.

Thus, please rebuild clementine.  I tested a local binnmu, it appears to work.

Related bugs: #807629, #807507.

Bug#769746: RM: lletters-media/0.1.9a-5

[Adam Borowski]

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

Hi!
Please remove lletters-media from jessie, it's a data package for lletters
which is not a part of jessie, with nil chances of being introduced.


-- 
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/20141116030415.19551.33625.report...@umbar.angband.pl

Re: Jessie Freeze - What is the next release name? (jessie+1)

[Adam Borowski]

On Sat, Nov 08, 2014 at 06:13:31PM +0100, Javier Barroso wrote:
  On Wed, Nov 05, 2014 at 11:56:49PM +, Jonathan Wiltshire wrote:
   The release team is pleased to announce that Debian 8.0 Jessie is
   frozen.

  I thought usually this type of announcement comes with next release
  name.
 
  I was going to update web site (later) and debian-reference package (in
  November) in proper timing.  Did I miss some announcement?
  (Too many init discussion posts )

 It would be useful to know it :
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766283

To prevent such problems in the future, what about choosing the names for
both zurg and zurg+1?  This way, the codename for zurg+1 would be known
during the whole zurg development cycle.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20141108180005.ga15...@angband.pl

Proposed release goal: UTF-8 support

[Adam Borowski]

Hi!

As previously (https://lists.debian.org/debian-devel/2013/08/msg00217.html)
discussed, I'd like to propose improving support for UTF-8.  All material
shipped with Debian should be encoded this way, or, for media with an opaque
format, as something capable of storing any Unicode character, without need
for any extra steps.

There are four sub-goals:

* user-accessible interfaces (GUI, stdin, stdout, stderr, command line,
  reading/writing plain-text files) should be able to pass through UTF-8
  data uncorrupted, by default
* UTF-8 should be properly displayed
* all filenames in Debian packages, binary and source, must use UTF-8
  (obviously, 7-bit ASCII satisfies this requirement)
* all text files shipped by Debian should be encoded in UTF-8

The wiki entry: https://wiki.debian.org/ReleaseGoals/utf-8

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


signature.asc
Description: Digital signature

Re: Roll call for porters of architectures in sid and testing

[Adam Borowski]

On Sun, Sep 01, 2013 at 09:33:51AM +0200, Niels Thykier wrote:
 roll-call

If ports not in unstable count, you can conditionally chalk me up for x32.
Conditionally, as I refuse to do so if I were the only official porter,
as I have little clue about the toolchain.

Thus, I'd be up for these:
   - test (most|all) packages on this architecture
   - triage arch-specific bugs
   - fix arch-related bugs
but not:
   - fix toolchain issues
   - maintain buildds

!DD, NM.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


signature.asc
Description: Digital signature

Re: Bug#640499: hardening, too

[Adam Borowski]

On Sat, Aug 18, 2012 at 01:04:42PM +0200, Cyril Brulebois wrote:
 Adam Borowski kilob...@angband.pl (18/08/2012):
  I just got bit by the lack of multiarch here (wine is broken on amd64
  if nvidia is involved), and wrote a multiarchification patch before
  realizing there's already one here.  It's redundant, except for one
  bit: since an upload is needed anyway
 
 given the intrusiveness of that patch [libxvmc/multiarch], I'm pretty
 sure it's going to be considered too late in the release cycle. I'm
 also pretty sure that we (release team) said that already for similar
 packages.

It stops a prominent package [wine] from working for a good part of users,
so that's quite a motivation.  It's your package, your call, of course.

 [cc: release team for other opinions.]

And theirs.

  you could just as well add the hardening flags (another release goal).
  It's a trivial change, but git am is still faster than doing that
  yourself...
 
 Thanks, but please note that requesting unrelated features in a given
 bug report isn't too nice.

I wanted to have them in one place, as both are release goals.

 BTW, you call it trivial but you lost -Wall…

Good point, that's not a case where hardening is really important too...
so scratch this part.



 Mraw,
Hell yeah, mraw!
 KiBi.
1KB (the real pre-committee 1024 :p).

-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


-- 
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/20120818135247.ga13...@angband.pl

accepted but not in unstable yet: crawl

[Adam Borowski]

Hi!

Somehow, even though crawl 2:0.7.1-3 has been uploaded and accepted on 9:02
this morning, it hasn't been picked up by either of the two dinstall runs
since then.  While buildds swiftly did their work and all arches except
hurd-i386 and -ports are already built, all the results (including several
2:0.7.1-2 builds from yesterday) are rotting in incoming.

-3 fixes two RC issues that were not properly marked at the time.  #591811
(FTBFS on powerpc due to a g++-4.4 bug) was closed by Guus Sliepen without
specifying the version (neither of us suspected it will matter) -- I've
amended that.  The other issue hasn't been reported in the BTS, but probably
no point in doing so since one RC bug is as good as two, as long as both are
fixed in the same version.

I've been told on IRC that even though the upload has been accepted seven
hours before the freeze announcement, it is the freeze-exceptions list
that matters, and thus I'm asking you to help rectify this.


Miaow!
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20100806193101.ga10...@angband.pl