Bug#1059462: g++-13: GCC 13 for Bookworm

[Olaf van der Spek]

Package: g++-13
Severity: wishlist
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Would it be possible to provide GCC 13 for Bookworm, perhaps via backports?

Olaf

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

Kernel: Linux 6.1.0-16-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1059398: httping: New Upstream Version

[Olaf van der Spek]

Package: httping
Version: 2.5-5.2+b1
Severity: wishlist
X-Debbugs-Cc: olafvds...@gmail.com

Hi,

A new version has been released upstream: 
https://github.com/folkertvanheusden/HTTPing/releases

Olaf


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

Kernel: Linux 6.6.8-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 httping depends on:
ii  libc6 2.37-13
ii  libfftw3-double3  3.3.10-1
ii  libncursesw6  6.4+20231209-1
ii  libssl3   3.1.4-2
ii  libtinfo6 6.4+20231209-1
ii  openssl   3.1.4-2

httping recommends no packages.

httping suggests no packages.

-- no debconf information

Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

[Olaf van der Spek]

Op wo 19 apr 2023 om 06:04 schreef Anton Gladky :
>
> Hi,
>
> boost-defaults_1.81.0 is in experimental. But boost1.81
> is also available in the Debian Bookworm [1].
>
> [1] https://packages.debian.org/source/testing/boost1.81

Hi Anton,

Ah, it's even available in bpo, thanks a lot!


-- 
Olaf

Bug#1024294: cmake: Why conflict with linux-image-6.0.0-2-amd64?

[Olaf van der Spek]

Package: cmake
Followup-For: Bug #1024294
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Nevermind, it seems to be an unrelated issue:

# apt install cmake
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 cmake : Depends: cmake-data (= 3.25.0-1) but 3.24.3-1 is to be installed
E: Unable to correct problems, you have held broken packages.

Greetings,

Olaf

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cmake depends on:
ii  cmake-data3.24.3-1
ii  libarchive13  3.6.0-1
ii  libc6 2.36-5
ii  libcurl4  7.86.0-2
ii  libexpat1 2.5.0-1
ii  libgcc-s1 12.2.0-9
ii  libjsoncpp25  1.9.5-4
ii  librhash0 1.4.3-3
ii  libstdc++612.2.0-9
ii  libuv11.44.2-1
ii  procps2:3.3.17-7.1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages cmake recommends:
ii  gcc   4:12.2.0-1
ii  make  4.3-4.1

Versions of packages cmake suggests:
pn  cmake-doc 
pn  cmake-format  
ii  ninja-build   1.11.1-1

-- no debconf information

Bug#1024294: cmake: Why conflict with linux-image-6.0.0-2-amd64?

[Olaf van der Spek]

Package: cmake
Version: 3.24.3-1
Severity: wishlist
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Maybe not a bug, but why does cmake conflict with this kernel image?

Greetings,

Olaf

# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  linux-image-6.0.0-2-amd64
The following packages have been kept back:
  cmake
0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
After this operation, 478 MB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 100203 files and directories currently installed.)
Removing linux-image-6.0.0-2-amd64 (6.0.6-2) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.0.0-2-amd64
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.0.0-4-amd64
Found initrd image: /boot/initrd.img-6.0.0-4-amd64
Found linux image: /boot/vmlinuz-6.0.0-3-amd64
Found initrd image: /boot/initrd.img-6.0.0-3-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cmake depends on:
ii  cmake-data3.24.3-1
ii  libarchive13  3.6.0-1
ii  libc6 2.36-5
ii  libcurl4  7.86.0-2
ii  libexpat1 2.5.0-1
ii  libgcc-s1 12.2.0-9
ii  libjsoncpp25  1.9.5-4
ii  librhash0 1.4.3-3
ii  libstdc++612.2.0-9
ii  libuv11.44.2-1
ii  procps2:3.3.17-7.1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages cmake recommends:
ii  gcc   4:12.2.0-1
ii  make  4.3-4.1

Versions of packages cmake suggests:
pn  cmake-doc 
pn  cmake-format  
ii  ninja-build   1.11.1-1

-- no debconf information

Bug#1020615: adduser: README.Debian doesn't seem to exist

[Olaf van der Spek]

Op ma 26 sep. 2022 om 15:19 schreef Marc Haber
:
>
> On Mon, Sep 26, 2022 at 03:18:39PM +0200, Marc Haber wrote:
> > Thanks for spotting this. Fixed in git. MR 65 created.
>
> In the mean time, find the information on salsa:
>
> https://salsa.debian.org/debian/adduser/-/blob/master/debian/README

Some feedback / typos:

> Sadly, currently (summer 2022, adduser 3.125) locking and unlocking accounts 
> it not well supported yet.

is? not

> Debian pacakges.

packages?

> to add the Desired support

desired?

> regular user's home directory to 0700 while keeping
the mode permissive setting

more?

> has oscillated back in forth

and?

> distributions, none of which setting the sgid bit on home directories to
1 (research done in July 2022).

set*


-- 
Olaf

Bug#1020615: adduser: README.Debian doesn't seem to exist

[Olaf van der Spek]

Package: adduser
Version: 3.129
Severity: normal
X-Debbugs-Cc: olafvds...@gmail.com

Hi,

> See /usr/share/doc/adduser/README.Debian for detailed reasoning.

$ cat /usr/share/doc/adduser/README.Debian
cat: /usr/share/doc/adduser/README.Debian: No such file or directory

$ l /usr/share/doc/adduser
total 56
-rw-r--r-- 1 root root 27798 Sep  5 21:57 changelog.gz
-rw-r--r-- 1 root root 12317 Sep  5 21:57 copyright
drwxr-xr-x 3 root root  4096 Sep 10 13:29 examples
-rw-r--r-- 1 root root   988 Sep  5 21:57 NEWS.Debian.gz
-rw-r--r-- 1 root root  1044 Sep  5 21:57 TODO

Greetings,

Olaf

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 adduser depends on:
ii  passwd  1:4.11.1+dfsg1-2

adduser recommends no packages.

Versions of packages adduser suggests:
ii  cron3.0pl1-149
ii  liblocale-gettext-perl  1.07-4+b2
ii  perl5.34.0-5

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

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Package: libc6
Version: 2.31-13
Followup-For: Bug #990069
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

The original issue of not being able to open a new SSH connection during the 
upgrade still seems to be present.

Greetings,

Olaf

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 libc6 depends on:
ii  libcrypt1  1:4.4.18-4
ii  libgcc-s1  10.2.1-6

Versions of packages libc6 recommends:
ii  libidn2-0   2.3.0-5
ii  libnss-nis  3.1-4
ii  libnss-nisplus  1.3-4

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.77
pn  glibc-doc  
ii  libc-l10n  2.31-13
ii  locales2.31-13

-- debconf information:
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/restart-services:
  glibc/restart-failed:

Bug#990069: closed by Debian FTP Masters (reply to Aurelien Jarno ) (Bug#990069: fixed in glibc 2.31-13)

[Olaf van der Spek]

Op di 6 jul. 2021 om 22:21 schreef Debian Bug Tracking System
:
> Changes:
>  glibc (2.31-13) unstable; urgency=medium
>  .
>[ Colin Watson ]
>* debian/debhelper.in/libc.postinst, script.in/nsscheck.sh: Look for
>  openssh-server package rather than ssh.  Closes: #990069

Hi,

I tried a buster -> unstable upgrade.
While the upgrade is waiting for a response to "Restart services
during package upgrades without asking?" ssh is still down.
It seems to stay down until the end of the apt run.

Greetings,

Olaf

Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 31902 files and directories currently installed.)
Preparing to unpack .../base-files_11.1_amd64.deb ...
Unpacking base-files (11.1) over (10.3+deb10u10) ...
Setting up base-files (11.1) ...
Installing new version of config file /etc/debian_version ...
Installing new version of config file /etc/dpkg/origins/debian ...
Installing new version of config file /etc/issue ...
Installing new version of config file /etc/issue.net ...
Updating /etc/profile to current default.
Updating /root/.profile to current default.
(Reading database ... 31902 files and directories currently installed.)
Preparing to unpack .../debianutils_4.11.2_amd64.deb ...
Unpacking debianutils (4.11.2) over (4.8.6.1) ...
Setting up debianutils (4.11.2) ...
(Reading database ... 31902 files and directories currently installed.)
Preparing to unpack .../archives/bash_5.1-3_amd64.deb ...
Unpacking bash (5.1-3) over (5.0-4) ...
Setting up bash (5.1-3) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to
provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
(Reading database ... 31903 files and directories currently installed.)
Preparing to unpack .../bsdmainutils_12.1.7+nmu3_all.deb ...
renamed '/etc/default/bsdmainutils' -> '/etc/default/bsdmainutils.dpkg-remove'
renamed '/etc/cron.daily/bsdmainutils' ->
'/etc/cron.daily/bsdmainutils.dpkg-remove'
Unpacking bsdmainutils (12.1.7+nmu3) over (11.1.2+b1) ...
dpkg: warning: unable to delete old directory '/etc/calendar':
Directory not empty
Selecting previously unselected package bsdextrautils.
Preparing to unpack .../bsdextrautils_2.36.1-7_amd64.deb ...
Unpacking bsdextrautils (2.36.1-7) ...
Selecting previously unselected package gcc-10-base:amd64.
Preparing to unpack .../gcc-10-base_10.2.1-6_amd64.deb ...
Unpacking gcc-10-base:amd64 (10.2.1-6) ...
Setting up gcc-10-base:amd64 (10.2.1-6) ...
Selecting previously unselected package libgcc-s1:amd64.
(Reading database ... 31824 files and directories currently installed.)
Preparing to unpack .../libgcc-s1_10.2.1-6_amd64.deb ...
Unpacking libgcc-s1:amd64 (10.2.1-6) ...
Replacing files in old package libgcc1:amd64 (1:8.3.0-6) ...
Setting up libgcc-s1:amd64 (10.2.1-6) ...
Selecting previously unselected package libcrypt1:amd64.
(Reading database ... 31826 files and directories currently installed.)
Preparing to unpack .../libcrypt1_1%3a4.4.18-4_amd64.deb ...
Unpacking libcrypt1:amd64 (1:4.4.18-4) ...
Replacing files in old package libc6:amd64 (2.28-10) ...
Setting up libcrypt1:amd64 (1:4.4.18-4) ...
(Reading database ... 31831 files and directories currently installed.)
Preparing to unpack .../libc-l10n_2.31-13_all.deb ...
Unpacking libc-l10n (2.31-13) over (2.28-10) ...
Preparing to unpack .../locales_2.31-13_all.deb ...
Unpacking locales (2.31-13) over (2.28-10) ...
Selecting previously unselected package libcbor0:amd64.
Preparing to unpack .../libcbor0_0.5.0+dfsg-2_amd64.deb ...
Unpacking libcbor0:amd64 (0.5.0+dfsg-2) ...
Selecting previously unselected package libfido2-1:amd64.
Preparing to unpack .../libfido2-1_1.6.0-2_amd64.deb ...
Unpacking libfido2-1:amd64 (1.6.0-2) ...
Preparing to unpack .../libselinux1_3.1-3_amd64.deb ...
Unpacking libselinux1:amd64 (3.1-3) over (2.8-1+b1) ...
Setting up libselinux1:amd64 (3.1-3) ...
(Reading database ... 31844 files and directories currently installed.)
Preparing to unpack .../openssh-sftp-server_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Selecting previously unselected package runit-helper.
Preparing to unpack .../runit-helper_2.10.3_all.deb ...
Unpacking runit-helper (2.10.3) ...
Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../libc6_2.31-13_amd64.deb ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
Setting up libc6:amd64 (2.31-13) ...
Checking for services that may need to be restarted...
Checking init scripts...
Configuring libc6:amd64
---

There are services installed on your system which need to be restarted
when certain libraries, such as libpam, libc, and libssl, are

Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Olaf van der Spek]

On Tue, Jul 6, 2021 at 1:19 AM Otto Kekäläinen  wrote:
>
> On Mon, Jul 5, 2021 at 1:12 PM Olaf van der Spek  wrote:
> >
> > On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen  wrote:
> > > I wish somebody could contribute with exact steps on how to reproduce
> > > the issue. So far I've gotten some half attempts at that but they
> > > haven't been actionable for me.
> >
> > Hi Otto,
> >
> > I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089
> > Not sure why it's not reproducible with those steps.
>
> I don't see *the* steps, but I see a lot of messages about many
> different steps. If you have them, why not copy-paste the steps here
> in email so I can copy-paste them into a Debian Buster Docker
> container and run the upgrade to isolate the regression?

Docker might be the problem, I'd try a real VM.


I do have this in a VM so I think we can easily repro this.

// Fresh VM install from debian-10.9.0-i386-netinst.iso
# history
1  visudo
2  rm /etc/motd
3  poweroff
4  apt install mariadb-server
5  dpkg -l|grep mariadb
6  sed -i 's/buster/bullseye/g' /etc/apt/sources.list
7  apt update
8  apt upgrade
9  apt dist-upgrade // output below
   10  dpkg -l|grep mariadb // output below
   11  apt dist-upgrade // output below
   12  history

-- 
Olaf

Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Olaf van der Spek]

On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen  wrote:
> I wish somebody could contribute with exact steps on how to reproduce
> the issue. So far I've gotten some half attempts at that but they
> haven't been actionable for me.

Hi Otto,

I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089
Not sure why it's not reproducible with those steps.


Greetings,
-- 
Olaf

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Op zo 4 jul. 2021 om 00:42 schreef Colin Watson :
> Sorry for my delay - it took me a while to spot the problem.  libc6's
> postinst does arrange to restart services where needed, but in this case
> it doesn't realize that you have the ssh service installed because you
> only have the openssh-server package installed, not the ssh metapackage
> (i.e. the package with the same name as the service).
>
> I've proposed
> https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix
> this.  glibc maintainers, if there's any way to get this into bullseye,
> I'm sure it would help avoid some people upgrading remote systems ending
> up being unable to fix them if something goes wrong between configuring
> libc6 and configuring openssh-server.  Also CCing debian-release for
> their information, as I know it's pretty late for glibc changes.

Thanks Colin!

