date:20220410

Control: reopen -1

On Sat, Apr 02, 2022 at 07:06:04PM +, Debian Bug Tracking System wrote:
> It has been closed by Debian FTP Masters  
> (reply to Daniel Echeverri ).

Thank you for addressing the error propagation. Unfortunately, the
symptom fully persists. The gtk check that you patched didn't actually
fail, so the patched code path is not exercised. Instead, the inner
configure for xhydra itself fails. The exit code of this secondary
configure invocation is ignored. I hope this makes the issue more clear.
In any case, you can use cross builds to trigger the faulty behaviour.
Full logs are available at https://crossqa.debian.net/src/hydra.

Helmut

PS: While the cross build failure also is a (normal) failure, that's not
the issue of this bug.

Bug#1009290: mariadb-server-10.6: Fails to start on live system

2022-04-10 Thread Daniel Lewart

Package: mariadb-server-10.6
Version: 1:10.6.7-3
Severity: important

Debian MariaDB Maintainers,

Live Build (--distribution testing) image from April 2022.
8 GB RAM, so should be plenty of disk space available.

$ sudo apt install mariadb-server-10.6-dbgsym
...
Setting up mariadb-server-10.6 (1:10.6.7-3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → 
/lib/systemd/system/mariadb.service.
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 142.
...

$ sudo journalctl | grep -i mariadb | cut -c58-
[See below]

Perhaps this is similar to:
  #983002 - plocate: does not work with /var on overlayfs
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983002

Please let me know any additional information that you could use.

Thank you!
Daniel Lewart
Urbana, Illinois
---
2022-04-10 22:53:02 0 [Warning] InnoDB: Retry attempts for writing partial data 
failed.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Write to file ./ibdata1 failed at offset 
0, 1048576 bytes should have been written, only 0 were written. Operating 
system error number 22. Check that your OS and file system support files of 
this size. Check also that the disk is not full or a disk quota exceeded.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
2022-04-10 22:53:02 0 [ERROR] InnoDB: Could not set the file size of 
'./ibdata1'. Probably out of disk space
2022-04-10 22:53:02 0 [ERROR] InnoDB: Database creation was aborted with error 
Generic error. You may need to delete the ibdata1 file before trying to start 
up again.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 22 in a 
file operation.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS error 
222. Cannot continue operation
220410 22:53:02 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.6.7-MariaDB-3
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467957 K  
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 9 in a file 
operation.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 9 means 'Bad file descriptor'
2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS error 
209. Cannot continue operation
Printing to addr2line failed
/usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x555d0aa77f0e]
/usr/sbin/mariadbd(handle_fatal_signal+0x478)[0x555d0a5c5268]
2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 9 in a file 
operation.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 9 means 'Bad file descriptor'
2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS error 
209. Cannot continue operation
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12200)[0x7f606ba96200]
2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 9 in a file 
operation.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 9 means 'Bad file descriptor'
2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS error 
209. Cannot continue operation
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7f606b57a8a1]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x112)[0x7f606b564546]
2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 9 in a file 
operation.
2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 9 means 'Bad file descriptor'
2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS error 
209. Cannot continue operation
/usr/sbin/mariadbd(+0x63b8e9)[0x555d0a2638e9]
/usr/sbin/mariadbd(+0xcb66e5)[0x555d0a8de6e5]
/usr/sbin/mariadbd(+0xdbc308)[0x555d0a9e4308]
/usr/sbin/mariadbd(+0xdbc371)[0x555d0a9e4371]
/usr/sbin/mariadbd(+0xdbea20)[0x555d0a9e6a20]
/usr/sbin/mariadbd(+0xdbfb41)[0x555d0a9e7b41]
/usr/sbin/mariadbd(+0xd2585f)[0x555d0a94d85f]
/usr/sbin/mariadbd(+0xc64245)[0x555d0a88c245]
/usr/sbin/mariadbd(_Z24ha_initialize_handlertonP13st_plugin_int+0x7e)[0x555d0a5c839e]
/usr/sbin/mariadbd(+0x797a76)[0x555d0a3bfa76]
/usr/sbin/mariadbd(_Z11plugin_initPiPPci+0x828)[0x555d0a3c0a38]
/usr/sbin/maria

Bug#1009281: [Debichem-devel] Bug#1009281: Should cinfony be removed?

2022-04-10 Thread Andrius Merkys

Hi,

On 2022-04-11 01:35, Moritz Muehlenhoff wrote:
> Source: cinfony
> Version: 1.2-4
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> 
> - Still depends on Python 2 and thus removed from testing since 2019
> - Dead upstream
> - No reverse dependencies

Incidentally, I was the last to upload this package. Since 2019 there
were no uploads, due to aforementioned reasons. I have contemplated
filing for RM ever since, but did not get to it. I think it is fine to
remove. If Python 3 port ever happens, we can reintroduce the package then.

Andrius

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009196: texlive-binaries: Reproducible content of .fmt files

2022-04-10 Thread Norbert Preining

Hi Luigi, hi all luatex devs,

here at Debian we got a bug report about reproducability of luatex
format dumps. It contains a patch to make the hyphenation exception list
sorted. (I attach the patch)

Could you please take a look whether this is still relevant for the
latest release of luatex.

Thanks

Norbert

On Fri, 08 Apr 2022, Roland Clobus wrote:
> Hello maintainers of texlive-binaries,
> 
> While working on the “reproducible builds” effort [1], I have noticed that the
> live image for Cinnamon in bookworm is no longer reproducible [2].
> 
> The attached patch ensures that the output of the function 'exception_strings'
> always uses the same order of the hyphenation exceptions.
> I've written the solution in C, perhaps someone more versed in lua could
> rewrite it more elegantly.
> (The lua manual says for the 'next' function: 'The order in which the indices
> are enumerated is not specified' [3])
> 
> With the attached patch applied, I'm able (with the help of 
> FORCE_SOURCE_DATE=1
> and SOURCE_DATE_EPOCH) to reproducibly rebuild the .fmt files, as created by
> 'fmtutil --sys --all'.
> 
> Small test case to reproduce:
> export FORCE_SOURCE_DATE=1
> export SOURCE_DATE_EPOCH=$(date +%s)
> for i in `seq 1 10`; do luahbtex -ini -jobname=luahbtex -progname=luabhtex
> luatex.ini > /dev/null; md5sum luahbtex.*; done
> 
> With kind regards,
> Roland Clobus
> 
>  [1]: https://wiki.debian.org/ReproducibleBuilds
>  [2]:
> https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_cinnamon_bookworm/
>  [3]: http://www.lua.org/manual/5.4/manual.html#pdf-next
> 

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
diff --git a/texk/web2c/luatexdir/lang/texlang.c 
b/texk/web2c/luatexdir/lang/texlang.c
index ba7614ff..ccc0ec90 100644
--- a/texk/web2c/luatexdir/lang/texlang.c
+++ b/texk/web2c/luatexdir/lang/texlang.c
@@ -498,10 +498,20 @@ static char *hyphenation_exception(int exceptions, char 
*w)
 return ret;
 }
 
