Bug#1061410: python3-trio: AttributeError: module 'eventlet.green.select' has no attribute 'epoll'

[Robie Basak]

severity 1061410 wishlist
thanks

This doesn't seem like a bug in python-trio to me. It's simply using
select.epoll(). If that's being monkey patched by gevent in a way that
breaks things then that seems like either a gevent problem or a
fundamental incompatibility in trying to use Trio at the same time as
gevent.

https://github.com/python-trio/trio/pull/2928 might be a workaround we
could take if upstream takes it, but nevertheless what Trio is currently
doing is certainly not wrong, and so "grave" seems inappropriate.

Bug#1037016: mk-build-deps fails if the package version is 0

[Robie Basak]

Package: devscripts
Version: 2.23.4
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

If the version of a package is 0, then mk-build-deps creates
$src-build-deps_1.0_all.deb instead of $src-build-deps_0_all.deb. If -i
is used, then it additionally attempts to install
$src-build-deps_0_all.deb, and this fails because of the previous
unexpected output.

AIUI, 0 is a perfectly valid package version according to Debian Policy,
and so should work.

This came up because I used 0 in a template. Of course it wouldn't last
long in a real package!

Minimal steps to reproduce:

# mkdir debian
# cat > debian/changelog
test (0) UNRELEASED; urgency=medium

  * Test mk-build-deps

 -- Robie Basak   Thu, 01 Jun 2023 16:03:13
+
# cat > debian/control
Source: test
Build-Depends: hello
# mk-build-deps -i -r
dpkg-buildpackage: info: source package test-build-deps
dpkg-buildpackage: info: source version 1.0
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Equivs Dummy Package Generator 

dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 debian/rules clean
dh clean
   dh_clean
 debian/rules binary
dh binary
   dh_update_autotools_config 
   dh_autoreconf
   create-stamp debian/debhelper-build-stamp
   dh_prep
   dh_auto_install --destdir=debian/test-build-deps/
   dh_install
   dh_installdocs   
   dh_installchangelogs
   dh_perl
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
   dh_installdeb
   dh_gencontrol
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'test-build-deps' in 
'../test-build-deps_1.0_all.deb'.
 dpkg-genbuildinfo --build=binary -O../test-build-deps_1.0_amd64.buildinfo
 dpkg-genchanges --build=binary -O../test-build-deps_1.0_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)

The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!
dpkg: error: cannot access archive 'test-build-deps_0_all.deb': No such file or 
directory
mk-build-deps: dpkg --unpack failed

Bug#1033606: Add dep8 tests for mosh

[Robie Basak]

Source: mosh
Version: 1.4.0-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi,

In Ubuntu, we added a couple of dep8 tests to the mosh package. These
should help detect any regressions caused by changes in dependencies
before they land. I think these should apply and be equally useful for
Debian. Please consider applying the attached patch. Thanks!

diff --git a/debian/changelog b/debian/changelog
index af36f16..2f1ba64 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+mosh (1.4.0-1ubuntu1) lunar; urgency=medium
+
+  [ Sergio Durigan Junior ]
+  * d/t/upstream-tests: New dep8 test which runs the upstream test
+suite against a system mosh.
+
+  [ Robie Basak ]
+  * d/t/smoke: smoke test for mosh using pexpect.
+
+ -- Robie Basak   Wed, 22 Mar 2023 13:36:00 +
+
 mosh (1.4.0-1build1) lunar; urgency=medium
 
   * Rebuild against new libprotobuf32.
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..7623e07
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,7 @@
+Tests: upstream-tests
+Depends: @, @builddeps@
+Restrictions: allow-stderr
+
+Tests: smoke
+Depends: mosh, openssh-server, python3-pexpect
+Restrictions: allow-stderr, isolation-container, needs-root, superficial, 
breaks-testbed
diff --git a/debian/tests/smoke b/debian/tests/smoke
new file mode 100755
index 000..7ff856d
--- /dev/null
+++ b/debian/tests/smoke
@@ -0,0 +1,28 @@
+#!/bin/sh
+set -ex
+
+# HOME may not be set in an autopkgtest environment, but we want to be on the
+# same page as ssh on where ~/.ssh is. See LP: #2012514.
+if [ "$HOME" = "" ]; then
+   export HOME=$(getent passwd `whoami`|cut -d: -f6)
+fi
+
+echo 'mosh motd test' > /etc/motd
+mkdir -pm700 "$HOME"/.ssh
+if [ ! -f "$HOME"/.ssh/id_rsa ]; then
+   ssh-keygen -N '' -C mosh-smoke -f "$HOME"/.ssh/id_rsa
+fi
+if [ ! -f "$HOME"/.ssh/authorized_keys ] || ! grep -q mosh-smoke\$ 
"$HOME"/.ssh/authorized_keys; then
+   cat "$HOME"/.ssh/id_rsa.pub >> "$HOME"/.ssh/authorized_keys
+fi
+python3 <

Bug#1030487: python-trustme: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Robie Basak]

clone 1030487 -1
reassign -1 python3-service-identity 18.1.0-7
retitle -1 Missing dependency on python3-six makes package unusable
thanks

On Sat, Feb 04, 2023 at 08:58:30AM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

[...]

> > ImportError while importing test module 
> > '/<>/.pybuild/cpython3_3.11/build/tests/test_trustme.py'.
> > Hint: make sure your test modules/packages have valid Python names.
> > Traceback:
> > /usr/lib/python3.11/importlib/__init__.py:126: in import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> > tests/test_trustme.py:21: in 
> > import service_identity.pyopenssl  # type: ignore[import]
> > /usr/lib/python3/dist-packages/service_identity/__init__.py:7: in 
> > from . import cryptography, pyopenssl
> > /usr/lib/python3/dist-packages/service_identity/pyopenssl.py:9: in 
> > import six
> > E   ModuleNotFoundError: No module named 'six'

Looks like python3-service-identity should have a dependency on
python3-six but it does not.

Steps to reproduce:

apt install python3-service-identity
python3
>>> from service_identity.pyopenssl import verify_hostname
...
ModuleNotFoundError: No module named 'six'

This is expected to work as documented at
https://service-identity.readthedocs.io/en/stable/api.html

I will send a fix for this to Salsa shortly.

Robie


signature.asc
Description: PGP signature

Bug#1026155: python-trio: diff for NMU version 0.22.0-0.1

[Robie Basak]

On Sat, Dec 17, 2022 at 07:28:24AM +0100, Jochen Sprickerhof wrote:
> I've prepared an NMU for python-trio (versioned as 0.22.0-0.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Thank you for working on this! Assuming it builds and passes tests OK,
+1 for immediate upload if you wish.


signature.asc
Description: PGP signature

Bug#1024016: mysql-8.0: CVE-2022-39400 CVE-2022-39402 CVE-2022-39403 CVE-2022-39408 CVE-2022-39410 CVE-2022-21594 CVE-2022-21599 CVE-2022-21604 CVE-2022-21608 CVE-2022-21611 CVE-2022-21617 CVE-2022-21

[Robie Basak]

On Sun, Nov 13, 2022 at 08:31:24PM +0100, Moritz Mühlenhoff wrote:
> The following vulnerabilities were published for mysql-8.0.

FTR, an update to 8.0.31 to fix these is already prepared and being
tested at
https://salsa.debian.org/mariadb-team/mysql/-/merge_requests/65


signature.asc
Description: PGP signature

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

On Sun, Nov 13, 2022 at 05:46:00PM +0100, Marco d'Itri wrote:
> On Nov 13, Robie Basak  wrote:
> 
> > This seems inconsistent to me. Where is the expectation that TMPDIR must
> > be unset if dropping privileges coming from? Obviously for users of
> Where is the expectation that $TMPDIR is writable by any user but the 
> current one?
> I do not believe that it is expected that if a user creates a directory 
> and points $TMPDIR to it then they also have to make it sticky, so this 
> has nothing to do with libpam-tmpdir.

I understand the traditional semantics of TMPDIR to be exactly the same
as /tmp. So that includes the sticky bit, or at least behaviour that is
equivalent under all circumstances. Or, alternatively, that someone who
sets TMPDIR without setting the sticky bit is certain that it will be
used in a way that does not rely on that.

libpam-tmpdir breaks those semantics in a way that breaks in edge cases
like the situation raised in this (and other) bug reports. So on the
contrary, I think it has everything to do with libpam-tmpdir, and
anything else that sets TMPDIR to something that doesn't match the
traditional semantics.

To be clear, if it's better that we change the semantics to improve the
system as a whole, then I don't have a particular objection to that.

But I'd prefer that it be done deliberately, with consensus across all
developers, and be well-defined and documented. Rather than have a
change of semantics exist in a multitude of individual fixes for
individual bug reports that potentially end up solving the issue
differently, inconsistently or incompletely, and without regard for the
bigger picture (eg. if the conclusion is that it should be done
somewhere other than maintainer scripts or in common tooling). There's
also the risk that we swap one problem for another - for example if
there are use cases which rely on maintainer scripts honouring TMPDIR,
including when they drop privileges.


signature.asc
Description: PGP signature

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

On Sun, Nov 13, 2022 at 04:16:29PM +0100, Marco d'Itri wrote:
> And I think that it would be wrong to have dpkg generally unset $TMPDIR, 
> because if root sets it then it would be reasonable to expect that also
> dpkg and the maintainer scripts use it (as long as they are not dropping 
> privileges).

This seems inconsistent to me. Where is the expectation that TMPDIR must
be unset if dropping privileges coming from? Obviously for users of
libpam-tmpdir that's a problem. But in the default case, it's something
that would be entirely reasonable to inherit through a drop of
privileges, for the same reason that I think you find that setting
TMPDIR for maintainer scripts to use would be useful.


signature.asc
Description: PGP signature

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

On Sun, Nov 13, 2022 at 02:58:47PM +, Simon McVittie wrote:
> If the maintainer script is *dropping* privileges from root down to a
> system user, then I think the maintainer script is/should be responsible
> for doing that privilege drop in a way that works...

Agreed, but amongst various other things, I don't think it's at all
clear whether TMPDIR is one of the things that the maintainer script
should be expected to unset in this case.

For libpam-tmpdir's use of setting TMPDIR, it's obviously the required
behaviour.

But what about in general? What's the "environment variable" interface
to maintainer scripts? Clearly they are expected to honor _some_
environment variables. Is TMPDIR one of them? Where's the complete list
defined, so that we can be sure that the semantics are reasonable for
all the use cases we can think of, and so that we can all write
maintainer scripts correctly?

Why is it that dropping privileges requires the unsetting of environment
variables in the case of maintainer script invocations anyway? They are
always run from a trusted environment and unsetting variables removes
the ability to pass configuration through. Sure, I can't rely on some
expectations holding (eg. HOME), but if I don't rely on this, there's no
problem. So then, what about TMPDIR? What are its actual semantics?
Tying TMPDIR to the uid that uses it is not the default, nor the
tradition. This entanglement is something that libpam-tmpdir adds. Maybe
that means that we need to consider TMPDIR's semantics changed, because
people find this kind of behaviour more useful. But that's a discussion
that hasn't yet happened.

For example, is there a user who expects to be able to use TMPDIR to
tell a maintainer script where there is enough space for its task, only
to find that it doesn't have any effect because the maintainer script
drops privileges and unsets it before doing its task?


signature.asc
Description: PGP signature

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

On Sun, Nov 13, 2022 at 02:21:58AM +0100, Marco d'Itri wrote:
> On Nov 12, Otto Kekäläinen  wrote:
> 
> > Instead of manually trying to manage TMPDIR env variable in various
> > places, we should have a standardized way to run maintainer scripts in
> > clean shell sessions that have all env variables set automatically
> > correctly.
> This is not about maintainer scripts, but about programs which change 
> the UID without sanitizing the environment.

No, it's absolutely about maintainer scripts, since that's the bug
reported, and the specific fix suggested implies that all relevant
maintainer scripts need changing.

You have generalised this, but I don't think it's at all clear that such
a broad generalisation is appropriate here.


signature.asc
Description: PGP signature

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

On Thu, Nov 10, 2022 at 10:46:55PM +, brian m. carlson wrote:
> > I think it's more wide than that: If you change UID, you need to
> > sanitise the environment.  Your HOME is likely to be wrong.  PATH might
> > very well be pointing at directories which are not appropriate for the
> > user you're changing the UID to, etc.
> 
> I believe this is the best practice.  For example, sudo typically passes
> through only a handful of environment variables, such as TERM, to avoid
> things like insecure PATH entries.  For example, if MySQL invoked a
> binary in PATH and I had a custom script named the same thing that had
> insecure behaviour when invoked as another user, that would be bad.
> OpenSSH also sanitizes the environment passed over the connection.

Taking your example, if we decide we cannot trust PATH, then dpkg should
reset it before invoking maintainer scripts. It doesn't make sense to
say that we should not trust the supplied PATH under these circumstances
but then also require maintainer scripts to individually reset it.


signature.asc
Description: PGP signature

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

On Thu, Nov 10, 2022 at 05:37:53PM +0100, Tollef Fog Heen wrote:
> I think it's more wide than that: If you change UID, you need to
> sanitise the environment.  Your HOME is likely to be wrong.  PATH might
> very well be pointing at directories which are not appropriate for the
> user you're changing the UID to, etc.

I don't think that this is necessarily obviously the case in general.
For example, I often use "sudo -s" and *don't* want HOME reset. It
depends on the purpose of taking different privileges as to what is
appropriate to reset.

> I'm not sure this is libpam-tmpdir specific, but rather a bit more
> general: what are the expectations that maintainer scripts can have
> about the environment they're running in, and how do we make those
> expectations hold?  This should probably then be documented in policy.

Agreed, but also, we need a specific answer for TMPDIR. We pass things
into maintainer scripts because we want to change their behaviour (eg.
DEBIAN_FRONTEND). So which specific variables are required to be reset
by maintainer scripts and under what circumstances?


signature.asc
Description: PGP signature

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

On Thu, Nov 10, 2022 at 12:08:55PM +0100, Marco d'Itri wrote:
> > But are you in essence saying that libpam-tmpdir requires that *every
> > maintainer script* that runs things as non-root, or starts processes
> > that do that, unset TMPDIR first?
> This would not be right, because it is totally valid to set $TMPDIR for 
> the root user too.
> The real issue here is that TMPDIR, like some other variables, should 
> not be propagated when switching privileges from the user to root.
> 
> But here we have ANOTHER issue: whatever ends up initialising mysql does 
> not run as root, but still uses $TMPDIR provided by the root environment.
> Since there is no guarantee at all that $TMPDIR can be accessed (not 
> just be writeable!) by other users then in this case it is correct to 
> request that the package ignores $TMPDIR.