I assume openssh-server would then be restarted after the "There are
services installed on your system which need to be
restarted when certain libraries, such as libpam, libc, and libssl,
are upgraded." question. But ssh is already 'down' when that question
is being asked, so wouldn't there still be a time window, with
required user interaction, where ssh would be 'down'?




-- 
Olaf

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Op zo 20 jun. 2021 om 10:38 schreef Olaf van der Spek :
>
> So I think it's not accepting new connections from the start of the
> upgrade run until the end:
> Setting up openssh-sftp-server (1:8.4p1-5) ...
> Setting up console-setup (1.203) ...
> Setting up mime-support (3.66) ...
> Setting up openssh-server (1:8.4p1-5) ...
> Installing new version of config file /etc/init.d/ssh ...
> Installing new version of config file /etc/ssh/moduli ...
> Replacing config file /etc/ssh/sshd_config with new version
> rescue-ssh.target is a disabled or a static unit, not starting it.

Hi Colin,

Any thoughts on this?

-- 
Olaf

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

So I think it's not accepting new connections from the start of the
upgrade run until the end:
Setting up openssh-sftp-server (1:8.4p1-5) ...
Setting up console-setup (1.203) ...
Setting up mime-support (3.66) ...
Setting up openssh-server (1:8.4p1-5) ...
Installing new version of config file /etc/init.d/ssh ...
Installing new version of config file /etc/ssh/moduli ...
Replacing config file /etc/ssh/sshd_config with new version
rescue-ssh.target is a disabled or a static unit, not starting it.

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Op za 19 jun. 2021 om 13:13 schreef Colin Watson :
>
> On Sat, Jun 19, 2021 at 12:53:48PM +0200, Olaf van der Spek wrote:
> > During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be 
> > accepting new connections. IMO this is less than optimal, and not sure if 
> > this was always the case.
> > Would it be possible to keep accepting connections, or at least to make the 
> > time window in which SSH is down as short as possible?

FYI, this is when it's waiting for a reply to this question:
Configuring libc6:amd64
 | There are services installed on your system which need to be
restarted when certain libraries, such as libpam, libc, and libssl,
are upgraded. Since these restarts may cause interruptions   |
 | of service for the system, you will normally be prompted on each
upgrade for the list of services you wish to restart.  You can choose
this option to avoid being prompted; instead, all  |
 | necessary restarts will be done for you automatically so you can
avoid being asked questions on each library upgrade.
  |
 |

   |
 | Restart services during package upgrades without asking?

$ ssh localhost
kex_exchange_identification: read: Connection reset by peer
Connection reset by ::1 port 22

/var/log/auth:
Jun 20 10:00:43 alpha sshd[10140]: fatal: recv_rexec_state: buffer
error: incomplete message



> That's odd, because we already take care to do that.  Any chance of some
> logs?  I think the most useful things would be /var/log/dpkg.log,

2021-05-09 10:03:01 status installed systemd:amd64 241-7~deb10u7
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade base-files:amd64 10.3+deb10u9 10.3+deb10u10
2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u9
2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u9
2021-06-20 09:40:28 status half-installed base-files:amd64 10.3+deb10u9
2021-06-20 09:40:28 status triggers-pending man-db:amd64 2.8.5-2
2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure base-files:amd64 10.3+deb10u10 
2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 status installed base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade libgcrypt20:amd64 1.8.4-5 1.8.4-5+deb10u1
2021-06-20 09:40:28 status triggers-pending libc-bin:amd64 2.28-10
2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5
2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5
2021-06-20 09:40:28 status half-installed libgcrypt20:amd64 1.8.4-5
2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure libgcrypt20:amd64 1.8.4-5+deb10u1 
2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 status installed libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade libnettle6:amd64 3.4.1-1 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1
2021-06-20 09:40:28 status half-installed libnettle6:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure libnettle6:amd64 3.4.1-1+deb10u1 
2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status installed libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade libhogweed4:amd64 3.4.1-1 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1
2021-06-20 09:40:28 status half-installed libhogweed4:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure libhogweed4:amd64 3.4.1-1+deb10u1 
2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status installed libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:29 upgrade libgnutls30:amd64 3.6.7-4+deb10u6 3.6.7-4+deb10u7
2021-06-20 09:40:29 status half-configured libgnutls30:amd64 3.6.7-4+deb10u6
2021-06-20 09:40:29 status unpacked libgnutls30:amd64 3.6.7-4+deb10u6
2021-06-20 09:40:29 status half-installed libgnutls30:amd

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Package: openssh-server
Version: 1:8.4p1-5
Severity: normal

Dear Maintainer,

During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be accepting 
new connections. IMO this is less than optimal, and not sure if this was always 
the case.
Would it be possible to keep accepting connections, or at least to make the 
time window in which SSH is down as short as possible?

Greetings,

Olaf

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
iu  libc6  2.31-12
ii  libcom-err21.44.5-1+deb10u3
ii  libcrypt1  1:4.4.18-4
ii  libgssapi-krb5-2   1.17-3+deb10u1
ii  libkrb5-3  1.17-3+deb10u1
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux13.1-3
ii  libssl1.1  1.1.1d-0+deb10u6
ii  libsystemd0241-7~deb10u7
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
iu  openssh-client 1:8.4p1-5
iu  openssh-sftp-server1:8.4p1-5
ii  procps 2:3.3.15-2
iu  runit-helper   2.10.3
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  241-7~deb10u7
ii  ncurses-term 6.1+20181013-2+deb10u2
ii  xauth1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: true
  openssh-server/password-authentication: true

Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

> Op za 22 mei 2021 om 23:30 schreef Otto Kekäläinen :
> > Would somebody like to review/test it?

Doesn't seem to be working for me:

# apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  libpython-stdlib mariadb-client-10.3 mariadb-client-core-10.3
mariadb-server mariadb-server-10.3 mariadb-server-core-10.3 python
python-minimal
The following packages will be upgraded:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

# apt dist-upgrade -o Debug::pkgDepCache::AutoInstall=1 -o
Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
  MarkInstall initramfs-tools-core:amd64 < 0.140 @ii mK NPb IPb > FU=0
  ignore old unsatisfied important dependency on pigz:amd64
   Delayed Removing: libpython-stdlib:amd64 as upgrade is not an
option for python2.7-minimal:amd64 (2.7.18-7)
   Delayed Removing: python:amd64 as upgrade is not an option for
python2.7-minimal:amd64 (2.7.18-7)
   Delayed Removing: python-minimal:amd64 as upgrade is not an option
for python2.7-minimal:amd64 (2.7.18-7)
  MarkInstall python2.7-minimal:amd64 < 2.7.16-2+deb10u1 -> 2.7.18-7
@ii umU Ib > FU=0
  MarkDelete libpython-stdlib:amd64 < 2.7.16-1 @ii mK Ib > FU=0
  MarkDelete python:amd64 < 2.7.16-1 @ii mK Ib > FU=0
  MarkDelete python-minimal:amd64 < 2.7.16-1 @ii mK Ib > FU=0
  MarkInstall iptables:amd64 < 1.8.7-1 @ii mK NPb IPb > FU=0
  ignore old unsatisfied important dependency on nftables:amd64
  MarkInstall mariadb-server:amd64 < 1:10.3.29-0+deb10u1 ->
1:10.5.10-2 @ii umU Ib > FU=0
  Installing mariadb-server-10.5:amd64 as Depends of mariadb-server:amd64
 Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not an
option for mariadb-server-10.5:amd64 (1:10.5.10-2)
 Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not an
option for mariadb-server-10.5:amd64 (1:10.5.10-2)
MarkInstall mariadb-server-10.5:amd64 < none -> 1:10.5.10-2 @un uN Ib > FU=0
Installing galera-4:amd64 as Depends of mariadb-server-10.5:amd64
  MarkKeep galera-3:amd64 < 25.3.25-2 -> 25.3.31-2+b1 @ii umU > FU=0
   Delayed Removing: galera-3:amd64 as upgrade is not an option
for galera-4:amd64 (26.4.8-1)
   Delayed Removing: galera-3:amd64 as upgrade is not an option
for galera-4:amd64 (26.4.8-1)
   Delayed Removing: galera-3:amd64 as upgrade is not an option
for galera-4:amd64 (26.4.8-1)
   Delayed Removing: galera-3:amd64 as upgrade is not an option
for galera-4:amd64 (26.4.8-1)
  MarkInstall galera-4:amd64 < none -> 26.4.8-1 @un uN Ib > FU=0
  MarkDelete galera-3:amd64 < 25.3.25-2 | 25.3.31-2+b1 @ii umH Ib > FU=0
Installing mariadb-client-10.5:amd64 as Depends of mariadb-server-10.5:amd64
   Delayed Removing: mariadb-client-10.3:amd64 as upgrade is not
an option for mariadb-client-10.5:amd64 (1:10.5.10-2)
   Delayed Removing: mariadb-client-10.3:amd64 as upgrade is not
an option for mariadb-client-10.5:amd64 (1:10.5.10-2)
   Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade is
not an option for mariadb-client-10.5:amd64 (1:10.5.10-2)
  MarkInstall mariadb-client-10.5:amd64 < none -> 1:10.5.10-2 @un
uN Ib > FU=0
  Installing mariadb-client-core-10.5:amd64 as Depends of
mariadb-client-10.5:amd64
 Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade
is not an option for mariadb-client-core-10.5:amd64 (1:10.5.10-2)
 Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade
is not an option for mariadb-client-core-10.5:amd64 (1:10.5.10-2)
MarkInstall mariadb-client-core-10.5:amd64 < none ->
1:10.5.10-2 @un uN Ib > FU=0
MarkDelete mariadb-client-core-10.3:amd64 <
1:10.3.29-0+deb10u1 @ii mK Ib > FU=0
  MarkDelete mariadb-client-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii
mK Ib > FU=0
Installing mariadb-server-core-10.5:amd64 as Depends of
mariadb-server-10.5:amd64
   Delayed Removing: mariadb-server-core-10.3:amd64 as upgrade is
not an option for mariadb-server-core-10.5:amd64 (1:10.5.10-2)
   Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not
an option for mariadb-server-core-10.5:amd64 (1:10.5.10-2)
   Delayed Removing: mariadb-server-core-10.3:amd64 as upgrade is
not an option for mariadb-server-core-10.5:amd64 (1:10.5.10-2)
  MarkInstall mariadb-server-core-10.5:amd64 < none -> 1:10.5.10-2
@un uN Ib > FU=0
  MarkDelete mariadb-server-core-10.3:amd64 < 1:10.3.29-0+deb10u1
@ii mK Ib > FU=0
  MarkDelete mariadb-server-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii
mK Ib > FU=0
MarkKeep python-minimal:amd64 < 2.7.16-1 @ii mR > FU=0
  MarkInstall libcap2-bin:amd64 < 1:2.44-1 @ii mK NPb IPb > FU=0
  ignore old unsatisfied important dependency on 

Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Op za 22 mei 2021 om 23:30 schreef Otto Kekäläinen :
>
> Hello!
>
> On Sun, May 16, 2021 at 4:18 PM Otto Kekäläinen  wrote:
> >
> >
> >> > But as said, the bug #988089 can only be fixed by a change in galera-4
> >> > debian/control. Changing the mariadb-10.5 debian/control to
> >> > recommends:galera-4 is a separate change.
> >> Ok but I have no idea how this should be handled then.
> >
> >
> > I outlined the exact galera-4 debugging steps in my email on May 13th. The 
> > solution can be found and also tested/validated easily with those steps.
>
> I had some spare time today and followed those steps, resulting in
> this MR: https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/5

Thanks a lot!

> Would somebody like to review/test it?

Conflicts: galera, galera-3, ...
Breaks: galera, galera-3

> When one binary package declares a conflict with another using a Conflicts 
> field, dpkg will refuse to allow them to be unpacked on the system at the 
> same time. This is a stronger restriction than Breaks,

Based on the text I'd assume it doesn't make sense to have a package
in both conflicts and breaks. Am I reading the text wrong?

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

-- 
Olaf

Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Olaf van der Spek]

Op za 22 mei 2021 om 23:54 schreef Trevor Cordes :
> So now mariadb should allow sane ^W settings now matter how it is
> compiled:
> - with readline: always worked
> - with libedit that comes with maria-db: always worked
> - with your system libedit: now works once you add settings to .editrc
>   and use this latest libedit verion (libedit-20210522-3.1 or
>   newer)

It'd be nice if ^W worked by default.


-- 
Olaf

Bug#976147: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Op vr 14 mei 2021 om 09:53 schreef Otto Kekäläinen :
> Investigating (0) galera-4:amd64 < none -> 26.4.7-3 @un uN Ib >
> Broken galera-4:amd64 Conflicts on galera-3:amd64 < 25.3.25-2 ->
> 25.3.31-2+b1 @ii umU Ib >
>   Considering galera-3:amd64 0 as a solution to galera-4:amd64 0
>   Holding Back galera-4:amd64 rather than change galera-3:amd64

I think here it should remove galera-3 rather than holding back galera4..



-- 
Olaf

Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Olaf van der Spek]

Op za 22 mei 2021 om 04:27 schreef Trevor Cordes :
>
> On Thu, 26 Nov 2020 12:50:26 -0500 The Wanderer 
> wrote:
> Which means at one time this was fixed.  That's why this used to work
> for us.  But something must have regressed in the source, and the fix

MariaDB 10.3 uses libreadline-gplv2
MariaDB 10.5 uses libedit
I think this explains the changes in behavior.

-- 
Olaf

Bug#988547: apt: Apt seems to keep back galera-3 without reason

[Olaf van der Spek]

Op za 15 mei 2021 om 18:10 schreef David Kalnischkies :
> So upgrading mariadb will bring you galera-4 which conflicts with
> galera-3. Package removals are not allowed in 'upgrade' so this mariadb
> upgrade will be reverted and you will get it in the next step with
> a full-upgrade – which will remove galera-3.

That seems to be another problem, it does actually upgrade galera-3
and remove mariadb 10.3, but it does NOT install mariadb 10.5:

# apt dist-upgrade
The following packages will be REMOVED:
  libpython-stdlib mariadb-client-10.3 mariadb-client-core-10.3
mariadb-server mariadb-server-10.3 mariadb-server-core-10.3 python
python-minimal
The following packages will be upgraded:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.


