Bug#970724: Suggests: check-pgbackrest

2020-09-22 Thread Christoph Berg
Package: pgbackrest
Version: 2.29-1
Severity: wishlist

Hi,

I recently packaged check_pgbackrest (package: check-pgbackrest) which
is the recommended monitoring plugin for pgbackrest (says Snow-Man).

Please consider adding `Suggests: check-pgbackrest` in the pgbackrest
control file.

Thanks,
Christoph



Bug#969705: postgresql-common: package fails to install

2020-09-07 Thread Christoph Berg
Control: tag -1 moreinto

Re: Nick
> On a freshly installed system (an hour or so earlier), my attempt to
> install postgresql-11 failed, apparently because postgresql-common
> failed to install.  It went like so:

> # apt-get install postgresql-11
> Setting up postgresql-common (200+deb10u3) ...
> debconf: unable to initialize frontend: Dialog
> debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
> buffer, or without a controlling terminal.)
> debconf: falling back to frontend: Readline
> Adding user postgres to group ssl-cert
> dpkg: error processing package postgresql-common (--configure):
>  installed postgresql-common package post-installation script subprocess 
> returned error exit status 1

Hi Nick,

it works on a fresh machine for me, so it is likely some particularity
of the system at your end. To see more details, can you put

set -x

at the beginning of /var/lib/dpkg/info/postgresql-common.postinst and
then try one of these:

apt-get install -f

or

dpkg-reconfigure postgresql-common

That should give more detail about where it is dying.

Christoph



Bug#956811: cura: UI not usable because of OpenGL renderer

2020-09-07 Thread Christoph Berg
Control: tag -1 help

Re: Peter Felecan
> The only difference that I found is the OpenGL renderer used in the 2
> situations:
[...]
> My conclusion is that the Cura user interface is not working correctly
> when the renderer used is the one provided by my GPU but works
> correctly on a software renderer.
> 
> Unfortunately I do not have enough experience in the OpenGL context
> but willing to provide more information to or try experiments from
> more experienced users.

Hi Peter,

I don't have experience in debugging this either, so the best I can do
at the moment is to tag this bug "help".

I'll be switching machines soon at home, so maybe if that problem pops
up there as well, I'll have more insight... At the moment cura works
for me.

Christoph



Bug#907576: . RE: push. dream --A Software Digital Radio Mondiale

2020-08-25 Thread Christoph Berg
Re: GMiller
> For the Debian directory look in:
> 
> Project 52290
> Initial commit Dream push to Salsa-Garie Miller 08 19 20
> Repository
> dream/dream-2.2.1+r1339/debian/
> 
> I pushed my working directory (with screenshots) both as an 'existing folder' 
> and a '.git repo'. If you have any review comments I would be interested.

Sorry, the git layout is completely wrong. The upstream sources (if
you decide to commit them) need to be in the root directory of the
repo, and the debian directory needs to be /debian.

Also, don't add any tarballs (see `pristine-tar` instead, but that is
optional), and don't commit .dsc or .buildlog or whatever. The
screenshots are likely wrong in the repo as well.

Looking over the debian/ dir:

Why Section: non-free/hamradio ?

copyright: you probably don't want to list all files individually. If
all files have the same (C), just add "Files: *".

You never build-depend on a C-compiler, that's what build-essential is
for.

libfaac-dev and libfdk-aac-dev do not exist in unstable. On which
distribution did you test that?

For the binary: Remove all the lib* (and zlib) dependencies,
dpkg-shlibdeps will sort that out automatically.

Things in debian/docs do not need to be installed by debian/install.

Any COPYING file should be installed by dh_installdocs to
/usr/share/doc/$package/copyright.gz, and not under random other
filenames.

Re debian/tests/: GUI apps are hard to test anyway, so that's entirely
optional.

Christoph



Bug#907576: . push. dream --A Software Digital Radio Mondiale

2020-08-24 Thread Christoph Berg
Hi Garie,

Re: GMiller
> OK looks like I finally succeeded with the push. I was able to re-add the ED 
> key this morning. I appreciate your patience.
> 
> This is my complete Dream working file. I also sent the .git but don't see it 
> for some reason.

The push worked, but there's no debian/ directory in there.

Also, the .git directory will never appear "inside" the git repo so
you can't see it in the gitlab UI. But effectively, you are only
pushing the .git/ contents to the server which will extract all the
working files from there.

> If I recall, Dream has several code errors. The cast issue is maybe the most 
> difficult. I have read casts can be a mess. Anyway I request help in patching 
> these.

I suggest you get it to compile first, without any debianization.
Upstream should hopefully be interesting in shipping code that
compiles.

Christoph



Bug#907576: . push. dream --A Software Digital Radio Mondiale

2020-08-20 Thread Christoph Berg
Re: GMiller
> OK I see here in gittutorial. Is GMIller a good name to push my branch 
> (instead of master)?

Clone the repo to your account on salsa and push it there first.

Christoph



Bug#907576: . push. dream --A Software Digital Radio Mondiale

2020-08-20 Thread Christoph Berg
Re: GMiller
> git push --set-upstream 
> ssh://g...@salsa.debian.org:debian-hamradio-team/dream.git master
> 
> It responded with:
> 
> ssh: Could not resolve hostname salsa.debian.org:debian-hamradio-team: Name 
> or service not known
  ^

Try either g...@salsa.debian.org:debian-hamradio-team/dream.git
or ssh://g...@salsa.debian.org/debian-hamradio-team/dream.git

Christoph



Bug#907576: . push. dream --A Software Digital Radio Mondiale

2020-08-19 Thread Christoph Berg
Re: GMiller
> git push --set-upstream 
> ssh://g...@salsa.debian.org:debian-hamradio-team/dream.git master
> 
> It gave two errors, the second in red:
> 
> error: src refspec master does not match any
> error: failed to push some refs to 
> 'ssh://g...@salsa.debian.org:debian-hamradio-team/dream.git'

Uhm. Which branch are you on?

Christoph



Bug#968514: Package name "systemctl" is confusing and misleading, please rename to "systemctl-replacement"

2020-08-16 Thread Christoph Berg
Package: systemctl
Severity: normal

Hi,

I believe the package name "systemctl" is misleading in several ways:

* Users will think systemctl.deb will contain the normal
  /bin/systemctl and might be tricked into installing this when they
  actually wanted systemd.deb.
