Bug#1060287: awscli: new upstream (2.15.1) available

[Matt Barry]

Package: awscli
Version: 2.15.8-1
Severity: important
Tags: newcomer

I would have this as wishlist, but the current version in unstable
(2.14) fails to install because of a versioned dependency on python-
cryptography, is therefore unusable.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages awscli depends on:
ii  groff-base1.23.0-3
ii  python3   3.11.6-1
ii  python3-awscrt0.19.19+dfsg-1
ii  python3-colorama  0.4.6-4
ii  python3-cryptography  41.0.7-1
ii  python3-dateutil  2.8.2-3
ii  python3-distro1.9.0-1
ii  python3-docutils  0.20.1+dfsg-3
ii  python3-jmespath  1.0.1-1
ii  python3-prompt-toolkit3.0.43-1
ii  python3-pyasn10.4.8-4
ii  python3-ruamel.yaml   0.17.21-1
ii  python3-ruamel.yaml.clib  0.2.8-1
ii  python3-urllib3   1.26.18-1

awscli recommends no packages.

awscli suggests no packages.

-- no debconf information

Bug#1053415: ITP: vaticinator -- Python 'fortune' implementation/library

[Matt Barry]

Package: wnpp
Severity: wishlist
Owner: Matt Barry 
X-Debbugs-Cc: debian-de...@lists.debian.org, m...@hazelmollusk.org

* Package name: vaticinator
  Version : 0.0.4
  Upstream Contact: Matt Barry 
* URL : https://github.com/hazelmollusk/vaticinator
* License : MIT
  Programming Lang: Python
  Description : Python 'fortune' implementation/library

 The vaticinator package provides a Python reimplemention of the
 'fortune' program.  The 'vaticinator' command supports most/all
 of the functionality of the original; also provided is a
 library of reusable fortune cookie functionality.

Bug#1029829: Server connections refused after applying update?

[Barry Trent]

I applied this update to my one remaining buster machine and now it is 
refusing to connect to my bullseye-based amanda backup server.


amcheck and the amanda server are both reporting "Connection refused" 
when accessing the updated buster machine.


--
Barry A. Trent
952-829-5864, x109
barry.tr...@atcorp.com



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1008082: How to --lock an account

[Matt Barry]

On Wed, 2022-07-27 at 15:21 +0200, Marc Haber wrote:
> On Wed, Jul 27, 2022 at 09:12:50AM -0400, Jason Franklin wrote:
> For a normal user account, I am undecided whether:
> 
> - leave login shell intact, leaving a possible security hole
> - set login shell back to the default when the account gets reenabled
> - save login shell somewhere to reinstate if on reenabling.

Maybe have adduser prompt when using --unlock (and without -s) whether
to reset the shell to the default?  (just #2, but more explicit)

Then again a single colon-separated file to check *before* selecting
the default isn't a ton of added complexity.  

Contrary to the behavior of usermod(8), I personally think adding the
additional barrier to access is a feature.

> I'd say, do it as you see fit

Me too :)

mb


signature.asc
Description: This is a digitally signed message part

Bug#1012420: no_del_paths includes /srv?

[Matt Barry]

tags -1 + wontfix
thanks

On Fri, 2022-07-22 at 11:44 +0200, Marc Haber wrote:
> On Mon, Jun 06, 2022 at 03:26:24PM -0400, Matt Barry wrote:
> > AIUI /srv is under the purview of the sysadmin; if they decide to
> > set
> > DHOME somewhere under /srv, shouldn't this behave the same as with
> > /home?
> 
> I find it sensible that the default of no_del_path includes /srv. If
> the
> local admin decides to violate FHS by putting a user's home dir
> there,
> they can also change no_del_path. We have user's home directores in
> /var
> as well for a bunch of system users and we still have /var in
> no_del_path's default.

I just looked more carefully at the FHS, and it is clear you are
correct.  cf 3.17.1: "Distributions must take care not to remove
locally placed files in these directories without administrator
permission."  Tagging this wontfix.

Bug#1015803: gnome-control-center: Sound page has no "None" option for Alert Sound.

[Matt Barry]

Package: gnome-control-center
Version: 1:42.3-2
Severity: wishlist
Tags: upstream



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-1
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-1
ii  desktop-base  11.0.3
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:42.3-2
ii  gnome-desktop3-data   42.3-1
ii  gnome-settings-daemon 42.2-1
ii  gsettings-desktop-schemas 42.0-1
ii  libaccountsservice0   22.08.8-1
ii  libadwaita-1-01.2~alpha-1
ii  libc6 2.33-8
ii  libcairo2 1.16.0-6
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-1
ii  libcups2  2.4.2-1
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.4
ii  libgcr-base-3-1   3.41.1-1
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.3-1
ii  libgnome-bg-4-1   42.3-1
ii  libgnome-bluetooth-ui-3.0-13  42.1-1
ii  libgnome-desktop-4-1  42.3-1
ii  libgnome-rr-4-1   42.3-1
ii  libgnutls30   3.7.6-2
ii  libgoa-1.0-0b 3.44.0-1
ii  libgoa-backend-1.0-1  3.44.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.34-1
ii  libgtk-4-14.6.6+ds-1
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.26-4
ii  libkrb5-3 1.19.2-2+b2
ii  libmalcontent-0-0 0.10.5-1
ii  libmm-glib0   1.18.10-1
ii  libnm01.38.2-1
ii  libnma-gtk4-0 1.8.40-1
ii  libpango-1.0-01.50.7+ds-1
ii  libpangocairo-1.0-0   1.50.7+ds-1
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   15.0+dfsg1-4+b1
ii  libpulse0 15.0+dfsg1-4+b1
ii  libpwquality1 1.4.4-1+b1
ii  libsecret-1-0 0.20.5-2
ii  libsmbclient  2:4.16.3+dfsg-1
ii  libsnapd-glib11.60-1
ii  libudisks2-0  2.9.4-1
ii  libupower-glib3   0.99.20-1
ii  libwacom9 2.2.0-1
ii  libx11-6  2:1.7.5-1
ii  libxi62:1.8-1
ii  libxml2   2.9.14+dfsg-1

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-4
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.1-2
ii  gnome-online-accounts 3.44.0-1
ii  gnome-remote-desktop  42.3-1
ii  gnome-user-docs   42.0-1
ii  gnome-user-share  3.34.0-5
ii  iso-codes 4.10.0-1
ii  libnss-myhostname 251.3-1
ii  malcontent-gui0.10.5-1
ii  network-manager-gnome 1.28.0-1
ii  policykit-1   0.105-33
ii  power-profiles-daemon 0.11.1-1
ii  pulseaudio-module-bluetooth   15.0+dfsg1-4+b1
ii  realmd0.17.0-2
ii  rygel 0.40.4-1
ii  rygel-tracker 0.40.4-1
ii  system-config-printer-common  1.5.16-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   42.3-1
ii  gstreamer1.0-pulseaudio  1.20.3-1
ii  x11-xserver-utils7.7+9

-- no debconf information

Bug#1015781: autopkgtests fail if user foo exists or existed

[Matt Barry]

On Thu, 2022-07-21 at 08:27 +0200, Marc Haber wrote:
> Package: adduser
> Version: 3.122
> Severity: normal
> 
> The tests expect the test environment to be fresh. They relay too
> much
> on uids being the same and do not preseed adduser to provide
> reproducible uids.
> 
> Reproducer:
> - create test chroot
> - adduser --system foo
> - deluser foo
> - verify that foo is actually gone
> - run autopkgtests
> - see not just one test failing.

I have seen similar cases where running 'autopkgtest -- null' more than
inside a debspawn session fails; it ought to be idempotent.

mb

Bug#1015279: ITP: python-pywayland -- provides Python bindings to the Wayland library

[Matt Barry]

Package: wnpp
Severity: wishlist
Owner: Matt Barry 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-pywayland
  Version : 0.4.13
  Upstream Author : Sean Vig
* URL : https://pywayland.readthedocs.io/en/latest/
* License : Apache
  Programming Lang: Python
  Description : provides Python bindings to the Wayland library

PyWayland provides Python bindings to the Wayland library, using pure Python by
making calls through the CFFI module.

I plan to maintain this within the Python Team.

Bug#1015278: ITP: python-pywlroots -- Python binding to the wlroots library using cffi

[Matt Barry]

Package: wnpp
Severity: wishlist
Owner: Matt Barry 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-pywlroots
  Version : 0.15.18
  Upstream Author : Sean Vig
* URL : https://github.com/flacjacket/pywlroots
* License : UIUC (NCSA)
  Programming Lang: Python
  Description : Python binding to the wlroots library using cffi
 A Python binding to the wlroots library using cffi.
 The library uses pywayland to provide the Wayland
 bindings and python-xkbcommon to provide wlroots
 keyboard functionality.

Bug#1015267: ITP: qtile -- A full-featured, hackable tiling window manager written and configured in Python

[Matt Barry]

Package: wnpp
Severity: wishlist
Owner: Matt Barry 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: qtile
  Version : 0.21.0
  Upstream Author : Aldo Cortesi
* URL : https://www.qtile.org/
* License : MIT
  Programming Lang: Python
  Description : A full-featured, hackable tiling window manager written and
configured in Python

Simple, small and extensible. It's easy to write your own layouts, widgets and
commands.  Runs as an X11 WM or a Wayland compositor.  Command shell that
allows all aspects of Qtile to be managed and inspected.  Complete remote
scriptability - write scripts to set up workspaces, manipulate windows, update
status bar widgets and more.  Qtile's remote scriptability makes it one of the
most thoroughly unit-tested window managers around.

I plan to maintain this under the auspices of the Python Team.

Bug#1011572: ITA: toilet -- display large colourful characters in text mode

[Matt Barry]

retitle -1 ITA: toilet -- display large colourful characters in text mode
thanks

Bug#970146: still blocked

[Matt Barry]

block -1 by 1014974
thanks

Bug#1014974: python3-sybil: New sybil version 3.0.1

[Matt Barry]

Package: python3-sybil
Version: 3.0.1-1~exp1
Severity: normal

Hi,

I note that there is a 3.0.1 package in experimental, which I will start
looking at; mostly filing this so I can refer to it as a blocker.

Thanks!
Matt


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-sybil depends on:
ii  python3  3.10.4-1+b1

python3-sybil recommends no packages.

python3-sybil suggests no packages.

-- no debconf information

Bug#1014901: Home directories should not be setgid by default

[Matt Barry]

Hi Josh,

On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote:
> > > The more recent issue 643559 suggests that
> > > > Those "bad side-effects", if they were ever relevant and
> > > > important
> > > > enough to make personal groups not work properly, have now been
> > > > fixed.
> > > 
> > > However, this is not the case; this change does in fact have bad
> > > side-effects. This change breaks some common use cases that apply
> > > to
> > > users on many systems, both single-user and multi-user.
> > 
> > Can we please have more information than just "bad side-effects"?
> 
> The use case below, and any other tools that create files and know to
> set their permissions appropriately but don't expect unusual
> ownership
> by default:
> > > In particular, it is common to build various kinds of filesystem,
> > > container, or disk images, and to do so within your home
> > > directory.
> > > Users writing tools and scripts to build such images need to make
> > > sure
> > > to create files with an appropriate mode, but such scripts often
> > > assume
> > > (reasonably) that if they're running as root:root and they create
> > > a
> > > file, that file will be owned by root:root. Attempting to build
> > > filesystems, containers, disk images, or similar in an
> > > unexpectedly
> > > setgid directory will produce unexpected results (leaving aside
> > > that the
> > > directory mode itself will be surprising).

Could you be just slightly more specific about a use case that fails? 
Given how many times this has come up over the years, I'm trying to get
a sense of what the *actual* issues are (as opposed to what they used
to be).

Enough instruction that I can reproduce a specific problem(s) would be
great.

(If it makes sense to take this part to -devel, please feel free.)

> > 
> > Would it help to do this kind of work in a subdirectory under the
> > home
> > directory and making sure that one is not setgid? I am happy to
> > document
> > this.
> 
> That's certainly a workaround if you know it's a problem. On the
> other
> hand, it's likewise possible for anyone doing shared-work-directories
> on
> a multiuser system to create a directory that *is* setgid.
> 
> I fully acknowledge here that there's no one default that will make
> everyone happy, and that someone is going to end up needing to
> configure
> it. I'm attempting to make the case for what the default should be.
> 
> I'm also hoping to make a case for "this change is a surprise and a
> regression, and changing it *back* shouldn't have the burden of
> 'changing the default' but rather 'reverting this change and
> returning to the
> previous default'". But either way, I'm willing to make the case
> regarding the default itself.