> In regards to the mariadb versioned packages and the potential for
> upgrade problems they produce I had recently talked to its maintainer,
> so I doubt that will change any time soon…
> https://lists.debian.org/debian-devel/2021/03/msg00239.html

If it's okay with you I'd like to talk about that, but I think that'll
be for Debian 12.


-- 
Olaf

Bug#976147: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Hi,

Another interesting observation. After upgrading galera-3 from buster
to bullseye first, apt will install 10.5..

# apt full-upgrade
The following packages will be REMOVED:
  libpython-stdlib mariadb-client-10.3 mariadb-client-core-10.3
mariadb-server mariadb-server-10.3 mariadb-server-core-10.3 python
python-minimal
The following packages will be upgraded:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

# apt install galera-3
The following packages will be upgraded:
  galera-3
1 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.

# apt full-upgrade
The following packages will be REMOVED:
  galera-3 libpython-stdlib mariadb-client-10.3
mariadb-client-core-10.3 mariadb-server-10.3 mariadb-server-core-10.3
python python-minimal
The following NEW packages will be installed:
  galera-4 mariadb-client-10.5 mariadb-client-core-10.5
mariadb-server-10.5 mariadb-server-core-10.5
The following packages will be upgraded:
  libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
mariadb-server python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 5 newly installed, 8 to remove and 0 not upgraded.

Bug#988547: apt: Apt seems to keep back galera-3 without reason

[Olaf van der Spek]

Package: apt
Version: 2.2.3
Severity: minor
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Upgrading galera-3 appears to be possible without troubles according to  the 
second invocation, so shouldn't the first invocation just do that upgrade?

# apt upgrade
The following packages have been kept back:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib 
mariadb-server python2 python2-minimal python2.7 python2.7-minimal
0 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.

# apt upgrade galera-3
The following packages have been kept back:
  libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib mariadb-server 
python2 python2-minimal python2.7 python2.7-minimal
The following packages will be upgraded:
  galera-3
1 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
Need to get 882 kB of archives.
After this operation, 308 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

Greetings,

Olaf

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::LastInstalledKernel "5.10.0-6-amd64";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc 

Bug#976147: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Op vr 14 mei 2021 om 09:53 schreef Otto Kekäläinen :
> As Faustin pointed out, Bullseye has both galera-3 and galera-4. This
> is so the distro is compatible with running whatever version of
> MariaDB you want. Galera-3 will be in Debian (and Ubuntu) repositories
> for as long as somebody is still using MariaDB 10.1-10.3.
>
> MariaDB 10.3 in Debian Buster depends on Galera 3. Thus, if you
> install Galera 4, which uninstalls Galera 3 (they cannot be installed
> at the same time on the same system as the files and commands
> overlap), and as a dependency of MariaDB 10.3 goes away it also
> uninstalls.

Not directly related, but:
Should Galera be a Depends of MariaDB? Wouldn't a Recommends or even
just a Suggests be good enough?

Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Op vr 14 mei 2021 om 08:21 schreef Olaf van der Spek :
> > - why installing galera-4 removes mariadb-server-10.3, see bellow:

galera-4 conflicts with galera-3
mariadb-server-10.3 depends on galera-3

Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Op wo 12 mei 2021 om 13:03 schreef Faustin Lammler :
> Here are some questions regarding galera (because I believe the problem
> might come from it):
> - why bullseye/sid provide both galera-3 and galera-4?
> - why installing galera-4 removes mariadb-server-10.3, see bellow:

On that topic, shouldn't galera-3 be in the replaces (and maybe breaks) fields?
Does it make sense to have packages in both Breaks and Conflicts?
Conflicts seems to be a stronger version of Breaks.

Package: galera-4
Architecture: any
Section: libs
Depends: ${misc:Depends},
 ${shlibs:Depends}
Conflicts: galera-3,
   garbd-2,
   garbd-3,
   garbd2,
   garbd3,
   percona-galera-3,
   percona-galera-4,
   percona-xtradb-cluster-galera,
   percona-xtradb-cluster-galera-2.x,
   percona-xtradb-cluster-galera-3.x,
   percona-xtradb-cluster-galera-4.x,
   percona-xtradb-cluster-garbd-2.x,
   percona-xtradb-cluster-garbd-3.x
Provides: galera,
  galera4,
  percona-xtradb-cluster-galera-26,
  wsrep
Breaks: galera
Replaces: galera

https://salsa.debian.org/mariadb-team/galera-4/-/blob/master/debian/control

Bug#976147: MariaDB upgrade issues from Debian 10 to Debian 11

[Olaf van der Spek]

Op zo 9 mei 2021 om 08:40 schreef Otto Kekäläinen :
> Here is a debian-devel thread where I learnt new ways to run apt in
> debug mode to better see why it chooses to upgrade/remove certain
> packages, it might be helpful here too:
> https://lists.debian.org/debian-devel/2021/03/msg00139.html
> https://lists.debian.org/debian-devel/2021/03/msg00131.html

# apt upgrade -o Debug::pkgDepCache::AutoInstall=1 -o
Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
  MarkInstall mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1
@ii umU Ib > FU=0
  Installing mariadb-server-10.5:amd64 as Depends of mariadb-server:amd64
 Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not an
option for mariadb-server-10.5:amd64 (1:10.5.9-1)
 Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not an
option for mariadb-server-10.5:amd64 (1:10.5.9-1)
MarkInstall mariadb-server-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > FU=0
Installing galera-4:amd64 as Depends of mariadb-server-10.5:amd64
   Delayed Removing: galera-3:amd64 as upgrade is not an option
for galera-4:amd64 (26.4.7-3)
   Delayed Removing: galera-3:amd64 as upgrade is not an option
for galera-4:amd64 (26.4.7-3)
  MarkInstall galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > FU=0
  MarkDelete galera-3:amd64 < 25.3.31-2+b1 @ii mK Ib > FU=0
Installing mariadb-client-10.5:amd64 as Depends of mariadb-server-10.5:amd64
   Delayed Removing: mariadb-client-10.3:amd64 as upgrade is not
an option for mariadb-client-10.5:amd64 (1:10.5.9-1)
   Delayed Removing: mariadb-client-10.3:amd64 as upgrade is not
an option for mariadb-client-10.5:amd64 (1:10.5.9-1)
   Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade is
not an option for mariadb-client-10.5:amd64 (1:10.5.9-1)
  MarkInstall mariadb-client-10.5:amd64 < none -> 1:10.5.9-1 @un
uN Ib > FU=0
  Installing mariadb-client-core-10.5:amd64 as Depends of
mariadb-client-10.5:amd64
 Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade
is not an option for mariadb-client-core-10.5:amd64 (1:10.5.9-1)
 Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade
is not an option for mariadb-client-core-10.5:amd64 (1:10.5.9-1)
MarkInstall mariadb-client-core-10.5:amd64 < none ->
1:10.5.9-1 @un uN Ib > FU=0
MarkDelete mariadb-client-core-10.3:amd64 <
1:10.3.27-0+deb10u1 @ii mK Ib > FU=0
  MarkDelete mariadb-client-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii
mK Ib > FU=0
Installing mariadb-server-core-10.5:amd64 as Depends of
mariadb-server-10.5:amd64
   Delayed Removing: mariadb-server-core-10.3:amd64 as upgrade is
not an option for mariadb-server-core-10.5:amd64 (1:10.5.9-1)
   Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not
an option for mariadb-server-core-10.5:amd64 (1:10.5.9-1)
   Delayed Removing: mariadb-server-core-10.3:amd64 as upgrade is
not an option for mariadb-server-core-10.5:amd64 (1:10.5.9-1)
  MarkInstall mariadb-server-core-10.5:amd64 < none -> 1:10.5.9-1
@un uN Ib > FU=0
  MarkDelete mariadb-server-core-10.3:amd64 < 1:10.3.27-0+deb10u1
@ii mK Ib > FU=0
  MarkDelete mariadb-server-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii
mK Ib > FU=0
  MarkKeep galera-3:amd64 < 25.3.31-2+b1 @ii mR > FU=0
  MarkKeep mariadb-server-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
  MarkKeep mariadb-client-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
  MarkKeep mariadb-server-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
  MarkKeep mariadb-client-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
Entering ResolveByKeep
  Dependencies are not satisfied for galera-4:amd64 < none -> 26.4.7-3
@un uN Ib >
Keeping package galera-4:amd64
  MarkKeep galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > FU=0
  Dependencies are not satisfied for mariadb-client-core-10.5:amd64 <
none -> 1:10.5.9-1 @un uN Ib >
Keeping package mariadb-client-core-10.5:amd64
  MarkKeep mariadb-client-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > FU=0
  Dependencies are not satisfied for mariadb-client-10.5:amd64 < none
-> 1:10.5.9-1 @un uN Ib >
Keeping package mariadb-client-10.5:amd64
  MarkKeep mariadb-client-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > FU=0
  Dependencies are not satisfied for mariadb-server-10.5:amd64 < none
-> 1:10.5.9-1 @un uN Ib >
Keeping package mariadb-server-10.5:amd64
  MarkKeep mariadb-server-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > FU=0
  Dependencies are not satisfied for mariadb-server:amd64 <
1:10.3.27-0+deb10u1 -> 1:10.5.9-1 @ii umU Ib >
Keeping package mariadb-server:amd64
  MarkKeep mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1
@ii umU Ib > FU=0
  Dependencies are not satisfied for mariadb-server-core-10.5:amd64 <
none -> 1:10.5.9-1 @un uN Ib >
Keeping package mariadb-server-core-10.5:amd64
  MarkKeep mariadb-server-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > 

Bug#988089: [debian-mysql] Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

> So in summary everything else goes OK and upgrade passes

It would be kinda nice to end up with mariadb-server-10.5 too... ;)

Op do 6 mei 2021 om 21:43 schreef Otto Kekäläinen :
>
> So in summary everything else goes OK and upgrade passes, but there is
> one 'mariadb-server' metapackage removed which should have been kept:
>
> Removing mariadb-server (1:10.3.27-0+deb10u1) ...   <-
> Removing mariadb-server-10.3 (1:10.3.27-0+deb10u1) ...
> Removing mariadb-client-10.3 (1:10.3.27-0+deb10u1) ...
> Removing mariadb-client-core-10.3 (1:10.3.27-0+deb10u1) ...
> Removing mariadb-server-core-10.3 (1:10.3.27-0+deb10u1) ...



-- 
Olaf

Bug#988089: [debian-mysql] Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Op do 6 mei 2021 om 04:29 schreef Otto Kekäläinen :
>
> Thanks for reporting!
>
> We constantly test updates from older distros and MariaDB versions in
> our Salsa-CI pipeline, and it does not show the symptoms your system
> had.
>
> Would it be possible for you to provide exact steps on how to
> reproduce this in a Docker image or virtual machine?
>
> If it only happens on one machine and cannot be reproduced, we can't
> help much. Therefore steps to reproduce are very important.

Hi Otto,

Can't apt dump / log it's state so it's decisions can be easily reproduced?

I do have this in a VM so I think we can easily repro this.

// Fresh VM install from debian-10.9.0-i386-netinst.iso
# history
1  visudo
2  rm /etc/motd
3  poweroff
4  apt install mariadb-server
5  dpkg -l|grep mariadb
6  sed -i 's/buster/bullseye/g' /etc/apt/sources.list
7  apt update
8  apt upgrade
9  apt dist-upgrade // output below
   10  dpkg -l|grep mariadb // output below
   11  apt dist-upgrade // output below
   12  history

# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  bsdmainutils galera-3 geoip-database libaio1 libbind9-161
libcgi-fast-perl libcgi-pm-perl libclone-perl libconfig-inifiles-perl
libdbd-mysql-perl libdbi-perl libdns1104 libdns1110
libencode-locale-perl libfcgi-bin libfcgi-perl libfcgi0ldbl
  libgeoip1 libhtml-parser-perl libhtml-tagset-perl
libhtml-template-perl libhttp-date-perl libhttp-message-perl libicu63
libio-html-perl libisc1100 libisc1105 libisccc161 libisccfg163
liblwp-mediatypes-perl liblwres161 libmariadb3 libmpdec2
  libperl5.28 libpython2-stdlib libpython3.7-minimal
libpython3.7-stdlib libreadline5 libreadline7 libsnappy1v5
libterm-readkey-perl libtimedate-perl liburi-perl mariadb-common
mysql-common python2 python2-minimal python3.7 python3.7-minimal rsync
  socat
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  libpython-stdlib mariadb-client-10.3 mariadb-client-core-10.3
mariadb-server mariadb-server-10.3 mariadb-server-core-10.3 python
python-minimal
The following packages will be upgraded:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.
Need to get 5,012 kB of archives.
After this operation, 147 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

# dpkg -l|grep mariadb
ii  libmariadb3:i386  1:10.5.9-1 i386
   MariaDB database client library
ii  mariadb-client-10.3   1:10.3.27-0+deb10u1i386
   MariaDB database client binaries
ii  mariadb-client-core-10.3  1:10.3.27-0+deb10u1i386
   MariaDB database core client binaries
ii  mariadb-common1:10.5.9-1 all
   MariaDB common configuration files
ii  mariadb-server1:10.3.27-0+deb10u1all
   MariaDB database server (metapackage depending on the latest
version)
ii  mariadb-server-10.3   1:10.3.27-0+deb10u1i386
   MariaDB database server binaries
ii  mariadb-server-core-10.3  1:10.3.27-0+deb10u1i386
   MariaDB database core server files

# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  bsdmainutils galera-3 geoip-database libaio1 libbind9-161
libcgi-fast-perl libcgi-pm-perl libclone-perl libconfig-inifiles-perl
libdbd-mysql-perl libdbi-perl libdns1104 libdns1110
libencode-locale-perl libfcgi-bin libfcgi-perl libfcgi0ldbl
  libgeoip1 libhtml-parser-perl libhtml-tagset-perl
libhtml-template-perl libhttp-date-perl libhttp-message-perl libicu63
libio-html-perl libisc1100 libisc1105 libisccc161 libisccfg163
liblwp-mediatypes-perl liblwres161 libmariadb3 libmpdec2
  libperl5.28 libpython2-stdlib libpython3.7-minimal