* If systemd should decide to split the package into smaller
  components (#959828 indicates that this is at least an option),
  this "systemctl" package is blocking an important bit of their
  namespace.
* The package description currently does not say explicitly that this
  implementation is not part of systemd. If systemctl.deb were to be
  split from systemd.deb it might have some description very close to
  the current one. The only indication that this isn't the case is
  that it's not built from Source: systemd, and the Maintainer is
  different. Readers not familiar with systemd intricacies in Debian
  will not be able to draw this conclusion.

Please consider renaming the binary package. Looking at the source
package name, "systemctl-replacement" is an ideal candidate.

(It is of course ok for the package to ship /bin/systemctl as that's
the point of the replacement. I'm only aiming at the package name.)

Christoph



Bug#957029: ax25mail-utils is marked for autoremoval from testing

2020-08-12 Thread Christoph Berg
Re: David Ranch
> I have built up a working Debian Sid image with GCC 10 and have reproduced
> the issue with the "develop" branch of ax25mail-utils. I am working on
> getting these issues resolved but how long do I have to get them addressed?
> 
> On 08/11/2020 09:39 PM, Debian testing autoremoval watch wrote:
> > ax25mail-utils 0.13-1 is marked for autoremoval from testing on 2020-08-26
^^

> > It is affected by these RC bugs:
> > 957029: ax25mail-utils: ftbfs with GCC-10
> >   https://bugs.debian.org/957029

... but the counter gets reset when new info is added to the bug (like
with this Cc here).

Christoph



Bug#958253: Use system libjsonparser-dev

2020-08-11 Thread Christoph Berg
Control: tags -1 upstream

Re: Yangfl
> Source: pgpool2
> Severity: wishlist
> 
> As libjsonparser-dev is now available, please consider linking against
> system library instead of bundled json.c.

Hi,

I don't think it's that simple:

src/utils/json.c:

/* pgpool extension:/

/*
 * pgpool extension:
 * search node with key from json object
 */
json_value *
json_get_value_for_key(json_value * source, const char *key)

... and a few more extra functions.

Christoph



Bug#885265: [py3] some fixes to get chirpw running with python3, Fixes #7431

2020-08-06 Thread Christoph Berg
Re: Arturo Borrero Gonzalez
> I tested chirp from the upstream mercurial repository (py3 branch) today in
> Debian testing bullseye, and I got it working with python3 with the attached 
> patch.

Hi Arturo,

thanks for picking this up. I had done some python3 hacking on chirp
earlier this year, but apparently never pushed the changes anywhere
since they weren't working.

> I was able to download the image from a baofeng UV-5RA, modify it and the 
> upload
> it again.

I confirm that my UV-5R works now as well. Cool.

Fwiw, I've tried to submit changes to the tracker on danplanet for
about half a dozen times and it always failed, so no idea where to
send my patches. If this mail gets through, the python3 patches are
there:

https://salsa.debian.org/debian-hamradio-team/chirp/-/tree/master/debian/patches

py3-print: print foo => print(foo) changes
py3-except: except Exception, e => except Exception as e changes
py3-fixes: the (small) rest

Only the UV-5R module is tested, there are many other issues remaining
in the other modules, but this is a start.

Thanks,
Christoph



Bug#957029: ax25mail-utils: ftbfs with GCC-10

2020-08-04 Thread Christoph Berg
Re: David Ranch
> > Do you think you can resolve the gcc 10 issues (-fcommon is the
> > default now) and put up a new release we can package?
> 
> Hmmm.. I don't have any systems that run GCC 10 today.  Do either of these
> packages NOT compile on your desired system?   What Debian OS version are
> you testing with?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957029

This is the bug we are currently discussing here. (on Debian unstable)

> > On the linpac side, I see Debian hasn't even picked up the last 0.25
> > release yet. I'll see to upload that soonish.
> 
> I would recommend to focus on the 0.28 Git "Develop" branch

We try to avoid packaging git snapshots. Please make a new tarball
release if you want the changes to be included.

> That's ok though coming out of the gates saying this package is "horrible",
> "dead", etc. is a bit brutal.

Sorry. I tried to add "extern" so some variable declarations but it
didn't work out.

Christoph



Bug#957029: ax25mail-utils: ftbfs with GCC-10

2020-08-04 Thread Christoph Berg
> The last commit for ax25mail-utils was back in late December 2019 and April
> 11th 2020 for Linpac so I wouldn't call these as "very much dead upstream".

Hi David,

thanks for the feedback!

I was glancing at the SF.net repo for ax25mail-utils but thought I had
seen the last commit in 2018. Sorry for being sloppy there.

> It's more a matter than it's being sustained.  Also, I'm not very familiar
> with the Debian packaging process but I've never seen code reviews come from
> the packaging process.  Is this a new requirement?  Is there a set of
> required Debian best practices, etc. that is enforced here?

Best general practice would be to see a new regular release in the
form of a tarball.

Do you think you can resolve the gcc 10 issues (-fcommon is the
default now) and put up a new release we can package?

On the linpac side, I see Debian hasn't even picked up the last 0.25
release yet. I'll see to upload that soonish.

(Sorry, we have a lot of old dust in the hamradio team we have to work
on removing, and I don't think anyone in the team has an overview over
all the packages we curate, so please excuse my not so well-founded
assessment of your utilities.)

73,
Christoph DF7CB



Bug#957029: ax25mail-utils: ftbfs with GCC-10

2020-08-04 Thread Christoph Berg
Control: tags -1 upstream wontfix

> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -g -Wall -g 
> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c axgetlist.c
> In file included from /usr/include/string.h:495,
>  from axgetlist.c:19:
> In function ‘strncat’,
> inlined from ‘load_config’ at axgetlist.c:127:42:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:136:10: warning: 
> ‘__builtin___strncat_chk’ output may be truncated copying 1 byte from a 
> string of length 255 [-Wstringop-truncation]

The package is horrible 1990ies C code cluttered with global variables
that no not even agree about the definitions.

Since it seems very much dead upstream, I think it's best to remove
it, unless someone thinks it is still needed. (In which case we need a
patch to fix this.)

Christoph



Bug#967226: redundant-globbing-patterns [* *] for legitimate use of * and debian/*

2020-08-04 Thread Christoph Berg
Package: lintian
Version: 2.80.0
Severity: normal

python-skytools uses this copyright file:

Files: *
Copyright:
 Copyright (c) 2007-2017 Skytools Authors
 Copyright (c) 2007-2017 Marko Kreen
License: ISC

Files: skytools/apipkg.py
Copyright: Copyright (c) holger krekel, 2009
License: MIT

Files: debian/*
Copyright:
 Copyright (c) 2007-2017 Skytools Authors
 Copyright (c) 2007-2017 Marko Kreen
 Copyright (c) 2018 The Debian Project
License: ISC

https://salsa.debian.org/postgresql/python-skytools/-/blob/debian/debian/copyright

which yields these warnings:

E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/changelog
E: python-skytools source: redundant-globbing-patterns [* *] for debian/compat
E: python-skytools source: redundant-globbing-patterns [* *] for debian/control
E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/copyright
E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/py3dist-overrides
E: python-skytools source: redundant-globbing-patterns [* *] for debian/rules
E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/source/format

I don't think that's wrong and lintian is at fault.

Christoph



Bug#956975: Removing acfax (acfax: ftbfs with GCC-10)

2020-08-01 Thread Christoph Berg
Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: severity -2 normal
Control: retitle -2 RM: acfax -- RoM: obsolete and buggy

Re: To 956...@bugs.debian.org
> I believe acfax has long reached the end of its usefulness. The build
> log is full of ugly warnings, the last upstream release was in 1998,
> the Debian release number has reached an impressive -17, and the
> program doesn't even start because it wants to open /dev/dsp which is
> long gone.
> 
> I suspect qsstv is a modern replacement, but I'm not an active
> fax/sstv user so can't say for sure.
> 
> I'll request removal from unstable shortly if I don't get any
> objections.

Doing so now: Please remove acfax from unstable.

Thanks,
Christoph



Bug#966022: lintian: False positive on missing-depends-on-sensible-utils with commands like i3-sensible-pager

2020-07-30 Thread Christoph Berg
Re: Raphaël Hertzog
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3-sensible-pager

Additionally, the warnings are somewhat useless because it doesn't say
which of the utils is being nagged about.

Could the warning be rephrased to include that?

E: flrig: missing-depends-on-sensible-utils usr/bin/flrig sensible-something

Christoph



Bug#956975: Removing acfax (acfax: ftbfs with GCC-10)

2020-07-25 Thread Christoph Berg
Hi,

I believe acfax has long reached the end of its usefulness. The build
log is full of ugly warnings, the last upstream release was in 1998,
the Debian release number has reached an impressive -17, and the
program doesn't even start because it wants to open /dev/dsp which is
long gone.

I suspect qsstv is a modern replacement, but I'm not an active
fax/sstv user so can't say for sure.

I'll request removal from unstable shortly if I don't get any
objections.

Christoph



Bug#964208: wsjtx: FTBFS without internet access

2020-07-05 Thread Christoph Berg
Re: tmanc...@debian.org
> For now I'll add docbook-xsl to the B-D for wsjtx
> and upload with the patch for XSLTPROC_OPTS to add --nonet.

That's the best option, I think.

Thanks!

Christoph



Bug#964208: wsjtx: FTBFS without internet access

2020-07-05 Thread Christoph Berg
Re: tmanc...@debian.org
> > I/O error : Attempt to load network entity 
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > warning: failed to load external entity 
> > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
> > compilation error: file /etc/asciidoc/docbook-xsl/manpage.xsl line 12 
> > element import
> > xsl:import : unable to load 
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > ...
> 
> So I propose that we reassign this to asciidoc, since any package that
> build-depends on asciidoc and uses the manpage stylesheet should fail in
> the same manner.  I don't have any experience with XSL stylesheets, but
> I assume that the asciidoc package can be updated to include the
> necessary components such that xsl files need not be fetched from the
> network during the build.
> 
> Does that sound reasonable to folks?

The primary problem is that we are missing a build-dependency on
docbook-xsl and possibly more packages of the xsl family which contain
the necessary files.

I can't say if that is actually a bug in asciidoc to not depend on
the bunch. (I guess at least a Recommends or Suggests there is in
order, but that wouldn't fix the B-D problem.)

Christoph



Bug#964208: wsjtx: FTBFS without internet access

2020-07-04 Thread Christoph Berg
Ideally we should add some --nonet flag to make the failure both more obvious 
and reproducible.

Bug#964016: js8call: New Upstream Available

2020-07-03 Thread Christoph Berg
Re: Dave Hibberd
> I'm happy to prepare an update on salsa, if no one has any objections!

Fine with me.

Thanks,
Christoph



Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-07-03 Thread Christoph Berg
Re: Baptiste BEAUPLAT
> >> Maybe you could add that to vcswatch?
> 
> The main differences between vcswatch and duck.d.n are:
> 
> - history: duck used to keep 6 runs for each package, reporting only
> after 3 failures. vcswatch only keeps the last run.

vcswatch could be improved by not notifying the users for each error.
At the moment the data model is very simple, but adding that would be
possible I'd think.

> - d/control: duck processed the Homepage as well as the
> Vcs-{Git,SVN,Hg,Darcs} fields. vcswatch has a wider support for all Vcs-*.

There's not much that vcswatch supports on top of that. CVS, but I
don't think anyone is still actively using it, the remaining entries
are just bitrot.

> - d/upstream/metadata: duck processed any urls found here.
> - worker: parallel worker for duck, single instance for vcswatch.

vcswatch can start several workers in parallel, the current config
starts up to 5 workers.

> I'm not convinced that adding those features would result in an
> improvement for vcswatch (Cc'ing Christoph to have his input on that).
> 
> Creating a new sub-project, like vcswatch, to qa.debian.org would be
> more sensible IMHO. The new duck could only take care of the http urls
> and leave Vcs stuff to vcswatch.

You could reuse the vcsimport machinery. It's not very pretty, but
works.

Christoph



Bug#963699: PostgreSQL: WolfSSL support

2020-06-27 Thread Christoph Berg
Re: Florian Weimer
> Sadly, upstream refused to clarify this
> 
>   
> 
> At this point, I have no idea what the actual intent is.

Ouch, that's a pretty non-helpful reply from upstream.

Browsing the source I saw only the usual "version 2, or any later
version" headers. I'd think that's what counts, even if the main
website links to GPL2 only.

Christoph



Bug#963699: PostgreSQL: WolfSSL support

2020-06-27 Thread Christoph Berg
Re: Florian Weimer
> WolfSSL is licensed under the GPL, version 2 only.  This means that
> applications which use libpq and whose license is incompatible with
> the GPL now violate the license of WolfSSL.  Furthermore, the original
> GPL compatibility problem is only addressed for programs which are
> licensed under the GPLv2.  The problem remains for programs licensed
> under the GPLv3 (in fact, the problem is more severe because it cannot
> be argued that WolfSSL gives implied permission to indirect linking
> via libpq, unlike direct users of libpq).

Looking into the wolfSSL source, it's actually GPL 2+.

Christoph



Bug#963699: PostgreSQL: wolfSSL support

2020-06-26 Thread Christoph Berg
Re: Felix Lechner
> > For postgresql-12, it fails at the configure stage
> 
> Attached please find a WIP patch for wolfSSL support in postgresql-12.

Hi,

very cool, thanks!

I'm on vacation for the next two weeks, so it's not very likely I can
have a closer look during that time. What you could try is to post it
as a WIP patch on the pgsql-hack...@postgresql.org list to see what
people think. (If you do that, please put me and this bug on Cc.)

> The offending types are called 'ValidateDate' and 'Hash'. They do not
> seem to be part of the wolfSSL ABI.

That's good news. Do you think renaming the types in wolfSSL is
feasible? On the PG side, "Hash" is possibly widely used in various
external extensions, so renaming could be an issue (though not unseen
before). I don't even know what "ValidateDate" is without looking it
up, but it sounds like less an issue.

> 1. DH parameters are not currently loaded from a database-internal PEM
> certificate. The function OBJ_find_sigid_algs is not available. The
> security implications should be discussed with a cryptographer.

Can't say anything about that offhand.

> 2. The contrib module pgcrypto was not compiled with OpenSSL support
> and currently offers only native algorithms. wolfSSL's compatibility
> support for OpenSSL's EVP interface is incomplete and offers only a
> few algorithms. The module should work directly with wolfCrypt.

Do you mean the module shouldn't use the OpenSSL compat layer?

> 3. The error reporting in wolfSSL_set_fd seems to be different from
> OpenSSL. I could not locate SSLerr and decided to return BAD_FUNC_ARG.
> That is what the routine being mimicked does in wolfSSL. If you see an
> SSL connection error, it may be wise to simply remove these two
> statements in src/interfaces/libpq/fe-secure-openssl.c:

Have to look at that later.

Christoph



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

2020-06-24 Thread Christoph Berg
Re: Felix Lechner
> There may be an alternative for some cases mentioned here. The wolfSSL
> encryption library is a FIPS-certified, commercial product with a
> fully usable, although incomplete, OpenSSL compatibility layer.

Interesting pointer, thanks.

For postgresql-12, it fails at the configure stage, though:

configure:11890: checking for CRYPTO_new_ex_data in -lcrypto
configure:11915: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmis
sing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv 
-fexcess-precision=standard -Wno-format-truncation -Wno-stringop-trun
cation -O2  -D_GNU_SOURCEconftest.c -lcrypto  -lz -ledit -lrt -lcrypt -ldl 
-lm  >&5
/usr/bin/ld: cannot find -lcrypto
collect2: error: ld returned 1 exit status
configure:11915: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
| #define PACKAGE_VERSION "12.2"
| #define PACKAGE_STRING "PostgreSQL 12.2"
| #define PACKAGE_BUGREPORT "pgsql-b...@lists.postgresql.org"
| #define PACKAGE_URL ""
| #define PG_MAJORVERSION "12"
| #define PG_VERSION "12.2"
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR "5432"
| #define BLCKSZ 8192
| #define RELSEG_SIZE 131072
| #define XLOG_BLCKSZ 8192
| #define ENABLE_THREAD_SAFETY 1
| #define PG_KRB_SRVNAM "postgres"
| #define USE_OPENSSL 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_PTHREAD_PRIO_INHERIT 1
| #define HAVE_PTHREAD 1
| #define HAVE_STRERROR_R 1
| #define HAVE_GETPWUID_R 1
| #define HAVE_GETHOSTBYNAME_R 1
| #define HAVE_LIBM 1
| #define HAVE_LIBREADLINE 1
| #define HAVE_LIBZ 1
| #define HAVE_SPINLOCKS 1
| #define HAVE_ATOMICS 1
| /* end confdefs.h.  */
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char CRYPTO_new_ex_data ();
| int
| main ()
| {
| return CRYPTO_new_ex_data ();
|   ;
|   return 0;
| }
configure:11924: result: no
configure:11934: error: library 'crypto' is required for OpenSSL

Christoph



Bug#932296: qa.debian.org: getwatch filling up /tmp

2020-06-21 Thread Christoph Berg
Re: Lucas Nussbaum
> To get the watch file, UDD extracts the source package (once per source
> package per version; then the watch file is stored in DB). /tmp on
> ullmann only has 5.3GB available, which is too small to extract some
> source packages in Debian (such as nvidia-cuda-toolkit).

For exactly this use case, I wrote `dscextract` in devscripts. It
extracts files from debian/* without having to unpack the tarball.

Christoph



Bug#962828: libpgjava: CVE-2020-13692

2020-06-14 Thread Christoph Berg
Re: Salvatore Bonaccorso
> CVE-2020-13692[0]:
> | PostgreSQL JDBC Driver (aka PgJDBC) before 42.2.13 allows XXE.

Hi,

upstream switched the buildsystem in the .13 release, so uploading
isn't as easy as I had hoped. Details are in

https://github.com/pgjdbc/pgjdbc/issues/1440

(Seen the end of the thread, the beginning is about Fedora.)

> Please adjust the affected versions in the BTS as needed.

More info from Dave Cramer:

> > which older versions are affected by this, and what is the impact?
> >
> 
> I would probably only worry about 42.2.x versions
> impact summary
> https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
> 
> 
> > In Debian, we currently ship:
> >
> > libpgjava  | 9.2-1002-1| oldoldstable | source (ignore, it's EOL
> > really soon)
> > libpgjava  | 9.4.1212-1| oldstable| source
> > libpgjava  | 42.2.5-2  | stable   | source
> > libpgjava  | 42.2.12-1 | testing  | source
> > libpgjava  | 42.2.12-1 | unstable | source
> >
> > Can you share the actual CVE diff, so we can fix it in the older
> > versions?
>
> Here is the diff
> https://github.com/pgjdbc/pgjdbc/commit/14b62aca4764d496813f55a43d050b017e01eb65

(I haven't checked yet if that diff applies to the buster package.)

Christoph



Bug#960385: dds: diff for NMU version 2.9.0-7.1

2020-06-10 Thread Christoph Berg
Re: Bruno Naibert de Campos
> I've prepared an NMU for dds (versioned as 2.9.0-7.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Thanks!

I rescheduled it for immediate release.

Christoph



Bug#962542: RFS: pat/0.9.0+dfsg.1-1 [ITP] -- Winlink client for sending and receiving radio mail

2020-06-09 Thread Christoph Berg
Hi Taowa,

some comments on the package:

The list of Depends is borked, I don't think you need any of the go
packages at runtime as everything is statically linked.

Why is libax25 there? It should be pulled in via shlibdeps, not
explicitly.

The description doesn't mention anything about hamradio, so an
occasional reader might think this is something to be used over the
internet.

After reading it several times, looking at the pat homepage, and the
winlink wikipedia article, I'm still not sure what the role of pat is.
Could you add a sentence or two how it interfaces with the rest of the
winlink network? Do I need to have a working ax25 modem or any of the
other (radio?) protocols? Are there any programs in Debian that the
package should recommend/suggest to get the radio interface working?

The pat-configure(1) manpage is very confusing, it took me several
minutes to figure out that the command to be invoked is actually
"pat configure" with a space. Please fix the synopsis to make that
clear.

Likewise, I think the comment on debian/pat.lintian-overrides is
confusing, I don't have any idea why you are citing that policy
section there. It might help to put "pat configure" into quotes. It
looked more like bad grammar than what you really wanted to say.
I think the override comment should be, along with a full pattern:

# "pat configure" has a separate manpage
pat: manpage-without-executable /usr/share/man/man1/pat-configure.1.gz

(recheck the full warning, I made it up here.)

What's that bindata_assetfs.go binary blob? Should that also better be
excluded with building the orig tarball?

73,
Christoph DF7CB



Bug#961594: Connection failed [IP: 151.101.112.204 80]

2020-06-03 Thread Christoph Berg
> > I wonder if turning on apt's Debug::Acquire::http would give more of a
> > clue on where things go wrong?  OTOH given this is highly intermittent
> > it'd be quite noisy...  Christoph, would you be able to give that a try?
> 
> I'll do that now. The first two retries with that setting didn't
> reproduce the problem, though.

20:20:00 Get: 31 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:22:05 GET 
/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44%2bdfsg-5%2bdeb9u4_amd64.deb
 HTTP/1.1
20:22:05 Host: security.debian.org
20:22:05 User-Agent: Debian APT-HTTP/1.3 (1.4.10)
20:22:05
20:22:05
20:22:05 Answer for: 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44+dfsg-5+deb9u4_amd64.deb
20:22:05 HTTP/1.1 200 OK
20:22:05 Server: Apache
20:22:05 X-Content-Type-Options: nosniff
20:22:05 X-Frame-Options: sameorigin
20:22:05 Referrer-Policy: no-referrer
20:22:05 X-Xss-Protection: 1
20:22:05 Last-Modified: Thu, 23 Apr 2020 05:40:59 GMT
20:22:05 ETag: "35840-5a3eeb18b3cf9"
20:22:05 Cache-Control: public, max-age=2592000
20:22:05 Expires: Tue, 28 Apr 2020 19:09:10 GMT
20:22:05 X-Clacks-Overhead: GNU Terry Pratchett
20:22:05 Content-Type: application/x-debian-package
20:22:05 Via: 1.1 varnish
20:22:05 Content-Length: 219200
20:22:05 Accept-Ranges: bytes
20:22:05 Date: Wed, 03 Jun 2020 18:22:05 GMT
20:22:05 Via: 1.1 varnish
20:22:05 Age: 515696
20:22:05 Connection: keep-alive
20:22:05 X-Served-By: cache-fra19137-FRA, cache-hhn4026-HHN
20:22:05 X-Cache: HIT, HIT
20:22:05 X-Cache-Hits: 1, 1
20:22:05 X-Timer: S1591208526.784738,VS0,VE0
20:22:05
20:22:05 Get: 32 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:24:10 GET 
/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44%2bdfsg-5%2bdeb9u4_amd64.deb
 HTTP/1.1
20:24:10 Host: security.debian.org
20:24:10 User-Agent: Debian APT-HTTP/1.3 (1.4.10)
20:24:10
20:24:10
20:24:10 Answer for: 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44+dfsg-5+deb9u4_amd64.deb
20:24:10 HTTP/1.1 200 OK
20:24:10 Server: Apache
20:24:10 X-Content-Type-Options: nosniff
20:24:10 X-Frame-Options: sameorigin
20:24:10 Referrer-Policy: no-referrer
20:24:10 X-Xss-Protection: 1
20:24:10 Last-Modified: Thu, 23 Apr 2020 05:40:59 GMT
20:24:10 ETag: "35840-5a3eeb18b3cf9"
20:24:10 Cache-Control: public, max-age=2592000
20:24:10 Expires: Tue, 28 Apr 2020 19:09:10 GMT
20:24:10 X-Clacks-Overhead: GNU Terry Pratchett
20:24:10 Content-Type: application/x-debian-package
20:24:10 Via: 1.1 varnish
20:24:10 Content-Length: 219200
20:24:10 Accept-Ranges: bytes
20:24:10 Date: Wed, 03 Jun 2020 18:24:10 GMT
20:24:10 Via: 1.1 varnish
20:24:10 Age: 515821
20:24:10 Connection: keep-alive
20:24:10 X-Served-By: cache-fra19137-FRA, cache-hhn4074-HHN
20:24:10 X-Cache: HIT, HIT
20:24:10 X-Cache-Hits: 1, 2
20:24:10 X-Timer: S1591208651.836599,VS0,VE0
20:24:10
20:24:10 Get: 33 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:24:10 Fetched 16.6 MB in 8min 30s (32.4 kB/s)
20:24:10 E: Failed to fetch 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-common_2.4.44+dfsg-5+deb9u4_all.deb:
 Connection failed [IP: 151.101.112.204 80]
20:24:10 E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' 
to continue with missing packages
20:24:11 Reading package lists...

I wonder if the 2min delay before the 2nd last package points at
something. Possibly the transfer was ok for that .deb, but then apt
tries http keepalive but that's already closed?

It could be that the NAT layer in the build chroots here have bad
iptables rules that break this (they have isolated network namespaces
using newpid/newnet). But then, why does it only happen for
security.d.o only, and only for jessie+stretch when buster has also
security? It's also restricted to a set of VMs at Hetzner, while other
machines are fine.

Also, the phenomenon is new (~3 months old or so), while the (buster)
buildhosts are much older and the config hasn't been touched except
for kernel updates.

Christoph



Bug#962073: alsa-info is calling home without asking

2020-06-02 Thread Christoph Berg
Package: alsa-utils
Version: 1.2.2-1
Severity: serious

Hi,

I just launched alsa-info and was surprised that it presented me with
this popup box:

┌───┐
│ Newer version of ALSA-Info has been   │
│ found │
│   │
│ Do you wish to download it?   │
├───┤
│ < Yes > < No  >   │
└───┘

Note that this box comes before it asks if the generated report should
be uploaded somewhere.

I don't think it is appropriate for a simple CLI utility to call home
without asking first.

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

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

Versions of packages alsa-utils depends on:
ii  kmod  27+20200310-2
ii  libasound21.2.2-2.1
ii  libatopology2 1.2.2-2.1
ii  libc6 2.30-8
ii  libfftw3-single3  3.3.8-2
ii  libncursesw6  6.2-1
ii  libsamplerate00.1.9-2
ii  libtinfo6 6.2-1
ii  lsb-base  11.1.0

alsa-utils recommends no packages.

Versions of packages alsa-utils suggests:
ii  dialog  1.3-20190808-1

-- no debconf information

Christoph



Bug#961594: Connection failed [IP: 151.101.112.204 80]

2020-06-02 Thread Christoph Berg
Re: Julien Cristau 2020-05-27 <20200527130809.GA1144124@chou>
> > 26 11:58  11:53:34 Err http://security.debian.org/debian-security 
> > stretch/updates/main
> > amd64 libldap-common all 2.4.44+dfsg-5+deb9u4
> > 26 11:58  11:53:34   Connection failed [IP: 151.101.112.204 80]

It just happened again, this time on jessie (for the first time I
think):

12:05:42 E: Failed to fetch 
http://security.debian.org/debian-security/pool/updates/main/k/krb5/libkrb5support0_1.12.1+dfsg-19+deb8u5_amd64.deb
  Connection failed [IP: 151.101.64.204 80]

Source IP in range 176.9.80.32 - 176.9.80.63
netname:HETZNER-fsn1-dc6

> I wonder if turning on apt's Debug::Acquire::http would give more of a
> clue on where things go wrong?  OTOH given this is highly intermittent
> it'd be quite noisy...  Christoph, would you be able to give that a try?

I'll do that now. The first two retries with that setting didn't
reproduce the problem, though.

Christoph



Bug#961604: History was empty on first startup, but appeared on second launch

2020-05-26 Thread Christoph Berg
Package: diodon
Version: 1.9.0-1
Severity: normal

Hi,

I just started using diodon because clipit notified me that it is
gone.

On the first startup, I selected some options (notably to track the
primary selection and to sync selections), and tried to select some
things. The history in the diodon systray icon remained empty
("").

Upon killing diodon and restarting it, things started working.

Using awesome, no gnome or other DE.

$ diodon

(diodon:29053): dbind-WARNING **: 16:58:18.339: Couldn't connect to 
accessibility bus: Failed to connect to socket /tmp/dbus-Dz5rIZiGzD: 
Verbindungsaufbau abgelehnt

(diodon:29053): Gdk-CRITICAL **: 16:58:18.535: 
gdk_window_thaw_toplevel_updates: assertion 
'window->update_and_descendants_freeze_count > 0' failed


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

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

Versions of packages diodon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libappindicator3-1   0.4.92-8
ii  libc62.30-8
ii  libdiodon0   1.9.0-1
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libpeas-1.0-01.26.0-2
ii  zeitgeist-core   1.0.2-3

diodon recommends no packages.

diodon suggests no packages.

-- no debconf information

Christoph



Bug#961594: Connection failed [IP: 151.101.112.204 80]

2020-05-26 Thread Christoph Berg
Package: mirrors,apt
Severity: normal

On the apt.postgresql.org buildds, I've repeatedly seen failures when
retrieving files from security.debian.org. It started a few weeks ago,
and stopped when I reported the problem on #debian-mirrors on the 20th
when jcristau modified some SRV records for the originating network.
(The problem was seen from a Hetzner host in 78.46.0.0/15 aka
HETZNER-RZ-NBG-BLK5).

Now the problem is back, this time from Hetzner 144.76.0.0/16
HETZNER-RZ-BLK-ERX1.

26 11:58  11:53:34 Err http://security.debian.org/debian-security 
stretch/updates/main
amd64 libldap-common all 2.4.44+dfsg-5+deb9u4
26 11:58  11:53:34   Connection failed [IP: 151.101.112.204 80]
26 11:58  jcristau: it happened again
26 11:59  this time from 144.76.0.0/16 HETZNER-RZ-BLK-ERX1
26 12:18  hmm there's 2 places apt seems to say "Connection failed", 
one is closed
connection while getting headers, i can't quite figure out 
the other one
26 12:19  Myon: can you file a bug against mirrors,apt so we can get 
input from the
apt folks?  i'm not sure i can usefully escalate to fastly 
just yet
26 14:46  if a bug with these two lines is enough, sure
26 14:46  curious why it's always that .deb, bad cache?
26 14:47  or maybe one bad backend?
26 14:49  yeah i don't know :/

Christoph



Bug#961532: devscripts: Missing package relation with pristine-tar (used by origtargz)

2020-05-25 Thread Christoph Berg
Re: Axel Beckert
> to my surprise the devscripts has no package relation with pristine-tar
> nor is it mentioned in devscripts' long package description despite
> origtargz uses it unconditionally. pristine-tar is though mentioned in
> the origtargz(1) man page and changelog.Debian.gz.
> 
> origtargz though ignores any errors from the pristine-tar (not sure if
> feature or bug ;-), so a missing pristine-tar binary is not noticed
> during usage as origtargz just falls back to other acquisition methods.

It intentionally ignores errors, it's really a best-effort tool to
look around where the tarball is.

Maybe it could be smarter by checking if there is a
origin/pristine-tar branch but pristine-tar isn't installed, though.

Christoph



Bug#961501: remmina is calling home for update notifications

2020-05-25 Thread Christoph Berg
Package: remmina
Version: 1.4.3+dfsg-2
Severity: grave

Hi,

this is the second time I've gotten an "What's new in Remmina" popup
window out of the blue (i.e. not while actually using it, it's just
sitting in the background at the moment). I suspect it is calling
home, which would be a gross privacy violation. It's not remmina
upstream's business if I have the program running or not. Note that
the "Send usage statistics silder" is disabled in the screenshot.

Please disable that logic in the default install.

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

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

Versions of packages remmina depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.16-2
ii  libavahi-client3 0.8-1
ii  libavahi-common3 0.8-1
ii  libavahi-ui-gtk3-0   0.8-1
ii  libayatana-appindicator3-1   0.5.4-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libgcrypt20  1.8.5-5
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-8
ii  libsodium23  1.0.18-1
ii  libsoup2.4-1 2.70.0-1
ii  libssh-4 0.9.4-1
ii  libssl1.11.1.1g-1
ii  libvte-2.91-00.60.2-1
ii  remmina-common   1.4.3+dfsg-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.4.3+dfsg-2
pn  remmina-plugin-secret  
ii  remmina-plugin-vnc 1.4.3+dfsg-2

Versions of packages remmina suggests:
pn  remmina-plugin-exec 
pn  remmina-plugin-kwallet  
pn  remmina-plugin-nx   
pn  remmina-plugin-spice
pn  remmina-plugin-www  
pn  remmina-plugin-xdmcp

-- no debconf information

Christoph


Bug#960697: dh_missing manpage still defaults to --list-missing

2020-05-15 Thread Christoph Berg
Package: debhelper
Version: 13
Severity: normal

The dh_missing manpage wasn't updated for #917368:

OPTIONS
   --list-missing
   Warn on stderr about source files not installed to somewhere.

   Note that many dh-tools acting on a path will mark the path as 
installed even if
   it has been excluded via -X or --exclude.  This is also seen when a 
dh-tool is
   acting on a directory and exclusion is used to ignore some files in 
the directory.
   In either case, this will make dh_missing silently assume the 
excluded files have
   been handled.

   This is the default in compat 12 and later.

Christoph



Bug#960690: RM: pgadmin3 -- ROM; obsolete and unmaintained

2020-05-15 Thread Christoph Berg
Package: ftp.debian.org
Severity: normal

Please remove pgadmin3 from unstable. Upstream has long moved to
pgadmin4, and attempts at keeping the old codebase alive by other
people across the internet have failed to produce anything that works
on all platforms.

Let's stick a fork in it.

Christoph



Bug#959665: git-buildpackage: please put a full stop after "New upstrem version X."

2020-05-04 Thread Christoph Berg
I prefer my debian/changelog entries to end with a dot, please allow
for that.

Christoph



Bug#959705: Please enable datachecksums for new clusters

2020-05-04 Thread Christoph Berg
Control: tags -1 upstream

> Please consider enabling data checksums for new clusters on versions
> that support them. From what I can tell, the upstream vibe became
> something along the lines of "they dont hurt performance wise and
> its a good idea generally".

I agree it would be a good thing, but I'd still rather not deviate
from the upstream default here.

Christoph



Bug#959165: udd vcswatch: 429 "Retry later" or "could not read Username" from Salsa

2020-04-30 Thread Christoph Berg
Control: reassign -1 python-asteval

Re: Rebecca N. Palmer 2020-04-30 
> spyder, python-asteval and beignet don't have a cgit in Vcs-Git.  Hence,
> while I agree it's a bug that apertium-bel does, this alone doesn't explain
> either of the above messages.

Salsa was down for two days, you can speed up the rescan by clicking
the "Scan now" buttons.

spyder is fine now, but python-asteval is buggy, the repository
doesn't seem to exist.

Vcs-Browser: https://salsa.debian.org/science-team/python-asteval
Vcs-Git: https://salsa.debian.org/science-team/python-asteval.git

Christoph



Bug#959165: udd vcswatch: 429 "Retry later" or "could not read Username" from Salsa

2020-04-30 Thread Christoph Berg
Control: reassign -1 apertium-bel

Re: Rebecca N. Palmer 2020-04-30 
> Package: qa.debian.org
> User: qa.debian@packages.debian.org
> Usertags: udd
> 
> Some packages' vcswatch pages have the error
> 
> fatal: could not read Username for 'https://salsa.debian.org': No such
> device or address
> 
> (e.g. apertium-bel, python-asteval) or

For apertium-bel, the bug is that its Vcs-Git URL contains a stray
/cgit/.

Vcs-Browser: https://salsa.debian.org/science-team/apertium-bel
Vcs-Git: https://salsa.debian.org/cgit/science-team/apertium-bel.git

(Didn't check the others.)

Christoph



Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED

2020-04-12 Thread Christoph Berg
retitle 950920 RFP: trimesh -- Python triangular meshes with an emphasis on 
watertight surfaces
noowner 950920
thanks

Re: Thorsten Alteholz 2020-04-08 
> please mention trimesh-3.5.25/models/duck.dae in your debian/copyright.
> 
> While you are at it, please also take care of the lintian error.

I updated the copyright, but there's more stuff to do in the new
upstream version:

 lintian ../trimesh_3.6.20-1_amd64.changes
E: trimesh source: source-is-missing 
trimesh/resources/javascript/load_base64.js line length is 2095 characters 
(>512)
W: python3-trimesh: broken-zip 
usr/lib/python3/dist-packages/trimesh/resources/gltf_2_schema.zip
W: trimesh source: dep5-copyright-license-name-not-unique (paragraph at line 
108)

There's also a load of errors at test time because the "models"
directory doesn't get created:

ERROR: tests.test_3mf (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: tests.test_3mf
Traceback (most recent call last):
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/test_3mf.py", 
line 2, in 
from . import generic as g
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/generic.py", 
line 332, in 
data = _load_data()
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/generic.py", 
line 137, in _load_data
for f in os.listdir(dir_models)]
FileNotFoundError: [Errno 2] No such file or directory: 
'/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/models'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3.8/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/test_3mf.py", 
line 4, in 
import generic as g
ModuleNotFoundError: No module named 'generic'


TBH, that's a lot more than my interest in the package as such, so I'd
be grateful if someone else would take over this ITP.

Git is here: https://salsa.debian.org/3dprinting-team/trimesh.git

Christoph



Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye

2020-03-31 Thread Christoph Berg
Re: Moritz Muehlenhoff 2020-03-27 <20200327220044.s7cmyqmlnevty...@inutil.org>
> > There's a py3 branch in upstream Hg that's activish. I haven't tried
> > it yet, but it looks promising. I'll give it a try over the weekend
> > and report back here.

I've pushed the new branch to our git, but it's still so broken that I
don't think uploading makes sense.

I mailed some basic patches to upstream, hopefully they can get this
working soon.

Christoph



Bug#947763: "aCount" is not a spelling error of "account"

2020-03-30 Thread Christoph Berg
Re: Felix Lechner 2020-03-30 

> Hi Christoph,
> 
> On Mon, Dec 30, 2019 at 2:51 AM Christoph Berg  wrote:
> >
> > "aCount" is hardly a spelling error for "account". It's not even
> > present in the source, but only in the "strings /usr/bin/cqrlog"
> > output.
> 
> Since the string is not present in your source, your bug was probably
> filed against the wrong package.

I'm filing this against lintian because this is a false positive
reported by lintian.

If lintian is going to be annoying with these warnings, maintainers
will tend to ignore them. You should strive to keep the number of
false positives as low as possible.

> Here are a few more using non-standard spelling:
> 
> I: lazarus-ide-gtk2-2.0: spelling-error-in-binary
> usr/lib/lazarus/2.0.6/lazarus-gtk2 Exluded Excluded

Yes, and I'm not reporting these as lintian false positives.

> > I suggest excluding CamelCased words from the spelling check.
> 
> I have not seen a lot of GUI items in camel case (which would cause
> more legitimate strings like it to appear in binaries) and do not
> perceive 'aCount' as a false positive.

If camel case isn't a common spelling error, why is lintian reporting
it? It's clearly a programming artifact, and lintian would be well
advised to ignore it, instead of pestering me.

Christoph



Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye

2020-03-27 Thread Christoph Berg
Re: Moritz Mühlenhoff 2020-03-27 
<20200327215634.GA1565432@pisco.westfalen.local>
> On Sun, Oct 13, 2019 at 07:16:47PM +, Chris Knadle wrote:
> > There has been some discussion about #936299 on the upstream mailing list, 
> > and
> > there have been a few upstream commits starting to port the code to Python3.
> > 
> > http://intrepid.danplanet.com/pipermail/chirp_devel/2019-August/005580.html
> 
> Has there been any further development? Otherwise let's remove chirp
> from the archive until it gets ported, it's currently among the last
> handful of packages blocking the pygtk removal.

There's a py3 branch in upstream Hg that's activish. I haven't tried
it yet, but it looks promising. I'll give it a try over the weekend
and report back here.

Christoph



Bug#955036: "convenience copies" should be named "embedded code copies"

2020-03-27 Thread Christoph Berg
Package: debian-policy
Version: 4.5.0.0
Severity: wishlist

Yesterday I was looking for a document to show upstream why Debian
thinks embedded code copies are bad. I started with looking in policy,
but completely missed section "4.13. Convenience copies of code"
because it doesn't mention "embed".

I think "embedded code copies" is the standard term - I wouldn't even
have known what "convenience copies" are about.

Please consider renaming the section, or at least mention the term
"embedded" somewhere in the text.

Christoph



Bug#954979: RM: postgresql-11 -- ROM; superseded by postgresql-12

2020-03-26 Thread Christoph Berg
Package: ftp.debian.org
Severity: normal

Please remove postgresql-11 from unstable, we have postgresql-12 now.
Furthermore, it's uninstallable now because of clang-9, and fixing
that doesn't make sense, removing is easier.

There's one single rdependency left (postgresql-11-pgl-ddl-deploy,
plus postgresql-11-pglogical which is only there because of
postgresql-11-pgl-ddl-deploy), an update moving that one to PG12 is
waiting in NEW. Please proceed anyway.

Thanks,
Christoph



Bug#954897: pydxcluster: should this package be removed?

2020-03-25 Thread Christoph Berg
Re: Sandro Tosi 2020-03-25 
<158509215087.18239.15325100274815623896.report...@zion.matrix.int>
> i believe this package should be removed:

+1 from me.

Christoph



Bug#954341: lintian: What's going on with "field-too-long Installed-Build-Depends"?

2020-03-22 Thread Christoph Berg
Control: severity -1 important

Re: Felix Lechner 2020-03-20 

> > E: pkg-perl-tools buildinfo: field-too-long Installed-Build-Depends (11190 
> > chars > 5000)
> 
> I will disable the tag for this particular buildinfo field in the near future.

This is causing lots of salsa-ci pipelines to fail (and it's not just
these "weird" nodejs packages):

https://salsa.debian.org/postgresql/pg-cron/-/jobs/622417
https://salsa.debian.org/postgresql/pldebugger/-/jobs/624068

Please make that future happen now.

Thanks,
Christoph



Bug#954186: RFS: libxtrxdsp/0.0.1+git20190830.eec2864-2 -- Library of DSP functions, developed for XTRX SDR

2020-03-19 Thread Christoph Berg
Re: Sepi Gair 2020-03-18 
<370975eaac3fc60a4dc57cb13d003dc9ac47d78b.ca...@email.cz>
>  * Package name: libxtrxdsp
>Version : 0.0.1+git20190830.eec2864-2

Hi Sepi,

I suggest we wait with this upload until the -1 version has passed
NEW.

Christoph



Bug#861789: Please provide database.target as a synchronization point for applications providing databases and needing databases

2020-03-19 Thread Christoph Berg
Re: Michael Biebl 2020-03-18 <27361fa3-c814-8787-6e10-c5d13956a...@debian.org>
> My concerns are still the same as I outlined above, so I think such a
> database.target would not be too useful given it would only be very
> vaguely defined.

Also, we shouldn't invent a snowflake solution in Debian that isn't
standard elsewhere in the systemd world.

We barely moved from specul Debian init scripts to standard service
files shipped with upstream sources, let's not complicate things again
without coordinating this.

Christoph



Bug#953547: RFS: libusb3380/0.0.1+git20190125.c83d1e9-1 [ITP] -- USB3380 abstraction layer for libusb: development

2020-03-10 Thread Christoph Berg
Hi Sepi,

there's a missing copyright attribution:

./cmake_modules/Findlibusb-1.0.cmake:
#  Adapted from cmake-modules Google Code project
#
#  Copyright (c) 2006 Andreas Schneider
#
#  (Changes for libusb) Copyright (c) 2008 Kyle Machulis
#
# Redistribution and use is allowed according to the terms of the New BSD 
license.
#
# CMake-Modules Project New BSD License
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# * Redistributions of source code must retain the above copyright notice, this
#   list of conditions and the following disclaimer.
#
# * Redistributions in binary form must reproduce the above copyright notice,
#   this list of conditions and the following disclaimer in the
#   documentation and/or other materials provided with the distribution.
#
# * Neither the name of the CMake-Modules Project nor the names of its
#   contributors may be used to endorse or promote products derived from this
#   software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE 
FOR
# ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
#  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND 
ON

This looks like the lib should be linked with pthreads:

dpkg-shlibdeps: warning: symbol pthread_setname_np used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries
dpkg-shlibdeps: warning: symbol sem_destroy used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries
dpkg-shlibdeps: warning: symbol sem_post used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries
dpkg-shlibdeps: warning: symbol pthread_join used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries
dpkg-shlibdeps: warning: symbol pthread_sigmask used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries
dpkg-shlibdeps: warning: symbol pthread_create used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries
dpkg-shlibdeps: warning: symbol sem_init used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries
dpkg-shlibdeps: warning: symbol sem_wait used by 
debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none 
of the libraries

/usr/lib/x86_64-linux-gnu/libpthread.so:00011370 T sem_close
/usr/lib/x86_64-linux-gnu/libpthread.so:00010b60 T 
sem_destroy@@GLIBC_2.2.5
/usr/lib/x86_64-linux-gnu/libpthread.so:000115a0 T 
sem_getvalue@@GLIBC_2.2.5
/usr/lib/x86_64-linux-gnu/libpthread.so:00010b20 T sem_init@@GLIBC_2.2.5
/usr/lib/x86_64-linux-gnu/libpthread.so:00010e60 T sem_open
/usr/lib/x86_64-linux-gnu/libpthread.so:000119c0 T sem_post@@GLIBC_2.2.5
/usr/lib/x86_64-linux-gnu/libpthread.so:00011950 T sem_timedwait
/usr/lib/x86_64-linux-gnu/libpthread.so:00011780 T 
sem_trywait@@GLIBC_2.2.5
/usr/lib/x86_64-linux-gnu/libpthread.so:00011470 T sem_unlink
/usr/lib/x86_64-linux-gnu/libpthread.so:00011740 T sem_wait@@GLIBC_2.2.5

(Not sure this is the correct solution, though.)

The rest is fine and good to go I think.

Christoph



Bug#953204: postgresql-11 segmentation fault

2020-03-05 Thread Christoph Berg
Control: tags -1 moreinfo

Re: Tim Bishop 2020-03-05 <27c7ad55-9e4c-7b03-9391-4ef3c660a...@inroads.ai>
> I tried to run postgresql through gdb but was unable to reproduce the error
> this way. The query is running accross multiple child processes and I'm
> unable to determine which one is causing the segfault.

Hi,

can you try to get a coredump?

/etc/postgresql/11/main/pg_ctl.conf:

pg_ctl_options = '-c'

... and then restart the server.

Christoph



Bug#953157: improve brittle pg_lsclusters parsing

2020-03-05 Thread Christoph Berg
Re: Tomas Pospisek 2020-03-05 
<158341012952.22047.14835993299149410230.reportbug@hier>
> if for whatever reason a cluster status line will contain the string
> `Port`, then that line will be filtered out.
> 
> I instead suggest to do:
> 
> PORT=$(($(pg_lsclusters | tail -n +2 | awk '{print $3}' | sort -n | tail 
> -1) + 1))
> 
> `tail -n +2` will output all lines starting from line 2 on (line
> numbering starts at 1), thus omitting the "table header".

pg_lsclusters -h

Christoph



Bug#953120: "salsa.sh update_safe" with no extra arguments should error out

2020-03-04 Thread Christoph Berg
Package: devscripts
Version: 2.20.2
Severity: normal

$ cat config
#SALSA_GROUP=debian-hamradio-team
SALSA_GROUP=debian-hamradio-team/soapysdr
SALSA_TOKEN_FILE=~/.priv/pw/salsa-token
SALSA_IRKER=no
SALSA_KGB=yes
SALSA_IRC_CHANNEL='debian-hams;use_irc_notices=1;squash_threshold=3'
SALSA_CI_CONFIG_PATH=debian/gitlab-ci.yml
SALSA_EMAIL=yes
SALSA_EMAIL_RECIPIENTS=dispatch+%p_...@tracker.debian.org
SALSA_ENABLE_MR=yes
SALSA_ENABLE_ISSUES=yes
SALSA_TAGPENDING=yes

$ cat salsa.sh
#!/bin/sh

salsa --conffile config "$@"

Now run that without any extra arguments like --all:

$ ./salsa.sh update_safe
salsa warn: Repository name is missing
1 packages misconfigured, update them ? (Y/n) ^C

The misconfig warning appeared basically instantaneously so I don't
believe it was actually talking to salsa.

Christoph



Bug#943636: uhd: b-d on python3-all-dev, but not built for all supported Python3 versions

2020-03-04 Thread Christoph Berg
Re: Matthias Klose 2019-10-27 
> Package: src:uhd
> Version: 3.14.1.1-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: python3.8 python3-all-dev
> 
> The package build-depends on python3-all-dev, but does not build
> extensions/libraries for all supported python3 versions (like
> currently introduced in experimental with python3-all-dev.  This
> is seen on the transition tracker for adding python3.8 support
> and creates false positives.

That doesn't seem very RC to me, just annoying.

Christoph



Bug#952974: [Pkg-nagios-devel] Bug#952974: Typo /etc/icingweb2 in a lot of module packages

2020-03-02 Thread Christoph Berg
Re: Sebastiaan Couwenberg 2020-03-02 
<58cea4eb-d7a5-7cca-aea8-0c4238c3f...@xs4all.nl>
> > The typo "/etc/icingweb2" seems to be in a lot of icingweb2 module
> > packages:
> 
> Those are separate source packages from icingaweb2, and not maintained
> within this team. Reassigning.

Fwiw, I suspect that there's some template at fault from which this
was copied. But I didn't look closer than noticing the bad directory
on my box, and then seeing all these hits on codesearch.

Thanks,
Christoph



Bug#952974: Typo /etc/icingweb2 in a lot of module packages

2020-03-02 Thread Christoph Berg
Package: icingaweb2
Version: 2.7.3-1
Severity: normal

The typo "/etc/icingweb2" seems to be in a lot of icingweb2 module
packages:

https://codesearch.debian.net/search?q=icingweb=1



icingaweb2-module-ipl_0.1.1-1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)

icingaweb2-module-director_1.6.0-1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)

icingaweb2-module-nagvis_1.1.1-1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)

icingaweb2-module-pnp_1.1.0-1.1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)


...


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

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

Versions of packages icingaweb2 depends on:
ii  fonts-dejavu-core 2.37-1
ii  fonts-dejavu-extra2.37-1
ii  icingaweb2-common 2.7.3-1
ii  php-xml   2:7.3+69
ii  php7.3-xml [php-xml]  7.3.15-3

Versions of packages icingaweb2 recommends:
ii  apache2 [httpd]   2.4.41-4
ii  icingacli 2.7.3-1
pn  icingaweb2-module-doc 
ii  icingaweb2-module-monitoring  2.7.3-1
ii  php   2:7.3+69
ii  php-cli   2:7.3+69
ii  php-curl  2:7.3+69
pn  php-gd
pn  php-imagick   
pn  php-intl  
pn  php-ldap  
ii  php7.3 [php]  7.3.15-3
ii  php7.3-cli [php-cli]  7.3.15-3
ii  php7.3-curl [php-curl]7.3.15-3
ii  php7.3-json [php-json]7.3.15-3

icingaweb2 suggests no packages.

-- no debconf information

Christoph



Bug#948728: apt doesn't completely remove "postgresql-11" dependencies

2020-03-02 Thread Christoph Berg
Re: Mario E. Weisz 2020-01-12 

> $ sudo apt autoremove
> 
> leaves these packages behind:
> postgresql-client-11

As mentioned in one of the other bugs you filed, this was caused by
/etc/apt/apt.conf.d/01autoremove-postgresql. I've now replaced this
with a smarter solution that only marks packages to be kept if there
are still PostgreSQL clusters of that version. That was overdue,
thanks for prompting that change.

> I contacted a Postgres package maintainer and he believes APT is to blame 
> here.

Re: Mario E. Weisz 2020-01-15 
<23U0Vh3WiVxEJHi_4vcq1wEiSonLY_ixM8K4O8C6-RDP1GyLmNRwgbYYJUU5f3Kd1_a7ApMUAHK_oXULW0JkUOQKU3IdaMzKy9Bzd6KP_RI=@protonmail.com>
> In case anyone is interested, I filed a bug report for APT:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948735
> 
> >postgresql-client-11
> sounds like a bug but the dev seems to be ignoring it.

Fwiw, you filed at least three bugs in three different places (of
which at least one location -- salsa support -- was totally wrong) and
made a huge fuss about it. Claiming "the dev seems to be ignoring it"
after only three days wasn't helping your case either.

I found that bugs that come with so much drama are much better handled
by ignoring them for some time.

Christoph



Bug#950920: RFP: trimesh -- Trimesh is a Python library for loading and using triangular meshes with an emphasis on watertight surfaces

2020-03-01 Thread Christoph Berg
Control: retitle -1 ITP: trimesh -- Python triangular meshes with an emphasis 
on watertight surfaces
Control: owner -1 !
Control: tag -1 pending

Status: Waiting for https://github.com/mikedh/trimesh/issues/728

Christoph



Bug#952572: procps: move binaries back to /bin

2020-02-26 Thread Christoph Berg
Another place where things must be called with absolute path:

/lib/systemd/system $ grep bin/kill *
gdm3.service:ExecReload=/bin/kill -SIGHUP $MAINPID
gdm.service:ExecReload=/bin/kill -SIGHUP $MAINPID
network-manager.service:#ExecReload=/bin/kill -HUP $MAINPID
NetworkManager.service:#ExecReload=/bin/kill -HUP $MAINPID
openvpn@.service:ExecReload=/bin/kill -HUP $MAINPID
prometheus-node-exporter.service:ExecReload=/bin/kill -HUP $MAINPID
smartmontools.service:ExecReload=/bin/kill -HUP $MAINPID
ssh.service:ExecReload=/bin/kill -HUP $MAINPID
thinkfan.service:ExecReload=/bin/kill -HUP $MAINPID
tor@default.service:ExecReload=/bin/kill -HUP ${MAINPID}
tor@.service:ExecReload=/bin/kill -HUP ${MAINPID}
unbound.service:ExecReload=+/bin/kill -HUP $MAINPID

Please revert this change, or at least put a compat symlink in /bin in
place.

Christoph



Bug#919385: postgresql-common: alter system set port ignored by pg-commands

2020-02-24 Thread Christoph Berg
Re: To wim.bert...@ucll.be 2019-02-27 <20190227143731.gc25...@msg.df7cb.de>
> 4. Patch PostgreSQL such that it puts the port into external_pid_file,
> i.e. into /var/run/postgresql/11-main.pid
> 
> The bottom line is that #4 looks most attractive, but I'm not fixing
> this in postgresql-common now. I will try sending a patch for #4 to
> upstream and see if it gets accepted for PG 12+. If so, we can still
> patch the older versions on our side.

I've had another look into this, and as the patch hasn't happened. I'm
documenting this as a configuration to avoid now.

Christoph



Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

2020-02-23 Thread Christoph Berg
Re: Tom Russo 2020-02-23 <20200223182310.ga7...@bogodyn.org>
> The script looks in the top level of the Xastir source tree being built
> for the presence of a .git directory.  The fact that the source tree is under
> a package directory that is itself in git should have no impact (there will
> then be a .git directory at a higher level, and our script will simply 
> be unaware of it and return no SHA at all).

In the packaging repo, xastir is in the top level directory.

https://salsa.debian.org/debian-hamradio-team/xastir

Christoph



Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

2020-02-23 Thread Christoph Berg
Re: Tom Russo 2020-02-23 <20200223174551.gd5...@bogodyn.org>
> That won't work if you're building the Debian package
> out of a tarball (the trick involves looking for a .git directory, and if 
> found, invoking a git log command to get the current SHA-1).

Fwiw, these tricks are often a PITA for package maintainers, because
we keep the packaging also in a git repository, but that one doesn't
have any (git) connection to the upstream xastir.git.

In many cases, we have to patch the build system not to do these
tricks. (Generally, I didn't check if the variant used in xastir is
problematic.)

Christoph



Bug#951001: quisk: SoapySDR support

2020-02-09 Thread Christoph Berg
> Also, how about moving quisk to the debian-hamradio-team on salsa?
> I'd be interested to work on quisk.

I should have checked Salsa before writing that,
https://salsa.debian.org/debian-hamradio-team/quisk

Thanks!
Christoph



Bug#951001: quisk: SoapySDR support

2020-02-09 Thread Christoph Berg
Package: quisk
Version: 4.1.52-1
Severity: wishlist

Hi,

I just discovered quisk - afaict the only SDR application in Debian
that can transmit and not just receive. Unfortunately, it's not built
with soapysdr support which my LimeSDR would require.

Afaict all it takes is build-depending on libsoapysdr-dev and calling
"make soapy3" at build time. Please consider enabling that.

Also, how about moving quisk to the debian-hamradio-team on salsa?
I'd be interested to work on quisk.

Thanks,
Christoph DF7CB



Bug#947151: [3dprinter-general] Bug#947151: Bug#947151: cura: GUI unusable under scaled desktop

2020-02-08 Thread Christoph Berg
Re: Gregor Riepl 2020-01-29 <9ab5ab88-5337-9474-0683-fb21a6317...@gmail.com>
> I think the original upstream bug was this one:
> https://github.com/Ultimaker/Cura/issues/5296

#947151 is about *scaled* desktops, while #5296 is about generally
broken or empty display.

The core issue might still be the same, though.

Christoph



Bug#950934: RM: postgresql-12-wal2json [armel armhf i386 mipsel] -- NBS; Package only supports 64bit

2020-02-08 Thread Christoph Berg
Package: ftp.debian.org
Severity: normal

Hi,

please remove the 32bit packages of postgresql-12-wal2json in
unstable. Thanks.

Reference: https://github.com/eulerto/wal2json/issues/142

Christoph



Bug#950734: Remove postgresql-11 from testing

2020-02-07 Thread Christoph Berg
Re: Graham Inggs 2020-02-07 

> Done.

Thanks!

Christoph



Bug#950608: gmp 6.2.0 crashes postgresql-pgmp

2020-02-06 Thread Christoph Berg
Re: Steven Robbins 2020-02-06 <4839510.uz11uGdL23@riemann>
> > the new gmp version makes postgresql-pgmp crash on arm64:
> > 
> > https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-pgmp/
> 4173638/log.gz
> > (linked from https://packages.qa.debian.org/g/gmp.html)
> 
> ...etc.  Thanks, that's useful to know.  I don't know the postgresql-pgmp 
> code 
> at all.  Can you help me understand what the linked web pages are telling us?

Hi Steve,

the postgresql-pgmp author found a fix so this isn't an issue anymore:

https://github.com/dvarrazzo/pgmp/issues/18
https://github.com/dvarrazzo/pgmp/commit/04274c40b63d3dff758bee47c8525112d64d1ab2

I don't know the gmp internals, but I guess this fix might be
applicable to other gmp users as well if they have problems.

Christoph



Bug#950734: Remove postgresql-11 from testing

2020-02-05 Thread Christoph Berg
Package: postgresql-11
Version: 11.6-2~sid1
Severity: serious

postgresql-11 should not be part of testing, please remove it, and all
reverse-dependencies. The upstreams of the reverse-dependencies have
all been pinged plenty of times, and have had enough time to fix their
stuff.

Thanks,
Christoph



Bug#950608: gmp 6.2.0 crashes postgresql-pgmp

2020-02-04 Thread Christoph Berg
Source: gmp
Version: 2:6.2.0+dfsg-3
Severity: grave

Hi,

the new gmp version makes postgresql-pgmp crash on arm64:

https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-pgmp/4173638/log.gz
(linked from https://packages.qa.debian.org/g/gmp.html)

I can also see the crash on amd64 with a newer postgresql-pgmp
version:

https://salsa.debian.org/postgresql/postgresql-pgmp/-/jobs/545558
https://pgdgbuild.dus.dg-i.net/job/postgresql-pgmp-binaries/28/architecture=amd64,distribution=sid/console

(The new postgresql-pgmp version works fine with the old gmp: 
https://travis-ci.org/dvarrazzo/pgmp/jobs/644531088)

Christoph



Bug#947151: [3dprinter-general] Bug#947151: cura: GUI unusable under scaled desktop

2020-01-29 Thread Christoph Berg
Re: Gregor Riepl 2019-12-22 
> The bug is known, but I'm not sure if it is in python3-qt or in Cura itself.

Do you know if it was already reported to upstream? I couldn't find it
on github, but there's 967 issues open...

Christoph



Bug#947151: [3dprinter-general] Bug#947151: Bug#947151: cura: GUI unusable under scaled desktop

2020-01-29 Thread Christoph Berg
Re: Kyle Robbertze 2020-01-29 <0b496332-2245-ee1b-8515-a2931ff12...@debian.org>
> While the update means I can actually read some of the text, alignment
> between checkboxes and labels is still broken as is the text displayed
> on the screen. I have attached two screenshots of the issue I am seeing.

Ah, so this was a different bug than the one I was seeing - I didn't
have any text in the buttons.

Christoph



Bug#950033: missing dependencies on python3-healpy and python3-tk

2020-01-28 Thread Christoph Berg
Package: pymoctool
Version: 0.5.0-4
Severity: normal

pymoctool is missing dependencies on python3-healpy and python3-tk:

$ pymoctool ../cepheiden.moc --plot
Traceback (most recent call last):
  File "/usr/bin/pymoctool", line 40, in 
main()
  File "/usr/bin/pymoctool", line 33, in main
tool.run(sys.argv[1:])
  File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 111, in run
self.command[p](self)
  File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 380, in plot
from .plot import plot_moc
  File "/usr/lib/python3/dist-packages/pymoc/util/plot.py", line 16, in 
import healpy
ModuleNotFoundError: No module named 'healpy'

... installing python3-healpy:

$ pymoctool ../cepheiden.moc --plot
Traceback (most recent call last):
  File "/usr/bin/pymoctool", line 40, in 
main()
  File "/usr/bin/pymoctool", line 33, in main
tool.run(sys.argv[1:])
  File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 111, in run
self.command[p](self)
  File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 380, in plot
from .plot import plot_moc
  File "/usr/lib/python3/dist-packages/pymoc/util/plot.py", line 18, in 
import matplotlib.pyplot as plt
  File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 2349, in 

switch_backend(rcParams["backend"])
  File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 221, in 
switch_backend
backend_mod = importlib.import_module(backend_name)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py", 
line 1, in 
from . import _backend_tk
  File "/usr/lib/python3/dist-packages/matplotlib/backends/_backend_tk.py", 
line 6, in 
import tkinter as tk
ModuleNotFoundError: No module named 'tkinter'

... after installing python3-tk, rendering works.

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

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

Versions of packages pymoctool depends on:
ii  python33.7.5-3
ii  python3-pymoc  0.5.0-4

pymoctool recommends no packages.

pymoctool suggests no packages.

-- no debconf information

Christoph



Bug#947244: shouldn't include Architectures in sources file by default

2020-01-23 Thread Christoph Berg
Re: Wouter Verhelst 2020-01-23 <20200123130529.gf1...@grep.be>
> > (On a similar ticket, should "deb-src" be include by default? At least
> > a switch to configure that at "enable" time would be nice.)
> 
> I think it should. It doesn't hurt?

Sometimes I try getting rid of extra things to download when there's a
lot of repositories activated so "apt update" doesn't take ages.

It's probably a good default, but as said, a switch would be nice.

Christoph



Bug#949377: dh_python --buildsystem=cmake doesn't pass recently added Python_EXECUTABLE variable

2020-01-22 Thread Christoph Berg
Fwiw, olasd found a way to make it work using the current dh_python
version:

https://salsa.debian.org/3dprinting-team/libarcus/commit/2503ec8273bdb67a710a0d2b633efa8909ed083c

But having that built-in would be nicer.

Christoph

>From 2503ec8273bdb67a710a0d2b633efa8909ed083c Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont 
Date: Mon, 20 Jan 2020 12:39:01 +0100
Subject: [PATCH] Add patch to force python version in CMake

---
 ...erriding-the-Python-version-in-CMake.patch | 35 +++
 debian/patches/series |  1 +
 debian/rules  |  2 ++
 3 files changed, 38 insertions(+)
 create mode 100644 
debian/patches/0003-Allow-overriding-the-Python-version-in-CMake.patch

diff --git 
a/debian/patches/0003-Allow-overriding-the-Python-version-in-CMake.patch 
b/debian/patches/0003-Allow-overriding-the-Python-version-in-CMake.patch
new file mode 100644
index 000..870cfcc
--- /dev/null
+++ b/debian/patches/0003-Allow-overriding-the-Python-version-in-CMake.patch
@@ -0,0 +1,35 @@
+From: Nicolas Dandrimont 
+Date: Mon, 20 Jan 2020 12:37:08 +0100
+Subject: Allow overriding the Python version in CMake
+
+---
+ CMakeLists.txt  | 2 +-
+ cmake/FindSIP.cmake | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index b97ee18..92cae18 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -32,7 +32,7 @@ if(BUILD_PYTHON)
+ find_package(PythonLibs 3.4 REQUIRED)
+ else()
+ # Use FindPython3 for CMake >=3.12
+-find_package(Python3 3.4 REQUIRED COMPONENTS Interpreter Development)
++find_package(Python3 ${PYVER} EXACT REQUIRED COMPONENTS Interpreter 
Development)
+ endif()
+
+ find_package(SIP REQUIRED)
+diff --git a/cmake/FindSIP.cmake b/cmake/FindSIP.cmake
+index 815a16d..90b5398 100644
+--- a/cmake/FindSIP.cmake
 b/cmake/FindSIP.cmake
+@@ -63,7 +63,7 @@ if(${CMAKE_VERSION} VERSION_LESS 3.12)
+ endif()
+ else()
+ # Use FindPython3 for CMake >=3.12
+-find_package(Python3 3.4 REQUIRED COMPONENTS Interpreter Development)
++find_package(Python3 ${PYVER} EXACT REQUIRED COMPONENTS Interpreter 
Development)
+ endif()
+
+ get_filename_component(_python_binary_path ${Python3_EXECUTABLE} DIRECTORY)
diff --git a/debian/patches/series b/debian/patches/series
index dd440ac..a81baff 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 01-remove-rpath.patch
 02-add-python-version.patch
+0003-Allow-overriding-the-Python-version-in-CMake.patch
diff --git a/debian/rules b/debian/rules
index fa1dac0..9d08fe2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,5 +4,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk

+export PYBUILD_CONFIGURE_ARGS=-DPYVER={version}
+
 %:
dh $@ --buildsystem=pybuild --with python3 --with sip3
--
2.20.1



Bug#949428: postgresql-12: FTBFS with libxml2 2.9.10 (uses xml2-config)

2020-01-20 Thread Christoph Berg
Control: tags -1 wontfix

Re: Mattia Rizzolo 2020-01-20 <20200120194247.ga3704...@mapreri.org>
> your package is using `xml2-config` to detect and use libxml2.  I'm
> removing that script

Hi,

please don't do that unless you get libxml2 upstream to properly
announce the deprecation first.

Christoph



Bug#949377: dh_python --buildsystem=cmake doesn't pass recently added Python_EXECUTABLE variable

2020-01-20 Thread Christoph Berg
Package: dh-python
Version: 4.20191017
Severity: normal

libarcus and libsavitar from the 3dprinting team have the problem
that the cmake jobs called from dh_auto_install use the wrong python
version, note that 3.8 is used in the 3.7 install pass:

https://salsa.debian.org/3dprinting-team/libsavitar/-/jobs/515849#L935

olasd tracked the problem down to find_package(Python3) not working:

I: pybuild base:217: dh_auto_configure --buildsystem=cmake 
--builddirectory="/builds/3dprinting-team/libsavitar/debian/output/libsavitar-4.4.1/.pybuild/cpython3_3.7/build"
 -- -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.7 
-DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.so
 -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.7m
...
-- Found Python3: /usr/bin/python3.8 (found suitable version "3.8.1", minimum 
required is "3.4") found components:  Interpreter Development

It looks like dh-python should include Python_EXECUTABLE:

https://gitlab.kitware.com/cmake/cmake/commit/06d9e67fbd2b2dfc9cba12327866b2f73eab8a18

cmake variables are case-sensitive, afaict.

(cmake maintainers are in Cc if they want to add something.)

IRC log for reference:

20 12:07  Myon: looks like pybuild's dh_auto_configure override for 
cmake passes old variables for cmake's python stuff 
(-DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.7 
-DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.so
 -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.7m), but not the new ones (that 
are only supported since cmake 3.12)
[...]
20 12:11  pybuild defers to debhelper's cmake buildsystem
20 12:11  maybe that calls make install
20 12:11  (but the actual issue is at the configure step, the py3.7 
build detects python3.8)
20 12:13  it's still doing the 3.8 things in the 3.7 pass
20 12:13  https://gitlab.kitware.com/cmake/cmake/issues/19492
20 12:13  looks like what dh-python is trying to do is not possible 
anymore
20 12:13  ah, good catch
20 12:13  -- Found PythonInterp: /usr/bin/python3.7 (found suitable 
version "3.7.6", minimum required is "3.4")
20 12:13  -- Found PythonLibs: 
/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.so (found 
suitable version "3.7.6", minimum required is "3.4")
20 12:13  -- Found Python3: /usr/bin/python3.8 (found suitable version 
"3.8.1", minimum required is "3.4") found components:  Interpreter Development
20 12:14  or...
20 12:15  ah, yes. dh-python/pybuild should set the new cmake 
Python_EXECUTABLE variable 
(https://gitlab.kitware.com/cmake/cmake/commit/06d9e67fbd2b2dfc9cba12327866b2f73eab8a18)

Thanks,
Christoph



Bug#948797: fails to compile cqrlog on mipsel: Fatal: Internal error 200603251

2020-01-16 Thread Christoph Berg
Re: Graham Inggs 2020-01-14 
> I think this is #948803 in binutils.
> 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948803

Thanks for the pointer. This one has been fixed in the meantime.


Re: To Graham Inggs 2020-01-13 <20200113143325.ge11...@msg.df7cb.de>
> Oh, actually I didn't look closely enough - I remembered that cqrlog
> has never successfully built on some arch, but that was mipsel:
> 
> https://buildd.debian.org/status/logs.php?pkg=cqrlog=mipsel
> 
> 2100 111.284/116.512 Kb Used
> /<>/src/./synapse/synautil.pas(2121,88) Warning: (5043) Symbol 
> "ShortMonthNames" is deprecated
> /<>/src/./synapse/synautil.pas(2122,87) Warning: (5043) Symbol 
> "ShortMonthNames" is deprecated
> /<>/src/./synapse/synautil.pas(2118,1) Fatal: Internal error 
> 200603251
> Fatal: (1018) Compilation aborted
> Error: /usr/bin/ppcmipsel returned an error exitcode
> 
> The error message is the same in all mipsel logs except the oldest
> one.

That's the bug I actually wanted to file.

Christoph



Bug#948797: fails to compile cqrlog on arm64: cqrlog.lpr(84) Warning: (9034) "crtbegin.o" not found, this will probably cause a linking failure

2020-01-13 Thread Christoph Berg
Re: Graham Inggs 2020-01-13 
> > Other architectures are fine.
> 
> I don't think anything changed in lazarus or fpc.
> I uploaded doublecmd yesterday and it build successfully on arm64[1].
> Today it fails the reproducible build[2] with the same error as cqrlog.

Oh, actually I didn't look closely enough - I remembered that cqrlog
has never successfully built on some arch, but that was mipsel:

https://buildd.debian.org/status/logs.php?pkg=cqrlog=mipsel

2100 111.284/116.512 Kb Used
/<>/src/./synapse/synautil.pas(2121,88) Warning: (5043) Symbol 
"ShortMonthNames" is deprecated
/<>/src/./synapse/synautil.pas(2122,87) Warning: (5043) Symbol 
"ShortMonthNames" is deprecated
/<>/src/./synapse/synautil.pas(2118,1) Fatal: Internal error 
200603251
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppcmipsel returned an error exitcode

The error message is the same in all mipsel logs except the oldest
one.

Christoph



Bug#948797: fails to compile cqrlog on arm64: cqrlog.lpr(84) Warning: (9034) "crtbegin.o" not found, this will probably cause a linking failure

2020-01-13 Thread Christoph Berg
Source: lazarus
Version: 2.0.6+dfsg-3
Severity: normal

Hi,

I think this is a bug in lazarus on arm64, but maybe I'm wrong:

https://buildd.debian.org/status/fetch.php?pkg=cqrlog=arm64=2.4.0-3=1578918606=0

700 291.337/324.064 Kb Used
800 291.987/324.064 Kb Used
(9009) Assembling dlogupload
(9009) Assembling cqrlog
(9022) Compiling resource /<>/src/cqrlog.or
(9015) Linking /<>/src/cqrlog
cqrlog.lpr(84) Warning: (9034) "crtbegin.o" not found, this will probably cause 
a linking failure
cqrlog.lpr(84) Warning: (9034) "crtend.o" not found, this will probably cause a 
linking failure
cqrlog.lpr(84) Error: (9014) Can't call the linker, switching to external 
linking
cqrlog.lpr(84) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppca64 returned an error exitcode
Error: (lazarus) Compile Project, Target: cqrlog: stopped with exit code 1

Other architectures are fine.

Christoph



Bug#948549: pgadmin3: Segfault when trying toi start query tool

2020-01-13 Thread Christoph Berg
Re: To Erwin Brandstetter 2020-01-10 <20200110140734.ge30...@msg.df7cb.de>
> I can revert to the old wxgtk package on the older distributions, but
> maybe we have to accept that pgadmin3 is dead now and ultimately
> remove it from unstable.

I just updated the pgadmin3 packages on apt.pg.o to use
libwxgtk3.0-dev again instead of libwxgtk3.0-gtk3-dev on anything but
unstable and bullseye.

Christoph



Bug#813487: pgbouncer: Upgrading pgbouncer drops connections when run with systemd

2020-01-12 Thread Christoph Berg
Re: Peter Eisentraut 2020-01-11 

> It might be possible to do this if we have systemd organize the file
> descriptor passing (using socket activation and all that).  It's something
> I've been meaning to look into, but it would be a development effort, not
> just a packaging change.

That sounds promising; all that would be left to do would be to keep
the old instance running while there are still connections to it.

> Another option might be to use the SO_REUSEPORT socket option and start a
> new pgbouncer instance concurrently with the old one.  Then you can shut
> down the old one once the new one is up and taking on connections. I don't
> know whether that's in scope for packaging, either, though.

That would still need systemd allowing to start two instances in
parallel. I think implementing something along these lines is a
prerequisite for the first solution.

Christoph



Bug#948549: pgadmin3: Segfault when trying toi start query tool

2020-01-10 Thread Christoph Berg
Re: Erwin Brandstetter 2020-01-10 
<157862519463.9993.8745255910335394793.reportbug@brsanuc5>
> Package: pgadmin3
> Version: 1.22.2-6.pgdg100+1
> Severity: grave
> Justification: renders package unusable
> 
> Introduced with installing pgadmin3 1.22.2-6.pgdg18.04+1
> Now it segfaults every time when trying to open the essential query tool. 
> Tried
> with Postgres 10, 11, 12.

Not good. I can reproduce the problem here on bullseye.

I can revert to the old wxgtk package on the older distributions, but
maybe we have to accept that pgadmin3 is dead now and ultimately
remove it from unstable.

There's this https://github.com/Symbiatch/pgAdmin3 fork but that
doesn't support PG12 either, and didn't even compile for reasons I
forgot about.

Christoph



Bug#948571: Description isn't descriptive

2020-01-10 Thread Christoph Berg
Package: libstb0
Version: 0.0~git20190817.1.052dce1-1
Severity: normal

Hi,

libstb{0,-dev}'s Description is

Description-en: single-file public domain (or MIT licensed) libraries for C/C++
 It includes the following modules:
  * stb_vorbis.c: decode ogg vorbis files from file/memory to float/16-bit
signed output
...

The short description doesn't say anything about what the library is
doing. I'd suggest something like:

Description-en: single-file image and audio processing libraries for C/C++

The long description should stand by itself, so you should include
some introductory sentence at the beginning:

 libstb is a set of single-file libraries for C/C++.
 The files are dual-licensed under public domain and the MIT license.
 .
 It includes the following modules:
 ...

Christoph



Bug#889883: dh-lua: Please disable --silent in libtool calls

2019-12-31 Thread Christoph Berg
Re: Jean-Michel Vourgère 2018-02-08 <2927066.44csPzL39Z@deimos>
> My rrdtool package uses dh-lua. I get a bunch of compiler-flags-hidden 
> warnings in build log scanner [1], from package blhc.

Hi,

I'm getting these warnings on hamlib. I'd appreciate if the dh-lua fix
were uploaded to unstable as well!

Christoph



Bug#947763: "aCount" is not a spelling error of "account"

2019-12-30 Thread Christoph Berg
Package: lintian
Version: 2.25.0
Severity: normal

I: cqrlog: spelling-error-in-binary usr/bin/cqrlog aCount account

"aCount" is hardly a spelling error for "account". It's not even
present in the source, but only in the "strings /usr/bin/cqrlog"
output.

I suggest excluding CamelCased words from the spelling check.

Thanks,
Christoph



Bug#947244: shouldn't include Architectures in sources file by default

2019-12-23 Thread Christoph Berg
Package: extrepo
Version: 0.6
Severity: normal

Hi,

I just enabled the postgresql repo here:

Holen:10 http://apt.postgresql.org/pub/repos/apt bullseye-pgdg/main Sources 
[42,7 kB]
Holen:11 http://apt.postgresql.org/pub/repos/apt bullseye-pgdg/main amd64 
Packages [147 kB]
Holen:12 http://apt.postgresql.org/pub/repos/apt bullseye-pgdg/main ppc64el 
Packages [146 kB]

I am on amd64, the ppc64el Packages file isn't useful.

$ cat /etc/apt/sources.list.d/extrepo_postgresql.sources
Components: main
Types: deb deb-src
Suites: bullseye-pgdg
Uris: http://apt.postgresql.org/pub/repos/apt
Architectures: amd64 ppc64el
Signed-By: /var/lib/extrepo/keys/postgresql.asc

Please don't include the Architectures line here, it should only be
added by the user if they want to *exclude* some architectures
otherwise enabled via dpkg `--add-architecture`. Perhaps adding the
list as a comment makes sense.

(On a similar ticket, should "deb-src" be include by default? At least
a switch to configure that at "enable" time would be nice.)

Christoph



Bug#947067: extrepo UX quirks

2019-12-20 Thread Christoph Berg
Package: extrepo
Version: 0.6
Severity: wishlist

These could raise nicer warnings:

$ extrepo
Use of uninitialized value $cmdlower in ucfirst at /usr/bin/extrepo line 98.
Undefined subroutine ::ExtRepo::Commandsrun called at (eval 15) line 
1.
...propagated at /usr/bin/extrepo line 102.

$ extrepo --help
syntax error at (eval 15) line 1, near "Debian::ExtRepo::Commands::--"
...propagated at /usr/bin/extrepo line 102.


This should be a syntax error:

$ extrepo update
gpgv: Signatur vom Fr 20 Dez 2019 09:17:24 CET
gpgv:mittels RSA-Schlüssel 
7A8502E9FF4765B162A964171283BEE904FB0E04
gpgv: Korrekte Signatur von "Debian external repositories signing key 
(experimental)"


Repository  does not exist! at 
/usr/share/perl5/Debian/ExtRepo/Commands/Enable.pm line 18.
...propagated at /usr/bin/extrepo line 102.


The search command should separate the output with newlines:

$ extrepo search
gpgv: Signatur vom Fr 20 Dez 2019 09:17:24 CET
gpgv:mittels RSA-Schlüssel 
7A8502E9FF4765B162A964171283BEE904FB0E04
gpgv: Korrekte Signatur von "Debian external repositories signing key 
(experimental)"


Found debian_official:
---
components:
- main
- contrib
- non-free
contact: ftpmas...@debian.org
description: Configuration for the official Debian repository. It should not be 
managed
  through extrepo.
gpg-key-checksum:
  sha256: 9c854992fc6c423efe8622c3c326a66e73268995ecbe8f685129063206a18043
gpg-key-file: debian_official.asc
policies:
  contrib: contrib
  main: main
  non-free: non-free
source:
  Components: 
  Suites: bullseye
  Types: deb deb-src
  URIs: http://deb.debian.org/debian
Found liquorix:
---
description: Liquorix.net alternate desktop multimedia/gaming kernels
gpg-key-checksum:
  sha256: a1e1ed12d8521f3b91772fff10c1bdaa39b42e030b49634f67dc21c85786747c
gpg-key-file: liquorix.asc
policy: main
source:
  Components: main
  Suites: bullseye
  Types: deb deb-src
  URIs: https://liquorix.net/debian
Found neurodebian_software:

... it's hard to tell wehere the next entry starts, and it's not at "---".


The manpage could mention that invoking "search" without arguments
works. Prior to trying, I was wondering why there was no "list all"
command.


Maybe it should notice earlier that I'm not root:

$ extrepo enable pgdg
gpgv: Signatur vom Fr 20 Dez 2019 09:17:24 CET
gpgv:mittels RSA-Schlüssel 
7A8502E9FF4765B162A964171283BEE904FB0E04
gpgv: Korrekte Signatur von "Debian external repositories signing key 
(experimental)"


Permission denied at /usr/bin/extrepo line 102.


Does it have to print that gpg message on each invocation?


It should print some success message I think (or don't do any output):

$ sudo extrepo enable pgdg
gpgv: Signatur vom Fr 20 Dez 2019 09:17:24 CET
gpgv:mittels RSA-Schlüssel 
7A8502E9FF4765B162A964171283BEE904FB0E04
gpgv: Korrekte Signatur von "Debian external repositories signing key 
(experimental)"


$

(Note the extra empty lines.)


Now that it is enabled, I would like a "list" command that shows which
sources.lists entries it knows about.


"sudo extrepo disable pgdg" seemed to be quite slow. Is it accessing
the network for that?


Cheers,
Christoph



Bug#946359: pg-snakeoil: Selftest apears to be broken

2019-12-20 Thread Christoph Berg
Re: Sebastian Andrzej Siewior 2019-12-19 <20191219193659.t6qzowamewru7yfk@flow>
> > One bit that could have been relevant is that I'm running on schroot
> > with tmpfs on an overlay fs.
> 
> But that part is transparent.

There's one thing that doesn't work on overlayfs, renaming (underlay?)
directories. We appear not to have problems with that in Debian, but
yum operations fail horribly in a centos chroot.

But that's not the problem here.

Christoph



Bug#946957: postgresql-common: pg_upgradecluster woe: postgres fails to restart after upgrade

2019-12-19 Thread Christoph Berg
Re: Julian Gilbey 2019-12-18 <20191218140411.ga8...@d-and-j.net>
> Running 'invoke-rc.d postgresql start' does not help: it still does
> not bring up the postgresql server.

Hi,

did you invoke pg_upgradecluster as 'postgres' user? In that case,
systemd doesn't get notified that a new cluster exists until
"systemctl daemon-reload" is run manually.

> The /lib/systemd/system/postgresql@.service files are identical on
> both machines.  And 'systemctl enable postgresql@.service' doesn't do
> anything, though 'systemctl enable postgresql@12-main.service' changes
> the status to enabled.  But even with that, 'invoke-rc.d postgresql
> start' doesn't start it.

What's in /etc/postgresql/12/main/start.conf ? It should be 'auto' to
be included in postgresql.service start.

start.conf is legacy from the old sysvinit days. It is now read by
/lib/systemd/system-generators/postgresql-generator.

Christoph



Bug#946359: pg-snakeoil: Selftest apears to be broken

2019-12-19 Thread Christoph Berg
Re: Sebastian Andrzej Siewior 2019-12-18 <20191218225837.qttuxpwrbo5ukpr3@flow>
> > $ sudo -u clamav freshclam --verbose
> 
> what happens if you strip the sudo part? One of the first thing is to
> change to the clamav user (well so is my memory and the /var/…/clamav is
> owned by clamav so…)? However after I install sudo in my chroot and try
> this it still works :/

Now it just works, both with "sudo freshclam --verbose" and "sudo -u
clamav freshclam --verbose":

$ sudo freshclam --verbose
Thu Dec 19 10:00:32 2019 -> ClamAV update process started at Thu Dec 19 
10:00:32 2019
Thu Dec 19 10:00:32 2019 -> *Current working dir is /var/lib/clamav/
Thu Dec 19 10:00:32 2019 -> *Querying current.cvd.clamav.net
Thu Dec 19 10:00:32 2019 -> *TTL: 539
Thu Dec 19 10:00:32 2019 -> *fc_dns_query_update_info: Software version from 
DNS: 0.102.1
Thu Dec 19 10:00:32 2019 -> *Current working dir is /var/lib/clamav/
Thu Dec 19 10:00:32 2019 -> *check_for_new_database_version: No local copy of 
"daily" database.
Thu Dec 19 10:00:32 2019 -> *query_remote_database_version: daily.cvd version 
from DNS: 25667
Thu Dec 19 10:00:32 2019 -> daily database available for download (remote 
version: 25667)
Thu Dec 19 10:00:32 2019 -> *Retrieving https://database.clamav.net/daily.cvd
Thu Dec 19 10:00:32 2019 -> *downloadFile: Download source:  
https://database.clamav.net/daily.cvd
Thu Dec 19 10:00:32 2019 -> *downloadFile: Download destination: 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp
*   Trying 2606:4700::6810:db54:443...
* TCP_NODELAY set
* Connected to database.clamav.net (2606:4700::6810:db54) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; 
CN=ssl392509.cloudflaressl.com
*  start date: Aug 24 00:00:00 2019 GMT
*  expire date: Mar  1 23:59:59 2020 GMT
*  subjectAltName: host "database.clamav.net" matched cert's "*.clamav.net"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; 
CN=COMODO ECC Domain Validation Secure Server CA 2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c822a6d790)
> GET /daily.cvd HTTP/2
Host: database.clamav.net
user-agent: ClamAV/0.102.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
accept: */*
connection: close

* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200 
< date: Thu, 19 Dec 2019 09:00:33 GMT
< content-type: application/octet-stream
< content-length: 55429776
< set-cookie: __cfduid=d808352f8029efc872822e310079600b81576746033; 
expires=Sat, 18-Jan-20 09:00:33 GMT; path=/; domain=.clamav.net; HttpOnly; 
SameSite=Lax
< last-modified: Wed, 18 Dec 2019 09:53:00 GMT
< etag: "5df9f6fc-34dca90"
< expires: Thu, 19 Dec 2019 13:00:33 GMT
< cache-control: public, max-age=14400
< cf-cache-status: HIT
< age: 3383
< accept-ranges: bytes
< strict-transport-security: max-age=15552000
< x-content-type-options: nosniff
< expect-ct: max-age=604800, 
report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct;
< server: cloudflare
< cf-ray: 54782fd3fa8ed45b-HAM
< 
Time: 3.5s, ETA; 0.0s [===>] 
52.86MiB/52.86MiB
* Connection #0 to host database.clamav.net left intact
Thu Dec 19 10:00:36 2019 -> *updatedb: Running g_cb_download_complete 
callback...
Thu Dec 19 10:00:36 2019 -> *download_complete_callback: Download complete for 
database : 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd
Thu Dec 19 10:00:36 2019 -> *download_complete_callback:   
fc_context->bTestDatabases   : 1
Thu Dec 19 10:00:36 2019 -> *download_complete_callback:   
fc_context->bBytecodeEnabled : 1
Thu Dec 19 10:00:36 2019 -> Testing database: 
'/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd' ...
Thu Dec 19 10:00:36 2019 -> *Loading signatures from 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd
Thu Dec 19 10:00:40 2019 -> *Properly loaded 2061162 signatures from 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd
Thu Dec 19 10:00:41 2019 -> Database test passed.
Thu Dec 19 10:00:41 2019 -> daily.cvd updated (version: 25667, sigs: 2061162, 
f-level: 63, builder: raynman)
Thu Dec 19 10:00:41 2019 -> *fc_update_database: daily.cvd updated.
Thu Dec 19 10:00:41 2019 -> *Current working dir is /var/lib/clamav/
Thu Dec 19 10:00:41 2019 -> *check_for_new_database_version: No local copy of 
"main" database.
Thu Dec 19 10:00:41 2019 -> *query_remote_database_version: main.cvd version 
from DNS: 59
Thu Dec 19 10:00:41 2019 -> main database 

Bug#946359: pg-snakeoil: Selftest apears to be broken

2019-12-18 Thread Christoph Berg
Re: Sebastian Andrzej Siewior 2019-12-11 <20191211141451.tn2u64ssgarpgz25@flow>
> > The test fails in my sid chroot as well because freshclam can't
> > download the database, /var/lib/clamav/ is empty except for a "tmp"
> > directory.
> 
> Do you have a special inet setup? Kind of web proxy or something like
> that.

Nothing special, and the test started failing on ci.debian.net as well
as in my local sid chroot.

> Could you start `freshclam' by hand with --verbose (not sure if --debug
> works) and provide more output? It appears that the version downloaded
> is one less than available and that is where things go south.

In the sid chroot, with an empty /var/lib/clamav/:

$ sudo -u clamav freshclam --verbose
Wed Dec 18 11:56:09 2019 -> ClamAV update process started at Wed Dec 18 
11:56:09 2019
Wed Dec 18 11:56:09 2019 -> *Current working dir is /var/lib/clamav/
Wed Dec 18 11:56:09 2019 -> *Querying current.cvd.clamav.net
Wed Dec 18 11:56:09 2019 -> *TTL: 503
Wed Dec 18 11:56:09 2019 -> *fc_dns_query_update_info: Software version from 
DNS: 0.102.1
Wed Dec 18 11:56:09 2019 -> *Current working dir is /var/lib/clamav/
Wed Dec 18 11:56:09 2019 -> *check_for_new_database_version: No local copy of 
"daily" database.
Wed Dec 18 11:56:09 2019 -> *query_remote_database_version: daily.cvd version 
from DNS: 25667
Wed Dec 18 11:56:09 2019 -> daily database available for download (remote 
version: 25667)
Wed Dec 18 11:56:09 2019 -> *Retrieving https://database.clamav.net/daily.cvd
Wed Dec 18 11:56:09 2019 -> *downloadFile: Download source:  
https://database.clamav.net/daily.cvd
Wed Dec 18 11:56:09 2019 -> *downloadFile: Download destination: 
/var/lib/clamav/tmp/clamav-88ed61b7591f35acdee87b5b900326e2.tmp
*   Trying 2606:4700::6810:db54:443...
* TCP_NODELAY set
* Connected to database.clamav.net (2606:4700::6810:db54) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; 
CN=ssl392509.cloudflaressl.com
*  start date: Aug 24 00:00:00 2019 GMT
*  expire date: Mar  1 23:59:59 2020 GMT
*  subjectAltName: host "database.clamav.net" matched cert's "*.clamav.net"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; 
CN=COMODO ECC Domain Validation Secure Server CA 2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561ac8280980)
> GET /daily.cvd HTTP/2
Host: database.clamav.net
user-agent: ClamAV/0.102.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
accept: */*
connection: close

* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200 
< date: Wed, 18 Dec 2019 10:56:10 GMT
< content-type: application/octet-stream
< content-length: 55374037
< set-cookie: __cfduid=da44da730a0bfc7a34a8990f54f1610a4157570; 
expires=Fri, 17-Jan-20 10:56:10 GMT; path=/; domain=.clamav.net; HttpOnly; 
SameSite=Lax
< last-modified: Tue, 17 Dec 2019 09:54:00 GMT
< etag: "5df8a5b8-34cf0d5"
< expires: Wed, 18 Dec 2019 14:56:10 GMT
< cache-control: public, max-age=14400
< cf-cache-status: HIT
< age: 10753
< accept-ranges: bytes
< strict-transport-security: max-age=15552000
< x-content-type-options: nosniff
< expect-ct: max-age=604800, 
report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct;
< server: cloudflare
< cf-ray: 54709bcece3a40ce-HAM
< 
Time: 2.4s, ETA; 0.0s [===>] 
52.81MiB/52.81MiB   
* Connection #0 to host database.clamav.net left intact
Wed Dec 18 11:56:13 2019 -> ^Mirror https://database.clamav.net is not 
synchronized.
Wed Dec 18 11:56:13 2019 -> !Unexpected error when attempting to update 
database: daily
Wed Dec 18 11:56:13 2019 -> ^fc_update_databases: fc_update_database failed: 
Up-to-date (1)
Wed Dec 18 11:56:13 2019 -> !Database update process failed: Up-to-date (1)
Wed Dec 18 11:56:13 2019 -> !Update failed.

> > Using a smaller database instead of downloading the whole thing for
> > each test run makes sense.

We implemented that now, the pg_snakeoil 1.3 testsuite will now look
for the "The Quick Brown Fox" virus:

https://github.com/credativ/pg_snakeoil/tree/master/testfiles

Thanks for the tip!

Christoph



Bug#946938: postgresql-common: pg_upgradecluster woes: fails to upgrade to v12 because ee key too small; postgres also fails to restart after upgrade

2019-12-18 Thread Christoph Berg
Control: reassign -1 ssl-cert
Control: affects -1 postgresql-common

Re: Julian Gilbey 2019-12-18 
<157666085037.520017.6645946659722479335.report...@erdos.d-and-j.net>
> I've just tried upgrading postgresql from version 11 to version 12,
> following the instructions in README.Debian.

Hi,

did you upgrade the OS at the same time?

> 2019-12-18 08:55:15.323 GMT [520011] FATAL:  could not load server 
> certificate file "/etc/ssl/certs/ssl-cert-snakeoil.pem": ee key too small

This isn't a PostgreSQL problem, the snakeoil certificate will be
rejected by any other daemon as well.

The ssl-cert package should regenerate the keys if the openssl package
upgrades the key requirements.

Christoph



Bug#938510: soapysdr: Python2 removal in sid/bullseye

2019-12-17 Thread Christoph Berg
Hi Andreas,

I pushed some changes to git. Could you review these?

Christoph



  1   2   3   4   5   6   7   8   9   10   >