+char *unsorted_buffer = NULL;
+size_t *indexes = NULL;
+
+static int sort_func(const void *a, const void *b) {
+size_t ia = *(size_t*)a;
+size_t ib = *(size_t*)b;
+return strcmp(&unsorted_buffer[ia], &unsorted_buffer[ib]);
+}
+
 char *exception_strings(struct tex_language *lang)
 {
 const char *value;
 size_t size = 0, current = 0;
+size_t num_bytes = 0;
 size_t l = 0;
 char *ret = NULL;
 if (lang->exceptions == 0)
@@ -509,19 +519,42 @@ char *exception_strings(struct tex_language *lang)
 lua_checkstack(Luas, 2);
 lua_rawgeti(Luas, LUA_REGISTRYINDEX, lang->exceptions);
 if (lua_istable(Luas, -1)) {
-/*tex Iterate and join. */
+/*tex Determine required memory. */
 lua_pushnil(Luas);
 while (lua_next(Luas, -2) != 0) {
 value = lua_tolstring(Luas, -1, &l);
-if (current + 2 + l > size) {
-ret = xrealloc(ret, (unsigned) ((size + size / 5) + current + 
l + 1024));
-size = (size + size / 5) + current + l + 1024;
-}
-*(ret + current) = ' ';
-strcpy(ret + current + 1, value);
+num_bytes += l + 1;
+size++;
+lua_pop(Luas, 1);
+}
+unsorted_buffer = xmalloc(num_bytes);
+indexes = xmalloc(sizeof(size_t)*size);
+
+/*tex Fetch values. */
+current = 0;
+size = 0;
+lua_pushnil(Luas);
+while (lua_next(Luas, -2) != 0) {
+value = lua_tolstring(Luas, -1, &l);
+strcpy(unsorted_buffer + current, value);
+indexes[size++] = current;
 current += l + 1;
 lua_pop(Luas, 1);
 }
+/*tex Sort and join. */
+qsort(indexes, size, sizeof(size_t), sort_func);
+ret = xmalloc(num_bytes);
+current = 0;
+for (l = 0; l < size; l++) {
+   strcpy(ret + current, &unsorted_buffer[indexes[l]]);
+   current += strlen(&unsorted_buffer[indexes[l]]);
+   ret[current] = ' ';
+   current += 1;
+}
+ret[current - 1] = '\0';
+
+free(unsorted_buffer);
+free(indexes);
 }
 return ret;
 }

Bug#1009289: gmerlin-avdecoder FTCBFS: hard codes the build architecture pkg-config

Source: gmerlin-avdecoder
Version: 2.0.0~svn6298~dfsg0-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gmerlin-avdecoder fails to cross build from source, because configure.ac
hard codes the build architecture pkg-config in one place and thus
misdetects a path that leads to a build failure. Please consider
applying the attached patch to fix that.

Helmut
--- gmerlin-avdecoder-2.0.0~svn6298~dfsg0.orig/configure.ac
+++ gmerlin-avdecoder-2.0.0~svn6298~dfsg0/configure.ac
@@ -184,7 +184,7 @@
 gmerlin_plugindir='$(libdir)/gmerlin/plugins'
 
 dnl LDFLAGS for plugins
-GMERLIN_PLUGIN_LDFLAGS="-export-symbols "`pkg-config --variable=prefix gmerlin`"/share/gmerlin/plugin.sym ${XTRA_LDFLAGS}"
+GMERLIN_PLUGIN_LDFLAGS="-export-symbols "`$PKG_CONFIG --variable=prefix gmerlin`"/share/gmerlin/plugin.sym ${XTRA_LDFLAGS}"
 
 fi

Bug#1009288: mate-power-manager: turns on keyboard backlight for no good reason

2022-04-10 Thread Yan Hetges

Package: mate-power-manager
Version: 1.26.0-2
Severity: minor

Dear Maintainer,

On battery power, with "Reduce Keyboard Backlight" checked, and the keyboard 
backlight
turned off. After the Display dims when idle, and I continue working, when the 
display 
goes back to "bright", the kb bl switches on when it was off before idle.
It should go back to the original state instead.

Thanks

  --Yan


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

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

Versions of packages mate-power-manager depends on:
ii  dbus-user-session [default-dbus-session-bus]1.14.0-1
ii  dbus-x11 [dbus-session-bus] 1.14.0-1
ii  libc6   2.33-7
ii  libcairo2   1.16.0-5
ii  libcanberra-gtk3-0  0.30-10
ii  libcanberra00.30-10
ii  libdbus-1-3 1.14.0-1
ii  libdbus-glib-1-20.112-2
ii  libgdk-pixbuf-2.0-0 2.42.8+dfsg-1
ii  libglib2.0-02.72.0-1+b1
ii  libgtk-3-0  3.24.33-1
ii  libmate-panel-applet-4-11.26.2-1
ii  libnotify4  0.7.9-3
ii  libpango-1.0-0  1.50.6+ds-2
ii  libpangocairo-1.0-0 1.50.6+ds-2
ii  libsecret-1-0   0.20.5-2
ii  libupower-glib3 0.99.17-1
ii  libx11-62:1.7.5-1
ii  libxext62:1.3.4-1
ii  libxrandr2  2:1.5.2-1
ii  mate-notification-daemon [notification-daemon]  1.26.0-1
ii  mate-power-manager-common   1.26.0-2
ii  notification-daemon 3.20.0-4+b1
ii  policykit-1 0.105-33
ii  systemd 250.4-1
ii  upower  0.99.17-1

mate-power-manager recommends no packages.

Versions of packages mate-power-manager suggests:
ii  mate-polkit  1.26.0-1

-- no debconf information

Bug#1009287: mate-power-manager: "Put computer to sleep after 10 minutes" results in hibernation

2022-04-10 Thread Yan Hetges

Package: mate-power-manager
Version: 1.26.0-2
Severity: minor

Dear Maintainer,

I enabled "On Battery power, put computer to sleep after 10 minutes"
I would suspect it to suspend but it went to hibernate.

Thanks
 
 --Yan

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

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

Versions of packages mate-power-manager depends on:
ii  dbus-user-session [default-dbus-session-bus]1.14.0-1
ii  dbus-x11 [dbus-session-bus] 1.14.0-1
ii  libc6   2.33-7
ii  libcairo2   1.16.0-5
ii  libcanberra-gtk3-0  0.30-10
ii  libcanberra00.30-10
ii  libdbus-1-3 1.14.0-1
ii  libdbus-glib-1-20.112-2
ii  libgdk-pixbuf-2.0-0 2.42.8+dfsg-1
ii  libglib2.0-02.72.0-1+b1
ii  libgtk-3-0  3.24.33-1
ii  libmate-panel-applet-4-11.26.2-1
ii  libnotify4  0.7.9-3
ii  libpango-1.0-0  1.50.6+ds-2
ii  libpangocairo-1.0-0 1.50.6+ds-2
ii  libsecret-1-0   0.20.5-2
ii  libupower-glib3 0.99.17-1
ii  libx11-62:1.7.5-1
ii  libxext62:1.3.4-1
ii  libxrandr2  2:1.5.2-1
ii  mate-notification-daemon [notification-daemon]  1.26.0-1
ii  mate-power-manager-common   1.26.0-2
ii  notification-daemon 3.20.0-4+b1
ii  policykit-1 0.105-33
ii  systemd 250.4-1
ii  upower  0.99.17-1

mate-power-manager recommends no packages.

Versions of packages mate-power-manager suggests:
ii  mate-polkit  1.26.0-1

-- no debconf information

Bug#1009286: gcc-12: DEB_STAGE=rtlibs should include libatomic

Source: gcc-12
Version: 12-20220319-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