libpython3.7-stdlib libreadline5 libreadline7 libsnappy1v5
libterm-readkey-perl libtimedate-perl liburi-perl mariadb-common
mysql-common python2 python2-minimal python3.7 python3.7-minimal rsync
  socat
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  libpython-stdlib mariadb-client-10.3 mariadb-client-core-10.3
mariadb-server mariadb-server-10.3 mariadb-server-core-10.3 python
python-minimal
The following packages will be upgraded:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.
Need to get 5,012 kB of archives.
After this operation, 147 MB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian 

Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Package: mariadb-server
Version: 1:10.5.9-1
Severity: normal
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Installed Debian 10, installed mariadb-server and some other stuff.
Updated sources.list to reference bullseye.
Did apt update
Did apt upgrade

# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  bsdmainutils cpp-8 galera-3 geoip-database libaio1 libasan5 libbind9-161 
libcgi-fast-perl libcgi-pm-perl libclone-perl libconfig-inifiles-perl 
libdbd-mysql-perl libdbi-perl libdns1104 libdns1110 libencode-locale-perl 
libevent-2.1-6 libevent-2.1-7
  libfam0 libfcgi-bin libfcgi-perl libfcgi0ldbl libgeoip1 libgmp-dev 
libgmpxx4ldbl libgnutls-dane0 libgnutls-openssl27 libgnutls28-dev libgnutlsxx28 
libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl libhttp-date-perl 
libhttp-message-perl
  libicu63 libidn2-dev libio-html-perl libisc1100 libisc1105 libisccc161 
libisccfg163 libisl19 libjsoncpp1 liblwp-mediatypes-perl liblwres161 libmpdec2 
libmpx2 libp11-kit-dev libperl5.28 libpython2-stdlib libpython3.7-minimal 
libpython3.7-stdlib
  libreadline5 libreadline7 libsnappy1v5 libtasn1-6-dev libtasn1-doc 
libterm-readkey-perl libtimedate-perl libunbound8 liburi-perl nettle-dev 
python2 python2-minimal python3.7-minimal rsync socat
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  g++-8 gcc-8 libboost1.67-dev libgcc-8-dev libpython-stdlib libstdc++-8-dev 
mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server mariadb-server-10.3 
mariadb-server-core-10.3 php7.3-cli php7.3-common php7.3-fpm php7.3-json 
php7.3-opcache
  php7.3-readline python python-minimal python3.7
The following NEW packages will be installed:
  cpp-10 fontconfig-config fonts-dejavu-core g++-10 gcc-10 libasan6 
libboost1.74-dev libbpf0 libbrotli1 libc-devtools libcbor0 libclone-perl 
libcrypt-dev libcrypt1 libdeflate0 libfcgi-bin libfcgi0ldbl libfido2-1 
libfontconfig1 libgcc-10-dev libgd3
  libicu67 libip4tc2 libip6tc2 libisl23 libjbig0 libjpeg62-turbo libmpdec3 
libnsl-dev libnss-nis libnss-nisplus libperl5.32 libpython3.9-minimal 
libpython3.9-stdlib libreadline8 libstdc++-10-dev libtiff5 libtirpc-dev 
libwebp6 libxpm4
  lighttpd-mod-deflate lighttpd-mod-openssl perl-modules-5.32 php7.4-cli 
php7.4-common php7.4-fpm php7.4-json php7.4-opcache php7.4-readline python3.9 
python3.9-minimal runit-helper systemd-timesyncd
The following packages will be upgraded:
  cpp g++ galera-3 gawk gcc groff-base iproute2 iptables libboost-dev libc-bin 
libc-dev-bin libc6 libc6-dev libcurl3-gnutls libcurl4 libdbd-mysql-perl 
libdbi-perl libfcgi-perl libfreetype6 libhtml-parser-perl libhttp-message-perl 
libiptc0
  liblocale-gettext-perl libnss-systemd libpam-modules libpam-modules-bin 
libpam-systemd libpng16-16 libpython2-stdlib libpython2.7-minimal 
libpython2.7-stdlib libpython3-stdlib libslang2 libsqlite3-0 libsystemd-dev 
libsystemd0 libterm-readkey-perl
  libtext-charwidth-perl libtext-iconv-perl libudev1 libxml2 libxtables12 
lighttpd lighttpd-modules-ldap lighttpd-modules-mysql locales login mawk 
openssh-client openssh-server openssh-sftp-server passwd perl perl-base 
php-common php-fpm python2
  python2-minimal python2.7 python2.7-minimal python3 python3-apt 
python3-minimal python3-pycurl rsyslog systemd udev util-linux 
util-linux-locales
69 upgraded, 53 newly installed, 20 to remove and 0 not upgraded.
Need to get 124 MB of archives.
After this operation, 29.3 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Here mariadb (10.3) is to be REMOVED, but 10.5 doesn't appear to get installed.

Before dist-upgrade:
# dpkg -l|grep mariadb
ii  libmariadb-dev  1:10.5.9-1 i386 
MariaDB database development files
ii  libmariadb-dev-compat:i386  1:10.5.9-1 i386 
MariaDB Connector/C, compatibility symlinks
ii  libmariadb3:i3861:10.5.9-1 i386 
MariaDB database client library
ii  mariadb-client-10.3 1:10.3.27-0+deb10u1i386 
MariaDB database client binaries
ii  mariadb-client-core-10.31:10.3.27-0+deb10u1i386 
MariaDB database core client binaries
ii  mariadb-common  1:10.5.9-1 all  
MariaDB common configuration files
ii  mariadb-server  1:10.3.27-0+deb10u1all  
MariaDB database server (metapackage depending on the latest version)
ii  mariadb-server-10.3 1:10.3.27-0+deb10u1i386 
MariaDB database server binaries
ii  mariadb-server-core-10.31:10.3.27-0+deb10u1i386 
MariaDB database core server files

After apt dist-upgrade:
# dpkg -l|grep mariadb
ii  libmariadb-dev  1:10.5.9-1 

Bug#984997: [debian-mysql] Bug#984997: Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment

[Olaf van der Spek]

On Mon, Mar 15, 2021 at 2:33 PM  wrote:
> Speaking of environment, AFAIK on modern systems it can be read only by
> sufficiently privileged user, so I don't see how it is less secure than
> a file (which will have to have the same permissions as
> /proc//environ). Could you elaborate how is it less secure than
> using --defaults-extra-file?

Environment data 'leaks' easier than file contents.
For example, when developing / debugging, one could easily copy/paste
all environment data, including the password (by accident), and post
it online when asking for help.

Bug#975911: [debian-mysql] Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Olaf van der Spek]

Hi,

>  There are no libedit related customizations in the Debian packaging, so I 
> suggest you report this
upstream at jira.mariadb.org, where upstream devs might have some input
into this.

Could this be related to:

> Installation of all MariaDB packages on Debian Sid is currently broken, as 
> libreadline5 was 2 days ago removed




-- 
Olaf

Bug#982797: apt: Advice requested for PHP deps

[Olaf van der Spek]

Package: apt
Version: 2.1.20
Severity: wishlist
X-Debbugs-Cc: olafvds...@gmail.com

Hi,

This is a request for advice for dependencies of PHP packages. See the related 
issue @ https://github.com/oerdnj/deb.sury.org/issues/1533

The goal is to avoid a situation where apt wants to install a second web server:
In this case lighttpd / php7.4-fpm was installed already.
# apt update
...
20 packages can be upgraded. Run 'apt list --upgradable' to see them.

# apt upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  apache2 apache2-bin apache2-data apache2-utils libapache2-mod-php8.0 
libaprutil1-dbd-sqlite3 libaprutil1-ldap libbrotli1 libjansson4 liblua5.2-0 
php8.0 php8.0-cli php8.0-common php8.0-curl php8.0-fpm php8.0-gd 
php8.0-mbstring php8.0-mysql
  php8.0-opcache php8.0-readline
The following packages will be upgraded:
  google-cloud-sdk libpcre2-8-0 php php-common php-curl php-fpm php-gd 
php-mbstring php-mysql php7.4 php7.4-cli php7.4-common php7.4-curl php7.4-fpm 
php7.4-gd php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache 
php7.4-readline
20 upgraded, 20 newly installed, 0 to remove and 0 not upgraded.
Need to get 105 MB of archives.
After this operation, 33.1 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
# 

What would you recommend here?
AFAIK php depends on php8.0, which depends on one of libapache2-mod-php8.0, 
php8.0-fpm or php8.0-cgi.
The desire is to have one properly configured web server, but maybe the PHP 
package shouldn't try to do this automatically.

Greetings,

Olaf


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::LastInstalledKernel "5.10.0-3-amd64";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Get "";
APT::Get::HideAutoRemove "true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";

Bug#979331: php-fpm: PHP 8.0

[Olaf van der Spek]

Package: php-fpm
Version: 2:7.4+76
Severity: wishlist
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Thanks a lot for packaging 8.0!
Is the plan to ship it in Bullseye?

Greetings,

Olaf

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

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

Versions of packages php-fpm depends on:
ii  php7.4-fpm  7.4.11-1

php-fpm recommends no packages.

php-fpm suggests no packages.

-- no debconf information

Bug#978748: libboost-dev: Boost 1.75

[Olaf van der Spek]

Package: libboost-dev
Version: 1.74.0.3
Severity: wishlist
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Could Boost 1.75 be packaged?

Greetings,

Olaf

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libboost-dev depends on:
ii  libboost1.74-dev  1.74.0-6

libboost-dev recommends no packages.

Versions of packages libboost-dev suggests:
pn  libboost-doc  

-- no debconf information

Bug#977137: [debian-mysql] Bug#977137: mariadb-server: Mariadb-server kept back on apt upgrade

[Olaf van der Spek]

Op vr 11 dec. 2020 om 17:31 schreef Otto Kekäläinen :
>
> We test the Debian 10 -> Debian 11 upgrade in
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1222976
>
> Source: 
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/salsa-ci.yml#L201-226
>
> Would you like to contribute by extending the salsa-ci.yml to test for
> the upgrade scenario you have which is not yet covered by the existing
> tests?

I would, but I don't have the time currently.

-- 
Olaf

Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)

[Olaf van der Spek]

Hi,

10.5 and the upstream versions seem affected too.

# grep mariadb syslog
Dec 13 10:10:28 debian mariadbd[535]: 2020-12-13 10:10:28 0 [Note]
/usr/sbin/mariadbd (mysqld 10.5.8-MariaDB-1:10.5.8+maria~sid) starting
as process 535 ...
Dec 13 10:10:28 debian mariadbd[535]: 2020-12-13 10:10:28 0 [Warning]
Could not increase number of max_open_files to more than 16384
(request: 32184)

# dpkg -l|grep mariadb
...
ii  mariadb-server-10.51:10.5.8+maria~sid
   amd64MariaDB database server binaries
ii  mariadb-server-core-10.5   1:10.5.8+maria~sid
   amd64MariaDB database core server files

Bug#977137: [debian-mysql] Bug#977137: mariadb-server: Mariadb-server kept back on apt upgrade

[Olaf van der Spek]

Hi Otto,

Note this is on apt upgrade. On apt dist-upgrade it works fine. But
most others packages are fine with just upgrade.

I installed Debian 10, changed buster to testing in sources.list and
ran apt upgrade.

Grtz,

Olaf

Op vr 11 dec. 2020 om 16:28 schreef Otto Kekäläinen :
>
> Hello!
>
> What are the exact steps to reproduce this scenario?
>
> We have simple upgrade tests on every commit, so this must be due to
> some special situation.



-- 
Olaf

Bug#977137: [debian-mysql] Bug#977137: mariadb-server: Mariadb-server kept back on apt upgrade

[Olaf van der Spek]

Op vr 11 dec. 2020 om 16:26 schreef Faustin Lammler :
>
> Hi Olaf!
>
> Yes I can confirm this behavior on sid.
>
> My understanding from
> https://lists.debian.org/debian-release/2020/11/msg00305.html is that
> 10.3 will be fully removed from sid and replaced by 10.5.
>

Hi Faustin,

I understand, but it does occur when you upgrade from Debian 10 to 11..



-- 
Olaf

Bug#977137: mariadb-server: Mariadb-server kept back on apt upgrade

[Olaf van der Spek]

Package: mariadb-server
Version: 1:10.3.27-0+deb10u1
Severity: wishlist
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

I thought / hoped with the correct dependencies (replaces?) apt upgrade could 
do this upgrade without holding back. Is some dep missing or can't apt upgrade 
do this yet?

Greetings,

Olaf

# apt upgrade
The following packages have been kept back:
  galera-3 gcc-8-base libpython2-stdlib mariadb-server python2 python2-minimal
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.

# apt install mariadb-server
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  geoip-database libbind9-161 libdns1104 libdns1110 libgeoip1 libicu63 
libisc1100 libisc1105 libisccc161 libisccfg163 liblwres161 libmpdec2 
libperl5.28 libpython3.7-minimal libpython3.7-stdlib libreadline5 libreadline7 
python3.7 python3.7-minimal
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  galera-4 mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server-10.5 
mariadb-server-core-10.5
Suggested packages:
  mailx mariadb-test netcat-openbsd
The following packages will be REMOVED:
  galera-3 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server-10.3 
mariadb-server-core-10.3
The following NEW packages will be installed:
  galera-4 mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server-10.5 
mariadb-server-core-10.5
The following packages will be upgraded:
  mariadb-server
1 upgraded, 5 newly installed, 5 to remove and 4 not upgraded.
Need to get 14.0 MB of archives.
After this operation, 12.4 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 mariadb-server depends on:
ii  mariadb-server-10.3  1:10.3.27-0+deb10u1

mariadb-server recommends no packages.

mariadb-server suggests no packages.

-- no debconf information

Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)

[Olaf van der Spek]

Hi,

https://mariadb.com/kb/en/server-system-variables/#open_files_limit

> If set to 0, then MariaDB will calculate a limit based on the following:

> MAX(max_connections*5, max_connections +table_open_cache*2)

max_connections: 151
table_open_cache: 2000

This doesn't add up to 32186.

https://mariadb.com/docs/reference/mdb/system-variables/open_files_limit/

> SkySQL Analytical 10.5; Default: 32186

This however, is about the value we're seeing. Could the docs be out-of-date?

Grtz,