I think this statement is in violent agreement with the statement I made
above?

I agree that there is now no guarantee that $TMPDIR can be accessed,
because of what libpam-tmpdir is doing. However, if you were to ask an
expert from the nineties, that was a reasonable assumption. So what
changed, and where and how precisely is this change supposed to be
accomodated? Every relevant maintainer script? dpkg? Or somewhere else?


signature.asc
Description: PGP signature

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Robie Basak]

Thank you for the report. Adding debian-devel@ and the libpam-tmpdir
maintainer for wider discussion.

On Thu, Nov 10, 2022 at 12:54:34AM +, brian m. carlson wrote:
> On my systems, I use libpam-tmpdir, which provides each user with a
> private temporary directory owned and accessible only by them under
> /tmp/user/UID (e.g., /tmp/user/1000).  PAM sets the TMPDIR variable to
> this value upon creating a session.
> 
> When I upgrade mysql-server-8.0, it is obviously as root, so TMPDIR is
> set to /tmp/user/0.  This value does not work since MySQL doesn't run as
> root, and so MySQL fails to start after upgrade in such a configuration,
> like so:

I think I understand the problem.

But are you in essence saying that libpam-tmpdir requires that *every
maintainer script* that runs things as non-root, or starts processes
that do that, unset TMPDIR first?

Wouldn't ignoring TMPDIR make it less useful for users who wish to set
it for other purposes, since maintainer scripts would stop respecting
this?

Or, if this universally is the right thing to do, then maybe dpkg should
be doing it rather than individual maintainer script?

I'd be happy to unset TMPDIR if there's clear consensus that this is
what such maintainer scripts should always do, but it isn't clear to me
that this is correct.

Note that in this case it's the database initialization that's affected,
which happens to be done by mysqld running as a daemon, but in a way
that is equivalent to it not being a daemon - the task will be complete,
with no lingering processes, before the maintainer script exits.

In searching all I could find was
https://lists.debian.org/debian-devel/2005/02/msg00374.html which is
a similar question but doesn't look like it ever concluded.

I think the answer to this should probably be established by the
libpam-tmpdir maintainer and documented first, for fear of someone else
later coming along and saying that the maintainer script incorrectly
ignores TMPDIR because we started ignoring it to resolve this bug. So I
copied debian-devel@ for comment.

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#1020518: [debian-mysql] Bug#1020518: Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Robie Basak]

On Thu, Sep 22, 2022 at 11:32:05PM +0200, Ghislain Adnet wrote:
> in fact /etc/mysql/mariadb.cnf does not exist as there is a mysql server and 
> not a mariadb one.

mariadb-common ships /etc/mysql/mariadb.cnf.

> I have a perconna mysql server running and i want to install mytop that 
> require a perl lib that require libmariad3b, that then, want to replace 
> /etc/mysql/my.cnf with a link to /etc/mysql/mariadb.cnf,

Not necessarily. It integrates with update-alternatives. It will link
from /etc/mysql/my.cnf to /etc/mysql/mariadb.cnf unless overridden by
another package or by the user.

> but /etc/mysql/mariadb.cnf does not exist while /etc/mysql/my.cnf exist from 
> the percona packages.

You're entitled to remove /etc/mysql/mariadb.cnf and I think in that
case the packaging should respect that and not break. So there might be
something that could be improved here.

However, I did some investigation, and found that if you set
update-alternatives correctly to use a different my.cnf (in my testing I
used my.cnf.fallback as it was already there), then the packaging does
not break. So, as far as I can tell, the problem here lies with your
third party packaging not correctly integrating with distribution
packaging by using update-alternatives correctly to supply my.cnf. I
think you need to report this bug to them, and it isn't an issue in
Debian.


signature.asc
Description: PGP signature

Bug#1020518: [debian-mysql] Bug#1020518: Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Robie Basak]

On Thu, Sep 22, 2022 at 05:28:27PM +0100, Robie Basak wrote:
> Again, note that I'm still speculating here because I don't follow the
> exact sequence of events which is causing the third party packaging to
> trip up here. If there's something we're doing wrong then we should fix
> it, but nothing I've read so far suggests that.

Oh, hold on. Is the issue that you've *deleted* /etc/mysql/mariadb.cnf?
If so, then yes, /usr/share/mysql-common/configure-symlinks could
reasonably not call update-alternatives --install to maintain that
"sysadmin choice". It should probably print a warning in this case.

But we should also take care of the "remove" call too, make sure that
also works if the "install" was skipped.


signature.asc
Description: PGP signature

Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Robie Basak]

On Thu, Sep 22, 2022 at 06:21:34PM +0200, Ghislain Adnet wrote:
> So perhaps we could see it another way :
> in this particular case i think that a client library, if it find an existing 
> /etc/mysql/my.cnf, should not do anything as it is there adn so everything it 
> need is okay.
> There is no need for a client library to change this part if it is here if it 
> only need one to exist.
> 
> Perhaps just adding a check
> if [[  ! -e /etc/mysql/my.cnf ]]; then
>   do touch server configuration in /etc/mysql/my.cnf
> fi

We use the Debian-system-wide update-alternatives mechanism, which has
standard and known behaviour. Further, third party packaging can simply
integrate with it to provide their own my.cnf as needed. If
/etc/mysql/my.cnf is properly overriden by packaging, even external
packaging, then the client library packages that touch it will leave it
alone.

I don't think it makes sense to introduce extra behaviour that might be
surprising for sysadmins who already know how update-alternatives works
and integrate with it.

Again, note that I'm still speculating here because I don't follow the
exact sequence of events which is causing the third party packaging to
trip up here. If there's something we're doing wrong then we should fix
it, but nothing I've read so far suggests that.


signature.asc
Description: PGP signature

Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Robie Basak]

On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote:
>* What outcome did you expect instead?
> 
>installing a client library should not require anything on the server side 
> and should not modify server configuration of mariadb or other mysql flavors 
> (imho ;p)

Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and
use /etc/mysql/my.cnf, and many common packages supplied by Debian link
to a MySQL/MariaDB library. So Debian ends up needing to ship a working
/etc/mysql/my.cnf essentially by default. It doesn't matter which side
of the fork is in use - it's necessary either way. Maybe upstream could
separate the two out, but they don't.

MySQL and MariaDB Debian maintainers worked out a way to make it work
regardless of the side of the fork in use using the update-alternatives
mechanism. I think there might still be some implementation bugs in how
they do that exactly, but I don't think they're relevant to what you're
reporting here.

If third parties are shipping apt packages that override some of this,
they need to integrate with distribution packages, not the other way
round. Issues with third party apt repositories aren't normally
considered bugs in Debian. This sounds like an issue with a third party
repository and a bug in their packaging, and not a bug in Debian.
However I'm not entirely sure as you haven't provided a detailed
analysis of why they've been unable to integrate.

I suggest that this bug needs to be either moreinfo or wontfix.


signature.asc
Description: PGP signature

Bug#1020505: debuginfod is configured by an environment variable instead of /etc

[Robie Basak]

Package: libdebuginfod-common
Version: 0.187-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi,

