Bug#948093: hyphy: autopkgtest regression: Duplicate analysis keyword

[Andreas Tille]

Control: tags -1 moreinfo

Hi Paul,

On Fri, Jan 03, 2020 at 09:40:44PM +0100, Paul Gevers wrote:
> 
> With a recent upload of hyphy the autopkgtest of hyphy fails in testing
> when that autopkgtest is run with the binary packages of hyphy from
> unstable. It passes when run with only packages from testing. In tabular
> form:
>passfail
> hyphy  from testing2.5.1+dfsg-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it? If needed, please
> change the bug's severity.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=hyphy
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/h/hyphy/3845632/log.gz

I've uploaded 2.5.1+dfsg-2 with more debug infor in the autopkgtest.  Since this
the tests are passing again as you can check from

   https://ci.debian.net/data/autopkgtest/testing/amd64/h/hyphy/3874825/log.gz

on.  I admit I have no idea why my `set -x` would have fixed that issue but
may be other packages in testing might have an additional effect.  What do
you think?

Kind regards

Andreas.


-- 
http://fam-tille.de

Bug#948316: New upstream release available (2.3.0)

[Russ Allbery]

Package: yadm
Version: 1.12.0-2
Severity: normal

I was looking for good home directory dotfile managers, and yadm looks
like the best currently packaged in Debian, but the Debian version is
out of date.  The current upstream version is 2.3.0 and seems to have
substantial improvements in how the files are organized.

Could you update the Debian package to the latest version?  Let me know
if I can be of any help.

Thanks!

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

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

Versions of packages yadm depends on:
ii  git  1:2.25.0~rc1-1

yadm recommends no packages.

yadm suggests no packages.

Bug#948315: ITP: libjson-path-perl -- search nested hashref/arrayref structures using JSONPath

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : libjson-path-perl
  Version : 0.420
  Upstream Author : , Kit Peters 
* URL : https://metacpan.org/release/JSON-Path
* License : Artistic
  Programming Lang: Perl
  Description : search nested hashref/arrayref structures using JSONPath
 JSON::Path implements JSONPath, an XPath-like language for searching
 JSON-like structures.
 .
 JSONPath is described at http://goessner.net/articles/JsonPath/.

JSON::Path is a dependency for JSON::Hyper, which I intend to eventually
package.

Remark: This package is to be maintained with Debian Perl Group at
   https://salsa.debian.org/perl-team/modules/packages/libjson-path-perl

Bug#946625: scipy: autopkgtest regularly times out

[Drew Parsons]

Thanks Håvard. Placing @pytest.mark.skip will get the job so worse come 
to worse we can deal with it that way.  The reason why I'd prefer not to 
do it that way is that that here we only want to control the tests being 
run from debian/tests. The @pytest.mark.skip will disable them for all 
testing (e.g. users running the tests locally), which we don't 
necessarily want.



The thing I don't understand is that the skips currently in place (in 
debian/tests/python3) were working fine until relatively recently. I 
don't know why they've stopped functioning (I'm assuming some syntax 
change for handling the skip structure that is currently used in 
debian/tests/python3).


The configuration of debian/tests/python3 of obfuscated by use of 
junitxml, so hard to check. I think the problem is testid is no longer 
matching the skip entries, where previously it did match.


Perhaps activating the -k-slow option like you suggested might be 
simpler for us.





On 2020-01-06 09:44, Håvard Flaget Aasen wrote:

I might be way off here, but if you want to skip test you can create a
patch with this above the class or function you want to skip.

--
@pytest.mark.skip(reason="no way of currently testing this")
--

More info here [1]
This will of course skip the tests at build time as well.

I also saw some tests that was marked '@pytest.mark.slow'. These can 
also

be skipped using 'pytest -k-slow' though you might skip over more
tests than you want.

I must admit I'm on thin ice here, cause I don't even know how your
script runs..


[1]: https://docs.pytest.org/en/latest/skipping.html#skip

Bug#948211: Decouple containerd from docker.io again?

[Shengjing Zhu]

On Tue, Jan 7, 2020 at 11:22 AM Arnaud Rebillout
 wrote:
[..]
> 1) try to update containerd -> oh, requires a new version of containerd/cri
> 2) so let's try to update containerd/cri -> oh, requires a new version of 
> docker

The plan is to keep upstream
vendor/github.com/{docker/docker,containerd/cri} in src:containerd.
Since the vendor/github.com/docker/docker/ only has ~60 Go files, it's
easy to review copyright and other things.

>
> I think you can already upload containerd to unstable at this point? Or is 
> there some blocker?

There's no blocker, but I want to ensure that the docker.io
maintainers are aware of it.

-- 
Shengjing Zhu

Bug#948314: RFS: opensurge/0.5.1.1-1 [ITP] -- Fun 2D retro platformer inspired by Sonic games

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "opensurge"

 * Package name: opensurge
   Version : 0.5.1.1-1
   Upstream Author : Alexandre Martins 
 * URL : https://opensurge2d.org
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/games-team/opensurge
   Section : games

It builds those binary packages:

  opensurge - Fun 2D retro platformer inspired by Sonic games
  opensurge-data - Fun 2D retro platformer inspired by Sonic games (data file)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opensurge/opensurge_0.5.1.1-1.dsc

Changes since the last upload:

   * Initial release (Closes: #943676)

Regards,

--
  Carlos Donizete Froes [a.k.a coringao]

Bug#948313: RFS: surgescript/0.5.4.2-1 -- Scripting language for games

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "surgescript"

 * Package name: surgescript
   Version : 0.5.4.2-1
   Upstream Author : Alexandre Martins 
 * URL : https://docs.opensurge2d.org
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/games-team/surgescript
   Section : graphics

It builds those binary packages:

  surgescript - Scripting language for games

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/surgescript/surgescript_0.5.4.2-1.dsc

Changes since the last upload:

   * New upstream release.
   * Update debian/copyright years.
   * debian/rules: Reduced command to directory.
   * Update debian/upstream/metadata years.

Regards,

--
  Carlos Donizete Froes [a.k.a coringao]

Bug#948211: Decouple containerd from docker.io again?

[Arnaud Rebillout]

On 1/7/20 1:29 AM, Shengjing Zhu wrote:

We should keep containerd version in sync with docker. eg docker
19.03.x with containerd 1.2.x. And I guest next docker major version
will use containerd 1.3.x.



Agreed on that, as long as both projects are in sync upstream, that can 
work.






Talking about versions, looking at the file 
https://download.docker.com/linux/debian/dists/buster/stable/binary-amd64/Packages,
 I can see that:

- the docker-ce package started to depend on container.io from the 18.09.x 
series (it's been a while: good)
- the latest version of docker-ce "5:19.03.5~3-0~debian-buster" depends on 
containerd.io (>= 1.2.2-3)... Where is the source for this package? Is containerd.io 
patched here?

I found a comment from someone asking for the sources of the package: 
https://github.com/containerd/containerd/issues/1508#issuecomment-461413010. 
The comment went unanswered. A bit more research, and still no idea where are 
the source for this package. Do you have an idea?


Neither do I :(

But let's be optimized about this. There's no reason for docker
upstream to _hide_ some patches which are not applied in containerd
upstream :)
Actually if you look at commits in containerd release branch, the
people from docker are actively backporting things.



I don't think anyone hides anything, but I don't want to be in the 
situation were:


- you install docker and containerd from docker repos, everything works
- you install docker and containerd from debian repos (same versions as 
in docker repos), and some things don't work...


Why? Because there are some patches in containerd.io (from docker repos) 
that we are not aware of...


That's one thing I'm worried about as long as I don't have the source 
package for containerd.io.


The second thing is that, in any case, we shouldn't patch containerd to 
accomodate docker. If docker is the consumer of containerd, and can't 
work with it "as is", then docker has to be patched, not containerd.


All of that is theoretical speaking, maybe in the end docker and 
containerd can work with each other, from tagged version, and without 
any patch.


But this has never been the case up to now (I mean, docker could never 
/build/ against a tagged version of containerd, at least), so I have 
reasons to be cautious, and not over optimistic.





CRI makes containerd useful without docker in a kubernetes worker
node. (That's why I want a separate containerd package)

I have some mistakes in my previous sentence. It should be,
+ github.com/containerd/cri pull in github.com/docker/docker.
+ github.com/containerd/containerd/cmd/containerd pull in
github.com/containerd/cri
So only when you build containerd binary(with cri), you will need
github.com/docker/docker.
No consumer will pull in github.com/containerd/containerd/cmd/..., so
no need to pull in github.com/docker/docker.
There's no circular dependencies, apparently.



Thanks for the details.

Correct me if I'm wrong, but there's still a bit of a circular dep, in 
the sense that the Build-Depends are for the source package, not for 
each binary package produced.


So, assuming that we want to bump both docker and containerd to a new 
major version, the situation could very well be:


1) try to update containerd -> oh, requires a new version of containerd/cri
2) so let's try to update containerd/cri -> oh, requires a new version 
of docker

3) so let's try to update docker -> oh, requires a new version of containerd
4) back to 1...

That wouldn't be the first circular of this kind, we already had it at 
some point with fsouza-go-dockerclient, even though I think these days 
it's gone.


Anyway.

I think you can already upload containerd to unstable at this point? Or 
is there some blocker?


I'm not fundamentally against attempts to un-bundle containerd from 
docker, but the reality is that I don't know when (if ever) I can spend 
time giving it a try, and in the meantime you shouldn't be waiting on 
me. The docker package shouldn't block the containerd package from being 
in unstable, and unless I'm mistaken, at the moment it doesn't.


In the short-term, for unstable, I would be in favor of having 
containerd, and also docker.io as it is now, ie. with bundled 
containerd. And in a longer term, possibly before bullseyes, if it seems 
realistic, I will find some time to work on un-bundling.


Having someone working on the containerd packaging is already a great 
improvement, so it's good that this discussion is taking place.


Thanks!

  Arnaud

Bug#872890: this can be closed

[McIntyre, Vincent (CASS, Marsfield)]

The issue I reported is fixed in upstream's 1.43.

Bug#948207: kio-gdrive: No more work because google temoprarilly supressed the access

[Nicholas D Steeves]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=415089
Control: severity -1 important
Justification: kio-gdrive is not unusable for everyone

Hi Eric,

Thank you for reporting this bug, and especially for providing a link to
the upstream bug :-)

I've reduced the severity to important, because the package remains
usable for anyone who already has already authorised kio-gdrive and who
did not fall victim to Google's manipulation--the narrative you've
provided is remarkably similar to a phishing attack in the sense that an
email requested user action, the user took action, and consequently the
user lost access to their files.  I agree that it's a severe issue that
has greatly inconvenienced you, but we need to abide by official
severity definitions:
  https://www.debian.org/Bugs/Developer#severities

It is my position that this is a user-hostile action by Google and not a
bug in kio-gdrive, and I expect that existing kio-gdrive versions will
begin to work again without maintainer action as soon as Google
reauthorises kio-gdrive's application API key.  While it only affects a
minority of users (eg: not on Windows or MacOS), it's a really bad PR
move (like Dropbox dropping non-ext4 support) that ought to drive users
away from their proprietary services towards freedom-respecting
solutions like Syncthing and OwnCloud/NextCloud.  If maintainer action
is required, then I will also provide a stable update for buster users.

It's 10 or 11 months early for the decision about whether this package
should be cut from bullseye (Debian 11) due to this issue.  At that time
it may be appropriate to raise this bug's severity to RC, with the
practical "for all intents and purposes unusable for new users"
rationale you provided.  It will be interesting to see what Ubuntu will
do for their 20.04 LTS release!

With respect to the "Accounts" interface, Plasma will activate whatever
it can use, as will GNOME.  The former has checkboxes and the later has
toggle switches to limit which services are activated.

https://bugs.kde.org/show_bug.cgi?id=415089#c15
  * From what you wrote it sounds like there's also a bug (or evil
misfeature) in Google's authorisation interface/infrastructure,
because deauthaurising calendar or mail should not have disabled
access to GDrive.

Thanks again for taking the time to file this bug and for drawing
attention to a real-life problem that demonstrates how we shouldn't
trust our data to corporations who hold all the locks and keys...and I
say this as someone who took the time to package kio-gdrive for Debian,
because it's better to have it than to not, but best not to use it at
all.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#938827: RM winpdb

[Scott Talbert]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: winpdb -- RoQA; semi-dead upstream; unmaintained; low 
popcon; blocking py2 removal

The existing maintainer doesn't intend to maintain it anymore, so let's 
just RM it.

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Benjamin Poirier]

I'm not sure if it's related but I saw almost the same error on last
upgrade (but for 5.4.0-2):

depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file 
'/var/tmp/mkinitramfs_J2sneW/lib/modules/5.4.0-2-amd64/modules.builtin.bin'

and I now get:

root@vsid:~# lttng list --kernel
Error: Unable to list kernel events: Kernel tracer not available
root@vsid:~# journalctl -u lttng-sessiond.service
[...]
Jan 07 09:33:20 vsid lttng-sessiond[403]: Error: Failed to load kmod library 
resources
Jan 07 09:33:20 vsid lttng-sessiond[403]: Warning: No kernel tracer available

lttng-modules-dkms is installed. I can load the modules manually but I
still get the same error.

Bug#948151: git: Please consider demoting git-man to Recommends

[Jonathan Nieder]

John Paul Adrian Glaubitz wrote:
> On 1/7/20 1:03 AM, Jonathan Nieder wrote:

>> Using Recommends to mean "Depends, except on
>> buildds" would produce bad results for end users that use
>> --no-recommends.
>
> I disagree. Anyone who uses "--no-recommends" should know what they are
> doing. And those are just manpages, after all.

The trouble is that the "git help" feature (a standard feature of Git)
is not designed to work in their absence.  I agree that that's worth
changing, and that is what https://bugs.debian.org/613892 is about.

For the case at hand: do you have a list of arches that are affected
by this?  I can demote the dependency to Recommends on those arches.

Sincerely,
Jonathan

Bug#947916: [pcp] Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

[Nathan Scott]

Hi Martin, Sunil, all,

Thanks for looking into this issue while we were all off, Martin and Sunil!

To summarise where I understand things are at now: Martin's uploaded
a pcp package for rebuild which drops the python2 build steps.  I think
this is fine and solves the immediate, pressing issue.

The intent with the build system is/was to allow pcp deb builds on older
Debian platforms as well, where python(2) may be the only option.  But,
it looks like python3 has been present in all supported Debian versions
going back to debian8 so perhaps it is time to make Martin's change in
upstream PCP too?

Ken and Andreas, this would mean we set Debian8 (and the equivalent
Ubuntu release) as the minimum required for Makepkgs builds.  Would
that be a problem for anyone?  It turns out that was the first Debian that
used systemd as the init system, so there's a possibility of several other
useful packaging cleanups if we take this path.

cheers.

--
Nathan