Olaf

Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.27-0+deb10u1
Followup-For: Bug #976652

Dear Maintainer,

Fresh Debian 10 install, fresh mariadb-server install:

# zgrep max_open_files syslog*

Dec 11 13:08:46 xyz mysqld[1695]: 2020-12-11 13:08:46 0 [Warning] Could not 
increase number of max_open_files to more than 16384 (request: 32184)

Greetings,

Olaf

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libdbi-perl   1.642-1+deb10u1
ii  libgnutls30   3.6.7-4+deb10u5
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.27-0+deb10u1
ii  mariadb-common1:10.3.27-0+deb10u1
ii  mariadb-server-core-10.3  1:10.3.27-0+deb10u1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6+deb10u1
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
pn  mailx   
pn  mariadb-test
pn  netcat-openbsd  
pn  tinyca  

-- debconf information:
  mariadb-server-10.3/nis_warning:
  mariadb-server-10.3/postrm_remove_databases: false
  mariadb-server-10.3/old_data_directory_saved:

Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.27-0+deb10u1
Followup-For: Bug #976652

Dear Maintainer,

Debian 10 server @ Linode:

$ zgrep max_open_files syslog*
syslog:Dec 11 12:36:58 ln0 mysqld[699]: 2020-12-11 12:36:58 0 [Warning] Could 
not increase number of max_open_files to more than 16384 (request: 32186)
syslog.4.gz:Dec  7 06:27:47 ln0 mysqld[31471]: 2020-12-07  6:27:47 0 [Warning] 
Could not increase number of max_open_files to more than 16384 (request: 32186)

Same warning but slightly different value (32186)

Olaf










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

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libdbi-perl   1.642-1+deb10u1
ii  libgnutls30   3.6.7-4+deb10u5
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.27-0+deb10u1
ii  mariadb-common1:10.3.27-0+deb10u1
ii  mariadb-server-core-10.3  1:10.3.27-0+deb10u1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6+deb10u1
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  mailutils [mailx]  1:3.5-4
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- debconf information:
  mariadb-server-10.3/postrm_remove_databases: false
  mariadb-server-10.3/old_data_directory_saved:
  mariadb-server-10.3/nis_warning:

Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.27-0+deb10u1
Followup-For: Bug #976652

Hi Faustin,

Debian 10 server @ Linode:

$ zgrep max_open_files syslog*
syslog:Dec 11 12:36:58 ln0 mysqld[699]: 2020-12-11 12:36:58 0
[Warning] Could not increase number of max_open_files to more than
16384 (request: 32186)
syslog.4.gz:Dec  7 06:27:47 ln0 mysqld[31471]: 2020-12-07  6:27:47 0
[Warning] Could not increase number of max_open_files to more than
16384 (request: 32186)

Same warning but slightly different value (32186)

Olaf










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

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libdbi-perl   1.642-1+deb10u1
ii  libgnutls30   3.6.7-4+deb10u5
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.27-0+deb10u1
ii  mariadb-common1:10.3.27-0+deb10u1
ii  mariadb-server-core-10.3  1:10.3.27-0+deb10u1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6+deb10u1
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  mailutils [mailx]  1:3.5-4
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- debconf information:
  mariadb-server-10.3/postrm_remove_databases: false
  mariadb-server-10.3/old_data_directory_saved:
  mariadb-server-10.3/nis_warning:

Bug#976652: [debian-mysql] Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)

[Olaf van der Spek]

Op vr 11 dec. 2020 om 12:22 schreef Faustin Lammler :
>
> > > syslog.6.gz:Dec  5 18:56:49 dev mysqld[694]: 2020-12-05 18:56:49 0 
> > > [Warning] Could not increase number of max_open_files to more than 16384 
> > > (request: 32183)
> Are you having this message too?

Yes, aren't you? ;)

> > Where does the 32183 come from? I don't see it in any conf file and it's 
> > not a value I'd set myself..
> So you grep /etc for this value? I have no idea where it could come
> from.

$ sudo grep -r 32183 /etc
$

Nothing

I think it's just the MariaDB default. I don't remember seeing the
warning before though, was it introduced in a security update?

> Can you maybe describe your setup so we can maybe find correlations with
> Richard's setup?
>
> Would that maybe come from a particular DB installation where this value
> is setup directly in the DB by the installer?

It's a Digital Ocean VM, initially installed as Debian 9 (or 8?), now 10.

I'll do a fresh Debian 10 install in a new VM to see if the warning
occurs there too.


-- 
Olaf

Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.27-0+deb10u1
Followup-For: Bug #976652

Dear Maintainer,

> syslog.6.gz:Dec  5 18:56:49 dev mysqld[694]: 2020-12-05 18:56:49 0 [Warning] 
> Could not increase number of max_open_files to more than 16384 (request: 
> 32183)

Where does the 32183 come from? I don't see it in any conf file and it's not a 
value I'd set myself..

I'm not sure this isn't a 'bug'.

Greetings,

Olaf

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

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libdbi-perl   1.642-1+deb10u1
ii  libgnutls30   3.6.7-4+deb10u5
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.27-0+deb10u1
ii  mariadb-common1:10.3.27-0+deb10u1
ii  mariadb-server-core-10.3  1:10.3.27-0+deb10u1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6+deb10u1
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- Configuration Files:
/etc/mysql/mariadb.conf.d/50-server.cnf changed:
[mysqld]
user  = mysql
pid-file= /var/run/mysqld/mysqld.pid
socket  = /var/run/mysqld/mysqld.sock
port  = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir  = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
query_cache_size = 0
key_buffer_size = 16M
max_allowed_packet  = 16M
thread_cache_size   = 8
myisam_recover_options  = BACKUP
log_error = /var/log/mysql/error.log
expire_logs_days= 10
max_binlog_size   = 100M
character-set-server  = utf8mb4
collation-server  = utf8mb4_general_ci


-- debconf information:
  mariadb-server-10.3/old_data_directory_saved:
  mariadb-server-10.3/nis_warning:
  mariadb-server-10.3/postrm_remove_databases: false

Bug#969385: Bullseye

[Olaf van der Spek]

Op zo 11 okt. 2020 om 16:30 schreef Giovanni Mascellani :
>
> Hi,
>
> Il 10/10/20 07:28, Olaf van der Spek ha scritto:
> > Hi,
> >
> > What's the plan for Bullseye?
> > It'd be nice if Boost 1.75, expected December 9, could be included.
>
> I agree. On the other hand, transition freeze will be mid January or so,
> so the available time is not a lot.
>
> The two things requiring a lot of time when packaging a new Boost
> release are writing the debian/copyright file (for which I have some
> automated scripts, but that require some manual work anyway) and filing
> patches for the reverse dependencies that break. Fortunately I can start
> working on both things before Boost is actually released. I will try.

Thanks Giovanni!

Would it make sense to package 1.74 first to minimize the differences
when 1.75 becomes available?



-- 
Olaf

Bug#969385: Bullseye

[Olaf van der Spek]

Hi,

What's the plan for Bullseye?
It'd be nice if Boost 1.75, expected December 9, could be included.

Greetings,

-- 
Olaf

Bug#933063: [debian-mysql] Bug#933063: Bug#933063: character_set_client: latin1?

[Olaf van der Spek]

Op vr 2 okt. 2020 om 08:28 schreef Otto Kekäläinen :
>
> Did you notice my question?
>
> > Olaf: what commands did you run to compile your example program? Any
> > pkg-config or mariadb_config involved?

No, I used: g++ b933063.cpp -l mysqlclient

join@dev:~$ cat /etc/debian_version
10.6

join@dev:~$ ./a.out
character_set_client: latin1
character_set_connection: latin1
character_set_database: utf8mb4
character_set_filesystem: binary
character_set_results: latin1
character_set_server: utf8mb4
character_set_system: utf8
character_sets_dir: /usr/share/mysql/charsets/

dpkg -l|grep mariadb
ii  libmariadb-dev 1:10.3.23-0+deb10u1
  amd64MariaDB database development files
ii  libmariadb-dev-compat:amd641:10.3.23-0+deb10u1
  amd64MariaDB Connector/C, compatibility symlinks
ii  libmariadb3:amd64  1:10.3.23-0+deb10u1
  amd64MariaDB database client library
ii  libmariadbclient-dev:amd64 1:10.3.23-0+deb10u1
  amd64MariaDB database development files (transitional
package)
rc  mariadb-client-10.11:10.1.37-3
  amd64MariaDB database client binaries
ii  mariadb-client-10.31:10.3.23-0+deb10u1
  amd64MariaDB database client binaries
ii  mariadb-client-core-10.3   1:10.3.23-0+deb10u1
  amd64MariaDB database core client binaries
ii  mariadb-common 1:10.3.23-0+deb10u1
  all  MariaDB common metapackage
ii  mariadb-server 1:10.3.23-0+deb10u1
  all  MariaDB database server (metapackage depending on the
latest version)
rc  mariadb-server-10.11:10.1.37-3
  amd64MariaDB database server binaries
ii  mariadb-server-10.31:10.3.23-0+deb10u1
  amd64MariaDB database server binaries
ii  mariadb-server-core-10.3   1:10.3.23-0+deb10u1
  amd64MariaDB database core server files


olaf@debian:~$ cat /etc/debian_version
bullseye/sid

olaf@debian:~$ ./a.out
character_set_client: latin1
character_set_connection: latin1
character_set_database: utf8mb4
character_set_filesystem: binary
character_set_results: latin1
character_set_server: utf8mb4
character_set_system: utf8
character_sets_dir: /usr/share/mysql/charsets/

olaf@debian:~$ dpkg -l|grep mariadb
ii  libmariadb-dev   1:10.5.5-1
amd64MariaDB database development files
ii  libmariadb-dev-compat:amd64  1:10.5.5-1
amd64MariaDB Connector/C, compatibility symlinks
ii  libmariadb3:amd641:10.5.5-1
amd64MariaDB database client library
rc  mariadb-client-10.3  1:10.3.24-2
amd64MariaDB database client binaries
ii  mariadb-client-10.5  1:10.5.5-1
amd64MariaDB database client binaries
ii  mariadb-client-core-10.5 1:10.5.5-1
amd64MariaDB database core client binaries
ii  mariadb-common   1:10.5.5-1
all  MariaDB common configuration files
ii  mariadb-server   1:10.5.5-1
all  MariaDB database server (metapackage depending on the
latest version)
rc  mariadb-server-10.3  1:10.3.24-2
amd64MariaDB database server binaries
ii  mariadb-server-10.5  1:10.5.5-1
amd64MariaDB database server binaries
ii  mariadb-server-core-10.5 1:10.5.5-1
amd64MariaDB database core server files

-- 
Olaf

Bug#917088: [debian-mysql] Bug#917088: Bug#917088: Bug#917088: mariadb-server-10.3: #1071 - Specified key was too long; max key length is 1000 bytes

[Olaf van der Spek]

Op wo 30 sep. 2020 om 17:05 schreef Faustin Lammler :
> I see that you opened a jira issue about this, remember to forward bug
> reports to upstream issue so we can track them better.
>
> What about Sergei last message, do you have any further comments?

Hi Faustin,

I think this issue can be closed, I'm not sure what could be done
about it downstream.

-- 
Olaf

Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?

[Olaf van der Spek]

Op ma 28 sep. 2020 om 19:27 schreef Otto Kekäläinen :
> If you Olaf want to contribute by improving this, I suggest you
> research upstream docs and configs and try to figure out if we
> actually need a full charset row of only utf8mb4 or if current
> situation is sufficient and the 'client' and 'conn' charset 'latin1'
> can be ignored.

I'm pretty sure the current situation is bad..

> You Olaf could for example write an extension to our autopkgtest tests
> in Debian or the salsa-ci.yml to automatically test if some utf8mb4
> thing works or now on each build/upload automatically.

I'll see what I can do.

-- 
Olaf

Bug#962902: [debian-mysql] Bug#962902: Bug#962902: server does not start

[Olaf van der Spek]

On Tue, Jun 16, 2020 at 1:33 PM Toni Mueller  wrote:
>
>
> Hi Otto,
>
> On Tue, Jun 16, 2020 at 12:27:53PM +0300, Otto Kekäläinen wrote:
> > Can you provide us enough information about your environment so we
> > could try to reproduce this error?
>
> I'm not sure what you are after. The machine in question is a laptop
> with Buster (latest), and all sorts of stiff.

http://thedjbway.b0llix.net/djbdns/dnsroots.html :

> The file /etc/dnsroots.global is created when you install the djbdns package 
> itself.

Is djbdns installed? Was it installed previously?

Greetings,

Olaf

Bug#920727: Status?

[Olaf van der Spek]

Op wo 13 mei 2020 om 11:09 schreef Olaf van der Spek :
>
> Dear maintainers,
>
> How's progress on Boost packaging?

Thanks for the update!


-- 
Olaf

Bug#920727: Status?

[Olaf van der Spek]

Op wo 13 mei 2020 om 11:28 schreef Giovanni Mascellani :
> Il 13/05/20 11:09, Olaf van der Spek ha scritto:
> > How's progress on Boost packaging?
>
> Version 1.71 has been in unstable for quite some time now. It is not the
> default yet, but bugs are filed against packages that fail to build with
> it[1], so it could be possible to start a transition at some point.
>
>  [1]
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=team%2Bboost%40tracker.debian.org=boost1.71

Nice!
Note Boost 1.71 has issues with GCC 10 so perhaps 1.73 could be packaged too.

Greetings,

-- 
Olaf

Bug#920727: Status?

[Olaf van der Spek]

Dear maintainers,

How's progress on Boost packaging?

Greetings,
-- 
Olaf

Bug#888705: abseil-cpp packaging

[Olaf van der Spek]

Op do 27 feb. 2020 om 06:54 schreef László Böszörményi :
>  Are you going to rename it to abseil-cpp (as Google has abseil-python
> as well, make a disparity between the two)?

Python libraries use a "python3-" prefix while C/C++ libraries use a
"lib" prefix, so I don't think it makes sense to change the name.

Bug#888705: abseil-cpp packaging

[Olaf van der Spek]

What about the C++ std version? Abseil / C++14 isn't the same as Abseil / C++17.
This applies to other C++ libraries as well.

Bug#946388: mariadb-10.3: 10.4?