libdebuginfod-common sets DEBUGINFOD_URLS to a reasonable default (after
prompting appropriately because it's a privacy leak otherwise).

But Debian Policy 9.9 says: "Programs installed on the system PATH
(/bin, /usr/bin, /sbin, /usr/sbin, or similar directories) must not
depend on custom environment variable settings to get reasonable
defaults."

Ideally upstream would support using a file in /etc instead, or failing
that, policy suggests using wrappers.

Technically then this seems like a policy violation.

I also don't like it because it imposes an environment variable on every
user - for example in Ubuntu libdebuginfod-common ends up on every
system because of the built in crash handling. It wouldn't scale and
seems quite ugly to carry this configuration around in environment
variables, and debuginfod doesn't seem like it should have a special
exception.

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#1002239: google-authenticator: FTBFS: dh_auto_test: error: make -j4 test VERBOSE=1 returned exit code 2

[Robie Basak]

Hi,

On Tue, Dec 21, 2021 at 05:33:17PM +0100, Lucas Nussbaum wrote:
> Source: google-authenticator
> Version: 20191231-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211220 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

I'm not the maintainer but noticed that google-authenticator is being
held out of testing due to this bug.

But this package seems to rebuild successfully for me locally, and
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/google-authenticator.html
seems to concur.

Can this bug be closed, please?

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#1005720: [debian-mysql] Bug#1005720: mysql-8.0: FTBFS with OpenSSL 3.0

[Robie Basak]

On Fri, Jul 01, 2022 at 05:45:12PM +0200, Bastian Germann wrote:
> Lena, please tag the changelog entries accordingly, at least for RC bugs so 
> they do not keep the package from migrating.

Note that mysql-8.0 is permanently blocked from migrating by order of
the release team. They want MariaDB in testing to the exclusion of
MySQL. The maintainers would prefer to have both, but the release team
overrode that.

We will continue fixing bugs against the MySQL packaging, but with no
expectation that it will ever migrate.


signature.asc
Description: PGP signature

Bug#1010804: frogatto: Missing Build-Depends on libopengl-dev

[Robie Basak]

Package: frogatto
Version: 1.3.1+dfsg-5
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

*** /tmp/tmpULOMPK/bug_body

In Ubuntu, the build was failing with the following:

Package opengl was not found in the pkg-config search path.
Perhaps you should add the directory containing `opengl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'opengl', required by 'glu', not found

It looks like you need it to be an explicit Build-Depends as the build
requires it directly. Presumably it built before because it was being
brought in indirectly, but that isn't happening here.

  * Add Build-Depends on libopengl-dev to fix FTBFS.


Thanks for considering the patch.

*** /tmp/tmpULOMPK/frogatto_1.3.1+dfsg-5ubuntu1.debdiff
diff -Nru frogatto-1.3.1+dfsg/debian/control frogatto-1.3.1+dfsg/debian/control
--- frogatto-1.3.1+dfsg/debian/control  2020-07-27 16:41:33.0 +0100
+++ frogatto-1.3.1+dfsg/debian/control  2022-05-10 12:45:13.0 +0100
@@ -14,7 +13,8 @@
  libsdl-mixer1.2-dev (>= 1.2.7),
  libsdl-image1.2-dev (>= 1.2.7),
  libboost-regex-dev (>= 1.35),
- libboost-system-dev (>= 1.35)
+ libboost-system-dev (>= 1.35),
+ libopengl-dev
 Homepage: http://www.frogatto.com/
 Uploaders: Debian Games Team ,
Vincent Cheng ,


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (400, 'xenial-proposed'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-221-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#1010621: Missing dependency on fdisk

[Robie Basak]

Package: cloud-guest-utils
Version: 0.31-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi,

cloud-guest-utils is missing a dependency on whatever supplies sfdisk or
sgdisk (eg. fdisk and gdisk), so growpart fails by default. gdisk
is a Recommends. Should this be a Depends, given that growpart is a
headline item in the package description?

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#1010372: [debian-mysql] Bug#1010372: mysql-8.0: Should mysql-8.0 be removed from unstable?

[Robie Basak]

Hi Salvatore,

On Fri, Apr 29, 2022 at 09:52:04PM +0200, Salvatore Bonaccorso wrote:
> Should mysql-8.0 be dropped completely from the archive or is there
> still interest in keeping in in unstable?

I think this is a dupe of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004180? Was asking
again intentional?

My answer is the same - we'd like to keep mysql-8.0 in unstable and are
working on updating unstable and getting Ubuntu back into sync against
Debian.

At Canonical, I am onboarding a colleague who will be working on this.
Prompted again by you, we just set ourselves a goal of having this done
by the end of the month, if that's OK with you?

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#1004180: [debian-mysql] Bug#1004180: mysql-8.0: should mysql-8.0 be removed from unstable?

[Robie Basak]

On Sat, Jan 22, 2022 at 10:53:48AM +0100, Salvatore Bonaccorso wrote:
> While mysql-8.0 itself won't enter testing, the version in unstable is
> as well only from february 2021, lacking behind several updates for
> fixes in the Oracle CPUs.
> 
> Should mysql-8.0 be removed as well from unstable?

FWIW, we started a renewed effort to catch up and stay caught up - for
example I cherry-picked a fix to the master branch in Salsa recently,
and further picks from Ubuntu to catch up security-wise should be coming
soon.

So hopefully we'll be doing much better soon.


signature.asc
Description: PGP signature

Bug#1000866: Source package is missing files required to make a derived work

[Robie Basak]

Source: debianutils
Severity: serious
Justification: FTBFS when making a derived work, contrary to the spirit
 of the Debian Social Contract
Version: 5.5-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Hi,

If I patch the debianutils source package, then I find that I cannot
easily rebuild it without the following files from Salsa VCS that are
not included in the Debian source package:

po4a/de/translator_german.add
po4a/fr/savelog.8.fr.add
po4a/fr/translator_french.add
po4a/fr/which.1.fr.add
po4a/ja/translator_japanese.add
po4a/pl/translator_polish.add
po4a/sl/translator_slovene.add
po4a/po/de.po
po4a/po/es.po
po4a/po/fr.po
po4a/po/it.po
po4a/po/ja.po
po4a/po/pl.po
po4a/po/pt.po
po4a/po/sl.po

Everything is fine if I rebuild the package unmodified. But the build
fails when I patch the package to run "autoreconf" because these files
are missing.

As a result, I wouldn't consider the debianutils Debian source package
to be truly the source, contrary to my expectation that it should be. I
think this fails the spirit of the "desert island test" since someone on
a desert island with a Debian release containing all source packages
would not be able to straightforwardly modify Makefile.am, run
autoreconf and rebuild debianutils. I think the same applies to anyone
who wishes to adjust the translations.

Please could you arrange to ship these missing files in the source
package?

I discovered this while looking to patch debianutils in Ubuntu, but I
think the issue stands in Debian alone, under its own policies. As a
workaround, I just patched these files (grabbed from Salsa) back in, and
that worked fine.

Thanks!

Robie


signature.asc
Description: PGP signature

Bug#998699: Bug#998700: python-trio: Please package new upstream version

[Robie Basak]

forcemerge 998699 998700
tags 998699 + help
thanks

On Sat, Nov 06, 2021 at 03:24:48PM -0400, Boyuan Yang wrote:
> As listed on https://tracker.debian.org/pkg/python-trio , package python-trio
> has new upstream releases that should be packaged. Please consider updating
> this package in Debian.

This is currently blocked on test failures related to garbage
collection with the current release version of trio. If someone can
figure out why a build fails against sid but succeeds for upstream CI,
that would be helpful. Otherwise I'll need to do a deep debuggging
session at some point.


signature.asc
Description: PGP signature

Bug#985320: [debian-mysql] Bug#985320: mariadb-common: Spurious messages when installing package

[Robie Basak]

Hi,

On Tue, Mar 16, 2021 at 12:23:53AM +0100, jpp wrote:
> When upgrading python3-mysqldb apt also update mariadb-common and I get some
> spurious messages :
> Setting up mariadb-common (1:10.5.9-1) ...
> update-alternatives: using /etc/mysql/mariadb.cnf to provide /etc/mysql/my.cnf
> (my.cnf) in auto mode
> update-alternatives: warning: not replacing /etc/mysql/my.cnf with a link

I don't see how these messages are spurious. They're accurate and the
warnings seem appropriate and helpful to me.

> I didn't have MariaDB installed (i am running mysql 5.7.33).

bullseye doesn't ship MySQL 5.7.33, and most MySQL protocol -speaking
packages are linked with MariaDB. On Debian, the release team have
chosen to exclude MySQL in stable releases, so you have no choice but to
use MariaDB to fulfill those dependencies if you want to use packages
like python3-mysqldb.

I suggest this bug should be wontfixed, but I'll leave that decision to
others.

Robie


signature.asc
Description: PGP signature

Bug#983044: Please update to ssh-import-id 5.11

[Robie Basak]

Source: ssh-import-id
Version: 5.10-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

I just uploaded ssh-import-id 5.11 to Ubuntu. I think it's suitable for
upload to Debian also. You can grab it from:

dget 
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ssh-import-id/5.11-0ubuntu1/ssh-import-id_5.11-0ubuntu1.dsc

I expect this will need to wait until bookworm though.

Robie


signature.asc
Description: PGP signature

Bug#981195: mysql-5.7: should mysql-5.7 be removed from Debian unstable?

[Robie Basak]

forcemerge 969095 981195
thanks

On Wed, Jan 27, 2021 at 03:11:40PM +0100, Salvatore Bonaccorso wrote:
> While mysql-5.7 is already not present in testing, I wonder if the
> mysql-5.7 package should be alltogether removed in the Debian archives
> as well from unstable.

Agreed. We already have a bug to track this.

> Removeing cannot be done straight, because of 
> 
> Checking reverse dependencies...
> # Broken Build-Depends:
> myodbc: libmysqlclient-dev (>= 5.5.17)
> pytest-services: mysql-testsuite-5.7

libmysqlclient-dev is now provided by src:mysql-8.0, so myodbc isn't a
blocker. pytest-services is a blocker, and I filed bug 971670 for that
and marked it as blocking the mysql-5.7 removal bug, but have received
no response.


signature.asc
Description: PGP signature

Bug#969602: lptools: UnicodeDecodeError in lp-project-upload

[Robie Basak]

tags 969602 + patch
thanks

I just bumped into this. The solution is to open the release tarball and
its signature as binary, as follows. This should probably just be
squashed into debian/patches/02_python3:

--- a/bin/lp-project-upload 2020-12-07 19:40:42.0 +
+++ b/bin/lp-project-upload 2020-12-07 19:43:40.056335442 +
@@ -123,7 +123,7 @@
 release = create_release(proj, version)
 
 # Get the file contents.
-file_content = open(tarball, 'r').read()
+file_content = open(tarball, 'rb').read()
 # Get the signature, if available.
 signature = tarball + '.asc'
 if not os.path.exists(signature):
@@ -133,7 +133,7 @@
 print('gpg failed, aborting', file=sys.stderr)
 
 if os.path.exists(signature):
-signature_content = open(signature, 'r').read()
+signature_content = open(signature, 'rb').read()
 else:
 signature_content = None


signature.asc
Description: PGP signature

Bug#972445: [debian-mysql] Bug#972445: mysql-server-8.0: possibly erroneous inclusion of mecab libraries

[Robie Basak]

tags 972445 + wontfix
thanks

On Sun, Oct 18, 2020 at 07:18:13PM +, Norwid Behrnd wrote:
> Expected solution: the installation of package mysql-server should
> skip the installation of these four libraries.

Debian generally configures packages to support every feature shipped in
Debian that is supported by that upstream. Where that results in a
dynamic link, it results in a dependency on that shared library. This is
by design.

In this case then, linking libmecab2 and the resulting dependency is
intentional in the design of Debian and of this package. If you want
different build-time configurations to reduce disk space usage, you
should probably use a source-based distribution rather than a binary
distribution like Debian, or modify Debian to suit your needs.

libmecab2 itself is only 1774k. You can use --no-install-recommends to
avoid pulling in mecab-ipadic-utf8 and its chain of dependencies which
is more considerable in size, though if you do that then you will need
to deal with any missing functionality yourself. See the apt
documentation for details on how "Recommends" works.

I'm marking this wontfix since we have no plans to remove mecab from the
build configuration. If you have a more specific suggestion then you're
welcome to propose it and we can consider it.


signature.asc
Description: PGP signature

Bug#969095: RM: mysql-5.7 -- ROM; superseded by mysql-8.0

[Robie Basak]

On Sat, Oct 03, 2020 at 11:59:26AM -0700, Sean Whitton wrote:
> Looks like there is still a rdep on pytest-services.

Sorry. It looks like I missed searching for reverse build dependencies.
I filed a blocking bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971670 against
src:pytest-services for this.

Robie


signature.asc
Description: PGP signature

Bug#971670: Build dependency on deprecated package

[Robie Basak]

Source: pytest-services
Version: 2.1.0-1

src:pytest-services 2.1.0-1 build depends on mysql-testsuite-5.7, which
is now deprecated in favour of 8.0. Please use mysql-testsuite-8.0
instead, or better, use mysql-testsuite which is a metapackage that
depends on the current version.

This is blocking removal of src:mysql-5.7.

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#971367: [debian-mysql] Bug#971367: mariadb-10.5 should not embed wolfssl

[Robie Basak]

Hi,

The relevant previous bug is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921488 where the
packaging switched from "system" to "bundled". Switching back to
"system" would regress that licensing problem.

Also relevant is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937 which is the
same situation but for Postgres.

I don't know how to resolve this conflict between Debian's security
position and Debian's licensing position, but hopefully the above
references provide some background to help someone else figure this out.

Robie


signature.asc
Description: PGP signature

Bug#887007: [debian-mysql] Bug#887007: Bug#887007: my.cnf handling collides with MySQL

[Robie Basak]

I think the original idea was:

Keep the client configuration common to both MySQL and MariaDB as much
as possible. This is because we do want the clients to be coinstallable
and also because users often don't have control of the client in use
since it goes through a client library they didn't choose to build.

So in this world, client configuration would be shipped by mysql-common
only.

I may be remembering this wrong, and there might have been a
misunderstanding at the time, so I welcome any corrections to this.

Then it'd only be the _server packages_ that register against
update-alternatives. Only one of the servers can be active at once,
which is reasonable. And then there would be no collision, since we
already ensure that only one server is active at once.

(If we want to allow coinstallable servers then we also need to complete
the cooperative handling of /var/lib/mysql that we agreed, as well as
disentangle the service files and binaries and default listening ports
in addition to /etc/mysql).

On Mon, Sep 28, 2020 at 08:57:11PM +0300, Otto Kekäläinen wrote:
> I also see that mysql-8.0 added quite a few conflicts on mariadb-*. In
> mysql-5.7 only the server conflicted with the mariadb equivalent.

[...]

> So having any kind of co-installability for even the clients does not
> seem possible right now.

Then how does this bug arise?


signature.asc
Description: PGP signature

Bug#887007: [debian-mysql] Bug#887007: Bug#887007: my.cnf handling collides with MySQL

[Robie Basak]

On Mon, Sep 28, 2020 at 03:31:37PM +0300, Otto Kekäläinen wrote:
> We still have this situation in mariadb-10.5. How do you suggest we
> change the current situation to remedy this?

I think we should move the symlink claim handling from mariadb-common to
mariadb-server-. Then it'd work the same as
mysql-server- and because those all conflict, we won't end up
with this collision.

We just need to ensure that MariaDB clients and the client library work
correctly without the configuration components provided by
/etc/mysql/mariadb.cnf.


signature.asc
Description: PGP signature

Bug#969115: [debian-mysql] Bug#969115: mysql-5.7: FTBFS with GCC 10: multiple definition of symbols

[Robie Basak]

tags 969115 + wontfix
thanks

Hi,

Thank you for the FTBFS report. As it happens src:mysql-5.7 has been
deprecated by src:mysql-8.0 and I filed a removal bug 969095 for
src:mysql-5.7. So it seems pointless to fix this now.

Robie

On Thu, Aug 27, 2020 at 09:48:21PM +0200, Aurelien Jarno wrote:
> Source: mysql-5.7
> Version: 5.7.26-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> mysql-5.7 fails to build from source with GCC 10:
> 
> | [ 42%] Linking CXX shared module innodb_engine.so
> | cd /<>/builddir/plugin/innodb_memcached/innodb_memcache && 
> /usr/bin/cmake -E cmake_link_script CMakeFiles/innodb_engine.dir/link.txt 
> --verbose=1
> | /usr/bin/x86_64-linux-gnu-g++ -fPIC -g -O2 
> -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security -fPIC -Wall -Wextra -Wformat-security -Wvla 
> -Wimplicit-fallthrough=2 -Woverloaded-virtual -Wno-unused-parameter -O3 -g 
> -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -std=gnu++03 
> -DDBUG_OFF -fPIC   -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro 
> -Wl,-z,now -shared  -o innodb_engine.so 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o 
> CMakeFiles/innodb_engine.dir/src/innodb_utility.c.o 
> CMakeFiles/innodb_engine.dir/src/hash_item_util.c.o 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o 
> CMakeFiles/innodb_engine.dir/src/innodb_api.c.o 
> CMakeFiles/innodb_engine.dir/src/embedded_default_engine.c.o 
> CMakeFiles/innodb_engine.dir/src/handler_api.cc.o 
> CMakeFiles/innodb_engine.dir/cache-src/assoc.c.o 
> CMakeFiles/innodb_engine.dir/cache-src/items.c.o 
> CMakeFiles/innodb_engine.dir/cache-src/slabs.c.o  -lpthread 
> ../../../archive_output_directory/libmysqlservices.a 
> ../../../archive_output_directory/liblibmcd_util.a -lpthread 
> | /usr/bin/ld: 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:432:
>  multiple definition of `ib_cb_cfg_trx_level'; 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:432:
>  first defined here
> | /usr/bin/ld: 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:436:
>  multiple definition of `ib_cb_cfg_bk_commit_interval'; 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:436:
>  first defined here
> | /usr/bin/ld: 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:414:
>  multiple definition of `ib_cb_trx_release'; 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:414:
>  first defined here
> | /usr/bin/ld: 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:398:
>  multiple definition of `ib_cb_tuple_delete'; 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:398:
>  first defined here
> | /usr/bin/ld: 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:435:
>  multiple definition of `ib_cb_trx_get_start_time'; 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:435:
>  first defined here
> | /usr/bin/ld: 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:413:
>  multiple definition of `ib_cb_trx_start'; 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:413:
>  first defined here
> | /usr/bin/ld: 
> CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:438:
>  multiple definition of `ib_cb_cursor_stmt_begin'; 
> CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:438:
>  first defined here
> | 

Bug#969095: RM: mysql-5.7 -- ROM; superseded by mysql-8.0

[Robie Basak]

Package: ftp.debian.org
Severity: normal

Binary movements:

libmysqld-dev is gone in src:mysql-8.0 - this feature is no longer
supported upstream. The other binary packages have direct replacements:

libmysqlclient20 -> libmysqlclient21
s/5.7/8.0/

There's also a new binary package mysql-router.

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#968854: [debian-mysql] Bug#968854: libmysqld-dev uninstallable in Debian Sid due to recent mysql-8.0 upload

[Robie Basak]

tags 968854 + moreinfo
thanks

libmysqld is no longer part of MySQL and so libmysql-dev is no longer a
binary source package produced by MySQL packaging. src:mysql-8.0 does
not produce libmysqld-dev. The libmysqld-dev package in unstable is left
over from src:mysql-5.7 which needs to be removed.

Why are you trying to install libmysqld-dev from unstable?


signature.asc
Description: PGP signature

Bug#968149: mysql-router-dbgsym,mysql-server-core-8.0-dbgsym: file conflict due to shared build-id

[Robie Basak]

Thank you for the report.

On Sun, Aug 09, 2020 at 09:48:13PM +0200, Andreas Beckmann wrote:
> This is likely caused by the corresponding binary packages shipping
> identical binaries (or librariesi, ...) with different names.

Looks like this is because this file is shipped in both mysql-router
and mysql-server-core:

/usr/lib/mysql/private/libprotobuf-lite.so.*
/usr/lib/mysql-router/libprotobuf-lite.so.*


signature.asc
Description: PGP signature

Bug#968356: transition: mysql-8.0

[Robie Basak]

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

Though this is a transition, I don't think it requires the usual
coordination with the release team because it won't entangle with
anything.

src:mysql-5.7 generates binary package libmysqlclient20 and is currently
in unstable. However, it is blocked from testing in favour of MariaDB by
order of the release team. Therefore libmysqlclient20 does not exist in
testing.

src:mysql-8.0 is ready in experimental and moves to libmysqlclient21.
I'd like to upload this to unstable.

Packages in unstable that need a MySQL client library build depend on
default-libmysqlclient-dev which sends them in MariaDB's direction. So
while this might be technically considered an unstable-only transition,
it should not affect testing.

The release team will presumably want to move the migration block on
src:mysql-5.7 to also include src:mysql-8.0.

Thanks,

Robie

Ben file:

title = "mysql-8.0";
is_affected = .depends ~ "libmysqlclient20" | .depends ~ "libmysqlclient21";
is_good = .depends ~ "libmysqlclient21";
is_bad = .depends ~ "libmysqlclient20";


signature.asc
Description: PGP signature

Bug#953259: Missing modules in build: regression since buster

[Robie Basak]

tags 953259 + patch
user ubuntu-de...@lists.ubuntu.com
usertag 953259 + ubuntu-patch
thanks

Looking at the previous build of 2.0.27, it looks like only three
extra modules are different with 3.4.0-2. The rest are being
automatically enabled by the configure script, when previously they were
explicitly enabled.

m_geo_maxmind.cpp: looks like this was previously m_geoip.cpp and
remains enabled.

m_regex_stdlib.cpp: this has regressed and is no longer enabled.

m_ldap.cpp: previously m_ldapauth.cpp and m_ldapoper.cpp, this has
regressed and is no longer enabled.

Presumably this is an accident - it seems that the only reason these
aren't being enabled automatically is that the new automatic detection
code has no implementation to detect the presence of the dependencies.

Here's the patch (with thanks to Joel Sing):

diff -Nru inspircd-3.4.0/debian/rules inspircd-3.4.0/debian/rules
--- inspircd-3.4.0/debian/rules 2019-12-24 04:20:19.0 + 
+++ inspircd-3.4.0/debian/rules 2020-03-02 15:18:36.0 + 
@@ -31,6 +31,8 @@
--example-dir=/usr/share/doc/inspircd/examples \ 
--data-dir=/var/run/inspircd \ 
--binary-dir=/usr/sbin
+   ./configure --disable-interactive \
+   --enable-extras=m_ldap.cpp,m_regex_stdlib.cpp
 
 override_dh_auto_build:
dh_auto_build -- INSPIRCD_VERBOSE=1 all


signature.asc
Description: PGP signature

Bug#953259: Missing modules in build: regression since buster

[Robie Basak]

Package: inspircd
Version: 3.4.0-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Hi,

I noticed that some modules such as m_ldapauth and m_ldapoper are
missing from the build, which is a regression from 2.0.27-1 in Buster.

AFAICT, the change was made in the packaging update to 3.2.0-1. But I
can't find any documentation to suggest that this change was
intentional.

Was the dropping of these modules deliberate, or is this a bug that can
be fixed by calling ./configure with --enable-extras as it was before?

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#943149: pam-mysql: Python2 removal in sid/bullseye

[Robie Basak]

tags 943149 + patch
thanks

Hi,

I understand that this is blocked in Debian by the marked bug. I have
fixed this in Ubuntu with the attached patch though, which I hope is
helpful when this bug is unblocked in Debian.

Robie
diff -Nru pam-mysql-0.8.1/debian/tests/auth pam-mysql-0.8.1/debian/tests/auth
--- pam-mysql-0.8.1/debian/tests/auth   2018-05-29 04:03:27.0 +
+++ pam-mysql-0.8.1/debian/tests/auth   2020-03-04 12:15:40.0 +
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 
 import PAM
 import subprocess
diff -Nru pam-mysql-0.8.1/debian/tests/control 
pam-mysql-0.8.1/debian/tests/control
--- pam-mysql-0.8.1/debian/tests/control2018-05-29 04:01:26.0 
+
+++ pam-mysql-0.8.1/debian/tests/control2020-03-04 11:53:21.0 
+
@@ -1,3 +1,3 @@
-Depends: default-mysql-server, libpam-mysql, python-pam
+Depends: default-mysql-server, libpam-mysql, python3-pam
 Restrictions: needs-root, isolation-container
 Tests: auth


signature.asc
Description: PGP signature

Bug#953030: bacula-sd.postinst fails on systems with protected_regular=2 enabled

[Robie Basak]

Hi,

On Tue, Mar 03, 2020 at 05:53:31PM +0100, Carsten Leonhardt wrote:
> thanks for the patch. I've commited a change to our git repository based
> on it. For consistency I changed the order in similar postinst files
> too.

Thank you! I grabbed your commit in Ubuntu to replace my patch.


signature.asc
Description: PGP signature

Bug#953030: bacula-sd.postinst fails on systems with protected_regular=2 enabled

[Robie Basak]

Package: bacula-sd
Version: 9.4.4-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

bacula-sd.postinst currently uses mktemp, chowns to bacula.bacula, and
then attempts to write to the temporary file using a shell redirection.

If a system has /proc/sys/fs/protected_regular set to 2, then this
fails[1].

While what is being done might be safe in this particular case, writing
to a file in /tmp not owned by the writing user is in principle unsafe,
and so it is blocked. In Ubuntu we are moving to protected_regular=2 and
so for us a build of this package becomes uninstallable[2].

Please consider applying the attached patch, which simply rearranges the
postinst to change file ownership after writing the file. This prevents
the protection from being tripped.

Thanks,

Robie

[1] https://www.kernel.org/doc/Documentation/sysctl/fs.txt
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040904.html
From 2efa5028139683bd851c76ab117cc47cf698e2b3 Mon Sep 17 00:00:00 2001
From: Robie Basak 
Date: Mon, 2 Mar 2020 20:19:27 +
Subject: [PATCH]   * d/bacula-sd.postinst: change temporary file ownership
 after writing to it to avoid a protected_regular=2 world-writeable sticky
 denial.

---
 debian/bacula-sd.postinst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/bacula-sd.postinst b/debian/bacula-sd.postinst
index 1ed67ff4..d3f83bb8 100644
--- a/debian/bacula-sd.postinst
+++ b/debian/bacula-sd.postinst
@@ -14,13 +14,13 @@ case "$1" in
 
 	# create new bacula-sd.conf using the template
 	TMP_CONFIG="$(mktemp -p /tmp $PKG_NAME.conf.ucftmp-XX)"
-	chmod 640 $TMP_CONFIG
-	chown bacula:bacula $TMP_CONFIG
 
 	sed -e s~@debian_basename@~`hostname`~ \
 	-e s~XXX_SDPASSWORD_XXX~$SDPASSWD~ \
 	-e s~XXX_MONSDPASSWORD_XXX~$SDMPASSWD~ \
 	$TEMPLATE > $TMP_CONFIG
+	chmod 640 $TMP_CONFIG
+	chown bacula:bacula $TMP_CONFIG
 	# let ucf handle the conffile and register it
 	ucf --debconf-ok --three-way $TMP_CONFIG $TARGET
 	ucfr $PKG_NAME $TARGET
-- 
2.25.0



signature.asc
Description: PGP signature

Bug#952744: MySQL tests fail

[Robie Basak]

Source: libdbi-drivers
Version: 0.9.0-8
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

I noticed that the test suite during the build is currently failing,
including on the Debian buildds, but this isn't causing the package
built to fail. Regardless, attached is the fix for the failures
themselves.
From ce4d5170dd8ebd179bfbb773b250667f15376e15 Mon Sep 17 00:00:00 2001
From: Robie Basak 
Date: Thu, 27 Feb 2020 15:49:16 +
Subject: [PATCH]   * d/p/test_mysql_date_tz.patch: fix MySQL test timezone
 inputs.

---
 debian/patches/series   |  1 +
 debian/patches/test_mysql_date_tz.patch | 36 +
 2 files changed, 37 insertions(+)
 create mode 100644 debian/patches/test_mysql_date_tz.patch

diff --git a/debian/patches/series b/debian/patches/series
index 975fbf4..b3fb76c 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ freetds-1.0-fix.patch
 pgsql_precision.patch
 mysql-8.0.patch
 test_exception_failure.patch
+test_mysql_date_tz.patch
diff --git a/debian/patches/test_mysql_date_tz.patch b/debian/patches/test_mysql_date_tz.patch
new file mode 100644
index 000..c50fcb5
--- /dev/null
+++ b/debian/patches/test_mysql_date_tz.patch
@@ -0,0 +1,36 @@
+Author: Robie Basak 
+Description: fix MySQL test timezone inputs
+ MySQL 8.0 requires the timezone field in a DATETIME input string to
+ have no leading spaces, and does not support a timezone field in the
+ TIME type. Adjust accordingly. The test input time is therefore
+ different as it is not offset by the timezone, so the expected output
+ is also adjusted to match.
+ .
+ It isn't clear if this also applies to older MySQL or MariaDB as the
+ previous test failures weren't failing the build.
+Last-Update: 2020-02-27
+
+--- a/tests/test_dbi.c
 b/tests/test_dbi.c
+@@ -253,7 +253,7 @@
+   {"the_binary_quoted_string", 4, 0, 6, 0, .expect_val.string_val = "", 0, ""}, /* string */
+   {"the_binary_escaped_string", 4, 0, 6, 0, .expect_val.string_val = "", 0, ""}, /* string */
+   {"the_datetime", 5, 3, 0, 0, .expect_val.uint_val = 1009843199, 1009843199, "2001-12-31 23:59:59"}, /* DBI_DATETIME_DATE|TIME */
+-  {"the_datetime_tz", 5, 3, 0, 0, .expect_val.uint_val = 1009843199, 1009843199, "2001-12-31 23:59:59"}, /* DBI_DATETIME_DATE|TIME */
++  {"the_datetime_tz", 5, 3, 0, 0, .expect_val.uint_val = 1009879199, 1009879199, "2001-12-31 23:59:59"}, /* DBI_DATETIME_DATE|TIME */
+   {"the_date", 5, 1, 0, 0, .expect_val.uint_val = 1009756800, 1009756800, "2001-12-31 00:00:00"}, /* DBI_DATETIME_DATE */
+   {"the_time", 5, 2, 0, 0, .expect_val.uint_val = 86399, 86399, "1970-01-01 23:59:59"}, /* DBI_DATETIME_TIME */
+   {"the_time_tz", 5, 2, 0, 0, .expect_val.uint_val = 86399, 86399, "1970-01-01 23:59:59"}, /* DBI_DATETIME_TIME */
+@@ -1567,10 +1567,10 @@
+ "'AB\\0C\\\'D',"
+ "'AB\\0C\\\'D',"
+ "'2001-12-31 23:59:59',"
+-"'2001-12-31 23:59:59 -10:00',"
++"'2001-12-31 23:59:59-10:00',"
+ "'2001-12-31',"
+ "'23:59:59',"
+-"'23:59:59-10:00')",
++"'23:59:59')",
+ numstring);
+}
+else if (!strcmp(ptr_cinfo->drivername, "pgsql")) {
-- 
2.25.0



signature.asc
Description: PGP signature

Bug#952743: Test suite failures don't fail the build

[Robie Basak]

Source: libdbi-drivers
Version: 0.9.0-8
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

I noticed that the test suite during the build is currently failing,
including on the Debian buildds, but this isn't causing the package
built to fail.

Patch attached.
From 7bb6ed96a6900a6178ca390a3d2ce99c7ca4cacc Mon Sep 17 00:00:00 2001
From: Robie Basak 
Date: Thu, 27 Feb 2020 15:48:31 +
Subject: [PATCH]   * d/p/test_exception_failure.patch: make test exceptions
 fail the test suite and thus the build.

---
 debian/patches/series   |  1 +
 debian/patches/test_exception_failure.patch | 28 +
 2 files changed, 29 insertions(+)
 create mode 100644 debian/patches/test_exception_failure.patch

diff --git a/debian/patches/series b/debian/patches/series
index ffca70f..975fbf4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,3 +7,4 @@ dbd_sqlite3_resolve_a_stack_buffer_overflow.patch
 freetds-1.0-fix.patch
 pgsql_precision.patch
 mysql-8.0.patch
+test_exception_failure.patch
diff --git a/debian/patches/test_exception_failure.patch b/debian/patches/test_exception_failure.patch
new file mode 100644
index 000..c871b95
--- /dev/null
+++ b/debian/patches/test_exception_failure.patch
@@ -0,0 +1,28 @@
+Author: Robie Basak 
+Description: make test exceptions fail the test suite and thus the build
+ Syntax-related issues in the MySQL tests were resulting in setup like INSERT
+ INTO to fail. This was resulting in a test exception rather than a failure,
+ causing the entire MySQL test suite to silently fail. This should instead cause
+ the build to fail, so patch the testsuite to treat exceptions as failures.
+Last-Update: 2020-02-27
+
+--- a/tests/cgreen/src/unit.c
 b/tests/cgreen/src/unit.c
+@@ -130,7 +130,7 @@
+ int run_test_suite(TestSuite *suite, TestReporter *reporter) {
+ 	setup_reporting(reporter);
+ 	run_every_test(suite, reporter);
+-	int success = (reporter->failures == 0);
++	int success = (reporter->failures == 0 && reporter->exceptions == 0);
+ 	clean_up_test_run(suite, reporter);
+ 	return success ? EXIT_SUCCESS : EXIT_FAILURE;
+ }
+@@ -138,7 +138,7 @@
+ int run_single_test(TestSuite *suite, char *name, TestReporter *reporter) {
+ 	setup_reporting(reporter);
+ 	run_named_test(suite, name, reporter);
+-	int success = (reporter->failures == 0);
++	int success = (reporter->failures == 0 && reporter->exceptions == 0);
+ 	clean_up_test_run(suite, reporter);
+ 	return success ? EXIT_SUCCESS : EXIT_FAILURE;
+ }
-- 
2.25.0



signature.asc
Description: PGP signature

Bug#952378: spamassassin: Example config needs a way of whitelisting GPG signed mail (EG from DDs)

[Robie Basak]

On Mon, Feb 24, 2020 at 01:56:59AM +1100, Russell Coker wrote:
> It would be good if the example configuration included a way of whitelisting
> mail from known good GPG keys.  An example configuration that would be useful
> in real use would be the Debian developer keylist.

I think this is a great idea. Debian developers already have a
bootstrapped trust mechanism and making use of it would make the spam
problem better for ourselves.

I have pondered implementing something like this and submitting it to
the spamassassin maintainer for many years, but never got round to it. I
thought of some additional complications though, which I hope will be
helpful to mention here in case others wish to implement it.

1) Someone who wants to attack this could attach a legitimate email PGP
signed by someone acceptable to the system to an otherwise illegitimate
email. To avoid this, the filter would have to somehow verify that the
entire email itself (and not just some of its contents) was constructed
wholly by the signatory. But PGP protects only email contents. I don't
know how to achieve this in a way that is easy for senders. Perhaps some
connection between DKIM and PGP would be required, but of course that
will be harder to achieve for senders.

