Bug#956516: ImportError: cannot import name '_coin' from 'pivy'
It is worth noting that this error prevents accessing the "Arch"
workbench at all.
On 22/04/2020 20:11, Steve Frécinaux wrote:
It looks like this works around the problem somehow:
ln -sf
/usr/lib/python3/dist-packages/pivy/_coin.{cpython-38-x86_64-linux-gnu.,}so
Bug#953574: Some more relevant links and a ping
Hi all! Some more relevant links: * https://github.com/shlomif/PySolFC/issues/155 - pysol fc ticket * https://salsa.debian.org/jnumm-guest/python-pysol-cards - Debian Package Repo on Debian Salsa * https://pypi.org/project/pysol-cards/ - pypi package And finally a ping / keepalive for volunteers to handle this request already. -- Shlomi Fish https://www.shlomifish.org/ Buddha has the Chuck Norris nature. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Bug#952660: src:linux: macvlan multicast/broadcast regression in stretch
This seems to also affect keepalived `use_vmac` configurations, where the keepalived VIPs are configured on macvlan interfaces. After a stretch kernel update from 4.9.0-11-amd64 (4.9.189) to 4.9.0-12-amd64 (4.9.209) the keepalived VIPs stop responding to ARP queries, causing the VIP to remain configured but unreachable on the VRRP master.
Bug#91815: Patch to add memusage and memusagestat
Hi Aurelien and Stephen, On Wed, Apr 22, 2020 at 12:04:32AM +0200, Aurelien Jarno wrote: > > The attached patch adds memusage and memusagestat to the libc-bin package. > > This does mean that the latter becomes dependent on libgd3, so it might be > > better to add a new memusage package; I can take care of that if the > > maintainers think it’s better. > > I am not sure we want to add a new dependency for libc-bin, I am sure > people running embedded systems won't appreciate. Any reason for not > shipping it in libc-dev-bin instead? For me that looks more like a tool > to be used for "development". At least the memusagestat is similar to > the mtrace one that is in libc-dev-bin. > > We also have to make sure that this new build-dependency doesn't break > bootstrapping. I have added Helmut in Cc so that he can have a look. Thank you for notifying me. Indeed, the patch doesn't work for bootstrapping as is. A stage2 build of glibc would start requiring libgd-dev -> libgd3 -> libc6, but the stage1 libc6 will not be sufficient to build src:libgd2. It must be possible to build stage2 without that dependency. (Note that this is going to become more confusing as there is ongoing work on removing stage1 and maybe renaming stage2, but let's stick to the current names for now.) >From a bootstrapping pov, the libgd-dev dependency is similar to the libselinux-dev dependency, but I notice just now that it is not correctly annotated with in Build-Depends! >From a build profile pov, it is very undesirable to have package contents change with profiles. Doing so makes it impossible to validate them using reproducible builds. However, since we need libc6-dev from stage2 and it depends on libc-dev-bin we cannot skip generating libc-dev-bin in stage2. I wonder whether it would make sense to add another binary package for development tools that are not normally needed for building software. Then we could skip generating that package. mtrace would be a good candidate to join that package indeed. Failing that, we'll have to cope with changing package contents for stage2 and disable the new dependency for stage2 (or some other profile). Helmut
Bug#958479: qmake passes unsupported -isystem to gcc
Package: qt5-qmake
Version: 5.12.5+dfsg-10
Severity: important
Tags: ftbfs patch upstream
Control: affects -1 + src:deepin-music
Control: block 798955 by -1
The context of this bug is #798955 aka moving glibc headers from
/usr/include to /usr/include/. When doing this, some packages
FTBFS with the symptom that or fail to find
#include_next or #include_next respectively. The
cause is passing -isystem /usr/include/ to the compiler. I
asked libstdc++ upstream to fix this, but the reply was that passing
this flag is unsupported (see bug log of #798955). The takeaway is:
Pass -isystem /usr/include or -isystem /usr/include/ is broken.
Unfortunately, qmake does exactly that. It collects include directories
(e.g. from pkg-config file). For instance libavutil.pc contains
includedir=/usr/include/. The collected directories reside in a
variable INCLUDEPATH. It then passes -isystem for every path that
resides below a set of compiler include directories and -I for
everything else. Since /usr/include/ resides below
/usr/include, qmake turns the flag into -isystem. Doing so changes the
order of -isystem directories and breaks gcc. I think this is a bug in
qmake. The resuling flags are assigned to a variable INCPATH. The
relevant source can be found at:
https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-10/qmake/generators/unix/unixmake2.cpp/#L196
An example of an affected package is deepin-music. I think around 10 (an
upper bound seems to be 30, but that includes other causes). You can
quickly check whether a package is affected by grepping a build log for
"-isystem /usr/include/".
I can also propose a solution. When constructing INCPATH, any directory
that directly is a compiler search directory (not a subdirectory
thereof), the directory should be skipped. Doing so ensures that the
order of compiler search directories is not changed. The possible harm
seems quite limited given that the compiler will already search these
directories (just in the correct order).
What do you think?
Please expect that this bug becomes a regular ftbfs bug eventually.
Helmut
--- qtbase-opensource-src-5.12.5+dfsg.orig/qmake/generators/makefiledeps.cpp
+++ qtbase-opensource-src-5.12.5+dfsg/qmake/generators/makefiledeps.cpp
@@ -359,6 +359,11 @@
return false;
}
+bool QMakeSourceFileInfo::isCompilerInclude(const QString &name)
+{
+return systemIncludes.contains(name);
+}
+
char *QMakeSourceFileInfo::getBuffer(int s) {
if(!spare_buffer || spare_buffer_size < s)
spare_buffer = (char *)realloc(spare_buffer, spare_buffer_size=s);
--- qtbase-opensource-src-5.12.5+dfsg.orig/qmake/generators/makefiledeps.h
+++ qtbase-opensource-src-5.12.5+dfsg/qmake/generators/makefiledeps.h
@@ -106,6 +106,7 @@
void addSourceFile(const QString &, uchar seek, SourceFileType type=TYPE_C);
bool containsSourceFile(const QString &, SourceFileType type=TYPE_C);
bool isSystemInclude(const QString &);
+bool isCompilerInclude(const QString &);
int included(const QString &file);
QStringList dependencies(const QString &file);
--- qtbase-opensource-src-5.12.5+dfsg.orig/qmake/generators/unix/unixmake2.cpp
+++ qtbase-opensource-src-5.12.5+dfsg/qmake/generators/unix/unixmake2.cpp
@@ -202,11 +202,12 @@
if (inc.isEmpty())
continue;
-if (!isystem.isEmpty() && isSystemInclude(inc.toQString()))
-t << ' ' << isystem << ' ';
+ if (isCompilerInclude(inc.toQString()))
+ ;
+ else if (!isystem.isEmpty() && isSystemInclude(inc.toQString()))
+t << ' ' << isystem << ' ' << escapeFilePath(inc);
else
-t << " -I";
-t << escapeFilePath(inc);
+t << " -I" << escapeFilePath(inc);
}
}
if(!project->isEmpty("QMAKE_FRAMEWORKPATH_FLAGS"))
Bug#958417: new upstream version available
On 2020-04-21 15:09:02, Antoine Beaupre wrote: > 1. contrib.go.opencensus.io/exporter/jaeger I have updated to rc35, but i patched out that dependency, as it's not present in Debian and doesn't seem like a hard requirement. a. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Einstein
Bug#940215: Acknowledgement and Gratitude
Hi Bouyan Yang, Thanks a lot for taking care of this. I also appreciate the fact that you prepared a PR. It's merged now I'm happy with all the changes. Thank you for the upload. I don't know if it's possible but feel free to upload straight away if you want. Regards, -- Rock Storm GPG KeyID: 4096R/C96832FD GPG Fingerprint: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD
Bug#934663: socket activated sshd sometimes complains about /run/sshd not being there
On Tue, 13 Aug 2019 07:37:29 +0200 Marc Haber
wrote:
> Package: openssh-server
> Version: 1:7.9p1-10
> Severity: minor
>
> Hi,
>
> I am running sshd with systemd socket activation, which is a
> non-standard configuration, hence severity: minor.
>
> Since the buster upgrade, on a host that is hit by ssh brute force
> attacks hundreds of times a day, I get "fatal: chroot("/run/sshd"): No
> such file or directory [preauth]" log entries about three times a day.
>
> When I look, /run/sshd is there. It is also confusing that the message
> does happen so seldomly, only in a very small fraction of cases. So it
> must be an exotic race condition.
>
> sshd doesn't delete and recreate the privsep directory after a chrooted
> daemon exits, does it?
I have also run into this problem.
The reason is rather simple: systemd creates the RuntimeDirectory when
the service starts, and deletes when it stops. Since it's an instanced unit
activated by socket connection, multiple units access the same directory
concurrently in a racy way.
Instance A may delete the directory after instance B is started, but before
it has chrooted into it, which causes the instance B to fail. The time window
is small, so it happens rarely.
Given that, RuntimeDirectoryPreserve=yes seems like the proper fix.
/run/sshd problems with socket activation were previously addressed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872978, but it was an
incomplete fix.
Bug#958481: ITP: python3-yoyo-migrations -- database schema migration tool
Package: wnpp Severity: wishlist Owner: Henry-Nicolas Tourneur * Package name: python3-yoyo-migrations Version : 7.0.2 Upstream Author : Oliver Cope * URL : https://pypi.org/project/yoyo-migrations/ * License : Apache software license Programming Lang: Python Description : database schema migration tool Yoyo is a database schema migration tool. You write database migrations as Python scripts containing raw SQL statements or Python functions. Extra information on this packaging: - I wish to maintain this package together with DPMT - This library is a dependency for the authenticator gnome app which I would like to package as well once dependencies are resolved.
Bug#958480: RFS: python-pyperclip/1.8.0-1 [QA] -- Cross-platform clipboard module for Python3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-pyperclip" * Package name: python-pyperclip Version : 1.8.0-1 Upstream Author : Al Sweigart * URL : https://github.com/asweigart/pyperclip * License : BSD-3-clause * Vcs : https://salsa.debian.org/debian/python-pyperclip Section : python It builds those binary packages: python3-pyperclip - Cross-platform clipboard module for Python3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-pyperclip Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-pyperclip/python-pyperclip_1.8.0-1.dsc Changes since the last upload: * QA upload. [ Debian Janitor ] * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse. . [ Håvard Flaget Aasen ] * New upstream version 1.8.0 * Update Standards-Version to 4.5.0 * Add Upstream-Contact in d/copyright Regards, Håvard
Bug#958484: gxkb FTCBFS: hard codes the build architecture pkg-config
Source: gxkb
Version: 0.8.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
gxkb fails to cross build from source, because configure.ac hard codes
the build architecture pkg-config in one occasion. Please consider
applying the attached patch to make it use the correctly detected
pkg-config.
Helmut
--- gxkb-0.8.0.orig/configure.ac
+++ gxkb-0.8.0/configure.ac
@@ -19,7 +19,7 @@
AC_SUBST(LIBXKLAVIER_LIBS)
AC_SUBST(LIBWNCK_CFLAGS)
AC_SUBST(LIBWNCK_LIBS)
-LIBXKLAVIER_VERSION=`pkg-config --modversion libxklavier | sed 's/\.//;s/\..*//g'`
+LIBXKLAVIER_VERSION=`$PKG_CONFIG --modversion libxklavier | sed 's/\.//;s/\..*//g'`
AC_DEFINE_UNQUOTED(LIBXKLAVIER_VERSION, ${LIBXKLAVIER_VERSION}, [libxklavier version])
APPINDICATOR_REQUIRED_VERSION=0.2.4
Bug#958486: ITP: python3-text-unidecode -- text-unidecode is the most basic port of the Text::Unidecode Perl library.
Package: wnpp Severity: wishlist Owner: Henry-Nicolas Tourneur * Package name: python3-text-unidecode Version : 1.3 Upstream Author : Mikhail Korobov * URL : https://pypi.org/project/text-unidecode/ * License : Artistic License Programming Lang: Python Description : text-unidecode is the most basic port of the Text::Unidecode Perl library. Extra information on this packaging: - I wish to maintain this package together with DPMT - This library is a dependency for the authenticator gnome app which I would like to package as well once dependencies are resolved.
Bug#958483: xrdesktop Settings application not packaged
Source: xrdesktop Version: 0.14.0-2 Severity: normal A new package for the settings application -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (980, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (120, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.7.0-rc1 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#958485: opensmtpd-extras FTCBFS: uses the build architecture pkg-config
Source: opensmtpd-extras
Version: 6.6.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
opensmtpd-extras fails to cross build from source, because configure.ac
hard codes the build architecture pkg-config. Please consider using the
upstream macro PKG_PROG_PKG_CONFIG to discover the pkg-config location.
I'm attaching a patch for your convenience.
Helmut
--- opensmtpd-extras-6.6.0.orig/configure.ac
+++ opensmtpd-extras-6.6.0/configure.ac
@@ -1357,6 +1357,8 @@
]
)
+PKG_PROG_PKG_CONFIG
+
#
# check for python
#
@@ -1425,12 +1427,9 @@
LUA_LDFLAGS=
if test x"${need_lua}" = x"yes"; then
LUA_CONFIG=
- for path in /usr/local/bin /usr/bin; do
- if test -f ${path}/pkg-config; then
- LUA_CONFIG=${path}/pkg-config
- break
- fi
- done
+ if test "x$PKG_CONFIG" != x; then
+ LUA_CONFIG=$PKG_CONFIG
+ fi
# if lua provided --with-lua, override
if test x"${with_lua}" != x""; then
@@ -1471,12 +1470,9 @@
REDIS_LDFLAGS=
if test x"${need_redis}" = x"yes"; then
REDIS_CONFIG=
- for path in /usr/local/bin /usr/bin; do
- if test -f ${path}/pkg-config; then
- REDIS_CONFIG=${path}/pkg-config
- break
- fi
- done
+ if test "x$PKG_CONFIG" != x; then
+ REDIS_CONFIG=$PKG_CONFIG
+ fi
# if redis provided --with-redis, override
if test x"${with_hiredis}" != x""; then
Bug#958482: RFS: pygresql/1:5.1.2-1 [QA] -- PostgreSQL module for Python3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pygresql" * Package name: pygresql Version : 1:5.1.2-1 Upstream Author : PyGreSQL team * URL : https://www.pygresql.org/index.html * License : PostgreSQL * Vcs : https://salsa.debian.org/debian/pygresql Section : python It builds those binary packages: python3-pygresql - PostgreSQL module for Python3 python-pygresql-doc - Python Pygresql (common documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pygresql Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pygresql/pygresql_5.1.2-1.dsc Changes since the last upload: * QA upload. * New upstream version 5.1.2 Regards, Håvard
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
Hi Thomas, Reply follows in-line: Thomas Koch writes: > Hi Nicholas, > > I just uploaded persist-el. Thank you and sorry for the delay. This > was my first sponsorship and I also had to setup a new laptop. I'm > just waiting for the confirmation mail for the upload. > Thank you for sponsoring! Best of luck with the toil of getting the new laptop setup (eg: MUA line wrapping, and weird trailing white-space in lintian output). Did you upload twice btw? [22-04 edit: Oh! Sébastien, thank you!] > There are a few nitpicks and I'd be grateful if you could track them, > e.g. in bugs.d.o after the package enters the archive: > > - It's a pity that we can not include the info file due to the > license. Could you ask upstream to consider another license? Sure thing, I've added it to my TODO. BTW, because it's a GNU ELPA project I'm pessimistic they'll relicense the docs... > - As long as the doc is not included, I think you don't need to build > depend on texinfo. Agreed, I'll either drop it for the -2 upload, or if upstream relicenses their texinfo source then I'll build the info file. > - If upstream also uses Git, I prefer to track upstreams master branch > as upstream branch in the packaging repo. You could still merge their > branch in your existing repo or restart the repo? I also prefer to track upstream's master branch; however, persist.el is part of the GNU ELPA mondo-repo, which contains many other packages, and our team uses one repo per source package. > - Lintian also had two nitpicks, see below. I'm guilty of the "wrong" > section myself for elpa-editorconfig. What is the teams stand on this? > I've discussed similar issues with the team before, and the consensus is that it's not worth the trouble of a section change. Having filed a couple of section change requests in the past, an ftpmaster sometimes moved them to weird/generic sections...eg: I requested a move for Elpy (Python IDE) to Development from either Lisp or Editors, and they moved it to Text... Dh-make-elpa also used to use section "lisp" but now uses section "editors", and this is also a case where where "editors" seems to be team-endorsed (via dh-make-elpa), and I think the team consensus is that lintian's claim is wrong. IIRC the "info" severity is a compromise between our team and whoever believes all packages that are implemented in lisp should be in section lisp... When it was a warning I filed a bunch of section change requests (editors-to->lisp) that ftpmasters didn't seem to appreciate. That said, upon further consideration I agree that "lisp" might have been the most appropriate section, because persist.el has no interactive functions and is thus more of a library than an editor. If there's a way to attach a note to the ftpmaster review, then let's do that! I'm of course happy to happy to correct the package's classification in control so that it matches the archive. > I: persist-el source: public-upstream-key-not-minimal > upstream/signing-key.asc has 1 extra signature(s) for keyid 066DAFCB81E42C40 > > N: > > > N:The package contains a public upstream signing key with extra > > > N:signatures. The signatures are unnecessary and take up space in the > > > N:archive. > > > N: > > > N:Please export the upstream key again with the command: > > > N: > > > N: $ gpg --armor --export --export-options export-minimal,export-clean > > > N: > > > N:and use that key instead of the key currently in the source package. > > > N:
Bug#958307: ejabberd: Fails to make a backup
Hi Am 20.04.20 um 14:06 schrieb Santiago Castillo Oli: > The documentation (/usr/share/doc/ejabberd/README.Debian.gz says that > backups are stored in /var/backups when ejabberd is upgraded or > restored. I didn't check if this is working or is it also affected by > this problem. > > > There is not (or at least I didn't find) a proper place to store backups. > > I think it should be documented where to store backups, or have and > specific directory for backups that works. executing /var/lib/dpkg/info/ejabberd.prerm upgrade works like a charm. The trick is to create a writable directory for ejabberd inside /var/backups. Indeed, the documentation could be improved. Regards -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#918727: [Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0
On 2020-04-21 21:39:43 [+0200], Kurt Roeckx wrote: > On Tue, Apr 21, 2020 at 09:18:05PM +0200, Sebastian Andrzej Siewior wrote: > > On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote: > > > On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote: > > > > > > > > I think setting defaults in the shared library itself would be more > > > > robust, and if a configuration file to override that is necessary, > > > > > > This is also the route that Ubuntu took, because it's possible to > > > install the library without the openssl package. I think we should > > > do this too. > > > > > > It causes various issues with the test suite because SHA1 is used > > > for various tests. But I think that has been fixed in master, or has a > > > pull request. > > > > > > I would like to drop SHA1 support in testing/unstable anyway, so I > > > think we should merge those patches once they've all been merged. > > > > Ehm. I read this a few times but I have no idea what we are going to do. > > Could you please enlighten me? > > It's about building with -DOPENSSL_TLS_SECURITY_LEVEL=2, and > something like the patch I've used before to set the default TLS > version, instead of having both in openssl.cfg. Setting it in the > config file should override the build time defaults. So if this replaces the entry openssl.cnf file then it would get rid of that incompatible part. However if someone downgrades it for some reason (by editing the file) then we are back to the incompatibility part where things break if the syntax changes. > Building with that set will cause testsuite errors. Some of those > are because SHA1 is being used. Yes. I suggested once to ship that .cnf file as part of libssl but you didn't like the idea, dunno why. But I know that you said that openssl is almost always installed due to ca-cert and so on so… > In the master branch, things are changing so that SHA1 isn't > allowed at security level 1 anymore. For the next release, if > we're not shipping 3.0, I would like to at least change that. No SHA1 at level1? Lovely. You remember this one CDN that signed the key-exchange with SHA1 despite the fact that the client did not offer it? I just checked it, it is still doing it. And ssllabs.com does not report this "bug" as such. I hope the web browsers have SHA1 also on their agande because otherwise… > Kurt Sebastian
Bug#955323: RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs
Hi Antoine! It seems I forgot to push my work on this package from early 2020 :-/ Probably fell asleep...I'm truly sorry for wasting your time in the initial review. Reply follows inline; feel free to skip the rest of this email if you're busy. The package should meet your standards @a69fbc3. OT, I wish the sponsorship template would insert commit:@foo...that would have prevented this, and I think the pkg on mentors was @a69fbc3... Antoine Beaupré writes: > i am not sure, but i suspect it is a mismatch between the > debian/changelog and debian/control package names. indeed, with the > following patch: > [snip] > -atomic-chrome (2.0.0-1) unstable; urgency=medium > +atomic-chrome-el (2.0.0-1) unstable; urgency=medium [snip] > ... the package compiles. > Indeed. Fixed 1 Jan 2020 (many apologies, I forgot to push). > The other issue I found is what now seems to be a recurring disagreement > between us. :) This is the tarball that `uscan` gives me when I run the > above command: > [snip] > There are a few things wrong here: > > 1. we should not needlessly differ from the upstream tarball > Yeah... I did special-case your preference 29 March 2020 (forgot to push). [1a] That said, in addition to what we discussed before, I'm finding that more and more projects release less-than useful tarballs eg: missing tox.ini or other things for self-tests. Fundamentally, the only reason I use a tarball check in the watch file is to reduce the load on the system that runs uscan (daily?). I would move everything over to pure git (with a quilt patch series, if necessary) in a heartbeat if using git in the watch file wouldn't make people grumble. > 2. if we really have to, `uscan` should allow us to reconstruct our > tarball reproducibly, or at least `README.source` should explain > how. at minimum, `README.source` should explain *why* we differ > [2a] I'm still not convinced of the value of this when it's fetchable with 'apt source', 'dgit clone', or 'dget'. That copy is gpg signed via the changes and/or dsc, and benefits from our (Debian) identity verification. Re: README.source, I don't know about this one...Lamby convinced me not to use README.source for this purpose some time ago. I used to always document when I was using a git tag rather than upstream release tarball :-) > 3. even if we insist on using `xz` (and I don't see why we do in this > case), we don't need the maximum compression level. this is a small > package and there's not reason to "crank it up to 11", so to speak :) > [3a] :-) I agree with you that it doesn't have much practical value for a package of this size, but there is a reason: establishing policy. I think it was spwhitton who impressed on me the value that the accumulation of packaging decisions affects trends, consensus, and ultimately Policy. The practical value is that if maintainers are willing to "crank it up to 11" even for little packages, then it's fair to expect the same from maintainers of packages where the diff is large. I'd give up on this with proof that weaker compression resulted in less net electricity consumption (including ongoing storage and transmission) than what is required for compression and decompression of xz. If you know, please share! > The following patch should fix the problem: > > From a9dc9a10a4c1ea9024a70335232dd837d36738d1 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= > Date: Fri, 17 Apr 2020 21:01:14 -0400 > Subject: [PATCH] remove superfluous diff with upstream tarball > Thank you for the patches, I sincerely appreciate that you took time to write them. Once again, sorry for not realising I hadn't pushed... > I feel uncomfortable sponsoring a package if it doesn't use the upstream > tarballs. I hope you'll understand. > Definitely! I've been mentoring some new Emacsen Team members, and wrote up a short hierarchy of priorities. The standards of one's sponsor are #1, unless they contradict Policy. Anyways, it has both conceptual and practical dimensions. Here's a practical one you'll appreciate: tldr (pithy synopsis), don't drain your sponsor with unnecessary arguments or they'll be too drained to review and sponsor your work ;-) If you're interested in reading it and/or if you think such a thing would make a good addition to an existing doc, please let me know! Cheers, Nicholas signature.asc Description: PGP signature
Bug#958487: inkscape: Inkscape v1.0 requires libcairo v1.17
Package: inkscape Version: 0.92.5-1 Severity: normal One of the new features in Inkscape v1.0 is the ability to export PNG images with 16-bit colour depth: https://wiki.inkscape.org/wiki/index.php?title=Release_notes/1.0#Export_PNG_images However, this depends on the corresponding feature in the Cairo graphics library, which only became available in version 1.17.2, released over a year ago: https://cairographics.org/news/cairo-1.17.2/ But this version is not yet available in the Debian archive, even in experimental: # apt-show-versions -a libcairo2 libcairo2:amd64 1.16.0-4 install ok installed libcairo2:amd64 1.16.0-4 stable ftp.us.debian.org No stable-updates version libcairo2:amd64 1.16.0-4 testing ftp.us.debian.org libcairo2:amd64 1.16.0-4 unstable ftp.us.debian.org No experimental version libcairo2:amd64/testing 1.16.0-4 uptodate Cairo v1.17.2 in turn depends on libpixman v0.36, which is available in the Debian archive. However, it is also over a year out-of-date; the current version is v0.40: https://www.cairographics.org/releases/ Please upgrade the Debian version of libcairo, and possibly also libpixman, to the current release, so that the new 16-bit colour depth functionality in Inkscape can be supported. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii libatkmm-1.6-1v5 2.28.0-2 ii libc62.30-4 ii libcairo21.16.0-4 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.6-1 ii libdbus-glib-1-2 0.110-5 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libgc1c2 1:7.6.4-0.4 ii libgcc-s110-20200411-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libglib2.0-0 2.64.1-1 ii libglibmm-2.4-1v52.64.2-1 ii libgomp1 10-20200411-1 ii libgsl23 2.5+dfsg-6+b1 ii libgtk2.0-0 2.24.32-4 ii libgtkmm-2.4-1v5 1:2.24.5-4 ii libgtkspell0 2.0.16-1.3 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-4+b1 ii libmagick++-6.q16-8 8:6.9.10.23+dfsg-2.1+b2 ii libpango-1.0-0 1.44.7-3 ii libpangocairo-1.0-0 1.44.7-3 ii libpangoft2-1.0-01.44.7-3 ii libpangomm-1.4-1v5 2.42.1-1 ii libpng16-16 1.6.37-2 ii libpoppler-glib8 0.71.0-6 ii libpoppler82 0.71.0-6 ii libpopt0 1.16-14 ii libpotrace0 1.16-2 ii librevenge-0.0-0 0.0.4-6+b1 ii libsigc++-2.0-0v52.10.2-1 ii libstdc++6 10-20200411-1 ii libvisio-0.1-1 0.1.7-1 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.6.9-2 ii libxml2 2.9.10+dfsg-4 ii libxslt1.1 1.1.34-4 ii python2 2.7.17-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages inkscape recommends: ii aspell 0.60.8-1 ii fig2dev 1:3.2.7b-3 ii imagemagick 8:6.9.10.23+dfsg-2.1+b2 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2 ii libimage-magick-perl 8:6.9.10.23+dfsg-2.1 ii libwmf-bin 0.2.8.4-17 ii python-lxml 4.5.0-1+b1 ii python-numpy 1:1.16.5-5 ii python-scour 0.37-2 Versions of packages inkscape suggests: ii dia 0.97.3+git20160930-9 pn inkscape-tutorials pn libsvg-perl pn libxml-xql-perl ii pstoedit 3.75-1 pn python-uniconvertor ii ruby 1:2.7+1
Bug#958487: inkscape: Inkscape v1.0 requires libcairo v1.17
Control: reassign -1 src:cairo 1.16.0-4 Control: severity -1 wishlist Control: retitle -1 cairo: Please update to the new upstream version 1.17 On Wed, Apr 22, 2020 at 12:59:34PM -0700, Ian Bruce wrote: > One of the new features in Inkscape v1.0 is the ability to export PNG > images with 16-bit colour depth: > > https://wiki.inkscape.org/wiki/index.php?title=Release_notes/1.0#Export_PNG_images > > However, this depends on the corresponding feature in the Cairo graphics > library, which only became available in version 1.17.2, released over a > year ago: > > https://cairographics.org/news/cairo-1.17.2/ > > But this version is not yet available in the Debian archive, even in > experimental: Then this is a request for the cairo maintainers, reassigning. > Cairo v1.17.2 in turn depends on libpixman v0.36, which is available in > the Debian archive. However, it is also over a year out-of-date; the > current version is v0.40: > > https://www.cairographics.org/releases/ That would be https://bugs.debian.org/958298 Thanks for the report. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#958173: buster-pu: package lxc-templates/3.0.3-1
Control: tags -1 -moreinfo +confirmed On Tue, 2020-04-21 at 22:01 +0200, Pierre-Elliott Bécue wrote: > Le mardi 21 avril 2020 à 21:21:28+0200, Andreas Beckmann a écrit : > > > Stripping all useless commits, here is the Debdiff I get. > > > > > > Note that the version isn't 3.0.4-3~deb10u1 as 3.0.4-3 contains > > > only > > > packaging changes that I didn't include. > > > > > > Should you wish me to release 3.0.4-3~deb10u1, we would have to > > > make an > > > empty changelog for 3.0.4-3 over which I could do the changelog > > > entry to > > > release into buster. > > > > A version generally used in this case would be 3.0.4-0+deb10u1 with > > the > > changelog entries squashed together. It's no longer a plain > > "rebuild", > > but a new upstream release + selected cherry-picked bugfixes > > without > > inappropriate packaging changes. > > (mariadb and postgresql are prominent users of this scheme.) > > Thanks, here is a debdiff that should fit then. Thanks, please feel free to upload that. Regards, Adam
Bug#947464: buster-pu: gnome-maps/3.30.3.1-1+deb10u1
Control: tags -1 + moreinfo On Fri, 2019-12-27 at 11:19 +, Phil Wyett wrote: > On Fri, 2019-12-27 at 11:12 +, Phil Wyett wrote: > > Attached is a pu debdiff that updates gnome-maps from 3.30.3 to > > 3.30.3.1 > > in buster. This is a minor stable point release. > > > > Entry in upstream: NEWS > > > > 3.30.3.1 - May 21, 2019 > > = > > > > Changes since 3.30.3 > > - Make the shape layer renderer use the tile size specified in the > > dynamic > >service file, fixing an issue with misaligned shape layer > > (GeoJSON, > > GPX, KML) > >rendering with the new 512 pixel tiles Sorry for the delay in getting back to you. +gnome-maps (3.30.3.1-1+deb10u1) buster; urgency=medium That version number would be the first stable update to 3.30.3.1-1. As this is a new upstream version, 3.30.3.1-0+deb10u1 is a commonly used pattern. + * Non-maintainer upload I'm not sure if you are, but as a note, if you're involved with the general maintenance of the package (but not "the maintainer") then this could also potentially be a team upload. + * New upstream release It would be helpful to provide a brief explanation here of what changes the release includes, for the benefit of users installing the update. Regards, Adam
Bug#958488: memtest86+: freezes in non-SMP mode at 15%
Package: memtest86+ Version: 5.01-3.1 Severity: important Hi. On a system with 32GB RAM, memtest86+ freezes every time at 15% of the first test. The system is a Fujitsu Lifebook U757, having the newest BIOS, running with BIOS compatibility mode enabled. Recently, my notebook hanged up itself (the frist time in months), so I decide to run some memtest. Yet I'd still suspect the memory is in fact good (it runs just normally now, no data corruptions, no strangely dying processes or similar). And memtest86+ doesn't find an error it just freezes. Unlike the many known bugs of memtest86+ this is not in SMP mode. In fact, it might perhaps even be the new BIOS, which also installed new CPU microcode. Perhaps there is some further memory protection now, which memtest86+ chokes upon? Any ideas? Cheers, Chris.
Bug#958491: acpica-unix: FTBFS on s390x
Source: acpica-unix Version: 20200326-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) acpica-unix failed to build on s390x: https://buildd.debian.org/status/fetch.php?pkg=acpica-unix&arch=s390x&ver=20200326-1&stamp=1585774833&raw=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#958489: buster-pu: package fuse/2.9.9-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi SRMs, There are two RC bugs fixed in fuse for Bullseye but not yet for Buster. First one[1] and its variant[2] are caused by a leftover in postinst - udev has rules now to handle such things in its 50-udev-default.rules and 99-systemd.rules files. Then it shouldn't explicitly remove fuse.conf [3] as it should be done by dpkg and fuse3 might still need it. Proposed update is attached. Thanks for consideration, Laszlo/GCS [1] https://bugs.debian.org/934457 [2] https://bugs.debian.org/935496 [3] https://bugs.debian.org/953222 diff -Nru fuse-2.9.9/debian/changelog fuse-2.9.9/debian/changelog --- fuse-2.9.9/debian/changelog 2019-01-07 20:32:01.0 + +++ fuse-2.9.9/debian/changelog 2020-04-22 19:38:47.0 + @@ -1,3 +1,10 @@ +fuse (2.9.9-1+deb10u1) buster; urgency=medium + + * Drop outdated udevadm commands from postinst (closes: #934457, #935496). + * Don't explicitly remove fuse.conf on purge (closes: #953222). + + -- Laszlo Boszormenyi (GCS) Wed, 22 Apr 2020 19:38:47 + + fuse (2.9.9-1) unstable; urgency=medium * New upstream release. diff -Nru fuse-2.9.9/debian/fuse.postinst fuse-2.9.9/debian/fuse.postinst --- fuse-2.9.9/debian/fuse.postinst 2016-06-23 16:23:28.0 + +++ fuse-2.9.9/debian/fuse.postinst 2020-04-22 19:38:47.0 + @@ -25,17 +25,6 @@ modprobe fuse > /dev/null 2>&1 || true - if [ -x /sbin/lsmod ] && lsmod | grep -qs fuse - then - if udevadm control --reload-rules > /dev/null 2>&1 - then -if [ -e /dev/fuse ] -then - udevadm test --action -p $(udevadm info -q path -n /dev/fuse) > /dev/null 2>&1 -fi - fi - fi - if [ -x /usr/sbin/update-initramfs ] then update-initramfs -u diff -Nru fuse-2.9.9/debian/fuse.postrm fuse-2.9.9/debian/fuse.postrm --- fuse-2.9.9/debian/fuse.postrm 2014-06-20 06:23:50.0 + +++ fuse-2.9.9/debian/fuse.postrm 2020-04-22 19:38:47.0 + @@ -11,7 +11,6 @@ ;; purge) - rm -f /etc/fuse.conf ;; upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
Bug#958490: buster-pu: package fuse3/3.4.1-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi SRMs, There are two RC bugs fixed in fuse3 for Bullseye but not yet for Buster. First one[1] is caused by a leftover in postinst - udev has rules now to handle such things in its 50-udev-default.rules and 99-systemd.rules files. Then it shouldn't explicitly remove fuse.conf [2] as it should be done by dpkg and fuse might still need it. Last but not least there's a small memory leak fix[3] due to free()-ing the stuct pointer of *mo but not its content with destroy_mount_opts(). Proposed update is attached. Thanks for consideration, Laszlo/GCS [1] https://bugs.debian.org/934293 [2] https://bugs.debian.org/953223 [3] https://github.com/libfuse/libfuse/commit/50fe9f7c818628dc5dd69218c851a48fa1f07987 diff -Nru fuse3-3.4.1/debian/changelog fuse3-3.4.1/debian/changelog --- fuse3-3.4.1/debian/changelog 2018-12-25 16:57:44.0 + +++ fuse3-3.4.1/debian/changelog 2020-04-22 19:38:49.0 + @@ -1,3 +1,11 @@ +fuse3 (3.4.1-1+deb10u1) buster; urgency=medium + + * Drop outdated udevadm commands from postinst (closes: #934293). + * Don't explicitly remove fuse.conf on purge (closes: #953223). + * Backport fix of memory leak in fuse_session_new() . + + -- Laszlo Boszormenyi (GCS) Wed, 22 Apr 2020 19:38:49 + + fuse3 (3.4.1-1) unstable; urgency=medium * New upstream release. diff -Nru fuse3-3.4.1/debian/fuse3.postinst fuse3-3.4.1/debian/fuse3.postinst --- fuse3-3.4.1/debian/fuse3.postinst 2018-07-21 14:11:44.0 + +++ fuse3-3.4.1/debian/fuse3.postinst 2020-04-22 19:38:49.0 + @@ -25,17 +25,6 @@ modprobe fuse > /dev/null 2>&1 || true - if [ -x /sbin/lsmod ] && lsmod | grep -qs fuse - then - if udevadm control --reload-rules > /dev/null 2>&1 - then -if [ -e /dev/fuse ] -then - udevadm test --action -p $(udevadm info -q path -n /dev/fuse) > /dev/null 2>&1 -fi - fi - fi - if [ -x /usr/sbin/update-initramfs ] then update-initramfs -u diff -Nru fuse3-3.4.1/debian/fuse3.postrm fuse3-3.4.1/debian/fuse3.postrm --- fuse3-3.4.1/debian/fuse3.postrm 2014-06-20 06:23:50.0 + +++ fuse3-3.4.1/debian/fuse3.postrm 2020-04-22 19:38:49.0 + @@ -11,7 +11,6 @@ ;; purge) - rm -f /etc/fuse.conf ;; upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) diff -Nru fuse3-3.4.1/debian/patches/0009-Fixed-memory-leak-in-fuse_session_new.patch fuse3-3.4.1/debian/patches/0009-Fixed-memory-leak-in-fuse_session_new.patch --- fuse3-3.4.1/debian/patches/0009-Fixed-memory-leak-in-fuse_session_new.patch 1970-01-01 00:00:00.0 + +++ fuse3-3.4.1/debian/patches/0009-Fixed-memory-leak-in-fuse_session_new.patch 2020-04-22 19:38:49.0 + @@ -0,0 +1,23 @@ +From 50fe9f7c818628dc5dd69218c851a48fa1f07987 Mon Sep 17 00:00:00 2001 +From: Bill Zissimopoulos +Date: Thu, 2 Jan 2020 03:08:03 -0800 +Subject: [PATCH] Fixed memory leak in fuse_session_new() + +--- + lib/fuse_lowlevel.c | 3 ++- + 2 files changed, 4 insertions(+), 1 deletion(-) + +diff --git a/lib/fuse_lowlevel.c b/lib/fuse_lowlevel.c +index 36713854..d8112f58 100644 +--- a/lib/fuse_lowlevel.c b/lib/fuse_lowlevel.c +@@ -2893,7 +2893,8 @@ struct fuse_session *fuse_session_new(struct fuse_args *args, + out4: + fuse_opt_free_args(args); + out3: +- free(mo); ++ if (mo != NULL) ++ destroy_mount_opts(mo); + out2: + free(se); + out1: diff -Nru fuse3-3.4.1/debian/patches/series fuse3-3.4.1/debian/patches/series --- fuse3-3.4.1/debian/patches/series 2018-07-21 14:11:44.0 + +++ fuse3-3.4.1/debian/patches/series 2020-04-22 19:38:49.0 + @@ -6,3 +6,4 @@ #0006-arm64.patch #0007-manpage.patch #0008-init-include-lsb.patch +0009-Fixed-memory-leak-in-fuse_session_new.patch
Bug#930735: WireGuard: Add resolvconf as optional dependency
Good day, I would like to pitch in. I've created a symlink: ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf and wg-quick works fine with it. I did not need to install any other package. Br, Tim On Wed, 19 Jun 2019 17:34:28 -0400 Daniel Kahn Gillmor < d...@fifthhorseman.net> wrote: > What about when resolvectl(1) from systemd is symlinked as resolvconf > (see the resolvectl man page for more details) -- would that be > preferable? according to its documentation, it has partial support for > -x, plausible support for -a, and silently ignores -m. is that > sufficient? If that's ok, maybe there are other adjustments we can make > so that it integrates nicely with systemd-resolved. > > More details about what configurations you've tested and how well they > work to do what you expect from wg-quick would help me understand how to > make this system integration work better for you.
Bug#795421: version 5.01 freezes on test #7 in SMP mode
Hey. Anything new on merging this patch? Cheers, Chris.
Bug#939904: systemd should ship resolvconf symlink in some package
Hi, > So for wireguard's purposes, it would be good to figure out how to get > some debian package that ships the symlink in question (i understand why > you can't ship the symlink by default in the systemd package -- it would > conflict with the other implementations of resolvconf). I've stumbled across this after I replied to 930735. Arch linux seems to solve it by a separate package. It blocks openresolv, to prevent the conflict on the symlink. https://www.archlinux.org/packages/core/x86_64/systemd-resolvconf/ Br, Tim On Tue, 10 Sep 2019 16:39:59 -0400 Daniel Kahn Gillmor < d...@fifthhorseman.net> wrote: > On Tue 2019-09-10 08:54:35 +0200, Michael Biebl wrote: > > wouldn't it be better if wireguard calls resolvctl directly? > > Then it knows exactly what kind of behaviour it'll get. > > > > You're right about the resolvconf.1 man page. We should not ship that in > > the systemd man page since we don't ship the resolvconf symlink either > > (for obvious reasons). > > Hm, Jason (wireguard upstream, cc'ed here) seems to believe strongly in > the resolvconf interface. he writes [0]: > > >> The standard interface for modifying DNS on Linux is resolvconf. It is for > >> this reason that systemd added the compatibility layer. Debian should > >> install the proper symlink. WireGuard upstream will support the standard > >> mechanism of resolvconf. > > fwiw, I don't understand the vehemence of his allegiance to this > interface, especially given the amount of trouble its different > implementations have caused him (and others) in the past, but *shrug* > i'd also prefer not to diverge from the version of wg-quick that he's > shipping upstream, unless someone from the systemd team wants to supply > a patch that they think is a reliable fix for the linux bash > implementation [1]. > > Is the resolvectl interface stable as documented? > > So for wireguard's purposes, it would be good to figure out how to get > some debian package that ships the symlink in question (i understand why > you can't ship the symlink by default in the systemd package -- it would > conflict with the other implementations of resolvconf). > > Is there a chance that the systemd source would generate such a package > (one that enables systemd-resolved, and supplies the symlinks to the > binary and the manpage)? > > If not, feel free to close this bug with an explanation of why that's > not acceptable. > > Thanks for your work in maintaining systemd. > > --dkg > > [0] https://lists.zx2c4.com/pipermail/wireguard/2019-September/004521.html > [1] https://salsa.debian.org/debian/wireguard/blob/debian/master/src/tools/wg-quick/linux.bash
Bug#958492: xfonts-terminus: Provide gtk-compatible fonts
Package: xfonts-terminus Version: 4.40-2 Severity: grave Justification: renders package unusable Dear Maintainer, With pango 1.44, bitmap fonts are no longer supported: https://gitlab.gnome.org/GNOME/pango/issues/386 This means that trying to render Terminus in gtk applications looks like... well, this: https://rharwood.fedorapeople.org/screenshots/2020-04-22-162841_1920x1080_scrot.png The Fedora maintainer has adapted the terminus-fonts package to provide .otb files in more recent versions, using the approach described there and in https://bugzilla.redhat.com/show_bug.cgi?id=1753295 Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-trunk-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfonts-terminus depends on: ii xfonts-utils 1:7.7+6 xfonts-terminus recommends no packages. Versions of packages xfonts-terminus suggests: ii xfonts-terminus-oblique 4.40-2 ii xserver-xorg [xserver] 1:7.7+20 -- no debconf information
Bug#958493: sphinxcontrib-bibtex: autopkgtest regression
Source: sphinxcontrib-bibtex Version: 1.0.0-1 Severity: serious The autopkgtest of sphinxcontrib-bibtex fails, preventing its migration to testing. See https://ci.debian.net/data/autopkgtest/testing/amd64/s/sphinxcontrib-bibtex/5114485/log.gz Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#930735: WireGuard: Add resolvconf as optional dependency
On Wed, 22 Apr 2020 23:57:04 +0300 Tim Mohlmann wrote: > Good day, > > I would like to pitch in. I've created a symlink: ln -s /usr/bin/resolvectl > /usr/local/bin/resolvconf and wg-quick works fine with it. I did not need > to install any other package. And systemd-resolved/libnss-resolve is enabled and active? Otherwise it seems you could just as well symlink resolvconf to /bin/true to have the same effect. signature.asc Description: OpenPGP digital signature
Bug#958494: linux-image-5.5.0-2-amd64: Amdgpu / drm: No video signal/blank screen on resume from suspend
Package: src:linux Version: 5.5.17-1 Severity: normal Tags: upstream,fixed-in-experimental Dear Maintainer, This is a tracking bug for kernel bug #206575 (https://bugzilla.kernel.org/show_bug.cgi?id=206575), which is fixed in experimental. The problem occurs when using AMD graphic cards and amdgpu driver, after doing a suspend-to-ram and resuming, the monitor/screen will stay blank or show no signal. This problem is fixed with the kernel in linux-image-5.6.0-trunk-amd64:5.6.4-1~exp1 Regards, Facundo -- Package-specific info: ** Version: Linux version 5.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-10)) #1 SMP Debian 5.5.17-1 (2020-04-15) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.5.0-2-amd64 root=UUID=ac43c144-ff3f-4c08-b24e-b9d76e3d66e2 ro loglevel=8 ** Not tainted ** Kernel log: [4.213896] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [4.215770] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input18 [4.217432] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [4.242801] input: HDA ATI SB Front Mic as /devices/pci:00/:00:14.2/sound/card0/input19 [4.244655] EDAC amd64: F15h detected (node 0). [4.244673] input: HDA ATI SB Rear Mic as /devices/pci:00/:00:14.2/sound/card0/input20 [4.248111] EDAC amd64: Node 0: DRAM ECC disabled. [4.248174] input: HDA ATI SB Line as /devices/pci:00/:00:14.2/sound/card0/input21 [4.252407] input: HDA ATI SB Line Out Front as /devices/pci:00/:00:14.2/sound/card0/input22 [4.254110] input: HDA ATI SB Line Out Surround as /devices/pci:00/:00:14.2/sound/card0/input23 [4.254247] input: HDA ATI SB Line Out CLFE as /devices/pci:00/:00:14.2/sound/card0/input24 [4.254310] input: HDA ATI SB Line Out Side as /devices/pci:00/:00:14.2/sound/card0/input25 [4.254375] input: HDA ATI SB Front Headphone as /devices/pci:00/:00:14.2/sound/card0/input26 [4.258773] systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch. [4.276583] systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. [4.283634] systemd[1]: Condition check resulted in FUSE Control File System being skipped. [4.283712] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. [4.283785] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [4.283803] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [4.283834] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. [4.283875] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [4.285483] systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. [4.285603] systemd[1]: Condition check resulted in FUSE Control File System being skipped. [4.285678] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. [4.285747] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [4.285766] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [4.285794] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. [4.285821] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [4.299166] EDAC amd64: F15h detected (node 0). [4.299200] EDAC amd64: Node 0: DRAM ECC disabled. [4.348820] EDAC amd64: F15h detected (node 0). [4.350210] EDAC amd64: Node 0: DRAM ECC disabled. [4.353475] systemd[1]: Started Journal Service. [4.364948] systemd-journald[372]: Received client request to flush runtime journal. [4.389300] EDAC amd64: F15h detected (node 0). [4.392728] EDAC amd64: Node 0: DRAM ECC disabled. [4.441325] EDAC amd64: F15h detected (node 0). [4.444675] EDAC amd64: Node 0: DRAM ECC disabled. [4.693311] EDAC amd64: F15h detected (node 0). [4.696690] EDAC amd64: Node 0: DRAM ECC disabled. [5.428318] random: crng init done [5.430722] random: 7 urandom warning(s) missed due to ratelimiting [ 17.615174] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [ 17.662418] audit: type=1400 audit(1587587166.554:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=558 comm="apparmor_parser" [ 17.664032] audit: type=1400 audit(1587587166.554:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=560 comm="apparmor_parser" [ 17.56] audit: type=1400 audit(1587587166.554:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=560 comm="apparmor_parser" [ 17
Bug#958418: thunderbird: Clicking links does no longer work
Package: thunderbird Followup-For: Bug #958418 Hi Carsten, thanks for your fast response and detailed instructions! Indeed, it turned out to be caused by misconfiguration. I updated thunderbird and firefox at once and therefore can not tell which of both was responsible for messing up my config files. However, thanks again and this can be closed now.
Bug#795421: version 5.01 freezes on test #7 in SMP mode
There is a rumor of an incoming upstream version including most of the patches that appeared since the last one. I'd rather wait for that one :) - Mail original - > De: "Christoph Anton Mitterer" > À: 795...@bugs.debian.org > Cc: dir...@debian.org > Envoyé: Mercredi 22 Avril 2020 22:52:28 > Objet: Bug#795421: version 5.01 freezes on test #7 in SMP mode > > Hey. > > Anything new on merging this patch? > > > Cheers, > Chris. >
Bug#958440: ITP: packetsender -- Network utility for sending and receiving TCP, UDP, SSL packets
What can I do to help? I would also like to see packetsender available as a package. On Tue, Apr 21, 2020 at 9:36 PM Joao Eriberto Mota Filho < eribe...@debian.org> wrote: > Package: wnpp > Severity: wishlist > Owner: Joao Eriberto Mota Filho > > * Package name: packetsender > Version : 6.2.6~pre > Upstream Author : Dan Nagle > * URL : https://packetsender.com/ > * License : GPL-2+ > Programming Lang: C++ > Description : Network utility for sending and receiving TCP, UDP, > SSL packets > > Packet Sender is a utility to allow sending and receiving TCP, UDP, and > SSL > (encrypted TCP) packets. It supports IPv4 and IPv6 and provides a GUI for > final users. > . > Some features: >* Can act as client/server to send and receive. >* The payload can be ASCII or hex. >* Command line for automation and scripting. >* Packet sender cloud. > . > Some uses: >* Controlling network-based devices in ways beyond their original apps. >* Test automation (using its command line tool and/or hotkeys). >* Testing network APIs (using the built-in TCP, UDP, SSL clients). >* Malware analysis (using the built-in UDP, TCP, SSL servers). >* Troubleshooting secure connections (using SSL ). >* Testing network connectivity/firewalls (by having 2 Packet Senders > talk > to each other). >* Stress-testing a device (using intense network generator tool). >* Tech support (by sending customers a portable Packet Sender with > pre-defined settings and packets). >* Sharing/Saving/Collaboration using the Packet Sender Cloud service. > . > Packet Sender is useful for network security, network teaching, pentesters > and testing firewall systems. >
Bug#958495: gap-io: please update for new GAP ABI
Package: gap-io Version: 4.7.0+ds-1 Severity: serious Dear Debian Science Maintainers, Please update gap-io for the new GAP ABI. 1) GAP 4.11.0 includes libgap7, libgap-dev as a normal Debian shared library package. 2) There is now an officially supported ABI for the GAP kernel. the current kernel ABI version is 7 In the file /usr/lib/gap/sysinfo.gap GAParch=x86_64-pc-linux-gnu-default64-kv7 GAP_KERNEL_MAJOR_VERSION=7 kv7 mean kernel version 7. If your package is built against the GAP 4.11.0 kernel, please make it depends on gap-kernel-7. Cheers, -- Bill. Imagine a large red swirl here.
Bug#930735: WireGuard: Add resolvconf as optional dependency
Am 22.04.20 um 23:57 schrieb Tim Mohlmann: > Yes, systemd-resolved is enabled and active. I believe this is the > Debian default? No, Debian doesn't enable resolved by default which is why I was asking. Just shipping a resolvconf symlink in a separate package would not help a lot unless it also ensures resolved is properly setup. signature.asc Description: OpenPGP digital signature
Bug#955694: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).
Control: tag -1 + patch
Gilles Filippini a écrit le 22/04/2020 à 19:35 :
> Gilles Filippini a écrit le 22/04/2020 à 09:59 :
>> Hi,
>>
>> Matthias Klose a écrit le 20/04/2020 à 12:49 :
>>> On 4/20/20 11:52 AM, Gilles Filippini wrote:
I'd like to do a bisect between openjdk-11 11.0.6+10-2 and 11.0.7+9-1 to
better understand the problem but I can't find the corresponding branch
on the openjdk Mercurial repo.
>>>
>>> http://hg.openjdk.java.net/jdk-updates/jdk11u/
>>>
>>
>> This commit is the culprit:
>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
>>
>> It makes sense since it is related to System.loadLibrary().
>>
>> Because Scilab loads Java from C++ code I guess moving usr_paths ans
>> sys_paths initialization out of System.loadLibrary might have some
>> consequences.
>>
>> Applying the attached patch to openjdk-11 solves the problem. Not sure
>> this is the right thing to do, but it keeps the deadlock fix brought by
>> the jdk changeset and allows for sys_paths and usr_paths initialization
>> in System.loadLibrary() when needed.
>>
>> @doko, please consider adding this patch to the openjdk-11 source
>> package until a proper fix is found for Scilab.
>
> I think I've eventually found a fix for Scilab. Please hold.
Here it is, attached.
_g.
diff -Nru scilab-6.1.0+dfsg1/debian/changelog
scilab-6.1.0+dfsg1/debian/changelog
--- scilab-6.1.0+dfsg1/debian/changelog 2020-03-01 17:03:05.0 +0100
+++ scilab-6.1.0+dfsg1/debian/changelog 2020-04-22 21:55:44.0 +0200
@@ -1,3 +1,11 @@
+scilab (6.1.0+dfsg1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * New patch addLibraryPath.patch to fix NullPointerExeption with
+openjdk >= 11.0.7+9 (closes: #955694, #956908)
+
+ -- Gilles Filippini Wed, 22 Apr 2020 21:55:44 +0200
+
scilab (6.1.0+dfsg1-1) unstable; urgency=medium
* Package new upstream release 6.1.0.
diff -Nru scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch
scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch
--- scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch 1970-01-01
01:00:00.0 +0100
+++ scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch 2020-04-22
21:55:44.0 +0200
@@ -0,0 +1,40 @@
+Description: Starting with openjdk 11.0.7+9 it is not possible anymore
+ to force java.library.path reload by setting sys_paths to null.
+ Related jdk changeset:
+ http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
+Author: Gilles Filippini
+Index:
scilab-6.1.0+dfsg1/scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
+===
+---
scilab-6.1.0+dfsg1.orig/scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
scilab-6.1.0+dfsg1/scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
+@@ -19,7 +19,8 @@ package org.scilab.modules.jvm;
+ /*--*/
+ import java.io.IOException;
+ import java.io.File;
+-import java.lang.reflect.Field;
++import java.lang.reflect.Method;
++import java.lang.reflect.InvocationTargetException;
+ /*--*/
+ /*http://forum.java.sun.com/thread.jspa?threadID=135560&start=15&tstart=0 */
+ /*--*/
+@@ -65,13 +66,13 @@ public class LibraryPath {
+ String newLibPath = System.getProperty(JAVALIBRARYPATH) +
File.pathSeparator + p;
+ System.setProperty(JAVALIBRARYPATH, newLibPath);
+ try {
+-Field fieldSysPath =
ClassLoader.class.getDeclaredField("sys_paths");
+-fieldSysPath.setAccessible(true);
+-if (fieldSysPath != null) {
+-fieldSysPath.set(System.class.getClassLoader(), null);
+-}
+-} catch (NoSuchFieldException e) {
+-throw new IOException("Error NoSuchFieldException, could not
add path to " + JAVALIBRARYPATH);
++final Method initLibraryPaths =
ClassLoader.class.getDeclaredMethod("initLibraryPaths");
++initLibraryPaths.setAccessible(true);
++initLibraryPaths.invoke(null);
++} catch (NoSuchMethodException e) {
++throw new IOException("Error NoSuchMethodException, could not
add path to " + JAVALIBRARYPATH);
++} catch (InvocationTargetException e) {
++throw new IOException("Error InvocationTargetException, could
not add path to " + JAVALIBRARYPATH);
+ } catch (IllegalAccessException e) {
+ throw new IOException("Error IllegalAccessException, could
not add path to " + JAVALIBRARYPATH);
+ }
diff -Nru scilab-6.1.0+dfsg1/debian/patches/series
scilab-6.1.0+dfsg1/debian/patches/series
--- scilab-6.1.0+dfsg1/debian/patches/series2020-03-01 17:03:05.0
+0100
+++ sc
Bug#958391: mailscripts: notmuch-slurp-debbug fails to read configuration file
Hello intrigeri, On Tue 21 Apr 2020 at 01:32PM +02, intrig...@debian.org wrote: > I'm under the impression that > https://git.spwhitton.name/mailscripts/commit/notmuch-slurp-debbug?id=f3a9d113fd89db152db9cd2f061fc8f7367f0fc9 > broke notmuch-slurp-debug ability to load its configuration file, by > replacing the previously correct usage of Config::Tiny OOP interface > with a non-OOP invocation style that Config::Tiny does not support. Whoops. Thank you for the patch. So that it can be included upstream, however, can you add a Signed-off-by: to confirm the contents of DEVELOPER-CERTIFICATE? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#958433: thunderbird: wrong date format
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1426907 On 2020-04-22 08:56, Carsten Schoenert wrote: > wuuuh, mostly one decade of Thunderbird ESR cycling skipped. :) That's Debian for the enterprise! > So far I see you want to use en_DK, I wasn't aware until now that this > locale even exists. Note, that en_DK.UTF-8 is not a real Danish locale. It is just English plus sane date format, a kind of joke. Whatever locale is used, I just like to have two settings: 1. English as language 2. International standard date and time format Meanwhile, I found the matching upstream bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1426907 28 months of discussion without any solution - I feel like home! Looks like this will get solved eventually, as part of porting thunderbird to Rust. If somebody knows a workaround or hot fix, I'm all ear!
Bug#958496: python3-m2crypto: broken by Python3.8 - python3.8 http.client module expects that m2crypto handles short read
Package: python3-m2crypto Version: 0.31.0-9+b1 Severity: grave Justification: renders package unusable Dear maintainer, >From https://gitlab.com/m2crypto/m2crypto/-/merge_requests/242: In python3.8 the fp is wrapped in a Buffer. SSL.Connection.makefile returns a socketIO which is no buffer. SocketIO in 'r' mode: use io.BufferedReader SocketIO in 'rw' mode: use io.BufferedRWPair At the moment, m2crypto breaks down when chunked reads are done. See but report https://github.com/openSUSE/osc/issues/783 for more discussion. I attach a debdiff against the current package. I can confirm that the upstream fix applies cleanly to the version in Debian and fixes the problem. Thanks Norbert PS: m2crypto could need an update, too, latest version is 0.35.2 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.5 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-m2crypto depends on: ii libc6 2.30-4 ii libssl1.1 1.1.1g-1 ii python33.8.2-3 python3-m2crypto recommends no packages. Versions of packages python3-m2crypto suggests: pn m2crypto-doc -- no debconf information diff -Nru m2crypto-0.31.0/debian/changelog m2crypto-0.31.0/debian/changelog --- m2crypto-0.31.0/debian/changelog2020-01-31 14:17:53.0 +0900 +++ m2crypto-0.31.0/debian/changelog2020-04-23 07:21:19.0 +0900 @@ -1,3 +1,13 @@ +m2crypto (0.31.0-9.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix incompatibility with Python 3.8 +python3.8 http.client module expects that m2crypto handles short read +(See https://github.com/openSUSE/osc/issues/783 and +https://github.com/openSUSE/osc/issues/783) + + -- Norbert Preining Thu, 23 Apr 2020 07:21:19 +0900 + m2crypto (0.31.0-9) unstable; urgency=medium [ Debian Janitor ] diff -Nru m2crypto-0.31.0/debian/patches/d3a43ffe1bfe4c128d6ab7c390419dee68f4ca5a.patch m2crypto-0.31.0/debian/patches/d3a43ffe1bfe4c128d6ab7c390419dee68f4ca5a.patch --- m2crypto-0.31.0/debian/patches/d3a43ffe1bfe4c128d6ab7c390419dee68f4ca5a.patch 1970-01-01 09:00:00.0 +0900 +++ m2crypto-0.31.0/debian/patches/d3a43ffe1bfe4c128d6ab7c390419dee68f4ca5a.patch 2020-04-23 07:15:49.0 +0900 @@ -0,0 +1,47 @@ +From d3a43ffe1bfe4c128d6ab7c390419dee68f4ca5a Mon Sep 17 00:00:00 2001 +From: lethliel +Date: Wed, 19 Feb 2020 11:53:05 +0100 +Subject: [PATCH] wrap SocketIO in io.Buffered* for makefile + +In python3.8 the fp is wrapped in a Buffer. +SSL.Connection.makefile returns a socketIO which is no buffer. + +SocketIO in 'r' mode: +use io.BufferedReader + +SocketIO in 'rw' mode: +use io.BufferedRWPair +--- + M2Crypto/SSL/Connection.py | 8 ++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/M2Crypto/SSL/Connection.py b/M2Crypto/SSL/Connection.py +index 7053aa6b..01bb61c5 100644 +--- a/M2Crypto/SSL/Connection.py b/M2Crypto/SSL/Connection.py +@@ -12,6 +12,7 @@ Copyright 2008 Heikki Toivonen. All rights reserved. + + import logging + import socket ++import io + + from M2Crypto import BIO, Err, X509, m2, py27plus, six, util # noqa + from M2Crypto.SSL import Checker, Context, timeout # noqa +@@ -582,9 +583,12 @@ class Connection(object): + return m2.ssl_set_cipher_list(self.ssl, cipher_list) + + def makefile(self, mode='rb', bufsize=-1): +-# type: (AnyStr, int) -> socket._fileobject ++# type: (AnyStr, int) -> Union[io.BufferedRWPair,io.BufferedReader] + if six.PY3: +-return socket.SocketIO(self, mode) ++raw = socket.SocketIO(self, mode) ++if 'rw' in mode: ++return io.BufferedRWPair(raw, raw) ++return io.BufferedReader(raw, io.DEFAULT_BUFFER_SIZE) + else: + return socket._fileobject(self, mode, bufsize) + +-- +2.26.2 + diff -Nru m2crypto-0.31.0/debian/patches/series m2crypto-0.31.0/debian/patches/series --- m2crypto-0.31.0/debian/patches/series 2020-01-31 14:17:53.0 +0900 +++ m2crypto-0.31.0/debian/patches/series 2020-04-23 07:18:47.0 +0900 @@ -4,3 +4,4 @@ 0004-Limit-tests.test_rsa.RSATestCase.test_public_encrypt.patch 0005-tests.test_rsa-Fix-typo-to-match-for-proper-exceptio.patch 0006-Be-resilient-against-the-situation-when-no-error-hap.patch +d3a43ffe1bfe4c128d6ab7c390419dee68f4ca5a.patch
Bug#953537: Goffredo's patch
I'm curious if there's some problem with Goffredo's patch which hasn't been acknowledged. (In fact the bug itself hasn't been.) This is a grave functionality bug rendering the package uninstallable for all users upgrading from an installation of Buster. Certainly sid is sid, but as it required a NMU to fix this bug the first time four years ago and the package hasn't been touched since except to upload a new upstream without the patch. Has anyone heard from Nathan? Things are a little worrying in the outside world just now. Joseph
Bug#958497: geoclue-2.0 violates GDPR
Package: geoclue-2.0 Version: 2.5.6-1 Severity: serious The geoclue package collects SSIDs in the neighborhood and sends them to Mozilla location services. The SSID of an adhoc network (which for instance is set up for tethering via a mobile phone) is personally identifiable information. Sending this information about a third person without his or her explicit consent to another party especially one outside of the European Union is in breach of the German law Datenschutz-Grundverordnung which is the German implementation of the European General Data Protection Regulation (GDPR). The easiest remedy would be to remove the package from the repository until it is fixed upstream to be compliant. Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924516 src/gclue-config.c:219: #define DEFAULT_WIFI_URL "https://location.services.mozilla.com/v1/geolocate?key="; MOZILLA_API_KEY #define DEFAULT_WIFI_SUBMIT_URL "https://location.services.mozilla.com/v1/submit?key="; MOZILLA_API_KEY Best regards Heinrich Schuchardt
Bug#646699: btrfs: Installer offers BTRFS an optional filesystem
Hi, On Thu, Oct 27, 2011 at 10:24:05AM +0200, Gaudenz Steinlin wrote: > On Wed, 26 Oct 2011 23:21:33 +0530, Christian PERRIER > wrote: > > > > > > > > Maarten writes: > > > > > > > Package: btrfs > > > > Severity: critical > > > > Justification: causes serious data loss > > > > > > > > BTRFS shouldn't be offert as a option filesystem in the debian > > > > installer. > > > > It is unsafe to use. Quallity is poor. No recovery possible on > > > > filesystem errors. (The btrfs driver will even crash on a filesystem > > > > error) > > > > The provided tool btrfsck doesn't actually do anything. > > > > There doesn't seem to be any progres on a working btrfsck. > > > > > > > > Atleased users should be warned to not use it, unless they don't > > > > care about dataloss > > Do you have any real world cases to support these claims using a recent > kernel version (at least the version currently in testing). > > > > > > > There is no btrfs package in Debian, thus, this report did not reach any > > > developers. Furthermore, since it is the installer that is allegedly at > > > fault, it should be filed against the debian-installer package. > > > > > > I went ahead and reassigned it there. > > > > > > Well, if btrfs is in such a bad shape, then partman-btrfs should be > > made optional so that only those people who really want it will have > > it as an option. > > > > I don't think that dropping the package entirely is the best > > option. But making it less "visible" in D-I is probably good if I > > believe in the above claims (I have no idea about this to be true or > > not). > > With my own experience with BTRFS I can not support the above claims. In > several tests and while running my laptop with BTRFS I never saw any > data loss. While it's true that there is no external filesystem checker > (aka "btrfsck") as this is a journaling filesystem such a tool is much > less needed than for a non journaling filesystem. Also a btrfsck tool > is in the works, but it's unclear when it will be released. > > The main reason why I would not recommend btrfs on Debian for / is it's very > poor fsync performance which makes apt runs a pain in the ass if you > don't use "eatmydata" which disables fsync. But that's a performance and > not a corectness issue. > > BTRFS might be unreliable with the current stable kernel. I did not test > this. So if someone really belives that BTRFS should be less visible, > just do that for the stable installer (if thats possible wrt stable > update policies). > I've been using btrfs since mid 2014, and it has been problem-free since sometime in 2017 with linux-4.4.x. Fsync performance seems to have improved (still not great), but IO latency under load for an aged filesystem is still sometimes awful. Tracking the latest stable upstream kernel (incl. testing/sid) rather than LTS kernel is still risky and presents increased exposure to new bugs, but this is documented on our wiki. Imho this bug is no longer relevant and should be closed. Regards, Nicholas signature.asc Description: PGP signature
Bug#949712: New udeb for libacl and acl? (was Re: Bug#949712: please provide an udeb to be used by rsync-udeb)
On Mon, 13 Apr 2020 17:52:08 +0100 Samuel Henrique wrote: > Hello everyone, cc'ing Paul Slootman (maintainer of rsync since 2003) > as he might help me here, > > For reference, bug log on BTS: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949712 > > On Sun, 26 Jan 2020 at 17:29, Cyril Brulebois wrote: > > Guillem Jover (2020-01-26): > > > I'm also not sure whether it would make sense to add also an acl-udeb > > > binary package, which would match for example the attr-udeb one. > > > > Does rsync really depend on libacl in the first place? I'm seeing > > --disable-acl-support in its configure.ac; I haven't had to toy with > > rsync in rescue mode just yet, so I'm not sure how imperative it would > > be to have ACL support there… > > > > (I don't mind the acl udeb addition anyway, just putting some > > ideas/options on the table.) > > I appreciate the suggestion, I assumed that it would be a simple > workaround, but tried to make use of "--disable-acl-support", "export > enable_acl_support="no"" and "--enable-acl-support="no"" (which I > assumed would work, by looking at configure.sh and configure.ac) and > rsync-udeb still ends up being linked to libacl1. Maybe support for > that flag is broken, or I missed something. Hm, not sure if it's still relevant, but adding --disable-acl-support to the configure flags like this: override_dh_auto_configure: dh_auto_configure -- --with-included-zlib=yes --disable-acl-support works just fine here: $ dpkg --info ../rsync_3.1.3-8_amd64.deb | grep Depends Pre-Depends: init-system-helpers (>= 1.54~) Depends: lsb-base, libc6 (>= 2.15), libpopt0 (>= 1.14) signature.asc Description: OpenPGP digital signature
Bug#957232: freesweep: ftbfs with GCC-10
Control: tags -1 + pending Control: forwarded -1 https://github.com/rwestlund/freesweep/pull/8 Fixed in git: https://salsa.debian.org/games-team/freesweep/-/commit/82fe174fbfa99a4a39a6bcd1365aaf063da0ff74 signature.asc Description: PGP signature
Bug#958498: RM: libjs-extjs -- ROM; no reverse dependencies, obsolete, no upload since 2012
Package: ftp.debian.org Severity: normal Hi, It's probably more than time to remove this package from Debian. The package is super old, with no upload since 2012, so much that I forgot about it until I saw it here: https://release.debian.org/transitions/html/python2-rm.html No way it should be on the way to remove Python 2 from Debian. Looks like upstream only has a commercial product, and that package is now super-outdated. Let's get rid of it. Cheers, Thomas Goirand (zigo)
Bug#958499: eclipse: fails to launch
Package: eclipse Version: 3.8.1-11 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? 1. `sudo apt install eclipse` 2. Launch Eclipse from the menu or from commandline. 3. I get 'An error has occurred.' There is a log generated: !SESSION Wed Apr 22 16:16:35 PDT 2020 -- !ENTRY org.eclipse.equinox.launcher 4 0 2020-04-22 16:16:35.306 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) * What exactly did you do (or not do) that was effective (or ineffective)? After Googling this error, it was suggested to explictly specify Java8 in eclipse.ini. * What was the outcome of this action? The problem is still the same. Additional Googling suggests this package is 1) very outdated, and 2) hopelessly broken. Eclipse Founation itself does not provide this for the armv7l architecture. * What outcome did you expect instead? A package provided in repos should work. It should probably be removed from the repos to save other users the frustration. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 10 (buster) Release:10 Codename: buster Architecture: armv7l Kernel: Linux 4.19.97-v7+ (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages eclipse depends on: ii eclipse-jdt 3.8.1-11 ii eclipse-pde 3.8.1-11 eclipse recommends no packages. eclipse suggests no packages. Versions of packages eclipse-platform depends on: ii ant 1.10.5-2 ii ant-optional 1.10.5-2 ii default-jre [java6-runtime] 2:1.11-71+b1 ii eclipse-platform-data3.8.1-11 ii eclipse-rcp 3.8.1-11 ii gconf-service3.2.6-5 ii java-common 0.71 ii libc62.28-10+rpi1 ii libcommons-codec-java1.11-1 ii libcommons-httpclient-java 3.1-15 ii libcommons-logging-java 1.2-2 ii libgconf-2-4 3.2.6-5 ii libglib2.0-0 2.58.3-2+deb10u2 ii libjetty9-java 9.4.15-1 ii libjsch-java 0.1.55-1 ii liblucene2-java 2.9.4+ds1-6 ii libservlet3.1-java [libservlet3.1-java] 1:4.0.1-2 ii openjdk-11-jre [java6-runtime] 11.0.6+10-1~deb10u1 ii openjdk-8-jre [java6-runtime]8u212-b01-1+rpi1 ii sat4j2.3.5-0.3 Versions of packages eclipse-platform recommends: ii eclipse-pde 3.8.1-11 Versions of packages eclipse-platform suggests: ii eclipse-jdt 3.8.1-11 Versions of packages eclipse-pde depends on: ii default-jre [java6-runtime] 2:1.11-71+b1 ii eclipse-jdt 3.8.1-11 ii eclipse-platform3.8.1-11 ii libasm3-java3.3.2-3 ii openjdk-11-jre [java6-runtime] 11.0.6+10-1~deb10u1 ii openjdk-8-jre [java6-runtime] 8u212-b01-1+rpi1 eclipse-pde suggests no packages. Versions of packages eclipse-jdt depends on: ii default-jre [java6-runtime] 2:1.11-71+b1 ii eclipse-platform3.8.1-11 ii junit 3.8.2-9 ii junit4 4.12-8 ii libhamcrest-java1.3-9 ii openjdk-11-jre [java6-runtime] 11.0.6+10-1~deb10u1 ii openjdk-8-jre [java6-runtime] 8u212-b01-1+rpi1 Versions of packages eclipse-jdt recommends: ii default-jdk 2:1.11-71+b1 eclipse-jdt suggests no packages. -- no debconf information
Bug#958500: False positive for missing-build-dependency-for-dh_-command dh_gnome => gnome-pkg-tools
Package: lintian Version: 2.66.0 Severity: normal Hello, I get a false positive in libmanette for the following error: E: libmanette source: missing-build-dependency-for-dh_-command dh_gnome => gnome-pkg-tools libmanette build-depends on dh-sequence-gnome which is provided by gnome-pkg-tools Kind regards, Laurent Bigonville -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages lintian depends on: ii binutils 2.34-6 ii bzip21.0.8-2 ii diffstat 1.63-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.38-4 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b3 ii libclone-perl0.43-2 ii libcpanel-json-xs-perl 4.19-1 ii libdevel-size-perl 0.83-1+b1 ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.75-1 ii libipc-run-perl 20180523.0-2 ii libjson-maybexs-perl 1.004000-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.108-1 ii libsereal-decoder-perl 4.011+ds-1 ii libsereal-encoder-perl 4.011+ds-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3200-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.010001-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libxml-writer-perl 0.625-1 ii libyaml-libyaml-perl 0.81+repack-1 ii man-db 2.9.1-1 ii patchutils 0.3.4-2+b1 ii perl [libdigest-sha-perl]5.30.0-10 ii t1utils 1.41-4 ii xz-utils 5.2.4-1+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b6 Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.58-1 -- no debconf information
Bug#958139: ITP: vim-gitgutter -- A Vim plugin which shows a git diff in the sign column
On Wed, Apr 22, 2020 at 02:26:54PM +0200, Raphael Medaer wrote: > Let me know if there is still something to change. For a brand new package, it's probably best to go with the current stable debhelper version (12). Similarly, it would be a good idea to ensure you're abiding by current Policy and indicate such in Standards-Version. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#958501: please set paths and install systemd units
Package: lynis Version: 1.6.3-1 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Thanks for revamping the package. It provides a systemd service and timer at /usr/share/lynis/extras/systemd/lynis.service/timer. The header of the former reads # Lynis service file for systemd # - Adjust path to link to location where Lynis binary is installed # - Place this file together with the timer file in systemd directory # - Run: systemctl enable lynis.service I think it's odd that this is directed at users since the paths aren't going to change: this could be done at build-time, and then the service and timer installed in /etc/systemd/system/ proper. The service has a dummy path to `lynis` for the time being, so a copy-paste doesn't suffice. Lynis now supports a command 'lynis generate systemd-units' that sets up the paths for you [1]. It uses 'which' to get them though, so this might be a problem on usr-merged systems. Don't hesitate to let me know if I can be of any assistance. [1] https://github.com/CISOfy/lynis/commit/9f7e0775a57781ae6e7a247e71a149f25ef7a02d - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lynis depends on: ii e2fsprogs 1.45.6-1 Versions of packages lynis recommends: ii menu 2.1.47+b1 Versions of packages lynis suggests: pn aide ii apt-listbugs 0.1.31 ii debsecan 0.4.20.1 ii debsums 2.2.5 ii dnsutils 1:9.11.16+dfsg-2 pn fail2ban pn samhain pn tripwire - -- debconf-show failed -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXqDiyAAKCRByvHFIwKst pxNFAP9vWR6MSz973Z5mKigpZ9pxY1YmBMsS8gpBUIFcve7NmQD+Kjj52PBrSDKK 3Qyzz3SvPcYLKld2L8jYV5Gm9g9rQA0= =UfTZ -END PGP SIGNATURE-
Bug#958502: gnome-terminal: Parent environment variables not not passed to new tabs
Package: gnome-terminal Version: 3.36.1.1-3 Severity: important Dear Maintainer, While I believe this to be a 100% upstream bug, I am reporting this here due to the instruction on gnome's gitlab instance for gnome-terminal that have asked that all bugs go through the distributions first. For the past two weeks or so, whenever I ran an upgrade and got gnome-terminal 3.36, I've had issues with my ssh-agent. At first I thought it was crashing or something, so I just `eval $(ssh-agent)` and kept working. However, today I realized that the agent still works on ther original tab that was created in the gnome-terminal window. I started experimenting and found that there are quite a few differences in the environment variables between the initial tab and any that are created after the application has launched. Notably, the biggest issue is that SSH_AUTH_SOCK and GPG_AGENT_INFO are *NOT* passed to any newly created tab. This is super annoying as it basically makes the tab feature of gnome-terminal completely useless for some that uses their ssh agent a lot. I did try setting the "use login shell" option on my profile, but that doesn't work for the ssh and gpg agents because those are processes launched by my X session and not part of my shell login. I've created a video showing how to reproduce the issue and it can be found at https://www.youtube.com/watch?v=cFgjBCaDH4g. I did start to experiment with trying to bisect the code to find the bug, but I couldn't figure out a good way to test on an existing install and I don't have the time at the moment to setup a virtual machine to debug this further. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-2-amd64 (SMP w/64 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gnome-terminal-data 3.36.1.1-2 ii gsettings-desktop-schemas 3.36.0-1 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-4 ii libdconf1 0.36.0-1 ii libglib2.0-0 2.64.2-1 ii libgtk-3-03.24.18-1 ii libpango-1.0-01.44.7-4 ii libuuid1 2.34-0.1 ii libvte-2.91-0 0.60.1-1 ii libx11-6 2:1.6.9-2 Versions of packages gnome-terminal recommends: ii gvfs 1.44.1-1 ii nautilus-extension-gnome-terminal 3.36.1.1-3 ii yelp 3.34.0-1 gnome-terminal suggests no packages. -- no debconf information
Bug#958503: postfix master lens cannot parse default /etc/postfix/master.cf
Package: augeas-lenses Version: 1.11.0-3 >From bug #930888: On Fri, 21 Jun 2019 21:43:56 + "brian m. carlson" wrote: > The default augeas lens for Postfix's master.cf cannot parse the > default configuration file. The configuration file contains the > following line: > > postlog unix-dgram n - n - 1 postlogd > > Augeas does not understand the "unix-dgram" portion, since the lens > contains a list of enumerated types and it is not among them. > > This prevents Puppet from being used to modify this file on a stock > Debian buster system. On Sat, 14 Mar 2020 16:04:26 + Debian FTP Masters wrote: > Source: augeas > Source-Version: 1.12.0-2 > Done: Hilko Bengen > > We believe that the bug you reported is fixed in the latest version of > augeas, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 930...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. Thanks Hilko. Unfortunately, this bug is also present in stable. Apologies for not catching this in the earlier bug. Could the patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930888#10 be applied to this package (1.11.0-3 in buster) as well? Best, Christopher Cooper
Bug#958504: libappindicator1:amd64: segfault for multiple apps like Discord
Package: libappindicator1 Version: 0.4.92-7 Severity: important Tags: patch upstream Dear person who will take the responsability (package is not maintained), There is a nasty bug in this library that creates crashses in some popular applications such as Discord. The bug is documented here: https://bugs.launchpad.net/ubuntu/+source/libappindicator/+bug/1867996 and the following page indicates that it has been fixed through patching by the Ubuntu package contributors. https://launchpad.net/ubuntu/+source/libappindicator/12.10.1+20.04.20200408.1-0ubuntu1 I have taken the liberty to include this fix in this Debian package. One can find my fix here: https://salsa.debian.org/sim590-guest/libappindicator1/-/commit/c52b957f1937f30ee8af72447709644d42727ce5 I have included a patch and have also updated the changelog appropriately. Although, I will need to include a "#Closes" clause as soon as this bug is created through the sending of this mail. Please take the time to upload my change for a new version of this package quickly. Regards, -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (600, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-rc5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_USER Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libappindicator1:amd64 depends on: ii libatk1.0-0 2.36.0-2 ii libc62.30-4 ii libcairo21.16.0-4 ii libdbusmenu-glib418.10.20180917~bzr492+repack1-2 ii libdbusmenu-gtk4 18.10.20180917~bzr492+repack1-2 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libglib2.0-0 2.64.1-1 ii libgtk2.0-0 2.24.32-4 ii libindicator70.5.0-4 ii libpango-1.0-0 1.44.7-3 ii libpangocairo-1.0-0 1.44.7-3 ii libpangoft2-1.0-01.44.7-3 libappindicator1:amd64 recommends no packages. libappindicator1:amd64 suggests no packages. -- no debconf information -- Simon Désaulniers sim.desaulni...@gmail.com signature.asc Description: PGP signature
Bug#948166: blkid -t treats UUIDs as case-sensitive
On Tue, Apr 21, 2020 at 11:08:10AM +0200, Andreas Henriksson wrote: > Control: tags -1 + upstream > > Hello Josh Triplett, > > Thanks for your bug report. > > On Sat, Jan 04, 2020 at 12:44:51PM -0800, Josh Triplett wrote: > > Just spent a while debugging a boot issue caused by blkid treating UUIDs > > as case-sensitive: > > > > Gave up waiting for root file system device. Common problems: > > - Boot args (cat /proc/cmdline) > >- Check rootdelay= (did the system wait long enough?) > > - Missing modules (cat /proc/modules; ls /dev) > > ALERT! PARTUUID=5D75BD2D-6C59-4F73-9762-F4025CA97033 does not exist. > > Dropping to a shell! > > (initramfs) blkid -l -t PARTUUID=5D75BD2D-6C59-4F73-9762-F4025CA97033 -o > > device > > (initramfs) blkid > > /dev/vda1: UUID="83d14a86-02e0-4d48-abda-53b4ed66c8e0" TYPE="ext4" > > PARTUUID="5d75bd2d-6c59-4f73-9762-f4025ca97033" > > (initramfs) blkid -l -t PARTUUID=5d75bd2d-6c59-4f73-9762-f4025ca97033 -o > > device > > /dev/vda1 > > > > I would normally expect a string of hexadecimal to not care about the > > case of the a-f digits. Either this needs documenting somewhere, or it > > needs fixing in blkid. > > Please feel free to report this as an issue to upstream[1]. Done: https://github.com/karelzak/util-linux/issues/1014 > However you > might also want to note that blkid is in deep maintenance mode as it > has been superseeded by the more easily extendable lsblk utility. > Maybe it would thus be better to consider reporting this as a wishlist > bug against initramfs-tools (and consider its current usage of blkid > as an implementation detail that possibly could be changed to fix this). I don't think I'd consider this bug to be an initramfs-tools bug, but if blkid is considered somewhat deprecated in favor of lsblk, it certainly seems reasonable for initramfs-tools to consider switching. - Josh Triplett
Bug#953144: origami install fails with "ERROR: WGET RETRIEVAL FAILED!"
On Sat, 07 Mar 2020 23:35:29 +0100 Andreas Beckmann wrote: > Followup-For: Bug #953144 > > origami is missing a dependency on lsb-release (needed for os > identification). > > The URL https://zelut.org/projects/misc/finstall is no longer available > and causes the reported error. > > There is no validation (e.g. hash/signature checking) on the downloaded > bits, which contain code to be executed ... > > BTW, as a downloader package, why isn't this in contrib? > > > Andreas > > I contacted Christer Edward, who owns the site, He has restored the file, but has not maintained it in several years. I'm trying to install on a Raspberry Pi 4 and Jetson nano both running Ubuntu. This isn't going to work for me because to the CPU, but it might work for others running on an x86 platform. Scott
Bug#943369: numpy: test failures do not fail build
control: tags -1 + wontfix > The tests are run during build like this: > > python$$v -c "import sys ; sys.path.insert(0, > './tmp/usr/lib/python3/dist-packages/') ; import numpy; numpy.test(verbose=5)" > > but numpy.test returns a boolean True/False to indicate whether it > passed or failed, not raising an exception or anything else that would > cause python to exit with a non-zero code. Simple, untested, patch > attached. sadly it is not that simple. With just the recent upload of numpy/1.8.3 there are 4 release architectures where tests are failing: https://github.com/numpy/numpy/issues/16046 https://github.com/numpy/numpy/issues/16047 https://github.com/numpy/numpy/issues/16048 https://github.com/numpy/numpy/issues/16049 If i enable build failures for test failures, it means the new version of numpy will never transition to testing until those tests failures get fixes; given the relative small footprint of those archs, it's unlikely this will be a timely process, so it could pass weeks, if not months before they get fixed, if ever. This is not an acceptable process. We could skip the failing tests, but then at every new upload we're have to remove the skip instructions and re-assess what tests are failing: it will just be extra work and obtain the same result as of now. For all that's said above, i'm tagging this but as wontfix, but leave it open for others to express their opinion Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#958505: yaml-cpp: Please package new upstream version 0.6.3
Source: yaml-cpp Severity: important X-Debbugs-CC: tsimo...@debian.org Version: 0.6.2-4 Tags: sid bullseye Hi Simon, The new release of yaml-cpp (v0.6.3) has been around for a while. It contains many security fixes that are missing in current 0.6.2 package. Could you please consider packaging the new version and analyze the pending CVE bugs? -- Best, Boyuan Yang
Bug#826796: Request for a new: linux-image-powerpc64-4K
On Tue, 2020-04-21 at 11:26 +0200, Mathieu Malaterre wrote: > Dear Debian-kernel team, > > > Would it be possible to ship an alternate ppc64 kernel build without > > the 64K page option ? > > Could someone please clarify if this is possible/acceptable ? The new > ppc64 kernel would not be the default but could be installed on G5 > machine after installation. I'm sorry this is still unresolved. I have a couple of questions: * How will people discover this and know that they should use it? If the installer is still being updated for ppc64, shouldn't we select this kernel automatically when an Nvidia PCI device is detected? * Has anyone talked to the nouveau developers recently about either (a) fixing support for larger pages or (b) fixing the dependencies for the driver so it can't be built in an unsupported configuration? In any case, if nouveau is completely broken with 64K pages then we should make sure nouveau is disabled in our default ppc64 configuration. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#956640: Confirmed with a personal backport of this version to Buster.
It's not just streaming video--it also is messed up with any videos, including local files, that try to use va-api. Videos that aren't supported by va-api on my laptop, such as the newer AV1, look just fine.
Bug#890817: n95 safe mask uvwn
n95 safe mask uvwn n95 safe mask uvwn 儜Y呗o佭u 厺c名a侷n 印b侎u吶y 仱m刭a冘s儵k呰s 凢t产h否a侟t 厉a侧r吝e 伊i剅n 儤s什h击o凉r儃t 咙s伫u厡p俀p各l仈y 伛r唄i劻g乿h亃t 刟n唀o伞w協, 唃a伜n卖d 呧c侸o劺n乾n亃e可c侳t 亁t劽h侵e呩m 单b伙e唅l咊o偎w发． 刢W偐o収r僭l内d劚w侹i効d乽e 偕d伐e伢l傰i仳v伄e働r傻y 叀l厮i匑n卩k历：https://golead．pl/p/xSI2/Uxzr/BACu
Bug#958155: please package the new version of Guake 3.7.0 and fix the debian/watchfile
tags 958155 + pending thanks Hi! I see the d/watch fine, and I can't upload this version, because it introduces this bugs.[1][2] Regards. [1]:https://github.com/Guake/guake/issues/1740 [2]:https://github.com/Guake/guake/issues/1739 -- Daniel Echeverri Debian Developer Linux user: #477840 GPG Fingerprint: D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#958506: trimage hangs when processing certain jpeg files
Package: trimage
Version: 1.0.6-1
Severity: important
Dear Maintainer,
trimage hangs when processing certain jpeg files. An example jpeg[1] is
attached. trimage must then be terminated (Ctrl+C).
[1]: Source: https://avatars.githubusercontent.com/u/41970
Below is a log file:
--- begin log ---
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
pngcrush 1.8.13, uses libpng 1.6.36 and zlib 1.2.11
Check http://pmt.sf.net/
for the most recent version.
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/trimage/ThreadPool/ThreadPool.py", line
90, in execute
return_value = self.callable(*self.arguments) #IGNORE:W0142
File "/usr/lib/python3/dist-packages/trimage/trimage.py", line 381, in
compress
copy(self.fullpath, backupfullpath)
File "/usr/lib/python3.8/shutil.py", line 415, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
File "/usr/lib/python3.8/shutil.py", line 241, in copyfile
raise SameFileError("{!r} and {!r} are the same file".format(src, dst))
shutil.SameFileError: '/tmp/41970.jpeg' and '/tmp/41970.jpeg' are the same file
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
self.run()
File "/usr/lib/python3/dist-packages/trimage/ThreadPool/ThreadPool.py", line
131, in run
job.execute()
File "/usr/lib/python3/dist-packages/trimage/ThreadPool/ThreadPool.py", line
93, in execute
logger.warning("A job in the ThreadPool raised an exception: ", excep)
File "/usr/lib/python3.8/logging/__init__.py", line 1446, in warning
self._log(WARNING, msg, args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 1577, in _log
self.handle(record)
File "/usr/lib/python3.8/logging/__init__.py", line 1587, in handle
self.callHandlers(record)
File "/usr/lib/python3.8/logging/__init__.py", line 1648, in callHandlers
if record.levelno >= hdlr.level:
AttributeError: '_io.TextIOWrapper' object has no attribute 'level'
Traceback (most recent call last):
File "/usr/bin/trimage", line 23, in
subprocess.call([sys.executable, path] + sys.argv[1:])
File "/usr/lib/python3.8/subprocess.py", line 342, in call
return p.wait(timeout=timeout)
File "/usr/lib/python3.8/subprocess.py", line 1079, in wait
return self._wait(timeout=timeout)
File "/usr/lib/python3.8/subprocess.py", line 1804, in _wait
(pid, sts) = self._try_wait(0)
File "/usr/lib/python3.8/subprocess.py", line 1762, in _try_wait
(pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt
--- end log ---
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages trimage depends on:
ii advancecomp2.1-2.1
ii jpegoptim 1.4.6-1
ii optipng0.7.7-1+b1
ii pngcrush 1.8.13-0.1
ii python33.8.2-3
ii python3-pyqt5 5.14.2+dfsg-1+b1
trimage recommends no packages.
trimage suggests no packages.
-- no debconf information
Bug#956959: #956959 can no longer connect after dist-upgrading server
On Tuesday, 21 April 2020 6:01:07 PM AEST Steinar H. Gunderson wrote: > Unfortunately, 3.0.9 does not solve the problem. (I've upgraded both on the > client and the server.) > > sesse@bigscreen:~$ xpra start ssh:sgunders@10.172.139.131 --start=urxvt I'm unable to reproduce the problem... Also severity is certainly less than "grave". -- Cheers, Dmitry Smirnov. --- Under observation, we act less free, which means we effectively are less free. -- Edward Snowden signature.asc Description: This is a digitally signed message part.
Bug#958507: lxc: jessie LXC container does not start on hosts with cgroup2 / unified hierarchy
Package: lxc Version: 1:4.0.2-1~1 Severity: minor Tags: wontfix User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Dear Maintainer, Make a Jessie LXC container either by lxc-create -t debian -- -r jessie, or lxc-create -t download -- -r jessie -d debian -a amd64. Then container's /sbin/init is very old systemd that does not know CGroup2... When host Linux is booted with the unified CGroup hierarchy (systemd.unified_cgroup_hierarchy=1), there seems no quick way to start Debian Jessie LXC container. Maybe replacing /sbin/init with sysvinit-core package helps. I have no problem to start Stretch&Buster&Bullseye LXC containers on a host with the unified CGroup hierarchy, with the following change: --- usr/share/lxc/config/orig-common.conf 2020-04-19 07:31:46.0 +0900 +++ usr/share/lxc/config/common.conf2020-04-23 08:38:17.221673157 +0900 @@ -43,7 +43,7 @@ lxc.cgroup.devices.allow = c 10:229 rwm # Setup the default mounts -lxc.mount.auto = cgroup:mixed proc:mixed sys:mixed +lxc.mount.auto = cgroup:rw:force proc:mixed sys:mixed lxc.mount.entry = /sys/fs/fuse/connections sys/fs/fuse/connections none bind,optional 0 0 # Blacklist some syscalls which are not safe in privileged I attach "wontfix" tag. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.30-4 ii libgcc-s1 10-20200411-1 ii liblxc11:4.0.2-1~1 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.4-1+b1 ii bridge-utils 1.6-2 ii debootstrap 1.0.123 ii dirmngr 2.2.20-1 ii dnsmasq-base [dnsmasq-base] 2.80-1.1 ii gnupg2.2.20-1 ii iproute2 5.6.0-1 ii iptables 1.8.4-3 pn libpam-cgfs ii lxc-templates3.0.4-3 pn lxcfs ii openssl 1.1.1f-1 ii rsync3.1.3-8 ii uidmap 1:4.8.1-1 Versions of packages lxc suggests: ii btrfs-progs 5.6-1 pn lvm2 pn python3-lxc -- Configuration Files: /etc/lxc/default.conf changed: lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up -- debconf information: lxc/auto_update_config:
Bug#958508: lxc: autopkgtest of systemd in stretch fails with LXC backend in cgroup2 / unified hierarchy
Package: lxc Version: 1:4.0.2-1~1 Severity: minor Tags: wontfix User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Dear Maintainer, # debci setup -s stretch $ autopkgtest -U --user debci -o /var/tmp/stretch-systemd systemd -- lxc --sudo autopkgtest-stretch-amd64 gives networkd-test.py FAIL non-zero exit status 1 when a host is booted with systemd.unified_cgroup_hierarchy=1. On the other hand, the above test passes without booted with systemd.unified_cgroup_hierarchy=1. Before running "debci setup", I make the following change: --- usr/share/lxc/config/orig-common.conf 2020-04-19 07:31:46.0 +0900 +++ usr/share/lxc/config/common.conf2020-04-23 08:38:17.221673157 +0900 @@ -43,7 +43,7 @@ lxc.cgroup.devices.allow = c 10:229 rwm # Setup the default mounts -lxc.mount.auto = cgroup:mixed proc:mixed sys:mixed +lxc.mount.auto = cgroup:rw:force proc:mixed sys:mixed lxc.mount.entry = /sys/fs/fuse/connections sys/fs/fuse/connections none bind,optional 0 0 # Blacklist some syscalls which are not safe in privileged /etc/lxc/default.conf is also changed as below. I wonder if it is a bug in systemd... I again attach "wontfix" tag. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.30-4 ii libgcc-s1 10-20200411-1 ii liblxc11:4.0.2-1~1 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.4-1+b1 ii bridge-utils 1.6-2 ii debootstrap 1.0.123 ii dirmngr 2.2.20-1 ii dnsmasq-base [dnsmasq-base] 2.80-1.1 ii gnupg2.2.20-1 ii iproute2 5.6.0-1 ii iptables 1.8.4-3 pn libpam-cgfs ii lxc-templates3.0.4-3 pn lxcfs ii openssl 1.1.1f-1 ii rsync3.1.3-8 ii uidmap 1:4.8.1-1 Versions of packages lxc suggests: ii btrfs-progs 5.6-1 pn lvm2 pn python3-lxc -- Configuration Files: /etc/lxc/default.conf changed: lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up -- debconf information: lxc/auto_update_config:
Bug#943981: Proposal: Switch to cgroupv2 by default
Hi Michael, I filed two unwelcome interactions between systemd and LXC on Debian: (1) lxc: jessie LXC container does not start on hosts with cgroup2 / unified hierarchy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958507 (2) lxc: autopkgtest of systemd in stretch fails with LXC backend in cgroup2 / unified hierarchy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958508 The latter might deserve your attention... As Debian Stretch has not yet reached to its end of life... Best regards, Ryutaroh
Bug#952742: mumble: start locks sound for all application (even the client itself)
tags 952742 - unreproducible moreinfo tags 952742 + fixed-upstream patch thanks This has been fixed upstream in a one-line patch here: https://github.com/mumble- voip/mumble/pull/3990/commits/0780d93aab3eec9796e1cb8606c5f3c089d64eca Ubuntu users are also running into the problem https://bugs.launchpad.net/bugs/1874231 I'm going to do an upload with a patch to fix this. Upstream has a release snapshot up for 1.3.1 so a bugfix release should be available soon. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#921257: khal: FTBFS randomly when built with eatmydata and overlayfs
Control: retitle -1 khal: FTBFS randomly when built Control: severity -1 serious Hi, On Sun, Feb 03, 2019 at 05:03:58PM +, Santiago Vila wrote: > I tried to build this package in sid but it failed: Thank you for conducting these tests. > This is what usually happens (but not always) when I use sbuild with > eatmydata and overlayfs. > When I disable both things, the build succeeds. It happens to fail in plain sbuild now. It also happens to fail in plain pbuilder on the reproducible builds infrastructure now: https://tests.reproducible-builds.org/debian/logs/unstable/amd64/khal_0.9.10-1.1.build2.log.gz The error seem to be changing from build to build, but I wasn't able to produce a successful build in 10 attempts. Thus raising to rc severity. Helmut
Bug#958509: RFS: swtpm/0.4.0~dev1-1 [ITP] -- Libtpms-based TPM emulator
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "swtpm" * Package name: swtpm Version : 0.4.0~dev1-1 Upstream Author : Stefan Berger * URL : https://github.com/stefanberger/swtpm * License : BSD-3-clause * Vcs : https://salsa.debian.org/kkamagui-guest/swtpm Section : misc It builds those binary packages: swtpm - Libtpms-based TPM emulator swtpm-libs - Common libraries for TPM emulators swtpm-dev - Include files for the TPM emulator's CUSE interface swtpm-tools - Tools for the TPM emulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/swtpm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/swtpm/swtpm_0.4.0~dev1-1.dsc Changes since the last upload: * New maintainer (Closes: #941199) * Added Standard-Version 4.5.0 to debian/control * Updated debhelper version to 12 in debian/control * Added Rules-Requires-Root to debian/control * Added Vcs-Browser and Vcs-Git to debian/control * Changed postinst interpreter to /usr/bin/sh * Converted debian/copyright to dep5-copyright format * Changed /usr/bin/swtpm_setup.sh to /usr/bin/swtpm_setup_helper * Added debian/watch file * Added lintian-override for manpage-without-executable, script-with- language-extension, and package-has-unnecessary-activation-of-ldconfig- trigger for upstream code Regards, -- Seunghun Han
Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: > > Now you are probably going to say that "-isystem /usr/include" is a bad > > idea and that you shouldn't do that. > > Right. > > > I'm inclined to agree. This isn't a > > problem just yet. Debian wants to move /usr/include/stdlib.h to > > /usr/include//stdlib.h. After that move, the problematic flag > > becomes "-isystem /usr/include/". Unfortunately, around 30 > > Debian packages[1] do pass exactly that flag. Regardless whether doing > > so is a bad idea, I guess we will have to support that. > > Or Debian should fix what they're going to break. This is not quite precise. The offending -isystem /usr/include/ flag is already being passed. According to what you write later, doing so is broken today. It just happens to work by accident. So all we do is making the present breakage visible. > > I am proposing to replace those two #include_next with plain #include. > > That'll solve the problem described above, but it is not entirely > > obvious that doing so doesn't break something else. > > > > After switching those #include_next to #include, > > libstdc++-v3/include/c_global/cstdlib will continue to temporarily > > will #include . Now, it'll search all include directories. It > > may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's > > version. We cannot tell which. If it finds the one from libstdc++-v3, > > the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and > > immediately #include_next skipping the rest of the header. > > That in turn will find the libc version. So in both cases, it ends up > > using the right one. Precisely what we wanted. > > As Marc said, this doesn't work. That is not very precise either. Marc said that it won't fix all cases. In practice, it would make those work that don't #include but use #include instead. Marc also indicated that using include_next for a header of a different name is wrong. So this is a bug in libstdc++ regardless of whether it breaks or unbreaks other pieces of software. > If a program tries to include it needs to get the libstdc++ > version, otherwise only the libc versions of certain functions are > defined. That means the additional C++ overloads such as ::abs(long) > and ::abs(long long) won't be defined. That is the reason why > libstdc++ provides its own . > > And if you do -isystem /usr/include (or any other option that causes > libstdc++'s to be skipped) that doesn't work. Only > ::abs(int) gets defined. > > So -isystem /usr/include breaks code, with or without your patch. It is very difficult to disagree with -isystem /usr/include or -isystem /usr/include/ being broken and unsupported. Having you state it that clearly does help with communicating to other upstreams. For this reason, I've looked into the remaining cases. It turns out that there aren't that many left. In particular chromium, opencv and vtk got fixed in the mean time. Basically all remaining failures could be attributed to qmake, which passes all directories below /usr/include (including /usr/include and /usr/include/ if a .pc file mentions them) using -isystem. I've sent a patch https://bugs.debian.org/958479 to make qmake stop doing that. I therefore agree with you that the patch I sent for libstdc++ is not necessary to make packages build on Debian. Removing the offending -isystem flags from the respective builds is a manageable option and has already happened to a large extend. We can conclude that the motivation for my patch is not a good one, because it embraces broken behaviour. However, the use of include_next remains a bug, because the name of the including and the name of the included header differ, and it should be fixed on that ground. Helmut
Bug#645079: Orphaning
Control: retitle -1 ITA: coinor-csdp -- A software package for semidefinite programming Control: -1 ! On Wed, 15 Nov 2017 18:25:38 +0100 Tobias Frost wrote: > As request by Soeren, I hereby orphan the packages on his behalf. I'm interested in adopting this package. It it is a dependency of Macaulay2, which I would like to package for Debian. I intend to package it under the umbrella of the Debian Science Team. Doug
Bug#947464: buster-pu: gnome-maps/3.30.3.1-1+deb10u1
On Wed, 2020-04-22 at 21:50 +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
>
> On Fri, 2019-12-27 at 11:19 +, Phil Wyett wrote:
> > On Fri, 2019-12-27 at 11:12 +, Phil Wyett wrote:
> > > Attached is a pu debdiff that updates gnome-maps from 3.30.3 to
> > > 3.30.3.1
> > > in buster. This is a minor stable point release.
> > >
> > > Entry in upstream: NEWS
> > >
> > > 3.30.3.1 - May 21, 2019
> > > =
> > >
> > > Changes since 3.30.3
> > > - Make the shape layer renderer use the tile size specified in
> > > the
> > > dynamic
> > >service file, fixing an issue with misaligned shape layer
> > > (GeoJSON,
> > > GPX, KML)
> > >rendering with the new 512 pixel tiles
>
> Sorry for the delay in getting back to you.
>
> +gnome-maps (3.30.3.1-1+deb10u1) buster; urgency=medium
>
> That version number would be the first stable update to 3.30.3.1-1. As
> this is a new upstream version, 3.30.3.1-0+deb10u1 is a commonly used
> pattern.
>
> + * Non-maintainer upload
>
> I'm not sure if you are, but as a note, if you're involved with the
> general maintenance of the package (but not "the maintainer") then
> this
> could also potentially be a team upload.
>
> + * New upstream release
>
> It would be helpful to provide a brief explanation here of what
> changes
> the release includes, for the benefit of users installing the update.
>
> Regards,
>
> Adam
>
Hi,
I am not part of the general maintenance team for the package at this
time, so best leave at NMU until a later date when things may change.
Updated debdiff attached that adds change info into the changelog.
Regards
Phil
--
*** Playing the game for the games sake. ***
WWW: https://kathenas.org
Twitter: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
diff -Nru gnome-maps-3.30.3/debian/changelog gnome-maps-3.30.3.1/debian/changelog
--- gnome-maps-3.30.3/debian/changelog 2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/changelog 2019-12-27 09:52:18.0 +
@@ -1,3 +1,14 @@
+gnome-maps (3.30.3.1-1+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload
+ * New upstream release
+- Make the shape layer renderer use the tile size specified in the dynamic
+ service file, fixing an issue with misaligned shape layer (GeoJSON, GPX,
+ KML) rendering with the new 512 pixel tile
+- Update Icelandic translation
+
+ -- Phil Wyett Fri, 27 Dec 2019 09:52:18 +
+
gnome-maps (3.30.3-1) unstable; urgency=medium
* New upstream release
diff -Nru gnome-maps-3.30.3/debian/control gnome-maps-3.30.3.1/debian/control
--- gnome-maps-3.30.3/debian/control 2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/control 2019-12-27 09:52:18.0 +
@@ -6,7 +6,7 @@
Section: gnome
Priority: optional
Maintainer: Debian GNOME Maintainers
-Uploaders: Jeremy Bicha , Tim Lunn
+Uploaders: Jeremy Bicha , Michael Biebl , Tim Lunn
Build-Depends: debhelper (>= 11),
geoclue-2.0 (>= 0.12.99),
gjs (>= 1.50.0),
diff -Nru gnome-maps-3.30.3/debian/gbp.conf gnome-maps-3.30.3.1/debian/gbp.conf
--- gnome-maps-3.30.3/debian/gbp.conf 2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/gbp.conf 2019-12-27 09:52:18.0 +
@@ -1,14 +1,14 @@
[DEFAULT]
pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/buster
+upstream-branch = upstream/3.30.3.1
upstream-vcs-tag = v%(version)s
[buildpackage]
sign-tags = True
[import-orig]
-postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
+#postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
[pq]
patch-numbers = False
diff -Nru gnome-maps-3.30.3/meson.build gnome-maps-3.30.3.1/meson.build
--- gnome-maps-3.30.3/meson.build 2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/meson.build 2019-05-21 22:18:49.0 +0100
@@ -1,5 +1,5 @@
project('gnome-maps', 'c',
- version: '3.30.3',
+ version: '3.30.3.1',
license: 'GPL2+'
)
diff -Nru gnome-maps-3.30.3/NEWS gnome-maps-3.30.3.1/NEWS
--- gnome-maps-3.30.3/NEWS 2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/NEWS 2019-05-21 22:18:49.0 +0100
@@ -1,3 +1,18 @@
+3.30.3.1 - May 21, 2019
+=
+
+Changes since 3.30.3
+ - Make the shape layer renderer use the tile size specified in the dynamic
+ service file, fixing an issue with misaligned shape layer (GeoJSON, GPX, KML)
+ rendering with the new 512 pixel tiles
+
+Added/updated/fixed translations
+ - Icelandic
+
+All contributors to this release
+Marcus Lundblad
+Sveinn í Felli
+
3.30.3 - Dec 10, 2018
=
diff -Nru gnome-maps-3.30.3/po/is.po gnome-maps-3.30.3.1/po/is.po
--- gnome-maps-3.30.3/po/is.po 2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/po/is.po 2019-05-21 22:18:49.0 +0100
@@ -1,13 +1,13 @@
# Copyright (C) YEAR THE PACKAGE
Bug#956516: ImportError: cannot import name '_coin' from 'pivy'
Control: severity -1 important On Wed, Apr 22, 2020 at 08:16:29PM +0200, Steve Frécinaux wrote: > It is worth noting that this error prevents accessing the "Arch" workbench > at all. I can confirm the Arch workbench being completely unusable. Hence why I'm raising the severity from normal to important. Regards, -- Rock Storm GPG KeyID: 4096R/C96832FD signature.asc Description: PGP signature
Bug#958455: From a minimum installation of Sid, metapackage enlightenment installs neither X nor a login manager. Debian Sid, 15 april 2020
Hi Daniel, On Wed, Apr 22, 2020 at 09:18:24AM +, Daniel Tourde wrote: > I was expecting to be welcomed by a login manager but it did not happen > 'automagically', so to say. I checked and noticed that neither X nor a login > manager were installed (as it happens with Gnome, KDE, XFCE (I checked... ;) > )). Can this be fixed? Currently, enlightenment is not a metapackge as your subject says - it's a binary package for the enlightenment window manager. I don't think it's appropriate to add a Depends or Recommends on a login manager, since it's reasonable to use without. At most it might make sense to add Suggests: x-display-manager. But apt does not install Suggests by default, so you'd still need to request it manually. Would this be an improvement? > I know that 'entrance' is not considered stable/mature at the moment but I > guess an another login manager could be installed anyway, one that does not > require way too many dependencies. If entrance (or some other EFL-based login manager) were mature, I'd be tempted to add an enlightenment-desktop metapackage. But I don't think this is likely. Ross
Bug#905581: Mailing list for Salsa/Salsa-CI team
Hello! The Salsa-CI discussions still have no mailing list to go to. Could you please create a mailing list for the team now? ke 17. heinäk. 2019 klo 8.33 Otto Kekäläinen (o...@debian.org) kirjoitti: > > Hello! > > There are now 10 people discussing "Licensing salsa-ci pipeline" in > private thread that really should belong into a Debian mailing list. > > Can you please create this list now? > > If you think "debian-salsa-ci" is too small, then create a more > generic "debian-salsa" list where also other Salsa usage and > improvements can be discussed. > > - Otto -- - Otto
Bug#956959: #956959 can no longer connect after dist-upgrading server
On Thu, Apr 23, 2020 at 09:44:22AM +1000, Dmitry Smirnov wrote: >> sesse@bigscreen:~$ xpra start ssh:sgunders@10.172.139.131 --start=urxvt > I'm unable to reproduce the problem... Were you able to reproduce it on 3.0.8? (Ie., is there any reason to believe that 3.0.9 would fix this specific issue?) > Also severity is certainly less than "grave". If it can't connect anywhere, ie. completely broken, it's grave. However, if it's just broken for some suitably small set of users, it's probably important. /* Steinar */ -- Homepage: https://www.sesse.net/