[Olaf van der Spek]

Package: mariadb-10.3
Severity: wishlist

Dear Maintainer,

10.4 was released some time ago, what's the plan for 10.4?

Greetings,

Olaf

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

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

Bug#927289: [debian-mysql] Bug#927289: Bug#927289: mariadb-server-10.3: SSL error: Unable to get private key

[Olaf van der Spek]

Op wo 11 sep. 2019 om 15:27 schreef Faustin Lammler :
>
> Hi Olaf,
> did you finally managed to setup the TLS between client and server?
>
> Let me know if you want me to test something based on
> https://mariadb.com/kb/en/library/securing-connections-for-client-and-server/
> and
> https://mariadb.com/kb/en/library/certificate-creation-with-openssl/.

No, I gave up.
I'll give it another try and let you know.


-- 
Olaf

Bug#933063: character_set_client: latin1?

[Olaf van der Spek]

Package: libmariadb-dev-compat
Version: 1:10.3.15-1
Severity: normal

Dear Maintainer,

I expected character_set_client to be utf8mb4, but it's latin1. Isn't it 
supposed to be utf8mb4?

Greetings,

Olaf

/etc/mysql/mariadb.conf.d/50-client.cnf :
[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4

Output:
character_set_client: latin1
character_set_connection: latin1
character_set_database: utf8mb4
character_set_filesystem: binary
character_set_results: latin1
character_set_server: utf8mb4
character_set_system: utf8
character_sets_dir: /usr/share/mysql/charsets/

#include 
#include 
#include 

int main()
{
  MYSQL h;

  if (!mysql_init()
|| mysql_options(, MYSQL_READ_DEFAULT_GROUP, "")
// || mysql_options(, MYSQL_SET_CHARSET_NAME, "utf8mb4")
|| !mysql_real_connect(, "", "", NULL, "", 0, NULL, 0))
throw std::runtime_error(mysql_error());
  std::string q = "show variables like '%char%'";
  if (mysql_real_query(, q.data(), q.size()))
throw std::runtime_error(mysql_error());
  MYSQL_RES* result = mysql_store_result();
  if (!result && mysql_errno())
throw std::runtime_error(mysql_error());
  while (MYSQL_ROW row = mysql_fetch_row(result))
  {
std::cout << row[0] << ": " << row[1] << "\n";
  }
  return 0;
}

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmariadb-dev-compat depends on:
ii  libmariadb-dev  1:10.3.15-1

libmariadb-dev-compat recommends no packages.

libmariadb-dev-compat suggests no packages.

-- no debconf information

Bug#930643: npm ERR! cb() never called!

[Olaf van der Spek]

Package: npm
Version: 5.8.0+ds6-4
Severity: normal

Hi,

Doesn't happen all the time.. the log is 5000+ lines, would you like me to 
include the full log?

> npm install --ignore-scripts --no-package-lock

5412 silly extract stylelint@^10.0.1 extracted to 
/srv/pma/node_modules/.staging/stylelint-c019eb3c (3171ms)
5413 silly extract codemirror@5.47.0 extracted to 
/srv/pma/node_modules/.staging/codemirror-ab4b1083 (2670ms)
5414 silly extract caniuse-lite@^1.0.3971 extracted to 
/srv/pma/node_modules/.staging/caniuse-lite-ad742eae (3419ms)
5415 silly extract fsevents@^1.2.7 extracted to 
/srv/pma/node_modules/.staging/fsevents-34b613df (1634ms)
5416 http fetch GET 200 https://registry.npmjs.org/rxjs/-/rxjs-6.5.2.tgz 2786ms
5417 silly extract rxjs@^6.4.0 extracted to 
/srv/pma/node_modules/.staging/rxjs-16cb677d (2988ms)
5418 error cb() never called!
5419 error This is an error with npm itself. Please report this error at:
5420 error 

Greetings,

Olaf


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages npm depends on:
ii  ca-certificates 20190110
ii  node-abbrev 1.1.1-1
ii  node-ansi   0.3.0-3
ii  node-ansi-regex 3.0.0-1
ii  node-ansistyles 0.1.3-1
ii  node-aproba 1.2.0-1
ii  node-archy  1.0.0-2
ii  node-bluebird   3.5.1+dfsg2-2
ii  node-boxen  1.2.2-1
ii  node-cacache11.3.2-2
ii  node-call-limit 1.1.0-1
ii  node-chownr 1.1.1-1
ii  node-config-chain   1.1.11-1
ii  node-detect-indent  5.0.0-1
ii  node-detect-newline 2.1.0-1
ii  node-editor 1.0.0-1
ii  node-encoding   0.1.12-2
ii  node-errno  0.1.4-1
ii  node-from2  2.3.0-1
ii  node-fs-vacuum  1.2.10-2
ii  node-fs-write-stream-atomic 1.0.10-4
ii  node-glob   7.1.3-2
ii  node-graceful-fs4.1.11-1
ii  node-gyp3.8.0-6
ii  node-has-unicode2.0.1-2
ii  node-hosted-git-info2.7.1-1
ii  node-iferr  1.0.2-1
ii  node-import-lazy3.0.0.REALLY.2.1.0-1
ii  node-inflight   1.0.6-1
ii  node-inherits   2.0.3-1
ii  node-ini1.3.5-1
ii  node-is-npm 1.0.0-1
ii  node-json-parse-better-errors   1.0.2-2
ii  node-jsonstream 1.3.2-1
ii  node-latest-version 3.1.0-1
ii  node-lazy-property  1.0.0-3
ii  node-libnpx 10.2.0+repack-1
ii  node-lockfile   1.0.4-1
ii  node-lru-cache  5.1.1-4
ii  node-mississippi3.0.0-1
ii  node-mkdirp 0.5.1-1
ii  node-move-concurrently  1.0.1-2
ii  node-nopt   3.0.6-3
ii  node-normalize-package-data 2.4.0-1
ii  node-npm-package-arg6.0.0-2
ii  node-npmlog 4.1.2-1
ii  node-once   1.4.0-3
ii  node-opener 1.4.3-1
ii  node-osenv  0.1.5-1
ii  node-path-is-inside 1.0.2-1
ii  node-promise-inflight   1.0.1-1
ii  node-promzard   0.3.0-1
ii  node-qw 1.0.1-1
ii  node-read   1.0.7-1
ii  node-read-package-json  2.0.13-1
ii  node-request2.88.1-2
ii  node-resolve-from   4.0.0-1
ii  node-retry  0.10.1-1
ii  node-rimraf 2.6.2-1
ii  node-safe-buffer5.1.2-1
ii  node-semver 5.5.1-1
ii  node-semver-diff2.1.0-2
ii  node-sha2.0.1-1
ii  node-slide  1.1.6-2
ii  node-sorted-object  2.0.1-1
ii  node-ssri   5.2.4-2
ii  node-stream-iterate 1.2.0-4
ii  node-strip-ansi 4.0.0-1
ii  node-tar4.4.6+ds1-3
ii  node-text-table 0.2.0-2
ii  node-uid-number 0.0.6-1
ii  node-unique-filename1.1.0+ds-2
ii  node-unpipe 1.0.0-1
ii  node-validate-npm-package-name  3.0.0-1
ii  node-which  1.3.0-2
ii  node-wrappy 1.0.2-1
ii  node-write-file-atomic  2.3.0-1
ii  node-xdg-basedir3.0.0-1
ii  nodejs  10.15.2~dfsg-2

npm recommends no packages.

npm suggests no 

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Olaf van der Spek]

On Wed, Jun 12, 2019 at 10:44 PM Faustin Lammler  wrote:
> do you still have the build log, if not, can you give me your build
> steps and environment so I can try to reproduce the error?

No, however I think it should be reproducible in all environments.

It's too late for Buster isn't it?

It might make more sense to do this split in 10.4.

-- 
Olaf

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Olaf van der Spek]

On Wed, Jun 12, 2019 at 1:12 PM Faustin Lammler  wrote:
>
> Hi Olaf,
> do you think that
> https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests/12
> resolves the bug or is there anything more you want me to test in order
> to double check?
>
> Thanks!
> Faustin

MR 12 is (kinda) unrelated to #917086.

-- 
Olaf

Bug#929207: lighttpd: -tt not documented in man page

[Olaf van der Spek]

Op di 21 mei 2019 om 09:03 schreef Helmut Grohne :
> I cannot reproduce the issue with version 1.4.53-4. The manual page
> clearly documents the -tt option. This was fixed upstream in commit
> c4edd356.

You're right, I'm sorry, I looked at an out-of-date version of the man page.



-- 
Olaf

Bug#929207: lighttpd: -tt not documented in man page

[Olaf van der Spek]

Package: lighttpd
Version: 1.4.53-4
Severity: wishlist

Dear Maintainer,

-h includes the option but the man page doesn't.

Greetings,

Olaf

# lighttpd -help 
lighttpd/1.4.53 (ssl) - a light and fast webserver
usage:
 -f   filename of the config-file
 -m   module directory (default: /usr/lib/lighttpd)
 -i   graceful shutdown after  of inactivity
 -1 process single (one) request on stdin socket, then exit
 -p print the parsed config-file in internal form, and exit
 -t test config-file syntax, then exit
 -tttest config-file syntax, load and init modules, then exit

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.48-4
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-10
ii  libfam0   2.7.0-17.3
ii  libpcre3  2:8.39-12
ii  libssl1.1 1.1.1b-2
ii  lsb-base  10.2019031300
ii  mime-support  3.62
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
ii  lighttpd-modules-ldap   1.4.53-4
ii  lighttpd-modules-mysql  1.4.53-4
ii  perl5.28.1-6
ii  spawn-fcgi  1.6.4-2

Versions of packages lighttpd suggests:
pn  apache2-utils  
pn  lighttpd-doc   
ii  openssl1.1.1b-2
pn  php-cgi
pn  rrdtool

-- no debconf information

Bug#929203: lighttpd: PIDFile= references path below legacy directory /var/run

[Olaf van der Spek]

Package: lighttpd
Version: 1.4.53-4
Severity: normal

Dear Maintainer,

May 19 10:56:32 buster systemd[1]: /lib/systemd/system/lighttpd.service:6: 
PIDFile= references path below legacy directory /var/run/, updating 
/var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file 
accordingly.

Greetings,

Olaf

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.48-4
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-10
ii  libfam0   2.7.0-17.3
ii  libpcre3  2:8.39-12
ii  libssl1.1 1.1.1b-2
ii  lsb-base  10.2019031300
ii  mime-support  3.62
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
ii  lighttpd-modules-ldap   1.4.53-4
ii  lighttpd-modules-mysql  1.4.53-4
ii  perl5.28.1-6
ii  spawn-fcgi  1.6.4-2

Versions of packages lighttpd suggests:
pn  apache2-utils  
pn  lighttpd-doc   
ii  openssl1.1.1b-2
pn  php-cgi
pn  rrdtool

-- no debconf information

Bug#929028: lighttpd: Invalid character in URI -> 400 /?a=%7F

[Olaf van der Spek]

Source: lighttpd
Version: 1.4.53-4
Severity: normal

Dear Maintainer,

> (response.c.344) invalid character in URI -> 400 /?a=%7F 

%7F looks fine to me..

Greetings,

Olaf

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/3 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#928077: [debian-mysql] Bug#928077: mariadb-server-10.3: fails to start. init files don't create directory /run/mysqld

[Olaf van der Spek]

On Sat, Apr 27, 2019 at 5:27 PM Michael Farmbauer
 wrote:
> in the latest update the pid and socket files have been moved from
> /var/run/mysqld to /run/mysqld.
>
> The directory /run/mysqld must be created in the init files:
>
> /etc/init.d/mysql
> /var/lib/systemd/system/mariadb*
>
> Those file still create the directory /var/run/mysqld

On my systems /var/run is a symlink to /run, is this not the case on
your systems?

# ls -l /var/run
lrwxrwxrwx 1 root root 4 Jun 19  2017 /var/run -> /run

Bug#928060: lighttpd: Tabs and Spaces

[Olaf van der Spek]

Package: lighttpd
Version: 1.4.53-4
Severity: wishlist

Hi,

Lighttpd.conf appears to use a mix of tabs and spaces for indentation. Could 
spaces (2 ;)) be used consistently? 

Greetings,

Olaf

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.48-4
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-9
ii  libfam0   2.7.0-17.3
ii  libpcre3  2:8.39-12
ii  libssl1.1 1.1.1b-2
ii  lsb-base  10.2019031300
ii  mime-support  3.62
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
pn  lighttpd-modules-ldap   
pn  lighttpd-modules-mysql  
ii  perl5.28.1-6
pn  spawn-fcgi  

Versions of packages lighttpd suggests:
pn  apache2-utils  
pn  lighttpd-doc   
ii  openssl1.1.1b-2
pn  php-cgi
pn  rrdtool

-- no debconf information

Bug#928059: lighttpd: setenv missing from conf-available

[Olaf van der Spek]

Package: lighttpd
Version: 1.4.53-4
Severity: normal

Hi,

server.modules = ( "mod_setenv" ) was removed from lighttpd.conf but no setenv 
conf file appears to be available in the conf-available dir.

Greetings,

Olaf

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.48-4
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-9
ii  libfam0   2.7.0-17.3
ii  libpcre3  2:8.39-12
ii  libssl1.1 1.1.1b-2
ii  lsb-base  10.2019031300
ii  mime-support  3.62
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
pn  lighttpd-modules-ldap   
pn  lighttpd-modules-mysql  
ii  perl5.28.1-6
pn  spawn-fcgi  

Versions of packages lighttpd suggests:
pn  apache2-utils  
pn  lighttpd-doc   
ii  openssl1.1.1b-2
pn  php-cgi
pn  rrdtool

-- no debconf information

Bug#927289: [debian-mysql] Bug#927289: mariadb-server-10.3: SSL error: Unable to get private key

[Olaf van der Spek]