2) (wishlist) it'd be nice if the filter could also use the web of trust
and also allow any senders who have been signed in to the web of trust.
This is harder of course, especially with the current SKS situation. But
this would allow: anyone who has been signed in to the web of trust to
immediately be able to get through to "Debian" mail servers without fear
of spam filters; and for the purposes of this filter, abusers and
abuser-supporters to have their PGP keys blacklisted, including for WoT
path finding, effectively preventing abuse through this channel.

Neither of these need to be addressed to make progress, but I thought it
important to point out at least the first caveat. It's not my intention
to pile on additional requirements. It'd be up to any implementor to
decide how important it is to care about this.


signature.asc
Description: PGP signature

Bug#951600: "debian/rules build" fails to call defined build-indep target, causing FTBFS

[Robie Basak]

Source: zoneminder
Version: 1.32.3-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Severity: serious
Justification: policy violation in behaviour of build target causing FTBFS
Tags: patch

Hi,

In Ubuntu this package FTBFS. The reason seems to be that the
build-indep target isn't running when sbuild invokes "debian/rules
build", causing a later dh_install against the zoneminder-doc package to
fail because files produced by that target don't exist.

As far as I understand, the cause is that debhelper's dh sequencer
doesn't itself call the build-indep target when invoked via
"debian/rules build". So when using debhelper, a "build-indep" rule
appears to be wrong, and override_dh_auto_build-indep needs to be used
to override the appropriate behaviour instead.

