Bug#1072297: [Pkg-shadow-devel] Bug#1072297: lastlog(8) man page: stray XML markup

[Serge E. Hallyn]

On Fri, May 31, 2024 at 07:27:22PM +0200, Jakub Wilk wrote:
> Package: login
> Version: 1:4.13+dfsg1-1+b1
> Severity: minor
> 
> I stumbled upon this:
> 
>$ man lastlog.8 | grep -w term
>   Having high UIDs can create problems when handling the 
>   /var/log/lastlog with external tools. Although the
> 
> I suppose this XML markup shouldn't be there.

Yes, that looks like a simple xml misunderstanding.  I'll remove that
upstream, thanks.

Bug#1068229: [Pkg-shadow-devel] Bug#1068229: login: remove lastlog, remove pam_lastlog.so from PAM config [patch]

[Serge E. Hallyn]

Thanks.  Applied to https://salsa.debian.org/debian/shadow

On Thu, May 30, 2024 at 02:32:24AM +0200, Chris Hofstaedtler wrote:
> Control: tags 1068229 + patch
> 
> Hi,
> 
> here's a patch to achieve the requested changes.
> 
> When this is uploaded, we can have lastlog2 take over.
> 
> Please let me know about your plan on uploading.
> 
> Chris
> 

> diff -Nru shadow-4.13+dfsg1/debian/changelog 
> shadow-4.13+dfsg1/debian/changelog
> --- shadow-4.13+dfsg1/debian/changelog2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/changelog2024-05-30 02:23:58.0 
> +0200
> @@ -1,3 +1,11 @@
> +shadow (1:4.13+dfsg1-4.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Drop pam_lastlog.so from config. (Closes: #1068229)
> +  * Stop installing lastlog binary.
> +
> + -- Chris Hofstaedtler   Thu, 30 May 2024 02:23:58 +0200
> +
>  shadow (1:4.13+dfsg1-4) unstable; urgency=medium
>  
>[ Helmut Grohne ]
> diff -Nru shadow-4.13+dfsg1/debian/login.install 
> shadow-4.13+dfsg1/debian/login.install
> --- shadow-4.13+dfsg1/debian/login.install2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/login.install2024-05-30 02:23:58.0 
> +0200
> @@ -2,6 +2,5 @@
>  usr/share/locale/*/LC_MESSAGES/shadow.mo
>  sbin/nologin usr/sbin
>  usr/bin/faillog
> -usr/bin/lastlog
>  usr/bin/newgrp
>  bin/login usr/bin
> diff -Nru shadow-4.13+dfsg1/debian/login.manpages 
> shadow-4.13+dfsg1/debian/login.manpages
> --- shadow-4.13+dfsg1/debian/login.manpages   2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/login.manpages   2024-05-30 02:23:58.0 
> +0200
> @@ -4,7 +4,6 @@
>  usr/share/man/*/man5/faillog.5
>  usr/share/man/*/man5/login.defs.5
>  usr/share/man/*/man8/faillog.8
> -usr/share/man/*/man8/lastlog.8
>  usr/share/man/*/man8/nologin.8
>  usr/share/man/man1/login.1
>  usr/share/man/man1/newgrp.1
> @@ -12,5 +11,4 @@
>  usr/share/man/man5/faillog.5
>  usr/share/man/man5/login.defs.5
>  usr/share/man/man8/faillog.8
> -usr/share/man/man8/lastlog.8
>  usr/share/man/man8/nologin.8
> diff -Nru shadow-4.13+dfsg1/debian/login.pam 
> shadow-4.13+dfsg1/debian/login.pam
> --- shadow-4.13+dfsg1/debian/login.pam2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/login.pam2024-05-30 02:23:58.0 
> +0200
> @@ -77,10 +77,6 @@
>  # (Replaces the use of /etc/limits in old login)
>  sessionrequired   pam_limits.so
>  
> -# Prints the last login info upon successful login
> -# (Replaces the `LASTLOG_ENAB' option from login.defs)
> -sessionoptional   pam_lastlog.so
> -
>  # Prints the status of the user's mailbox upon successful login
>  # (Replaces the `MAIL_CHECK_ENAB' option from login.defs). 
>  #
> diff -Nru shadow-4.13+dfsg1/debian/not-installed 
> shadow-4.13+dfsg1/debian/not-installed
> --- shadow-4.13+dfsg1/debian/not-installed2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/not-installed2024-05-30 02:23:58.0 
> +0200
> @@ -15,6 +15,7 @@
>  etc/pam.d/useradd
>  etc/pam.d/userdel
>  etc/pam.d/usermod
> +usr/bin/lastlog
>  usr/bin/sg
>  usr/lib/*/libsubid.la
>  usr/sbin/logoutd
> @@ -25,6 +26,7 @@
>  usr/share/man/*/man3/getspnam.3
>  usr/share/man/*/man3/shadow.3
>  usr/share/man/*/man5/suauth.5
> +usr/share/man/*/man8/lastlog.8
>  usr/share/man/*/man8/logoutd.8
>  usr/share/man/man1/groups.1
>  usr/share/man/man1/logoutd.1
> @@ -32,5 +34,6 @@
>  usr/share/man/man3/getspnam.3
>  usr/share/man/man3/shadow.3
>  usr/share/man/man5/suauth.5
> +usr/share/man/man8/lastlog.8
>  usr/share/man/man8/logoutd.8
>  

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1069760: linux-headers-6.1.0-20-amd64: WWAN adapter (Modem) is not found after update to this kernel

[Serge Polyakov]

Package: linux-headers-6.1.0-20-amd64
Version: 6.1.85-1
Severity: important
X-Debbugs-Cc: beer-b...@yandex.ru

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After updating stable Debian to the latest version my laptop Thinkpad X390
loses modem device.
After sleep or even after reboot Settings don't have Mobile Network tab and
icon for Mobile Network is  disappeared from panels on Gnome Desktop (right top
corner)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

1. In Gnome desktop search for Mobile Network
2. Launch it.
3. Mobile Network appears in Settings again but have "No WWAN Adapter found"
status.
4. Launch Network Manager
5. Save existing Mobile Broadband configuration.
6. It CAN fixes and Modem is back, or nothing has changed.

I haven't determine solution for sure.

   * What was the outcome of this action?

   * What outcome did you expect instead?
*** End of the template - remove these template lines ***


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

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
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 linux-headers-6.1.0-20-amd64 depends on:
ii  linux-compiler-gcc-12-x86  6.1.85-1
ii  linux-headers-6.1.0-20-common  6.1.85-1
ii  linux-kbuild-6.1   6.1.85-1

linux-headers-6.1.0-20-amd64 recommends no packages.

linux-headers-6.1.0-20-amd64 suggests no packages.

-- no debconf information

Bug#1069710: network-manager: WWAN adapter (Modem) is not found after update of stable Debian

[Serge Polyakov]

Package: network-manager
Version: 1.42.4-1
Severity: important
X-Debbugs-Cc: beer-b...@yandex.ru

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After updating stable Debian to the latest version my laptop losts modem
device.
After sleep or even after reboot Settings doesn't have Mobile Network tab and
icon for Mobile Network is  disappeared from panels on Gnome Destop (right top
corner)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

1. In Gnome desktop search for Mobile Network
2. Launch it.
3. Mobile Network appears in Settings again but have "No WWAN Adapter found"
status.
4. Launch Network Manager
5. Save existing Mobile Broadband configuration.
6. It CAN fixes and Modem is back, or nothing has changed.

I haven't determine solution for sure.

   * What was the outcome of this action?

   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
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 network-manager depends on:
ii  adduser 3.134
ii  dbus [default-dbus-system-bus]  1.14.10-1~deb12u1
ii  libaudit1   1:3.0.9-1
ii  libbluetooth3   5.66-1+deb12u1
ii  libc6   2.36-9+deb12u4
ii  libcurl3-gnutls 7.88.1-10+deb12u5
ii  libglib2.0-02.74.6-2
ii  libgnutls30 3.7.9-2+deb12u2
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.4-1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.42.4-1
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.4-1+b6
ii  libsystemd0 252.22-1~deb12u1
ii  libteamdctl01.31-1
ii  libudev1252.22-1~deb12u1
ii  policykit-1 122-3
ii  polkitd 122-3
ii  udev252.22-1~deb12u1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   252.22-1~deb12u1
ii  modemmanager 1.20.4-1
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-12

Versions of packages network-manager suggests:
ii  iptables   1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-2

-- no debconf information

Bug#1068590: steam-installer: Impossible installation

[Serge Kilimoff]

Package: steam-installer
Version: 1:1.0.0.79~ds-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: serge.kilim...@gmail.com

Dear Maintainer,

when I try to install the package I get the following error :

The following packages have unmet dependencies:
 libgl1-mesa-dri:i386 : Depends: libllvm17t64:i386 but it is not installable
E: Unable to correct problems, you have held broken packages.


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

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

Versions of packages steam-installer depends on:
ii  debconf [debconf-2.0]  1.5.86
pn  steam-libs 
pn  steam-libs-i386
ii  zenity 4.0.1-1+b1

steam-installer recommends no packages.

steam-installer suggests no packages.

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Serge E. Hallyn]

On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote:
> Hi OpenSSH, shadow Maintainers,
> 
> On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > > It seems desirable to ship liblastlog2 in trixie, considering that the
> > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > > recorded in /var/log/lastlog.
> > 
> [..]
> > At the same time, all traditional writing to /var/log/lastlog should
> > stop.
> > 
> > So, after some of the current fog clears, src:util-linux could
> > introduce new binary packages (at least libpam-lastlog2), but
> > src:pam would need to add it to the common-* config files.
> > 
> > Does this seem right?
> 
> Answering my own question, not quite.
> 
> Apparently, traditionally we have:
> 
> * sshd writes to /var/log/lastlog by itself.
> * login has pam_lastlog.so in its PAM snippet. 
> 
> Both of these would need to be replaced by pam_lastlog2.so. I don't
> really know what the other distros are doing right now, and/or if
> we should align on this.
> 
> So we could either put pam_lastlog2.so into a common-* file from
> src:pam, or openssh and shadow should switch their setup.
> 
> What do we all think about that?

Hi Chris,

It doesn't look like upstream shadow is specifying pam_lastlog.so,
but debian login does.

Putting pam_lastlog2.so into a common-* from src:pam sounds like a good
solution.

thanks,
-serge

Bug#1064940: [Pkg-shadow-devel] Bug#1064940: vipw's manpage does not document ~/.selected_editor

[Serge E. Hallyn]

Thanks.  This is new to me - I see that debian/rules sets that as the
default.

Note that vipw will not use sensible-editor, or ask you what you want
for it, if VISUAL or EDITOR is set in your environment.  Would you
mind adding that to your manpage patch?

thanks,
-serge

On Wed, Feb 28, 2024 at 12:07:50AM +, Toni via Pkg-shadow-devel wrote:
> Package: passwd
> Version: 1:4.13+dfsg1-1+b1
> Severity: minor
> Tags: patch
> 
> 
> Hi,
> 
> the 'vipw' program uses a file that isn't documented. The attached patch
> should fill this gap, although I haven't tried to build the package with
> it.
> 
> 
> Enjoy,
> Toni
> 
> 
> 
> -- System Information:
> Debian Release: 12.5
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-18-amd64 (SMP w/12 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages passwd depends on:
> ii  libaudit1   1:3.0.9-1
> ii  libc6   2.36-9+deb12u4
> ii  libcrypt1   1:4.4.33-2
> ii  libpam-modules  1.5.2-6+deb12u1
> ii  libpam0g1.5.2-6+deb12u1
> ii  libselinux1 3.4-1+b6
> ii  libsemanage23.4-1+b5
> 
> Versions of packages passwd recommends:
> ii  sensible-utils  0.0.17+nmu1
> 
> passwd suggests no packages.
> 
> -- no debconf information

> diff --git a/man/vipw.8.xml b/man/vipw.8.xml
> index 4caddcb..9775af7 100644
> --- a/man/vipw.8.xml
> +++ b/man/vipw.8.xml
> @@ -77,6 +77,11 @@
>vi
>1.
>  
> +
> +On the first run, this program asks you for an editor and stores your
> +selection in ~/.selected_editor. If the editor mentioned therein does
> +not exist on your system, the program will fall back to using 'nano'.
> +
>
>  
>
> @@ -210,6 +215,9 @@
>
>   gshadow5
>
> +  
> +  
> ~/.selected_editor5
> +  
>
>   login.defs5
>,

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1059915: [Pkg-shadow-devel] Bug#1059915: DEP17: move login and shadowconfig to /usr

[Serge E. Hallyn]

Hi,

fwiw this looks good to me.

thanks,
-serge

On Wed, Jan 03, 2024 at 02:59:32PM +0100, Helmut Grohne wrote:
> Source: shadow
> Version: 1:4.13+dfsg1-3
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
> 
> Hi,
> 
> We want to finalize the /usr-merge transition via DEP17 by moving all
> files to /usr. shadow is involved at this time, because login is
> installed by debootstrap. I'm attaching a patch that moves both login
> and shadowconfig. It seems fairly harmless to me and I think it can go
> to unstable directly. This patch should not be included in
> bookworm-backports or earlier. If you want to support backports, please
> use dh_movetousr instead.
> 
> Helmut

> diff --minimal -Nru shadow-4.13+dfsg1/debian/changelog 
> shadow-4.13+dfsg1/debian/changelog
> --- shadow-4.13+dfsg1/debian/changelog2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/changelog2024-01-03 11:41:32.0 
> +0100
> @@ -1,3 +1,10 @@
> +shadow (1:4.13+dfsg1-3.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * DEP17: Move login and shadowconfig to /usr. (Closes: #-1)
> +
> + -- Helmut Grohne   Wed, 03 Jan 2024 11:41:32 +0100
> +
>  shadow (1:4.13+dfsg1-3) unstable; urgency=medium
>  
>* Team upload
> diff --minimal -Nru shadow-4.13+dfsg1/debian/login.install 
> shadow-4.13+dfsg1/debian/login.install
> --- shadow-4.13+dfsg1/debian/login.install2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/login.install2024-01-03 11:00:47.0 
> +0100
> @@ -4,4 +4,4 @@
>  usr/bin/faillog
>  usr/bin/lastlog
>  usr/bin/newgrp
> -bin/login
> +bin/login usr/bin
> diff --minimal -Nru shadow-4.13+dfsg1/debian/passwd.install 
> shadow-4.13+dfsg1/debian/passwd.install
> --- shadow-4.13+dfsg1/debian/passwd.install   2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/passwd.install   2024-01-03 11:01:01.0 
> +0100
> @@ -1,5 +1,5 @@
>  debian/default/useradd etc/default
> -debian/shadowconfig sbin
> +debian/shadowconfig usr/sbin
>  usr/bin/chage
>  usr/bin/chfn
>  usr/bin/chsh
> diff --minimal -Nru shadow-4.13+dfsg1/debian/rules 
> shadow-4.13+dfsg1/debian/rules
> --- shadow-4.13+dfsg1/debian/rules2023-10-15 19:10:52.0 +0200
> +++ shadow-4.13+dfsg1/debian/rules2024-01-03 11:00:01.0 +0100
> @@ -42,7 +42,7 @@
>   dh_install -a
>  ifeq ($(DEB_HOST_ARCH_OS),hurd)
>   # /bin/login is provided by the hurd package.
> - rm -f debian/login/bin/login
> + rm -f debian/login/usr/bin/login
>  endif
>  
>  override_dh_installpam:

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1053724: offlineimap3: OfflineIMAP crashes on synchronisation of a 'Message-ID: <>' in header

[Serge Cohen]

Package: offlineimap3
Version: 0.0~git20230519.c9f44ad+dfsg-1
Severity: important
X-Debbugs-Cc: serge.co...@cnrs.fr

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   Using OfflineIMAP as a solution to synchronise and secure a second copies of 
messages.
   When a message contains a header line as
Message-ID: <>

   This causes a crash of the message header parsing of OfflineIMAP :

ERROR: Copying message 66358 [acc: XX]
  list index out of range
Thread 'Copy message from XX-remote:INBOX' terminated with exception:
Traceback (most recent call last):
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 2069, in 
get_msg_id
token, value = get_dot_atom_text(value)
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 1334, in 
get_dot_atom_text
raise errors.HeaderParseError("expected atom at a start of "
email.errors.HeaderParseError: expected atom at a start of dot-atom-text but 
found '>'

   This crash also inhibit OfflineIMAP from synchronising any message which is 
later in the IMAP list.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   Currently, the only workaround is to suppress such messages from the 
originating mailbox.

   * What was the outcome of this action?

   The message is not archived (indeed, even worse : it is completely deleted), 
but the synchronisation can go on

   * What outcome did you expect instead?

   Both that the message is synchronised (as any other message) and the process 
continue to synchronise all the rest of the mailbox.

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 offlineimap3 depends on:
ii  ca-certificates   20210119
ii  python3   3.9.2-3
ii  python3-distro1.5.0-1
ii  python3-imaplib2  2.57-5.2

offlineimap3 recommends no packages.

Versions of packages offlineimap3 suggests:
pn  python3-gssapi  

-- no debconf information

Bug#1053709: roundcube-core: Trying to recreate an already existing symlink '/etc/apache2/conf-available/roundcube.conf'

[Serge Cohen]

Package: roundcube
Version: 1.4.14+dfsg.1-1~deb11u1
Severity: normal
X-Debbugs-Cc: serge.co...@cnrs.fr

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
A Bullseye running server having roundcube already installed. At the occasion 
of an 'apt-get upgrade' got the message that it was impossible to create the 
symling '/etc/apache2/conf-available/roundcube.conf' since it already existed 
(indeed created earlier and present for a long time). This error halts totally 
the installation process.
Note, however, that in my situation the target of the symlink does NOT exist.

Indeed, on this server the web interface is served through Nginx and FPM.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Removed the symlink and rerun the 'apt upgrade'

   * What was the outcome of this action?

The upgrade went well after having removed the symlink. The symlink is 
recreated exactly as it was before the 'apt upgrade'.

   * What outcome did you expect instead?

The symlink should transparently handled during the upgrade.

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 roundcube-core depends on:
ii  dbconfig-common   2.0.19
ii  debconf [debconf-2.0] 1.5.77
ii  dpkg  1.20.13
ii  libapache2-mod-php2:7.4+76
ii  libapache2-mod-php7.4 [libapache2-mo  7.4.33-1+deb11u4
ii  libjs-bootstrap4  4.5.2+dfsg1-8~deb11u1
ii  libjs-codemirror  5.59.2+~cs0.23.109-1
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-minicolors   2.2.6+dfsg-4
ii  libjs-jquery-ui   1.12.1+dfsg-8+deb11u1
ii  libjs-jstimezonedetect1.0.6-5
ii  libmagic1 1:5.39-3+deb11u1
ii  php-auth-sasl 1.1.0-1
ii  php-common2:76
ii  php-intl  2:7.4+76
ii  php-mail-mime 1.10.10-1
ii  php-masterminds-html5 2.7.4+dfsg-2
ii  php-mbstring  2:7.4+76
ii  php-net-sieve 1.4.4-2
ii  php-net-smtp  1.9.0-1
ii  php-net-socket1.2.2-2
ii  php-pear  1:1.10.12+submodules+notgz+20210212-1
ii  php7.4-cli [php-cli]  7.4.33-1+deb11u4
ii  php7.4-intl [php-intl]7.4.33-1+deb11u4
ii  php7.4-json [php-json]7.4.33-1+deb11u4
ii  php7.4-mbstring [php-mbstring]7.4.33-1+deb11u4
ii  roundcube-sqlite3 1.4.14+dfsg.1-1~deb11u1
ii  ucf   3.0043

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi] 2.4.56-1~deb11u2
ii  nginx-core [httpd-cgi]  1.18.0-6.1+deb11u3
ii  php-fpm 2:7.4+76
ii  php-gd  2:7.4+76
ii  php-pspell  2:7.4+76
ii  php7.4-fpm [php-fpm]7.4.33-1+deb11u4
ii  php7.4-gd [php-gd]  7.4.33-1+deb11u4
ii  php7.4-pspell [php-pspell]  7.4.33-1+deb11u4

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg 
pn  php-mkopinsky-zxcvbn-php  
pn  php-net-ldap3 
iu  roundcube-plugins 1.4.14+dfsg.1-1~deb11u1

Versions of packages roundcube depends on:
ii  dpkg  1.20.13

-- Configuration Files:
/etc/roundcube/apache.conf [Errno 2] Aucun fichier ou dossier de ce type: 
'/etc/roundcube/apache.conf'

-- debconf information:
  roundcube/hosts:
  roundcube/db/dbname: roundcube
  roundcube/remove-error: abort
  roundcube/dbconfig-remove: true
  roundcube/dbconfig-upgrade: true
  roundcube/passwords-do-not-match:
  roundcube/install-error: abort
  roundcube/upgrade-backup: true
  roundcube/purge: false
  roundcube/internal/skip-preseed: false
  roundcube/language: fr_FR
  roundcube/db/basepath: /var/lib/dbconfig-common/sqlite3/roundcube
  roundcube/internal/reconfiguring: false
* roundcube/dbconfig-install: false
  roundcube/reconfigure-webserver: apache2, lighttpd
  roundcube/restart-webserver: true
  roundcube/database-type: sqlite3
  roundcube/upgrade-error: abort
  roundcube/missing-db-package-error: abort
  roundcube/dbconfig-reinstall: false

Bug#1053572: libosmgpsmap-1.0-1: libosmgpsmap and GeocodeGlib are incompatible and cannot be used together

[Serge Noiraud]

Package: libosmgpsmap-1.0-1
Version: 1.2.0-2
Severity: critical
Tags: d-i
Justification: breaks unrelated software
X-Debbugs-Cc: serge.noir...@free.fr

libosmgpsmap uses libsoup 2.4 and GeocodeGlin use libsoup 3.0
This occurs with the gramps application.
gramps stop then we have the following error:
(Gramps.py:3226): libsoup-ERROR **: 13:47:37.498: libsoup2 symbols detected.
Using libsoup2 and libsoup3 in the same process is not supported.
Trace/breakpoint trap


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

Kernel: Linux 6.1.0-12-amd64 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: 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 libosmgpsmap-1.0-1 depends on:
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libsoup2.4-1 2.74.3-1

libosmgpsmap-1.0-1 recommends no packages.

libosmgpsmap-1.0-1 suggests no packages.

-- no debconf information

Bug#1041547: [Pkg-shadow-devel] Bug#1041547: login: I can login as root without password despite it being forbidden

[Serge E. Hallyn]

On Thu, Jul 20, 2023 at 05:10:14PM +, ircu...@gmail.com wrote:
> Package: login
> Version: 1:4.13+dfsg1-1+b1
> Severity: serious
> X-Debbugs-Cc: ircu...@gmail.com
> 
> Dear Maintainer,
> 
> On a newly installed debian bookworm /usr/share/doc/passwd/NEWS.Debian.gz 
> mentions a new PREVENT_NO_AUTH option that is supposed to prevent login to 
> passwordless accounts.
> 
> The option is found in /etc/login.defs and has the default value:
> PREVENT_NO_AUTH superuser
> 
> I removed root password using `passwd -d root` so that `grep root 
> /etc/shadow` reads:
> root::19519:0:9:7:::
> 
> I can now login to root on a tty just by typing root as the login name. I can 
> also login to root just by typing `su` from a regular user account. 
> "PREVENT_NO_AUTH superuser" has no effect.
> 
> I then changed the option to "PREVENT_NO_AUTH yes", which is supposed to 
> prevent all passwordless account login.
> 
> I created a new user account `useradd -m -s /bin/bash testuser` and deleted 
> its password `passwd -d testuser`. If I run `grep testuser /etc/shadow` it 
> reads:
> testuser::19558:0:9:7:::
> 
> I can now also login to this account on a tty without any password. `su 
> newuser` also doesn't need any password. I can also still login to the root 
> account by doing `su`.
> 
> https://sources.debian.org/src/shadow/1:4.13+dfsg1-1/src/su.c/?hl=504#L504
> 
> and
> 
> https://sources.debian.org/src/shadow/1:4.13+dfsg1-1/src/login.c/?hl=980#L980
> 
> indicate that this should not be possible. It looks like PREVENT_NO_AUTH 
> doesn't do anything at all.
> 
> This was replicated on IRC by another user too.

The shadow code enforcing PREVENT_NO_AUTH is in the !ifdef PAM case.

-serge

Bug#1038861: [Pkg-shadow-devel] Bug#1038861: login updates login.defs, adds options that old groupmod doesn't understand

[Serge E. Hallyn]

On Thu, Jun 22, 2023 at 08:13:24AM +0200, Marc Haber wrote:
> Package: login
> Version: 1:4.13+dfsg1-1+b1
> Severity: minor
> 
> Hi,
> 
> upgrading from bullseye to bookworm, during the "apt upgrade" step, it
> may happen that login updates login.defs and adds the NONEXISTENT and
> PREVENT_NO_AUTH options to login.defs. However, it is not guaranteed
> that passwd gets upgraded quickly afterwards. Old groupmod, from old
> passwd, doesn't understand the new configuration options and logs
> 
> Jun 22 07:38:41 emptybullseye99 groupmod[6828]: unknown configuration item 
> `NONEXISTENT'
> Jun 22 07:38:41 emptybullseye99 groupmod[6828]: unknown configuration item 
> `PREVENT_NO_AUTH'
> 
> Those messages also end up on the console, unfortunately without a
> prefix indicating which program caused the message. It just says
> "configuration error - unknown item NONEXISTENT". If groupmod didn't log to
> syslog as well, I would still be searching.

That does seem annoying, I don't really see any reason for those error
messages.

I filed https://github.com/shadow-maint/shadow/issues/746 about this.

> This shows, for example, when openssh-client tries to rename its ssh
> group to _ssh in postinst between the updates of login and passwd. I
> have also seen this when upgrading udev from bullseye to bookworm as it
> tries to create the new sgx group.
> 
> Functionality is not affected, the operation succeeds, but there is a
> confusing error message on the console.
> 
> Maybe it would be a good idea to have a versioned dependency between
> login and passwd, preventing the case of an old binary not fully
> understanding a new configuration file.
> 
> Greetings
> Marc
> 
> 
> -- System Information:
> Debian Release: 11.7
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.3.7-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages login depends on:
> ii  libaudit1   1:3.0-2
> ii  libc6   2.36-9
> ii  libcrypt1   1:4.4.18-4
> ii  libpam-modules  1.4.0-9+deb11u1
> ii  libpam-runtime  1.4.0-9+deb11u1
> ii  libpam0g1.4.0-9+deb11u1
> 
> login recommends no packages.
> 
> login suggests no packages.
> 
> -- Configuration Files:
> /etc/pam.d/login changed [not included]
> 
> -- no debconf information
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1035918: [Pkg-shadow-devel] Bug#1035918: shadow fr.po update

[Serge E. Hallyn]

On Thu, May 11, 2023 at 09:48:27AM +0200, bu...@no-log.org wrote:
> Package: shadow
> Version: N/A
> Severity: wishlist
> Tags: patch l10n
> 
> Dear Maintainer,
> 
> Please find attached the french updated translation of shadow-man-page,
> proofread by the debian-l10n-french mailing list contributors.
> 
> This file should be put as debian/po/fr.po in your package build tree.

Hi,

Thanks for the update.

Just as a heads-up, we applied this upstream.  We had to update it due to some
format changes.  You can see the result at

curl -L https://github.com/shadow-maint/shadow/pull/727.diff

-serge

Bug#1035021: keepass2: Keepass2 window elements is out of screen

[Serge]

Package: keepass2
Version: 2.47+dfsg-2
Severity: important

Dear Maintainer,



   just install, start and trying to add database.
Window about master password is big and bottom of window with buttons is out of 
screen.
Compaq CQ57, screen resolution is 1366x768.


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
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 keepass2 depends on:
ii  libgcrypt20  1.10.1-3
ii  libmono-corlib4.5-cil6.8.0.105+dfsg-3.3
ii  libmono-system-drawing4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-security4.0-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-windows-forms4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-system-xml4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system4.0-cil6.8.0.105+dfsg-3.3
ii  libx11-6 2:1.8.4-2
ii  mono-runtime 6.8.0.105+dfsg-3.3

Versions of packages keepass2 recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages keepass2 suggests:
pn  keepass2-doc  
pn  mono-dmcs 
pn  xdotool   

-- no debconf information

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Serge E. Hallyn]

On Mon, Mar 06, 2023 at 08:41:15PM +0100, Bálint Réczey wrote:
> Hi Alejandro,
> 
> 
> Alejandro Colomar  ezt írta (időpont: 2023.
> márc. 5., V, 20:38):
> >
> > Package: passwd
> > Source: shadow
> > Tags: patch
> > X-Debbugs-CC: Bálint Réczey 
> > X-Debbugs-CC: Iker Pedrosa 
> > X-Debbugs-CC: Serge Hallyn 
> > To: sub...@bugs.debian.org
> >
> > Hi Balint,
> >
> > This is my first patch set sent to Debbugs.  Let's see if I do it
> > correctly :).
> >
> > I can't open a MR in Salsa, since my account is still to be approved
> > (I opened it yesterday).  BTW, if you have any contacts there, please
> > have a look at it; the identifier is 'alx' and the associated email is
> > .  I sent a mail to the Salsa admin a week ago but
> > received no response (but I guess they might be busy).
> >
> > Cheers,
> >
> > Alex
> >
> > ---
> >
> > Alejandro Colomar (2):
> >   debian/control: Sort alphabetically package lists
> >   debian/control: Add libbsd-dev and pkg-config
> >
> >  debian/control | 26 ++
> >  1 file changed, 14 insertions(+), 12 deletions(-)
> >
> > Range-diff against v1:
> > -:   > 1:  3d079bd9 debian/control: Sort alphabetically package 
> > lists
> > 1:  48ac3d10 ! 2:  9e323b50 debian/control: Add libbsd-dev and pkg-config
> > @@ debian/control: Build-Depends: bison,
> >  libselinux1-dev [linux-any],
> >  libsemanage-dev [linux-any],
> >  libxml2-utils,
> > -+   pkg-config,
> > ++   pkgconf,
> 
> Thank you for the good intention, but this change won't be needed
> because pkgconf will provide pkg-config according to the plan:
> 
> https://lists.debian.org/debian-devel/2022/07/msg00252.html
> 
> Cheers,
> Balint

Hi Balint,

right now shadow is not depending on either one.  Alex is adding
the pkgconf one.  This diff is between Alex's two diffs, showing
that his first diff had added pkg-config, while v2 is instead doing
pkgconf.

-serge

Bug#1026213: [Pkg-shadow-devel] Bug#1026213: login: $HOME created as 0755 by default

[Serge E. Hallyn]

On Fri, Dec 16, 2022 at 04:14:56PM +0300, Michael Tokarev wrote:
> On Fri, 16 Dec 2022 11:50:18 + debian user  wrote:
> > Package: login
> > Version: 1:4.13+dfsg1-1
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> > X-Debbugs-Cc: r...@localhost.lan, Debian Security Team 
> > 
> > 
> > Dear Maintainer,
> > 
> > please uncomment the line in /etc/login.defs that currently says:
> > 
> > #HOME_MODE  0700
> > 
> > to say:
> > 
> > HOME_MODE  0700
> > 
> > The current settings makes user $HOME directories be created with
> > permissions where other users can read the contents by default.
> 
> I tend to disagree, the default is just fine, all the sensitive
> data (eg, .bash_history, .ssh/ etc) is already protected, there's
> absolutely nothing wrong if the files in home dirs are accessible
> by default, - for example my users complain if they can't show content
> of their own files to other users by default.  On the other hand,
> it is trivial to uncomment the HOME_MODE setting locally if the local
> policy is that users should be paranoid against each other.  It is
> just as easy to set perms of your own home dir at any time, too.
> 
> /mjt

Agreed with mjt.  As an example, unprivileged containers cannot be
started if your subuids cannot at least 'x' $HOME.  And in all the
systems I set up to share with family/friends I want to encourage
not limit sharing.

-serge

Bug#1021745: [Pkg-shadow-devel] Bug#1021745: passwd: /etc/passwd was edited with the wrong shell path

[Serge E. Hallyn]

On Fri, Oct 14, 2022 at 12:18:26AM +0200, Najib B wrote:
> Package: passwd
> Version: 1:4.12.3+dfsg1-1
> Severity: important
> X-Debbugs-Cc: najibbak...@gmail.com
> 
> Dear Maintainer,
> 
> I have just noticed this issue on chsh that I would like to report to you,
> including a solution that I would like to mention.
> 
> --
> # chsh
> Changing the login shell for root
> Enter the new value, or press ENTER for the default
> Login Shell [/bin/zsh]: zsh
> chsh: Warning: zsh does not exist
> 
> exit
> $ sudo chsh
> Password:
> chsh: PAM: Authentication failure`
> ---
> The problem here, is that chsh has accepted "zsh" without checking first, if
> that path exists.

Well no, it clearly checked, and warned you.  You chose to
ignore the warning.  If we refuse to set it, we'll get tons
of bug reports about that.  We could add a fail-on-warning
option I suppose...  But if you choose to ignore the warnings
I don't think you'd use that option.

> After exiting "root" it is not possible to login back.
> The solution is to edit /etc/passwd from this:
> root:x:0:0:root:/root:zsh
> to this:
> root:x:0:0:root:/root:/bin/zsh
> 
> Best regards,
> 
> 
> -- System Information:
> Distributor ID:   Kali
> Description:  Kali GNU/Linux Rolling
> Release:  2022.3
> Codename: kali-rolling
> Architecture: x86_64
> 
> Kernel: Linux 5.18.0-kali7-amd64 (SMP w/3 CPU threads; PREEMPT)
> 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 passwd depends on:
> ii  libaudit1   1:3.0.7-1.1
> ii  libc6   2.34-4
> ii  libcrypt1   1:4.4.28-2
> ii  libpam-modules  1.5.2-5
> ii  libpam0g1.5.2-5
> ii  libselinux1 3.4-1+b2
> ii  libsemanage23.4-1+b2
> 
> Versions of packages passwd recommends:
> ii  sensible-utils  0.0.17
> 
> passwd suggests no packages.
> 
> -- no debconf information
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#989919: login: consider setting PAM's user_readenv=1

[Serge E. Hallyn]

On Sat, Apr 09, 2022 at 06:41:47PM +0200, Christoph Anton Mitterer wrote:
> On Sat, 2022-04-09 at 08:20 -0500, Serge E. Hallyn wrote:
> > I wonder whether it was disabled
> > for security reasons?  Is there a debian bug referring to that?
> 
> Hmm could be this...
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611136
> 
> Though I don't quite understand what the attack actually is (or whether
> it was fixed - and if there is no real fix, why the pam manpages still
> don't warn from that option), since any user could just set any var in
> his .bashrc or so

Based on https://www.openwall.com/lists/oss-security/2010/09/27/7
I think the concern was that the user's env file was being read
while fsuid was still root.  I see patches fixing it in pam itself,
so I don't think the default workaround is needed.  Now, arguably,
it is a hairy bit of code, and so defaulting to not reading it
while allowing sites to override is conservative.  I guess someone
should do another code review of at least pam_env.

Bug#868568: [Pkg-shadow-devel] Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Serge E. Hallyn]

So deluser was doing the right thing, right?

The bug is how you got into this state?  Either the adduser for
the high uid should have checked for it being a delegated subuid,
or the adduser which added the subuids to the lower subuid should
have refused when the higher subuid existed as a uid.

On Tue, Mar 08, 2022 at 05:31:41PM +, Ben Harris wrote:
> I ran into a problem very similar to the one described in Debian bug 868568:
> deleting a user with a UID < 10 failed because of a process that was
> running as a user with a UID >= 10.  It turned out to be because the
> larger user ID was recorded in /etc/subuid as a subordinate user-ID for the
> lower-numbered user.  Blanking out /etc/subuid and /etc/subgid caused
> deluser to behave as normal.
> 
> According to login.defs(5), the default range of subuids starts at 10.
> If you're using UIDs over 10 for normal users then you probably want to
> change that (or find a way to disable subordinate user-IDs entirely).
> 
> -- 
> Ben Harris, University of Cambridge Information Services.
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1006216: [Pkg-shadow-devel] Bug#1006216: shadow: suggestions for man 8 groupadd

[Serge E. Hallyn]

Thank you, applied (with tiny changes) at github.com/shadow-maint/shadow.

On Mon, Feb 21, 2022 at 02:24:01PM +0100, Markus Hiereth wrote:
> Source: shadow
> Version: 4.8.1
> Severity: minor
> 
> Hi Serge,
> 
> I withdrew the changes you did not appreciate, kept the ones you did no 
> comment on and used the suggustions you made.
> 
> Attached the respective xml and diff files.
> 
> Best regards
> Markus
> 
> ----
> 
> "Serge E. Hallyn"  schrieb am 20. Februar 2022 um 10:33
> > On Thu, Feb 17, 2022 at 09:43:59PM +0100, Markus Hiereth wrote:
> > > Hi Serge,
> > > 
> > > today I worked on the message catalogue for groupadd.8
> > > 
> > > I have no problems with understanding or translating this manual
> > > page. Nevertheless there are paragraphs for which I would suggest
> > > alternatives explanations. They are alreay in an attached xml-file.
> > > 
> > > Below, there is a diff with commments that allows you to jugde the
> > > suggestions.
> > > 
> > > Feel free to tell me what changes are welcome.
> > > 
> > > Best regards
> > > Markus
> > > 
> > > 
> > > --- shadow-4.8.1/man/groupadd.8.xml   2019-07-23 17:26:08.0 
> > > +0200
> > > +++ shadow-4.8.1_mh/man/groupadd.8.xml2022-02-17 16:30:14.284465573 
> > > +0100
> > > 
> 
> > > Elsewhere, capital letters are used for such arguments 
> > > 
> > > @@ -72,10 +72,10 @@
> > >  
> > >groupadd
> > >
> > > - options
> > > + OPTIONS
> > >
> > >
> > > - group
> > > + NEWGROUP
> > >
> > >  
> > >
> > > 
> 
> > > These two paragraphs come from section CAVEATS, but I think the are
> > > necessary parts of the section DESCRIPTION
> > > @@ -87,6 +87,15 @@
> > >values from the system. The new group will be entered into the 
> > > system
> > >files as needed.
> > >  
> > > + 
> > > +   Groupnames must start with a lower case letter or an underscore,
> > > +   followed by lower case letters, digits, underscores, or dashes.
> > > +   They can end with a dollar sign.
> > > +   In regular expression terms: [a-z_][a-z0-9_-]*[$]?
> > > + 
> > > + 
> > > +   Groupnames may only be up to _NAME_MAX_LENGTH; characters 
> > > long.
> > > + 
> > >
> > > 
> > > 
> 
> > > Changed due to my different view on the attribute "unique". For me, an
> > > ID that appears only once is an unique but in our context, it always
> > > deals with the relation between names and IDs.
> > > @@ -103,10 +112,11 @@
> > >   
> > > 
> > >   This option causes the command to simply exit with success
> > > - status if the specified group already exists. When used with
> > > - -g, and the specified GID already exists,
> > > - another (unique) GID is chosen (i.e. -g is
> > > - turned off).
> > > + status if the specified group already exists. When used
> > > + with -g and the specified GID already
> > > + exists, another one is chosen. As result, option
> > > + -g is turned off and the GID points in a
> > > + unique way to NEWGROUP.
> > 
> > Sorry, the new language is confusing to me.
> > 
> > Would simply doing 's/another (unique)/a different, unused, /' be
> > clearer to you?
> 
> Yes it would.
> 
>  
> > > I just replaced "this value" with "GID" which is used in the line above
> > > 
> > > @@ -115,8 +125,8 @@
> > > -g, 
> > > --gidGID
> > >   
> > >   
> > > -   The numerical value of the group's ID. This value must be
> > > - unique, unless the -o option is used. The value
> > > +   The numerical value of the group's ID. 
> > > GID 
> > > + must be unique, unless the -o option is used. The 
> > > value
> > >   must be non-negative. The default is to use the smallest ID
> > >   value greater than or equal to GID_MIN and
> > >   greater than every other group.
> > 
> > Ok.
> 
> > > Again, "unique-and-non-unique" stuff 
> > > 
> > > @@ -159,7 +169,10 @@
>

Bug#1006225: [Pkg-shadow-devel] Bug#1006225: edited groups.1.xml and id.1.xml and diff files

[Serge E. Hallyn]

Thank you, applied.

On Wed, Feb 23, 2022 at 10:02:12AM +0100, Markus Hiereth wrote:
> Hi Serge,
> 
> On Mon, 21 Feb 2022 10:30:17 -0600 serge wrote:
> 
> attached groups.1.xml and id.1.xml and patches that replace the
> previously sent on 21 Feb 2022 17:01:53 +0100.
> 
> > Changing 'support' to 'allow' is not good.  And I do think that
> > simply referencing initgroups as I did is better than saying "by
> > using...".  Although I don't believe there's any system out there
> > which does not support initgroups.
> 
> this point made me change the respective paragraph.
> 
> In groups.1.xml in the paragraph above, xml-markup  was
> replaced by  and one removed as not necessary.
> 
> In the SEE ALSO section initgroups(3) was added.
> 
> I hope the two manual pages are done now. Best regards
> Markus


> --- ../../shadow-4.8.1/man/groups.1.xml   2019-07-23 17:26:08.0 
> +0200
> +++ groups.1.xml  2022-02-23 09:39:44.060606763 +0100
> @@ -80,16 +80,17 @@
>The groups command displays the current group names
>or ID values. If the value does not have a corresponding entry in
>/etc/group, the value will be displayed as the
> -  numerical group value. The optional  -  remap='I'>user parameter will display the groups for the
> -  named user.
> +  numerical group value. The optional user
> +  parameter will display the groups for the named user.
>  
>
>  
>
>  NOTE
>  
> -  Systems which do not support concurrent group sets will have the
> +  Systems which do not support supplementary groups (see 
> + initgroups3
> +  ) will have the
>information from /etc/group reported. The user
>must use newgrp or sg to change
>his current real and effective group ID.
> @@ -122,6 +123,9 @@
>,
>
>   getuid2
> +  ,
> +  
> + initgroups3
>.
>  
>


> --- ../../shadow-4.8.1/man/id.1.xml   2019-07-23 17:26:08.0 +0200
> +++ id.1.xml  2022-02-23 09:41:18.64038 +0100
> @@ -79,8 +79,9 @@
>have a corresponding entry in /etc/passwd or
>/etc/group, the value will be displayed without
>the corresponding name. The optional -a flag will
> -  display the group set on systems which support multiple concurrent
> -  group membership.
> +  display the group set on systems which support supplementary groups
> +  (see initgroups
> +  3).
>  
>
>  
> @@ -113,6 +114,9 @@
>,
>
>   getuid2
> +  ,
> +  
> + initgroups3
>
>  
>

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1006848: [Pkg-shadow-devel] Bug#1006848: shadow: improvements for man 8 lastlog

[Serge E. Hallyn]

Thank you, this was already addressed by:

https://github.com/shadow-maint/shadow/commit/726abe8a3260984ead9c2d57e0e5564584dc9f8f

I must have accidentally git-add'd this change from you, which you had
originally sent Dec 22, into my fix for
https://github.com/shadow-maint/shadow/issues/500 , sorry about that.

-serge

Bug#1006208: [Pkg-shadow-devel] Bug#1006208: shadow: trying to improve man pwck

[Serge E. Hallyn]

Thank you.  I will take these diffs (4 I believe?), do one final review, and
push to github.com/shadow-maint/shadow under commits with you as Author.

On Mon, Feb 21, 2022 at 12:40:07PM +0100, Markus Hiereth wrote:
> Source: shadow
> Version: 4.8.1
> Severity: minor
> 
> Dear Serge,
> 
> in accordance your mail from 2022-02-20 (attached) an edited manual xml file 
> and the respective patch file.
> 
> Best regards
> Markus

> On Wed, Feb 16, 2022 at 09:42:34PM +0100, Markus Hiereth wrote:
> > Hi Serge and shadow-utils developers
> > 
> > a few remarks on this manual page. I do not know whether a bug report
> > or a patch are appreciated.
> > 
> > Best regards
> > Markus
> > 
> > 
> > 69   
> > 70 pwck
> > 71 verify integrity of password files
> > 72   
> >  
> > s/verify integrity/verify the integrity
> > 
> > 
> > 
> > 75 
> > 76   pwck
> > 77   options
> > 78   
> > 79 
> > 80   passwd
> > 81 
> > 82 
> > 83   
> > 84 shadow
> > 85   
> > 86 
> > 87   
> > 88 
> > 
> > Replaceables appear in capital letters elsewhere, the name of the
> > argument shall indicate that the name of the two files is not
> > pre-defined, thus write:
> > 
> > 80   PASSWORDFILE
> > 84   SHADOWFILE
> > 
> > 
> > 
> > 128   shadow checks are enabled when a second file
> > 129   parameter is specified or when /etc/shadow
> > 130   exists on the system.
> > 
> > I think "shadow" in "shadow checks" is meant in a general
> > sense. Therefore, if xml is used for mark-up, it should not be the filename 
> > element, but the replaceable element. Or write:
> > 
> > 128 Checks for shadowed password information are enabled when a second 
> > 129 file parameter is specified or when /etc/shadow
> 
> That's all fine.
> 
> > 
> > 
> > 162 checks will still be made. All other errors are warning and the user
> > 163 is encouraged to run the usermod command to 
> > correct
> > 
> > Is "warning" here the participe present from the verb "to warn". In
> > case it is the plural of the noun "a warning", add the plural-s. Or write:
> > 
> > ... All other errors warn the user and encourage him to run the 
> > usermod
> 
> It's just meant as the plural of warning, so simplest would be to just
> say 'All other errors are warnings and..." 
> 
> thanks,
> -serge

> --- shadow-4.8.1/man/pwck.8.xml   2019-10-05 03:23:58.0 +0200
> +++ shadow-4.8.1_mh/man/pwck.8.xml2022-02-21 12:30:25.634576331 +0100
> @@ -68,7 +68,7 @@
>
>
>  pwck
> -verify integrity of password files
> +verify the integrity of password files
>
>
>
> @@ -77,11 +77,11 @@
>options
>
>   
> -   passwd
> +   PASSWORDFILE
>   
>   
> 
> - shadow
> + SHADOWFILE
> 
>   
>
> @@ -123,11 +123,10 @@
>   a valid login shell
>
>  
> -
>  
> -  shadow checks are enabled when a second file
> -  parameter is specified or when /etc/shadow
> -  exists on the system.
> +  Checks for shadowed password information are enabled when the second
> +  file parameter SHADOWFILE is specified or
> +  when /etc/shadow exists on the system.
>  
>  
>These checks are the following:
> @@ -159,7 +158,7 @@
>prompted to delete the entire line. If the user does not answer
>affirmatively, all further checks are bypassed. An entry with a
>duplicated user name is prompted for deletion, but the remaining
> -  checks will still be made. All other errors are warning and the user
> +  checks will still be made. All other errors are warnings and the user
>is encouraged to run the usermod command to correct
>the error.
>  

> 
> 
>"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
> 
> 
> 
> 
> 
> 
> 
> ]>
> 
>   
>   
> 
>   Julianne Frances
>   Haugh
>   Creation, 1992
> 
> 
>   Thomas
>   Kłoczko
>   kloc...@pld.org.pl
>   shadow-utils maintainer, 2000 - 2007
> 
> 
>   Nicolas
>   François
>   nicolas.franc...@centraliens.net
>   sha

Bug#1005253: [Pkg-shadow-devel] Bug#1005253: Bug#1005253: shadow: Improved manual page useradd.8

[Serge E. Hallyn]

On Fri, Feb 11, 2022 at 07:14:27PM +0100, Markus Hiereth wrote:
> Hi Serge,
> 
> "Serge E. Hallyn"  schrieb am 11. Februar 2022 um 18:13
>  
> > Thanks.  The diff is especially helpful.  Although a few of these hunks
> > appear to be just changes to the line breaks.
> 
> > > @@ -219,14 +221,17 @@
> > >   
> > >   
> > > 
> > > - The number of days after a password expires until the account is
> > > - permanently disabled. A value of 0 disables the account as soon
> > > - as the password has expired, and a value of -1 disables the
> > > - feature.
> > > +defines the number of days after the password exceeded its 
> > > maximum
> > > +age where the user is expected to replace this password. The 
> > > value
> > 
> > How about 'number of days after the password exceeded its maximum
> > age during which the user may login by immediately replacing this
> > password. The value is stored in the shadow password file.'
> 
> I also thought that there is something better then "where the user..."

Actually how about "may still login by..."

> > > 
> > >   If not specified, useradd will use the
> > > - default inactivity period specified by the
> > > + default inactivity onset specified by the
> > 
> > "onset" is weird here.
> 
> I looked up in a dictionary: "onset is the first attack or beginning
> (of something bad)" . There are similar usages: "onset of winter", a
> "hard onset" in phonetics, in medicine they speak of the "onset" of a
> disease.
> 
> What do you think of "begin of inactivity"?
> 
> You know I also suggested "grace period". But, expressing it this way,
> the connection to inactivity gets lost.
> 
> I really dislike "inactivity period" as the user does not define the
> duration of inactivity but the number of days he will be able to do
> something against a shift of his account into the inactive state.

Grace period is good, actually.  How about
"grace period before the account becomes inactive"?

> > >   INACTIVE variable in
> > >   /etc/default/useradd, or -1 by default.
> > > 
> > > @@ -237,8 +242,9 @@
> > > -g, 
> > > --gidGROUP
> > >   
> > >   
> > > +   
> > 
> > This i assume is leftover marker to be dropped.
> 
> Sure.
> 
> 
> > > @@ -398,10 +407,18 @@
> > > -o, --non-unique
> > >   
> > >   
> > > -   Allow the creation of a user account with a duplicate 
> > > (non-unique) UID.
> > > +   
> > > + allows the creation of an account with an already existing
> > > + UID.
> > > +   
> > > 
> > >   This option is only valid in combination with the
> > > - -u option.
> > > + -u option. As a user identity
> > > + serves as
> > > + key to map between users on one hand and permissions, file
> > > + ownerships and other aspects that determine the system's
> > > + behavior on the other hand, more than one login name
> > > + will access the account of the given UID.
> > > 
> > >   
> > >
> > > @@ -410,14 +427,25 @@
> > > -p, 
> > > --passwordPASSWORD
> > >   
> > >   
> > > +   
>  
> > Drop this?
> 
> yes
> 
>  
> > > @@ -488,11 +516,11 @@
> > >   
> > >   
> > > 
> > > - The name of the user's login shell. The default is to leave this
> > > - field blank, which causes the system to select the default login
> > > - shell specified by the SHELL variable in
> > > - /etc/default/useradd, or an empty string
> > > - by default.
> > > +sets the path to the user's login shell. Without this option,
> > > +the system will use the SHELL variable 
> > > specified
> > > + in /etc/default/useradd, or, if that is as
> > > + well not set, the field for the login shell in /etc/passwd
> > > + remains empty.
> > > 
> > >   
> > >
> > > @@ -533,13 +561,16 @@
> > >
> > >
> > >   
> > > -   -Z, 
> > > --selinux-userSEUSER
> > > +   -Z, --selinux
> > > +   -userSEUSER
>  
> > Is the line break here accidental?
&g

Bug#1005253: [Pkg-shadow-devel] Bug#1005253: shadow: Improved manual page useradd.8

[Serge E. Hallyn]

On Wed, Feb 09, 2022 at 11:18:04PM +0100, Markus Hiereth wrote:
> Source: shadow
> Version: 4.8.1
> Severity: normal
> 
> Dear Serge,
> 
> attached to this bugreport the improved file useradd.8.xml and a diff.
> A last check is certainly reasonable.

Thanks.  The diff is especially helpful.  Although a few of these hunks
appear to be just changes to the line breaks.

...

> --- shadow-4.8.1/man/useradd.8.xml2020-01-17 16:47:56.0 +0100
> +++ shadow-4.8.1_mh/man/useradd.8.xml 2022-02-09 23:09:13.241687932 +0100
> @@ -143,11 +143,11 @@
>   
>   
> 
> - The default base directory for the system if 
> -dHOME_DIR is not specified.
> - BASE_DIR is
> - concatenated with the account name to define the home directory. 
> - If the -m option is not used,
> - BASE_DIR must exist.
> + The default base directory for the system if
> + -dHOME_DIR
> + is not specified.  BASE_DIR is
> + concatenated with the account name to define the home
> + directory.
> 
> 
>   If this option is not specified, useradd
> @@ -165,7 +165,7 @@
>   
> 
>   Any text string. It is generally a short description of the
> - login, and is currently used as the field for the user's full
> + account, and is currently used as the field for the user's full
>   name.
> 
>   
> @@ -177,12 +177,14 @@
>   
> 
>   The new user will be created using
> - HOME_DIR as the value for the user's
> - login directory. The default is to append the
> + HOME_DIR as the value for the
> + user's login directory. The default is to append the
>   LOGIN name to
> - BASE_DIR and use that as the login
> - directory name. The directory HOME_DIR
> - does not have to exist but will not be created if it is missing.
> + BASE_DIR and use that as the
> + login directory name.  If the directory
> + HOME_DIR does not exist, then
> + it will be created unless the -M option
> + is specified.
> 
>   
>
> @@ -219,14 +221,17 @@
>   
>   
> 
> - The number of days after a password expires until the account is
> - permanently disabled. A value of 0 disables the account as soon
> - as the password has expired, and a value of -1 disables the
> - feature.
> +defines the number of days after the password exceeded its 
> maximum
> +age where the user is expected to replace this password. The 
> value

How about 'number of days after the password exceeded its maximum age
during which the user may login by immediately replacing this password. The 
value
is stored in the shadow password file.'

> +is stored in the shadow password file. An input of 0 will 
> disable an
> +expired password with no delay. An input of -1 will blank the
> +respective field in the shadow password file. See 
> + shadow5
> +for more information.
> 
> 
>   If not specified, useradd will use the
> - default inactivity period specified by the
> + default inactivity onset specified by the

"onset" is weird here.

>   INACTIVE variable in
>   /etc/default/useradd, or -1 by default.
> 
> @@ -237,8 +242,9 @@
> -g, 
> --gidGROUP
>   
>   
> +   

This i assume is leftover marker to be dropped.

> 
> - The group name or number of the user's initial login group. The
> + The name or the number of the user's primary group. The
>   group name must exist. A group number must refer to an already
>   existing group.
> 
> @@ -249,7 +255,7 @@
>   set to yes (or
>   -U/--user-group is specified on the command
>   line), a group will be created for the user, with the same
> - name as her loginname. If the variable is set to
> + name as the loginname. If the variable is set to
>   no (or
>   -N/--no-user-group is specified on the
>   command line), useradd will set the primary group of the new
> @@ -315,14 +321,17 @@
>   (UID_MIN, UID_MAX,
>   UMASK, PASS_MAX_DAYS
>   and others).
> -   
> 
> - Example: 
> -KPASS_MAX_DAYS=-1
> - can be used when creating system account to turn off password
> - aging, even though system account has no password at all.
> - Multiple -K options can be speci

Bug#1004472: [Pkg-shadow-devel] Bug#1004472: setup had to be performed / still another problem

[Serge E. Hallyn]

On Fri, Jan 28, 2022 at 12:26:00PM +0100, Markus Hiereth wrote:
> Dear Maintainer,
> 
> the previously reported p
> roblem is quite probable due to fact that the setup instruction on groupmems 
> hadn't be performs.

Ah, I see, manpage recommends setgid.  The instructions in
the manpage are definitely not right, though.  For instance,
they say to chown groupmems after the chmod, but the chown
will negate the chmod.

More importantly, groupmems will try to open a file called
/etc/group.$pid, which it will not be allowed to do just by
virtue of being setuid-group 'groups'.

So yes, the recommended setup can't work.  I wonder whether
anyone actually uses groupmems, or whether we should deprecate
it.

Bug#1004472: [Pkg-shadow-devel] Bug#1004472: groupmem: make authentification clear and check interaction with PAM

[Serge E. Hallyn]

On Fri, Jan 28, 2022 at 11:29:49AM +0100, Markus Hiereth wrote:
> Package: passwd
> Version: 1:4.8.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> 
> Checks made for translation of man 8 groupmems 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Try to invoke groupmems as user and as systemadministrator
> 
>* What was the outcome of this action?
> 
> groupmems asked in both cases for authentification by a password, but does 
> not specify which password is expected. There are three possibilies
> a) root password from root (however, this does not make much sense)
> b) user password for group-owning user (however, this does not make much 
> sense)  
> c) the group's password
> 
> In all cases, I got a PAM authentification failure
> 
>* What outcome did you expect instead?
> 
> A snippet from the logfile is attached
> 
> Best regards
> Markus

This is not a well understood - or well documented - command.

In order for unprivileged users to use groupmems, you must make
it setuid-root:  'chmod u+s /usr/sbin/groupmems'.

After I do this, I as user serge in group serge can do

groupmems -a testuser

to add user testuser to my group serge.  I do have to provide
my own password.

-serge

Bug#1004007: freecad: Segfaults on armhf when clicking "Ceate New..." or File -> New

[serge]

On Thu, 2022-01-20 at 12:42 +, se...@raspberrypi.com wrote:
> A bit of a follow-up - I just found that running with
> LIBGL_ALWAYS_INDIRECT=true gets rid of the black triangle problem.
> 

Okay sorry, the black triangle issue just doesn't occur right away
every time, and LIBGL_ALWAYS_INDIRECT doesn't actually fix it.

Bug#1004007: freecad: Segfaults on armhf when clicking "Ceate New..." or File -> New

[serge]

A bit of a follow-up - I just found that running with
LIBGL_ALWAYS_INDIRECT=true gets rid of the black triangle problem.

Bug#1004007: freecad: Segfaults on armhf when clicking "Ceate New..." or File -> New

[serge]

On Wed, 2022-01-19 at 17:15 +0100, Tobias Frost wrote:
> 
> However, you might want to see if cherry-picking the mentioned patch
> in
> #969230 (https://github.com/coin3d/coin/pull/404/files) and recompile
> the
> coin3 Debian package locally with that patch.. Maybe this does
> something for you
> and helps pin-pointing the problem.
> 

Many thanks, Tobias! That does indeed fix the crash, but then the
window doesn't render properly.

Hopefully the attachment goes through, but if not, is looks like the
context is divided into two triangles and the bottom left half is just
black. There are two contexts like that which overlap, leaving most of
the screen black.

Kind regards,

Serge

Bug#1004007: freecad: Segfaults on armhf when clicking "Ceate New..." or File -> New

[Serge Schneider]

Package: freecad
Version: 0.19.1+dfsg1-2
Severity: important
X-Debbugs-Cc: se...@raspberrypi.com

Dear Maintainer,

When running FreeCAD, creating a new file crashes with a segfault:

connect failed: No such file or directory
Program received signal SIGSEGV, Segmentation fault.
#0  /lib/arm-linux-gnueabihf/libc.so.6(+0x2acb0) [0xb4aaacb0]
FreeCAD 0.19, Libs: 0.19R
© Juergen Riegel, Werner Mayer, Yorik van Havre and others 2001-2021
FreeCAD is free and open-source software licensed under the terms of LGPL2+ 
license.
FreeCAD wouldn't be possible without FreeCAD community.
  #   ###     
  ##  # #   #   # 
  # ##     # #   #  #   # 
    # # #  # #  #  # #  #   # 
  # #      ## # #   # 
  # #   ## ## # #   #  ##  ##  ##
  # #       ### # #    ##  ##  ##


This is the same issue as #931458, which was closed because it was reported 
against Raspbian's packages.
However, the issue is reproducible in Debian too (using 
20210823_raspi_2_bullseye.img.xz).

The crash seems to have something to do with how Ccoin3D creates the context in 
Qt.

Rebuilding FreeCAD against Qt4 rather than Qt5 makes it work. It also works on 
arm64.

The main difference I can see is that Qt is built with OpenGL support on arm64, 
but only OpenGL ES support on armhf.

The issue has also been reported upstream at 
https://tracker.freecadweb.org/view.php?id=4083, but there hasn't been any 
progess in a few years.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.0-8-armmp (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.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 freecad depends on:
ii  freecad-python3  0.19.1+dfsg1-2

Versions of packages freecad recommends:
ii  calculix-ccx  2.17-3
ii  graphviz  2.42.2-5

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#989712: Bug#992578: login: please add support for DPKG_ROOT

[Serge E. Hallyn]

On Fri, Sep 24, 2021 at 08:13:22AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi Balint & Serge,
> 
> Quoting Johannes Schauer Marin Rodrigues (2021-08-20 14:45:14)
> > For your convenience, I created a salsa MR that fixes #989712 as well as
> > #992578:
> > 
> > https://salsa.debian.org/debian/shadow/-/merge_requests/15
> > 
> > With this patch, a chroot created with DPKG_ROOT will be bit-by-bit 
> > identical
> > to one created normally, see
> > https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs
> 
> would you mind me applying the above merge request and doing an NMU of shadow?
> 
> Thanks!
> 
> cheers, josch

I'm not package maintainer, but it looks fine to me.

thanks,
-serge

Bug#980230: fonts-allerta is proposing 2 font files but LibreOffice is proposing only one

[Serge Pouliquen]

Hi,

I took time to make some tests with files from official website.
The problem is still present with libreoffice.
Is there a debian page about stuff to check when a font is not appearing 
in font list ?


Debian files looks not up to date.
md5sum for debian files
b0b0b4e19b80cf1efe2074ac45066130 
/usr/share/fonts/opentype/allerta/allerta_medium.otf
46019393b8fc0cc3a55684c18ab36f4e 
/usr/share/fonts/opentype/allerta/allerta_stencil.otf

md5sum for official website
5c452f83f43801f04eff595b0e8a8835  allerta_medium.otf
5ded992908f415149c9de35c73adbf70  allerta_stencil.otf

I tried to open official otf files with font forge, I got a warning message:
This font contains both a kern table and a GPOS table.
  The kern table will only be read if there is no kern feature in GPOS
Warning: Mac and Windows entries in the name table differ for the
  Fullname string in the language English (US)
  Mac String: Allerta Medium
  Windows String: Allerta-Medium

I'm not a font specialist. Is it possible that there is any relation ?

Regards,
Serge

On 20/01/2021 21:01, Matt McInerney wrote:
I'm not familiar with this issue, but you can try downloading the 
original files here: http://pixelspread.com/allerta/ 
<http://pixelspread.com/allerta/>

There are two weights in a few different file types you can try

Bug#990350: [Pkg-shadow-devel] Bug#990350: shadow: spurious subuid/subgid entries

[Serge E. Hallyn]

On Sat, Jun 26, 2021 at 05:57:02PM +0200, Christoph Anton Mitterer wrote:
> Source: shadow
> Version: 1:4.8.1-1
> Severity: normal
> 
> 
> Hey there.
> 
> 
> I've recently noted that some of my systems had entries like
> 
> $ cat /etc/subuid
> debian-security-support:10:65536
> lightdm:427680:65536
> _apt:493216:65536
> 
> $ cat /etc/subgid
> debian-security-support:10:65536
> lightdm:427680:65536
> _apt:493216:65536
> 
> 
> While in a freshly debootstrapped chroot, with the same packages installed
> there is neither of these entries.
> 
> I tried to find out whther these packages themselves ever manually added
> the entries, but it doesn't seem so, the just call adduesr.

adduser does not create the entries, but useradd does.  That is because
useradd ships from the shadow soure package, adduser does not.

> After a while of trying I've noted - and this is the main reason for this
> (possible) bug - that entries are created for normal users, but not for
> system users.
> 
> No sure if this is by accident - if not, it should perhaps at least documented
> in the manpage.

The fact that it doesn't happen for system users is not clearly spelled
out, you're right.

> It's still a bit strange though, that I see exactly those entries from
> above in my files, cause when I look at my passwd it has:
> ...
> dnsmasq:x:120:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
> dcmtk:x:122:139::/var/lib/dcmtk/db:/bin/sh
> debian-security-support:x:123:140:Debian security support 
> check,,,:/var/lib/debian-security-support:/bin/false
> uuidd:x:100:102::/run/uuidd:/usr/sbin/nologin
> lightdm:x:128:146:Light Display Manager:/var/lib/lightdm:/bin/false
> _apt:x:129:65534::/nonexistent:/usr/sbin/nologin
> libvirt-qemu:x:64055:127:Libvirt Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin
> ...
> 
> Now let's assume the behaviour of adding subuid/subgid entries started some
> time after my dcmtk was created... and ended for system users some time
> before libvirt-qemu was created...
> then it still doesn't explain why uuidd, which was chronologically likely in
> between, didn't get one.

Could adduser vs useradd explain it?

> Cheers,
> Chris.
> 
> PS: Is there recommended way to add the subuid/subgid entries for all those
> users/groups that were created before this was introduced and which would
> get them, were they created now?

You could script that through usermod, but it might be worth explicitly
adding a usermod flag to say 'only add subuid if it doesn't already
have one'

Bug#928176: vlc: BOBOOvlc cannot play cd audio without net connection and crash

[Serge Pouliquen]

Hello,

In https://trac.videolan.org/vlc/ticket/25252, upstream answer :

> That CDDB bug was fixed 9 years ago in VLC contribs. Complain to Debian.

Can you have a look on debian side ?

I made test with fedora 33 live + install proccess 
(https://www.videolan.org/vlc/download-fedora.html).

vlc is functional.

Regards,
Serge

Bug#944816: thunar: Failed to trash file (stored on / partition) only proposing to permanently delete it

[Serge Pouliquen]

Hello,

I made some test with bullseye (testing), and that issue is still present.

Regards,
Serge


On 15/11/2019 22:00, Serge Pouliquen wrote:

Package: thunar
Version: 1.8.4-1
Severity: normal

Dear Maintainer,


My system has 2 partitions / and /home.
I tried to trash a file (as a non-root user). The user has the right to delete.
My uid is 1000. When I choose 'Move to Wastebasket', Thunar is proposing me to 
'Cancel' or 'Delete permanently'.
I was expecting a file added in wastebasket.

I tried to create /.Trash and /.Trash-1000 with and without sticky bit as 
indicated in trash spec [1]
ls -la /
drwxrwxrwt   2 rootroot 4096 Nov 15 21:31 .Trash
drwxr-xr-t   2 sp31415 sp31415  4096 Nov 14 23:21 .Trash-1000

I didn't find any workaround. If I misunderstood the document [1], can you take 
some time to explain me my failure.

[1] https://specifications.freedesktop.org/trash-spec/trashspec-latest.html



-- System Information:
Debian Release: 10.1
   APT prefers stable-updates
   APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 
'oldstable-updates'), (700, 'oldstable'), (58, 'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.4-1
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libexo-2-0  0.12.4-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u1
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.4-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.4-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  gvfs  1.38.1-5
ii  libcairo-gobject2 1.16.0-4
ii  libpangocairo-1.0-0   1.42.4-7~deb10u1
ii  libxfce4panel-2.0-4   4.12.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 0.9.1-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-4
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

Bug#980230: fonts-allerta is proposing 2 font files but LibreOffice is proposing only one

[Serge Pouliquen]

Package: fonts-allerta
Version: 2.01+dfsg1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I installed the package fonts-allerta
I opened LibreOffice and tried to select allerta fonts.
According to my understanding, there are 2 fonts : Allerta Stencil and Allerta 
Regular.
When I sellect Allerta with Libre Office text is written with Allerta Stencil.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I didn't tried to rename font Family name with FontForge in order to have 2 
different names. It may solve.

   * What was the outcome of this action?
Nothing at the moment

   * What outcome did you expect instead?
Be able to select the 2 font in LibreOffice


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#928176: vlc: BOBOOvlc cannot play cd audio without net connection and crash

[Serge Pouliquen]

Hi,

issue is still present in current version.
reported upstream as  https://trac.videolan.org/vlc/ticket/25252

Regards,
Serge

Bug#973882: RFS: elfio/3.8-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: elfio
   Version : 3.8-1
   Upstream Author : Serge Lamikhov-Center 
 * URL : http://serge1.github.io/ELFIO
 * License : Expat
 * Vcs : https://github.com/serge1/ELFIO
   Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.8-1.dsc

Changes for the initial release:

 elfio (3.8-1) unstable; urgency=medium
 .
   * Initial release (closes: #839382)
   * new upstream version
   * 'copyright' name has been changed to Expat
   * 'watch' file has been updated
   * signing key has been added
   * 'metadata' file added
   * doc-base control file added
   * Passes lintian check with command line:
 lintian -EviIL +pedantic --profile debian --show-overrides \
 elfio_3.8-1_amd64.changes

Initially, the package was requested as a dependency for Apache Mesos (#839382).
The library is used by many processor design companies, academic institutions, 
performance
researchers and other development.

Regards,
--
  Serge Lamikhov-Center

Bug#969789: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: elfio
   Version : 3.7-1
   Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : Expat
* Vcs : https://github.com/serge1/ELFIO
   Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (closes: #839382)
   * 'copyright' name has been changed to Expat
   * 'watch' file has been updated
   * signing key has been added
   * 'metadata' file added
   * doc-base control file added
   * Passes lintian check with command line:
 lintian -EviIL +pedantic --profile debian --show-overrides \
 elfio_3.7-1_amd64.changes

Initially, the package was requested as a dependency for Apache Mesos (#839382).
The library is used by many processor design companies, academic institutions, 
performance
researchers.
FreeBSD OS already packages the library.

Regards,
Serge

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

On Sun, Sep 06, 2020 at 12:20:24AM +0200, Chris Hofstaedtler wrote:
> * Serge E. Hallyn  [200905 22:19]:
> > On Mon, May 01, 2017 at 04:47:17PM +0200, Michael Biebl wrote:
> > > On Tue, 16 Aug 2016 15:26:46 -0500 "Serge E. Hallyn" 
> > > wrote:
> > For what it's worth, we had retired cgmanager upstream, but I'm now
> > considering either picking it back up, or actually starting from scratch
> > (mainly to drop the 'libnih' dependency which is pretty problematic)
> 
> Apparently the upstream repository is now marked as "Archived".
> 
> > > There is elogind [1], which is a standalone logind implementation which
> > > doesn't require systemd-shim and cgmanager.
> > > This might be an alternative approach to provide the logind interfaces
> > > under sysvinit.
> 
> elogind seems to be in Debian now.
> 
> 
> Serge, what's the current upstream status, or would it make more
> sense to RM cgmanager now?

Indeed, RM makes most sense.

Bug#969789: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: elfio
   Version : 3.7-1
   Upstream Author : Serge Lamikhov-Center 
 * URL : http://serge1.github.io/ELFIO
 * License : Expat
 * Vcs : https://github.com/serge1/ELFIO
   Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

 elfio (3.7-1) unstable; urgency=medium
 .
   * Initial release (Closes: #839382)
   * 'watch' file has been updated
   * Passes lintian check with command line:
 lintian --profile debian -i -I --show-overrides elfio_3.7-1_amd64.changes \
   --profile debian

Initially, the package was requested as a dependency for Apache Mesos (#839382).
The library is used by many processor design companies, academic institutions, 
performance
researchers.
FreeBSD OS already packages the library.

Regards,
--
  Serge Lamikhov-Center

Bug#969789: RFS: elfio/3.7-1 [ITP] -- C++ header-only library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: elfio
  Version : 3.7-1
  Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* Vcs : https://github.com/serge1/ELFIO
  Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Initially, the package was requested as a dependency for Apache Mesos (#839382).
The library is used by many processor design companies and academic 
institutions.


Regards,
--
  Serge Lamikhov-Center

Bug#839382: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name    : elfio
  Version : 3.7-1
  Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* Vcs : https://github.com/serge1/ELFIO
  Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Initially, the package was requested as a dependency of Apache Mesos.

P.S. For some reason mails sent to sub...@bugs.debian.org and 
839...@bugs.debian.org didn’t reach
Mentor’s mailing list. I apologize if this correspondence will be duplicated.

Regards,
--
  Serge Lamikhov-Center
  

Bug#839382: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: elfio
  Version : 3.7-1
  Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* Vcs : https://github.com/serge1/ELFIO
  Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Initially, the package was requested as a dependency of Apache Mesos.

P.S. For some reason mails sent to sub...@bugs.debian.org and 
839...@bugs.debian.org didn’t reach
Mentor’s mailing list. I apologize if this correspondence will be duplicated.

Regards,
--
  Serge Lamikhov-Center
  

Bug#839382: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: elfio
  Version : 3.7-1
  Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* Vcs : https://github.com/serge1/ELFIO
  Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Initially, the package was requested as a dependency of Apache Mesos.


Regards,
--
  Serge Lamikhov-Center

Bug#839382: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: elfio
   Version : 3.7-1
   Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* Vcs : https://github.com/serge1/ELFIO
   Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Regards,
--
  Serge Lamikhov-Center

Bug#839382: RFS: elfio/1.0-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: elfio
   Version : 3.7-1
   Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* Vcs : https://github.com/serge1/ELFIO
   Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Regards,
--
  Serge Lamikhov-Center

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

On Sun, Sep 06, 2020 at 12:20:24AM +0200, Chris Hofstaedtler wrote:
> * Serge E. Hallyn  [200905 22:19]:
> > On Mon, May 01, 2017 at 04:47:17PM +0200, Michael Biebl wrote:
> > > On Tue, 16 Aug 2016 15:26:46 -0500 "Serge E. Hallyn" 
> > > wrote:
> > For what it's worth, we had retired cgmanager upstream, but I'm now
> > considering either picking it back up, or actually starting from scratch
> > (mainly to drop the 'libnih' dependency which is pretty problematic)
> 
> Apparently the upstream repository is now marked as "Archived".
> 
> > > There is elogind [1], which is a standalone logind implementation which
> > > doesn't require systemd-shim and cgmanager.
> > > This might be an alternative approach to provide the logind interfaces
> > > under sysvinit.
> 
> elogind seems to be in Debian now.
> 
> 
> Serge, what's the current upstream status, or would it make more
> sense to RM cgmanager now?

Hi,

the main problem with cgmanager was that it was based on libnih and
so inherited it's penchant for using select(), so it was easy to make
it crash by running out of selectable fds.

Bug#960616: ITP: nextpnr -- FPGA place-and-route tool

[Serge Cohen]

Hi there,

This is great news, as a replacement for archne-pnr !

Any intention/idea/knowledge about packaging also Project X-ray. Indeed there 
are also quite some «small» FPGA boards based on Artix-7 which would be very 
nice to be able to use through a completely open-source and packaged workflow ?

Amongst others, the ZTEX boards or some digilent boards … relatively not so 
expensive hardware with more powerful FPGA (including DSP, BRAM… slices).

Cheers,

Serge.

> Le 14 mai 2020 à 19:19, Nathaniel Graff  a écrit :
> 
> Package: wnpp
> Owner: Nathaniel Graff 
> Severity: wishlist
> X-Debbugs-CC: debian-scie...@lists.debian.org
> 
> * Package name: nextpnr
>  Version : 0~2020507gitfaf07a
>  Upstream Author :
>   Claire Wolf 
>   David Shah 
>   Dan Gisselquist 
>   Serge Bazanski 
>   Miodrag Milanovic 
>   Eddie Hung 
> * URL : https://github.com/YosysHQ/nextpnr
> * License : ISC
>  Programming Lang: C++
>  Description : FPGA place-and-route tool
> 
> nextpnr is a vendor-neutral, timing-driven, FOSS FPGA place-and-route
> tool. It is the successor to arachne-pnr, which is no longer maintained.
> Including nextpnr in Debian will allow current users of yosys and
> fpga-icestorm to make use of the latest development on the YosysHQ FPGA
> toolchain for Lattice iCE40 FPGAs.
> 
> This initial packaging effort will create three binary packages:
> - nextpnr-generic
> - nextpnr-ice40
> - nextpnr-ice40-qt
> 
> These binary packages span two different FPGA architectures (a generic
> target and Lattice iCE40 FPGAs) and a version for iCE40 FPGAs which
> features a Qt GUI.
> 
> Since nextpnr can be extended to support additional FPGA architectures
> (unlike its predecessor arachne-pnr), future work can extend this
> initial effort to support FPGA architectures like Lattice ECP5 and
> Xilinx 7-Series FPGAs using Project Trellis and Project X-Ray.
> 
> Keith Packard has offered to sponsor the upload.
> 
> Ongoing packaging effort is taking place on Salsa:
> https://salsa.debian.org/nategraff-guest/nextpnr
> 



signature.asc
Description: Message signed with OpenPGP

Bug#941005: [Pkg-shadow-devel] Bug#941005: Bug#941005: shadow uses obsolete SELinux API

[Serge E. Hallyn]

On Sat, Nov 30, 2019 at 06:47:28PM +0100, Christian Göttsche wrote:
> As the change got merged upstream [1], and upstream releases roughly
> once a year, any chance this gets cherry-picked in the next Debian

Digs aside, the goal is 4x/year, and the next one is scheduled for December.
I was intending to do it next week.

> upload?
> 
> [1] 
> https://github.com/shadow-maint/shadow/commit/a8a921184fdf950194cb887d241e0cbc588759c4
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#944816: thunar: Failed to trash file (stored on / partition) only proposing to permanently delete it

[Serge Pouliquen]

Package: thunar
Version: 1.8.4-1
Severity: normal

Dear Maintainer,


My system has 2 partitions / and /home.
I tried to trash a file (as a non-root user). The user has the right to delete.
My uid is 1000. When I choose 'Move to Wastebasket', Thunar is proposing me to 
'Cancel' or 'Delete permanently'.
I was expecting a file added in wastebasket.

I tried to create /.Trash and /.Trash-1000 with and without sticky bit as 
indicated in trash spec [1]
ls -la /
drwxrwxrwt   2 rootroot 4096 Nov 15 21:31 .Trash
drwxr-xr-t   2 sp31415 sp31415  4096 Nov 14 23:21 .Trash-1000

I didn't find any workaround. If I misunderstood the document [1], can you take 
some time to explain me my failure.

[1] https://specifications.freedesktop.org/trash-spec/trashspec-latest.html



-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 
'oldstable-updates'), (700, 'oldstable'), (58, 'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.4-1
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libexo-2-0  0.12.4-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u1
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.4-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.4-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  gvfs  1.38.1-5
ii  libcairo-gobject2 1.16.0-4
ii  libpangocairo-1.0-0   1.42.4-7~deb10u1
ii  libxfce4panel-2.0-4   4.12.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 0.9.1-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-4
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

Bug#857805: [Pkg-shadow-devel] Bug#857805: Bug#857805: shadow: please run the testsuite

[Serge E. Hallyn]

Yes, I'd actually like to have a make option to run the tests in a
container, but I also had some trouble running the tests.  Need a
"known to fail" option per test might be a good way to get moving
on this.  Please keep me in the loop if/as you work on this.

On Mon, Nov 11, 2019 at 04:36:32PM +0100, Bálint Réczey wrote:
> Hi Chris,
> 
> Chris Lamb  ezt írta (időpont: 2019. nov. 11., H, 16:15):
> >
> > Hi Bálint,
> >
> > > I have started experimenting with the tests but they are failing.
> > > Maybe with upstream's help we can enable them for later upstream releases.
> >
> > Good shout. I wonder if it would be helpful to mark them as "known
> > failing" in some way ("|| true" or equivalent...) just so we have the
> > [failing] logs to point upstream at?
> 
> Upstream dropped the tests from the 4.7 release tarball, but this is
> where we are heading.
> I added a link to the failing pipelines.
> 
> Cheers,
> Balint
> 
> >
> >
> > Regards,
> >
> > --
> >   ,''`.
> >  : :'  : Chris Lamb
> >  `. `'`  la...@debian.org chris-lamb.co.uk
> >`-
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#942680: [Pkg-shadow-devel] Bug#942680: passwd: vipw does not resume properly when suspended

[Serge E. Hallyn]

Thanks,

second option sounds nicer but sure is a lot more code.  So I'm
leaning towards the first.  Do you  mind creating a github issue
at github.com/shadow-maint/shadow for this, or would you prefer that
I do it?

-serge

On Sat, Oct 19, 2019 at 04:20:11PM -0600, Todd C. Miller wrote:
> Package: passwd
> Version: 1:4.5-1.1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> If vipw is suspended (e.g. via control-Z) and then resumed, it
> often gets immediately suspended.  This is easier to reproduce
> on a multi-core system.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  
> root@buster:~# /usr/sbin/vipw
> 
> [1]+  Stopped /usr/sbin/vipw
> root@buster:~# fg
> /usr/sbin/vipw
> 
> [1]+  Stopped /usr/sbin/vipw
> 
> root@buster:~# fg
> [vipw resumes on the second fg]
> 
> The problem is that vipw forks a child process and calls waitpid()
> with the WUNTRACED flag.  When the child process (running the editor)
> is suspended, the parent sends itself SIGSTOP to suspend the main vipw
> process.  However, because the main vipw is in the same process group
> as the editor which received the ^Z, the kernel already sent the
> main vipw SIGTSTP.
> 
> If the main vipw receives SIGTSTP before the child, it will be
> suspended and then, once resumed, will proceed to suspend itself
> again.
> 
> There are two main ways to fix this.  I've included patches for
> each approach.
> 
> 1) Don't pass the WUNTRACED flag to waitpid() in vipw.c and
>just assume the main vipw will receive a stop signal from
>the kernel.  This is the simplest fix and works fine for
>stop signals generated due to ^Z.  However, if someone sends
>SIGSTOP to the vipw child process via the kill command, the
>parent vipw will not notice.
> 
> --- vipw.c.orig   2019-10-18 16:19:15.673956247 -0600
> +++ vipw.c.simple_fix 2019-10-18 16:43:04.265583507 -0600
> @@ -325,16 +325,9 @@
>   }
>  
>   for (;;) {
> - pid = waitpid (pid, , WUNTRACED);
> - if ((pid != -1) && (WIFSTOPPED (status) != 0)) {
> - /* The child (editor) was suspended.
> -  * Suspend vipw. */
> - kill (getpid (), SIGSTOP);
> - /* wake child when resumed */
> - kill (pid, SIGCONT);
> - } else {
> + pid = waitpid (pid, , 0);
> + if (pid != -1 || errno != EINTR)
>   break;
> - }
>   }
>  
>   if (-1 == pid) {
> 
> 2) The other option is to run the child process in its own process
>group as the foregroup process group.  That way, control-Z will
>only affect the child process and the parent can use the existing
>logic to suspend the parent.
> 
> 
> --- vipw.c.orig   2019-10-18 16:19:15.673956247 -0600
> +++ vipw.c.pgrp_fix   2019-10-19 12:55:50.526591299 -0600
> @@ -206,6 +206,8 @@
>   struct stat st1, st2;
>   int status;
>   FILE *f;
> + pid_t orig_pgrp, editor_pgrp = -1;
> + sigset_t mask, omask;
>   /* FIXME: the following should have variable sizes */
>   char filebackup[1024], fileedit[1024];
>   char *to_rename;
> @@ -293,6 +295,8 @@
>   editor = DEFAULT_EDITOR;
>   }
>  
> + orig_pgrp = tcgetpgrp(STDIN_FILENO);
> +
>   pid = fork ();
>   if (-1 == pid) {
>   vipwexit ("fork", 1, 1);
> @@ -302,6 +306,14 @@
>   char *buf;
>   int status;
>  
> + /* Wait for parent to make us the foreground pgrp. */
> + if (orig_pgrp != -1) {
> + pid = getpid();
> + setpgid(0, 0);
> + while (tcgetpgrp(STDIN_FILENO) != pid)
> + continue;
> + }
> +
>   buf = (char *) malloc (strlen (editor) + strlen (fileedit) + 2);
>   snprintf (buf, strlen (editor) + strlen (fileedit) + 2,
> "%s %s", editor, fileedit);
> @@ -324,19 +336,50 @@
>   }
>   }
>  
> + /* Run child in a new pgrp and make it the foreground pgrp. */
> + if (orig_pgrp != -1) {
> + setpgid(pid, pid);
> + tcsetpgrp(STDIN_FILENO, pid);
> +
> + /* Avoid SIGTTOU when changing foreground pgrp below. */
> + sigemptyset();
> +

Bug#942292: exim4.template.conf for clean buster install av_scanner incorrect

[Serge Rijkers]

On 14/10/2019 16:50, Marc Haber wrote:

On Mon, Oct 14, 2019 at 09:23:17AM +0100, Adam D. Barratt wrote:

On 2019-10-14 01:21, Serge Rijkers wrote:

exim4.template.conf contains:

av_scanner = clamd: /var/run/clamav/clamd.ctl

clean buster clamav-daemon uses /run/clamav/clamd.ctl

For a on tech-savvy user this is difficult to diagnose
possibly exim4.template.conf should contain:

av_scanner = clamd:/run/clamav/clamd.ctl

Debian Policy requires that /var/run be a symlink to /run, so that change
should make no difference.


I tested again with the symlink in place. It does make a difference.


Also, the configuration option is commented in the default file, and
there is not even a macro to enable it. So, who enables this already
knows her way around things.


Apparently, I am one of those who knows my way around things. Even so, this 
av_scanner = thing bit me. And yes, I figured it out quickly.



This should, IMO, be fixed in unstable and testing (it's a no-brainer
one-line change), but I don't think we should do this in stable.


That seems fair enough.

Regards,
Serge Rijkers

Bug#942292: exact error message from exim4 in mainlog

[Serge Rijkers]

below is the exact error in mainlog with /var/run symlink in in place

1iJnUT-0005ZN-Je malware acl condition: clamd /var/run/clamav/clamd.ctl 
: unable to connect to UNIX socket (/var/run/clamav/clamd.ctl): No such 
file or directory


regards,

Serge Rijkers

Bug#942292: exim4.template.conf for clean buster install av_scanner incorrect

[Serge Rijkers]

On 14/10/2019 10:23, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

On 2019-10-14 01:21, Serge Rijkers wrote:

exim4.template.conf contains:

av_scanner = clamd: /var/run/clamav/clamd.ctl

clean buster clamav-daemon uses /run/clamav/clamd.ctl

For a on tech-savvy user this is difficult to diagnose
possibly exim4.template.conf should contain:

av_scanner = clamd:/run/clamav/clamd.ctl


Debian Policy requires that /var/run be a symlink to /run, so that 
change should make no difference.


Regards,

Adam


I would like to point out that a clean buster install does not create 
the symlink, so the change would make a difference.


I feel that a package should not depend on erratic behavior elsewhere in 
the system. Clamd-daemon uses /run not /var/run exim should reflect that 
change.


Ultimately a new user installing buster runs into this problem. Whether 
this is fixed in exin, clamd or debian installer is metter for debate. 
should i report this elsewhere?

Bug#942292: exim4.template.conf for clean buster install av_scanner incorrect

[Serge Rijkers]

On 14/10/2019 10:23, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

On 2019-10-14 01:21, Serge Rijkers wrote:

exim4.template.conf contains:

av_scanner = clamd: /var/run/clamav/clamd.ctl

clean buster clamav-daemon uses /run/clamav/clamd.ctl

For a on tech-savvy user this is difficult to diagnose
possibly exim4.template.conf should contain:

av_scanner = clamd:/run/clamav/clamd.ctl


Debian Policy requires that /var/run be a symlink to /run, so that 
change should make no difference.


Regards,

Adam


I have also created the symlink to/run in /var and retested with 
av_scanner = /var/run/clamav/clamd.ctl wihich then fails again.

Bug#942292: exim4.template.conf for clean buster install av_scanner incorrect

[Serge Rijkers]

Package: exim4
Version: 4.92-8+deb10u3
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

A clean install of buster as an smtp mail server

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
exim4.template.conf contains:

av_scanner = clamd: /var/run/clamav/clamd.ctl

clean buster clamav-daemon uses /run/clamav/clamd.ctl

For a on tech-savvy user this is difficult to diagnose
possibly exim4.template.conf should contain:

av_scanner = clamd:/run/clamav/clamd.ctl

instead.

   * What was the outcome of this action?

Changing this to the above made clamd scanning from exim4 operational is
was not before.

   * What outcome did you expect instead?


-- Package-specific info:
Exim version 4.92 #3 built 27-Sep-2019 16:09:35
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event OCSP PRDR PROXY 
SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='tregare.net'
dc_local_interfaces='192.168.0.110 ; 127.0.0.1 ; ::1'
dc_readhost='tregare.net'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='192.168.0.0/24'
dc_smarthost='smtp.ziggo.nl'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
mailname:tregare.net
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more ports, it is recommended to use
# -oX 25:587:10025 -oP /run/exim4/exim.pid
SMTPLISTENEROPTIONS='-oX 25:465:587 -oP /run/exim4/exim.pid'

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL 
to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_ALL to default locale: 
No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-base 4.92-8+deb10u3
ii  exim4-daemon-heavy 4.92-8+deb10u3

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_MONETARY = 

Bug#941005: [Pkg-shadow-devel] Bug#941005: shadow uses obsolete SELinux API

[Serge E. Hallyn]

Thanks.  If you feel so inclined, please feel free to file an issue for it
at github.com/shadow-maint/shadow.  I'll aim to fix this in the next week
or two.  (A lot of travel coming up)

On Mon, Sep 23, 2019 at 01:16:10PM +0200, Laurent Bigonville wrote:
> Source: shadow
> Version: 1:4.7-2
> Severity: normal
> User: selinux-de...@lists.alioth.debian.org
> Usertags: selinux
> 
> Hello,
> 
> It seems that the shadow source package is using obsolete SELinux API,
> for example:
> 
> In file included from passwd.c:46:
> /usr/include/selinux/flask.h:5:2: warning: #warning "Please remove any 
> #include's of this header in your source code." [-Wcpp]
>  #warning "Please remove any #include's of this header in your source code."
>   ^~~
> /usr/include/selinux/flask.h:6:2: warning: #warning "Instead, use 
> string_to_security_class() to map the class name to a value." [-Wcpp]
>  #warning "Instead, use string_to_security_class() to map the class name to a 
> value."
>   ^~~
> In file included from passwd.c:47:
> /usr/include/selinux/av_permissions.h:1:2: warning: #warning "Please remove 
> any #include of this header in your source code." [-Wcpp]
>  #warning "Please remove any #include of this header in your source code."
>   ^~~
> /usr/include/selinux/av_permissions.h:2:2: warning: #warning "Instead, use 
> string_to_av_perm() to map the permission name to a value." [-Wcpp]
>  #warning "Instead, use string_to_av_perm() to map the permission name to a 
> value."
> 
> That should be fixed as it could lead to security issues (or at least
> weakened security) for people using SELinux
> 
> Kind regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#928659: systemd: "systemctl reboot " broken since v240 - fixed in v242

[Serge Schneider]

Package: systemd
Version: 241-3+rpi1
Severity: normal

Dear Maintainer,

v240 of systemd broke the mechanism that passes reboot arguments to the kernel.
https://github.com/systemd/systemd/issues/11828

I've tested that adding this patch to the current Buster version (241-3) 
resolves the problem.
https://github.com/vesajaaskelainen/systemd/commit/b4bf7e500b28362c2bf50f0320dc66a55b92cda2.patch

I don't know if the issue is considered critical enough to update the package 
now that Buster is frozen,
but it would certainly be appreciated.

-- Package-specific info:

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux buster/sid
Release:testing
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.14.98-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-2+b1
ii  libblkid12.33.1-0.1
ii  libc62.28-8
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.6-2
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-3+rpi1
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  241-3+rpi1

Versions of packages systemd suggests:
ii  policykit-10.105-25
ii  systemd-container  241-3+rpi1

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-3+rpi1

-- no debconf information

Bug#928176: vlc: BOBOOvlc cannot play cd audio without net connection and crash

[Serge Pouliquen]

Package: src:vlc
Version: 3.0.6-0+deb9u1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
remove wire cable from ethernet
play cd audio with vlc
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
with net connection, vlc can play cd audio and display title from cddb protocol
   * What was the outcome of this action?
fix network connection
   * What outcome did you expect instead?
to be able to play cd audio without internet connection


-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages vlc depends on:
ii  dpkg 1.18.25
ii  vlc-bin  3.0.6-0+deb9u1
ii  vlc-l10n 3.0.6-0+deb9u1
ii  vlc-plugin-base  3.0.6-0+deb9u1
ii  vlc-plugin-qt3.0.6-0+deb9u1
ii  vlc-plugin-video-output  3.0.6-0+deb9u1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  3.0.6-0+deb9u1
ii  vlc-plugin-samba   3.0.6-0+deb9u1
ii  vlc-plugin-skins2  3.0.6-0+deb9u1
ii  vlc-plugin-video-splitter  3.0.6-0+deb9u1
ii  vlc-plugin-visualization   3.0.6-0+deb9u1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.24-11+deb9u4
ii  libvlc5  3.0.6-0+deb9u1

Versions of packages libvlc5 depends on:
ii  dpkg 1.18.25
ii  libc62.24-11+deb9u4
ii  libvlccore9  3.0.6-0+deb9u1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.6-0+deb9u1

Versions of packages vlc-bin depends on:
ii  libc6   2.24-11+deb9u4
ii  libvlc-bin  3.0.6-0+deb9u1
ii  libvlc5 3.0.6-0+deb9u1

Versions of packages vlc-plugin-base depends on:
ii  dpkg 1.18.25
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-2+deb9u1
ii  libasound2   1.1.3-5
ii  libass5  1:0.13.4-2
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavc1394-0 0.5.4-4+b1
ii  libavcodec57 7:3.2.12-1~deb9u1
ii  libavformat577:3.2.12-1~deb9u1
ii  libavutil55  7:3.2.12-1~deb9u1
ii  libbasicusageenvironment12016.11.28-1+deb9u2
ii  libbluray1   1:0.9.3-3
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-10
ii  libdvbpsi10  1.3.0-5
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.4-1
ii  libfaad2 2.8.0~cvs20161113-1+deb9u1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libfribidi0  0.19.7-1+b1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgcrypt20  1.7.6-2+deb9u3
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u4
ii  libgpg-error01.26-2
ii  libgroupsock82016.11.28-1+deb9u2
ii  libharfbuzz0b1.4.2-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.9.4c-9
ii  liblivemedia57   2016.11.28-1+deb9u2
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8+deb9u1
ii  libmatroska6v5   1.4.5-2
ii  libmicrodns0 0.0.3-3
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-7+b2
ii  libmpg123-0  1.23.8-1+b1
ii  libmtp9  1.1.13-1
ii  libncursesw5 6.0+20161126-1+deb9u2
ii  libnfs8  1.11.0-2
ii  libogg0  1.3.2-1
ii  libopenmpt-modplug1  0.2.7386~beta20.3-3+deb9u3
ii  libopus0 1.2~alpha2-1
ii  libpng16-16  1.6.28-1+deb9u1
ii  libpostproc54   

Bug#923478: [Pkg-shadow-devel] Bug#923478: initscripts use unsafe `: >` shell command to create files

[Serge E. Hallyn]

On Tue, Apr 16, 2019 at 10:44:21PM +, Dmitry Bogatov wrote:
> 
> [2019-04-14 13:35] Cristian Ionescu-Idbohrn 
> 
> > On Sun, 14 Apr 2019, Dmitry Bogatov wrote:
> > > 
> > > Definitely. But default one is from bin:util-linux.
> >
> > On my sid/unstable:
> >
> > # dpkg -S /bin/login
> > login: /bin/login
> 
> You are right, it is from src:shadow.
> 
> > > So I question, how much of this code is actually necessary:
> > > 
> > >  * group 'utmp' exists on bare system, so conditional is not needed.
> > >  * if /var/run/utmp is missing, nothing bad seems to happen, so does
> > >this code is needed at all?
> > > 
> > > Opinions?
> >
> > IMO, less code is better.  I didn't loog at the source.  But I can 
> > see this:
> >
> > # strings /bin/login | egrep 'utmp|faillog|/'
> > /lib64/ld-linux-x86-64.so.2
> > /usr/share/locale
> > No utmp entry.  You must exec "login" from the lowest level "sh"
> > [...]
> 
> I took a look at source. It seems that this error may only happen if UID != 0.
> I'd better add login maintainers into thread.
> 
> Dear login maintainers, currently we have following core executed during
> boot:
> 
>   # Create /var/run/utmp so we can login.
>   true > /var/run/utmp
>   if grep -q ^utmp: /etc/group
>   then
>   chmod 664 /var/run/utmp
>   chgrp utmp /var/run/utmp
>   fi
> 
> It seems that system boots and works just fine without it. Are there any
> subtle reasons to keep creating /var/run/utmp in initscripts?

Hi,

Is the above pseudocode?  If not, where is that code precisely?

Near as I can tell, if you do not create it, it will never exist,
and pututent entries will not be saved.

> > > PS. Cristian, it seems I did not enough research prior asking you to
> > > make patch and caused labour wasted. I am sorry.
> >
> > No worries.  Still, I would be cautious.  That redirection (with or 
> > without a command prefix) is still questionable, as it _truncates_ the 
> > file (as opposed to just touching it).
> 
> It is under /var/run, which is tmpfs, so it is okay.
> -- 
> Note, that I send and fetch email in batch, once every 24 hours.
>  If matter is urgent, try https://t.me/kaction
>  
> --
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#927194: /etc/init.d/alsa-utils sleeps at store_levels()

[Serge Belyshev]

Package: alsa-utils
Version: 1.1.8-2
Tags: patch

/etc/init.d/alsa-utils initscript contains an unnecessary "sleep 1" at
store_levels(), delaying shutdown by one second when using sysvinit.

Proposed fix:

diff --git a/debian/init b/debian/init
index e6a6e92..403c17f 100755
--- a/debian/init
+++ b/debian/init
@@ -79,7 +79,6 @@ store_levels()
CARD="$1"
[ "$1" = all ] && CARD=""
if MSG="$(alsactl -E HOME="$ALSACTLHOME" store $CARD 2>&1)" ; then
-   sleep 1
return 0
else
log_action_cont_msg "warning: 'alsactl store${CARD:+ $CARD}' 
failed with error message '$MSG'"

Bug#927113: wrong /tmp permissions when symlinking /tmp to /run/tmp

[Serge Belyshev]

Package: initscripts
Version: 2.93-8

Second (part of the) issue described in #915671, namely, wrong /tmp
permissions when it is symlinked to a non-existent location was not
previously fixed.

Not that I care very much about this feature, but for consistency it
should be either fixed or removed.

The possible simple fix is the same as before:

diff --git a/debian/src/initscripts/lib/init/mount-functions.sh 
b/debian/src/initscripts/lib/init/mount-functions.sh
index e453f6a8..cd09883f 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -627,7 +627,7 @@ mount_tmp ()
  # If /tmp is a symlink, make sure the linked-to directory exists.
  if [ -L /tmp ] && [ ! -d /tmp ]; then
   TMPPATH="$(readlink /tmp)"
-  mkdir -p --mode=755 "$TMPPATH"
+  mkdir -p --mode="$TMP_MODE" "$TMPPATH"
   [ -x /sbin/restorecon ] && /sbin/restorecon "$TMPPATH"
  fi

Bug#919317: [Pkg-shadow-devel] Bug#919317: shadow: French documentation translation update

[Serge E. Hallyn]

Hi,

it would be great if you could open a pull request at
https://github.com/shadow-maint/shadow/

Bug#915671: symlinking /tmp to /run/tmp does not work

[Serge Belyshev]

> This is *WRONG*, it will also return 0 if /tmp is not a symlink.

Wow, my bad, sorry for the noise.  Should not have really mixed C and
shell code in my head.

> (Also, use test -h instead of test -L for symlinks, cf. the
> GNU autoconf texinfo manual, *Limitations of Builtins::)
>
> What about this instead:
>
>   if test -h /tmp; then
>   # symbolic link
>   # will be created by mount_tmp if it does not exist
>   test -d /tmp || return 0
>   # but we’ll clean it if it does
>   fi

Indeed your version is better.  (Although as a minor nitpick
bootclean.sh uses [ and -L in other places, so it will look inconsistent)

Bug#915671: symlinking /tmp to /run/tmp does not work

[Serge Belyshev]

Package: initscripts
Version: 2.93-1

In /usr/share/doc/initscripts/README.Debian it is documented that /tmp
could be a symlink to (for example) /run/tmp. This feature was
implemented in version 2.88dsf-13.3 (see
https://salsa.debian.org/debian/sysvinit/commit/3bec14850 ).

But currently it does not work, because bootclean.sh happens to run
before mountall.sh and chokes on a broken symlink.

Another issue is that mount_tmp() function creates the pointed-to
directory with the 755 mode, which is wrong for /tmp.

The following is a possible patch to fix these two problems (first
posted and discussed here:
http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2018-December/000544.html
 ):

---
 debian/src/initscripts/lib/init/bootclean.sh   | 2 ++
 debian/src/initscripts/lib/init/mount-functions.sh | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/src/initscripts/lib/init/bootclean.sh 
b/debian/src/initscripts/lib/init/bootclean.sh
index 67e15a66..55f1c8b2 100644
--- a/debian/src/initscripts/lib/init/bootclean.sh
+++ b/debian/src/initscripts/lib/init/bootclean.sh
@@ -52,6 +52,8 @@ checkflagfile()
}
 
 clean_tmp() {
+   # Will be created by mount_tmp()
+   [ -L /tmp ] && [ -d /tmp ] || return 0
# Does not exist
[ -d /tmp ] || return 1
# tmpfs does not require cleaning
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh 
b/debian/src/initscripts/lib/init/mount-functions.sh
index e453f6a8..cd09883f 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -627,7 +627,7 @@ mount_tmp ()
# If /tmp is a symlink, make sure the linked-to directory exists.
if [ -L /tmp ] && [ ! -d /tmp ]; then
TMPPATH="$(readlink /tmp)"
-   mkdir -p --mode=755 "$TMPPATH"
+   mkdir -p --mode="$TMP_MODE" "$TMPPATH"
[ -x /sbin/restorecon ] && /sbin/restorecon "$TMPPATH"
fi
 

Bug#912680: Same problem

[Serge Kilimoff-Goriatchkine]

Hello, I have the same problem following an update this morning.
To correct this (at least temporarily), I removed the defective symbolic
links present in /etc/alsa/alsa.d.
My headphone output works, but not the hdmi output. Which is better than
nothing while waiting for a real fix.

Thank you.



Bonjour, j'ai eu le même problème suite à une mise à jour ce matin.
Pour corriger ça (au moins temporairement), j'ai supprimé les liens
symbolique défectueux présent dans /etc/alsa/alsa.d.
Ma sortie casque fonctionne, mais pas la sortie hdmi. Ce qui est mieux que
rien en attendant un vrai correctif.

Merci.

Bug#908504: fake-hwclock runs after systemd-fsck-root

[Serge Schneider]

Package: fake-hwclock
Version: 0.11
Severity: normal

Dear Maintainer,

Judging by these comments [1], fake-hwclock should run before fsck.

However, on a system without initrd, with fsck on root enabled in fstab, 
systemd-fsck-root.service runs first.
On a system without an RTC, this may result in a lengthy and unnecessary 
fsck run if the system thinks the last write or mount time is in the future.


May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: e2fsck 1.43.4 
(31-Jan-2017)
May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: Superblock last 
mount time (Thu May 17 18:53:33 2018,
May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: now = Thu Nov 3 
17:16:44 2016) is in the future.

May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: Fix? yes
May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: Superblock last 
write time (Wed Apr 18 01:24:23 2018,
May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: now = Thu Nov 3 
17:16:44 2016) is in the future.

May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: Fix? yes
May 17 19:27:19.908109 raspberrypi systemd-fsck[68]: Pass 1: Checking 
inodes, blocks, and sizes
May 17 19:27:19.919007 raspberrypi systemd[1]: Starting udev Kernel 
Device Manager...
May 17 19:27:20.146456 raspberrypi fake-hwclock[79]: Thu 17 May 
19:27:19 UTC 2018
May 17 19:27:20.832099 raspberrypi systemd[1]: Started udev Kernel 
Device Manager.


The issue is resolved if the service file's Before= line has 
systemd-fsck-root.service:


Sep 10 14:39:38 serge-poehat fake-hwclock[91]: Mon 10 Sep 13:39:38 UTC 
2018

...
Sep 10 14:39:38 serge-poehat systemd[1]: Started Create Static Device 
Nodes in /dev.
Sep 10 14:39:38 serge-poehat systemd-fsck[125]: e2fsck 1.43.4 
(31-Jan-2017)
Sep 10 14:39:38 serge-poehat systemd[1]: Starting udev Kernel Device 
Manager...
Sep 10 14:39:38 serge-poehat systemd-fsck[125]: Superblock last mount 
time is in the future.
Sep 10 14:39:38 serge-poehat systemd-fsck[125]: (by less than 
a day, probably due to the hardware clock being incorrectly set)
Sep 10 14:39:38 serge-poehat systemd-fsck[125]: Superblock last write 
time is in the future.
Sep 10 14:39:38 serge-poehat systemd-fsck[125]: (by less than 
a day, probably due to the hardware clock being incorrectly set)
Sep 10 14:39:38 serge-poehat systemd-fsck[125]: rootfs: clean, 
167411/477664 files, 1341219/1928192 blocks
Sep 10 14:39:38 serge-poehat systemd[1]: Started File System Check on 
Root Device.



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782314;msg=10


-- System Information:
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.4 (stretch)
Release:    9.4
Codename:   stretch
Architecture: armv7l

Kernel: Linux 4.14.52-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fake-hwclock depends on:
ii  init-system-helpers  1.48

fake-hwclock recommends no packages.

Versions of packages fake-hwclock suggests:
ii  cron [cron-daemon]  3.0pl1-128+deb9u1
pn  ntp 

Bug#906122: thunar: Thunar doesn't show a deleted file which is present in /.Trash-1000/files/

[Serge Pouliquen]

Package: thunar
Version: 1.6.11-1
Severity: normal

Dear Maintainer,

On my system, there are 2 partitions : / and /home

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

In order to have a functional trash for root partition, I made a directory 
called /.Trash-1000/
  ls -l 
  drwxr-xr-x   44096 Aug 12 19:42 .Trash-1000

When I delete a file (from /usr/local/...) with Thunar, It is correctly moved 
to /.Trash-1000/files/

When using Thunar with location "trash:///", I didn't see my deleted file.

   * What outcome did you expect instead?

I was expecting to see the deleted file with Thunar in trash.

in https://specifications.freedesktop.org/trash-spec/trashspec-latest.html
> For showing trashed files, implementations SHOULD support (1) and (2) at the 
> same time (that is, if both $topdir/.Trash/$uid and $topdir/.Trash-$uid are 
> present, it should list trashed files from both of them).

I didn't read anywhere in the document that $topdir can't be root partition. 
But I may have misunderstood the document.
If it looks inappropriate to developper, you can close it.

I didn't try to empty trash, so I don't know if it will be removing the deleted 
file.

Regards,


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-11+deb9u3
ii  libcairo2   1.14.8-1
ii  libdbus-1-3 1.10.26-0+deb9u1
ii  libdbus-glib-1-20.108-2
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.5-1
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-2-0  1.6.11-1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.8-1+deb9u1
ii  thunar-data 1.6.11-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.26-0+deb9u1
ii  dbus-x11 [dbus-session-bus]   1.10.26-0+deb9u1
ii  gvfs  1.30.4-1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  thunar-volman 0.8.1-2
ii  tumbler   0.1.31-2+b3
ii  xdg-user-dirs 0.15-2+b1
ii  xfce4-panel   4.12.1-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#900103: xserver-xorg-video-nvidia: Broken dependency with xserver-xorg-core 2:1.20.0-2

[Serge Kilimoff-Goriatchkine]

Package: xserver-xorg-video-nvidia
Version: 390.48-3
Severity: important

Dear Maintainer,

Dependency with xserver-xorg-core is no longer assured because it requires << 
2: 1.19.99 but the currently available version is 2: 1.20.0-2

Thanks !


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.6.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xserver-xorg-video-nvidia depends on:
ii  libc6  2.26-4
pn  libnvidia-glcore   
ii  nvidia-alternative 384.111-2
ii  nvidia-installer-cleanup   20151021+7
ii  nvidia-legacy-check384.111-2
ii  nvidia-support 20151021+7
ii  xserver-xorg-core [xorg-video-abi-23]  2:1.19.5-1

Versions of packages xserver-xorg-video-nvidia recommends:
pn  nvidia-driver  
pn  nvidia-kernel-dkms | nvidia-kernel-390.48  
pn  nvidia-settings
pn  nvidia-vdpau-driver

Versions of packages xserver-xorg-video-nvidia suggests:
pn  nvidia-kernel-dkms | nvidia-kernel-source  

Bug#898958: peruse: does not start

[Serge Kilimoff-Goriatchkine]

Package: peruse
Version: 1.2+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When I just run "peruse" command in my terminal (in fresh installation of 
peruse from apt), I get the following message that appears :

  Failed to load the component from disk. Reported error was: 
"file:///usr/share/peruse/qml/Main.qml:26 Type PeruseMain 
unavailable\nfile:///usr/share/peruse/qml/PeruseMain.qml:27 module 
\"org.kde.kirigami\" is not installed\n"

Thanks ! Et merci !



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

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages peruse depends on:
ii  kio 5.45.0-1
ii  libc6   2.27-3
ii  libgcc1 1:8.1.0-3
ii  libkf5archive5  5.45.0-1
ii  libkf5baloo55.45.0-1
ii  libkf5configcore5   5.45.0-1
ii  libkf5coreaddons5   5.45.0-1
ii  libkf5declarative5  5.45.0-1
ii  libkf5filemetadata3 5.45.0-1
ii  libkf5kiocore5  5.45.0-1
ii  libkf5kiowidgets5   5.45.0-1
ii  libqt5core5a5.10.1+dfsg-6+b1
ii  libqt5gui5  5.10.1+dfsg-6+b1
ii  libqt5qml5  5.10.1-4
ii  libqt5quick55.10.1-4
ii  libqt5widgets5  5.10.1+dfsg-6+b1
ii  libstdc++6  8.1.0-3
ii  peruse-common   1.2+dfsg-2
ii  qml-module-org-kde-kirigami25.45.0-1
ii  qml-module-org-kde-newstuff 5.45.0-1
ii  qml-module-qt-labs-folderlistmodel  5.10.1-4

peruse recommends no packages.

peruse suggests no packages.

-- no debconf information

Bug#898175: dwarf-fortress: The shortcut of Dwarf Fortress does not work

[Serge Le Tyrant]

Package: dwarf-fortress
Version: 0.44.10-1
Followup-For: Bug #898175

I imagine I'm not alone in using the i386 architecture (even though we are
fewer and fewer).

Thank you for your time and your work.

Greetings
Serge.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Foreign Architectures: 64, x32, 32

Kernel: Linux 4.16.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dwarf-fortress depends on:
ii  dwarf-fortress-data 0.44.10-1
ii  libc6   2.27-3
ii  libgcc1 1:8.1.0-1
ii  libglib2.0-02.56.1-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgtk2.0-0 2.24.32-1
ii  libsdl-image1.2 1.2.12-8
ii  libsdl-ttf2.0-0 2.0.11-4
ii  libsdl1.2debian 1.2.15+dfsg2-0.1
ii  libstdc++6  8.1.0-1
ii  python3 3.6.5-3
ii  python3-xdg 0.25-4
ii  unionfs-fuse1.0-1+b1

dwarf-fortress recommends no packages.

dwarf-fortress suggests no packages.

-- no debconf information

Bug#898175: dwarf-fortress: The shortcut of Dwarf Fortress does not work

[Serge Le Tyrant]

Package: dwarf-fortress
Version: 0.44.10-1
Severity: important
Tags: patch

To make it functional, please add this line in the shortcut :
LD_PRELOAD=/usr/lib/i386-linux-gnu/libz.so /usr/games/dwarf-fortress

(Dwarf Fortress does not work without libz.so)

Thanks



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Foreign Architectures: 64, x32, 32

Kernel: Linux 4.16.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dwarf-fortress depends on:
ii  dwarf-fortress-data 0.44.10-1
ii  libc6   2.27-3
ii  libgcc1 1:8.1.0-1
ii  libglib2.0-02.56.1-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgtk2.0-0 2.24.32-1
ii  libsdl-image1.2 1.2.12-8
ii  libsdl-ttf2.0-0 2.0.11-4
ii  libsdl1.2debian 1.2.15+dfsg2-0.1
ii  libstdc++6  8.1.0-1
ii  python3 3.6.5-3
ii  python3-xdg 0.25-4
ii  unionfs-fuse1.0-1+b1

dwarf-fortress recommends no packages.

dwarf-fortress suggests no packages.

-- no debconf information

Bug#896190: Acknowledgement (ffmpeg convertion from dsf to flac - noisy at the end of file)

[Serge Pouliquen]

Hi

In case of interest, I attached an audacity capture.

ffmpeg output convertion was:

ffmpeg output is :

ffmpeg -i "2L-125_stereo-11289k-1b_04.dsf" -acodec flac -ar 96000 
"2L-125_stereo-11289k-1b_04.flac"

ffmpeg version 3.2.10-1~deb9u1 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18) 20170516
  configuration: --prefix=/usr --extra-version='1~deb9u1' 
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu 
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping 
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa 
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca 
--enable-libcdio --enable-libebur128 --enable-libflite 
--enable-libfontconfig --enable-libfreetype --enable-libfribidi 
--enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse 
--enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora 
--enable-libtwolame --enable-libvorbis --enable-libvpx 
--enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid 
--enable-libzmq --enable-libzvbi --enable-omx --enable-openal 
--enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 
--enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 
--enable-shared

  libavutil  55. 34.101 / 55. 34.101
  libavcodec 57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter 6. 65.100 /  6. 65.100
  libavresample   3.  1.  0 /  3.  1.  0
  libswscale  4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
[dsf @ 0x55a2767b3ee0] Estimating duration from bitrate, this may be 
inaccurate

Input #0, dsf, from '2L-125_stereo-11289k-1b_04.dsf':
  Metadata:
    encoded_by  : Merging Technologies Album Publishing
    comment : Generated by Merging Technologies Album Publishing
    : Label Code: 2L
    title   : Frank Bridge Variations: 4. Romance
    artist  : TrondheimSolistene
    album_artist    : TrondheimSolistene
    composer    : Benjamin Britten
    album   : REFLECTIONS
    track   : 4/22
    disc    : 1
    TSRC    : NOMPP1603040
    : 7041888521525
    publisher   : 2L
    date    : 2016
    genre   : Classical
  Duration: 00:01:38.00, bitrate: 22579 kb/s
    Stream #0:0: Audio: dsd_lsbf_planar, 1411200 Hz, stereo, fltp, 
22579 kb/s
    Stream #0:1: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown), 
1200x1200, 90k tbr, 90k tbn, 90k tbc

    Metadata:
  comment : Cover (front)
[flac @ 0x55a2767b8de0] encoding as 24 bits-per-sample
Output #0, flac, to '2L-125_stereo-11289k-1b_04.flac':
  Metadata:
    encoded_by  : Merging Technologies Album Publishing
    DESCRIPTION : Generated by Merging Technologies Album Publishing
    : Label Code: 2L
    title   : Frank Bridge Variations: 4. Romance
    artist  : TrondheimSolistene
    ALBUMARTIST : TrondheimSolistene
    composer    : Benjamin Britten
    album   : REFLECTIONS
    TRACKNUMBER : 4/22
    DISCNUMBER  : 1
    TSRC    : NOMPP1603040
    : 7041888521525
    publisher   : 2L
    date    : 2016
    genre   : Classical
    encoder : Lavf57.56.101
    Stream #0:0: Audio: flac, 96000 Hz, stereo, s32 (24 bit), 128 kb/s
    Metadata:
  encoder : Lavc57.64.101 flac
Stream mapping:
  Stream #0:0 -> #0:0 (dsd_lsbf_planar (native) -> flac (native))
Press [q] to stop, [?] for help
size=   24736kB time=00:01:37.76 bitrate=2072.8kbits/s speed=30.4x
video:0kB audio:24728kB subtitle:0kB other streams:0kB global 
headers:0kB muxing overhead: 0.034367%



Regards,

SergeP


On 20/04/18 18:36, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 896190: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896190.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
   sp31...@free.fr
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Debian Multimedia Maintainers 


If you wish to submit further information on this problem, please
send it to 896...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#896190: ffmpeg convertion from dsf to flac - noisy at the end of file

[Serge Pouliquen]

Package: ffmpeg
Version: 7:3.2.10-1~deb9u1
Severity: normal

Dear Maintainer,


   * What led up to the situation?

I tried to convert dsf file to flac with ffmpeg.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

It looks like there is a noisy part at the end of some flac file.

Steps to reproduce:
1/ download from 
http://www.lindberg.no/hires/test/2L-125_stereo-11289k-1b_04.dsf.zip
2/ extract archive
3/ run ffmpeg command : ffmpeg -i "2L-125_stereo-11289k-1b_04.dsf" -acodec flac 
-ar 96000 "2L-125_stereo-11289k-1b_04.flac"
4/ play the flac file or open it with audacity (some flac player are playing a 
noisy 'clac' at the end of file like deadbeef, some don't)

I'm not sure the bug is from ffmpeg, but probably because two softwares have 
seen that noise

maybe related :
https://trac.ffmpeg.org/ticket/5488
https://trac.ffmpeg.org/ticket/5489

Regards,
Serge


   * What was the outcome of this action?
no outcome at the moment
   * What outcome did you expect instead?
a proper flac file




-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ffmpeg depends on:
ii  libavcodec577:3.2.10-1~deb9u1
ii  libavdevice57   7:3.2.10-1~deb9u1
ii  libavfilter67:3.2.10-1~deb9u1
ii  libavformat57   7:3.2.10-1~deb9u1
ii  libavresample3  7:3.2.10-1~deb9u1
ii  libavutil55 7:3.2.10-1~deb9u1
ii  libc6   2.24-11+deb9u3
ii  libpostproc54   7:3.2.10-1~deb9u1
ii  libsdl2-2.0-0   2.0.5+dfsg1-2
ii  libswresample2  7:3.2.10-1~deb9u1
ii  libswscale4 7:3.2.10-1~deb9u1
ii  libva1  1.7.3-2

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
ii  ffmpeg-doc  7:3.2.10-1~deb9u1

-- no debconf information

Bug#894996: [Pkg-shadow-devel] Bug#894996: Give the path of the directory you are talking about

[Serge E. Hallyn]

Would you mind opening an issue (well, two) at 
github.com/shadow-maint/shadow/issues?

I'll see it there when looking for a task, but am not likely to see this email.

Quoting 積丹尼 Dan Jacobson (jida...@jidanni.org):
> Package: passwd
> Version: 1:4.5-1
> Severity: wishlist
> File: /usr/sbin/useradd
> 
> We see:
> useradd: warning: the home directory already exists.
> 
> The problem is this might be in a forest of other messages,
> so please say what (user's) directory you are talking about.
> Give the exact path.
> 
> We also see
> Not copying any file from skel directory into it.
> 
> If this is from useradd, then I would prefix it
> useradd: Not copying any file from skel directory into it.
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#276655: synaptic: 'lock version' harmful; another suggestion : replace with apt-mark hold

[Serge Le Tyrant]

Package: synaptic
Version: 0.84.2
Followup-For: Bug #276655

I have reported the bug #890668 about unattended-upgrades package
In it's recent version (0.99), this package upgrade all Debian packages (not
only security packages) even if they are blocked on Synaptic.

The maintainer of this package tells me to use :
apt-mark hold 
to hold a package.

I suggest to use this function on Synaptic



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Foreign Architectures: 64, x32, 32

Kernel: Linux 4.15.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.17-1
ii  libapt-inst2.0   1.6~alpha7
ii  libapt-pkg5.01.6~alpha7
ii  libatk1.0-0  2.26.1-3
ii  libc62.26-6
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:8-20180218-1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-2
ii  libgnutls30  3.5.18-1
ii  libgtk-3-0   3.22.28-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpcre2-8-0 10.22-6
ii  libstdc++6   8-20180218-1
ii  libvte-2.91-00.50.2-4
ii  libx11-6 2:1.6.4-3
ii  libxapian30  1.4.5-1
ii  policykit-1  0.105-18
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages synaptic recommends:
ii  libgtk2-perl   2:1.24992-1+b1
ii  rarian-compat  0.8.1-6+b1
ii  xdg-utils  1.1.2-1

Versions of packages synaptic suggests:
ii  apt-xapian-index 0.49
ii  deborphan1.7.28.8-0.3+b1
pn  dwww 
ii  menu 2.1.47+b1
ii  software-properties-gtk  0.96.20.2-1
ii  tasksel  3.43

-- no debconf information

Bug#890668: unattended-upgrades: All Debian packages are updated (not only Debian-Security) including blocked packages

[Serge Le Tyrant]

Package: unattended-upgrades
Version: 0.99
Severity: important
Tags: d-i

With unattended-upgrades 0.99: All Debian packages are updated (not only
Debian-Security) including blocked packages

I don't wan't to upgrade Tellico 3.1-0.3, because the last version (3.1.1-0.1)
has an annoying bug (sorry i don't report it). So i have blocked this 3.1-0.3
version on Synaptic.

I hadn't this probleme before this 0.99 version (upgraded on the 02.10.2018)

/etc/apt/apt.conf.d/10periodic (i never edited it) :
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "0";

If i understand Debian Wiki correctly :
APT::Periodic::Download-Upgradeable-Packages "1" mean Do "apt-get upgrade
--download-only" so unattended-upgrades must only download upgradable packages,
and not to update all the system, and let alone update blocked packets.

This can cause a severe malfunction of my system if I dont want to update a
kernel or a library whose top version does not work

In /var/log/unattended-upgrades :
(...)
2018-02-17 08:21:24,977 INFO Paquets initialement sur la liste noire:
2018-02-17 08:21:24,997 INFO Paquets initialement sur la liste blanche:
2018-02-17 08:21:24,997 INFO Démarrage du script de mise à niveau automatique
2018-02-17 08:21:24,997 INFO Les origines permises sont:
[‘origin=Debian,codename=sid,label=Debian’,
‘origin=Debian,codename=sid,label=Debian-Security’]
2018-02-17 08:21:46,799 INFO Paquets initialement sur la liste noire:
2018-02-17 08:21:46,800 INFO Paquets initialement sur la liste blanche:
2018-02-17 08:21:46,800 INFO Démarrage du script de mise à niveau automatique
2018-02-17 08:21:46,801 INFO Les origines permises sont:
[‘origin=Debian,codename=sid,label=Debian’,
‘origin=Debian,codename=sid,label=Debian-Security’]
2018-02-17 08:21:57,915 INFO Paquets mis à niveau: tellico tellico-data
tellico-doc tellico-scripts
2018-02-17 08:21:57,915 INFO Écriture du journal de dpkg dans «
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log »
2018-02-17 08:25:11,516 INFO Toutes les mises à niveau ont été installées
(...)
2018-02-12 17:30:45,179 INFO Paquets mis à niveau: corebird tellico tellico-
data tellico-doc tellico-scripts
(…)
2018-02-14 17:56:53,341 INFO Paquets mis à niveau: tellico tellico-data
tellico-doc tellico-scripts

I can reproduce this bug on my system easily.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Foreign Architectures: 64, x32, 32

Kernel: Linux 4.14.0-3-686-pae (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  lsb-base   9.20170808
ii  lsb-release9.20170808
ii  python33.6.4-1
ii  python3-apt1.4.0~beta3+b1
ii  ucf3.0037
ii  xz-utils   5.2.2-1.3

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-24
ii  cron [cron-daemon]  3.0pl1-128.1

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx 
pn  mail-transport-agent  
pn  needrestart   

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component (eg, "main", "contrib", "non-free")
//   l,label (eg, "Debian", "Debian-Security")
//   o,origin(eg, "Debian", "Unofficial Multimedia Packages")
//   n,codename  (eg, "jessie", "jessie-updates")
// site  (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}Installed origin.
//   ${distro_codename}  Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// Software will be the latest available for the named release,
// but the Debian release itself will not be automatically upgraded.
//  

Bug#888053: libcdio-utils: cd-paranoia is absent from deb package at version 1.0.0-2 (currently in testing/sid)

[Serge Pouliquen]

Package: libcdio-utils
Version: 0.83-4.3+b1
Severity: normal

Dear Maintainer,


I tried to upgrade to the last version.

I failed to find a binary for cd-paranoia in debian package.
That binary should be present according to package description.

Maybe, it should be provided by another package, but I didn't find any.

Regards,


-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcdio-utils depends on:
ii  libc6  2.24-11+deb9u1
ii  libcdio-cdda1  0.83-4.3+b1
ii  libcdio-paranoia1  0.83-4.3+b1
ii  libcdio13  0.83-4.3+b1
ii  libiso9660-8   0.83-4.3+b1
ii  libncurses56.0+20161126-1+deb9u1
ii  libtinfo5  6.0+20161126-1+deb9u1

libcdio-utils recommends no packages.

libcdio-utils suggests no packages.

-- no debconf information

Bug#886657: gitlab postinst failing when 'apt-get install' or 'reconfigure' when CWD not accessible to gitlab user

[Serge Cohen]

Package: gitlab
Version: 8.13.11+dfsg1-8
Severity: important

Dear Maintainer,

   * What led up to the situation?
   I am installing the gitlab package (and reconfiguring it) when in a specific 
directory /root/ or even a subdirectory therein which has rights : drwx-- 1 
root root
   In such a case the (re)configuration stops soon after finishing to ask 
questions, with an error :

root@test-stretch-bpo:~# ls -lad .
drwx-- 10 root root 4096 janv.  8 16:18 .

root@test-stretch-bpo:~# LANG=C dpkg-reconfigure gitlab
Creating/updating gitlab user account...
Making gitlab owner of /var/lib/gitlab...
Creating runtime directories for gitlab...
Updating file permissions...
fatal: Cannot come back to cwd: Permission denied

   When investigating the root cause of this crash I realised it happens in the 
postinst script of gitlab package a bit after line 124 (echo "Updating file 
permissions...") and I think it is on the 'runuser' call of line 132 ? 

   When, conversely, I run the same command (apt-get install or 
dpk-reconfigure) from within a «world readable directory '/tmp' or '/etc') 
everything goes ok.

   Thank you for finding a solution to this annoying bug, which prevent some 
automatic installation and (re)configuration of the gitlab package.

Sincerely,

Serge Cohen.

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

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

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  apache2 [httpd]   2.4.25-3+deb9u3
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b3
ii  bundler   1.13.6-2
ii  dbconfig-pgsql2.0.9~bpo9+1
ii  debconf [debconf-2.0] 1.5.61
ii  git   1:2.14.2-1~bpo9+1
ii  gitlab-shell  3.6.6-4
ii  gitlab-workhorse  0.8.5+debian-3+b2
ii  init-system-helpers   1.48
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nodejs4.8.2~dfsg-1
ii  openssh-client1:7.4p1-10+deb9u2
ii  postfix [mail-transport-agent]3.1.6-0+deb9u1
ii  postgresql-client-9.6 [postgresql-client  9.6.6-0+deb9u1
ii  postgresql-contrib9.6+181+deb9u1
ii  rake  10.5.0-2
ii  redis-server  5:4.0.6-1~bpo9+1
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-5
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1
ii  ruby-doorkeeper   4.2.0-3
ii  ruby-dropzonejs-rails 0.7.1-1
ii  ruby-email-reply-parser   0.5.8-1
ii  ruby-fog-aws  0.12.0-1
ii  ruby

Bug#882770: lm-sensors homepage not online

[Serge Pouliquen]

Package: lm-sensors
Version: 1:3.4.0-4
Severity: minor

Dear Maintainer,

Home website is referred to : http://www.lm-sensors.org/
That link is down !

In /etc/sensors3.conf:
# Such custom configuration files for specific mainboards can be found at
# http://www.lm-sensors.org/wiki/Configurations
That link is down !

I found informations at:
hwmon.wiki.kernel.org

https://marc.info/?l=lm-sensors=145868501607656=2


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lm-sensors depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libsensors4  1:3.4.0-4
ii  lsb-base 9.20161125
ii  perl 5.24.1-3+deb9u2
ii  sed  4.4-1

lm-sensors recommends no packages.

Versions of packages lm-sensors suggests:
pn  fancontrol  
pn  i2c-tools   
pn  read-edid   

-- no debconf information

Bug#873436: xserver-xorg-video-intel: IGP crash during screensaver

[Serge Pouliquen]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20161206-1
Severity: important

Dear Maintainer,

I'm using debian jessie with uptodate packages.
It is the second time that IGP is crashing during the wallpaper.
Wallpaper was active long time before crash.
I hope that the attached dump will be useful.

   * What led up to the situation?
maybe the wallpaper, but I don't really believe it
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
nothing
   * What outcome did you expect instead?
I'm expecting no crash

I'm using intel core i5-7600 with 4k@60Hz desktop.

syslog extract :
Aug 26 21:02:40 lemon kernel: [23694.914814] [drm] GPU HANG: ecode 
9:0:0xfffe, in Xorg [738], reason: Hang on render ring, action: reset
Aug 26 21:02:40 lemon kernel: [23694.914817] [drm] GPU hangs can indicate a bug 
anywhere in the entire gfx stack, including userspace.
Aug 26 21:02:40 lemon kernel: [23694.914818] [drm] Please file a _new_ bug 
report on bugs.freedesktop.org against DRI -> DRM/Intel
Aug 26 21:02:40 lemon kernel: [23694.914819] [drm] drm/i915 developers can then 
reassign to the right component if it's not a kernel issue.
Aug 26 21:02:40 lemon kernel: [23694.914820] [drm] The gpu crash dump is 
required to analyze gpu hangs, so please always attach it.
Aug 26 21:02:40 lemon kernel: [23694.914821] [drm] GPU crash dump saved to 
/sys/class/drm/card0/error
Aug 26 21:02:40 lemon kernel: [23694.914873] drm/i915: Resetting chip after gpu 
hang
Aug 26 21:02:40 lemon kernel: [23694.914933] [drm] RC6 on
Aug 26 21:02:40 lemon kernel: [23694.930508] [drm] GuC firmware load skipped
Aug 26 21:02:52 lemon kernel: [23706.914579] drm/i915: Resetting chip after gpu 
hang
Aug 26 21:02:52 lemon kernel: [23706.914640] [drm] RC6 on
Aug 26 21:02:52 lemon kernel: [23706.929619] [drm] GuC firmware load skipped

xorg conf:
Section "Device"
Identifier  "Intel_HD_Graphics_630"
Driver  "intel"
BusID   "PCI:0:2:0"
Option  "AccelMethod"   "sna"
Option  "TearFree"   "true"
Option  "VSync"   "true"
EndSection


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:5912] 
(rev 04)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 252 May 23 22:31 40-intel-hd630.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 126070 Jul 19 16:50 /var/log/Xorg.1.log
-rw-r--r-- 1 root root  18494 Aug 27 18:11 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[26.787] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[26.787] X Protocol Version 11, Revision 0
[26.787] Build Operating System: Linux 4.9.0-3-amd64 x86_64 Debian
[26.787] Current Operating System: Linux lemon 4.9.0-3-amd64 #1 SMP Debian 
4.9.30-2+deb9u3 (2017-08-06) x86_64
[26.787] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=b919e139-2813-40fc-b7df-644f207388dc ro quiet
[26.787] Build Date: 07 July 2017  06:14:06AM
[26.787] xorg-server 2:1.19.2-1+deb9u1 (https://www.debian.org/support) 
[26.787] Current version of pixman: 0.34.0
[26.787]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[26.787] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[26.787] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 27 18:09:20 
2017
[27.025] (==) Using config directory: "/etc/X11/xorg.conf.d"
[27.025] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[27.217] (==) No Layout section.  Using the first Screen section.
[27.217] (==) No screen section available. Using defaults.
[27.217] (**) |-->Screen "Default Screen Section" (0)
[27.217] (**) |   |-->Monitor ""
[27.219] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[27.219] (**) |   |-->Device "Intel_HD_Graphics_630"
[27.219] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[27.219] (==) Automatically adding devices
[27.219] (==) Automatically enabling devices
[27.219] (==) Automatically adding 

Bug#864736: [Pkg-shadow-devel] Bug#864736: shadow: [INTL:nl] Dutch po file for the shadow package

[Serge E. Hallyn]

On Sat, Jul 15, 2017 at 11:42:22AM +0200, Frans Spiesschaert wrote:
> Serge E. Hallyn schreef op vr 14-07-2017 om 14:06 [-0500]:
> > Thanks, I see it went through some review at 
> > 
> > https://lists.debian.org/debian-l10n-dutch/2017/06/msg00055.html
> > 
> > so happy to take it in the upstream package.  Would you like to
> > post a pull request at github.com/shadow-maint/shadow, 
> 
> > or would
> > you prefer that I post the file for you?
> 
> yes, I would be grateful if you would be willing to do so.

Thanks, done upstream.

Bug#864736: [Pkg-shadow-devel] Bug#864736: shadow: [INTL:nl] Dutch po file for the shadow package

[Serge E. Hallyn]

Thanks, I see it went through some review at 

https://lists.debian.org/debian-l10n-dutch/2017/06/msg00055.html

so happy to take it in the upstream package.  Would you like to
post a pull request at github.com/shadow-maint/shadow, or would
you prefer that I post the file for you?

Bug#866666: xfce4-sensors-plugin: no hddtemp data

[serge]

Package: xfce4-sensors-plugin
Version: 1.2.6-1+b1
Severity: normal

Dear Maintainer,

excuse my broken English.
No hddtemp data in plugin preferences but i can view tempereatures in terminal
--

hddtemp /dev/sda
/dev/sda: Hitachi HDS721032CLA362: 37°C





-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages xfce4-sensors-plugin depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libnotify4   0.7.7-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libsensors4  1:3.4.0-4
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  xfce4-panel  4.12.1-2

Versions of packages xfce4-sensors-plugin recommends:
ii  hddtemp 0.3-beta15-52+b1
ii  lm-sensors  1:3.4.0-4

Versions of packages xfce4-sensors-plugin suggests:
pn  xsensors  

-- no debconf information

Bug#864317: xfce4-datetime-plugin : settings are lost after some modifications

[Serge Pouliquen]

Package: xfce4-datetime-plugin
Version: 0.7.0-1
Severity: normal

Dear Maintainer,

I tried to change settings in order to display time the way I want.

Step to reproduce are :

1/ Right click on plugin, then Properties

2/ change a few settings like
Digital
Custom Format
%H:%M
Custom Format
%a %_d %H:%M

3/ click close

4/ right click on plugin, then Properties

5/ change the first field (custom tooltip format) to  %_d %H:%M

6/ close

result : only tooltip settings has been saved, clocl format has been lost

expected result : all settings should be saved

Regards,
Serge Pouliquen


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (700, 'testing'), (58, 'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages xfce4-datetime-plugin depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libxfce4panel-2.0-4  4.12.1-2
ii  libxfce4ui-2-0   4.12.1-2
ii  libxfce4util74.12.1-3

xfce4-datetime-plugin recommends no packages.

xfce4-datetime-plugin suggests no packages.

-- no debconf information

Bug#863945: fpm2: doubleclick to tray icon for main window popup

[serge]

Package: fpm2
Version: 0.79-3
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

minimize program to tray

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

click on tray icon

   * What was the outcome of this action?

nothing

   * What outcome did you expect instead?

main program window popup


*** End of the template - remove these template lines ***


even right click > show/hide must be issued two times



-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages fpm2 depends on:
ii  libc6   2.19-18+deb8u9
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.42.1-1+b1
ii  libgtk2.0-0 2.24.25-3+deb8u1
ii  libx11-62:1.6.2-3
ii  libxml2 2.9.1+dfsg1-5+deb8u4

fpm2 recommends no packages.

fpm2 suggests no packages.

-- no debconf information

Bug#861975: audacity doesn't start

[serge]

Package: audacity
Version: 2.0.6-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,



   * What led up to the situation?

# apt-get install audacity

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

$ audacity

   * What was the outcome of this action?

about 50% cpu load, no output, no gui

   * What outcome did you expect instead?

audacity gui start




-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages audacity depends on:
ii  audacity-data 2.0.6-2
ii  libasound21.0.28-1
ii  libavcodec56  10:2.8.11-dmo1~bpo8+1
ii  libavformat56 10:2.8.11-dmo1~bpo8+1
ii  libavutil54   10:2.8.11-dmo1~bpo8+1
ii  libc6 2.19-18+deb8u7
ii  libexpat1 2.1.0-6+deb8u3
ii  libflac++61.3.0-3
ii  libflac8  1.3.0-3
ii  libgcc1   1:4.9.2-10
ii  libglib2.0-0  2.42.1-1+b1
ii  libid3tag00.15.1b-11
ii  libmad0   0.15.1b-8
ii  libmp3lame0   1:3.99.5-dmo4
ii  libogg0   1.3.2-1
ii  libportaudio2 19+svn20140130-1
ii  libportsmf0   0.1~svn20101010-4
ii  libsbsms102.0.2-1
ii  libsndfile1   1.0.25-9.1+deb8u1
ii  libsoundtouch01.8.0-1
ii  libsoxr0  0.1.1-1
ii  libstdc++64.9.2-10
ii  libtwolame0   0.3.13-1.1
ii  libvamp-hostsdk3  1:2.5-dmo6
ii  libvorbis0a   1.3.4-2
ii  libvorbisenc2 1.3.4-2
ii  libvorbisfile31.3.4-2
ii  libwxbase3.0-03.0.2-1+b1
ii  libwxgtk3.0-0 3.0.2-1+b1

audacity recommends no packages.

Versions of packages audacity suggests:
pn  ladspa-plugin  

-- no debconf information

Bug#777640: desmume: fails to start

[serge]

Package: desmume
Version: 0.9.10-2
Followup-For: Bug #777640

Dear Maintainer,

can confirm bug
"serge@debian:~$ desmume
Failed to set format: Invalid argument
Microphone init failed.
DeSmuME 0.9.10 svn0 dev+ x86-JIT NOSSE
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted
serge@debian:~$ desmume-glade
Failed to set format: Invalid argument
Microphone init failed.
DeSmuME 0.9.10 svn0 dev+ x86-JIT NOSSE
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted
"



-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages desmume depends on:
ii  libasound21.0.28-1
ii  libc6 2.19-18+deb8u7
ii  libcairo2 1.14.0-2.1+deb8u2
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglade2-0   1:2.6.4-2
ii  libglib2.0-0  2.42.1-1+b1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libgtkglext1  1.2.0-3.2
ii  libosmesa610.3.2-1+deb8u1
ii  libpango-1.0-01.36.8-3
ii  libsdl1.2debian   1.2.15-10+b1
ii  libsoundtouch01.8.0-1
ii  libstdc++64.9.2-10
ii  libtinyxml2.6.2   2.6.2-2
ii  zlib1g1:1.2.8.dfsg-2+b1

desmume recommends no packages.

desmume suggests no packages.

-- no debconf information

Bug#859613: cgm gettasks not working properly

[Serge E. Hallyn]

On Tue, Apr 11, 2017 at 03:35:54PM +0200, Svenja Otten wrote:
> Am Wed, 5 Apr 2017 08:51:09 -0500
> schrieb "Serge E. Hallyn" <se...@hallyn.com>:
> 
> > My guess would be that your new login is in a different cgroup from the
> > old.  The path 'user.slice/user-1000.slice' is relative to your current
> > path.  What does
> > 
> > cgm getpidcgroupabs memory $$
> > 
> > show before and after logging back in?
> 
> ok, I tried it out.
> 
> Before logging out:
> --
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> 13099
> 13101
> 13102
> 13104
> 13105
> 
> root@debian-test:~# cgm getpidcgroupabs memory $$
> /
> --
> 
> After logging back in:
> --
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> call to cgmanager_get_tasks_sync failed: invalid request
> 
> root@debian-test:~# cgm getpidcgroupabs memory $$
> /user.slice/user-0.slice
> --
> 
> But how how does it work after logging back in?

This is odd.  Are you logging in the same way both times?  how
exactly are you logging in?  (ssh, console, lightdm or the like?)
As which user?  Certainly user-0.slice seems wrong.

You do seem to have multiple things installed at the same time which
can upset each other.  In the first email you showed 'cgget', which
comes from libcgroup, and showed 
/etc/systemd/system/user-1000.slice.d/MemoryLimit.conf
which comes from systemd.

Note that if you are using systemd you should definately not be using
cgmanager.  Both will be trying to set up cgroups and will walk over
each other.  And libcgroup AFAIK is unmaintained for several years now.
It existed before either systemd or cgmanager, so if it is set up to
setup cgroups it will definately cause trouble.

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

On Mon, May 01, 2017 at 04:47:17PM +0200, Michael Biebl wrote:
> On Tue, 16 Aug 2016 15:26:46 -0500 "Serge E. Hallyn" <se...@hallyn.com>
> wrote:
> > Package: wnpp
> > Severity: normal
> > 
> > I'd like to pass cgmanager along to a new maintainer, if anyone has
> > an interest in keeping it up.  Upstream (mainly myself) is essentially
> > no longer active, as its use has been supplanted by lxcfs.
> > 
> > If noone has need of it, then perhaps removing it will be the better
> > option.  I will continue to maintain the package in the short term,
> > until either someone takes over or I decide that it can be removed
> > without adversely affecting anyone.
> > 
> 
> I guess the main reason for keeping cgmanager in Debian is to keep
> systemd-shim, thus logind under sysvinit functional.
> So CCing the sysvinit maintainers. Maybe they have an interest in taking
> over the package.

For what it's worth, we had retired cgmanager upstream, but I'm now
considering either picking it back up, or actually starting from scratch
(mainly to drop the 'libnih' dependency which is pretty problematic)

> There is elogind [1], which is a standalone logind implementation which
> doesn't require systemd-shim and cgmanager.
> This might be an alternative approach to provide the logind interfaces
> under sysvinit.
> 
> Regards,
> Michael
> 
> [1] https://github.com/wingo/elogind
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#860818: please package new edbrowse

[Serge E. Hallyn]

Package: edbrowse
Version: 3.6.3

Please package the new version (3.6.3) of edbrowse.

It has some great new features like caching of http files, and M
without a destination buffer.

thanks,
Serge

Bug#857803: [Pkg-shadow-devel] Bug#857803: shadow: Make the sp_lstchg shadow field reproducible.

[Serge E. Hallyn]

Quoting Chris Lamb (la...@debian.org):
> Hi Serge,
> 
> > > > looks ok to me, although, would it be better to fall back to time(NULL)
> > > > if the env variable is invalid?
> > > 
> > > In my experience it is far superior to explicitly error out in this
> > > situation.
> > 
> > My concern is unprivileged users causing unexpected failure in a more
> > privileged script or program by setting an invalid environment variable.
> 
> I hadn't considered that until now. However, I think you have bigger
> problems if you can do that (eg. manipulate PATH!) and tools generally
> do the right thing these days with respect to cleaning the environment
> (eg. sudo).

Right, sudo does but just setuid-root does not.  This env variable
is for reproducible builds, so can we check ruid==0 and ignore the
env variable if not?  Or do the build scripts also run as non-root?

Bug#857803: [Pkg-shadow-devel] Bug#857803: shadow: Make the sp_lstchg shadow field reproducible.

[Serge E. Hallyn]

On Sun, Apr 09, 2017 at 10:07:38AM +0100, Chris Lamb wrote:
> Serge E. Hallyn wrote:
> 
> > looks ok to me, although, would it be better to fall back to time(NULL)
> > if the env variable is invalid?
> 
> In my experience it is far superior to explicitly error out in this
> situation.

My concern is unprivileged users causing unexpected failure in a more
privileged script or program by setting an invalid environment variable.

Bug#857803: [Pkg-shadow-devel] Bug#857803: shadow: Make the sp_lstchg shadow field reproducible.

[Serge E. Hallyn]

Quoting Chris Lamb (la...@debian.org):
> Package: shadow
> Severity: wishlist
> Version: 1:4.4-4
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Hi,
> 
> Attached is the following:
> 
>   commit 2dd84b0ee31e44dc51cba7b7cdc8657bf9ff0a31
>   Author: Chris Lamb <la...@debian.org>
>   Date:   Wed Mar 15 11:35:35 2017 +0100
>   
>   Make the sp_lstchg shadow field reproducible.
>   
>   The third field in the /etc/shadow file (sp_lstchg) contains the date of
>   the last password change expressed as the number of days since Jan 1, 
> 1970.
>   As this is a relative time, creating a user today will result in:
>   
>  username:17238:0:9:7:::
>   
>   whilst creating the same user tomorrow will result in:
>   
>  username:17239:0:9:7:::
>   
>   This has an impact for the Reproducible Builds[0] project where we aim 
> to
>   be independent of as many elements the build environment as possible,
>   including the current date.
>   
>   This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
>   environment variable (instead of Jan 1, 1970) if available.
>   
>[0] https://reproducible-builds.org/
>[1] https://reproducible-builds.org/specs/source-date-epoch/
>   
>   Signed-off-by: Chris Lamb <la...@debian.org>
>   
>lib/prototypes.h|  3 ++
>libmisc/Makefile.am |  1 +
>libmisc/gettime.c   | 86 
> +
>src/chpasswd.c  |  2 +-
>src/newusers.c  |  4 +--
>src/passwd.c|  2 +-
>src/useradd.c   |  2 +-
>src/usermod.c   |  4 +--
>8 files changed, 97 insertions(+), 7 deletions(-)
> 
> 
> Regards,

Hi,

looks ok to me, although, would it be better to fall back to time(NULL)
if the env variable is invalid?

Do you want to submit this as a patch to upstream at
github.com/shadow-maint/shadow ?

-serge

> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

> >From 2dd84b0ee31e44dc51cba7b7cdc8657bf9ff0a31 Mon Sep 17 00:00:00 2001
> From: Chris Lamb <la...@debian.org>
> Date: Wed, 15 Mar 2017 11:35:35 +0100
> Subject: [PATCH] Make the sp_lstchg shadow field reproducible.
> 
> The third field in the /etc/shadow file (sp_lstchg) contains the date of
> the last password change expressed as the number of days since Jan 1, 1970.
> As this is a relative time, creating a user today will result in:
> 
>username:17238:0:9:7:::
> 
> whilst creating the same user tomorrow will result in:
> 
>username:17239:0:9:7:::
> 
> This has an impact for the Reproducible Builds[0] project where we aim to
> be independent of as many elements the build environment as possible,
> including the current date.
> 
> This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
> environment variable (instead of Jan 1, 1970) if available.
> 
>  [0] https://reproducible-builds.org/
>  [1] https://reproducible-builds.org/specs/source-date-epoch/
> 
> Signed-off-by: Chris Lamb <la...@debian.org>
> ---
>  lib/prototypes.h|  3 ++
>  libmisc/Makefile.am |  1 +
>  libmisc/gettime.c   | 86 
> +
>  src/chpasswd.c  |  2 +-
>  src/newusers.c  |  4 +--
>  src/passwd.c|  2 +-
>  src/useradd.c   |  2 +-
>  src/usermod.c   |  4 +--
>  8 files changed, 97 insertions(+), 7 deletions(-)
>  create mode 100644 libmisc/gettime.c
> 
> diff --git a/lib/prototypes.h b/lib/prototypes.h
> index 7aaf1a6..4808d5d 100644
> --- a/lib/prototypes.h
> +++ b/lib/prototypes.h
> @@ -179,6 +179,9 @@ extern int getrange (char *range,
>   unsigned long *min, bool *has_min,
>   unsigned long *max, bool *has_max);
>  
> +/* gettime.c */
> +extern time_t gettime ();
> +
>  /* get_uid.c */
>  extern int get_uid (const char *uidstr, uid_t *uid);
>  
> diff --git a/libmisc/Makefile.am b/libmisc/Makefile.am
> index 76f3c05..e691dac 100644
> --- a/libmisc/Makefile.am
> +++ b/libmisc/Makefile.am
> @@ -31,6 +31,7 @@ libmisc_a_SOURCES = \
>   getdate.y \
>   getgr_nam_gid.c \
>   getrange.c \
> + gettime.c \
>   hushed.c \
>   idmapping.h \
>   idmapping.c \
> diff --git a/libmisc/gettime.c b/libmisc/gettime.c
> new file mode 100644
> index 000..b0c539b
> --- /dev/null
> +++ b/libmisc/gettime.c
> @@ -0,0 +1,86 @@
> +/*
&g

Bug#859613: cgm gettasks not working properly

[Serge E. Hallyn]

Quoting Svenja Otten (ot...@global-village.de):
> Package: cgmanager
> Version: 0.33-2+deb8u2
> 
> Hi,
> 
> the "cgm gettasks" command does not always work as expected.
> I set up a memory limit of 64MB for the user with uid 1000:
> 
> root@debian-test:~# cat /etc/systemd/system/user-1000.slice.d/MemoryLimit.conf
> [Slice]
> MemoryLimit=67108864
> 
> It is set up at reboot, as I can see (with the user logged in):
> 
> root@debian-test:~# cgget -g memory:/user.slice/user-1000.slice
> /user.slice/user-1000.slice:
> memory.pressure_level: 
> memory.use_hierarchy: 1
> memory.swappiness: 60
> memory.memsw.failcnt: 0
> memory.limit_in_bytes: 67108864
> memory.memsw.max_usage_in_bytes: 3182592
> memory.usage_in_bytes: 2670592
> memory.memsw.limit_in_bytes: 18446744073709551615
> memory.failcnt: 0
> memory.force_empty: 
> memory.memsw.usage_in_bytes: 2670592
> memory.max_usage_in_bytes: 3182592
> memory.numa_stat: total=652 N0=652
>   file=0 N0=0
>   anon=652 N0=652
>   unevictable=0 N0=0
>   hierarchical_total=652 N0=652
>   hierarchical_file=0 N0=0
>   hierarchical_anon=652 N0=652
>   hierarchical_unevictable=0 N0=0
> memory.oom_control: oom_kill_disable 0
>   under_oom 0
> memory.stat: cache 0
>   rss 2670592
>   rss_huge 0
>   mapped_file 0
>   writeback 0
>   swap 0
>   pgpgin 1285
>   pgpgout 633
>   pgfault 2744
>   pgmajfault 0
>   inactive_anon 0
>   active_anon 2670592
>   inactive_file 0
>   active_file 0
>   unevictable 0
>   hierarchical_memory_limit 67108864
>   hierarchical_memsw_limit 18446744073709551615
>   total_cache 0
>   total_rss 2670592
>   total_rss_huge 0
>   total_mapped_file 0
>   total_writeback 0
>   total_swap 0
>   total_pgpgin 1285
>   total_pgpgout 633
>   total_pgfault 2744
>   total_pgmajfault 0
>   total_inactive_anon 0
>   total_active_anon 2670592
>   total_inactive_file 0
>   total_active_file 0
>   total_unevictable 0
> memory.move_charge_at_immigrate: 0
> memory.soft_limit_in_bytes: 18446744073709551615
> 
> 
> I can also see the user's tasks:
> 
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> 2732
> 2734
> 2735
> 2737
> 2738
> 
> But if I then log out with the root user and re-log in, the command fails
> with:
> 
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> call to cgmanager_get_tasks_sync failed: invalid request
> 
> Can you please check why the command fails after re-log in?

My guess would be that your new login is in a different cgroup from the
old.  The path 'user.slice/user-1000.slice' is relative to your current
path.  What does

cgm getpidcgroupabs memory $$

show before and after logging back in?

Bug#857295: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

[Serge E. Hallyn]

On Tue, Mar 28, 2017 at 06:45:34AM -0400, Stiepan wrote:
> Thanks to the 2.0.7-2 update by Evgeni Golov and his crystal-clear 
> instructions on how to use lxcbr0 with this version, I could confirm that the 
> issue with the host's routing table being affected by changes in the 
> containers' routing tables is not there anymore when using that version (lxc 
> 2.0.7-2 from jessie-backports), which includes the fixes to CVE-2017-5985 
> which were brought in LXC 2.0.7 (upstream).
> 
> This was thus basically a variation of said CVE, which probably doesn't need 
> to be separately numbered as such, the core problem at stake being the same:
> network namespace ownership was not respected by a setuid-root program 
> enabling the user to configure networks as non-root, which is now solved.
> This leads me to a suggestion to the upstream developers: couldn't the same 
> be achieved using specific network-related capabilities, instead of 
> setuid-root, thereby further reducing the risk of lxc-user-nic being 
> exploited and hence, reducing overall attack surface (in unprivileged mode)?
> I have read in https://wiki.ubuntu.com/UserNamespace that the approach of 
> using "targeted capabilities" was then considered. This is probably the 
> closest to what I am suggesting (specifically for lxc-user-nic - the current 
> approach with 1-1 uid mappings seems fine for network-unrelated things).

The targeted capabilities wouldn't help here, because in fact
lxc-user-nic requires privilege against the parent namespace.

-serge