Bug#993491: grilo-plugins: Please switch to tracker 3

[Laurent Bigonville]

Source: grilo-plugins
Version: 0.3.13-2
Severity: serious
Tags: patch

Hello,

The transition to tracker 3 has begun, and grilo-plugins requires
changes to the build-dependencies to use that new version

There is already a MR proposed here:
https://salsa.debian.org/berto/grilo-plugins/-/merge_requests/2

Could you please apply that change?

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#993490: handbrake: terminates on launch, no reason given

[Rob Moss]

Package: handbrake
Version: 1.4.1+ds1-1
Severity: important
X-Debbugs-Cc: robm@gmail.com

Dear Maintainer,

I am running Debian Testing. I last used handbrake around 2 weeks ago, and it 
worked as expected.

Today, both the GTK and CLI versions terminate immediately when I launch them.

When I pass the "--debug" argument, I obtain the following output:

--
(null): create_builder_or_die()

(null): ghb_ui_update() activity_location
(null): get_setting_key ()

(null): ghb_widget_to_setting
(null): get_setting_key ()

(null): get_setting_key ()

Aborted
--

I haven't been able to identify the cause for this.

I tried downgrading to handbrake 1.4.0+ds1-2 and ffmpeg 7:4.3.2-0+deb11u2, but 
this had no effect.

All the best,
Rob

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

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

Versions of packages handbrake depends on:
ii  libass9 1:0.15.1-2
ii  libavcodec587:4.4-5
ii  libavfilter77:4.4-5
ii  libavformat58   7:4.4-5
ii  libavutil56 7:4.4-5
ii  libbluray2  1:1.3.0-3
ii  libc6   2.31-17
ii  libcairo2   1.16.0-5
ii  libdvdnav4  6.1.1-1
ii  libdvdread8 6.1.2-1
ii  libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii  libglib2.0-02.68.4-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libgtk-3-0  3.24.30-2
ii  libgudev-1.0-0  237-2
ii  libjansson4 2.13.1-1.1
ii  libmfx1 21.1.0-1
ii  libpango-1.0-0  1.48.9+ds1-2
ii  libswresample3  7:4.4-5
ii  libswscale5 7:4.4-5
ii  libtheora0  1.1.1+dfsg.1-15
ii  libturbojpeg0   1:2.0.6-4
ii  libva-drm2  2.12.0-2
ii  libva2  2.12.0-2
ii  libvorbis0a 1.3.7-1
ii  libvorbisenc2   1.3.7-1
ii  libx264-160 2:0.160.3011+gitcde9a93-2.1
ii  libx265-192 3.4-2
ii  libxml2 2.9.10+dfsg-6.7

Versions of packages handbrake recommends:
ii  gstreamer1.0-libav   1.18.4-3
ii  gstreamer1.0-pulseaudio  1.18.4-2
ii  gstreamer1.0-x   1.18.4-2

handbrake suggests no packages.

-- no debconf information

Bug#944208: thunderbird warns addMetadata: Add-on wetrans...@extensions.thunderbird.net is invalid (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)

[Carsten Schoenert]

Version: 1:91.0-1

Hello Daniel,

this report should have been closed by the upload of 1:91.0-1 but this
hasn't worked.
The wetransfer AddOn isn't part of Thunderbird upstream any more so I'll
close this report now.

Regards
Carsten

Am Tue, Nov 05, 2019 at 06:10:20PM -0500 schrieb Daniel Kahn Gillmor:
> Control: affects 944208 + src:enigmail
> 
> This produces noise on the enigmail test suite, so i'm marking it as
> "affects" enigmail.
> 
> On Tue 2019-11-05 18:01:16 -0500, Daniel Kahn Gillmor wrote:
> > When trying to set up a temporary testing profile with thunderbird on an
> > otherwise clean system, that i want to not access the network, i see
> > nasty error messages on stderr:
> 
> An even simpler reproducer to generate the warnings:
> 
> x=$(mktemp -d profdir.XX)
> printf 'user_pref("browser.dom.window.dump.enabled", true);\n' > 
> "$x/prefs.js"
> thunderbird --headless --profile "$(pwd)/$x"
> 
> hope this is useful,
> 
>  --dkg

Bug#976246: dpkg-source: Reference detection of native vs non-native source package type

[Anatoli Babenia]

Hello.

> > It would help greatly if `dpkg-source` reported native or non-native
> > package type.
> >
> > -dpkg-source: info: using source format '1.0'
> > +dpkg-source: info: using non-native source format '1.0'
>
> While I think something like this would be nice, unfortunately I'm afraid
> this cannot be done right now, because there are still package at least
> in Debian that have a mismatched version format compared to their source
> format.

In that case `dpkg-source` could throw a warning about ambiguity.

> > It would be nice to see a reference algorithm that detects different package
> > types. It would help people like me to troubleshoot issues with Debian
> > packaging faster.
>
> It would be nice, and I've been trying to get there, but see above.

I still don't see why `dpkg-source` should not produce helpful messages
while there are some other packages that fail validation.

Bug#992829: spamassassin: "spamassassin -r" fails with permission problem

[Francois Marier]

On 2021-08-23 at 17:14:05, Noah Meyerhans (no...@debian.org) wrote:
> What happens if you pipe message content to spamassassin from your
> shell, outside mutt?

I've attached the result of piping your message to spamassassin in this way:

  cat msg  | spamassassin -r -D > spamassassin.out 2>&1

>From what I can see, $HOME is set correctly, but perhaps the permissions on
/var/lib/spamassassin are the source of the problem given that I'm running
the spamassassin binary as the "francois" user?

  $ ls -ld /var/lib/spamassassin
  drwxr-x--- 8 debian-spamd debian-spamd 4,0K  4 jun 10:36 
/var/lib/spamassassin/

In the last week, I've certainly noticed that SpamAssassin is letting tons
of spam through. Maybe because everything ends up triggering BAYES_00?

Francois

-- 
https://fmarier.org/
Sep  1 21:55:07.796 [320717] dbg: logger: adding facilities: all
Sep  1 21:55:07.796 [320717] dbg: logger: logging level is DBG
Sep  1 21:55:07.796 [320717] dbg: generic: SpamAssassin version 3.4.6
Sep  1 21:55:07.796 [320717] dbg: generic: Perl 5.032001, PREFIX=/usr, 
DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin, 
LOCAL_STATE_DIR=/var/lib/spamassassin
Sep  1 21:55:07.797 [320717] dbg: config: timing enabled
Sep  1 21:55:07.797 [320717] dbg: config: score set 0 chosen.
Sep  1 21:55:07.798 [320717] dbg: util: running in taint mode? yes
Sep  1 21:55:07.798 [320717] dbg: util: taint mode: deleting unsafe environment 
variables, resetting PATH
Sep  1 21:55:07.798 [320717] dbg: util: PATH included '/home/francois/bin', 
keeping
Sep  1 21:55:07.798 [320717] dbg: util: PATH included 
'/home/francois/devel/remote/user-scripts', keeping
Sep  1 21:55:07.798 [320717] dbg: util: PATH included '/usr/lib/ccache', keeping
Sep  1 21:55:07.798 [320717] dbg: util: PATH included '/home/francois/bin', 
keeping
Sep  1 21:55:07.798 [320717] dbg: util: PATH included '/usr/share/safe-rm/bin', 
keeping
Sep  1 21:55:07.798 [320717] dbg: util: PATH included '/usr/local/bin', keeping
Sep  1 21:55:07.798 [320717] dbg: util: PATH included '/usr/bin', keeping
Sep  1 21:55:07.798 [320717] dbg: util: PATH included '/bin', keeping
Sep  1 21:55:07.799 [320717] dbg: util: PATH included '/usr/local/games', which 
is unusable, dropping: No such file or directory
Sep  1 21:55:07.799 [320717] dbg: util: PATH included '/usr/games', keeping
Sep  1 21:55:07.799 [320717] dbg: util: final PATH set to: 
/home/francois/bin:/home/francois/devel/remote/user-scripts:/usr/lib/ccache:/home/francois/bin:/usr/share/safe-rm/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
Sep  1 21:55:07.802 [320717] dbg: util: secure_tmpfile created a temporary file 
/tmp/user/1000/.spamassassin320717yllOW5tmp
Sep  1 21:55:07.802 [320717] dbg: archive-iterator: 
_set_default_message_selection_opts After: Scanprob[1], want_date[0], cache[0], 
from_regex[^From \S+ ?(\S\S\S \S\S\S .?\d .?\d:\d\d:\d\d 
\d{4}|.?\d-\d\d-\d{4}_\d\d:\d\d:\d\d_)]
Sep  1 21:55:07.802 [320717] warn: config: path 
"/var/lib/spamassassin/3.004006" is inaccessible: Permission denied
Sep  1 21:55:07.802 [320717] dbg: config: using "/etc/spamassassin" for site 
rules pre files
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/init.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file 
/etc/spamassassin/sa-compile.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v310.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v312.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v320.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v330.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v340.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v341.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v342.pre
Sep  1 21:55:07.803 [320717] dbg: config: read file /etc/spamassassin/v343.pre
Sep  1 21:55:07.803 [320717] dbg: config: using "/usr/share/spamassassin" for 
sys rules pre files
Sep  1 21:55:07.804 [320717] dbg: config: using "/usr/share/spamassassin" for 
default rules dir
Sep  1 21:55:07.804 [320717] dbg: config: read file 
/usr/share/spamassassin/10_default_prefs.cf
Sep  1 21:55:07.804 [320717] dbg: config: read file 
/usr/share/spamassassin/10_hasbase.cf
Sep  1 21:55:07.804 [320717] dbg: config: read file 
/usr/share/spamassassin/20_advance_fee.cf
Sep  1 21:55:07.804 [320717] dbg: config: read file 
/usr/share/spamassassin/20_aux_tlds.cf
Sep  1 21:55:07.805 [320717] dbg: config: read file 
/usr/share/spamassassin/20_body_tests.cf
Sep  1 21:55:07.805 [320717] dbg: config: read file 
/usr/share/spamassassin/20_compensate.cf
Sep  1 21:55:07.805 [320717] dbg: config: read file 
/usr/share/spamassassin/20_dnsbl_tests.cf
Sep  1 21:55:07.805 [320717] dbg: config: read file 
/usr/share/spamassassin/20_drugs.cf
Sep  1 21:55:07.805 [320717] dbg: config: read file 
/usr/share/spamassassin/20_dynrdns.cf
Sep  1 21:55:07.805 [320717] 

Bug#993489: bullseye-pu: package cyrus-imapd/3.2.6-2+deb11u1

[Yadd]

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

[ Reason ]
cyrus-imapd before 3.2.8 allows remote attackers to cause a denial of
service (multiple-minute daemon hang) via input that is mishandled
during hash-table interaction. Because there are many insertions into
a single bucket, strcmp becomes slow. This is fixed in 3.4.2, 3.2.8,
and 3.0.16.

[ Impact ]
Medium vulnerability

[ Tests ]
The new cunit/strhash.testc passed.