I think DEB_STAGE=rtlibs should include libatomic. This is not currently
the case and it causes issues. The cross compiler build normally
includes e.g. libatomic1-riscv64-cross and when building e.g. zstd, it
generates symbol uses for libatomic1, but dpkg-shlibdeps cannot locate
libatomic.so.1, because dpkg-shlibdeps does not search
/usr/riscv64-linux-gnu/lib. We need libatomic1:riscv64 here, which was
disabled by DEB_STAGE=rtlibs. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru gcc-12-12-20220319/debian/changelog 
gcc-12-12-20220319/debian/changelog
--- gcc-12-12-20220319/debian/changelog 2022-03-19 08:39:27.0 +0100
+++ gcc-12-12-20220319/debian/changelog 2022-04-11 06:06:01.0 +0200
@@ -1,3 +1,10 @@
+gcc-12 (12-20220319-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do build libatomic for DEB_STAGE=rtlibs. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Apr 2022 06:06:01 +0200
+
 gcc-12 (12-20220319-1) unstable; urgency=medium
 
   * New upstream snapshot, taken from the trunk.
diff --minimal -Nru gcc-12-12-20220319/debian/rules.defs 
gcc-12-12-20220319/debian/rules.defs
--- gcc-12-12-20220319/debian/rules.defs2022-02-25 11:18:28.0 
+0100
+++ gcc-12-12-20220319/debian/rules.defs2022-04-11 06:06:01.0 
+0200
@@ -1630,7 +1630,6 @@
   with_hppa64 := $(call envfilt, hppa64, , , $(with_hppa64))
 
   ifeq ($(DEB_STAGE),rtlibs)
-with_libatomic := disabled for rtlibs stage
 with_libasan := disabled for rtlibs stage
 with_liblsan := disabled for rtlibs stage
 with_libtsan := disabled for rtlibs stage

Bug#1009285: firejail: firecfg --clean breaks symlinks

2022-04-10 Thread Yan Hetges

Package: firejail
Version: 0.9.68-3
Severity: normal

Dear Maintainer,

after installing a new machine (bullseye then upgrade to sid) and installing 
firejail I couldn't get mutt working with my old muttrc. Took me a while to 
figure it was
for the jail.

after running "firecfg --clean" I get for example:
jan@cactus:~$ man vim
bash: /usr/local/bin/man: No such file or directory

and 

jan@cactus:~$ mutt
bash: /usr/local/bin/mutt: No such file or directory

running /usr/bin/man and /usr/bin/mutt directly works.

This is all I have found so far.

Thank you,

  --Yan

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

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

Versions of packages firejail depends on:
ii  libapparmor1  3.0.4-2
ii  libc6 2.33-7
ii  libselinux1   3.3-1+b2

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.68-3
ii  iproute2   5.17.0-1
ii  iptables   1.8.7-1
ii  xauth  1:1.1.1-1
ii  xdg-dbus-proxy 0.1.3-1
ii  xpra   3.1-1+b5
ii  xvfb   2:21.1.3-2+b1

firejail suggests no packages.

-- no debconf information

Bug#1009284: util-linux: new upstream release with lsfd command

2022-04-10 Thread Andres Salomon

Package: util-linux
Version: 2.37.3-1+b1
Severity: wishlist

Hi,

I see that util-linux 2.38-rc2 is in experimental, but final 2.38 has
been released. As the lsof maintainer, I'm interested in seeing how
usable lsfd is in this release. It's meant to replace lsof on linux.
Lsfd was merged in rc1, but I don't see it in your util-linux 2.38~rc2-1
package. So I encourage you to upload 2.38 with lsfd enabled in sid.

Thanks,
Andres

Bug#1009278: kodi: cannot switch language in regional settings

2022-04-10 Thread Vasyl Gello

Hi Alban!

Can you please enable debug logging in Settings - System - Logging,
then also add debug logging on cURL category under the drop-down option below 
the main debug logging switch,
and reproduce the problem again?

This will clearly show what server Kodi tries to reach and why it fails to do 
so.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1009283: caffeine fails immediately on starting

2022-04-10 Thread Ron Murray

Package: caffeine
Version: 2.9.10-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   caffeine does't come up when I try to start it. Here's what happens
when I try to start it from the command line:

- ---
ron@khufu:~$ caffeine
Gtk-Message: 20:20:56.219: Failed to load module "xapp-gtk3-module"
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 1.16.0-unknown is an invalid version and will 
not be supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 2.9.0.Odd.Olm is an invalid version and will 
not be supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an 
invalid version and will not be supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: -VERSION- is an invalid version and will not be 
supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 
2.0.5-build-libtorrent-rasterbar-Cemion-libtorrent-rasterbar-2.0.5-bindings-python
 is an invalid version and will not be supported in a future release
  warnings.warn(
Traceback (most recent call last):
  File "/usr/bin/caffeine", line 35, in 
parser.add_argument('-V', '--version', action='version', 
version=PROGRAM_NAME + ' ' + pkg_resources.require(PROGRAM_NAME)[0].version)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 891, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 777, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'caffeine' distribution was not found 
and is required by the application
- ---

Thanks,

 .Ron

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

Kernel: Linux 5.17.2.khufu (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages caffeine depends on:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.90-8
ii  gir1.2-gtk-3.0   3.24.33-1
ii  python3  3.9.8-1
ii  python3-ewmh 0.1.6-2
ii  python3-gi   3.42.0-3
ii  python3-pkg-resources59.6.0-1.2
ii  python3-xlib 0.29-1
ii  xdg-utils1.1.3-4.1

caffeine recommends no packages.

caffeine suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmJTdiAOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52FYgxAAnSOJndCgg2LMctcugJ98f8YtjpnJAmmdhExG
jZ2CSsIYAfc8JXfgzDnV0qH4SOQznPornaec5jrzBX3sOTu9x7W1yUDmV1SO6LXs
qY8JI3PIltOF39eSoGgJnecApHueZq3GFdXXXqWPMCzY1/XglGGImBvJn76otJM1
nnj9RG9ps+n/MVXj8mx1g/6BU8l6ee93dGK1ltKG8X1hfmjog36eludsrnmIrWDN
zqWiFfk6XwBFCOwsHFQy+z9lIMf33ozH94cL9vjnMlay1Xqskjy4B+44BmErdLRd
ZSSrjyKzdYiIwU0JaO91alQ4fLMs/Fw9WDA9j/y/pEQHIjlq61urwm7jvGz8QjTn
2v6pNwq79f+JGtbADd/jlAu7/081T5pF8YHDEI1CdPuGm4r4f9KF2XIm5zf6JUy4
M56hSOJJ2asQj9Z/fXoBspHeHWhb+eBaoglmHaVykYxaDbYTQtjx0DnZFW9Gtfmu
dAPyw35hoGheAyfMQo9fXdcayMEhce0KR256anAOvhPEwKsYmHRbcrfI7yK1rY4I
mAP31W0Zjp8oGmbmX7fY1xPLRGSNnhPyR/iXqZA0FFUgN57MYMG5NPeNvVmeA3tf
QSMqNitMZnPD77N+uaWRMBpGIzBeTbk7MrM9U8d0kc1EcIUp2tqRw9aak9lK3k8p
BN4I0OA=
=28WY
-END PGP SIGNATURE-

Bug#1009216: /etc/default/prometheus-node-exporter should be much shorter

2022-04-10 Thread Daniel Kahn Gillmor

On Sun 2022-04-10 18:03:13 +0200, Guillem Jover wrote:
> Also true in principle, as long as the man page is coming from upstream
> (and gets updated by them or a script :) or gets generated from the
> Debian packaging out of --help output, which I'm not sure is the case
> for all current exporters. But DRY principle and all.

Agreed.  But if the package maintainer has to spend any time at all
keeping some documentation up to date, please spend it ensuring that the
manpage is up-to-date, as that's going to be relevant for many more
people than /etc/default/prometheus-node-exporter.

> I can bring it up on the team's IRC channel, and gather the feeling of
> the team about this.

Thanks!  One other motivating reason to simplify the file is that it's
easy for a busy/rushed admin to scan the file, see the long list of
commented options and think "i'll just uncomment the ones that i want"
(without understanding that they need to be copied to the ARGS="" line).

Less text makes it easier for someone in a rush to focus on the most
important thing, which is where the options go.

Thanks for looking into this, Guillem!

  --dkg

signature.asc
Description: PGP signature

Bug#988945: [Pkg-rust-maintainers] Bug#988945: rust-http: diff for NMU version 0.1.21-0.1

2022-04-10 Thread Jonas Smedegaard

Hi Sylvestre,

Quoting Sylvestre Ledru (2022-04-10 22:15:47)
> Maybe you should join the team, commit there and follow the process 
> for our packages?  :)

Thanks for the suggestion, but I decline the offer:

I am not interested in joining a team where packages should be tracked 
in one giant git repo.

If I am mistaken and that's not a policy in the Rust team - or if the 
team might consider changing that policy, then I would gladly join.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1008700: [Pkg-electronics-devel] Bug#1008700: Should geda-gaf be removed?

2022-04-10 Thread Moritz Mühlenhoff

Am Wed, Mar 30, 2022 at 04:43:12PM -0600 schrieb Bdale Garbee:
> Moritz Muehlenhoff  writes:
> 
> > Source: geda-gaf
> > Version: 1:1.8.2-11
> > Severity: serious
> >
> > Your package came up as a candidate for removal from Debian:
> 
> For the record, I've previously indicated that I consider lepton-eda a
> complete replacement for geda-gaf in Debian.  It was forked some years
> ago, is actively maintained, and still reads existing geda-gaf designs
> and library files perfectly.  I contribute to lepton-eda upstream, and
> actively maintain the lepton-eda package in Debian.
> 
> I do wonder if there's some action we can/should take when removing
> geda-gaf to ease the transition for existing users of the package to
> lepton-eda?  Perhaps replace the package content with dependency
> information causing the replacement to be more or less automatic on
> upgrades?  [shrug]

If lepton-eda is a sufficient drop-in replacement for existing geda-gaf
users, lepton could provide a geda-gaf transition package for the bookworm
release? I can file a bug against lepton-eda when geda-gaf has been removed.

Cheers,
Moritz

Bug#1009282: Should live-wrapper be removed?

Source: live-wrapper
Version: 0.10
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since 2019
- Depends on vmdebootstrap which was removed
- It's not included in Bullseye, but we did release live images so
  I guess live-wrapper got replaced by something else?

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal at some point.

Cheers,
Moritz

Bug#1009281: Should cinfony be removed?

Source: cinfony
Version: 1.2-4
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since 2019
- Dead upstream
- No reverse dependencies

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1009280: Should python-passfd be removed?

Source: python-passfd
Version: 0.2-3
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since 2020
- No reverse dependencies
- Last upload in 2016

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1009279: cloud-init: Please drop unneeded dependencies

2022-04-10 Thread Brett Holman

Package: cloud-init
Version: 21.4-3
Severity: normal

Cloud-init no longer uses the following dependencies:

python3-prettytable - since 2017
python3-six - since 2020

Both requirements were removed years ago upstream, we should drop them
in Debian as well.

Cheers,

Brett Holman

Bug#1008687: FTBFS: as-test_pool FAIL killed by signal 6 SIGABRT

2022-04-10 Thread Matthias Klumpp

Hello!

Am Mi., 30. März 2022 um 20:21 Uhr schrieb Florian Ernst
:
>
> Source: appstream
> Version: 0.15.2-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
>
> Hello there,
>
> during a rebuild of the reverse b-d of libyaml I found that this package
> failed to build on my amd64.
>
> In addition, the build also failed on amd64, i386, arm64, and armhf,
> each both in unstable and in bookworm, cf.
> 
> where you will also find full logs.
>
> The relevant part from my build log (hopefully, full log attached):

I can't reproduce this issue at all, and a recent upload of AppStream
is building fine on all architectures...
Does this issue still exist? Maybe it was a fluke or fixed in some
other component meanwhile...

Cheers,
Matthias


-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1009277: gnome-weather: background service ImportError on login

2022-04-10 Thread Zack Weinberg

Package: gnome-weather
Version: 42.0-1
Severity: normal
X-Debbugs-Cc: za...@panix.com

Upon logging in I get these error messages in the user journal:

Apr 10 16:51:27 moxana org.gnome.Weath[5211]:
ImportError: Unable to load file from:
resource:///org/gnome/Weather/js/service/main.js
(The resource at “/org/gnome/Weather/js/service/main.js” does not exist)
Apr 10 16:51:27 moxana org.gnome.Weath[5211]:
Unhandled promise rejection. To suppress this warning, add an
error handler to your promise chain with .catch() or a try-catch
block around your await expression. Stack trace of the failed promise:
@/usr/share/org.gnome.Weather/org.gnome.Weather.BackgroundService:9:4

These errors repeat periodically for as long as I am logged in —
I presume something is trying to start the background service at
intervals.

A file named “main.js” appears to be packed inside
/usr/share/org.gnome.Weather/org.gnome.Weather.BackgroundService.src.gresource;
I do not know enough about gjs to understand why it’s not being found
there.

The primary “gnome-weather” application seems to work fine.

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

Kernel: Linux 5.16.0-6-amd64 (SMP w/32 CPU threads; PREEMPT)
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 gnome-weather depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  geoclue-2.0  2.6.0-1
ii  gir1.2-adw-1 1.1.0-1
ii  gir1.2-geoclue-2.0   2.6.0-1
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gtk-4.0   4.6.2+ds-1
ii  gir1.2-gweather-4.0  4.0.0-2
ii  gjs  1.72.0-2
ii  libglib2.0-bin   2.72.0-1+b1

gnome-weather recommends no packages.

gnome-weather suggests no packages.

-- no debconf information

Bug#988945: [Pkg-rust-maintainers] Bug#988945: rust-http: diff for NMU version 0.1.21-0.1

2022-04-10 Thread Sylvestre Ledru


Hello

Maybe you should join the team, commit there and follow the process for our 
packages?  :)

You won't need to do NMU.

Cheers,
Sylvestre


Le 10/04/2022 à 21:42, Jonas Smedegaard a écrit :

Control: tags 988945 + patch
Control: tags 988945 + pending

Dear maintainer,

I've prepared an NMU for rust-http (versioned as 0.1.21-0.1) and
uploaded it without delay, due to current package being completely broken.


Regards,

  - Jonas

diff -Nru rust-http-0.1.19/Cargo.toml rust-http-0.1.21/Cargo.toml
--- rust-http-0.1.19/Cargo.toml 1970-01-01 01:00:00.0 +0100
+++ rust-http-0.1.21/Cargo.toml 2019-12-02 20:18:55.0 +0100
@@ -1,26 +1,38 @@
-# THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
-#
-# When uploading crates to the registry Cargo will automatically
-# "normalize" Cargo.toml files for maximal compatibility
-# with all versions of Cargo and also rewrite `path` dependencies
-# to registry (e.g., crates.io) dependencies
-#
-# If you believe there's an error in this file please file an
-# issue against the rust-lang/cargo repository. If you're
-# editing this file be aware that the upstream Cargo.toml
-# will likely look very different (and much more reasonable)
-
  [package]
  name = "http"
-version = "0.1.19"
-authors = ["Alex Crichton ", "Carl Lerche ", 
"Sean McArthur "]
-description = "A set of types for representing HTTP requests and responses.\n"
-documentation = "https://docs.rs/http";
+# When releasing to crates.io:
+# - Update html_root_url in lib.rs.
+# - Update CHANGELOG.md.
+# - Create git tag
+version = "0.1.21"
  readme = "README.md"
+documentation = "https://docs.rs/http";
+repository = "https://github.com/hyperium/http";
+license = "MIT/Apache-2.0"
+authors = [
+  "Alex Crichton ",
+  "Carl Lerche ",
+  "Sean McArthur ",
+]
+description = """
+A set of types for representing HTTP requests and responses.
+"""
  keywords = ["http"]
  categories = ["web-programming"]
-license = "MIT/Apache-2.0"
-repository = "https://github.com/hyperium/http";
+
+[dependencies]
+bytes = "0.4"
+fnv = "1.0.5"
+itoa = "0.4.1"
+
+[dev-dependencies]
+indexmap = "1.0"
+quickcheck = "0.6"
+rand = "0.4"
+seahash = "3.0.5"
+serde = "1.0"
+serde_json = "1.0"
+doc-comment = "0.3"
  
  [[bench]]

  name = "header_map"
@@ -37,31 +49,3 @@
  [[bench]]
  name = "uri"
  path = "benches/uri.rs"
-[dependencies.bytes]
-version = "0.4"
-
-[dependencies.fnv]
-version = "1.0.5"
-
-[dependencies.itoa]
-version = "0.4.1"
-[dev-dependencies.doc-comment]
-version = "0.3"
-
-[dev-dependencies.indexmap]
-version = "1.0"
-
-[dev-dependencies.quickcheck]
-version = "0.6"
-
-[dev-dependencies.rand]
-version = "0.4"
-
-[dev-dependencies.seahash]
-version = "3.0.5"
-
-[dev-dependencies.serde]
-version = "1.0"
-
-[dev-dependencies.serde_json]
-version = "1.0"
diff -Nru rust-http-0.1.19/Cargo.toml.orig rust-http-0.1.21/Cargo.toml.orig
--- rust-http-0.1.19/Cargo.toml.orig2019-10-15 20:44:13.0 +0200
+++ rust-http-0.1.21/Cargo.toml.orig1970-01-01 01:00:00.0 +0100
@@ -1,51 +0,0 @@
-[package]
-name = "http"
-# When releasing to crates.io:
-# - Update html_root_url in lib.rs.
-# - Update CHANGELOG.md.
-# - Create git tag
-version = "0.1.19"
-readme = "README.md"
-documentation = "https://docs.rs/http";
-repository = "https://github.com/hyperium/http";
-license = "MIT/Apache-2.0"
-authors = [
-  "Alex Crichton ",
-  "Carl Lerche ",
-  "Sean McArthur ",
-]
-description = """
-A set of types for representing HTTP requests and responses.
-"""
-keywords = ["http"]
-categories = ["web-programming"]
-
-[dependencies]
-bytes = "0.4"
-fnv = "1.0.5"
-itoa = "0.4.1"
-
-[dev-dependencies]
-indexmap = "1.0"
-quickcheck = "0.6"
-rand = "0.4"
-seahash = "3.0.5"
-serde = "1.0"
-serde_json = "1.0"
-doc-comment = "0.3"
-
-[[bench]]
-name = "header_map"
-path = "benches/header_map/mod.rs"
-
-[[bench]]
-name = "header_name"
-path = "benches/header_name.rs"
-
-[[bench]]
-name = "header_value"
-path = "benches/header_value.rs"
-
-[[bench]]
-name = "uri"
-path = "benches/uri.rs"
diff -Nru rust-http-0.1.19/.cargo_vcs_info.json 
rust-http-0.1.21/.cargo_vcs_info.json
--- rust-http-0.1.19/.cargo_vcs_info.json   1970-01-01 01:00:00.0 
+0100
+++ rust-http-0.1.21/.cargo_vcs_info.json   1970-01-01 01:00:00.0 
+0100
@@ -1,5 +0,0 @@
-{
-  "git": {
-"sha1": "9c05e391e00474abaa8c14a86bcb0fc5eff1120e"
-  }
-}
diff -Nru rust-http-0.1.19/CHANGELOG.md rust-http-0.1.21/CHANGELOG.md
--- rust-http-0.1.19/CHANGELOG.md   2019-10-15 20:45:44.0 +0200
+++ rust-http-0.1.21/CHANGELOG.md   2019-12-02 20:18:55.0 +0100
@@ -1,3 +1,14 @@
+# 0.1.21 (December 2, 2019)
+
+* Fix `Method::is_idempotent` returning `false` for `PUT` and `DELETE.
+
+# 0.1.20 (November 26, 2019)
+
+* Fix possible double-free if `header::Drain` iterator is `std::mem::forgot`en 
(#357).
+* Fix possible data race if multiple `header::ValueDrain`s are iterated on 
different threads (#362).
+* Fix `HeaderMap::reserve` capacity overflows (#360).

Bug#1009246: New Upstream Version

2022-04-10 Thread Benjamin Barenblat

Control: tags 1009246 + pending

I’ve updated the packaging for 1.5.1; upload incoming. Thanks for your
work on preliminary packaging!

It looks like there’s still some discussion about
libayatana-appindicator going on upstream [1], so I’ve left it out of
this upload. I’ve filed https://bugs.debian.org/1009274 to track
enabling libayatana-appindicator support.


[1] https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/184

Bug#1003653: Revision of removal of rename.ul from package util-linux

Hi Chris,

On Thu, Apr 07, 2022 at 01:04:54PM +0200, Chris Hofstaedtler wrote:
> I see two clear options:
> 
> A) Keep the status quo ("rename is not part of Debians util-linux").
>Very clear, very simple, no work.

This option is obviously incompatible with the request to restore
util-linux' rename. I think we have pretty wide consensus that we do not
want this option.

> B) Finish the very old migration. Have util-linux(-extra) ship
>/usr/bin/rename; perl rename can be prename/file-rename as today,
>but would need to drop the update-alternatives symlink; versioned
>Conflicts/Provides/Replaces would probably be needed. I would also
>suggest having no binary package ship /usr/bin/rename for one
>release.

I've checked back with the perl people and with other ctte members.
Consensus is that we do not want to "finish" this transition. We expect
that /usr/bin/rename only has the perl API on Debian systems.

Do you see any other options or compromises that you'd be comfortable
with?

At this point, it is very clear that we will be unable to reconcile the
position of the submitter (provide util-linux' rename somewhere), the
position of the perl rename maintainers (retain perl API for
/usr/bin/rename) and your stated position (option A or option B). One of
these will have to move and we think it needs to be yours.

Helmut

Bug#1009276: Should fsl be removed?

Source: fsl
Version: 5.0.8-6
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since two years
- Also FTBFSes with GCC 10
- Last upload in 2019

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1009275: kde-standard: Kde daemon asks for wifi password when kwallet is turned off

2022-04-10 Thread Olof Hansson

Package: kde-standard
Version: 5:111
Severity: normal
X-Debbugs-Cc: olof_hans...@outlook.com

Dear Maintainer,

1)
Installed wlan0: Broadcom BCM43a0 802.11 Hybrid Wireless Controller
6.30.223.271 (r587334)
05:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac
Wireless Network Adapter (rev 03)
Which is Asus AC68 PCI-E card for Wifi.

2)
Created a new wifi connection with my Asus ACWrote wifi password and choosed
"save only password for this user (encrypted)" clicked saved. Unchecked kWallet
because I didn't want any system where I needed to sign in or similar.

3)
The KDE Daemon Wifi asks for the networks password at every login in KDE
Plasma.

4) I've updated my system as one should, but this is not resolved, still.
Anyone else with this problem?

I want it to work as intended:
If one option says that the password till be saved I shall not be enforced to
write it every login. This should be remembered by the system/password manager.
And it should be ok to not use Kwallet.

I have done little research if this is related to wifi card/driver, worried if
no one else had this problem?


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 kde-standard depends on:
ii  akregator  4:20.08.3-1
ii  ark4:20.12.2-1
ii  dragonplayer   4:20.12.0-1
ii  gwenview   4:20.12.3-2
ii  juk4:20.12.3-1
ii  kaddressbook   4:20.08.3-1
ii  kate   4:20.12.2-1
ii  kcalc  4:20.12.0-1
ii  kde-plasma-desktop 5:111
ii  kde-spectacle  20.12.3-1
ii  khelpcenter4:20.12.0-1
ii  kmail  4:20.08.3-1
ii  knotes 4:20.08.3-1
ii  korganizer 4:20.08.3-1
ii  kwalletmanager 4:20.12.0-1
ii  okular 4:20.12.3-2
ii  plasma-dataengines-addons  4:5.20.5-1
ii  plasma-pa  4:5.20.5-1
ii  plasma-runners-addons  4:5.20.5-1
ii  plasma-wallpapers-addons   4:5.20.5-1
ii  plasma-widgets-addons  4:5.20.5-1
ii  polkit-kde-agent-1 4:5.20.5-1
ii  sweeper4:20.12.0-1

Versions of packages kde-standard recommends:
ii  konq-plugins  4:20.12.0-4
ii  plasma-nm 4:5.20.5-3

Versions of packages kde-standard suggests:
pn  skanlite

Bug#1009274: transmission-remote-gtk: reenable appindicator support using libayatana-appindicator

2022-04-10 Thread Benjamin Barenblat

Package: transmission-remote-gtk
Version: 1.4.1-5
Severity: wishlist

This bug, split from https://bugs.debian.org/1009246, tracks reenabling
appindicator support using libayatana-appindicator. There’s currently an
open discussion with upstream about adding libayatana-appindicator
support to their build system [1].

That said, I believe we can’t link against libayatana-appindicator due
to license issues: transmission-remote-gtk is GPL-2-only because of some
files like [2], while libayatana-appindicator is GPL-3-only because of
some files like [3]. Upstream has indicated that they’d like to rid
themselves of the GPL-2 restriction [4] but that it’s likely to be
challenging [5].


[1] https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/184
[2] 
https://sources.debian.org/src/transmission-remote-gtk/1.4.1-5/src/torrent-cell-renderer.c/
[3] 
https://sources.debian.org/src/libayatana-appindicator/0.5.91-1/src/generate-id.c/
[4] 
https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/184#issuecomment-1094307680
[5] https://github.com/transmission-remote-gtk/transmission-remote-gtk/issues/21

Bug#1009273: Should python-keepkey be removed?

Source: python-keepkey
Version: 0.7.3-1
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since 2019
- Last upload back in 2016

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#936777: k3d: Python2 removal in sid/bullseye

2022-04-10 Thread Moritz Mühlenhoff

Hi Manuel,
> > Given upstream's reply at https://github.com/K-3D/k3d/issues/38 this
> > seems unlikely to get ported, let's remove k3d?
> 
> Basically I'd like to extend its life in Debian and keep users using
> this package rather than having to build the version themselves, as
> long as it doesn't become a big burden for Debian -- when it does
> sure, let's drop it, and if the moment is now, so be it.
> 
> This package is in a bad situation with Python2 and GTK dependencies,
> but this is not the kind of application like a media player or similar
> for which there are a gazillion alternatives with more or less the
> same features -- this is a pretty specialized piece of software and
> migration to some other tool can be a huge undertaking and might not
> always be possible.
> 
> If the relevant Python2 packages are going to be removed imminently,
> that's OK, we can remove it now.  And in any case, this package should
> prevent the removal of Python2 if it's one of the last dependencies.
> 
> But if Python2 it's to be held for a few months/years because other
> important/popular packages are not migrated yet (gnat-gps, kodi?), and
> even if only to keep it for unstable, I'd prefer to remove this
> package only when Python2 is removed.

Revisiting this two years later; I really think k3d should be removed now?
Nothing changed upstream and at this point it's uninstallable in unstable
for many other libraries besides Python 2:

-
The following packages have unmet dependencies:
 k3d : Depends: libboost-program-options1.67.0 but it is not installable
   Depends: libboost-python1.67.0 but it is not installable
   Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not installable
   Depends: libcgal13 but it is not installable
   Depends: libopenexr24 (>= 2.3.0) but it is not installable
E: Unable to correct problems, you have held broken packages.
-

Maybe it's better to ship such a proven, but no longer updated to current
tooling package as a Flatpak on Flathub?

Cheers,
Moritz

Bug#988945: rust-http: diff for NMU version 0.1.21-0.1

2022-04-10 Thread Jonas Smedegaard

Control: tags 988945 + patch
Control: tags 988945 + pending

Dear maintainer,

I've prepared an NMU for rust-http (versioned as 0.1.21-0.1) and
uploaded it without delay, due to current package being completely broken.


Regards,

 - Jonas

diff -Nru rust-http-0.1.19/Cargo.toml rust-http-0.1.21/Cargo.toml
--- rust-http-0.1.19/Cargo.toml 1970-01-01 01:00:00.0 +0100
+++ rust-http-0.1.21/Cargo.toml 2019-12-02 20:18:55.0 +0100
@@ -1,26 +1,38 @@
-# THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
-#
-# When uploading crates to the registry Cargo will automatically
-# "normalize" Cargo.toml files for maximal compatibility
-# with all versions of Cargo and also rewrite `path` dependencies
-# to registry (e.g., crates.io) dependencies
-#
-# If you believe there's an error in this file please file an
-# issue against the rust-lang/cargo repository. If you're
-# editing this file be aware that the upstream Cargo.toml
-# will likely look very different (and much more reasonable)
-
 [package]
 name = "http"
-version = "0.1.19"
-authors = ["Alex Crichton ", "Carl Lerche 
", "Sean McArthur "]
-description = "A set of types for representing HTTP requests and responses.\n"
-documentation = "https://docs.rs/http";
+# When releasing to crates.io:
+# - Update html_root_url in lib.rs.
+# - Update CHANGELOG.md.
+# - Create git tag
+version = "0.1.21"
 readme = "README.md"
+documentation = "https://docs.rs/http";
+repository = "https://github.com/hyperium/http";
+license = "MIT/Apache-2.0"
+authors = [
+  "Alex Crichton ",
+  "Carl Lerche ",
+  "Sean McArthur ",
+]
+description = """
+A set of types for representing HTTP requests and responses.
+"""
 keywords = ["http"]
 categories = ["web-programming"]
-license = "MIT/Apache-2.0"
-repository = "https://github.com/hyperium/http";
+
+[dependencies]
+bytes = "0.4"
+fnv = "1.0.5"
+itoa = "0.4.1"
+
+[dev-dependencies]
+indexmap = "1.0"
+quickcheck = "0.6"
+rand = "0.4"
+seahash = "3.0.5"
+serde = "1.0"
+serde_json = "1.0"
+doc-comment = "0.3"
 
 [[bench]]
 name = "header_map"
@@ -37,31 +49,3 @@
 [[bench]]
 name = "uri"
 path = "benches/uri.rs"
-[dependencies.bytes]
-version = "0.4"
-
-[dependencies.fnv]
-version = "1.0.5"
-
-[dependencies.itoa]
-version = "0.4.1"
-[dev-dependencies.doc-comment]
-version = "0.3"
-
-[dev-dependencies.indexmap]
-version = "1.0"
-
-[dev-dependencies.quickcheck]
-version = "0.6"
-
-[dev-dependencies.rand]
-version = "0.4"
-
-[dev-dependencies.seahash]
-version = "3.0.5"
-
-[dev-dependencies.serde]
-version = "1.0"
-
-[dev-dependencies.serde_json]
-version = "1.0"
diff -Nru rust-http-0.1.19/Cargo.toml.orig rust-http-0.1.21/Cargo.toml.orig
--- rust-http-0.1.19/Cargo.toml.orig2019-10-15 20:44:13.0 +0200
+++ rust-http-0.1.21/Cargo.toml.orig1970-01-01 01:00:00.0 +0100
@@ -1,51 +0,0 @@
-[package]
-name = "http"
-# When releasing to crates.io:
-# - Update html_root_url in lib.rs.
-# - Update CHANGELOG.md.
-# - Create git tag
-version = "0.1.19"
-readme = "README.md"
-documentation = "https://docs.rs/http";
-repository = "https://github.com/hyperium/http";
-license = "MIT/Apache-2.0"
-authors = [
-  "Alex Crichton ",
-  "Carl Lerche ",
-  "Sean McArthur ",
-]
-description = """
-A set of types for representing HTTP requests and responses.
-"""
-keywords = ["http"]
-categories = ["web-programming"]
-
-[dependencies]
-bytes = "0.4"
-fnv = "1.0.5"
-itoa = "0.4.1"
-
-[dev-dependencies]
-indexmap = "1.0"
-quickcheck = "0.6"
-rand = "0.4"
-seahash = "3.0.5"
-serde = "1.0"
-serde_json = "1.0"
-doc-comment = "0.3"
-
-[[bench]]
-name = "header_map"
-path = "benches/header_map/mod.rs"
-
-[[bench]]
-name = "header_name"
-path = "benches/header_name.rs"
-
-[[bench]]
-name = "header_value"
-path = "benches/header_value.rs"
-
-[[bench]]
-name = "uri"
-path = "benches/uri.rs"
diff -Nru rust-http-0.1.19/.cargo_vcs_info.json 
rust-http-0.1.21/.cargo_vcs_info.json
--- rust-http-0.1.19/.cargo_vcs_info.json   1970-01-01 01:00:00.0 
+0100
+++ rust-http-0.1.21/.cargo_vcs_info.json   1970-01-01 01:00:00.0 
+0100
@@ -1,5 +0,0 @@
-{
-  "git": {
-"sha1": "9c05e391e00474abaa8c14a86bcb0fc5eff1120e"
-  }
-}
diff -Nru rust-http-0.1.19/CHANGELOG.md rust-http-0.1.21/CHANGELOG.md
--- rust-http-0.1.19/CHANGELOG.md   2019-10-15 20:45:44.0 +0200
+++ rust-http-0.1.21/CHANGELOG.md   2019-12-02 20:18:55.0 +0100
@@ -1,3 +1,14 @@
+# 0.1.21 (December 2, 2019)
+
+* Fix `Method::is_idempotent` returning `false` for `PUT` and `DELETE.
+
+# 0.1.20 (November 26, 2019)
+
+* Fix possible double-free if `header::Drain` iterator is `std::mem::forgot`en 
(#357).
+* Fix possible data race if multiple `header::ValueDrain`s are iterated on 
different threads (#362).
+* Fix `HeaderMap::reserve` capacity overflows (#360).
+* Fix parsing long authority-form `Uri`s (#351).
+
 # 0.1.19 (October 15, 2019)
 
 * Allow `%` in IPv6 addresses in `Uri` (#343).
diff -Nru rust-http-0.1.19/debian/changelog rust-http-0.1.21/debian/changelog
--

Bug#1009272: src:hydrogen: fails to migrate to testing for too long: unresolved RC bug (flaky autopkgtest)

2022-04-10 Thread Paul Gevers


Source: hydrogen
Version: 1.0.1-3
Severity: serious
Control: close -1 1.1.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1005912

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:hydrogen has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. I recognize I've been in contact 
with you on the blocking bug report, but it's time to determine how to 
move on (even if it were not the final solution).


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.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#999837: my two cents

2022-04-10 Thread Geert Stappers



Merecat footprint is ~ 140 KiB.
Having CGI support and Let's encrypt support is also a plus.

The swap of publicfile-installer for merecat
is a improvement for Debian.

FWIW, this email adds deep link https://salsa.debian.org/debian/merecat
to this ITP BR. I can confirm that 
  
  debcheckout https://salsa.debian.org/debian/merecat

works.  Once merecat is in debian you can do just

  debcheckout merecat

(Install debcheckout by `sudo apt install -y devscripts`.)


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1009167: xz-utils: diff for NMU version 5.2.5-2.1

2022-04-10 Thread Salvatore Bonaccorso

Hi Jonathan,

On Sun, Apr 10, 2022 at 03:08:12PM +0200, Salvatore Bonaccorso wrote:
> Control: tags 1009167 + patch
> Control: tags 1009167 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

I noted that the last uploads done by Sebastian were NMUs, so hope it
is uncontroversial that I rescheduled the fix to delayed/0 and direct
upload tonight. There is not particular reason for the urgency, it's
more that I would like to base the bullseye-security just on top of
the 5.2.5-2.1 versioned 5.2.5-2.1~deb11u1 and have additionally the
fix first exposed in unstable enough as well for regression testing.

If that was a not welcome move and not having it only on delayed/2
then please let me know.

Regards,
Salvatore

Bug#1008722: Possible bugfix

2022-04-10 Thread Sudip Mukherjee

Hi Felix,

On Wed, Apr 6, 2022 at 1:27 PM Moessbauer, Felix
 wrote:
>
> Hi Sudip,
>
> Unfortunately I found more races in the build.

I am thinking  of disabling parallel jobs while building. That should
fix the problem for now. Your thoughts ?


-- 
Regards
Sudip

Bug#1009199: src:tcpreplay: fails to migrate to testing for too long: ftbfs on armhf

2022-04-10 Thread Paul Gevers


Dear Fred,

On 10-04-2022 19:04, Fred Klassen wrote:
Paul, I am somewhat confused. I have not touched any old versions on 
github, including 4.3.4. Is this something I should concern myself with?


This bug has nothing to do with what happens outside of Debian, so this 
bug is totally unrelated to github.


This bug is about the fact that in Debian the version in unstable is 
newer than in testing for more than 60 days. The reason why the version 
in unstable is not migrating is that the version in unstable failed to 
build on armhf, while previous versions built on that architecture. That 
needs somebody to figure out what the best solution is.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009257: Option to convert white to transparency

2022-04-10 Thread martin f krafft

Regarding the following, written by "Jeff" on 2022-04-10 at 12:52 Uhr +:

Can't this be achieved with a user defined tool?

Sure thing, for instance:

```
convert -size 2480x3508 -depth 300x300 -transparent white in.pdf out.pdf
```

I see four problems with this though:

1. This operation would be a lot faster on the PNM files, rather
than first writing the PDF, and then basically accessing the PDF
bitmaps page-wise for this operation;

2. The ImageMagick conversion really messes with the PDF file in
ways I haven't figure out yet. If I apply it to the PNM files,
there is no quality loss;

3. A user-defined tool does not have access to the resolution to be
used, unlike gscan2pdf. I can calculate the dimensions, but only
if I have the resolution;

4. Invoking user-defined tools is cumbersome, especially if you want
to do so multiple times
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007197)

I understand your point, but the argument can be made about all of
the post-processing tools built-in, and the question becomes which
one of those are so commonly used that they should be built-in. I
never use unsharp mask, negation, brigthness/contrast, or even OCR,
but they are built-in.

--
.''`. martin f. krafft @martinkrafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems

"the difference between genius and stupidity

is that genius has it's limits."
-- albert einstein

digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#1009270: RM: python-jsonrpc-server, python-language-server, pyls-black -- ROM; Packages have been superseded

2022-04-10 Thread Julian Gilbey

Package: ftp.debian.org
Severity: normal

This set of three packages have been superseded by community-supported
forks.  (A bit of a long story there.)  But none of these are now
required in Debian; the last package depending on them was spyder, and
I have just uploaded a newer version (5.3.0) which uses the new
versions.

Package to remove (source):  Package has been superseded by (source):
python-jsonrpc-serverpython-lsp-jsonrpc
python-language-server   python-lsp-server
pyls-black   python-lsp-black

Best wishes,

   Julian

Bug#1009269: Should sphinx-patchqueue be removed?

Source: sphinx-patchqueue
Version: 0.5.0-2
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since 2019
- No remaining reverse dependencies
- Last upload in 2015

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#937261: pd-aubio: Python2 removal in sid/bullseye

2022-04-10 Thread Moritz Mühlenhoff

Am Fri, Aug 30, 2019 at 07:30:29AM + schrieb Matthias Klose:
> Package: src:pd-aubio
> Version: 0.4-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

This is fixed in current aubio upstream releases, which have switched
to Python 3. The last upload was over eight years ago, are you planning
to upload a fixed version or should it rather be removed?

Cheers,
Moritz

Bug#1009268: FTBJS: build fails with node-chalk >= 5

2022-04-10 Thread Yadd

Source: node-jest
Version: 27.5.1~ds+~cs69.51.22-6
Severity: serious
Tags: ftbfs
Justification: FTBFS

Typescript generation fails with node-chalk >= 5

Bug#1003653: Revision of removal of rename.ul from package util-linux

Hi Dom and gregor,

On Sun, Apr 10, 2022 at 03:06:56PM +0100, Dominic Hargreaves wrote:
> +1 to all of this.

Thank you for your replies. They're not unexpected, but we (or at least
I) weren't entirely sure.

> Furthermore I'm troubled that this discussion rolled on for two months
> having dropped the perl folk, in a circular fashion. That doesn't seem
> to be in the spirit of cooperation alluded to in
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003653#122

At that time, we (ctte) didn't really consider changing the
/usr/bin/rename API to be a viable option, but apparently Chris did and
that only became fully clear much later. Thus the question popped up
now.

In any case, we now have three relevant opinions that form a
contradiction when combined:

 * Submitter: The util-linux rename implementation should be included in
   Debian
 * Chris: The util-linux rename should be either /usr/bin/rename or
   absent.
 * Dom/gregor: /usr/bin/rename should be perl rename.

In all of this discussion, I think we didn't have such a clear
understanding of the disagreement. It always looked solvable in a
consensual way to me. That has somewhat changed now.

The next step is checking back with Chris on whether his position could
be adjusted. I would still prefer resolving this without using special
ctte powers.

Helmut

Bug#1009199: src:tcpreplay: fails to migrate to testing for too long: ftbfs on armhf

2022-04-10 Thread Christoph Biedl

Fred Klassen wrote...

> Paul, I am somewhat confused. I have not touched any old versions on
> github, including 4.3.4. Is this something I should concern myself with?

tcpreplay failed to build on armhf and I never managed to take a deeper
look:

https://buildd.debian.org/status/fetch.php?pkg=tcpreplay&arch=armhf&ver=4.4.0-1&stamp=1644098099&raw=0

(check for "Bus error")

Will check again tonight.

Chri- "Debian maintainer, slacking" stoph



signature.asc
Description: PGP signature

Bug#948435: gdisk: cgdisk claims that attribute flags are all set to 0

I believe I've fixed this bug. It's in the following commit to the GPT
fdisk git repository:

https://sourceforge.net/p/gptfdisk/code/ci/b056f3860ad587c01ed9e2a0bae6cc3ba8d41535/

I expect to make a new 1.0.9 release of GPT fdisk sometime in the next
few days, including this bug fix.

-- 
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com

Bug#1009267: zfsnap fail to delete snapshorts if left without removal for three years

2022-04-10 Thread Petter Reinholdtsen



Package: zfsnap
Version: 1.11.1-5.1

After using zfsnap for a few years, I discovered that I had forgotten
the -d option when calling it to make snapshots every hour and keep them
for 5 days.  The end result is a lot of snapshots I am currently trying
to get rid of.  I am currently running 'zfs destroy' in a for look to
remove them, as the -d option only reported this error when trying to
let zfSnap take care of it:

  /usr/sbin/zfSnap: 410: grep: Argument list too long
  xargs: printf: terminated by signal 13

Perhaps the code could be rewritten to handle more snapshots to remove?

-- 
Happy hacking
Petter Reinholdtsen

Bug#992120: [Pkg-utopia-maintainers] Bug#992120: (No Subject)

2022-04-10 Thread Yves-Alexis Perez

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2022-04-09 at 16:11 +0200, Michael Biebl wrote:
> I think that was a red herring.
> After closer inspection I think the shown screenshot was from 
> gnome-control-center and *not* from nm-connection-editor.
> 
> Sorry for the confusion.

Ah, thanks for the clarification. I guess the bug can be reassigned back to
network-manager-gnome and closed with the version number including
49f87caa3ab867de2569185c34c384d507ed5b62 (not sure which one it is)?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmJTDtUACgkQ3rYcyPpX
RFvQkQgAm5Dci//cWfeS3IYe94b/XPGiVe37EonTfHwKksLPwUnw5j7lc+iHLPC1
DfXLEJ5tpb1Ey8IN8Lf2b79N2a+q8t3IxdLo+d+6EpQkXa2rXExd/ff94c6WvEB2
2IzMs0CfcH6n1JY5TP48XSO89y3Lgsw4P6cOW3TSKKE9KTDO2wJ8+OW7WDQeJoAe
+E6WjQradaMGzrXsowFh3LO83l/V0H08qn8M5pf5LyEyc7PIeuQH6HdltpwWdGkv
be7ScqYexI5JgJimsZJ8gA7RS3scem6d+5JTKTyMl3qEDgIki31pvhKxt8SDzui2
vg+QdMsmatJZNEhor1KTnyCWvRqEkg==
=664a
-END PGP SIGNATURE-

Bug#802260: gnome-gmail: Installation experience on KDE

2022-04-10 Thread Dave Steele

Control: severity -1 wishlist
thanks

Bug#1006130: Easier packaging in new versions of sioyek

2022-04-10 Thread ali mostafavi

Developer of sioyek here.
I have recently made some changes to the build script which should make
packaging for debian easier. I have already packaged it myself and it seems
to be working well (I built it on Ubuntu 21.10 and tested it on a vanilla
Ubuntu 22.04 Beta virtual machine, it might not run on older distros) .
Here is the `debian` folder that I used:

https://github.com/ahrm/sioyek/tree/main/resources/debian

I would prefer if someone else packaged sioyek (mainly because I am a total
noob when it comes to packaging) but if no one is interested maybe I can do
it myself.

Bug#1008785: ITP: fonts-creep -- Pretty sweet 4px wide pixel font

2022-04-10 Thread Roland Clobus


Hello Agathe,

On 09/04/2022 14:15, Agathe Porte wrote:

02/04/2022 21:21, Roland Clobus :

See the last entry of
https://forums.debian.net/viewtopic.php?t=136305
for a possible solution.


I just tried, but it was not successful; see attached screenshots. :(


Hmm. I didn't get the error message about the 'bitmap of size 11'.

I opened creep2.sfd in FontForge, saved the otb.
Then to preview it, I opened the font with the Fontviewer in Nautilus (I 
have a GNOME desktop).

After clicking 'Install', it was located at ~/.local/share/fonts/creep2.otb
It becomes crisp at 8.

With kind regards,
Roland


OpenPGP_signature
Description: OpenPGP digital signature

Bug#994676: gdisk FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

Thanks for the bug report and patch. I've added the patch referenced in
this bug report to the GPT fdisk git repository. I expect to make a new
1.0.9 release with this fix in the next few days.

https://sourceforge.net/p/gptfdisk/code/ci/4be26d7228a5dadfd04488618f08a29f0c67dd8c/

-- 
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com

Bug#876393: gdisk: valgrind reports conditional evaluation depends on unitialized variable

Thanks for the patch! I've just added it to the GPT fdisk git repository:

https://sourceforge.net/p/gptfdisk/code/ci/8ff360f49eda175142e01d46edbb494cfebe309d/

(I expect to do a new release soon, FWIW.)

-- 
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com

Bug#873452: gdisk reports "Total free space is 18446744073709551581 sectors (16.0 EiB)"