The previous conversation on -devel would have been the best point at
which to identify this as a regression (or indeed, to document any
downsides).  My personal choice of defaults align with neither the
current nor the previous config; if it is to keep changing, the setting
should really have some consensus.

Cheers,
Matt

Bug#682156: groupdel performance

[Matt Barry]

On Thu, 2022-07-14 at 21:54 +0200, Marc Haber wrote:
> On Thu, Jul 14, 2022 at 03:00:50PM -0400, Matt Barry wrote:
> > Any objections to either moving this bug to passwd, or just
> > wontfix'ing
> > this?
> 
> No objection from me, I'd just reassign the bug. If we can do
> something
> to speed deletion up while having more pretty code, we should do that
> anyway though.

To make the test fast enough to be realistically runnable, I had to
replace even useradd/groupadd with direct writes to /etc/passwd et al.
So.. no prettier code to be had here. :(

We can do as suggested above and remove our own (arguably superfluous)
check, and take the minor performance win.

Bug#682156: groupdel performance

[Matt Barry]

Hi,

I have added a test to benchmark the deletion of groups on a system
with tens of thousands of users, and it is indeed (still) not great.

However, removing the overhead described in this bug (and replacing it
with *nothing*) only yields < 10-15% speed-up.

I would not be opposed to relying on the failure of userdel if it meant
a real boost, but I am tempted to say that this decade-old problem
might be better taken up with the passwd package.

Here is a snippet of the performance test output.  The times for
comparable groups are shown both for delgroup and for groupdel.

ok 2 - populated 1 groups in 4 seconds (< 120).
ok 3 - command success: /usr/sbin/delgroup --quiet dgpg_3
ok 4 - delgroup dgpg_3 took 8s (< 30).
ok 5 - command success: /usr/sbin/delgroup --quiet dgpg_
ok 6 - delgroup dgpg_ took 9s (< 30).
ok 7 - command success: /usr/sbin/delgroup --quiet dgpg_
ok 8 - delgroup dgpg_ took 11s (< 30).
ok 9 - command success: /usr/sbin/delgroup --quiet dgpg_9998
ok 10 - delgroup dgpg_9998 took 13s (< 30).
ok 11 - command success: /usr/sbin/groupdel dgpg_4
ok 12 - groupdel dgpg_4 took 11s (< 30).
ok 13 - command success: /usr/sbin/groupdel dgpg_3334
ok 14 - groupdel dgpg_3334 took 10s (< 30).
ok 15 - command success: /usr/sbin/groupdel dgpg_6667
ok 16 - groupdel dgpg_6667 took 11s (< 30).
ok 17 - command success: /usr/sbin/groupdel dgpg_
ok 18 - groupdel dgpg_ took 13s (< 30).

Any objections to either moving this bug to passwd, or just wontfix'ing
this?

Cheers,
Matt



signature.asc
Description: This is a digitally signed message part

Bug#1014450: usernames have a 32 character limit

[Matt Barry]

On Wed, 2022-07-13 at 23:09 +0200, Marc Haber wrote:
> On Wed, Jul 13, 2022 at 04:50:20PM -0400, Matt Barry wrote:
> > On Wed, 2022-07-13 at 22:44 +0200, Marc Haber wrote:
> > > On Wed, Jul 06, 2022 at 12:32:16PM +0200, Marc Haber wrote:
> > > > the useradd documentation says that a user name has a 32
> > > > character
> > > > limit. We should enforce this as well.
> > > 
> > > Matt, would you want to take a quick plunge at this as well?
> > > You're
> > > still deeply acquained with the entire name checking stuff
> > > anyway.
> > 
> > Sure.  There actually is a test for this, and it passes (ie. fails
> > in
> > every instance, for a 33 character name) - I think because useradd
> > fails?  We might as well check it though, I'll take a look.
> 
> If we are ok with erroring out with a useradd error message, and the
> output is not offensively ugly, I'm fine with that, and we can just
> close this bug as fixed in 3.122. I am not emotional about this.

I would apply that patch at some point; it isn't urgent, but it is
cleaner.

Bug#1014450: usernames have a 32 character limit

[Matt Barry]

On Wed, 2022-07-13 at 23:11 +0200, Marc Haber wrote:
> On Wed, Jul 13, 2022 at 04:50:20PM -0400, Matt Barry wrote:
> > There actually is a test for this, and it passes (ie. fails in
> > every instance, for a 33 character name)
> 
> Does it also fail reasonably prettily for a < 32 character UTF-8 name
> that is > 32 bytes when encoded?

(new patch)

/h/d/adduser $ sudo adduser 
adduser: Usernames must be no more than 32 bytes in length;
note that if you are using Unicode characters, the
character
limit will be less than 32.

In the 3.121, the IEEE check will squash it.
In 3.22: 

~/h/d/adduser $ sudo adduser  --allow-all-names
Allowing use of questionable username.
Adding user `' ...
Adding new group `' (1023) ...
groupadd: '' is not a valid group name
adduser: `/sbin/groupadd -g 1023 ' returned
error code 3. Exiting.

so, not ideal, but it does error.  

Bug#1014450: usernames have a 32 character limit

[Matt Barry]

On Wed, 2022-07-13 at 22:44 +0200, Marc Haber wrote:
> Hi,
> 
> On Wed, Jul 06, 2022 at 12:32:16PM +0200, Marc Haber wrote:
> > the useradd documentation says that a user name has a 32 character
> > limit. We should enforce this as well.
> 
> Matt, would you want to take a quick plunge at this as well? You're
> still deeply acquained with the entire name checking stuff anyway.

Sure.  There actually is a test for this, and it passes (ie. fails in
every instance, for a 33 character name) - I think because useradd
fails?  We might as well check it though, I'll take a look.

mb


signature.asc
Description: This is a digitally signed message part

Bug#678615: "users" group is empty

[Matt Barry]

On Tue, 2022-07-05 at 15:34 +0200, Marc Haber wrote:
> On Tue, Jul 05, 2022 at 09:07:11AM -0400, Matt Barry wrote:
> > On Tue, 2022-07-05 at 12:46 +0200, Marc Haber wrote:
> > > (1) Augment the USERS_GID with a USERS_GROUP setting, throwing a
> > > warning
> > >     if both are set.
> > > (2) Set the primary group of a new non-system user created with
> > >     USERGROUPS=no to the USERS_GID or the GID of the USERS_GROUP
> > > (3) Set USERS_GROUP or the Group that has USERS_GID as
> > > supplementary
> > >     group of newly created non-system users with USERGROUPS=yes
> > 
> > if USERS_GID and USERS_GROUP are empty, and USERGROUPS is no... the
> > user gets the "users" group as before?
> 
> If USERGROUPS is no, then currently the new user gets group 100,
> which
> is "users" as per base-passwd. USERS_GID is documented as having 100
> as
> default.

Yup, sounds good.

Bug#678615: "users" group is empty

[Matt Barry]

On Tue, 2022-07-05 at 12:46 +0200, Marc Haber wrote:
> (1) Augment the USERS_GID with a USERS_GROUP setting, throwing a
> warning
>     if both are set.
> (2) Set the primary group of a new non-system user created with
>     USERGROUPS=no to the USERS_GID or the GID of the USERS_GROUP
> (3) Set USERS_GROUP or the Group that has USERS_GID as supplementary
>     group of newly created non-system users with USERGROUPS=yes

if USERS_GID and USERS_GROUP are empty, and USERGROUPS is no... the
user gets the "users" group as before?

> 
> (The suggestion for USERS_GROUP comes from the fact that the primary
> group is set via GID and supplementary group is set via name. Don't
> we
> all love those twisted UNIX traditions?)

:)

mb

Bug#1014355: adduser: ADD_EXTRA_GROUPS does not work

[Matt Barry]

On Tue, 2022-07-05 at 12:34 +0200, Marc Haber wrote:
> The body of the bug report was empty, and I can not confirm the non
> working of the option.
> 

Apologies, this was filed in error, can be rejected.

Bug#1014355: adduser: ADD_EXTRA_GROUPS does not work

[Matt Barry]

Package: adduser
Version: 3.122~1
Severity: normal



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages adduser depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  passwd 1:4.11.1+dfsg1-2

adduser recommends no packages.

Versions of packages adduser suggests:
ii  cron4.1-0.1
ii  liblocale-gettext-perl  1.07-4+b2
ii  perl5.34.0-4

-- debconf information:
  adduser/homedir-permission: true
  adduser/title:

-- debsums errors found:
debsums: changed file /usr/share/man/man5/adduser.conf.5.gz (from adduser 
package)
debsums: changed file /usr/share/man/man8/adduser.8.gz (from adduser package)

Bug#1006941: checkname logic

[Matt Barry]

On Mon, 2022-07-04 at 08:54 +0200, Marc Haber wrote:
> Hi Matt,
> 
> thanks for checking this.
> 
> On Sun, Jul 03, 2022 at 09:16:49PM -0400, Matt Barry wrote:
> > 1st check: all-numeric, always rejected
> > 2nd check: ieee 1003.1-2001, minimal requirements [0]
> > 3rd check: user-configurable *NAME_REGEX
> > 4th: (possible override --allow-badname)
> 
> So the hardcoded
> if ($name !~ /^[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$/) {
> is the IEEE 1003.1-2001 check? Does it make sense to have this
> non-overridable?

I think there should be *some* non-overrideable minimum standard, if
only to keep unicode usernames out.  (which I suggest just because I
have no idea what could break.  I'm not a zealot for 1003.1-2001, but
its as good a line as any to draw.)  

> 
> While the error message is clear, how about having this at least in a
> variable like $ieee1003_regex?

Sure, that's easy enough.

> 
> 
> > The docs desribe --force-badname as "weak checks applied"; this
> > could
> > be clarified, but I don't think its urgent.
> 
> We have this in #774046, I planned to do some work o this myself.
> 
> > As I write this, the most confusing part is that there are three
> > separate checks for all-numeric names; I have a patch to simplify
> > this.
> 
> Thank you.
> 
> How deeply are we testing the username checks in the suite? I'd like
> the
> test suite to throw some corner cases on both sides of the red line
> at
> adduser and see whether it does what is intended.

Fairly basic (valid_username.t).  Tests a numeric username, tests a
dotted name with and without the configuration to pass it, tests
NAME_REGEX and SYS_NAME_REGEX.  More edge cases could certainly be
added here.

Cheers,
Matt


signature.asc
Description: This is a digitally signed message part

Bug#1006941: checkname logic

[Matt Barry]

The logic as it is now is fairly straightforward:

1st check: all-numeric, always rejected
2nd check: ieee 1003.1-2001, minimal requirements [0]
3rd check: user-configurable *NAME_REGEX
4th: (possible override --allow-badname)

The docs desribe --force-badname as "weak checks applied"; this could
be clarified, but I don't think its urgent.

As I write this, the most confusing part is that there are three
separate checks for all-numeric names; I have a patch to simplify this.

Cheers,
Matt

[0] this ties us to ascii mostly alpha-num usernames, obviously.  I
think it is okay to have a sanity check hard-coded to limit user's
creativity here, at least until we support anything wider.


signature.asc
Description: This is a digitally signed message part

Bug#815038: sounds

[Matt Barry]

Oops.. real file.
sound/boss/ant_lion/earthquake
sound/boss/ant_lion/eat
sound/boss/armour_boss/clang
sound/boss/armour_boss/die
sound/boss/armour_boss/growl
sound/boss/armour_boss/saw_spin
sound/boss/armour_boss/saw_start
sound/boss/armour_boss/saw_stop
sound/boss/armour_boss/tongue_hit  NOT FOUND
sound/boss/armour_boss/tongue_start  NOT FOUND
sound/boss/awesome_boss/hadouken
sound/boss/azriel/azriel_die
sound/boss/azriel/azriel_lightning_cage
sound/boss/azriel/azriel_scythe_throw
sound/boss/black_book/page
sound/boss/blob_boss/bounce
sound/boss/blob_boss/plop
sound/boss/borer_boss/breathe_in
sound/boss/boulder_boss/roll  NOT FOUND
sound/boss/chaos/breathe_fire
sound/boss/chaos/breathe_in  NOT FOUND
sound/boss/chaos/die
sound/boss/fly_boss/buzz  NOT FOUND
sound/boss/fly_boss/fly_boss_bullet
sound/boss/gargoyle/gargoyle_create_lance
sound/boss/gargoyle/gargoyle_lance_stab
sound/boss/gargoyle/gargoyle_petrify
sound/boss/gargoyle/gargoyle_stone_to_flesh
sound/boss/gargoyle/petrify_shake
sound/boss/grimlore/grimlore_beam
sound/boss/grimlore/grimlore_summon
sound/boss/grub_boss/death  NOT FOUND
sound/boss/grub_boss/fire
sound/boss/grub_boss/roar  NOT FOUND
sound/boss/mataeus/create_knife
sound/boss/mataeus/throw_knife
sound/boss/snake_boss/hiss  NOT FOUND
sound/boss/snake_boss/snake_boss_die
sound/boss/snake_boss/snake_boss_shot
sound/boss/sorceror/electrocute
sound/boss/sorceror/shield_die
sound/common/click
sound/common/crash
sound/common/crumble
sound/common/crunch
sound/common/dink
sound/common/door
sound/common/explosion
sound/common/freeze
sound/common/gib
sound/common/lava
sound/common/massive_explosion
sound/common/mine_lift
sound/common/pop
sound/common/punch  NOT FOUND
sound/common/rock_bounce
sound/common/rock_shatter  NOT FOUND
sound/common/shatter
sound/common/slime
sound/common/spell
sound/common/splash
sound/common/splat1
sound/common/splat2
sound/common/splat3
sound/common/switch
sound/common/teleport
sound/common/throw
sound/common/tick
sound/edgar/arrow
sound/edgar/block
sound/edgar/shield  NOT FOUND
sound/edgar/swing
sound/enemy/armadillo/armadillo_die
sound/enemy/bat/squeak
sound/enemy/bug/buzz
sound/enemy/ceiling_crawler/ceiling_crawler_die
sound/enemy/centipede/centipede_die
sound/enemy/centurion/centurion_die
sound/enemy/centurion/walk
sound/enemy/chicken/cluck
sound/enemy/fireball/fireball
sound/enemy/fire_burner/flame
sound/enemy/floating_snapper/burp
sound/enemy/floating_snapper/chomp
sound/enemy/frog/croak  NOT FOUND
sound/enemy/gazer/flap
sound/enemy/gazer/flash
sound/enemy/gazer/gazer_die
sound/enemy/gazer/growl
sound/enemy/ghost/ghost
sound/enemy/giant_snowball/crumble
sound/enemy/ground_spear/spear
sound/enemy/grub/grub_die
sound/enemy/icicle/smash
sound/enemy/jumping_slime/baby_jump1
sound/enemy/jumping_slime/baby_jump2
sound/enemy/jumping_slime/hatch
sound/enemy/jumping_slime/jump1
sound/enemy/jumping_slime/jump2
sound/enemy/jumping_slime/slime_die
sound/enemy/laser/zap
sound/enemy/mouth_stalk/hiss  NOT FOUND
sound/enemy/pendulum/swing
sound/enemy/rampaging_master_tortoise/stomp
sound/enemy/red_grub/spin  NOT FOUND
sound/enemy/red_grub/thud
sound/enemy/red_sludge/acid
sound/enemy/skeleton/skeleton_die
sound/enemy/skeleton/skeleton_resurrect
sound/enemy/sludge/sludge_die
sound/enemy/snail/snail_die
sound/enemy/snail/spit  NOT FOUND
sound/enemy/spider/spider
sound/enemy/spirit/spirit_explode
sound/enemy/spirit/spirit_scream
sound/enemy/splitter/splat
sound/enemy/thunder_cloud/lightning
sound/enemy/tortoise/tortoise_die
sound/enemy/tortoise/tortoise_electric
sound/enemy/wasp/wasp_die
sound/enemy/whirlwind/ricochet  NOT FOUND
sound/enemy/whirlwind/suck
sound/enemy/whirlwind/whirlwind_die
sound/item/blender
sound/item/block_beep
sound/item/burst
sound/item/buzzer
sound/item/chain
sound/item/charge_beep
sound/item/chop
sound/item/cork
sound/item/crack
sound/item/crossbow  NOT FOUND
sound/item/fill_potion
sound/item/force_field_shutdown  NOT FOUND
sound/item/fuse
sound/item/generator  NOT FOUND
sound/item/inflate
sound/item/magnet  NOT FOUND
sound/item/number_block
sound/item/ping
sound/item/rift
sound/item/spray
sound/item/spring
sound/item/striker_top  NOT FOUND
sound/item/tesla_electrocute
sound/item/trap_close
sound/item/tuning_fork

Bug#815038: sounds

[Matt Barry]

Attached is a report of sound files that are referenced in the source
(see below for how it was created).

I will report this issue upstream.

for i in `grep 'playSoundToMap("' src -R | sed -e
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`; do echo -n $i; if [
! -f $i ]; then echo -n "  NOT FOUND"; fi; echo ""; done > sounds.txt
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/ant_lion/earthquake]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/ant_lion/eat]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/clang]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/die]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/growl]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/saw_spin]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/saw_start]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/saw_stop]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/tongue_hit]0;[ ! -f $i ]]0;echo -n "  NOT FOUND"  
NOT FOUND]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/armour_boss/tongue_start]0;[ ! -f $i ]]0;echo -n "  NOT 
FOUND"  NOT FOUND]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/awesome_boss/hadouken]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/azriel/azriel_die]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/azriel/azriel_lightning_cage]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/azriel/azriel_scythe_throw]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/black_book/page]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/blob_boss/bounce]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/blob_boss/plop]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/borer_boss/breathe_in]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/boulder_boss/roll]0;[ ! -f $i ]]0;echo -n "  NOT FOUND"  NOT 
FOUND]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/chaos/breathe_fire]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/chaos/breathe_in]0;[ ! -f $i ]]0;echo -n "  NOT FOUND"  NOT 
FOUND]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/chaos/die]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/fly_boss/buzz]0;[ ! -f $i ]]0;echo -n "  NOT FOUND"  NOT 
FOUND]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 
$isound/boss/fly_boss/fly_boss_bullet]0;[ ! -f $i ]]0;echo ""
]0;for i in `grep 'playSoundToMap("' src -R | sed -e 
's/.*playSoundToMap("\([^,"]*\)".*/\1/'|sort|uniq`]0;echo -n 

Bug#1014156: svg?

[Matt Barry]

Looking at the check, it seems there is an exemption for SVG files
built in; would it make any sense to search for a text/* mime type
instead (ala libfile-libmagic-perl)?

Cheers,
Matt

Bug#832116: music assets

[Matt Barry]

Hello!

I am looking at the possibility of getting edgar updated and back into
the archive, which obviously involves this bug.

I don't desperately want to dredge up an entirely old discussion, so
I'll just document my starting point here.  My working assumption is 
that existing practice reflects more or less the correct interpretation
of the relevant documents; there are still plenty of games in the
archive with unsourced ogg files.  Fwiw, [0] is roughly my
interpretation; however, the disagreement over this has been going on
for many years; if anyone feels it needs to be relitigated, my humble
suggestion is that you migrate that discussion to one of the mailing
lists.  (You may assume I am subscribed.)

With regard to the actual bug report:

- medcine.ogg is correctly attributed upstream now
- I have reached out to Johan Brodd, requesting a) source, or b) dual
licensing options.. will give it a bit to see if he responds.
- If we cannot reach the author, I believe the next step is to approach
upstream; they are redistributing the file incorrectly as well.

If I have misunderstood anything so far, kindly let me know; again,
larger questions of non-programmatic works really need a larger
audience than a bug report.

Cheers,
Matt

[0] https://lists.debian.org/debian-devel/2014/03/msg00301.html


signature.asc
Description: This is a digitally signed message part

Bug#1014117: RFS: edgar/1.35-1 [ITA] -- Legend of Edgar platform game

[Matt Barry]

Package: sponsorship-requests
Severity: normal

Greetings mentors!

I am looking for a sponsor for my package "edgar":

 * Package name: edgar
   Version : 1.35-1
   Upstream Author : Richard Sweeney 
 * URL : http://www.parallelrealities.co.uk/games/edgar/
 * License : GPL-2.0+
 * Vcs : https://salsa.debian.org/games-team/edgar
   Section : games

The source builds the following binary packages:

  edgar - Legend of Edgar platform game
  edgar-data - Data files for Legend of Edgar game

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/edgar/

Alternatively, you can download the package with 'dget' using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/e/edgar/edgar_1.35-1.dsc

Changes since the last upload:

 edgar (1.35-1) unstable; urgency=medium
 .
   * New upstream release (1.35).
   * New maintainer.  Closes: #998116.
   * URL updates.  Closes: #1013412.
   * Various Lintian updates.
   * Update and drop patches.

Cheers,
-- 
  Matt Barry


signature.asc
Description: This is a digitally signed message part

Bug#1001208:

[Matt Barry]

Confirmed by Slack support; you need to get the package directly from
Slack.

Bug#970146: blocked

[Matt Barry]

block -1 by 1014067
thanks

Bug#1014067: RFP: python-pdm -- next generation Python package management tool

[Matt Barry]

Package: wnpp
Severity: wishlist

* Package name: python-pdm
  Version : 1.15.4
  Upstream Author : frostming 
* URL : https://github.com/pdm-project/pdm
* License : MIT
  Programming Lang: Python
  Description : next generation Python package management tool

(from the site)
PDM is meant to be a next generation Python package management tool.  It was
originally built for personal use. If you feel you are going well with Pipenv
or Poetry and don't want to introduce another package manager, just stick to
it. But if you are missing something that is not present in those tools, you
can probably find some goodness in pdm.

This package includes a PEP517 backend that is required for packaging
pyproject.toml style modules.

Bug#983405: concurrency

[Matt Barry]

On Wed, 2022-06-29 at 11:13 +0200, Marc Haber wrote:
> On Tue, Jun 28, 2022 at 01:34:23PM -0400, Matt Barry wrote:
> > Good call.  I've attached a minimal POC, which works in manual
> > testing,
> > but automated testing is tricky and there may be edge cases.  (This
> > test is blocking; NB (erroring out) might be easier to test, but
> > which
> > is the better UX?)
> 
> A minimal test would be the test taking the lock, calling out to
> adduser
> and seeing whether it fails. The other side (testing whether adduser
> properly takes the lock) is probably harder.

I was thinking the same thing; this too is easier to test if adduser's
behavior is non-blocking (ie. fail instead of wait).  Is that the
desired response?

mb

Bug#983405: concurrency

[Matt Barry]

tags -1 patch

On Mon, 2022-06-27 at 22:02 +0200, Marc Haber wrote:
> 
> /run/adduser please, and probably a simple flock()? lock files in a
> shell script are a minefield for code running as root, I hope it is
> easier in perl.

Good call.  I've attached a minimal POC, which works in manual testing,
but automated testing is tricky and there may be edge cases.  (This
test is blocking; NB (erroring out) might be easier to test, but which
is the better UX?)

mb
diff --git a/AdduserCommon.pm b/AdduserCommon.pm
index ffb8bac..2330d3a 100644
--- a/AdduserCommon.pm
+++ b/AdduserCommon.pm
@@ -12,11 +12,14 @@
 
 
 use File::Basename;
+use Fcntl qw(:flock SEEK_END);
 
 use constant PROGNAME => basename($0);
 
 use vars qw(@EXPORT $VAR1);
 
+my $lockfile;
+
 @EXPORT = (
 'dief',
 'get_group_members',
@@ -280,6 +283,17 @@ sub preseed_config {
   }
 }
 
+BEGIN {
+open($lockfile, '>>', '/run/adduser') or dief "could not open lock file %s!\n", '/run/adduser';
+flock($lockfile, LOCK_EX) or dief "could not lock file %s!\n", '/run/adduser';
+seek($lockfile, 0, SEEK_END) or dief "could not seek - %s!\n", '/run/adduser';
+}
+
+END {
+flock($lockfile, LOCK_UN) or dief "could not unlock file %s - %s!\n", '/run/adduser', "$!";
+close($lockfile) or dief "could not close lock file %s - %s!\n", '/run/adduser', "$!";
+}
+
 # Local Variables:
 # mode:cperl
 # End:

Bug#983405: concurrency

[Matt Barry]

The simplest way I can think of to solve this is:

(start)
mkdir /tmp/adduser.lock
sleep and loop until mkdir succeeds

(end)
remove /tmp/adduser.lock

which should be atomic assuming a local /tmp.

One could possibly add a /tmp/adduser.lock/adduser.pid and check for a
dead lock.. I hesitate to overcomplicate this one (and certainly don't
want a dependency for it).

Thoughts?

Bug#675804: patch

[Matt Barry]

tags -1 patch
thanks

Bug#926262: patch

[Matt Barry]

tags -1 patch
thanks

Bug#1013321: aideinit segfault on bullseye

[Barry Trent]

Indeed, installing aide-dynamic instead of aide appears to fix the problem.

Thank you.

On 6/21/22 2:04 PM, Marc Haber wrote:

On Tue, Jun 21, 2022 at 10:59:46AM -0500, Barry Trent wrote:

aide-dynamic is not installed.


You should use aide-dynamic. The statically linked binary is broken on
bullseye.

See
https://salsa.debian.org/debian/aide/-/blob/master/debian/aide-common.README.Debian
"aide no longer statically linked" from the testing distribution.

Greetings
Marc



--
Barry A. Trent
952-829-5864 x109
barry.tr...@atcorp.com


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1013321: aideinit segfault on bullseye

[Barry Trent]

Package: aide
Version: 0.17.3-4+deb11u1
Severity: normal
X-Debbugs-Cc: barry.tr...@atcorp.com

Dear Maintainer,

I upgraded a host which functions as a samba active directory controller from 
buster to bullseye. aideinit fails with a segfault:

root@atc-hq-dc2:~# aideinit
Running aide --init...
Segmentation fault
AIDE --init return code 139

Syslog shows:

Jun 20 11:33:28 atc-hq-dc2 kernel: [239549.685035] aide[153613]: segfault at 4 
ip 7fe6593ab350 sp 7ffcf4aa4800 error 4 in 
libnss_systemd.so.2[7fe6593aa000+25000]
Jun 20 11:33:28 atc-hq-dc2 kernel: [239549.685041] Code: 01 89 90 04 00 00 00 
eb e8 b8 b5 ff ff ff 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 08 48 8d 3d 
5d 2c 03 00 e8 70 f
0 ff ff <8b> 80 04 00 00 00 85 c0 0f 95 c0 48 83 c4 08 c3 48 81 ec d8 00 00

I found someone with similar problems googling, but the suggestion here to 
purge and re-install aide makes no difference -- same failure.

https://bugs.launchpad.net/ubuntu/+source/aide/+bug/1920649

aide-dynamic is not installed.

Interesting that I've upgraded at least 10 of our machines in the last month 
or so and this is the first I have seen this problem. Let me know what further
info I can provide to help.

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-15-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

aide depends on no packages.

Versions of packages aide recommends:
ii  aide-common  0.17.3-4+deb11u1

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

Bug#768073: "ping!"

[Matt Barry]

On Fri, 2022-06-17 at 12:57 +, Mathias Gibbens wrote:
>   The final thing that's been preventing upload of LXD is an issue
> that
> was found with a filename conflict with the lxc packaging (#1010843).
> I
> neglected to block this bug by that one, but just did so.
> 
>   The good news is that a new version of lxc with that fix was just
> released, so hopefully the lxc packages can get updated after which
> I'll be requesting an upload of LXD to NEW. :)

That's great news!  I noticed the --force-overwrite.. otherwise though,
I've been using it to run autopkgtests and it worked great (right up
until zfs broke in unstable ;).

Thanks for your work!

Matt



signature.asc
Description: This is a digitally signed message part

Bug#1001208:

[Matt Barry]

Just for the record, here is the response I received:
--

Hi there,

Thank you for reaching out.

We’re looking into this and will get back to you.

Thank you for your patience.

Best,

Lauren | (She/Her)
Customer Experience, Slack Support

Bug#573407: ita

[Matt Barry]

retitle -1 ITA: blackbox -- Window manager for X
thanks

Bug#564018: ita

[Matt Barry]

retitle -1 ITA: purity -- Automated purity testing software
thanks

Bug#1001208: non-distributable

[Matt Barry]

tags -1 + wontfix
thanks

Hello,

I have submitted an inquiry to Slack to clarify, but it doesn't appear
that there are any rights to redistribute this software.  They already
offer a .deb (as well as a snap) - afaict you will have to download it
directly from them.

Cheers,
Matt

Bug#998116: ita

[Matt Barry]

retitle -1 ITA: edgar -- 2D platform game with a persistent world
thanks

Bug#971356: ita

[Matt Barry]

retitle -1 ITA python-redmine -- Python library for the Redmine RESTful API 
(Python 3)
thanks

Bug#970146: ita

[Matt Barry]

retitle -1 ITA: python-public -- @public decorator for adding names to __all__
thanks

Bug#1012600:

[Matt Barry]

found 1012600 2.1.4-1
thanks

Module compilation (5.18) stalls for 10-15 minutes, then errors out. 
Make log attached.
DKMS make.log for zfs-2.1.4 for kernel 5.18.0-1-amd64 (x86_64)
Thu Jun 16 12:05:46 PM EDT 2022
make  all-recursive
make[1]: Entering directory '/var/lib/dkms/zfs/2.1.4/build'
Making all in module
make[2]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module'
list='icp lua zstd'; for td in $list; do make -C $td; done
make[3]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module/icp'
mkdir -p api core spi io os algs algs/aes algs/edonr algs/modes algs/sha1 algs/sha2 algs/skein asm-x86_64 asm-x86_64/aes asm-x86_64/modes asm-x86_64/sha1 asm-x86_64/sha2 asm-i386 asm-generic
make[3]: Leaving directory '/var/lib/dkms/zfs/2.1.4/build/module/icp'
make[3]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module/lua'
mkdir -p setjmp
make[3]: Leaving directory '/var/lib/dkms/zfs/2.1.4/build/module/lua'
make[3]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module/zstd'
mkdir -p lib
make[3]: Leaving directory '/var/lib/dkms/zfs/2.1.4/build/module/zstd'
make -C /lib/modules/5.18.0-1-amd64/build  \
	  \
	M="$PWD"  O=/lib/modules/5.18.0-1-amd64/build CONFIG_ZFS=m modules
make[3]: Entering directory '/usr/src/linux-headers-5.18.0-1-amd64'
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/avl/avl.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-atomic.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lapi.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/nvpair.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/illumos-crypto.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/unicode/u8_textprep.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/abd.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/cityhash.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-condvar.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_cipher.o
  LD [M]  /var/lib/dkms/zfs/2.1.4/build/module/avl/zavl.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfeature_common.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/aggsum.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zstd/zfs_zstd.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-cred.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_comutil.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lauxlib.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/arc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_digest.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-err.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/fnvpair.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zstd/lib/zstd.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/unicode/uconv.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-generic.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_deleg.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lbaselib.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_mac.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/nvpair_alloc_spl.o
  LD [M]  /var/lib/dkms/zfs/2.1.4/build/module/unicode/zunicode.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lcode.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-kmem.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/nvpair_alloc_fixed.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_fletcher.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-kmem-cache.o
  LD [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/znvpair.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-kstat.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_miscapi.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-proc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lcompat.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lcorolib.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_fletcher_superscalar.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lctype.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/ldebug.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-procfs-list.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_fletcher_superscalar4.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_namecheck.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_ctxops.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/ldo.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lfunc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lgc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/blkptr.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-taskq.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/llex.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lmem.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/bplist.o
  CC [M]  

Bug#866825: fspy

[Matt Barry]

Hello Dalibor,

Several years ago you expressed interest in adopting the fspy package;
are you still interested in working on this?

Cheers,
Matt


signature.asc
Description: This is a digitally signed message part

Bug#896916: patch

[Matt Barry]

tags -1 + patch
thanks

Salsa PR 27 - implements the strategy Marc describes above.

Bug#768073: "ping!"

[Matt Barry]

Hi,

I imagine I arrived at this bug the same way a lot of folks did, trying
to sleuth out the reason why (e.g.) autopkgtest-build-lxd is broken in
Debian.. but perhaps I might be the first that read all the way to the
end to find a repo that builds somewhat working packages!  Kudos and
thanks!

What is the state of the packages at the moment?  Are there any areas
that need help or testing?  (I'm not a go expert, but happy to help out
if I can.)

Cheers,
Matt


signature.asc
Description: This is a digitally signed message part

Bug#896916:

[Matt Barry]

On Fri, 2022-06-10 at 12:13 +0200, Marc Haber wrote:
> On Thu, Jun 09, 2022 at 05:58:28PM -0400, Matt Barry wrote:
> > (TIL: the reverse of --auto-compress is on by default; 'tar [tx]f'
> > will
> > automatically determine the right algorithm.)
> 
> And -THAt- cannot be disabled, see #1012571.

Yeah, initially I tried doing something like that :)

Bug#896916:

[Matt Barry]

On Thu, 2022-06-09 at 19:57 +0200, Marc Haber wrote:
> 
> I'd recommend the following:
> 
> - invoke tar --create --auto-compress --file /tmp/foo.tar.suffix
>   --directory / usr/sbin/deluser
> - if exit code 127 (compressor known, but not installed):
>   - print diagnostic
>   - set suffix to ".gz" (gzip is essential and guaranteed to exist)
> - if exit code != 127
>   - invoke tar --create --file /tmp/foo.tar
>     --directory / usr/sbin/deluser
>   - check whether foo.tar and foo.tar.sufffix are identical (that
>     happens when the tar file suffix does not match a known
> compressor)
>   - if identical (unknown compressor given)
>     - print diagnostic
>     - set suffix to ".gz"

This sounds good to me.  You could use something like 'file', but that
isn't essential iirc, and anyway this tests actual functionality.  I'm
happy to implement this in a new branch.

(TIL: the reverse of --auto-compress is on by default; 'tar [tx]f' will
automatically determine the right algorithm.)


Matt

Bug#1008091: sgid_home

[Matt Barry]

Especially with the default mode already setgid (overriding this
setting), it doesn't really add anything anymore.

Bug#896916:

[Matt Barry]

On Wed, 2022-06-08 at 11:59 +0200, Marc Haber wrote:
> On Wed, Jun 08, 2022 at 12:34:14AM -0400, Matt Barry wrote:
> > tags -1 + confirmed patch
> > thanks
> 
> How about zstd and the other hip compressors?

Heh.  I was thinking about whether to bother with this one.  A couple
of factors:

* adding zstd in the same fashion will take ~ 2 minutes
* there are, imo, no additional algorithms worth considering, so it
isn't a bottomless well of feature requests
* I guess the ideal for users would be a config item that controls the
order of selection:

BACKUP_COMPRESS=xz gz zstd  # eg. would never try bzip2

I can't imagine it getting more complicated than that..

Cheers,
Matt

Bug#896916:

[Matt Barry]

tags -1 + confirmed patch
thanks

Bug#992163: deletion protection, failure detection

[Matt Barry]

tags -1 + confirmed patch
thanks

Thanks for the bug report!  There is a fix in the works for this issue;
I will update here when it's merged.

Cheers,
Matt

Bug#588872: EXCLUDE_FS_TYPES

[Matt Barry]

Hi folks,

So, I've pushed a more simple fix for these two bugs:

https://salsa.debian.org/debian/adduser/-/merge_requests/24

One thing that is unclear (and I could not find guidance in the
documentation) is what the intent towards mount points actually is.

For the moment, I have made --remove-all-files perform the same checks
as --remove-home:
* all mountpoint directories are pruned
* all no_del_paths matches are pruned

Since mountpoints are never touched, EXCLUDE_FS_TYPES becomes obsolete.

My sense is that this is not the best of intentions, eg. the one edge
case that has to be hard-coded (/home), but this is clearly not ideal
(see also [0]).

My first guess at an ideal interpretation:
* mount points of EXCLUDE_FS_TYPES are pruned
* mount points are traversed, but the dir itself not removed
* keep no_del_paths as is (including the above changes)

Thoughts?

Cheers,
Matt

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012420


signature.asc
Description: This is a digitally signed message part

Bug#588872: patch

[Matt Barry]

tags -1 + patch
thanks

Patch available on salsa.

Bug#1012420: no_del_paths includes /srv?

[Matt Barry]

Package: adduser
Severity: wishlist

AIUI /srv is under the purview of the sysadmin; if they decide to set
DHOME somewhere under /srv, shouldn't this behave the same as with
/home?

Cheers,
Matt


signature.asc
Description: This is a digitally signed message part

Bug#1011957: aideinit fails in amanda-server processing

[Barry Trent]

Yes. After applying this patch aideinit succeeds on all 3 machines I 
have it running on with amanda-server


On 5/31/22 5:13 AM, Hannes von Haugwitz wrote:

On Mon, May 30, 2022 at 09:46:30AM -0500, Barry Trent wrote:

Applied the patch and added some blank lines back to the disklist. Still
doesn't work.


Argh, I overlooked the missing -E flag for grep. Please try again.

diff --git a/debian/aide.conf.d/31_aide_amanda-server 
b/debian/aide.conf.d/31_aide_amanda-server
index 5750779..7604e0f 100755
--- a/debian/aide.conf.d/31_aide_amanda-server
+++ b/debian/aide.conf.d/31_aide_amanda-server
@@ -66,7 +66,7 @@ for configfile in $(find /etc/amanda -name amanda.conf ! 
-path '/etc/amanda/temp
  printf "@@define AMANDA_INDEXDIR %s\\n" "${AMANDA_INDEXDIR}"
  if [ -f "disklist" ]; then
while read -r host dev rest; do
-if echo "${host}" | grep -q '^\\(#.*\\)\\?$'; then continue; fi
+if echo "${host}" | grep -Eq '^(#.*)?$'; then continue; fi
  dev="$(echo "${dev}" | sed 's|[/:]|_|g;s|\\"||g')"
 if ! skip_multiline_dle; then
  printf "!/@@{AMANDA_INDEXDIR}/%s/%s/@@{YEAR4D}[0-9]{4}_[0123]\\.gz$ f\\n" 
"${host}" "${dev}"

Best regards

Hannes


--
Barry A. Trent
952-829-5864 x109
barry.tr...@atcorp.com


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1011957: aideinit fails in amanda-server processing

[Barry Trent]

Applied the patch and added some blank lines back to the disklist. Still 
doesn't work.


amalthea:~# patch /etc/aide/aide.conf.d/31_aide_amanda-server -i aide.patch
patching file /etc/aide/aide.conf.d/31_aide_amanda-server
Hunk #1 succeeded at 66 with fuzz 2.
amalthea:~# cd /etc/amanda/Trent/
amalthea:/etc/amanda/Trent# nano disklist
amalthea:/etc/amanda/Trent# aideinit
Overwrite existing /var/lib/aide/aide.db.new [Yn]?
Running aide --init...
  ERROR: /etc/aide/aide.conf.d/31_aide_amanda-server (stdout):13:28: 
error in rule '/var/lib/amanda/Trent/index///2022[0-9]{4}_[0123]\.gz$': 
invalid double slash (line: 
'!/@@{AMANDA_INDEXDIR}///@@{YEAR4D}[0-9]{4}_[0123]\.gz$ f')

AIDE --init return code 17


On 5/28/2022 2:10 PM, Hannes von Haugwitz wrote:

Hello Barry,

On Sat, May 28, 2022 at 11:34:44AM -0500, Barry Trent wrote:

Yes! Removing all blank (and "#" comment) lines from disklist solved the
problem on 3 different machines.

So you've found the issue but, of course, blanks and comments are valid in
the disklist and are even present in the disklist installed as a sample with
amanda-server in DailySet1. I had to remove the DailySet1 which was still
present on one machine to get aideinit to complete without the error.

Can you please apply the following patch and report back if it solves your
issue?

diff --git a/debian/aide.conf.d/31_aide_amanda-server 
b/debian/aide.conf.d/31_aide_amanda-server
index 5750779..78424eb 100755
--- a/debian/aide.conf.d/31_aide_amanda-server
+++ b/debian/aide.conf.d/31_aide_amanda-server
@@ -66,7 +66,7 @@ for configfile in $(find /etc/amanda -name amanda.conf ! 
-path '/etc/amanda/temp
  printf "@@define AMANDA_INDEXDIR %s\\n" "${AMANDA_INDEXDIR}"
  if [ -f "disklist" ]; then
while read -r host dev rest; do
-if echo "${host}" | grep -q '^\\(#.*\\)\\?$'; then continue; fi
+if echo "${host}" | grep -q '^(#.*)?$'; then continue; fi
  dev="$(echo "${dev}" | sed 's|[/:]|_|g;s|\\"||g')"
 if ! skip_multiline_dle; then
  printf "!/@@{AMANDA_INDEXDIR}/%s/%s/@@{YEAR4D}[0-9]{4}_[0123]\\.gz$ f\\n" 
"${host}" "${dev}"

Best regards

Hannes



--
Barry A. Trent
952-829-5864, x109
barry.tr...@atcorp.com



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1011957: aideinit fails in amanda-server processing

[Barry Trent]

Yes! Removing all blank (and "#" comment) lines from disklist solved the 
problem on 3 different machines.


So you've found the issue but, of course, blanks and comments are valid 
in the disklist and are even present in the disklist installed as a 
sample with amanda-server in DailySet1. I had to remove the DailySet1 
which was still present on one machine to get aideinit to complete 
without the error.


On 5/28/2022 9:46 AM, Hannes von Haugwitz wrote:

Hi Barry,

On Fri, May 27, 2022 at 04:29:54PM -0500, Barry Trent wrote:

*** disklist
zmoby.atcorp.com/   comp-root-tar

symposium.atcorp.com/   comp-root-tar
symposium.atcorp.com/bbbcomp-root-tar
moby.atcorp.com /   comp-root-tar
coelacanth.atcorp.com   /   comp-root-tar
sawfish.atcorp.com  /   comp-root-tar
sawfish.atcorp.com  /varcomp-root-tar

Is there an empty line in the disklist file? If so, can you please
remove this line and try again?

Best regards

Hannes



--
Barry A. Trent
952-829-5864, x109
barry.tr...@atcorp.com



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1011957: aideinit fails in amanda-server processing

[Barry Trent]

Package: aide
Version: 0.17.3-4+deb11u1
Severity: important
X-Debbugs-Cc: barry.tr...@atcorp.com

Dear Maintainer,

I upgraded two hosts which function as amanda backup servers from buster to 
bullseye and ran into issues running aideinit. It failed:

root@archive:~# aideinit
Overwrite existing /var/lib/aide/aide.db.new [Yn]?
Running aide --init...
  ERROR: /etc/aide/aide.conf.d/31_aide_amanda-server (stdout):15:25: error in 
rule '/etc/amanda/atc-hq/index///2022[0-9]{4}_[0123]\.gz$': invalid double 
slash (line: '!/@@{AMANDA_INDEXDIR}///@@{YEAR4D}[0-9]{4}_[0123]\.gz$ f')
AIDE --init return code 17

I worked around the problem by commenting out a small section of 
31_aide_amanda-server starting at line 65:

  AMANDA_INDEXDIR="$(amgetconf "${CONF}" indexdir)"
  AMANDA_INDEXDIR="${AMANDA_INDEXDIR#/}"
#
# Commented out by bat May 2022 at bullseye upgrade to
# prevent errors
#
#  if [ -n "${AMANDA_INDEXDIR}" ]; then
#printf "@@define AMANDA_INDEXDIR %s\\n" "${AMANDA_INDEXDIR}"
#if [ -f "disklist" ]; then
#  while read -r host dev rest; do
#if echo "${host}" | grep -q '^\\(#.*\\)\\?$'; then continue; fi
#dev="$(echo "${dev}" | sed 's|[/:]|_|g;s|\\"||g')"
#   if ! skip_multiline_dle; then
#printf 
"!/@@{AMANDA_INDEXDIR}/%s/%s/@@{YEAR4D}[0-9]{4}_[0123]\\.gz$ f\\n" "${host}" 
"${dev}"
#printf "/@@{AMANDA_INDEXDIR}/%s/%s$ d VarDir\\n" "${host}" "${dev}"
#   fi
#  done < disklist
#  MULTILINEDLE=0
#fi
#  fi
  AMANDA_CHANGERFILE="$(amgetconf "${CONF}" changerfile)"
  AMANDA_CHANGERDIR="${AMANDA_CHANGERFILE%changer}"

I've included my amanda.conf and disklist from one of the machines in this bug 
report:


*** disklist
zmoby.atcorp.com/   comp-root-tar

symposium.atcorp.com/   comp-root-tar
symposium.atcorp.com/bbbcomp-root-tar
moby.atcorp.com /   comp-root-tar
coelacanth.atcorp.com   /   comp-root-tar
sawfish.atcorp.com  /   comp-root-tar
sawfish.atcorp.com  /varcomp-root-tar


*** amanda.conf
# amanda.conf - sample Amanda configuration file. See amanda.conf(5) for 
# details

org  "ATC-HQ"   # your organization name for reports
mailto   "root" # space separated list of operators at your site
mailer  "/usr/bin/mail"
dumpuser "backup"   # the user to run dumps under

inparallel 4# maximum dumpers that will run in parallel
dumporder "sssS"# specify the priority order of each dumper
#   s -> smallest size
#   S -> biggest size
#   t -> smallest time
#   T -> biggest time
#   b -> smallest bandwitdh
#   B -> biggest bandwitdh
# try "BTBTBTBTBTBT" if you are not holding
# disk constrained

taperalgo first # The algorithm used to choose which dump image to send
# to the taper.
# Possible values: 
# [first|firstfit|largest|largestfit|smallest|last]
# Default: first. 
# first First in - first out.
# firstfit  The first dump image that will fit 
#   on the current tape.
# largest   The largest dump image.
# largestfitThe largest dump image that will fit 
#   on the current tape.
# smallest  The smallest dump image.
# last  Last in - first out.

displayunit "k" # Possible values: "k|m|g|t"
# Default: k. 
# The unit used to print many numbers.
# k=kilo, m=mega, g=giga, t=tera

netusage  8000 Kbps # maximum net bandwidth for Amanda, in KB per sec

dumpcycle 1 weeks   # the number of days in the normal dump cycle
runspercycle 5 # the number of amdump runs in dumpcycle days
# (4 weeks * 5 amdump runs per week -- just weekdays)
tapecycle 80 tapes  # the number of tapes in rotation
# 4 weeks (dumpcycle) times 5 tapes per week (just
# the weekdays) plus a few to handle errors that
# need amflush and so we do not overwrite the full
# backups performed at the beginning of the previous
# cycle

bumpsize 20 Mb  # minimum savings (threshold) to bump level 1 -> 2
bumppercent 20  # minimum savings (threshold) to bump level 1 -> 2
bumpdays 1  # minimum days at each level
bumpmult 4  # threshold = 

Bug#891748: all-numeric usernames

[Matt Barry]

Control: tags -1 patch

Hi!  I've added a patch[0] that rejects all-numeric usernames in
adduser.. feedback welcome!

Cheers,
Matt

[0] https://salsa.debian.org/debian/adduser/-/merge_requests/21

Bug#679746: system users @ /nonexistent

[Matt Barry]

Control: tags -1 patch

This patch [0] implements the default system user home dir as
/nonexistent.  Feedback welcome!

Cheers,
Matt

[0] https://salsa.debian.org/debian/adduser/-/merge_requests/20

Bug#1008081: SYS_DIR_MODE

[Matt Barry]

Control: tags -1 patch

Hi!  I've created a patch[0] which implements SYS_DIR_MODE as described
in this bug; any feedback is welcome!

One thing I just wanted to confirm: the default for regular accounts
*should* have setgid?  I only ask because this was previously
documented as causing issues (in adduser.conf.5).

Cheers!
Matt'

[0] https://salsa.debian.org/debian/adduser/-/merge_requests/19

Bug#1011313: RFS: python-decouple/3.6-3 -- Helps you to organize your Django/Flask settings

[Matt Barry]

Control: tags -1 - moreinfo

Thanks!  The fixed 3.6-1 files are up on mentors now.

~m

On Fri, 2022-05-20 at 11:27 +0200, Bastian Germann wrote:
> Control: reopen -1
> Control: tags -1 moreinfo
> 
> Am 20.05.22 um 11:17 schrieb Bastian Germann:
> > You have to make this a NMU, which means mentioning it in the
> > changelog and making the version 3.6-0.1.
> > However, you did not give the maintainer a chance to act on this.
> > Please file a bug asking for the new
> > version and when it is not acted upon in a month, come back with
> > your NMU and include a Closes: tag in
> > your changelog for that bug.
> 
> I did not see #986939. You have to close the ITA via your changelog.
> Please keep -1 revision as long as this is not sponsored.
> On reuploading please untag moreinfo.
> 

Bug#516285: y/n prompts

[Matt Barry]

tags #516285 patch
thanks

I've created a small patch that may address this issue; merge request
available here:

https://salsa.debian.org/debian/adduser/-/merge_requests/18

Cheers,
Matt


signature.asc
Description: This is a digitally signed message part

Bug#695188: Pong

[Matt Barry]

This bug is almost ten years old; a patch was added almost five years
ago.


signature.asc
Description: This is a digitally signed message part

Bug#1011313: RFS: python-decouple/3.6-3 -- Helps you to organize your Django/Flask settings

[Matt Barry]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-decouple":

 * Package name: python-decouple
   Version : 3.6-3
   Upstream Author : Henrique Bastos 
 * URL : https://github.com/henriquebastos/python-decouple
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/python-decouple
   Section : python

The source builds the following binary packages:

  python3-decouple - Helps you to organize your Django/Flask settings

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-decouple/

Alternatively, you can download the package with 'dget' using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-decouple/python-decouple_3.6-3.dsc

Or, the git repository (forked from the main branch):

  https://salsa.debian.org/zaharazod/python-decouple.git

Changes since the last upload:

 python-decouple (3.6-3) unstable; urgency=medium
 .
   * copyright fixes
   * lintian fixes
   * new upstream version (3.6)

Regards,
-- 
  Matt Barry

Bug#960634: nanopolish: FTBFS on ppc64el (as well as ppc64 and powerpc), enumerator conflict

[Barry Arndt]

Source: nanopolish
Version: 0.13.2-1
Severity: normal
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past) on arch ppc64el
 
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 5.4.0-3-powerpc64le (SMP w/80 CPU cores)

nanopolish FTBFS on ppc64el:
https://buildd.debian.org/status/fetch.php?pkg=nanopolish=ppc64el=0.13.2-1=1588529870=0
 



nanopolish-0.13.2/src/nanopolish_squiggle_read.h contains the following 
enumeration:
 
enum PoreType
{
PT_UNKNOWN = 0,
PT_R7,
PT_R9,
};
 
Enumerators PT_R7 and PT_R9 are both already defined elsewhere, which 
conflicts with this package and causes FTBFS in ppc64el.  (I'm not sure 
where PT_R7 and PT_R9 are already defined.  A quick grep of kernel source 
shows several in /usr/src/linux-xx/arch as well as /usr/lib.)
 
I verified that changing those names (PT_R7 and PT_R9) in the enumeration 
and corresponding code fixes the problem in ppc64el and allows it to build 
successfully.  Based on the build log files for ppc64 and powerpc, this 
change should fix FTBFS for those as well. 
 
I did not include a patch.  Since this problem could be fixed in several 
different ways, including the possibility of changing enumerator names, 
the maintainer might want it to match already established conventions.
 
A minor nit, removing the comma after PT_R9 would make the code a little 
more standard and match the rest of the enums in that .h file.
 
Barry Arndt
 

Bug#938027: python-pip: Python2 removal in sid/bullseye

[Barry Warsaw]

Hi Sandro.

Honestly, I have not contributed to Debian in a couple of years, and I don’t 
see that changing any time soon.  Best to contact Matthias, the Python Team, or 
just do whatever you think is best.

Cheers,
-Barry

> On Mar 13, 2020, at 12:32, Sandro Tosi  wrote:
> 
> On Fri, 30 Aug 2019 07:44:13 + Matthias Klose  wrote:
>> Package: src:python-pip
>> Version: 18.1-5
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
> 
> the only rdeps of `bin:python-pip` have been removed from testing, so
> it's probably time we drop this package too!
> 
> Carl, Barry: do you see anything wrong with this? what should we do
> about the -whl package? is it still required for something or can we
> drop it along with bin:python-pip? is it needed for anything
> py3k-related?
> 
> I would like to proceed quickly, ideally within a week.
> 
> thanks,
> Sandro



signature.asc
Description: Message signed with OpenPGP

Bug#866122: kernel resolution

[Barry Arndt]

For reference:
 
While debugging this very tricky problem, our kernel team found 2 separate 
but related bugs whose resolutions fix the problem outlined in this 
report.
 
The bug fixes both resulted in CVEs and have already been added to Linus' 
tree.  They are:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=fixes=a8318c13e79badb92bc6640704a64cc022a6eb97
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=fixes=8205d5d98ef7f155de211f5e2eb6ca03d95a5a60
 
The CVEs are:
https://security-tracker.debian.org/tracker/CVE-2019-15030
https://security-tracker.debian.org/tracker/CVE-2019-15031
 
One of the problems was introduced in 4.12, and the other in 4.15.
 
Barry

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Barry Arndt]

A few things:
 
I verified that this problem does not recreate on buster, as Ryan 
mentioned earlier, because of the disabling of lock elision in glibc.
 
I verified that this problem still exists on a Debian 9.8 base with 
upstream kernel 5.1.0-x, which contains up-to-date TM fixes.
 
Our kernel team is actively debugging this problem on upstream kernel 
5.2.0-rc5, and is in favor of disabling TM in Debian until this issue is 
resolved.
 
Thanks.
Barry

Bug#896843: FTBFS: incorrect CPPFLAG for powerpc*

[Barry Arndt]

Source: ctsim
Version: 6.0.2
Severity: serious
Tags: l10n patch
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

FTBFS of ctsim-6.0.2 on ppc64el reported from unicamp.

The build log reported:
g++: error: unrecognized command line option '-faltivec'; did you mean 
'-maltivec'

The correct flag for ppc64el (as well as powerpc*) is -maltivec.

I changed -faltivec in configure.ac to -maltivec as follows:

--- ctsim-6.0.2.orig/configure.ac
+++ ctsim-6.0.2/configure.ac
@@ -137,7 +137,7 @@ case $target_cpu in
 CXXFLAGS="$CXXFLAGS $CPUEXT_FLAGS $SIMD_FLAGS"
 ;;
 powerpc*)
-ARCH_OPTION="-fno-common -faltivec";;
+ARCH_OPTION="-fno-common -maltivec";;
 armv1*|armv2*|armv3*|armv4*|armv5*|armv6*)
 ARCH_OPTION="-ffast-math";;
 armv7*|armv8*)

I then ran autoconf.  After that, the package build properly.

This fix should also fix the FTBFS of ctsim on 
powerpc, powerpcspe, and ppc64.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.9.0-4-powerpc64le (SMP w/80 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#470939: ok

[Eric Barry]

-message -
From: Eric Barry <barryeri...@gmail.com>
Date: Thu, Apr 5, 2018 at 5:04 AM
Subject: ok
To:

Bug#870909: RFS: cxlflash/4.3.2493-1 [ITP] -- IBM Data Engine for NoSQL Software Libraries

[Barry Arndt]

Mentors,

I am picking up work on this package.  I'm working through the issues 
already outlined to make sure they are resolved and all questions are 
answered.

Once that is done, I'll refresh the package if necessary, and inform of 
the updates and answered questions.

Thanks.

Barry Arndt
IBM Linux Technology Center - Linux on Power

Bug#890621: forwarded python3.6 issue (bpo-32305 causing regressions)

[Barry Warsaw]

On Feb 19, 2018, at 04:08, Matthias Klose  wrote:
> 
> This is https://bugs.python.org/issue32305, apparently intentional and will be
> in 3.7.  So better fix the packages itself. Not sure if that really should be
> backported.

Thanks for the forward.  The fix is for third party packages to use 
`getattr(module, ‘__file__’, None)` instead of `hasattr(module, ‘__file__’)`.  
I think gunicorn has already fixed this in their upstream.



signature.asc
Description: Message signed with OpenPGP

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Barry Warsaw]

On Sep 22, 2017, at 18:53, Pierre-Elliott Bécue  wrote:

> Now, when I run the tests, there are a lot of errors, but I can't say
> exactly why. If you wish I can put a copy of the last attempt.

Sure, post a link.  I’ll let you know if I see anything obvious.

-B



signature.asc
Description: Message signed with OpenPGP

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Barry Warsaw]

On Sep 22, 2017, at 09:28, Pierre-Elliott Bécue <be...@crans.org> wrote:
>> 
>>> In d/tests/mailman3-core-tests, what do you think about using `python3 -m 
>>> nose2` instead of `nose2-3`?
>> 
>> As I wasn't able to have working tests for this package, they're disabled in
>> d/rules. Maybe I just should remove this file.

Can you remember why the test suite doesn’t work in d/rules?

I do think that if they can’t be run in d/rules, they should be run at some 
point, and autopkgtests are a good alternative.  While that doesn’t block 
promotion in Debian (yet?) it does in Ubuntu, so there should be good feedback 
when the autopkgtests fail.

That said, in my own packages I always try to include a few other autopkgtests. 
 Things like:

* Run the command line (e.g. ``mailman —help``)
* Try to create a simple list
* Do a simple ``mailman shell`` command
* Hit the REST API and just make sure it returns some non-error.

>> Another interesting integration test might be to start up MM3’s REST API and 
>> GET the /3.1/system/versions resource, then either print the JSON or compare 
>> its value to something expected.  It’s at least a minimal sniff test that 
>> some runners could be started up.
>> 
>> I think this requires more background on mailman3 functionnalities that I
>> currently have. Maybe I'll set this suggestion in debian/TODO for later!

+1!  Tests are an investment over time, so just get the bare minimum working 
now, and it can always be improved.

>> autopkgtest fails for me with:
>>> 
>>> After this operation, 159 MB of additional disk space will be used.
>>> Err:1 http://httpredir.debian.org/debian sid/main amd64 python3-falcon 
>>> amd64 1.0.0-2+b1
>>>  404  Not Found
>>> E: Failed to fetch 
>>> http://httpredir.debian.org/debian/pool/main/p/python-falcon/python3-falcon_1.0.0-2+b1_amd64.deb
>>>   404  Not Found
>>> E: Unable to fetch some archives, maybe run apt-get update or try with 
>>> --fix-missing?
>>> autopkgtest [20:07:28]: ERROR: testbed failure: apt repeatedly failed to 
>>> download packages
>> 
>> I guess I'm not able to do such test myself.

You should be able to build the source package, and then if you have a chroot, 
just do:

$ autopkgtest mailman-core-blah-blah.dsc — schroot sid-amd64

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Barry Warsaw]

Hi guys, apologies for not responding earlier.  I have taken a break from 
Debian development, so I am not reading my @debian.org email much these days:

https://lists.debian.org/debian-python/2017/08/msg00107.html

That said...

> On Sep 20, 2017, at 12:53, Jonas Meurer <jo...@freesources.org> wrote:

> @barry: I could do the uploads but as you're PEB's sponsor so far you
> might want to do that yourself. Maybe you also want to review the latest
> changes to the packages? That would be awesome.

Jonas, Mattia, thank you very much for working with PEB, and thanks to PEB for 
being so diligent about getting Mailman 3 into Debian!  I wholeheartedly 
support your sponsorship of these packages while I am on hiatus.

I did a quick review of the core package, and noticed just a few things:

d/copyright should really go back to 1998.  Even though Mailman 3 was forked 
from Mailman 2 only in the last few years, there’s enough code inherited from 
the early days to warrant the earlier copyright start year.

In d/tests/mailman3-core-tests, what do you think about using `python3 -m 
nose2` instead of `nose2-3`?

Another interesting integration test might be to start up MM3’s REST API and 
GET the /3.1/system/versions resource, then either print the JSON or compare 
its value to something expected.  It’s at least a minimal sniff test that some 
runners could be started up.

If and when you get a real manpage, please write it in reST, convertible via 
rst2man and contribute it back upstream!

autopkgtest fails for me with:

After this operation, 159 MB of additional disk space will be used.
Err:1 http://httpredir.debian.org/debian sid/main amd64 python3-falcon amd64 
1.0.0-2+b1
  404  Not Found
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/p/python-falcon/python3-falcon_1.0.0-2+b1_amd64.deb
  404  Not Found
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?
autopkgtest [20:07:28]: ERROR: testbed failure: apt repeatedly failed to 
download packages

Didn’t try to debug that.  Building the package locally works and makes lintian 
happy.  Didn’t try to install it.

Everything else LGTM!


signature.asc
Description: Message signed with OpenPGP

Bug#641314: debhelper: dh_auto_test should support standard python cli for running tests

[Barry Warsaw]

Hi Niels,

> On Sep 17, 2017, at 09:31, Niels Thykier  wrote:
> Is there an update to the situation here?  Can we assume that the test
> target is (generally) always available ?  (even if we limit it to just
> python3 related calls).

No, I don’t have any update to this.  I am taking a break from Debian 
development (not retiring!) so don’t expect any progress on this in the near 
future.



signature.asc
Description: Message signed with OpenPGP

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Barry Arndt]

On Thu, 27 Jul 2017 10:20:12 -0300 Breno Leitao <bren...@br.ibm.com> 
wrote:
> Although lack of recent updates, we are still working on this problem.
> 
> Barry (on CC) is allocated to work on this issue and should have updates 
soon.
> 
> 
> 

The offending line of code that Breno mentioned earlier was part of a 
larger patch.  Looking at that larger patch, I'm afraid that just removing 
the offending line of code would make that patch incomplete and could 
possibly leave other errors behind.

We have a few patches for other issues in this area of code.  I tested a 
couple of them, but they did not resolve this issue.  I'm working with 
another developer (who is currently working on other items related to this 
one) to gather more debug information to narrow down to the correct fix.

Bug#865779: systemd: timed out waiting for lvm devices

[Barry S. Newberger]

Package: systemd

Version: 215-17+deb8u7

The /home, /root, /var, /tmp, /usr, /swap, and /home partitions are in a 
logical volume group. From the log:



Jun 18 14:01:00 barry-debian systemd[1]: Starting Arbitrary Executable File 
Formats File System Automount Point.

Jun 18 14:01:00 barry-debian systemd[1]: Set up automount Arbitrary Executable 
File Formats File System Automount Point.

Jun 18 14:01:00 barry-debian systemd[1]: Expecting device 
dev-mapper-vg_bsnlinux\x2dlv_swap.device...

Jun 18 14:01:00 barry-debian systemd[1]: Expecting device 
dev-disk-by\x2duuid-017fcb02\x2d46b3\x2d443f\x2da1c7\x2d65ad9e3a6565.device...

Jun 18 14:01:00 barry-debian systemd[1]: Expecting device 
dev-disk-by\x2duuid-23de4c26\x2d60d1\x2d4e21\x2db046\x2dbf76bf6876f7.device...

Jun 18 14:01:00 barry-debian systemd[1]: Expecting device 
dev-mapper-vg_bsnlinux\x2dlv_home.device...

Jun 18 14:01:00 barry-debian systemd[1]: Expecting device 
dev-mapper-vg_bsnlinux\x2dlv_temp.device...

Jun 18 14:01:00 barry-debian systemd[1]: Expecting device 
dev-mapper-vg_bsnlinux\x2dlv_var.device...



Jun 18 14:01:05 barry-debian kernel: EXT4-fs (sda2): mounted filesystem without 
journal. Opts: (null)

Jun 18 14:02:30 barry-debian systemd[1]: Job 
dev-mapper-vg_bsnlinux\x2dlv_var.device/start timed out.

Jun 18 14:02:30 barry-debian systemd[1]: Timed out waiting for device 
dev-mapper-vg_bsnlinux\x2dlv_var.device.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for /var.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for Local File 
Systems.



Jun 18 14:02:30 barry-debian systemd[1]: Triggering OnFailure= dependencies of 
local-fs.target.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for Update UTMP 
about System Runlevel Changes.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for Load/Save Random 
Seed.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for Various fixups 
to make systemd work better on Debian.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for Update UTMP 
about System Boot/Shutdown.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for Load/Save RF 
Kill Switch Status of rfkill0.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for File System 
Check on /dev/mapper/vg_bsnlinux-lv_var.



Jun 18 14:02:30 barry-debian systemd[1]: Job 
dev-mapper-vg_bsnlinux\x2dlv_temp.device/start timed out.

Jun 18 14:02:30 barry-debian systemd[1]: Timed out waiting for device 
dev-mapper-vg_bsnlinux\x2dlv_temp.device.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for /tmp.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for File System 
Check on /dev/mapper/vg_bsnlinux-lv_temp.

Jun 18 14:02:30 barry-debian systemd[1]: Job 
dev-mapper-vg_bsnlinux\x2dlv_home.device/start timed out.

Jun 18 14:02:30 barry-debian systemd[1]: Timed out waiting for device 
dev-mapper-vg_bsnlinux\x2dlv_home.device.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for /home.

Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for File System 
Check on /dev/mapper/vg_bsnlinux-lv_home.


Jun 18 14:02:30 barry-debian systemd[1]: Job 
dev-mapper-vg_bsnlinux\x2dlv_swap.device/start timed out.
Jun 18 14:02:30 barry-debian systemd[1]: Timed out waiting for device 
dev-mapper-vg_bsnlinux\x2dlv_swap.device.
Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for 
/dev/mapper/vg_bsnlinux-lv_swap.
Jun 18 14:02:30 barry-debian systemd[1]: Dependency failed for Swap.

The /root and /usr partitions mount without issue.

Here is the fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/vg_bsnlinux-lv_root /   ext4errors=remount-ro 0 
  1
# /Photos-Data was on /dev/sda3 during installation
UUID=017fcb02-46b3-443f-a1c7-65ad9e3a6565 /Photos-Dataext4defaults  
  0   2
# /boot was on /dev/sda2 during installation
UUID=23de4c26-60d1-4e21-b046-bf76bf6876f7 /boot   ext2defaults  
  0   2
/dev/mapper/vg_bsnlinux-lv_home /home   ext4defaults0   
2
/dev/mapper/vg_bsnlinux-lv_temp /tmpext4defaults0   
2
/dev/mapper/vg_bsnlinux-lv_usr /usrext4defaults0   2
/dev/mapper/vg_bsnlinux-lv_var /varext4defaults0   2
/dev/mapper/vg_bsnlinux-lv_swap noneswapsw  0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0


Barry Newberger

Bug#864072: D-I: installer hangs on re-formatting ext3 partition (having grub in the partition boot record).

[Barry S. Newberger]

Package: debian-installer

Version: 8.8

Severity: important

Tags: d-i

It looks like the partman bug (#767682) is back in debian-8.8.0-amd64. The 
installer hangs when installing from debian-8.8.0-amd64-DVD-1.iso.

Using graphical expert install. Reformatting the boot partition on sda2 with 
ext3 filesystem.

Barry Newberger

Bug#862072: [Python-modules-team] Bug#862072: python3-virtualenv doesn't provide entry point virtualenv

[Barry Warsaw]

On May 08, 2017, at 10:16 AM, Mickael Viey wrote:

>After a python3-virtualenv fresh install. The package is installed on
>/usr/lib/python3/dist-packages, but doesn't provide any entry point to invoke
>virtualenv:

That's correct.  python3-virtualenv is just the library.  Install the
`virtualenv` package to get the /usr/bin script.

% apt-file search /usr/bin/virtualenv
virtualenv: /usr/bin/virtualenv
virtualenv-clone: /usr/bin/virtualenv-clone

Bug#859421: python-tz orphaning

[Barry Warsaw]

On Apr 07, 2017, at 02:47 AM, Matthias Klose wrote:

>I think it's safe to go forward with this. Maybe keep the zope team (or the
>individual uploaders) as an uploader for a while, but I think the zope team
>is a little bit dead at this point ...

I really think we should pull the zope library packages into DPMT.

Bug#859747: pycxx 7.0.1-1 fails its autopkgtest

[Barry Warsaw]

Source: pycxx
Version: 7.0.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I just noticed this over in Ubuntu, where pycxx 7.0.1-1 is failing its
autopkgtest, which prevents it from getting promoted out of
zesty-proposed.  Retested on unstable, in a sid chroot, the exact same
failure occurs.

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/p/pycxx/20170329_091528_f4dc4@/log.gz

autopkgtest [15:13:29]: test buildtest: ---]
autopkgtest [15:13:29]: test buildtest:  - - - - - - - - - - results -
- - - - - - - - - -
buildtestFAIL non-zero exit status 1
autopkgtest [15:13:29]: test buildtest:  - - - - - - - - - - stderr -
- - - - - - - - - -
Traceback (most recent call last):
  File "test_example.py", line 40, in 
  import example
  ImportError:
/tmp/autopkgtest.BUHlO2/autopkgtest_tmp/examples/local/lib/python2.7/site-packages/CXX/example.so:
undefined symbol: _ZN2Py26ifPyErrorThrowCxxExceptionEv
autopkgtest [15:13:29]:  summary
buildtestFAIL non-zero exit status 1

I don't know if this ever worked.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAljmlAoACgkQEm61Y6dL
Br/Y+Q/9GgkEMluf+ff18Bko3CdV3z1yGJ0r+l6H5xp43jZ+bUNFp5EPZI45JwFQ
2ZfTTnhXlrlGN/LBTvC/BRveJEAYYfzYLQqOniMnB/4nJhY1Y/o7fwK7519yC2oN
zRX6u6MwEcfzmJpGuCsk8qD016vQDe9UHwvhrZ2MCNo+tV6ws9+TQHmRgi3850XY
iiTWnOohiFMHKtBVLkHR08WLgitZZAv20Fi1Q2z0WmXIXQtSXQ5Q3iaBXoTUDzCM
tOwKqiZYqcdfsEK8MMew8Il6AYOG11SzO7EdOZR1412txo8IPocExdpJK5uq7pJf
dnBdovkhN+gtsIsHRZRyOQ1Wzel5mDkbM9iSX/LthxmW4gkad5rOX31k+i/AJOWN
b6oa31DEep9LH1Y+rnaV7rQH5c8Fvm3x3sR6DN+cphbXlUDsGmi4ctmFHOe6HtHk
oh7W71+vVTcVcGtaEDlbUJ7/CJp7AoOJYCbu9dyiv2nrXt4eCBeIqJi+Xqc0Lrtr
l2XzE+RWPkDLCtHuWxQHMfJyarvV8wL4C3PVxf+vxJ2M129y2qlMZWiaNzY/UpDh
Bubu+nKHDM2rLzyIqZYBqnOkWlVqJMprPFnfWwIH0A3UwKS0g5OfjNNx70LSNw3X
8ffAkle3j91vuS1bxrWUYU5VjHlBmimfiT9UQjpM/yZxULOKqEg=
=B/8Y
-END PGP SIGNATURE-

Bug#853894: -> Bug#856607

[Barry Fishman]

On Wed, 2017-03-10 18:51:27 + Ben Hitchings wrote:
>On Wed, 2017-03-01 at 11:46 -0500, Barry Fishman wrote:
>> I'm not sure if this should be filed as a separate bug, but with the
>> 4.9 kernel update the WinTV Aero-M (Hauppauge) TV card also stopped
>> working.
>> 
>> Trying the unstable vmlinux-4.9.0-2-amd64 kernel on a otherwise up to
>> date Stretch system, the attached journal log was produced when the usb
>> card was plugged in the system.

>Please open a separate bug report for this.

I opened Debian Bug #856607 "WinTV Aero-M Card fails with 4.9.x kernels",
on 2 Mar 2017 as you suggested.  Its now 20 days later.

Since then there has been no response.  What do I need to do to get it
at least looked at?

--
Barry Fishman

Bug#856607: kernel-common: WinTV Aero-M Card fails with 4.9.x kernels

[Barry Fishman]

Package: kernel-common
Version: 4.9.0-2-amd64
Severity: important
Tags: upstream

Dear Maintainer,

A security change in the 4.9 kernels breaks a variety of dvd-usb
devices including this WinTV Aero-M TV usb card.  I play video
via mplayer and vlc.  The bug shows up with messages like
The errors are logged to the journal when the card is plugged in.

Mar 02 16:36:54 ecube vlc-tv.desktop[12107]: [7ff914d07348] dtv access
error: cannot access adapter 0: No such file or directory

The card works on kernels though 4.8.13 that I have tried on a variety
for OS releases like Debian Jessie, as well as Ubuntu through 16.10.
If fails on Fedora 25 (Using the 4.9 kernel) and Arch when updated
to the 4.9 kernel.

This is an up-to-date Debian Stretch system with the 4.9.0-1-amd64 kernal. It
also fails when the 4.9.0-2-amd64 kernel is installed
from unstable (as when this bug report was generated).



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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

*** /home2/barry/src/tv-card/Errors-sid-4.9.13-1.log
-- Logs begin at Wed 2017-03-01 11:22:47 EST. --
Mar 01 11:23:54 ecube gnome-session-binary[1917]: Entering running state
Mar 01 11:23:54 ecube dbus-daemon[1915]: Successfully activated service
'org.gnome.evolution.dataserver.AddressBook9'
Mar 01 11:23:54 ecube systemd[1902]: Started Evolution address book service.
Mar 01 11:23:55 ecube clipit[2300]:
/build/glib2.0-IOHfFd/glib2.0-2.50.3/./gobject/gsignal.c:2523: signal 'child-
added' is invalid for instance '0x55d32bc083e0' of type 'GtkMenu'
Mar 01 11:23:56 ecube dbus-daemon[1915]: Activating via systemd: service
name='org.gnome.Terminal' unit='gnome-terminal-server.service'
Mar 01 11:23:56 ecube systemd[1902]: Starting GNOME Terminal Server...
Mar 01 11:23:56 ecube telepathy-rakia[2170]: Exiting
Mar 01 11:23:56 ecube dbus-daemon[1915]: Successfully activated service
'org.gnome.Terminal'
Mar 01 11:23:56 ecube systemd[1902]: Started GNOME Terminal Server.
Mar 01 11:23:56 ecube telepathy-haze[2172]: Exiting
Mar 01 11:24:25 ecube realmd[1830]: quitting realmd service after timeout
Mar 01 11:24:25 ecube realmd[1830]: stopping service
Mar 01 11:24:33 ecube kernel: usb 1-10: new high-speed USB device number 6
using xhci_hcd
Mar 01 11:24:33 ecube kernel: usb 1-10: New USB device found, idVendor=2040,
idProduct=c61b
Mar 01 11:24:33 ecube kernel: usb 1-10: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Mar 01 11:24:33 ecube kernel: usb 1-10: Product: WinTV Aero-M
Mar 01 11:24:33 ecube kernel: usb 1-10: Manufacturer: Hauppauge
Mar 01 11:24:33 ecube kernel: usb 1-10: SerialNumber: 4034988243
Mar 01 11:24:33 ecube mtp-probe[2560]: checking bus 1, device 6:
"/sys/devices/pci:00/:00:14.0/usb1/1-10"
Mar 01 11:24:33 ecube mtp-probe[2560]: bus: 1, device: 6 was not an MTP device
Mar 01 11:24:33 ecube kernel: usb 1-10: dvb_usb_v2: found a 'Hauppauge WinTV-
Aero-M' in warm state
Mar 01 11:24:33 ecube kernel: usb 1-10: dvb_usb_v2: will pass the complete
MPEG2 transport stream to the software demuxer
Mar 01 11:24:33 ecube kernel: DVB: registering new adapter (Hauppauge WinTV-
Aero-M)
Mar 01 11:24:33 ecube kernel: [ cut here ]
Mar 01 11:24:33 ecube kernel: WARNING: CPU: 1 PID: 2559 at /build/linux-
QtSjAP/linux-4.9.13/drivers/usb/core/hcd.c:1584
usb_hcd_map_urb_for_dma+0x37c/0x570 [usbcore]
Mar 01 11:24:33 ecube kernel: transfer buffer not dma capable
Mar 01 11:24:33 ecube kernel: Modules linked in: dvb_usb_mxl111sf(+) dvb_usb_v2
tveeprom dvb_core rc_core fuse rfcomm snd_hrtimer snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device bnep snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec joydev
btusb nouveau intel_rapl mxm_wmi snd_hda_core btrtl snd_hwdep
x86_pkg_temp_thermal ttm intel_powerclamp snd_pcm_oss coretemp dell_wmi
drm_kms_helper evdev iTCO_wdt hci_uart drm btbcm btqca btintel snd_mixer_oss
sparse_keymap dell_smbios kvm_intel bluetooth i2c_algo_bit dcdbas snd_pcm
iTCO_vendor_support snd_timer intel_lpss_acpi snd rfkill intel_lpss kvm tpm_crb
sg soundcore video battery mei_me mfd_core shpchp mei tpm_tis irqbypass
tpm_tis_core tpm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate
acpi_als
Mar 01 11:24:33 ecube kernel:  kfifo_buf serio_raw industrialio intel_uncore
button acpi_pad intel_rapl_perf wmi pcspkr binfmt_misc ecryptfs cbc sunrpc hmac
encrypted_keys parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4
crc16 jbd2 crc32c_generic fscrypto ecb mbcache uas usb_storage sr_mod cdrom
sd_mod hid_generic usbhid crc32c_intel ahci libahci xhci_pci aesni_intel
xhci_hcd aes_x86_64 glue_helper libata lrw gf128mul ablk_helper cryptd e1000e
psmouse usbcore scsi_mod ptp i2c_i801 pps_core

Bug#853894: similar issue with hauppauge WinTV nova-t-usb2

[Barry Fishman]

7f516ea8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c008c78] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516ea8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00cdb8] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f51600057d8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c008c78] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f51600057d8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00ce18] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f51600057d8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00f168] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f51600057d8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c008f68] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f51600057d8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00f168] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f5160009f08] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00cef8] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516000a2b8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00e7c8] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f51600080a8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00cef8] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516000ce78] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c012a98] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516000ce78] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00da38] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516000cc28] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c012a98] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516000cc28] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c0127e8] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516000f768] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c012a98] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516000cc28] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c00d6c8] core input 
error: open of `dvb://' failed
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f51600125c8] dtv access 
error: cannot access adapter 0: No such file or directory
Mar 01 11:26:34 ecube vlc-tv.desktop[2794]: [7f516c008e88] core input 
error: open of `dvb://' failed
Mar 01 11:27:32 ecube vlc-tv.desktop[2794]: QObject::~QObject: Timers cannot be 
stopped from another thread


--
Barry Fishman

Bug#852289: [Python-modules-team] Bug#852289: python-passlib: please make the build reproducible (timestamps)

[Barry Warsaw]

On Jan 31, 2017, at 09:43 AM, Eli Collins wrote:

>Passlib 1.7.1 is out, which should fix #852289; I'll try to keep an eye on
>the reproducible build status for a bit in case there's any other hiccups.

Thanks!  I'm working on the new upstream in git right now.  It looks like we
can also drop the 0001-Disable-Django-support.patch since

https://bitbucket.org/ecollins/passlib/issues/68/tests-fail-with-django-19

is resolved upstream.  I'm not a Django expert though so please let me know if
this is not correct.

Cheers,
-Barry


pgpaSH_AHEkxO.pgp
Description: OpenPGP digital signature

Bug#812768: [Python-modules-team] Bug#812768: python-whoosh: diff for NMU version 2.7.0-1.1

[Barry Warsaw]

On Jan 30, 2017, at 08:21 AM, Simon McVittie wrote:

>Thanks for letting me know, I'll mark it as unmaintained. Would you like
>your other packages to be marked as unmaintained too?
>
>Sorry, I am not intending to adopt python-whoosh: I'm only fixing it
>because removing it from testing would be disruptive for other packages
>in Debian.

I'd be willing to help maintain whoosh, but only with DPMT as Maintainer and
myself as Uploader.

Given the ongoing discussion over in debian-python@ it might not be worth
git-dpm'ifying it, but instead just moving the vcs branch over to the team
repo.  If this is acceptable, let me know.

Bug#744741: (no subject)

[Barry Warsaw]

Maybe, create a python{,3}-pyside-common package that only contains the
.egg-info and then have all subpackages depend on that?

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

[Barry Warsaw]

Hi Martin,

On Jan 24, 2017, at 09:19 PM, Martin Pitt wrote:

>Ah, sbuild usually copies that from the host system
>(/etc/schroot/default/nssdatabases), so indeed this tends to cause conffile
>conflicts.

Ah ha!  That was the piece I was missing.

Thanks for applying the patch.

-Barry


pgp08bth0I0vq.pgp
Description: OpenPGP digital signature

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

[Barry Warsaw]

https://code.launchpad.net/~barry/autopkgtest/+git/autopkgtest/+ref/852475


pgp9syopDe3sn.pgp
Description: OpenPGP digital signature

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

[Barry Warsaw]

Package: autopkgtest
Version: 4.3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Let's say one of your autopkgtest dependencies (perhaps recursively)
needs to update a configuration file, i.e. via a conffile.  E.g. when
running the autopkgtests for aptdaemon in an Ubuntu Zesty chroot, the
netbase package wants to be installed, and this has conffiles for
/etc/{protocols,rpc,services}.

This can break the tests when dpkg needs to query about updating these
conffiles because the default is to --force-confdef, which prompts the
user and waits for a response.  This fails in the following way:

Setting up netbase (5.4) ...

Configuration file '/etc/protocols'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
D   : show the differences between the versions
Z   : start a shell to examine the situation
 The default action is to keep your current version.
*** protocols (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
netbase (--configure):
 end of file on stdin at conffile prompt
 
Thus the test dependencies can't be installed and the entire
autopkgtest fails.

It would be better I think when setting up the testbed, to pass to the 
`apt-get install` command an additional option: 
- -o Dpkg::Options::="--force-confnew" so that the prompt is bypassed
and the dependency can be installed.

I can't think of a reason why you'd want to retain the old conffile,
since the testbed is (usually? always?) ephemeral.  If you can think
of a use case for that, then an autopkgtest option would probably be
required.  I'd opt for YAGNI and just include that dpkg option
unconditionally.  

Seems like it should be a relatively easy fix in adt_testbed.py; I'll
try to put together a branch and test it.

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   1.4~beta4
ii  libdpkg-perl1.18.18
ii  procps  2:3.3.12-3
ii  python3 3.5.3-1
ii  python3-debian  0.1.29

Versions of packages autopkgtest recommends:
ii  autodep8  0.8

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.10-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAliHr7kACgkQEm61Y6dL
Br9yew/+NRKoZ1e5B3z2I0MRdo2qiNOF76zaP6WDAAoFeLyQaplFshvIMmKTzvKt
cERFGnijEKWfeCPOP3wyLbotqVXHYqqJmiqDDmx7jFUJEUFYO9UIPqymUz6LGU4S
//Ya1GSYucOCw/VQQfHt1hAlsnyAxWfv2e87xfgFIDhxQihoQu7VZqA8dvGIkvRt
nbXiAPf4a2s9/MRjLctEAfwwyw3HbGSzytaDyCgiZH+r562tqccClfe7VhMfGn3j
QQvzumjELwcXPQbijZAiNeMHN4JEWQzzXwbRwndlq51F+tsCzrjPrm5bcUnILiVL
jA7mrZGMAHanOPl6F4ZC5Idfby7h6gXRqZ5Nc2o/+rUU+TX6iBb/TEtT64ejiy9O
G5PxrQGuL2WxEk8ObcVi6E5PW/L9hmx/T/kLm3oVdOEFEmxhPS95uNlu7aKnOg9N
6X4BeDej7UNwRVjG45lgKw1xW0xfZ5rLBvdQtQqsXkECZDgquW298eBM1D4JuPbc
I5bZyj4w7pNkWIrBglkeX6rxy3YzH+k/21Fx/pYAtG4PRfk09p7k+YOePATRrclf
FBOnf9+KzgfDiCTqgXB1HN/nxbpcTBirg0d4CCrdpW4wcru5VEpnEe9GRxJbY/X3
pZPKAoKkE4jTYgXICqaheEHjAtsh3k0rFNuYmLL9dUHnVi9zGI8=
=rNub
-END PGP SIGNATURE-

Bug#852289: [Python-modules-team] Bug#852289: python-passlib: please make the build reproducible (timestamps)

[Barry Warsaw]

On Jan 23, 2017, at 04:40 PM, Eli Collins wrote:

>In case this helps the debian package maintainer decide on this patch /
>schedule things, the timestamp problem this addresses is due to a bug in
>the passlib 1.7.0 setup script, which should be fixed in the 1.7.1 upstream
>release (due out next weekend).

Thanks for the status Eli.  If the bug is fixed upstream, I think it makes
sense to just wait until 1.7.1.  Feel free to drop us a ping when that's
available (though I'll eventually notice it anyway).  If Brian doesn't beat me
to it, I'm happy to update to 1.7.1 once it's available.