Op wo 17 apr. 2019 om 19:45 schreef Otto Kekäläinen :
>
> > > Try making the overly broad permissions of
> > > /etc/mysql/ssl/server-key.pem -rwxr-xr-x
> > > to something less world-readable.
> >
> > # chmod 700 server-cert.pem
> > # service mysql restart
> >
> > error.log:
> > SSL error: Unable to get certificate from '/etc/mysql/ssl/server-cert.pem'
> > 2019-04-17 14:41:29 0 [Warning] Failed to setup SSL
> > 2019-04-17 14:41:29 0 [Warning] SSL error: Unable to get certificate
>
> Maybe you need to seek out for SSL experts on what the correct file
> permissions or other settings are supposed to be. Based on the info
> provided there is nothing I can debug or fix, sorry.

The documentation could be improved. I've created a ticket upstream @
https://jira.mariadb.org/browse/MDEV-19268


-- 
Olaf

Bug#927289: [debian-mysql] Bug#927289: mariadb-server-10.3: SSL error: Unable to get private key

[Olaf van der Spek]

Op wo 17 apr. 2019 om 16:40 schreef Otto Kekäläinen :
>
> Try making the overly broad permissions of
> /etc/mysql/ssl/server-key.pem -rwxr-xr-x
> to something less world-readable.

# chmod 700 server-cert.pem
# service mysql restart

error.log:
SSL error: Unable to get certificate from '/etc/mysql/ssl/server-cert.pem'
2019-04-17 14:41:29 0 [Warning] Failed to setup SSL
2019-04-17 14:41:29 0 [Warning] SSL error: Unable to get certificate


-- 
Olaf

Bug#927289: [debian-mysql] Bug#927289: mariadb-server-10.3: SSL error: Unable to get private key

[Olaf van der Spek]

Op wo 17 apr. 2019 om 15:09 schreef Otto Kekäläinen :
>
> What does this print?
>
> find /etc/mysql/ -ls

# find /etc/mysql/ -ls
   137133  4 drwxr-xr-x   5 root root 4096 Apr 17
12:14 /etc/mysql/
   132729  0 lrwxrwxrwx   1 root root   24 Apr 17
06:56 /etc/mysql/my.cnf -> /etc/alternatives/my.cnf
   399024  4 drwxr-xr-x   2 root root 4096 Apr 17
12:17 /etc/mysql/ssl
   399278  4 -rw-r--r--   1 root root  981 Apr 17
12:17 /etc/mysql/ssl/client-cert.pem
   399274  4 -rw-r--r--   1 root root  899 Apr 17
12:16 /etc/mysql/ssl/server-req.pem
   399276  4 -rw---   1 root root 1679 Apr 17
12:17 /etc/mysql/ssl/client-key.pem
   399277  4 -rw-r--r--   1 root root  899 Apr 17
12:17 /etc/mysql/ssl/client-req.pem
   399053  4 -rw-r--r--   1 root root 1679 Apr 17
12:14 /etc/mysql/ssl/ca-key.pem
   399273  4 -rw---   1 root root 1679 Apr 17
12:16 /etc/mysql/ssl/server-key.pem
   399275  4 -rwxr-xr-x   1 root root  981 Apr 17
12:16 /etc/mysql/ssl/server-cert.pem
   399272  4 -rw-r--r--   1 root root 1127 Apr 17
12:15 /etc/mysql/ssl/ca-cert.pem
   139576  4 -rwxr-xr-x   1 root root 1620 Jan 18
20:04 /etc/mysql/debian-start
   137152  4 drwxr-xr-x   2 root root 4096 Apr 17
12:24 /etc/mysql/mariadb.conf.d
   139714  4 -rw-r--r--   1 root root 2934 Apr 17
12:24 /etc/mysql/mariadb.conf.d/50-server.cnf
   139568  4 -rw-r--r--   1 root root  336 Jan  8
22:10 /etc/mysql/mariadb.conf.d/50-mysql-clients.cnf
   139567  4 -rw-r--r--   1 root root  733 Jan  8
22:10 /etc/mysql/mariadb.conf.d/50-client.cnf
   139577  4 -rw-r--r--   1 root root 1032 Jan  8
22:10 /etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf
   137151  4 -rw-r--r--   1 root root  869 Jan  8
22:10 /etc/mysql/mariadb.cnf
   139615  4 -rw---   1 root root  277 Apr 17
07:02 /etc/mysql/debian.cnf
   137134  4 drwxr-xr-x   2 root root 4096 Apr 17
06:56 /etc/mysql/conf.d
   137136  4 -rw-r--r--   1 root root   55 Aug  3
2016 /etc/mysql/conf.d/mysqldump.cnf
   137135  4 -rw-r--r--   1 root root8 Aug  3
2016 /etc/mysql/conf.d/mysql.cnf
   137137  4 -rw-r--r--   1 root root  839 Aug  3
2016 /etc/mysql/my.cnf.fallback

> Are your file permissions correct?

Don't know ;)

> Does TLS work on any previous version of MariaDB in Debian, a MariaDB
> version from MariaDB.org repos or using some MySQL version?

It's the first time I try to setup TLS. Maybe it's related to openssl
vs non-openssl?

> In Debian packaging we can only fix things that "normally" work. If it
> is an upstream issue it is out of scope of Debian packaging work.
>
> Also see related https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921151



-- 
Olaf

Bug#927289: mariadb-server-10.3: SSL error: Unable to get private key

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.13-2
Severity: normal

Dear Maintainer,

I followed 
https://www.cyberciti.biz/faq/how-to-setup-mariadb-ssl-and-secure-connections-from-clients/
 but something went wrong:

2019-04-17 12:24:55 0 [Note] InnoDB: Loading buffer pool(s) from 
/var/lib/mysql/ib_buffer_pool
SSL error: Unable to get private key from '/etc/mysql/ssl/server-key.pem'
2019-04-17 12:24:55 0 [Warning] Failed to setup SSL
2019-04-17 12:24:55 0 [Warning] SSL error: Unable to get private key

What went wrong?

# cat /etc/mysql/ssl/server-key.pem
-BEGIN RSA PRIVATE KEY-
...
-END RSA PRIVATE KEY-

Is a better guide available?
Could this be automated?

Greetings,

Olaf

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-8
ii  libdbi-perl   1.642-1+b1
ii  libgnutls30   3.6.6-2
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019031300
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.13-2
ii  mariadb-common1:10.3.13-2
ii  mariadb-server-core-10.3  1:10.3.13-2
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  mailutils [mailx]  1:3.5-3
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- Configuration Files:
/etc/mysql/mariadb.conf.d/50-server.cnf changed:
[server]
[mysqld]
user= mysql
pid-file= /run/mysqld/mysqld.pid
socket  = /run/mysqld/mysqld.sock
basedir = /usr
datadir = /var/lib/mysql
tmpdir  = /tmp
lc-messages-dir = /usr/share/mysql
query_cache_size= 16M
log_error = /var/log/mysql/error.log
expire_logs_days= 10
ssl-ca=/etc/mysql/ssl/ca-cert.pem
ssl-cert=/etc/mysql/ssl/server-cert.pem
ssl-key=/etc/mysql/ssl/server-key.pem
character-set-server  = utf8mb4
collation-server  = utf8mb4_general_ci


-- debconf information:
  mariadb-server-10.3/nis_warning:
  mariadb-server-10.3/postrm_remove_databases: false
  mariadb-server-10.3/old_data_directory_saved:

Bug#906686: closed by Ondřej Surý (Re: Bug#906686: problem still present on 7.3.2-3 and something more :-))

[Olaf van der Spek]

Op wo 17 apr. 2019 om 10:06 schreef Debian Bug Tracking System
:
> Ernesto confirmed that it was lack of entropy in his case, so I am closing 
> the bug.

So, what is the solution?

Bug#926231: [debian-mysql] Bug#926231: mariadb-server-10.3: dpkg configure error - upgrade from mysql

[Olaf van der Spek]

On Wed, Apr 3, 2019 at 11:12 PM Graham Cobb  wrote:
> I'm not sure what the "MariaDB error log" is but I have found the following 
> entries in syslog:

It's /var/log/mysql/error.log

Bug#916310: Unstable?

[Olaf van der Spek]

Should it be in unstable?

-- 
Olaf

Bug#923526: mariadb-server-10.3: utf8_general_ci vs utf8_unicode_ci

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.13-1
Severity: wishlist

Dear Maintainer,

To utf8_unicode_ci or not to utf8_unicode_ci, that's the question. ;)
AFAIK utf8_unicode_ci is recommended, but the current default is 
utf8_general_ci.

Ideally this would be fixed upstream but upstream seems unresponsive.

https://jira.mariadb.org/browse/MDEV-17662

Greetings,

Olaf

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-1
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-8
ii  libdbi-perl   1.642-1+b1
ii  libgnutls30   3.6.6-2
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-2
ii  lsb-base  10.2018112800
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.13-1
ii  mariadb-common1:10.3.13-1
ii  mariadb-server-core-10.3  1:10.3.13-1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-4
ii  psmisc23.2-1
ii  rsync 3.1.3-5
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  mailutils [mailx]  1:3.5-2
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- debconf information:
  mysql-server/error_setting_password:
  mariadb-server-10.3/old_data_directory_saved:
  mysql-server/password_mismatch:
  mariadb-server-10.3/postrm_remove_databases: false
  mariadb-server-10.3/nis_warning:

Bug#922018: [debian-mysql] Bug#922018: mariadb-server-10.3: Logs are not in /var/lib/mysql

[Olaf van der Spek]

Op di 12 feb. 2019 om 18:13 schreef Faustin Lammler :
>
> Olaf,
> It seems that in this case, the error log should indeed be in the
> datadir ($ldata -> /var/lib/mysql).
>
> I have double checked and this behavior is the same since 10.1 (Debian
> or upstream).
>
> See:
> https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/master/scripts/mysql_install_db.sh#L489
> https://salsa.debian.org/mariadb-team/mariadb-10.3/blob/master/scripts/mysql_install_db.sh#L511
> https://github.com/MariaDB/server/blob/10.1/scripts/mysql_install_db.sh#L499
> https://github.com/MariaDB/server/blob/10.3/scripts/mysql_install_db.sh#L511

Hi Faustin,

I'm sure not what point you're trying to make.

What does `ls -l /var/log/mysql` return on your system?

# ls -l /var/log/mysql
total 28
-rw-r- 1 mysql adm0 Feb 15 00:00 error.log
-rw-r- 1 mysql adm   20 Feb 14 12:09 error.log.1.gz
-rw-r- 1 mysql adm  978 Feb 14 12:09 error.log.2.gz
-rw-r- 1 mysql adm   20 Feb 12 00:00 error.log.3.gz
-rw-r- 1 mysql adm   20 Feb 11 09:39 error.log.4.gz
-rw-r- 1 mysql adm  933 Feb 11 09:39 error.log.5.gz
-rw-r- 1 mysql adm   20 Feb  4 12:05 error.log.6.gz
-rw-r- 1 mysql adm 1117 Feb  4 12:05 error.log.7.gz



-- 
Olaf

Bug#904422: [Pkg-javascript-devel] Bug#904422: npm: complains about too-new nodejs

[Olaf van der Spek]

Op di 12 feb. 2019 om 11:15 schreef Pirate Praveen :
> npm was not updated for over 3 years and was removed from stretch. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870460
>
> My motivation for updating it was for gitlab (I'd have been happy with
> even npm 1.4 as I only wanted 'npm install yarn' from npm) and 5.x was
> perfectly suitable, not only for my usecase but that was the latest
> upstream version at that time (5.8 is also available in
> stretch-backports). Now yarn (node-yarnpkg) is already packaged and I
> don't have any motivation to keep npm updated. Its a team maintained
> package and anyone is free to update it (just like how I updated it to
> 5.x from 1.x). Is there any specific feature that you are looking for
> in npm 6?

No, it's just the noise regarding nodejs version that I'd like to avoid.

In general it's nice to have the latest stable versions in a release
though, as in other cases you do hit bugs or features that aren't
available due to an older version being present.


-- 
Olaf

Bug#904422: [Pkg-javascript-devel] Bug#904422: npm: complains about too-new nodejs

[Olaf van der Spek]

Op di 12 feb. 2019 om 10:25 schreef Pirate Praveen :
> > npm 6 has been available for some time..
> >
>
> If that introduce any rc bugs, there won't be enough time to fix it and
> I don't want to risk it at this point.

Makes sense. 6 has been available since May though, right? Why wasn't
it uploaded earlier?


-- 
Olaf

Bug#904422: [Pkg-javascript-devel] Bug#904422: npm: complains about too-new nodejs

[Olaf van der Spek]

Op di 12 feb. 2019 om 10:13 schreef Pirate Praveen :
> On ചൊ, ഫെബ്രു 12, 2019 at 2:34 വൈകു, Olaf van
> der Spek  wrote:
> > Could npm 6 be packaged?
>
> We won't be able to get it into buster (soft freeze starting today),

>  2019-02-12 Soft freeze (no new packages, no re-entry, 10 day migration)

It'd not be a new package would it?

> but we can try for buster + 1 or possibly buster-backports.

npm 6 has been available for some time..


-- 
Olaf

Bug#904422: npm: complains about too-new nodejs

[Olaf van der Spek]

Hi,

Could npm 6 be packaged?

Greetings,

-- 
Olaf

Bug#922018: [debian-mysql] Bug#922018: mariadb-server-10.3: Logs are not in /var/lib/mysql

[Olaf van der Spek]

Op ma 11 feb. 2019 om 16:06 schreef Faustin Lammler :
> I have just checked and this seems to be the default directory
> for the error log:
> https://mariadb.com/kb/en/library/overview-of-mariadb-logs/

Debian has log_error = /var/log/mysql/error.log

-- 
Olaf

Bug#922018: [debian-mysql] Bug#922018: mariadb-server-10.3: Logs are not in /var/lib/mysql

[Olaf van der Spek]

Op ma 11 feb. 2019 om 16:02 schreef Faustin Lammler :
> Can I ask you what steps leads to this?

apt upgrade I think, from 10.1 to 10.3, with enable-large-prefix in a conf file.
Note it's not about the failure itself, it's about the text being
wrong about the location of logs.


-- 
Olaf

Bug#922018: mariadb-server-10.3: Logs are not in /var/lib/mysql

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.12-2
Severity: normal

Dear Maintainer,

Feb 11 10:13:29 ln0 mariadb-server-10.3.postinst[14792]: 
Feb 11 10:13:29 ln0 mariadb-server-10.3.postinst[14792]: Installation of system 
tables failed!  Examine the logs in
Feb 11 10:13:29 ln0 mariadb-server-10.3.postinst[14792]: /var/lib/mysql for 
more information.