Here is the patch:

diff -Nru zoneminder-1.32.3/debian/rules zoneminder-1.32.3/debian/rules
--- zoneminder-1.32.3/debian/rules  2018-11-07 23:11:36.0 +
+++ zoneminder-1.32.3/debian/rules  2020-02-18 15:21:25.0 +
@@ -34,8 +34,9 @@
dh_clean $(MANPAGES1)
$(RM) -r docs/_build docs/installationguide web/api/app/Plugin/Crud
 
-build-indep:
+override_dh_auto_build-indep:
$(MAKE) -C docs html
+   dh_auto_build
 
 MANPAGES1 = \
 dbuild/scripts/zmupdate.pl.1\


signature.asc
Description: PGP signature

Bug#935042: Program phones home by default

[Robie Basak]

On Sun, Oct 13, 2019 at 11:02:45PM +0200, Birger Schacht wrote:
> The problem is that the package will be removed from unstable in a
> couple of days because of this bug report. 3 month is sometimes not that
> much time to fix a bug or even comment on a bug report. And the release
> of bullseye is not even in sight. I or someone else could do an NMU, but
> the package will be removed from the archive before that can happen.

It sounds like you would like to change Debian's process for handling
serious bugs then, rather than having any particular issue with this bug
specifically? That might be a discussion better had on the debian-devel@
list.


signature.asc
Description: PGP signature

Bug#935042: Program phones home by default

[Robie Basak]

On Sun, Oct 13, 2019 at 05:23:40PM +0200, Birger Schacht wrote:
> Robie, could you please point out the part of the Debian policy that
> this package is violating?

I cannot. I believe that this issue is such a clear violation of
Debian's philosophy that it has never been necessary to document it
formally as policy.

However you seem to have missed out the latter part of the definition of
"serious" in your quote. Here's the full definition:

serious is a severe violation of Debian policy (roughly, it
violates a "must" or "required" directive), or, in the package
maintainer's or release manager's opinion, makes the package
unsuitable for release.

I think it's quite clear that this issue makes the package unsuitable
for release. If the package maintainer disagrees and thinks that it's OK
to release Debian with this bug outstanding, they may change it.

Are you suggesting that "serious" is not justified? Nobody seems to have
doubted that so far. If the package maintainer wants to reduce the
severity of this bug by relying on policy not mentioning this type of
matter, then I'm fairly confident that this will result in policy being
amended in the end anyway.


signature.asc
Description: PGP signature

Bug#941986: [debian-mysql] Bug#941986: mariadb-client-10.3: InnoTop crashes during use

[Robie Basak]

On Tue, Oct 08, 2019 at 11:31:14AM -0400, Michael Krieger wrote:
> This is because technically 10.3 is not officially supported by innotop, and 
> so it uses old legacy code which returns incorrect results.
> 
> While innotop doesn't get support 10.3, us shipping innotop with MariaDB 10.3 
> means it should really work with it.  It is substantially close to 10.1/10.2 
> to include it in the ways that works as opposed to using outdated code meant 
> for older versions of MySQL.
> 
> Ideally, innotop should be updated to include official 10.3 support.  Until 
> the developer does that, this will at least make innotop usable on Debian 
> Buster 10.

FWIW, we removed innotop from "the other side" in the MySQL packaging.
We faced similar breakages, and it seemed wrong to ship innotop inside
the MySQL packaging as it's a separate upstream that comes from a
different upstream organisation and breakages like this don't seem
infrequent.

IMHO, if we ship it at all, innotop should be shipped as a separate
Debian source package with appropriate declared dependencies and
autopkgtests. This current breakage might be an opportunity to fix that.

This would also permit people who care about innotop to become nominated
maintainers and they would then be able to look after its compatibility
against MySQL/MariaDB in the same way that Debian handles transitions
for other reverse dependencies, with all the usual tooling, process and
reporting, which might make everything run smoother.

I don't intend for this comment to block any particular approach though
- I'm just offering what I hope is a useful perspective.


signature.asc
Description: PGP signature

Bug#935042: your mail

[Robie Basak]

On Mon, Sep 30, 2019 at 12:39:33PM +0200, Michael Boelen wrote:
> Although I can understand the sentiment of disabling "phoning home"
> functionality, it is there with a good reason. It helps people to learn
> when their software is (very) outdated, especially when it comes to doing a
> security audit. Using old software to perform an audit has its own risks.

I understand that this is born out of good intentions. However, consider
that Debian users understand that the mechanism for getting software
updated, and checking for updates, is "apt-get". They _want_ a unified
way of doing this: that's why they're using a distribution, and why they
installed lynis from the distribution archive! There are mechanisms to
notify users of software needing an update via apt, and better still,
it's unified. And if a Debian user is using an older Debian release,
they have deliberately chosen that path, or at least are generally aware
of it.

Consider what would happen if every piece of software in Debian followed
this same behaviour.

I understand that you consider lynis to be special, but so might many
other upstream maintainers of similarly sensitive software, so we'd end
up in the same undesirable situation.

Instead, if there are specific issues with the lynis package in existing
Debian releases, please file those separately, and the maintainer will
be able to fix them according to Debian's stable update and security
policies - thus giving Debian users the unified release management they
expect. You could also ship newer lynis releases into the Debian
backports repository for users who wish to opt-in.

> Hope this helps at least with improving the Debian package,

Thank you for helping out in Debian!

Robie

[1] https://wiki.debian.org/ReproducibleBuilds


signature.asc
Description: PGP signature

Bug#935042: Program phones home by default

[Robie Basak]

Package: lynis
Version: 2.6.2-1
Severity: serious
Justification: privacy leak

By default, this program appears to make a DNS query to
lynis-latest-version.cisofy.com. thus leaking information about the
system and the fact that the user is running an audit. This is
particularly egregious in the case of a security audit tool, as it
reveals to observers that the sysadmin performing the audit may be
concerned about the system's security. Note that this information is
being revealed both to whoever controls "cisofy.com" and also to any
network observers as DNS queries are still typically unencrypted.

I believe that Debian has held the long standing philosophy that this
kind of privacy leak must not be permitted by default. Debian users
generally assume that the package maintainer has taken care of this kind
of thing, and that it is safe to assume that there is no information
being exfiltrated from the system without the user's explicit
permission.

Please patch the default configuration so that there is no privacy leak.

If this issue affects existing stable releases, I suggest that a stable
update is also necessary, or perhaps even a security update.


signature.asc
Description: PGP signature

Bug#925463: pytest: Please provide a pytest binary for Python 3.x

[Robie Basak]

