Bug#1067884: KiCad no longer seems to recognize any of the built-in libraries
On Fri, 12 Apr 2024 08:45:34 + Erich Minderlein wrote: > I must correct my self: This was an update from devuan chimaera and > an old history concerning $HOME, which lives with me since years > > Today I made a fresh install in a virtual machine and every thing > works fine. > > Then I deleted directories > rm -r $HOME/.config/kicad $HOME/.cache/kicad $HOME/.local/share/kicad > > I started KiCad again as $USER and it acknowledged the libraries. > > This is an aide at least for those who do not have a valuable history > in KiCad > > For the others the problem remains to be solved I beg to differ. You upgraded to Devuan Daedalus which is based on Debian bookworm, aka Debian stable. However, the original bug report concerns in Debian trixie, i.e. Debian testing. In current testing the package kicad depends on kicad-libraries with a version string >=7.0.1~ , which in turn depends on kicad-footprints, kicad-symbols, kicad-templates and kicad-packages3d, again with version string >=7.0.1~ . About two weeks ago, the packages or symbols, footprints, etc. were upgraded to version 8.0.1-1 in testing. So an 'apt upgrade' on debian testing happily pulls these v8 kicad libraries. However, kicad still remains on v7.0.1 . Since kicad libraries are explicitly not downward compatible across major versions, the 7.0.1 kicad binary refuses to load any element from a 8.0.1 library. This makes the package virtually unusable for its intended purpose. I got bitten by the bug, too. Unfortunately, a downgrade to stable is no option, since kicad is on v6.0 over there. All my kicad projects are on v7.0 already and will not open with kicad6. Unfortunately, I found no way to make apt downgrade to version 7.0 of the libraries. Luckily, I was able to regained access to my projects by manually replacing the upgraded v8 libraries with v7 versions from a backup. The upgrade of the package kicad is blocked until until gtk+3.0, libgllib2.0t64, python3.11, curl, opencascade and wywidgets3.2 have all received a successful upgrade. This will probably take a few days. How about adding '<8.0' to the version requirement for the time being? Best regards, ---<)kaimartin(>--- -- Kai-Martin Knaak kn...@iqo.uni-hannover.de Universität Hannover, Inst. für Quantenoptik tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover fax: +49-511-762-2211 PGP-Key: https://keys.openpgp.org/search?q=kn...@iqo.uni-hannover.de pgpQBpw2EC1l5.pgp Description: OpenPGP digital signature
Bug#1067195: fzf: Please package 0.48.x
Package: fzf Version: 0.44.1-1 Severity: wishlist Dear Maintainers, please consider packaging and releasing 0.48.x which was released some days ago. This version introduces an easy way to integrate and configure fzf: # in .bashrc eval $(fzf --bash) This will make it easier to configure cross-platform dotfiles and Debian no longer has to ship the configuration files cause it is build into the binary. Regards, Kai
Bug#1065638: systemd-journald: systemd-journald restart misses SyslogFacility
Package: systemd Version: 247.3-7+deb11u4 Severity: normal X-Debbugs-Cc: armando.va...@gmail.com Dear Maintainer, * What led up to the situation? A systemd service unit "test" has SyslogFacility=local0 set. Service is running and logging lines. Log lines have SYSLOG_FACILITY=16 when observed with journalctl -o verbose. Restart journald. After restart of journald, log lines have no more SYSLOG_FACILITY=16. To restore SYSLOG_FACILITY=16 in journal logs, one has to restart service unit "test". * What exactly did you do (or not do) that was effective (or ineffective)? systemctl restart systemd-journald.service * What was the outcome of this action? journald did not record the SyslogFacility set in the service unit file. * What outcome did you expect instead? journald should continue recording SyslogFacility set in the service unit file without needing to restart the service having the SyslogFacility set. -- Package-specific info: -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-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 systemd depends on: ii adduser 3.118+deb11u1 ii libacl1 2.2.53-10 ii libapparmor1 2.13.6-10 ii libaudit11:3.0-2 ii libblkid12.36.1-8+deb11u1 ii libc62.31-13+deb11u7 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libcryptsetup12 2:2.3.7-1+deb11u1 ii libgcrypt20 1.8.7-6 ii libgnutls30 3.7.1-5+deb11u3 ii libgpg-error01.38-2 ii libip4tc21.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2.1~deb11u1 ii libmount12.36.1-8+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libseccomp2 2.5.1-1+deb11u1 ii libselinux1 3.1-3 ii libsystemd0 247.3-7+deb11u4 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.36.1-8+deb11u1 ii util-linux 2.36.1-8+deb11u1 Versions of packages systemd recommends: ii dbus 1.12.28-0+deb11u1 ii ntp [time-daemon] 1:4.2.8p15+dfsg-1 Versions of packages systemd suggests: ii policykit-10.105-31+deb11u1 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 ii libnss-systemd 247.3-7+deb11u4 ii libpam-systemd 247.3-7+deb11u4 ii udev 247.3-7+deb11u4 -- no debconf information
Bug#1064364: gnome-software: causes packagekit to spam syslog
A workaround for this issue is to `killall gnome-software` until the next login.
Bug#1000955: I have the same problem
Hi, I have the same issue for maybe two months now. The problem occurs in two cases: 1) If I use the computer again after suspend. 2) If I just disable the screen by the power button without suspending the computer. Of course, I have configured my power saving settings accordingly. I use additional to Debian (stable version) openSUSE Tumbleweed with the most recent packages, so with the latest state of development. I don't have the issue with it, although I use the same user data. I'm able to solve the problem by running "systemctl --user restart plasma-kglobalaccel.service", which works until the next time I bring the computer back from suspend mode or until the next time I press the power off button to turn off the screen. Feel free to ask for additional information. Regards, Kai
Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)
Hey Aurelien, Aurelien Jarno wrote on 06.07.23 21:43: Hi, On 2023-07-06 08:14, Kai Wasserbäch wrote: OK, downgrading from the broken system state didn't work either and left me with a lot of segfaulting programs. In the end it seems that 2.73-3 isn't really broken, but the update process is somehow. After I went to a rescue system and redid the update from there, everything worked out. Now 2.73-3 is working here as well. In the rescue system environment the post-install scripts ran successfully. This looks very strange that downgrading and re-upgrading fixes the issue. Did the initial upgrade finished properly? You might want to look for issues in /var/log/dpkg.log or /var/log/apt/term.log. the logs I can only check on Monday, but as I've written in my first e-mail: the post-install scripts failed with segmentation faults. And the re-upgrade only succeeded from a rescue environment (with its own, working libc). Cheers, Kai OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)
OK, downgrading from the broken system state didn't work either and left me with a lot of segfaulting programs. In the end it seems that 2.73-3 isn't really broken, but the update process is somehow. After I went to a rescue system and redid the update from there, everything worked out. Now 2.73-3 is working here as well. In the rescue system environment the post-install scripts ran successfully. In case it matters: I made the initial update with aptitude in my graphical session (KDE on X11).
Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)
I did manage do get a full back trace for man:
$ gdb --args man apt-get
GNU gdb (Debian 13.2-1) 13.2
[...]
Reading symbols from man...
Reading symbols from
/usr/lib/debug/.build-id/70/bd707aa6a7ea95d80aaa2933e2d49f1cc56c5f.debug...
(gdb) r
Starting program: /usr/bin/man apt-get
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x7f557d18ff36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt full
#0 0x7f557d18ff36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x7f557d15dd49 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x7f557d15f26d in fnmatch () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3 0x5586d79b6a49 in match_wildcard_in_directory
(path=0x5586d99f4460 "/usr/share/man/man8", pattern=0x5586d99ecea0
"apt-get.8*", opts=, matched=0x5586d99ea4d0,
cache=0x5586d99ece80) at ../../../src/globbing.c:273
flags = 16
pattern_start = {pattern = 0x5586d9a1bf60 "apt-get.8", len =
}
bsearched =
i = 22
#4 0x5586d79b7042 in look_for_file (hier=hier@entry=0x5586d99f0140
"/usr/share/man", sec=sec@entry=0x5586d99e7a70 "8",
unesc_name=unesc_name@entry=0x7ffef1c470b2 "apt-get",
cat=cat@entry=false, opts=opts@entry=0) at ../../../src/globbing.c:343
dirs_node = 0x1
dirs_iter = {vtable = 0x5586d79cb500
, list = 0x5586d99f3400, count = 1, p =
0x5586d99f01e8, q = 0x5586d99f01e8, i = 0, j = 0}
dirs = 0x5586d99f3400
dir = 0x5586d99f4460 "/usr/share/man/man8"
matched = 0x5586d99ea4d0
pattern = 0x5586d99ecea0 "apt-get.8*"
path = 0x0
layout = 1
name = 0x5586d99e7fd0 "apt-get"
__PRETTY_FUNCTION__ = "look_for_file"
MPI_LABEL_4_break_340 =
#5 0x5586d79ba18c in try_section (cand_head=0x7ffef1c46038,
name=0x7ffef1c470b2 "apt-get", sec=0x5586d99e7a70 "8",
path=0x5586d99f0140 "/usr/share/man") at ../../../src/man.c:3172
found = 0
lff_opts = 0
names = 0x0
cat = 0 '\000'
MPI_LABEL_4_break_3197 =
found_name = 0x5586d99e80c8 " utility -- command-line interface"
found =
names =
found_name =
cat =
lff_opts =
MPI_LABEL_1_body_3197 =
MPI_LABEL_1_done_3197 =
MPI_LABEL_2_body_3197 =
MPI_LABEL_2_done_3197 =
MPI_LABEL_4_body_3197 =
MPI_LABEL_4_break_3197 =
MPI_LABEL_4_finish_3197 =
names_iter =
names_node =
info =
ult =
f =
#6 locate_page (candidates=0x7ffef1c46038, name=0x7ffef1c470b2
"apt-get", sec=0x5586d99e7a70 "8", manpath=0x5586d99f0140
"/usr/share/man") at ../../../src/man.c:3613
found =
db_ok =
found =
db_ok =
#7 locate_page_in_manpath (page_section=,
page_name=page_name@entry=0x7ffef1c470b2 "apt-get",
candidates=candidates@entry=0x7ffef1c46038,
found=found@entry=0x7ffef1c460f4) at ../../../src/man.c:3971
manpathlist_node = 0x2
manpathlist_iter = {vtable = 0x5586d79cb500
, list = 0x5586d99e7e30, count = 2, p =
0x5586d99f0130, q = 0x5586d99f0130, i = 0, j = 0}
mp = 0x5586d99f0140 "/usr/share/man"
MPI_LABEL_1_done_3970 =
MPI_LABEL_2_done_3970 =
MPI_LABEL_4_break_3970 =
#8 0x5586d79bd29b in man (name=0x7ffef1c470b2 "apt-get",
found=0x7ffef1c460f4) at ../../../src/man.c:4003
section_list_node = 0x4
section_list_iter = {vtable = 0x5586d79cb500
, list = 0x5586d99e57a0, count = 17, p =
0x5586d99e7cd0, q = 0x5586d99e7d38, i = 0, j = 0}
sec = 0x5586d99e7a70 "8"
page_name =
page_section =
candidates = 0x0
cand =
candnext =
MPI_LABEL_1_done_4002 =
MPI_LABEL_2_done_4002 =
MPI_LABEL_4_break_4002 =
#9 0x5586d79b5786 in main (argc=, argv=out>) at ../../../src/man.c:4385
found_subpage =
status =
found = 0
maybe_section = false
nextarg = 0x7ffef1c470b2 "apt-get"
argc_env =
exit_status = 0
argv_env =
tmp =
__PRETTY_FUNCTION__ = "main"
(gdb) info registers
rax0x7f557cc84e98 140005142449816
rbx0x7ffef1c45940 140732954597696
rcx0x7f557cc84e98 140005142449816
rdx0x3048
rsi0x2010201 33620481
rdi0x6197
rbp0x100x10
rsp0x7ffef1c42be8 0x7ffef1c42be8
r8 0x1016
r9 0x0 0
r100x7ffef1c45310 140732954596112
r110x7ffef1c45940 140732954597696
r120x7ffef1c45530 140732954596656
r130x61
Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)
Package: libc6 Version: 2.37-3 Severity: important Dear maintainers, I've just upgraded to libc6 2.37-3 and now I have an almost broken system. But broken in a very weird way: the graphical user interface (KDE Plasma) is coming up, I can start big programs like Firefox, Thunderbird, etc., but as soon as I go to a shell — it doesn't matter if I'm inside or outside the graphical session, ie. tty2 vs. tty3 — I can execute almost no program. ldd works, surprisingly gdb works as well, but eg. man or apt-get or perl do not. They all end with $ man apt-get Segmentation fault (core dumped) Since gdb is working, I got a backtrace, even though that is not that helpful, I fear. $ gdb --args man apt-get GNU gdb (Debian 13.2-1) 13.2 [...] Reading symbols from man... (No debugging symbols found in man) (gdb) r Starting program: /usr/bin/man apt-get [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x7ffa2b4f8f36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x7ffa2b4f8f36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7ffa2b4c6d49 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x7ffa2b4c826d in fnmatch () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #3 0x561538c0ca49 in ?? () No symbol table info available. #4 0x561538c0d042 in ?? () No symbol table info available. #5 0x561538c1018c in ?? () No symbol table info available. #6 0x561538c1329b in ?? () No symbol table info available. #7 0x561538c0b786 in ?? () No symbol table info available. #8 0x7ffa2b4136ca in ?? () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #9 0x7ffa2b413785 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #10 0x561538c0bca1 in ?? () No symbol table info available. (gdb) info registers rax0x7ffa2b084e98 140712440516248 rbx0x7ffca64594a0 140723098064032 rcx0x7ffa2b084e98 140712440516248 rdx0x3048 rsi0x2010201 33620481 rdi0x6197 rbp0x100x10 rsp0x7ffca6456748 0x7ffca6456748 r8 0x1016 r9 0x0 0 r100x7ffca6458e70 140723098062448 r110x7ffca64594a0 140723098064032 r120x7ffca6459090 140723098062992 r130x6197 r140x1016 r150x7ffca6459094 140723098062996 rip0x7ffa2b4f8f36 0x7ffa2b4f8f36 eflags 0x10246 [ PF ZF IF RF ] cs 0x3351 ss 0x2b43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 Perl was failing with a call to towupper(). The KDE session is also incomplete, eg. audio devices are no longer found. During the update I saw errors towards the end (post-install scripts) for libc6 (and some others, which should not matter here). Ie. the post-install script could not be executed with the core dumped/segmentation fault. It also doesn't matter what shell I use, I've tried bash and dash. This might be related to #1040140 reportbug is not working either, so you have to do without the automatically generated system information, but I do try to reproduce it here as close as I can. Now I will try to downgrade my system and get it fully functional again. Cheers, Kai -- System Information: Debian Release: trixie/sid APT prefers testing Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12) x86_64 GNU/Linux Locale: LANG=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1037346: Lost all emails during update
Dear Michael,
On Tue, 13 Jun 2023 21:43:34 +1000 Michael Stockenhuber
wrote:
> Thank you very much for this report and a possible solution. Exactly the
> same happened to me on upgrade to bookworm. Can you please elaborate how
> you did this in detail? I really would be in trouble if I lose the emails.
> I know this is a big ask but I would really appreciate your help.
Sure, I created a small quick'n'dirty helper script to automate some things
(see below), I added the comments for this post. The script was created
iteratively while figuring out how the recovering might work. I worked on the
live system and relied on my backup. I did not spent any time to make the
script fail-safe or even readable, sorry. (Be sure to backup the spool
directory..)
===
#!/bin/bash
# the cyrus spool dir
SPOOLDIR=/var/spool/cyrus/mail/
# first argument is relative spool dir of user e.g.: $ scriptname k/user/kai
# extract user and reformat for cm command of cyadmin
# k/user/kai -> user.kai
USER=$(echo $1|cut -d/ -f 2,3|tr "/" ".")
# find all mailboxes of user and reformat for cm
MBXLIST=$(find $SPOOLDIR$1 -type d|cut -d/ -f 1-8 --complement|tr "/ " "._")
# generate a script for cyradm to create new mailboxes
for MBX in $MBXLIST; do
echo cm $USER.$MBX
done > creatembx.cyradm
echo starting shell to examine the situation
echo creatembx.cyradm created to feed cyradm \(please review\)
echo continue with exit
# start a shell to check cyradmin script and general situation
# you need to feed the cyradmin script to cyadmin with
# $ cat creatembx.cyradm | cyradm --user cyrus localhost
bash
# generate a script to hard-link to the new location
for MBX in $MBXLIST; do
# get path of created mailbox
NEWPATH=$(/usr/lib/cyrus/bin/mbpath $USER.$MBX)
# get original path of mailbox
OLDPATH=$SPOOLDIR$1/${MBX//\./\/}
# link it
echo ln -f ${OLDPATH//_/\\ }/\* $NEWPATH
done | tee linkmbx.bash
echo linkmbx.bash created, please review before executing
echo manual work:
echo 1. might be too many argument, review output
echo 2. main inbox not linked, create inbox_recovered
==
(be sure you understand each step of the script and be sure that it fits to
your configuration.)
You need to apply this script for all users on your systems (~20 users on my
system). Then you should see all sub-mailboxes filled with mails.
I treated the INBOX differently because the server was already receiving new
mail and out them into the INBOX. To avoid any interferences I created a
mailbox inbox_recovered for each user with cyradm:
$ cyradm --user cyrus localhost
xxx.xxx> cm user.kai.inbox_recovered
ctrl-d
and hard-linked the mails with
$ cd `mbpath user.kai.inbox_recovered`
$ ln -f /var/spool/cyrus/mail/k/user/kai/* .
(these are the commands from by bash history)
some final thoughts:
- I did all the operations as the user cyrus
- I used hard-linking to avoid copying 10s of Gigs of mails
- it fails with unusual characters because of not escaping them
- new mailbox use underscore instead of blank (did not want to escape too)
Total time for my system: 6 hours with analysis, learnings, and recovering
Feel free to ask, if anything was too unclear, of if you want to know why I
did sth this way (sometime there might be a reason, sometimes I did not know
better)
Good luck
Kai
Bug#1037346: new upstream bug
Dear Maintainer, a new upstream bug was filed on github https://github.com/cyrusimap/cyrus-imapd/issues/4532. Best -Kai
Bug#1037346: cyrus-imapd: all emails disappeared after upgrading from bullseye to bookworm (similar to #1007965)
Package: cyrus-imapd Version: 3.6.1-4 Severity: important Dear Maintainer, today I upgraded our famliy+friends email server system from bullseye to bookworm including the cyrus-imapd upgrade to v3.6.1-4. Unfortunately, all mails of all users disappeared and new inboxes were autocreated when users logged in: --syslog- Jun 11 12:27:15 xxx cyrus/imaps[1730301]: autocreateinbox: User x, INBOX was successfully created - The emails were still in the non-uuid directory of the cyrus spool dir. I did not figure out how this happened, but I solved it by 1. extracting a list of all sub-mailboxes of all users from the filesystem structure, 2. re-creating the same sub-mailboxes with the cm command of cyradm, 3. and hard-linking all directory content to the new uuid dirs (with the help of mbpath) The issue is now solved for me, but I can provide additional system information and logs if needed. (same report goes to https://github.com/cyrusimap/cyrus-imapd/issues/4035) -Kai -- System Information: Debian Release: 12.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cyrus-imapd depends on: ii cyrus-common 3.6.1-4 ii libc6 2.36-9 ii libcom-err2 1.47.0-2 ii libsasl2-22.1.28+dfsg-10 ii libssl3 3.0.9-1 ii libwrap0 7.6.q-32 ii zlib1g1:1.2.13.dfsg-1 Versions of packages cyrus-imapd recommends: ii rsync 3.2.7-1 cyrus-imapd suggests no packages. -- no debconf information
Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work
As a workaround I created a file /etc/initramfs-tools/hooks/libgcc: . /usr/share/initramfs-tools/hook-functions copy_file library /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib/x86_64-linux-gnu/libgcc_s.so.1 With this hook the lib is copied an I am able to provide a password at login.
Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work
Package: cryptsetup Version: 2:2.6.1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: kai.weber+deb...@glorybox.de Dear Maintainer, Today's upgrade triggered a rebuild of the initramfs. After a reboot I can no longer login to my system. Using an older kernel worked. This ist the error message: Please unlock disk nvme0n1p3_crypt: libgcc_s.so.1 must be installed for pthread_exit to work Aborted cryptsetup: ERROR: nvme0n1p3_crypt: cryptsetup failed, bad password or options? Some investigations: - update-initramfs does indeed not copy libpthread.so or libgcc_s.so - none of the binaries copied during the update seem to depend on those libraries - attached is the debug output I added to the copy_exec function (echo "$src $x" >> /tmp/dependencies.log) Doing some research I found an older bug #950254 that helped me debugging the issue -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-6.1.0-4-amd64 root=/dev/mapper/dummy--vg-root ro quiet -- /etc/crypttab nvme0n1p3_crypt UUID=e9aff144-a836-49d6-8640-01f4b7c3bb8b none luks,discard -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # /dev/mapper/dummy--vg-root / ext4errors=remount-ro 0 1 # /boot was on /dev/nvme0n1p2 during installation UUID=0d9a09b3-abe6-4831-ad3a-166f68e6c77f /boot ext2defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=D114-FD63 /boot/efi vfatumask=0077 0 1 /dev/mapper/dummy--vg-swap_1 noneswapsw 0 0 -- lsmod Module Size Used by snd_usb_audio 376832 1 snd_usbmidi_lib45056 1 snd_usb_audio snd_rawmidi53248 1 snd_usbmidi_lib xt_conntrack 16384 1 nft_chain_nat 16384 3 xt_MASQUERADE 20480 1 nf_nat 57344 2 nft_chain_nat,xt_MASQUERADE nf_conntrack_netlink57344 0 nf_conntrack 188416 4 xt_conntrack,nf_nat,nf_conntrack_netlink,xt_MASQUERADE nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack xfrm_user 53248 1 xfrm_algo 16384 1 xfrm_user xt_addrtype16384 2 nft_compat 20480 4 nf_tables 286720 57 nft_compat,nft_chain_nat libcrc32c 16384 3 nf_conntrack,nf_nat,nf_tables nfnetlink 20480 4 nft_compat,nf_conntrack_netlink,nf_tables br_netfilter 32768 0 bridge311296 1 br_netfilter stp16384 1 bridge llc16384 2 bridge,stp typec_displayport 16384 1 ctr16384 2 ccm20480 6 uhid 20480 1 rfcomm 94208 4 cmac 16384 3 snd_seq_dummy 16384 0 snd_hrtimer16384 1 algif_hash 16384 1 snd_seq90112 7 snd_seq_dummy algif_skcipher 16384 1 snd_seq_device 16384 2 snd_seq,snd_rawmidi af_alg 36864 6 algif_hash,algif_skcipher overlay 159744 0 qrtr 49152 4 bnep 28672 2 binfmt_misc24576 1 nls_ascii 16384 1 nls_cp437 20480 1 vfat 24576 1 fat90112 1 vfat snd_sof_pci_intel_skl16384 0 snd_sof_intel_hda_common 188416 1 snd_sof_pci_intel_skl soundwire_intel49152 1 snd_sof_intel_hda_common soundwire_generic_allocation16384 1 soundwire_intel snd_hda_codec_hdmi 81920 1 soundwire_cadence 40960 1 soundwire_intel snd_sof_intel_hda 20480 1 snd_sof_intel_hda_common snd_sof_pci24576 2 snd_sof_intel_hda_common,snd_sof_pci_intel_skl snd_sof_xtensa_dsp 16384 1 snd_sof_intel_hda_common iwlmvm385024 0 snd_sof 274432 2 snd_sof_pci,snd_sof_intel_hda_common snd_ctl_led24576 0 intel_pmc_core_pltdrv16384 0 intel_pmc_core 53248 0 snd_hda_codec_realtek 172032 1 snd_sof_utils 20480 1 snd_sof soundwire_bus 102400 3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence x86_pkg_temp_thermal20480 0 intel_powerclamp 20480 0 snd_hda_codec_generic98304 1 snd_hda_codec_realtek joydev 28672 0 coretemp 20480 0 mac80211 1171456 1 iwlmvm snd_soc_skl 184320 0 btusb 65536 0 snd_soc_hdac_hda 24576 2 snd_sof_intel_hda_common,snd_soc_skl mei_hdcp 24576 0 snd_hda_ext_core 40960 3
Bug#1028508: python3-packaging: Please package 23.0, 22.0 has an annoying bug
Package: python3-packaging Version: 22.0-2 Severity: normal X-Debbugs-Cc: kai.weber+deb...@glorybox.de Dear Maintainer, please consider packaging the latest version 23.0. Version 22.0 introduced a problem that affects some packages. See here for the upstream bug report https://github.com/pypa/packaging/issues/629 And here a report from the pipx project https://github.com/pypa/pipx/issues/924 Thanks for your work! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/8 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 python3-packaging depends on: ii python3 3.11.1-1 python3-packaging recommends no packages. python3-packaging suggests no packages. -- no debconf information
Bug#1016735: O: safe-iop -- Safe integer operation library
Package: wnpp Severity: normal This is a dependency of Android SDK components. I am no longer active in Debian. Therefore, I orphan this package. OpenPGP_0xDD1FAB8937FE9825.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1010764: openafs-modules-dkms: module fails to build for kernel 5.17.0-1-amd64
Package: openafs-modules-dkms Version: 1.8.8.1-2 Severity: important Dear Maintainer, * What led up to the situation? - regular apt upgrade on testing * What exactly did you do that was effective? - switch to kernel 5.16.0-6-amd64 The module built fine for this slightly older kernel. * What was the outcome of this action? - I am unable to use openafs with kernel 5.17 * What outcome did you expect instead? - a working openafs module for kernel 5.17 /var/lib/dkms/openafs/1.8.8.1/build/make.log seems to indicate a problem with the function complete_and_exit() in afs_call_nfs.c : --- DKMS make.log for openafs-1.8.8.1 for kernel 5.17.0-1-amd64 (x86_64) Mon 9 May 17:10:20 CEST 2022 checking for gcc... gcc-11 (...) CC [M] /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/osi_proc.o CC [M] /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/osi_vnodeops.o /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/osi_vnodeops.c: In function ‘afs_linux_can_bypass’: /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/osi_vnodeops.c:2700:16: warning: this statement may fall through [-Wimplicit-fallthrough=] 2700 | if (i_size_read(ip) > cache_bypass_threshold) | ^ /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/osi_vnodeops.c:2703:9: note: here 2703 | default: | ^~~ CC [M] /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/osi_pagecopy.o CC [M] /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/afs_nfsclnt.o CC [M] /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/afs_nfsdisp.o CC [M] /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/afs_call_nfs.o /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/afs_call_nfs.c: In function ‘afsd_thread’: /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/afs_call_nfs.c:331:9: error: implicit declaration of function ‘complete_and_exit’ [-Werror=implicit-function-declaration] 331 | complete_and_exit(0, 0); | ^ cc1: some warnings being treated as errors make[4]: *** [/usr/src/linux-headers-5.17.0-1-common/scripts/Makefile.build:293: /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP/afs_call_nfs.o] Error 1 make[3]: *** [/usr/src/linux-headers-5.17.0-1-common/Makefile:1855: /var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP] Error 2 make[3]: Leaving directory '/usr/src/linux-headers-5.17.0-1-amd64' FAILURE: make exit code 2 make[2]: *** [Makefile.afs:279: openafs.ko] Error 1 make[2]: Leaving directory '/var/lib/dkms/openafs/1.8.8.1/build/src/libafs/MODLOAD-5.17.0-1-amd64-SP' make[1]: *** [Makefile:186: linux_compdirs] Error 2 make[1]: Leaving directory '/var/lib/dkms/openafs/1.8.8.1/build/src/libafs' make: *** [Makefile:15: all] Error 2 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openafs-modules-dkms depends on: ii dkms 2.8.7-2 ii libc6-dev 2.33-7 ii perl 5.34.0-4 Versions of packages openafs-modules-dkms recommends: ii openafs-client 1.8.8.1-2 openafs-modules-dkms suggests no packages. -- no debconf information -- Kai-Martin Knaak kn...@iqo.uni-hannover.de Universität Hannover, Inst. für Quantenoptik tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover fax: +49-511-762-2211 PGP-Key: https://keys.openpgp.org/search?q=kn...@iqo.uni-hannover.de pgpSxcK9A8bir.pgp Description: OpenPGP digital signature
Bug#1008776: intel-media-va-driver: Segmentation fault with gstreamer based applications
* Sebastian Ramacher : > That could be another case of the driver expecting to have a kernel > available which in fact is disabled in the open source build. If > 22.3.1+dfsg1-1 doesn't fix the issue for you, please let my know your > CPU/GPU so that the issue can be reported upstream. Unfortunately it does not solve the issue. Here are my CPU/GPU types: CPU: Intel® Core™ i7-8550U CPU @ 1.80GHz × 8 GPU: Mesa Intel® UHD Graphics 620 (KBL GT2)
Bug#1008776: intel-media-va-driver: Segmentation fault with gstreamer based applications
Package: intel-media-va-driver Version: 22.3.0+dfsg1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: kai.weber+deb...@glorybox.de Dear Maintainer, since a recent update (can not excalty determine the date) gstreamer based applications like totem or gst-play-1.0 itself segfault on video files. Removing intel-media-va-driver resolves the issue. Installing intel-media-va-driver-non-free resolves the issue. Attached is a backtrace. I have no experience getting backtraces. This one was achieved after install the intel-media-va-driver-dbgsym package and running $ export DEBUGINFOD_URLS="https://debuginfod.debian.net; $ gdb --args gst-play-1.0 /home/kai/Downloads/pony.mp4 --videosink=glimagesink Thread 14 "qtdemux0:sink" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb77fe640 (LWP 22147)] 0x7fffb5f906be in KernelDll_AllocateStates (pKernelBin=, uKernelSize=0, pFcPatchCache=0x0, uFcPatchCacheSize=, pDefaultRules=0x0, ModifyFunctionPointers=0x0) at ./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c:2791 Download failed: Invalid argument. Continuing without source file ./obj-x86_64-linux-gnu/media_driver/./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c. 2791./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c: No such file or directory. (gdb) set logging file backtrace.log (gdb) set logging on Copying output to backtrace.log. (gdb) bt ... (gdb) set logging off Done logging to backtrace.log. (gdb) quit -- 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/8 CPU threads; PREEMPT) 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:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages intel-media-va-driver depends on: ii libc6 2.33-7 ii libgcc-s1 12-20220319-1 ii libigdgmm12 22.1.2+ds1-1 ii libstdc++6 12-20220319-1 ii libva2 [libva-driver-abi-1.14] 2.14.0-1 intel-media-va-driver recommends no packages. intel-media-va-driver suggests no packages. -- no debconf information #0 0x7fffb5f906be in KernelDll_AllocateStates (pKernelBin=, uKernelSize=0, pFcPatchCache=0x0, uFcPatchCacheSize=, pDefaultRules=0x0, ModifyFunctionPointers=0x0) at ./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c:2791 #1 0x7fffb5f82028 in VphalRenderer::Initialize (this=0x7fffa813d480, pSettings=0x7fffb77fae80, isApoEnabled=) at ./media_driver/agnostic/common/vp/hal/vphal_renderer.cpp:1418 #2 0x7fffb5f67a89 in VphalState::Allocate (this=0x7fffa8123e50, pVpHalSettings=0x7fffb77fae80) at ./media_driver/agnostic/common/vp/hal/vphal.cpp:201 #3 0x7fffb61848a2 in DdiVp_InitVpHal (pVpCtx=0x7fffa812add0) at ./media_driver/linux/common/vp/ddi/media_libva_vp.c:1811 #4 0x7fffb6189460 in DdiVp_InitCtx (pVaDrvCtx=, pVpCtx=0x7fffa812add0) at ./media_driver/linux/common/vp/ddi/media_libva_vp.c:1671 #5 0x7fffb618985e in DdiVp_CreateContext (pVaDrvCtx=pVaDrvCtx@entry=0x7fffa8081e20, vaConfigID=vaConfigID@entry=0, iWidth=iWidth@entry=0, iHeight=iHeight@entry=0, iFlag=iFlag@entry=0, vaSurfIDs=vaSurfIDs@entry=0x0, iNumSurfs=0, pVaCtxID=0x7fffb77fb1ac) at ./media_driver/linux/common/vp/ddi/media_libva_vp.c:3291 #6 0x7fffb6147be2 in DdiMedia_PutImage (ctx=0x7fffa8081e20, surface=0, image=, src_x=0, src_y=0, src_width=64, src_height=64, dest_x=0, dest_y=0, dest_width=64, dest_height=64) at ./media_driver/linux/common/ddi/media_libva.cpp:5535 #7 0x7fffd425521c in vaPutImage () from /lib/x86_64-linux-gnu/libva.so.2 #8 0x7fffd42def8d in ?? () from /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so #9 0x7fffd429d686 in ?? () from /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so #10 0x7fffd42a480e in ?? () from /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so #11 0x777ac5cb in ?? () from /lib/x86_64-linux-gnu/libgstbase-1.0.so.0 #12 0x777b014d in ?? () from /lib/x86_64-linux-gnu/libgstbase-1.0.so.0 #13 0x77b912f0 in gst_pad_query () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 #14 0x77b91a1b in gst_pad_peer_query () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 #15 0x77bd14b8 in gst_pad_peer_query_caps () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 #16 0x777afe28 in ?? () from /lib/x86_64-linux-gnu/libgstbase-1.0.so.0 #17 0x77b912f0 in gst_pad_query () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 #18 0x77b91a1b in gst_pad_peer_query () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 #19 0x77bcb858 in ?? () from /lib/x86_64-linux-gnu/libgstream
Bug#1000616: upstream bug url
I opened a kernel bugzilla issue where I also pasted a similar trace from an arm64 device: https://bugzilla.kernel.org/show_bug.cgi?id=215571
Bug#1000616: linked bug fix commit is not relevant
I just checked again and the linked bug fix commit is not relevant because it addresses a problem introduced in v5.16-rc1
Bug#995420: bt-full with debug symbols
Here the paste for running gdb bt and bt full with debug symbols: https://paste.debian.net/1229712
Bug#1000616: Kernel list_del corruption. next->prev should be ...
With 5.16~rc4-1~exp1 I couldn't reproduce it, the system is running for 8 days now and I also filled my swap while doing some small tasks but nothing triggered it.
Bug#1000616: Kernel list_del corruption. next->prev should be ...
Found it, that linked patch is in 5.16-rc2¹ while the debian package has rc1, maybe it still makes sense to try to reproduce if the patch is unrelated https://lwn.net/Articles/876660/
Bug#1000616: Kernel list_del corruption. next->prev should be ...
Hi, yes, good idea, will do it as it looks promising seeing that there is some related patch in 5.16 (not sure if it's in the package you mentioned, though): https://lore.kernel.org/all/yyp40a2lnrxaz...@casper.infradead.org/T/#u I'll try out if I can reproduce it with 5.16 or whether it's gone.
Bug#1000616: Kernel list_del corruption. next->prev should be ...
Package: linux-image-5.15.0-1-amd64 Version: 5.15.3-1 I often hit this bug here, often shortly before others are hit which render the system unusable. Here the dmesg log section from pstore: <3>[ 257.036085] list_del corruption. next->prev should be dfd4c8b732c8, but was 98adb59f5830 <4>[ 257.036115] [ cut here ] <2>[ 257.036117] kernel BUG at lib/list_debug.c:54! <4>[ 257.036129] invalid opcode: [#1] SMP NOPTI <4>[ 257.036137] CPU: 1 PID: 3955 Comm: xdg-document-po Tainted: G I 5.15.0-1-amd64 #1 Debian 5.15.3-1 <4>[ 257.036146] Hardware name: LENOVO 20CLS2LJ00/20CLS2LJ00, BIOS N10ET38W (1.17 ) 08/20/2015 <4>[ 257.036150] RIP: 0010:__list_del_entry_valid.cold+0x1d/0x47 <4>[ 257.036164] Code: c7 c7 d8 c5 d5 aa e8 32 f7 fe ff 0f 0b 48 89 fe 48 c7 c7 68 c6 d5 aa e8 21 f7 fe ff 0f 0b 48 c7 c7 18 c7 d5 aa e8 13 f7 fe ff <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 d8 c6 d5 aa e8 ff f6 fe ff 0f 0b <4>[ 257.036170] RSP: 0018:a6ba0182b958 EFLAGS: 00010046 <4>[ 257.036178] RAX: 0054 RBX: a6ba0182bab0 RCX: dmesg-efi-163787479303001: Oops#1 Part3 <4>[ 257.036183] RDX: RSI: 98afc5c60880 RDI: 98afc5c60880 <4>[ 257.036188] RBP: dfd4c8b732c0 R08: R09: a6ba0182b788 <4>[ 257.036192] R10: a6ba0182b780 R11: ab2d21c8 R12: 0002 <4>[ 257.036197] R13: a6ba0182bae0 R14: a6ba0182b998 R15: dfd4c8b73248 <4>[ 257.036202] FS: 7f3313ed5380() GS:98afc5c4() knlGS: <4>[ 257.036208] CS: 0010 DS: ES: CR0: 80050033 <4>[ 257.036213] CR2: 7f5434002078 CR3: 35acc005 CR4: 003706e0 <4>[ 257.036219] Call Trace: <4>[ 257.036224] <4>[ 257.036228] release_pages+0x2eb/0x510 <4>[ 257.036244] __pagevec_release+0x1c/0x50 <4>[ 257.036254] truncate_inode_pages_range+0x157/0x520 <4>[ 257.036264] ? schedule+0x44/0xa0 <4>[ 257.036271] ? schedule_hrtimeout_range_clock+0x9d/0x120 <4>[ 257.036281] ? __inode_wait_for_writeback+0x7e/0xf0 <4>[ 257.036294] fuse_evict_inode+0x16/0xd0 [fuse] <4>[ 257.036320] evict+0xce/0x180 <4>[ 257.036330] __dentry_kill+0xe1/0x180 <4>[ 257.036337] shrink_dentry_list+0x4e/0xc0 <4>[ 257.036344] shrink_dcache_parent+0xd1/0x120 <4>[ 257.036352] d_invalidate+0x66/0xe0 <4>[ 257.036359] ? dput+0x32/0x300 <4>[ 257.036366] fuse_reverse_inval_entry+0xbd/0x1e0 [fuse] <4>[ 257.036385] fuse_dev_do_write+0x54b/0xee0 [fuse] <4>[ 257.036404] ? __pollwait+0xd0/0xd0 <4>[ 257.036416] fuse_dev_write+0x4f/0x80 [fuse] <4>[ 257.036449] do_iter_readv_writev+0x14f/0x1b0 <4>[ 257.036462] do_iter_write+0x7c/0x1c0 <4>[ 257.036473] vfs_writev+0xaa/0x140 <4>[ 257.036485] ? ktime_get_ts64+0x49/0xf0 <4>[ 257.036494] do_writev+0x6b/0x110 <4>[ 257.036505] do_syscall_64+0x38/0xc0 <4>[ 257.036512] entry_SYSCALL_64_after_hwframe+0x44/0xae dmesg-efi-163787479302001: Oops#1 Part2 <4>[ 257.036523] RIP: 0033:0x7f3314351a6d <4>[ 257.036529] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 6a f9 f8 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 be f9 f8 ff 48 <4>[ 257.036535] RSP: 002b:7ffde2997830 EFLAGS: 0293 ORIG_RAX: 0014 <4>[ 257.036543] RAX: ffda RBX: 0003 RCX: 7f3314351a6d <4>[ 257.036547] RDX: 0003 RSI: 7ffde29978a0 RDI: 0007 <4>[ 257.036552] RBP: 7ffde29978a0 R08: R09: 7f33145b82c0 <4>[ 257.036556] R10: 7f3333a0 R11: 0293 R12: 563a24a49690 <4>[ 257.036560] R13: 0003 R14: 7f333440 R15: 563a24a1f8c0 <4>[ 257.036567] <4>[ 257.036570] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat iscsi_target_mod target_core_mod nft_masq nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bridge stp llc nf_tables nfnetlink ctr bnep overlay ccm algif_aead des_generic libdes ecb algif_skcipher cpufreq_userspace cpufreq_powersave cmac cpufreq_ondemand cpufreq_conservative md4 algif_hash lz4 af_alg lz4_compress zram zsmalloc btusb btrtl btbcm btintel bluetooth jitterentropy_rng uvcvideo videobuf2_vmalloc videobuf2_memops sha512_ssse3 videobuf2_v4l2 videobuf2_common sha512_generic videodev mc drbg ansi_cprng ecdh_generic ecc crc16 binfmt_misc nls_ascii nls_cp437 vfat fat joydev intel_rapl_msr intel_rapl_common mei_wdt x86_pkg_temp_thermal intel_powerclamp iwlmvm snd_ctl_led watchdog snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi dmesg-efi-163787479301001: Oops#1 Part1 <4>[ 257.036705] kvm_intel snd_hda_intel mei_hdcp mac80211 kvm snd_intel_dspcfg snd_intel_sdw_acpi irqbypass libarc4 snd_hda_codec rapl
Bug#998359: age fails reading passphrase-protected key files
Package: age Version: 1.0.0~rc1-2+b3 Severity: grave Justification: renders package unusable Dear Maintainer, this is how you can reproduce the bug: $ age-keygen | age -p > tmp/key.age Public key: age17sxjygr9yuvv7s5yd657gfw6v2c9597938ur2smug4u9fysrxdms2p9h0y Enter passphrase (leave empty to autogenerate a secure one): Using the autogenerated passphrase "dolphin-coffee-erase-table-denial-remain-orphan-gym-debris-episode". $ age -r age17sxjygr9yuvv7s5yd657gfw6v2c9597938ur2smug4u9fysrxdms2p9h0y -o /tmp/passwd.age /etc/passwd $ age -d -i tmp/key.age -o /tmp/passwd /tmp/passwd.age Error reading "tmp/key.age": failed to read "tmp/key.age": error at line 1: malformed secret key: separator '1' at invalid position: pos=20, len=21 [ Did age not do what you expected? Could an error be more useful? Tell us: https://filippo.io/age/report ] Being unable to use passphrase-protected key files renders this package unusable. This bug is not present in upstream v1.0.0. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/1 CPU thread) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 age depends on: ii libc6 2.31-13+deb11u2 age recommends no packages. age suggests no packages. -- no debconf information
Bug#997889: bison: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bison)
Hi, glibc 2.32-4 migrated to testing on 2021-09-22. Please upgrade your libc6 package to the latest version, and that should fix the issue. Thank you! Chuan-kai
Bug#995420: D-Bus crash atk-bridge
Package: epiphany-browser Version: 41.0-2 A few seconds after startup the app crashes with the following error printed on the console: (WebKitWebProcess:2): dbind-WARNING **: 22:39:12.184: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown dbus[10454]: arguments to dbus_message_new_method_call() were incorrect, assertion "destination == NULL || _dbus_check_is_valid_bus_name (destination)" failed in file ../../../dbus/dbus-message.c line 1364. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace (WebKitWebProcess:2): WPE-FDO-ERROR **: 22:39:16.262: Failed to bind wpe_bridge Abgebrochen (Speicherabzug geschrieben) The systemd-coredump entry is: Message: Process 9820 (epiphany) of user 1000 dumped core. Stack trace of thread 9820: #0 0x7faa00e23e71 __GI_raise (libc.so.6 + 0x3ce71) #1 0x7faa00e0d536 __GI_abort (libc.so.6 + 0x26536) #2 0x7fa9f92e0d62 n/a (libdbus-1.so.3 + 0xed62) #3 0x7fa9f9303b60 _dbus_warn_check_failed (libdbus-1.so.3 + 0x31b60) #4 0x7fa9f92f32d2 dbus_message_new_method_call (libdbus-1.so.3 + 0x212d2) #5 0x7fa9fb10eebd n/a (libatk-bridge-2.0.so.0 + 0xfebd) #6 0x7fa9fdbc779c n/a (libwebkit2gtk-4.0.so.37 + 0xb8379c) #7 0x7fa9fd764067 n/a (libwebkit2gtk-4.0.so.37 + 0x720067) #8 0x7fa9fd759370 n/a (libwebkit2gtk-4.0.so.37 + 0x715370) #9 0x7fa9fd9879eb n/a (libwebkit2gtk-4.0.so.37 + 0x9439eb) #10 0x7fa9fda83f13 n/a (libwebkit2gtk-4.0.so.37 + 0xa3ff13) #11 0x7fa9fd980e25 n/a (libwebkit2gtk-4.0.so.37 + 0x93ce25) #12 0x7fa9fd982d5e n/a (libwebkit2gtk-4.0.so.37 + 0x93ed5e) #13 0x7fa9fcc26cdd _ZN3WTF7RunLoop11performWorkEv (libjavascriptcoregtk-4.0.so.18 + 0x159dcdd) #14 0x7fa9fcc75879 n/a (libjavascriptcoregtk-4.0.so.18 + 0x15ec879) #15 0x7fa9fcc7619f n/a (libjavascriptcoregtk-4.0.so.18 + 0x15ed19f) #16 0x7faa011b0c0f g_main_context_dispatch (libglib-2.0.so.0 + 0x53c0f) #17 0x7faa011b0fb8 n/a (libglib-2.0.so.0 + 0x53fb8) #18 0x7faa011b106f g_main_context_iteration (libglib-2.0.so.0 + 0x5406f) #19 0x7faa013cd7d5 g_application_run (libgio-2.0.so.0 + 0xe27d5) #20 0x55b0b4109c24 n/a (epiphany + 0x4c24) #21 0x7faa00e0ee4a __libc_start_main (libc.so.6 + 0x27e4a) #22 0x55b0b4109efa n/a (epiphany + 0x4efa)
Bug#987671: gnome-disk-utility: User could possibly erase/format the hard disk without giving any password
Severity: minor Hi, thanks for reporting this but it is not a dangerous bug because the disk wiping in your case on the USB stick could have been done anyway without password while for system drives this always requires a password. The confusing behavior in GNOME Disks is that it always wipes the drive after encountering an error during the restore image operation, but also treated authentification errors the same way. I made a patch to skip the disk wiping in case the authentification dialog was dismissed: https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/merge_requests/43 In the future, please report directly to upstream. I just found this bug report by chance. (Also, since UDisks is responsible for the authentification: if it were possible to overwrite arbitrary drives without a password, then it should have been a UDisks bug report, not a GNOME Disks bug report.) Regards, Kai P.S.: Your second response is an HTML message which is only shown on the bug tracker web UI as an attachment.
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Found this in the junk e-mails today... Am 23.02.21 um 19:20 schrieb Sebastiaan Couwenberg: There is still a test failure, though. Refer to the attached buildlog for details. This seems unrelated to PROJ 8.0.0. The failing test creates a QTemporaryFile, removes all permissions from the file via QFile::setPermissions(), and expects QFileInfo::readable() to return false for the path of the temporary file. This expectation seems to be not met. The test may be volatile, but worked so far, and I didn't have a better idea how to solve this in a portable way. If there is another change in the environment, hints are welcome. Best regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 24.02.21 um 08:46 schrieb Sebastiaan Couwenberg: On 2/24/21 8:04 AM, Kai Pastor, DG0YT wrote: I would agree that many projects have shortcoming in how they use CMake, partly due to past shortcomings of CMake and its documentation, partly due to ignorance of cross-platform building and packaging. But IMO it goes to far when you imply that CMake is to blame for issues with paths and reproducibility. CMake uses abolute paths, whereas autotools uses relative paths. How is CMake not to blame from issues that arise from that? If issue arise from the use of absolute path, it is okay to consider to CMake as a cause of this issues. But it doesn't mean it can always be blamed. Example: This Debian package was flagged to not build reproducible, due to absolute paths in binaries. But the installed artifacts were fully reproducible. The offending binaries were tests which were meant to be run in the build environment, nowhere else. Since your more comfortable with CMake, maybe you can help upstream the pkg-config patch so that the Fedora package doesn't have to patch the CMake build to have proj.pc installed. Did Fedora try to do that? We really need to get downstream projects more involved in PROJ development to help support their needs. Sure. I'm doing that for at least for PROJ, GDAL, Qt, Poppler. And I really want to use the small gains in build time CMake can offer e.g. with Ninja, when working with so many upstreams and platforms. We probably can agree that a packager (infrequent builds of a particular, rare changes to a clean build system, facing many leaf packages) and a developer (frequent builds, regular modifications to the build system, onboarding of new developers, facing many upstream packages) may have different requirements. Best regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 24.02.21 um 05:55 schrieb Sebastiaan Couwenberg: On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote: Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: It's good practice to include the Find modules for any dependencies that are not part of cmake itself to not need upstream projects to install cmake modules for them. I think it is deprecated legacy practice, not good practice. Find modules are poorly standardized, poorly maintained, and poorly tested. It would be much better to provide PROJ config files as soon as possible, instead of letting more developers start using PROJ with non-standard find modules picked from random internet locations. I wonder if there is a blocker for building debian PROJ with CMake. I build PROJ for Android, macOS, Windows from Debian tarballs - with cmake, not using debian/rules. https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake Switching from autotools to cmake is generally a regression, cmake doesn't handle multiarch as well, and because it uses absolute paths instead of relative paths it hinders reproducible builds. See the recent discussion on the geos-devel lists for example: https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html From the mailing list post and its links I learn that a) actively maintained projects do fix reported build system issues quickly. b) there is some confusion about dealing with CMAKE_BUILD_TYPE, NDEBUG and reproducible paths. I would agree that many projects have shortcoming in how they use CMake, partly due to past shortcomings of CMake and its documentation, partly due to ignorance of cross-platform building and packaging. But IMO it goes to far when you imply that CMake is to blame for issues with paths and reproducibility. (Is there a Debian documentation for how to prepare CMake projects to help with Debian multi-arch?) The CMake build of PROJ doesn't seem to provide a pkgconfig file, but even for mips64el, the single proj.pc looks much less complex than the set of cmake config files, or the patch proposed for FindProj4.cmake. We're not going to switch to cmake for the proj package as long as autotools is supported, because that is the best build system from a packaging point of view. Okay, so this covers your packaging point of view where autotools are already available. But it doesn't align with my requirements as a developer, and also not with my experience in single-arch bundling/packaging third-party components for Android, macOS, Windows. (And I wouldn't even say that CMake is the best system for some purpose.) The best solution for downstream projects not wanting to include their own FindProj modules is to update the autotools build system to also install the cmake bits. Perhaps you can provide a patch for that which PROJ upstream can merge? No, I don't think learning autotools and then teaching autotools to provide CMake config files, possibly for multi-arch, is a good use of my resources. But you may ask for patches for PROJ's CMake build system. Multiarch if I can test/verify in an amd_64 environment. Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: A patch for that was just submitted to this bugreport. Thanks. It's good practice to include the Find modules for any dependencies that are not part of cmake itself to not need upstream projects to install cmake modules for them. I think it is deprecated legacy practice, not good practice. Find modules are poorly standardized, poorly maintained, and poorly tested. It would be much better to provide PROJ config files as soon as possible, instead of letting more developers start using PROJ with non-standard find modules picked from random internet locations. I wonder if there is a blocker for building debian PROJ with CMake. I build PROJ for Android, macOS, Windows from Debian tarballs - with cmake, not using debian/rules. https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake The CMake build of PROJ doesn't seem to provide a pkgconfig file, but even for mips64el, the single proj.pc looks much less complex than the set of cmake config files, or the patch proposed for FindProj4.cmake. Kind regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 21.02.21 um 16:32 schrieb Bas Couwenberg: Source: openorienteering-mapper Version: 0.9.4-2 Severity: important Tags: upstream ftbfs User: debian-...@lists.debian.org Usertags: proj-8.0 Control: forwarded -1 https://github.com/OpenOrienteering/mapper/issues/1214 Dear Maintainer, Your package FTBFS with PROJ 8.0.0: CMake Error at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message): Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR) It needs to be ported to use proj.h instead of proj_api.h which has been removed. Kind Regards, Bas Mapper source code is ported to use proj.h for modern PROJ. However, the embedded fallback FindPROJ4.cmake module isn't, and possible won't. Does Debian build PROJ 8.0.0 with cmake? Debian doesn't seem to provide the cmake config files for PROJ. openorienteering-mapper is meant to pick up these config files. If it finds a recent PROJ in that way, it won't use proj_api.h. Regards, Kai
Bug#982164: RFS: geda-gaf/1.10.2-2 [ITA] -- GPL EDA -- Electronics design software
Juhani Numminen schrieb am 10. February 2021: > Another thing. There is a removal of fam in progress.[1] Please edit > Build-Depends so that you don't introduce a dependency on libfam-dev. > > The xorn executable is not too well suited to be in libgeda47 because > its name does not change with SONAME which would make library > transitions difficult.[2] So perhaps put xorn live in geda-utils then? > > [1] https://bugs.debian.org/966273 > [2] > https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#shared-library-support-files Just a quick note: In my current upload to debian-mentors these issues are addressed. The xorn script lives in libgeda-common now. And the package does not depend on libfam-dev any more. A couple of additional changes have reduced the amount of complains by lintian. https://mentors.debian.net/package/geda-gaf/ All the best, ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgp5002Dm405X.pgp Description: OpenPGP digital signature
Bug#885195: [Pkg-electronics-devel] Bug#885195: guile-2.0 removed
Joerg Jaspert schrieb am 13. February 2021: > i just removed guile-2.0 from unstable. > While your package already won't be part of the next release, it will > now also be unusable in unstable. > > Please either upload a fixed version A fixed version sits at debian mentors looking for a sponsor. https://mentors.debian.net/package/geda-gaf/ First upload to debian mentors was last week (Tuesday 9th). I reploaded to amend changes that make lintian complain less and respond to remarks by reviewers. All the best, ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgp5DT0e2autd.pgp Description: OpenPGP digital signature
Bug#982164: RFS: geda-gaf/1.10.2-2 [ITA] -- GPL EDA -- Electronics design software
Following the the suggestion by Roland, I moved the xorn executable to gedalib-common. In addition I removed the closes clause for #936593 and closed #966736 in the changelog. Lintian complained about inconsistent licenses. So I made debian/copyright aware that certain files are GFDL licensed (with no invariant parts). I just uploaded a new version of the source package to debian-mentors and made sure, the sponsor search flag is still set: https://mentors.debian.net/package/geda-gaf/ ---<)kaimartin(>--- pgpZGetl0LOUg.pgp Description: OpenPGP digital signature
Bug#982808: linux-image-5.10.0-3-amd64: Please configure kernel with CONFIG_PWM_CRC=y
Package: src:linux Version: 5.10.13-1 Severity: normal Tags: patch X-Debbugs-Cc: kai.harr...@posteo.de Dear Maintainer, Please consider to set the Linux kernel option "CONFIG_PWM_CRC=y", without that option it is not possible to control the brightness of the display of the Asus T100Chi. Many thanks Regards Kai -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.13.kai (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN 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) LSM: AppArmor: enabled Versions of packages linux-image-5.10.0-3-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.139 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-3-amd64 recommends: ii apparmor 2.13.6-9 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.10.0-3-amd64 suggests: pn debian-kernel-handbook pn grub-pc | grub-efi-amd64 | extlinux pn linux-doc-5.10 Versions of packages linux-image-5.10.0-3-amd64 is related to: ii firmware-amd-graphics 20201218-3 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120201218-3 pn firmware-cavium ii firmware-intel-sound 20201218-3 pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20201218-3 pn firmware-libertas ii firmware-linux-nonfree20201218-3 ii firmware-misc-nonfree 20201218-3 pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#982243: Tested fix from libsane
Hello, I tested the suggested the aforementioned fix in https://gitlab.com/sane-project/backends/-/issues/137 and the Scanner works again. I would ask to merge the fix or pull 1.0.32 from upstream that it will work for other People as well. I hope that this will help.
Bug#982164: RFS: geda-gaf/1.10.2-2 [ITA] -- GPL EDA -- Electronics design software
On Sun, 7 Feb 2021 11:13:53 +0200 Juhani Numminen wrote: > Please also close these two bugs in your changelog: > > #975985, ITA is to be closed when you set yourself as the new > maintainer/uploader [1] > > #747424, requesting the new upstream version done. > The changelog should mention that Bdale removed himself from the list > of Uploaders. [2] done. > The mentors.d.n page shows that the packages still depend on python2, > so are you first making the package name change python->python2 > (#966736) and only later switching to python3 (#936593)? yes. I know, migration to python3 is inevitable. However, the transition from geda-gaf-1.8 to 1.10 involved large amounts of python code. I talked to upstream (Roland Lutz): Migration to python3 will be a little tedious and non-trivial. It will be the main focus of upcoming development, non the less. > If that's the > case, we need to unmerge #966736 and #936593. > > [1] https://www.debian.org/devel/wnpp/#l3 > [2] > https://salsa.debian.org/electronics-team/geda-gaf/-/commit/8633b12b984541ab5ca1c139ffed7d10b3871439 Beeing new to Debian package maintenance, I am unsure how to proceed on this. Should I act on the bugs? Am I allowed to set tags? If so which would be appropriate? ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpIV8wlfctT6.pgp Description: OpenPGP digital signature
Bug#975985: Your mail
I went ahead and adopted the package. I uploaded geda-gaf-1.10.2-1 to debian-mentors. The package is currently waiting for a sponsor to upload it into unstable. So this bug can be closed. https://mentors.debian.net/package/geda-gaf/ ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgp7Oi7St7Vdi.pgp Description: OpenPGP digital signature
Bug#982243: sane-backends: Canoscan N650U does not scan on Testing
Source: sane-backends Version: 1.0.31-4 Severity: normal Tags: upstream Dear Maintainer, I was recently trying to use my old and trusty Scanner CanoScan N650U on my new) Debian Testing Computer (with a AMD B450 chipset). It was as a USB-Device but did not scan. The scanner is not detected in simple-scan or gscan2pdf. (The scanner does however still works on all ports (USB2/USB3) on my Thinkpad X220 on Debian 10.) This bug (regression?) might have to do with the fixed upstream bug https://gitlab.com/sane-project/backends/-/issues/137 which is fixed in 1.0.32. Sadly, I don't know how to do a temporary package replacement to check if the upstream version does fix the problem. If you need for information, please contact me. -- further terminal output $ scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). $ sane-find-scanner found USB scanner (vendor=0x04a9, product=0x2206) at libusb:001:010 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-2-amd64 (SMP w/12 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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
Bug#982164: RFS: geda-gaf/1.10.2-2 [ITA] -- GPL EDA -- Electronics design software
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "geda-gaf": * Package name: geda-gaf Version : 1.10.2-2 Upstream Author : gEDA Contributors * URL : http://www.geda-project.org/ * License : GPL-2+ * Vcs : https://salsa.debian.org/electronics-team/geda-gaf Section : electronics It builds those binary packages: geda-doc - GPL EDA -- Electronics design software (documentation) geda-examples - GPL EDA -- Electronics design software (example designs) geda-cli - GPL EDA -- Electronics design software (gaf utility) geda-utils - GPL EDA -- Electronics design software (utilities) geda-gsymcheck - GPL EDA -- Electronics design software (symbol checker) geda-gnetlist - GPL EDA -- Electronics design software (netlister) geda-gattrib - GPL EDA -- Electronics design software (attribute editor) geda-gschem - GPL EDA -- Electronics design software (schematic editor) geda-symbols - GPL EDA -- Electronics design software (symbols library) libgeda-common - GPL EDA -- Electronics design software (data files) libgeda-dev - GPL EDA -- Electronics design software (development files) libgeda47 - GPL EDA -- Electronics design software (library files) geda - GPL EDA -- Electronics design software (metapackage) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/geda-gaf/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/geda-gaf/geda-gaf_1.10.2-2.dsc Changes since the last upload: geda-gaf (1:1.10.2-2) unstable; urgency=medium . * Add lintian override for desktop-entry-lacks-main-category according to the policy of pkg-electronics https://wiki.debian.org/Teams/pkg-electronics . -- Kai-Martin Knaak Sun, 07 Feb 2021 05:00:20 +0100 . . geda-gaf (1:1.10.2-1) unstable; urgency=medium . [ Ahmed El-Mahmoudy ] * Imported Upstream version 1.10.0 * Remove texinfo from build-deps, no more needed according to automake fix in #906426. * Add py3.diff patch to migrate to Python 3 * geda-utils: Depend on python3 instead of python (Closes: #936593) * Removed bashisms.diff and no-refdes-warning-fix.patch patches, applied upstream. * Refresh patches * Update standards version to 4.4.1 * Update copyright years . [ Roland Lutz ] * New upstream release. + Upstream now depends on guile-2.2. Closes: #885195. * Rename libgeda46 to libgeda47 and update symbols file. + Prevent internal C++ symbols from being exported. * debian/control: + Rename binary package `geda-gaf' to `geda-cli' in order to avoid confusion with source package. + Add dependency on geda-cli to metapackage. + Bump dependencies to: geda-symbols (>= 1:1.7.1), geda-symbols (<< 1:1.11.0~) + Change Python dependencies to versioned packages. + Add Python dependencies to libgeda47 and geda-gnetlist. + Remove dependency on libstroke. * debian/rules: Add missing dh_clean invocation to override_dh_clean. * Patch scripts to use versioned interpreter lines. * Remove patches which have been applied upstream. * Update upstream contact information. . [ Kai-Martin Knaak ] * Add xorn man page * Add Keywords entry to geda-gattrib.desktop and geda-gschem.desktop Regards, ---<)kaimartinknaak(>--- -- Kai-Martin Knaak Email: kmk-deb...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpgy5bNaap3b.pgp Description: OpenPGP digital signature
Bug#859342: Florence: segfault when clicking on size changing keys
Unfortunately, florence still crashes if I hit the zoom keys with current Debian/bullseye just before freeze. There is a message on stdout: -- $ dbus[105330]: arguments to dbus_connection_unref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../../dbus/dbus-connection.c line 2823. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace -- Hope, this helps to fix the bug, ---<)kaimartin(>--- pgp4wwCVBqz3c.pgp Description: OpenPGP digital signature
Bug#975039: Evolution 3.38.1-2 fails to render emails: WebKitWebProcess crashed. Sandbox
I noticed my last reply did not go to BTS... Today I re-checked by upgrading evolution again. ii evolution 3.38.2-1 amd64 ii evolution-common 3.38.2-1 all ii evolution-data-server 3.38.2-2 amd64 ii evolution-data-server-common 3.38.2-2 all ii evolution-plugins 3.38.2-1 amd64 I also noticed that bwrap is no longer SUID root (and newer modification time). Re-installing bubblewrap did not change it. # ls -la /usr/bin/bwrap -rwxr-xr-x 1 root root 59680 Jan 3 15:13 /usr/bin/bwrap The observation of the issues has changed slightly with the new evolution version: Now no window appears at all when selecting "New message" (in fact, nothing appears to happen). I tried again with bwrap SUID root (and a reboot for good measure) to no change in behavior. Back to 3.36.4-2. Kai On Sun, 2020-12-06 at 15:05 +0100, Kai Juse wrote: > On Sat, 2020-12-05 at 20:00 +, Simon McVittie wrote: > > On standard Debian kernels, /usr/bin/bwrap needs to be setuid root. > > Is it? > > Yes: > $ ls -la /usr/bin/bwrap > -rwsr-xr-x 1 root root 59680 Mar 30 2020 /usr/bin/bwrap > > However, I saw the message (only) during strace(1)ing evolution, so > it > (speculating...) might have to do with some special handling of > setuid > root while tracing? > > Kai
Bug#979193: installation-reports: Bullseye Alpha 3 cannot configure HTTP mirror with preseed
Package: installation-reports Severity: normal Tags: d-i X-Debbugs-Cc: ck...@debian.org >From installation syslog: Jan 4 04:13:46 apt-setup: warning: /usr/lib/apt-setup/generators/50mirror returned error code 1; discarding output Jan 4 04:13:47 main-menu[354]: (process:25092): /usr/lib/apt-setup/generators/50mirror: line 32: is_ports_architecture: not found 50mirror references is_ports_architecture function, which was removed from library.sh in a later revert [1]. As a result the installer is unable to set up a package mirror from preseed. [1] https://salsa.debian.org/installer-team/base-installer/-/commit/3885175086542d3d3404bdb85700c7879b3c1e34 -- Package-specific info: Boot method: CD Image version: https://cdimage.debian.org/cdimage/bullseye_di_alpha3/amd64/iso-dvd/debian-bullseye-DI-alpha3-amd64-DVD-1.iso Date: Sun 03 Jan 2021 08:13:00 PM PST Machine: VMWare ESXi 7.0 Guest Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: >From installation syslog: Jan 4 04:13:46 apt-setup: warning: /usr/lib/apt-setup/generators/50mirror returned error code 1; discarding output Jan 4 04:13:47 main-menu[354]: (process:25092): /usr/lib/apt-setup/generators/50mirror: line 32: is_ports_architecture: not found 50mirror references is_ports_architecture function, which was removed from library.sh in a later revert [1]. As a result the installer is unable to set up a package mirror from preseed. [1] https://salsa.debian.org/installer-team/base-installer/-/commit/3885175086542d3d3404bdb85700c7879b3c1e34 -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20201202" X_INSTALLATION_MEDIUM=cdrom -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/1 CPU thread) 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)
Bug#963058: [Android-tools-devel] Bug#963058: still ftbfs on arm64
It looks like upstream does not support anything but x86, and they've added assembly code. So unless someone steps up to port that to ARM, the ARM binaries will be removed. Curiously, the master branch of AOSP SDK now seems to support ARM64: https://ci.android.com/builds/submitted/7058119/sdk_arm64-sdk/latest OpenPGP_signature Description: OpenPGP digital signature
Bug#965098: geda-gaf orphaned
On Fri, 27 Nov 2020 10:56:18 -0700 (MST) Bdale Garbee wrote: > In light of Kai-Martin Knaak's comments here, I won't push harder for > geda-gaf to be removed from Debian. > > However, since I have no intention of doing more work on it myself, I > just filed bug #975985 marking geda-gaf as orphaned. > > Bdale I just added my intention to adopt the package to this bug. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpYW_KqP_yKB.pgp Description: OpenPGP digital signature
Bug#975985: intend to adopt
Hi Bdale. I use geda-gaf several times a week. Because of recent progress in geda-gaf I do not feel inclined to switch to lepton-eda. So I hereby express my intend to adopt the package and act as a maintainer. However, this is the first time I touch Debian maintenance. I would happily accept pointers where to start. Am reading the "Debian New Maintainers' Guide" right now. Is there any other place to look at? Viele Grüße, ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpHfefEBlAXc.pgp Description: OpenPGP digital signature
Bug#965098: migrated to guile 2.2
On Tue, 27 Oct 2020 09:39:16 -0700 Sean Whitton wrote: > Hello, > > On Mon 26 Oct 2020 at 04:58AM +01, Kai-Martin Knaak wrote: > > > Just a heads-up: > > Upstream pushed a few patches to the git repository to make the > > package compatible with guile 2.2. > > > > This removes the road block that triggered this removal request. Is > > there anything else that prevents geda-gaf from staying in the Debian > > repos? > > Well, someone needs to update the version of the package in Debian. > Can you? I am rather interested in having the non forked version of geda available in Debian. I use geda on a daily base at work. While I habitually build the application from source, my workmates certainly do not. I see that Bdale officially orphaned the package(s). So I may step up to carry the flag and maintain the geda package in Debian. What would be the first steps to do so? (I am a long time user of Debian but never had a reason to enter this arena?) ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpYaZXqr6fKZ.pgp Description: OpenPGP digital signature
Bug#975039: Downgrade to 3.36.4-2 fixes the issue
Hi, I can confirm that downgrading to evolution 3.36.4-2 and related packages (from snapshot 20201117T032431Z) avoids the problem and restores normal/previous behavior.
Bug#975039: Evolution 3.38.1-2 fails to render emails: WebKitWebProcess crashed. Sandbox
Hi, I have the same issue with evolution update (3.38.1-2) over (3.36.4-2) on 2020-12-05. When opening any email message in a seperate window the window opens with title menu but without mail header and body content. Instead: "A WebKitWebProcess crashed when displaying the message. You can try again by moving to another message and back. If the issue persists, please file a bug report in GNOME Gitlab.". As mentioned in earlier message, "new email" and "forward" also don't work due to no window opening at all in that case. The issue appears to be related to sandboxing; it diappears disappears with running evolution this way: $ WEBKIT_FORCE_SANDBOX=0 evolution I am running evolution though an X11 ssh forward and see messages like these in the terminal every time I open an email: Unable to init server: Could not connect: Connection refused (WebKitWebProcess:3): Gtk-WARNING **: 13:43:24.795: cannot open display: :10.0 However, the message also appears at evolution startup and drawing the main window without causing apparent problems. I have seen the error message before also the upgrade and the problem, but am unsure of the exact times they were shown. Using strace, I find the WebKitWebProcess child process indeed unable to connect to localhost:6010 (as well as expected domain sockets) (Also: bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. ) Best Regards, Kai
Bug#875847: Patch to fix ".qhc files not reproducible"
Am 25.11.20 um 19:05 schrieb Dmitry Shachnev: On Wed, Nov 25, 2020 at 06:15:53AM +0100, Kai Pastor, DG0YT wrote: I also left a link to this Debian bug in Qt's code review for the offending change. Can you please share a link to the mentioned code review? https://bugreports.qt.io/browse/QTBUG-62697 has only some old reviews from 2018 linked. https://codereview.qt-project.org/c/qt/qttools/+/203587 (Found again via seaching "status:merged commentby:dg...@darc.de") Ah, sorry, I misunderstood you and thought that you submitted a new code review with your patch. But you commented on change that introduced that code. Is there any reason why you didn't submit your patch to gerrit? Will you mind if I do it? -- Dmitry Shachnev Feel free to submit it. I didn't submit it to gerrit because contributing in that way became too much work for me when they required contributions to go to dev, not LTS. (And I didn't realize that there is a *new* Qt Help issue until Oct 2020, with dev meaning Qt 6 IIRC.) Kai
Bug#875847: Patch to fix ".qhc files not reproducible"
Am 24.11.20 um 19:24 schrieb Dmitry Shachnev:
Hi Kai!
On Thu, Oct 15, 2020 at 07:48:49AM +0200, Kai Pastor, DG0YT wrote:
This patch fixes the creation of the offending timestamp, by clamping to
SOURCE_DATE_EPOCH as specified.
Thank you for the patch and sorry for delayed response!
I also left a link to this Debian bug in Qt's code review for the offending
change.
Can you please share a link to the mentioned code review?
https://bugreports.qt.io/browse/QTBUG-62697 has only some old reviews from
2018 linked.
https://codereview.qt-project.org/c/qt/qttools/+/203587
(Found again via seaching "status:merged commentby:dg...@darc.de")
Clamp registered collection time-stamp to SOURCE_DATE_EPOCH if set.
--- a/src/assistant/help/qhelpcollectionhandler.cpp
+++ b/src/assistant/help/qhelpcollectionhandler.cpp
@@ -2197,7 +2197,14 @@
m_query->addBindValue(fileName);
const QFileInfo fi(absoluteDocPath(fileName));
m_query->addBindValue(fi.size());
-m_query->addBindValue(fi.lastModified().toString(Qt::ISODate));
+QDateTime last_modified = fi.lastModified();
+if (qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))
+{
+qint64 source_date_epoch =
qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH");
+if (source_date_epoch < last_modified.toSecsSinceEpoch())
+
last_modified.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));
I think we can use setSecsSinceEpoch(source_date_epoch) here?
I think this was my intention.
Kai.
Bug#972294: openorienteering-mapper: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath
Am 10.11.20 um 11:35 schrieb Simon McVittie:
On Fri, 16 Oct 2020 at 08:29:48 +0200, Kai Pastor, DG0YT wrote:
So far, all cases in openorienteering-mapper were tests which were expected
to be run in the build environment and indeed access the pristine test data
in the source directory.
The current issue comes from using Qt's QFINDTESTDATA(), which relies on a
cpp macro (QT_TESTCASE_BUILDDIR) pointing "to the working directory from
which the compiler is invoked" in order to "the absolute path of the source
directory" [!], https://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA .
QT_TESTCASE_BUILDDIR is defined by Qt's cmake file.
One way this is often done, particularly in the GNOME ecosystem, is to
check for an environment variable that is set by the build system while
running tests. There are often two environment variables - one for the
source directory and one for the build directory - so that tests can
either ask for data files that are distributed with the source code, or
data files that were compiled along with the test itself and placed in
the build directory, if those directories are different.
If the environment variable is not set, there's a fallback that would
be reasonable to use if the test has been installed system-wide,
typically into /usr/libexec/installed-tests (which is something
that various GNOME and GNOME-adjacent packages support doing, for
"as-installed" testing like Debian's autopkgtest: see
<https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests>).
In GLib the fallback is to use dirname(argv[0]), but hard-coding an
installation path would also be reasonable here.
This avoids having to hard-code the path to either the source or build
directory into any binaries, even if test executables and data are going
to be installed into /usr/libexec/installed-tests for "as-installed"
testing.
Some packages need to set environment variables for build-time testing
*anyway*, so that third-party components will find their required data
in the source or build tree: for example, you might need to set PATH,
LD_LIBRARY_PATH, XDG_DATA_DIRS and similar variables. The variables used
by this particular package's tests can be set in the same way.
The implementation that is normally used in GNOME is GLib's
g_test_build_filename(), which works something like this pseudocode:
if file_type == G_TEST_DIST:
dir = getenv("G_TEST_SRCDIR")
elif file_type == G_TEST_BUILT:
# this branch is the closest equivalent of QFINDTESTDATA
dir = getenv("G_TEST_BUILDDIR")
else:
fatal error
if dir is null:
dir = directory containing the running executable
return join_paths(dir, first_path, ...)
An implementation of the build-system side of this in a simple
Makefile-based build system would look something like:
export G_TEST_BUILDDIR = $(CURDIR)
export G_TEST_SRCDIR = $(srcdir)
check:
./test-foo
./test-bar
Obviously the code would look a bit different for Autotools, CMake or
Meson, but all are capable of doing this (Autotools uses
AM_TESTS_ENVIRONMENT, CMake uses
set_tests_properties(... PROPERTIES ENVIRONMENT ...), Meson uses
test(..., env : ...)).
I assume qmake would also be able to do this, but I don't know how.
smcv
I did consider these options, but I am not convinced. One perspective I
am looking at is onboarding of new contributors (upstream).
Reproducibility helps with that, no doubt. But with your favourite IDE
as a development tool, or at the command line, why to make it hard to
just run a particular test executable? Why add complexity to each and
every package's source code or build system?
... or how to fix QFINDTESTDATA? This macro is the canonical way with
Qt. It should be made compatible with reproducible builds. The solution
might include environment variables, but implemented by Qt Test, not
implemented in each and every package.
And then one more step, and standardize the variables' names (like
SOURCE_DATE_EPOCH).
Bug#972294: openorienteering-mapper: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath
Am 10.11.20 um 01:00 schrieb Vagrant Cascadian: On 2020-10-16, Kai Pastor, DG0YT wrote: Am 16.10.20 um 01:19 schrieb Vagrant Cascadian: When the reproducible=+fixfilepath feature is enabled (either through DEB_BUILD_OPTIONS, or using a dpkg that enables this by default), openorienteering-mapper fails to build from source: http://qa-logs.debian.net/2020/09/26.fixfilepath/openorienteering-mapper_0.9.3-1_unstable_fixfilepath.log While the "fixfilepath" feature is not currently enabled by dpkg-buildflags by default, it may become the default at some point in the future, and can by triggered manually by setting DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. More information about this issue is available at: https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html I have not identified the exact cause of this issue for openorienteering-mapper, but a common triggering issue is test suites expectinfg __FILE__ to resolve to an absolute path. The attached patch works around this issue by disabling the fixfilepath feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath. ... sorry for the delay... So far, all cases in openorienteering-mapper were tests which were expected to be run in the build environment and indeed access the pristine test data in the source directory. The current issue comes from using Qt's QFINDTESTDATA(), which relies on a cpp macro (QT_TESTCASE_BUILDDIR) pointing "to the working directory from which the compiler is invoked" in order to "the absolute path of the source directory" [!], https://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA . QT_TESTCASE_BUILDDIR is defined by Qt's cmake file. I do see some inconsistency there, but this is a different story. Yes, this is part of the known issues with test data mentioned; the majority of known build failures triggered by fixfilepath are these use-cases with QFINDTESTDATA. In previous cases I "solved" the failing reproducible builds by: using another macro, carrying the source directory. But I'm not sure if this is what is intented. While I do have ideas how to workaround this in other ways, I would appreciate a clear recommendation how test data in the source dir should be handled. If the package in question only uses such features in test suites that are not shipped in the binary packages, it's perfectly reasonable to disable the fixfilepath feature; it will likely have no effect on the resulting packages either way. If the package embeds file paths in files shipped in the binary packages, then it might be worth some of the workarounds you suggested with the test suites, and further debugging what exactly is embedding the build paths; enabling fixfilepath only catches some of the issues of embedded build paths, so it may be a moot point for any particular package. Disabling fixfilepath in your package will allow tests.reproducible-builds.org to be able to test builds of the openorienteering-mapper package in unstable and experimental again, where the build path is varied, and possibly help identify weather further exploration is needed. At this point, I'd suggest disabling fixfilepath for this particular package. But I submitted the patch to do that, so maybe I am biased? :) Trying to express my concerns in terms of reproducible-builds.org terminology definitions: As the author of the software, I define the "expected reproducible artifacts" to be the files created by "make install". With disabling fixfilepath, is there another test which not only verifies "bit-by-bit identical copies of all specified artifacts", but would also offer the diagnosis that the build path ended up in the installed artifacts? Last not least, "make install" is the canonical way of creating the set of artifacts meant for distribution. Hope that is a clear enough recommendation? Oh, and, sorry for not getting back to you till now! Not sure how I lost track of this... live well, vagrant Thanks! Kai
Bug#965098: migrated to guile 2.2
Just a heads-up: Upstream pushed a few patches to the git repository to make the package compatible with guile 2.2. This removes the road block that triggered this removal request. Is there anything else that prevents geda-gaf from staying in the Debian repos? ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpkbooHNwbcN.pgp Description: OpenPGP digital signature
Bug#965098: Removal of geda-gaf
Dear maintainer,
The removal request suggests to use lepton-eda as a drop-in replacement
for geda-gaf. I tested lepton-eda with one of my geda projects
("Lasertreiber"). This is a medium scale analogue circuit with a
hierarchy of three subcircuits. I noted a few issues:
* Apparently, lepton was forked before docks were introduced to the GUI
of gschem. Consequently, lepton-schematics still uses pop-up dialogues
for frequent tasks like the choice of symbols or setting values of
attributes.
While geda-gaf 1.10 maintains the ability to work with pop-ups, it also
supports docks that attach to the sides of the main window. IMHO, this
makes the UI much more usable - no more need to constantly move mini
windows around. The docks match the general UI paradigm of other design
applications like freecad or inkscape, too.
* Text in lepton-schematic is put almost but not quite at the same
place as in gschem. It seems to be shifted up or down a little bit,
depending on where the attachment point of the text is set. The amount
of shift depends on the font size. It seems to be about an eighth of
the font height. I like to carefully place labels close but not too
close to symbols. This is noticeably affected by the shift. The result
is still readable. The text is just positioned a little off.
* Text in lepton-schematic is rendered larger than in gschem. Size
increase is about 15 %.
* lepton-schematic uses a different font family in print than on screen.
The PDF shows text in a serif font while text on screen is shown in
sans serif. This may be configurable. I just report on the defaults.
* Version 1.10 of gschem saw a major usability improvement when dealing
with hierarchies: In gschem a double-click on a subsheet symbol
now opens the corresponding subsheet. To return, there is a nice
big button in the row of actions. With lepton-schematics I still have
to select the subsheet symbol and open a menu to go "down-schematic".
* Issue reporting of potential problems on export of the netlist got
noticeably better in geda. On import to the layout application pcb I
now get warnings in a dialogue rather than on stdout. The messages
themselves are much more legible, too. These changes came when the
backends of geda got ported from scheme to python and were essentially
rewritten in the process. Since lepton was forked to explicitly not
move to python, the above improvements are missing in lepton.
As you may have guessed from the comments, I like to work with the most
up to date version of geda. I habitually pull the latest development
version from the git repo and compile myself. So removal of geda from
debian does not immediately affect my work flow. However, I also teach
electronics. Removal of geda-gaf would put me in an awkward place. It
would make it harder for the students to install the same set-up at
home.
What would it take to keep the original geda in Debian (preferably in
the latest released version, that is 1.10)?
Best regards,
---<)kaimartin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882
pgpfekiCHmyTP.pgp
Description: OpenPGP digital signature
Bug#972294: openorienteering-mapper: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath
Am 16.10.20 um 01:19 schrieb Vagrant Cascadian: Package: openorienteering-mapper Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: fixfilepath ftbfs X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org When the reproducible=+fixfilepath feature is enabled (either through DEB_BUILD_OPTIONS, or using a dpkg that enables this by default), openorienteering-mapper fails to build from source: http://qa-logs.debian.net/2020/09/26.fixfilepath/openorienteering-mapper_0.9.3-1_unstable_fixfilepath.log While the "fixfilepath" feature is not currently enabled by dpkg-buildflags by default, it may become the default at some point in the future, and can by triggered manually by setting DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. More information about this issue is available at: https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html I have not identified the exact cause of this issue for openorienteering-mapper, but a common triggering issue is test suites expectinfg __FILE__ to resolve to an absolute path. The attached patch works around this issue by disabling the fixfilepath feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath. Thanks for maintaining openorienteering-mapper! live well, vagrant So far, all cases in openorienteering-mapper were tests which were expected to be run in the build environment and indeed access the pristine test data in the source directory. The current issue comes from using Qt's QFINDTESTDATA(), which relies on a cpp macro (QT_TESTCASE_BUILDDIR) pointing "to the working directory from which the compiler is invoked" in order to "the absolute path of the source directory" [!], https://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA . QT_TESTCASE_BUILDDIR is defined by Qt's cmake file. I do see some inconsistency there, but this is a different story. In previous cases I "solved" the failing reproducible builds by: using another macro, carrying the source directory. But I'm not sure if this is what is intented. While I do have ideas how to workaround this in other ways, I would appreciate a clear recommendation how test data in the source dir should be handled. Thanks, Kai
Bug#875847: Patch to fix ".qhc files not reproducible"
This patch fixes the creation of the offending timestamp, by clamping to
SOURCE_DATE_EPOCH as specified.
I also left a link to this Debian bug in Qt's code review for the
offending change.
Best regards,
Kai
Clamp registered collection time-stamp to SOURCE_DATE_EPOCH if set.
--- a/src/assistant/help/qhelpcollectionhandler.cpp
+++ b/src/assistant/help/qhelpcollectionhandler.cpp
@@ -2197,7 +2197,14 @@
m_query->addBindValue(fileName);
const QFileInfo fi(absoluteDocPath(fileName));
m_query->addBindValue(fi.size());
-m_query->addBindValue(fi.lastModified().toString(Qt::ISODate));
+QDateTime last_modified = fi.lastModified();
+if (qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))
+{
+qint64 source_date_epoch = qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH");
+if (source_date_epoch < last_modified.toSecsSinceEpoch())
+last_modified.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));
+}
+m_query->addBindValue(last_modified.toString(Qt::ISODate));
if (!m_query->exec())
return false;
Bug#972178: openorienteering-mapper: FTBFS with Qt 5.15: error: aggregate 'QPainterPath outside_path' has incomplete type and cannot be defined
Am 13.10.20 um 20:05 schrieb Dmitry Shachnev: Source: openorienteering-mapper Version: 0.9.3-1 Severity: important Tags: ftbfs User: debian-qt-...@lists.debian.org Usertags: qt5.15 Dear Maintainer, openorienteering-mapper fails to build with Qt 5.15, currently available in experimental: /build/openorienteering-mapper-0.9.3/src/gui/print_tool.cpp: In member function 'virtual void OpenOrienteering::PrintTool::draw(QPainter*, OpenOrienteering::MapWidget*)': /build/openorienteering-mapper-0.9.3/src/gui/print_tool.cpp:144:15: error: aggregate 'QPainterPath outside_path' has incomplete type and cannot be defined 144 | QPainterPath outside_path; | ^~~~ The full build log is attached. -- Dmitry Shachnev Fixed in 0.9.4, already released. Cf. https://build.opensuse.org/package/show/home:dg0yt/openorienteering-mapper Regards, Kai
Bug#970686: thermald: Comet Lake CPUID family:model:stepping 0x6:a5:2 (6:165:2) is not included
Package: thermald Version: 1.9.1-1ubuntu0.3 Severity: normal Dear Maintainer, * The thermald failed to start, the journalctl log shows the CPU is not supported Sep 15 17:07:00 ubuntu thermald[1089]: [WARN]Unsupported cpu model, use thermal-conf.xml file or run with --ignore-cpuid-check Sep 15 17:07:00 ubuntu thermald[1089]: [ERR]THD engine start failed Sep 15 17:07:00 ubuntu systemd[1]: thermald.service: Succeeded. * Create a upstream bug, and upsteam maintainer recognized https://github.com/intel/thermal_daemon/issues/275 * Upstream maintainer create commit for adding lost CPUID https://github.com/intel/thermal_daemon/commit/7f2003ee911dd1c97ff74d2b84c62e10950bc9e0 * Need to backport from upstream to support Comet Lake and Rocket Lake in the future -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1027-oem (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thermald depends on: ii libc6 2.31-0ubuntu9 ii libdbus-1-3 1.12.16-2ubuntu2.1 ii libdbus-glib-1-2 0.110-5fakssync1 ii libgcc-s1 10-20200411-0ubuntu1 ii libglib2.0-0 2.64.3-1~ubuntu20.04.1 ii libstdc++610-20200411-0ubuntu1 ii libxml2 2.9.10+dfsg-5 ii lsb-base 11.1.0ubuntu2 thermald recommends no packages. thermald suggests no packages. -- no debconf information
Bug#970446: Segmentation fault is gone, close #970446
I can no longer reproduce this behaviour. Totem and other gstreamer based applications work. I have no glue what caused the issue and why it's gone now. Sorry for the noise. Kai
Bug#970446: gstreamer1.0-plugins-base:amd64: Caught a segmentation fault libgsttypefindfunctions.so
Package: gstreamer1.0-plugins-base Version: 1.18.0-2 Severity: important When running totem on any Video (mp4, avi, mov) file I get a "Segmentation fault". This affects two systems running Sid. I would like to help debug this issue. $ totem Videos/The\ secret\ behind\ many\ great\ engineering\ organizations.mp4 (totem:113386): GLib-CRITICAL **: 15:18:47.362: g_propagate_error: assertion 'src != NULL' failed (totem:113386): GLib-GIO-CRITICAL **: 15:18:47.362: g_task_return_error: assertion 'error != NULL' failed (totem:113386): GLib-GIO-CRITICAL **: 15:18:47.374: g_task_propagate_boolean: assertion 'task->result_set' failed ERROR: Caught a segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgsttypefindfunctions.so Please either: - remove it and restart. - run with --gst-disable-segtrap --gst-disable-registry-fork and debug. Segmentation fault -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads) 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 gstreamer1.0-plugins-base:amd64 depends on: ii libc6 2.31-3 ii libcdparanoia0 3.10.2+debian-13+b1 ii libglib2.0-02.66.0-2 ii libgstreamer-plugins-base1.0-0 1.18.0-2 ii libgstreamer1.0-0 1.18.0-3 ii libogg0 1.3.2-1+b1 ii libopus01.3-1+b1 ii liborc-0.4-01:0.4.32-1 ii libtheora0 1.1.1+dfsg.1-15 ii libvisual-0.4-0 0.4.0-17 ii libvorbis0a 1.3.6-2 ii libvorbisenc2 1.3.6-2 gstreamer1.0-plugins-base:amd64 recommends no packages. Versions of packages gstreamer1.0-plugins-base:amd64 suggests: ii gvfs 1.44.1-1+b1 -- no debconf information
Bug#967906: systemd 246 resolvconf path unit
Yes, I had resolvconf around for some reason while using systemd-resolved. Thanks for forwarding to upstream.
Bug#967906: systemd 246 resolvconf path unit
Hi, in my case this was caused by the resolvconf-pull-resolved.path unit which continuously triggered the resolvconf-pull-resolved.service unit. I checked if the trigger was valid but there were no write events which should cause the trigger: inotifywait -m -e modify /run/systemd/resolve/stub-resolv.conf Setting up watches. Watches established. # no further output Starting the service unit actually works but because it starts so often, it hits the restart burst limit and is reported as failed (but still will be started immediately again). A workaround was to remove the resolvconf package which was not really needed in my case anyway, I guess. Would be good to see if the PathChanges is broken in general and then report this upstream. Regards, Kai
Bug#966274: O: ident2 -- An advanced ident daemon
Package: wnpp Severity: normal I intend to orphan the ident2 package. The package no longer builds on gcc-10, and I realized that I cannot adequately maintain this package without an active upstream. Besides, there seems to be no shortage of ident servers in Debian. If you care deeply about ident2 specifically, please adopt this package. The package description is: ident2 is an advanced, configurable ident daemon. You can set it to lie, not lie, or not return any response at all, and it is per-user configurable (e.g. if user daniel was IRCing, it'd use ~daniel/.ident for its config, if user kim was IRCing, it'd use ~kim/.ident). The admin can specify whether users can configure the type of return they want or not.
Bug#966273: RFA: fam -- File Alteration Monitor
Package: wnpp Severity: normal I request an adopter for the fam package. I can no longer invest sufficient time to maintain this package. Upstream had disappeared a long time ago, and gamin is a better maintained alternative. The package description is: FAM monitors files and directories, notifying interested applications of changes. . This package provides a server that can monitor a given list of files and notify applications through a socket. If the kernel supports dnotify (kernels >= 2.4.x) FAM is notified directly by the kernel. Otherwise it has to poll the files' status. FAM can also provide an RPC service for monitoring remote files (such as on a mounted NFS filesystem).
Bug#960897: Update android-platform-external-libunwind and build for ppc64el
> According to the source trees at both > https://github.com/Unity-Technologies/android-libunwind and > https://android.googlesource.com/platform/external/libunwind/, ppc64[le] > systems are supported. I doubt it. Android never officially supported architectures other than x86, ARM or MIPS. And these days MIPS support is being removed. The source tree for PowerPC is probably from the original `libunwind` and never touched by Google. Even if it builds successfully in PowerPC, I'm quite sure it was never tested. signature.asc Description: OpenPGP digital signature
Bug#960608: Bison 3.6.1 generates (internal) tokentype and (yyerror) function with same name: _error
Hi Akim,
I am forwarding a bug report that the libexplain and the fhist Debian
packages fail to build with Bison 3.6.1.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960608
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libexplain.html
I have also attached the build log with this email. Can you look into
this issue and see if it is a bug in Bison? Thanks!
Here is the explanation from Andreas Beckmann, who reported the bug:
At least two packages FTBFS with the latest bison with some yyerror related
error message. I had a short look into the libexplain failure and found the
following:
In libexplain/acl_grammar.yacc.c (generated from libexplain/acl_grammar.y),
these bits are new in 3.6.1 (they were not generated by 3.5.3):
...
enum acl_grammar_tokentype
{
acl_grammar_EMPTY = -2,
acl_grammar_EOF = 0, /* "end of file" */
acl_grammar_error = 256, /* error */
acl_grammar_UNDEF = 257, /* "invalid token" */
...
};
...
#define acl_grammar_EOF 0
#define acl_grammar_error 256
#define acl_grammar_UNDEF 257
...
and acl_grammar_error clashes with the existing (generated by 3.6.1 and
3.5.3, in acl_grammar.y this is yyerror())
...
static void
acl_grammar_error(const char *text)
{
...
}
which causes this error during compilation:
y.tab.c:152:27: error: expected identifier or '(' before numeric constant
libexplain/acl_grammar.y:128:1: note: in expansion of macro 'acl_grammar_error'
128 | yyerror(const char *text)
| ^
libexplain/acl_grammar.y: In function 'acl_grammar_errorf':
y.tab.c:152:27: error: called object is not a function or function pointer
libexplain/acl_grammar.y:155:5: note: in expansion of macro 'acl_grammar_error'
155 | yyerror(buf);
| ^
libexplain/acl_grammar.y: In function 'acl_grammar_parse':
y.tab.c:152:27: error: called object is not a function or function pointer
libexplain/acl_grammar.y:470:13: note: in expansion of macro 'acl_grammar_error'
470 | yyerror
| ^~~
y.tab.c:152:27: error: called object is not a function or function pointer
y.tab.c:1720:7: note: in expansion of macro 'acl_grammar_error'
y.tab.c:152:27: error: called object is not a function or function pointer
y.tab.c:1831:3: note: in expansion of macro 'acl_grammar_error'
At top level:
libexplain/acl_grammar.y:105:1: warning: 'result_append' defined but
not used [-Wunused-function]
105 | result_append(const char *text)
| ^
This does not look like it is an error in libexplain.
Mon May 11 13:28:49 UTC 2020 I: starting to build libexplain/unstable/amd64 on
jenkins on '2020-05-11 13:28'
Mon May 11 13:28:49 UTC 2020 I: The jenkins build log is/was available at
https://jenkins.debian.net/userContent/reproducible/debian/build_service/amd64_14/12752/console.log
Mon May 11 13:28:49 UTC 2020 I: Downloading source for
unstable/libexplain=1.4.D001-9
--2020-05-11 13:28:50--
http://deb.debian.org/debian/pool/main/libe/libexplain/libexplain_1.4.D001-9.dsc
Connecting to 78.137.99.97:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2184 (2.1K)
Saving to: ‘libexplain_1.4.D001-9.dsc’
0K ..100% 190M=0s
2020-05-11 13:28:50 (190 MB/s) - ‘libexplain_1.4.D001-9.dsc’ saved [2184/2184]
Mon May 11 13:28:50 UTC 2020 I: libexplain_1.4.D001-9.dsc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 3.0 (quilt)
Source: libexplain
Binary: explain, libexplain-doc, libexplain51, libexplain-dev
Architecture: any all
Version: 1.4.D001-9
Maintainer: Debian QA Group
Homepage: http://libexplain.sourceforge.net/
Standards-Version: 4.4.0
Vcs-Browser: https://salsa.debian.org/debian/libexplain
Vcs-Git: https://salsa.debian.org/debian/libexplain.git
Build-Depends: bison, debhelper-compat (= 12), ghostscript, groff, libacl1-dev,
libcap-dev [linux-any], libtool-bin, linux-libc-dev [linux-any], lsof
[linux-any], netbase
Package-List:
explain deb devel optional arch=any
libexplain-dev deb libdevel optional arch=any
libexplain-doc deb doc optional arch=all
libexplain51 deb libs optional arch=any
Checksums-Sha1:
e191e1e7f066f8cefca8d05c846c3a38931d8410 4770006
libexplain_1.4.D001.orig.tar.gz
051e4be36c618b454657db790a7a7920704ee513 43992
libexplain_1.4.D001-9.debian.tar.xz
Checksums-Sha256:
28863b65eccc74934e237cac41364cb3c1802c36c9e2318ed0417460fee83f80 4770006
libexplain_1.4.D001.orig.tar.gz
4ac59e45f82811b8fd0cf519149d224467f25ea212f161a5ac004241f502d543 43992
libexplain_1.4.D001-9.debian.tar.xz
Files:
8fabd3de196bde3ca941cd27c029ff8b 4770006 libexplain_1.4.D001.orig.tar.gz
078b819d14486f28ebab03884dc6b658 43992 libexplain_1.4.D001-9.debian.tar.xz
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAl1yplIACgkQwpPntGGC
Ws6jGg//ZreHxsvjOCNmKJ3RTjNwNEop3ml1HcRdd0YBVLB28zwOLTB6nAaxip6t
Bug#948307: works with openafs 1.8.5-1 and kernel 5.4.0-4-amd64
Dear Ben, I can confirm that dkms module openafs 1.8.5-1 from unstable compiles fine with kernel 5.4.0-4-amd64 . Thank you for the heads up. All the best, ---<)kaimartin(>--- -- Kai-Martin Knaak kn...@iqo.uni-hannover.de Universität Hannover, Inst. f. Quantenoptik tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover fax: +49-511-762-2211 https://keyserver.ubuntu.com/pks/lookup?op=get=0xC13AA4CC7B0F9882 pgphXZR9yAmq5.pgp Description: OpenPGP digital signature
Bug#948307: Also fails for kernel 5.4.0-2-amd64
I tried to build the module for kernel 5.4.0-2-amd64 but got the same failure like with kernel 5.3.15 Best regards, ---<)kaimartin(>--- -- Kai-Martin Knaak kn...@iqo.uni-hannover.de Universität Hannover, Inst. f. Quantenoptik tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover fax: +49-511-762-2211 https://keyserver.ubuntu.com/pks/lookup?op=get=0xC13AA4CC7B0F9882 pgpmLFoQ4NZpP.pgp Description: OpenPGP digital signature
Bug#948307: openafs-modules-dkms: Compile of the module fails for kernel 5.3.15
Package: openafs-modules-dkms Version: 1.8.4~pre1-1 Severity: important Tags: newcomer Dear Maintainer, the openafs module fails to build for kernel 5.3.15 on my system. * What led up to the situation? apt upgrade * What was the outcome of this action? The openafs module failed to build for kernel 5.3.15. See the log in the attachment. The module did build for kernel 5.2.17 , though. * What outcome did you expect instead? The openafs module builds and installs for kernel 5.3.15 The relevant portion of the log seems to be: (...) CC [M] /var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.o In file included from /var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.c:24: /var/lib/dkms/openafs/1.8.4pre1/build/src/afs/LINUX/osi_compat.h: In function ‘afs_linux_search_keyring’: /var/lib/dkms/openafs/1.8.4pre1/build/src/afs/LINUX/osi_compat.h:225:12: error: too few arguments to function ‘keyring_search’ 225 | key_ref = keyring_search( |^~ In file included from /usr/src/linux-headers-5.3.0-3-common/include/linux/cred.h:13, from /usr/src/linux-headers-5.3.0-3-common/include/linux/seq_file.h:12, from /usr/src/linux-headers-5.3.0-3-common/include/linux/seq_file_net.h:5, from /usr/src/linux-headers-5.3.0-3-common/include/net/net_namespace.h:186, from /usr/src/linux-headers-5.3.0-3-common/include/linux/netdevice.h:38, from /usr/src/linux-headers-5.3.0-3-common/include/net/inet_sock.h:19, from /usr/src/linux-headers-5.3.0-3-common/include/linux/udp.h:16, from /var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/./netinet/udp.h:1, from /var/lib/dkms/openafs/1.8.4pre1/build/src/rx/rx_kcommon.h:110, from /var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.c:20: /usr/src/linux-headers-5.3.0-3-common/include/linux/key.h:387:18: note: declared here 387 | extern key_ref_t keyring_search(key_ref_t keyring, | ^~ make[5]: *** [/usr/src/linux-headers-5.3.0-3-common/scripts/Makefile.build:286: /var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP/rx_kmutex.o] Error 1 make[4]: *** [/usr/src/linux-headers-5.3.0-3-common/Makefile:1639: _module_/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP] Error 2 make[3]: *** [/usr/src/linux-headers-5.3.0-3-common/Makefile:179: sub-make] Error 2 make[3]: Leaving directory '/usr/src/linux-headers-5.3.0-3-amd64' FAILURE: make exit code 2 make[2]: *** [Makefile.afs:280: openafs.ko] Error 1 make[2]: Leaving directory '/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-3-amd64-SP' make[1]: *** [Makefile:187: linux_compdirs] Error 2 make[1]: Leaving directory '/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs' make: *** [Makefile:15: all] Error 2 Hope, this helps fix the problem. Best regards, ---<)kaimartinknaak>--- -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openafs-modules-dkms depends on: ii dkms 2.8.1-4 ii libc6-dev 2.29-7 ii perl 5.30.0-9 Versions of packages openafs-modules-dkms recommends: ii openafs-client 1.8.4~pre1-1 openafs-modules-dkms suggests no packages. -- no debconf information -- Kai-Martin Knaak kn...@iqo.uni-hannover.de Universität Hannover, Inst. f. Quantenoptik tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover fax: +49-511-762-2211 https://keyserver.ubuntu.com/pks/lookup?op=get=0xC13AA4CC7B0F9882 DKMS make.log for openafs-1.8.4pre1 for kernel 5.3.0-3-amd64 (x86_64) Mon 6 Jan 15:55:04 CET 2020 checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header
Bug#885149: Any progress?
Would it be possible that an Exim Maintainer could simply answer the question wether Exim will ever be build with SMTPUTF8 (SUPPORT_I18N, SUPPORT_I18N_2008) or if there are any problems preventing this?
Bug#941903: snapshot.debian.org: 404 error for one snapshot.debian.org IP address but not for the other
Am 21.10.19 um 15:11 schrieb Peter Palfrader: Evan Jones schrieb am Monday, dem 21. October 2019: THANK YOU and whoever else is involved in maintaining this. Just letting you know that I appreciate the work here. I don't work for Google, but I do use Distroless [1], a lightweight Debian-based container runtime that uses snapshot to have reproducible builds, so this was definitely annoying to work around. Thanks! [1] https://github.com/GoogleContainerTools/distroless I'm tempted to think that this tool should not use snapshot but the real mirrors that can handle the load way better. Thank you very much, indeed. Coincidentally, I'm also using the snapshots for non-debian build scripts (for Windows, macOS, Android). I'm not using the debian rules, but the copyright, patches, and DFSG source tarballs. I cannot switch versions at the pace of the debian packages, and I'm unaware of mirrors which provide long-term stable download URLs for older versions (except of uploads to/downloads from my own webspace). The sources are cached in CI, so the load should be very low anyway. OTOH it seems this kind of usage helps to discover such debian snapshots issues quickly. Kai.
Bug#942485: snapshot.debian.org: "404 Not found" for sqlite3_3.30.1-1.debian.tar.xz
This is probably the same issue as #941903.
Bug#942485: snapshot.debian.org: "404 Not found" for sqlite3_3.30.1-1.debian.tar.xz
Package: snapshot.debian.org Severity: normal Dear Maintainer, sqlite3_3.30.1-1.debian.tar.xz is listed on https://snapshot.debian.org/archive/debian/20191013T030844Z/pool/main/s/sqlite3/ (and also for later dates), but the link https://snapshot.debian.org/archive/debian/20191013T030844Z/pool/main/s/sqlite3/sqlite3_3.30.1-1.debian.tar.xz returns 404 Not found, most of the time. It worked a few times, but with no clear pattern. sqlite3_3.30.1-1.dsc seems to suffer, too. Kai
Bug#934707: [dbus,systemd,sssd]: Unresponsive domain and nonexistent user in policy lead to reload fail and fall of dependant daemons.
Package: dbus Version: 1.12.16-1 Severity: normal Dear Maintainer. As subject says, if sssd can't reach dc, dbus get NoReply fail and succesfully restarted aftervards with following consequences: 1. reload process lagging due sssd timeouts; 2. other daemons fail because 1 or dbus restart; 3. failed reload at packet install process may lead to overall install fail; Because of automatic config reload, 1 is strikes at periodic manner. The most notorious example of 2 is NetworkManager, which gets SIGTERM (org.freedesktop.nm_dispatcher timeout), shutdown network and require manual restart, despite the fact that dbus already restarted. Nice to have bunch of isolated instances at midnight because of network spike (: 3 is theoretical and depends on packages postinstall scripts and hooks. Steps to reproduce: 1a. Get minimal setup with some additional packages: # debootstrap --arch=amd64 --include=network-manager,sssd,iio-sensor-proxy,ovirt-guest-agent,linux-image-amd64,grub-pc stable /mnt # #Do other stuff to boot from... 1b. Or add network-manager, sssd, iio-sensor-proxy and ovirt-guest-agent to fresh setup. Last two will add policy with currently nonexistent users gdm and geoclue. Skip sssd realm config. You may notice NoReply fail due setup. 2. Check NetworkManager status and restart if already dead. 3. Do systemctl reload dbus.service. Notice time taken. 4. Check NetworkManager again. Status change to 'dead' after step 3 or some short time. 5. Check dbus journal. Notice org.freedesktop.nm_dispatcher activation fail, NoReply and restart. BONUS STAGE: remove one user policy (eg. purge ovirt-guest-agent OR iio-sensor-proxy), restart NetworkManager and do dbus reload again. This time NM not fail. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dbus depends on: ii adduser 3.118 ii libapparmor1 2.13.2-10 ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libcap-ng00.7.9-2 ii libdbus-1-3 1.12.16-1 ii libexpat1 2.2.6-2 ii libselinux1 2.8-1+b1 ii libsystemd0 241-5 dbus recommends no packages. Versions of packages dbus suggests: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 Versions of packages dbus is related to: pn dbus-x11 ii systemd 241-5 ii systemd-sysv 241-5 -- no debconf information -- Logs begin at Tue 2019-08-13 14:27:09 UTC, end at Tue 2019-08-13 17:45:55 UTC. -- Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: NetworkManager-wait-online.service: Succeeded. Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Stopped Network Manager Wait Online. Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Stopping Network Manager Wait Online... Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Starting Network Manager... Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.3909] NetworkManager (version 1.14.6) is starting... (after a restart) Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.3917] Read config: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Started Network Manager. Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Starting Network Manager Wait Online... Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.4021] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager" Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.4029] manager[0x55a91f88b020]: monitoring kernel firmware directory '/lib/firmware'. Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.4031] monitoring ifupdown state file '/run/network/ifstate'. Aug 13 17:43:29 test-dbus-fail.fake.domain dbus-daemon[7179]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.8' (uid=0 pid=7338 comm="/usr/sbin/NetworkManager --no-daemon ") Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Starting Hostname Service... Aug 13 17:43:29 test-dbus-fail.fake.domain dbus-daemon[7179]: [system] Successfully activated service 'org.freedesktop.hostname1' Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Started Hostname Service. Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.4680] hostname: hostname: using hostnamed Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.4681] hostname: hostname changed from (none) to "test-dbus-fail.fake.domain" Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]: [1565718209.4683]
Bug#903059: slt FTBFS: update Build-Depends: ruby-ronn -> ronn
The bug has already been fixed in slt 0.0.git20140301-5 and can be closed. On buster slt can be build using the 0.0.git20140301-6.dsc from unstable. Would be nice to get it into buster-backports. Kai-Uwe
Bug#933264: gradle: update SID version to new version?
Newer version of Gradle requires Kotlin, which is being worked on right now. See https://java-team.pages.debian.net/gsoc-kotlin-blog signature.asc Description: OpenPGP digital signature
Bug#807383: gcc-doc: Manpage documentation of -l is incorrect
Hello, the manual text has been fixed upstream for gcc-9.1.0. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Link-Options.html#Link-Options The linker searches a standard list of directories for the library. The directories searched include several standard system directories plus any that you specify with -L. Static libraries are archives of object files, and have file names like liblibrary.a. Some targets also support shared libraries, which typically have names like liblibrary.so. If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used.
Bug#932304: do_IRQ: 0.37 No irq handler for vector
at 22:24, Mathieu Malaterre wrote: False positive. Turns out commit e9d0ba506ea8661a7d91d67e04abe69a535b6048 is present in debian linux kernel on buster. Do you mean it’s solved? If it's not, please file a proper bug report at Launchpad.net or bugzilla.kernel.org with enough information. Kai-Heng -- Forwarded message - From: Kai-Heng Feng Date: Wed, Jul 17, 2019 at 4:13 PM Subject: Re: do_IRQ: 0.37 No irq handler for vector To: Mathieu Malaterre Hi Mathieu, at 22:05, Mathieu Malaterre wrote: Hi Kai, I just stumble upon your post: https://lore.kernel.org/lkml/e5521441-be1e-4a43-ab5c-0e91165e0...@canonical.com/ Would you be kind and tell me what is the actual commit -stable which was needed ? commit e9d0ba506ea8661a7d91d67e04abe69a535b6048 Author: Daniel Drake Date: Thu Sep 27 15:47:33 2018 -0500 PCI: Reprogram bridge prefetch registers on resume I think this affect many PCI devices that facilitate MSI-X Kai-Heng
Bug#931215: many well known Android devices not supported
Control: severity -1 wishlist > You raised the severity of this bug to serious. I think that was by mistake. Since this is a "metabug", I am now giving it a `wishlist`. signature.asc Description: OpenPGP digital signature
Bug#930091: bison is wrongly marked Multi-Arch: foreign
I finished rebuilding all reverse build dependencies of bison. And I found that removing libbison-dev as a dependency of bison (option A) does not cause any additional FTBFS errors. All the build failures I observed were due to existing FTBFS bugs, or due to problems (such as tests hanging) that are very unlikely to be caused by missing liby.a, which should cause static linking errors. So I believe that we can proceed with option A without filing any bugs on reverse build dependencies of bison.
Bug#930091: bison is wrongly marked Multi-Arch: foreign
Status update. The ratt run is still in progress, having built 152 out of 547 reverse dependencies. Out of those 152 only 1 fails to build (libbonobo), and that package is already FTBFS for reasons entirely unrelated to bison. So I think A is the way to go, and it is likely that very few packages will need to manually add libbison-dev as build dependency.
Bug#930091: bison is wrongly marked Multi-Arch: foreign
On Thu, Jun 6, 2019 at 9:50 PM Helmut Grohne wrote: > And the question now is: Where to move that dependency? Either the > consumers must explicitly depend on libbison-dev (A) or bison is > restructured in a way that still provides the library for the right > architecture when issuing a dependency on bison (B). Personally I would go for A. The reason being the following paragraph from Bison documentation [1]: "The Yacc library contains default implementations of the yyerror and main functions. These default implementations are normally not useful, but POSIX requires them." I don't see too many applications being happy with the Yacc library main() function, so I suspect that most packages should continue to build without explicit dependency on libbison-dev. And letting the mostly useless Yacc library take the "bison" package name just feels wrong to me. I will see about setting up a ratt run to see how many packages would actually FTBFS with option A and report back. Though I will definitely take you up on your offer to take care of MBF, once we have the list of affected packages. [1] https://www.gnu.org/software/bison/manual/html_node/Yacc-Library.html#Yacc-Library
Bug#930091: bison is wrongly marked Multi-Arch: foreign
Hi Helmut, Thank you for the bug report! Let me see if I understand the situation correctly: 1. bison (the executable) being marked Multi-Arch: foreign is not inherently broken, since in a cross-build situation we are running the bison binary in the host (instead of the target) architecture. 2. The broken part is bison depending on libbison-dev, which cannot possibly be Multi-Arch: foreign (as it needs to be linked into the binary being built). 3. So the desired end state (for both options) is that bison (the executable binary, whatever its package name) remaining Multi-Arch: foreign but not depending on libbison-dev. Am I understanding this correctly? Chuan-kai
Bug#927742: eclipse-titan: Avoid hard dependency of eclipse-titan to default-jdk
Package: eclipse-titan Version: 6.5.0-1+b1 Severity: normal Dear Maintainer, * What led up to the situation? Adding eclipse-titan to a development VM results in a lot of unnecessary package installs due to the dependency on default-jdk. * What exactly did you do (or not do) that was effective (or ineffective)? s. above * What was the outcome of this action? s. above * What outcome did you expect instead? I would like to be able to use the titan TTCN-3 compiler in C++ only mode (without eclipse based UI components which seem to required a full blown JDK). Could you consider to move the dependency on default-jdk to the recommended (or suggested) packages? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (150, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages eclipse-titan depends on: ii default-jdk 2:1.11-71 ii expect5.45.4-2 ii gcc 4:8.3.0-1 ii libc6 2.28-8 ii libgcc1 1:8.3.0-6 ii libncurses6 6.1+20181013-2 ii libpcap-dev 1.8.1-6 ii libpcre3-dev 2:8.39-12 ii libsctp-dev 1.0.18+dfsg-1 ii libssl-dev1.1.1b-2 ii libssl1.1 1.1.1b-2 ii libstdc++68.3.0-6 ii libtinfo6 6.1+20181013-2 ii libxml2 2.9.4+dfsg1-7+b3 ii libxml2-dev 2.9.4+dfsg1-7+b3 ii make 4.2.1-1.2 ii perl 5.28.1-6 ii python2.7.16-1 eclipse-titan recommends no packages. eclipse-titan suggests no packages. -- no debconf information
Bug#924591: this requires linking in libsparse, which is from Android sources
> So your choice --- we can either reassign this bug back to fastboot or > android-sdk-platforms-tools, or I can downgrade the severity of this > bug for e2fsprogs down to wishlist[1]. Let me know how you want to > handle this. I would say downgrade it for the moment. We can deal with it after Buster. Indeed this is quite tricky. I agree that `e2fsprogs` shouldn't depend on `libsparse`. I like the `dlopen` approach but it increases the maintenance burden a little bit. But anyway I am too mentally tired of yet another AOSP fork making into Debian's archive... signature.asc Description: OpenPGP digital signature
Bug#926735: Set severity
Control: severity -1 serious
Bug#926735: Set Severity
Severity: serious
Bug#926735: Set severity
severity: serious Maybe this can be lowered to 'important', but I believe buster should not be released because users might misinterpret the disappearence of the extended partition as data loss (leading to panic specially when the GUI does not show the contained logical partitions anymore) while actually it is not a data loss since triggering a syscall, reattaching the device, or rebooting makes it appear again.
Bug#926735: Include upstream patch for extended partition size
Package: libparted2 Version: 3.2-24 src:parted Please include upstream commit c6dc6e5d from 2015 as additional package patch because it fixes the unit of the partition resize ioctl. http://git.savannah.gnu.org/cgit/parted.git/commit/?id=c6dc6e5d0f49a26242d2b28622514814a53d92e1 Currently the extended partitions will be inaccessible until some program forces the kernel to reread the partition table. See related issues: https://github.com/storaged-project/udisks/issues/425 https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1641308
Bug#925424: linux-image-amd64: Build the Silead touchscreen controller kernel driver
Package: linux-image-amd64 Version: 4.19+102 Severity: normal Dear Maintainers, a wide range of budget x86 tablets make use of Silead touchscreen controllers. A driver for Silead touchscreen controllers was added to the Linux kernel a few years ago, but it's not being built in the Debian kernel images at the moment. To enable it, the following build configuration options would have to be set: CONFIG_TOUCHSCREEN_SILEAD=m CONFIG_TOUCHSCREEN_DMI=y (https://github.com/onitake/gsl-firmware/issues/114#issuecomment-475989938) Could you consider enabling these options for future builds? Thank you very much! Greetings, Kai Renzig -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-amd64 depends on: ii linux-image-4.19.0-2-amd64 4.19.16-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
Bug#922444: racket: Install Package doesn't work in DrRacket
On Sat, 16 Feb 2019 09:00:50 -0400 David Bremner wrote: > Mike Manilone writes: > > cadr: contract violation > > expected: (cons/c any/c pair?) > > given: #f > > context...: > >/usr/share/racket/pkgs/gui-pkg-manager-lib/pkg/gui/private/by- > > source.rkt:534:4: adjust-deps method in by-source-panel% > >/usr/share/racket/pkgs/gui-pkg-manager-lib/pkg/gui/private/by- > > source.rkt:422:4: adjust-all method in by-source-panel% > >/usr/share/racket/collects/racket/private/class- internal.rkt:3554:0: > > Looking at this again, do you mean that you get the traceback when you > select the menu item? Yes. When I click this menu item, DrRacket reports this error. > Are you running the standard Gnome3 interface, or something else? Yes, I'm using Gnome3. I've got a new discovery. Run DrRacket under the en_US.utf8 locale and the problem is gone. I tested ja_JP.utf8 as well and it also worked. I don't know if it only happens under zh_CN.utf8. Maybe an upstream bug?
Bug#877331: sponsorship-requests: nix/1.1.15 (ITP 877019) -- Purely functional package manager
Hi, itd writes: > Hi, > > Kai Harries: >> The depender will break if the dependency is not at the path where it >> used to be at build-time (by default /nix/store/...). All software >> deployed by nix contains the full path to its dependencies. And all >> dependencies are available inside the nix-store. The idea is to rely on >> nothing that is outside the nix-store. > > would `mount --bind /var/nix /nix` help? In other words, Debian package > nix uses /var/nix. Additionally, the package ships a Debian.README which > states that users need to either bind mount /var/nix to /nix or to > disable binary downloads. Yes, bind mounts should work. I had started a discussion on d-devel [1] on the topic of the non-standard-toplevel-dir, and from there I got the impression that a lintian override is the way to go. >From the user experience view I would prefer not to resort to a bind-mount, but I guess your proposal should work and is the next best thing I can imagine. Regards Kai [1] https://lists.debian.org/debian-devel/2019/01/msg00010.html
Bug#877331: sponsorship-requests: nix/1.1.15 (ITP 877019) -- Purely functional package manager
Dmitry Bogatov writes: > [2018-12-29 19:54] Vincent Bernat >> > Probably not. Violations of FHS is violation of policy, and to get >> > authorization to policy violation is long road, starting with discussion >> > on debian-devel@. >> > >> > But, can't we just configure Nix to store it under /var/nix? >> >> This would break the ability to use pre-built stuff and make nix >> slow. > > I belive you, but just for my curiosity, what will break if we download > substitute (nar, almost tar archive) and extract it not in /nix, but in > /var/nix? The depender will break if the dependency is not at the path where it used to be at build-time (by default /nix/store/...). All software deployed by nix contains the full path to its dependencies. And all dependencies are available inside the nix-store. The idea is to rely on nothing that is outside the nix-store. For example an ldd on bash looks like this: $ ldd /nix/store/ij6wirzff9id7jr071p04w4nk6hksc3y-bash-interactive-4.4-p23/bin/bash /nix/store/ij6wirzff9id7jr071p04w4nk6hksc3y-bash-interactive-4.4-p23/bin/bash: linux-vdso.so.1 (0x7ffe1a7d5000) libreadline.so.7 => /nix/store/vvwxc17kpc39qbcz7qp7mkqa7fr0my84-readline-7.0p5/lib/libreadline.so.7 (0x7f25b0593000) libhistory.so.7 => /nix/store/vvwxc17kpc39qbcz7qp7mkqa7fr0my84-readline-7.0p5/lib/libhistory.so.7 (0x7f25b0389000) libncursesw.so.6 => /nix/store/2lbhgxlrhgnij2c3bm719xidymmhp0m0-ncurses-6.1-20181027/lib/libncursesw.so.6 (0x7f25b011a000) libdl.so.2 => /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libdl.so.2 (0x7f25aff16000) libc.so.6 => /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libc.so.6 (0x7f25afb62000) /nix/store/7gx4kiv5m0i7d7qkixq2cobra10lvxwc-glibc-2.27/lib/ld-linux-x86-64.so.2 => /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x7f25b07def000) Regards, Kai
Bug#919598: zlib: copyright file needs updating
Source: zlib Severity: normal Dear Maintainer, a) the zlib 1:1.2.11.dfsg-1 copyright file claims to be based on sources from zlib-1.0.4.tar.gz which is obviously wrong. b) the Files-Excluded field is not up-to-date for zlib_1.2.11.dfsg.orig.tar.gz. The listed contrib/testzlib is in the DFSG sources, but the now-removed win32 directory is not listed as Files-Excluded. The win32 directory is how I came here: I'm building for Mingw from the Debian sources, which now fails. Is the removal of the win32 directory neccessary? I do see the restrictions established in win32/DLL_FAQ.txt. However, I don't think these restrictions are removed by removing this file. They may apply to the DFSG sources as well, even with the win32 dir removed. Best regards Kai
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
* Simon Deziel : > Actually, please use this new attached profile which is identical in > purpose but uses better names. The profile works with the secret-tool solution. If the maintainers choose to restrict the use of "secret helpers" to only gpg* and secret-tool than this should be mentioned in the documentation/README/NEWS. Is there any decision yet that says where the restriction of AppArmor should be documented in Debian? AppArmor restrictions might bring up a lot of bug reports in the future. One addition: I chose to place my logfiles into $XDG_CACHE_HOME, which by default is $HOME/.cache. I am no longer able to go this way. Should a user not allowed to write in any file at any place in it's home directory? This is my current setting logfile ~/.cache/msmtp/msmtp.log and the error is not very helpful because it never mentions AppArmor: msmtp: cannot log to /home/kai/.cache/msmtp/msmtp.log: cannot open: Permission denied
