Bug#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate
Dear Salvatore, I've already started bisecting. It will take some time. Usually the bug appears after a few hours, unfortunately I am not able to trigger it faster. So, if the bug appears, I can step forward easily, but if not, its hard to decide if it is still present and simply just have not occured, or if the current version is a good one. I'll try to do my best. I will also contact linux-nfs mailing list. As I remember, it started nearly a year ago, when I switched to Debian's kernel. I dont know exactly what version was at that time. Howewer, I've checked Debian's patches, and I did not find anything related to NFS. Regards, Richard 2024-05-20 21:07 időpontban Salvatore Bonaccorso ezt írta: Hi Richard, On Mon, May 20, 2024 at 09:27:24AM +, Richard Kojedzinszky wrote: Package: src:linux Version: 6.1.90-1 Severity: normal X-Debbugs-Cc: richard+debian+bugrep...@kojedz.in Dear Maintainer, I am running kubernetes on debian, and pods are mounting multiple nfs shares. I am running dovecot processes in PODs, which receive mails from the internet, and also serves as imap server for clients. I am monitoring my mail system by sending mails periodically (15 seconds) and also downloading them via imap. I found a few times that some dovecot process stuck in D state, a reboot was always needed to recover from that state. Unfortunately, I was not able to trigger the bug really fast, I dont really know what operations does dovecot issue and in what order to trigger this behavior. So until I get closer, I've set up a similar, but smaller environment with just a single dovecot process, and it also does the same work, delivering only test mails locally, and serving them via imap to the monitoring client, storing everything on NFS. Fortunately, this also triggers the bug, after a few hours one of the dovecot processes is stuck in D state. Kernel also shows blocked state: As you seem in the lucky position to be able to trigger the issue in a more localized setup, might you: - try as well more recent kernels from upper suites (6.8.9-1 in unstable would be ideal to check if the issue is there as well). - I did read you cannot trigger with 5.15. If you build 6.1.90 from upstream without Debian patches I assume you can trigger the issue likewise? If so could you bisect the changes introducing the issue? This is a cumbersome process in particular if you need few hours to trigger it So maybe the following point could be done first: - Can you report the issue to the linux-nfs list, keeping us in the loop? Regards, Salvatore
Bug#1071556: Acknowledgement (Dvorak keymap not loaded after login)
I've reported this issue to the upstream project at https://github.com/neutrinolabs/xrdp/issues/3081 Ubuntu's version 0.9.24-4 in 24.04/noble is likewise affected.
Bug#1071556: Dvorak keymap not loaded after login
Package: xrdp Version: 0.9.24-5 Severity: important Recently, I have noticed that logging in via a recent version of xrdp, while using the Dvorak layout on the client, yields a QWERTY layout in the remote framebuffer after getting past the login dialog. This is incorrect behavior and has never happened before. After some digging, I tracked the problem down to this: https://bugs.debian.org/1063725 It is no longer possible to refer to the Dvorak layout as just "dvorak" (as when one would run "setxkbmap dvorak"); one must now use either "us dvorak" or "us(dvorak)". The below edit fixes the issue and allows me the proper keymap after logging in: --- /etc/xrdp/xrdp_keyboard.ini.orig +++ /etc/xrdp/xrdp_keyboard.ini @@ -86,7 +86,7 @@ ; = [default_layouts_map] rdp_layout_us=us -rdp_layout_us_dvorak=dvorak +rdp_layout_us_dvorak=us(dvorak) rdp_layout_us_dvp=us(dvp) rdp_layout_dk=dk rdp_layout_de=de @@ -125,7 +125,7 @@ [rdp_layouts_map_mac] rdp_layout_us=us -rdp_layout_us_dvorak=dvorak +rdp_layout_us_dvorak=us(dvorak) rdp_layout_us_dvp=us(dvp) rdp_layout_dk=dk rdp_layout_de=de --Daniel
Bug#1071426: logcheck-database: smartd: Match nvme lines too
On Sun, 19 May 2024 at 05:06, Stefanos Harhalakis wrote:
> See attached patch for matching NVMe devices too in smartd logs
Thanks - yes i'd noticed that the rules for smartd need an update and
this is on the radar - however, the
update to the names of the .state files i was not aware of!
I think the first part of the patch is not quite right, per the code
i think it should be:
# from https://sources.debian.org/src/smartmontools/7.4-2/smartd.cpp/#L5829
... Monitoring [[:digit:]]+ ATA/SATA, [[:digit:]]+ SCSI/SAS and
[[:digit:]]+ NVMe devices
It would be really helpful if you could:
1/ send some sample log output logs,
something like:
journalctl -t smartd | awk '{$1=$2=$3=$4="";$5="X";print}' | sort -u
would be helpful
I'm especially unsure about the bits of rules that start "Device:" as
i could not work out what format is expected -- the current rules have
Device: /dev/[^[:space:]]+( \[[_/[:alnum:][:space:]]+\])?( \[SAT\])?
but im not sure if the optional groups are up-to-date, -- i couldnt
find what bit of code determines those.
2/ the attached rules (untested) are what i'm wokring on for smartd -
any testing of these would be great
(I generalised the name of the .state file - again i dont know where
smartd sets this bit, so hard to know what is expected!)
(these are completely untested, so may be completely broken)
smartd.rules
Description: Binary data
Bug#1071377: chkrootkit: File name including a quote mark throws script off
On Sat, 18 May 2024 at 08:39, Shai Berger wrote: > This morning, when chkrootkit made its daily run, I had > in /tmp a file named: 'חברת חשמל לישראל בע"מ - חשבון דו חודשי.pdf' > (the single quote marks on the edges are not part of the name, but > the double quote mark in the middle is) > > This caused this output from the script: > > """ > Searching for suspect PHP files... /usr/bin/head: > cannot open '/tmp/חברת חשמל לישראל בעמ' for reading: No such file or directory > /usr/bin/head: cannot open 'חשבון' for reading: No such file or directory > /usr/bin/head: cannot open 'דו' for reading: No such file or directory > /usr/bin/head: cannot open 'חודשי.pdf 2>/dev/null | /usr/bin/grep -q ^#!.*php > && echo /tmp/חברת' for reading: No such file or directory > /usr/bin/head: cannot open 'חשמל' for reading: No such file or directory > /usr/bin/head: cannot open 'לישראל' for reading: No such file or directory > /usr/bin/head: cannot open 'בעמ - חשבון דו חודשי.pdf' for reading: No such > file or directory > WARNING Thanks, yes this is probably also bug in upstream as well, but there are debian-specific patches that make this worse. Will fix. Patches also welcome - it's patch number 16 in debian/patches that has the PHP check.
Bug#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate
Package: src:linux Version: 6.1.90-1 Severity: normal X-Debbugs-Cc: richard+debian+bugrep...@kojedz.in Dear Maintainer, I am running kubernetes on debian, and pods are mounting multiple nfs shares. I am running dovecot processes in PODs, which receive mails from the internet, and also serves as imap server for clients. I am monitoring my mail system by sending mails periodically (15 seconds) and also downloading them via imap. I found a few times that some dovecot process stuck in D state, a reboot was always needed to recover from that state. Unfortunately, I was not able to trigger the bug really fast, I dont really know what operations does dovecot issue and in what order to trigger this behavior. So until I get closer, I've set up a similar, but smaller environment with just a single dovecot process, and it also does the same work, delivering only test mails locally, and serving them via imap to the monitoring client, storing everything on NFS. Fortunately, this also triggers the bug, after a few hours one of the dovecot processes is stuck in D state. Kernel also shows blocked state: May 19 12:16:49 k8s-node07 kernel: INFO: task lmtp:665683 blocked for more than 120 seconds. May 19 12:16:49 k8s-node07 kernel: Not tainted 6.1.0-21-arm64 #1 Debian 6.1.90-1 May 19 12:16:49 k8s-node07 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 19 12:16:49 k8s-node07 kernel: task:lmtpstate:D stack:0 pid:665683 ppid:2881 flags:0x May 19 12:16:49 k8s-node07 kernel: Call trace: May 19 12:16:49 k8s-node07 kernel: __switch_to+0xf0/0x170 May 19 12:16:49 k8s-node07 kernel: __schedule+0x340/0x940 May 19 12:16:49 k8s-node07 kernel: schedule+0x58/0xf0 May 19 12:16:49 k8s-node07 kernel: __nfs_lookup_revalidate+0x118/0x160 [nfs] May 19 12:16:49 k8s-node07 kernel: nfs4_lookup_revalidate+0x20/0x30 [nfs] May 19 12:16:49 k8s-node07 kernel: lookup_fast+0x138/0x150 May 19 12:16:49 k8s-node07 kernel: walk_component+0x30/0x1a0 May 19 12:16:49 k8s-node07 kernel: path_lookupat+0x80/0x1a4 May 19 12:16:49 k8s-node07 kernel: filename_lookup+0xb4/0x1b0 May 19 12:16:49 k8s-node07 kernel: vfs_statx+0x94/0x19c May 19 12:16:49 k8s-node07 kernel: vfs_fstatat+0x68/0x90 May 19 12:16:49 k8s-node07 kernel: __do_sys_newfstatat+0x58/0xa0 May 19 12:16:49 k8s-node07 kernel: __arm64_sys_newfstatat+0x28/0x34 May 19 12:16:49 k8s-node07 kernel: invoke_syscall+0x78/0x100 May 19 12:16:49 k8s-node07 kernel: el0_svc_common.constprop.0+0x4c/0xf4 May 19 12:16:49 k8s-node07 kernel: do_el0_svc+0x34/0xd0 May 19 12:16:49 k8s-node07 kernel: el0_svc+0x34/0xd4 May 19 12:16:49 k8s-node07 kernel: el0t_64_sync_handler+0xf4/0x120 May 19 12:16:49 k8s-node07 kernel: el0t_64_sync+0x18c/0x190 Or, for another process: May 20 04:50:01 k8s-node07 kernel: INFO: task imap:8337 blocked for more than 120 seconds. May 20 04:50:01 k8s-node07 kernel: Not tainted 6.1.0-21-arm64 #1 Debian 6.1.90-1 May 20 04:50:01 k8s-node07 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 20 04:50:01 k8s-node07 kernel: task:imapstate:D stack:0 pid:8337 ppid:3164 flags:0x May 20 04:50:01 k8s-node07 kernel: Call trace: May 20 04:50:01 k8s-node07 kernel: __switch_to+0xf0/0x170 May 20 04:50:01 k8s-node07 kernel: __schedule+0x340/0x940 May 20 04:50:01 k8s-node07 kernel: schedule+0x58/0xf0 May 20 04:50:01 k8s-node07 kernel: __nfs_lookup_revalidate+0x118/0x160 [nfs] May 20 04:50:01 k8s-node07 kernel: nfs4_lookup_revalidate+0x20/0x30 [nfs] May 20 04:50:01 k8s-node07 kernel: lookup_fast+0x138/0x150 May 20 04:50:01 k8s-node07 kernel: walk_component+0x30/0x1a0 May 20 04:50:01 k8s-node07 kernel: path_lookupat+0x80/0x1a4 May 20 04:50:01 k8s-node07 kernel: filename_lookup+0xb4/0x1b0 May 20 04:50:01 k8s-node07 kernel: vfs_statx+0x94/0x19c May 20 04:50:01 k8s-node07 kernel: vfs_fstatat+0x68/0x90 May 20 04:50:01 k8s-node07 kernel: __do_sys_newfstatat+0x58/0xa0 May 20 04:50:01 k8s-node07 kernel: __arm64_sys_newfstatat+0x28/0x34 May 20 04:50:01 k8s-node07 kernel: invoke_syscall+0x78/0x100 May 20 04:50:01 k8s-node07 kernel: el0_svc_common.constprop.0+0x4c/0xf4 May 20 04:50:01 k8s-node07 kernel: do_el0_svc+0x34/0xd0 May 20 04:50:01 k8s-node07 kernel: el0_svc+0x34/0xd4 May 20 04:50:01 k8s-node07 kernel: el0t_64_sync_handler+0xf4/0x120 May 20 04:50:01 k8s-node07 kernel: el0t_64_sync+0x18c/0x190 Of course the NFS server is running, and other NFS mounts are still working from the node. Also, this started to happen with Debian's kernel. Before that, I was compiling my own upstream kernel, version 5.15. With that, I've never experienced such a lockup. Unfortunately, I dont know, how to go further, how shall I collect more relevant debugging information. I expect thet dovecot is just an application, which should not cause any kernel-side lockups. In my test lab, this specific NFS mount is just mounted on one machine
Bug#358965: RE: bash: Please support setting terminal title for screen
On Sun, 4 May 2014 22:33:23 +1000 Scott Leggett wrote: > I just spent half an hour figuring out how to get window titles to > reflect my session in byobu.. and I find the exact patch required is > already here (thanks Josh). > > I guess this is just a +1 for patching skel.bashrc so that ssh-ing into > machines via byobu does The Right Thing to your terminal emulator's > window title automatically. > > -- > Regards, > Scott Leggett The screen manpage explains this, and recommends a slightly different formulation for escaping --- might want to use that for consistency: PROMPT_COMMAND='printf "\033k\033\134"'
Bug#625895: logcheck-database: /etc/logcheck/ignore.d.server/dovecot rule misses unusual Message-Id
On Fri, 06 May 2011 11:32:03 -0700 Gerald Turner wrote: > Hello, I've seen some legitimate mails with unusual Message-Id headers > that cause logchecks dovecot delivery rule to be bypassed. > > Example: … sieve: msgid=<20110422T2108.GA.(stdi.s...@fsing.rootsland.net>: > stored mail into mailbox 'Mailing Lists/Debian/debian-devel' It's a shame no-one replied since 2011. That doesnt seem to be a valid msgid, so not sure logcheck should be ignoring it by default. Obviously you can edit / make your own rules to do so. So not sure there is anything for debian to do in this one. Perhaps we should close the bug?
Bug#491127: logcheck: please consider an option which will always check the entire log file
On Sun, 12 May 2024 at 19:57, Marc Haber wrote: > > On Sun, May 12, 2024 at 06:54:59PM +0100, R Lewis wrote: > > On Wed, 16 Jul 2008 23:15:51 +0200 Marc Haber > > wrote: > > > > > It would help with debugging to have an option that causes logcheck to > > > always look through the entire log file, ie not using logtail. > > > > Looking at this old bug from 2008: does the -t option meet this need? > > Not quite. Imagine: I have a system running logcheck hourly. At 11:00, I > get a mail with a log message from 10:55 that is not yet covered by the > rule. The stamp gets updated to 11:00. > > I now fix the rule that should have filtered the message. logcheck -t > will still only start checking a 11:00, so the test run will not prove > that the change has actually filtered the message from 10:55. > > Does this make the usecase clear? Does logcheck-test help with that?
Bug#975694: [logcheck-database] stop filtering smartd attribute change events
control: tags -1 + moreinfo thanks On Wed, 25 Nov 2020 13:13:14 +0500 Alex Volkov wrote: > IDK how it was in 2006 when this stupid decision was made, but nowadays > `smartd` has all the needed filtering features in itself, in a case someone > gets "annoyed" by attribute changes. Yeah, sure, it "can send warning mails", > but by default only in a case of attribute FAILURE, and some Old-age related > attributes NEVER fail (like Power-On Hours on WD, which counts down to 1 and > just sits happily there, never getting to "failing" 0). In such cases at least > seeing them changing (or not) is useful. Overall, it's not the place for a > *maintainer* to decide (instead of a user) which events of a third-party > package are annoying and which are not. Following up on the above bug from 2020 -- we need more information here: what is the issue that you would like fixed? you can already (even in 2020) add or subtract any rules for logcheck that you like. smartd has a way to alert you to issues, but that is nothing to do with logcheck. in the absence of a clearer statement we would need to close this one.
Bug#862638: logcheck: Please add suricata rules to logcheck
control: tags -1 moreinfo control: severity -1 wishlist thanks On Mon, 15 May 2017 10:42:03 +0200 > I am very happy with logcheck. It is great working and very usefull. However, > it would be nice, if you could add a ruleset for suricata (a successor to the > well known snort IDS), so I get alerted, when something fishy is going on. It's a shame no-one replied to this bug from 2017 - let's change that now. >In my case logcheck is run every 30 minutes, so I am very fast aware, when an >attack is going on. On the other hand, I found no realtime alert option with >suricata. Best way, IMO, would be a ruleset for suricata logs, which do alert >me by mail (as logcheck normally do). Unfortunately more information is needed to help this. Is the request to use logcheck to scan non-log files created by suricata? you can definitely do that but would need to write your own rules to ignore things that are not "fishy". ...but i dont think logcheck-database should ship such rules unless there is clear demand. It looks like suricata can send its own alerts so not sure this is even needed in 2024? If there are messages produced by suricata in the journal that logcheck should be filtering, then we need to know what those are? (In the absence of more information we would likely close this bug as unactionable)
Bug#735287: logcheck: invent conditional logging
On Tue, 14 Jan 2014 13:33:25 +0100 Arne Wichmann wrote: > There is one thing I would like to have in logcheck for quite a long time > already: > > Invent a mechanism by which a pattern is only mailed (or not mailed) if > another pattern was seen a given time before it (or also possibly after > it). > > For example I would like to make reboots invisible on some machines, but I > do want to see it if the sshd terminates as long as the machine is not > rebooting. Hi - It's a shame no-one replied to this bug in 10 years: let's change that now. The only realistic way i can see this working is to have some kind of pre-processing of log entries. I'm thinking you would write a pre-processor that takes each line in the log and look back in the journal (or syslog) for related lines -- i dont think we'd want to implement that in logcheck, as it would be a whole other project to write, but we could allow the user to do it. There are several reasons to make logcheck configurable to pre-processing ( - work on this is in progress. watch this space!). You can maybe even today do this with post-processing by writing a 'syslog-summary' script - again this would need the user to write their own code. (I think the point in the last para is basically solved by using systemd, which makes it much easier to restart daemons when they crash) In the absence of other suggestions, i suggest we implement configurable pre-processing, leave syslog-summary support in place and close this bug.
Bug#919866: logcheck: Feature request: wildcards in .logfiles pathnames
On Sun, 20 Jan 2019 15:50:55 +0530 Charles Atkinson wrote: > Please consider introducing wildcards into the paths in the .logfiles > configuration files. Perhaps similar to the way they are used in logrotate's > paths. > A use case is when using logcheck to check logs from multiple non-Debian > systems such as routers, each having a dedicated directory with the last > directory being their FQDN. The router FQDNs follow a fixed pattern. > Currently this requires an /etc/logcheck-for-routers/logcheck.logfile.d file > for each router. If .logfiles supported wildcards, a single > /etc/logcheck-for-routers/logcheck.logfile.d file could be used for all > routers and there would be one less step in the procedures to commission and > to decommission a router. (It's a shame no-one replied since 2019: let's change that now) You could instead implement this by a script that updates the .logfiles file before logcheck runs: if you put this into logcheck.conf it would work, so eg: echo /var/log/whatever/*.log > /etc/logcheck-for-routers/logcheck.logfiles.d/routers.logfiles If that would meet your needs we could close this bug - the code to read logfiles.list is already over-complicated and adding more features needs a good reason
Bug#241787: options to seperate hosts and for log compaction would both be nice
> This bug is nearly 20 years old. (It is a shame no-one replied - the links > no longer work and there is not enough info recorded to action) > > Unless anyone is watching and can proivde more info about what the issue > is/was then i suggest we close it. A year later: closing. logcheck can send reports as gzip'd attachments so perhaps it was even fixed sometime in the last 20 years.
Bug#302379: dh_installlogcheck installs files as root:root 644, not root:logcheck 640
On Mon, 24 Aug 2009 08:36:21 -0400 =?iso-8859-1?B?RnLpZOlyaWMgQnJp6HJl?= wrote: > On Thu, Mar 31, 2005 at 09:54:34AM -0500, Marc Sherman wrote: > > I reported a bug on a couple clamav packages (302253, 302254) which > > noted that in Sarge, logcheck files are supposed to be root:logcheck > > 640, not root:root 644. The clamav maintainer replied that he's using > > I should note that while the /etc/logcheck/* directories are setgid to > attempt to fix this discrepancy, this doesn't work, as dpkg will chown() > the installed files anyway. > > I guess there should be a note in README.Maintainer to instruct people > not to install those files as 640, as tempting as it may be. Closing this bug because it no longer applies some 15 years later: - The directory /etc/logcheck is no longer setgid (since bookworm), - Rules can have any permissions (as long as logcheck can read them). (the default is 644 and root:root (which means harder to delete rules files). - so no need for dh_logcheck to be patched here therefore, closing as no more bug. (But feel free to reopen if there is anything more to do)
Bug#383289: RFE: logtail locking
On Wed, 16 Aug 2006 05:33:26 -0500 bingo wrote: > It would be good if logtail supports locking. I think we need some more information if this bug is to be action-ed. logcheck uses logtail2 now (and syslog is not the default):so perhaps it is not relevant after nearly 20 years (there were other replies requesting patches in the intervening period, and no-one has provided them -- so perhaps we should just close this as no longer relevant). If the issue is that rsyslog might still be writing to the file, when logtail runs, surely all that might happen is that the same entries might be re-checked on the next run? (and I dont think it would be sensible for logtail to try and stop rsyslog writing while logtail runs) the journal has a better way to avoid races, using --cursor-file -- logcheck doesnt yet use that (watch this space!) which i think might also avoid potential race conditions here
Bug#750232: logtail2 should not not print the final log entry if it does not end with "\n"
On Mon, 2 Jun 2014 10:25:40 -0700 (PDT) Chris Stromsoe wrote: > logtail2 does not do any sanity checking on the final line of input to > make sure that it is complete and "\n" terminated. If syslog is not set > to flush on every write, it's possible for consecutive runs of logcheck to > get a single log entry split in half for each run, resulting in false > positives from logcheck. Is this still an issue in 2024? if not we could close this old bug. If you ran logtail2 on a non-syslog file (which might actually be an increasingly common usage in a systemd world?), then ignoring a line without a trailing \n means that last line might never be checked, which seems far worse than the occasional false-positive. I dont think i ever saw such false positives with rsyslog, when i used it.
Bug#470997: logcheck: allow running w/o locking
On Fri, 14 Mar 2008 21:50:17 -0400 =?utf-8?b?RnLDqWTDqXJpYyBCcmnDqHJl?= < > When testing a checked-out copy of the rulefiles against an old log copy > and sending the output to stdout, I still have to use sudo because > logcheck insists on creating a lockfile. It'd be nice to provide an > option to skip that part. This is easy to solve by changing LOCKDIR to point to something you can access. You presumably are setting a custom configuration file to run as non-root (since you wont be able to read /etc/logcheck/logcheck.conf without sudo), and then that custom config file can change the location to /tmp or wherever. I think this already works in the version in bookworm, so perhaps we can close this bug
Bug#470608: work-around for logcheck email charset
On Sat, 16 May 2020 17:12:42 -0700 Wade Richards wrote: > This is regarding Debian bug #47608 "wrong charset in logcheck mail > (charset=unknown-8bit)" > > > The maintainer has closed this bug as 'wontfix', but if an end-user is > looking for a work-around, you can add the following to your > /etc/logcheck.conf file > > > # Additional args to mime-construct for sending email > > MIMECONSTRUCTARGS="$MINECONSTRUCTARGS --type 'text/plain; > charset=UTF-8'" > > > It's an undocumented option, so it may stop working with a future > version of logcheck, but it works for now. logcheck also has an option 'MIMEENCODING=' does that solve this issue?
Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats
On Sat, 18 Mar 2023 18:55:25 + Richard Lewis wrote: > On Sat, 18 Mar 2023, 15:12 Holger Levsen, wrote: > > > On Thu, Mar 16, 2023 at 06:00:06PM +, Holger Levsen wrote: > > > aaah, thanks! I only checked > > /usr/share/doc/logcheck/NEWS.Debian.gz > > > but not /usr/share/doc/logcheck-database/NEWS.Debian.gz > > > > now that I read it and followed the advice and the very nice > > sed example there, I can they that it worked flawlessly and was > > very easy to do. Thank you for that NEWS entry! > > > > > so maybe reassign this bug to src:release-notes? > > > > this question is still open... though maybe cloning the bug is even > > better, I'd really appreciated a small pointer to logcheck-database's NEWS > > file in the NEWS for logcheck... Think we may as well close this bug, unless anyone objects. bookworm release-notes cover the issue. Next big change im planning to document in logcheck's NEWS.Debian to catch all users - watch this space!
Bug#583600: ignore individual entries but write summaries
On Fri, 28 May 2010 19:04:17 +0200 Holger Levsen wrote: > I often add logcheck ignore rules for security related events (like ssh login > attemps. etc), cause they are too many and login is protected reasonably > anyway. > > But then I would like to get summaries for some ignored patterns, probably one > mail per host day. > > Do you think thats a reasonable feature request? This is already possible, maybe that's why no-one replied for 15 years. Simply create a command called syslog-summary and tell logcheck to use it (via the setting in logcheck.conf) Think we should close this bug on that basis it would be better to develop such a summarising programme outside logcheck as it's a whole other project to work out what to summarise, and how to present the results - you'd need a lot of flexibility to please everyone, i suspect. There was packaged version called syslog-summary some releases ago, but no-one maintained it and it was removed from Debian. but the code to use it remains in logcheck.
Bug#1070972: epiphany-browser fails to render webpages - blank pages
Package: epiphany-browser Version: 46.0-2 Severity: important X-Debbugs-Cc: bug.repor...@mail.sheugh.com Dear Maintainer, A previously installed debian system** was reconfigured via the intallation of debian-12-5 from a dvd. That 'bookworm' installation was updated to 'trixie' almost immediately, and additional packages, including epiphany-browser and konquerer browser were installed. On opening epiphany browser, as expected, six webpage tabs appeared, however the content of the pages was not rendered. These pages appeared to be blank. Moving the mouse over the pages showed that the webpage links were present. I did not explore further. A search on the internet suggested that libwebkitgtk might be a source of this problem. ** prior to the reconfiguration I had saved all the packages to a folder. In that folder I ran # sudo dpkg -i ./libwebkitgtk* This reported dpkg: warning: downgrading libwebkitgtk-6.0-4:amd64 from 2.44.1-1+b1 to 2.42.5-1 libwebkitgtk-6.0-4:amd64 depends on libjavascriptcoregtk-6.0-1 (= 2.42.5-1); I ran sudo dpkg -i ./libwebkitgtk* ./libjavascriptcoregtk-6.0-1* And got (Reading database ... 158748 files and directories currently installed.) Preparing to unpack .../libwebkitgtk-6.0-4_2.42.5-1_amd64.deb ... Unpacking libwebkitgtk-6.0-4:amd64 (2.42.5-1) over (2.42.5-1) ... dpkg: warning: downgrading libjavascriptcoregtk-6.0-1:amd64 from 2.44.1-1+b1 to 2.42.5-1 Preparing to unpack .../libjavascriptcoregtk-6.0-1_2.42.5-1_amd64.deb ... Unpacking libjavascriptcoregtk-6.0-1:amd64 (2.42.5-1) over (2.44.1-1+b1) ... Setting up libjavascriptcoregtk-6.0-1:amd64 (2.42.5-1) ... Setting up libwebkitgtk-6.0-4:amd64 (2.42.5-1) ... Processing triggers for libc-bin (2.38-7) ... The pages now appear as they should. HTH *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages epiphany-browser depends on: hi dbus-user-session [default-dbus-session-bus] 1.14.10-4+b1 hi epiphany-browser-data 46.0-2 hi gsettings-desktop-schemas 46.0-1 hi iso-codes 4.16.0-1 hi libadwaita-1-01.5.0-1 hi libarchive13t64 3.7.2-2 hi libc6 2.38-7 hi libcairo2 1.18.0-3+b1 hi libgck-2-24.2.0-5 hi libgcr-4-44.2.0-5 hi libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b3 hi libglib2.0-0t64 2.80.1-1 hi libgmp10 2:6.3.0+dfsg-2+b1 hi libgranite-7-77.4.0-1+b2 hi libgraphene-1.0-0 1.10.8-3+b1 hi libgstreamer1.0-0 1.24.3-1 hi libgtk-4-14.12.5+ds-6+b1 hi libhogweed6t643.9.1-2.2 ii libjavascriptcoregtk-6.0-12.42.5-1 hi libjson-glib-1.0-01.8.0-2+b1 hi libnettle8t64 3.9.1-2.2 hi libpango-1.0-01.52.2+ds-1 hi libportal-gtk4-1 0.7.1-5+b1 hi libportal10.7.1-5+b1 hi libsecret-1-0 0.21.4-1+b1 hi libsoup-3.0-0 3.4.4-5+b1 hi libsqlite3-0 3.45.3-1 ii libwebkitgtk-6.0-42.42.5-1 hi libxml2 2.9.14+dfsg-1.3+b3 Versions of packages epiphany-browser recommends: hi ca-certificates 20240203 hi evince 46.0-1+b1 hi yelp 42.2-1+b2 epiphany-browser suggests no packages. -- no debconf information
Bug#1070717: Acknowledgement (linux-image-6.7.12-amd64: Mediatek mt7921e WiFi fails connecting after hibernation since 6.7.12)
Addendum: this is the output of dmesg related to mt7921e that shows up when this happens: [Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7922_1.bin [Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: ASIC revision: 79220010 [Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: firmware: direct-loading firmware mediatek/WIFI_MT7922_patch_mcu_1_1_hdr.bin [Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20230530123154a [Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7922_1.bin [Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: WM Firmware Version: 00, Build Time: 20230530123236 [Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7922_1.bin [Th May 9 18:36:51 2024] [01;31m[Kmt7921e[m[K :01:00.0 wlp1s0: renamed from wlan0 [Fr May 10 09:53:01 2024] [01;31m[Kmt7921e[m[K :01:00.0: Message 00020007 (seq 8) timeout [Fr May 10 09:53:01 2024] [01;31m[Kmt7921e[m[K :01:00.0: PM: dpm_run_callback(): pci_pm_restore+0x0/0xe0 returns -110 [Fr May 10 09:53:01 2024] [01;31m[Kmt7921e[m[K :01:00.0: PM: failed to restore async: error -110 [Fr May 10 09:53:01 2024] [01;31m[Kmt7921e[m[K :01:00.0: Failed to get patch semaphore [Fr May 10 09:53:01 2024] [01;31m[Kmt7921e[m[K :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xffcec680 flags=0x] [Fr May 10 09:53:04 2024] [01;31m[Kmt7921e[m[K :01:00.0: Message 0010 (seq 6) timeout [Fr May 10 09:53:04 2024] [01;31m[Kmt7921e[m[K :01:00.0: Failed to get patch semaphore [Fr May 10 09:53:07 2024] [01;31m[Kmt7921e[m[K :01:00.0: Message 0010 (seq 7) timeout [Fr May 10 09:53:07 2024] [01;31m[Kmt7921e[m[K :01:00.0: Failed to get patch semaphore [Fr May 10 09:53:10 2024] [01;31m[Kmt7921e[m[K :01:00.0: Message 46ed (seq 8) timeout [Fr May 10 09:53:10 2024] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi tls uinput ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nf_tables typec_displayport qrtr bnep zstd zram tun binfmt_misc nls_ascii nls_cp437 vfat fat btusb btrtl btintel btbcm btmtk intel_rapl_msr intel_rapl_common bluetooth evdev joydev snd_sof_amd_rembrandt snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp snd_hda_codec_realtek snd_sof sha3_generic snd_hda_codec_generic jitterentropy_rng [01;31m[Kmt7921e[m[K snd_sof_utils mt7921_common ledtrig_audio uvcvideo edac_mce_amd mt792x_lib snd_hda_codec_hdmi snd_soc_core drbg mt76_connac_lib videobuf2_vmalloc uvc kvm_amd videobuf2_memops ansi_cprng snd_compress snd_hda_intel videobuf2_v4l2 mt76 snd_pcm_dmaengine hid_sensor_als videodev snd_intel_dspcfg hid_sensor_trigger ecdh_generic snd_intel_sdw_acpi ecc hid_sensor_iio_common snd_pci_ps kvm mac80211 snd_hda_codec crc16 videobuf2_common industrialio_triggered_buffer kfifo_buf snd_rpl_pci_acp6x irqbypass [Fr May 10 09:53:10 2024] [01;31m[Kmt7921e[m[K :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xff772a80 flags=0x] [Fr May 10 09:53:10 2024] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi tls uinput ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nf_tables typec_displayport qrtr bnep zstd zram tun binfmt_misc nls_ascii nls_cp437 vfat fat btusb btrtl btintel btbcm btmtk intel_rapl_msr intel_rapl_common bluetooth evdev joydev snd_sof_amd_rembrandt snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp snd_hda_codec_realtek snd_sof sha3_generic snd_hda_codec_generic jitterentropy_rng [01;31m[Kmt7921e[m[K snd_sof_utils mt7921_common ledtrig_audio uvcvideo edac_mce_amd mt792x_lib snd_hda_codec_hdmi snd_soc_core drbg mt76_connac_lib videobuf2_vmalloc uvc kvm_amd videobuf2_memops ansi_cprng snd_compress snd_hda_intel videobuf2_v4l2 mt76 snd_pcm_dmaengine hid_sensor_als videodev snd_intel_dspcfg hid_sensor_trigger ecdh_generic snd_intel_sdw_acpi ecc hid_sensor_iio_common snd_pci_ps kvm mac80211 snd_hda_codec crc16 videobuf2_common industrialio_triggered_buffer kfifo_buf snd_rpl_pci_acp6x irqbypass [Fr May 10 09:53:14 2024] [01;31m[Kmt7921e[m[K :01:00.0: Message 0010 (seq 9) timeout [Fr May 10 09:53:14 2024] [01;31m[Kmt7921e[m[K :01:00.0: Failed to get patch semaphore [Fr May 10 09:53:14 2024] [01;31m[Kmt7921e[m[K :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xffd79900 flags=0x] [Fr May 10 09:53:14 2024] [01;31m[Kmt7921e[m[K :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xffd79900 flags=0x] [Fr May 10 09:53:14 2024] [01;31m[Kmt7921e[m[K :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d
Bug#1063900: gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)
Hello. Upgrading gstreamer1.0-plugins-ugly to 1.24.3-1 on Trixie didn't produce the error that was originally reported. Here's my output: Retrieving bug reports... Done Parsing Found/Fixed information... Done serious bugs of gstreamer1.0-plugins-good (1.22.10-1 → 1.24.3-1) b1 - #1063900 - gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23) Merged with: 1063921 Summary: gstreamer1.0-plugins-good(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] y Reading changelogs... Done ... Preparing to unpack .../gstreamer1.0-plugins-good_1.24.3-1_amd64.deb ... Unpacking gstreamer1.0-plugins-good:amd64 (1.24.3-1) over (1.22.10-1) ... Preparing to unpack .../gstreamer1.0-plugins-bad_1.24.3-1_amd64.deb ... Unpacking gstreamer1.0-plugins-bad:amd64 (1.24.3-1) over (1.22.10-1) ... ... Preparing to unpack .../04-libgstreamer-plugins-bad1.0-0_1.24.3-1_amd64.deb ... Unpacking libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) over (1.22.10-1) ... Preparing to unpack .../05-gir1.2-gst-plugins-bad-1.0_1.24.3-1_amd64.deb ... Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) over (1.22.10-1) ... ... Setting up libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) ... Setting up gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) ... Setting up gstreamer1.0-plugins-good:amd64 (1.24.3-1) ... Setting up gstreamer1.0-plugins-bad:amd64 (1.24.3-1) ... Processing triggers for libc-bin (2.38-7) ... I see that the conflicting files mentioned are on my system, but that didn't seem to impact my upgrade: -rw-r--r-- 1 root root 27K Apr 30 04:18 /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so -rw-r--r-- 1 root root 19K Apr 30 04:18 /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so -rw-r--r-- 1 root root 208 Apr 29 18:15 /usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs gstreamer1.0-plugins-ugly was upgraded to a matching version before this. Here's what dpkg reports: ii gstreamer1.0-plugins-ugly:amd64 1.24.3-1 amd64 GStreamer plugins from the "ugly" set Best. Richard
Bug#1049972: Upstream issue
For links, this seems to be https://github.com/rdiff-backup/rdiff-backup/issues/616. Apparently it's expected behaviour.
Bug#1070717: linux-image-6.7.12-amd64: Mediatek mt7921e WiFi fails connecting after hibernation since 6.7.12
uot; operation="open" class="file" profile="libreoffice-soffice" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max" pid=6388 comm=433120436F6D70696C657254687265 requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [ 435.827462] kauditd_printk_skb: 23 callbacks suppressed [ 435.827471] audit: type=1400 audit(1715094303.003:543): apparmor="ALLOWED" operation="open" class="file" profile="libreoffice-soffice" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max" pid=6388 comm=433120436F6D70696C657254687265 requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [ 438.120605] audit: type=1400 audit(1715094305.295:544): apparmor="ALLOWED" operation="open" class="file" profile="libreoffice-soffice" name="/home/richard/.config/LanguageTool/LibreOffice/LanguageTool.log" pid=6388 comm="soffice.bin" requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000 [ 438.120658] audit: type=1400 audit(1715094305.295:545): apparmor="ALLOWED" operation="file_perm" class="file" profile="libreoffice-soffice" name="/home/richard/.config/LanguageTool/LibreOffice/LanguageTool.log" pid=6388 comm="soffice.bin" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 [ 804.953714] i2c_hid_acpi i2c-FRMW0003:00: i2c_hid_get_input: incomplete report (7/65535) [ 1121.046255] usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd [ 1121.265790] usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd [ 2531.546014] usb 1-2.1: new high-speed USB device number 9 using xhci_hcd [ 2531.683091] usb 1-2.1: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02 [ 2531.683100] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2531.683104] usb 1-2.1: Product: Audio Expansion Card [ 2531.683107] usb 1-2.1: Manufacturer: Framework [ 2531.742937] input: Framework Audio Expansion Card Consumer Control as /devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/1-2.1/1-2.1:1.2/0003:32AC:0010.0008/input/input18 [ 2531.802301] hid-generic 0003:32AC:0010.0008: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-:c1:00.3-2.1/input2 [ 2532.064766] usbcore: registered new interface driver snd-usb-audio [ 2532.085724] input: Framework Audio Expansion Card Consumer Control as /devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/1-2.1/1-2.1:1.2/0003:32AC:0010.0009/input/input19 [ 2532.142241] hid-generic 0003:32AC:0010.0009: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-:c1:00.3-2.1/input2 [ 2540.147902] MediaPD~oder #1[62983]: segfault at 60 ip 7fe017d0b2dd sp 7fe038ffce20 error 4 in libLLVM-16.so.1[7fe01520+6d26000] likely on CPU 15 (core 7, socket 0) [ 2540.147919] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24 40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24 48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49 [ 2578.200646] MediaPD~oder #1[64518]: segfault at 60 ip 7fe016b0b2dd sp 7fe03a367e20 error 4 in libLLVM-16.so.1[7fe01400+6d26000] likely on CPU 5 (core 2, socket 0) [ 2578.200671] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24 40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24 48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49 [ 2959.977573] MediaPD~oder #1[81449]: segfault at 60 ip 7fe01750b2dd sp 7fe03a367e20 error 4 in libLLVM-16.so.1[7fe014a0+6d26000] likely on CPU 2 (core 1, socket 0) [ 2959.977598] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24 40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24 48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49 [ 2974.055589] MediaPD~oder #2[81490]: segfault at 60 ip 7fe012f0b2dd sp 7fe038efce20 error 4 in libLLVM-16.so.1[7fe01040+6d26000] likely on CPU 8 (core 4, socket 0) [ 2974.055603] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24 40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24 48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49 [ 3208.859075] audit: type=1400 audit(1715097075.994:546): apparmor="DENIED" operation="open" class="file" profile="torbrowser_firefox" name="/usr/local/lib/x86_64-linux-gnu/libEGL.so.1.0.0" pid=87874 comm="glxtest" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 3208.861128] audit: type=1400 audit(1715097075.994:547): apparmor="DENIED" operation="open" class=&quo
Bug#1070671: Please include static library builds in libharfbuzz-dev
Package: libharfbuzz-dev Version: 8.3.0-2+b1 It is customary for -dev packages to provide static archive libraries in addition to the bare .so files for shared-library linking. The current version of libharfbuzz-dev only provides the latter, and thus does not allow applications to statically link the libraries. I understand that GObject introspection requires a shared-library build, but this functionality is often not needed. In particular, the Chromium browser consumes harfbuzz and harfbuzz-subset, and does perfectly well without introspection support. I recently ran into a situation on the Ubuntu side of things where the lack of a static-linking option caused some difficulty in supporting Chromium on 22.04/jammy: https://bugs.launchpad.net/bugs/2064821 My solution was to produce a modified harfbuzz package that provides (only) static libraries: https://launchpad.net/~xtradeb/+archive/ubuntu/deps/+sourcepub/16120809/+listing-archive-extra Needless to say, it would be preferable if the official packages supported static linking from the get-go.
Bug#1070669: Please include a static library build in libdav1d-dev
Package: libdav1d-dev Version: 1.4.1-1 It is customary for -dev packages to provide a static archive library in addition to the bare .so file for shared-library linking. The current version of libdav1d-dev only provides the latter, and thus does not allow applications to statically link the library.
Bug#1070483: btrfs root volume being mounted as ro upon boot
Package: installation-reports Severity: important Boot method: USB stick Image version: https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-gnome.iso Date: 19.04.2024 Machine: Framework 16 Processor: AMD Ryzen 7 7840HS w/ Radeon 780M Graphics Memory: 2 x 16 GB Crucial DDR5 5600MHz Partitions: from lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS zram0 252:0 0 8,2G 0 disk [SWAP] nvme0n1 259:0 0 3,6T 0 disk ├─nvme0n1p1 259:1 0 2G 0 part /boot/efi ├─nvme0n1p2 259:2 0 35G 0 part │ └─luks- 253:1 0 35G 0 crypt [SWAP] └─nvme0n1p3 259:3 0 3,6T 0 part └─luks- 253:0 0 3,6T 0 crypt /home / Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14e8] Subsystem: Framework Computer Inc. Device [f111:0005] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device [1022:14e9] Subsystem: Framework Computer Inc. Device [f111:0005] 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ea] 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ea] 00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ee] Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453] Kernel driver in use: pcieport 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ee] Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453] Kernel driver in use: pcieport 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ea] 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel [1022:14ef] Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453] Kernel driver in use: pcieport 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ea] 00:04.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel [1022:14ef] Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453] Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ea] 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:14eb] Subsystem: Device [0005:f111] Kernel driver in use: pcieport 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:14eb] Subsystem: Device [0005:f111] Kernel driver in use: pcieport 00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:14eb] pcilib: Error reading /sys/bus/pci/devices/:00:08.3/label: Operation not permitted Subsystem: Device [0005:f111] Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 71) Subsystem: Framework Computer Inc. Device [f111:0005] Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4, sp5100_tco 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) Subsystem: Framework Computer Inc. Device [f111:0005] 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f0] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f1] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f2] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f3] Kernel driver in use: k10temp Kernel modules: k10temp 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f4] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f5] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f6] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14f7] 01:00.0 Network controller [0280]: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:0616] Subsystem: MEDIATEK Corp. Device [14c3:e616] Kernel driver in use: mt7921e Kernel modules: mt7921e 02:00.0 Non-Volatile memory controller [0108]: Sandisk Corp WD Black SN850X NVMe SSD [15b7:5030] (rev 01) Subsystem: Sandisk Corp WD Black SN850X NVMe SSD [15b7:5030] Kernel driver in use: nvme Kernel modules: nvme c1:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf] (rev c2) Subsystem: Framework Computer Inc. Device [f111:0005] Kernel driver in use: amdgpu Kernel modules: amdgpu c1:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller [1002:1640] Subsystem: Framework Computer Inc. Device [f111:0005]
Bug#1070281: logcheck: becomes less and less usable because of user-level logs
On Fri, 3 May 2024, 12:44 Francesco Potortì, wrote: > > > One cure would be to have logcheck ignore user-level messages, and only > care about system-level ones. Is that possible? > > > >maybe it is possible - how do you define "system-level message"? > > Those created by root-owned processes, that would be a good start. I > definitely care about Sshd messages, much less about Gvfsd ones, and even > less by those generated by Telegram running over Snapd. For some reason, > the problem has vastly increased after the advent of systemctl. The options seem to be 1.you make a local rule that ignores all messages from known culprets -- so you might jusy want to do a version of "^timestamp hostname (Telegram|gvfsd)". This works today, but does need you to know what you want to ignore 2.you tell logcheck to.not check the journal at all - also possoble today: simply remove "journal" from the file in /etc/logcheck/logcheck.logfiles.d (i dont know if this is that helpful!) 3. i have work in progress to allow you to tell logcheck to only check a subset of the journal by passif arguments to journalctl. Looking at the journalctl.man-page: --unit ssh.service will only show messages from ssh eg --system might exclude things like telegram (untested!) eg --priority might also be helpful eg _UID=0 might select only things run by root (but that would probably exclude things run by special users like apache) eg --priority might also help? This needs a small change in logcheck to make JOURNALCTL_OPTS settable from the config file - this is WiP already! (logcheck currently hardcoded this to an empty array) other thoughts: - we could definitely make logcheck only report the first N lines. I can broadly see how to implement this. you can almost do this today by making a "syslog-summary" script!
Bug#1070436: autopkgtest-virt-schroot: error when using 'unshare --net' even though schroot allows this
control: close 1070436 thanks On Sun, 5 May 2024, 19:10 Jochen Sprickerhof, wrote: > Hi Richard, > > * Richard Lewis [2024-05-05 11:32]: > >If i try and run tests that use 'unshare --net' with a > >schroot backend they fail inside autopkgtest even though > >this works in the schroot being used. > > > >This works fine in a 'plain schroot' (I expect i allowed > >the calling user to run the schroot as root in the schroot > >in /etc/schroot): > > > > $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user > root -- unshare --net --map-root-user ls > > bin boot build dev etc home lib lib64 media mnt opt proc > root run sbin srv sys tmp usr var > > I can't reproduce this. Testing in a fresh debvm: > > $ debvm-create --size=2G --release=stable -- \ > --include=sbuild,schroot,debootstrap,autopkgtest \ > --hook-dir=/usr/share/mmdebstrap/hooks/useradd > $ debvm-run > # echo "inside debvm" > # sbuild-createchroot unstable /srv/chroot/unstable-amd64-sbuild \ > http://deb.debian.org/debian > # sbuild-adduser user > # su - user > $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root > -- unshare --net --map-root-user ls > unshare: unshare failed: Operation not permitted > > Do you have any idea why it works for you? > im so sorry - this was just a complete user error by me. the issue is the --map-root-user, i thought absolutely sure i was using that with plain schroot, but it turns out i was completely misreading what i was running, and apparently copied the command and output from separate places. as you say, if i omit map-root-user then it works with both schroot and autopkgtest. and if i include map-root-user then both fail. Over all I think using unshare --map-root-user in > autopkgtest-virt-schroot is not supported and I don't think there is a > way around that except using a different autopkgtest backend. thanks - this is fair enough. thanks for the response. and sorry for the noise
Bug#1070440: mesa-va-drivers: vaapi cannot find target for triple amdgcn
Package: mesa-va-drivers Version: 24.0.6-1+b1 Severity: important Dear Maintainer, I'm not sure if this is the right package to report this issue to, as there recently have been many package updates due to the time_t transition. But mpv, VLC and Firefox are no longer able to access VA-API while ffmpeg shows stranger behavior. I can't say for sure when this breakage happened since Firefox is gracefully falling back to software decoding and I rarely use mpv or VLC, which just fail to start (even though mpv has the option hwdec=auto-safe set which should cause the same behavior as in Firefox. mpv gives this quite ominous error message: Cannot load libcuda.so.1 Cannot find target for triple amdgcn-- Unable to find target for this triple (no targets are registered) Segmentation fault That it can't load anything Nvidia related is no surprise, I'm on an AMD Ryzen 7 7840HS without any dGPU. Firmware is installed directly from kerne.org as the one in Debians repos is way too old. VLC goes into a little more detail: libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_20 Cannot find target for triple amdgcn-- Unable to find target for this triple (no targets are registered) Segmentation fault Firefox is even more verbose: [RDD 9113: MediaSupervisor #1]: D/FFmpegVideo FFVPX: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/av1 Codec ID 226 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Initialising VA-API FFmpeg decoder [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 : Alliance for Open Media AV1 libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: FFmpegVideoDecoder::GetAcceleratedFormats() [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Profile H264ConstrainedBaseline: [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format p010le 3 15 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Profile H264Main: [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format p010le 3 15 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Profile H264High: [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format p010le 3 15 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Profile VP9Profile0: [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec vp9 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Profile VP9Profile2: [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec vp9 format p010le 3 15 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: vp9 target pixel format is not supported! [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Profile AV1Profile0: [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format p010le 3 15 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format nv12 3 12 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format p010le 3 15 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Supported accelerated formats: [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: h264 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: vp9 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: av1 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: VA-API FFmpeg init successful [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: FFmpegDataDecoder: shutdown [RDD 9113: MediaSupervisor #1]: D/FFmpegVideo FFVPX: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/av1 Codec ID 226 [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Initialising VA-API FFmpeg decoder [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Format av1 is accelerated [RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 : Alliance for Open Media AV1 [AVHWDeviceContext @ 0x7f5a31931340] Format 0x3231564e -> nv12. [AVHWDeviceContext @ 0x7f5a31931340] Format 0x30313050 -> p010le. [AVHWDeviceContext @ 0x7f5a31931340] Format 0x36313050 -> unknown. [AVHWDeviceContext @ 0x7f5a31931340] Format 0x30323449 -> yuv420p. [AVHWDeviceContext @ 0x7f5a31931340] Format 0x32315659 ->
Bug#1070436: autopkgtest-virt-schroot: error when using 'unshare --net' even though schroot allows this
Package: autopkgtest Version: 5.28 Severity: normal X-Debbugs-Cc: richard.lewis.deb...@googlemail.com Dear Maintainer, If i try and run tests that use 'unshare --net' with a schroot backend they fail inside autopkgtest even though this works in the schroot being used. This works fine in a 'plain schroot' (I expect i allowed the calling user to run the schroot as root in the schroot in /etc/schroot): $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root -- unshare --net --map-root-user ls bin boot build dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var But if i have an autopkgtest with eg a debian/tests/control with Test-Command: unshare --map-root-user --net ./debian/tests/foo Depends: @ Features: test-name=foo Restrictions: needs-root then even adding '--user root' doesnt work: $ /usr/bin/autopkgtest package.changes --user root -- schroot unstable-amd64-sbuild i get errors like unshare: unshare failed: Operation not permitted Same if i put the unshare call inside the test What am I doing wrong? -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 autopkgtest depends on: ii apt-utils 2.6.1 ii libdpkg-perl1.21.22 ii procps 2:4.0.2-3 ii python3 3.11.2-1+b1 ii python3-debian 0.1.49 Versions of packages autopkgtest recommends: ii autodep8 0.28 ii fakeroot 1.31-1.2 Versions of packages autopkgtest suggests: pn docker.io pn fakemachine ii lxc 1:5.0.2-1+deb12u2 pn lxd pn ovmf pn ovmf-ia32 pn podman ii python3-distro-info 1.5+deb12u1 pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils 1:7.2+dfsg-7+deb12u5 ii schroot 1.6.13-3+b2 ii util-linux 2.38.1-5+deb12u1 pn vmdb2 pn zerofree -- no debconf information
Bug#1070281: logcheck: becomes less and less usable because of user-level logs
control: reassign -1 logcheck-database thanks (this is mostly about logcheck-database) On Fri, 3 May 2024, 09:39 Francesco Potortì, wrote: > > > Starting maybe a couple years ago, logcheck spits an amount of stuff that > has now become unamnageable. logcheck-database was mostly dormant sround that time. im hoping to improve that, but it is a big task and needs some wider improvements. So: please bear with it! While in the beginning logs were relevant to the system, which is what I > want, now any bug in a user-level daemon writing info to the syslog or to > the systemsctl thing makes havoc. i sympathise however: - a bug in a daemon should ideally be reported and fixed in the daemon - this may include logging "too much" -- i would suggest discussing with upstream as they may be open to improvements - you didnt give any examples so not sure how anyone can help you I had many email tens of megabytes long. (there's already a request to split the report if it is long) In the last month, reports have been completely useless to me as they are > filled with useless things and I am busy adding local rules to remove them > > Now I have reached a point where its usefulness is negative: I spend more > time adding rules than it is worth for me getting the info. > i sympathise - but writing local rules is always going to be needed. i think we can do much better than what we have, but realistically it is hard to do in this way. If.you wanted to chamge the world, get upstream authors to agree some standard where messges are easier to identify as routine and then logcheck could more easily ignore that. i wont hold my breath for thay > One cure would be to have logcheck ignore user-level messages, and only > care about system-level ones. Is that possible? > maybe it is possible - how do you define "system-level message"?
Bug#1070152: chkrootkit: duplicate line from ifpromisc
On Thu, 2 May 2024, 03:45 Vincent Lefevre, wrote: > On 2024-05-01 19:05:06 +0100, Richard Lewis wrote: > > I agree that you should be able to filter out duplicate lines. And i > think > > this is possible with a custom filter. > > Yes, but "sed" may not be the best tool for that. With sed, removing > lines containing only the usual network managers is easier. > you dont have to use sed, you can set anything. id use awk or sort. but then you dont know if things have disappeared. > > I dont think it should be the default - most chkrootkit users have a more > > static network setup, > > If they have a static network setup, why hiding the interface name? > i believe this was because if you have multiple interfaces they may not have static names (in the days where these were eth0 vs eth1 ) and because eg dhcpcd was set up to listen on eth0 and wlan0 even if eth0 wasnt used. maybe some of these assumptions are out of date? Doing that makes the output more confusing, and the replacement of > an interface by another one would not be detected. > > > and the alert shows something has changed. For laptops where > > networking is more dynamic it's hard to design something that works > > for everyone without also hiding information for other people. > > But are lines containing *only* the usual network managers suspicious? no, but it is suspicious is anything changed. Please also see the manpage which tells you how to use -s to remove these lines. The config file can easily be used to use -s each time.
Bug#1015201: logcheck: Update patterns, here: rsyslogd
lOn Mon, 29 Apr 2024, 14:19 Helge Kreutzmann, wrote:
> Am Sat, Apr 27, 2024 at 07:11:40PM +0100 schrieb Richard Lewis:
> > On Sun, 17 Jul 2022 17:28:11 +0100 Richard Lewis
> > wrote:
>
> > Hi Helge. Apologies no-one has replied to this bug report for 2 years
> > and that this response isnt going to be what you want!
>
> Thanks for taking care of it anyhow, I noticed that it is not worth
> reporting improvements to logcheck proper.
>
i hope to convince you otherwise! pleae report issues again!
>
> > debian usually doesnt add rules to filter startup messages as it tends
> > to add a lot of rules
>
> Indeed, startup rules are quite helpful, because then I see what was
> *different* during startup, i.e. if something got wrong.
totally agree
For servers,
> this is not very useful, but for workstatins it is. Btw., the current
> rules also deal with startup:
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: imklog [0-9.]+, log source =
> /proc/kmsg started.$
>
i think that practice and theory have diverged here! or possibly this
is/was produced when logs are rotated.
Bug#1070152: chkrootkit: duplicate line from ifpromisc
On Wed, 1 May 2024, 00:57 Vincent Lefevre, wrote:
> On 2024-05-01 01:29:10 +0200, Vincent Lefevre wrote:
> > For instance, /var/log/chkrootkit/log.expected contains
> >
> > WARNING: Output from ifpromisc:
> > lo: not promisc and no packet sniffer sockets
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> >
> > But /var/log/chkrootkit/log.today currently has a duplicate line:
> >
> > WARNING: Output from ifpromisc:
> > lo: not promisc and no packet sniffer sockets
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> >
> > which has the effect to generate an alert.
>
> This is actually due to the filter in /etc/chkrootkit/chkrootkit.conf,
> which obfuscates the output.
>
> The unfiltered output:
>
> lo: not promisc and no packet sniffer sockets
> eth0: PACKET SNIFFER(/usr/sbin/NetworkManager[1261])
> wlp0s20f3: PACKET SNIFFER(/usr/sbin/NetworkManager[1261],
> /usr/sbin/wpa_supplicant[1263])
>
> But for a laptop, there is not always an Ethernet cable plugged in.
>
> IMHO, known packet sniffers should be filtered out.
>
I agree that you should be able to filter out duplicate lines. And i think
this is possible with a custom filter.
I dont think it should be the default - most chkrootkit users have a more
static network setup, and the alert shows something has changed. For
laptops where networking is more dynamic it's hard to design something that
works for everyone without also hiding information for other people.
I think the defaults need to be conservative, while allowing people to hide
what they want.
Maybe the best solution is to provide more docs/examples about how to hide
duplicate lines.
Bug#1068161: Video playback regression
Hi Andres, On Tue, 2024 Apr 30 02:42-04:00, Andres Salomon wrote: > Please let me know if this is still broken with chromium 124. I'm happy to report that the issue appears to be resolved in the current 124.0.6367.78-1~deb12u1. (I did not test 124.0.6367.60.) Some additional info that I meant to send in earlier: * I was able to work around the problem in 123 with "--use-gl=egl". Even now, with 124, I get "MESA: error: Out of instructions" messages on the terminal when this flag is removed (but video now works either way). * The video adapter is listed as a "VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2]", on a Lenovo ThinkPad. * This is a different and much older bug, but I've observed that some Web sites show visual artifacts in chromium on this particular system, and --use-gl=egl also cleared those up. I think the issue may be that the driver for this specific hardware is buggy, and affected users are better off using the alternate GL implementation. (I can provide more details if this is of interest.)
Bug#1070109: fakechroot: apt crashes inside fakechroot
Package: fakechroot Version: 2.20.1+ds-17 Severity: important X-Debbugs-Cc: ri...@paraeasy.ch Dear Maintainer, We use fakechroot for building a live OS that starts out with debootstrap. This worked fine for a while, but started to fail last week. Now apt crashes when it ties to download anything: https://github.com/AminaBank/livedeb/blob/master/Dockerfile#L85 => ERROR [stage-8 4/30] RUN fakechroot chroot ROOTFS apt-get update && fakechroot chroot ROOTFS a 1.2s -- > [stage-8 4/30] RUN fakechroot chroot ROOTFS apt-get update && fakechroot > chroot ROOTFS apt-get -y dist-upgrade && fakechroot chroot ROOTFS apt-get > install -y --no-install-recommends curldosfstools electrum fdisk > firefox-esr fonts-freefont-ttf fonts-noto-mono keepassxc > libgl1 libglib2.0-0libykpiv2 minicom mousepad > mtools openssh-client p7zip-full pcscdpython3-pyqt5 > systemd-resolvedsystemd-timesyncd thunar-archive-plugin > xarchiver xfce4 xfce4-terminal xinit xserver-xorg > yubikey-manager: #9 0.613 Reading package lists... #9 1.059 E: Method http has died unexpectedly! #9 1.059 E: Sub-process http received a segmentation fault. #9 1.059 E: Method /usr/lib/apt/methods/http did not start correctly #9 1.059 E: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease #9 1.059 E: Some index files failed to download. They have been ignored, or old ones used instead. I don't know where the problem really lies, but when I buil an older version, where fakechroot was not used, then it builds just fine: https://github.com/AminaBank/livedeb/blob/b38de278e45f0175f5d9c5fc39716a4e31eda6c3/Dockerfile#L37 The first version that uses fakechroot generates a slightly different error messages, but also at about the same place: https://github.com/AminaBank/livedeb/blob/e22eda84c67643da13d46cb56a24e1eb47fdbfcd/Dockerfile#L57 Step 11/50 : RUN fakechroot chroot ROOTFS apt-get update ---> Running in 9f203eea9b98 *** stack smashing detected ***: terminated Aborted (core dumped) The command '/bin/sh -c fakechroot chroot ROOTFS apt-get update' returned a non-zero code: 134 I am reporting this from my trixie system, but the same happens on bookworm systems, and bookworm is used inside the relevant Docker container. -- System Information: Debian Release: bookworm/trixie/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fakechroot depends on: ii binutils 2.42-4 ii libfakechroot 2.20.1+ds-17 fakechroot recommends no packages. fakechroot suggests no packages. -- no debconf information
Bug#409444: logcheck: ignore "last line repeated $n times" if prevline matched
On Sat, 03 Feb 2007 10:29:38 +0100 Jonas Koelker wrote: > I (think I) want to see how many times the messages I care about are > repeated. This means I can't ignore "last line repeated $n times" > messages (obviously). But since those can also occur after messages > that are ignored, I can't _not_ ignore them either. So, I lose. > rsyslog has disabled the "feature" which produces this message, see https://www.rsyslog.com/doc/configuration/action/rsconf1_repeatedmsgreduction.html so this bug from 2007 can, i think, be closed.
Bug#690608: logcheck-database: consider to add ignore.d.server/rrdcached
On Tue, 16 Oct 2012 03:14:20 +0200 Sebastian Steinhuber
wrote:
> Dear Maintainer,
> to drop (slightly boring) messages from the package rrdcached of the
> form:
> Oct 15 22:59:29 dds rrdcached[12045]: flushing old values
>
> I added a file named ignore.d.server/rrdcached, containing the line:
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rrdcached\[[0-9]+\]: flushing
> old values$
Hi Sebastian,
over a decade ago you reported the above bug against
logcheck-database: im sorry no-one replied before today!
Is this rule still valid? im thinking things may have moved on, and
wondering if the bug is still valid.
Bug#442244: [Logcheck-devel] Bug#442244: logcheck-database: should include the filters from cyrus-imapd-2.2
On Fri, 14 Sep 2007 14:06:58 +0200 martin f krafft wrote: > also sprach Alex Prinsier [2007.09.14.1344 > +0200]: > > Please copy over the filters from cyrus-imapd-2.2. I'm running > > logcheck on a loghost, which doesn't run cyrus itself. There might > > be a better alternative to copying the file, but anyhow it should > > be in logcheck-database. > logcheck is not designed to be run on a loghost, really. I know it > would be nice, but it's not the general use case. You'll fare best > if you copy the file over, or simply install the cyrus-imapd-2.2 > package on the loghost and disable all services. > I am tempted to close this bug from 2007: - No-one has objected to the above two paragraphs since 2007, over a decade ago - The design of logcheck is that rules can be installed by packages and logcheck-database should not duplicate that, and it would risk file conflicts and out of date files. - People who want to run logcheck on a "loghost" can copy the rules - for example from sources.debian.org or salsa.debian.org HOWEVER: maybe this bug has value as it suggests that the logcheck ignore.d.serve/cyrus rules should actually be deleted: apt-file search cyrus | grep logcheck cyrus-common: /etc/logcheck/ignore.d.server/cyrus-imapd cyrus-common: /etc/logcheck/violations.ignore.d/cyrus-common cyrus-common: /etc/logcheck/violations.ignore.d/cyrus-imapd logcheck-database: /etc/logcheck/ignore.d.server/cyrus
Bug#588312: [Logcheck-devel] Bug#588312: logcheck-database: updated rules for many packages
Closing this bug from 2010 (14 years ago!) -- the then-maintainer
found that most of the suggestions were either already present or
should not actually be added, for various reasons.
A requested was made to resubmit as more independent bugs - if that
was done, we dont need this bug, and if not that suggests there is no
interest in proceeding.
Either way, the best thing seems to be to close this bug. Please
reopen with updated rules, if needd
On Thu, 08 Jul 2010 13:58:47 +0200 Hannes von Haugwitz
wrote:
> Hi,
>
> Like Gerfried said, please file different bug reports for different
> packages the next time.
>
> Some comments about your rule suggestions:
>
> Radosław Antoniuk wrote:
> >> #dkimproxy
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: connect from
> >> .*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: DKIM signing -
> >> signed; .*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: DKIM signing -
> >> skipped; .*$
> >
> > No rules at all.
> >
> >
> > Jul 7 12:39:21 hosting dkimproxy.out[1508]: DKIM signing - skipped;
> > message-id=,
> > from=
> > Jul 7 12:39:21 hosting dkimproxy.out[1508]: DKIM signing - signed;
> > message-id=,
> > from=
> > Jul 7 12:39:21 hosting dkimproxy.out[1508]: connect from 127.0.0.1
> >
>
> I don't see the need of wildchar .* here.
>
> >
> >> #ssh
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+\]: error writing
> >> /proc/self/oom_adj: Operation not permitted$
> >
> > Not there.
> >
>
> Looks like an error for me, maybe #555625?
>
> >> #ntp
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ ntpd\[[0-9]+\]: kernel time sync status
> >> change 4001
> >
> > No config at all
> >
>
> This message shouldn't occur anymore (see #498992).
>
> >
> >> #syslog-ng
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslog-ng\[[0-9]+\]: Log statistics;.*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslog-ng\[[0-9]+\]: Configuration
> >> reload request received, reloading configuration;$
> >
> >
> > syslog-ng[31823]: Log statistics; processed='destination(d_error)=3',
> > processed='destination(d_messages)=298',
> > processed='src.internal(s_src#1)=90',
> > stamp='src.internal(s_src#1)=1278499023',
> > processed='destination(d_syslog)=90', processed='center(received)=0',
> > processed='destination(d_xconsole)=3',
> > processed='destination(d_newscrit)=0',
> > processed='destination(d_auth)=1452',
> > processed='destination(d_daemon)=1',
> > processed='global(payload_reallocs)=0',
Bug#511483: logcheck-database: please add rules for rkhunter
package: logcheck-database # think it's reasonable to add rkhunter rules - although the ones in this bug need updates severity 511483 normal tags 511481 - wontfix
Bug#592365: logcheck: ignore rules for transmission-daemon
On Tue, 10 Aug 2010 10:28:54 +1000 Nemo wrote:
> > ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+
> > transmission-daemon\[[[:digit:]]+\]: Saved
> > "/var/lib/transmission-daemon/info/.*" \(bencode.c:1651\)$
> > ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ transmission-daemon\[[0-9]+\]: .* DHT
> > announce .*\(tr-dht.c:(669|637)\)$
Hi Nemo, in 14 years ago you reported a bug against logcheck-database
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592365 -
I believe you suggested that the above be added to logcheck.
It;s a shame no-one ever replied to you - let me at least try now:
Are these rules still needed for transmission-daemon? I imagine there
may have been several changes to message formats since then.
Bug#1015201: logcheck: Update patterns, here: rsyslogd
On Sun, 17 Jul 2022 17:28:11 +0100 Richard Lewis
wrote:
> > The pattern for rsyslogd can be improved. Please add the following
> > line:
> >
> > imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' \(fd 3\) from
> > systemd. \[v8.2206.0\]
> >
> > You might want to generalize the fd (on my system it is always fd 3,
> > but I don't know if this is general) and possibly the version number;
> > ideally this would remain in sync to whatever is in testing.
>
> I have the following rules in etc/logcheck/ignore.d.server/local-rsyslog
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ systemd\[1\]: rsyslog\.service:
> Sent signal SIGHUP to main process [0-9]+ \(rsyslogd\) on client
> request\.$
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd\[[0-9]+\]: \[origin
> software="rsyslogd" swVersion="[0-9.]+" x-pid="[0-9]+"
> x-info="https://www.rsyslog.com"\] rsyslogd was HUPed$
>
> so you might like to add those too. (i believe these are caused by
> logrotate via /usr/lib/rsyslog/rsyslog-rotate , the latter being part
> of rsyslog). they are relevant to bullseye systems
Hi Helge. Apologies no-one has replied to this bug report for 2 years
and that this response isnt going to be what you want!
The rules for rsyslog are actually provided by rsyslog not
logcheck-database so this bug should be against rsyslog --
however, im not sure rsyslog produces those messages about HUP any
more so maybe it should be closed rather than reassigned?
I do see the one about the unix socket but
a) i wonder if that's a bug rather that should be hidden?
b) I also think i only see it "startup" (ie only produced when the
system boots / service starts):
debian usually doesnt add rules to filter startup messages as it tends
to add a lot of rules
(apologies if i am wrong on this - i dont usually have rsyslog
installed, but ve been running it in a container for testing some
upcoming changes to logcheck and
i don't see either of the messages above despite running for several days).
Bug#532719: [Logcheck-devel] Bug#532719: additional sample
On Tue, 16 Jun 2009 11:27:57 -0700 Russ Allbery wrote: > chrysn writes: > touch /etc/default/locale will also make these go away with no behavior > changes. In my experience, it happens on systems upgraded from older > versions of Debian but not with new installs. I think this is more a > bug or misconfiguration than something that logcheck really should be > filtering out. For the reason given above in 2009 im closing this bug asking to filter a message about a missing locale: debian installs a locale by defuault and not having one is unusual: if the file disappeared most people would want to know about it, so logcheck should be reporting it. people who want to have a system without a locale set (assuming that is even still possible - and why not just set it to C?) can of course add a local rule to filter the message, but i see no case for hiding this message by default. Therefore, closing this bug. If there's some case im missing, it can be reopened of couse
Bug#510472: logcheck-database: pam_unix messages could be ignored.
On Tue, 18 Aug 2009 20:24:31 -0400 =?iso-8859-1?B?RnLpZOlyaWMgQnJp6HJl?= wrote: > On Fri, Jan 02, 2009 at 10:21:51AM +0100, Jan Evert van Grootheest wrote: > > Package: logcheck-database > > Version: 1.2.68 > > > > It has now started to spam the logs with lots of > > Jan 2 09:22:57 sisko sshd[28511]: pam_unix(sshd:auth): authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= > > rhost=host92-22-static.38-79-b.business.telecomitalia.it user=root > > This is a duplicate of #70, which was fixed a while ago. (The fix > was actually part of 1.2.64, so I'm assuming you filed this report from > a different machine.) > > > And on another system the same is happening for imapd. > > Are we talking about cyrus-imapd-2.2? Could you provide an example? This bug is from 2009, and has been tagged moreinfo for much of that time: i fear the world has moved on: - logcheck-database filters messages from pam for successful login - most people would want to know about authentication failures, especially since root is not allowed to ssh in by default these days - those that get too many authentication failures can and should add their local rule, but i dont see a case to filter such methods by default - there isnt really anything actionable in this report anyway Therefore: closing it - anyone is feel free to reopen!
Bug#590684: [logcheck-database] rules for rsyslog
On Mon, 02 Aug 2010 10:29:03 +0200 Hannes von Haugwitz
wrote:
> > ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rsyslogd: \[origin
> > software="rsyslogd" swVersion="3.18.6" x-pid="[[:digit:]]+"
> > x-info="http://www.rsyslog.com"\] restart$
>
> Daemon restart messages are willingly not included in logcheck-database.
>
> So I tag this bug as wontfix.
I think we can actually close this bug 14-year old bug: rsyslog
provides its own rules for logcheck and those rules do cover the
startup message (which has changed since the report).
Bug#1069777: initramfs-tools: Bug/feature request: better handling of /etc/crypttab not ending in new line character
Package: initramfs-tools Version: 0.142 Severity: wishlist Dear Maintainer, I'm not sure if this is a bug that should be fixed or a feature request for better error handling. I noticed by accident, that when /etc/crypttab ends in the line of the last entry and not a new line character, update-initramfs just ignores the last line and says it couldn't find that device in /etc/crypttab. Either the tool should be able to just handle this rather simple case or at least give a proper error message. Or whatever would make it more obvious for the user what actually the error is as the existing error message is quite misleading. Best Richard
Bug#1069697: lintian: debian-changelog-line-too-short CVEs
On Tue, 23 Apr 2024, 00:12 Thorsten Glaser, wrote: > P: openjdk-8-doc: debian-changelog-line-too-short CVEs > [usr/share/doc/openjdk-8-doc/changelog.Debian.gz:4] > > The changelog in question is: > > * New upstream release > * CVEs > - CVE-2024-21011 > - CVE-2024-21085 > - CVE-2024-21068 > - CVE-2024-21094 > * Security fixes > […] > > I find this a little opinionated anyway, but here not quite > appropriate as the changelog “line” spans more than a physical > line. Maybe, if you won’t consider the space until the next > /^ \* / a “line”, then at least exclude itemisations from that tag? > would it make a difference if the somewhat ambiguous line "CVEs" was changed to "Fixes the following CVEs:" ?
Bug#1052714: firmware-amd-graphics: Missing firmware for AMD Radeon RX 7000 series cards
I'd also like to support this. The current firmware-amd-graphics is getting close to being a year old. While of course the Stable branch won't get up-to-date firmware as that's not the point of firmware, I don't see a reason at least sid or an experimental branch shouldn't be kept more up-to-date. And I don't really see a reason why that shouldn't be the case for testing and stable-updates or stable-backports too. E.g., a Ryzen 7040's iGPU can't be handled by the 06/2023 firmware package, it will complain that "amdgpu/gc_11_0_1_me" couldn't be loaded. With at least the 09/2023 firmware that's not an issue anymore. Greetings, Richard
Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile
On Thu, 18 Apr 2024, 23:18 Santiago Vila, wrote: > El 18/4/24 a las 22:17, Richard Lewis escribió: > >>> '^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$' > >> > >> Hi. I confirm that this is appropriate for what we distribute: > > > > What about local scripts added by users (which this change might > > prevent loading): perhaps a NEWS.Debian entry would suffice? > > Are there any guidelines about when NEWS.Debian should be used > and when the Release Notes? > > (I'd like to avoid spamming the users with non-important information) > i may well be missing something, but I think: - policy is entirely silent on this (i may well be missing something here!) - devref has: < https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#supplementing-changelogs-with-news-debian-files > which says "This is the preferred means to let the user know about significant changes in a package." and "Only update them if you have something particularly newsworthy that user should know about." - release notes has very little - https://salsa.debian.org/ddp-team/release-notes/-/blob/master/README.md which says "The Release Notes contain important information for people updating from the previous version of Debian, particularly for less experienced users." fwiw my understanding is that release-notes should be used less often, than NEWS.Debian because - it only covers stable-to-stable upgrades (i doubt many unstable users read it at all - certainly at the moment i don't think there is any single post-bookworm content) - release-notes will only be ready once, on stable upgrades, whereas NEWS.Debian might be more useful for people tracking unstable (personally i would hope everything in release-notes is covered in NEWS.Debian for that reason!) - release-notes is meant to be understandable by less experienced non-technical "users" (all documentation should of course aim for that, in theory) - NEWS.Debian is "opt-in": if you install apt-listchanges you'll see NEWS.Debian, but that package isnt installed by the default. Even fewer users will read the changelog (although apt-listchanges can email that as well) (i dont think people would take a radically different view, but i may be mistaken!) i think in both cases, what gets included is a matter of judgement --- my personal view is that this change is not quite important enough (in terms of likely impact) for release-notes, but i would also happily help draft text for release-notes or drop the issue entirely: i dont feel strongly about this, i just happened to spot this bug
Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile
> >'^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$' > > Hi. I confirm that this is appropriate for what we distribute: What about local scripts added by users (which this change might prevent loading): perhaps a NEWS.Debian entry would suffice?
Bug#1068775: sbuild-qemu: fails to work, if piuparts is requested, but not installed on the host
On Fri, 12 Apr 2024, 19:00 Johannes Schauer Marin Rodrigues, < jo...@debian.org> wrote: > Hi Francesco, > > Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51) > > > > sbuild --dist unstable --purge-build=never --purge-deps=never > --chroot-mode=autopkgtest --autopkgtest-virt-server=qemu > --autopkgtest-virt-server-opt --overlay-dir=/dev/shm > --autopkgtest-virt-server-opt --qemu-architecture=x86_64 > --autopkgtest-virt-server-opt --ram-size=2048 --autopkgtest-virt-server-opt > --cpus=2 --autopkgtest-virt-server-opt --boot=efi > --autopkgtest-virt-server-opt > /home/$USER/.cache/sbuild/unstable-autopkgtest-amd64.img > --bd-uninstallable-explainer apt > > Error reading configuration: PIUPARTS binary 'piuparts' does not exist > or is not executable at /usr/share/perl5/Sbuild/Conf.pm line 76. > > > > > > However, I thought that setting $run_piuparts = 1 in ~/.sbuildrc caused > > piuparts to be run inside the virtual machine guest system, not on the > > host system! > > What made you think that? Is the error message above not clear enough? Do > you > think it should be improved to make things clearer? Do you have > suggestions for > a message that would've better explained that piuparts needs to be > installed on > the host system? > Adding a data point, i would also like the error message to be clearer - i know that once you understand how sbuild and piuparts work it becomes "obvious" that piuparts needs to be run from the host -- but this is not at all clear for new users: would be great if the documentation and errors could clearly distinguish between which things inside/outside the chroot This particular error message could be improved in at least 3 ways: 1. "Error reading configuration" -- suggests it couldnt parse the config file, which doesnt seem to be the case here (suggest either dropping this from the error message or saying more clearly what the issue is) 2. "PIUPARTS binary 'piuparts' does not exist or is not executable" not sure why the capitials and repetition? just say more directly what the issue is: eg : "Error: piuparts not found (it needs to be installed on the host)" 3. "at /usr/share/perl5/Sbuild/Conf.pm line 76." -- not sure this implementation detail is helpful for a user -- it makes it look a bug rather than a message for the user: could it be dropped from the error message or hidden behind a "debug"/"verbose" setting? thanks for working on sbuild, it's really great.
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 3/25/24 7:17 PM, Julian Gilbey wrote: So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! As someone from the Debian-GIS community, I would also be very interested in this! The Apache Arrow C++ library is one of the dependencies to make GDAL/OGR able to read/write (geo)parquet files, a data format with a lot traction in the geo community [0]. Thereby making it possible for QGIS to handle those (on Debian). [0] https://cloudnativegeo.org/blog/2023/09/duckdb-the-indispensable-geospatial-tool-you-didnt-know-you-were-missing/ Regards, Richard Duivenvoorde
Bug#1068161: Video playback regression
Package: chromium Version: 123.0.6312.86-1~deb12u1 Severity: important Video playback worked fine in the previous version, 122.0.6261.128-1~deb12u1 In the current version, when I attempt to play a video, the visual portion is completed whited out. The playback controls are present, playback position advances, audio can be heard, but the video is just a solid, constant white (regardless of the site's background color). During playback, the following pair of error messages are printed repeatedly to the terminal: [179003:179003:0331/180459.326096:ERROR:raster_decoder.cc(2407)] [.RenderCompositor-0x38dc004ddc00]GL ERROR :GL_INVALID_OPERATION : glWritePixelsYUV: Failed to upload pixels to dest shared image [179003:179003:0331/180459.385907:ERROR:shared_image_representation.cc(478)] Attempt to read from an uninitialized SharedImage. Initialized region: (0, 0, 0, 0) Size: (544, 360) I have downloaded the previous 122.0.6261.128-1~deb12u1 package, and run it to confirm that it can still play video correctly. In fact, I have 122 and 123 running side by side, with one working and the other spewing errors. --Daniel
Bug#1066903: libgnt: please drop runtime dependencies
This sounds reasonable to. It looks like you beat me to this with an
NMU. Thanks!
On 2024-03-15 04:08, Gianfranco Costamagna wrote:
Package: libgnt
Version: 2.14.4-1.1
Severity: serious
Tags: patch
Hello, I found some runtime dependencies, such as removed libglib2.0-0
breaking every 32bit build except i386 due to
time64_t transition.
Please update, remove them, let debhelper evaluate them via shlibs:Depends.
Also I added libxml2-dev build-dependency, looks like the support was
not enabled.
before:
Run-time dependency glib-2.0 found: YES 2.79.3
Run-time dependency gobject-2.0 found: YES 2.79.3
Run-time dependency gmodule-2.0 found: YES 2.79.3
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency libxml-2.0 found: NO (tried pkgconfig and cmake)
Now:
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
Run-time dependency glib-2.0 found: YES 2.79.3
Run-time dependency gobject-2.0 found: YES 2.79.3
Run-time dependency gmodule-2.0 found: YES 2.79.3
Run-time dependency libxml-2.0 found: YES 2.9.14
Also dpkg shows correct dependencies now:
Package: libgnt0t64
[...]
Depends: libc6 (>= 2.38), libglib2.0-0t64 (>= 2.75.3), libncursesw6 (>=
6), libtinfo6 (>= 6), libxml2 (>= 2.7.4)
Breaks: finch (<< 2.14.1), libgnt0 (<< 2.14.4-1.2)
Replaces: finch (<< 2.14.1), libgnt0
Provides: libgnt0 (= 2.14.4-1.2)
[...]
Thanks for considering the patch.
*** /tmp/tmpkfjro47y/libgnt_2.14.4-1.1ubuntu1.debdiff
diff -Nru libgnt-2.14.4/debian/control libgnt-2.14.4/debian/control
--- libgnt-2.14.4/debian/control 2024-03-08 06:22:50.0 +0100
+++ libgnt-2.14.4/debian/control 2024-03-15 09:59:05.0 +0100
@@ -1,6 +1,7 @@
libglib2.0-dev,
libglib2.0-doc,
libncurses-dev,
+ libxml2-dev,
meson,
Build-Depends-Indep: gtk-doc-tools,
Homepage: https://keep.imfreedom.org/libgnt/libgnt
@@ -18,10 +18,7 @@
Package: libgnt0t64
Provides: ${t64:Provides}
Architecture: any
-Depends: libglib2.0-0,
- libncursesw6,
- libxml2,
- ${misc:Depends},
+Depends: ${misc:Depends},
${shlibs:Depends},
Breaks: libgnt0 (<< ${source:Version}), finch (<< 2.14.1),
Replaces: libgnt0, finch (<< 2.14.1),
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1066817: input-remapper-gtk: Syntax errors at installation
Package: input-remapper-gtk
Version: 2.0.1-1
Severity: minor
Dear Maintainer,
this is a really minor issue, but upon finishing installation (from
terminal),
I'm greeted by this error message:
Notices:
/usr/lib/python3/dist-packages/inputremapper/gui/controller.py:304:
SyntaxWarning: invalid escape sequence '\d'
match = re.search(" copy *\d*$", name)
/usr/lib/python3/dist-packages/inputremapper/gui/messages/message_data.py:45:
SyntaxWarning: invalid escape sequence '\d'
all_matches = list(re.finditer("(\d+, )+", string))
It doesn't seem to be affecting anything, but maybe issues would only be
appearing in special circumstances.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (50, 'experimental'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.15-amd64 (SMP w/8 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 input-remapper-gtk depends on:
ii gir1.2-glib-2.01.78.1-15
ii gir1.2-gtk-3.0 3.24.41-1
ii gir1.2-gtksource-4 4.8.4-5+b1
ii input-remapper-daemon 2.0.1-1
ii python33.11.6-1
ii python3-inputremapper 2.0.1-1
input-remapper-gtk recommends no packages.
input-remapper-gtk suggests no packages.
-- no debconf information
Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec
(Replying via mobile, so non-Debian address.) It should be reasonably possible to convert this to .d style. I will have to dig into this to fully consider all the implications, especially around handling upgrades. I think part of the issue here is that ntpd logs there by default. That is, you don’t turn on logging. I’m not sure if there is a way to turn off logging. But I have to check. I want to maintain the same posture we have now: - No logs by default. Most people don’t use them, so this is pointless I/O. - People can enable logs reasonably easily. - Installing ntpviz automatically enables logs. For upgrades, I can use the presence or absence of the directory for most of the handling. I do need to think through what happens / what to do if someone has customized any of the other log settings. -- Richard
Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec
Control: reopen -1 On 2024-03-12 11:10, MOESSBAUER, Felix wrote: On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote: This is intentional. The logging is optional and whether the directory exists controls this. Hi Richard, that's a quite uncommon interface. Is this at least documented somewhere? ntp.conf Also the "error" should be downgraded to a "warning" at least. Didn't I do that? commit b06f1d8177a9b0a2593947a2ebefcb43e94ac281 Author: Santiago Vila Date: Sun Dec 24 15:36:25 2023 -0600 Downgrade missing stats dir log severity The Debian package does not create /var/log/ntpsec by default. The admin is directed (by a comment in ntp.conf) to create it if and only if they want logging. However, upstream ntpsec logs an error message if the log directory does not exist. Closes: 1049424 Signed-off-by: Richard Laager [The commit message / patch description is my wording.] One advantage of that is the ntpsec-ntpviz package can create that directory to enable logging, which is required for ntpviz to be useful. Otherwise, it would have to edit the config file, which is riskier. Well... for that conf.d style configs are usually used. Yeah. ntpsec supports those _now_. (I don't know that it did at the time.) So maybe that's a better answer. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066079: RFS: ddclient/3.11.2-1 -- address updating utility for dynamic DNS services
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddclient": * Package name : ddclient Version : 3.11.2-1 Upstream contact : https://github.com/ddclient/ddclient * URL : https://ddclient.net * License : GPL-2.0+, Artistic or GPL-1+, Apache-2.0 * Vcs : https://salsa.debian.org/debian/ddclient Section : net The source builds the following binary packages: ddclient - address updating utility for dynamic DNS services To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ddclient/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/ddclient/ddclient_3.11.2-1.dsc Changes since the last upload: ddclient (3.11.2-1) unstable; urgency=medium . * Add curl build dependency to enable the -curl argument * Suggest curl * Bump Standards-Version to 4.6.2 (no changes needed) * gbp.conf: Rename branches and tags to match current convention * gbp.conf: Set upstream-vcs-tag (for import-orig) * New upstream version 3.11.2 * Refresh patches * Update dependencies * Use dh_installchangelogs to install ChangeLog.md * debian/copyright: Set Upstream-Contact to project URL * debian/copyright: Update copyright year for debian/* Regards, OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060023: Acknowledgement (ITP: keyd -- Keyboard key remapping daemon for Linux)
Request for sponsorship (RFS): bug #1066022 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066022: RFS: keyd/2.4.3-1 [ITP] -- keyboard key remapping daemon
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "keyd": * Package name : keyd Version : 2.4.3-1 Upstream contact : Raheman Vaiya * URL : https://github.com/rvaiya/keyd * License : Expat * Vcs : https://salsa.debian.org/rhansen/keyd Section : utils The source builds the following binary packages: keyd - keyboard key remapping daemon keyd-application-mapper - keyboard key remapping daemon - application-specific remapper To access further information about this package, please visit the following URL: https://mentors.debian.net/package/keyd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keyd/keyd_2.4.3-1.dsc Changes for the initial release: keyd (2.4.3-1) unstable; urgency=medium . * Initial debianization. (Closes: #1060023) Regards, Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
I think, but am not sure, that this is now functionally a duplicate of #1060506. That one tells me to change it from systemd to systemd-dev because: Since systemd_253-2 [1], these two pkgconfig files have been split into a separate package named systemd-dev. This package is arch:all, so even available on non-Linux architectures, which will simplify the installation of upstream provided service files / udev rules. I have made that change. If that is NOT sufficient, please let me know and I'll adjust again. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064025: ntpsec does not sync to server if "iburst" is missing
I agree that the description, as provided, would be a bug. However, I cannot reproduce this. Can you provide your ntp.conf file, in full, please? -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”
Hello. I can confirm that upgrading fwupd and libfwupd2 on Trixie to 1.9.14-1 and installing the package maintainer's version of /etc/fwupd/fwupd.conf allowed the fwupd status to start: sudo apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: fwupd libfwupd2 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/3,833 kB of archives. After this operation, 54.3 kB of additional disk space will be used. Do you want to continue? [Y/n] y Retrieving bug reports... Done Parsing Found/Fixed information... Done serious bugs of fwupd (1.9.11-1 → 1.9.14-1) b1 - #1061731 - fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish” Summary: fwupd(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] y Reading changelogs... Done ... Configuration file '/etc/fwupd/fwupd.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** fwupd.conf (Y/I/N/O/D/Z) [default=N] ? y Installing new version of config file /etc/fwupd/fwupd.conf ... fwupd-offline-update.service is a disabled or a static unit not running, not starting it. fwupd-refresh.service is a disabled or a static unit not running, not starting it. fwupd.service is a disabled or a static unit not running, not starting it. Processing triggers for libc-bin (2.37-15) ... Processing triggers for man-db (2.12.0-3) ... Processing triggers for dbus (1.14.10-4) ... Processing triggers for hicolor-icon-theme (0.17-2) ... systemctl status fwupd ○ fwupd.service - Firmware update daemon Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static) Active: inactive (dead) Docs: https://fwupd.org/ sudo systemctl start fwupd systemctl status fwupd ● fwupd.service - Firmware update daemon Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static) Active: active (running) since Thu 2024-03-07 16:37:27 CST; 3s ago Docs: https://fwupd.org/ Main PID: 22184 (fwupd) Tasks: 7 (limit: 18110) Memory: 23.7M (peak: 108.7M) CPU: 988ms CGroup: /system.slice/fwupd.service └─22184 /usr/libexec/fwupd/fwupd I kept fwupd at 1.9.11-1 since this bug was reported, but the new version seems to be in the clear. Best. Richard
Bug#1065567: timedatectl does not recognize ntpsec
If I'm understanding this correctly, I just need to install a file with the contents "ntpsec.service" to /usr/lib/systemd/ntp-units.d/50-ntpsec.list. That's easy enough to do. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065434: spice-vdagent: Automatic window resize not working XFCE and MATE desktops (Cinnamon works correctly)
Package: spice-vdagent Version: 0.22.1-4+b1 Severity: important X-Debbugs-Cc: po42st+deb12...@gmail.com Dear Maintainer, * What led up to the situation? Installed Debian Bookworm 12.5 XFCE VM within Debian 12.4 + Proxmox 8.1.4 XFCE workstation. On the VM installed spice-vdagent. Noticed that the Debian VM's desktop would not automatically resize to the client screen size on boot or to the client window size if running in a window after rebooting VM. Checked settings of client machines Virtual Machine Viewer 11. Auto resize is set. Checked spice-vdagent was running on the VM with "sudo systemctl status spice- vdagent", it was. Checked that the copy and paste between the client OS and VM was functional. It was. * What exactly did you do (or not do) that was effective (or ineffective)? Opened the VM XFCE display settings from the graphical XFCE desktop. Noticed that a VM window resize or switch to full screen was being picked up by the VM display settings manager but was not being selected and activated automatically. The pictoral "Virtual-1" window representation would change shape however the display settings "Resolution" drop down box would become blank. On selecting the "Resolution" drop down box, the display window setting required is shown at the very top of the list with an asterix (*) against it. Selecting this option and then apply correctly resizes the desktop resolution to match the VM window size. However this behavior should be automatic and not require user intervention. The issue was googled. Indication that the issue was affecting MATE but not Cinnamon desktops was found. MATE and Cinnamon desktops were also installed into a cloned instance of the VM to test. This was confirmed. Cinnamon works correctly and auto resizes. MATE does not and also was found to not take on the settings into the Display manager unlike XFCE. The affected test VM was updated to Trixie and the same tests carried out again. The same behaviour was found as with Bookworm 12.5. The logs available for spice-vdagent were searched for within the Gnome Logs application. Errors were found with each resizing the VM display window: 14:06:31 spice-vdagent:error message: Cannot invoke method; proxy is for the well-known name without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag 14:06:31 spice-vdagent:error message: Cannot invoke method; proxy is for the well-known name without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag 14:06:31 spice-vdagent: display: failed to call GetCurrentState from mutter over DBUS 14:06:31 spice-vdagent:error message: Cannot invoke method; proxy is for the well-known name without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag 14:06:31 spice-vdagent: display: failed to call GetCurrentState from mutter over DBUS * What was the outcome of this action? Automatic window resize not working XFCE and MATE desktops (Cinnamon works correctly) * What outcome did you expect instead? Automatic window resizing. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages spice-vdagent depends on: ii init-system-helpers 1.66 ii libasound2 1.2.10-3 ii libc62.37-15 ii libdbus-1-3 1.14.10-4 ii libdrm2 2.4.120-2 ii libglib2.0-0 2.78.4-1 ii libgtk-3-0 3.24.41-1 ii libpciaccess00.17-3 ii libsystemd0 255.3-2 ii libx11-6 2:1.8.7-1 ii libxinerama1 2:1.1.4-3 ii libxrandr2 2:1.5.2-2+b1 spice-vdagent recommends no packages. spice-vdagent suggests no packages. -- no debconf information
Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment
On Wed, 28 Feb 2024 18:37:41 +0100 Michael Biebl wrote: > On Fri, 17 Nov 2023 14:40:05 +0100 Christoph Anton Mitterer > wrote: > > Package: systemd > > Version: 255~rc2-1 > > Because of #1056135 I was downgradin systemd/udev packages to 254.5-1. > > While apt was still running, this causes the whole desktop environment > > (I use cinnamon) to be killed (and all processes in it ;-) ). > My guess is, that the failures you encountered are due to the following > change in v255: > > """ > Service Manager: > > * The way services are spawned has been overhauled. I couldnt follow the bit i deleted, and this maybe jumping to conclusions: are there any implications for upgrading to/after 255 within a desktop environment? should something be said in the release-notes?
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Mon, 26 Feb 2024, 13:03 Michael Biebl, wrote: > Hi > > On Thu, 22 Feb 2024 19:01:05 +0000 Richard Lewis > wrote: > > On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck, wrote: > > > > > On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > > > > > > > I forgot to mention: > > > > There is an upstream (rsyslog) bug-report at > > > > https://github.com/rsyslog/rsyslog/issues/5332 > > > > > > Upstream has decided that it is not a bug and that both timestamp > > > formats are valid RFC 3339 (I've checked, the grammar explicitly > defines > > > the sub-seconds part of the timestamp as optional). See link above. > > > They also think, logcheck should cope with both formats. > > > > > > So I guess that logcheck should be prepared to receive both kinds of > > > timestamps, the 32-byte version and the 25-byte version (without the > > > subseconds timestamp). > > > > > > > what is the default, and does logcheck cope with that? there's a limit to > > how much to suport out of the box - especially as rsyslog is no longer > the > > default. > > Just to clarify: It is correct that rsyslog is no longer installed by > default. That said, I would still consider rsyslog the default syslog > daemon in Debian. Packages that depend on system-log-daemon typically do > this via a "Depends: rsyslog | system-log-daemon" > thanks - agree logcheck should cope with a default rsyslog output. ... i just dont know what that default output is: does the below mean the subseconds are now always present? or: what regexp should logcheck use as prefix? As for this specific issue, Ralf has found a way to make ensure that > remote syslog messages also carry a subseconds timestamp by explicitly > specifying the format when forwarding the messages [2] > > Michael > > [1] > > https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.36/administration-guide/ts-format > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385#29 >
Bug#1064574: file-roller: 7zip can't handle encrypted archives with encrypted file names
Package: file-roller Version: 43.1-1 Severity: important Dear Maintainer, it seems the version of file-roller is partially broken, possibly due to the fact that it still lists p7zip-full as dependency and not the new 7zip package and thus might be missing some adaptation. Maybe some behavior of the 7z interface has changed, I can't tell. I can only tell that file-roller is incapable of opening and extracting encrypted 7zip archives that have their file names encrypted as well. The 7z CLI from the 7zip package can do so with no issues, so it seems to be an issue with file-roller. At least, I think it was capable of handling this kind of archives before p7zip was replaced by 7zip. The issue shows itself in the form that when trying to open such a file with file-roller, it doesn't ask for a password, but only shows an empty screen. You can select "extract", but it will fail with a message that the extraction couldn't be performed. Sadly, I have yet to be able to collect any kind of logs. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/8 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 file-roller depends on: ii 7zip [p7zip-full]23.01+dfsg-8 ii bzip21.0.8-5+b2 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 ii libarchive13 3.7.2-1 ii libc62.37-15 ii libcairo21.18.0-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libglib2.0-0 2.78.4-1 ii libgtk-3-0 3.24.41-1 ii libhandy-1-0 1.8.3-1 ii libjson-glib-1.0-0 1.8.0-2 ii libnautilus-extension4 45.2.1-4 ii libpango-1.0-0 1.51.0+ds-4 ii p7zip-full 16.02+transitional.1 Versions of packages file-roller recommends: ii gvfs 1.53.90-2 ii yelp 42.2-1+b1 Versions of packages file-roller suggests: ii arj 3.10.22-26 ii lhasa [lha] 0.4.0-1+b1 ii lzip 1.24-1 ii lzop 1.04-2 pn ncompress ii rpm2cpio 4.18.2+dfsg-1 pn rzip pn sharutils ii squashfs-tools 1:4.6.1-1 ii unace1.2b-23 ii unalz0.65-9 ii unar 1.10.7+ds1+really1.10.1-2+b3 ii unzip6.0-28 ii xz-utils [lzma] 5.4.5-0.3 ii zip 3.0-13 pn zoo -- no debconf information
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck, wrote: > On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > > > I forgot to mention: > > There is an upstream (rsyslog) bug-report at > > https://github.com/rsyslog/rsyslog/issues/5332 > > Upstream has decided that it is not a bug and that both timestamp > formats are valid RFC 3339 (I've checked, the grammar explicitly defines > the sub-seconds part of the timestamp as optional). See link above. > They also think, logcheck should cope with both formats. > > So I guess that logcheck should be prepared to receive both kinds of > timestamps, the 32-byte version and the 25-byte version (without the > subseconds timestamp). > what is the default, and does logcheck cope with that? there's a limit to how much to suport out of the box - especially as rsyslog is no longer the default. if you configure a logger to produce a certain format it's not unreasonable to also have to edit logcheck rules accordingly But a longer-term solution is perhaps to allow easier customisation of rules via "macros"/variables --- a proof-of-concept for this is in progress, but not.yet ready for testing
Bug#959867: ifup kills dhclient on if-up.d script failure
I was recently bitten by this as well. It was particularly bad in my case: on a headless server, with the network connection being my only way in---and the problem was not with the main Ethernet interface, but with a separate WireGuard one that I was not using (both marked as "auto"). The eno1 interface got a DHCP connection without issue. But the wg0 config had a post-up routing-setup bug that I'd missed in earlier testing. As the syslog excerpt below shows, the failure to bring up wg0 caused *all* of the "Raise network interfaces" task to be walked back. And as this only killed dhclient and left eno1 configured, I thought all was fine... until the system dropped off the network twelve hours later. (It's also clear that dhclient was killed uncleanly, because the next time it runs, you get a "Removed stale PID file" message.) The "FIB table does not exist" error is where things start to go wrong: 2024-02-05T22:19:06.343712-05:00 darkstar systemd[1]: Starting networking.service - Raise network interfaces... 2024-02-05T22:19:06.377118-05:00 darkstar dhclient[620]: Internet Systems Consortium DHCP Client 4.4.3-P1 2024-02-05T22:19:06.377147-05:00 darkstar ifup[620]: Internet Systems Consortium DHCP Client 4.4.3-P1 2024-02-05T22:19:06.377154-05:00 darkstar ifup[620]: Copyright 2004-2022 Internet Systems Consortium. 2024-02-05T22:19:06.377159-05:00 darkstar ifup[620]: All rights reserved. 2024-02-05T22:19:06.377164-05:00 darkstar ifup[620]: For info, please visit https://www.isc.org/software/dhcp/ 2024-02-05T22:19:06.377178-05:00 darkstar dhclient[620]: Copyright 2004-2022 Internet Systems Consortium. 2024-02-05T22:19:06.377190-05:00 darkstar dhclient[620]: All rights reserved. 2024-02-05T22:19:06.377201-05:00 darkstar dhclient[620]: For info, please visit https://www.isc.org/software/dhcp/ 2024-02-05T22:19:06.377213-05:00 darkstar dhclient[620]: 2024-02-05T22:19:06.675691-05:00 darkstar dhclient[620]: Listening on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675765-05:00 darkstar ifup[620]: Listening on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675783-05:00 darkstar ifup[620]: Sending on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675796-05:00 darkstar ifup[620]: Sending on Socket/fallback 2024-02-05T22:19:06.675831-05:00 darkstar dhclient[620]: Sending on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675863-05:00 darkstar dhclient[620]: Sending on Socket/fallback 2024-02-05T22:19:06.675919-05:00 darkstar dhclient[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:06.675956-05:00 darkstar ifup[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:09.219179-05:00 darkstar kernel: [6.436538] e1000e :00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx 2024-02-05T22:19:09.219201-05:00 darkstar kernel: [6.436674] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready 2024-02-05T22:19:11.467192-05:00 darkstar dhclient[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:11.467252-05:00 darkstar ifup[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:11.470106-05:00 darkstar dhclient[620]: DHCPACK of 192.168.1.2 from 192.168.1.1 2024-02-05T22:19:11.470172-05:00 darkstar ifup[620]: DHCPACK of 192.168.1.2 from 192.168.1.1 2024-02-05T22:19:11.509438-05:00 darkstar dhclient[620]: bound to 192.168.1.2 -- renewal in 21284 seconds. 2024-02-05T22:19:11.509497-05:00 darkstar ifup[620]: bound to 192.168.1.2 -- renewal in 21284 seconds. 2024-02-05T22:19:11.575017-05:00 darkstar kernel: [8.793246] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information. 2024-02-05T22:19:11.575027-05:00 darkstar kernel: [8.793252] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. 2024-02-05T22:19:11.589364-05:00 darkstar ifup[689]: Error: ipv4: FIB table does not exist. 2024-02-05T22:19:11.589373-05:00 darkstar ifup[689]: Flush terminated 2024-02-05T22:19:11.589765-05:00 darkstar ifup[583]: ifup: failed to bring up wg0 2024-02-05T22:19:11.599118-05:00 darkstar systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE 2024-02-05T22:19:11.663575-05:00 darkstar systemd[1]: networking.service: Failed with result 'exit-code'. 2024-02-05T22:19:11.664060-05:00 darkstar systemd[1]: Failed to start networking.service - Raise network interfaces. 2024-02-05T22:19:11.664996-05:00 darkstar systemd[1]: Reached target network.target - Network. 2024-02-05T22:19:11.665371-05:00 darkstar systemd[1]: Reached target network-online.target - Network is Online.
Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed
On 2/5/24 00:08, Jeremy Bícha wrote: I do not believe your issue is the same since you are still able to log in to your NextCloud, but the original bug poster is not. Okay. Yes, I believe it is expected that updating GNOME Online Accounts to 3.49 will require reauthenticating. Authentication is now handled in the user's regular web browser instead of a webkitgtk dialog which makes login more reliable and should be more resilient to authentication changes from upstream providers. I was looking for information like this pointing out the incompatibility. (The changelog does mention that authentication for Google & Microsoft now uses the web browser, but nothing about nextCloud etc.) It is not expected that everything will work if you try to share configuration between different operating system versions. Sorry. :( Ouch! This is so frustrating. -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed
Confirmed: Same problem here for nextCloud and for google accounts. Gnome files says "Unable to access usern...@googlemail.com Invalid credentials for usern...@googlemail.com". Same for nextCloud accounts. goa-daemon says "/org/gnome/OnlineAccounts/Accounts/account_1706819076_1: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: Invalid password with username “username” (goa-error-quark, 4): Authentication failed (goa-e rror-quark, 4) I can remove the accounts and re-add them. But then they don't work with gnome-online-accounts 3.46.0-1 (Debian stable machine where same home dir is mounted). There, I can remove them and re-add them. But changing to 3.49.0-1 from testing all starts over again. Seems like compatibility broke badly.
Bug#1060023: Acknowledgement (ITP: keyd -- Keyboard key remapping daemon for Linux)
I have been uploading drafts of the new keyd package to: https://mentors.debian.net/package/keyd/ Any feedback would be appreciated. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Am Mi., 17. Jan. 2024 um 17:08 Uhr schrieb John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > This is exactly what it's supposed to mean. Packages distributed by > Debian are obviously required > > to not be broken when they hit stable. Otherwise an update wouldn't be > accepted to be sent to stable. > > The package is not broken. It works as intended by the upstream > developers. It does not say anywhere > that AusweisApp is supposed to work on a non-Qt system. > This is just not how anything works. Besides the fact that after Gnome was made because people didn't like Qt's licensing and after a while they both added compatibility for each others software - there basically isn't such thing as a "non-Qt system". A non-Qt system would be a system with no Qt dependencies available. But you'll probably never find any distro where this is the case. That's why any package will always work with any DE, no matter if it was build with GTK, Qt or something else. Sure, with Wayland needing to be supported by the DEs instead of a generic server, it can happen that some minor things need to be harmonized, e.g. communicating a sensible cursor size to Qt apps in a Gnome DE, but that's it. There's absolutely nothing that makes Qt apps Plasma only or GTK apps Gnome only. > > > And since neither Debian with KDE nor Debian with Gnome is a separate > distribution, obviously a > > package is supposed to work with both. > > Sorry, but that's just non-sense. If an upstream project does not support > GNOME, it will not > support GNOME on Debian either. Again, you are barking up the wrong tree > here. > Again, not how anything works. > > > That's why all KDE packages will pull in all necessary dependencies > required to run in Gnome (or > > any other DE offered by Debian) and vice versa. If any package would be > allowed in stable in a > > theoretical future where it only supports Wayland and not X while not > all available DEs would > > be supporting Wayland would be very questionable. And that's just > another version of this exact problem. > > It's simply not possible to support every possible use cases. You just > have to accept that. > Obviously not. But every use case supported by Debian itself must be supported by the packages. With DEs it's not like with CPU architectures where you can simply choose not to compile a package for a specific architecture. Besides the fact that even that's not relevant. Even AusweisApp is being compiled for pretty much any architecture supported by debian, simply because there's nothing preventing it. That's at least true for anything in the main repo. The only exception I know of is Steam, but that's only shipped in contrib (and used to be non-free). So yes, every use case supported by Debian stable in the main repo must be supported by every package in that branch. Everything else wouldn't make any sense after all. The real software world is not perfect. > > > > The limitations around GNOME support are an upstream issue and not > related to packaging which > > > is what I am doing. Claiming that a particular issue that is not a > serious bug must be fixed > > > before the next release is something that I would call entitlement. If > you have figured out > > > how to fix this particular problem, you are free to send a patch to me > or upstream. That's > > > how it works with community-maintained software. > > > > It's obviously serious since it literally renders the software unusable > for some users. If you > > have a different opinion, you should really re-read the severity levels' > definitions: > > https://www.debian.org/Bugs/Developer#severities > > important: a bug which has a major effect on the usability of a package, > without rendering it > > completely unusable to everyone. > > This is literally what this is. > > And you're still missing the point that the issue you are seeing here is > not a limitation of Debian > but of the upstream software you are using. You are blaming me for > something that I am not responsible > for. > > I am neither the upstream developer of GNOME nor of Qt or the AusweisApp. > I am the person who is > maintaining AusweisApp in Debian. And I am shipping the software as it is > provided by upstream. > > If upstream doesn't support usecase X, I am not the person to be blamed. > You really should look up how "Maintainer" was defined when the concept was introduced: https://www.debian.org/vote/2007/vote_003 One of the points: unfixed bugs may lead to the Maintainers key removal from the Debian Maintainers keyring, effectively revoking their status of being a Maintainer. > > > Neither me nor the upstream maintainer are actually getting paid to > provide this application > > > on Linux or on Debian, so it's perfectly fine that we get to decide > how we spend our free > > > time. > > > > Nobody said otherwise. But literally with a bug this severe v2 can't and > shouldn't be accepted > > into stable with Trixie. And if nobody fixes it, it's
Bug#1031956: TrayIcon
Hi, I'm sorry, but you must have misread the bug report. Nobody's talking about autostart. When the app is opened, be it from its desktop icon or from a terminal, in Gnome with an extension enabled to enable a tray for icons of apps running the background, AusweisApp does add its icon to the tray (though not actually showing an icon, so there's just an empty button). But that's it. If it was wokring as supposed, its icon would also be added to Gnome's dock and usually - if the app doesn't have an option enabled to start as a background app - obviously the apps UI is supposed to open up. Both last things don't happen. Also, from the tray icon, you can only close the app. There's no option to toggle the window (or whatever programs call that option). This is the whole issue, rendering the app completely unusable for all users meeting the aforementioned criteria. Yes, if you start it with --show, you get the UI. But if you close it, it closes to tray with no option to get it back. And no, by no means it's supposed to be a deamon that only shows its UI when it's used for authentication. That's not how the Windows version works, not the Android version and most likely no version of AusweisApp. So why should the Linux app? Otherwise you wouldn't be able to change settings, e.g. to connect to a smartphone to act as a card reader. When it comes to Qt apps that act as expected, I honestly don't use that many Qt apps - or I just can't tell if an app uses Qt or something completely different. VLC kinda works as expected - you can have it start only showing a tray icon and do what you like from there. But VLC is dirt old - I was not yet able to get VLC 4 to work on Linux. KeePassXC is based on Qt 5 and certainly works as expected. I think Telegram desktop may be written with Qt, that's definetely working as expected. Also, I'm using a syncing app for a cloud service based on Owncloud (or Nextcloud), the Linux Client is based on the Owncloud Linux client, which also is based on Qt5, also working with a tray icon as expected. Other than that, I don't really know that many Qt based apps, even less that can make use of a tray icon, and then less that are already based on Qt 6, independent of their use of tray icons. Richard Am Mi., 17. Jan. 2024 um 15:24 Uhr schrieb A. Klitzing : > Hi there, > > the AusweisApp has no autostart option on Linux. Did you add the > AusweisApp to autostart by yourself? Why is it expected that the app > should be in foreground if the systems starts? It is a service > application like a "daemon" that waits until a users click on a > eID-link in the browser. As a work-around you can add "--show" to > cmdline option to start in foreground. > > The app uses Qt for the TrayIcon. We can show "Open" on Linux like we > do for macOS if you like. You can see in Qt doc [2] the possible > activation reason. Currently we use "Trigger" to show up the UI. This > works for me on KDE. I tried Gnome on Debian right now and it requires > a double-click. This looks like a bug in Qt or not documented > behaviour. Do you know a Qt app with QSystemTrayIcon that works like > you expected? So I can look into that. > > Best regards > André > > > [1] > https://github.com/Governikus/AusweisApp/blob/master/src/ui/qml/TrayIcon.cpp#L112 > [2] https://doc.qt.io/qt-6/qsystemtrayicon.html#ActivationReason-enum > > -- > To unsubscribe, send mail to 1031956-unsubscr...@bugs.debian.org. >
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Am Di., 16. Jan. 2024 um 20:41 Uhr schrieb John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > Who says I am? I am running testing. Also, getting security updates > from unstable is actually > > recommended behavior, so the stuff around "FrankenDebian" is > contradicting itself. > > There is no version 2.0.x in Debian stable nor stable-backports yet, so > unless you built the > package yourself from the unstable sources or installed the Flatpak > version, you created a > "FrankenDebian". > To be quoting myself: *I am running testing**. AKA Trixie. *So no, there's no FrankenDebian at work. > > And, no, the wiki page regarding "FrankenDebian" is not contradicting > itself because security > updates are provided through debian-security. These updates are built to > target Debian stable, > so it's perfectly fine to install them without risking to break anything. > It is not contradicting itself page-wide, but wiki-wide. This is the Wiki entry for Debian Testing, where it literally recommends to do what the "FrankenDebian" Wiki page recommends not to do: https://wiki.debian.org/DebianTesting *It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable.* > > Entitled? Well that's rich. The point of the whole bug reporting system > is exactly what we > > are doing here. So yes, if you are unwilling to maintain the > package, which will always > > include getting bug reports if things don't behave as intended, then > don't do it. > > Not really. If someone steps up to maintain something, it doesn't > automatically mean they > are responsible for supporting all possible configurations that exist > within Debian which > is what you are asking for. The package works perfectly fine on KDE which > is what I am using > myself. > This is exactly what it's supposed to mean. Packages distributed by Debian are obviously required to not be broken when they hit stable. Otherwise an update wouldn't be accepted to be sent to stable. And since neither Debian with KDE nor Debian with Gnome is a separate distribution, obviously a package is supposed to work with both. That's why all KDE packages will pull in all necessary dependencies required to run in Gnome (or any other DE offered by Debian) and vice versa. If any package would be allowed in stable in a theoretical future where it only supports Wayland and not X while not all available DEs would be supporting Wayland would be very questionable. And that's just another version of this exact problem. > > The limitations around GNOME support are an upstream issue and not related > to packaging which > is what I am doing. Claiming that a particular issue that is not a serious > bug must be fixed > before the next release is something that I would call entitlement. If you > have figured out > how to fix this particular problem, you are free to send a patch to me or > upstream. That's > how it works with community-maintained software. > It's obviously serious since it literally renders the software unusable for some users. If you have a different opinion, you should really re-read the severity levels' definitions: https://www.debian.org/Bugs/Developer#severities *important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.* This is literally what this is. > > Neither me nor the upstream maintainer are actually getting paid to > provide this application > on Linux or on Debian, so it's perfectly fine that we get to decide how we > spend our free > time. > Nobody said otherwise. But literally with a bug this severe v2 can't and shouldn't be accepted into stable with Trixie. And if nobody fixes it, it's questionable how long this package will be accepted to stay in the repos at all.
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Am Mo., 15. Jan. 2024 um 21:38 Uhr schrieb John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > On Mon, 2024-01-15 at 19:29 +0100, Richard wrote: > > I second this report. The app did use to work actually, but recently - > not sure with > > transitioning to ausweisapp with v2.0 or later, this breaks for me too. > > What breaks? Please be more specific! > I mean the exact same behavior. App starts, it has an entry in the tray, but no icon, also none in the Gnome dock and no window is opening, > > > This renders the app completely unusable, at least using Gnome, which > should justify a > > severity of important. It's quite irrelevant if the app is a Gnome, Gt > or whatever app. > > It is actually quite relevant because it is up to the upstream developer > which configurations > they support and which not. There is an endless number of Linux > distributions and desktop > environments, so it's naturally impossible to support all of them. > Sure, but it's part of Debian's repository. And if it's supposed to stay that way, something needs to be fixed. And for all I know this app doesn't have an official Linux version. The website calls it a community version. So whoever feels responsible, the person maintaining it in the Debian repositories and keeping it there or the person that ported the app (not even sure if the official app uses Qt). But the current state needs to be resolved at least by the time Trixie hits stable. Sure, it wouldn't be the best solution to dropp the app altogether, but having the app only on paper for many users isn't one either. > > > Sure, the newer version right now is only available in testing and sid > (tested both, same > > result). > > Errm, you shouldn't be installing packages from unstable on a stable > system [1]. > Who says I am? I am running testing. Also, getting security updates from unstable is actually recommended behavior, so the stuff around "FrankenDebian" is contradicting itself. > > > But that just makes it more important that this is sorted out before > this package is made > > available in stable or stable-backports. Especially since running it as > Flatpak would > > probably render half the app unusable since the communication with the > browser would > > probably not work. > > FWIW, I am merely packaging the software for Debian. I am not the upstream > developer. If > you have problems with the software itself which is not related to > packaging, you should > direct your bug reports upstream. > > Unfortunately though, upstream actually does not officially support Linux, > so they don't > really care if it breaks. Thus, if you are really so annoyed by the > software not working > on your particular system, I am happy to request a removal of the package > from the Debian > archive mirrors so that I don't have to bother with such entitled bug > reports anymore. > Entitled? Well that's rich. The point of the whole bug reporting system is exactly what we are doing here. So yes, if you are unwilling to maintain the package, which will always include getting bug reports if things don't behave as intended, then don't do it.
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
Package: postfix-mysql Version: 3.7.9-0+deb12u1 Severity: grave Justification: renders package unusable Dear Maintainer, With the update in stable-updates, this package seems to be no longer working. removing it and going back to 3.7.6 solves the issue. This is what it writes to journal: Jan 16 14:58:32 mail postfix/smtpd[14969]: error: unsupported dictionary type: mysql Jan 16 14:58:32 mail postfix/smtpd[14969]: connect from localhost[127.0.0.1] Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: error: unsupported dictionary type: mysql Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: mysql:/etc/postfix/mysql-forwards.cf is unavailable. unsupported dictionary type: mysql Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: virtual_alias_domains: mysql:/etc/postfix/mysql-forwards.cf: table lookup problem Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: mysql:/etc/postfix/mysql-forwards.cf is unavailable. unsupported dictionary type: mysql Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: virtual_alias_domains: mysql:/etc/postfix/mysql-forwards.cf: table lookup problem Jan 16 14:58:32 mail postfix/smtpd[14969]: warning: mysql:/etc/postfix/mysql-forwards.cf is unavailable. unsupported dictionary type: mysql Jan 16 14:58:32 mail postfix/smtpd[14969]: warning: mysql:/etc/postfix/mysql-forwards.cf lookup error for "recei...@domain.de" Jan 16 14:58:32 mail postfix/smtpd[14969]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 : Temporary lookup failure; from= to= proto=ESMTP helo= So it simply stops providing the mysql support it was made for, which renders postfix itself unusable unless you where to move away from mysql. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-amd64 (SMP w/2 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 postfix-mysql depends on: ii libc62.36-9+deb12u3 ii libmariadb3 1:10.11.4-1~deb12u1 ih postfix 3.7.9-0+deb12u1 postfix-mysql recommends no packages. postfix-mysql suggests no packages. -- no debconf information
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
I second this report. The app did use to work actually, but recently - not sure with transitioning to ausweisapp with v2.0 or later, this breaks for me too. This renders the app completely unusable, at least using Gnome, which should justify a severity of important. It's quite irrelevant if the app is a Gnome, Gt or whatever app. Like any app, if it's included in Debian it should not be broken beyond usability. Sure, the newer version right now is only available in testing and sid (tested both, same result). But that just makes it more important that this is sorted out before this package is made available in stable or stable-backports. Especially since running it as Flatpak would probably render half the app unusable since the communication with the browser would probably not work.
Bug#1060459: scalpel: Scalpel not working on Apple Silicon
Package: scalpel Version: 1.60-10 Severity: grave Tags: patch Justification: renders package unusable X-Debbugs-Cc: goldenrich...@gmail.com Dear Maintainer, * What led up to the situation? I am the author of Scalpel. Execution of Scalpel 1.60 (the version that is currently in the scalpel package on Debian et al) fails completely on VMs hosted on Apple Silicon because of some long-standing memory corruption bugs. It may also work incorrectly on other platforms. * What exactly did you do (or not do) that was effective (or ineffective)? I have placed updated source distros for Scalpel 1.60 as well as the newer (and more powerful) Scalpel 2.02 on GitHub via https://github.com/nolaforensix/scalpel-1.60 and https://github.com/nolaforensix/scalpel-2.02. My recommendation is to rebuild the 1.60 package from the updated source and also consdering adding 2.02. * What was the outcome of this action? Scalpel is broken and I fixed it :) * What outcome did you expect instead? N/A? -- System Information: Distributor ID: Kali Description:Kali GNU/Linux Rolling Release:2023.4 Codename: kali-rolling Architecture: x86_64 Kernel: Linux 6.5.0-kali3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.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 scalpel depends on: ii libc6 2.37-12 scalpel recommends no packages. scalpel suggests no packages. -- no debconf information
Bug#1024683: Interest to participate
Hello! I would be willing to help out with packaging helix, seeing as it is really useful editor and I want to use in some debian systems on which cargo would not be a great route to install it. Therefore I would like to offer my help with packaging some of its dependencies and maybe the main package as well. I would need some guidance on how to proceed, seeing as in the salsa there are a lot of dependencies still out necessary to be packaged. Where could I start? Is there are any low-hanging fruit depency which could be a great target for me? I have registered an account with the Salsa gitlab and am waiting on approval for it. Kind regards, Richard
Bug#1060023: ITP: keyd -- Keyboard key remapping daemon for Linux
Package: wnpp Severity: wishlist Owner: Richard Hansen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: keyd Version : 2.4.3 Upstream Contact: Raheman Vaiya * URL : https://github.com/rvaiya/keyd * License : Expat Programming Lang: C Description : Keyboard key remapping daemon for Linux keyd is a system-wide key remapping daemon which supports features like layering, oneshot modifiers, and macros. In its most basic form it can be used to define a custom key layout that persists across display server boundaries (e.g wayland/X/tty). Why I'm packaging this: I converted my Chromebook to a normal laptop running Debian, and use keyd to work around the device's limited keyboard (no Home, End, PageUp, PageDown, or Del keys, among others). Unlike tools like xmodmap, keyd works at a low level (via Linux kernel interfaces evdev and uinput), so it works with X11, Wayland, and VTs without needing any environment-specific support. As far as I know, no existing Debian package provides similar low-level functionality. keyd's feature set overlaps with kmonad (https://github.com/kmonad/kmonad) which also merits packaging. I'm packaging keyd instead of kmonad because keyd is considerably simpler, and I'm unfamiliar with the Haskell ecosystem (kmonad is written in Haskell). I am not a DD or DM, so I would like some team or DD to volunteer to co-maintain and sponsor uploads. I'm not sure which team would be the best match; suggestions would be appreciated. Maybe the input method team (https://wiki.debian.org/Teams/IMEPackagingTeam) would be interested; I'll ping them if nobody has an alternative suggestion.
Bug#1059854: libdrm2: New upstream available for libdrm
Package: libdrm2 Version: 2.4.117-1 Severity: wishlist X-Debbugs-Cc: r...@ayottesoftware.com Dear Maintainer, A new upstream version of available for the libdrm2 package is available and needed to run Hyprland. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.8-rt-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libdrm2 depends on: ii libc6 2.38-2 ii libdrm-common 2.4.117-1 libdrm2 recommends no packages. libdrm2 suggests no packages. -- no debconf information
Bug#1059769: chkrootkit-daily : filtering out empty lines to prevent unnecessary empty alert emails.
On Sun, 31 Dec 2023 at 17:30, Franck Richter wrote:
> Currently chkrootkit-daily send me emails even if I ignore all false
> positives using chkrootkit.ignore.
> Because chkrootkit outputs empty lines that cannot be excluded via
> chkrootkit.ignore.
I havn't checked this, but: i think you can exclude blank lines using
chkrootkit.ignore - just add "^$" in there?
> It can be solved by adding to the filter in /etc/chkrootkit/chkrootkit.conf
> -e '/^$/d'
>
> ie replacing:
> FILTER="sed -re 's![[:alnum:]]+: PACKET
> SNIFFER\(((/lib/systemd/systemd-networkd|(/usr)?/sbin/(dhclient|dhcpc?d[0-9]*|wpa_supplicant|NetworkManager))\[[0-9]+\](,
> )?)+\)!: PACKET
> SNIFFER\([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID}\)!'
> -e 's/(! [[:alnum:]+-]+)\s+[0-9]+/\1 {PID}/'"
> by
> FILTER="sed -e '/^$/d' -re 's![[:alnum:]]+: PACKET
> SNIFFER\(((/lib/systemd/systemd-networkd|(/usr)?/sbin/(dhclient|dhcpc?d[0-9]*|wpa_supplicant|NetworkManager))\[[0-9]+\](,
> )?)+\)!: PACKET
> SNIFFER\([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID}\)!'
> -e 's/(! [[:alnum:]+-]+)\s+[0-9]+/\1 {PID}/'"
>
> Would it make sense to put that in default chkrootkit.conf ?
hmm. I'm not sure it would! The blank line there to separate output
from different tests, getting rid of it makes the output harder to
read, which doesnt seem like a good default. (There's of course
nothing wrong with you adding that to your systems, if you prefer it
--- but im not sure it's the best as a default for everyone)
I'd instead look at using:
- DIFF_MODE - then (whatever your other settings) you'd only see the
report once, until something changes
- RUN_DAILY_OPTS
a) including a -q which should suppress the blank line entirely.
b) you might be able to use -e or -s options - these are used by
chkrootkit and if all files are ignored that way, then no
'WARNING+list+blank line' would be produced tat all, whereas the
chkrootkit.ignore and other filtering are only done at the end
- tbh id also investigate why these files are being shipped by debian
at all, especially .gitignore looks like a mistake!
Bug#1057302: Bug#1057234: sbuild: Generates weird messages in /var/log/syslog
On Sun, 3 Dec 2023 00:06:23 +0100 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=
wrote:
> On 02.12.2023 08:30, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Hilmar Preusse (2023-12-01 23:10:36)
>
> Hi,
>
> >> I run sbuild as following:
> >>
> >> sbuild --no-run-lintian --arch-all --dist=sid *.dsc -d
> >> unstable-amd64-sbuild
> >>
> >> , where unstable-amd64-sbuild references a chroot. Updating the chroot is
> >> done:
> >>
> >> sudo sbuild-update -udcar unstable-amd64-sbuild
> >>
> >> Both commands generate weird messages in /var/log/syslog like this:
> >>
> >> 2023-12-01T09:36:52.230653+01:00 haka2 schroot[3182]: [unstable-
> >> amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot] (root->root)
> >> Running
> >> command: "perl -e #012use strict;#012
> >> use warnings;#012use POSIX;#012
> > it may also be an issue with schroot, no? I do not think sbuild at any point
> > tells schroot to write anything to syslog.
I think this is done by the calls to debug, eg here:
https://salsa.debian.org/debian/sbuild/-/blob/main/lib/Sbuild/Chroot.pm?ref_type=heads#L811
debug("Running command: ", join(" ", @$command), "\n");
debug() is defined at
https://salsa.debian.org/debian/sbuild/-/blob/main/lib/Sbuild.pm?ref_type=heads#L336
to print to STDERR, which systemd will then connect to the journal (i
don't know how this last bit works, i think
it happens from schroot - but the lines to write are generated by sbuild)
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-26 22:02, Martin-Éric Racine wrote: On Wed, Dec 27, 2023 at 5:54 AM Richard Laager wrote: On 2023-12-26 21:43, Martin-Éric Racine wrote: Looking at the diff for the Hurd port What Hurd port? https://deb.debian.org/debian-ports/pool-hurd-i386/main/n/ntp/ That is the wrong package (ntp vs ntpsec). That is not in any way relevant to this conversation. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-26 21:43, Martin-Éric Racine wrote: Looking at the diff for the Hurd port What Hurd port? -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-26 02:38, Martin-Éric Racine wrote:
On Mon, Dec 25, 2023 at 12:20 AM Richard Laager wrote:
If past me was correct, without systemd at build-time, waf will not
install the systemd units. Then we will end up with other failures in
debian/rules or from the .install files.
Not installing them on platforms where systemd has not been ported is
the correct action.
Agreed. My point was that additional work would be required, during the
package building process, to not blow up when those files are missing
from `waf install`.
It built enough to have ntpdate.
bin:ntpdate is just a transitional package to transition uses of the old
src:ntp's bin:ntpdate to src:ntpsec's bin:ntpsec-ntpdate. It is
Architecture: all, which is why it is available on Hurd.
In ntpsec, the ntpdate executable is just a thin wrapper around ntpdig,
which ships in the bin:ntpsec-ntpdig package (formerly, it was in
bin:ntpsec-ntpdate). While ntpdig is Python, so it doesn't actually
require compilation, it is presumably going to require some build steps
happen.
ifeq (hurd, $(DEB_HOST_ARCH_OS))
# hurd does not provided the system calls needed for ntpd to work.
exit 1
endif
I see a couple of ways forward here:
A) I properly indicate this package does not support HURD.
I think I would just replace the "Architecture: any" with
"Architecture: linux-any" on binary packages in debian/control, but
I would love confirmation on that.
Which is what this bug requested
I'm confused.
What you asked for was for me to limit "Build-Depends: systemd" to
[linux-any]. What I said here was that I'd limit all the built binary
packages to [linux-any], dropping any claims of support for HURD.
The rest of your email reads to me like you think this package should
support HURD to some degree. But here you are agreeing with the choice
that it should not support HURD _at all_.
I'm fine with dropping support for HURD entirely. I think that would be
more honest than the current state of affairs where the build just fails.
But if ntpdig is something that would be useful on HURD, I suppose it
would be nice if we could figure out how to make bin:ntpsec-ntpdig (and
some other packages) build for HURD.
If you are interested in HURD support, could you start with the attached
patch to ntpsec, try to build it, and see what happens?
--
Richard
diff --git a/debian/control b/debian/control
index a33a26ecb..2b1bc2a18 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@
python3,
python3-dev,
python3-gps,
- systemd,
+ systemd [linux-any],
xsltproc,
xz-utils,
Build-Conflicts: libavahi-compat-libdnssd-dev,
@@ -31,7 +31,7 @@
Homepage: https://www.ntpsec.org
Package: ntpsec
-Architecture: any
+Architecture: [linux-any]
Pre-Depends: ${misc:Pre-Depends},
Depends: adduser,
netbase,
diff --git a/debian/rules b/debian/rules
index dc23970f5..ff816974d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,10 +12,6 @@
dh $@ --with apache2,python3
override_dh_auto_configure:
-ifeq (hurd, $(DEB_HOST_ARCH_OS))
- # hurd does not provided the system calls needed for ntpd to work.
- exit 1
-endif
# Only build with refclocks NOT slated for removal. See also
# debian/patches/update-refclock-docs.patch. However, if the reason
# for deprecation is only "two digit years", I *am* keeping it.
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-12 04:52, Martin-Éric Racine wrote: Build-Depends: systemd must be changed to systemd [linux-any], since systemd has not been powerted to non-Linux platforms. I suspect that change would be necessary, but not sufficient. In commit 7f969a0ecab4ef3ab50defd4fe9d7e7a47817dbe, I wrote: Build-Depend on systemd This is required for the pkg-config file, so that waf will detect systemd and install the systemd units. If past me was correct, without systemd at build-time, waf will not install the systemd units. Then we will end up with other failures in debian/rules or from the .install files. HURD is the only non-Linux platform that Debian supports these days, right? kFreeBSD is gone, IIRC. The ntpsec package (like ntp before it, IIRC) does not build on HURD anyway. From debian/rules: ifeq (hurd, $(DEB_HOST_ARCH_OS)) # hurd does not provided the system calls needed for ntpd to work. exit 1 endif I see a couple of ways forward here: A) I properly indicate this package does not support HURD. I think I would just replace the "Architecture: any" with "Architecture: linux-any" on binary packages in debian/control, but I would love confirmation on that. B) Someone who cares about HURD figures out how much of this package can reasonably be expected to work and submits a patch. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058511: ntpsec: FTBFS: mv: cannot stat 'debian/tmp/lib/systemd/system/ntpd.service': No such file or directory
Control: fixed 1.2.2+dfsg1-3 This looks to be the same as #1052664. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058961: ntpsec: postinst should check for user:group before adding them
On 2023-12-18 16:15, Bob Proulx wrote: Package: ntpsec Version: 1.2.2+dfsg1-3 Severity: normal Tags: patch Every time the ntpsec package upgrades it attempts to unconditionally add the ntpsec user and group as per the following postinst snippet. addgroup --system --quiet ntpsec adduser --system --quiet --ingroup ntpsec \ --no-create-home --home /nonexistent ntpsec This logs errors because the user and group already exists. For the record, the "logs" here is critical. These errors show up in the logs, not on stdout. This is why I have never noticed this behavior until now (whether in ntpsec or just generally, having used adduser for years). Please test for the existence of those groups before creating them as other packages such as apt and others do. Adding the following "if" and "getent" checking fixes this using the same method the apt package and others do. if ! getent passwd ntpsec > /dev/null; then addgroup --system --quiet ntpsec fi if ! getent group ntpsec > /dev/null; then adduser --system --quiet --ingroup ntpsec \ --no-create-home --home /nonexistent ntpsec fi Those getent checks have passwd & group swapped, but otherwise, yes, that's what we want. I'll upload a fix shortly. Thanks! -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059273: missing path /var/lib/ntp/drift-tmp in apparmor.d/usr.sbin.ntpd
On 2023-12-22 05:32, Stefan Bauer wrote: Apparmor denies creation of /var/lib/ntp/drift-tmp. Where are you getting /var/lib/ntp/drift from? The ntpsec package in Debian has (from when both ntp and ntpsec existed in Debian) everything namespaced under "ntpsec". It uses /var/lib/ntpsec/ntp.drift in the default config file. Maybe you have something different set. What does "grep driftfile /etc/ntpsec/ntp.conf" say? -- Richard
Bug#1057570: libgnt: FTBFS: error: invalid use of incomplete typedef ‘PANEL’ {aka ‘struct panel’}
On 2023-12-20 09:57, Sven Joachim wrote: I have not tested it myself, but these errors should be fixed in libgnt 2.14.4 which has been released upstream the other day. See https://keep.imfreedom.org/libgnt/libgnt/rev/2da723f790d6, which explicitly mentions this bug. Thanks for letting me know! -- Richard
Bug#1058755: logcheck: Email not report log lines
control: close -1 thanks On Tue, 19 Dec 2023, 08:39 Stefano Callegari, wrote: > > > > The logs lines there are, but after the header I see many blank lines: I > > use mutt in a full screen console (more than 50 lines) and I need to > press > > page down for 16 times before reach the first line of logs (in the last > one > > email). > > > May be the problem is related with irqbalance. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058886 > https://bugs.launchpad.net/ubuntu/+source/irqbalance/+bug/2046470 > https://ubuntuforums.org/showthread.php?t=2493441=14169790 > > that loooks quite likely to be it - although trailing space does get removed, it looks like the lines end with lots of dashes. You can filter these lines like any other, and setting SORTUNIQ reduces duplication (a bit) > > If you think, close the bug. > thanks - yes the output looks normal. the "output" is actually on stderr so to save it, use ... 2>&1 or similar.
Bug#1058755: logcheck: Email not report log lines
On Sun, 17 Dec 2023 at 19:03, Stefano Callegari wrote: > Il Fri, Dec 15, 2023 at 11:31:18PM +0000, Richard Lewis scrisse: > > On Fri, 15 Dec 2023 at 16:06, Stefano Callegari > > wrote: > > > > > from few days the email from cron are empty, there is only the header.txt. > > > > > /etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -l > > > /var/log/syslog" logcheck > > > > > > the email has the log lines. Without the -l option, still empty. > > > > Seems like it isnt checking the syslog -- what is in the files in > > /etc/logcheck/logcheck.logfiles.d/ and logcheck.conf ? > > ~ <-bash> # ls /etc/logcheck/logcheck.logfiles.d/ > journal.logfiles syslog.logfiles [snip] -- everything you posted looked fine and standard to me: it should be checking both syslog and the journal as expected The only other thing you didn't include is a check of the permissions: there was a change in bookworm - i doubt that this is the issue, but for completeness: the directory /etc/logcheck should be owned by logcheck:logcheck and permissions: drwxr-x--- the contents should all be root:root and usual permissions, ie -rw-r--r-- (with subdirectories drwxr-xr-x) (as long permissions allow logcheck to read everything, it should all be fine) > > I suggest also using the -d option -- should say what it is doing in > > great detail (pipe to file or through less) > > I've tried! Many and many of lines, never ending, it seems a loop. I had to > do a ^C. Interesting - that definitely shouldnt happen, and '-d' shouldn't be doing anything 'extra' to cause that (is it definitely a loop or just looking like one because if your log contains lines that dont match any rules (will be reported in the email), logcheck has to check every single rules file, and -d will tell you the results before and after each rule file it uses: so it should look like it's printing the same output many times. to minimise the output, you can run once without -d, then do a 'logger foo' to ensure there's at lease one new line in the log and then re-run with -d) The only potential for a loop that i can immediately think of would be if you had some kind of symlink loop in the rules directory - do you have any symlinks in the ignore.d.server or similar dirs (check with ls -laR) i didnt think that could happen, i've no idea if logcheck would cope with that or not Can you provide the start of the -d output /enough to understand what the loop is? Otherwise, the start of the output should say what files it was checking, unfortunately, if there's an issue sending the issue, it likely wont be obvious until the very end. the only other thing i can think of is a disk space issue (i could imaging bad things happening if /tmp was full, or wherever the mta stores the email - /var or similar) (you could email it to me if you want to avoid it appearing in the public bts - up to you: i wouldnt expect there to be anything too sensitive in the logs, but i suppose we cant rule that out).
Bug#1058755: logcheck: Email not report log lines
On Fri, 15 Dec 2023 at 16:06, Stefano Callegari wrote: > from few days the email from cron are empty, there is only the header.txt. > /etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -l > /var/log/syslog" logcheck > > the email has the log lines. Without the -l option, still empty. Seems like it isnt checking the syslog -- what is in the files in /etc/logcheck/logcheck.logfiles.d/ and logcheck.conf ? Are you using systemd? I suggest also using the -d option -- should say what it is doing in great detail (pipe to file or through less) > /etc/logcheck/header.txt [Errno 13] Permesso negato: > '/etc/logcheck/header.txt' > /etc/logcheck/logcheck.conf [Errno 13] Permesso negato: > '/etc/logcheck/logcheck.conf' > /etc/logcheck/logcheck.logfiles [Errno 13] Permesso negato: > '/etc/logcheck/logcheck.logfiles' > /etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Permesso > negato: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles' > /etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Permesso negato: > '/etc/logcheck/logcheck.logfiles.d/syslog.logfiles' > > -- no debconf information >