[I'm not the maintainer; just driving by]

On Mon, Mar 25, 2019 at 01:14:34PM +, Joel Cross wrote:
> I noticed today that while the python3-pytest package works fine when invoked
> as `python3 -m pytest`, it does not provide a binary, and the only binary
> provided is as part of the `python-pytest` package which is built on Python 2.

python3-pytest provides /usr/bin/pytest-3 and /usr/bin/py.test-3, does
it now? I've been using these for years:

https://packages.debian.org/sid/all/python3-pytest/filelist


signature.asc
Description: PGP signature

Bug#931804: python3-trustme: Key size too small

[Robie Basak]

Hi Matthias,

On Wed, Jul 10, 2019 at 05:42:03PM +0200, Matthias Urlichs wrote:
> Package: python3-trustme
> Version: 0.4.0-3
> Severity: important
> Tags: patch
> 
> Debian changed the default key size requirement to 2048 bits, thus keys
> generated with trustme no longer work.

I don't understand. You seem to be reporting the same problem as bug
926652 and including the exact patch I already uploaded as 0.4.0-3 to
fix it, which is the very version you are reporting affected.

Please could you explain how this is a bug in python3-trustme 0.4.0-3?


signature.asc
Description: PGP signature

Bug#927118: unblock: python-trustme/0.4.0-3

[Robie Basak]

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

Please unblock package python-trustme

This fixes a second FTBFS, further to the previous unblock request in
bug 925576. This time the build failed on the buildds but not in my
local testing because openssl was installed there, which (correctly)
isn't a build dependency.

The fix is to generate larger keys. The same change has now been
accepted by upstream.

diff -Nru python-trustme-0.4.0/debian/changelog 
python-trustme-0.4.0/debian/changelog
--- python-trustme-0.4.0/debian/changelog   2018-10-13 22:48:59.0 
+0100
+++ python-trustme-0.4.0/debian/changelog   2019-04-13 17:30:43.0 
+0100
@@ -1,3 +1,19 @@
+python-trustme (0.4.0-3) unstable; urgency=medium
+
+  * d/p/keysize: bump test key sizes to 2048 to fulfil Debian's new default
+requirement. This fixes another FTBFS due to test failure in the case that
+the openssl binary package is installed, which is not a build dependency,
+but apparently the buildds have it by default. Closes: #926652.
+
+ -- Robie Basak   Sat, 13 Apr 2019 17:30:20 +0100
+
+python-trustme (0.4.0-2) unstable; urgency=medium
+
+  * Explicitly build-depend on python3-idna to fix FTBFS.
+Closes: #925566.
+
+ -- Robie Basak   Tue, 26 Mar 2019 23:22:42 +
+
 python-trustme (0.4.0-1) unstable; urgency=low
 
   * Initial release. Closes: #910951.
diff -Nru python-trustme-0.4.0/debian/control 
python-trustme-0.4.0/debian/control
--- python-trustme-0.4.0/debian/control 2018-10-13 22:48:59.0 +0100
+++ python-trustme-0.4.0/debian/control 2019-04-13 17:22:21.0 +0100
@@ -6,6 +6,7 @@
 Build-Depends: debhelper (>= 9~),
dh-python,
python3,
+   python3-idna,
python3-openssl,
python3-pytest,
python3-service-identity,
diff -Nru python-trustme-0.4.0/debian/patches/keysize 
python-trustme-0.4.0/debian/patches/keysize
--- python-trustme-0.4.0/debian/patches/keysize 1970-01-01 01:00:00.0 
+0100
+++ python-trustme-0.4.0/debian/patches/keysize 2019-04-13 17:26:01.0 
+0100
@@ -0,0 +1,33 @@
+From 96b8799325fa0f53fad4db529cbd2d25af42ebff Mon Sep 17 00:00:00 2001
+From: Robie Basak 
+Date: Sat, 13 Apr 2019 17:02:53 +0100
+Subject: [PATCH] Increase key size to 2048 bits
+
+Debian changed the default security level to 2 since openssl package
+version 1.1.1~~pre9-1 (August 2018), which requires a minimum key size
+of 2048 bit or larger RSA and DHE keys. To avoid test failures on newer
+Debian systems against OpenSSL, use a key size of at least 2048 bits.
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926652
+Forwarded: https://github.com/python-trio/trustme/pull/45
+Last-Update: 2019-04-13
+---
+ trustme/__init__.py | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/trustme/__init__.py
 b/trustme/__init__.py
+@@ -33,7 +33,12 @@
+ # On my laptop, making a CA + server certificate using 1024 bit keys takes ~40
+ # ms, and using 4096 bit keys takes ~2 seconds. We want tests to run in 40 ms,
+ # not 2 seconds.
+-_KEY_SIZE = 1024
++#
++# However, Debian changed the default security level to 2 in openssl
++# 1.1.1~~pre9-1 (August 2018), which requires a minimum key size of 2048 bit 
or
++# larger for RSA and DHE keys. To avoid test failures on newer Debian systems
++# against OpenSSL, we must therefore use a key size of at least 2048 bits.
++_KEY_SIZE = 2048
+ 
+ def _name(name):
+ return x509.Name([
diff -Nru python-trustme-0.4.0/debian/patches/series 
python-trustme-0.4.0/debian/patches/series
--- python-trustme-0.4.0/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ python-trustme-0.4.0/debian/patches/series  2019-04-13 17:25:34.0 
+0100
@@ -0,0 +1 @@
+keysize

unblock python-trustme/0.4.0-3


signature.asc
Description: PGP signature

Bug#926652: python-trustme: FTBFS on all

[Robie Basak]

Here's a debdiff, which I'll upload unless upstream point out any
problems with it.
diff -Nru python-trustme-0.4.0/debian/changelog 
python-trustme-0.4.0/debian/changelog
--- python-trustme-0.4.0/debian/changelog   2019-03-26 23:23:50.0 
+
+++ python-trustme-0.4.0/debian/changelog   2019-04-13 17:30:43.0 
+0100
@@ -1,3 +1,12 @@
+python-trustme (0.4.0-3) unstable; urgency=medium
+
+  * d/p/keysize: bump test key sizes to 2048 to fulfil Debian's new default
+requirement. This fixes another FTBFS due to test failure in the case that
+the openssl binary package is installed, which is not a build dependency,
+but apparently the buildds have it by default. Closes: #926652.
+
+ -- Robie Basak   Sat, 13 Apr 2019 17:30:20 +0100
+
 python-trustme (0.4.0-2) unstable; urgency=medium
 
   * Explicitly build-depend on python3-idna to fix FTBFS.
diff -Nru python-trustme-0.4.0/debian/patches/keysize 
python-trustme-0.4.0/debian/patches/keysize
--- python-trustme-0.4.0/debian/patches/keysize 1970-01-01 01:00:00.0 
+0100
+++ python-trustme-0.4.0/debian/patches/keysize 2019-04-13 17:26:01.0 
+0100
@@ -0,0 +1,33 @@
+From 96b8799325fa0f53fad4db529cbd2d25af42ebff Mon Sep 17 00:00:00 2001
+From: Robie Basak 
+Date: Sat, 13 Apr 2019 17:02:53 +0100
+Subject: [PATCH] Increase key size to 2048 bits
+
+Debian changed the default security level to 2 since openssl package
+version 1.1.1~~pre9-1 (August 2018), which requires a minimum key size
+of 2048 bit or larger RSA and DHE keys. To avoid test failures on newer
+Debian systems against OpenSSL, use a key size of at least 2048 bits.
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926652
+Forwarded: https://github.com/python-trio/trustme/pull/45
+Last-Update: 2019-04-13
+---
+ trustme/__init__.py | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/trustme/__init__.py
 b/trustme/__init__.py
+@@ -33,7 +33,12 @@
+ # On my laptop, making a CA + server certificate using 1024 bit keys takes ~40
+ # ms, and using 4096 bit keys takes ~2 seconds. We want tests to run in 40 ms,
+ # not 2 seconds.
+-_KEY_SIZE = 1024
++#
++# However, Debian changed the default security level to 2 in openssl
++# 1.1.1~~pre9-1 (August 2018), which requires a minimum key size of 2048 bit 
or
++# larger for RSA and DHE keys. To avoid test failures on newer Debian systems
++# against OpenSSL, we must therefore use a key size of at least 2048 bits.
++_KEY_SIZE = 2048
+ 
+ def _name(name):
+ return x509.Name([
diff -Nru python-trustme-0.4.0/debian/patches/series 
python-trustme-0.4.0/debian/patches/series
--- python-trustme-0.4.0/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ python-trustme-0.4.0/debian/patches/series  2019-04-13 17:25:34.0 
+0100
@@ -0,0 +1 @@
+keysize


signature.asc
Description: PGP signature

Bug#926652: python-trustme: FTBFS on all

[Robie Basak]

On Mon, Apr 08, 2019 at 01:38:04PM +, Ivo De Decker wrote:
> The latest version of python-trustme in unstable fails on all:

See also bug 925576. I haven't got round to looking at it yet. I hope to
investigate and fix it soon; patches also welcome.


signature.asc
Description: PGP signature

Bug#925576: unblock: python-trustme/0.4.0-2

[Robie Basak]

Hi Paul,

On Sun, Mar 31, 2019 at 10:40:38AM +0200, Paul Gevers wrote:
> The fix doesn't prevent the package from FTBFS. Please check
> https://buildd.debian.org/status/fetch.php?pkg=python-trustme=all=0.4.0-2=1553646768=0

Thanks. I only spotted that after you approved the unblock request. It
did build in sbuild for me locally (after fixing the Build-Depends as
changed in -2), so it must be some difference wrt. the buildds. I will
investigate.


signature.asc
Description: PGP signature

Bug#925576: unblock: python-trustme/0.4.0-2

[Robie Basak]

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

Please unblock package python-trustme

This fixes an FTBFS. The package previously built fine, pulling in
python3-idna implicitly via python3-cryptography via python3-openssl.
Since then, python3-cryptography stopped depending on python3-idna,
exposing the bug that python-trustme's build does actually depend on
python3-idna but this wasn't explicitly declared. This change declares
explicitly what was being pulled in previously, so shouldn't in itself
cause any functional change; only the FTBFS will be fixed (along with
the usual regression risk associated with a rebuild).

diff -Nru python-trustme-0.4.0/debian/changelog 
python-trustme-0.4.0/debian/changelog
--- python-trustme-0.4.0/debian/changelog   2018-10-13 22:48:59.0 
+0100
+++ python-trustme-0.4.0/debian/changelog   2019-03-26 23:23:50.0 
+
@@ -1,3 +1,10 @@
+python-trustme (0.4.0-2) unstable; urgency=medium
+
+  * Explicitly build-depend on python3-idna to fix FTBFS.
+Closes: #925566.
+
+ -- Robie Basak   Tue, 26 Mar 2019 23:22:42 +
+
 python-trustme (0.4.0-1) unstable; urgency=low
 
   * Initial release. Closes: #910951.
diff -Nru python-trustme-0.4.0/debian/control 
python-trustme-0.4.0/debian/control
--- python-trustme-0.4.0/debian/control 2018-10-13 22:48:59.0 +0100
+++ python-trustme-0.4.0/debian/control 2019-03-26 23:21:57.0 +
@@ -6,6 +6,7 @@
 Build-Depends: debhelper (>= 9~),
dh-python,
python3,
+   python3-idna,
python3-openssl,
python3-pytest,
python3-service-identity,

unblock python-trustme/0.4.0-2


signature.asc
Description: PGP signature

Bug#925566: python-trustme: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Robie Basak]

On Tue, Mar 26, 2019 at 09:49:00PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in buster (in a buster chroot, not a
> sid chroot), your package failed to build on amd64.

Thank you for this report.

It looks like python-trustme (build time) tests uses the idna directly,
so an explicit Build-Depends on python3-idna would be correct.

Previously the build worked because python3-openssl happened to depend
on python3-cryptography which happened to depend on python3-idna.
However python3-cryptography no longer depends on python3-idna,
triggering this latent bug.


signature.asc
Description: PGP signature

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Robie Basak]

On Tue, Mar 19, 2019 at 10:49:06AM +0100, Christoph Berg wrote:
> Re: Robie Basak 2019-03-18 <20190318165800.gc12...@mal.justgohome.co.uk>
> > It is well understood that the OpenSSL license is not "compatible" with
> > the GPL (either version 2 or 3); and furthermore, Debian has long taken
> > the position that, unless a license exception is granted by the
> > copyright holders, a package which is distributed under the GPL must
> > only link to libraries whose licenses are also GPL-compatible in order
> > for it to be included in Debian.
> 
> How is that a problem in libpq5, and not in the other packages?

libpq5 seemed like a reasonable place to file this bug in the first
instance. I don't intend to dictate how or where this must be resolved.

To help put this into perpspective:

There are 140 source packages that build a binary that depends on
libpq5.

84 of these mention GPL in debian/copyright, but apparently have no
linking exception (heuristically and not checked but this is hopefully
enough for an indication).

Of these 84, based on my glance at their debian/copyright files
manually, and without deeper investigation:

  * 12[1] appear to be GPL-2 only, so are affected today and will
continue to be affected in the upcoming OpenSSL upstream
relicensing.

  * 27[2] look like they're GPL-2+, GPL-3 or GPL-3+, so are affected
today but can be expected to become compatible in the future with a
newer release of OpenSSL upstream. However this does not help for
buster.

So that's at least approximately 39 of 140 reverse dependencies that
appear affected based on a quick glance through. I've been fairly
conservative in my superficial analysis - I skipped reverse dependencies
where I couldn't see any compatibility problem from a quick glance.

[1] bandwidthd-pgsql dballe inspircd libnss-pgsql2 libodb-pgsql-2.4
pmacct r-cran-rpostgresql saga sphinxsearch tora ulogd2-pgsql
yubikey-server-c

[2] clisp cvm cyphesis-cpp gammu gnokii gnu-smalltalk gnunet grass
libpg-perl libpreludedb motion newlisp osm2pgrouting osm2pgsql pam-pgsql
libzdb perdition pgmodeler postgis pspp pvpgn qgis repmgr sqlsmith
sysbench w1retap zabbix


signature.asc
Description: PGP signature

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Robie Basak]

Package: libpq5
Version: 11.2-2
Severity: serious
Affects: bandwidthd-pgsql dballe inspircd libnss-pgsql2 libodb-pgsql-2.4 pmacct 
r-cran-rpostgresql saga sphinxsearch tora ulogd2-pgsql yubikey-server-c
Justification: renders many Debian packages undistributable

Hello,

It's come to my attention that in buster and unstable, packages which
build-depend on libpq-dev wind up linked against libpq5, which in turn
links against OpenSSL (libssl1.1).

This includes software which is licensed under the GPL and uses the
PostgreSQL APIs.

It is well understood that the OpenSSL license is not "compatible" with
the GPL (either version 2 or 3); and furthermore, Debian has long taken
the position that, unless a license exception is granted by the
copyright holders, a package which is distributed under the GPL must
only link to libraries whose licenses are also GPL-compatible in order
for it to be included in Debian.

I am opening this as a serious bug, since I believe this makes a large
and indeterminate number of packages non-distributable in buster.

See also bug 921488 which was the same situation but with MariaDB.

Based on a quick glance through the debian/copyright files of reverse
dependencies, I found the following packages that appear to generally be
licensed GPL-2 (only) for example and list no OpenSSL linking exception.
If I've accurately understood which licence applies in these cases, this
situation certainly cannot be resolved even with the upcoming OpenSSL
upstream relicense to Apache-2.0. Note that this is an indicative
non-exhaustive list only, based on some approximations and only sampling
to check accuracy; I haven't verified each one in detail.

bandwidthd-pgsql
dballe
inspircd
libnss-pgsql2
libodb-pgsql-2.4
pmacct
r-cran-rpostgresql
saga
sphinxsearch
tora
ulogd2-pgsql
yubikey-server-c

There are many more reverse dependencies licensed with GPL-2+, GPL-3,
etc, which suffer this redistributability until the relicensed OpenSSL
arrives in Debian.

Thanks,



signature.asc
Description: PGP signature

Bug#921687: [debian-mysql] Bug#921687: systemctl just hangs on stoping or starting mysql-server-5.7

[Robie Basak]

Hi,

Could this be the issue described here:
https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1600164 ?

Apart from that, I don't know of anyone else affected by this, so I
don't think we can treat it as a bug in the mysql-server-5.7 package
without further details of why it must be a bug or having steps to
reproduce the issue.

Robie


signature.asc
Description: PGP signature

Bug#921423: /var/log/letsencrypt gets wiped on transitional package purge

[Robie Basak]

Package: letsencrypt
Version: 0.28.0-1
Severity: grave
Justification: causes data loss
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco

Steps to reproduce:

1. Start on sid
2. apt install letsencrypt  # using transitional package
3. Use letsencrypt or certbot
4. Later, note the project rename and start using the certbot name
5. Note the package description says that the letsencrypt binary package
can be removed, and purge it.
6. Look for previous logs

Expected: logs still exist back to the beginning, or at least since step
4.

Actual: logs are gone.

Real use case: users upgrading through the regular upgrade path will,
upon purging old transitional packages, lose their logs.

Suspected cause: letsencrypt.postrm removes /var/log/letsencrypt.

Suggested fix: drop the "rm -rf /var/log/letsencrypt" from
letsencrypt.postrm (which makes the postrm redundant so the entire file
can be removed).


signature.asc
Description: PGP signature

Bug#914172: [debian-mysql] Bug#914172: Bug#914172: Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & ma

[Robie Basak]

On Thu, Nov 22, 2018 at 10:44:42AM +0100, David Escala wrote:
> Perhaps we should change the apt dist-upgrade command for security updates
> (suggestions?), but
> not adding new dependencies in a security update may also be a good policy.

You should use apt pinning to restrict package upgrades to security
updates only. See what the unattended-upgrades package does for an
example. Removing apt's visibility of stuff that it already has
installed on the system is a hack that will lead to the problem you've
discovered.

I'm interested for someone to confirm that pinning will solve this
problem correctly in this particular case. I believe that it will but am
not certain.

I don't know about Debian's policies in adding dependencies to security
updates. Clearly it is to be avoided, but there might be some situations
when it is necessary for security purposes. Therefore, I'm not sure that
this should be considered a bug at all from mariadb packaging's point of
view, unless there is some other reason that the dependency addition
should not have gone in.


signature.asc
Description: PGP signature

Bug#895458: [debian-mysql] Status of debconf translation handling in mysql-5.7, help needed?

[Robie Basak]

Hi Helge,

On Wed, Nov 14, 2018 at 01:34:45PM +0100, Helge Kreutzmann wrote:
> your package mysql-5.7 has several unhandled debcon
> translations, some of then available for several month. I see that
> several uplaods have been made, is there a reason for not including
> those translations? Do you need help handling?

Thank you for the prompt. I'm preparing an upload now.

Robie


signature.asc
Description: PGP signature

Bug#893740: scons: diff for NMU version 3.0.1-1.1

[Robie Basak]

On Fri, Nov 09, 2018 at 03:08:27PM +, Robie Basak wrote:
> I've prepared an NMU for scons (versioned as 3.0.1-1.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer, or upload it some other way.

Thank you for the upload. I've cancelled my NMU.

Robie


signature.asc
Description: PGP signature

Bug#913424: trio does not have a stable API

[Robie Basak]

Source: python-trio
Version: 0.9.0-1
Severity: serious
Forwarded: https://github.com/python-trio/trio/issues/1

Trio upstream do not yet consider the API stable, so in my opinion this
package is not yet ready for a stable Debian release.

Please use this bug for discussion if you think this status should
change.


signature.asc
Description: PGP signature

Bug#893740: scons: diff for NMU version 3.0.1-1.1

[Robie Basak]

Control: tags 893740 + pending

Dear maintainer,

I've prepared an NMU for scons (versioned as 3.0.1-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer, or upload it some other way.

Robie
diff -Nru scons-3.0.1/debian/changelog scons-3.0.1/debian/changelog
--- scons-3.0.1/debian/changelog	2017-12-14 14:57:20.0 +
+++ scons-3.0.1/debian/changelog	2018-11-09 14:46:34.0 +
@@ -1,3 +1,11 @@
+scons (3.0.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * patches/0110-remove_stale_files.patch: fix Python 3 compatibility (Closes:
+#893740).
+
+ -- Robie Basak   Fri, 09 Nov 2018 14:45:13 +
+
 scons (3.0.1-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru scons-3.0.1/debian/patches/0110-remove_stale_files.patch scons-3.0.1/debian/patches/0110-remove_stale_files.patch
--- scons-3.0.1/debian/patches/0110-remove_stale_files.patch	2017-10-03 05:25:00.0 +0100
+++ scons-3.0.1/debian/patches/0110-remove_stale_files.patch	2018-11-09 14:48:52.0 +
@@ -2,18 +2,17 @@
 Origin: Debian
 Bug-Debian: http://bugs.debian.org/519948
 Forwarded:  http://scons.tigris.org/issues/show_bug.cgi?id=1571
+Last-Update:2018-11-09
 
-Index: trunk/engine/SCons/Script/Main.py
-===
 trunk.orig/engine/SCons/Script/Main.py
-+++ trunk/engine/SCons/Script/Main.py
-@@ -1106,6 +1106,21 @@ def _main(parser):
+--- a/engine/SCons/Script/Main.py
 b/engine/SCons/Script/Main.py
+@@ -1106,6 +1106,21 @@
  print('Found nothing to build')
  exit_status = 2
  
 +# Remove temporary files left by SCons
 +if options.clean:
-+if os.environ.has_key('DH_INTERNAL_OPTIONS'):
++if 'DH_INTERNAL_OPTIONS' in os.environ:
 +import shutil
 +for path in ('.sconsign.dblite', '.sconf_temp'):
 +try:


signature.asc
Description: PGP signature

Bug#900296: ITP: trio -- Async/await-native Python3 I/O library for humans and snake people

[Robie Basak]

On Sat, Oct 13, 2018 at 09:03:47PM +0200, Matthias Urlichs wrote:
> On 13.10.18 17:43, Robie Basak wrote:
> > Any news on this? If not, any objection to me taking over this ITP?
> 
> Go for it. You'll have to package a couple of small dependencies first
> (sniffio, outcome).

On it already. Thanks!

> I'm not too busy to be co-maintainer. ;-)

I intend to put the packages into DPMT for team maintenance, though I
need to join the DPMT first and get the package into compliance with
their policies, so I'll just upload to unstable first to get there
incrementally.

Robie


signature.asc
Description: PGP signature

Bug#910960: ITP: python-outcome -- capture the outcome of Python function calls

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-outcome
  Version : 1.0.0-1
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/outcome
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : capture the outcome of Python function calls

 Outcome provides a function `capture' for capturing the outcome of a Python
 function call, so that it can be passed around - even if the function raises
 an exception. It also provides the async equivalent function `acapture'.

This is a dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#910956: ITP: python-sniffio -- detect which async Python library is in use

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-sniffio
  Version : 1.0.0-1
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/sniffio
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : detect which async Python library is in use

 Python libraries that support multiple async packages (like Trio, asyncio,
 etc) need to know which is in use. This library provides this information.

This is a dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#910951: ITP: python-trustme -- fake certificate authority for test use

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-trustme
  Version : 0.4.0
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/trustme
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : fake certificate authority for test use

 trustme is a tiny Python package that gives you a fake certificate authority
 (CA) that you can use to generate fake TLS certificates to use in tests. Its
 only useful purpose is as a dependency of test suites.

This is a (test) dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#903917: Acknowledgement (libsss-sudo.postinst clobbers local change to /etc/nsswitch.conf)

[Robie Basak]

I wonder if "dpkg -P libsss-sudo" is a reasonable workaround. Are there
any cases where libsss-sudo needs to be installed but not active in
nsswitch.conf?


signature.asc
Description: PGP signature

Bug#903917: libsss-sudo.postinst clobbers local change to /etc/nsswitch.conf

[Robie Basak]

Package: libsss-sudo
Version: 1.16.2-1
Severity: serious
Justification: policy violation (section 10.7.3)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic

Steps to reproduce:

1. apt install sssd
2. Edit /etc/nsswitch.conf and remove "sss" from the "sudoers" entry
3. apt install --reinstall libsss-sudo

Expected behaviour:

"sss" remains not present in /etc/nsswitch.conf (ie. the local change is
preserved).

Actual behaviour:

"sss" is re-added to nsswitch.conf.

I have verified this behaviour in a Debian sid container today.

Policy violation:

This breaks "local changes must be preserved during a package upgrade"
from policy section 10.7.3.

Suggested fix:

Make the change only on fresh install of the package, rather than on
upgrade.

Additional information:

You might be interested to know that the reason users are hitting this
is that they are trying to work around a different bug that is reported
downstream here:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1249777. But the
workaround gets removed on upgrade.

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#902603: /var/log/iptraf not created by default

[Robie Basak]

Package: iptraf-ng
Version: 1:1.1.4-6
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic

The iptraf-ng package arranges to logrotate in /var/log/iptraf. The
iptraf-ng -L option logs to /var/log/iptraf by default. Since the
packaging doesn't currently create /var/log/iptraf, this means that the
-L option fails by default.

Please either create /var/log/iptraf automatically, or have iptraf-ng -L
log to somewhere else (the current directory?) by default. IMHO, the
latter option is what users would expect as most commands operate in the
current directory by default and this makes sense for interactive
execution. But you may want to convince upstream of that first.

Downstream bug:
https://bugs.launchpad.net/ubuntu/+source/iptraf-ng/+bug/1778959

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#902601: freshclam apparmor profile prevents some operations

[Robie Basak]

Package: clamav-freshclam
Version: 0.100.0+dfsg-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Hi,

We've received a downstream report of the following AppArmor denial:

Jun 26 16:31:12 localhost kernel: [21690.397358] audit: type=1400 
audit(1530048672.329:116): apparmor="DENIED" operation="rename_src" 
profile="/usr/bin/freshclam" name="/var/log/clamav/freshclam.log" pid=2604 
comm="freshclam" requested_mask="r" denied_mask="r" fsuid=121 ouid=121

The suggestion is to change, in debian/usr.bin.freshclam:

  /var/log/clamav/* kw,

to:

  /var/log/clamav/* krw,

Downstream bug:
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1778812

Upstream discussion:
https://lists.ubuntu.com/archives/apparmor/2018-June/011711.html

Here's the patch:

diff --git a/debian/usr.bin.freshclam b/debian/usr.bin.freshclam
index de970a4..90490ac 100644
--- a/debian/usr.bin.freshclam
+++ b/debian/usr.bin.freshclam
@@ -32,7 +32,7 @@
   /var/lib/clamav/ r,
   /var/lib/clamav/** krw,
 
-  /var/log/clamav/* kw,
+  /var/log/clamav/* krw,
   /{,var/}run/clamav/freshclam.pid w,
   /{,var/}run/clamav/clamd.ctl rw,

I haven't verified this, but it seems trivial and reasonable enough that
I think it should be fine just to land.

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#865931: [debian-mysql] Bug#865931: Dealing with new packaging policy

[Robie Basak]

On Fri, Jun 15, 2018 at 04:42:20PM +0200, Narcis Garcia wrote:
> Applications and CMS ask user for username to create their
> databases and dedicated accounts. This is not solved with unattended
> install of MariaDB server because those programs don't use "sudo", and
> new Debian packaging policy seems only friendly with terminal-based
> configuration.
> 
> Take into account that previous behaviour of MySQL server packages was
> incompatible with unattended installs, because of the use of whiptail to
> ask for "root" password.

This is incorrect. MySQL and MariaDB packaging correctly integrates with
debconf. If you don't know how to use debconf to achieve unattended
installs, then please read up the documentation on that. If there's a
bug in the implementation which causes it not to work, then please file
a full bug report on that.

If you need to set up MySQL or MariaDB to permit a non-privileged user
to access the database, then you can use sudo (or equivalent) to set
that up, just like anything else on a Debian system. You can certainly
script that for unattended installation, too.


signature.asc
Description: PGP signature

Bug#899959: bind9: Invalid maintainer address pkg-dns-de...@lists.alioth.debian.org

[Robie Basak]

Fix proposed in:

https://salsa.debian.org/dns-team/bind9/merge_requests/3


signature.asc
Description: PGP signature

Bug#898161: dh_missing(1) manpage contradicts itself on default behaviour

[Robie Basak]

Package: debhelper
Version: 11.2.1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic
X-Debbugs-Cc: ni...@thykier.net

dh_missing(1) says:

"Please note that without either of these options, dh_missing will
silently do nothing."

However, it later says that --list-missing "is the default in compat 12
and later".

These statements cannot both be true.

Looks like this was an oversight in commit 8c69e49, and is still present
in current git master (67356ae).


signature.asc
Description: PGP signature

Bug#898148: [debian-mysql] Bug#898148: mysql-server: it does not allow me to change the database

[Robie Basak]

tags 898148 + moreinfo
severity 898148 normal
thanks

Thank you for your report.

Please explain what steps you followed with full details (what commands
you typed, what configuration files you changed and how, etc) and
explain exactly what you were expecting and what happened instead. Until
you've done this, your report cannot be addressed.

See https://www.debian.org/Bugs/Reporting and
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html if you don't
understand why I'm asking this.

Thanks.


signature.asc
Description: PGP signature

Bug#896709: [debian-mysql] Bug#896709: innobackupex: Error: Unsupported server version: '5.7.21-1-log'

[Robie Basak]

tags 896709 + moreinfo
thanks

This doesn't appear to be a bug report. Please see
https://www.debian.org/Bugs/Reporting (in particular the section
entitled "The body of the report") and
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html and provide a
full explanation.


signature.asc
Description: PGP signature

Bug#884462: Please update mongodb to 3.6

[Robie Basak]

I've updated Ubuntu to mongodb 3.6.

Rather than spam the bug with the entire patchset, you can view the
changes I had to make here:

https://git.launchpad.net/ubuntu/+source/mongodb/log?id=upload/1%253.6.3-0ubuntu1


signature.asc
Description: PGP signature

Bug#895623: golang-github-juju-testing: dep8 test failure with mongodb 3.6

[Robie Basak]

Package: golang-github-juju-testing
Version: 0.0~git20170608.2fe0e88-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

In Ubuntu, the attached patch was applied to achieve the following:

I'm bumping up to mongodb 3.6, which isn't currently in Debian but I
expect will happen sooner or later. At this point, you'll need this
package updated to a new upstream, or you'll need to cherry-pick the
same patch, to fix dep8.

I will separately submit my mongodb 3.6 updates to Debian.

Thanks for considering the patch.

*** 
/tmp/tmpOdgl3i/golang-github-juju-testing_0.0~git20170608.2fe0e88-3ubuntu1.debdiff
diff -Nru 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6
--- 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6   
1970-01-01 01:00:00.0 +0100
+++ 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6   
2018-04-13 16:47:11.0 +0100
@@ -0,0 +1,39 @@
+From 1f2396685494ccf2c5079936561a70652ef78111 Mon Sep 17 00:00:00 2001
+From: John Arbash Meinel 
+Date: Mon, 2 Apr 2018 15:18:23 +0400
+Subject: [PATCH] Changes to support Mongo 3.6.
+
+Don't drop the 'admin' database, and we don't actually need to pass
+`--nohttpinterface`.
+
+In 3.6, there is no '--httpinterface' that you could pass, so there is
+also not its negation. But since it isn't the default, we don't actually
+ever need to pass it.
+
+Origin: upstream, 
https://github.com/juju/testing/commit/1f2396685494ccf2c5079936561a70652ef78111
+Last-Update: 2018-04-13
+---
+ mgo.go | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/mgo.go b/mgo.go
+index c128747..de668ca 100644
+--- a/mgo.go
 b/mgo.go
+@@ -230,7 +230,6 @@ func (inst *MgoInstance) run() error {
+   "--nssize", "1",
+   "--noprealloc",
+   "--smallfiles",
+-  "--nohttpinterface",
+   "--oplogSize", "10",
+   "--ipv6",
+   "--setParameter", "enableTestCommands=1",
+@@ -744,7 +743,7 @@ func (inst *MgoInstance) Reset() error {
+   logger.Infof("reset successfully reset admin password")
+   for _, name := range dbnames {
+   switch name {
+-  case "local", "config":
++  case "local", "config", "admin":
+   // don't delete these
+   continue
+   }
diff -Nru 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series
--- golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series
1970-01-01 01:00:00.0 +0100
+++ golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series
2018-04-13 16:46:26.0 +0100
@@ -0,0 +1 @@
+mongodb-3.6


signature.asc
Description: PGP signature

Bug#895548: Sources are missing, contrary to lintian override comment

[Robie Basak]

Source: golang-github-smartystreets-goconvey
Version: 1.6.1-3
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic

debian/source/lintian-overrides says:

  ## False-positives, sources provided in "debian/missing-sources":

However there is no debian/missing-sources provided. So the following
appear to be accurate and currently have no source:

source-is-missing web/client/js/diff-match-patch.min.js
source-is-missing web/client/js/goconvey.gen.js source-is-missing
web/client/js/jquery-2_0_3.min.js source-is-missing
web/client/js/jquery.waypoints.sticky.min.js


signature.asc
Description: PGP signature

Bug#890446: bcache-tools: /dev/bcache/{by-uuid,by-label} symlinks not present after reboot

[Robie Basak]

For the record, I've been reluctant to commit this without it having
been accepted and resolved upstream.


signature.asc
Description: PGP signature

Bug#823860: bcache-tools: bcache does not work with suspend

[Robie Basak]

On Mon, May 09, 2016 at 01:22:43PM -0400, Scott Moser wrote:
> There is an initial /lib/systemd/system-sleep/bcache.sh in the Ubuntu bug.
> The script there intends to use /lib/systemd/system-sleep/ . However,
> systemd-suspend.service(8) has the following to say:
> 
>  | Note that scripts or binaries dropped in /lib/systemd/system-sleep/ are
>  | intended for local use only and should be considered hacks. If
>  | applications want to be notified of system suspend/hibernation and
>  | resume, there are much nicer interfaces available.

Thank you for the patch! I'm reluctant to commit code that uses an
interface documented like this. So I guess this bug needs someone to
volunteer a patch that only uses recommended interfaces.


signature.asc
Description: PGP signature

Bug#774797: initramfs-tools: Include bcache.ko by default

[Robie Basak]

This seems like a good idea and a reasonable request, but needs someone
to volunteer a patch.


signature.asc
Description: PGP signature

Bug#893897: Preferred method to request update from maintainer scripts not documented

[Robie Basak]

Source: initramfs-tools
Version: 0.130
Severity: wishlist

bcache-tools currently just calls "update-initramfs -u" from its
postinst. On initial review, this seemed inefficient to me over using
the trigger.

It looks like you actually wrap yourself to activate the trigger, so in
practice it makes no difference. I wondered whether you have any
preference or recommendation on which method to use, and I couldn't find
anything. I looked for a README.Debian and in update-initramfs(8).

I asked on IRC, and smcv suggested that given you support a trigger,
that's probably the preferred way, but there was a suggestion that I
should file a bug for you to document this, so here it is.

Please document how you recommend that other package maintainer scripts
should request an initramfs update.

While you're there, debian/README looks pretty out of date, too :)

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#893621: mongodb binaries can't be used directly

[Robie Basak]

Source: mongodb
Severity: wishlist
Version: 3.4.7-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Hi,

I've uploaded the following patch to Ubuntu. This provides a
mongodb-server-core package that ships the binaries only, and
mongodb-server now depends on that instead of shipping the packages
instead. This allows a different type of consumption by dependent
packages and users: to use the binaries directly without
packaging-managed configuration in /var/lib/mongodb and the related
service. This is useful because a consuming dependent app (whether in
the archive or not) can make use of mongodb in its own private space in
/var/lib (or /var/local etc. when not in the archive) without
interfering with anything else on the system or what the user is doing
with mongodb directly.

In Ubuntu, I did this to facilitate a request from Juju, which is not
packaged in Debian. I'm not aware of a use case for Debian that is
needed right now. Further, Juju upstream intends to change how it uses
mongodb in the future, so it is likely that we will drop the patch in
Ubuntu within a release or two.

However, this use case is provided for in MySQL and MariaDB packaging
already using the same pattern, so I thought I'd present it to you in
case you find it useful to maintain in the future.

Feel free to wontfix this if you don't want it. Since we don't intend to
maintain this long term in Ubuntu, it makes little odds to me either
way.

Thank you for your consideration. Here's what I just uploaded to Ubuntu,
which I think should apply to Debian equally:

diff --git a/debian/changelog b/debian/changelog
index b8be094..d1f3258 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+mongodb (1:3.4.7-1ubuntu3) bionic; urgency=medium
+
+  * Break out mongodb-server-core to provide binaries only as a separate
+package (LP: #1756432). This allows users (such as Juju) to use the mongodb
+binaries only for use in non-system-wide databases without conflict with
+what a user on the same system may be doing. This follows the same pattern
+already established with MySQL and MariaDB packaging.
+
+ -- Robie Basak <robie.ba...@ubuntu.com>  Tue, 13 Feb 2018 11:35:01 +
+
 mongodb (1:3.4.7-1ubuntu2) bionic; urgency=high
 
   * No change rebuild against openssl1.1.
diff --git a/debian/control b/debian/control
index f112ae2..12f9d01 100644
--- a/debian/control
+++ b/debian/control
@@ -59,6 +59,31 @@ Description: object/document-oriented database (metapackage)
  the server, the clients and the development files (headers and library).
 
 Package: mongodb-server
+Architecture: all
+Depends:
+ mongodb-server-core,
+ ${misc:Depends}
+Description: object/document-oriented database (server management package)
+ MongoDB is a high-performance, open source, schema-free
+ document-oriented data store that's easy to deploy, manage
+ and use. It's network accessible, written in C++ and offers
+ the following features:
+ .
+* Collection oriented storage - easy storage of object-style data
+* Full index support, including on inner objects
+* Query profiling
+* Replication and fail-over support
+* Efficient storage of binary data including large objects (e.g. videos)
+* Auto-sharding for cloud-level scalability
+ .
+ High performance, scalability, and reasonable depth of
+ functionality are the goals for the project.
+ .
+ This package provides the server functionality, including the system
+ service, management of a mongodb user/group and management of the daemon
+ running against /var/lib/mongodb.
+
+Package: mongodb-server-core
 Architecture: amd64 arm64 ppc64el s390x
 Depends:
  mongodb-clients,
@@ -66,9 +91,12 @@ Depends:
  lsb-base (>= 3.0-6),
  ${misc:Depends},
  ${shlibs:Depends}
+Breaks:
+ mongodb-server (<= 1:3.4.7-1ubuntu2)
 Replaces:
- mongodb (<= 1:1.4.2-2)
-Description: object/document-oriented database (server package)
+ mongodb (<= 1:1.4.2-2),
+ mongodb-server (<= 1:3.4.7-1ubuntu2)
+Description: object/document-oriented database (server binary package)
  MongoDB is a high-performance, open source, schema-free
  document-oriented data store that's easy to deploy, manage
  and use. It's network accessible, written in C++ and offers
@@ -84,7 +112,7 @@ Description: object/document-oriented database (server 
package)
  High performance, scalability, and reasonable depth of
  functionality are the goals for the project.
  .
- This package contains the server itself  (mongod) and the sharding
+ This package contains the server binaries (mongod) and the sharding
  server/load-balancer (mongos).
 
 Package: mongodb-clients
diff --git a/debian/mongodb-server-core.install 
b/debian/mongodb-server-core.install
new file mode 100644
index 000..c941ce1
--- /dev/null
+++ b/debian/mongodb-server-core.install
@@ -0,0 +1,2 @@
+debian/tmp/usr/bin/mongod
+debian/tmp/usr/bin/mongos
diff --git a/debian/mongodb-server.install b/debian/mongodb

Bug#892922: memcached.service is less secure by default

[Robie Basak]

Package: memcached
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch bionic
Tags: patch
Forwarded: https://github.com/memcached/memcached/issues/359

Downstream bug:
 https://bugs.launchpad.net/ubuntu/+source/memcached/+bug/1755460

This affects git master on alioth (currently 0fd2dc1), but not anything
you've uploaded yet.

Upstream version 1.5.6 removed some systemd sandboxing options from
memcached.service as RHEL's systemd currently doesn't support it. Since
AFAIK Debian's systemd does support these options, we should not regress
this sandboxing.

In Ubuntu I've fixed this as follows, which also includes a double check
in debian/rules in case upstream adds further options using this pattern
in the future.

diff --git a/debian/patches/restore-systemd-sandboxing 
b/debian/patches/restore-systemd-sandboxing
new file mode 100644
index 000..584e774
--- /dev/null
+++ b/debian/patches/restore-systemd-sandboxing
@@ -0,0 +1,61 @@
+Author: Robie Basak <robie.ba...@canonical.com>
+Description: Restore systemd sandboxing
+ Upstream regressed systemd sandboxing for everyone by default because RHEL
+ cannot support it. Put it back again to avoid this functional regression.
+Bug: https://github.com/memcached/memcached/issues/359
+Bug-Ubuntu: https://bugs.launchpad.net/memcached/+bug/1755460
+Forwarded: not-needed
+Last-Update: 2018-03-13
+
+--- a/scripts/memcached.service
 b/scripts/memcached.service
+@@ -42,21 +42,16 @@
+ # of this unit. Protects against vulnerabilities such as CVE-2016-8655
+ RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
+ 
+-
+-# Some security features are not in the older versions of systemd used by
+-# e.g. RHEL7/CentOS 7. The below settings are automatically edited at package
+-# build time to uncomment them if the target platform supports them.
+-
+ # Attempts to create memory mappings that are writable and executable at
+ # the same time, or to change existing memory mappings to become executable
+ # are prohibited.
+-##safer##MemoryDenyWriteExecute=true
++MemoryDenyWriteExecute=true
+ 
+ # Explicit module loading will be denied. This allows to turn off module
+ # load and unload operations on modular kernels. It is recommended to turn
+ # this on for most services that do not need special file systems or extra
+ # kernel modules to work.
+-##safer##ProtectKernelModules=true
++ProtectKernelModules=true
+ 
+ # Kernel variables accessible through /proc/sys, /sys, /proc/sysrq-trigger,
+ # /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs and /proc/irq
+@@ -64,21 +59,21 @@
+ # kernel variables should only be written at boot-time, with the sysctl.d(5)
+ # mechanism. Almost no services need to write to these at runtime; it is hence
+ # recommended to turn this on for most services.
+-##safer##ProtectKernelTunables=true
++ProtectKernelTunables=true
+ 
+ # The Linux Control Groups (cgroups(7)) hierarchies accessible through
+ # /sys/fs/cgroup will be made read-only to all processes of the unit.
+ # Except for container managers no services should require write access
+ # to the control groups hierarchies; it is hence recommended to turn this
+ # on for most services
+-##safer##ProtectControlGroups=true
++ProtectControlGroups=true
+ 
+ # Any attempts to enable realtime scheduling in a process of the unit are
+ # refused.
+-##safer##RestrictRealtime=true
++RestrictRealtime=true
+ 
+ # Takes away the ability to create or manage any kind of namespace
+-##safer##RestrictNamespaces=true
++RestrictNamespaces=true
+ 
+ PIDFile=/var/run/memcached/memcached.pid
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 46c68ba..bb9c45b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
 fix-distribution.patch
 always_enable_alignment.patch
 disable_watcher_test.patch
+restore-systemd-sandboxing
diff --git a/debian/rules b/debian/rules
index ccd01ec..9fc8d04 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,6 +26,8 @@ override_dh_auto_install:
$(CURDIR)/debian/memcached.init
install -m 755 $(CURDIR)/scripts/memcached.service \
$(CURDIR)/debian/memcached.service
+   # Check for LP: #1755460
+   if grep -i '##safer##' $(CURDIR)/debian/memcached.service >/dev/null 
2>&1; then echo "ERROR: debian/patches/restore-systemd-sandboxing is 
incomplete; please see LP: #1755460" >&2; exit 1; fi
install -m 755 $(CURDIR)/scripts/damemtop $(SCRIPTS)
install -m 644 $(CURDIR)/scripts/damemtop.yaml $(SCRIPTS)
install -m 644 $(CURDIR)/scripts/README.damemtop $(SCRIPTS)
-- 
cgit v0.10.2



signature.asc
Description: PGP signature

Bug#892732: [debian-mysql] Bug#892732: mysql-server: service start/stop or restart sometimes fails because mysql is still running after the stop

[Robie Basak]

reassign 892732 mariadb-server-10.1
thanks

mysql-server 5.5.+default is a transitional package in stretch that
leads to mariadb-server-10.1, so reassigning.

Robie


signature.asc
Description: PGP signature

Bug#888956: dep8 tests regressed by removal of mariadb-test

[Robie Basak]

Source: mariadb-10.1
Version: 1:10.1.29-6
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic
X-Debbugs-CC: Ondřej Surý 

Commit 27202e3 regressed dep8 tests in buster since debian/tests/control
declares a dependency on mariadb-test but this binary is no longer being
produced.

This is a mistake, IMHO, until mariadb-10.1 is removed from testing,
since mariadb-10.1 can no longer be maintained for quality in testing as
long as the dep8 tests are broken.

Or, if you really intend for this to be the case, then please at least
remove the broken test from debian/tests/ to get us green again, so the
smoke test is at least useful.


signature.asc
Description: PGP signature

Bug#887007: my.cnf handling collides with MySQL

[Robie Basak]

Package: mariadb-client-10.1
Version: 1:10.1.29-6
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic

Steps to reproduce:

apt install mariadb-client-10.1
apt install mysql-server-5.7

The second command will cause mariadb-client-10.1 because of a conflict
with mysql-client-5.7, which is depended on by mysql-server-5.7 and is
expected. However, then we have:

# update-alternatives --display my.cnf
my.cnf - auto mode
  link best version is /etc/mysql/mariadb.cnf
  link currently points to /etc/mysql/mariadb.cnf
  link my.cnf is /etc/mysql/my.cnf
/etc/mysql/mariadb.cnf - priority 200
/etc/mysql/my.cnf.fallback - priority 100
/etc/mysql/mysql.cnf - priority 200

This is incorrect. Our /etc/mysql/my.cnf management system expects that
only one variant package will claim the file at one time. In this case
we have MariaDB claiming /etc/mysql/my.cnf -> /etc/mysql/mariadb.cnf
even though MySQL's mysql-server-5.7 is installed and supposedly active.

This happens because the code to claim /etc/mysql/my.cnf is in
mariadb-common, which is depended on my mariadb-client-10.1. I had
intended the claim to be made from mariadb-server-10.1 (and other
variants' counterparts) only.


signature.asc
Description: PGP signature

Bug#885589: Test suite fails

[Robie Basak]

Package: openscad-testing
Version: 2015.03-2+dfsg-2+b1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic

Running "openscad-testrun --virtual" fails on sid.

Expected: pass

The failures are as follows. AFAICT, echotest_rands cannot possibly work
because I can't find the source it's looking for anywhere.

97% tests passed, 24 tests failed out of 929

Total Test time (real) = 284.03 sec

The following tests FAILED:
 17 - echotest_rands (Failed)
216 - cgalpngtest_text-font-alignment-tests (Failed)
217 - cgalpngtest_text-font-composition (Failed)
218 - cgalpngtest_text-font-direction-tests (Failed)
219 - cgalpngtest_text-font-simple-tests (Failed)
284 - cgalpngtest_polyhedron-nonplanar-tests (Failed)
297 - cgalpngtest_tessellation-text-test (Failed)
470 - opencsgtest_issue1165 (Failed)
473 - opencsgtest_issue1215 (Failed)
524 - csgpngtest_text-font-alignment-tests (Failed)
525 - csgpngtest_text-font-composition (Failed)
526 - csgpngtest_text-font-direction-tests (Failed)
527 - csgpngtest_text-font-simple-tests (Failed)
528 - csgpngtest_text-font-symbol (Failed)
529 - csgpngtest_text-font-tests (Failed)
592 - csgpngtest_polyhedron-nonplanar-tests (Failed)
605 - csgpngtest_tessellation-text-test (Failed)
777 - throwntogethertest_issue1215 (Failed)
811 - monotonepngtest_polyhedron-nonplanar-tests (Failed)
834 - cgalstlcgalpngtest_polyhedron-nonplanar-tests (Failed)
870 - dxfpngtest_text-font-alignment-tests (Failed)
871 - dxfpngtest_text-font-composition (Failed)
872 - dxfpngtest_text-font-direction-tests (Failed)
873 - dxfpngtest_text-font-simple-tests (Failed)


signature.asc
Description: PGP signature

Bug#885429: Please add dep8 test

[Robie Basak]

Source: openscad
Version: 2015.03-2+dfsg-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Thank you for the openscad-testing package. It was very helpful in
pinning down a bug I'm chasing.

Please could you add a dep8 (http://dep.debian.net/deps/dep8/) test that
automatically runs the testsuite from openscad-testing? Patch below.
This will allow both Debian and Ubuntu infrastructure to automatically
run the tests including on reverse dependency changes, and the test
result history will help us better pin down regression root causes in
the future.

At the moment a number of tests in the test suite fail. I intend to file
a separate bug for this. But at least with the dep8 tests running we
will have better visibility of this.

Here's the (rather trivial) patch:

diff -Nru openscad-2015.03-2+dfsg/debian/tests/control 
openscad-2015.03-2+dfsg/debian/tests/control
--- openscad-2015.03-2+dfsg/debian/tests/control1970-01-01 
01:00:00.0 +0100
+++ openscad-2015.03-2+dfsg/debian/tests/control2017-12-24 
09:10:45.0 +
@@ -0,0 +1,3 @@
+Test-Command: openscad-testrun --virtual --directory $AUTOPKGTEST_TMP/testrun
+Depends: openscad-testing, xvfb
+Restrictions: allow-stderr



signature.asc
Description: PGP signature