On Mon, Jan 6, 2020 at 7:19 AM Martin Pitt  wrote:
>
> Control: tag -1 pending
>
> Hello again,
>
> Martin Pitt [2020-01-05 10:54 +0100]:
> > > I ran into similar issue when attempting to build with multiple parallel
> > > tasks with DEB_BUILD_OPTIONS=parallel=8 or with -j8. If you have this
> > > turned on, please try disabling it.
> >
> > I indeed had that option set, thanks for pointing out! pcp's packaging is
> > rather complex and debian/rules rather old-fashioned and hard to understand,
> > and apparently doesn't get along well with parallel builds. This RC bug fix 
> > is
> > not the time for more intrusive changes though, so let's ignore this for now
> > indeed.
> >
> > However, even with unsetting it it still fails:
>
> Nevermind, I also had MAKEVARS=-j4 set, which caused this issue.
>
> I now uploaded this as an NMU to DELAYED/3, using the exact patch that I
> attached yesterday.
>
> Thanks,
>
> Martin
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#21752): https://groups.io/g/pcp/message/21752
> Mute This Topic: https://groups.io/mt/69427489/174104
> -=-=-
> pcp mailing list
> p...@groups.io
> https://groups.io/g/pcp/messages
> -=-=-
> Group Owner: pcp+ow...@groups.io
> Unsubscribe: https://groups.io/g/pcp/leave/354222/526236543/xyzzy  
> [nath...@redhat.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Bug#948151: git: Please consider demoting git-man to Recommends

[John Paul Adrian Glaubitz]

On 1/7/20 1:03 AM, Jonathan Nieder wrote:
> This is not what Recommends is for.  If we want to remove a dependency
> in the buildd environment but not for users, we can use build profiles
> for that instead.

Build profiles cannot be triggered on buildds. They can be set for manual
builds only.

> Using Recommends to mean "Depends, except on
> buildds" would produce bad results for end users that use
> --no-recommends.

I disagree. Anyone who uses "--no-recommends" should know what they are
doing. And those are just manpages, after all.

> Are there any plans for debian-ports to host the relevant arch:all
> packages?

We do have arch:all in Debian Ports but that's not the problem. The
problem is explained in [1]. We don't have the CRUFT feature in
Debian Ports as we don't use DAK but Mini-DAK so we run into this
problem every time a build fails on a certain architecture and the
package versions for the arch:any and arch:all package divert.

Any time this happens, I have to build the package manually with
the testsuite disabled or with some local patches applied which
is always time-consuming and frustrating which is why I am asking
for the manpages being moved from Depends to Recommends.

There are efforts to make Debian Ports use Mini-DAK but unfortunately
there has not been any progress on this lately. There are quite
some people interested in Debian Ports but not many are willing to
do the work which is why progress is slow.

Adrian

> [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#948151: git: Please consider demoting git-man to Recommends

[Jonathan Nieder]

reassign 948151 git 1:2.25.0~rc1-1
forcemerge 613892 948151
tags 613892 + upstream
quit

Hi,

Anatoly Pugachev wrote:

> clone of #613892 ?

Indeed it is!  Thanks for digging that up.

See that bug for details on what is needed to get this done (an
upstream patch teaching "git help" to cope with missing manpages).

John Paul Adrian Glaubitz wrote:
>> John Paul Adrian Glaubitz wrote:

>>> Since Recommends are enabled by default in apt, this would still
>>> cause git-man to be installed on standard desktop installations
>>> when a user invokves "apt install git" but at the same time it
>>> would avoid installability problems as described in [1], especially
>>> for Debian Ports buildds which, for example, cannot build rustc
>>> at the moment because git is no installable [2].
[...]
> I would actually move it to Recommends as this will still result
> of git-man being installed on any regular system but the installation
> will not fail if the package is not available.
>
> Recommends is basically a Depends that can be turned off with 
> "--no-recommends"
> which is exactly what the buildds are using.

Thanks for reporting it.  Interesting.

This is not what Recommends is for.  If we want to remove a dependency
in the buildd environment but not for users, we can use build profiles
for that instead.  Using Recommends to mean "Depends, except on
buildds" would produce bad results for end users that use
--no-recommends.

Are there any plans for debian-ports to host the relevant arch:all
packages?

Sincerely,
Jonathan

Bug#948312: obfs4proxy: New upstream releasse

[Chris Lamb]

Package: obfs4proxy
Version: 0.0.8-1
Severity: wishlist

There is a new upstream release of obfs4proxy available (at the time
of writing, 0.0.11):

  https://qa.debian.org/cgi-bin/watch?pkg=obfs4proxy

However, this will require the packaging of at least https://
gitlab.com/yawning/utls.


Regards,

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

Bug#947630: lintian still gives E: statically-linked-binary for golang project's binary

[Chris Lamb]

Hi Felix,

> Would you be opposed if I reverse the logic of this check? Until the
> contemplated features are implemented, the tag would be issued only
> when sources are present.

Not at all.

> My adverse position towards the tag is supported by user statistics.
> On lintian.d.o, it was overridden 189 out of 192 times.

(Ouch, indeed.)


Regards,

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

Bug#948311: RFS: clamfs/1.2.0-1 -- user-space anti-virus protected file system

[Krzysztof Burghardt]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "clamfs"

 * Package name: clamfs
   Version : 1.2.0-1
   Upstream Author : Krzysztof Burghardt
 * URL : https://github.com/burghardt/clamfs
 * License : GPL-2+
 * Vcs : https://github.com/burghardt/clamfs-debian-package
   Section : utils

It builds those binary packages:

  clamfs - user-space anti-virus protected file system

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/clamfs/clamfs_1.2.0-1.dsc

Changes since the last upload:

   * New upstream version
   * debian/control:
 - libfuse3-dev replaces libfuse-dev
 - add pkg-config dependency
   * debian/copyright:
 - add fdpassing.m4 and src/fdpassing.h

Regards,
-- 
Krzysztof Burghardt 
http://www.burghardt.pl/

Bug#945486: pwman3: fails to upgrade from 'buster': new pwman3 package pre-installation script subprocess returned error exit status 1

[Andreas Beckmann]

On 07/01/2020 00.09, Emmanuel Bouthenot wrote:
> Andreas,
> 
> On Mon, Nov 25, 2019 at 09:44:14PM +0100, Andreas Beckmann wrote:
> [...]
> 
>> during a test with piuparts I noticed your package fails to upgrade from
>> 'buster'.
>> It installed fine in 'buster', then the upgrade to 'bullseye' fails.
>>
>> From the attached log (scroll to the bottom...):
> 
> It is very probably a false positive due to a debconf question[1] raised
> during the preinst script.
> 
> In presinst script[2], it is possible to completely abort the package
> upgrade process to let the users backup their data (old database is not
> compatible with the new database format).
> 
> I guess we could lower the severity?

Yes.

> What do you suggest to fix this bug?

Can I preseed the debconf question to 'continue'?
I do this in piuparts for some questions in similar situations.

> [1] https://salsa.debian.org/kolter/pwman3/blob/unstable/debian/templates
s/form/from/
s/renamed/rename/

> [2] https://salsa.debian.org/kolter/pwman3/blob/unstable/debian/pwman3.preinst
> 

Andreas

Bug#948283: tinyproxy: If no PidFile is configured logrotate will change the owner of the root directory

[Tim Düsterhus]

Salvatore,

Am 06.01.20 um 22:46 schrieb Salvatore Bonaccorso:
> I think the whole problem is placed at multiple levels. You seem to
> use systemd as init, but when lgorotate comes into action, the
> postrotate is

Yes. I use systemd. I updated my unit file to `Type=simple`, because I
wanted tinyproxy to log to stdout (for the logs to be picked up by
systemd-journald). While doing so I removed the PidFile setting I no
longer needed.

> invoke-rc.d --quiet tinyproxy reload > /dev/null
> 
> As tinyproxy.service can't reload the service through the .service
> file, it will fallback into reloading tinyproxy via the init-script:
> 
> […]
> 
> PIDDIR will be ".", and the chown and chgrp will be applied to the
> current working directory.
> 
> The current working directory is changed to /, and thus the chown and
> chgrp call upon '.' will affect /.

This matches my observations.

>> Thus I feel the severity of `critical` is justified for this bug report.
> 
> I'm not sure this is warranted, but I will leave this to the decision
> of the maintainer :)

At least the description within reportbug applied to my case. It was a
nasty surprise, because it didn't happen immediately after the
configuration change, but with a bit of delay.

Best regards
Tim Düsterhus

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

[Daniel Kahn Gillmor]

On Sun 2019-10-06 14:18:16 -0400, Daniel Kahn Gillmor wrote:
> On Sat 2019-10-05 10:21:05 -0700, Sean Whitton wrote:
>
>> As an alternative to adding the integration tests, how about you use
>> imap-dl on a daily basis for ~3 months with (I assume) a standard IMAP
>> server, and if you don't have to make any nontrivial changes to the
>> script during that time, we can ship it in mailscripts?
>
> i'm using imap-dl on a daily basis now, and will happily report back
> then too.  the last changes i made were supplying more debugging details
> on october 2nd, so i suppose the new year is ~3 months if you want to
> start the clock from my last changes :)

It's now been three months, and the only changes i've made to imap-dl
have been trivial ones:

 - accept that some IMAP daemons will lie about message sizes before
   download, offer workaround for users stuck with those servers
   (thanks, bremner)
 - some grammar cleanup (thanks, Clint)
 - auto-creating the target maildir if it wasn't already present
   (thanks, jrollins)
 - produce sensible --help output
   (thanks, jrollins)
 - clean up internal typechecking
 - add tab completion in bash

The whole series is available on the "imap-dl" branch at
https://salsa.debian.org/dkg/mailscripts.git, or if you prefer to import
it a single patch, i'm attaching that here.

Thanks for maintaining mailscripts,

   --dkg

diff --git a/Makefile b/Makefile
index af30616..ec3d851 100644
--- a/Makefile
+++ b/Makefile
@@ -1,15 +1,17 @@
 MANPAGES=mdmv.1 mbox2maildir.1 \
 	notmuch-slurp-debbug.1 notmuch-extract-patch.1 maildir-import-patch.1 \
+	imap-dl.1 \
 	email-extract-openpgp-certs.1 \
 	email-print-mime-structure.1 \
 	notmuch-import-patch.1
-COMPLETIONS=completions/bash/email-print-mime-structure
+COMPLETIONS=completions/bash/email-print-mime-structure completions/bash/imap-dl
 
 all: $(MANPAGES) $(COMPLETIONS)
 
 check:
 	./tests/email-print-mime-structure.sh
 	mypy --strict ./email-print-mime-structure
+	mypy --strict ./imap-dl
 
 clean:
 	rm -f $(MANPAGES)
diff --git a/debian/control b/debian/control
index bc8268a..21afa45 100644
--- a/debian/control
+++ b/debian/control
@@ -77,3 +77,5 @@ Description: collection of scripts for manipulating e-mail on Debian
  email-print-mime-structure -- tree view of a message's MIME structure
  .
  email-extract-openpgp-certs -- extract OpenPGP certificates from a message
+ .
+ imap-dl -- download messages from an IMAP mailbox to a maildir
diff --git a/debian/mailscripts.bash-completion b/debian/mailscripts.bash-completion
index 435576f..657de01 100644
--- a/debian/mailscripts.bash-completion
+++ b/debian/mailscripts.bash-completion
@@ -1 +1,2 @@
 completions/bash/email-print-mime-structure
+completions/bash/imap-dl
diff --git a/debian/mailscripts.install b/debian/mailscripts.install
index 2c060df..3739c49 100644
--- a/debian/mailscripts.install
+++ b/debian/mailscripts.install
@@ -1,5 +1,6 @@
 email-extract-openpgp-certs /usr/bin
 email-print-mime-structure /usr/bin
+imap-dl /usr/bin
 maildir-import-patch /usr/bin
 mbox2maildir /usr/bin
 mdmv /usr/bin
diff --git a/debian/mailscripts.manpages b/debian/mailscripts.manpages
index 1de088f..a915617 100644
--- a/debian/mailscripts.manpages
+++ b/debian/mailscripts.manpages
@@ -1,5 +1,6 @@
 email-extract-openpgp-certs.1
 email-print-mime-structure.1
+imap-dl.1
 maildir-import-patch.1
 mbox2maildir.1
 mdmv.1
diff --git a/imap-dl b/imap-dl
new file mode 100755
index 000..f5d7a85
--- /dev/null
+++ b/imap-dl
@@ -0,0 +1,254 @@
+#!/usr/bin/python3
+# PYTHON_ARGCOMPLETE_OK
+# -*- coding: utf-8 -*-
+
+# Copyright (C) 2019 Daniel Kahn Gillmor
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or (at
+# your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+DESCRIPTION = '''A simple replacement for a minimalist use of getmail.
+
+In particular, if you use getmail to reach an IMAP server as though it
+were POP (retrieving from the server and optionally deleting), you can
+point this script to the getmail config and it should do the same
+thing.
+
+It tries to ensure that the configuration file is of the expected
+type, and will terminate raising an exception, and it should not lose
+messages.
+
+If there's any interest in supporting other use cases for getmail,
+patches are welcome.
+
+If you've never used getmail, you can make the simplest possible
+config file like so:
+
+--
+[retriever]
+server = mail.example.net
+username = foo
+password = sekr1t!
+

Bug#948238: man-db: man produces apparmor kernel warnings

[Bruce Momjian]

Ok sounds good, thanks.

--
Bruce Momjian
br...@momjian.us

On Mon, Jan 6, 2020, 5:27 PM Colin Watson  wrote:

> On Mon, Jan 06, 2020 at 10:07:08PM +, Colin Watson wrote:
> > There's already "/var/cache/man/** w" in man_filter,
>
> In fact, I just noticed that you're running stable, which doesn't have
> that fix:
>
>   https://bugs.debian.org/926450
>
> https://salsa.debian.org/debian/man-db/commit/e9384c86cddec12c98737afc0f724392497b7b4a
>
> So the right thing to do is just to issue a stable update with that fix.
> I already have such a patch queued up and will try to get round to the
> paperwork for it soon.
>
> --
> Colin Watson   [cjwat...@debian.org]
>
>

Bug#948238: man-db: man produces apparmor kernel warnings

[Colin Watson]

On Mon, Jan 06, 2020 at 10:07:08PM +, Colin Watson wrote:
> There's already "/var/cache/man/** w" in man_filter,

In fact, I just noticed that you're running stable, which doesn't have
that fix:

  https://bugs.debian.org/926450
  
https://salsa.debian.org/debian/man-db/commit/e9384c86cddec12c98737afc0f724392497b7b4a

So the right thing to do is just to issue a stable update with that fix.
I already have such a patch queued up and will try to get round to the
paperwork for it soon.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#948310: maven: Depend on Guice no_aop

[Emmanuel Bourg]

Package: maven
Version: 3.6.2-1
Severity: normal

Once #948309 is fixed the maven package should be changed to depend on
libguice-noaop-java instead of libguice-java. This will remove the illegal
reflective access warning displayed when invoking Maven with Java 9+.

Two changes are required:
- libmaven3-core-java has to depend on libguice-noaop-java instead of 
libguice-java
- the guice.jar symlink in /usr/share/maven/lib should point to the no_aop 
variant

Emmanuel Bourg

Bug#945486: pwman3: fails to upgrade from 'buster': new pwman3 package pre-installation script subprocess returned error exit status 1

[Emmanuel Bouthenot]

Andreas,

On Mon, Nov 25, 2019 at 09:44:14PM +0100, Andreas Beckmann wrote:
[...]

> during a test with piuparts I noticed your package fails to upgrade from
> 'buster'.
> It installed fine in 'buster', then the upgrade to 'bullseye' fails.
> 
> From the attached log (scroll to the bottom...):

It is very probably a false positive due to a debconf question[1] raised
during the preinst script.

In presinst script[2], it is possible to completely abort the package
upgrade process to let the users backup their data (old database is not
compatible with the new database format).

I guess we could lower the severity?

What do you suggest to fix this bug?

Regards,

[1] https://salsa.debian.org/kolter/pwman3/blob/unstable/debian/templates
[2] https://salsa.debian.org/kolter/pwman3/blob/unstable/debian/pwman3.preinst

-- 
Emmanuel Bouthenot
  mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
  xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}

Bug#948142: [pkg-apparmor] Bug#948142: apparmor: Update abstractions/ibus socket path

[Jamie Strandboge]

On Sat, 04 Jan 2020, Changwoo Ryu wrote:

> Package: apparmor
> Version: 2.13.3-7
> Severity: normal
> 
> In short, the ibus socket path in  needs to be changed 
> for the recent ibus versions like this:
> 
>  unix (connect, receive, send)
>type=stream
>peer=(addr="@{HOME}/.cache/ibus/dbus-*"),
> 
> Details:
> 
> This is follow-up to debian/patches/debian/allow-access-to-ibus-socket.patch.
> 
> In IBus upstream 1.5.21, the upstream has changed the default socket path
> to"/tmp/ibus" to make it distinguishable. But it is not secure as a malicious
> user can create "/tmp/ibus" with restrictive permission. In IBus upstream git
> after 1.5.21, the upstream has changed the socket path to
> "$XDG_CACHE_HOME/ibus" for Linux and "/tmp" for non-Linux. (See
> https://github.com/ibus/ibus/issues/2095 and
> https://github.com/ibus/ibus/issues/2116 for more information.) AppArmor is
> Linux specific so allowing Unix socket "${HOME}.cache/ibus/dbus-*" is enough.
> 
> Debian ibus 1.5.21-5 has these changes (to fix non-linux FTBFS).
> 
> You can also remove the old socket path and then "ibus (<< 1.5.21-5)" should 
> be
> added to Breaks.

FYI, this is:

https://salsa.debian.org/apparmor-team/apparmor/commit/8c11bb9f2744555cc9c79447b5adb4dedfd36d2b

I didn't upstream it yet because of the referenced bug, but there is no
reason this couldn't be included in Debian until that bug is fixed.

-- 
Jamie Strandboge | http://www.canonical.com

Bug#948309: guice: Package the no_aop jar

[Emmanuel Bourg]

Source: guice
Version: 4.2.1-1
Severity: normal

The 'no_aop' variant of guice (without the embedded cglib) isn't installed
by the libguice-java package, instead a symlink to the 'aop' jar is
installed. This was mostly done to reduce the size of the package. Since the
aop variant is a superset of the no_aop one [1], that was fine.

Unfortunately the modules introduced in Java 9 don't play well with cglib [2],
and using the aop variant triggers a warning on the console. This is especially
annoying with Maven, the following warning is displayed on each invocation:

  WARNING: An illegal reflective access operation has occurred
  WARNING: Illegal reflective access by 
com.google.inject.internal.cglib.core.$ReflectUtils$1 
(file:/usr/share/maven/lib/guice.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
  WARNING: Please consider reporting this to the maintainers of 
com.google.inject.internal.cglib.core.$ReflectUtils$1
  WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective 

Maven upstream depends on the 'no_aop' variant and isn't affected by this
warning.

Packaging the 'no_aop' variant could address this issue. It could be placed
into it's own libguice-noaop-java package, this would save ~400KB when
installing Maven.

Emmanuel Bourg


[1] https://github.com/google/guice/wiki/OptionalAOP
[2] https://github.com/cglib/cglib/issues/129

Bug#948029: splitting windows sometimes zaps images

[Katsumi Yamaoka]

> C-h l
>  T [w3m-toggle-inline-images]
>  C-x 3 [split-window-right] Zaps the images. Need to turn them on again.
>  T [w3m-toggle-inline-images]
>  C-x 1 [delete-other-windows] Zaps the images again.

> By the way, C-x 2 doesn't zap the images.

What url where did you do it?  Unreproducible so far.

Bug#948028: w3m-reload-this-page should respect the current image toggle state

[Katsumi Yamaoka]

On Fri, 03 Jan 2020 21:17:14 +0800, 積丹尼さん wrote:
> But doing
> T then
> R
> then needs a second
> T
> to make the page look fine again.

Hmm, doesn't it work as you expected, does it?  I tried it in

and others without the second T.

Bug#948181: x2gothinclient-minidesktop: fails to install with lightdm installed

[Wolfgang Schweer]

Hi Andreas, hi Mike,

On Sun, Jan 05, 2020 at 12:41:32AM +0100, Andreas Beckmann wrote:
> Are you trying to use dpkg-divert on conffiles? That does not work ...

[..]

> PS: If you tell me what exactly you want to achieve, I might think about it 
> ... ;-)

The vanilla lightdm.conf file should be replaced with a custom one 
inside the thin client chroot.

I figure that this can be done by shipping a file, say lightdm.conf.tce, 
and then do some tweaking.

In a git copy I did: 'minidesktop/etc/lightdm.conf 
minidesktop/etc/lightdm.conf.tce'

Then I changed some files like this:

diff --git a/debian/x2gothinclient-minidesktop.install 
b/debian/x2gothinclient-minidesktop.install
index 27b6033..37a2900 100644
--- a/debian/x2gothinclient-minidesktop.install
+++ b/debian/x2gothinclient-minidesktop.install
@@ -1,7 +1,7 @@
 management/share/etc/x2gothinclient-minidesktop_start etc/x2go/
 management/share/etc/x2gothinclient-minidesktop_background.svg 
usr/share/backgrounds/x2go/
 management/share/etc/x2gothinclient_init.d/95*
etc/x2go/x2gothinclient_init.d/
-minidesktop/etc/lightdm.conf etc/lightdm/
+minidesktop/etc/lightdm.conf.tce etc/lightdm/
 minidesktop/etc/restart.lightdm etc/lightdm/
 minidesktop/desktop/x2gothinclient-*.desktop usr/share/applications/
 minidesktop/schema-overrides/* usr/share/glib-2.0/schemas/
diff --git a/debian/x2gothinclient-minidesktop.postinst 
b/debian/x2gothinclient-minidesktop.postinst
index b446610..172747c 100755
--- a/debian/x2gothinclient-minidesktop.postinst
+++ b/debian/x2gothinclient-minidesktop.postinst
@@ -26,6 +26,10 @@ case "$1" in
desktop-background \

/usr/share/backgrounds/x2go/x2gothinclient-minidesktop_background.svg 72
 
+   if [ -f /etc/lightdm/lightdm.conf ]; then
+   mv /etc/lightdm/lightdm.conf 
/etc/lightdm/lightdm.conf.disabled-by-x2gotce
+   fi
+   cp /etc/lightdm/lightdm.conf.tce /etc/lightdm/lightdm.conf
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
diff --git a/debian/x2gothinclient-minidesktop.postrm 
b/debian/x2gothinclient-minidesktop.postrm
index 02ccc76..4be986b 100755
--- a/debian/x2gothinclient-minidesktop.postrm
+++ b/debian/x2gothinclient-minidesktop.postrm
@@ -24,8 +24,9 @@ case "$1" in
if dpkg-divert --list | grep usr/lib/x2go/x2goclient 
1>/dev/null 2>/dev/null; then
dpkg-divert --package x2gothinclient-minidesktop 
--rename --remove /usr/bin/x2goclient
fi
-   if dpkg-divert --list | grep lightdm.conf.disabled-by-x2gotce 
1>/dev/null 2>/dev/null; then
-   dpkg-divert --package x2gothinclient-minidesktop 
--rename --remove /etc/lightdm/lightdm.conf
+   if [ -f /etc/lightdm/lightdm.conf.disabled-by-x2gotce ]; then
+   rm /etc/lightdm/lightdm.conf
+   mv /etc/lightdm/lightdm.conf.disabled-by-x2gotce 
/etc/lightdm/lightdm.conf
fi
;;
upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
diff --git a/debian/x2gothinclient-minidesktop.preinst 
b/debian/x2gothinclient-minidesktop.preinst
index 5bfb315..b7c6f26 100755
--- a/debian/x2gothinclient-minidesktop.preinst
+++ b/debian/x2gothinclient-minidesktop.preinst
@@ -26,9 +26,6 @@ case "$1" in
if ! dpkg-divert --list | grep usr/lib/x2go/x2goclient 
1>/dev/null 2>/dev/null; then
dpkg-divert --add --rename --package 
x2gothinclient-minidesktop --divert /usr/lib/x2go/x2goclient /usr/bin/x2goclient
fi
-   if ! dpkg-divert --list | grep lightdm.conf.disabled-by-x2gotce 
1>/dev/null 2>/dev/null; then
-   dpkg-divert --add --rename --package 
x2gothinclient-minidesktop --divert 
/etc/lightdm/lightdm.conf.disabled-by-x2gotce /etc/lightdm/lightdm.conf
-   fi
;;
abort-upgrade)
;;
diff --git a/debian/x2gothinclient-minidesktop.prerm 
b/debian/x2gothinclient-minidesktop.prerm
index 0f7c483..07d975a 100755
--- a/debian/x2gothinclient-minidesktop.prerm
+++ b/debian/x2gothinclient-minidesktop.prerm
@@ -29,7 +29,10 @@ fi
 
 case "$1" in
remove)
-   :
+   if [ -f /etc/lightdm/lightdm.conf.disabled-by-x2gotce ]; then
+   rm /etc/lightdm/lightdm.conf
+   mv /etc/lightdm/lightdm.conf.disabled-by-x2gotce 
/etc/lightdm/lightdm.conf
+   fi
;;
deconfigure|upgrade|failed-upgrade)
:
 
The x2gothinclient-minidesktop package built with these changes seems to 
work ok, but maybe I have missed some tests; please check.

Wolfgang


signature.asc
Description: PGP signature

Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library

[Andreas Beckmann]

On 06/01/2020 18.19, Giovanni Mascellani wrote:
>> To simplify such future transitions, I created a patch (#948273) to
>> actually make use of the virtual packages introduced in -12.
>> Please include it along with the reintroduction of python2 support in
>> *sid*. Then we can binNMU all rdepends of libboost-python1.67.0,
>> libboost-mpi-python1.67.0, libboost-numpy1.67.0 to add more strict
>> dependencies on the required python support.
> 
> So, if I get this right, the point of binNMU-ing is to make sure that
> all the rev deps choose their versioned dependency, so that when a
> Python version goes away the breakage will be recorded in the packages
> dependencies (and won't be an actual breakage). Is this right?

Yes. Packages depending on (virtual) libboost-python1.67.0-py37 will not
be installable with a libboost-python1.67.0 that no longer provides that
virtual package (and no longer ships the corresponding shared library).
It needs a proper transition (likely part of a future python3.7-rm
transition) to drop these dependencies (in favor of -py38 ones) and get
everything migrated to testing.

> And then you need to have Boost.Python with Python 2.7 back because
> otherwise binNMUs will just fail, right?

Some might fail, some might just drop python2.7 dependencies.
But ...

> If so, then I agree. If not, please explain me, because I am still
> learning this kind of things.
> 
>> For the transition to boost1.71 it would be best if that happens before
>> python3.8 is the only supported python3 and we can thus remove a
>> boost1.67 still supporting python2.7 and python3.7 from sid.
> 
> Why this?

... I'm more worried about smooth upgrades from buster to bullseye.
If we have a libboost-python1.67.0 in testing that is missing features
that were available in buster (worst case bullseye supports only py38,
while buster supports only py27, py37), but that is installable in
buster, it will silently break packages in buster. Even if this only
happens for a short time during the upgrade (new libboost-python1.67.0
gets unpacked, I'm quite sure to run into it in some strange upgrade
path during a piuparts test. ;-)
Therefore it would be best if libboost-python1.67.0 is gone from testing
(e.g. by renaming) before it loses "features" compared to buster.


Andreas

Bug#941365: libimobiledevice 1.2.1~git20181030.92c5462-2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941365 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libimobiledevice
Version: 1.2.1~git20181030.92c5462-2

Explanation: properly handle partial SSL writes

Bug#948305: [Debichem-devel] Bug#948305: avogadro: app dies after launch. problem with shared libraries

[Daniel Leidert]

Am Montag, den 06.01.2020, 21:29 + schrieb André Isidoro Fernandes Esteves:
> Package: avogadro
> Version: 1.2.0-4+b2
> Severity: important

[..]
> app died
> app wrote: avogadro: error while loading shared libraries:
> libboost_python27.so.1.67.0: cannot open shared object file: No such file or
> directory

Due to the removal of Python 2.7 the library mentioned in the message is no
longer provided and avogadro is broken. Due to this avogadro has actually been
removed from the Debian archive temporarily:

https://packages.qa.debian.org/a/avogadro.html
https://alioth-lists.debian.net/pipermail/debichem-devel/2019-December/010629.html

and will be back as soon as avogadro 2 has passed the NEW queue:

https://ftp-master.debian.org/new/avogadro_1.91.0-1.html

Regards, Daniel


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

Bug#948209: follow-up

[Dmitry Smirnov]

On Monday, 6 January 2020 4:40:29 PM AEDT Dave Gomboc wrote:
> I do not understand why the bug is being closed as "Done".

There is not other way to close the ticket.

I've closed it because there is nothing actionable here. If this is an 
upstream bug then it should be addressed upstream. The problem is not a 
problem here on Debian so why do you expect us to help you?

The environment where you have encountered the problem is not supported by 
us. Also IMHO that operating system should never be used to begin with.

This bug have nothing to do with Debian therefore there is no reason to keep 
it opened.

Also closing the bug does not mean that those like yourself who wish to find 
the root cause of the problem are not going to try just because I've closed 
this bug report.

-- 
All the best,
 Dmitry Smirnov.

---

There can be no faith in government if our highest offices are excused from
scrutiny - they should be setting the example of transparency.
-- Edward Snowden


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

Bug#948308: Macro AUTH_SERVER_ALLOW_NOTLS_PASSWORDS ignore true/false

[Brian Wengel]

Package: exim4-daemon-heavy

Version: 4.92-8+deb10u3


I've put the following in macro in "/etc/exim4/conf.d/main/000_localmacros":

It seem the activation on this macro is rather inconsistent:

"AUTH_SERVER_ALLOW_NOTLS_PASSWORDS" >  error
"AUTH_SERVER_ALLOW_NOTLS_PASSWORDS=" > OK

"AUTH_SERVER_ALLOW_NOTLS_PASSWORDS=whatever you write"  > OK


By "error" I mean update-exim4.conf will give following error:

2020-01-06 23:10:49 Exim configuration error in line 21 of
/var/lib/exim4/config.autogenerated.tmp:
  malformed macro definition
Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not
installing
/var/lib/exim4/config.autogenerated.tmp to
/var/lib/exim4/config.autogenerated


Best regards
Brian

Bug#948238: man-db: man produces apparmor kernel warnings

[Colin Watson]

On Sun, Jan 05, 2020 at 02:45:44PM -0500, Bruce Momjian,,, wrote:
> When doing 'man libreoffice' the following kernel messages are generated:
> 
>   [Sun Jan  5 10:28:57 2020] audit: type=1400 audit(1578238128.275:29): 
> apparmor="DENIED" operation="file_inherit" profile="man_groff" 
> name="/var/cache/man/cat1/cattld6Dp" pid=6359 comm="preconv" 
> requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
>   [Sun Jan  5 10:28:57 2020] audit: type=1400 audit(1578238128.275:30): 
> apparmor="DENIED" operation="file_inherit" profile="man_filter" 
> name="/var/cache/man/cat1/cattld6Dp" pid=6364 comm="gzip" requested_mask="w" 
> denied_mask="w" fsuid=0 ouid=0
>   [Sun Jan  5 10:28:57 2020] audit: type=1400 audit(1578238128.279:31): 
> apparmor="DENIED" operation="file_inherit" profile="man_groff" 
> name="/var/cache/man/cat1/cattld6Dp" pid=6360 comm="tbl" requested_mask="wr" 
> denied_mask="wr" fsuid=0 ouid=0
>   [Sun Jan  5 10:28:57 2020] audit: type=1400 audit(1578238128.283:32): 
> apparmor="DENIED" operation="file_inherit" profile="man_groff" 
> name="/var/cache/man/cat1/cattld6Dp" pid=6370 comm="troff" 
> requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
> 
> It appears apparmor doesn't allow writes by these external tools called by 
> 'man'.  The following patch fixes this.
> 
> --- ./usr.bin.man.orig2020-01-05 12:04:13.059106386 -0500
> +++ ./usr.bin.man 2020-01-05 12:06:20.037415963 -0500
> @@ -59,10 +59,10 @@
>/usr/bin/eqn rm,
>/usr/bin/grap rm,
>/usr/bin/pic rm,
> -  /usr/bin/preconv rm,
> +  /usr/bin/preconv rmw,
>/usr/bin/refer rm,
> -  /usr/bin/tbl rm,
> -  /usr/bin/troff rm,
> +  /usr/bin/tbl rmw,
> +  /usr/bin/troff rmw,
>/usr/bin/vgrind rm,
>  
>/etc/groff/** r,
> @@ -82,8 +82,8 @@
># open FDs before execve.
>#include 
>  
> -  /{,usr/}bin/bzip2 rm,
> -  /{,usr/}bin/gzip rm,
> +  /{,usr/}bin/bzip2 rmw,
> +  /{,usr/}bin/gzip rmw,
>/usr/bin/col rm,
>/usr/bin/compress rm,
>/usr/bin/iconv rm,

This patch seems extremely peculiar.  According to apparmor.d(5), this
would allow processes running with this profile to have write access
*to* /usr/bin/preconv etc.  That's definitely not what we want.

There's already "/var/cache/man/** w" in man_filter, and perhaps we need
"/var/cache/man/** rw" or similar in man_groff, although I'd want to
figure out exactly why that's needed and if it's possible to rearrange
things to avoid it.  I admit I don't completely understand
file_inherit's behaviour.

To experiment with this, it should be possible to remove the cat file
(something like /var/cache/man/cat1/libreoffice.1.gz, depending on
exactly what "libreoffice" is resolved to) and re-run.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#948194: RFS: jcc/3.6-1 [ITA] -- generator for a Python extension from Java classes (transitional)

[Emmanuel Arias]

Hi Adam,

El dom., 5 de ene. de 2020 a la(s) 18:40, Adam Borowski
(kilob...@angband.pl) escribió:
>
> On Sun, Jan 05, 2020 at 01:37:20AM -0300, Emmanuel Arias wrote:
> >  * Package name: jcc
> >Version : 3.6-1
>
> > It builds those binary packages:
> >
> >   python-jcc - generator for a Python extension from Java classes (Python 2)
> >   python3-jcc - generator for a Python extension from Java classes (Python 
> > 3)
> >   jcc - generator for a Python extension from Java classes (transitional)
>
> [Note: a trip through binNEW is required.]
>
> > Changes since the last upload:
> >
> >[ Emmanuel Arias ]
> >* New upstream version 3.6
> >* New maintainer (Closes: #922568):
> >  - Add myself to Maintainer field on d/control.
> >* Bump debhelper to 12 (from 9.2):
> >  - Update debhelper to debhelper-compat on d/control Build-Depends.
> >* Update Vcs-* repository to salsa repository.
> >* Add myself on debian/* files copyright on d/copyright.
> >* Bump Standard-Version to 4.4.1
> >* d/control: add autopkgtest-pkg-python
>
> Hi!
> The package has three RC bugs filed against it, and you don't close any of
> them.  These are:
> #875579 FTBFS with Java 9: library path guessed wrong
> #885955 FTBFS: /usr/bin/ld: cannot find -ljvm
> -- both of these are fixed in your upload, but without closing them, the
>package won't be allowed back in

Seems to be closes to 3.0-1. but was never upload [1]. And d/changelog
has a incorrect
release. So, I will remove that entry

>
> #936761 jcc: Python2 removal in sid/bullseye
> -- as there are no reverse {,B-}Rdependencies, there's nothing to preserve
>compatibility for, thus it'd be enough to drop the python-jcc package
>(which you try to introduce!) -- it's not needed, and as the next Debian
>release will not feature Python2[1], would need to be removed shortly
>anyway

This is embarrassing, I was working o remove python 2 support on some packages,
and I try to add it Sorry. Removed.

I've just push to salsa de fix and now I will upload to mentors.d.n

Thanks for the review!

[1] https://salsa.debian.org/debian/jcc/blob/master/debian/changelog#L16
>
> Meow!
>
> [1]. Or, if removal doesn't succeed, Python2 will be trimmed to a stub.
> --
> ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
> ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
> ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
> ⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#948239: adminer not starting

[Alexandre Rossi]

Hi,

> "localhost/adminer" or similar does not start the program = adminer.php file

Can you be more explicit on what you are trying to do? Did you type
localhost/adminer in your browser address bar?

> there is no man page

There usually is no man page for web apps unless they provide cli tools.

> no guidance on setup or configuration

Did you read the basic guidance in
/usr/share/doc/adminer/README.Debian ? I see that you are using
stable, and the stable version lacks some things that make setup
easier. You should either use the backport or see for instance
https://lists.debian.org/debian-user/2019/09/msg00175.html

> on the internet I see people just installing directly into
> /var/www/html?

Which instructions? Where?

This is not a support channel. If you feel there is a bug in adminer,
please rephrase and be more specific on what you were expecting and
how what you did find was not enough. If you need support, please
close this bug, rephrase, be more specific and use one of the numerous
support channels, for instance send a mail to
debian-u...@lists.debian.org

Thank you,

Alex

Bug#948307: openafs-modules-dkms: Compile of the module fails for kernel 5.3.15

[Kai-Martin Knaak]

Package: openafs-modules-dkms
Version: 1.8.4~pre1-1
Severity: important
Tags: newcomer

Dear Maintainer,
the openafs module fails to build for kernel 5.3.15 on my system.

   * What led up to the situation?
   apt upgrade

   * What was the outcome of this action?
   The openafs module failed to build for kernel 5.3.15.
   See the log in the attachment. 
   The module did build for kernel 5.2.17 , though.

   * What outcome did you expect instead?
   The openafs module builds and installs for kernel 5.3.15

The relevant portion of the log seems to be:


(...)
  CC [M]  
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.o
In file included from 
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.c:24:
/var/lib/dkms/openafs/1.8.4pre1/build/src/afs/LINUX/osi_compat.h: In function 
‘afs_linux_search_keyring’:
/var/lib/dkms/openafs/1.8.4pre1/build/src/afs/LINUX/osi_compat.h:225:12: error: 
too few arguments to function ‘keyring_search’
  225 |  key_ref = keyring_search(
  |^~
In file included from 
/usr/src/linux-headers-5.3.0-3-common/include/linux/cred.h:13,
 from 
/usr/src/linux-headers-5.3.0-3-common/include/linux/seq_file.h:12,
 from 
/usr/src/linux-headers-5.3.0-3-common/include/linux/seq_file_net.h:5,
 from 
/usr/src/linux-headers-5.3.0-3-common/include/net/net_namespace.h:186,
 from 
/usr/src/linux-headers-5.3.0-3-common/include/linux/netdevice.h:38,
 from 
/usr/src/linux-headers-5.3.0-3-common/include/net/inet_sock.h:19,
 from 
/usr/src/linux-headers-5.3.0-3-common/include/linux/udp.h:16,
 from 
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/./netinet/udp.h:1,
 from 
/var/lib/dkms/openafs/1.8.4pre1/build/src/rx/rx_kcommon.h:110,
 from 
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.c:20:
/usr/src/linux-headers-5.3.0-3-common/include/linux/key.h:387:18: note: 
declared here
  387 | extern key_ref_t keyring_search(key_ref_t keyring,
  |  ^~
make[5]: *** [/usr/src/linux-headers-5.3.0-3-common/scripts/Makefile.build:286: 
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.o]
 Error 1
make[4]: *** [/usr/src/linux-headers-5.3.0-3-common/Makefile:1639: 
_module_/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP]
 Error 2
make[3]: *** [/usr/src/linux-headers-5.3.0-3-common/Makefile:179: sub-make] 
Error 2
make[3]: Leaving directory '/usr/src/linux-headers-5.3.0-3-amd64'
FAILURE: make exit code 2
make[2]: *** [Makefile.afs:280: openafs.ko] Error 1
make[2]: Leaving directory 
'/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP'
make[1]: *** [Makefile:187: linux_compdirs] Error 2
make[1]: Leaving directory '/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs'
make: *** [Makefile:15: all] Error 2


Hope, this helps fix the problem. 

Best regards, 

---<)kaimartinknaak>---

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
(charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh
linked to /bin/dash Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.8.1-4
ii  libc6-dev  2.29-7
ii  perl   5.30.0-9

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.8.4~pre1-1

openafs-modules-dkms suggests no packages.

-- no debconf information



-- 
Kai-Martin Knaak
kn...@iqo.uni-hannover.de Universität Hannover, Inst. f. Quantenoptik
 tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover
  fax: +49-511-762-2211
https://keyserver.ubuntu.com/pks/lookup?op=get=0xC13AA4CC7B0F9882
DKMS make.log for openafs-1.8.4pre1 for kernel 5.3.0-3-amd64 (x86_64)
Mon  6 Jan 15:55:04 CET 2020
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header 

Bug#948193: e2scrub services delay boot by 2 seconds

[Josh Triplett]

On Mon, 6 Jan 2020 16:14:24 -0500 "Theodore Y. Ts'o"  wrote:
> On Mon, Jan 06, 2020 at 12:39:52AM -0800, Josh Triplett wrote:
> > That's an *additional* delay, on top of the sleeps above. The two-second
> > sleep in the "exitcode" function seems like the primary culprit.  Note
> > that I don't even have lvm2-tools installed.
> 
> Ah, yes, sorry, I had missed the sleep in the exitcode function.
> Actually it's not needed in e2scrub_all at all; it was there due
> copy/paste oversight.
> 
> The commit below should address your concern.

That addresses the two-second sleep in a default install, thank you.

Please also move the entirely commented-out e2scrub.conf to an example
in /usr/share/doc (deleting /etc/e2scrub.conf in postinst if it matches
the current example), and making the timer/service use
ConditionPathExists=/etc/e2scrub.conf, which will avoid running the
service at all.

- Josh Triplett

Bug#948283: tinyproxy: If no PidFile is configured logrotate will change the owner of the root directory

[Salvatore Bonaccorso]

Hi Tim,

[Dislaimer: not the maintainer here, just looked at it briefly]

On Mon, Jan 06, 2020 at 02:44:48PM +0100, Tim Duesterhus wrote:
> Package: tinyproxy
> Version: 1.10.0-2
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> I configured tinyproxy without a PidFile.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I removed the PidFile configuration option from tinyproxy.conf
> 
>* What was the outcome of this action?
> 
> The next run of logrotate changed the owner and group of my root
> directory (`/`) to tinyproxy:tinyproxy.
> 
>* What outcome did you expect instead?
> 
> I expected that not to happen.
> 
> Example demonstrating the issue in a fresh VM:
> 
> root@debian-2gb-fsn1-1:~# stat /
>   File: /
>   Size: 4096  Blocks: 8  IO Block: 4096   directory
> Device: 801h/2049dInode: 2   Links: 18
> Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
> Access: 2019-12-08 05:11:02.514309382 +0100
> Modify: 2020-01-06 01:51:41.52400 +0100
> Change: 2020-01-06 01:51:41.52400 +0100
>  Birth: -
> root@debian-2gb-fsn1-1:~# apt-get install - tinyproxy
> Selecting previously unselected package tinyproxy-bin.
> (Reading database ... 35006 files and directories currently installed.)
> Preparing to unpack .../tinyproxy-bin_1.10.0-2_amd64.deb ...
> Unpacking tinyproxy-bin (1.10.0-2) ...
> Selecting previously unselected package tinyproxy.
> Preparing to unpack .../tinyproxy_1.10.0-2_all.deb ...
> Unpacking tinyproxy (1.10.0-2) ...
> Setting up tinyproxy-bin (1.10.0-2) ...
> Setting up tinyproxy (1.10.0-2) ...
> Created symlink /etc/systemd/system/multi-user.target.wants/tinyproxy.service 
> → /lib/systemd/system/tinyproxy.service.
> Processing triggers for man-db (2.8.5-2) ...
> Processing triggers for systemd (241-7~deb10u2) ...
> root@debian-2gb-fsn1-1:~# grep PidFile /etc/tinyproxy/tinyproxy.conf
> # PidFile: Write the PID of the main tinyproxy thread to this file so it
> PidFile "/run/tinyproxy/tinyproxy.pid"
> root@debian-2gb-fsn1-1:~# sed -i '/PidFile/d' /etc/tinyproxy/tinyproxy.conf
> root@debian-2gb-fsn1-1:~# grep PidFile /etc/tinyproxy/tinyproxy.conf
> root@debian-2gb-fsn1-1:~# systemctl start logrotate
> root@debian-2gb-fsn1-1:~# sed -i 's/2020/2019/g' /var/lib/logrotate/status
> root@debian-2gb-fsn1-1:~# systemctl start logrotate
> root@debian-2gb-fsn1-1:~# stat /
>   File: /
>   Size: 4096  Blocks: 8  IO Block: 4096   directory
> Device: 801h/2049dInode: 2   Links: 18
> Access: (0755/drwxr-xr-x)  Uid: (  106/tinyproxy)   Gid: (  112/tinyproxy)
> Access: 2019-12-08 05:11:02.514309382 +0100
> Modify: 2020-01-06 01:51:41.52400 +0100
> Change: 2020-01-06 01:53:05.254019354 +0100
>  Birth: -
> 
> Note that tinyproxy does not start up with this configuration, because systemd
> expects the PidFile to appear. For the machine where I noticed this issue I 
> also
> adjusted the systemd unit to be of `Type=simple`.
> 
> While this configuration might not be common and not encountered by the 
> average
> user it introduced a possible security hole in my system and even if this 
> might
> not be fully exploitable by the `tinyproxy` user it breaks systemd-tmpfiles:
> 
> Jan 06 01:57:53 debian-2gb-fsn1-1 systemd-tmpfiles[282]: Detected unsafe path 
> transition / → /var during canonicalization of /var.

I think the whole problem is placed at multiple levels. You seem to
use systemd as init, but when lgorotate comes into action, the
postrotate is

invoke-rc.d --quiet tinyproxy reload > /dev/null

As tinyproxy.service can't reload the service through the .service
file, it will fallback into reloading tinyproxy via the init-script:

[...]
# assert pidfile directory and permissions
if [ "$1" != "stop" ]; then
if [ -f "$CONFIG" ]; then
USER=$(grep-i '^User[[:space:]]'"$CONFIG" | awk '{print $2}')
GROUP=$(grep   -i '^Group[[:space:]]'   "$CONFIG" | awk '{print $2}')
PIDFILE=$(grep -i '^PidFile[[:space:]]' "$CONFIG" | awk '{print $2}' |\
  sed -e 's/"//g')
PIDDIR=`dirname "$PIDFILE"`
if [ -n "$PIDDIR" -a "$PIDDIR" != "/run" ]; then
if [ ! -d "$PIDDIR" ]; then
mkdir "$PIDDIR"
fi
if [ "$USER" ]; then
chown "$USER" "$PIDDIR"
fi
if [ "$GROUP" ]; then
chgrp "$GROUP" "$PIDDIR"
fi
fi
fi
fi
[...]

PIDDIR will be ".", and the chown and chgrp will be applied to the
current working directory.

The current working directory is changed to /, and thus the chown and
chgrp call upon '.' will affect /.
> 
> Thus I feel the severity of `critical` is justified for this bug report.

I'm not sure this is warranted, but I will leave this to the decision
of the maintainer :)

Regards,
Salvatore

Bug#947882: had gone the same warning at my end too -

[shirish शिरीष]

Dear all,
Had got the same issue at my end as well. The same syntax version
statements as shared by Chrstian Cottsche , Maybe somebody can like to
the upstream commit which fixed the issue upstream.


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#948305: avogadro: app dies after launch. problem with shared libraries

[André Isidoro Fernandes Esteves]

Package: avogadro
Version: 1.2.0-4+b2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

trying to run avogadro

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

nothing

   * What was the outcome of this action?

app died
app wrote: avogadro: error while loading shared libraries: 
libboost_python27.so.1.67.0: cannot open shared object file: No such file or 
directory

   * What outcome did you expect instead?

running app

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


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages avogadro depends on:
ii  libavogadro1   1.2.0-4+b2
ii  libc6  2.29-8
ii  libgcc11:9.2.1-22
ii  libopenbabel5  2.4.1+dfsg-6
ii  libqt4-opengl  4:4.8.7+dfsg-19
ii  libqtcore4 4:4.8.7+dfsg-19
ii  libqtgui4  4:4.8.7+dfsg-19
ii  libstdc++6 9.2.1-22
ii  libx11-6   2:1.6.8-1

Versions of packages avogadro recommends:
ii  avogadro-data  1.2.0-4

avogadro suggests no packages.

-- no debconf information

Bug#941365: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2

[Adam D. Barratt]

On Sat, 2019-12-21 at 10:59 +0100, Yves-Alexis Perez wrote:
> On Sat, 2019-12-07 at 20:11 +, Adam D. Barratt wrote:
> > > Sorry, I replied to the wrong bug. I'll upload the isolated fix
> > > soon,
> > > likely this weekend, thanks.
> > 
> > Just to keep this up-to-date, the libimobiledevice upload made it
> > to sid, but is blocked by python3-plist needing to make it out of
> > NEW.
> 
> Hi, just to be sure: 1.2.1~git20181030.92c5462-2 won't be able to
> enter buster-pu before the sid uploads makes it to testing (so when
> python3-plist gets out of NEW and migrates as well)?

It's not particularly being in testing, but we do tend to want fixes to
be happy in unstable first - for several reasons, including the fact
that uploads to unstable get much more exposure much more quickly and
it's much easier to fix issues there quickly.

I can see that the situation seems to have resolved itself in the
meantime; sorry for not having spotted that sooner.

Regards,

Adam

Bug#948306: ucblogo: Consider adding a .desktop file to have program shown in launchers

[Boyuan Yang]

Package: ucblogo
Version: 6.1-0.1
Severity: wishlist

Dear ucblogo maintainer,

I believe it should be reasonable if we ship a desktop file so that the icon
of ucblogo can be shown in DE Launchers. The file could be like this
(debian/ucblogo.desktop):

[Desktop Entry]
Version=1.0
Name=Berkeley Logo
GenericName=UCBLogo
Exec=/usr/bin/ucblogo
Icon=ucblogo
Type=Application
Categories=Education;Development;
Keywords=Logo;Programming;

Please consider adding it in the packaging repo. I'm putting the proposed file
into public-domain in case you need a license information.

-- 
Thanks,
Boyuan Yang


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

Bug#948304: also ship an austin-tui binary

[Antoine Beaupre]

Package: austin
Version: 1.0.0-1
Severity: wishlist

Could we get more of the goodies shipped with austin?

The default output is not exactly useful, as it requires
flamegraph.pl, which doesn't seem packaged as a standalone binary in
Debian.

(Well, technically, there's a version of flamegraph.pl available in
libdevel-nytprof-perl, but that's kind of hard to discover, and its
output is not as useful as the other stuff austin has.)

There's also a web interface, although I'd be happy just with the tui
interface.

Thanks!

-- System Information:
Debian Release: 10.2
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages austin depends on:
ii  libc6  2.28-10

austin recommends no packages.

austin suggests no packages.

-- debconf-show failed

Bug#948302: mmdebstrap autopkgtest fails on arm64 while it should probably return neutral

[Johannes Schauer]

Hi Paul,

Quoting Paul Gevers (2020-01-06 21:38:56)
> The autopkgtest of mmdebstrap fails on arm64 with the following message:
> """
> script only supports being run on amd64
> """
> 
> You should fix the failure. If you don't want to spend time on making
> the script work on non-amd64, than at least mark your test with the
> "skippable" restriction and exit with exit code 77 on non-amd64. That
> way the non-successful autopkgtest will be treated as a non-failure.

thanks for the tip! Indeed I did not know how to skip tests on a certain
architecture. I was looking for something like an architecture restriction for
tests. I forgot that tests can be made skippable with the magic exit code.

The good news though is, that I already modified the tests such that they
should also work on non amd64 architectures. We will see if I was successful on
my next upload. :)

Thanks again!

cheers, josch


signature.asc
Description: signature

Bug#948193: e2scrub services delay boot by 2 seconds

[Theodore Y. Ts'o]

On Mon, Jan 06, 2020 at 12:39:52AM -0800, Josh Triplett wrote:
> That's an *additional* delay, on top of the sleeps above. The two-second
> sleep in the "exitcode" function seems like the primary culprit.  Note
> that I don't even have lvm2-tools installed.

Ah, yes, sorry, I had missed the sleep in the exitcode function.
Actually it's not needed in e2scrub_all at all; it was there due
copy/paste oversight.

The commit below should address your concern.

Cheers,

- Ted

commit 0b3208958eb63df6cd8b38ee63f3bc4266a683e7
Author: Theodore Ts'o 
Date:   Mon Jan 6 16:01:23 2020 -0500

e2scrub, e2scrub_all: don't sleep unnecessarily in exitcode

The two second sleep is only needed in e2scrub, and when there is a
failure, so that systemd has a chance to gather the log output before
e2scrub exits.  It's not needed if the script is exiting successfully,
and it's never needed for e2scrub_all ever.

Addresses-Debian-Bug: #948193
Signed-off-by: Theodore Ts'o 

diff --git a/scrub/e2scrub.in b/scrub/e2scrub.in
index f21499b6..30ab7cbd 100644
--- a/scrub/e2scrub.in
+++ b/scrub/e2scrub.in
@@ -66,7 +66,7 @@ exitcode() {
# for capturing all the log messages if the scrub fails, because the
# fail service uses the service name to gather log messages for the
# error report.
-   if [ -n "${SERVICE_MODE}" ]; then
+   if [ -n "${SERVICE_MODE}" -a "${ret}" -ne 0 ]; then
test "${ret}" -ne 0 && ret=1
sleep 2
fi
diff --git a/scrub/e2scrub_all.in b/scrub/e2scrub_all.in
index f0336711..4288b969 100644
--- a/scrub/e2scrub_all.in
+++ b/scrub/e2scrub_all.in
@@ -56,14 +56,8 @@ exitcode() {
# section 22.2) and hope the admin will scan the log for what
# actually happened.
 
-   # We have to sleep 2 seconds here because journald uses the pid to
-   # connect our log messages to the systemd service.  This is critical
-   # for capturing all the log messages if the scrub fails, because the
-   # fail service uses the service name to gather log messages for the
-   # error report.
-   if [ -n "${SERVICE_MODE}" ]; then
+   if [ -n "${SERVICE_MODE}" -a "${ret}" -ne 0 ]; then
test "${ret}" -ne 0 && ret=1
-   sleep 2
fi
 
exit "${ret}"

Bug#938489: sinntp: diff for NMU version 1.6-0.2

[Adrian Bunk]

Dear maintainer,

I've prepared an NMU for sinntp (versioned as 1.6-0.2) and uploaded
it to DELAYED/5. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru sinntp-1.6/debian/changelog sinntp-1.6/debian/changelog
--- sinntp-1.6/debian/changelog	2019-12-26 08:55:37.0 +0200
+++ sinntp-1.6/debian/changelog	2020-01-06 21:33:26.0 +0200
@@ -1,3 +1,11 @@
+sinntp (1.6-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert the autopkgtest to Python 3.
+  * Remove the old homepage from debian/copyright.
+
+ -- Adrian Bunk   Mon, 06 Jan 2020 21:33:26 +0200
+
 sinntp (1.6-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sinntp-1.6/debian/copyright sinntp-1.6/debian/copyright
--- sinntp-1.6/debian/copyright	2012-04-18 23:45:21.0 +0300
+++ sinntp-1.6/debian/copyright	2020-01-06 21:33:26.0 +0200
@@ -2,7 +2,6 @@
 Upstream-Name: sinntp
 Upstream-Contact: Piotr Lewandowski 
   Jakub Wilk 
-Source: http://sinntp.googlecode.com/
 
 Files: *
 Copyright: 2008-2012, Piotr Lewandowski 
diff -Nru sinntp-1.6/debian/tests/tests sinntp-1.6/debian/tests/tests
--- sinntp-1.6/debian/tests/tests	2012-04-19 00:09:33.0 +0300
+++ sinntp-1.6/debian/tests/tests	2020-01-06 21:33:14.0 +0200
@@ -1,8 +1,8 @@
 #!/bin/sh
-pyversions -i \
+py3versions -i \
 | tr ' ' '\n' \
 | xargs -t -I {} env {} -c "
 import sys
 sys.path[0:0] = ['/usr/share/sinntp/']
-execfile('tests.py')
+exec(open('tests.py').read())
 " --verbose

Bug#948104: buster-pu: package python3.7/3.7.3-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-01-03 at 22:56 +0100, Moritz Muehlenhoff wrote:
> Similar to the python2.7 update which landed in Buster 10.2. Debdiff
> below. All these are fixed in bullseye/sid (but none had a dedicated
> bug)
> 

Please go ahead.

Regards,

Adam

Bug#710009: /usr/bin/zbarimg: Decoding binary data fails

[วรัญญา ฮ่วนเส้ง]

On Mon, 27 May 2013 14:26:06 +0100 Sam Morris wrote: > Package: zbar-tools
> Version: 0.10+doc-8 > Severity: normal > File: /usr/bin/zbarimg > >
-BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > $ gpg
--export-secret-key 5EA01078 | paperkey --output-type raw | ascii85 |
qrencode -8 -o key.png > $ zbarimg key.png > QR-Code: > scanned 1 barcode
symbols from 1 images in 0.1 seconds > > The image can be decoded with
qtqr, so I am assuming qrencode is doing > the right thing here. I'm only
99�sure because, while qtqr is not able > to save the decoded data in
uninterpreted form anywhere, it doesn't > indicate an error while decoding.
> > - -- System Information: > Debian Release: jessie/sid > APT prefers
testing > APT policy: (540, 'testing'), (530, 'unstable'), (520,
'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures:
i386 > > Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG

Bug#821254: systemd[1]: xendomains.service start operation timed out.

[Hans van Kranenburg]

Hi,

On 1/3/20 5:42 PM, Martin Maney wrote:
> 
> [...]
> 
> Yes, the shutdown hang is a different issue, but I'm going to hope that
> the real systemd units mentioned in this bug will fix my problem, too.

What you could do already now is try testing those scripts, just
shutting down and starting up the domUs, without actually rebooting the
machine. By doing so we can learn if we could use them as a drop in
replacement or not.

The xendomains init script that we have in Debian is:

https://salsa.debian.org/xen-team/debian-xen/blob/master/debian/xen-utils-common.xendomains.init

The upstream one (which is quite a bit different) is:

https://salsa.debian.org/xen-team/debian-xen/blob/master/tools/hotplug/Linux/xendomains.in

Or, it seems that last one gets installed in a location for helper
scripts and it's just called from both the init.d script and the systemd
service:

https://salsa.debian.org/xen-team/debian-xen/blob/master/tools/hotplug/Linux/init.d/xendomains.in

https://salsa.debian.org/xen-team/debian-xen/blob/master/tools/hotplug/Linux/systemd/xendomains.service.in

It would be really helpful if you would want to spend some time on this.

Speaking for myself, I either deal with clusters and using live migrate
to empty a server before shutting it down, or otherwise I rather have my
own way to carefully shut down things before typing a reboot command,
combined with a molly-guard script to prevent accidental reboots while
something is still running. That way there's still an option to
debug/salvage a misbehaving domU before shutdown.

Hans

Bug#948219: stretch-pu: package ros-ros-comm/1.12.6-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-01-05 at 15:53 +0100, Jochen Sprickerhof wrote:
> The ros-ros-comm version in stretch is affected by two new CVEs:
> CVE-2019-13465 and CVE-2019-13445. The first one was already fixed by
> 1.12.6-2+deb9u1, cf. #945944, but the second one is new. The attached
> patch is against 1.12.6-2+deb9u1 and also adopts the changelog to
> mention the second CVE.
> 

Please go ahead.

Regards,

Adam

Bug#945896: buster-pu: package ros-ros-comm/1.14.3+ds1-5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-01-05 at 15:40 +0100, Jochen Sprickerhof wrote:
> Two more CVEs where published, please find a new patch attached.

Please go ahead; thanks.

Regards,

Adam

Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library

[Andreas Beckmann]

On 06/01/2020 15.20, Dimitri John Ledkov wrote:
>> Please include it along with the reintroduction of python2 support in
>> *sid*. Then we can binNMU all rdepends of libboost-python1.67.0,
>> libboost-mpi-python1.67.0, libboost-numpy1.67.0 to add more strict
>> dependencies on the required python support.
> 
> I can see value in binNMU of rdepends such that boost-python3 using
> apps get the right right versioned 3.x deps.
> 
> But I'm struggling to understand what reintroducing python2 support in
> *sid* aims to achieve, given that python2 support is to be removed
> from *both* testing _and_ sid.

This would be easiest and quickest solution for the current problems
while better options are implemented.

> On upgrades, the old boost-python from stable will remain installed on
> users systems, or get autoremoved.

For that to work, libboost-python1.67.0 and friends need to be gone from
sid (e.g. by renaming). Right now the version in sid has less features
than the ones in stable and testing, but that is not reflected in
dependencies.

> I'd rather rename boost-python package to boost-python3 with virtual
> versioned 3.x provides, without reintroducing python2 support and
> simply leaving the old boost-python as NBS.
> 
>>
>> For the transition to boost1.71 it would be best if that happens before
>> python3.8 is the only supported python3 and we can thus remove a
>> boost1.67 still supporting python2.7 and python3.7 from sid.
>>
>> In the unlikely event that bullseye should ship boost1.67 (along 1.71+),
>> we need to reinvestigate this to ensure partial upgrades from buster to
>> bullseye don't break anything. Probably renaming the three binary
>> packages to get a -python3 suffix would be easiest.
> 
> Why not just do this now? I'd rather wait in the ftp-master NEW queue
> today, than at some point in the future.

It would be a valid solution to the current issue, too. I just thought
we could avoid a probably unnneccessary transition.

Andreas

Bug#948303: ITP: aionotify -- Simple, asyncio-based inotify library for Python

[Adam Cecile]

Package: wnpp
Severity: wishlist
Owner: Adam Cecile 

* Package name: aionotify
  Version : 0.2.0
  Upstream Author : The aionotify project 
* URL : https://github.com/rbarrois/aionotify
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Simple, asyncio-based inotify library for Python

Asyncio library to create watchers on filesystem using inotify API
and generate events from changes.

I intend to maintain this package as part of the DPMT.

Bug#948302: mmdebstrap autopkgtest fails on arm64 while it should probably return neutral

[Paul Gevers]

Source: mmdebstrap
Version: 0.5.1-2
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: alwaysfails

Hi josch,

The autopkgtest of mmdebstrap fails on arm64 with the following message:
"""
script only supports being run on amd64
"""

You should fix the failure. If you don't want to spend time on making
the script work on non-amd64, than at least mark your test with the
"skippable" restriction and exit with exit code 77 on non-amd64. That
way the non-successful autopkgtest will be treated as a non-failure.

Thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Salvatore Bonaccorso]

Merge request at
https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/23
with Marco's patch.

Regards,
Salvatore

Bug#808419: copyright

[Dieter Adriaenssens]

No worries, thanks for the update!

Kind regards,

Dieter Adriaenssens

Op zo 5 jan. 2020 21:30 schreef Otto Kekäläinen :

> Updating bug status:
> - This was filed as a pull request at
> https://github.com/ottok/mariadb-10.0/pull/46
> - I plan to finalize this for the mariadb-10.4 cycle.
>
> I am terribly sorry I was not able to finalize this in due time.
>

Bug#948299: osc-plugins-dput: Doesn't work with Python 3 version of osc

[Andrej Shadura]

Control: tag -1 pending

Hi,

On Mon, 6 Jan 2020 at 21:15, Simon McVittie  wrote:
> I attach a possible patch, although this seems to have been fixed
> differently upstream.

Thanks for the patch, I was going to roll an upstream tarball and
upload it to Debian, you shouldn’t have spent effort on this, but
thanks anyway :)

-- 
Cheers,
  Andrej

Bug#948301: libkmod2: update-initramfs fails in lookup_builtin_file()

[Ben Caradoc-Davies]

Package: libkmod2
Version: 26+20191223-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

upgrading:

   kmod (26-3 => 26+20191223-1)
   libkmod-dev (26-3 => 26+20191223-1)
   libkmod2 (26-3 => 26+20191223-1)

fails with:

[...]
Preparing to unpack .../libkmod-dev_26+20191223-1_amd64.deb ...
Unpacking libkmod-dev:amd64 (26+20191223-1) over (26-3) ...
Preparing to unpack .../kmod_26+20191223-1_amd64.deb ...
Unpacking kmod (26+20191223-1) over (26-3) ...
Preparing to unpack .../libkmod2_26+20191223-1_amd64.deb ...
Unpacking libkmod2:amd64 (26+20191223-1) over (26-3) ...
Setting up libkmod2:amd64 (26+20191223-1) ...
Setting up kmod (26+20191223-1) ...
update-initramfs: deferring update (trigger activated)
Setting up libkmod-dev:amd64 (26+20191223-1) ...
Processing triggers for systemd (244-3) ...
Processing triggers for man-db (2.9.0-2) ...
Processing triggers for libc-bin (2.29-8) ...
Processing triggers for initramfs-tools (0.135) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-1-amd64
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open
builtin file
'/var/tmp/mkinitramfs_TvElE8/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
[line repeats hundreds of times]

Workaround is to downgrade these three packages to 26-3, which triggers a
successful update-initramfs. Failure is repeatable.



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

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

Versions of packages libkmod2 depends on:
ii  libc6  2.29-8
ii  liblzma5   5.2.4-1+b1
ii  libssl1.1  1.1.1d-2

libkmod2 recommends no packages.

libkmod2 suggests no packages.

-- no debconf information

Bug#948300: python3-m2crypto: assumes "some_string is ''" will give the same answer as "some_string == ''"

[Simon McVittie]

Package: python3-m2crypto
Version: 0.31.0-8
Severity: normal

> Preparing to unpack .../python3-m2crypto_0.31.0-8_amd64.deb ...
> Unpacking python3-m2crypto (0.31.0-8) ...
> Setting up python3-m2crypto (0.31.0-8) ...
> /usr/lib/python3/dist-packages/M2Crypto/X509.py:44: SyntaxWarning: "is not" 
> with a literal. Did you mean "!="?
>   value.strip('0123456789abcdefABCDEF:') is not '':

"foo is bar" compares object identity, like "foo == bar" in C.

"foo == bar" compares object contents, like "strcmp (foo, bar) == 0" (or
whatever is the appropriate comparison function for the pointers foo
and bar) in C.

In CPython, empty strings have historically been interned, so "foo is ''"
will return True for any empty string foo; but this is not an API
guarantee, and this check will do the wrong thing if empty strings are
not interned (not the same object) in some future version of Python.

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-m2crypto depends on:
ii  libc6  2.29-7
ii  libssl1.1  1.1.1d-2
ii  python33.7.5-3

python3-m2crypto recommends no packages.

Versions of packages python3-m2crypto suggests:
pn  m2crypto-doc  

-- no debconf information

Bug#948299: osc-plugins-dput: Doesn't work with Python 3 version of osc

[Simon McVittie]

Package: osc-plugins-dput
Version: 20180227.1-1
Severity: grave
Justification: renders package unusable
Tags: patch upstream

$ osc -A xxx dput xxx:xxx ~/tmp/build-area/xxx_source.changes
Traceback (most recent call last):
  File "/usr/bin/osc", line 41, in 
r = babysitter.run(osccli)
...
  File "/usr/lib/osc-plugins/dput.py", line 30, in do_dput
osc_plugins_dput.do_dput(self, subcmd, opts, proj_name, dsc_file)
  File "/usr/share/osc-plugins-dput/osc_plugins_dput.py", line 161, in do_dput
package_list = osc.core.meta_get_packagelist(conf.config['apiurl'], 
dput.PROJECT_NAME)
  File "/usr/lib/python3/dist-packages/osc/core.py", line 3442, in 
meta_get_packagelist
u = makeurl(apiurl, ['source', prj], query)
  File "/usr/lib/python3/dist-packages/osc/core.py", line 3316, in makeurl
return urlunsplit((scheme, netloc, '/'.join([path] + list(l)), query, ''))
TypeError: sequence item 2: expected str instance, bytes found

and with that fixed:

$ osc -A xxx dput xxx:xxx ~/tmp/build-area/xxx_source.changes
Traceback (most recent call last):
  File "/usr/bin/osc", line 41, in 
r = babysitter.run(osccli)
...
  File "/usr/lib/osc-plugins/dput.py", line 30, in do_dput
osc_plugins_dput.do_dput(self, subcmd, opts, proj_name, dsc_file)
  File "/usr/share/osc-plugins-dput/osc_plugins_dput.py", line 170, in do_dput
dput._create_package()
  File "/usr/share/osc-plugins-dput/osc_plugins_dput.py", line 84, in 
_create_package
osc.core.createPackageDir(self.PACKAGE_NAME)
  File "/usr/lib/python3/dist-packages/osc/core.py", line 7078, in 
createPackageDir
if is_project_dir(prj_dir):
  File "/usr/lib/python3/dist-packages/osc/core.py", line 3088, in 
is_project_dir
return os.path.exists(os.path.join(d, store, '_project')) and not \
  File "/usr/lib/python3.7/posixpath.py", line 94, in join
genericpath._check_arg_types('join', a, *p)
  File "/usr/lib/python3.7/genericpath.py", line 155, in _check_arg_types
raise TypeError("Can't mix strings and bytes in path components") from None
TypeError: Can't mix strings and bytes in path components

I attach a possible patch, although this seems to have been fixed
differently upstream.

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages osc-plugins-dput depends on:
ii  osc 0.167.1-1
ii  python3-debian  0.1.36

osc-plugins-dput recommends no packages.

osc-plugins-dput suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/osc-plugins-dput/osc_plugins_dput.py (from 
osc-plugins-dput package)
>From 343315308c7ed9f7f3635be30766c9a8a06581f9 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 6 Jan 2020 20:02:14 +
Subject: [PATCH] Be compatible with Python 3 osc

---
 osc_plugins_dput.py | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/osc_plugins_dput.py b/osc_plugins_dput.py
index f54b4f0..dbdb066 100644
--- a/osc_plugins_dput.py
+++ b/osc_plugins_dput.py
@@ -6,6 +6,7 @@ import os
 import osc.cmdln as cmdln
 import osc.conf as conf
 import osc.core
+import sys
 
 try:
 from debian.deb822 import Changes, Dsc
@@ -126,12 +127,21 @@ class DPut(object):
 
 return fileList
 
+
+if sys.version_info[0] >= 3:
+def str_cast(s):
+return s
+else:
+def str_cast(s):
+return s.encode('utf-8')
+
+
 @cmdln.option('--maintained-in-git', action='store_true',
   help='add MAINTAINED_IN_GIT.txt')
 def do_dput(self, subcmd, opts, proj_name, dsc_or_changes_file):
 dput = DPut()
 
-dput.PROJECT_NAME = proj_name.encode("utf8")
+dput.PROJECT_NAME = str_cast(proj_name)
 dput.WORKING_DIR = tempfile.mkdtemp('_oscdput')
 def cleanup(dirname, initdir):
 os.chdir(initdir)
@@ -144,8 +154,8 @@ def do_dput(self, subcmd, opts, proj_name, dsc_or_changes_file):
 # get debian .change object before moving current path to the
 # working_dir
 changes, dsc, dsc_file = _get_objects_from_file(dsc_or_changes_file)
-dput.PACKAGE_NAME = dsc.get("Source").encode('utf8') # XXX: needs to be utf8!!!
-dput.PACKAGE_VERSION = dsc.get("Version")
+dput.PACKAGE_NAME = str_cast(dsc.get("Source"))
+dput.PACKAGE_VERSION = str_cast(dsc.get("Version"))
 
 # Filenames in the .dsc are relative to the directory where it appears.
 # We need to make it absolute before we chdir elsewhere.
-- 
2.25.0.rc0

Bug#945595: Wrong bug number?

[Mateusz Łukasik]

W dniu 21.12.2019 o 11:27, Graham Inggs pisze:

Hi, does this message have the wrong bug number?


To: cont...@bugs.debian.org
From: Mateusz Łukasik 
Subject: Re: New mpv in sid breaks smplayer
Message-ID: <8d5a8d18-b29a-179f-4701-b97226937...@linuxmint.pl>
Date: Thu, 12 Dec 2019 08:56:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
  Thunderbird/68.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Greylist: delayed 371 seconds by postgrey-1.36 at buxtehude; Thu, 12
Dec 2019 08:02:26 UTC
Delivered-To: cont...@bugs.debian.org

fixed 940919 19.10.2~ds0-1
thanks



Hi,

yes, my mistake.

--
 .''`.  Mateusz Łukasik
: :' :  https://l0calh0st.pl
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#686141: patch to add stdin support to galax-run

[Christopher Cramer]

The following patch adds support for reading from standard input
when - is given as an argument.

diff -ur a/galax-1.1/toplevel/galax-run.ml b/galax-1.1/toplevel/galax-run.ml
--- a/galax-1.1/toplevel/galax-run.ml   2007-10-26 08:49:33.0 -0700
+++ b/galax-1.1/toplevel/galax-run.ml   2020-01-06 10:48:27.635953915 -0800
@@ -77,13 +77,17 @@
 print_processing_file mod_file;
 let (ext_ctxt_item,ext_ctxt) = set_up_external_context proc_ctxt in
 (* Load main module *)
+let input = match mod_file with
+  "-" -> Galax_io.Channel_Input stdin
+  | filename -> Galax_io.File_Input filename
+in
 let (mod_ctxt'', stmts) =
   match !context_file with
   | None ->
- compile_main_module_helper ext_ctxt_item mod_ctxt 
(Galax_io.File_Input mod_file)
+ compile_main_module_helper ext_ctxt_item mod_ctxt input
   | Some f ->
  let compiled_program = Galax.import_prolog_only mod_ctxt 
ext_ctxt_item (Galax_io.File_Input f) in
- compile_main_module_helper false compiled_program 
(Galax_io.File_Input mod_file)
+ compile_main_module_helper false compiled_program input
 in
 
 (* Evaluate all global variables *)
diff -ur a/galax-1.1/toplevel/top_options.ml b/galax-1.1/toplevel/top_options.ml
--- a/galax-1.1/toplevel/top_options.ml 2007-10-26 08:49:33.0 -0700
+++ b/galax-1.1/toplevel/top_options.ml 2020-01-06 11:13:01.339877090 -0800
@@ -963,6 +963,13 @@
   let (parse_list,real_usage) = 
 make_parse_list bos usage option_list true
   in
+  let parse_list =
+(
+  "-",
+  Arg.Unit (function () -> args := "-" :: !args),
+  "read module from standard input"
+) :: parse_list
+  in
   begin
 Arg.parse parse_list (fun arg -> args := arg :: !args) real_usage;
 !args

Bug#948298: linux-image-5.3.0-0.bpo.2-armmp: please enable armada 38x comphy driver for armmp

[Josua Mayer]

Package: src:linux
Version: 5.3.9-2~bpo10+1sr1
Severity: normal
Tags: patch

Dear Maintainer,

As of Linux v5.1 a special comphy driver was introduced for Armada 38x SoCs.
It is actively referenced by the dts for the Clearfog Base and Clearfog Pro -
and used by the new Clearfog GTR (which has its device-tree posted to lkml in 
v3).

Please enable this driver as a module for the armmp kernel flavour.
I am attaching the patch to enable this module - and the dmesg of when I 
verified that
the resulting kernel works as expected.

Also, it would be nice if this change could make it into buster-backports ;)

Yours sincerely
Josua Mayer

-- Package-specific info:
** Version:
Linux version 5.3.0-0.bpo.2-armmp (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 5.3.9-2~bpo10+1sr1 (2020-01-06)

** Command line:
  console=ttyS0,115200 log_level=7 net.ifnames=0

** Not tainted

** Kernel log:

** Model information
[6.952015] usb 4-1: Manufacturer: TOSHIBA
[6.956130] usb 4-1: SerialNumber: 0E70657012733A39
[6.967191] usb-storage 4-1:1.0: USB Mass Storage device detected
[6.973990] scsi host4: usb-storage 4-1:1.0
[6.978439] usbcore: registered new interface driver usb-storage
[6.985921] usbcore: registered new interface driver uas
[6.986841] libphy: mdio: probed
[7.118832] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[7.181531] libphy: mdio: probed
[7.299011] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[7.352811] libphy: mdio: probed
[7.478658] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[7.541070] libphy: mdio: probed
[7.655533] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[7.716804] libphy: mdio: probed
[7.832195] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[7.895216] libphy: mdio: probed
[8.004389] scsi 4:0:0:0: Direct-Access TOSHIBA  TransMemory  5.00 
PQ: 0 ANSI: 0 CCS
[8.017642] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[8.026886] sd 4:0:0:0: [sda] 2013184 512-byte logical blocks: (1.03 GB/983 
MiB)
[8.034467] sd 4:0:0:0: [sda] Write Protect is off
[8.039301] sd 4:0:0:0: [sda] Mode Sense: 23 00 00 00
[8.039469] sd 4:0:0:0: [sda] No Caching mode page found
[8.044814] sd 4:0:0:0: [sda] Assuming drive cache: write through
[8.054320]  sda: sda1
[8.058169] sd 4:0:0:0: [sda] Attached SCSI removable disk
[8.080803] libphy: mdio: probed
[8.212177] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[8.275624] libphy: mdio: probed
[8.397802] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[8.460802] libphy: mdio: probed
[8.580273] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[8.643294] libphy: mdio: probed
[8.763092] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[8.830193] libphy: mdio: probed
[8.900734] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[8.967203] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[9.028725] libphy: mdio: probed
[9.110343] mv88e6085 f1072004.mdio-mii:04: switch 0x3900 detected: Marvell 
88E6390, revision 1
[9.141298] Not activating Mandatory Access Control as /sbin/tomoyo-init 
does not exist.
[9.172705] libphy: mdio: probed
[9.954303] systemd[1]: Inserted module 'autofs4'
[   10.019965] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[   10.041719] systemd[1]: Detected architecture arm.
[   10.068617] systemd[1]: Set hostname to .
[   10.081427] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid 
argument
[   10.595635] mv88e6085 f1072004.mdio-mii:04 lan8 (uninitialized): PHY 
[!soc!internal-regs!mdio@72004!switch0@4!mdio:01] driver [Marvell 88E6390]
[   10.608585] mv88e6085 f1072004.mdio-mii:04 lan8 (uninitialized): phy: 
setting supported 00,,22ef advertising 00,,22ef
[   10.612489] mv88e6085 f1072004.mdio-mii:04 lan7 (uninitialized): PHY 
[!soc!internal-regs!mdio@72004!switch0@4!mdio:02] driver [Marvell 88E6390]
[   10.622680] random: systemd: uninitialized urandom read (16 bytes read)
[   10.625451] mv88e6085 f1072004.mdio-mii:04 lan7 (uninitialized): phy: 
setting supported 00,,22ef advertising 00,,22ef
[   10.635967] mv88e6085 f1072004.mdio-mii:04 lan6 (uninitialized): PHY 
[!soc!internal-regs!mdio@72004!switch0@4!mdio:03] driver [Marvell 88E6390]
[   10.636784] random: systemd: uninitialized 

Bug#948297: gthumb: diff for NMU version 3:3.8.0-2.1

[Boyuan Yang]

Package: gthumb
Version: 3:3.8.0-2
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for gthumb (versioned as 3:3.8.0-2.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru gthumb-3.8.0/debian/changelog gthumb-3.8.0/debian/changelog
--- gthumb-3.8.0/debian/changelog   2019-07-23 12:36:16.0 -0400
+++ gthumb-3.8.0/debian/changelog   2020-01-06 13:33:46.0 -0500
@@ -1,3 +1,11 @@
+gthumb (3:3.8.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Source-only upload to allow testing migration.
+  * debian/control: Bump Standards-Version to 4.4.1.
+
+ -- Boyuan Yang   Mon, 06 Jan 2020 13:33:46 -0500
+
 gthumb (3:3.8.0-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru gthumb-3.8.0/debian/control gthumb-3.8.0/debian/control
--- gthumb-3.8.0/debian/control 2019-07-23 12:05:48.0 -0400
+++ gthumb-3.8.0/debian/control 2020-01-06 13:33:43.0 -0500
@@ -23,7 +23,7 @@
libwebp-dev,
meson,
yelp-tools
-Standards-Version: 4.4.0
+Standards-Version: 4.4.1
 Vcs-Git: https://salsa.debian.org/debian/gthumb.git
 Vcs-Browser: https://salsa.debian.org/debian/gthumb
 Homepage: https://wiki.gnome.org/Apps/Gthumb


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

Bug#936557: freeorion: Python2 removal in sid/bullseye

[Adrian Bunk]

Control: severity -1 normal

On Sun, Dec 01, 2019 at 11:38:39AM +0100, Andreas Beckmann wrote:
> Followup-For: Bug #936557
> Control: severity -1 serious
> 
> freeorion now FTBFS in sid:
>...
> -- Found PythonInterp: /usr/bin/python2.7 (found suitable version "2.7.17", 
> minimum required is "2.7") 
> CMake Error at 
> /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
> (message):
>   Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS)
>   (Required is at least version "2.7")
>...

The #945840 breakage has been reverted, so for now this works again.

> Andreas

cu
Adrian

Bug#946289: ufw: fails to start with iptables 1.8.4

[Jamie Strandboge]

On Fri, 13 Dec 2019, Jamie Strandboge wrote:

> I can confirm this. It looks like iptables-restore and iptables6-restore
> in 1.8.4 has broken -n behavior with the nft varieties.

This is https://bugzilla.netfilter.org/show_bug.cgi?id=1394

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#948275: is Debian POSIX compliant?

[Russ Allbery]

Harald Dunkel  writes:

> I haven't found it mentioned in the policy manual, so I wonder if Debian
> is supposed to be POSIX compliant (unless noted otherwise)?  IMHO a "it
> goes without saying" is not sufficient.

> Is it safe to assume that POSIX code works?

Simon provided the practical answer, which is that POSIX code will
probably work but you may have to configure individual tools in
non-standard ways if you need very precise adherence to the letter of the
standard.

The formal answer is that no, Debian does not attempt to pass any sort of
POSIX compliance test suite and is not attempting to be POSIX-compliant in
any formal sense.

I believe that this is the list of formally-certified POSIX operating
systems:

https://www.opengroup.org/openbrand/register/

I believe EulerOS may be a Linux derivative; other than that, there are no
Linux distributions on that list.  There's more information here:


https://unix.stackexchange.com/questions/522413/why-are-most-linux-distributions-not-posix-compliant

-- 
Russ Allbery (r...@debian.org)  

Bug#948211: Decouple containerd from docker.io again?

[Shengjing Zhu]

On Mon, Jan 6, 2020 at 3:02 PM Arnaud Rebillout
 wrote:
[...]
> Thanks for the details. So if I understand properly, the situation for 
> upstream docker is that:
>
> - the build dependency is against a containerd commit from the master branch 
> (pulled in according to the vendor.conf file)
> - however for runtime, docker-ce depends on an external containerd.io 
> package. The version of this package suggests that it's a released version 
> and not a snapshot.
>
> Do you understand the same?
>

Yes.

> Maybe we could try a similar middle ground for our packaging, ie. build with 
> the vendored copy of containerd, but don't ship the containerd binary, and 
> instead depend on the containerd package.
>
> But if we want this to work, I guess we should stick to the versions that are 
> tested by docker upstream, which might be an issue (if you want to track 
> latest containerd and docker lags behind, what do we do?).
>

We should keep containerd version in sync with docker. eg docker
19.03.x with containerd 1.2.x. And I guest next docker major version
will use containerd 1.3.x.

> Talking about versions, looking at the file 
> https://download.docker.com/linux/debian/dists/buster/stable/binary-amd64/Packages,
>  I can see that:
>
> - the docker-ce package started to depend on container.io from the 18.09.x 
> series (it's been a while: good)
> - the latest version of docker-ce "5:19.03.5~3-0~debian-buster" depends on 
> containerd.io (>= 1.2.2-3)... Where is the source for this package? Is 
> containerd.io patched here?
>
> I found a comment from someone asking for the sources of the package: 
> https://github.com/containerd/containerd/issues/1508#issuecomment-461413010. 
> The comment went unanswered. A bit more research, and still no idea where are 
> the source for this package. Do you have an idea?
>

Neither do I :(

But let's be optimized about this. There's no reason for docker
upstream to _hide_ some patches which are not applied in containerd
upstream :)
Actually if you look at commits in containerd release branch, the
people from docker are actively backporting things.

> That sounds like a red flag if we don't know what patches (if any) are 
> applied to the containerd.io package shipped by docker in their repo.
>
>
> containerd(without cri) don't import github.com/docker/docker.
> But containerd-cri needs some functions from docker repo.
> But you can build containerd with no_cri tag(I think this should be
> used when building docker, next release).
>
>
> Ok, good to know. Does that mean that you would build containerd with 
> `no_cri`, so that the containerd-dev package would not depend on docker-dev? 
> (I have no idea what CRI really does and if it's needed in Debian).
>

CRI makes containerd useful without docker in a kubernetes worker
node. (That's why I want a separate containerd package)

I have some mistakes in my previous sentence. It should be,
+ github.com/containerd/cri pull in github.com/docker/docker.
+ github.com/containerd/containerd/cmd/containerd pull in
github.com/containerd/cri
So only when you build containerd binary(with cri), you will need
github.com/docker/docker.
No consumer will pull in github.com/containerd/containerd/cmd/..., so
no need to pull in github.com/docker/docker.
There's no circular dependencies, apparently.

-- 
Shengjing Zhu

Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1

[Vincent Bernat]

Hello Michael,

I was able to hit the bug again. It seems I have to go to another wifi
network, then back to my home network to hit the bug. On the
client-side, I get:

janv. 06 18:57:13 zoro NetworkManager[75721]:   [1578333433.9474] dhcp4 
(wlp3s0): activation: beginning transaction (timeout in 45 seconds)
janv. 06 18:57:13 zoro NetworkManager[75721]:  [1578333433.9532] dhcp4 
(wlp3s0): sent REQUEST to 255.255.255.255
janv. 06 18:57:13 zoro NetworkManager[75721]:  [1578333433.9571] dhcp4 
(wlp3s0): received NACK from 0.0.0.0
janv. 06 18:57:13 zoro NetworkManager[75721]:   [1578333433.9572] dhcp4 
(wlp3s0): state changed unknown -> fail

On the server-side, I am using dnsmasq. Logs say:

Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPREQUEST(lan-trusted) 
192.168.117.40 3e:55:59:b2:a3:b9
Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPNAK(lan-trusted) 192.168.117.40 
3e:55:59:b2:a3:b9 address in use

I am a bit puzzled why dnsmasq says that, but it didn't happen with
older versions of Network Manager. If I capture the request and
response, I get:

18:57:13.952425 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP 
(17), length 317)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
3e:55:59:b2:a3:b9, length 289, xid 0xa9a8ed40, Flags [none] (0x)
  Client-Ethernet-Address 3e:55:59:b2:a3:b9
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 3e:55:59:b2:a3:b9
Parameter-Request Option 55, length 18:
  Subnet-Mask, Time-Zone, Domain-Name-Server, Hostname
  Domain-Name, MTU, BR, Classless-Static-Route
  Default-Gateway, Static-Route, YD, YS
  NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft
  Option 252, RP
MSZ Option 57, length 2: 576
Requested-IP Option 50, length 4: 192.168.117.40
Hostname Option 12, length 4: "zoro"
END Option 255, length 0
18:57:13.952596 IP (tos 0xc0, ttl 64, id 26751, offset 0, flags [none], proto 
UDP (17), length 328)
192.168.117.1.67 > 255.255.255.255.68: [bad udp cksum 0x36ef -> 0x0984!] 
BOOTP/DHCP, Reply, length 300, xid 0xa9a8ed40, Flags [Broadcast] (0x8000)
  Client-Ethernet-Address 3e:55:59:b2:a3:b9
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Server-ID Option 54, length 4: 192.168.117.1
MSG Option 56, length 14: "address in use"
END Option 255, length 0
PAD Option 0, length 0, occurs 34

But if I look at the lease file from dnsmasq, I see:

1578382414 e8:2a:ea:05:c0:df 192.168.117.40 zoro 01:e8:2a:ea:05:c0:df

So, I suppose this is a because of randomizatio of the MAC address on
wifi networks. I don't see anytrhing special in the NEWS file about
this. Previously, the hardware MAC address was used to do the DHCP
request.

When using dhcp=dhclient, I am getting the same NAK, but then the ISC
DHCP client is using DISCOVER and gets a new IP address.

RFC says "If the client receives a DHCPNAK message, the client
restarts the configuration process." So, I think the bug is more in the
fact that the DHCP client doesn't restart configuration when receiving a
NAK but just gives up.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#948217: docker-registry: failed to open htpasswd path open /etc/registry

[Vincent Smeets]

Hallo,

Thanks for your reply. I manually changed the config file as you suggested
and now the service is starting.

Thanks

Op ma 6 jan. 2020 om 06:01 schreef Arnaud Rebillout <
arnaud.rebill...@collabora.com>:

>
> On 1/5/20 9:07 PM, Vincent Smeets wrote:
> > Package: docker-registry
> > Version: 2.7.1+ds2-5
> > Severity: important
> >
> > docker-registry is not starting. I installed docker.io and then
> > docker-registry. docker.io is working normally, but docker-registry
> > isn't started by systemd. The following error is shown in journalctl:
> >
> > panic: unable to configure authorization (htpasswd): failed to open
> htpasswd path open /etc/registry: permission denied
> >
> > The file or directory /etc/registry doesn't exists. I would have
> > expected that this file is created during the installation. I did find
> > the directory /etc/docker/registry. Is there some configuration error
> > that the wrong directory name is specified?
>
>
> Indeed, there was a configuration error, thanks for reporting.
>
> In the file /etc/docker/registry/config.yml, the configuration for auth:
> htpasswd: path: /etc/registry should be /etc/docker/registry
>
> Can you please make this change on your side, and confirm that it fixes
> the issue? I will upload a new package with the fix after your
> confirmation.
>
>
> > Additional point:
> > I didn't find a manual page.
>
>
> I don't think upstream provides a man page, and I don't think they will
> (the maintenance level has been rather low on this repo). But their
> online documentation is quite OK. If you think they should provide a man
> page, maybe try opening an issue on GitHub?
>
>
> Regards,
>
>Arnaud
>
>

Bug#948296: haproxy: please update dconv to python3

[Andreas Hasenack]

Package: haproxy
Version: 2.0.12-1
Severity: normal

Dear Maintainer,

please update the debian/dconv/* code to use python3. Upstream has
moved to py3 already at https://github.com/cbonte/haproxy-dconv,
assuming that's the correct repository.

The mako package doesn't even build the python-mako (py2) package
anymore, just the py3 version.

Thanks!

Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64

[Ximin Luo]

Helmut Grohne:
> On Sat, Jan 04, 2020 at 01:56:33AM +, Ximin Luo wrote:
>> Please see also the attached patch to support cross-compiling which I needed 
>> in
>> order to test that the first patch works. You can repeat the build yourself 
>> with an
>> sbuild invocation like:
> 
> Please refrain from applying the cross compilation patch as is.
> Disabling features (such as ocaml bindings) is inappropriate for the
> cross profile. The cross profile is only used for making cross
> compilation work. It should not alter the generated package set nor
> change package contents. For disabling ocaml bindings please use a
> separate profile. Likely "noocaml" even though it isn't registered yet.
> Registering it should be uncontroversial. In case java bindings need to
> be disabled, there already is a "nojava" profile for that.
> 

To that end, one just needs to change "" to "" in my patch, 
as well as the line in d/rules where it tests "ifeq (,$(filter 
cross,$(DEB_BUILD_PROFILES)))" to test noocaml instead of cross.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#948295: python-dateutils's autopkg tests fail / Update to 2.8.1 for Python 3.8

[Matthias Klose]

Package: src:python-dateutil
Version: 2.7.3-3
Severity: serious
Tags: sid bullseye

python-dateutils's autopkg tests fail for Python2, python-freezegun was already
removed.  Maybe for now just stop testing for Python2.

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dateutil/3890104/log.gz

Please also update to 2.8.1 to support Python 3.8.

Bug#948293: geeqie: Geeqie crashes when name of new dir is the same as the existing file

[Wojciech Muła]

Package: geeqie
Version: 1:1.5.1-5
Severity: normal

Steps to reproduce:

Create a file:

$ touch 1

Then run geeqie in the same directory, like

$ geeqie

Finally click right on the directory listing, select the option "New
directory..." and enter the name of the just created file, i.e. "1". On
accepting, geeqie terminates. When run in gdb, following error is shown:

ERROR:filedata.c:654:file_data_new_dir: assertion failed: (S_ISDIR(st.st_mode))

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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.5.1-5
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libexiv2-14  0.25-4
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc1  1:9.2.1-19
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblirc-client0  0.10.1-5.2
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libstdc++6   9.2.1-19
ii  libtiff5 4.0.10-4
ii  sensible-utils   0.0.12

Versions of packages geeqie recommends:
pn  cups-bsd | lpr   
pn  exiftran 
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  librsvg2-common  2.44.10-2.1
ii  ufraw-batch  0.22-4
pn  zenity   

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.10.8-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw
pn  xpaint   

-- debconf-show failed

Bug#948294: ITS: 4digits

[Boyuan Yang]

Package: 4digits
Severity: important
Version: 1.1.4-1
X-Debbugs-CC: panyong...@gmail.com alli...@lohutok.net

Dear 4digits maintainers,

After looking into the package you maintain (4digits, 
https://tracker.debian.org/pkg/4digits ), I found that this package received
no updates since 2014 and is not in good shape. As a result, I am filing an
ITS (Intent to Salvage) request against your package according to sections
5.12 in Debian's Developers' Reference [1].

Please let me know if you are still willing to maintain this package ASAP.
According to the criteria listed at [2], I will upload a Non-maintainer Upload
(NMU) of 4digits onto DELAYED/7 after 21 days (Jan. 27, 2020) to continue with
the package salvaging. If it's necessary to pause the ITS process, please let
me know immediately by replying this bug report.

Thank you for your previous work in Debian and looking forward to your reply.

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

-- 
Best Regards,
Boyuan Yang

Bug#948290: buster-pu: package console-common/0.7.90

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2020-01-06 at 16:48 +, Alastair McKinstry wrote:
> Release critical bug fixed a regression that dropped critial files
> (935096)
> 
> 
> diff -Nru console-common-0.7.90/debian/changelog console-common-
> 0.7.90+deb10u1/debian/changelog
> --- console-common-0.7.90/debian/changelog2018-05-14
> 14:22:01.0 +0100
> +++ console-common-0.7.90+deb10u1/debian/changelog2019-09-08
> 11:00:28.0 +0100
> @@ -1,3 +1,12 @@
> +console-common (0.7.90+deb10u1) unstable; urgency=medium

The distribution there should be "buster", not "unstable".

> +  * Patch from Patrick Cernko for regression that dropped files.
> +Closes: #935096
> +  * Use debhelper-compat (= 12)
> +  * Standards-Version: 4.4.0

Those last two changes wouldn't be appropriate for a stable update, but
don't appear to be included in the diff in any case?

Regards,

Adam

Bug#948292: firmware-iwlwifi: Unable to reconnect wifi after hibernation with Centrino Advanced-N 6205

[red0queen]

Package: firmware-iwlwifi
Version: 20190114-2
Severity: normal

Dear Maintainer,
It is my first report, and I hope do it correctly !
Since two years I experience a stange thing. I work with a thinkpad (and, 
firmware-iwlwifi) that I connect to a hidden wifi network at my work. But, when 
I return at home with this laptop (after hibernate in my backpack), most of the 
times, it refuse to reconnect to another wifi (with or without encryption). It 
force me to reboot the computer to be able to reconnect. Don't know if it's a 
firmware bug, or a network manager, or another mate component (I don't use 
gnome). The bug is not hardware dependent, I've try with anothers thinkpad 
(T420/T430).
Best regards

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.133+deb10u1

-- no debconf information

Bug#948268: Crashes after startup

[Bernhard Übelacker]

Dear Maintainer,
just as a side note, a similar bug was submitted
against the basilisk2 package.

https://bugs.debian.org/922323

Another user of slirp is qemu, which had some changes in
that area, which seems to have evolved into this library:

https://gitlab.freedesktop.org/slirp/libslirp
https://gitlab.freedesktop.org/slirp/libslirp/blob/master/src/ip.h#L214

Kind regards,
Bernhard

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

On Mon, 2020-01-06 at 16:58 +, Anton Ivanov wrote:
> On 06/01/2020 16:21, Ritesh Raj Sarraf wrote:
> > Control: tag -1 +help
> > 
> > On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:
> > > On my sid system:
> > > ```
> > > $ strings /usr/bin/linux.uml | grep port-helper
> > > /usr/lib//uml/port-helper
> > > ```
> > > 
> > > So the path is still incorrect even with newer upstream kernels.
> > 
> > I spent some time today looking at the new build but I haven't been
> > able to ascertain why this isn't setting the correct path.
> 
> It is used in a "user" side file - xterm.c
> 
> None of these sees "CONFIG_" so it considers it undef-ed which
> defaults 
> to 32 bit.
> 
> You need to use some other way to figure out what is the build or to
> set 
> OS_LIB_PATH for this case.

Thank you for the quick reply Anton.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

On Mon, 2020-01-06 at 21:51 +0530, Ritesh Raj Sarraf wrote:
> First, for context to the readers here, the port-helper binary is
> shipped with uml-utilities package. This package, depending on the
> architecture, installs the binary to a architecture specific
> location.
> 
> https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10
> 
> Which on an amd64 machine is: /usr/lib64/uml/port-helper

So 2 things I noticed on my machine.

1. There's nothing else under /usr/lib64/ on my Debian box. Even UML's
modules are built and installed under /usr/lib/

```
rrs@priyasi:/usr/lib$ ls uml/modules/5.4.6/
kernel/modules.alias.bin  modules.builtin.bin  modules.dep 
 modules.devname  modules.softdep  modules.symbols.bin
modules.alias  modules.builtinmodules.builtin.modinfo  modules.dep.
bin  modules.ordermodules.symbols
22:18 ♒ ॐ  ☺ 
rrs@priyasi:/usr/lib$ ls ../lib64/
uml/
22:18 ♒ ॐ  ☺ 
rrs@priyasi:/usr/lib$ ls ../lib64/uml/
port-helper*
22:18 ♒ ॐ  ☺ 
```


2. Given that /usr/lib64/ is empty, quick immediate workaround could be to 
patch uml-utilities
and ship the binary under /usr/lib/. That would solve all these issues.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Anton Ivanov]

On 06/01/2020 16:21, Ritesh Raj Sarraf wrote:

Control: tag -1 +help

On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:

On my sid system:
```
$ strings /usr/bin/linux.uml | grep port-helper
/usr/lib//uml/port-helper
```

So the path is still incorrect even with newer upstream kernels.


I spent some time today looking at the new build but I haven't been
able to ascertain why this isn't setting the correct path.


It is used in a "user" side file - xterm.c

None of these sees "CONFIG_" so it considers it undef-ed which defaults 
to 32 bit.


You need to use some other way to figure out what is the build or to set 
OS_LIB_PATH for this case.




```
$ strings `which  linux.uml` | grep port-helper
/usr/lib/uml/port-helper
```

First, for context to the readers here, the port-helper binary is
shipped with uml-utilities package. This package, depending on the
architecture, installs the binary to a architecture specific location.

https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10

Which on an amd64 machine is: /usr/lib64/uml/port-helper

```
$ dpkg  -S /usr/lib64/uml/port-helper
uml-utilities: /usr/lib64/uml/port-helper
```

The UML setup on my box always worked because long back, when I first
encountered this problem, I had created a symlink of the path to
/usr/lib/ too. And had completely forgotten about it. My apologies.


But that said, the current problem is with the UML binary built by the
kernel sources.
Problem is that, as mentioned above and other reports too on this bug
report thread, the path resolved at build time is always
"/usr/lib/uml/".

The build configuration and the code are all correct.

```
$ grep 64BIT .config
CONFIG_64BIT=y
CONFIG_64BIT_TIME=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
```


Snipped from: arch/um/include/shared/os.h

```
#ifdef CONFIG_64BIT
#define OS_LIB_PATH "/usr/lib64/"
#else
#define OS_LIB_PATH "/usr/lib/"
#endif
```

I also checked the generated include headers and they are correct for
the amd64 .config file.

```
linux-source-5.4/include/generated$ grep 64BIT autoconf.h
#define CONFIG_64BIT_TIME 1
#define CONFIG_PHYS_ADDR_T_64BIT 1
#define CONFIG_64BIT 1
#define CONFIG_ARCH_DMA_ADDR_T_64BIT 1
```

I'll keep looking as time permits but if anyone else has ideas on what
I may be doing wrong, please do mention.

Thanks,
Ritesh


___
linux-um mailing list
linux...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um



--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library

[Giovanni Mascellani]

Hi,

Il 06/01/20 13:54, Andreas Beckmann ha scritto:
> This bug is not about the python2 removal. This bug is about removing a
> shared library without doing a proper transition, i.e. renaming the
> package (which will happen with boost1.71) or adding a bunch of Breaks.
> The same will happen again once python3.7 gets removed and only
> python3.8 remains as a supported version. (Similar bugs happened during
> the python3.6->python3.7 switch and prompted for the introduction of
> some virtual packages)

I agree.

> To simplify such future transitions, I created a patch (#948273) to
> actually make use of the virtual packages introduced in -12.
> Please include it along with the reintroduction of python2 support in
> *sid*. Then we can binNMU all rdepends of libboost-python1.67.0,
> libboost-mpi-python1.67.0, libboost-numpy1.67.0 to add more strict
> dependencies on the required python support.

So, if I get this right, the point of binNMU-ing is to make sure that
all the rev deps choose their versioned dependency, so that when a
Python version goes away the breakage will be recorded in the packages
dependencies (and won't be an actual breakage). Is this right?

And then you need to have Boost.Python with Python 2.7 back because
otherwise binNMUs will just fail, right?

If so, then I agree. If not, please explain me, because I am still
learning this kind of things.

> For the transition to boost1.71 it would be best if that happens before
> python3.8 is the only supported python3 and we can thus remove a
> boost1.67 still supporting python2.7 and python3.7 from sid.

Why this?

Anyway, I started filing bugs for transitioning to Boost 1.71[1]. It
will take some time, though.

 [1]
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=team%2Bboost%40tracker.debian.org=boost1.71

> In the unlikely event that bullseye should ship boost1.67 (along 1.71+),
> we need to reinvestigate this to ensure partial upgrades from buster to
> bullseye don't break anything. Probably renaming the three binary
> packages to get a -python3 suffix would be easiest.

Again, I am not sure of what is actually going on here, but I really
hope this will not happen.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#948291: dpkg-buildpackage: please support --hook-foo=bar=baz

[Daniel Shahaf]

Package: dpkg-dev
Version: 1.19.7
Severity: normal
Tags: patch

Dear Maintainer,

[tl;dr: dpkg-buildpackage --hook-init=foo=bar errors out; patch attached.]

   * What led up to the situation?

I was trying to build a package in a chroot and inject some additional
flags into CFLAGS.

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

I read the pdebuild(1) and dpkg-buildflags(1) manual pages and ran the
following command:

% pdebuild -- --debbuildopts "--hook-init='echo APPEND CFLAGS -std=c89 > 
/etc/dpkg/buildflags.conf'"

   * What was the outcome of this action?

[[[
I: Building the package
I: Running cd /build/zsh-syntax-highlighting-0.6.0/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc --source-option=--extend-diff-ignore=^tags$ --hook-init='echo APPEND CFLAGS 
-std=c89 > /etc/dpkg/buildflags.conf' -rfakeroot
dpkg-buildpackage: error: unknown hook name init=echo APPEND CFLAGS -std
]]]

(zsh-syntax-highlighting is just a random package that doesn't have any
source files in C; the error should be repeatable with any package.)

   * What outcome did you expect instead?

I expected the string «--hook-init='echo APPEND CFLAGS -std=c89 > 
/etc/dpkg/buildflags.conf'»
in argv to be taken as creating an «init» hook whose value is the shell
command «echo APPEND CFLAGS -std=c89 > /etc/dpkg/buildflags.conf».

I believe the following patch (against current git) should do the trick:

[[[
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index 2c49738b5..1332ca716 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -238,7 +238,7 @@ while (@ARGV) {
$check_command = $1;
 } elsif (/^--check-option=(.*)$/) {
push @check_opts, $1;
-} elsif (/^--hook-(.+)=(.*)$/) {
+} elsif (/^--hook-(.+?)=(.*)$/) {
my ($hook_name, $hook_cmd) = ($1, $2);
usageerr(g_('unknown hook name %s'), $hook_name)
if not exists $hook{$hook_name};
]]]

Cheers,

Daniel

Bug#934119: [Pkg-privacy-maintainers] Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles

[Roger Shimizu]

On Sun, Jan 5, 2020 at 11:24 PM intrigeri  wrote:
>
> Hi,
>
> Roger Shimizu (2020-01-05):
> > I find this is due to below files were shipped by previous version of
> > torbrowser-launcher, but not as conffile.
> >   /etc/apparmor.d/local/torbrowser.Tor.tor
> >   /etc/apparmor.d/local/torbrowser.Browser.firefox
>
> Yes.
>
> > But now they're shipped with conffile, though in size zero.
>
> That's indeed the problem IMO. See below for my reasoning.
>
> > So new conffiles complain they don't match with existing ones.
>
> Right.

Thanks for your confirmation!

> > It can be fixed by removing the old files when they match the checksum
> > of old shipped ones.
> > The fix will be uploaded soon.
>
> I think this can help for files under /etc/apparmor.d/local/ that the
> package does not install at all anymore (be it via dh-apparmor or as
> conffiles). This would clean up stuff and that's good :)
>
> But I don't think it will help for local/torbrowser.Tor.tor and
> local/torbrowser.Browser.firefox, which this bug report was initially
> about.
>
> FYI, the very purpose of the files under /etc/apparmor.d/local/ is to
> be modified by the system administrator, that is, to diverge from
> what's shipped by packages under /etc/apparmor.d/. The content of
> these files will, by design, always be: local changes, done manually,
> and that packages and dpkg should not fiddle with.
>
> So, if /etc/apparmor.d/local/* are conffiles, and if the administrator
> is using this facility, upon upgrades their local changes will
> necessarily conflict with the (empty) version installed by the
> package, and dpkg will ask what to do. That would be pretty annoying,
> since the answer to dpkg's question in this case will always be "keep
> my local changes, because that's what this file is for after all :)".
>
> I hope this clarifies the drawback I see in handling these files
> as conffiles.

Yes, I didn't find a way to exclude local profile from being listed as
conffile, until I find:
- https://stackoverflow.com/questions/3398511/prevent-creation-of-conffiles

Now I can confirmed that patch below to debian/rules can do the trick:

+override_dh_installdeb:
+dh_installdeb
+sed -i '\:/etc/apparmor.d/local/:d' debian/*/DEBIAN/conffiles

I'll upload this fix soon.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#948288: Acknowledgement (gnome-shell reproducibly crashes on boot, and the boot process gets stuck)

[Md Ayquassar]

Below you find is the dmesg output.

[ 0.00] Linux version 4.19.0-6-686 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
[ 0.00] Disabled fast string operations
[ 0.00] x86/fpu: x87 FPU will use FXSAVE
[ 0.00] BIOS-provided physical RAM map:
[ 0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[ 0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[ 0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[ 0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[ 0.00] BIOS-e820: [mem 0x0010-0x7ff5] usable
[ 0.00] BIOS-e820: [mem 0x7ff6-0x7ff76fff] ACPI data
[ 0.00] BIOS-e820: [mem 0x7ff77000-0x7ff78fff] ACPI NVS
[ 0.00] BIOS-e820: [mem 0x7ff8-0x7fff] reserved
[ 0.00] BIOS-e820: [mem 0xff80-0x] reserved
[ 0.00] Notice: NX (Execute Disable) protection missing in CPU!
[ 0.00] SMBIOS 2.3 present.
[ 0.00] DMI: IBM 2373ZJD/2373ZJD, BIOS 1RETDRWW (3.23 ) 06/18/2007
[ 0.00] tsc: Fast TSC calibration failed
[ 0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[ 0.00] e820: remove [mem 0x000a-0x000f] usable
[ 0.00] last_pfn = 0x7ff60 max_arch_pfn = 0x10
[ 0.00] MTRR default type: uncachable
[ 0.00] MTRR fixed ranges enabled:
[ 0.00] 0-9 write-back
[ 0.00] A-B uncachable
[ 0.00] C-C write-protect
[ 0.00] D-DBFFF uncachable
[ 0.00] DC000-D write-back
[ 0.00] E-F write-protect
[ 0.00] MTRR variable ranges enabled:
[ 0.00] 0 base 0 mask F8000 write-back
[ 0.00] 1 base 07FF8 mask 8 uncachable
[ 0.00] 2 disabled
[ 0.00] 3 disabled
[ 0.00] 4 disabled
[ 0.00] 5 disabled
[ 0.00] 6 disabled
[ 0.00] 7 disabled
[ 0.00] x86/PAT: PAT not supported by CPU.
[ 0.00] x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC
[ 0.00] initial memory mapped: [mem 0x-0x1fff]
[ 0.00] BRK [0x1faf7000, 0x1faf7fff] PGTABLE
[ 0.00] RAMDISK: [mem 0x32681000-0x35337fff]
[ 0.00] ACPI: Early table checksum verification disabled
[ 0.00] ACPI: RSDP 0x000F6D70 24 (v02 IBM )
[ 0.00] ACPI: XSDT 0x7FF6A672 4C (v01 IBM TP-1R 3230 LTP
)
[ 0.00] ACPI: FACP 0x7FF6A700 F4 (v03 IBM TP-1R 3230 IBM
0001)
[ 0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block:
64/32 (20180810/tbfadt-569)
[ 0.00] ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid
Address but zero Length: 0x102C/0x0 (20180810/tbfadt-624)
[ 0.00] ACPI: DSDT 0x7FF6A8E7 00C530 (v01 IBM TP-1R 3230 MSFT
010E)
[ 0.00] ACPI: FACS 0x7FF78000 40
[ 0.00] ACPI: FACS 0x7FF78000 40
[ 0.00] ACPI: SSDT 0x7FF6A8B4 33 (v01 IBM TP-1R 3230 MSFT
010E)
[ 0.00] ACPI: ECDT 0x7FF76E17 52 (v01 IBM TP-1R 3230 IBM
0001)
[ 0.00] ACPI: TCPA 0x7FF76E69 32 (v01 IBM TP-1R 3230 PTL
0001)
[ 0.00] ACPI: BOOT 0x7FF76FD8 28 (v01 IBM TP-1R 3230 LTP
0001)
[ 0.00] 1171MB HIGHMEM available.
[ 0.00] 875MB LOWMEM available.
[ 0.00] mapped low ram: 0 - 36bfe000
[ 0.00] low ram: 0 - 36bfe000
[ 0.00] BRK [0x1faf8000, 0x1faf8fff] PGTABLE
[ 0.00] Zone ranges:
[ 0.00] DMA [mem 0x1000-0x00ff]
[ 0.00] Normal [mem 0x0100-0x36bfdfff]
[ 0.00] HighMem [mem 0x36bfe000-0x7ff5]
[ 0.00] Movable zone start for each node
[ 0.00] Early memory node ranges
[ 0.00] node 0: [mem 0x1000-0x0009efff]
[ 0.00] node 0: [mem 0x0010-0x7ff5]
[ 0.00] Initmem setup node 0 [mem 0x1000-0x7ff5]
[ 0.00] On node 0 totalpages: 524030
[ 0.00] DMA zone: 40 pages used for memmap
[ 0.00] DMA zone: 0 pages reserved
[ 0.00] DMA zone: 3998 pages, LIFO batch:0
[ 0.00] Normal zone: 2150 pages used for memmap
[ 0.00] Normal zone: 220158 pages, LIFO batch:63
[ 0.00] HighMem zone: 299874 pages, LIFO batch:63
[ 0.00] Using APIC driver default
[ 0.00] ACPI: PM-Timer IO Port: 0x1008
[ 0.00] Local APIC disabled by BIOS -- you can enable it with "lapic"
[ 0.00] APIC: disable apic facility
[ 0.00] APIC: switched to apic NOOP
[ 0.00] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.00] PM: Registered nosave memory: [mem 0x-0x0fff]
[ 0.00] PM: Registered nosave memory: [mem 0x0009f000-0x0009]
[ 0.00] PM: Registered nosave memory: [mem 0x000a-0x000d1fff]
[ 0.00] PM: Registered nosave memory: [mem 0x000d2000-0x000d3fff]
[ 0.00] PM: Registered nosave memory: 

Bug#948290: buster-pu: package console-common/0.7.90

[Alastair McKinstry]

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

Release critical bug fixed a regression that dropped critial files
(935096)


diff -Nru console-common-0.7.90/debian/changelog 
console-common-0.7.90+deb10u1/debian/changelog
--- console-common-0.7.90/debian/changelog  2018-05-14 14:22:01.0 
+0100
+++ console-common-0.7.90+deb10u1/debian/changelog  2019-09-08 
11:00:28.0 +0100
@@ -1,3 +1,12 @@
+console-common (0.7.90+deb10u1) unstable; urgency=medium
+
+  * Patch from Patrick Cernko for regression that dropped files.
+Closes: #935096
+  * Use debhelper-compat (= 12)
+  * Standards-Version: 4.4.0
+
+ -- Alastair McKinstry   Sun, 08 Sep 2019 11:00:28 +0100
+
 console-common (0.7.90) unstable; urgency=medium

   * Drop Christian Perrier from Uploaders. Thanks for all the work, Bubulle!
diff -Nru console-common-0.7.90/debian/console-common.files 
console-common-0.7.90+deb10u1/debian/console-common.files
--- console-common-0.7.90/debian/console-common.files   2009-07-26 
14:19:59.0 +0100
+++ console-common-0.7.90+deb10u1/debian/console-common.files   2019-09-08 
11:00:28.0 +0100
@@ -1,3 +0,0 @@
-usr/sbin
-usr/share/man/man8
-usr/share/console
diff -Nru console-common-0.7.90/debian/console-common.install 
console-common-0.7.90+deb10u1/debian/console-common.install
--- console-common-0.7.90/debian/console-common.install 2009-07-26 
14:19:59.0 +0100
+++ console-common-0.7.90+deb10u1/debian/console-common.install 2019-09-08 
11:00:23.0 +0100
@@ -1 +1,4 @@
 debian/lintian/console-common  usr/share/lintian/overrides
+usr/sbin
+usr/share/man/man8
+usr/share/console

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

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

Bug#948289: ITP: liblv-perl -- lvalue subroutines for Perl

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : liblv-perl
  Version : 0.006
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/LV
* License : Artistic
  Programming Lang: Perl
  Description : lvalue subroutines for Perl
 LV makes lvalue subroutines easy and practical to use. It's inspired by the
 lvalue module which is sadly problematic because of the existence of
another
 module on CPAN called Lvalue. (They can get confused on file-systems that
 have case-insensitive file names.)
 .
 LV comes with three different implementations, based on Variable::Magic,
 Sentinel and tie; it will choose and use the best available one.

The package is a dependency of Perl modules for JSON handling, for
example, JSON::Hyper and JSON::Path.

Remark: This package is to be maintained with Debian Perl Group at

   https://salsa.debian.org/perl-team/modules/packages/liblv-perl

Bug#942761: mmdebstrap: hooks not documented in man page / --help

[Johannes Schauer]

Quoting Benjamin Drung (2020-01-06 17:08:09)
> Am Montag, den 06.01.2020, 07:52 +0100 schrieb Johannes Schauer:
> > I assume you are not creating a tarball then, because tar would take care
> > of clamping the mtime for you?
> I wasn't aware of the mtime clamping. So this mtime adjustment can be removed
> completely.

mtime clamping is how mmdebstrap makes the output tarball bit-by-bit
reproducible if you run with the same SOURCE_DATE_EPOCH:

$ SOURCE_DATE_EPOCH=1578217697 mmdebstrap --variant=apt --mode=fakechroot 
unstable chroot1.tar
$ SOURCE_DATE_EPOCH=1578217697 mmdebstrap --variant=apt --mode=fakechroot 
unstable chroot2.tar
$ cmp chroot1.tar chroot2.tar

> > As you know from my private mail, there are now some basic special hooks to
> > copy stuff in and out of the chroot. Just like with guestfish hooks,
> > globbing is not (yet) supported. This could be fixed but would require
> > implementing a full shell quoting parser as well as a symlink resolver
> > which the current solution is working around by utilizing /bin/sh inside
> > the chroot. If you want globbing, then create one hook that utilizes
> > globbing in sh to create a tarball of the files you want and a second hook
> > to move that tarball out of the chroot.  Like this:
> > 
> > --customize-hook='chroot "$1" sh -c "cd /boot && tar -cf
> > /tmp/boot.tar vmlinuz* initrd.img*"'
> > --customize-hook='copy-out /tmp/boot.tar .'
> > --customize-hook='rm "$1"/tmp/boot.tar'
> > 
> > Or like this:
> > 
> > --customize-hook='chroot "$1" sh -c "mkdir /tmp/boot && cp
> > /boot/vmlinuz* /boot/initrd.img* /tmp/boot"'
> > --customize-hook='copy-out /tmp/boot .'
> > --customize-hook='rm -r "$1"/tmp/boot'
> 
> I tried this solution and are fine with using it. Compared to implementing
> globbing in mmdebstrap, this solution adds two more hooks and copies the
> files twice (should not have a big performance impact).
> 
> The only remaining issues is that copy-out copies the directory as-is instead
> of copying the content of the directory. So in this your example above, the
> current directory would contain a directory 'boot' containing the kernel and
> initrd, but I like to have the kernel and initrd in the current directory
> (instead of the 'boot' subdirectory).  Any good idea how to do that?

Some ideas:

--customize-hook='chroot "$1" sh -c "cp /boot/vmlinuz* /tmp/vmlinuz && cp 
/boot/initrd.img* /tmp/initrd"'
--customize-hook='copy-out /tmp/vmlinuz .'
--customize-hook='copy-out /tmp/initrd.img .'
--customize-hook='rm "$1"/tmp/vmlinuz "$1"/tmp/initrd.img'

or like this:

--customize-hook='chroot "$1" sh -c "cd /boot && tar -cf /tmp/boot.tar vmlinuz* 
initrd.img*"'
--customize-hook='copy-out /tmp/boot.tar .'
--customize-hook='rm "$1"/tmp/boot.tar'
--customize-hook='tar -xf boot.tar && rm boot.tar'

or like this:

--customize-hook='chroot "$1" sh -c "mkdir /tmp/boot && cp /boot/vmlinuz* 
/boot/initrd.img* /tmp/boot"'
--customize-hook='tar-out /tmp/boot boot.tar'
--customize-hook='rm -r "$1"/tmp/boot'
--customize-hook='tar --strip-components=1 -xf boot.tar && rm boot.tar'

If you think this is all too convoluted, feel free to write up a patch that
adds wildcard support. I'd gladly apply it!

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

Control: tag -1 +help

On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:
> On my sid system:
> ```
> $ strings /usr/bin/linux.uml | grep port-helper
> /usr/lib//uml/port-helper
> ```
> 
> So the path is still incorrect even with newer upstream kernels.

I spent some time today looking at the new build but I haven't been
able to ascertain why this isn't setting the correct path.

```
$ strings `which  linux.uml` | grep port-helper
/usr/lib/uml/port-helper
```

First, for context to the readers here, the port-helper binary is
shipped with uml-utilities package. This package, depending on the
architecture, installs the binary to a architecture specific location.

https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10

Which on an amd64 machine is: /usr/lib64/uml/port-helper

```
$ dpkg  -S /usr/lib64/uml/port-helper
uml-utilities: /usr/lib64/uml/port-helper
```

The UML setup on my box always worked because long back, when I first
encountered this problem, I had created a symlink of the path to
/usr/lib/ too. And had completely forgotten about it. My apologies.


But that said, the current problem is with the UML binary built by the
kernel sources.
Problem is that, as mentioned above and other reports too on this bug
report thread, the path resolved at build time is always
"/usr/lib/uml/".

The build configuration and the code are all correct.

```
$ grep 64BIT .config
CONFIG_64BIT=y
CONFIG_64BIT_TIME=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
```


Snipped from: arch/um/include/shared/os.h

```
#ifdef CONFIG_64BIT
#define OS_LIB_PATH "/usr/lib64/"
#else
#define OS_LIB_PATH "/usr/lib/"
#endif
```

I also checked the generated include headers and they are correct for
the amd64 .config file.

```
linux-source-5.4/include/generated$ grep 64BIT autoconf.h 
#define CONFIG_64BIT_TIME 1
#define CONFIG_PHYS_ADDR_T_64BIT 1
#define CONFIG_64BIT 1
#define CONFIG_ARCH_DMA_ADDR_T_64BIT 1
```

I'll keep looking as time permits but if anyone else has ideas on what
I may be doing wrong, please do mention.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#936105: python is still used in the autopkg tests

[Matthias Klose]

Control: severity -1 serious

python is still used in the autopkg tests, and all the scripts in the package
are not ported to python3.

Bug#942761: mmdebstrap: hooks not documented in man page / --help

[Benjamin Drung]

Hi,

Am Montag, den 06.01.2020, 07:52 +0100 schrieb Johannes Schauer:
> Hi,
> 
> On Wed, 13 Nov 2019 19:37:04 +0100 Benjamin Drung <
> benjamin.dr...@cloud.ionos.com> wrote:
> > Am Mittwoch, den 13.11.2019, 19:22 +0100 schrieb Johannes Schauer:
> > > Quoting Benjamin Drung (2019-11-13 19:03:31)
> > > > One hook is missing: A clean hook that is run after the
> > > > cleanup, which
> > > > would be run at last step of the setup function.
> > > What kind of stuff would you run there instead of putting it into
> > > the
> > > customize hook?
> > My cleanup script contains two things:
> > 
> > 1) Removal of different stuff like /etc/resolv.conf,
> > /etc/udev/rules.d/70-persistent-net.rules,
> 
> why can these two things not go into the customize hook?

They can probably go at the end of the customize hooks.

> > 2) Adjusting the timestamp of files/directories, e.g.:
> > 
> > find "$0/etc/" "$0/var/" -newermt "@${SOURCE_DATE_EPOCH}" \
> > \( -type f -o -type l \) -print0 | \
> > xargs -0r touch -hm -d "@${SOURCE_DATE_EPOCH}"
> 
> Why is the customize hook too late for this snippet?
> 
> I assume you are not creating a tarball then, because tar would take
> care of clamping the mtime for you?

I wasn't aware of the mtime clamping. So this mtime adjustment can be
removed completely.

> > > > I have only one issue related to the hooks: There is no easy,
> > > > safe, and
> > > > reliable way to copy stuff out of the image to an existing
> > > > directory.
> > > > Use case: copy the kernel+initrd out of the image for PXE
> > > > booting.
> > > I agree and I have needed this myself several times already. I'm
> > > still
> > > thinking of a good way to implement this because it does not only
> > > involve
> > > copying the data itself but also assuring right permission and
> > > ownership
> > > information.  Furthermore, it should be possible to copy files in
> > > and out
> > > of the chroot at any point where hook are currently run.
> > > 
> > > Currently I'm doing a lot of this in my own scripts:
> > > 
> > > --customize-hook='cp -a tmpfile "$1/target/directory"'
> > > --customize-hook='echo foobar > "$1/target/file"'
> > > 
> > > I have been considering adding another option that allows
> > > extracting
> 
> As you know from my private mail, there are now some basic special
> hooks to
> copy stuff in and out of the chroot. Just like with guestfish hooks,
> globbing
> is not (yet) supported. This could be fixed but would require
> implementing a
> full shell quoting parser as well as a symlink resolver which the
> current
> solution is working around by utilizing /bin/sh inside the chroot. If
> you want
> globbing, then create one hook that utilizes globbing in sh to create
> a tarball
> of the files you want and a second hook to move that tarball out of
> the chroot.
> Like this:
> 
> --customize-hook='chroot "$1" sh -c "cd /boot && tar -cf
> /tmp/boot.tar vmlinuz* initrd.img*"'
> --customize-hook='copy-out /tmp/boot.tar .'
> --customize-hook='rm "$1"/tmp/boot.tar'
> 
> Or like this:
> 
> --customize-hook='chroot "$1" sh -c "mkdir /tmp/boot && cp
> /boot/vmlinuz* /boot/initrd.img* /tmp/boot"'
> --customize-hook='copy-out /tmp/boot .'
> --customize-hook='rm -r "$1"/tmp/boot'

I tried this solution and are fine with using it. Compared to
implementing globbing in mmdebstrap, this solution adds two more hooks
and copies the files twice (should not have a big performance impact).

The only remaining issues is that copy-out copies the directory as-is
instead of copying the content of the directory. So in this your
example above, the current directory would contain a directory 'boot'
containing the kernel and initrd, but I like to have the kernel and
initrd in the current directory (instead of the 'boot' subdirectory).
Any good idea how to do that?

-- 
Benjamin Drung

System Developer and Debian & Ubuntu Developer
Platform Engineering Compute (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet


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

Bug#948194: RFS: jcc/3.6-1 [ITA] -- generator for a Python extension from Java classes (transitional)

[Emmanuel Arias]

Hi Adam,

Thanks for the feedback
I will work on that right now.

Thanks!

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El dom., 5 de ene. de 2020 a la(s) 18:40, Adam Borowski
(kilob...@angband.pl) escribió:
>
> On Sun, Jan 05, 2020 at 01:37:20AM -0300, Emmanuel Arias wrote:
> >  * Package name: jcc
> >Version : 3.6-1
>
> > It builds those binary packages:
> >
> >   python-jcc - generator for a Python extension from Java classes (Python 2)
> >   python3-jcc - generator for a Python extension from Java classes (Python 
> > 3)
> >   jcc - generator for a Python extension from Java classes (transitional)
>
> [Note: a trip through binNEW is required.]
>
> > Changes since the last upload:
> >
> >[ Emmanuel Arias ]
> >* New upstream version 3.6
> >* New maintainer (Closes: #922568):
> >  - Add myself to Maintainer field on d/control.
> >* Bump debhelper to 12 (from 9.2):
> >  - Update debhelper to debhelper-compat on d/control Build-Depends.
> >* Update Vcs-* repository to salsa repository.
> >* Add myself on debian/* files copyright on d/copyright.
> >* Bump Standard-Version to 4.4.1
> >* d/control: add autopkgtest-pkg-python
>
> Hi!
> The package has three RC bugs filed against it, and you don't close any of
> them.  These are:
> #875579 FTBFS with Java 9: library path guessed wrong
> #885955 FTBFS: /usr/bin/ld: cannot find -ljvm
> -- both of these are fixed in your upload, but without closing them, the
>package won't be allowed back in
>
> #936761 jcc: Python2 removal in sid/bullseye
> -- as there are no reverse {,B-}Rdependencies, there's nothing to preserve
>compatibility for, thus it'd be enough to drop the python-jcc package
>(which you try to introduce!) -- it's not needed, and as the next Debian
>release will not feature Python2[1], would need to be removed shortly
>anyway
>
>
> Meow!
>
> [1]. Or, if removal doesn't succeed, Python2 will be trimmed to a stub.
> --
> ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
> ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
> ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
> ⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#896844: Any Updates?

[Edmund Christian Herenz]

I just installed Debian 10 and I found that preview-latex is not
working.
Preview-latex is one of the big features of this package.
Any chance this bug can be fixed?

As a workaround one can remove the debian package and install the
latest auctex version from elpa.  However, note that the latest
version needs some adjustments to work with ghostscript 9.27, which is
shipped in debian.  This is all a mess, and honestly, a dissapointment
to find this wonderfull package being shipped in such a unusable state
in debian.  


-- 

Edmund Christian Herenz (ESO Fellow) Office: M152
ESO Vitacura Email:  eher...@eso.org
Alonso de Córdova 3107   Phone:  +56 2 2463 3047  (Office)
Vitacura, Casilla 19001  +56 9 4613 7517  (Mobile)
Santiago de Chile, Chile WWW:http://www.sc.eso.org/~eherenz/

Bug#948279: [Python-modules-team] Bug#948279: python-gmusicapi: please make the build reproducible

[Emmanuel Arias]

Hi,

I applied the patch on salsa.

Please check. I will need sponsorship to upload it.

Thanks!

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El lun., 6 de ene. de 2020 a la(s) 09:12, Chris Lamb
(la...@debian.org) escribió:
>
> Source: python-gmusicapi
> Version: 12.1.1-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0] we noticed that
> python-gmusicapi could not be built reproducibly.
>
> This is because the documentation embedded the build user's home
> directory (via the XDG config directory).
>
> Patch attached.
>
>  [0] https://reproducible-builds.org/
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Marco d'Itri]

Control: severity -1 normal
Control: tags -1 patch
Control: reassign -1 initramfs-tools

On Jan 06, crvi  wrote:

>* What outcome did you expect instead?
> 
> Successful ramfs generation
Do you have any reason to believe that the initrfamfs was not generated 
successfully?

This is only cosmetic, and it needs to be fixed in /usr/sbin/mkinitramfs
by copying modules.builtin.bin too:

-for x in modules.builtin modules.order; do
+for x in modules.builtin modules.builtin.bin modules.order; do

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#948269: file: misdetection of shared libraries as statically linked - breaks dh_shlibdeps

[Christoph Biedl]

James McCoy wrote...

> Autopkgtests already run against packages in experimental, albeit at a
> slower pace than those in unstable.  It seems those did catch the issue
> -- https://release.debian.org/britney/pseudo-excuses-experimental.html#file

TIL - now added to the list of things to check before the first upload
to unstable.

Christoph


signature.asc
Description: PGP signature