[ Risks ]
Low risk, patch is easy to read

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
New string hashing algorithm and test.

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index c8259297..bd11af8d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cyrus-imapd (3.2.6-2+deb11u1) bullseye; urgency=medium
+
+  * Replace string hashing algorithm (Closes: #993433, CVE-2021-33582)
+
+ -- Yadd   Wed, 01 Sep 2021 07:58:38 +0200
+
 cyrus-imapd (3.2.6-2) unstable; urgency=medium
 
   * Update gbp.conf for Bullseye branch
diff --git a/debian/control b/debian/control
index 3a4556b0..9b31670e 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Maintainer: Debian Cyrus Team 
 Uploaders: Henrique de Moraes Holschuh ,
Ondřej Surý ,
Anthony Prades ,
-   Xavier Guimard 
+   Yadd 
 Section: mail
 Priority: optional
 Build-Depends: bison,
diff --git a/debian/patches/CVE-2021-33582.patch 
b/debian/patches/CVE-2021-33582.patch
new file mode 100644
index ..af48b338
--- /dev/null
+++ b/debian/patches/CVE-2021-33582.patch
@@ -0,0 +1,632 @@
+Description: Fixed CVE-2021-33582
+ Certain user inputs are used as hash table keys during processing. A
+ poorly chosen string hashing algorithm meant that the user could control
+ which bucket their data was stored in, allowing a malicious user to direct
+ many inputs to a single bucket. Each subsequent insertion to the same bucket
+ requires a strcmp of every other entry in it. At tens of thousands of
+ entries, each new insertion could keep the CPU busy in a strcmp loop for
+ minutes.
+ .
+ The string hashing algorithm has been replaced with a better one, and now
+ also uses a random seed per hash table, so malicious inputs cannot be
+ precomputed.
+ .
+ Discovered by Matthew Horsfall, Fastmail
+Author: ellie timoney 
+Origin: upstream, 
https://github.com/cyrusimap/cyrus-imapd/compare/cyrus-imapd-3.2.7...cyrus-imapd-3.2.8
+Bug: https://security-tracker.debian.org/tracker/CVE-2021-33582
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-09-01
+
+--- a/Makefile.am
 b/Makefile.am
+@@ -677,6 +677,7 @@
+   cunit/squat.testc \
+   cunit/strarray.testc \
+   cunit/strconcat.testc \
++  cunit/strhash.testc \
+   cunit/times.testc \
+   cunit/tok.testc \
+   cunit/vparse.testc
+--- a/configure.ac
 b/configure.ac
+@@ -191,7 +191,7 @@
+ 
+ AC_CHECK_HEADERS(unistd.h sys/select.h sys/param.h stdarg.h)
+ AC_REPLACE_FUNCS(memmove strcasecmp ftruncate strerror posix_fadvise strsep 
memmem memrchr)
+-AC_CHECK_FUNCS(strlcat strlcpy strnchr getgrouplist fmemopen pselect futimens 
futimes)
++AC_CHECK_FUNCS(strlcat strlcpy strnchr getgrouplist fmemopen pselect futimens 
futimes getline)
+ AC_HEADER_DIRENT
+ 
+ dnl check whether to use getpassphrase or getpass
+--- a/cunit/hash.testc
 b/cunit/hash.testc
+@@ -117,6 +117,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(0, count);
+ 
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(0, hash_numrecords());
++
+ /* free the hash table */
+ free_hash_table(, NULL);
+ }
+@@ -146,6 +149,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(1, count);
+ 
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(1, hash_numrecords());
++
+ /* re-insert into the hash table */
+ d = hash_insert(KEY0, VALUE1, );
+ /* get the old value back */
+@@ -160,6 +166,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(1, count);
+ 
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(1, hash_numrecords());
++
+ /* delete from the hash table */
+ d = hash_del(KEY0, );
+ CU_ASSERT_PTR_EQUAL(VALUE1, d);
+@@ -173,6 +182,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(0, count);
+ 
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(0, hash_numrecords());
++
+ /* free the hash table */
+ free_hash_table(, NULL);
+ }
+@@ -239,6 +251,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(N, count);
+ 
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(N, hash_numrecords());
++
+ /* delete from the hash table */
+ for (i = 0 ; i < N ; i++) {
+ d = hash_del(key(i), );
+@@ -256,6 +271,9 @@
+ hash_enumerate(, count_cb, );
+ 

Bug#993488: security-tracker: Revoked group permission on a user continue to take effect on all existing processes and sessions

[xuancong84]

Package: security-tracker
Severity: important
Tags: security

Dear Debian security team,

This bug deals with the lower framework of Linux/Debian system, it affects at
least all debian-based Linux Distros like Ubuntu, MX-Linux, etc.

Steps to reproduce:
1. create a new group called secure01
addgroup secure01

2. create files that are only accessible by the group
mkdir /mnt/secure-folder
echo yes >/mnt/secure-folder/secure-file
chown -R root:secure01 /mnt/secure-folder/
chmod -R o-rwx /mnt/secure-folder

3. add an existing user into the group
usermod -a -G secure01 user01

BUG1:
if user01 is already logged in, he still cannot access /mnt/secure-
folder/secure-file
ls: cannot open directory '/mnt/secure-folder/': Permission denied

4. del the user from the group
gpasswd -d user01 secure01

BUG2:
if user01 is already logged in or it has running tmux/screen sessions, he still
can access that group's /mnt/secure-folder/secure-file
user01@local:~$ cat /mnt/secure-folder/secure-file
yes


This bug is significant for a multi-user secure Linux environment. In a secure
network cluster, new data files are often dynamically added into the system
with new group permissions created, and some users are added into the group or
removed from the group depending on role change, task change, etc. However, the
changed permission does not reflect immediately on all the running processes
belonging to that user.

As a result, a user can have a persistent tmux/screen session (that does not go
away unless reboot) to continue to access group files he can access before,
even though his access permission has been revoked now.



-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.57 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[jiho lee]

Hello,

Thank you for your hard work on shutter packaging.

As I sent you earlier, gir1.2-appindicator3-0.1 has been removed from
Debian Bullseye, so a replacement package is needed.

I looked up the Debian package and found gir1.2-ayatanaappindicator3-0.1,
so I asked the shutter team if this package was available and they got a
patch.

The patch contents are at the following URL:

https://github.com/shutter-project/shutter/commit/27935490c32a35acea9f60629593a883b1a39faa

Sorry for just uploading a new shutter to the repository, but the
gir1.2-appindicator3-0.1 package is no longer maintained after Debian 10,
so instead of the gir1.2-appindicator3-0.1 package, update the dependencies
to gir1.2-ayatanaappindicator3-0.1 You need to change it.

In addition, the shutter team is introducing gir1.2-appindicator3-0.1
(gir1.2-ayatanaappindicator3-0.1 on debian 11 and ubuntu 21.04, etc.) as an
optional package.

Accordingly, in the debian/control file of the Debian shutter, please
consider removing gir1.2-appindicator3-0.1 from depends and separating it
with suggest, etc.

We apologize for not being careful in advance and disrupting packaging.


There is a future society, but my future is not what others do.
Dept. of Information Science, Graduate School, Korea National Open
University


2021년 9월 1일 (수) 오후 10:50, Andrej Shadura 님이 작성:

> Control: tag -1 pending
>
> Hi,
>
> FYI I have uploaded shutter to NEW yesterday.
>
> --
> Cheers,
>   Andrej
>

Bug#993458: The obs-studio downloaded as apt source fails to package.

[jiho lee]

Thanks it worked out well.

libsndio-dev was specified as a package that the installed libsdl2-dev
depended on to compile ffmpeg.

This problem was discovered while packaging ffmpeg first and then packaging
obs-studio to add nvenc support to obs-studio.

Even in Debian Buster, after ffmpeg packaging to add nvenc support to
obs-studio, I was puzzled because there has never been a problem with the
libsndio-dev package during the obs-studio packaging process.

Why did obs-studio have a problem with the libsndio-dev package in the
process of upgrading from Debian Buster to Bullseye?

A set of problems have been solved, but for someone like me who wants to
compile ffmpeg and obs-studio sequentially, this problem seems to need a
separate guide (whether wiki or source package).


There is a future society, but my future is not what others do.
Dept. of Information Science, Graduate School, Korea National Open
University


2021년 9월 2일 (목) 오전 2:36, Sebastian Ramacher 님이 작성:

> Control: tags -1 moreinfo
>
> On 2021-09-02 01:43:08 +0900, jiho lee wrote:
> > Package: obs-studio
> > Version: 26.1.2+dfsg1-2
> >
> > Hello.
> >
> > This time, I downloaded obs-studio from Debian bullseye with the apt
> > source command and tried to package it with the debuild command, but a
> > dh_missing error occurs.
> >
> > System: Debian Bullseye
> > Platform: x86_64
> > Commands:
> > sudo apt build-dep obs-studio
> > debuild -us -uc -b
> >
> > Expected Result:
> > You must have a packaged deb file.
> >
> > Failed Result:
> >dh_strip_nondeterminism
> >dh_compress
> >dh_fixperms
> >dh_missing
> > dh_missing: warning: usr/lib/x86_64-linux-gnu/obs-plugins/sndio.so
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ar-SA.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ca-ES.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/cs-CZ.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/da-DK.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/de-DE.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/el-GR.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/en-GB.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/en-US.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/es-ES.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/et-EE.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fa-IR.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fi-FI.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fr-FR.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/gl-ES.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/hu-HU.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/id-ID.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/it-IT.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ja-JP.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ka-GE.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning:
> > usr/share/obs/obs-plugins/sndio/locale/kab-KAB.ini exists in
> > debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ko-KR.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/nl-NL.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pl-PL.ini
> > exists in debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pt-BR.ini
> > exists in debian/tmp but is not 

Bug#993487: libguestfs-tools: virt-sparsify fails to pass necessary arguments to qemu-img

[Norbert Preining]

Package: libguestfs-tools
Version: 1:1.44.1-2
Severity: important


virt-sparsify in.qcow2 out.qcow2 now is broken:

debugging it gives:

libguestfs: trace: disk_create "/tmp/sparsify4e60f4.qcow2" "qcow2" -1 
"backingfile:/var/lib/libvirt/images/FujitsuWin10v2.qcow2" "compat:1.1"
libguestfs: command: run: qemu-img
libguestfs: command: run: \ create
libguestfs: command: run: \ -f qcow2
libguestfs: command: run: \ -o 
backing_file=/var/lib/libvirt/images/FujitsuWin10v2.qcow2,compat=1.1
libguestfs: command: run: \ /tmp/sparsify4e60f4.qcow2
qemu-img: /tmp/sparsify4e60f4.qcow2: Backing file specified without backing 
format
Detected format of qcow2.libguestfs: trace: disk_create = -1 (error)

and even if I add
-o backing_fmt=qcow
it does not work since the option is not passed to qemu-img, despite
what the man page says.

Best



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

Kernel: Linux 5.13.13+futex+ (SMP w/8 CPU threads)
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
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libguestfs-tools depends on:
ii  curl   7.74.0-1.3+b1
ii  libc6  2.31-17
ii  libconfig9 1.5-0.4
ii  libcrypt1  1:4.4.25-1
ii  libfuse2   2.9.9-5
ii  libguestfs-perl1:1.44.1-2
ii  libguestfs01:1.44.1-2
ii  libintl-perl   1.26-3
ii  libjansson42.13.1-1.1
ii  liblzma5   5.2.5-2
ii  libpcre3   2:8.39-13
ii  libreadline8   8.1-2
ii  libstring-shellquote-perl  1.04-1
ii  libsys-virt-perl   7.5.0-1
ii  libtinfo6  6.2+20201114-4
ii  libtirpc3  1.3.2-2
ii  libvirt0   7.6.0-1
ii  libwin-hivex-perl  1.3.21-1
ii  libxml22.9.12+dfsg-3

Versions of packages libguestfs-tools recommends:
ii  gnupg 2.2.27-2
ii  virt-p2v  1.42.0-3

libguestfs-tools suggests no packages.

-- no debconf information

Bug#993486: ITP: mirrorrib -- tool locally to mirror a Debian release, including backports

[Thaddeus H. Black]

Package: wnpp
Severity: wishlist
Owner: "Thaddeus H. Black" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mirrorrib
  Version : 0.14.4
  Upstream Author : Thaddeus H. Black 
* URL : https://www.derivations.org/mirrorrib/
* License : GPL-2
  Programming Lang: Shell (bash)
  Description : tool locally to mirror a Debian release, including backports

Debian releases a major revision of its operating system about every
two years and a minor revision approximately quarterly, but these
revisions exclude Debian backports.  Debian releases backports only on
a rolling basis like sid.

Mirrorrib is for Debian users who want an approximately quarterly,
stable revision of backports to accompany the approximately quarterly,
stable revision of the rest of the operating system -- with both
revisions dated as of the same date.

Mirrorrib reproducibly assembles a stable backports revision and
release to accompany a stable regular revision and release.  It
downloads the matched pair of releases with all their packages and
associated files, mirroring the pair together to your hard drive.
After running Mirrorrib and configuring /etc/apt/sources.list to
access the local repository Mirrorrib has assembled, one no longer
needs a live network connection to update or reinstall one's system to
Debian stable -- not even if the update or reinstallation requires
access to backports.

Mirrorrib's name stands for "MIRROR Release Including Backports."

I will maintain the package.  No sponsor is needed.  Because the
software is Debian-specific and is useful only to users of Debian, the
package is a Debian-native package.

Bug#976246: dpkg-source: Reference detection of native vs non-native source package type

[Guillem Jover]

Hi!

On Wed, 2020-12-02 at 07:16:52 +0300, Anatoli Babenia wrote:
> Package: dpkg-dev
> Version: 1.19.7
> Severity: normal
> File: /usr/bin/dpkg-source

> It would help greatly if `dpkg-source` reported native or non-native
> package type.
> 
> -dpkg-source: info: using source format '1.0'
> +dpkg-source: info: using non-native source format '1.0'

While I think something like this would be nice, unfortunately I'm afraid
this cannot be done right now, because there are still package at least
in Debian that have a mismatched version format compared to their source
format. See:

  

For most of which I've filed bug reports, see:

  


Unfortunately there are a couple of maintainers that refuse to fix these
problems, so we cannot currently have coherent semantics. :(

> There is no information about native vs non-native format in this wiki page
> https://wiki.debian.org/Packaging/SourcePackage
> 
> Mentors FAQ explains it in a lot of detail, but still hard to understand.
> https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_
> package_and_a_non-native_package.3F

The dpkg-source man page contains documentation about the various
formats:

  

> `dpkg-source` code does explain the logic either. Detection of source format
> relies on checking command line flags, and it does not make sense to me.
> 
> my $v = Dpkg::Version->new($self->{fields}->{'Version'});
> if ($sourcestyle =~ m/[kpursKPUR]/) {
> error(g_('non-native package version does not contain a revision'))
> if $v->is_native();
> } else {
> # FIXME: This will become fatal in the near future.
> warning(g_('native package version may not have a revision'))
> unless $v->is_native();
> }
> 
> https://salsa.debian.org/dpkg-team/dpkg/-/blob/09c9e02046f18f02bf3c3c2533bc557abfdc828c/scripts/Dpkg/Source/Package/V1.pm#L355
> 
> It would be nice to see a reference algorithm that detects different package
> types. It would help people like me to troubleshoot issues with Debian
> packaging faster.

It would be nice, and I've been trying to get there, but see above.

Thanks,
Guillem

Bug#993485: apt-listchanges: add option to show only changes since a date: --from 2021-01-01

[Paul Wise]

Package: apt-listchanges
Version: 3.24
Severity: wishlist
X-Debbugs-CC: Sean Whitton 

Sean's blog post indicates a need in some cases to add an option to
show only changes since a date specified by the user, like this:

   apt-listchanges --from 2021-01-01

https://spwhitton.name//blog/entry/posthoc-apt-listchanges/

This would complement the existing options for showing changes since a
version and the latest N number of changes.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#984849: dpkg-divert: too sensitive to order of command-line args

[Guillem Jover]

Hi!

On Mon, 2021-03-08 at 22:35:49 -0800, Ross Vandegrift wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: wishlist
> X-Debbugs-Cc: rvandegr...@debian.org
> 
> dpkg-divert is too sensitive to the order of the command line parameters.
> Since I only use it rarely, I almost always run into:
> 
>   # dpkg-divert --add /wooo --divert /yeah --rename
>   dpkg-divert: warning: please specify --no-rename explicitly, the default 
> will change to --rename in 1.20.x
>   dpkg-divert: error: --add needs a single argument
>   
>   Use --help for help about diverting files.
> 
> The fix is to move --add last.  But neither the error nor the manpage makes
> that clear.

Both the man page and the --help output mention that the usage is:

  dpkg-divert [...] 

And then go to list the commands and options on their respective
sections. While I guess I could add a hint or similar on the error
message (because modifying the way this is parsed would be a pain),
that seems it would be too specific for such a generic message. So
I'm inclined to leave it as is, TBH. If you have an alternative
suggestion I'm happy to consider, otherwise I'm afraid I'll just
going to close the report.

Thanks,
Guillem

Bug#871420: dpkg(1) manpage path-exclude docs possible license issue

[Guillem Jover]

Control: severity -1 minor
Control: retitle -1 dpkg: Man page not clear on re-inclusion behavior

Hi!

On Mon, 2017-08-07 at 15:26:36 -0500, Adam Heath wrote:
> package: dpkg
> version: 1.17.27
> 
> In the manpage for dpkg, there is an example for path-exclude/path-include:
> 
> ==
> --path-exclude=/usr/share/doc/*
> --path-include=/usr/share/doc/*/copyright
> ==
> 
> These 2 patterns will end up skipping packages that have
> /usr/share/doc/$foo as a symlink to another package.  Which means
> things like perl-base, libstdc++6, libgcc1, etc, which have their docs
> symlinked to another package from the same source, will be broken, as
> the copyright for the package is not available at
> /usr/share/doc/$pkg/copyright, as *required* by policy.

Policy requires shipping these files in the packages, it does not
require them to be present on the user filesystem. It also mentions
in §12.3 that no package can expect the existence of any files under
/usr/share/doc, which I've always understood as allowing local admins
to remove the entire hierarchy w/o consequence.

> Perhaps --path-exclude=/usr/share/doc/*/*, with the same include,
> might be better.

This is not necessary, as the current implementation will reinclude
any directory or symlink to a directory when there's a more specific
path reinclusion. This was already mentioned, but not directly, so
I've further clarified this behavior now in the man page and will be
included in the next release.

Thanks,
Guillem

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Hideki Yamane]

Hi,

On Wed, 01 Sep 2021 07:46:07 -0700
Russ Allbery  wrote:
> >> I believe that the discussion has later identified that doing so would
> >> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> >> security benefits are not strong (beyond embracing good habits), I
> >> think the reasonable thing to do is keep preferring http.
> 
> > That is an opt-in choice which likely only a small number of users use.
> > People wanting to use a caching proxy can just switch to http as part of
> > this choice; it doesn't seem a good reason to not use https by default
> > for all other users.
> 
> Completely agreed.

 Providing "default secure setting" is good message to users.


 Some users want proxy but they can configure their settings.
 So just change "default setting for {deb,security}.debian.org"
 is not so harmful, IMO. 

 - Users can choose other mirror than https://deb.debian.org
 - Caching .debs from security.debian.org is not so huge, I guess
   (maybe except linux-image).


-- 
Hideki Yamane 

Bug#993479: ITP: go-control-plane -- Go implementation of data-plane-api

[srud]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : go-control-plane
Version : 0.9.9
Upstream Author : Envoy Proxy - CNCF
* URL : https://github.com/envoyproxy/go-control-plan
* License : Apache-2.0
Description : Go implementation of data-plane-api (program)

This is a Go-based implementation of an API server
that implements the discovery service APIs defined in data-plane-api
(https://github.com/envoyproxy/data-plane-api). Due to the
variety of platforms out there, there is no single control plane
implementation that can satisfy everyone's needs. Hence this code
base does not attempt to be a full scale control plane for a fleet
of Envoy proxies. Instead, it provides infrastructure that is shared
by multiple different control plane implementations.

Bug#993476: inetutils: security bug in ftp client

[Simon Josefsson]

Package: inetutils-ftp

Hi!  Just to let you know that inetutils 2.2 contains a fix for
long-standing security bug, a patch that should apply to earlier
versions:

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=58cb043b190fd04effdaea7c9403416b436e50dd

See bug report with plenty of links to earlier similar issues in other
ftp clients:

https://lists.gnu.org/archive/html/bug-inetutils/2021-06/msg2.html

/Simon


signature.asc
Description: PGP signature

Bug#960883: FBZX is out of date

[Steve Clark]

FBZX is getting further out of date.
Current version in Bullseye has not changed since Buster.

Latest version upstream is now 4.8.0

Bug#871494: dpkg-genbuildinfo: Include crossbuild-essential-ARCH when cross-building

[Guillem Jover]

Hi!

[ Sorry I thought I had replied to this, but it seems I only did on my
  head… :/ ]

On Tue, 2017-08-08 at 09:20:32 -0400, Vagrant Cascadian wrote:
> Package: dpkg-dev
> Severity: wishlist
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

> When I've crossbuilt packages such as u-boot for the armhf architecture,
> I've noticed there there's no mention of crossbuild-essential-armhf or
> gcc-arm-linux-gnueabihf in Installed-Build-Depends in the buildinfo, but
> in reality these are the primary tools used to cross-build u-boot.
> 
> If BUILD_PROFILES includes "cross" and/or the Architecture and
> Build-Architecture do not match (except for Architecture: all or
> Architecture: source builds), it seems like it would be appropriate to
> treat crossbuild-essential-ARCH similarly to build-essential, including
> it's dependencies in Installed-Build-Depends.
> 
> Sbuild automatically installs crossbuild-essential-ARCH when it detects
> that you are cross-building.

Right, currently the cross-building support in dpkg-dev is a bit
lacking. That needs overall improvement. Regarding the cross
build-essential, the main reason I've not added these
crossbuild-essential packages is that they are a hack that should be
replaced by proper build-essential multi-arch packages, but AFAIR
that's blocked on the introduction of packages such as gcc-for-host
and gcc-for-build and similar. My concern has been that adding support
for these would legitimize them and ossify that support. With the
understanding, of course, that this is currently somewhat counter
productive.

Thanks,
Guillem

Bug#993338: octave: Setting up octave fails due to missing libGL.so.1

[Witold Baryluk]

Package: octave
Version: 6.2.0-1
Followup-For: Bug #993338
X-Debbugs-Cc: witold.bary...@gmail.com

Looking more detailed in the live-builds / dpkg logs, and checking
dependencies, it is actually not issue with dpkg or octave.

The libgl1 is fully unpacked and configured before octave postinst is
called.

I suspect `ldconfig` is not run properly in libgl1, or not triggered by
dpkg between libgl1 postinst and octave postinst.

Bug#979041: libopempi3: aborts python code due to libfabric fork() issues

[Lucas Nussbaum]

reopen 979041
notfixed 979041 4.1.0-7
thanks

Hi,

I ran into this problem with 4.1.0-7. The ofi BTL was disabled, but not
the ofi MTL. In some cases, both need to be disabled.

You need something like:
mtl = ^ofi
in addition to:
btl = ^ofi

(I ran into this with https://github.com/LLNL/mpiGraph and
libhwloc-contrib-plugins, and CUDA installed -- let me know if you need
help reproducing)

Lucas

Bug#993380: [pkg-lxc-devel] Bug#993380: lxc FTCBFS: compilation error in non-default code path

[Pierre-Elliott Bécue]

Helmut Grohne  writes:

> Source: lxc
> Version: 1:4.0.10-1
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> lxc used to cross build successfully, but no longer does. A build
> includes the following snippet:
>
> | libtool: compile:  powerpc64le-linux-gnu-gcc -DHAVE_CONFIG_H -I. 
> -I../../src -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPIC -Wvla -std=gnu11 
> -fms-extensions -fdiagnostics-color -Wimplicit-fallthrough=5 -Wcast-align 
> -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection 
> -fstack-protector-strong --param=ssp-buffer-size=4 -g 
> -Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs 
> -Wold-style-definition -Winit-self -Wunused-but-set-variable -Wfloat-equal 
> -Wsuggest-attribute=noreturn -Werror=return-type 
> -Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels 
> -Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow 
> -Werror=shift-overflow=2 -Wdate-time -Wnested-externs 
> -fasynchronous-unwind-tables -pipe -fexceptions -Warray-bounds -Wrestrict 
> -Wreturn-local-addr -Wstringop-overflow 
> -DLXCROOTFSMOUNT=\"/usr/lib/powerpc64le-linux-gnu/lxc/rootfs\" 
> -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/etc/lxc/lxc.conf\" 
> -DLXCINITDIR=\"/usr/libexec\" -DLIBEXECDIR=\"/usr/libexec\" 
> -DLXCTEMPLATEDIR=\"/usr/share/lxc/templates\" 
> -DLXCTEMPLATECONFIG=\"/usr/share/lxc/config\" -DLOGPATH=\"/var/lib/lxc\" 
> -DLXC_DEFAULT_CONFIG=\"/etc/lxc/default.conf\" 
> -DLXC_USERNIC_DB=\"/run/lxc/nics\" 
> -DLXC_USERNIC_CONF=\"/etc/lxc/lxc-usernet\" -DDEFAULT_CGROUP_PATTERN=\"\" 
> -DRUNTIME_PATH=\"/run\" -DSBINDIR=\"/usr/sbin\" 
> -DAPPARMOR_CACHE_DIR=\"/var/cache/lxc/apparmor\" -I ../../src -I 
> ../../src/lxc -I ../../src/lxc/storage -I ../../src/lxc/cgroups 
> -DHAVE_APPARMOR -DHAVE_SECCOMP -DHAVE_SELINUX -DUSE_CONFIGPATH_LOGS -pthread 
> -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wvla -std=gnu11 -fms-extensions -Werror -c criu.c  
> -fPIC -DPIC -o .libs/liblxc_la-criu.o
> | In file included from criu.c:22:
> | criu.c: In function ‘exec_criu’:
> | log.h:378:2: error: ‘%s’ directive argument is null 
> [-Werror=format-overflow=]
> |   378 |  LXC_ERROR(, format, ##__VA_ARGS__);   \
> |   |  ^~
> | log.h:459:3: note: in expansion of macro ‘ERROR’
> |   459 |   ERROR("%s - " format, ptr, ##__VA_ARGS__); \
> |   |   ^
> | log.h:493:3: note: in expansion of macro ‘SYSERROR’
> |   493 |   SYSERROR(format, ##__VA_ARGS__);  \
> |   |   ^~~~
> | criu.c:324:11: note: in expansion of macro ‘log_error_errno’
> |   324 |return log_error_errno(-ENOMEM, ENOMEM, "Failed to remove 
> extraneous slashes from \"%s\"", tmp);
> |   |   ^~~
> | cc1: all warnings being treated as errors
> | make[4]: *** [Makefile:4606: liblxc_la-criu.lo] Error 1
>
> Notably, this is not reproducible in a native build. Closer inspection
> reveals that the faulty code is in a code path conditional to
> !HAVE_M_FORMAT. That conditional is determined using AC_RUN_IFELSE
> (because it determines a runtime property of the C library) and happens
> to default to false during cross compilation. So on native glibc builds,
> HAVE_M_FORMAT is true, but everywhere else it is false. Since it is
> normally true, the other code path is untested and fails.
>
> There are two notable methods to improve the situation. One is providing
> a cache variable using AC_CACHE_CHECK. Doing so allows cross builders to
> provide a result for this check as it is not otherwise testable in cross
> builds. Another would be improving the defaults to just assume that %m
> works on glibc when the test cannot be performed for cross building.
> Finally, the !HAVE_M_FORMAT code path can be fixed.
>
> As it is not obvious which route you want to take, I'm not including a
> patch here. Rather, you have a detailed analysis with multiple options
> to proceed. If you indicate a preference, I can turn it into a patch. Or
> you simply fix it as it is not that difficult once the issue is
> understood.

Dear Helmut,

Thanks for your report and analysis. I admit I have not much time to
dive in the code and write the appropriate fix. Furthermore I guess it'd
be better if upstream fixed the issue.

Would you like me to forward the bug to their github issue tracker? If
you prefer I'm eager to do it. But to be honest, as you did the work, I
would prefer if you handled it, opening an issue on
https://github.com/lxc/lxc/issues .

If in your opinion there would be a preferred way to fix, please do
offer a patch! :)

Tell me what you'd prefer to do.

Thanks a lot!
--
PEB


signature.asc
Description: PGP signature

Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

[Roger Lynn]

On Wed, 25 Aug 2021 08:07:48 +0200 Heiner Kallweit  
wrote:

A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in 
the PHY
reporting an invalid PHY ID. Realtek / Gigabyte don't release errata 
information,
therefore there's not much that can be done. In bugzilla.kernel.org you can find
workarounds that helped for some users, else use the r8168 driver.


In https://bugzilla.kernel.org/show_bug.cgi?id=207203 it was suggested to 
enable the boot ROM in the BIOS and/or reinsert the r8169 kernel module. 
Neither of these worked for me. Fortunately the r8168-dkms package does 
work. Thank you for the suggestion, as I was not aware of this driver.


Roger

Bug#922545: [pkg-lxc-devel] Bug#922545: Bug#922545: lxc: FTBFS on hppa - symbol mismatch

[Pierre-Elliott Bécue]

John David Anglin  writes:

> On 2019-02-19 4:54 a.m., Pierre-Elliott Bécue wrote:
>> I'll need more information to action your bug.
> With 1:4.0.10-1, the only missing symbol is lxc_log_category_seccomp@Base 
> 1:3.0.2.
>
> dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
> file: see diff output below
> dpkg-gensymbols: warning: debian/liblxc1/DEBIAN/symbols doesn't match 
> completely debian/liblxc1.symbols
> --- debian/liblxc1.symbols (liblxc1_1:4.0.10-1_hppa)
> +++ dpkg-gensymbolssWsm0O2021-08-27 19:27:05.880833302 +
> @@ -340,7 +340,7 @@
>   lxc_log_category_process_utils@Base 1:4.0.4
>   lxc_log_category_rbd@Base 1:3.0.2
>   lxc_log_category_rsync@Base 1:3.0.2
> - lxc_log_category_seccomp@Base 1:3.0.2
> +#MISSING: 1:4.0.10-1# lxc_log_category_seccomp@Base 1:3.0.2
>   lxc_log_category_selinux@Base 1:3.0.2
>   lxc_log_category_start@Base 1:3.0.2
>   lxc_log_category_state@Base 1:3.0.2
>
> The same error occurs on alpha, m68k, sh4 and sparc64.
>
> I see in the build log:
> Build-Depends: bash-completion, debhelper-compat (= 13), dh-apparmor, 
> dh-exec, docbook2x, doxygen, graphviz, libapparmor-dev, libcap-dev,
> libgnutls28-dev, liblua5.2-dev, libpam0g-dev, libseccomp-dev [!alpha !hppa 
> !m68k !sh4 !sparc64], libselinux-dev, linux-libc-dev, pkg-config
>
> libseccomp-dev is available on hppa but not on the other arches.  lxc build 
> successfully on hppa if I include the libseccomp-dev
> dependency.  Wasn't able to fix symbol issue.

Hi,

I am not sure about how I can make the symbols file vary for
architectures. I'll ask to other developers.

If you have recommendations I'm eager to take them! :)

Cheers!
--
PEB


signature.asc
Description: PGP signature

Bug#993484: golang-github-urfave-cli: FTBFS with Go 1.17

[William 'jawn-smith' Wilson]

Package: golang-github-urfave-cli
Version: 1.22.4-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,


As of Go 1.17, the flag package panics if given a syntactically invalid flag.
This was causing build time tests of this package to fail and therefore
the package was not building in Ubuntu with Go 1.17.

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

Allow the package to build with Go 1.17

  * Change "incorrect usage" test case to use an undefined flag rather
than a syntactically invalid flag. This prevents panics in test cases,
as Go 1.17 panics with invalid flag syntax (LP: #1942255)


Thanks for considering the patch.


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

Kernel: Linux 5.11.0-31-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-urfave-cli-1.22.4/debian/patches/0002-fix-failing-flag-test.patch 
golang-github-urfave-cli-1.22.4/debian/patches/0002-fix-failing-flag-test.patch
--- 
golang-github-urfave-cli-1.22.4/debian/patches/0002-fix-failing-flag-test.patch 
1969-12-31 18:00:00.0 -0600
+++ 
golang-github-urfave-cli-1.22.4/debian/patches/0002-fix-failing-flag-test.patch 
2021-09-01 09:47:18.0 -0500
@@ -0,0 +1,42 @@
+Description: Fix failing build time test
+ As of Go 1.17, the go flag package will panic if given a
+ syntactically invalid flag. This causes
+ TestApp_RunAsSubCommandIncorrectUsage to panic and therefore
+ fail. See https://golang.org/doc/go1.17#flag for more information.
+ This patch changes the test to use a flag that doesn't exist rather
+ than a syntactically invalid one to avoid the panic.
+Author: William 'jawn-smith' Wilson 
+Origin: Ubuntu
+Bug: https://github.com/urfave/cli/issues/1298
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-urfave-cli-v2/+bug/1942255
+Forwarded: https://github.com/urfave/cli/pull/1299
+Applied-Upstream: 
+Last-Update: 2021-08-31
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/app_test.go
 b/app_test.go
+@@ -509,19 +509,20 @@
+ 
+ func TestApp_RunAsSubCommandIncorrectUsage(t *testing.T) {
+   a := App{
++  Name: "cmd",
+   Flags: []Flag{
+-  StringFlag{Name: "--foo"},
++  {Name: "foo"},
+   },
+   Writer: bytes.NewBufferString(""),
+   }
+ 
+   set := flag.NewFlagSet("", flag.ContinueOnError)
+-  _ = set.Parse([]string{"", "---foo"})
++  _ = set.Parse([]string{"", "-bar"})
+   c := {flagSet: set}
+ 
+   err := a.RunAsSubcommand(c)
+ 
+-  expect(t, err, errors.New("bad flag syntax: ---foo"))
++  expect(t, err.Error(), "flag provided but not defined: -bar")
+ }
+ 
+ func TestApp_CommandWithFlagBeforeTerminator(t *testing.T) {
diff -Nru golang-github-urfave-cli-1.22.4/debian/patches/series 
golang-github-urfave-cli-1.22.4/debian/patches/series
--- golang-github-urfave-cli-1.22.4/debian/patches/series   2020-10-05 
15:24:27.0 -0500
+++ golang-github-urfave-cli-1.22.4/debian/patches/series   2021-09-01 
09:46:20.0 -0500
@@ -1 +1,2 @@
 0001-fix-zsh-autocomplete.patch
+0002-fix-failing-flag-test.patch

Bug#671296: sstp-client: changing back from ITP to RFP

[Lucas Nussbaum]

Yes, that's a good idea

On 01/09/21 at 22:12 +, Eivind Næss wrote:
> Hrm,
> 
> I filed this issue almost 10 years ago, and there been next to zero interests 
> on debian's side. People have consistently been pinging me to update the 
> packages out of a launchpad.net repository.
> 
> The network-manager-sstp is a part of the Gnome project, and I recently got a 
> Gnome membership. Would you suggest, I start by emailing some of the 
> maintainers of the other plugins to see if there is willingness to sponsor 
> (or even maintain) this package?
> 
> - Eivind
> 
> 
> 
> 
> 
> Get Outlook for Android
> 
> From: Lucas Nussbaum 
> Sent: Wednesday, September 1, 2021 11:59:34 AM
> To: Eivind Naess 
> Cc: 671...@bugs.debian.org <671...@bugs.debian.org>; Jonathan Rubenstein 
> 
> Subject: Re: Bug#671296: sstp-client: changing back from ITP to RFP
> 
> Hi,
> 
> On 01/09/21 at 16:38 +, Eivind Naess wrote:
> >  Hi Jonathan,
> >
> > I've since packaged sstp-client and network-manager-sstp and the respective 
> > debian source is located on launchpad:
> >
> > bzr branch lp:sstp-client-packagebzr branch lp:network-manager-sstp-package
> > I would love for debian to pick up the packages such that all the debian 
> > based distros like Ubuntu, etc would get this package as a part of their 
> > distribution (or at least an extra).
> > There should be very little work to make it a debian package, and the 
> > latest update to these branches fixed all the LINT warnings and is using 
> > the latest debian-helper/compat.
> >
> > What do you think, Lucas? Jonathan?
> 
> There are two paths here:
> 
> (A) find someone willing to maintain the package in Debian, preferably a
> Debian Developer or a Debian Maintainer
> 
> (B) agree to maintain the package yourself in Debian. Then you need to
> find someone (a sponsor) who will review the package and upload it to
> Debian on your behalf. This can happen inside a team (if there's a team
> where those packages are a good fit), or outside, using the
> http://mentors.debian.net/ service. The full process is described on
> https://mentors.debian.net/intro-maintainers/ .
> 
> (I ran into this bug during a routine QA task so I don't have any
> particular interest in SSTP, and I have very limited time for Debian
> currently, so I'm not a good candidate to be that sponsor)
> 
> Lucas

Bug#993483: golang-github-urfave-cli-v2: FTBFS with Go 1.17

[William 'jawn-smith' Wilson]

Package: golang-github-urfave-cli-v2
Version: 2.2.0-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

As of Go 1.17, the flag package panics if given a syntactically invalid flag.
This was causing build time tests of this package to fail and therefore
the package was not building in Ubuntu with Go 1.17.

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

Allow the package to build successfully with Go 1.17.

  * Change "incorrect usage" test case to use an undefined flag rather
than a syntactically invalid flag. This prevents panics in test cases,
as Go 1.17 panics with invalid flag syntax (LP: #1942255)


Thanks for considering the patch.


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

Kernel: Linux 5.11.0-31-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-urfave-cli-v2-2.2.0/debian/patches/0001-fix-failing-flag-test.patch
 
golang-github-urfave-cli-v2-2.2.0/debian/patches/0001-fix-failing-flag-test.patch
--- 
golang-github-urfave-cli-v2-2.2.0/debian/patches/0001-fix-failing-flag-test.patch
   1969-12-31 18:00:00.0 -0600
+++ 
golang-github-urfave-cli-v2-2.2.0/debian/patches/0001-fix-failing-flag-test.patch
   2021-08-31 13:54:29.0 -0500
@@ -0,0 +1,40 @@
+Description: Fix failing build time test
+ As of Go 1.17, the go flag package will panic if given a
+ syntactically invalid flag. This causes
+ TestApp_RunAsSubCommandIncorrectUsage to panic and therefore
+ fail. See https://golang.org/doc/go1.17#flag for more information.
+ This patch changes the test to use a flag that doesn't exist rather
+ than a syntactically invalid one to avoid the panic.
+Author: William 'jawn-smith' Wilson 
+Origin: Ubuntu
+Bug: https://github.com/urfave/cli/issues/1298
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-urfave-cli-v2/+bug/1942255
+Forwarded: https://github.com/urfave/cli/pull/1299
+Applied-Upstream: 
+Last-Update: 2021-08-31
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/app_test.go
 b/app_test.go
+@@ -471,18 +471,18 @@
+   a := App{
+   Name: "cmd",
+   Flags: []Flag{
+-  {Name: "--foo"},
++  {Name: "foo"},
+   },
+   Writer: bytes.NewBufferString(""),
+   }
+ 
+   set := flag.NewFlagSet("", flag.ContinueOnError)
+-  _ = set.Parse([]string{"", "---foo"})
++  _ = set.Parse([]string{"", "-bar"})
+   c := {flagSet: set}
+ 
+   err := a.RunAsSubcommand(c)
+ 
+-  expect(t, err, errors.New("bad flag syntax: ---foo"))
++  expect(t, err.Error(), "flag provided but not defined: -bar")
+ }
+ 
+ func TestApp_CommandWithFlagBeforeTerminator(t *testing.T) {
diff -Nru golang-github-urfave-cli-v2-2.2.0/debian/patches/series 
golang-github-urfave-cli-v2-2.2.0/debian/patches/series
--- golang-github-urfave-cli-v2-2.2.0/debian/patches/series 1969-12-31 
18:00:00.0 -0600
+++ golang-github-urfave-cli-v2-2.2.0/debian/patches/series 2021-08-31 
13:52:48.0 -0500
@@ -0,0 +1 @@
+0001-fix-failing-flag-test.patch

Bug#993391: [pkg-lxc-devel] Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"

[Pierre-Elliott Bécue]

Control: severity -1 normal

Hi,

I don't like to make judgemental calls when I try to help our users, but
here I'll still make a guess. I guess that you actually did not read
carefully README.Debian.gz and therefore did not follow these
instructions carefully.

pk  writes:

> Thank you for answering. kernel.unprivileged_userns_clone = 1 on my
> machine and on the Live DVD. All instructions of the README.Debian.gz
> were followed.
>
> To rule out machine-specific misconfiguration, this log is from the
> Live DVD, Debian 11.0 AMD64 Standard:
>
>
>
> Warning: Permanently added '[localhost]:12346' (ECDSA) to the list of
> known hosts.
> user@localhost's password:
> Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64
>
> The programs included with the Debian GNU/Linux system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> user@debian:~$ sudo su -l
> root@debian:~# apt-get update ; apt-get install lxc
> [snip]

What's in there apart from apt-get output?

> root@debian:~# sysctl kernel.unprivileged_userns_clone
> kernel.unprivileged_userns_clone = 1
> root@debian:~# grep user /etc/subuid /etc/subgid
> /etc/subuid:user:10:65536
> /etc/subgid:user:10:65536
> root@debian:~#
> logout
> user@debian:~$ mkdir -p .local/share/lxc
> user@debian:~$ chmod +x . .local .local/share
> user@debian:~$
> user@debian:~$ cat > test_config
>   lxc.idmap = u 0 10 65536
>   lxc.idmap = g 0 10 65536
>   lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
>   lxc.apparmor.profile = unconfined

This is not in the README, and you actually don't seem to have created
any container yet. Furthermore, your configuration actually doesn't
mention any rootfs or block device to pivot on!

Here is what I get doing something like what you pasted here.

.-(0:03:50)-(~)--(peb@x)-
`--[130]-> lxc-ls -f
NAME   STATE   AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED 
autopkgtest-lxc-xwkkud STOPPED 0 -  --true 
autopkgtest-unstable   STOPPED 0 -  --true 

As you see I only have two containers. I'll try to start a container
named "blah" which does not exist. I wrote a blah.cfg containing roughly
the same config as you just adapted for my subuids.

.-(0:03:51)-(~)--(peb@x)-
`---> cat blah.cfg
lxc.idmap = u 0 1214112 65536
lxc.idmap = g 0 1214112 65536
lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
lxc.apparmor.profile = unconfined

Here I'll use your command, but note that README.Debian.gz states we
have lxc-unpriv-start which makes things quite more elegant.

-(0:04:40)-(~)--(peb@x)-
`--[1]-> systemd-run --user --scope -p "Delegate=yes" /usr/bin/lxc-start -o 
/dev/stdout -f blah.cfg blah
Running scope as unit: run-r34581cfe965441428e3520ecb8c0bb7b.scope
lxc-start blah 20210901220449.759 ERRORutils - utils.c:safe_mount:1204 - 
Permission denied - Failed to mount "proc" onto "/proc"
lxc-start blah 20210901220449.759 ERRORconf - 
conf.c:lxc_mount_auto_mounts:681 - Permission denied - Failed to mount "proc" 
on "/proc" with flags 14
lxc-start blah 20210901220449.759 ERRORconf - conf.c:lxc_setup:3330 - 
Failed to setup first automatic mounts
lxc-start blah 20210901220449.759 ERRORstart - start.c:do_start:1218 - 
Failed to setup container "blah"
lxc-start blah 20210901220449.759 ERRORsync - sync.c:__sync_wait:36 - An 
error occurred in another process (expected sequence number 5)
lxc-start blah 20210901220449.759 ERRORlxccontainer - 
lxccontainer.c:wait_on_daemonized_start:859 - Received container state 
"ABORTING" instead of "RUNNING"
lxc-start blah 20210901220449.759 ERRORstart - start.c:__lxc_start:1999 - 
Failed to spawn container "blah"
[and it goes on]

With of course the Apparmor denial in dmesg.

I guess the reason is that lxc having no rootfs or block device to pivot
on tries to mount proc on "/proc" (maybe because it concatenates
$rootfs+"/proc", whith $rootfs being "" here?), ie on the host's /proc,
or anyway on something you don't have a right to mount on.

Of course with a created container and a real config, things are going
smoothly.

Considering what I gathered, I would recommend you take the time to
actually read the documentation properly and try to follow it.

If you fail to have a running container, please do provide a full log of
what you did step by step, and which part of README.Debian.gz it were
covered by what you did, in your opinion.

With best regards,

--
PEB


signature.asc
Description: PGP signature

Bug#991276: grub-live dracut support

[Patrick Schleizer]

grub-live dracut support has been implemented.

Bug#993466: libxcrypt-source: Add symbols for ARC

[Alexey Brodkin]

Package: libxcrypt-source
Version: 4.4.25-1
Severity: normal
Tags: patch
Usertags: rebootstrap

libxcrypt fails to build for ARC because of missing symbols.
Please consider including the following symbols file:

$ cat debian/libcrypt1.symbols.arc
libcrypt.so.1 libcrypt1 #MINVER#
#include "libcrypt1.symbols.common"
 GLIBC_2.31@GLIBC_2.31 1:4.1.0
 crypt@GLIBC_2.31 1:4.1.0
 crypt_r@GLIBC_2.31 1:4.1.0
 encrypt@GLIBC_2.31 1:4.1.0
 encrypt_r@GLIBC_2.31 1:4.1.0
 fcrypt@GLIBC_2.31 1:4.1.0
 setkey@GLIBC_2.31 1:4.1.0
 setkey_r@GLIBC_2.31 1:4.1.0
$

-Alexey

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#993482: python3-fonttools: missing dependency to python3-lxml

[Romain Porte]

Package: fonttools
Version: 4.19.1-1
Severity: important
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

I am using fontmake to build a font source package in Debian.

During the invocation in an isolated environment (sbuild), the call
fails with the following stacktrace:

> Traceback (most recent call last):
>   File "/usr/bin/fontmake", line 33, in 
> sys.exit(load_entry_point('fontmake==2.4.1', 'console_scripts', 
> 'fontmake')())
>   File "/usr/bin/fontmake", line 25, in importlib_load_entry_point
> return next(matches).load()
>   File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
> module = import_module(match.group('module'))
>   File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1030, in _gcd_import
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 680, in _load_unlocked
>   File "", line 850, in exec_module
>   File "", line 228, in _call_with_frames_removed
>   File "/usr/lib/python3/dist-packages/fontmake/__main__.py", line 20, in 
> 
> from ufo2ft import CFFOptimization
>   File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 8, in 
> 
> from ufo2ft.featureCompiler import (
>   File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line 14, 
> in 
> from ufo2ft.featureWriters import (
>   File "/usr/lib/python3/dist-packages/ufo2ft/featureWriters/__init__.py", 
> line 11, in 
> from .markFeatureWriter import MarkFeatureWriter
>   File 
> "/usr/lib/python3/dist-packages/ufo2ft/featureWriters/markFeatureWriter.py", 
> line 9, in 
> from ufo2ft.fontInfoData import getAttrWithFallback
>   File "/usr/lib/python3/dist-packages/ufo2ft/fontInfoData.py", line 23, in 
> 
> from fontTools import ufoLib
>   File "/usr/lib/python3/dist-packages/fontTools/ufoLib/__init__.py", line 8, 
> in 
> import fs
>   File "/usr/lib/python3/dist-packages/fs/__init__.py", line 4, in 
> __import__("pkg_resources").declare_namespace(__name__)  # type: ignore
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3243, 
> in 
> Traceback (most recent call last):
>   File "/usr/bin/fontmake", line 33, in 
> sys.exit(load_entry_point('fontmake==2.4.1', 'console_scripts', 
> 'fontmake')())
>   File "/usr/bin/fontmake", line 25, in importlib_load_entry_point
> return next(matches).load()
>   File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
> module = import_module(match.group('module'))
>   File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1030, in _gcd_import
> def _initialize_master_working_set():
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3226, 
> in _call_aside
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 680, in _load_unlocked
>   File "", line 850, in exec_module
>   File "", line 228, in _call_with_frames_removed
>   File "/usr/lib/python3/dist-packages/fontmake/__main__.py", line 20, in 
> 
> from ufo2ft import CFFOptimization
>   File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 8, in 
> 
> from ufo2ft.featureCompiler import (
>   File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line 14, 
> in 
> from ufo2ft.featureWriters import (
>   File "/usr/lib/python3/dist-packages/ufo2ft/featureWriters/__init__.py", 
> line 11, in 
> from .markFeatureWriter import MarkFeatureWriter
>   File 
> "/usr/lib/python3/dist-packages/ufo2ft/featureWriters/markFeatureWriter.py", 
> line 9, in 
> from ufo2ft.fontInfoData import getAttrWithFallback
>   File "/usr/lib/python3/dist-packages/ufo2ft/fontInfoData.py", line 23, in 
> 
> from fontTools import ufoLib
>   File "/usr/lib/python3/dist-packages/fontTools/ufoLib/__init__.py", line 8, 
> in 
> f(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3255, 
> in _initialize_master_working_set
> import fs
>   File "/usr/lib/python3/dist-packages/fs/__init__.py", line 4, in 
> __import__("pkg_resources").declare_namespace(__name__)  # type: ignore
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3243, 
> in 
> working_set = WorkingSet._build_master()
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 568, 
> in _build_master
> def _initialize_master_working_set():
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3226, 
> in _call_aside
> ws.require(__requires__)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 886, 
> in require
> needed = self.resolve(parse_requirements(requirements))
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 772, 
> in resolve

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[dann frazier]

On Tue, Aug 31, 2021 at 10:00:18PM +0300, Michael Tokarev wrote:
> 31.08.2021 18:02, dann frazier wrote:
> 
> > char device redirected to /dev/pts/14 (label charserial0)
> > about to fire assert: salen=2
> > qemu-system-x86_64: ../../util/qemu-sockets.c:1352: 
> > socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) 
> > + 1 && salen <= sizeof(struct sockaddr_un)' failed.
> > 2021-08-31 15:01:18.082+: shutting down, reason=crashed
> 
> Thank you very much dann!
> So this new assert() is wrong on both min and max sides. Oh well.. ;)
> 
> I cooked another patch to fix this, will upload it asap.
> 
> It is a fun one.. ;)

Thanks for the fix Michael! It works for me.

  -dann

Bug#993481: thunar: tree side pane malfunctions when collapsing and expanding folders

[David Christensen]

Package: thunar
Version: 1.8.4-1
Severity: normal

Dear Maintainer,

When using Thundar, if I collapse a folder in the Side Pane in Tree
mode and then expand a different folder, Thunar often (25%?) changes
the folder selection to the previously collapsed folder and expands
the previously selected folder.  Thunar should not change the folder
selection I made and should expand the folder I selected.


David



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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.4-1
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4+deb10u1
ii  libexo-2-0  0.12.4-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.4-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.4-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-0+deb10u1
ii  dbus-x11 [dbus-session-bus]   1.12.20-0+deb10u1
ii  gvfs  1.38.1-5
ii  libcairo-gobject2 1.16.0-4+deb10u1
ii  libpangocairo-1.0-0   1.42.4-8~deb10u1
ii  libxfce4panel-2.0-4   4.12.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 0.9.1-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-4
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

Bug#993480: gcl: Fails to install in unstable

[Samuel Thibault]

Package: gcl
Version: 2.6.12-102
Severity: serious
Justification: cannot install

Hello,

gcl cannot be installed in a fresh unstable chroot:

Setting up gcl (2.6.12-102) ...
/var/lib/dpkg/info/gcl.postinst: 5: tempfile: not found
/var/lib/dpkg/info/gcl.postinst: 5: tempfile: not found
/var/lib/dpkg/info/gcl.postinst: 27: cannot create : Directory nonexistent
dpkg: error processing package gcl (--configure):
 installed gcl package post-installation script subprocess returned error exit 
status 2

tempfile was indeed dropped from the debianutils package as of its
version 5.0-1

Samuel

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

Kernel: Linux 5.13.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcl depends on:
ii  debconf  1.5.77
ii  emacs-gtk [emacsen]  1:27.1+1-3.1
ii  gcc  4:10.2.1-1
ii  libc62.31-17
ii  libgmp10 2:6.2.1+dfsg-1
pn  libreadline6 
ii  libreadline7 7.0-5
ii  libreadline8 8.1-2
ii  libtcl8.68.6.11+dfsg-1
ii  libtk8.6 8.6.11-2
ii  libx11-6 2:1.7.2-1
ii  ucf  3.0043

gcl recommends no packages.

Versions of packages gcl suggests:
pn  gcl-doc  

-- 
Samuel
"...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning."
(By Matt Welsh)

Bug#993478: src:fricas: fails to migrate to testing for too long: maintainer built arch:all binaries

[Paul Gevers]

Source: fricas
Version: 1.3.6-6
Severity: serious
Control: close -1 1.3.7-1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As announced [1] last year, the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:fricas has
been trying to migrate for 62 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only really blocked because the arch:all binary
package(s) aren't built on a buildd. Unfortunately the Debian
infrastructure doesn't allow arch:all packages to be properly binNMU'ed.
Hence, I will shortly do a no-changes source-only upload to DELAYED/15,
closing this bug. Please let me know if I should delay or cancel that
upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=fricas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

[Roger Lynn]

On 27/08/2021 14:33, Didier 'OdyX' Raboud wrote:> Control: tags -1 +wontfix

Using Let's Encrypt is fine, allowed, and (apparently) working with CUPS,
but as that's clearly not a default way of working for CUPS, I'd be
_very_ reluctant to allow CUPS to access "all the Let's Encrypt
certificates" on all systems it gets installed to. Furthermore, 
/etc/apparmor.d/usr.sbin.cupsd is a configuration file, freely

modifiable by the local system administrator. In other words, imposing
that a local system administrator needs to update that file to enable a
specific type of certificates is reasonable.


CUPS appears to already have access to everything in /etc/ssl/ on all 
systems, which is where I used to keep my CAcert certificates. This doesn't 
feel any different.


On 29/08/2021 08:31, Didier 'OdyX' Raboud wrote:

Le vendredi, 27 août 2021, 18.31:17 h CEST Roger Lynn a écrit :

The documentation is definitely lacking - I've been trying to work out
why my configuration broke since upgrading to Buster 3 months ago! Even
with the loglevel set to "debug", the logs were utterly unhelpful.
Let's Encrypt is the most popular source of signed certificates and the
upstream documentation at https://www.cups.org/doc/encryption.html
explicitly says:

"CUPS also supports certificates created and managed by the popular
Let's Encrypt certificate service, which are stored in the
/etc/letsencrypt/live directory."


Right. Where do you suggest this needed apparmor edition should be
documented?
README.Debian or cups-files.conf(5) seem appropriate. A mention in 
NEWS.Debian would have been useful, but it's probably a bit late for that now.


Thanks,

Roger

Bug#993477: fai-setup-storage: setup-storage cannot create btrfs on lvm

[Sam Hartman]

Package: fai-setup-storage
Version: 5.10.3
Severity: normal

Dear Maintainer,

I tried to create a root btrfs filesystem on a logical volume.
setup-storage failed looking up the UUID of /dev/rootvg/root.
It was running blkid to look up the uuid in Fstab.pm before running mkfs.btrfs 
with the following disk_config:

# config for a disk image for a Hadron Machine
#
#

disk_config disk1 disklabel:gpt bootable:1  fstabkey:uuid align-at:1M

primary /boot/efi 300vfat  defaults
primary   -   300-   - -


disk_config lvm

vg rootvg   disk1.2
rootvg-root /   3G-20G  btrfs   rw,noatime,subvol=@/



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

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fai-setup-storage depends on:
ii  e2fsprogs 1.46.2-2
ii  liblinux-lvm-perl 0.17-2.1
ii  libparse-recdescent-perl  1.967015+dfsg-2
ii  parted3.4-1
ii  perl  5.32.1-4+deb11u1

Versions of packages fai-setup-storage recommends:
ii  lvm2   2.03.11-2.1
ii  mdadm  4.1-11

Versions of packages fai-setup-storage suggests:
ii  cryptsetup 2:2.3.5-1
ii  dmsetup2:1.02.175-2.1
ii  dosfstools 4.2-1
pn  jfsutils   
ii  ntfs-3g1:2017.3.23AR.3-4
pn  reiserfsprogs  
ii  xfsprogs   5.10.0-4

-- no debconf information

Bug#993475: installation-guide: Linux is no operating system, GNU/Linux is

[Erik Pfannenstein]

Package: installation-guide
Severity: normal

Dear Maintainer,

a while ago we recieved an e-mail notifying us that the chapter 1.02 states:
"Linux is an operating system: […]" and that it should read "GNU/Linux is an 
operating system" instead.
Technically, that's right. I ask you to correct this.

For reference, this is the mail:
https://lists.debian.org/debian-www/2021/06/msg9.html
and the text in question:
https://www.debian.org/releases/buster/amd64/ch01s02.en.html

Thanks in advance!

Regards,
Erik

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

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

Bug#993393: sensible-utils: [INTL:de] updated German man page translation

[Bastien Roucariès]

Hi,

This is not a patch how can I apply ?

Please create a salsa merge request or send me a patch

Thanks 

Bastien

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

Bug#980457: dovecot-sieve: Vacation Address compare is not case insensitive anymore

[Sebastian Andrzej Siewior]

control: tags -1 + patch
control: fixed -1 1:2.3.10.1+dfsg1-1

On 2021-01-19 11:25:06 [+0100], Uwe Jans wrote:
> I think maybe a backport from this Patch may help integrated in buster:
> 
> https://github.com/dovecot/pigeonhole/commit/400566cc4a6f938ed1dfe513c38f1bd681717ebe?branch=400566cc4a6f938ed1dfe513c38f1bd681717ebe=split

This is just restruct. The actual change is
   
https://github.com/dovecot/pigeonhole/commit/4efeaa216c8aca54defd4d31ca72baf24c80664d

and part of Bullseye, current stable, which would require to backport it
to old-stable/Buster. So the bar is high here.

The maintainer could close this…

Sebastian

Bug#993474: open-infrastructure-compute-tools: German translation of the debconf template

[Markus Hiereth]

Source: open-infrastructure-compute-tools
Version: 20210804-2
Severity: normal

Dear Maintainer,

Please find attached the German debconf templates translation,
proofread by the debian-l10n-german mailing list contributors.

This file should be put as debian/po/de.po in your package build tree.

Best regards
Markus Hiereth
# German debconf translation of open-infrastructure-compute-tools
# Copyright (C) 2021 Markus Hiereth 
# This file is distributed under the same license as the 
open-infrastructure-compute-tools package.
# Markus Hiereth , 2021.
msgid ""
msgstr ""
"Project-Id-Version: open-infrastructure-compute-tools 20210804-2\n"
"Report-Msgid-Bugs-To: open-infrastructure-compute-to...@packages.debian.org\n"
"POT-Creation-Date: 2021-07-25 10:09+0200\n"
"PO-Revision-Date: 2021-08-24 21:28+0200\n"
"Last-Translator: Markus Hiereth \n"
"Language-Team: debian-l10n-german \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#. Type: title
#. Description
#: ../open-infrastructure-container-tools.templates:1001
msgid "container-tools: Setup"
msgstr "container-tools: Einrichtung"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid "machines directory:"
msgstr "Maschinen-Verzeichnis:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid "Please specify the directory that will be used to store the containers."
msgstr ""
"Bitte geben Sie das zum Speichern von Containern vorgesehene Verzeichnis an."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid ""
"If unsure, use /var/lib/machines (default) or /srv/container/system when "
"using shared storage."
msgstr ""
"Wenn Sie unsicher sind, verwenden Sie das Standardverzeichnis /var/lib/"
"machines oder für gemeinsam benutzten Speicher /srv/container/system."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid "config directory:"
msgstr "Konfigurationsverzeichnis:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid ""
"Please specify the directory that will be used to store the container "
"configuration files."
msgstr ""
"Bitte geben Sie das für die Container-Konfigurationsdateien vorgesehene "
"Verzeichnis an."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid ""
"If unsure, use /etc/compute-tools/config (default) or /srv/container/config "
"when using shared storage."
msgstr ""
"Wenn Sie unsicher sind, verwenden Sie das Standardverzeichnis /etc/compute-"
"tools/config oder für gemeinsam benutzten Speicher /srv/container/config."

#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
#: ../open-infrastructure-container-tools.templates:5001
#: ../open-infrastructure-container-tools.templates:6001
msgid "debconf directory:"
msgstr "Debconf-Verzeichnis:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
msgid ""
"Please specify the directory that will be used to store the container "
"preseed files."
msgstr ""
"Bitte geben Sie das Verzeichnis an, welches die Voreinstellungsdateien für "
"Container speichern soll."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
msgid ""
"If unsure, use /etc/compute-tools/debconf (default) or /srv/container/"
"debconf when using shared storage."
msgstr ""
"Wenn Sie unsicher sind, verwenden Sie das Standardverzeichnis /etc/compute-"
"tools/debconf oder /srv/container/debconf für gemeinsam benutzten Speicher."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:5001
msgid ""
"Please specify the directory that will be used to store the container hooks."
msgstr ""
"Bitte geben Sie das zum Speichern der Container-Hooks vorgesehene "
"Verzeichnis an."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:5001
msgid ""
"If unsure, use /etc/compute-tools/hooks (default) or /srv/container/hooks "
"when using shared storage."
msgstr ""
"Wenn Sie unsicher sind, verwenden Sie das Standardverzeichnis /etc/compute-"
"tools/hooks oder für gemeinsam benutzten Speicher /srv/container/hooks."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:6001
msgid ""
"Please specify the directory that will be used to store the container keys "
"for verifying container image downloads."
msgstr ""
"Bitte geben Sie das Verzeichnis für die Container-Schlüssel an, mit welchen "
"heruntergeladene Container-Abbilder überprüft werden."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:6001
msgid ""
"If unsure, use /etc/compute-tools/keys (default) or /srv/container/keys 

Bug#671296: sstp-client: changing back from ITP to RFP

[Lucas Nussbaum]

Hi,

On 01/09/21 at 16:38 +, Eivind Naess wrote:
>  Hi Jonathan, 
> 
> I've since packaged sstp-client and network-manager-sstp and the respective 
> debian source is located on launchpad:
> 
> bzr branch lp:sstp-client-packagebzr branch lp:network-manager-sstp-package
> I would love for debian to pick up the packages such that all the debian 
> based distros like Ubuntu, etc would get this package as a part of their 
> distribution (or at least an extra).
> There should be very little work to make it a debian package, and the latest 
> update to these branches fixed all the LINT warnings and is using the latest 
> debian-helper/compat. 
> 
> What do you think, Lucas? Jonathan? 

There are two paths here:

(A) find someone willing to maintain the package in Debian, preferably a
Debian Developer or a Debian Maintainer

(B) agree to maintain the package yourself in Debian. Then you need to
find someone (a sponsor) who will review the package and upload it to
Debian on your behalf. This can happen inside a team (if there's a team
where those packages are a good fit), or outside, using the
http://mentors.debian.net/ service. The full process is described on
https://mentors.debian.net/intro-maintainers/ .

(I ran into this bug during a routine QA task so I don't have any
particular interest in SSTP, and I have very limited time for Debian
currently, so I'm not a good candidate to be that sponsor)

Lucas

Bug#993473: quilt-el: quilt mode breaks visiting a file in a non-existent directory

[Neil Roeth]

Package: quilt-el
Version: 0.66-2.1
Severity: normal
X-Debbugs-Cc: none, Neil Roeth 

Emacs normal behavior when visiting a file in a non-existent directory
is to create a buffer for the file, display a message "Use M-x
make-directory RET RET to create the directory and its parents", then
switch to the new buffer.  With quilt-mode loaded, the same action
creates a buffer for the file, displays the message about
make-directory, but then quits with an error
"call-process-shell-command: Setting current directory: No such file or
directory," followed by the name of the non-existent directory.  It does
not switch to the new buffer even though the new buffer exists.

To reproduce, make sure the directory /tmp/fubar does not exist, then
execute the following command.

$ emacs -q -l quilt-mode /tmp/fubar/readme.txt

That will leave you in the scratch buffer.  Use list-buffers (C-x C-b)
to verify a buffer name readme.txt exists.  To show the expected
behavior, execute the following command.

$ emacs -q /tmp/fubar/readme.txt

That will leave you in the readme.txt buffer.


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

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

Versions of packages quilt-el depends on:
ii  emacs-gtk [emacsen]  1:27.1+1-3
ii  quilt0.66-2.1

quilt-el recommends no packages.

quilt-el suggests no packages.

-- no debconf information

-- 
Neil Roeth

Bug#842943: (no subject)

[ZenWalker]

It seems that someone could pack it for arm64:

https://github.com/0mniteck/Signal-Desktop-Builder

deb file:
https://github.com/0mniteck/Signal-Desktop-Builder/raw/master/builds/release/signal-desktop_5.14.0_arm64.deb

Signature:
https://github.com/0mniteck/Signal-Desktop-Builder/raw/master/builds/release/signal-desktop_5.14.0_arm64.deb.sig

Bug#993472: ITP: r-bioc-tximportdata -- GNU R various transcript abundance quantifiers

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-tximportdata -- GNU R various transcript abundance 
quantifiers
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-tximportdata
  Version : 1.20.0+ds
  Upstream Author : Michael Love
* URL : 
https://bioconductor.org/packages/release/data/experiment/html/tximportData.html
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R various transcript abundance quantifiers
 This package provides the output of running various
 transcript abundance quantifiers on a set of 6 RNA-seq samples
 from the GEUVADIS project. The quantifiers were Cufflinks,
 RSEM, kallisto, Salmon and Sailfish. For details on version
 numbers, sample information, and details on calls, see the
 package vignette.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-tximportdata

Bug#993371: Support for cgroups v2

[Sakirnth Nagarasa]

Hello

Thank you for your bug report.

I have opened a bug in upstream:
https://github.com/ansible/ansible-runner/issues/810

As soon as they adapt the code I will upload the new version to debian.

Cheers,
Saki

Bug#993471: mc crashes if ftp server specified on cmdline requires authentication

[Matija Nalis]

Package: mc
Version: 3:4.8.26-1.1
Severity: normal

Dear Maintainer,

Trying to specify FTP URL with username crashes mc if invoked from command line.
For example:

  mc /tmp ftp://someuser@192.168.43.1:2121/

mc would start to show the dialog to ask password, and then crash:
┌─── FTP: Password required for someuser 
───┐
│ Password: 
│
│ zsh: segmentation fault  mc /tmp ftp://someuser@192.168.43.1:2121/
│


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

- When invoked via menus (eg. F9 / Right / FTP link / 
ftp://mnalis@192.168.43.1:2121/) it asks for password normally and connects.
- if anonymous FTP is attempted (which does not require inputting password) it 
works.
- if correct password is also specified on command line, it also works
- if incorrect password is specified on command line, it fails as it tries to 
re-ask the password
- Also, it worked in Buster version of mc just fine. After upgrade to Bullseye 
it crashes.

In short, it seems to crash only if URL which was specified IN COMMAND LINE 
requires some user input.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages mc depends on:
ii  libc6 2.31-13
ii  libext2fs21.46.2-2
ii  libglib2.0-0  2.66.8-1
ii  libgpm2   1.20.7-8
ii  libslang2 2.3.2-5
ii  libssh2-1 1.9.0-2
ii  mc-data   3:4.8.26-1.1

Versions of packages mc recommends:
ii  mime-support3.66
ii  perl5.32.1-4+deb11u1
ii  sensible-utils  0.0.14
ii  unzip   6.0-26

Versions of packages mc suggests:
pn  arj  
ii  bzip21.0.8-4
pn  catdvi | texlive-binaries
ii  dbview   1.0.4-4
pn  djvulibre-bin
ii  epub-utils   0.2.2-4+b4
ii  evince [pdf-viewer]  3.38.2-1
ii  file 1:5.39-3
ii  genisoimage  9:1.1.11-3.2
pn  gv   
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
pn  libaspell-dev
ii  lynx 2.9.0dev.6-3~deb11u1
pn  odt2txt  
ii  poppler-utils20.09.0-3.1
pn  python   
pn  python-boto  
pn  python-tz
pn  unar 
ii  w3m  0.5.3+git20210102-6
pn  wimtools 
ii  zip  3.0-12

-- no debconf information

Bug#993470: gcc-10 rejected

[Adrian Bunk]

Source: gcc-10
Version: 10.3.0-8
Severity: serious

Your upload included the binary package lib32atomic1, version 10.3.0-8, for 
mips64el,
however unstable already has version 11.2.0-3+b1.

Bug#993468: RFS: materia-gtk-theme/20200916-3 [ITS] -- Material Design theme for GNOME/GTK+ based desktop environments

[Leandro Cunha]

Package: sponsorship-requests
Severity: normal
Owner: Boyuan Yang 

Dear mentors,

I request a review of the changes and I made an email request for
Boyuan Yang to upload this package. This bug is just to formalize
the process and inform that I'm working on an ITS process.

I am looking for a sponsor for my package "materia-gtk-theme":

 * Package name: materia-gtk-theme
   Version : 20200916-3
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/nana-4/materia-theme
 * License : GPL-2+, LGPL-2.1
 * Vcs :
https://salsa.debian.org/desktop-themes-team/materia-gtk-theme
   Section : x11

It builds those binary packages:

  materia-gtk-theme - Material Design theme for GNOME/GTK+ based
desktop environments

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

  https://mentors.debian.net/package/materia-gtk-theme/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/materia-gtk-theme/materia-gtk-theme_20200916-3.dsc

Changes since the last upload:

 materia-gtk-theme (20200916-3) unstable; urgency=medium
 .
   * debian/control:
 - Moved maintainer to Debian Desktop Themes Team. (Closes: #987697)
 - Added uploaders Boyuan Yang, Leandro Cunha and Sagar Ippalpalli.
 - Moved Vcs fields to Debian Desktop Themes Team group in Salsa.

Regards,
-- 
Leandro Cunha

Bug#993469: gtk+3.0: Schema org.gtk.Settings.Debug.gschema.xml should be part of libgtk-3-common (not libgtk-3-dev)

[Arnaud Rebillout]

Source: gtk+3.0
Severity: important
User: de...@kali.org
Usertags: origin-kali

  Dear Maintainer,

there was a change in gnome-terminal 3.40, it now requires the schema
org.gtk.Settings.Debug.gschema.xml to be installed. It's a hard
requirement. Without this schema, no crash, but the terminal falls back
to default settings.

It can be seen in the journal, all you need to reproduce is a system with
gnome-terminal 3.40, and make sure that libgtk-3-dev is NOT installed.

  Sep 01 14:15:55 fakemachine gnome-terminal-server[1467]: Installed schemas 
failed verification: Schema "org.gtk.Settings.Debug" is missing
  Sep 01 14:15:55 fakemachine gnome-terminal-server[1467]: Falling back to 
built-in reference schemas.

If ever libgtk-3-dev is installed, then the file
/usr/share/glib-2.0/schemas/org.gtk.Settings.Debug.gschema.xml is
present, and there's no error.

The problem was initially reported upstream:

  https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7867

Quoting the upstream maintainer:

  I do not think there is a bug in gnome-terminal here. The schema
  verifier worked as designed, catching the missing schema. Schemas
  are never optional, they are hard dependencies.

Seems like the file org.gtk.Settings.Debug.gschema.xml should be shipped
by libgtk-3-common instead of libgtk-3-dev then?

Cheers,

  Arnaud

Bug#993467: Shotdetect built from apt source aborts with "munmap_chunk(): invalid pointer" (Debian 10)

[Peter B.]

Package: shotdetect
Version: 1.0.86-5+b2
Severity: important
File: /usr/bin/shotdetect

Dear Maintainer,

This happened on Debian10. The same code used to work fine on Debian9.

   * What led up to the situation?
 A: I wanted to build the application from its "apt source" package.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 A: I've downloaded the package source (apt source shotdetect), then
 ran `debuild -us -uc`, without any modifications to the source.

   * What was the outcome of this action?
 A: The generated shotdetect binary exits with an "invalid pointer"
 error when initializing the output folder(names).
 The binary provided by the official repositories works fine though.

   * What outcome did you expect instead?
 I expected the created binary to work just like the one from the
 repositories.


**The good news is, it's fixed :) **

In fact it's a missing "return" statement in "create_img_dir()" in 
src/image.cpp.

Thanks to Georg Lippitsch and Giulio Paci for finding it :)

I've tested the fix and can provide a patch.

Here's the output of "quilt diff" after the fix:

-
Index: shotdetect-1.0.86/src/image.cpp
===
--- shotdetect-1.0.86.orig/src/image.cpp
+++ shotdetect-1.0.86/src/image.cpp
@@ -66,6 +66,7 @@ image::create_img_dir ()
 }
   free (buf);

+  return 0;
 }

 int
-


Thanks in advance,
Peter B.

Bug#993458: The obs-studio downloaded as apt source fails to package.

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-09-02 01:43:08 +0900, jiho lee wrote:
> Package: obs-studio
> Version: 26.1.2+dfsg1-2
> 
> Hello.
> 
> This time, I downloaded obs-studio from Debian bullseye with the apt
> source command and tried to package it with the debuild command, but a
> dh_missing error occurs.
> 
> System: Debian Bullseye
> Platform: x86_64
> Commands:
> sudo apt build-dep obs-studio
> debuild -us -uc -b
> 
> Expected Result:
> You must have a packaged deb file.
> 
> Failed Result:
>dh_strip_nondeterminism
>dh_compress
>dh_fixperms
>dh_missing
> dh_missing: warning: usr/lib/x86_64-linux-gnu/obs-plugins/sndio.so
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ar-SA.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ca-ES.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/cs-CZ.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/da-DK.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/de-DE.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/el-GR.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/en-GB.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/en-US.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/es-ES.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/et-EE.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fa-IR.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fi-FI.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fr-FR.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/gl-ES.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/hu-HU.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/id-ID.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/it-IT.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ja-JP.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ka-GE.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning:
> usr/share/obs/obs-plugins/sndio/locale/kab-KAB.ini exists in
> debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ko-KR.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/nl-NL.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pl-PL.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pt-BR.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pt-PT.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ru-RU.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/sk-SK.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/sl-SI.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/sv-SE.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/tr-TR.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/uk-UA.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/zh-CN.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/zh-TW.ini
> exists in debian/tmp but is not installed to anywhere
> dh_missing: error: missing files, aborting
> The 

Bug#993465: ITP: libxs-parse-keyword-perl -- XS functions to assist in parsing keyword syntax

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libxs-parse-keyword-perl
  Version : 0.14
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/XS-Parse-Keyword
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : XS functions to assist in parsing keyword syntax

XS::Parse::Keywords provides some XS functions to assist in writing syntax
modules that provide new perl-visible syntax, primarily for authors of
keyword plugins using the PL_keyword_plugin hook mechanism. It is unlikely to
be of much use to anyone else; and highly unlikely to be any use when writing
perl code using these. Unless you are writing a keyword plugin using XS, this
module is not for you.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#993464: The libgtk3-imageview-perl package needs to be updated.

[jiho lee]

Package: libgtk3-imageview-perl
Version: 6-1

When I try to install the newly submitted shutter package on Debian 11, the
libgtk3-imageview-perl package is outdated and not installed.
(The shutter package has not yet been reflected in the official repository,
and it was installed after cloning from salsa.debian.org and manually
building)

The version of the libgtk3-imageview-perl package required by the shutter
package is version 9 or higher, but in bullseye, libgtk3-imageview-perl is
6.

When the shutter package is officially upstreamed to the Debian repository,
it seems that it will be difficult to install and use it properly due to a
problem with the libgtk3-imageview-perl package.

There is no bug in the libgtk3-imageview-perl package itself, but there is
a dependency problem in the shutter package, so we report a bug.


There is a future society, but my future is not what others do.
Dept. of Information Science, Graduate School, Korea National Open
University

Bug#991981: python3-skbio: package installs .../dist-packages/benchmarks/..

[Adrian Bunk]

Control: severity -1 serious
Control: clone -1 -2
Control: reassign -2 python3-sunpy 3.0.1-3
Control: retitle -2 python3-sunpy: package installs 
.../dist-packages/benchmarks/..

On Sat, Aug 07, 2021 at 03:38:00PM +0200, Steffen Moeller wrote:
> Package: python3-skbio
> Version: 0.5.6-4
> Severity: normal
> 
> Dear Maintainer,
> 
> Unpacking python3-skbio (0.5.6-4) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/python3/dist-packages/benchmarks/__init__.py', 
> which is also in package cutesv 1.0.11-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb
> 
> I just fixed cutesv, leaving this as a reminder to also fix skbio.

And now python3-sunpy does the same:

...
Unpacking python3-sunpy (3.0.1-3) over (2.0.7-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-wnyRIj/135-python3-sunpy_3.0.1-3_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/python3/dist-packages/benchmarks/__init__.py', 
which is also in package python3-skbio 0.5.6-4
...

> Cheers,
> Steffen

cu
Adrian

Bug#993462: RM: memkind [s390x] -- ROM; untested, useless on s390*

[Adam Borowski]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove memkind (libmemkind-dev, libmemkind-progs, libmemkind0) on
s390x.  There's no use for that package there, and we also can't test it.

On Debian, s390 kernels are built without CONFIG_NUMA, which is required
for the package to work (during tests/at runtime).  We perhaps could leave
the package as a courtesy for Ubuntu who define CONFIG_NUMA=y, but after
asking around, I see there's no NUMA exposed to Linux on s390 hardware.
There's also no hardware (or at least, support in any kernels) for other
kinds of memory memkind can use: pmem, HBW.

There's also no effort towards supporting any of these, as far as I can
tell -- in stark contrast to IBM folks doing a lot of stuff for ppc64el.

As the package is already not available on some archs (!32-bit), it has
no value as a stub that compiles but performs no useful function.

Bug#993461: corrupted index.fits data files prohibit plate-solve

[Jens Scheidtmann]

Package: astrometry-data-2mass
Version: 1.1

After having installed the astrometry-data-2mass data on my raspi 4,
solve-field gives  errors on some of the examples provided by astrometry.net
(as part of their git repository):

$ solve-field demo/sdss.jpg
reports:

kdtree_fits_io.c:274:kdtree_fits_read_tree: Kdtree header was not found in
file /usr/share/astrometry/index-2mass-00-30.fits
starkd.c:259:my_open: Failed to read kdtree from file
"/usr/share/astrometry/index-2mass-00-30.fits"
index.c:401:index_reload: Failed to read star kdtree from file
/usr/share/astrometry/index-2mass-00-30.fits
engine.c:196:engine_add_index: Failed to load index from path
/usr/share/astrometry/index-2mass-00-30.fits
Failed to add index "/usr/share/astrometry/index-2mass-00-30.fits".
fitsbin.c:449:read_chunk: Couldn't find table "kdtree_data_codes" in file
"/usr/share/astrometry/index-2mass-00-20.fits"
index.c:401:index_reload: Failed to read star kdtree from file
/usr/share/astrometry/index-2mass-00-20.fits
engine.c:196:engine_add_index: Failed to load index from path
/usr/share/astrometry/index-2mass-00-20.fits
Failed to add index "/usr/share/astrometry/index-2mass-00-20.fits".
kdtree_fits_io.c:274:kdtree_fits_read_tree: Kdtree header was not found in
file /usr/share/astrometry/index-2mass-00-15.fits
starkd.c:259:my_open: Failed to read kdtree from file
"/usr/share/astrometry/index-2mass-00-15.fits"
index.c:401:index_reload: Failed to read star kdtree from file
/usr/share/astrometry/index-2mass-00-15.fits
engine.c:196:engine_add_index: Failed to load index from path
/usr/share/astrometry/index-2mass-00-15.fits
Failed to add index "/usr/share/astrometry/index-2mass-00-15.fits".
kdtree_fits_io.c:274:kdtree_fits_read_tree: Kdtree header was not found in
file /usr/share/astrometry/index-2mass-00-12.fits
starkd.c:259:my_open: Failed to read kdtree from file
"/usr/share/astrometry/index-2mass-00-12.fits"
index.c:401:index_reload: Failed to read star kdtree from file
/usr/share/astrometry/index-2mass-00-12.fits
engine.c:196:engine_add_index: Failed to load index from path
/usr/share/astrometry/index-2mass-00-12.fits
Failed to add index "/usr/share/astrometry/index-2mass-00-12.fits".

It seems that after the package downloaded the fits-files, some of the
files are corrupted. Removing and  then reinstalling the package did
download the files again, but then some other files were then corrupted
(not shown). Only after manually downloading the given files using wget, I
was able to solve sdss.jpg.

As an improvement, please consider checking downloaded files against the
md5sums.txt file, that is available from
http://data.astrometry.net/4200/md5sums.txt.

It would even be better, if a dpkg-reconfigure or a command (or some such),
would download only corrupted files as this is a 3 GB download.

Thanks in advance,

Jens

Bug#993460: RFS: python-jellyfish/0.8.8-1 -- Library for approximate and phonetic matching of strings

[Diego M. Rodriguez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-jellyfish":

 * Package name: python-jellyfish
   Version : 0.8.8-1
   Upstream Author : James Turk 
 * URL : https://github.com/jamesturk/jellyfish
 * License : BSD-2-clause
 * Vcs :
https://salsa.debian.org/python-team/packages/python-jellyfish
   Section : python

It builds those binary packages:

  python-jellyfish-doc - Library for approximate and phonetic matching
of strings (documentation)
  python3-jellyfish - Library for approximate and phonetic matching of
strings (Python 3)

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

  https://mentors.debian.net/package/python-jellyfish/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-jellyfish/python-jellyfish_0.8.8-1.dsc

Changes since the last upload:

 python-jellyfish (0.8.8-1) UNRELEASED; urgency=medium
 .
   [ Ondřej Nový ]
   * d/control: Update Maintainer field with new Debian Python Team
 contact address.
   * d/control: Update Vcs-* fields with new Debian Python Team Salsa
 layout.
 .
   [ Debian Janitor ]
   * Apply multi-arch hints.
 + python-jellyfish-doc: Add Multi-Arch: foreign.
 .
   [ Diego M. Rodriguez ]
   * d/watch: bump version to 4
   * New upstream version 0.8.8
   * d/control: bump Standards-Version to 4.6.0 (no changes needed)

Regards,
-- 
Diego M. Rodriguez

Bug#993459: openssh-server: sshd's PAM configuration doesn't set $MAIL

[Michael Krylov]

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

Dear Maintainer,

After upgrading from Buster to Bullseye, I've noticed that $MAIL
variable is not set when one logs in via ssh, but is set when one logs
in on TTY. I don't think it was an intended behaviour.

I've looked through the possible places where it could be set and found
out that it was previously set in /etc/login.defs, but now is governed
by PAM.

Further investigation showed that PAM configuration for sshd which resides
in /etc/pam.d/sshd has the line 

sessionoptional pam_mail.so standard noenv # [1]

I've changed it to 

sessionoptional pam_mail.so standard # [1]

and now the $MAIL is set again.

Searching for the reason to set `noenv' there led me to this bug in BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=58429

In this bug it was reported that there were multiple non-informative
entries in auth.log if `noenv` was not enabled, but the bug was filed
more than 20 years ago, so I've checked if it is still the case.
Apparently it is not, the only new lines in auth.log are 

Sep  1 19:42:14 laptop sshd[28790]: Accepted publickey for sqrt from 127.0.0.1 
port 50194 ssh2: RSA SHA256:oCn47IKkSvC9WS1aUl52hD0UYsVtDT80s9pFDETWac0
Sep  1 19:42:14 laptop sshd[28790]: pam_unix(sshd:session): session opened for 
user sqrt(uid=1000) by (uid=0)

So I suggest we revert this `noenv' option as the reason for its
existing is gone and it causes problems like the one I'm filing this bug
about.

Thanks in advance!

-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-8-686 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  libaudit1  1:3.0-2
ii  libc6  2.31-13
ii  libcom-err21.46.2-2
ii  libcrypt1  1:4.4.18-4
ii  libgssapi-krb5-2   1.18.3-6
ii  libkrb5-3  1.18.3-6
ii  libpam-modules 1.4.0-9
ii  libpam-runtime 1.4.0-9
ii  libpam0g   1.4.0-9
ii  libselinux13.1-3
ii  libssl1.1  1.1.1k-1
ii  libsystemd0247.3-6
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  openssh-client 1:8.4p1-5
ii  openssh-sftp-server1:8.4p1-5
ii  procps 2:3.3.17-5
ii  runit-helper   2.10.3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages openssh-server recommends:
pn  default-logind | logind | libpam-systemd  
pn  ncurses-term  
ii  xauth 1:1.1-1

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

-- Configuration Files:
/etc/pam.d/sshd changed:
@include common-auth
accountrequired pam_nologin.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad]
pam_selinux.so close
sessionrequired pam_loginuid.so
sessionoptional pam_keyinit.so force revoke
@include common-session
sessionoptional pam_motd.so  motd=/run/motd.dynamic
sessionoptional pam_motd.so noupdate
sessionoptional pam_mail.so standard # [1]
sessionrequired pam_limits.so
sessionrequired pam_env.so # [1]
sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale
session [success=ok ignore=ignore module_unknown=ignore default=bad]
pam_selinux.so open
@include common-password


-- debconf-show failed

Bug#993458: The obs-studio downloaded as apt source fails to package.

[jiho lee]

Package: obs-studio
Version: 26.1.2+dfsg1-2

Hello.

This time, I downloaded obs-studio from Debian bullseye with the apt
source command and tried to package it with the debuild command, but a
dh_missing error occurs.

System: Debian Bullseye
Platform: x86_64
Commands:
sudo apt build-dep obs-studio
debuild -us -uc -b

Expected Result:
You must have a packaged deb file.

Failed Result:
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
dh_missing: warning: usr/lib/x86_64-linux-gnu/obs-plugins/sndio.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ar-SA.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ca-ES.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/cs-CZ.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/da-DK.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/de-DE.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/el-GR.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/en-GB.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/en-US.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/es-ES.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/et-EE.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fa-IR.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fi-FI.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/fr-FR.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/gl-ES.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/hu-HU.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/id-ID.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/it-IT.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ja-JP.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ka-GE.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/share/obs/obs-plugins/sndio/locale/kab-KAB.ini exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ko-KR.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/nl-NL.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pl-PL.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pt-BR.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/pt-PT.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/ru-RU.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/sk-SK.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/sl-SI.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/sv-SE.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/tr-TR.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/uk-UA.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/zh-CN.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/obs/obs-plugins/sndio/locale/zh-TW.ini
exists in debian/tmp but is not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they
installed (with files per package)
 * dh_install: libobs-dev (11), libobs0 (27), obs-plugins
(12), obs-studio (31)
 * dh_installdocs: libobs-dev (0), libobs0 (0), obs-plugins
(0), obs-studio (0)
 

Bug#993456: ircmarkers FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: ircmarkers
Version: 0.15-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ircmarkers fails to cross build from source, because its upstream
Makefile hard codes the build architecture compiler. Please consider
applying the attached patch to make it substitutable.

Helmut
--- ircmarkers-0.15.orig/Makefile
+++ ircmarkers-0.15/Makefile
@@ -4,11 +4,12 @@
 VERSION=$(shell dpkg-parsechangelog 2>&1 | perl -ne 'print $$1 if /^Version: ([^-]*)/')
 TGZ=$(NAME)_$(VERSION).orig.tar.gz
 TGZ_DIR=$(NAME)-$(VERSION)
+CC=gcc
 
 all: overlap ircmarkers.1
 
 overlap: overlap.c
-	gcc -g -O2 -Wall $(DEBUG) -o overlap overlap.c
+	$(CC) -g -O2 -Wall $(DEBUG) -o overlap overlap.c
 
 ircmarkers.1: ircmarkers
 	pod2man --release="$(NAME)" --center="User Documentation" $< > $@

Bug#993457: tracker-miners FTCBFS: requires native tracker-testutils

[Helmut Grohne]

Source: tracker-miners
Version: 3.1.1-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tracker-miners fails to cross build from source, because meson.build
requires native tracker-testutils. I'm not sure whether it really is
being used, but it is quite explicit about that.

As such, it cannot be annotated , but beyond that I think that
since it is being run, the native one is needed.

Please consider applying the attached patch or improving upon it.

Helmut
diff --minimal -Nru tracker-miners-3.1.1/debian/changelog 
tracker-miners-3.1.1/debian/changelog
--- tracker-miners-3.1.1/debian/changelog   2021-08-31 04:49:52.0 
+0200
+++ tracker-miners-3.1.1/debian/changelog   2021-09-01 18:36:51.0 
+0200
@@ -1,3 +1,10 @@
+tracker-miners (3.1.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Require native tracker-testutils. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 01 Sep 2021 18:36:51 +0200
+
 tracker-miners (3.1.1-3) unstable; urgency=medium
 
   * Release to unstable
diff --minimal -Nru tracker-miners-3.1.1/debian/control 
tracker-miners-3.1.1/debian/control
--- tracker-miners-3.1.1/debian/control 2021-08-31 04:49:52.0 +0200
+++ tracker-miners-3.1.1/debian/control 2021-09-01 18:36:43.0 +0200
@@ -50,7 +50,7 @@
python3-gi ,
python3-tap ,
shared-mime-info ,
-   tracker-test-utils ,
+   tracker-test-utils:native,
systemd (>= 242) [linux-any],
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/gnome-team/tracker-miners
diff --minimal -Nru tracker-miners-3.1.1/debian/patches/cross.patch 
tracker-miners-3.1.1/debian/patches/cross.patch
--- tracker-miners-3.1.1/debian/patches/cross.patch 1970-01-01 
01:00:00.0 +0100
+++ tracker-miners-3.1.1/debian/patches/cross.patch 2021-09-01 
18:36:23.0 +0200
@@ -0,0 +1,11 @@
+--- tracker-miners-3.1.1.orig/meson.build
 tracker-miners-3.1.1/meson.build
+@@ -19,7 +19,7 @@ tracker_required = '3.1.0'
+ 
+ if get_option('tracker_core') == 'system'
+   tracker_sparql = dependency('tracker-sparql-3.0', version: '>=' + 
tracker_required, required: false)
+-  tracker_testutils = dependency('tracker-testutils-3.0', required: false)
++  tracker_testutils = dependency('tracker-testutils-3.0', required: false, 
native: true)
+ 
+   if not tracker_sparql.found() or not tracker_testutils.found()
+ error('Did not find the required versions of the Tracker core libraries ' 
+
diff --minimal -Nru tracker-miners-3.1.1/debian/patches/series 
tracker-miners-3.1.1/debian/patches/series
--- tracker-miners-3.1.1/debian/patches/series  2021-08-31 04:49:52.0 
+0200
+++ tracker-miners-3.1.1/debian/patches/series  2021-09-01 18:36:18.0 
+0200
@@ -3,3 +3,4 @@
 debian/Revert-build-Include-libdir-in-rpath.patch
 debian/tracker-extract-meson.build-Set-RPATH-for-the-extract-mod.patch
 seccomp-Allow-64bit-time-functions-on-32bit-systems.patch
+cross.patch

Bug#993455: axc FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: axc
Version: 0.3.5-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

axc fails to cross build from source, because its upstream Makefile hard
codes the build architecture pkg-config in one occasion. It already uses
the standard substitution variable for every other case. Please consider
applying the attached patch to make it cross buildable.

Helmut
--- axc-0.3.5.orig/Makefile
+++ axc-0.3.5/Makefile
@@ -44,7 +44,7 @@
 	 $(LIBGCRYPT_LDFLAGS)
 
 REQPKG=libsignal-protocol-c
-REQPKG:=$(shell pkg-config --exists $(REQPKG) && echo '$(REQPKG)')
+REQPKG:=$(shell $(PKG_CONFIG) --exists $(REQPKG) && echo '$(REQPKG)')
 ifneq ($(REQPKG),)
 	PKGCFG_C += $(SIGNAL_CFLAGS)
 	PKGCFG_L += $(SIGNAL_LDFLAGS)

Bug#937269: peframe: Python2 removal in sid/bullseye

[Sascha Steinbiss]

Hi,


Please feel free to remove it for now, unless someone wants to take over.


Ack. Given that noone stepped up for about a year now, I'll go ahead and file
a removal request.


Fine with me!

Cheers
Sascha

Bug#989720: openvswitch-switch: /etc/network/interfaces seems ignored

[Philippe Latu]

Hello,

Encountered the same issue.

Try to replace 'allow-ovs' by 'auto' at the main ovs bridge level.

###
auto br0
iface br0 inet manual
 ovs_type OVSBridge
 ovs_ports enp7s0 vlan1

hth,

--
- Philippe Latu
--
https://inetdoc.net

Bug#993454: pkg-js-tools: Fix permissions in components : remove -x fr json, js and ts file

[Bastien Roucariès]

Package: pkg-js-tools
Version: 0.9.65
Severity: minor

Dear Maintainer,

.json, .js and .d.ts should have -x bit removed

Thanks

Bastien

Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

severity 993449 important
tag 993449 + moreinfo
tag 993449 + unreproducible
thanks

Hi,

Am Wed, Sep 01, 2021 at 09:56:22AM -0500 schrieb pavel:
> Package: libreoffice-calc
> Version: 1:7.0.4-4
> Severity: critical
> Justification: breaks the whole system

Bulls*.

How does it break booting? How does it break other parts of
the system?

If at all, it'd be "grave".

Read the bug definitions and don't submit overinflated bug reports.

> X-Debbugs-Cc: paul_...@yahoo.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

Yes. Do. That's not there just for fun.
No text here is no real good sign of anything.

Anyways, your mail subject says

 Subject: Re: Bug#993449: libreoffice-calc: Top level tool menu is missing
  text labels and icons for most buttons

You should haver added some explanation here

In any case:

Oh, surprise. Works here fine. (and yes, I tried with gen(eric), gtk3,
qt5 and kde5).

So this is even unreproducible.

Regards,

Rene

Bug#993453: linux-image-5.13.0-trunk-riscv64: please enable CONFIG_NUMA on riscv64

[Adam Borowski]

Package: src:linux
Version: 5.13.12-1~exp1
Severity: wishlist
X-Debbugs-Cc: kilob...@angband.pl

Hi!
Please enable CONFIG_NUMA on riscv64.  The relevant code is there since
kernel 5.12.

While there's no physical hardware with multiple nodes that I know of yet,
the arch is meant to include big machines in the future as well.  As such,
it'd be a waste of our time to change packages multiple times -- let's put
riscv64 to the grown-up section of the arch pool quickly.

A package I maintain (memkind) requires the NUMA API (even if it returns
"1") to function and run tests.  Let's have such stuff working so the
software is in place before hardware comes.

I've tested on a self-built kernel (5.14 at this time), and all seems fine.


Meow!
-- Package-specific info:
** Model information
Device Tree model: SiFive HiFive Unmatched A00

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

Kernel: Linux 5.14.0-00033-gb0138dc69e0e (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#993452: osslsigncode: MSI tests fail on big-endian architectures

[Stephen Kitt]

Package: osslsigncode
Version: 2.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

The MSI tests enabled in 2.2-1 fail on big-endian architectures. This
could be related to the MSI rewrite in 2.2.

012. Sign a MSI file with a certificate and a private key in the PEM format 
failed
022. Sign a MSI file with an encrypted private key in the PEM format
failed
032. Sign a MSI file with an encrypted private key in the DER format
failed
042. Sign a MSI file with a SPC certificate and a PVK private key   
failed
052. Sign a MSI file with a certificate and a key stored in a PKCS#12 container 
failed
072. Sign a MSI file with Authenticode timestamping 
failed
082. Sign a MSI file with RFC 3161 timestamping 
failed
102. Sign a MSI file with addUnauthenticatedBlob
failed
112. Sign a MSI file with the nest flag 
failed
122. Sign a MSI file with a PEM key and a password read from password.txt file  
failed
132. Sign a MSI file with a PKCS#12 container and the file with a password  
failed
142. Sign a MSI file with a descryption 
failed
152. Sign a MSI file with specified URL 
failed
162. Sign a MSI file with the common purpose set
failed
172. Add an additional certificate to the signature block of a MSI file 
failed
212. Sign a MSI file with MD5 set of cryptographic hash functions   
failed
222. Sign a MSI file with SHA1 set of cryptographic hash functions  
failed
232. Sign a MSI file with SHA2 set of cryptographic hash functions  
failed
242. Sign a MSI file with SHA384 set of cryptographic hash functions
failed
252. Sign a MSI file with SHA512 set of cryptographic hash functions
failed
262. Extract the PEM signature from the MSI file
failed
272. Extract the DER signature from the MSI file
failed
312. Attach the DER signature to the MSI file   
failed
322. Attach the PEM signature to the MSI file   
failed
332. Attach the PEM signature to the signed MSI file
failed
342. Attach the PEM signature to the signed MSI file with the nest flag 
failed
352. Remove the signature from the MSI file 
failed
372. Add an authenticode timestamp to the MSI signed file   
failed
382. Add a RFC 3161 timestamp to the MSI signed file
failed
392. Add an unauthenticated blob to the MSI signed file 
failed
402. Compare the leaf hash against SHA256 message digest for the MSI file   
failed
412. Sign a MSI file with the add-msi-dse option
failed
512. Verify MSI file signed after the cert has been expired 
failed
522. Verify a MSI file signed with Authenticode after the cert has been expired 
failed
532. Verify a MSI file signed with RFC3161 after the cert has been expired  
failed
542. Verify a MSI file signed with the expired cert 
failed
552. Verify a MSI file signed with the revoked cert 
failed
562. Verify a MSI file signed with the multiple signature   
failed

See
https://buildd.debian.org/status/fetch.php?pkg=osslsigncode=s390x=2.2-1=1630508632=0
for the complete logs.

Regards,

Stephen

-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
'oldstable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 
'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages osslsigncode 

Bug#910482: libmagickcore-6.q16-6-extra: SVG error messages and/or rendering errors if inkscape not installed

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + moreinfo unreproducible

Hi Alan,

On Sat, 06 Oct 2018 19:21:50 -0700 "Alan W. Irwin"  
wrote:
> With libmagickcore-6.q16-6-extra installed, "display" (symlinked to
> display-im6.q16) renders validated SVG files incorrectly or not at all
> (exited with
> 
> "display-im6.q16: non-conforming drawing primitive definition `path' @ 
> error/draw.c/DrawImage/4216."
> 
> ) if inkscape is not installed.  Therefore, since inkscape is so
> essential for processing SVG files I suggest that inkscape be promoted from 
> "Suggests:"
> to "Recommends:" for libmagickcore-6.q16-6-extra or else the package 
> description should
> mention that inkscape is essential to SVG success.

I'm not able to reproduce your problem with the version of imagemagick
currently in unstable. Can you post a SVG file that exhibits the problem?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#993451: osslsigncode: timestamp-based tests fail on amd64 (sometimes)

[Stephen Kitt]

Package: osslsigncode
Version: 2.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

The tests enabled in 2.2-1 failed on amd64 on the buildd:

071. Sign a CAT file with Authenticode timestamping 
failed
072. Sign a MSI file with Authenticode timestamping 
failed
073. Sign a CAB file with Authenticode timestamping 
failed
074. Sign a PE file with Authenticode timestamping  
failed
081. Sign a CAT file with RFC 3161 timestamping 
failed
082. Sign a MSI file with RFC 3161 timestamping 
failed
083. Sign a CAB file with RFC 3161 timestamping 
failed
084. Sign a PE file with RFC 3161 timestamping  
failed
371. Add an authenticode timestamp to the CAT signed file   
failed
372. Add an authenticode timestamp to the MSI signed file   
failed
373. Add an authenticode timestamp to the CAB signed file   
failed
374. Add an authenticode timestamp to the PE signed file
failed
381. Add a RFC 3161 timestamp to the CAT signed file
failed
382. Add a RFC 3161 timestamp to the MSI signed file
failed
383. Add a RFC 3161 timestamp to the CAB signed file
failed
384. Add a RFC 3161 timestamp to the PE signed file 
failed
464. Verify changed PE file after signing with Authenticode timestamping
failed
474. Verify changed PE file after signing with RFC 3161 timestamping
failed
521. Verify a CAT file signed with Authenticode after the cert has been expired 
failed
522. Verify a MSI file signed with Authenticode after the cert has been expired 
failed
523. Verify a CAB file signed with Authenticode after the cert has been expired 
failed
524. Verify a PE file signed with Authenticode after the cert has been expired  
failed
531. Verify a CAT file signed with RFC3161 after the cert has been expired  
failed
532. Verify a MSI file signed with RFC3161 after the cert has been expired  
failed
533. Verify a CAB file signed with RFC3161 after the cert has been expired  
failed
534. Verify a PE file signed with RFC3161 after the cert has been expired   
failed
541. Verify a CAT file signed with the expired cert 
failed
542. Verify a MSI file signed with the expired cert 
failed
543. Verify a CAB file signed with the expired cert 
failed
544. Verify a PE file signed with the expired cert  
failed
551. Verify a CAT file signed with the revoked cert 
failed
552. Verify a MSI file signed with the revoked cert 
failed
553. Verify a CAB file signed with the revoked cert 
failed
554. Verify a PE file signed with the revoked cert  
failed
562. Verify a MSI file signed with the multiple signature   
failed
563. Verify a CAB file signed with the multiple signature   
failed
564. Verify a PE file signed with the multiple signature
failed

See
https://buildd.debian.org/status/fetch.php?pkg=osslsigncode=amd64=2.2-1=1630508600=0
for the complete logs.

Regards,

Stephen


-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
'oldstable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 
'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages osslsigncode depends on:
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4+deb10u2
ii  libglib2.0-0 2.58.3-2+deb10u3
ii  libgsf-1-114 1.14.45-1
ii  

Bug#993450: golang-1.17-go: Can't compile golang.org/x/tools/imports, undefined defaultGOARCH in internal/buildcfg

[Matthew Gabeler-Lee]

Package: golang-1.17-go
Version: 1.17-2
Severity: important

It seems like the binary packages for 1.17-2 were somehow built wrong. Some
build-time generated code that would have defined defaultGOARCH and other
constants doesn't seem to have been generated & built, resulting in some
built-in packages being un-compilable.

This manifested for me with some build tooling, but I've narrowed it down to
this minimal reproducer:

package main
import _ "golang.org/x/tools/imports"
func main() {}

Trying to compile this results in errors:

# internal/buildcfg
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:25:29: undefined: defaultGOARCH
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:26:27: undefined: defaultGOOS
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:27:28: undefined: defaultGO386
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:33:13: undefined: defaultGO_LDSO
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:34:13: undefined: version
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:56:9: undefined: defaultGOARM
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:74:30: undefined: defaultGOMIPS
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:79:9: undefined: defaultGOMIPS
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:83:32: undefined: defaultGOMIPS64
/usr/lib/go-1.17/src/internal/buildcfg/exp.go:32:29: undefined: 
defaultGOEXPERIMENT
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:83:32: too many errors

Pulling 1.17-1 from snapshot.debian.org, it does not reproduce this. There's
only one meaningful commit on salsa between the two, though it's not clear
to me how it would produce this issue.

I tried building 1.17-2 locally from salsa commit 9a929cf2, and my locally
built packages also do not reproduce this issue, so it seems that there was
somehow simply an error in the build process for the official packages.

-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages golang-1.17-go depends on:
ii  golang-1.17-src  1.17-2
ii  libc62.31-13

Versions of packages golang-1.17-go recommends:
ii  g++ 4:10.2.1-1
ii  gcc 4:10.2.1-1
ii  libc6-dev   2.31-13
ii  pkg-config  0.29.2-1

Versions of packages golang-1.17-go suggests:
pn  bzr | brz
ii  ca-certificates  20210119
ii  git  1:2.33.0-1
pn  mercurial
pn  subversion   

-- no debconf information

Bug#993311: Support for cgroup v2 via cgroup-tools

[Thomas Goirand]

On 8/31/21 3:40 PM, Santiago Ruano Rincón wrote:
> El 31/08/21 a las 14:45, Thomas Goirand escribió:
>> Hi Santiago,
>>
>> Thanks for this bug report, I'll be working on it.
> 
> Thanks!
> 
>>
>> On 8/30/21 5:19 PM, Santiago Ruano Rincón wrote:
>>> To know if cgroup v2 is supported, one way is to
>>> `grep cgroup2 /proc/mounts`
>>
>> I am really unsure about this. On Bullseye, for example, we do have
>> cgroup2 mounted just like in Sid, though the new syntax wont work. What
>> we need here is a way to tell what version of the cgset/cgcreate
>> userland binary is there, preferably with something distribution agnostic...
> 
> Mmm, you need to make sure of two things: 1) the version of cgroup fs
> available in the system, and 2) the version of cgroup-tools (which is
> independent of 1)). You can install cgroup-tools without
> mounting any cgroup file system, so I don't think knowing the version of
> cgset/cgcreate is a fully reliable solution.
> 
> For 2), I'd prefer a versioned Depends on cgroup-tools (>= 2.0-2).

That's not what I'm looking for. I'm looking for a way, in the upstream
Cinder, to detect what's going on. So this cannot be Debian (or any
other OS) specific.

>> Maybe the only way is to just attempt the old style cgset, see if it
>> fails, and if it does, do v2 style cgset?
> 
> For 1), I'd chose to test v2 first, and then v1. Remember that v1 is not
> mounted by default.

Yeah, definitively, the mounted cgroups needs to be tested too...

> If you can propose a better way, I am all ears.

Unfortunately, cgcreate / cgset don't output their version with -v :/

Thomas

Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"

[pk]

Thank you for answering. kernel.unprivileged_userns_clone = 1 on my
machine and on the Live DVD. All instructions of the README.Debian.gz
were followed.

To rule out machine-specific misconfiguration, this log is from the
Live DVD, Debian 11.0 AMD64 Standard:



Warning: Permanently added '[localhost]:12346' (ECDSA) to the list of
known hosts.
user@localhost's password:
Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
user@debian:~$ sudo su -l
root@debian:~# apt-get update ; apt-get install lxc
[snip]
root@debian:~# sysctl kernel.unprivileged_userns_clone
kernel.unprivileged_userns_clone = 1
root@debian:~# grep user /etc/subuid /etc/subgid
/etc/subuid:user:10:65536
/etc/subgid:user:10:65536
root@debian:~#
logout
user@debian:~$ mkdir -p .local/share/lxc
user@debian:~$ chmod +x . .local .local/share
user@debian:~$
user@debian:~$ cat > test_config
  lxc.idmap = u 0 10 65536
  lxc.idmap = g 0 10 65536
  lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
  lxc.apparmor.profile = unconfined
user@debian:~$
user@debian:~$   systemd-run --scope --quiet --user
--property=Delegate=yeslxc-start --logfile /dev/stderr -f
test_config -n machine
lxc-start machine 20210901150740.103 ERRORutils -
utils.c:safe_mount:1204 - Permission denied - Failed to mount "proc"
onto "/proc"
lxc-start machine 20210901150740.104 ERRORconf -
conf.c:lxc_mount_auto_mounts:681 - Permission denied - Failed to mount
"proc" on "/proc" with flags 14
lxc-start machine 20210901150740.104 ERRORconf -
conf.c:lxc_setup:3330 - Failed to setup first automatic mounts
lxc-start machine 20210901150740.105 ERRORstart -
start.c:do_start:1218 - Failed to setup container "machine"
lxc-start machine 20210901150740.106 ERRORsync -
sync.c:__sync_wait:36 - An error occurred in another process (expected
sequence number 5)
lxc-start machine 20210901150740.106 ERRORstart -
start.c:__lxc_start:1999 - Failed to spawn container "machine"
lxc-start machine 20210901150740.107 ERRORlxccontainer -
lxccontainer.c:wait_on_daemonized_start:859 - Received container state
"ABORTING" instead of "RUNNING"
lxc-start: machine: lxccontainer.c: wait_on_daemonized_start: 859
Received container state "ABORTING" instead of "RUNNING"
lxc-start machine 20210901150740.108 ERRORlxc_start -
tools/lxc_start.c:main:308 - The container failed to start
lxc-start: machine: tools/lxc_start.c: main: 308 The container failed to start
lxc-start machine 20210901150740.108 ERRORlxc_start -
tools/lxc_start.c:main:311 - To get more details, run the container in
foreground mode
lxc-start: machine: tools/lxc_start.c: main: 311 To get more details,
run the container in foreground mode
lxc-start machine 20210901150740.108 ERRORlxc_start -
tools/lxc_start.c:main:313 - Additional information can be obtained by
setting the --logfile and --logpriority options
lxc-start: machine: tools/lxc_start.c: main: 313 Additional
information can be obtained by setting the --logfile and --logpriority
options
user@debian:~$  sudo su -l
root@debian:~# dmesg | tail
[  294.416862] audit: type=1400 audit(1630508543.972:7):
apparmor="STATUS" operation="profile_replace" info="same as current
profile, skipping" profile="unconfined" name="lsb_release" pid=2444
comm="apparmor_parser"
[  294.526095] audit: type=1400 audit(1630508544.084:8):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/bin/man" pid=2442 comm="apparmor_parser"
[  294.527098] audit: type=1400 audit(1630508544.084:9):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="man_filter" pid=2442 comm="apparmor_parser"
[  294.528359] audit: type=1400 audit(1630508544.084:10):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="man_groff" pid=2442 comm="apparmor_parser"
[  297.864908] audit: type=1400 audit(1630508547.412:11):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="lxc-container-default" pid=2618 comm="apparmor_parser"
[  297.867516] audit: type=1400 audit(1630508547.416:12):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="lxc-container-default-cgns" pid=2618 comm="apparmor_parser"
[  297.869845] audit: type=1400 audit(1630508547.420:13):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="lxc-container-default-with-mounting" pid=2618
comm="apparmor_parser"
[  297.872902] audit: type=1400 audit(1630508547.420:14):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="lxc-container-default-with-nesting" pid=2618
comm="apparmor_parser"
[  297.933031] audit: type=1400 audit(1630508547.480:15):
apparmor="STATUS" operation="profile_load" profile="unconfined"

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Russ Allbery]

Ansgar  writes:
> On Wed, 2021-09-01 at 11:15 +0200, Helmut Grohne wrote:

>> I believe that the discussion has later identified that doing so would
>> break squid-deb-proxy-client and auto-apt-proxy. Given that the
>> security benefits are not strong (beyond embracing good habits), I
>> think the reasonable thing to do is keep preferring http.

> That is an opt-in choice which likely only a small number of users use.
> People wanting to use a caching proxy can just switch to http as part of
> this choice; it doesn't seem a good reason to not use https by default
> for all other users.

Completely agreed.

>> Caching packages and transport level encryption are fundamentally
>> incompatible.

> No. You can explicitly configure apt to use a local caching mirror or
> use a trusted TLS certificate for the mirror the proxy impersonates.

Yes.  For example, the approach used by apt-cacher-ng works fine.
Explicitly opting in to a local cache seems desirable.

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

Bug#991606: marked as pending in ruby-libxml

[Mattia Rizzolo]

On Tue, Aug 31, 2021 at 10:49:05AM -0400, Sergio Durigan Junior wrote:
> On Tuesday, August 31 2021, Mattia Rizzolo wrote:
> 
> > On Mon, Aug 30, 2021 at 09:54:29PM +, Sergio Durigan Junior wrote:
> >> Bug #991606 in ruby-libxml reported by you has been fixed in the
> >> Git repository and is awaiting an upload. You can see the commit
> >> message below and you can check the diff of the fix at:
> >> 
> >> https://salsa.debian.org/ruby-team/ruby-libxml/-/commit/93e491e68dfef33329834820e45e911d01e3d89c
> >
> > I haven't tried, but doesn't this cause the tests to fail with libxml2
> > << 2.9.12, such as what's currently in unstable?
> 
> Yes, it would cause regressions with libxml2 2.9.10.  This should only
> be uploaded when libxml2 2.9.12 is also uploaded to unstable.  I think I
> should have made it clearer in the changelog; sorry about that.

if that's true, then you likely should add a build-depends on the newer
libxml2.

fwiw, I just uploaded libxml2 2.9.12 to unstable, so please go ahead
with the upload.

-- 
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#924685: RFP: cumin -- An automation and orchestration framework

[Antoine Beaupré]

On 2019-03-16 21:17:52, Moritz Muehlenhoff wrote:
> Antoine Beaupre wrote:
>> Upstream (in CC) already ships Debian packages on their Github
>> releases page, but it would be great to see this in Debian.
>> 
>> I'd be happy to sponsor this package if upstream is willing to act as
>> maintainers, otherwise I will look at packaging this myself.
>
> Hi Antoine,
> thanks for your interest in Cumin :-)
>
> We're totally planning to maintain Cumin in Debian, but there's a
> few breaking changes lined up we don't want to impose on Debian
> users (plus NEW is frozen anyway), so this will probably only
> happen in a few months at the start of the bullseye development cycle.

Hi!

NEW was thawed, and I just reinstalled cumin in a virtualenv, and
thought of this bug. :) Need help with the packaging? I'd be happy to
just throw it in the python packaging team...

a.

-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#955540: chromium: Using ozone

[Bastian Germann]

On Sat, 6 Mar 2021 15:50:44 +0100 Guillem Jover  wrote:

On Thu, 2021-01-21 at 16:31:29 +0100, Michel Le Bihan wrote:
> I built Chromium with ozone, but I'm not sure if it's ready for Debian
> yet. It will need testing. You can test it, if you want:
> https://lebihan.pl/chromium/chromium_88.0.4324.96-ozone.tar
> Currently, I only built for amd64.

Could you provide the patch needed to build with Ozone enabled? Even
if it's trivial (which I assume it might be), it might make it easier
for the maintainers to simply apply it?

Missing Ozone support means Chromium currently has bogus behavior with
its tab handling, and it shows artifacts when watching videos in
fullscreen mode in Wayland, so it would be nice to get this support
uploaded, even if into experimental. I was having the same exact
artifacts with Firefox using Xwayland, and enabling its Wayland support,
made these disappear.


With the now-stable version 93, ozone is the default. Please import that 
version.

Bug#993448: ITP: cutefish-core -- Cutefish core system components and backend

[Arun Kumar Pariyar]

Package: wnpp
Severity: wishlist
Owner: Arun Kumar Pariyar 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name : cutefish-core
Version : 0.4
Upstream Author : Reion Wong 
* URL : https://github.com/cutefishos/core
* License : GPL-3+
Programming Lang: C++
Description : Cutefish core system components and backend

Cutefish core system components and backend for Cutefish desktop 
environment.

.
This package is a part of the Cutefish DE.



OpenPGP_0x4B542AF704F74516.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990428: ifenslave: Bonding not working on bullseye (using bond-slaves config)

[Claudio Kuenzler]

> In your case you could simply remove the stanzas for enp4s0f0 and enp4s0f1 
> which would leave you with just the stanza for bond1:

> iface bond1 inet static
>   bond-slaves enp4s0f0 enp4s0f1

Thank you Oleander. It works with this hint (the physical interfaces
were left out of the config).
Working config:
=
ck@bullseye:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
  address 192.168.12.4/24
  gateway 192.168.12.1
  bond-slaves enp3s0f0 enp3s0f1
  bond-mode 802.3ad
  bond-miimon 100
  bond-lacp-rate 1
=

> That should work but it is still a regression as it breaks configuration 
> which worked before.

Yes, agree. Do you know if your patch (I have not tested) will be
included in the next point release?

> https://serverfault.com/a/1075192/267378
>
> Best regards,
> Arunas

You mention both bond-master of the physical devices and blond-slaves
on the bond interface. This causes networking service to hiccup in my
case:

Sep 01 15:58:23 irczsrvp09 systemd[1]: Starting Raise network interfaces...
Sep 01 15:58:23 irczsrvp09 ifup[1251]: No iface stanza found for master bond0
Sep 01 15:58:23 irczsrvp09 ifup[1249]: run-parts:
/etc/network/if-pre-up.d/ifenslave exited with return code 1
Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp3s0f0
Sep 01 15:58:23 irczsrvp09 ifup[1256]: No iface stanza found for master bond0
Sep 01 15:58:23 irczsrvp09 ifup[1254]: run-parts:
/etc/network/if-pre-up.d/ifenslave exited with return code 1
Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp3s0f1
Sep 01 15:58:23 irczsrvp09 ifup[1261]: No iface stanza found for master bond1
Sep 01 15:58:23 irczsrvp09 ifup[1259]: run-parts:
/etc/network/if-pre-up.d/ifenslave exited with return code 1
Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp4s0f0
Sep 01 15:58:23 irczsrvp09 ifup[1266]: No iface stanza found for master bond1
Sep 01 15:58:23 irczsrvp09 ifup[1264]: run-parts:
/etc/network/if-pre-up.d/ifenslave exited with return code 1
Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp4s0f1

Although the bonding interface seems to work with your workaround, the
Systemd service (networking) is stuck at failed state.

So for now the "proper" way to fix this seems to be to remove the
physical device stanzas and only use the bonding interfaces - until
this bug is fixed.

Bug#993447: O: argagg -- Argument Aggregator - Simple C++11 command line argument parser

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: arg...@packages.debian.org
Control: affects -1 src:argagg

I have orphaned the argagg package for reasons independant of this package, or
of Debian.

The package description is:
 This is yet another C++ command line argument/option parser. It was
 written as a simple and idiomatic alternative to other frameworks like
 getopt, Boost program options, TCLAP, and others. The goal is to achieve
 the majority of argument parsing needs in a simple manner with an easy
 to use API. It operates as a single pass over all arguments, recognizing
 flags prefixed by - (short) or -- (long) and aggregating them into easy
 to access structures with lots of convenience functions. It defers
 processing types until you access them, so the result structures end up
 just being pointers into the original command line argument C-strings.
 .
 argagg supports POSIX recommended argument syntax conventions.

Bug#993446: ITP: r-cran-geoknife -- GNU R web-processing of large gridded datasets

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-geoknife -- GNU R web-processing of large gridded datasets
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-geoknife
  Version : 1.6.5
  Upstream Author : Jordan Read,
* URL : https://cran.r-project.org/package=geoknife
* License : CC0
  Programming Lang: GNU R
  Description : GNU R web-processing of large gridded datasets
 Processes gridded datasets found on the U.S. Geological Survey Geo Data
 Portal web application or elsewhere, using a web-enabled workflow that
 eliminates the need to download and store large datasets that are
 reliably hosted on the Internet. The package provides access to several
 data subset and summarization algorithms that are available on remote
 web processing servers (Read et al. (2015) ).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-geoknife

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Control: tag -1 pending

Hi,

FYI I have uploaded shutter to NEW yesterday.

-- 
Cheers,
  Andrej

Bug#993128: libvpx6: Unable to use camera or share screen on WebRTC conferences

[Jan Hasebos]

Hello Ramacher,


Could you please retry with 1.10.0-2 which is now available in unstable?


This new version fixed encoding VP8 with ffmpeg for me. I no longer get 
the "ABI version mismatch" error. Thank you!


~ Jan

Bug#993445: RFS: python-sense-hat/2.2.0-3 -- Sense HAT python library (Python 3)

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-sense-hat":

 * Package name: python-sense-hat
   Version : 2.2.0-3
   Upstream Author : https://github.com/astro-pi/python-sense-hat
 * URL : https://github.com/astro-pi/python-sense-hat
 * License : BSD-3-Clause
 * Vcs : https://salsa.debian.org/raspi-team/python-sense-hat
   Section : python

It builds those binary packages:

  python3-sense-hat - Sense HAT python library (Python 3)

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


  https://mentors.debian.net/package/python-sense-hat/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-sense-hat/python-sense-hat_2.2.0-3.dsc

Changes for the initial release:

 python-sense-hat (2.2.0-3) unstable; urgency=medium
 .
   * Initial Debian release.

Regards,
--
  Dave Jones

Bug#993370: RFP: rg-el -- elpa-rg

[Antoine Beaupré]

On 2021-08-31 23:47:26, Nicholas D. Steeves wrote:

[...]

> If you think the process might be interesting content for
> Debian Planet, please let me know :-)

That would be interesting, for sure, but no pressure. :)

>> I'm not actually sure why Nicholas picked rg.el.
>
> I can update this bug with my rationale (from IRC) if you think it would
> be useful to others.

That, however, seems like an important thing to document here, for
posterity.

a.

-- 
Brief is this existence, as a fleeting visit in a strange house.
The path to be pursued is poorly lit by a flickering consciousness.
   - Albert Einstein

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[jiho lee]

When I received the shutter in preparation for packaging from
salsa.debian.org and packaged it, there was a dependency problem in the
following.

gir1.2-appindicator3-0.1
libgtk3-imageview-perl

gir1.2-appindicator3-0.1 required the libappindicator3-1 package, which is
not currently included in bullseye.

For packaging test, I got the deb file of libappindicator3-1 from buster
and installed it. I needed the libindicator3-7 package for the
libappindicator3-1 package.

The libappindicator3-1 package in the Debian buster has been removed from
bullseye, so if you don't include the libappindicator3-1 package in
bullseye again, it would be a good idea to remove gir1.2-appindicator3-0.1
from shutter's control.

The gir1.2-appindicator3-0.1 package is used to display an icon in the
gnome panel when shutter is executed. However, the shutter itself works
normally even without the gir1.2-appindicator3-0.1 package, so it would be
better to remove it from the control file.

The libgtk3-imageview-perl package requires version 9, but since version 6
is included in bullseye, there is a problem with installation after
packaging.

It seems that the libgtk3-imageview-perl version should also be updated for
the stable distribution of shutter.

We will be happy to wait for shutter to be uploaded to the Debian
repository.


There is a future society, but my future is not what others do.
Dept. of Information Science, Graduate School, Korea National Open
University


2021년 8월 29일 (일) 오후 9:00, Michael Kogan 님이 작성:

> Am So., 29. Aug. 2021 um 13:51 Uhr schrieb Andrej Shadura <
> and...@shadura.me>:
>
>> Thanks very much for your offer, but at the moment the only thing
>> blocking it is me uploading the package :) The extra dependency is now in
>> Debian, so I can proceed with uploading Shutter too before I go on my
>> holiday.
>>
>> --
>> Cheers,
>>   Andrej
>>
>
> That's great news, thanks for the update!
>

Bug#993430: closed by Debian FTP Masters (reply to Jeremy Bicha ) (Bug#993430: fixed in gedit 40.1-2)

[Michael Biebl]

Am 01.09.21 um 13:51 schrieb Debian Bug Tracking System:

This is an automatic notification regarding your Bug report
which was filed against the tracker package:

#993430: Breaks nautilus  Settings schema 'org.freedesktop.Tracker.Miner.Files' 
is not installed

It has been closed by Debian FTP Masters  (reply to 
Jeremy Bicha ).


Looks like there is still a breaks missing in tracker3 against older 
nautilus versions?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#993444: libxml-sax-perl: Reproducible content for 'update-perl-sax-parsers'

[Roland Clobus]

Package: libxml-sax-perl
Version: 1.02+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hello maintainers for libxml-sax-perl,

While working on the “reproducible builds” effort [1], I have noticed
that the output of the script 'update-perl-sax-parsers' is not stable.

You can reproduce this with the following snippet:
mkdir test
PERL_HASH_SEED=0 update-perl-sax-parsers --directory test --file
test/ParserDetails.ini --add XML::SAX::Expat --priority 10
mv test/10-XML\:\:SAX\:\:Expat seed0
PERL_HASH_SEED=42 update-perl-sax-parsers --directory test --file
test/ParserDetails.ini --add XML::SAX::Expat --priority 10
mv test/10-XML\:\:SAX\:\:Expat seed42
md5sum seed*

After issuing the add command, the generated ini file has a random order for
its keys. See [2] for more information.

The attached patch sorts the keys prior to writing the file.
Once applied, it will be possible for the live-build live image with the
Cinnamon desktop to be built reproducibly.

With kind regards,
Roland Clobus

 [1]: https://wiki.debian.org/ReproducibleBuilds
 [2]: https://reproducible-builds.org/docs/stable-outputs/

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

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

Versions of packages libxml-sax-perl depends on:
ii  libxml-namespacesupport-perl  1.12-1.1
ii  libxml-sax-base-perl  1.09-1.1
ii  perl  5.32.1-5
ii  ucf   3.0043

Versions of packages libxml-sax-perl recommends:
ii  libwww-perl6.53-1
ii  libxml-sax-expat-perl  0.51-1

libxml-sax-perl suggests no packages.
diff --git a/debian/patches/series b/debian/patches/series
index 14b0514..006daf5 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ charset-decoding
 parserdetails-debian
 pod-spelling
 Fix-another-typo-in-POD.patch
+sort-ini-entries
diff --git a/debian/patches/sort-ini-entries b/debian/patches/sort-ini-entries
new file mode 100644
index 000..a3dc595
--- /dev/null
+++ b/debian/patches/sort-ini-entries
@@ -0,0 +1,14 @@
+From: Roland Clobus 
+Date: Wed, 1 Sep 2021 15:10:00+0200
+Subject: Sort the entries in the .ini-files. This generates the files with a 
constant content
+--- a/lib/XML/SAX/Debian.pm
 b/lib/XML/SAX/Debian.pm
+@@ -31,7 +31,7 @@
+ 
+ foreach my $p (@{ $class->parsers }) {
+ print $fh "[$p->{Name}]\n";
+-foreach my $key (keys %{$p->{Features}}) {
++foreach my $key (sort keys %{$p->{Features}}) {
+ print $fh "$key = $p->{Features}{$key}\n";
+ }
+ print $fh "\n";

Bug#968980: installation-reports: systemctl status networking.service "failed" but Wicd works fine (LXDE)

[Fernando Trebien]

On Sun, 22 Nov 2020 05:44:04 + Avinash Sonawane  wrote:
> On Tue, 25 Aug 2020 01:42:52 -0300 nora-v  wrote:
> > $ systemctl status networking.service
> > ● networking.service - Raise network interfaces
> >Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
> > prese
> >Active: failed (Result: exit-code) since Mon 2020-08-24 22:41:10 -03; 2h 
> > 54mi
> >  Docs: man:interfaces(5)
> >  Main PID: 423 (code=exited, status=1/FAILURE)
> >
> > And also:
> >
> > $ cat /etc/network/interfaces
> > source-directory /etc/network/interfaces.d
> > $ cat /etc/network/interfaces.d/setup
> > auto lo
> > iface lo inet loopback
> >
> > auto eth0
> > iface eth0 inet dhcp
>
> I experienced this exact same issue with this exact
> /etc/network/interfaces.d/setup file contents with Debian 10.6.0 live
> XFCE non-free iso fetched from
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current-live/amd64/iso-hybrid/debian-live-10.6.0-amd64-xfce+nonfree.iso
>
> I fixed it with this command:
> $ sudo sed -i 's/eth0/enp1s0/g' /etc/network/interfaces.d/setup
>
> where I found `enp1s0` in `$ ip l` output.

This issue has been around since Stretch, [1] when the modern network
interface names became default. So, another workaround is to comment
out the lines in /etc/network/interfaces.d/setup that reference old
network interface names like eth0. Maybe this can be considered a bug
and the installer should not generate those lines.

[1] 
https://unix.stackexchange.com/questions/390307/startup-debian-9-error-failed-to-start-raise-network-interfaces

Bug#993443: RFS: rtimulib/7.2.1-6 [ITP] -- Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU library (Python 3)

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "rtimulib":

 * Package name: rtimulib
   Version : 7.2.1-6
   Upstream Author : https://github.com/RPi-Distro/RTIMULib
 * URL : https://github.com/richards-tech/RTIMULib
 * License : MIT, GPL-3.0+, BSD-2-Clause
 * Vcs : https://salsa.debian.org/python-team/packages/rtimulib
   Section : libs

It builds those binary packages:

  python3-rtimulib - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (Python 3)
  librtimulib-utils - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (utilities)
  librtimulib-dev - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (dev files)
  librtimulib7 - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU library 
(shared library)

These packages are pre-requisites for support of the Raspberry Pi Sense 
HAT in Debian (though RTIMULib is more general as is applicable to many 
different IMUs).


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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/r/rtimulib/rtimulib_7.2.1-6.dsc

Changes for the initial release:

 rtimulib (7.2.1-6) unstable; urgency=medium
 .
   * Initial Debian release.

Regards,
-- Dave Jones

Bug#993177: RFS: dtkwidget/5.5.17.1-1~exp1 -- dtkwidget-examples is generated by dtkwidget

[Adam Borowski]

On Wed, Sep 01, 2021 at 10:57:45AM +0800, clay stan wrote:
> Adam Borowski  于2021年8月31日周二 上午10:27写道：
> > On Tue, Aug 31, 2021 at 09:12:52AM +0800, clay stan wrote:
> > > Adam Borowski  于2021年8月30日周一 下午4:17写道：
> > > > On Sat, Aug 28, 2021 at 08:12:20PM +0800, clay stan wrote:
> > > > >  dtkwidget (5.5.17.1-1~exp1) experimental; urgency=medium
> > > > >  .
> > > > >* New upstream version 5.5.17.1.

> Has rebuild and reupload to mentors.
> After discussion, our team(pkg-deepin) decided to remove the symbols,
> Because  all deepin packages are maintained by our team (pkg-deepin),
> So symbols of dtk(deepin toolkit) projects are meaningless.

Actually, symbols are meant for auto-generating versions in Depends: field,
to tell the minimal version of the library that matches the ABI.  But,
managing symbols for C++ code is notoriously hard, thus dropping them is
not a problem.

There's another issue, though.  The packaging includes a number of changes
that are not mentioned in the changelog -- and at least adding a new binary
package requires a different type of upload.

Thus: please mention packaging changes inside debian/changelog.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant:
⣾⠁⢠⠒⠀⣿⡁   Reverently made for universal free distribution by Wang Jie
⢿⡄⠘⠷⠚⠋⠀   on behalf of his two parents on the 15th of the 4th moon of
⠈⠳⣄   the 9th year of Xiantong [11 May 868].

Bug#993442: ITP: golang-github-charmbracelet-glamour -- stylesheet-based Markdown rendering for your CLI apps

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-charmbracelet-glamour
  Version : 0.3.0-1
  Upstream Author : Charmbracelet, Inc.
* URL : https://github.com/charmbracelet/glamour
* License : Expat
  Programming Lang: Go
  Description : stylesheet-based Markdown rendering for your CLI apps (Go 
library)

 glamour lets you render Markdown documents and templates on ANSI-compatible
 terminals.  You can create your own stylesheet or simply use one of the
 stylish defaults.

Reason for packaging:
 golang-github-charmbracelet-glamour-dev is a prerequisite of gh (GitHub CLI)

Bug#993441: kleopatra: Creates unsafe ~/.gnupg when not already present

[Diederik de Haas]

Package: kleopatra
Version: 4:21.08.0-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

I had previously 'improved' my gnupg configuration, but that is (now)
deprecated.
So I moved my ~/.gnupg directory to a backup location to start anew.

If I then start Kleopatra, but don't do anything with it, that directory
gets created, but with the wrong permissions:
diederik@bagend:~$ stat .gnupg/
  File: .gnupg/
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 10304h/66308d   Inode: 12845182Links: 3
Access: (0755/drwxr-xr-x)  Uid: ( 1000/diederik)   Gid: ( 1000/diederik)

Running a gpg command from a Konsole window reports the issue:
diederik@bagend:~$ gpg --list-keys
gpg: WARNING: unsafe permissions on homedir '/home/diederik/.gnupg'


If I uninstall Kleopatra and remove the ~/.gnupg directory (again) and
then do 'gpg --list-keys', I get:
diederik@bagend:~$ gpg --list-keys
gpg: directory '/home/diederik/.gnupg' created
gpg: keybox '/home/diederik/.gnupg/pubring.kbx' created
gpg: /home/diederik/.gnupg/trustdb.gpg: trustdb created
diederik@bagend:~$ stat .gnupg/
  File: .gnupg/
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 10304h/66308d   Inode: 12845180Links: 2
Access: (0700/drwx--)  Uid: ( 1000/diederik)   Gid: ( 1000/diederik)

So Kleopatra creates ~/.gnupg with incorrect permissions when the
directory doesn't exist.

Cheers,
  Diederik

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages kleopatra depends on:
ii  dirmngr2.2.27-2
ii  gnupg  2.2.27-2
ii  gpgsm  2.2.27-2
ii  libassuan0 2.5.5-1
ii  libc6  2.31-17
ii  libgcc-s1  11.2.0-3
ii  libgpg-error0  1.42-3
ii  libgpgme11 1.16.0-1
ii  libgpgmepp61.16.0-1
ii  libkf5codecs5  5.85.0-2
ii  libkf5configcore5  5.85.0-2
ii  libkf5configgui5   5.85.0-2
ii  libkf5configwidgets5   5.85.0-2
ii  libkf5coreaddons5  5.85.0-2
ii  libkf5crash5   5.85.0-2
ii  libkf5dbusaddons5  5.85.0-2
ii  libkf5i18n55.85.0-2
ii  libkf5iconthemes5  5.85.0-2
ii  libkf5itemmodels5  5.85.0-2
ii  libkf5libkleo5 [libkf5libkleo5-21.08]  4:21.08.0-1
ii  libkf5mime5abi1 [libkf5mime5-21.08]21.08.0-1
ii  libkf5notifications5   5.85.0-3
ii  libkf5textwidgets5 5.85.0-2
ii  libkf5widgetsaddons5   5.85.0-2
ii  libkf5windowsystem55.85.0-2
ii  libkf5xmlgui5  5.85.0-3
ii  libqgpgme7 1.16.0-1
ii  libqt5core5a   5.15.2+dfsg-10
ii  libqt5dbus55.15.2+dfsg-10
ii  libqt5gui5 5.15.2+dfsg-10
ii  libqt5network5 5.15.2+dfsg-10
ii  libqt5printsupport55.15.2+dfsg-10
ii  libqt5widgets5 5.15.2+dfsg-10
ii  libstdc++6 11.2.0-3
ii  paperkey   1.6-1
ii  pinentry-qt1.1.1-1

kleopatra recommends no packages.

kleopatra suggests no packages.

-- no debconf information

Bug#993128: libvpx6: Unable to use camera or share screen on WebRTC conferences

[Paulo]

On Tue, 31 Aug 2021 18:10:36 +0200 Sebastian Ramacher  
wrote:

Control: tags -1 moreinfo

On 2021-08-27 12:10:14 -0300, Paulo Roberto Alves de Oliveira (aka kretcheu) 
wrote:
> Package: libvpx6
> Version: 1.10.0-1
> Severity: important
> Tags: a11y
> 
> Dear Maintainer,
> 
> When we try do use camera or share screen on WebRTC like, Jitsi, GoogleMeeting, it's not working.
> 
> Running Chromium on terminal we can see many error messages:
> 
> ERROR:video_stream_encoder.cc(1729)] Failed to encode frame. Error code: -7
> 
> Downgrading to version 1.9.0-1 it's working again.


Could you please retry with 1.10.0-2 which is now available in unstable?

Cheers

> 
> Thank's
> 
> 
> -- System Information:

> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)

> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE not 
set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libvpx6 depends on:

> ii  libc6  2.31-17
> 
> libvpx6 recommends no packages.
> 
> libvpx6 suggests no packages.
> 
> -- no debconf information
> 


--
Sebastian Ramacher



Hi Sebastian,

It's working again, normal using Chromium and Firefox.

For me you could (Closes: #993128).

Thank you.

Bug#993430: Breaks nautilus: Settings schema 'org.freedesktop.Tracker.Miner.Files' is not installed

[Simon McVittie]

Control: reopen -1
Control: reassign -1 tracker-miner-fs 3.1.1-3
Control: tags -1 = bookworm sid
Control: block 993052 by -1

On Wed, 01 Sep 2021 at 11:51:02 +, Debian Bug Tracking System wrote:
> The latest update of tracker seems to have broken nautilus (which is
> still at version 3.38.2-1 here, has I have plugins like
> nautilus-nextcloud which haven't been updated yet).

tracker-miner-fs (>= 3) needs a Breaks: nautilus (<< 40) for this.
Older nautilus relied on tracker-miner-fs providing the version 2 schema.

smcv

Bug#990301: /usr/bin/identify-im6.q16: identify not following requested format for some gifs

[Johannes Schauer Marin Rodrigues]

On Fri, 25 Jun 2021 14:37:37 +1000 Brian May  wrote:
> $ identify -format "%w:%h" file.gif
> 480:270480:270480:270480:270
> 
> I only requested the values once, but it gave them to me 4 times. Which
> makes it kind of difficult to parse.
> 
> This only happens for this image file, but no idea what makes it
> special. Looks like an ordinary gif file to me:
> 
> $ file file.gif
> file.gif: GIF image data, version 89a, 480 x 270
> 
> $ ls -l file.gif
> -rw--- 1 brian brian 140074 Jun 25 14:27 file.gif
> 
> I have attached the file to this report. At least I hope I did :-)
> 
> This is what I would expect to see:
> 
> $ identify -format "%w:%h"  /usr/share/tcltk/tk8.6/images/pwrdLogo150.gif
> 97:150

your gif has four frames, so you get the width and height four times.

Maybe you only want to select the first frame? Try:

$ identify -format "%w:%h" 'file.gif[0]'
480:270

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#861073: NMUing dpkg-cross

[Wookey]

On 2021-08-31 21:30 +0200, Helmut Grohne wrote:
> Hi wookey,
> 
> you seem to be busy with non-dpkg-cross things and that's fine. The
> package has a few filed bugs and other minor issues though and I'm
> taking the liberty to NMU it in accordance with the LowNMU list you've
> subscribed to. I'm attaching the full .debdiff of the performed changes.

Thanks Helmut.

I am indeed currently distracted by trying to bottom the Gouffre
Berger (tommorrow if things go to plan). Back on the internet around
13th September.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#879849: libmagickcore-6.q16-3-extra: needs a dependency on librsvg2-bin

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + unreproducible moreinfo

On Thu, 26 Oct 2017 15:11:26 +0200 Brice Goglin  
wrote:
> I tried to convert from svg to png but got an error:
> convert-im6.q16: delegate failed `'rsvg-convert' -o '%o' '%i'' @ 
> error/delegate.c/InvokeDelegate/1919.
> convert-im6.q16: unable to open file `/tmp/magick-14874kBFjssQWoDha': Aucun 
> fichier ou dossier de ce type @ error/constitute.c/ReadImage/544.
> convert-im6.q16: no images defined `hwloc1.png' @ 
> error/convert.c/ConvertImageCommand/3258.
> 
> The description of the "imagemagick-6.q16" says I should install
> "libmagickcore-6.q16-3-extra" for SVG. But it didn't help.
> 
> apt-file found rsvg-convert in package librsvg2-bin which solved
> the issue. So I guess there's a missing dependency somewhere?
> 
> libmagickcore-6.q16-3-extra depends on inkscape,
> but it doesn't force librsvg2-bin.
> I can still uninstall librsvg2-bin without uninstalling
> libmagickcore-6.q16-3-extra
> 
> Given that this package is named "extra" and its description
> says "This package adds support for SVG...", a hard dependency
> on librsvg2-bin might be acceptable?
> 

I'm unable to reproduce this problem. I tried both with a chroot from October
2017 and imagemagick 8:6.9.7.4+dfsg-16 as well with Debian unstable as of today
with imagemagick 8:6.9.11.60+dfsg-1.3. In both cases, the package librsvg2-bin
was not installed but the following worked fine:

$ convert /usr/share/icons/hicolor/scalable/apps/gvim.svg /tmp/out.png

Can you supply an image that exposes this bug?

Thanks!

cheers, josch

signature.asc
Description: signature