Bug#1077818: snmp-mibs-downloader: Consider adding RFC-1212, RFC-1215 and IANA-ENTITY-MIB
Hi Craig, Thanks for the update. I just tried the lastest package version, but it seems that RFC1212 and RFC1215 are still not generated. It seems that the RFC files included in the packages are not patched. > The IETF MIBs are shipped with the downloader, so I can include them > and then patch the RFC using the standard Debian quilt patching. Are you sure standard patching is applied for Debian native packages? IIRC that was only for non-native packages? > That must be some old switch, most MIBs these days do not use RFC-1212/1215 > but instead are based upon SNMPv2-SMI. > SNMPv2-SMI was originally defined in RFC-1442 in 1993, so what we are > dealing with is MIBs that are really old, or using the wrong > definition. I'm working with the Netgear GS324T introduced in 2019, so not a super old switch. On the support package, I can download a package of MIBS, which includes a (I assume) old version of BRIDGE-MIB that still depends on 1155/1212/1213/1215. Based on your remarks I did try using the newer BRIDGE-MIB from your package, and loading SMNPv2-MIB instead of RFC123-MIB from my code, and that also appears to work with this switch. I suspect that these newer MIBs define attributes that are not actually supported by the switch, but everything I need for my application [1] seems to work (with your 1.7 package, since AFAICS this does still need the IANA-ENTITY-MIB because I need ENTITY-MIB). [1]: https://github.com/matthijskooijman/netgear-vlan-admin Still, I would say it is good to make the package supply 1212/1215 as well, since that makes it more internally consistent. > My concern is that RFC-1212 has a circular dependency with RFC-1213 so > there might be an issue anyway. Ah, you mean that 1212 import DisplayString from 1158 (which is not shipped) but DisplayString is usually provided by 1213? Looking at the 1212 file supplied by Netgear, they commented out the RFC1158-MIB import from RFC-1212. With that, I can load the MIBs just fine. Also, if I manually extract RFC-1212 from the rfc file and *not* comment out the RFC1158-MIB import, it also works (likely because the parser handles imports lazily and 1213 defines DisplayString before using OBJECT-TYPE). This might be implementation dependent, though. I use the python snimpy package, which uses libsmi to parse MIB files. I also have only confirmed that the MIBs load correctly, not that the new OBJECT-TYPE macro is actually used (not sure how to check in my setup). I also tried with snmpwalk from Net-SNMP, which also seems to work (but that command also works when RFC-1212 does not exist, or when I specify non-existent MIB names on the commandline, so not sure how much this really tells us): snmpwalk -m ENTITY-MIB -m IF-MIB -m RFC1213-MIB -m BRIDGE-MIB -m Q-BRIDGE-MIB -v2c -c public 192.168.1.1 Gr. Matthijs signature.asc Description: PGP signature
Bug#1077818: snmp-mibs-downloader: Consider adding RFC-1212, RFC-1215 and IANA-ENTITY-MIB
Package: snmp-mibs-downloader Version: 1.6 Severity: wishlist Hi, I've been using snmp-mibs-downloader for getting MIB files for my netgear switch, but I'm running into problems because RFC-1212, RFC-1215 and IANA-ENTITY-MIB are not present. # RFC-1212 and RFC-1215 Looking at these rfcs, they are a bit different than most others. The RFC does not contain a full MIB with a "XXX DEFINITIONS ::= BEGIN", but instead offer a lot of textual advice and examples about how other RFCs could define their MIBs. However, these two RFCs do define macros (OBJECT-TYPE and TRAP-TYPE respectively), that *are* used by other MIBs: $ grep -R -B 1 RFC-1215 /usr/share/snmp/mibs /usr/share/snmp/mibs/ietf/RFC1382-MIB-TRAP-TYPE /usr/share/snmp/mibs/ietf/RFC1382-MIB:FROM RFC-1215 $ grep -R -B 1 RFC-1212 /usr/share/snmp/mibs | head -n 5 /usr/share/snmp/mibs/ietf/FDDI-SMT73-MIB-OBJECT-TYPE /usr/share/snmp/mibs/ietf/FDDI-SMT73-MIB:FROM RFC-1212; -- /usr/share/snmp/mibs/ietf/PPP-LCP-MIB- OBJECT-TYPE /usr/share/snmp/mibs/ietf/PPP-LCP-MIB: FROM RFC-1212; (15 more imports omitted) Also note that one reference is made to RFC1212 instead of RFC-1212 and since the RFC itself does not define the MIB name, this is not necessarily incorrect, but the consensus does seem to be to use RFC-1212: $ grep -R FROM.RFC1212 /usr/share/snmp/mibs | wc -l 1 $ grep -R FROM.RFC-1212 /usr/share/snmp/mibs | wc -l 17 See also: https://www.rfc-editor.org/rfc/rfc1212.txt https://www.rfc-editor.org/rfc/rfc1215.txt # Adding RFC-1212 and RFC-1215 Adding these to snmp-mibs-downloader might be a bit tricky - because the relevant definitions are not contained in an "XXX DEFINITIONS :: BEGIN" block, the current script cannot extract these definitions as-is. A pragmatic approach to this could be to add a PREDIFF config option that patches the downloaded RFC file before running smistrip, though that does require saving the RFC to a file to patch it, it seems that patch does not support patching stdin: https://unix.stackexchange.com/questions/737104/how-to-apply-a-patch-as-part-of-a-pipe-in-other-words-how-to-patch-stdin # IANA-ENTITY-MIB In addition to these RFCs, I'm also missing the IANA-ENTITY-MIB, which is referenced once: $ grep -R FROM.IANA-ENTITY-MIB /usr/share/snmp/mibs /usr/share/snmp/mibs/ietf/ENTITY-MIB:FROM IANA-ENTITY-MIB; -- RFC 6933 This one is easy - it is contained in RFC 6933 that also contains ENTITY-MIB, so this adding IANA-ENTITY-MIB is a matter of editing rfclist to: 6933ENTITY-MIB:IANA-ENTITY-MIB:UUID-TC-MIB Tried, works. Thanks, Matthijs -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble'), (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports'), (50, 'unstable-debug'), (50, 'testing-debug'), (50, 'oldstable-debug'), (50, 'unstable'), (50, 'stable'), (50, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-44-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 snmp-mibs-downloader depends on: ii patch 2.7.6-7build2 ii smistrip 0.4.8+dfsg2-16 ii wget 1.21.3-1ubuntu1.1 snmp-mibs-downloader recommends no packages. Versions of packages snmp-mibs-downloader suggests: ii unzip 6.0-28ubuntu1.1 -- Configuration Files: /etc/snmp-mibs-downloader/rfc.conf changed [not included] /etc/snmp-mibs-downloader/rfclist changed [not included] -- no debconf information
Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Hi James, > The relevant CMake file addition was sourced[1] from the LLVM codebase, which > is licensed under a variant of the Apache 2.0 license with some exception > clauses added for the LLVM project. This is not yet documented in the source > package. Thanks for pointing this out. It turns out I've failed to update the copyright file for some other included code as well. I'm preparing an upload to fix this now. > To explain my reasoning: On balance I'd prefer opening a serious-severity bug > to prevent migration (that could later be reduced in severity) than to allow > the package transition while being aware of a potential problem. Yes, makes sense! Gr. Matthijs signature.asc Description: PGP signature
Bug#1059296: hamster-time-tracker: CVE-2023-36250
forwarded 1059296 https://github.com/projecthamster/hamster/issues/750 thanks Hi Moritz, Thanks for bringing this to attention, this was not reported upstream yet. > https://github.com/BrunoTeixeira1996/CVE-2023-36250/blob/main/README.md > sounds a little bogus, I don't see how this crosses any security boundary? AFAICS it does not cross any boundary, but if it allows arbitrary commands to be executed when just importing a CSV file, that would still be unexpected and a security issue. I haven't looked at the code yet, but hope to do so in the common days. Let's keep further discussion about this upstream for now. Gr. Matthijs signature.asc Description: PGP signature
Bug#1053950: openttd: diff for NMU version 13.4-0.1
Hi Maytham, > Nice! It's not on the Salsa repo, so I'm assuming you're yet to push your > changes. Yup. I've justed pushed and uploaded! > Thanks for your quick responses, and thanks for maintaining this awesome > package! Looking forward to the new version. :) Thanks for your interest and effort as well! Gr. Matthijs signature.asc Description: PGP signature
Bug#1053950: openttd: diff for NMU version 13.4-0.1
Hi Maytham, > nmudiff (from devscripts) did that gigantic diff, but I've followed > your workflow in my fork of the repo at [1], if you want to just copy > the commits over (and change the Debian revision from -0.1 to -1). Ah, I already imported the tarball myself :-) > I've built it on my computer, and have ran it through the usual tests, > and the only issue is that Lintian says the override for the missing > man page is unnecessary. Yeah, that's because on build, lintian tests both the openttd and openttd-data package so it sees the manpage and thinks the override is unneeded, but it *is* actually needed when testing the packages in isolation. Gr. Matthijs signature.asc Description: PGP signature
Bug#1053950: openttd: diff for NMU version 13.4-0.1
Hi Maytham, > I've prepared an NMU for openttd (versioned as 13.4-0.1). The diff > is attached to this message. Thanks for your patch. I should have uploaded a new OpenTTD version a long time ago, so let met correct that by handling the update now. I'll go through my normal git-based workflow rather than using your NMU though, AFAICS you've made no changes to the packaging except import the upstream tarball, right? Gr. Matthijs signature.asc Description: PGP signature
Bug#1051970: vim: clicking tab character selects next character after tab
Small addendum, in case it helps tracking down the issue: quite curiously, clicking below a tab character on the last line of the buffer still works correctly, it selects the tab itself.
Bug#1051970: vim: clicking tab character selects next character after tab
Source: vim Version: 2:9.0.1378-2 Severity: normal X-Debbugs-Cc: matthijsvand...@gmail.com Dear Maintainer, Clicking anywhere in a tab character other than its leftmost column causes the cursor to be placed on the next character after the tab instead of putting it on the tab character itself. This is especially obnoxious in selection mode, e.g. say you have some tab-separated columns of text, e.g.: abc foo x bar If you now start block-selection mode on the topleft and try to select the first column of text using the mouse you'll end up also selecting the "f" of "foo" and "b" of "bar". This is a regression, it worked correctly in bullseye (vim 8.2.2434). I only use vim in text mode (xterm mouse) but gvim appears to be affected in the same way based on some quick testing. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1050165: [PATCH] Resolve missing newlines in libsmartcols
Hi, Here is a patch for 'libsmartcols' that corrects the "lsblk -M" omission of some newlines. -- Description: libsmartcols missing newlines The "scols_walk_is_last" function is not always correct, it should also test for the end of a group. Author: Matthijs Melchior Bug: Debian #1050165; https://github.com/util-linux/util-linux/issues/2446 Last-Update: 2023-09-09 --- --- a/libsmartcols/src/walk.c +++ b/libsmartcols/src/walk.c @@ -69,6 +69,8 @@ } if (is_tree_root(parent) && !is_last_tree_root(tb, parent)) return 0; + if (is_group_child(parent) && !is_last_group_child(parent)) + return 0; } if (is_group_child(ln) && !is_last_group_child(ln)) return 0; -- This has been tested with 'lsblk -M' and the output is now correct. All the other ls* commands from util-linux have no changes in their output. Regards, Matthijs. -- -- Matthijs MelchiorZeist mmelch...@xs4all.nlNetherlands --
Bug#1050165: lsblk: -M output format error
nk Size : 64K Consistency Policy : none UUID : fd10b6a3:681ea35e:b6a053df:c74767e7 Number Major Minor RaidDevice State 1 25900 active sync /dev/nvme0n1 0 25951 active sync /dev/nvme1n1 + lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:00 149G 0 disk ├─md123 9:123 0 149G 0 raid1 │ ├─md123p1259:60 70.6M 0 part │ ├─md123p2259:70 145.4G 0 part │ └─md123p3259:80 3.5G 0 part └─md124 9:124 0 0B 0 md sdb 8:16 0 149G 0 disk ├─md123 9:123 0 149G 0 raid1 │ ├─md123p1259:60 70.6M 0 part │ ├─md123p2259:70 145.4G 0 part │ └─md123p3259:80 3.5G 0 part └─md124 9:124 0 0B 0 md nvme0n1259:00 1.8T 0 disk ├─md125 9:125 0 585.9G 0 raid1 │ ├─md125p1259:10 1M 0 part │ ├─md125p2259:20 1G 0 part /boot/efi │ ├─md125p3259:30 1G 0 part /boot │ └─md125p4259:40 583.9G 0 part │ ├─mir-root 253:0064G 0 lvm / │ ├─mir-var 253:1032G 0 lvm /var │ ├─mir-swap 253:20 128G 0 lvm [SWAP] │ └─mir-home 253:30 256G 0 lvm /home ├─md126 9:126 0 2.5T 0 raid0 │ ├─stp-black 253:40 256G 0 lvm /backup/black │ └─stp-deb32 253:50 128G 0 lvm /backup/deb32 └─md127 9:127 0 0B 0 md nvme1n1259:50 1.8T 0 disk ├─md125 9:125 0 585.9G 0 raid1 │ ├─md125p1259:10 1M 0 part │ ├─md125p2259:20 1G 0 part /boot/efi │ ├─md125p3259:30 1G 0 part /boot │ └─md125p4259:40 583.9G 0 part │ ├─mir-root 253:0064G 0 lvm / │ ├─mir-var 253:1032G 0 lvm /var │ ├─mir-swap 253:20 128G 0 lvm [SWAP] │ └─mir-home 253:30 256G 0 lvm /home ├─md126 9:126 0 2.5T 0 raid0 │ ├─stp-black 253:40 256G 0 lvm /backup/black │ └─stp-deb32 253:50 128G 0 lvm /backup/deb32 └─md127 9:127 0 0B 0 md + echo Show formatting error and trailing spaces Show formatting error and trailing spaces + lsblk -M + sed 's/$/\$/' NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS$ ┌┈▶ sda8:00 149G 0 disk $ └┬▶ sdb8:16 0 149G 0 disk $ ├┈┈md123 9:123 0 149G 0 raid1 $ ┆ ├─md123p1259:60 70.6M 0 part $ ┆ ├─md123p2259:70 145.4G 0 part $ ┆ └─md123p3259:80 3.5G 0 part $ └┈┈md124 9:124 0 0B 0 md$ ┌┈▶ nvme0n1 259:00 1.8T 0 disk $ └┬▶ nvme1n1 259:50 1.8T 0 disk $ ├┈┈md125 9:125 0 585.9G 0 raid1 $ ┆ ├─md125p1259:10 1M 0 part $ ┆ ├─md125p2259:20 1G 0 part /boot/efi$ ┆ ├─md125p3259:30 1G 0 part /boot$ ┆ └─md125p4259:40 583.9G 0 part $ ┆├─mir-root 253:0064G 0 lvm /$ ┆├─mir-var 253:1032G 0 lvm /var$ ┆├─mir-swap 253:20 128G 0 lvm [SWAP]$ ┆└─mir-home 253:30 256G 0 lvm /home ├┈┈md126 9:126 0 2.5T 0 raid0 $ ┆ ├─stp-black 253:40 256G 0 lvm /backup/black$ ┆ └─stp-deb32 253:50 128G 0 lvm /backup/deb32 └┈┈md127 9:127 0 0B 0 md$ + echo Show desired output using sed to insert missing line breaks Show desired output using sed to insert missing line breaks + lsblk -M + sed 's|/home |/home\n |;s|/deb32 |/deb32\n |' NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS ┌┈▶ sda8:00 149G 0 disk └┬▶ sdb8:16 0 149G 0 disk ├┈┈md123 9:123 0 149G 0 raid1 ┆ ├─md123p1259:60 70.6M 0 part ┆ ├─md123p2259:70 145.4G 0 part ┆ └─md123p3259:80 3.5G 0 part └┈┈md124 9:124 0 0B 0 md ┌┈▶ nvme0n1 259:00 1.8T 0 disk └┬▶ nvme1n1 259:50 1.8T 0 disk ├┈┈md125 9:125 0 585.9G 0 raid1 ┆ ├─md125p1259:10 1M 0 part ┆ ├─md125p2259:20 1G 0 part /boot/efi ┆ ├─md125p3259:30 1G 0 part /boot ┆ └─md125p4259:40 583.9G 0 part ┆├─mir-root 253:0064G 0 lvm / ┆├─mir-var 253:1032G 0 lvm /var ┆├─mir-swap 253:20 128G 0 lvm [SWAP] ┆└─mir-home 253:30 256G 0 lvm /home ├┈┈md126 9:126 0 2.5T 0 raid0 ┆ ├─stp-black 253:40 256G 0 lvm /backup/black ┆ └─stp-deb32 253:50 128G 0 lvm /backup/deb32 └┈┈md127 9:127 0 0B 0 md -- Thanks, Matthijs Melchior.
Bug#1032857: please consider adding the jgrpp patches
Hey Toni, > please consider packaging the jgrpp patches, too. Thanks for your suggestion. What did you have in mind exactly? I won't include third-party patches in the main build, since that affects multiplayer compatibility (i.e. a patched build will be incompatible with other people playing unpatched builds). I could consider including a non-patched and a patched build side-to-side (i.e. in two different binary packages), but I'm not sure I want to go down this path either (this is just one set of patches, but I'm pretty sure there's others and before we know it we'll be packaging a dozen of different patch sets...). IMHO the right path to making these patches more accessible, is to submit them for inclusion upstream (possibly after improving the patch quality). So I'm inclined to close this as wontfix. Gr. Matthijs signature.asc Description: PGP signature
Bug#1034529: vim-runtime: perl subroutine body fails to indent in bookworm (regression from bullseye)
Package: vim-runtime
Version: 2:9.0.1378-1
Severity: normal
X-Debbugs-Cc: matthijsvand...@gmail.com
Dear Maintainer,
I noticed when editing perl code in vim that pressing enter after the
opening brace of a subroutine no longer indents like you'd expect:
// expected:
sub foo {
_<-- cursor here
// actual:
sub foo {
_<-- cursor here
This worked correctly in debian bullseye (vim 8.2).
The culprit appears to be that syntax/perl.vim has introduced
syn region perlSubDeclaration ...
which seems to confuse GetPerlIndent() in indent/perl.vim. If I add
tests for this region name the issue appears to be fixed:
@@ -133,6 +133,7 @@ function! GetPerlIndent()
\ || synid == "perlHereDoc"
\ || synid == "perlBraces"
\ || synid == "perlStatementIndirObj"
+\ || synid == "perlSubDeclaration"
\ || synid =~ "^perlFiledescStatement"
\ || synid =~ '^perl\(Sub\|Block\|Package\)Fold'
let brace = strpart(line, bracepos, 1)
@@ -151,6 +152,7 @@ function! GetPerlIndent()
\ || synid == "perlMatchStartEnd"
\ || synid == "perlBraces"
\ || synid == "perlStatementIndirObj"
+\ || synid == "perlSubDeclaration"
\ || synid =~ '^perl\(Sub\|Block\|Package\)Fold'
let ind = ind - shiftwidth()
endif
But beware that I don't really know how this function works or whether
this is a correct fix, it was just a random guess that seemed to produce
the desired result.
The issue can alternatively be fixed by reverting the
" Functions
...various perlSub* match rules...
syn match perlFunction ...
section of syntax/perl.vim to its previous (vim 8.2) version, except
with perlSignature renamed to perlSubSignature to ensure it gets
highlighted correctly.
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
vim-runtime depends on no packages.
Versions of packages vim-runtime recommends:
ii vim-gtk3 [vim] 2:9.0.1378-1
vim-runtime suggests no packages.
-- no debconf information
Bug#1027860: hamster-time-tracker: cannot start because module 'gettext' has no attribute 'bind_textdomain_codeset'
forwarded 1027860 https://github.com/projecthamster/hamster/issues/710 thanks Hi, > AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset' Thanks for reporting this. There is also an upstream issue about this, with a suggested workaround: https://github.com/projecthamster/hamster/issues/710 Gr. Matthijs signature.asc Description: PGP signature
Bug#793749: RFP: telegraf -- plugin-driven server agent for reporting metrics into InfluxDB
Package: wnpp Followup-For: Bug #793749 FYI: It seems that Ubuntu has started packaging telegraf in 2020: https://packages.ubuntu.com/source/kinetic/telegraf http://changelogs.ubuntu.com/changelogs/pool/universe/t/telegraf/telegraf_1.22.3+ds1-0ubuntu1/changelog
Bug#1013356: fzf: Bash completions not active by default
Package: fzf Version: 0.30.0-1+b1 Severity: normal Hi, README.Debian says: Note, since fzf 0.29.0-1, the bash completion is installed for bash by default. Feel free to ignore the following instruction for fzf >= 0.29.0-1. It seems this means that the completion is installed as /usr/share/bash-completion/completions/fzf However, completions from that directory are not loaded by default, but are loaded dynamically when the user tries to complete arguments to their command. See e.g.: https://salsa.debian.org/debian/bash-completion/-/blob/master/bash_completion#L2175 In practice, this means that in a new shell, doing "cd **" does not offer completion. If I then do "fzf ", the completion is loaded, and after that "cd **" *does* offer fzf completion. This was tested on Ubuntu 22.04, but with the sid version of fzf (0.30.0-1+b1) and bash-completion (2:2.11-6), so I'm assuming the same behavior happens on Debian. I'm not sure if there is a way for the package to bypass this dynamic loading and have a snippet be loaded automatically (other than putting a file in `/etc/bash_completion.d`, but that seems to be for compatibility only). What does seem to work is to load it explicitly in `~/.bashrc`: source /usr/share/bash-completion/completions/fzf So maybe that chould be documented? Gr. Matthijs -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports'), (50, 'unstable-debug'), (50, 'testing-debug'), (50, 'stable-security'), (50, 'stable-debug'), (50, 'unstable'), (50, 'testing'), (50, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-25-generic (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1010659: systemd-networkd LLDP transmit broken since v250
Package: systemd Version: 250.4-1 Severity: normal Tags: patch upstream X-Debbugs-Cc: matthijsvand...@gmail.com Dear Maintainer, Since systemd v250 (bookworm/testing), the LLDP packets transmitted by systemd-networkd (with EmitLLDP=on) are malformed, causing debian systems running bookworm to be unidentifiable by managed switches. This is a regression relative to v247 (bullseye/stable). The issue has been fixed upstream in git: https://github.com/systemd/systemd/commit/b0221bb6a468e84841ad366ff39dcc4de97dc5db
Bug#964906: This is still an issue in 11.2
I ran into this same problem. The workarounds suggested here seemed really hacky so I tried to dig a bit deeper for a proper solution... I found the "btrfs device ready $DEV" command which is equivalent to "btrfs device scan $DEV" except it only has exit code 0 if all devices that are part of the same filesystem are known to the kernel, implying it is ready to be mounted. Note that contrary to what the btrfs-device manpage and "btrfs device --help" say it does not actually wait for this condition, it merely checks and exits. I also found that udev has a "btrfs ready" builtin which is used by /lib/udev/rules.d/64-btrfs.rules to set the ID_BTRFS_READY property based on this same criterion, and it also sets SYSTEMD_READY=0 until the filesystem is ready, which causes systemd to pretend the device doesn't exist yet. I tried testing the ID_BTRFS_READY property in an initramfs script but for some reason it doesn't seem to get set, even though udev should be running if I understand correctly. I didn't get around to try using "btrfs device ready" since I found a much easier workaround: apt-get install dracut apt-get purge initramfs-tools-core Matthijs van Duin
Bug#1003269: openttd: typo in suggested timidity package
Hey Daniel, > timidity was recommended but now timdity is suggested instead Bugger. I've fixed this locally, will be included in the next upload (but I'm not going to reupload just for this, I think). Thanks for reporting! Gr. Matthijs signature.asc Description: PGP signature
Bug#1002952: build-rdeps: Inconsistent defaults on Ubuntu (or other non-Debian systems)
Package: devscripts
Version: 2.21.7
Severity: normal
Hi,
I was trying to use build-rdeps on Ubuntu today, and the default settings seem
unusable there. I tried both the Ubuntu version from impish and the Sid
version, both with the same result:
$ sudo build-rdeps -d dh-cmake
DEBUG: Package => dh-cmake
DEBUG: running with dose-ceve resolver
DEBUG: buildarch=amd64 hostarch=amd64
DEBUG: Running 'apt-get' 'indextargets' 'DefaultEnabled: yes' 'Origin:
Debian'
build-rdeps: unable to find sources files.
Did you forget to run apt-get update (or add --update to this command)?
at /usr/bin/build-rdeps line 520.
Looking at the source code, I see that there does seem to be some code
in place to handle non-Debian vendors as well, but I think this does not
work well currently.
By default, the script only looks at sources that have 'Origin: Debian',
regardless of what the current system is:
https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/build-rdeps.pl#L157
my $opt_origin = 'Debian';
However, it then further limits sources to "development" releases only:
https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/build-rdeps.pl#L227
sub is_devel_release {
my $ctrl = shift;
if (get_current_vendor() eq 'Debian') {
return $ctrl->{Suite} eq 'unstable' || $ctrl->{Codename} eq 'sid';
} else {
return $ctrl->{Suite} eq 'devel';
}
}
In this case, it *does* use the current vendor to determine the default
release to check for, meaning running build-rdeps without additional
options on non-Debian systems will never work (not even if you have
Debian deb-src lines in your sources.list as I have).
It seems like adding an explicit --origin Ubuntu would help here,
except:
- Using a "devel" release of Ubuntu is apparently not a common practice
(anymore):
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1728616/comments/2
- If you *do* use e.g. `deb-src http://archive.ubuntu.com/ubuntu/ devel main`,
this produces "Release: devel", not "Suite: devel", so the current
code still does not match.
More generally, I wonder if build-rdeps should really limit itself to a
devel release only. This poses an additional requirement on your
sources.list (you need to have deb-src for sid or devel), which is not
documented in the manpage and not hinted at by the error message.
I can imagine it would *favor* unstable/devel if available (or maybe
testing if unstable is not found) , but fall back to the most recent
release (based on the Version field), or failing that, *any* available
src release instead?
As for the conflicting defaults, I can imagine:
- Adding a --vendor option, defaulting to Dpkg::Vendor::get_current_vendor()
- Pick the Origin based on the vendor (and maybe apply no origin limit
for unknown vendors)
- Pick the default distribution based on the vendor, like now (but
checking against Release: devel instead of Suite:devel
Alternatively, if the "priority"-based scheme suggested above is
implemented, maybe there is no need at all to switch the distribution
based on the vendor at all. If you just apply a priority to each release
(sid/unstable/devel get max priority, testing nearly max priority,
others based on Version) this works regardless of the current vendor,
and you can switch between vendors based on the Origin (which should
probably still switch its default based on the vendor).
Note that there is also the matter of the list of components being
hardcoded currently, but that is already the subject of #913551.
As for making the current version work, what I can now do is:
- Add a Ubuntu "devel" release to sources.list, patch build-rdeps to
check Release: devel instead of Suite: devel, and run with `--origin
Ubuntu".
- Run with "--origin Ubuntu --distribution impish" (or whatever distro
you're using).
- Add "sid" sources to sources.list, and run with `--distribution sid`.
Gr.
Matthijs
-- Package-specific info:
--- /etc/devscripts.conf ---
Empty.
--- ~/.devscripts ---
Not present
-- System Information:
Debian Release: 11.0
APT prefers jammy
APT policy: (500, 'jammy'), (500, 'impish-updates'), (500,
'impish-security'), (500, 'impish'), (100, 'impish-backports'), (50,
'unstable-debug'), (50, 'testing-debug'), (50, 'stable-security'), (50,
'stable-debug'), (50, 'unstable'), (50, 'testing'), (50, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.13.0-22-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/da
Bug#1002944: build-rdeps: Shows unfriendly errors when deb-src lines are missing
Package: devscripts Version: 2.21.7 Severity: normal Hi, when running build-rdeps without deb-src lines in sources.list, it produces perl errors, rather than providing useful feedback. This also happens when a deb-src line is present for the main packages, but missing for debug packages. E.g. with these sources: deb http://ftp.nl.debian.org/debian/ sid main non-free contrib deb http://deb.debian.org/debian-debug/ unstable-debug main I get: $ sudo build-rdeps -d dh-cmake --distribution sid DEBUG: Package => dh-cmake DEBUG: running with dose-ceve resolver DEBUG: buildarch=amd64 hostarch=amd64 DEBUG: Running 'apt-get' 'indextargets' 'DefaultEnabled: yes' 'Origin: Debian' Reverse Build-depends in main: -- Use of uninitialized value $source_file in concatenation (.) or string at /usr/bin/build-rdeps line 336. DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg --deb-native-arch=amd64 deb:///var/lib/apt/lists/deb.debian.org_debian-debug_dists_unstable-debug_main_binary-amd64_Packages debsrc://Fatal error in module dose_common.input: Input file does not exist. No reverse build-depends found for dh-cmake. Reverse Build-depends in main: -- Use of uninitialized value $source_file in concatenation (.) or string at /usr/bin/build-rdeps line 336. DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg --deb-native-arch=amd64 deb:///var/lib/apt/lists/ftp.nl.debian.org_debian_dists_sid_main_binary-amd64_Packages debsrc://Fatal error in module dose_common.input: Input file does not exist. No reverse build-depends found for dh-cmake. Reverse Build-depends in contrib: -- Use of uninitialized value $source_file in concatenation (.) or string at /usr/bin/build-rdeps line 336. DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg --deb-native-arch=amd64 deb:///var/lib/apt/lists/ftp.nl.debian.org_debian_dists_sid_contrib_binary-amd64_Packages debsrc://Fatal error in module dose_common.input: Input file does not exist. No reverse build-depends found for dh-cmake. Reverse Build-depends in non-free: -- Use of uninitialized value $source_file in concatenation (.) or string at /usr/bin/build-rdeps line 336. DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg --deb-native-arch=amd64 deb:///var/lib/apt/lists/ftp.nl.debian.org_debian_dists_sid_non-free_binary-amd64_Packages debsrc://Fatal error in module dose_common.input: Input file does not exist. No reverse build-depends found for dh-cmake. Looking at the source, it seems that collectfiles() looks at Sources files, but also Packages to find the arch. So for dists without a deb-src line, this lets collectfiles() return entries that have an `Architecture` field, but no `sources` field, This is probably easy to fix by just letting findreversebuilddeps() check for missing `sources` and showing an appropriate message. Gr. Matthijs -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- Not present -- System Information: Debian Release: 11.0 APT prefers impish-updates APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 'impish'), (100, 'impish-backports'), (50, 'testing-debug'), (50, 'stable-security'), (50, 'stable-debug'), (50, 'unstable'), (50, 'testing'), (50, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-22-generic (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.20.9ubuntu2 ii fakeroot 1.25.3-1.1ubuntu2 ii file 1:5.39-3 ii gnupg 2.2.20-1ubuntu4 ii gnupg22.2.20-1ubuntu4 ii gpgv 2.2.20-1ubuntu4 ii libc6 2.34-0ubuntu3 ii libfile-dirlist-perl 0.05-2 ii libfile-homedir-perl 1.006-1 ii libfile-touch-perl0.11-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20200505.0-1 ii libmoo-perl 2.004004-1 ii libwww-perl 6.53-1 ii patchutils0.4.2-1 ii perl 5.32.1-3ubuntu3 ii python3 3.9.4-1build1 ii sensible-utils0.0.14 ii wdiff 1.2.2-2build2 Versions of packages devscripts recommends: ii apt 2.3.9 ii curl7.74.0-1.3ubuntu2 ii dctrl-tools 2.24-3 ii debian-keyring 2021.09.25 ii dput1.1.0ubuntu2 ii dupload 2.9.6 ii equivs
Bug#1002913: openttd: FBTFS
Hi Aurelien, Thanks for reporting, I had already seen the failure and am working on a fix, probably next weekend. The issue is caused by the buildds building arch and arch-indep separately, which exposes a problem in the rules file, but I hadn't tested this scenario before upload. Gr. Matthijs signature.asc Description: PGP signature
Bug#984158: grfcodec: diff for NMU version 6.0.6-5.1
Hi Adrian, It took a while longer than anticipated, because of a problem with last month's keyring update, but that has now been resolved, so my uploads have come through. > packages without valid signature are usually silently dropped, > expect that you might have to reupload. Maybe packages with an expired signature are handled differently, since my packages were processed without reupload now. Thanks again for your interest and time! Gr. Matthijs signature.asc Description: PGP signature
Bug#984158: grfcodec: diff for NMU version 6.0.6-5.1
Hi Adrian, > I've prepared an NMU for grfcodec (versioned as 6.0.6-5.1) and uploaded > it to DELAYED/15. Please feel free to tell me if I should cancel it, or > to use the changes for a maintainer upload instead. Thanks for your interest and picking this up! However, I had actually *just* uploaded a new version myself yesterday, but it seems they are not picked up. I suspect this is because my gpg key expired and the validity extension I did a while ago isn't picked up by the keyring yet. As soon as it is, I expect my pending packages will be processed. See also https://salsa.debian.org/openttd-team/grfcodec/-/commits/master/ I suspect it would be best to cancel your upload, and use my version instead. Gr. Matthijs signature.asc Description: PGP signature
Bug#984158: grfcodec: ftbfs with GCC-11: Fixed upstream
forwarded 984158 https://github.com/OpenTTD/grfcodec/issues/12 tags 984158 fixed-upstream thanks Hi Matthias, thanks for reporting this issue. I've forwarded it upstream and they have fixed it, should be included in their next release (6.0.7 or 6.1.0). Gr Matthijs signature.asc Description: PGP signature
Bug#780280: dak: generate rejection mail for mails with expired signature
Hey folks, this issue still seems to exist, I just discovered that an upload I did three months ago was never processed because I forgot to push my extended key to Debian, which is a bit of a bummer. Gr. Matthijs signature.asc Description: PGP signature
Bug#980641: nml: builds with patch
Hi Phil, > Indeed, I've cleaned up my local test and pushed to salsa: > > https://salsa.debian.org/emorrp1/nml/-/commit/27c0aea7cd2670462c24246caf510d7dd8cb99dd Thanks! I think to be really correct, though, I'd have to backup the old files and restore them on clean (or maybe make a copy of the entire regression directory and run tests in there). > > I'll see if upstream maybe wants to do a release with these changes > > included, might be the easiest route... > > With 84 commits to master, I'm not convinced that would qualify for an > unblock. Hm, I hadn't really thought about the freeze. Seems we're still in soft freeze, and this not a very high-profile package, so I don't think a manual unblock is needed yet, but looking at the git log, it seems it's not just a few small fixes, also new features and refactors that might not be appropriate in this stage, so maybe better to backport the fix indeed. I also just noticed that I missed the nml 0.5.3 release in september. Given that's just a few changes, mostly for compatibility, I'm inclined to still include that release in my next upload, even with the freeze. Gr. Matthijs signature.asc Description: PGP signature
Bug#980641: nml: builds with patch
Hi Phil, Mathias, Thanks for your interest in nml and your effort in getting this bug squashed :-) > It would be a shame if openttd got autorm'ed just as the bullseye > freeze starts in earnest. Yeah, I'll make sure that doesn't happen. > Upstream have re-exported the pcx files and I can confirm nml now builds > correctly with these 3 files copied into place before tests. Cool, thanks for confirming. It would be obvious to just backport these changes, but I think the quilt patches used by the Debian patches cannot represent changes to binary files, so it would be a bit more hassle (probably needs some scripting in debian/rules) to include these changes. I'll see if upstream maybe wants to do a release with these changes included, might be the easiest route... Gr. Matthijs signature.asc Description: PGP signature
Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120
...and my (probably) final report to this mailing list: The most recent crashes/hangs I experienced have no relation to Debian release or Linux kernel, but most likely a hardware issue. I initially experienced a crash similar to what the original report in this bug-thread showed. Suspecting that the old machine was dying of old age, I replaced it with a new machine - and got a similar crash with that one as well. Later on - after having a newer kernel installed that probably solved the original bug - I got a few times a crash/hanging system without any kernel messages and suspected this to be caused by the same bug. This was likely a wrong assumption: in the past few days I've ran Memtest86-pro for two days straight - and the system is hanging now after 39hours testing. Since this Memtest86 is started from USB, it means that the OS is not involved. So, on to hardware debugging. I'm OK with closing this bug. Matthijs
Bug#975528: libinput-tools: debug-gui command not available
Package: libinput-tools Version: 1.15.5-1ubuntu0.1 Severity: normal Hi, the manpage, `libinput --help` output and upstream [1] document a `libinput debug-gui` command, but that does not seem to be available: $ libinput debug-gui libinput: debug-gui is not a libinput command or not installed. See 'libinput --help' $ libinput --help |grep -A 1 gui debug-gui Display a simple GUI to visualize libinput's events. I've tested this on Ubuntu, but looking at the `libinput-tools` file list [2] for 1.16.3-1 from unstable, it seems that `libinput` subcommands are shipped as separate binaries, but `debug-gui` is indeed not included, so I'm assumning this is not Ubuntu-specific. [1]: https://wayland.freedesktop.org/libinput/doc/latest/tools.html#libinput-debug-gui [2]: https://packages.debian.org/sid/amd64/libinput-tools/filelist Gr. Matthijs -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (990, 'focal-updates'), (990, 'focal-security'), (990, 'focal-backports'), (990, 'focal'), (50, 'unstable'), (50, 'testing'), (50, 'stable'), (50, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-52-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libinput-tools depends on: ii libc6 2.31-0ubuntu9.1 ii libevdev2 1.9.0+dfsg-1 ii libinput101.15.5-1ubuntu0.1 ii libudev1 245.4-4ubuntu3.3 ii python3 3.8.2-0ubuntu2 ii python3-libevdev 0.5-1 ii python3-pyudev0.21.0-3ubuntu1 libinput-tools recommends no packages. libinput-tools suggests no packages. -- no debconf information
Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120
Unfortunately, my machine crashed again last night. No special activity, no stressing things going on - just full 100% standstill. Nothing visible in either syslog or kern.log. On screen just the regular login prompt (no GUI, just terminal login) but the cursor was absent and the system didn't react to keyboard. So, also unfortunately, no error log or crash information at all. So don't know if the crashes I experience are in any way related to this kernel bug #968335 Any suggestions how I can get any further information out of this system in future crashes? Kind regards, Matthijs
Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120
Unfortunately, I seem to be suffering from the same issue. Initially I thought it was a hardware issue (system was ~10 years old), so I replaced the Intel DH67CF with core2duo processor by an Asrock H470M-ITX and Intel i5-10400 processor (and new case, new power supply; only SSD is re-used). A screenshot I made of a kernel crash ~3 weeks ago showed the same message as in the original bug report. With the new hardware, I suffered from a crash this weekend (still the 4.19.0-10-amd64 kernel). I wasn't able to reproduce the issue at will - it just happened randomly, it seems. But I did have the impression that, at least on three times, it happened when another Debian box was booted and made an NFS connection to the problematic machine. So could be ethernet related. And to agree with Mike above: indeed, I have a docker container operational. So far with the new kernel, no crash yet - but I did get this kernel call trace: Sep 30 08:24:30 vanaalten kernel: [159962.295249] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.19.0-11-amd64 #1 Debian 4.19.146-1 Sep 30 08:24:30 vanaalten kernel: [159962.295338] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H470M-ITX/ac, BIOS P1.20 05/18/2020 Sep 30 08:24:30 vanaalten kernel: [159962.295348] RIP: 0010:cpuidle_enter_state+0xb9/0x320 Sep 30 08:24:30 vanaalten kernel: [159962.295352] Code: e8 9c b5 b0 ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 ce a7 b6 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3 Sep 30 08:24:30 vanaalten kernel: [159962.295354] RSP: 0018:be03019a3e90 EFLAGS: 0246 ORIG_RAX: ffde Sep 30 08:24:30 vanaalten kernel: [159962.295358] RAX: 9c1bcf5620c0 RBX: 917c1fc829ea RCX: 001f Sep 30 08:24:30 vanaalten kernel: [159962.295360] RDX: 917c1fc829ea RSI: 2c13c01d RDI: Sep 30 08:24:30 vanaalten kernel: [159962.295362] RBP: 9c1bc4d13000 R08: 0002 R09: 00021980 Sep 30 08:24:30 vanaalten kernel: [159962.295363] R10: 0001a685134b4b1d R11: 9c1bcf5610a8 R12: 0003 Sep 30 08:24:30 vanaalten kernel: [159962.295365] R13: 94aba518 R14: 0003 R15: Sep 30 08:24:30 vanaalten kernel: [159962.295368] FS: () GS:9c1bcf54() knlGS: Sep 30 08:24:30 vanaalten kernel: [159962.295370] CS: 0010 DS: ES: CR0: 80050033 Sep 30 08:24:30 vanaalten kernel: [159962.295372] CR2: 561438923229 CR3: 0001ef40a006 CR4: 003606e0 Sep 30 08:24:30 vanaalten kernel: [159962.295374] Call Trace: Sep 30 08:24:30 vanaalten kernel: [159962.295386] do_idle+0x228/0x270 Sep 30 08:24:30 vanaalten kernel: [159962.296362] cpu_startup_entry+0x6f/0x80 Sep 30 08:24:30 vanaalten kernel: [159962.296367] start_secondary+0x1a4/0x200 Sep 30 08:24:30 vanaalten kernel: [159962.296373] secondary_startup_64+0xa4/0xb0 ...but the system is still fully operational. No idea how serious above call trace is. Hopefully no further crashes. -- Matthijs
Bug#905866: uscan: prefers watch files from a random dir over debian/watch
Hey Mattia, > Thank you for this, I've now merged it. Thanks! > Also, I personally hate changing long-standing defaults. Yeah, I can see that. > > Maybe the default could be changed to only scan the current directory > > *if* it is a debian source tree, and default to recursive scanning if > > not? That would support both the "Run on a single package" and "Run on a > > collection of packages" usecases neatly? > > That's too surprising. Changing behaviour that way just due to the > surrounding files is too unexpected for me. It might end up doing the right thing in most cases, but I can see it could also be surprising, which is indeed a downside of this approach. > Regardless, I'd accept an MR that would implement: Ok, sounds good. I'd like to submit such a MR, but it's highly likely that I'll not find the time in the near future, or maybe not at all, so if anyone else wants to do this, feel free. > Also perhaps add a relevant config item that would switch the default > locally, so that one can set, e.g., USCAN_RECURSIVE=no in their > ~/.devscripts and have it re-enabled with --recursive as needed. That also sounds like a good idea, that at least allows people to change their own defaults. > > One open question is what constitutes a "source tree" exactly for the > > purpose of the default operation. > > [ -f debian/changelog -a -f debian/watch ] should do IMHO. Without > parsing, it would just fail a few moments later anyway. Given you do not want to change the default as I suggested, I think this question is not actually relevant anymore. Gr. Matthijs signature.asc Description: PGP signature
Bug#926455: mail_autoremovals: incorrect version number in email warning
Package: release.debian.org Followup-For: Bug #926455 Hi, I also ran into this today. To me, it seems the observable problem is not so much an incorrect version number in the email warning, but the fact that the email warning is sent out at pretty much exactly the moment the autorm for a package is *cleared*, which makes it a very confusing email. The version number in there is also wrong, or at least contains the version that fixed the bug that caused autorm, indeed. I noticed this for the grfcodec package: Date: Mon, 17 Aug 2020 04:39:06 + From: Debian testing watch To: grfco...@packages.debian.org Subject: grfcodec 6.0.6-5 MIGRATED to testing FYI: The status of the grfcodec source package in Debian's testing distribution has changed. Previous version: 6.0.6-4 Current version: 6.0.6-5 Date: Mon, 17 Aug 2020 04:39:05 + Subject: grfcodec is marked for autoremoval from testing grfcodec 6.0.6-5 is marked for autoremoval from testing on 2020-09-11 It is affected by these RC bugs: 957307: grfcodec: ftbfs with GCC-10 https://bugs.debian.org/957307 Looking at the mailer script [1], it seems it tracks the most recent autorm email notification timestamp (to make sure to send out a notification only every 20 days) for each package version separately. So this makes me suspect that when a package migrates to testing that is subject to autorm: 1 the new version is first inserted into the `testing_autoremovals` table 2 the mail_autoremovals.pl script runs, sees this new version for which no notification was sent before, so immediately sends out a mail notification 3 the autorm status is cleared for the package, because the fixing version was migrated to testing I'm not quite sure where all this is orchestrated, so I couldn't check this in any code (other than the mail_autoremovals.pl code). Also, I can't remember seeing this behaviour before for packages where autorm was cleared by an upload, so I suspect that there might be a race condition between two processes here. Regardless, it seems that the new, fixing, version should *never* end up in the `testing_autoremovals` table, since that version is really never subject to autorm AFAICS. So if my analysis is correct, maybe that's something that can be fixed? Gr. Matthijs [1]: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Bug#967933: ant-optional: Missing ant-junitlauncher.jar
Package: ant-optional Version: 1.10.6-1ubuntu0.1 Severity: normal Hi, I'm trying to run junit-based tests for the JOSM application using ant, which does not work out of the box. The error I'm getting is: build.xml:491: The following error occurred while executing this line: build.xml:442: Problem: failed to create task or type junitlauncher Cause: the class org.apache.tools.ant.taskdefs.optional.junitlauncher.confined.JUnitLauncherTask was not found. Which suggests the org.apache.tools.ant.taskdefs.optional.junitlauncher.confined package is missing, which was added in ant 1.10.6 [1]. I'm not entirely familiar with this ecosystem, but I *think* this package is supplied by upstream (the java sources are present in the Debian source package) and should result in an ant-junitlauncher.jar file, which I think should be shipped in the ant-optional Debian package. However, that jar is not contained in any Debian package AFAICS. It seems there is an explicit whitelist of jar/pom files to install, and this new jar was probably forgotten when it was added upstream? Note that I tested on a slightly older Ubuntu version, but it seems the newest Debian version has the same problem. If my analysis is correct, could you make the changes so ant-junitlauncher is included? Gr. Matthijs [1]: https://ant.apache.org/manual/api/org/apache/tools/ant/taskdefs/optional/junitlauncher/confined/package-summary.html
Bug#923077: pyzor: crashes on certain emails
Package: pyzor Version: 1:1.0.0-3 Followup-For: Bug #923077 Hi, this problem is reported upstream as https://github.com/SpamExperts/pyzor/issues/64 and in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/pyzor/+bug/1852433 It is fixed in upstream master, but not included in any release yet. People have been asking for a new release (https://github.com/SpamExperts/pyzor/issues/54) but if that does not come along soon, maybe this fix would be worthwile to backport? It's just a oneline change (see upstream bug). Gr. Matthijs
Bug#875733: same with buster
> Has anybody succeeded in running systemd inside an LXC container with > "lxc.cap.drop = sys_admin" ? Yup, on a Buster system, I'm using this config, which works: https://github.com/daenney/Tika/blob/tika-host/etc/lxc/login/config Not sure what the essential part is, but maybe you can compare this with your own config and make it work from there. Gr. Matthijs signature.asc Description: PGP signature
Bug#961223: gnome-terminal: New terminal button default settting does not work, always in a tab.
Package: gnome-terminal Version: 3.36.2-1 Severity: normal Tags: upstream Dear Maintainer, The "Preferences-General" dialogue offers the option "Open new terminal in:" with choises "Window" or "Tab". This setting is not used when clicking the "+" button at the left top. My expectation was that it would invert the action of the "ctrl" key while clicking the "+" button: click to get a new window and ctrl-click to get a new tab. Thanks. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dbus-x11 [dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gnome-terminal-data 3.36.2-1 ii gsettings-desktop-schemas 3.36.1-1 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-8 ii libdconf1 0.36.0-1 ii libglib2.0-0 2.64.2-1 ii libgtk-3-03.24.20-1 ii libpango-1.0-01.44.7-4 ii libuuid1 2.35.1-5 ii libvte-2.91-0 0.60.2-1 ii libx11-6 2:1.6.9-2+b1 Versions of packages gnome-terminal recommends: ii gvfs 1.44.1-1 ii nautilus-extension-gnome-terminal 3.36.2-1 ii yelp 3.36.0-1 gnome-terminal suggests no packages. -- no debconf information
Bug#960419: dh_link: Add option to check for identical file contents before replacing
Hey Niels, > As far as I can tell, the underlying desire is to do some form of > deduplication. Yes, indeed. > If so, then I think this is similar to #888397 with an expanded scope > and a proposal for doing this via dh_link (rather than dh_installdocs > or a new helper). I guess my proposal is actually more narrow and specific. That other report asks about more generic deduplication (run on the entire package, or maybe a subset of files) that automatically finds duplicate files. I guess that could be useful, but is also quickly a lot more complicated (more work to find duplicates, which is the canonical one, any exceptions). I'm also less inclined to completely automate this, I'd rather make some more explicit choices (though something like "link files in *this* directory to *that* directory if you find duplicates" could be a nice compromise between automatic and manual work, maybe). Regardless, my suggestion would allow manual and explicit deduplication to become a bit easier, at the expense of having to manually track the list of duplicate files on upstream changes (but with my suggestions, detecting files that are no longer duplicated is automatic, and lintian can I think already detect *new* duplicate files, so together that would allow adequately fixing all duplicates). I think that both issues are thus sufficiently separate (in how they work and would be implemented) and can be valuable to eventually implement side-by-side, so I would suggest keeping both issues open for now. Gr. Matthijs signature.asc Description: PGP signature
Bug#960540: git-buildpackage: Documentation unclear about pristine-tar when upstream source comes from git
Package: git-buildpackage Version: 0.9.15 Severity: normal Hi Guido, I'm trying to figure out whether I need pristine-tar or not, and I can't quite figure it out based on the documentation. I understand that, when upstream supplies a tarball, you can use `gbp import-orig --pristine-tar` to import the tarball along with pristine-tar data, and then `gbp buildpackage --pristine-tar` will recreate the pristine tarball again (if needed). However, what if there is no upstream tarball and sources are merged using git directly? Is having a pristine tarball still relevant? I can imagine that when multiple people check out the packaging repo and build a package, they want to have the exact same tarball, so it would make sense to: - When a tarball is first created, commit pristine-tar data for it. - When a tarball is created later, use the pristine-tar info to recreate an identical tarball. Or does the `git archive` used to create tarballs from git already produce consistent tarballs (since there is no upstream tarball to match, this would be sufficient)? I could not find anything in the git archive manpage to suggest this, nor any details about what `pristine-tar` actually *does* to reason about this. A quick try shows that gbp does indeed manage to reproduce the same tarball twice, but that gives no guarantees about the same result with different git versions and different machines, of course. I was further confused by the gbp buildpackage manpage. It says: > When gbp buildpackage doesn't find a suitable upstream tarball it will > create one either using pristine-tar™ or git archive. These options > determine how the tarball is created: This is a bit confusing, I had expected that `git archive` would create a tarball and then pristine-tar would be used to make it pristine. I later read the `pristine-tar` manpage and noticed that pristine-tar actually creates the files from git directly (combining upstream commit and the pristine-tar commit), so no git archive involved. Also, it says: > --git-pristine-tar > Use pristine-tar when generating the upstream tarball if it doesn't > exist. If this mode is enabled the --git-upstream-tag, > --git-upstream-tree options have no effect. More confusion: If gbp-buildpackage is supposed to generate a pristine-tar delta when the tarball is first created from git, I would think I needed to pass `--git-pristine-tar`, but *also* `--git-upstream-tag` (or `--git-upstream-tree`) to allow gbp to locate the right upstream commit to base the tarball on? Later, I learned from the `pristine-tar` manpage that the pristine-tar commit actually contains the git tree id of the commit used to create it, so when recreating the tarball, pristine-tar can find the right commit on its own. But when creating the tarball the first time, `gbp buildpackage` *does* require the upstream commit, right? Or is the workflow to, on the first build for a new upstream version, run buildpackage without `--pristine-tar` to create the tarball and then run `pristine-tar` manually? I don't think so, since there is also `gbp --git-pristine-tar-commit`: > --git-pristine-tar-commit > Commit the pristine-tar delta to the pristine-tar branch if a new > tarball was generated and the pristine-tar data isn't already there. Or does this option maybe disable `--git-pristine-tar` when there is no pristine-tar data yet, and thus "reactivate" the `--git-upstream-*` options? If so (and if pristine-tar is still needed without upstream tarballs), the workflow could be to always run: gbp --git-pristine-tar --git-pristine-tar-commit --git-upstream-tag=v%(version)s And that would then *create* a tarball and pristine-tar data when no pristine-tar data is present yet, or *use* it (and ignore upstream-tag) when pristine-tar data *is* present? A quick shows that this might indeed work like this. I would be grateful if you could clarify some of this for me. Updating the docs would be even better, but maybe I can find some time to have a look at that if you can clarify things here first :-) Somewhat related: Is git archive even used at all? I ran 0.9.15 with `--git-verbose`, which seems to print all individual git commands ran, but I did not see git archive in there? Or is it just not printed? Gr. Matthijs
Bug#960485: lintian: false-positive no-dh-sequencer due to comments
Package: lintian Version: 2.72.0 Severity: minor Hi, lintian is incorrectly triggering no-dh-sequencer on my package (nml 0.5.1-2). The debian/rules file contains: # Use debhelper default for all targets (but some are overridden below). %: # Force the pybuild buildsystem, since there is also a # Makefile (which is used only for testing by this rules file). dh $@ --with python3 --buildsystem pybuild Looking at the source for this check, I suspect that the comment before the dh line prevents the dh sequence from being detected. Gr. Matthijs
Bug#905866: uscan: prefers watch files from a random dir over debian/watch
Hey folks, > (...) > and then goes on to detail how this directory name checking works > exactly. AFAICS, this directory name checking should protect against > these stray watch files in most of the cases, but apparently it is not > working. > (...) > AFAIU, "subdir" should have matched /^test(-+.)?/, which does not seem > to be the case, so this check seems broken in uscan? Turns out there was a bug with the directory checking. I submitted a fix here: https://salsa.debian.org/debian/devscripts/-/merge_requests/193 That MR also has a small change to the manpage that makes it a bit more explicit that uscan works recursively by default. > - There currently seems to be no way to disable this behaviour at all, >if it turns out to be problematic? I've found that the `--watchfile` option disables recursive processing and just processes the given file instead. So to just process the package in the current directory, you can run `uscan --watchfile debian/watch`. > - The most common usecase seems to be scanning for new versions of a >single package, where this recursive scanning is not needed at all. >Would it not make sense to just scan the current directory by >default, and add an option to enable recursive scanning for usecases >that need it? I still think that the current default might not be ideal. However, I do see the usecase of running uscan over a collection of debian package at the same time. Maybe the default could be changed to only scan the current directory *if* it is a debian source tree, and default to recursive scanning if not? That would support both the "Run on a single package" and "Run on a collection of packages" usecases neatly? More specifically, I would suggest: - Adding a `--no-recursive` option, which will always check only the current dir (and probably produce an error if no valid package and watchfile can be found). This might be implemented as an alias for `--watchfile debian/watch` maybe. - Adding a `--recursive` option, which ensures that recursive operation happens, even when the current directory is a valid source tree. This is what is the current default operation. - Specifying more than one of `--recursive`, `--no-recursive` and `--watchfile` is an error. - When none of `--recursive`, `--no-recursive` and `--watchfile` is specified, the default is to use `--no-recursive` when the current directory is a source tree, and `--recursive` otherwise. One open question is what constitutes a "source tree" exactly for the purpose of the default operation. The simplest (and most conservative) is "Whenever a debian/ subdirectory exists", the most extensive is probably "When a debian/changelog exists and can be parsed and debian/watch exists". I would tend to simplest rather than complex, since that is easier to check and harder to break (e.g. a typo in the changelog causing uscan to behave differently). I *can* imagine that someone would have a debian directory in their package collection they want to run uscan on (e.g. a debian and ubuntu directory for splitting packages between those), so maybe "When debian/changelog exists" is a good compromise here. How does that sound? Gr. Matthijs signature.asc Description: PGP signature
Bug#960430: uscan: "Use only newest of same package"-check not working?
Package: devscripts
Version: 2.20.3
Severity: minor
Hi,
while working on another problem, I noticed something weird in the code.
See
https://salsa.debian.org/debian/devscripts/-/blob/master/lib/Devscripts/Uscan/FindFiles.pm#L167-193
There is a comment there, that says:
# Now process the watch files in order. If a directory d has
# subdirectories d/sd1/debian and d/sd2/debian, which each contain watch
# files corresponding to the same package, then we only process the watch
# file in the package with the latest version number.
This seems to be implemented by sorting the watch files on version, and then
once you see a package that was previously already processed, skip it. However,
that skipping is implemented like this:
if (exists $donepkgs{$parentdir}{$package}) {
uscan_warn "Skipping $dir/debian/watch\n as this package has already
been found";
next;
}
IOW, it skips if a package was already processed that has both the same
$parentdir (e.g. the `foo-1.2.3` directory that contains the `debian` dir),
*and* the same $package (i.e. the package name parsed from `debian/changelog`).
This seems weird to me, I would think that just the same package name
should be enough. However, I could not find this behaviour mentioned in
the manpage at all, so I'm not exactly sure what the intended behaviour
is exactly.
To show this happens:
$ mkdir -p uscantest/test-1.2.3/debian
$ mkdir -p uscantest/test-2.0.0/debian
$ cd uscantest/
uscantest$ (cd test-1.2.3; dch --create --package test --newversion 1.2.3-1)
uscantest$ (cd test-2.0.0; dch --create --package test --newversion 2.0.0-1)
uscantest$ touch test-1.2.3/debian/watch test-2.0.0/debian/watch
uscantest$ uscan --report-status
uscan info: uscan (version 2.20.4~1.gbp0dd0c3) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in ./test-1.2.3
uscan info: package="test" version="1.2.3-1" (as seen in debian/changelog)
uscan info: package="test" version="1.2.3" (no epoch/revision)
uscan info: Check debian/watch and debian/changelog in ./test-2.0.0
uscan info: package="test" version="2.0.0-1" (as seen in debian/changelog)
uscan info: package="test" version="2.0.0" (no epoch/revision)
uscan info: ./test-2.0.0/debian/changelog sets package="test" version="2.0.0"
uscan info: ./test-1.2.3/debian/changelog sets package="test" version="1.2.3"
uscan info: Process watch file at: debian/watch
package = test
version = 2.0.0
pkg_dir = ./test-2.0.0
uscan info: Process watch file at: debian/watch
package = test
version = 1.2.3
pkg_dir = ./test-1.2.3
uscan info: Scan finished
It indeed processes the packages in descending version order, but does not skip
the lower version of the same package as the comment implies should happen.
I've tested this with current git master, so I used the most recently released
version number in the bug metadata.
Gr.
Matthijs
Bug#960419: dh_link: Add option to check for identical file contents before replacing
Package: debhelper Severity: wishlist Hi, in the openttd-opengfx package, I'm using dh_link to replace some upstream-installed files with symlinks. To prevent accidentally linking to the wrong file, I now explicitly diff the files before creating the link. It would be nice if dh_link could handle that. I can imagine an option that checks whether the to-be-created link and the target already exist and if so, whether they are equal. I can imagine four modes: 1. Always create the link. This is the current behaviour. 2. When both files exist and are not equal, do nothing. In all other cases, create the link. 3. When both files exist and are not equal, abort with an error. In all other cases, create the link. 4. When both files exist and are not equal, or either file does not exist, abort with an error. Only if both files exist and are equal, create the link. I suspect that in most cases, the link will not overwrite any existing files, so 2. is useful as a safeguard against accidentally overwriting a non-identical file. In my case, I'm letting the upstream Makefile first install files, and then replace them with a symlink. In that case, I want to *only* replace files and not create new links, so I would need 3. One complication in implementing this would be cross-package links. For implementing any of 2., 3. or 4. above, you need to be able to resolve the target of the link. If that lives in another package, this is tricky. I can imagine two flavours of this: - Links to other binary packages resulting from the currently built source package. Maybe dh can resolve those by looking in all available install dirs for the file. I guess this *might* result in multiple versions of the same file, which should then *all* be identical. - Links to unrelated binary packages (e.g. links to /usr/share/common-licenses). These could maybe be resolved against the build system (this is what I do for the license right now), but I don't think this can be made reliable, so this is probably better to not support at all. Gr. Matthijs
Bug#959665: git-buildpackage: please put a full stop after "New upstrem version X."
Package: git-buildpackage Followup-For: Bug #959665 Hi, It does seem that having a full stop at the end of debian/changelogs is conventional. However, this is already easy to configure locally. I had this in my debian/gbp.conf for a long time: [import-orig] import-msg = New upstream release %(version)s. I've since removed the dot again, since for *git* commit messages, it is conventional to *not* have a full stop at the end of the first line and I kept forgetting to add it for my Debian packages, so now my changelogs also omit the full stop. Also, it seems that Debian policy does not mention the full stop at all: https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog Anyway, this is already easy to configure, so I wonder if this would be worth changing? Gr. Matthijs
Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)
Hey folks, I've upgraded this system to buster and it seems that either the new kernel (4.19.0-8-amd64) or new lxc version (1:3.1.0+really3.0.3-8) has fixed this problem: I can now again re-exec systemd in containers even with lxc.cap.drop = sys_admin enabled. I guess this issue could be closed? Feel free to do so if you think it is appropriate. Anyway, below is some more info I collected a long time ago but never gotten around to cleaning up and sending. I'm including it here, in case it is useful for anyone else running into the same. Gr. Matthijs == Old debugging info below == When running systemd with debug loglevel (in /etc/systemd/system.conf), I see the following on boot (from the console logfile, since journald isn't running at that point yet): Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd. Release agent already installed. When reexecuting systemd, I get the following (from journalctl): Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd/../... Release agent already installed. Failed to create /../../init.scope control group: Operation not permitted Failed to allocate manager object: Operation not permitted The ../../init.scope is, I think, based on this file: $ cat /proc/1/cgroup 10:freezer:/ 9:pids:/../../init.scope 8:net_cls,net_prio:/ 7:devices:/../../init.scope 6:blkio:/../../init.scope 5:memory:/../../init.scope 4:perf_event:/ 3:cpu,cpuacct:/../../init.scope 2:cpuset:/ 1:name=systemd:/../../init.scope This is how it looks before and after the re-exec. I'm not sure what this file looks like when systemd first starts in the container, but I suspect the ../../ is not there yet, given the "File system hierarchy is at /sys/fs/cgroup/systemd" log message, or maybe systemd does not read it on initial startup? On the host, the file looks like this: $ cat /proc/1/cgroup 10:freezer:/ 9:pids:/init.scope 8:net_cls,net_prio:/ 7:devices:/init.scope 6:blkio:/init.scope 5:memory:/init.scope 4:perf_event:/ 3:cpu,cpuacct:/init.scope 2:cpuset:/ 1:name=systemd:/init.scope When I look up the container's pid 1 on the host, it looks like this: matthijs@tika:/etc/lxc$ cat /proc/1755/cgroup 10:freezer:/lxc/template 9:pids:/init.scope 8:net_cls,net_prio:/lxc/template 7:devices:/init.scope 6:blkio:/init.scope 5:memory:/init.scope 4:perf_event:/lxc/template 3:cpu,cpuacct:/init.scope 2:cpuset:/lxc/template 1:name=systemd:/init.scope When I start the container *with* CAP_SYS_ADMIN, the file inside the container looks different: matthijs@template:~$ cat /proc/1/cgroup | grep systemd 1:name=systemd:/init.scope When I look up the container's pid 1 on the host, it looks like this: matthijs@tika:/etc/lxc$ sudo cat /proc/507/cgroup | grep systemd 1:name=systemd:/lxc/template/init.scope == New debug info == After the upgrade to buster, it seems that the scopes are now correct. Inside the container *without* CAP_SYS_ADMIN, I now get: $ cat /proc/1/cgroup |grep systemd 1:name=systemd:/init.scope signature.asc Description: PGP signature
Bug#880170: aptitude: Read error (-5: DATA_ERROR_MAGIC)
Package: apt Followup-For: Bug #880170 Hi, I just also ran into this problem. It's on a stretch system, so with an older apt, but maybe my observations help regardless. I saw this error running `aptitude update`. It happened with the stretch security updates translation file for contrib and non-free. I read that emptying /var/lib/apt/lists might help, so I tried a light version: I deleted only security.debian.org_dists_stretch_updates_non-free_i18n_Translation-en and security.debian.org_dists_stretch_updates_contrib_i18n_Translation-en from that directory. I had expected these files to be somehow problematic, so I saved them to restore them later to reproduce the problem again. Removing both files indeed made the `aptitude update` complete succesfully. To my surprise these two files had been recreated, with exactly the same contents as before. Another `aptitude update` succeeds, so apparently something else changed (but I did not make a full backup of the lists directory, unfortunately). So I could not reproduce the problem by restoring these files manually, as I had planned. Looking on the server, I see that a http://security.debian.org/dists/stretch/updates/contrib/i18n/Translation-en.bz2 does exist, so the 404-theory stated previously might not be accurate. I also looked for the failing file in /var/lib/apt/lists/partial, but there were no files in there when I looked. Sorry I don't have anything more specific, but maybe some of this helps... Gr. Matthijs -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-8-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-
Bug#954672: openttd-opengfx: FTBFS: Error: (AttributeError) "module 'time' has no attribute 'clock'".
reassign 954672 nml 0.4.5-2 thanks Hi Lucas, > > Error:(AttributeError) "module 'time' has no attribute 'clock'". > > Command: ['/usr/bin/nmlc', '-c', '-p', 'DOS', '-M', > > '--MF=ogfx1_base.grf.dep', '--grf', 'ogfx1_base.grf', 'ogfx1_base.nml'] > > Location: File "/usr/lib/python3/dist-packages/nml/generic.py", line 332, > > in print_progress thanks for reporting. Seems this is really a bug in the nml compiler, which uses time.clock, which was deprecated since Python 3.3 and removed in 3.8. I'm also the maintainer of that package, so I'll make sure to get this fixed. Gr. Matthijs signature.asc Description: PGP signature
Bug#945945: dh-python: Should support DEB_BUILD_OPTIONS=terse
Package: dh-python
Version: 4.20191017
Severity: wishlist
Hi,
it would be nice if dh-python could automatically handle
DEB_BUILD_OPTIONS=terse.
Debhelper does already have some machinery for this:
/usr/share/perl5/Debian/Debhelper$ grep -r QUIET
Dh_Lib.pm: # make sure verbose is on. Otherwise, check DH_QUIET.
Dh_Lib.pm: } elsif (defined $ENV{DH_QUIET} && $ENV{DH_QUIET} ne "" ||
get_buildoption("terse")) {
Dh_Lib.pm: $dh{QUIET}=1;
Dh_Lib.pm: if (!$dh{QUIET}) {
Buildsystem/ninja.pm: if (!$dh{QUIET}) {
Buildsystem/cmake.pm: unless ($dh{QUIET}) {
Buildsystem/autoconf.pm:if ($dh{QUIET}) {
Iow, it sets `$dh{QUIET}` when the build should be quiet, and some build
systems already check this, so it would make sense for dh-python to do the same.
pybuild already has a working `--quiet` option, so I included a patch below
that passes `--quiet` to `pybuild` when appropriate (this checks for
`--verbose`, since from looking at the code, I expect mixing `--verbose` with
`--quiet` will give funny results). The patch is made against an installed
version 4.20191017, so I hope it still applies to a master version as-is.
Gr.
Matthijs
And here's the patch:
--- a/Debian/Debhelper/Buildsystem/pybuild.pm
+++ b/Debian/Debhelper/Buildsystem/pybuild.pm
@@ -10,7 +10,7 @@ package Debian::Debhelper::Buildsystem::
use strict;
use Dpkg::Control;
use Dpkg::Changelog::Debian;
-use Debian::Debhelper::Dh_Lib qw(error doit);
+use Debian::Debhelper::Dh_Lib qw(%dh error doit);
use base 'Debian::Debhelper::Buildsystem';
sub DESCRIPTION {
@@ -105,6 +105,10 @@ sub pybuild_commands {
push @options, '--dir', $dir;
}
+ if (not grep {$_ eq '--verbose'} @options and $dh{QUIET}) {
+ push @options, '--quiet';
+ }
+
my @deps;
if ($ENV{'PYBUILD_INTERPRETERS'}) {
push @result, ['pybuild', "--$step", @options];
Bug#945941: Lacking HTML encoding of debcheck results
Package: qa.debian.org Severity: normal Hi, for the "nml" package, I'm seeing some warnings from debcheck at [1]: Package declares a build time dependency on 'python3-all-dev:any' which is broken Syntax. Package declares a build time dependency on 'python3-pil ' which is broken Syntax. Package declares a build time dependency on 'python3-ply ' which is broken Syntax. [1]: https://qa.debian.org/debcheck.php?dist=unstable&package=nml At first glance, especially the latter two seem perfectly fine, making the error confusing. On closer inspection, the HTML source for these lines looks like: Package declares a build time dependency on 'python3-all-dev:any' which is broken Syntax. Package declares a build time dependency on 'python3-pil ' which is broken Syntax. Package declares a build time dependency on 'python3-ply ' which is broken Syntax. So it seems that qa.debian.org embeds the debcheck results into the HTML without any encoding, making the brackets be interpreted as HTML and the contents effectively hidden. In theory, this could be a security problem (XSS), though exploiting that probably requires uploading a package with an XSS attack embedded in the dependency line (which probably needs to be accepted by other tooling in the process as well, so might even be impossible). Maybe other errors are more exploitable, but the lack of anonymity in the uploads probably means that this is really a security problem in practice. Note that lack of support for such a clause is the subject of #816448, but the encoding should be solved separately (even when that bug is also solved). Solving this would probably be a matter of adding a `htmlspecialchars()` around the output lines. Gr. Matthijs
Bug#945332: libsystemd0: sd-event leaks file descriptors
Package: libsystemd0 Version: 241-7~deb10u2 Severity: normal When an sd-event io event source with fd ownership is released while it is dispatching (i.e. from inside the event callback), the event source is freed after dispatching is complete but it fails to close the fd. This bug has recently been fixed upstream: f59825595182 sd-event: don't invalidate source type on disconnect
Bug#909750:
I got the message "Unable to revert mtime: /usr/local/share/fonts"
(see also related bug 909728) upon opening a particular pdf file with
xpdf and discovered this message was emitted after it had created a
.uuid file in that directory (which was writable by me as normal user,
probably something I did in the past), so clearly libfontconfig still
writes to /usr under some circumstances. I'm using the latest
fontconfig in sid (2.13.1-2+b1).
relevant strace output:
access("/usr/local/share/fonts/.uuid", F_OK) = -1 ENOENT (No such file
or directory)
stat("/usr/local/share/fonts", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/usr/local/share/fonts/.uuid.TMP-gyDVw4",
O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 5
link("/usr/local/share/fonts/.uuid.TMP-gyDVw4",
"/usr/local/share/fonts/.uuid.LCK") = 0
unlink("/usr/local/share/fonts/.uuid.TMP-gyDVw4") = 0
unlink("/usr/local/share/fonts/.uuid.NEW") = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "/usr/local/share/fonts/.uuid.NEW",
O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 5
rename("/usr/local/share/fonts/.uuid.NEW", "/usr/local/share/fonts/.uuid") = 0
unlink("/usr/local/share/fonts/.uuid.LCK") = 0
utimes("/usr/local/share/fonts", [{tv_sec=1573279099, tv_usec=455382}
/* 2019-11-09T06:58:19.455382+0100 */, {tv_sec=1573279221,
tv_usec=252001} /* 2019-11-09T07:00:21.252001+0100 */]) = -1 EPERM
(Operation not permitted)
Bug#943399: golang: backport golang-1.13 to buster
Package: golang Version: 2:1.11~1 Severity: wishlist Dear Maintainer, If possible, please consider backporting golang-1.13 to buster. (Main reason: module support in 1.13 has been improved a lot compared to 1.11). Thanks for maintaining Go in Debian! Regards, Matthijs ten Berge -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages golang depends on: ii golang-1.11 1.11.6-1+deb10u2 ii golang-doc 2:1.11~1 ii golang-go2:1.11~1 ii golang-src 2:1.11~1 golang recommends no packages. golang suggests no packages. -- no debconf information DISCLAIMER: For our full disclaimer, please visit www.awl.nl/en/about-us/disclaimer
Bug#942716: add patch
Hey Matthias, > patch at > http://launchpadlibrarian.net/447871899/nml_0.4.5-1build2_0.4.5-1ubuntu1.diff.gz Thanks for the report and the patch, looks good. I'll prepare an upload with it, probably somewhere next week. Gr. Matthijs signature.asc Description: PGP signature
Bug#942716: add patch
Hey Matthias, > Thanks for the report and the patch, looks good. I'll prepare an upload > with it, probably somewhere next week. I had another look upstream, seems they fixed it by falling back to PILLOW_VERSION unconditionally, but I also noticed PIL.__version__ is actually the recommended replacement (available since pillow 3.4.0, which is < oldstable, so can probably be used unconditionally as well). See https://github.com/OpenTTD/nml/issues/39 for the upstream discussion. Gr. Matthijs signature.asc Description: PGP signature
Bug#942372: git-buildpackage: Allow configuring vendor for dch
Hey folks, > It is possible to override these defaults by passing `--vendor` to dch, > so it would be good if a value could be configured in gbp that is passed > to `dch --vendor`. Ideally, the value could be configured globally, or > per-package, I think. I found the `dch-opt` configuration as a way to do this with the current git-buildpackage version. E.g. in `~/.gbp.conf`: [dch] dch-opt = --vendor=debian Alternatively, you can set the DEB_VENDOR environment variable to (globally) change the default vendor that dpkg-vendor returns (as documented in dpkg-vendor(1)). I guess that pretty solves this request, though a dedicated option (or a mention in the manpage) might still make it easier for people to figure out how to do this. Gr. Matthijs signature.asc Description: PGP signature
Bug#942372: git-buildpackage: Allow configuring vendor for dch
Package: git-buildpackage Version: 0.9.14 Severity: normal Hi, I'm running gbp on an Ubuntu system to build packages for Debian. By default, dch (and thus also gbp dch) uses distribution and version number defaults for Ubuntu, rather than Debian (based on the results of dpkg-vendor). It is possible to override these defaults by passing `--vendor` to dch, so it would be good if a value could be configured in gbp that is passed to `dch --vendor`. Ideally, the value could be configured globally, or per-package, I think. There might be other tools that need to be told about the vendor, but I have not found them so far. Gr. Matthijs
Bug#942370: devscripts: [debchange] --release has undocumented exception for Ubuntu distribution name
Package: devscripts
Version: 2.19.6
Severity: normal
When running dhc on Ubuntu with --release, it uses the upcoming ubuntu
version (eoan currently), rather than unstable as the distribution name
to put into the changelog. It took me a while to figure out that dch was doing
this, since this exception is undocumented.
The code has:
if ($vendor eq 'Ubuntu') {
# In Ubuntu the development release regularly changes, don't just copy
# the previous name.
$DISTRIBUTION = get_ubuntu_devel_distro();
} else {
$DISTRIBUTION = $changelog->{Distribution};
}
(From
https://salsa.debian.org/debian/devscripts/blob/master/scripts/debchange.pl#L700-706)
But the manpage says:
--release, -r
Finalize the changelog for a release. Update the
changelog timestamp. If the distribution is set to
UNRELEASED, change it to the distribu‐ tion from the
previous changelog entry (or another distribution as
specified by --distribution). If there are no previous
changelog entries and an explicit distribution has not
been specified, unstable will be used.
Without mentioning this exception.
Gr.
Matthijs
Bug#905866: uscan: prefers watch files from a random dir over debian/watch
Package: devscripts Version: 2.19.4 Followup-For: Bug #905866 Hey folks, I'm also running into problems with uscan processing debian/watch files in subdirectories. Looking at the manpage, it *seems* to say it only scans `debian/watch`, but at the end of the manpage, under ADVANCED FEATURES, it says: uscan actually scans not just the current directory but all its subdirectories looking for debian/watch to process them all. See "Directory name checking". Looking at the section "Directory name checking", it says: Similarly to several other scripts in the devscripts package, uscan explores the requested directory trees looking for debian/changelog and debian/watch files. As a safeguard against stray files causing potential problems, and in order to promote efficiency, it will examine the name of the parent directory once it finds the debian/changelog file, and check that the directory name corresponds to the package name. It will only attempt to download newer versions of the package and then perform any requested action if the directory name matches the package name. and then goes on to detail how this directory name checking works exactly. AFAICS, this directory name checking should protect against these stray watch files in most of the cases, but apparently it is not working. To reproduce: $ mkdir -p subdir/debian $ (cd subdir; dch --create --package test --newversion 1.0.0-1) $ touch subdir/debian/watch $ uscan --report $ uscan --report-status uscan info: uscan (version 2.19.4) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in ./subdir uscan info: package="test" version="1.0.0-1" (as seen in debian/changelog) uscan info: package="test" version="1.0.0" (no epoch/revision) uscan info: ./subdir/debian/changelog sets package="test" version="1.0.0" uscan info: Process watch file at: debian/watch package = test version = 1.0.0 pkg_dir = ./subdir uscan info: Scan finished AFAIU, "subdir" should have matched /^test(-+.)?/, which does not seem to be the case, so this check seems broken in uscan? However, I'm actually wondering if this recursive scanning by default is a good feature at all. Two considerations: - There currently seems to be no way to disable this behaviour at all, if it turns out to be problematic? - The most common usecase seems to be scanning for new versions of a single package, where this recursive scanning is not needed at all. Would it not make sense to just scan the current directory by default, and add an option to enable recursive scanning for usecases that need it? Gr. Matthijs
Bug#895982: devscripts: [uscan] don't look in VCS directories for d/changelog or make it optional
Package: devscripts Followup-For: Bug #895982 Hey folks, it seems this was partly fixed in 2.19.6 by specifically ignoring .git directories: https://salsa.debian.org/debian/devscripts/merge_requests/132 There is also a similar bug report to this one that is not limited to VCS directories, but discusess the scanning of subdirectories in general: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905866 Gr. Matthijs
Bug#941446: openttd: Upstream version 1.9.3 available
Hi Georg, > new upstream version 1.9.3 is available. Thanks for the headsup, seems I missed that. I'll try to get this uploaded ASAP. Gr. Matthijs signature.asc Description: PGP signature
Bug#939257: pack_install fails to reach the swi-prolog servers due to switch to https
Package: swi-prolog
Version: 8.0.2+dfsg-3
pack_install stopped working due to swi-prolog upstream servers switching
from http to https, as documented here:
https://swi-prolog.discourse.group/t/www-swi-prolog-org-goes-https/811/2
Upstream has fixed this in commit 2f36f408be0abc1f6d4915534334fece26af5450,
which is a one-line fix that changes the URL of the server to contact from
http to https. I suggest backporting this fix into the debian package as
well.
Here's a transcript demonstrating the bug:
?- pack_install(uuid).
% Contacting server at http://www.swi-prolog.org/pack/query ...
ERROR: url `'https://www.swi-prolog.org/pack/query'' does not exist
(status(500,Internal Server Error))
ERROR: In:
ERROR: [18] throw(error(existence_error(url,'
https://www.swi-prolog.org/pack/query'),context(_8254,...)))
ERROR: [16] http_open:try_http_proxy(direct,[uri('
http://www.swi-prolog.org/pack/query'),...|...],_8290,[post(...),...]) at
/usr/lib/swi-prolog/library/http/http_open.pl:425
ERROR: [14]
ERROR: [13] '$sig_atomic'(prolog_pack:http_open('
http://www.swi-prolog.org/pack/query',_8384,...))
ERROR: [12] setup_call_catcher_cleanup(prolog_pack:http_open('
http://www.swi-prolog.org/pack/query',_8428,...),prolog_pack:read_reply(_8440,_8442,_8444),_8414,prolog_pack:close(_8454))
at /usr/lib/swi-prolog/boot/init.pl:469
ERROR: [10] prolog_pack:query_pack_server(locate(uuid),_8486,[]) at
/usr/lib/swi-prolog/library/prolog_pack.pl:1733
ERROR:[9] prolog_pack:pack_default_options(uuid,uuid,[],_8528) at
/usr/lib/swi-prolog/library/prolog_pack.pl:516
ERROR:[8] prolog_pack:pack_install(uuid) at /usr/lib/swi-prolog/library/
prolog_pack.pl:457
ERROR:[7]
ERROR:
ERROR: Note: some frames are missing due to last-call optimization.
ERROR: Re-run your program in debug mode (:- debug.) to get more detail.
Bug#927079: libpam-script: Filters environment variables
Package: libpam-script Followup-For: Bug #927079 Hi, you mentioned that libpam-script filters environment variables, but I think this is not actually the case. Looking at the code, it only seems to *add* a number of variables, not remove any. For example I added the following line to my /etc/pam.d/sudo (just before the common-auth line): auth optional pam_script.so dir=/etc/pam.d/lock-scripts And then created /etc/pam.d/lock-scripts/pam_script_auth: #!/bin/sh env > /tmp/env After running sudo, I get my entire environment in /tmp/env. I suspect there might be other pam modules that might be clearing the env, or maybe the application that calls the pam module? Gr. Matthijs
Bug#936027: libpam-script: Using "sufficient" prevents running post-auth modules
Package: libpam-script Version: 1.1.9-4 Severity: normal Hi, I've just installed libpam-script, and noticed it uses "sufficient" in its pam config lines. This results in e.g. the following common-auth on my system: # here are the per-package modules (the "Primary" block) authsufficient pam_script.so auth[success=1 default=ignore] pam_unix.so nullok_secure try_first_pass # here's the fallback if no module succeeds authrequisite pam_deny.so # prime the stack with a positive return value if there isn't one # already; this avoids us returning an error just because nothing sets # a success code since the modules above will each just jump around authrequiredpam_permit.so # and here are more per-package modules (the "Additional" block) authoptionalpam_fscrypt.so authoptionalpam_cap.so # end of pam-auth-update config IIUC, sufficient means to stop executing other modules if the script succeeds. This is fine wrt other modules that do additional "primary" authentication checks (e.g. only one of them needs to succeed), but AFAICS this also prevents running additional modules (that typically run after the primary modules (such as the fscrpt or cap modules above). As you can see, the unix module uses a jump to skip any other primary modules, rather than sufficient to skip *all* other modules. This is something that pam-auth-update can apparently automatically handle. Here's how this looks in /usr/share/pam-configs/unix: Name: Unix authentication Default: yes Priority: 256 Auth-Type: Primary Auth: [success=end default=ignore]pam_unix.so nullok_secure try_first_pass Auth-Initial: [success=end default=ignore]pam_unix.so nullok_secure Account-Type: Primary Account: [success=end new_authtok_reqd=done default=ignore] pam_unix.so Account-Initial: [success=end new_authtok_reqd=done default=ignore] pam_unix.so Note the "success=end", which I assume to be autoreplaced with an appropriate value. Gr. Matthijs -- System Information: Debian Release: buster/sid APT prefers disco-updates APT policy: (990, 'disco-updates'), (990, 'disco-security'), (990, 'disco-backports'), (990, 'disco'), (50, 'testing'), (50, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.0-25-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-script depends on: ii libc6 2.29-0ubuntu2 ii libpam0g 1.3.1-5ubuntu1 libpam-script recommends no packages. libpam-script suggests no packages. -- no debconf information
Bug#935996: libpam-fscrypt: Should provide a manpage
Package: libpam-fscrypt Version: 0.2.4-2 Severity: normal Hi, I'm trying to use libpam-fscrypt, but I'm missing a manpage that describes its usage. I've found /usr/share/doc/fscrypt/README.md.gz which has some info on the module, but is mostly limited to examples (for example, it is not clear what parts the "auth" and "session" invocation of the module play in the unlocking of encrypted files. Having a complete manpage would be helpful in this sense. Gr. Matthijs
Bug#934731: uwsgi-emperor: Fails to stop due to too wide pidfile permissions
Package: uwsgi-emperor Version: 2.0.18-1 Severity: normal Hi, on my uwsgi-emperor setup, I've noticed that uwsgi-emperor fails to stop or restart. e.g. when running `systemctl stop uwsgi-emperor`, I get (in `systemctl status uwsgi-emperor`): systemd[1]: Stopping LSB: Start/stop uWSGI server instance(s)... uwsgi-emperor[11470]: start-stop-daemon: matching on world-writable pidfile /run/uwsgi-emperor.pid is insecure systemd[1]: uwsgi-emperor.service: Succeeded. However, even though this says "Succeeded", uwsgi-emperor is still running as before, so I suspect start-stop-daemon has refused to act. Looking at the pidfile, I see indeed 666 permissions: -rw-rw-rw- 1 root root 6 aug 14 07:51 /run/uwsgi-emperor.pid Manually clearing the permissions (`chmod o-rwx /run/uwsgi-emperor.pid`) before running stopping indeed fixes both the message and makes the emperor stop properly. I found a mailing list post which suggests that this is due to the --daemonize option, which sets the umask to 0: http://lists.unbit.it/pipermail/uwsgi/2013-April/005803.html I think this issue has started occurring after upgrading to Buster. I suspect that maybe start-stop-daemon has become more strict in its permission check, or maybe the permissions changed on the uwsgi side. Adding `--umask 022` to the initscript fixed the permissions for my setup, but I suspect this might actually change all kinds of permissions for other files too, so this might not be ideal as a general solution. It seems uwsgi does not currently have any option to set the permissions of the pidfile, which might be the best solution. Doing a chmod from the init script seems like a workaround, but AFAICS would leave a race condition where the pidfile is writable for a short while. I have only tested this on a configured production system, but I highly suspect that this is not related to my setup, but also broken in a default installation. I've included my emperor config below as an indication. Gr. Matthijs -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (800, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages uwsgi-emperor depends on: ii uwsgi-core 2.0.18-1 uwsgi-emperor recommends no packages. uwsgi-emperor suggests no packages. -- Configuration Files: /etc/uwsgi-emperor/emperor.ini changed: [uwsgi] log-date = true strict = true set-placeholder = base-dir=/etc/uwsgi-emperor emperor = glob://%(base-dir)/vassals/*/app-*.ini emperor = glob://%(base-dir)/vassals/app-*.ini vassals-include-before = vassal-defaults.ini hook-as-vassal = callret:chdir %(base-dir) show-config = 1 -- no debconf information
Bug#930264: modemmanager: --filter-policy=strict no longer respects blacklist and probes Arduinos
Package: modemmanager Version: 1.10.0-1 Severity: normal Hi, since a while, ModemManager is using the new "strict" filter policy. Rather than probing all serial ports that are not blacklisted (which causes problems with serial devices that do not like to be probed), it now uses more specific rules about what devices are likely to be modems and does not probe any others. However, this strict policy does *not* use the blacklist (configured through udev rules), which I believe is problematic. This problem particularly surfaces when using Arduino serial devices. These development boards enumerate as TTY ACM USB devices, which cause the kernel to automatically create serial ports for them. However, in their USB descriptors, these devices advertise support for AT commands (class=2/subclass=2/protocol=1), which triggers the MM FILTER_RULE_TTY_ACM_INTERFACE and makes it probe these devices. Of course, the actual problem in this case is that these devices misadvertise themselves in their USB descriptor. I've raised this issue in the Arduino community [1] and hopefully this will be fixed in the future, but this will not help for existing devices (whose firmware is not automatically or easily updated). This means that there are a lot of Arduino devices out there which are broken by the switch to strict. Previously, these devices were handled by the blacklist, but now they are again probed when they should not. I suspect that there might be other devices that have a similar fate. Also, users (such as myself) might have collected some udev rules with blacklists over time, which now unexpectedly stop working. It seems that disabling the blacklist in strict mode is not an oversight from upstream, since they also offer a "paranoid" mode which is equal to "strict" mode but with the blacklist and greylist (manual scan only) enabled. A potential fix is to use the paranoid policy rather than the strict policy, or to explicitly enable the blacklist and/or greylist on top of the strict policy. I tried the latter, which indeed prevents MM from probing my Arduinos. I did this: $ cat /etc/systemd/system/ModemManager.service.d/override.conf [Service] Environment="MM_FILTER_RULE_TTY_BLACKLIST=1" Note that upstream discourages using the blacklists in their documentation: > It is not recommended to use this option in normal setups as the > blacklists may be obsoleted in future ModemManager versions (in favor > of using the Strict policy as default). However, I've raised this same issue upstream [2], asking them to reconsider this position. Since this issue is a regression (Stretch still has a working blacklist, but the Buster version uses the swtrict policy), it would make sense to me to still make this change in Buster, if the freeze policy allows this. [1]: https://github.com/arduino/ArduinoCore-avr/pull/92 [2]: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/127 Gr. Matthijs (Note that I'm running Ubuntu on this machine, but reporting this to Debian since that's where I believe this should be fixed) -- System Information: Debian Release: buster/sid APT prefers disco-updates APT policy: (990, 'disco-updates'), (990, 'disco-security'), (990, 'disco-backports'), (990, 'disco'), (50, 'testing'), (50, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.0-16-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages modemmanager depends on: ii libc6 2.29-0ubuntu2 ii libglib2.0-0 2.60.0-1 ii libgudev-1.0-0 1:232-2 ii libmbim-glib4 1.18.0-1 ii libmbim-proxy 1.18.0-1 ii libmm-glib01.10.0-1 ii libpolkit-gobject-1-0 0.105-25 ii libqmi-glib5 1.22.0-1.2 ii libqmi-proxy 1.22.0-1.2 ii libsystemd0240-6ubuntu5 Versions of packages modemmanager recommends: ii usb-modeswitch 2.5.2+repack0-2ubuntu1 modemmanager suggests no packages. -- no debconf information
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Adrian, I just updated the MR with the changes I discussed in my previous mail (and also listed below). My previous mail also contained some responses and questions, if you have some time to respond to those that would be great. > > >>> 3) Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d) I moved this into its own MR: https://salsa.debian.org/live-team/live-build/merge_requests/26 > > Well, I think you should use something else. > > modules32 is 9 characters long (not 8.3 compatible). What about module32 > > and module64? So that we can reuse the code in the iso side when > > isolinux is updated to support hybrid isos in efi mode ? > Good point, hadn't considered 8.3 compatibility. Singular "module32" > sounds a bit weird to me, but it is probably clearer than something like > "mods32" or even just "c32" (the latter seems reasonable, except that > the "c64" directory would then still contain ".c32" files since that's > what 64-bit syslinux-efi also uses...). I changed to module32 and module64 now (also using module32 for the bios modules, for consistency). > > 6.1) > > PATH syslinux command is still being written in capital letters in > > share/bootloaders/syslinux-efi/syslia32.cfg and > > share/bootloaders/syslinux-efi/syslx64.cfg while it should be written in > > non-capital letters. > Good catch, will fix that. Fixed. Gr. Matthijs signature.asc Description: PGP signature
Bug#920765: modemmanager: please package version 1.10 for buster
Package: modemmanager Followup-For: Bug #920765 Hey folks, AFAICS modemmanager 1.10 is available in sid and buster currently, so this bug can be closed? Gr. Matthijs
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
selected, but not if only syslinux-efi is selected). - binary_syslinux-efi that installs the modules and main config file for syslinux-efi (runs if syslinux-efi is selected). - binary_syslinux_proces_cfg that post-processes all config files installed by previous steps (runs if any of syslinux/extlinux/isolinux/syslinux-efi is selected). But I'm not so sure that this is really better than the current single-script for everything approach (which essentially just does the above four steps in a single script). > 6.1) > PATH syslinux command is still being written in capital letters in > share/bootloaders/syslinux-efi/syslia32.cfg and > share/bootloaders/syslinux-efi/syslx64.cfg while it should be written in > non-capital letters. Good catch, will fix that. > 6.2) What you should learn about the multibootloader support is that it > should let use as much as bootloaders as you want to. > > So, you could have something like: > > --bootloaders syslinux,syslinux-efi,grub-efi > > which, of course it does not make sense because either syslinux-efi and > grub-efi would overwrite each ones code. I see, and I think this still "works" with my MR. > Anyway what I wanted to say here is that: > > --bootloaders syslinux,syslinux-efi > and > --bootloaders syslinux-efi,syslinux > > are not the same thing. > > The first one (regarding binary_syslinux) should install special MBR > code so that BIOS can chainload into syslinx. > The second one (regarding binary_syslinux) should NOT install special > MBR code so that BIOS can chainload into syslinux. It should inhibit > itself because it is not the first bootloader. I'm not so convinved that this is how it should be. I guess the complication comes from HDD images, as you mentioned. On ISOs you just have multiple bootloader "slots" with one being the default. On a HDD image, you sort of have 2 bootloader "slots": the BIOS MBR and the EFI boot dir. As long as you select only one BIOS bootloader and one EFI bootloader, they can (and probably should) nicely coexist. Once you select more than one, they will likely overwrite each other, or perhaps only the first one should take effect (the latter is how it works with ISOs, I guess.). I guess the interpretation of multiple bootloaders is currently image-type-specific: - For iso images, all bootloaders are installed and the first one is made the default. - For hdd images before my MR, only the first bootloader is installed. Any extra bootloaders have their config files installed, but they are not installed into the MBR. EFI bootloaders are not supported for hdd images. - For hdd images with my MR applied, any BIOS bootloader is only installed if it is the first bootloader. Any EFI bootloader (which can only be syslinux-efi) is installed, regardless of its position. Multiple efi bootloaders would overwrite each other. This might warrant an extra configuration check for hdd images perhaps, that checks that no BIOS-bootloader appears in second or further positions and only one EFI bootloader appears in the list? I did not add anything like that, since there is no such check in place currently and I did not want to further complicate the MR. > Anyways... if we take a look at your untouched binary_hdd: > https://salsa.debian.org/live-team/live-build/blob/00eab3a77f3da176f3f0aa807b886206f8f0f0f1/scripts/build/binary_hdd > we can see that grub-pc is not supported. I guess I might add it in the > future. > But grub legacy is supported. (Well, it's not actually not supported.) > Assuming grub legacy are available at buster which I'm not totally sure. I actually think no grub is supported by hdd, the only grub code in there is in a big FIXME: https://salsa.debian.org/live-team/live-build/blob/00eab3a77f3da176f3f0aa807b886206f8f0f0f1/scripts/build/binary_hdd#L282-311 But this is probably beside the point. > Anyway... what I want to say is that you should be able to choose: > > --bootloaders grub,syslinux-efi > > or (if grub-pc was implemented there) > > --bootloaders grub-pc,syslinux-efi > > in a hdd target and 'syslinux' installation should be only triggered if > it's the first bootloader. This is what the current MR implements. In this case, the "syslinux-shared" configuration is installed, which is referenced by the "syslinux-efi" installation. See https://salsa.debian.org/matthijs-guest/live-build/blob/syslinux-efi/scripts/build/binary_syslinux#L165-171 > > Well, that's exactly how binary_hdd works right now... although the > multi bootloader part should be improved to have something better than: > > https://salsa.debian.org/live-team/live-build/blob/00eab3a77f3da176f3f0aa807b886206f8f0f0f1/scripts/build/binary_hdd#L60-86 In what sense would yo
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
on I guess that even ldlinux.c32 wouldn't be
> used but ldlinux.e64 instead.
Actually, ldlinux.e64 is only for EFI. This commit only touches
BIOS-related stuff. I'm not sure how "architecture dependent files" are
relevant here, since this commit just removes some files which are
really superfluous (since the 'syslinux' and 'extlinux' commands used to
install the bootloader in binary_hdd make sure to copy their own version
of these files into the image).
> 3.2) BTW Do you support both EFI IA32 and EFI X64 or only EFI X64 ?
Yes, but that's a later commit.
> > 4) Move syslinux modules into subdirectories (53901001)
>
> Shouldn't those c32 modules be moved to a folder named c32-modules (or
> c32mods for short name) instead?
>
> Let's see how you name the UEFI modules folder later.
>
> In "Add syslinux-efi bootloader support (a271f8f9)" you use modules32
> folder name for some c32. Shouldn't you use modules32 as a folder name
> in this "Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d)" commit
> in the first place?
>
> I'm not sure about this one I might be missing something.
I think the missing bit might be that
bootloaders/{syslinux,syslinux-shared} is installed into binary/boot,
while bootloaders/syslinux-efi is installed into binary/EFI/boot, so
these are distinct locations.
Also, EFI supports 32 and 64 bit (hence modules32 and modules64), but
BIOS is (by definition, I think) only 32-bit, so I just used "modules".
> > 5) Add syslinux-efi bootloader support (a271f8f9)
> 5.1) You have got a nice bug on that code XD . Just after the Echo_error
> statements about syslinux-efi not being supported there should be an
> exit 1 statement.
Thanks, fixed.
> 5.2) Anyway I don't think I like this code at all. I mean... you are
> supposed to create a new file named:
> scripts/build/binary_syslinux-efi
> and not hack around the existant one: binary_syslinux
That would make sense if I wanted syslinux-efi to be really indepenent,
but as I noted above, I wanted to make them share a single configuration
(and also allow syslinux-efi to be installed by itself). This seemed
like best way to achieve that, though alternative suggestions are
welcome :-)
I pushed a new version with the above changes to
https://salsa.debian.org/live-team/live-build/merge_requests/19
Gr.
Matthijs
signature.asc
Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Thierry, > Is there a chance that this work will be part of buster live-build > package, or is it too late already ? I'm not the maintainer of live-build, but given the freeze state that buster is in, I highly doubt this will make it into buster. Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Adrian, [ About removing --templates from the manpage ] > In that case IMO that commit should be in its own pull request and not > the current one. Done: https://salsa.debian.org/live-team/live-build/merge_requests/21 Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Adrian, > 1) What is the rationale behind removing the --templates option > explanation on manpage? I wondered about this option and looked around the source for it, but could not find any implementation for it, so it seemed good to remove the documentation for it. Prompted by your question, I looked a bit further and found that it was indeed removed: https://salsa.debian.org/live-team/live-build/commit/7e633e77f24b6f5ab9a8b22d7d6cf6521454d638 > Note: I will make more comments about this bug later in the week. Thanks! Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Luca & others, I've been working on syslinux-efi support in the past weeks and just submitted a MR with a working implementation, along with some small bootloader-related cleanups and refactors: https://salsa.debian.org/live-team/live-build/merge_requests/19 In the end, I opted to implement syslinux-efi rather than make grub-efi work on hdd images, since that seemed easier and allows preserving the existing bootloader config files in our project. Getting grub-efi to work on hdd images might still be an interesting project that could be implemented alongside syslinux-efi support, though I do not have any specific purpose for it as of yet. As predicted by others in this bug report, my work does not enable secure boot (which syslinux simply does not support), nor enable syslinux-efi support in iso/isohybrid images (since syslinux-efi does not support this, or at least it apparently does not work). Gr. Matthijs signature.asc Description: PGP signature
Bug#778317: live-build: improve cache support for rebuilds with different arch
Package: live-build Version: 1:20190311 Followup-For: Bug #778317 Hi folks, this bug still exists. The original report talks about erronously reusing the same debootstrap cache when chaning architectures, but the problem seems broader than that. E.g. when switching distributions, you'll also get (more subtle) problems (in my case, parted from stretch refusing to install to a chroot debootstrapped as buster or sid). As stated before, (a solution to) this issue has two variants: > 1) Users can easily switch architecture in their config and then > unknowingly run into issues upon rebuilding. > 2) For users building multiple images for different architectures, while > you could just use a separate build directory for each, this would allow > using the same build directory if desired, without having to throw away > or rename the existing cached bootstrap, things would just work > automatically. Personally, I would think fixing 1) is important - preventing users from running into issues when they change config but do not erase the cache. 2) is probably more tricky to implement and seems less important. As for implementation - I guess an obvious aproach would be to keep a file inside the cache directory that indicates how this particular debootstrap cache dir was created. This should include anything that can change the debootstrap outcome, so an obvious way to do that would simply be to store the debootstrap commandline used (and also check against it when restoring the cache). This probably requires merging bootstrap_debootstrap and bootstrap_cache. Gr. Matthijs signature.asc Description: PGP signature
Bug#925254: gitlab: Failed to upgrade (google-api-client not installed)
Package: gitlab Version: 11.8.2-3 Severity: important Dear Maintainer, I was trying to upgrade gitlab from 11.5.10 to the current version (11.8.2-3) in unstable. Most required packages are coming from buster with a few dependencies coming from unstable. The output from apt is as follows: Setting up gitlab (11.8.2-3) ... fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git Bundler could not find compatible versions for gem "google-api-client": In Gemfile: google-api-client (~> 0.23) fog-google (~> 1.8) was resolved to 1.8.2, which depends on google-api-client (~> 0.23.0) Could not find gem 'google-api-client (~> 0.23.0)', which is required by gem 'fog-google (~> 1.8)', in any of the sources. dpkg: error processing package gitlab (--configure): installed gitlab package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: gitlab E: Sub-process /usr/bin/dpkg returned an error code (1) I have no experience with ruby and how I can fix this. If you need more information please tell me and I'll try to provide it. One last thing, I am very grateful for providing gitlab in Debian. This must be an huge job with all the dependencies in ruby. Thank you! Regards, Matthijs -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gitlab depends on: ii asciidoctor1.5.8-1 ii bc 1.07.1-2+b1 ii bundler1.17.3-3 ii bzip2 1.0.6-9 ii dbconfig-pgsql 2.0.11 ii debconf [debconf-2.0] 1.5.71 ii gitlab-common 11.8.2-3 ii gitlab-workhorse 7.6.0+debian-1+b20 ii libjs-uglify 2.8.29-6 ii lsb-base 10.2019031300 ii nginx 1.14.2-2 ii nginx-full [nginx] 1.14.2-2 ii nodejs 10.15.2~dfsg-1 ii openssh-client 1:7.9p1-9 ii postfix [mail-transport-agent] 3.4.1-1 ii postgresql-client 11+200 ii postgresql-client-11 [postgresql-client] 11.2-2 ii postgresql-client-9.6 [postgresql-client] 9.6.10-0+deb9u1 ii postgresql-contrib 11+200 ii rake 12.3.1-3 ii redis-server 5:5.0.3-4 ii ruby 1:2.5.1 ii ruby-ace-rails-ap 4.1.1-1 ii ruby-acts-as-taggable-on 6.0.0-3 ii ruby-addressable 2.5.2-1 ii ruby-akismet 2.0.0-1 ii ruby-asana 0.8.1-2 ii ruby-asciidoctor-plantuml 0.0.8-1 ii ruby-attr-encrypted3.1.0-2 ii ruby-babosa1.0.2-2 ii ruby-base320.3.2-3 ii ruby-batch-loader 1.2.2-1 ii ruby-bcrypt-pbkdf 1.0.0-2 ii ruby-bootstrap-form2.7.0-1 ii ruby-browser 2.5.3-1 ii ruby-carrierwave 1.3.1-1 ii ruby-charlock-holmes 0.7.6-1 ii ruby-chronic 0.10.2-3 ii ruby-chronic-duration 0.10.6-1 ii ruby-commonmarker 0.17.9-1 ii ruby-connection-pool 2.2.2-1 ii ruby-creole0.5.0-2 ii ruby-default-value-for 3.1.1-3 ii ruby-device-detector 1.0.1-2 ii ruby-devise4.5.0-2 ii ruby-devise-two-factor 3.0.3-1 ii ruby-diffy 3.2.1-1 ii ruby-discordrb-webhooks3.3.0-1 ii ruby-doorkeeper4.4.2-1 ii ruby-doorkeeper-openid-connect 1.5.2-1 ii ruby-ed25519 1.2.4-1 ii ruby-email-reply-trimmer 0.1.6-1 ii ruby-escape-utils 1.2.1-1+b1 ii ruby-excon
Bug#924428: unblock: grfcodec/6.0.6-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package grfcodec
Version 6.0.6-3 adds a tiny patch to fix a serious bug (#922625).
unblock grfcodec/6.0.6-3
Thanks!
-- System Information:
Debian Release: 9.3
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'),
(500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (50, 'unstable'),
(1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru grfcodec-6.0.6/debian/changelog grfcodec-6.0.6/debian/changelog
--- grfcodec-6.0.6/debian/changelog 2018-05-10 21:42:34.0 +0200
+++ grfcodec-6.0.6/debian/changelog 2019-03-12 22:19:01.0 +0100
@@ -1,3 +1,11 @@
+grfcodec (6.0.6-3) unstable; urgency=medium
+
+ [ Jordi Mallach ]
+ * [e61a00b] Force build to abort upon endian_check failure. Thanks to
+Helmut Grohne for suggesting this fix (Closes: #922625)
+
+ -- Matthijs Kooijman Tue, 12 Mar 2019 22:19:01 +0100
+
grfcodec (6.0.6-2) unstable; urgency=medium
* [4dce67c] Bump debhelper version to v11
diff -Nru grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch
grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch
--- grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch
1970-01-01 01:00:00.0 +0100
+++ grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch
2019-03-12 22:19:01.0 +0100
@@ -0,0 +1,18 @@
+Description: Prevent infinite loop during build on endian_check failure
+Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922625
+Forwarded: https://github.com/OpenTTD/grfcodec/pull/1
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922625
+
+Index: grfcodec/Makefile
+===
+--- grfcodec.orig/Makefile
grfcodec/Makefile
+@@ -213,7 +213,7 @@ objs/$(ENDIAN_CHECK): src/endian_check.c
+
+ src/endian.h: objs/$(ENDIAN_CHECK)
+ $(_E) [ENDIAN] Determining endianness
+- $(_C)objs/$(ENDIAN_CHECK) $(ENDIAN_PARAMS) > src/endian.h || rm
src/endian.h
++ $(_C)objs/$(ENDIAN_CHECK) $(ENDIAN_PARAMS) > src/endian.h || { rm
src/endian.h; exit 1; }
+
+ FORCE:
+ %_r: FORCE
diff -Nru grfcodec-6.0.6/debian/patches/series
grfcodec-6.0.6/debian/patches/series
--- grfcodec-6.0.6/debian/patches/series2018-05-10 21:42:34.0
+0200
+++ grfcodec-6.0.6/debian/patches/series2019-03-12 22:19:01.0
+0100
@@ -1 +1,2 @@
# Series of quilt patches
+endian_check_cpp_abort_on_ftbfs.patch
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Steve, > In fact, one of the projects I've been trying to get to for a couple > of years now is simplifying things by going the other way: using GRUB > for everything and dropping syslinux on Debian media. Hm, that's another interesting thought. I was aiming for syslinux, since our current setup uses that (along with some custom configuration). However, that seems to be impossible to work with secure boot (which would be nice to have) and impossible to boot from optical media (which for my personal case is not an issue). I could imagine switching to grub completely (which means that this issue changes from "add syslinux-efi" to "make grub-pc & grub-efi work for hdd images"), though that's probably a bit more work for me and my client. I'll dig in a bit deeper to see how much work that would be. Thanks for everyone's input so far! Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Luca, > > So for the secure boot case in binary_grub-efi, what we do is that > > if the signed monolithic EFI binaries are available we copy those > > instead of building a new image. > > > > ... > > > > https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L79 Aha! Turns out I was looking at an old version, I messed up my git checkout apparently. That script indeed does what I would expect: Install shim alongside grub and use signed grub to make shim load it. > Ah silly me, I forgot something simple but quite fundamental: the point > of syslinux is to avoid using grub entirely. But indeed, I was aiming for syslinux, so none of this secure boot stuff will actually work with syslinux. Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Luca, > At a quick glance it all sounds good to me, although I can't say I have > a lot of experience with syslinux. Ok. > For feature parity, I'd encourage to look into supporting Secure Boot > like the grub-efi implementation does, since we are preparing to ship > that in Debian 10. It's not much extra work on top of adding the rest > anyway. Can you elaborate a bit on how grub-efi supports Secure Boot exactly? I can't really find anything about this in the code? Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, I see that a new efi firmware binary is built using grub-mkimage, so I suppose that that image is not already signed, and there is nothing suggesting that image is be signed at that time. Looking at binary_iso there is also no reference to signing or secure boot. AFAIU, to support secure boot, you need to sign the bootloader, typically using a key from MS. I've read about the Shim bootloader, which is signed and typically used to then load grub or other bootloaders (signed by the Debian key or other keys included in Shim). However, I can see no reference to shim either. Looking at the grub package more closely, I *think* that it installs shim alongside grub when using grub-install, but that is not used here? Regardless, how would you suggest we "support Secure Boot" with syslinux-efi exactly? AFAICT there is no syslinux-efi image available signed with the MS key, and I suspect it is not signed with the Debian key or any other key used by shim (also, since syslinux does not seem to support key verification on kernels, I guess there is no secure way to get syslinux booting under secure boot without compromising secure boot, but I might be missing an important point about SB here...). > > Since config sharing is easy and syslinux-efi is a matter of adding > > some files to the existing image, it would make sense to add > > syslinux-efi by default on normal syslinux hdd images (perhaps > > adding a new option to disable this?). I just noticed that lb config has a --bootloaders that supports *multiple* bootloaders, so that would be perfect way to support this. E.g. --bootloaders syslinux,syslinux-efi to have combined image (which would also become the default for hdd images), or an explicit --bootloaders syslinux or --bootloaders syslinux-efi to choose either one individually. Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Thomas, > > it seems isohybrid can include a small FAT filesystem with the > > bootloader files. [...] > > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI > > This describes the equipment of debian-live and debian-cd (DVD-*, BD-*, > netinst) ISOs. See e.g. debian-live-9.5.0-i386-xfce.iso and its > MBR partition table. I'm a bit confused by your message. When you say "This", are you referring to the syslinux isohybrid page? > Debian and nearly all others use GRUB 2 for their EFI capable ISOs. > See Knoppix 8.[12] for examples of SYSLINUX EFI in ISOs. > > SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from > HDD, SSD, and alike. Again, I'm confused. If syslinux-efi is known not to boot from CD/DVD/BD, then why do they document how to include it into an isohybrid image? Or does it then only work when booting the isohybrid image from a HDD, rather than CD? Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Package: live-build Version: 1:20180925 Severity: wishlist Hi folks, currently, live-build seems to only support EFI systems using the grub-efi bootloader, but not for netboot or hdd images (effectively only for iso images, I believe). Syslinux also has an EFI version, that can be installed through the syslinux-efi package. It would be useful for live-build to support this. I need this for a client, so I'm planning to implement support in the coming weeks. This report serves to track progress and discuss the implementation. I've done some experiments by adding syslinux-efi to an existing image manually (not with a full live-build image, but with my own hdd image that at least uses live-build for building the image, so should be representative in this area). This shows that adding syslinux-efi is fairly easy. The existing FAT partition can function as an ESP (EFI System Partition) as it is now. Installing the bootloader is a matter of dumping some files in the EFI/BOOT directory. This lets the bootloader be detected as a fallback bootloader, which is AFAIU intended for removable media. Syslinux needs some additional files (ldlinux, additional modules, configuration) which can live in that same directory. Both 32-bit and 64-bit EFI can be supported at the same time, by installing both versions of syslinux-efi (named bootx64.efi and bootia32.efi respectively). One caveat is that syslinux needs different .c32 modules for both architectures (though they are both named .c32 and are explicitly referenced in the config file). This means either duplicating the bootloader configuration file for 32 and 64 bit (which hinders modifications to the config), or putting the modules in subdirectories and using the PATH config directive to point to either directive before including the common configuration. I have not tried this latter approach but it is described here (though currently syslinux.org seems to be unavailable, I tried the Google cache): https://www.syslinux.org/archives/2014-August/022545.html (subject: syslinux efi configuration file name proposal) I've also tried to let the syslinux-efi config file include the normal syslinux configuration file (or at least the bulk that is in live.cfg), which seems to work just fine. Since config sharing is easy and syslinux-efi is a matter of adding some files to the existing image, it would make sense to add syslinux-efi by default on normal syslinux hdd images (perhaps adding a new option to disable this?). This also seems to hold for ISO9660 images, where it seems isohybrid can include a small FAT filesystem with the bootloader files. This might need some additional work to generate the filesystem image and/or pass options when generating the iso. See: https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI Using syslinux-efi exclusively (e.g. passing it to --bootloader and not installing normal syslinux) might also be an extra option. However, I'm not much interested in this case, so I will likely not implement it (I'll try not to make it too hard to add it later). In terms of code, this is probably best implemented in the existing binary_syslinux script. The bulk of what needs to happen is essentially copying bootloader files from config/bootloaders into binary, taking care to resolve symlinks. I'm planning to put the code that does that into a shell function, so it can be called at the current place and then a second time for syslinux-efi later. I think it would be good to copy files *from* config/bootloaders/syslinux-efi-addon or something similar, to leave config/bootloaders/syslinux-efi available for an EFI-only image. These two directories would be identical in terms of syslinux binary files, but the configurations would differ (the addon would include the normal boot/syslinux/syslinux.cfg, while the standalone version would contain the complete config). I haven't really looked at the iso version yet (which is also not my primary interest, but I think it would be good to handle as well). Happy to hear any thoughts :-) Gr. Matthijs
Bug#921447: etckeeper: Unnecessary dependency on python2
On Tue, 5 Feb 2019 at 19:53, Antoine Beaupré wrote: > I guess I could just drop the "python" dependency from there completely > and rely on the bzr bits to do the right thing if they are setup. Yes, in principle you could write out git | (bzr, python) as git | bzr, git | python but this feels pointless since bzr already depends on python. Dropping the dependency on python entirely seems fine to me. The technically most correct solution would be to split etckeeper into multiple packages along the lines of etckeeper-common etckeeper-git (Depends: etckeeper-common, git) etckeeper-bzr (Depends: etckeeper-common, bzr, python2) etckeeper (Depends: etckeeper-git | etckeeper-bzr) But considering how tiny these would be and the overhead and expense involved, this I don't feel it would be worth it. It would also be a backwards-incompatible change for non-git users, since APT has no way to pick the correct variant. > In fact, looking at #906000 again, I'm not sure that's the right > solution either. To quote that bug report: > > > etckeeper installs a Python module but no longer has a python > > dependency. > > If we remove the Python dependency, we reopen that bug. I'm not sure > what the implications of that are. I don't suppose it is an option to retroactively mark it INVALID? While I understand that packages of python modules need to depend on python, and packages that include python modules need to consider whether they require a dependency on python, such a dependency is neither needed nor desired in this case. > Bug #883146 tracks bzrlib python3 support. Upstream has released "3.0 > pelican" that ports to py3, but that hasn't landed in Debian > yet. There's also #883145 which explicitely requests etckeeper to be > ported to python3. A dependency on python3 would certainly be less offensive, but it would still be inappropriate and may end up unnecessarily pulling in python3 on systems where it was not previously installed.
Bug#921447: etckeeper: Unnecessary dependency on python2
Package: etckeeper Version: 1.18.10-1 Severity: normal Dear Maintainer, "apt-get install etckeeper" on one of my systems advised me: The following additional packages will be installed: libpython-stdlib libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib python python-minimal python2 python2-minimal python2.7 python2.7-minimal I'm not very happy about this. Python 2 is pretty much unmaintained and is approaching its (already extended) EOL date. Moreover, it seems that etckeeper only requires python when using bzr as VCS (which I'm not). Since bzr is an optional dependency of etckeeper, it makes no sense for python to be a mandatory dependency.
Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)
severity 919259 normal found 919259 232-25 retitle 919259 Reexecuting fails in containers without CAP_SYS_ADMIN thanks Hey Michael, > My suggestion would be to roll back to 232-25+deb9u1 and then gradually > upgrading to deb9u2, deb9u2 ... deb9u3 Yeah, that was my intention. I discovered some interesting things. - On my host system, systemd is now also upgraded without problems. - Restarting a container works just fine, even with deb9u8. However, the problem occurs when re-execing (e.g. systemctl daemon-reexec). - Downgrading to deb9u1 and re-execing also breaks, so this is not broken by the upgrade that happened this week. - Looking in the logs, I found that the last time re-exec happened (succesfully) was on 2017-09-12. It seems that was from a manual upgrade, so I am not sure what version that was exactly. From old unattended upgrade e-mails, I *suspect* it was deb9u1. - Looking through my config git history, I did not find any seemingly relevant changes in the lxc config since 2017. However, I think I did upgrade from jessie to stretch since then (or maybe just before then, but I probably didn't restart the containers and/or system until later). - For good measure, I also tested the original 232-25 version, which also breaks. - When I remove `lxc.cap.drop = sys_admin` from the lxc config, reexec works fine again. So it seems that *some* lxc upgrade since 2017 broke this. What is broken is re-execing systemd inside a container running without CAP_SYS_ADMIN. I'm not sure if this means this bug should be against lxc instead, but until we know more, I guess keeping it against systemd would be good. Since booting still works (and this issue can be worked around be rebooting the container), I'd say this issue can be downgraded from important to normal. I've went ahead and did this, feel free to revert if you feel otherwise. Going forward, I guess it would be good to investigate why the re-exec fails, based on the error messages shown: systemd[1]: Failed to create /../../init.scope control group: Operation not permitted systemd[1]: Failed to allocate manager object: Operation not permitted One interesting question is also why the initial startup does *not* fail, but the re-exec does. I'm out of time again for now. I'll have a closer look at what this init.scope control group is exactly and how systemd handles it on normal startup. Any additional thoughts are welcome :-) Gr. Matthijs signature.asc Description: PGP signature
Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)
Package: systemd Version: 232-25+deb9u7 Severity: important Hi folks, this morning, some lxc containers on my machine did an unattended upgrade from systemd 232-25+deb9u1 to version 232-25+deb9u7. As part of that upgrade, systemd was reexecuted, which resulted in systemd freezing: systemd[1]: Reloading. systemd[1]: Reexecuting. systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT + systemd[1]: Detected virtualization lxc. systemd[1]: Detected architecture x86-64. systemd[1]: Failed to create /../../init.scope control group: Operation not permitted systemd[1]: Failed to allocate manager object: Operation not permitted systemd[1]: Freezing execution. Looking in my logs, the last time systemd was reexeuted like this was in 2017, and neither of the error messages show above were present then. This problem occurred inside all lxc containers running on the machine that upgraded systemd. I suspect that the problem is related to running inside a container, but the host has not upgraded systemd yet, so I cannot compare. My containers run in unprivileged mode (e.g. without CAP_SYS_ADMIN and others, see config below), which has caused some problems with systemd in the past, so I suspect this is relevant in this case as well. After the above happened, systemd froze (and is no longer reachable through systemctl), but the systems are still running normally otherwise. I haven't investigated more closely yet (e.g. restarting containers, downgrading systemd, etc.), since I'm on a mobile connection now and don't want risk breaking it further just yet. I looked through the changelog from deb9u1 to deb9u7, and nothing springs out as an obvious cause. Only the last update was a security update (relating to the journal only), so this might be caused by one of the previous non-security updates as well (which I did not have installed yet). I'll investigate further soon. If you have suggestions on what changes might be causing this, I'm happy to hear them. Gr. Matthijs lxc config for one container: lxc.utsname = login.local lxc.rootfs = /containers/login lxc.console.logfile = /var/log/lxc/login.console lxc.logfile = /var/log/lxc/login.log lxc.network.type = veth lxc.network.flags = up lxc.network.veth.pair = lxc-login lxc.network.name = eth0 lxc.network.link = br-lxc lxc.network.ipv4 = 10.42.0.16/24 lxc.network.ipv4.gateway = auto lxc.network.script.up = /etc/lxc/enable-hairpin lxc.tty = 4 lxc.pts = 256 lxc.kmsg = 0 lxc.autodev = 1 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 254:0 rwm lxc.mount.auto = proc:rw lxc.mount.auto = sys:rw lxc.mount.auto = cgroup:mixed lxc.mount.entry = tmpfs dev/shm tmpfs rw,nosuid,nodev,create=dir 0 0 lxc.mount.entry = tmpfs run tmpfs rw,nosuid,nodev,mode=755,create=dir 0 0 lxc.mount.entry = tmpfs run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,create=dir 0 0 lxc.mount.entry = debugfs sys/kernel/debug debugfs rw,relatime 0 0 lxc.mount.entry = mqueue dev/mqueue mqueue rw,relatime,create=dir 0 0 lxc.mount.entry = hugetlbfs dev/hugepages hugetlbfs rw,relatime,create=dir 0 0 lxc.cap.drop = sys_module lxc.cap.drop = sys_rawio lxc.cap.drop = sys_time lxc.cap.drop = net_admin lxc.cap.drop = audit_control lxc.cap.drop = sys_admin -- Package-specific info: -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (800, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1+deb9u1 ii libc6 2.24-11+deb9u1 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.7.6-2+deb9u3 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod223-2 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1+deb9u1 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b3 ii libsystemd0 232-25+deb9u7 ii mount 2.29.2-1+deb9u1 ii procps 2:3.3.12-3+deb9u1 ii util-linux 2
Bug#910990: openttd FTCBFS: uses the build architecture pkg-config
Hi Helmut, On Sun, Nov 18, 2018 at 04:27:29PM +0100, Helmut Grohne wrote: > Hi Matthijs, > > On Sat, Nov 17, 2018 at 09:28:54PM +0100, Matthijs Kooijman wrote: > > Thanks for testing and provide a patch. I've included in the build, and > > verified it works. I did run into a problem running on a system where > > buildtools.mk did not exist, due to the % wildcard rule (see > > https://lists.debian.org/debian-mentors/2011/10/msg00308.html and > > https://salsa.debian.org/openttd-team/openttd/commit/2a60f8c976c12f3338655ba4c5130213987dde9a > > ) > > Dang. I didn't think of how make would handle absence. Me neither, but at least the error message was Googlable :-) > So buildtools.mk will always exist in buster and later releases. You > only get problems when backporting to stretch or older (and we don't > care about cross compilation there). The -include was meant to make it > backport-friendly, but it ultimately failed doing exactly that. I noticed it because git-buildpackage first cleans my git checkout to generate a source package for pbuilder, which I do on a stable system. > How about adding an empty rule for /usr/share/dpkg/buildtools.mk? Would > that work for you? That would work, but I opted for replacing the wildcard rule with an explicit list. See the links I noted: https://lists.debian.org/debian-mentors/2011/10/msg00308.html https://salsa.debian.org/openttd-team/openttd/commit/2a60f8c976c12f3338655ba4c5130213987dde9a So I think I'm good, I just wanted to give you a heads up for possible future patches :-) Gr. Matthijs signature.asc Description: PGP signature
Bug#906906: icu FTCBFS: fails linking -licu-le-hb in the native pass
Hey folks, > Meanwhile, Matthijs can you tell us how the OpenTTD layout work goes? > May you have any ETA from its upstream? It would be good to drop > icu-le-hb very soon. As already noted elsewhere, I just uploaded an OpenTTD version without the iculx and icu-le-hb dependency. Not sure how that affects this bug exactly, but I'm confident you guys will figure that out :-) Gr. Matthijs signature.asc Description: PGP signature
Bug#910990: openttd FTCBFS: uses the build architecture pkg-config
Hi Helmut, > openttd fails to cross build from source, because it uses the build > architecture pkg-config. The build system expects the packaging to pass > --pkg-config to use a triplet-prefixed pkg-config. Doing so is > sufficient to make openttd cross buildable. Please consider applying the > attached patch. Thanks for testing and provide a patch. I've included in the build, and verified it works. I did run into a problem running on a system where buildtools.mk did not exist, due to the % wildcard rule (see https://lists.debian.org/debian-mentors/2011/10/msg00308.html and https://salsa.debian.org/openttd-team/openttd/commit/2a60f8c976c12f3338655ba4c5130213987dde9a ) Gr. Matthijs signature.asc Description: PGP signature
Bug#898571: build dependency cycle between icu and icu-le-hb
Hi folks, I just uploaded openttd 1.8.0-2, which no longer has the ICU layout API enabled. This should clear the way for dropping iculx and icu-le-hb. This change makes at least Arabic and Hebrew support in OpenTTD pretty much unusable. However, some additional investigation suggests that Harfbuzz and ICU should provide enough building blocks to implement something better again. See upstream github for discussion about that: https://github.com/OpenTTD/OpenTTD/issues/6922 Gr. Matthijs signature.asc Description: PGP signature
Bug#913509: openttd FTBFS with ICU 63.1
Hi László, thanks for your investigation and patch. I ended up backporting the upstream patches for the issue, which turned out to be identical to your patch :-) I've just uploaded a version with this patch, as well as a bunch of other pending changes. Gr. Matthijs signature.asc Description: PGP signature
Bug#913863: libicu63: Versioned Breaks against openttd too strict
Hi László & Ivo, > > That's too much time for blocking the ICU transition. I'll clear this > > barrier of the openttd NMU in some days. :-/ Ah, I hadn't realized this was blocking a transition. Because of that, I tried a bit harder to find time, and just uploaded a fixed version to unstable. > I added a removal hint for openttd, to allow icu to migrate to testing. As > soon as a fixed version of openttd is ready, it can come back. Is anything needed for making openttd come back to testing, or will an upload that fixes the relevant bugs sufficient? Gr. Matthijs signature.asc Description: PGP signature
Bug#913863: libicu63: Versioned Breaks against openttd too strict
Hi Lásló, > That's too much time for blocking the ICU transition. I'll clear this > barrier of the openttd NMU in some days. :-/ Prompted by your other mail, I found some time in the airport today to look at the ICU build issue in OpenTTD. I still have a few minor things to include, but I should be able to upload a fixed version somewhere this weekend. Gr. Matthijs signature.asc Description: PGP signature
Bug#913863: libicu63: Versioned Breaks against openttd too strict
Hey László, > Matthijs working on a normal package upload? At least he answers my > mails quick and I thought he can apply my patch and upload it as > 1.8.0-2 package version. Ack, it's on my list. I'm a bit busy these weeks, but I expect to find some time in the next 2/3 weeks. Gr. Matthijs signature.asc Description: PGP signature
Bug#898571: build dependency cycle between icu and icu-le-hb
Hi Laszlo, > I do Cc its maintainer Matthijs and if he acknowledges I will drop > libiculx and icu-le-hb altogether. Yeah, I think that dropping icu-le-hb is the best course forward. I want to doublecheck that that does not have any unintended side effects. Ok if I get back to you about this in 2/3 weeks? Or would you rather act on this before then? Gr. Matthijs signature.asc Description: PGP signature
Bug#913635: php7.3-common: Repeatable segfault in php7.3 when running Cacti poller since upgrade to 7.3
Package: php7.3-common Version: 7.3.0~rc5-1 Followup-For: Bug #913635 Dear Maintainer, It is also reproducible when running php7.3-fpm (using nginx as frontend). I cannot install php7.3-fpm-dbgsym as it is not available on amd64 architecture. [ 2989.258352] php-fpm7.3[8102]: segfault at ip 562cd78d0616 sp 7fffc9c5cad8 error 7 in php-fpm7.3[562cd78a9000+269000] [ 2989.258357] Code: 49 03 4e 08 f7 c6 00 ff 00 00 74 20 48 8b 10 40 80 fe 0a 75 15 48 8d 42 08 f7 42 10 00 ff 00 00 74 0a 48 8b 52 08 ff 02 eb 02 02 48 8b 10 8b 40 08 49 83 c7 20 48 89 11 89 41 08 c3 53 49 63 -- Package-specific info: Additional PHP 7.3 information PHP @PHP_VERSION SAPI (php7.3query -S): PHP 7.3 Extensions (php7.3query -M -v): Configuration files: /etc/php/7.3/mods-available/calendar.ini extension=calendar.so /etc/php/7.3/mods-available/ctype.ini extension=ctype.so /etc/php/7.3/mods-available/exif.ini extension=exif.so /etc/php/7.3/mods-available/fileinfo.ini extension=fileinfo.so /etc/php/7.3/mods-available/ftp.ini extension=ftp.so /etc/php/7.3/mods-available/gettext.ini extension=gettext.so /etc/php/7.3/mods-available/iconv.ini extension=iconv.so /etc/php/7.3/mods-available/pdo.ini extension=pdo.so /etc/php/7.3/mods-available/phar.ini extension=phar.so /etc/php/7.3/mods-available/posix.ini extension=posix.so /etc/php/7.3/mods-available/shmop.ini extension=shmop.so /etc/php/7.3/mods-available/sockets.ini extension=sockets.so /etc/php/7.3/mods-available/sysvmsg.ini extension=sysvmsg.so /etc/php/7.3/mods-available/sysvsem.ini extension=sysvsem.so /etc/php/7.3/mods-available/sysvshm.ini extension=sysvshm.so /etc/php/7.3/mods-available/tokenizer.ini extension=tokenizer.so -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages php7.3-common depends on: ii libc6 2.27-8 ii libssl1.1 1.1.1-2 ii php-common 2:68 ii ucf 3.0038 php7.3-common recommends no packages. php7.3-common suggests no packages. Versions of packages php7.3-cli depends on: ii libargon2-1 0~20171227-0.1 ii libc62.27-8 ii libedit2 3.1-20180525-1 ii libmagic11:5.34-2 ii libpcre2-8-0 10.32-3 ii libsodium23 1.0.16-2 ii libssl1.11.1.1-2 ii libxml2 2.9.4+dfsg1-7+b2 ii mime-support 3.61 ii php7.3-json 7.3.0~rc5-1 ii php7.3-opcache 7.3.0~rc5-1 ii php7.3-readline 7.3.0~rc5-1 ii tzdata 2018g-1 ii ucf 3.0038 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages php7.3-cli suggests: pn php-pear Versions of packages php7.3-fpm depends on: ii libapparmor12.13.1-3+b1 ii libargon2-1 0~20171227-0.1 ii libc6 2.27-8 ii libmagic1 1:5.34-2 ii libpcre2-8-010.32-3 ii libsodium23 1.0.16-2 ii libssl1.1 1.1.1-2 ii libsystemd0 239-11 ii libxml2 2.9.4+dfsg1-7+b2 ii mime-support3.61 ii php7.3-cli 7.3.0~rc5-1 ii php7.3-json 7.3.0~rc5-1 ii php7.3-opcache 7.3.0~rc5-1 ii tzdata 2018g-1 ii ucf 3.0038 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages php7.3-fpm suggests: pn php-pear -- no debconf information
Bug#897233: openttd: Replace ICU ParagraphLayout usage
Hey folks, I've (finally) opened an upstream bug for this to track progress: https://github.com/OpenTTD/OpenTTD/issues/6922 If this cannot be fixed upstream in a timely manner, one additional option would be to simply not compile OpenTTD with ICU layout support. There is already a simpler fallback layouter in place that is probably satisfactory for western languages, but probably provides bad results for RTL languages, or languages where word-breaking works differently. I'm wouldn't be too happy with this, though I'm not sure how much users would really be affected (From a quick glance, popcon does not collect locales...). Gr. Matthijs signature.asc Description: PGP signature
Bug#906906: icu FTCBFS: fails linking -licu-le-hb in the native pass
> Meanwhile, Matthijs can you tell us how the OpenTTD layout work goes? > May you have any ETA from its upstream? It would be good to drop > icu-le-hb very soon. There's not much progress here. I haven't got time to really work on this, and haven't gotten around to pushing at this since we first spotted the issue a few months ago. Previously I've discussed this with upstream through IRC, but this week I opened up an upstream bug report for this, but not much is happening there yet: https://github.com/OpenTTD/OpenTTD/issues/6922 Gr. Matthijs signature.asc Description: PGP signature
Bug#846320: Duplicate consolekit assertion bugs
package consolekit merge 898411 846320 thanks Hi, I found these two bugs are actually about the same issue, so I went ahead and merged them. I'm also seeing this issue on 0.4.6-6. Looking around, I found an old bug report at Fedora which suggests this might be caused by ConsoleKit calling udev-acl wrongly: https://bugzilla.redhat.com/show_bug.cgi?id=611159 That report suggests that ConsoleKit calls commands in run-seat.d with a plain action argument, while udev-acl expects an --action option. This is confirmed by my log output: Sep 24 06:00:08 tika udev-acl.ck[21215]: g_slice_set_config: assertion 'sys_page_size == 0' failed Sep 24 06:00:08 tika console-kit-daemon[6695]: missing action And by running it manually: $ ls -l /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck lrwxrwxrwx 1 root root 18 Jan 25 2017 /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck -> /lib/udev/udev-acl $ /lib/udev/udev-acl foo (process:12937): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed missing action OTOH, it seems that the assertion might be unrelated to this, as it even occurs with `--help`, so the assertion might be a bug in udev, while the "missing action" error might be a bug in the consolekit package (since that suplies the udev-acl.ck symlink). $ /lib/udev/udev-acl --action=foo --user=123 (process:12947): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed $ /lib/udev/udev-acl --help (process:12989): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Usage: udev-acl --action=ACTION [--device=DEVICEFILE] [--user=UID] However, after writing this I read that consolekit is no longer maintained and mostly replaced by systemd-logind, so I ended up simply removing the consolekit package which "fixes" this log message. Gr. Matthijs signature.asc Description: PGP signature