Greetings,

Olaf

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.70
ii  galera-3  25.3.25-1
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-6
ii  libdbi-perl   1.642-1+b1
ii  libpam0g  1.1.8-4
ii  libssl1.1 1.1.1a-1
ii  libstdc++68.2.0-16
ii  lsb-base  10.2018112800
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.12-2
ii  mariadb-common1:10.3.12-2
ii  mariadb-server-core-10.3  1:10.3.12-2
ii  passwd1:4.5-1.1
ii  perl  5.28.1-4
ii  psmisc23.2-1
ii  rsync 3.1.3-5
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  mailutils [mailx]  1:3.5-2
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- debconf information:
  mariadb-server-10.3/old_data_directory_saved:
  mariadb-server-10.3/nis_warning:
  mariadb-server-10.3/postrm_remove_databases: false

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Olaf van der Spek]

On Mon, Feb 4, 2019 at 12:30 PM Otto Kekäläinen  wrote:
> > Great. Do you know what's missing from
> > https://salsa.debian.org/olafvdspek-guest/mariadb-10.3/commit/55d06886f5a81c10a00822078aac3ea0090c1b7f
> > to split mytop?
>
> hmm, no comments comes to my mind.

Just to be clear, the build fails with a file not found error which I
don't know how to resolve.

> Did you research the state of
> https://tracker.debian.org/pkg/mytop -

No, but it was fine when I used it.

> should mytop be a completely
> different package as it was?

IMO yes but I don't know the reasons it was included in MariaDB packaging.




-- 
Olaf

Bug#863596: mytop can't installed

[Olaf van der Spek]

Hi Werner,

> I don't know which source of mytop is included in mariadb-client-10.1 and 
> cannot estimate if the standalone package of mytop makes sense or not in 
> stretch. I assume the Maintainers of MariaDB do things right so I won't look 
> further into this.

Would you be willing to continue maintaining mytop if the conflict
with mariadb was resolved?



Greetings,

-- 
Olaf van der Spek

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Olaf van der Spek]

Op vr 1 feb. 2019 om 11:09 schreef Otto Kekäläinen :
>
> I agree that having mytop (or mariadbtop) in a separate package would
> make sense. I am not even fully familiar what the original upstream
> story is and who is maintaining the "most upstream" version of it
> currently.

Great. Do you know what's missing from
https://salsa.debian.org/olafvdspek-guest/mariadb-10.3/commit/55d06886f5a81c10a00822078aac3ea0090c1b7f
to split mytop?

BTW, have you seen
https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests/12 ?

Greetings,

-- 
Olaf

Bug#920727: Boost version 1.67 is known to be buggy

[Olaf van der Spek]

Giovanni Mascellani:
> Of course I will eventually update Boost, but probably not before
> stretch is released. Version 1.67 is going in stretch.

https://www.debian.org/releases/stretch/ ;)

> I have no idea why either meson or mpd think Boost 1.67 is buggy,

https://github.com/boostorg/lockfree/commit/12726cda009a855073b9bedbdce57b6ce7763da2

It's unfortunate Buster won't ship with 1.69 (or 1.68).

-- 
Olaf

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Olaf van der Spek]

On Sat, Dec 29, 2018 at 4:27 PM Otto Kekäläinen  wrote:
> > What about moving mytop (matop?) into it's own package? That'd keep
> > issues separated as well.
>
> That would solve the issue filed in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863968
>
> Maintaining MariaDB in Debian requires a lot of work and if you find
> this package important, please contribute by helping fix this bug.
> Also, if you test out current MariaDB 10.3 in Debian and find any new
> issues, please "scratch your own itch" and help out by fixing them.
>
> The preferred way of submitting contributions is as merge requests on
> Debian's Salsa system:
> https://wiki.debian.org/Teams/MySQL/patches

I've attempted to split the package at
https://salsa.debian.org/olafvdspek-guest/mariadb-10.3/commit/55d06886f5a81c10a00822078aac3ea0090c1b7f
but when building there's an error it can't find mytop..
Also, would it be better if mytop was in it's own source package and repo?
Building takes a while too, is there a way to do the packaging without
rebuilding the entire server every time?

Greetings,

-- 
Olaf

Bug#920996: apt: 2 packages can be upgraded. Run 'apt list --upgradable' to see them.

[Olaf van der Spek]

Package: apt
Version: 1.8.0~beta1
Severity: wishlist

Hi,

> 2 packages can be upgraded. Run 'apt list --upgradable' to see them.

Could you just tell me which packages, especially when it's just a few?
If it's 100+, the number makes sense. If it's 10, I'd like to know which.

Greetings,

Olaf

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Get "";
APT::Get::HideAutoRemove "1";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";

Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'

[Olaf van der Spek]

Op ma 28 jan. 2019 om 17:57 schreef Marko Mäkelä :
> > Wow that was quick, thanks a lot! Got a link to the changes?
>
> https://github.com/MariaDB/server/commit/36be0a5aef0376c526d68007da1c11ac440f0d8b
>
> The cost is not that big. Unfortunately we do not have any common

That's much more than I expected. Perhaps it makes sense to handle
this properly such that settings don't have to be removed entirely and
compatibility with older conf files is improved.


-- 
Olaf

Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'

[Olaf van der Spek]

Op ma 28 jan. 2019 om 17:17 schreef Marko Mäkelä :
>
> I filed and fixed the following ticket in the upcoming MariaDB 10.3.13 
> release:
> https://jira.mariadb.org/browse/MDEV-18399
> MDEV-18399 Recognize the deprecated parameters innodb_file_format,
> innodb_large_prefix

Wow that was quick, thanks a lot! Got a link to the changes?

I'm curious, what's the cost of retaining removed settings? Can't be
much more than a string in an array..




-- 
Olaf

Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'

[Olaf van der Spek]

Op ma 28 jan. 2019 om 13:23 schreef Marko Mäkelä :
> > > The parameters innodb_large_prefix and innodb_file_format were
> > > deprecated in MySQL 5.7 and MariaDB 10.2, and removed in MySQL 8.0 and
> > > MariaDB 10.3.
> >
> > What's the deprecation policy?
> > I think the time between deprecation and removal is too short.
>
> For Oracle, the policy is to deprecate in an earlier version (possibly
> in an update to a GA release) and to remove in the next major version
> (which is not yet released as GA).

So they could deprecate something in a 8.0 update today and remove it
in a 8.1 GA release tomorrow? That doesn't sound right. ;)

> > > How long should obscure parameters be preserved?
> >
> > Were large-prefix and file-format obscure? They were in the debian
> > default maria db conf files..
>
> They should have been made default and deprecated way before version
> 5.7. The only reason for the parameters to exist was to theoretically
> allow downgrading to MySQL 5.1. I do not think that such downgrading
> was ever tested.

I agree, I think we shouldn't deviate from upstream defaults.

> > > Forever? What about
> > > old syntax? The following worked in MySQL 5.0, but no longer in MySQL
> > > 5.1 or MariaDB:
> > > create table t(a int) type=innodb;
> >
> > Syntax is different, when did engine= become available?
>
> TYPE=InnoDB (or other storage engines) was deprecated in MySQL 4.1.2,
> in the same commit that introduced ENGINE=InnoDB syntax.
> So, at that time, the time frame from deprecation to removal was 2
> major releases.

4.1: October 2004
5.1: November 2008

4 years isn't too bad ;)

> The following were removed from InnoDB in MariaDB 10.3:
> innodb_support_xa
> innodb_use_mtflush, innodb_mtflush_threads
> innodb_file_format
> innodb_file_format_check
> innodb_file_format_max
> innodb_large_prefix
> innodb_instrument_semaphores
> innodb_use_fallocate
>
> Which removed parameters would you want to be recognized?

I think those three:
innodb_file_format= barracuda
innodb_large_prefix   = on
innodb_default_row_format = dynamic

https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/ae10a7fca8ddbc4f448f6a106440e9d8cbe14eac

Thanks
-- 
Olaf

Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'

[Olaf van der Spek]

Op ma 28 jan. 2019 om 12:33 schreef Marko Mäkelä :
> there would be no issue when upgrading. Would it be thinkable to add
> the loose_ prefix to unknown options in configuration files? Or to

We can't rewrite history.

> ship a new version of the default configuration file, commenting out
> the old (now redundant) settings? Then those users who modified the
> configuration files would be alerted about the problem when upgrading
> the package.

> The parameters innodb_large_prefix and innodb_file_format were
> deprecated in MySQL 5.7 and MariaDB 10.2, and removed in MySQL 8.0 and
> MariaDB 10.3.

What's the deprecation policy?
I think the time between deprecation and removal is too short.

> How long should obscure parameters be preserved?

Were large-prefix and file-format obscure? They were in the debian
default maria db conf files..

How long? Ideally until major distros have all shipped a MariaDB
version with the deprecation warnings.

Treating unknown settings as warnings rather then errors would work too.

> Forever? What about
> old syntax? The following worked in MySQL 5.0, but no longer in MySQL
> 5.1 or MariaDB:
> create table t(a int) type=innodb;

Syntax is different, when did engine= become available?


-- 
Olaf

Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'

[Olaf van der Spek]

Op zo 27 jan. 2019 om 19:22 schreef Otto Kekäläinen :
> Yes, I guess it would be ideal if the upstream binary ignored unknown
> configs instead of stopping on them. Maybe Marko has some comments on
> this.
>
> In packaging we could have some preinstall script that simply added a
> comment to all lines with deprecated config items in the configs, and
> would thus handle the migration automatically.
> Here is the commit about the changes necessary to the default configs
> in Debian: 
> https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/ae10a7fca8ddbc4f448f6a106440e9d8cbe14eac
>
> Would you Olaf want to contribute to the maintainer scripts and write
> up some sed commands etc that would do this?

Are scripts allowed to touch conf files? I think not.
This should be solved upstream such that everybody benefits.

-- 
Olaf

Bug#920415: [debian-mysql] Bug#920415: dpkg: warning: version 'p.ci' has bad syntax: version number does not start with digit

[Olaf van der Spek]

Op zo 27 jan. 2019 om 19:15 schreef Otto Kekäläinen :
> Can you reproduce this issue? What are the steps to reproduce?

1. Install stretch
2. apt install mariadb-server
3. Replace stretch by buster in sources.list
4. apt install mariadb-server

Preparing to unpack .../mariadb-server-10.3_1%3a10.3.12-2_amd64.deb ...
locale: Cannot set LC_ALL to default locale: No such file or directory
/var/lib/mysql: found previous version 10.1
dpkg: warning: version 'p.ci' has bad syntax: version number does not
start with digit
Unpacking mariadb-server-10.3 (1:10.3.12-2) ...

> I cannot find any file *p.ci* from the sources and I have no clue
> where it is picking it up. It should pick up the version string from

I suspect it's picked up here: VERSION=${0: -12:4}
I don't know what is the real full name of the maintainer script here,
but I think it's not what you think.

> the maintainer scripts (e.g. mariadb-server-10.3.preinstall) but in
> this case it sees some other string and I have not figured out what it
> is.

[10:35]  jcristau:  VERSION=${0: -12:4} this code tries to
extract the version number from "mariadb-server-10.3.preinst" but it
seems to get "p.ci" instead.
[10:36]  that code shouldn't make that sort of assumption
[10:36]  jcristau: I agree..
[10:37]  there should be DPKG_* variables with that info
[10:37]  preinst runs from somewhere in /tmp
[10:37]  iirc DPKG_MAINTSCRIPT_PACKAGE
[10:38]  right, what Myon says
[10:38]  
https://salsa.debian.org/postgresql/postgresql/blob/11/debian/postgresql-11.preinst#L5
[10:39]  Thanks, I'll copy that info into the bug report.


-- 
Olaf

Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'

[Olaf van der Spek]

Package: mariadb-server-10.3
Version: 1:10.3.12-2
Severity: normal

Hi,

When upgrading from 10.1 to 10.3 and not using the new 10.3 conf files.. 

2019-01-27 11:13:12 0 [ERROR] /usr/sbin/mysqld: unknown variable 
'innodb-large-prefix=on'
2019-01-27 11:13:12 0 [ERROR] Aborting

This is kinda ugly, can't previously known variables be ignored?
I didn't use the new conf files yet because I didn't want to lose local 
modifications.

Greetings,

Olaf

Setting up mariadb-server-10.3 (1:10.3.12-2) ...
Installing new version of config file /etc/init.d/mysql ...
Installing new version of config file /etc/mysql/debian-start ...

Configuration file '/etc/mysql/mariadb.conf.d/50-server.cnf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** 50-server.cnf (Y/I/N/O/D/Z) [default=N] ? 
dpkg: error processing package mariadb-server-10.3 (--configure):
 installed mariadb-server-10.3 package post-installation script subprocess 
returned error exit status 7
dpkg: dependency problems prevent configuration of mariadb-server:
 mariadb-server depends on mariadb-server-10.3 (>= 1:10.3.12-2); however:
  Package mariadb-server-10.3 is not configured yet.

dpkg: error processing package mariadb-server (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of default-mysql-server:
 default-mysql-server depends on mariadb-server-10.3; however:
  Package mariadb-server-10.3 is not configured yet.

dpkg: error processing package default-mysql-server (--configure):
 dependency problems - leaving unconfigured
Processing triggers for systemd (240-4) ...
Errors were encountered while processing:
 mariadb-server-10.3
 mariadb-server
 default-mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.70
ii  galera-3  25.3.25-1
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-5
ii  libdbi-perl   1.642-1+b1
ii  libpam0g  1.1.8-4
ii  libssl1.1 1.1.1a-1
ii  libstdc++68.2.0-15
ii  lsb-base  10.2018112800
ii  lsof  4.91+dfsg-1
pn  mariadb-client-10.3   
ii  mariadb-common1:10.4.1+maria~sid
pn  mariadb-server-core-10.3  
ii  passwd1:4.5-1.1
ii  perl  5.28.1-3
ii  psmisc23.2-1
ii  rsync 3.1.3-5
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- Configuration Files:
/etc/init.d/mysql changed [not included]
/etc/mysql/debian-start changed [not included]