Bug#1071427: RFS: rumur/2024.05.07-1 -- model checker for the Murphi language
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rumur": * Package name : rumur Version : 2024.05.07-1 Upstream contact : Matthew Fernandez * URL : https://github.com/Smattr/rumur * License : Unlicense * Vcs : https://github.com/Smattr/rumur/tree/packaging/debian Section : devel The source builds the following binary packages: rumur - model checker for the Murphi language To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rumur/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2024.05.07-1.dsc Changes since the last upload: rumur (2024.05.07-1) unstable; urgency=medium . * New upstream release. * Fix inaccurate libatomic checks in autopkgtests. Closes: #1018205. * Fix Vcs-Browser URL. Closes: #1018202. * Update debian-compat Build-Depends from 12 to 13. Regards, -- Matthew Fernandez
Bug#1018205:
tl;dr: I’ll attempt to address this in the next upload. Revisiting this, the logs are expired, but I think I finally understand the problem. This will take a bit of explanation, so strap in (or ignore this mail)… I now believe the failure was the rumur-model autopkgtest, though my previous replies suggest at the time I thought it was the rumur-run-model autopkgtest. This perhaps explains why Tobi was confused, when I pointed to an upstream commit that touched a file that has no interaction with the rumur-model test. This package uses both the GCC __sync built-ins¹ and the GCC __atomic built-ins². Either of these may require linking against libatomic, depending on your platform. However, the rumur-model test just checks a single __sync built-in does not need libatomic. On ARM, how these built-ins are lowered (to either inline assembly or a call to libatomic) depends on the architecture. In armv8.1-a, ARM added so-called “Large System Extensions”, the relevant feature of which to us is a compare-and-swap instruction. However, GCC only makes use of this for the __sync built-ins, not the __atomic built-ins.³ The upshot of this is that the rumur-model test could run its __sync test, conclude libatomic was not needed, then run its actual compilation which additionally used __atomic and would fail. My hypothesis is that the ARM buildd workers were a mixture of which would explain why we were seeing disagreeing results. Underneath all of this, what the atomics are used for is implementing a lock-free algorithm. So lowering to a call into libatomic and then taking a lock somewhat defeats the purpose. Once I realised this was happening in scenarios on ARM where it could be avoided, I tried to address this. A first attempt at this crashed GCC.⁴ After working around this,⁵ I believe I have something that avoids libatomic more reliably.⁶ Of course, none of this fixes the check the rumur-model test does that uses only one __sync built-in, but I think I now understand all the moving pieces and am capable of fixing this in the next upload. Tobi, thanks for reporting this, without which I probably never would have noticed the problem. I am also indebted to Caroline Xu, a Rumur user. Recent discussion with Caroline finally gave me the clues I needed to put all this together. ¹ https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html ² https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html ³ See https://gcc.gnu.org/pipermail/gcc-help/2017-June.txt and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 for a laborious discussion of why this is. ⁴ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114310 ⁵ https://github.com/Smattr/rumur/commit/28eb088ce8fdd5c039c19d39a4ef6cd85d4ea70f ⁶ https://github.com/Smattr/rumur/commit/adba81cde626901077a1c946dc57446660db47e3
Bug#1066211:
Thanks, this is very timely, I was just discussing it with upstream a couple days ago. On Mon, 6 May 2024 at 23:39, Arvin Sedererdj wrote: > Control: tags -1 + patch > > >
Bug#968415: susv4: Patch
Package: susv4 Version: 7.20180621 Followup-For: Bug #968415 X-Debbugs-Cc: mlukow...@sdf.org --- debian/susv4.postinst.orig 2024-05-02 15:56:25.243665232 -0400 +++ debian/susv4.postinst 2024-05-02 15:56:34.133076612 -0400 @@ -8,7 +8,7 @@ wget -P $TEMPDIR http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2 echo Verifying SHA512 checksum... -SHA512SUM="c356d8b9b311201bef8900add7aab18b822af0e6e1a0c63b141c7c5f5e401bf25f39dcf9976577e934b7bfc939574c965ebefd63fef7a57ad6feb875e237fd7d" +SHA512SUM="2484d24d19b9731808c61219b61d63cdf4d8dff6498fb4655478b76808a583064a5cfbcfcf18f1d27c56e03a6b47cc6833f94483784ec29059bef063724c2567" [ x"$(sha512sum $TEMPDIR/susv4-2018.tar.bz2 | cut -f1 -d\ )" = x"$SHA512SUM" ] || (rm -rf $TEMPDIR; exit 1) echo Untarring... -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages susv4 depends on: ii bzip2 1.0.8-5.1 ii wget 1.24.5-1 susv4 recommends no packages. susv4 suggests no packages. -- no debconf information
Bug#968415: susv4: Patch with new sha512sum
Package: susv4 Version: 7.20180621 Followup-For: Bug #968415 X-Debbugs-Cc: mlukow...@sdf.org Dear Maintainer, --- debian/susv4/DEBIAN/postinst.orig 2024-05-02 15:49:52.972725058 -0400 +++ debian/susv4/DEBIAN/postinst2024-05-02 15:50:01.506839488 -0400 @@ -8,7 +8,7 @@ wget -P $TEMPDIR http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2 echo Verifying SHA512 checksum... -SHA512SUM="c356d8b9b311201bef8900add7aab18b822af0e6e1a0c63b141c7c5f5e401bf25f39dcf9976577e934b7bfc939574c965ebefd63fef7a57ad6feb875e237fd7d" +SHA512SUM="2484d24d19b9731808c61219b61d63cdf4d8dff6498fb4655478b76808a583064a5cfbcfcf18f1d27c56e03a6b47cc6833f94483784ec29059bef063724c2567" [ x"$(sha512sum $TEMPDIR/susv4-2018.tar.bz2 | cut -f1 -d\ )" = x"$SHA512SUM" ] || (rm -rf $TEMPDIR; exit 1) echo Untarring... -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages susv4 depends on: ii bzip2 1.0.8-5.1 ii wget 1.24.5-1 susv4 recommends no packages. susv4 suggests no packages. -- no debconf information
Bug#1070195: glib2.0: test failure with pcre2/10.43: asserts that a variable-length lookbehind is an error
Hi, On 01/05/2024 17:29, Simon McVittie wrote: Matthew, if pcre2 (>= 10.43) isn't urgent, please don't upload it to unstable until after this glib2.0 bug has been fixed (and ideally also migrated to testing). Thanks for looking into this! I'm happy to hold off on a pcre2 upload to unstable until this has happened. Regards, Matthew
Bug#1069890: Resignation & call for votes to elect the Chair
Hi, ===BEGIN A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Stefano Rivera E: Timo Röhling F: Craig Small G: Matthew Vernon H: Sean Whitton ===END I vote H > A = B = C = D = E = G > F If no-one else wants to be chair when Sean leaves, I'd be willing to do so. Regards, Matthew OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067524: ITP: precis -- Java implementation of the PRECIS Framework
Package: wnpp Severity: wishlist Owner: Matthew Fennell X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: precis Version : 1.1.0 Upstream Contact: Christian Schudt * URL : https://github.com/sco0ter/precis * License : Expat Programming Lang: Java Description : Java implementation of the PRECIS Framework This Java library validates and prepares Unicode strings, so that they can safely be used in application protocols, e.g. when dealing with usernames and passwords. It supports RFCs 8264, 8265, 8266 and 5893, and is designed to replace software like Libidn's Stringprep class by handling internationalised strings in a more coherent way. It is a dependency of of Babbler, a Java library for interacting with XMPP servers, which is in turn used by several transports, as well as caas, an automated compliance tester with an open RFP (#959816). I hope to maintain this package within the Debian Java Maintainers team. I am not a Debian Developer, so will need to look for sponsorship once the package is ready.
Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library
bret curtis wrote: > > One thing I noticed is that upstream integrated their own fork [1] of > > glslang directly into the build [2] as of 1.0.3 [3]. > > Indeed, I created an issue to track this and Robert is aware of the > situation. AnyOldName3 and myself are working together with upstream > glslang that would make it findable and work correctly via cmake so that > cmake itself would not have to carry its own vulkan and glslang files. [1] Apologies, I somehow missed your Github issue. Looks like you're about 10 steps ahead of where I was when I wrote the email! :) > > I see a few options: > > > > 1) We work with upstream to unvendor the dependency > > > > We are already doing this. :) The trickle down should be happening now. [2] > > > > 2) We disable the shader compiler part of vsg > > > > Please no; while this would get the package into Debian faster it would be > useless for OpenMW, or specifically the Vulkan work we are doing there > which makes use of VSG's glslang. > > > > 3) We patch the build to depend on Debian's glslang package > > > > If we can't wait for 1 to trickle down into Debian's repo; this is a way > forward. I have a branch I've been working on that would resolve that. [3] Agreed - 1 makes most sense to me as well. I have a few machines with different configurations, so feel free to mail me if it would help for me to test against your branch (or anything else for that matter). Thanks, Matthew
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
On Sun, Mar 10, 2024 at 10:06:42AM +0800, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: csm...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Craig Small be > appointed by the Debian Project Leader to the Technical Committee. > > C: Recommend to Appoint Craig Small > F: Further Discussion > ===END I vote C > F signature.asc Description: PGP signature
Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library
Thanks Bret for your work to package this. I've been keeping an eye on upstream and this ITP for a while. One thing I noticed is that upstream integrated their own fork [1] of glslang directly into the build [2] as of 1.0.3 [3]. Their reasoning was that: > Relying upon glslang has turned out to be far more painful that it should be, > with the API evolving over the years, different packaging of glslang being > done in various ways on various platforms has meant that it's been a wake a > mole task trying to keep the VSG working on all the various build and runtime > combinations involving glslang and SPIRV-Tools. I believe this approach would violate Debian Policy on vendored dependencies, which are already available in glslang-dev. I see a few options: 1) We work with upstream to unvendor the dependency 2) We disable the shader compiler part of vsg 3) We patch the build to depend on Debian's glslang package 1) seems unlikely without a lot of work to help fix the original issues encountered by upstream. This was a deliberate choice on their side, so it would require some discussion to see if they'd be happy to try. 2) has a build flag for this, but it disables a significant portion of the library. 3) seems doable - I got it working without build or runtime issues locally, but I'm not sure if this would work in all cases, or if upstream would be happy for us to do this without further discussion. Do you have any thoughts on what is the best approach? IANADD, or involved with vsg; I'm just a user, so I may have missed something obvious. [1] https://github.com/vsg-dev/glslang [2] https://github.com/vsg-dev/VulkanSceneGraph/discussions/728 [3] https://github.com/vsg-dev/VulkanSceneGraph/releases/tag/VulkanSceneGraph-1.0.3
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Mon, Mar 04, 2024 at 04:08:37PM +, Simon McVittie wrote: > Copying context from elsewhere in the thread, Sam Hartman wrote: > > Are there solutions in the space of having glib2.0-0 continue to exist > > as a package depended on by glib2.0-0t64 or depending on the new library > > allowing you to replace the postrm? > > to which I replied: > > If libglib2.0-0 continues to exist, then packages that expect the affected > entry points to have 32-bit time_t will still have their dependencies > satisfied, but then when they call the affected entry points, they will > crash, because their time_t is not the same size as GLib's. So as far > as I can see, this is functionally equivalent to reverting the rename: > to be correct, it would have to be accompanied by versioned Breaks on > every package that calls into the affected entry points. Sorry, yes, because we're transitioning the package name but not the soname. My mistake.
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
I agree with the conclusions drawn here, but feel that it's possibly worth making a stronger general statement that policy should never prevent the implementation of a well-considered simple solution. I would like some further analysis of Sam's proposal, though - I don't think there's any advantage in undoing the existing solution, but if it would work then it's maybe a more straightforward solution for any similar issues in future?
Bug#1064624: Hard to short-stroke an encrypted drive
On Mon, Feb 26, 2024 at 12:34:50AM +0100, Pascal Hambourg wrote: > Not if you do not write anything to them, or if you TRIM them. You can stop explaining to me how TRIM works. commit 0c659b82d11e Author: Matthew Wilcox Date: Thu Apr 2 10:37:25 2009 -0400 ata: Add TRIM infrastructure > You may either > - tell the installer not to erase (=write) the encrypted partition (if > guided partitioning prompts it, not sure) > or > - enable "discard" in /etc/crypttab (should be the default) > - create a logical volume in the free VG space > - blkdiscard the logical volume Last time I checked, dm-crypt did not pass DISCARD requests through to the underlying device because it's a security hazard.
Bug#1064624: Hard to short-stroke an encrypted drive
On Sun, Feb 25, 2024 at 11:42:37PM +0100, Pascal Hambourg wrote: > On 25/02/2024 at 05:40, Matthew Wilcox wrote: > > > > The partitioner "guided partitioning" offers me: > > > > - use the largest continuous free space > > - use entire disk > > - use entire disk and set up LVM > > - use entire disk and set up encrypted LVM > > > > I want "use largest contiguous space and set up encrypted LVM". > > That would let me reserve 200GB of my SSD as unencrypted free space, > > which will improve the write endurance of my SSD. > > Alternatively, the installer allows to reserve free space in the encrypted > volume group. That does not accomplish my goal of extending the life of my SSD. The SSD will see those blocks as "in use" because they have encrypted data written to them (it cannot tell that they are encrypted blocks of zeroes because, well, they're encrypted). The unused area has to be part of the unencrypted disk. And then I have to call TRIM on it. > > Also once I start partitioning, eg, "and set up LVM", I can't delete the > > partitions again. > > The installer allows to delete logical volumes, volume groups and > unencrypted partitions formerly used as physical volumes, but not encrypted > volumes nor their underlying partitions. Yes. This is a poor experience.
Bug#1064791: No ethernet card in a laptop
Package: debian-installer On my new laptop, d-i prints "No Ethernet card was detected. If you know the name of the driver (etc)". This confused me, as I thought it _also_ couldn't find the wifi driver (since it's a new laptop, it's possible the d-i kernel doesn't know about the wifi device). I suggest that if d-i can find a wifi device, it skips the step where it gives me a long inscrutable list of module names and asks me to choose one to make the network work.
Bug#1064624: Hard to short-stroke an encrypted drive
Package: debian-installer The partitioner "guided partitioning" offers me: - use the largest continuous free space - use entire disk - use entire disk and set up LVM - use entire disk and set up encrypted LVM I want "use largest contiguous space and set up encrypted LVM". That would let me reserve 200GB of my SSD as unencrypted free space, which will improve the write endurance of my SSD. Also once I start partitioning, eg, "and set up LVM", I can't delete the partitions again. Well, I can, but I have to switch to a terminal, run dmsetup remove_all. Which sometimes confuses the partitioner and it gets stuck printing "??? ???" If that happens, I can neither "go back", nor "continue".
Bug#1064617: Passwords should not be changed frequently
Package: debian-installer I just did an installation with the 2024-02-24 debian-testing-amd64-netinst.iso image. I forget the exact wording used, but when setting up a user, d-i printed advice that user passwords should be changed frequently. This is no longer current good advice (since 2017): "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator." https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf I happen to like their suggestion of providing a password-strength meter, but that would be a separate bug. This bug is simply a request to remove this outdated suggestion text from d-i.
Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
Hi, On 12/01/2024 12:31, Helmut Grohne wrote: For the gzip case, we have the additional question whether we tolerate the temporary policy violation for the trixie upgrade or halt the /usr-move and retry with a modified dpkg (that could land in trixie, so we could complete in forky). What's the scope of dpkg modification needed here? And is likely the sort of thing the dpkg maintainers would accept. Were we not already in a bit of a mire here, it's not clear to me that policy is wrong here (and thus that we should set it aside). I also note that there may be unknowns beneath. In May last year, things looked good, then we found empty directory loss and m-a:same shared file loss. Then things looked good again until October when we found this. Chances are, there are more unknowns. This continues to make me worry we are not on the path of robust engineering. But I appreciate I'm in a very small minority in that regard. Regards, Matthew
Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
On 17/01/2024 14:07, Helmut Grohne wrote: I somehow missed how Ben's libnfsidmap bug #1058937 works slightly simpler. Given that $second has a conflict with the installed version of $first, one can skip that second step and instead install $second directly with dpkg -i. So no, this weird selections stuff is not technically necessary. To check I have understood correctly: one may see loss of files when doing dpkg -i of a package where it Conflicts: with an installed package? If that's so, then I think it increases my unhappyness about this situation. I can understand "do upgrades with apt, that's the tooling for the job", and we had already talked about adding something to release notes to describe what manual actions that one might take during an upgrade were dangerous, but "dpkg -i foo.deb where foo.deb Conflicts with something you have installed" seems like the sort of thing one really might reasonably do during an upgrade that has got stuck for some reason or other. Regards, Matthew
Bug#1063778: prayer: Sometimes bombs out "No HTTP or HTTPS ports active"
Package: prayer
Version: 1.3.5-dfsg1-8
Severity: normal
Hi,
Occasionally (December 14 2023, and February 12 2024) I have found that
prayer has stopped working (fixed by a restart), and I find in the
paniclog entries like:
Dec 14 03:03:18 [20888] No HTTP or HTTPS ports active
Feb 12 03:03:17 [529] No HTTP or HTTPS ports active
(note a very similar timestamp)
I suspect this relates to a restart run by cron when the underlying TLS
certificate has changed? But the configuration file does have specified
ports, and it's not that there's a problem reading the TLS key/cert (as
that produces more useful errors in the log).
Regards,
Matthew
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages prayer depends on:
ii adduser3.134
ii exim4-daemon-heavy [mail-transport-agent] 4.96-15+deb12u4
ii init-system-helpers1.65.2
ii libc-client2007e 8:2007f~dfsg-7+b2
ii libc6 2.36-9+deb12u4
ii libdb5.3 5.3.28+dfsg2-1
ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1
ii libssl1.1 1.1.1n-0+deb11u3
ii libtidy5deb1 2:5.6.0-11
ii logrotate 3.21.0-1
ii lsb-base 11.6
ii ssl-cert 1.1.2
ii sysvinit-utils [lsb-base] 3.06-4
ii zlib1g 1:1.2.13.dfsg-1
prayer recommends no packages.
Versions of packages prayer suggests:
ii aspell 0.60.8-4+b1
ii dovecot-imapd [imap-server] 1:2.3.19.1+dfsg1-2.1
ii ispell 3.4.05-1
pn prayer-accountd
pn prayer-templates-src
-- Configuration Files:
/etc/prayer/prayer.cf changed:
prefix = "/usr/share/prayer"
var_prefix = "/var/run/prayer"
prayer_user = "prayer"
prayer_group = "nogroup"
prayer_background = TRUE
file_perms= 0640
directory_perms = 0750
imapd_user_map = ""
imapd_server= localhost/notls
prefs_folder_name = ".prayer"
accountd_user_map = ""
accountd_timeout= 2m
sieved_timeout = 9m
sieve_maxsize = 32k
use_https_port 443
fatal_dump_core = FALSE
log_debug = TRUE
fix_client_ipaddr = FALSE
limit_vm = 150m
recips_max_msg = 250
recips_max_session = 1000
sending_allow_dir = "${var_prefix}/sending/allow"
sending_block_dir = "${var_prefix}/sending/block"
http_max_method_size = 32k
http_max_hdr_size= 64k
http_max_body_size = 15m
http_min_servers = 32
http_max_servers = 256
http_max_connections = 20
http_cookie_use_port = FALSE
http_timeout_idle= 10s
http_timeout_icons = 60s
http_timeout_session = 5m
icon_expire_timeout = 7d
ssl_cert_file=
"/var/lib/dehydrated/certs/aragorn.weathertop.principate.org.uk/fullchain.pem"
ssl_privatekey_file =
"/var/lib/dehydrated/certs/aragorn.weathertop.principate.org.uk/privkey.pem"
ssl_rsakey_lifespan = 15m
ssl_rsakey_freshen = 15m
session_idle_time = 10m
session_timeout = 30m
session_timeout_compose = 2h
stream_checkpoint = T
stream_ping_interval= 20m
stream_misc_timeout = 15m
log_ping_interval = 10m
db_ping_interval = 30m
login_template = "login"
login_banner= "Prayer Webmail Service"
login_service_name = "Prayer"
list_addr_maxlen= 30
list_subject_maxlen = 30
change_max_folders = 20
use_ispell_language british "British English"
use_ispell_language american "American English"
draft_att_single_max = 10M
draft_att_total_max = 10M
fix_from_address = FALSE
spam_purge_name = "spam_purge"
spam_purge_prefix = "# Spam Purge Timeout:"
spam_purge_timeout = 60
sendmail_path = /usr/lib/sendmail
ispell_path = /usr/bin/ispell
ssl_encouraged = FALSE
ssl_redirect= FALSE
ssl_required= FALSE
icon_dir= "$prefix/icons"
static_dir = "$prefix/static"
bin_dir = "/usr/sbin"
log_dir = "/var/log/prayer"
lock_dir= "$var_prefix"
socket_dir = "$var_prefix/sockets"
socket_split_dir= FALSE
init_socket_name= init
ssl_session_dir = "$var_prefix/ssl_scache"
tmp_dir = "$var_prefix/tmp"
p
Bug#1056793: False positive bug?
Hi, I looked at the build log, and the problems look to be disk related? /usr/bin/ld: final link failed: No space left on device collect2: error: ld returned 1 exit status (there follow further ENOSPC and also some No such file or directory errors, which presumably relate to things not written because of running out of space). ...so maybe the answer is not to go to cython-legacy, but to try a build somewhere with more disk? Regards, Matthew
Bug#1061731: load config: Key file does not have group “redfish”
Hello, As a workaround, purging and then reinstalling fwupd and dependencies fixed the problem on my machine. Regards, Matthew -- ** email: wimac...@gmail.com **
Bug#1059712: orphan-sysvinit-scripts: dnscrypt-proxy init script not working out of the box
Hi, On 30/12/2023 18:09, Matthias Geiger wrote: On Sat, 30 Dec 2023 18:52:52 +0100 Matthias Geiger wrote: > Package: orphan-sysvinit-scripts > Version: 0.15 > Severity: important > > Dear Maintainer, > > I installed dnscrypt-proxy alongside orphan-sysvinit-scripts. The > service does not start however. The script included in o-s-s passes > the -daemonize flag in line 44. This flag does not exist however on the > sid version of dnscrypt-proxy, thus rendering the script broken. > The systemd unit just calls this: "/usr/sbin/dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml". > > Trying to reproduce that by amending the init script [see attachment] > tries to start the service but fails because listen_addresses is empty. > This is as far as I got trying to get the service to run. attached script seems to work under openRC (copied from alpine and modified). Thanks - do you have copyright details for this script (which we would need to use it), and know which version of dnscrypt-proxy needs the change (since we'll need a versioned conflict or similar...) Regards, Matthew
Bug#1059249: designer-qt6: Segmentation fault in /usr/lib/qt6/bin/designer at launch
Package: designer-qt6 Version: 6.6.1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: mlukow...@sdf.org Hey, Designer segfaults on launch; seems the bug might be with qt6 xcb integration. Valgrind reports the following output: matt@pancakehut:~$ valgrind /usr/lib/qt6/bin/designer ==947004== Memcheck, a memory error detector ==947004== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==947004== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==947004== Command: /usr/lib/qt6/bin/designer ==947004== ==947004== Syscall param writev(vector[0]) points to uninitialised byte(s) ==947004==at 0x6A911BD: __writev (writev.c:26) ==947004==by 0x6A911BD: writev (writev.c:24) ==947004==by 0x7D46FBF: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D47800: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D48E24: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D48EA0: xcb_wait_for_reply (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0xA933D83: QXcbConnection::initializeScreensFromMonitor(xcb_screen_iterator_t*, int, QXcbScreen**, bool) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA934927: QXcbConnection::initializeScreens(bool) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA925F42: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA950B15: QXcbIntegration::QXcbIntegration(QList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0x486546F: ??? (in /usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so) ==947004==by 0x5C06F97: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C08887: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004== Address 0xa2699c5 is 4,533 bytes inside a block of size 21,176 alloc'd ==947004==at 0x48459F3: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==947004==by 0x7D46990: xcb_connect_to_fd (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D4B191: xcb_connect_to_display_with_auth_info (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x6E8BD09: _XConnectXCB (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==947004==by 0x6E7C0C6: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==947004==by 0xA92EB71: QXcbBasicConnection::QXcbBasicConnection(char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA925CF4: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA950B15: QXcbIntegration::QXcbIntegration(QList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0x486546F: ??? (in /usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so) ==947004==by 0x5C06F97: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C08887: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x6332545: QCoreApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.6.1) ==947004== ==947004== Invalid read of size 8 ==947004==at 0x637970A: ??? (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.6.1) ==947004==by 0x5C0D9E5: QGuiApplication::screenAdded(QScreen*) (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C66DB8: QWindowSystemInterface::handleScreenAdded(QPlatformScreen*, bool) (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0xA934A6F: QXcbConnection::initializeScreens(bool) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA925F42: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA950B15: QXcbIntegration::QXcbIntegration(QList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0x486546F: ??? (in /usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so) ==947004==by 0x5C06F97: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C08887: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x6332545: QCoreApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.6.1) ==947004==by 0x5C0890F: QGuiApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x54BCDDC:
Bug#1058937: /usr-move: Do we support upgrades without apt?
Hi, On 21/12/2023 09:41, Helmut Grohne wrote: Is it ok to call upgrade scenarios failures that cannot be reproduced using apt unsupported until we no longer deal with aliasing? I incline towards "no"; if an upgrade has failed part-way (as does happen), people may then reasonably use dpkg directly to try and un-wedge the upgrade (e.g. to try and configure some part-installed packages, or try installing some already-downloaded packages). It may be that the mitigations necessary are worse than the risk, but I think the behaviour as described in #1058937 is definitely buggy. Regards, Matthew
Bug#1057879: RFS: rumur/2023.11.27-1 -- model checker for the Murphi language
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rumur": * Package name : rumur Version : 2023.11.27-1 Upstream contact : Matthew Fernandez * URL : https://github.com/Smattr/rumur * License : Unlicense * Vcs : https://github.com/Smattr/rumur.git Section : devel The source builds the following binary packages: rumur - model checker for the Murphi language To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rumur/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2023.11.27-1.dsc Changes since the last upload: rumur (2023.11.27-1) unstable; urgency=medium . * New upstream release. Regards, Matt
Bug#1057744: nmap: bring back zenmap
Package: nmap Version: 7.93+dfsg1-1 Severity: wishlist Some time ago, zenmap was removed due to being stuck back on python 2, but as of nmap 0.94 [1] it has been brought up to date to use python 3 and gobject, so hopefully it can now be brought back to Debian? [1] https://github.com/nmap/nmap/blob/e47b742669e6aadcab8aaa16d123d8fa4832fe5d/CHANGELOG#L13
Bug#1057279: xtrlock option to verify password via a subprocess
Hi, On 02/12/2023 15:23, Simon Tatham wrote: I run xtrlock on a machine which doesn't store all its passwd/shadow entries locally. So xtrlock is unable to verify my password by the usual method. To get around this, I added a feature which replaces the passwd/shadow based check with a user-provided subprogram. xtrlock pipes the password into the subprogram's standard input, and unlocks the screen if the program exits with a success status. Thanks for this and the attached patches; I think it's a useful addition to xtrlock. Both patches are attached. At the moment, they lack documentation, and also the hourglass-pointer patch is unconditional rather than configurable. I'm prepared to do extra polishing effort if it's useful! I think both docs and making the hourglass optional would be good, please; I'm sorry I've not done anything more useful in terms of review yet, but I'm currently a bit swamped, and I thought at least some reply would be better than continued silence! Regards, Matthew
Bug#1055632: bind9: needs restarting daily to resolve www.dumbingofage.com
Package: bind9
Version: 1:9.18.19-1~deb12u1
Severity: normal
Hi,
This is a weird one, but it's been happening daily for a few days now,
so I figured it was worth reporting.
For the last few days, if I try and visit
https://www.dumbingofage.com/
Firefox can't resolve the hostname, similarly on the CLI:
matthew@aragorn:~$ host www.dumbingofage.com
Host www.dumbingofage.com not found: 2(SERVFAIL)
AFAICT the NSs work - I can do both
dig @23.226.68.75 www.dumbingofage.com
and
dig @23.226.68.76 www.dumbingofage.com
And get a sensible answer back.
If I restart bind9 then I am able to resolve the hostname fine, only for
the same problem to recur the following day.
So _something_ is getting confused, and I'm pretty sure it's bind :)
Regards,
Matthew
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages bind9 depends on:
ii adduser3.134
ii bind9-libs 1:9.18.19-1~deb12u1
ii bind9-utils1:9.18.19-1~deb12u1
ii debconf [debconf-2.0] 1.5.82
ii dns-root-data 2023010101
ii init-system-helpers1.65.2
ii iproute2 6.1.0-3
ii libc6 2.36-9+deb12u3
ii libcap21:2.66-4
ii libelogind0 [libsystemd0] 246.10-1debian1
ii libfstrm0 0.6.1-1
ii libjson-c5 0.16-2
ii liblmdb0 0.9.24-1
ii libmaxminddb0 1.7.1-1
ii libnghttp2-14 1.52.0-1
ii libprotobuf-c1 1.4.1-1+b1
ii libssl33.0.11-1~deb12u2
ii libuv1 1.44.2-1
ii libxml22.9.14+dfsg-1.3~deb12u1
ii lsb-base 11.6
ii netbase6.4
ii sysvinit-utils [lsb-base] 3.06-4
ii zlib1g 1:1.2.13.dfsg-1
bind9 recommends no packages.
Versions of packages bind9 suggests:
pn bind-doc
ii bind9-dnsutils [dnsutils] 1:9.18.19-1~deb12u1
ii dnsutils 1:9.18.19-1~deb12u1
pn resolvconf
pn ufw
-- Configuration Files:
/etc/bind/db.127 changed:
;
; BIND reverse data file for local loopback interface
;
$TTL604800
@ IN SOA ns.empire.pick.ucam.org. hostmaster.pick.ucam.org. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
/etc/bind/named.conf changed:
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind/README.Debian for information on the
// structure of BIND configuration files in Debian for BIND versions 8.2.1
// and later, *BEFORE* you customize this configuration file.
//
options {
directory "/var/cache/bind";
check-names master warn;
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
//can't use this, since it would break the reverse zones we secondary
//forwarders {
//212.23.8.1; 212.23.8.6;
//};
};
// reduce log verbosity on issues outside our control
logging {
category lame-servers { null; };
// category cname { null; };
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// add entries for other zones below
Bug#1055507: apt: needs a say to specify 'use this suite only for versioned dependencies'
Package: apt Version: 2.6.1 Severity: important Hi, When installing the dependencies of a package, it should be possible to have apt use an otherwise lower-priority suite only if necessary to satisfy a versioned dependency. In the abstract: consider two suites A and B, where every package in suite A is version x and every package in suite B is version y (y>x). If a package p Depends: foo(>x), bar then there should be a way for apt to be told to install p such that it will install foo from suite B (because of the versioned dependency) but bar from suite A. To use a more concrete example (which serves as a reproducer), I generate a stub package with mk-build-deps: matthew@aragorn:~/junk/aptbug$ cat debian/control Source: mcv21-demo Build-Depends: acr (>2), ckermit matthew@aragorn:~/junk/aptbug$ mk-build-deps debian/control ... dpkg-deb: building package 'mcv21-demo-build-deps' in '../mcv21-demo-build-deps_1.0_all.deb'. ... matthew@aragorn:~/junk/aptbug$ dpkg --info mcv21-demo-build-deps_1.0_all.deb | grep Depends Depends: build-essential:amd64, acr (>= 2), ckermit acr in bookworm is version 1.9.4. If I set the priority of bookworm-backports to any value less than 500, then try and install mcv21-demo-build-deps it fails: matthew@aragorn:~/junk/aptbug$ apt --dry-run install ./mcv21-demo-build-deps_1.0_all.deb ... The following packages have unmet dependencies: mcv21-demo-build-deps : Depends: acr (>= 2) but 1.9.4-1 is to be installed E: Unable to correct problems, you have held broken packages. If I set the priority of bookworm-backports to >=500 (either by adjusting the Pin-Priority or using -t) then apt instead tries to install both acr and ckermit from bookworm-backports: matthew@aragorn:~/junk/aptbug$ apt --dry-run install ./mcv21-demo-build-deps_1.0_all.deb ... The following additional packages will be installed: acr ckermit The following NEW packages will be installed: acr ckermit mcv21-demo-build-deps 0 upgraded, 3 newly installed, 0 to remove and 143 not upgraded. Inst acr (2.1.2-1~bpo12+1 Debian Backports:stable-backports [all]) Inst ckermit (405~beta10-2~bpo12+1 Debian Backports:stable-backports [amd64]) Inst mcv21-demo-build-deps (1.0 local-deb [all]) Conf acr (2.1.2-1~bpo12+1 Debian Backports:stable-backports [all]) Conf ckermit (405~beta10-2~bpo12+1 Debian Backports:stable-backports [amd64]) Conf mcv21-demo-build-deps (1.0 local-deb [all]) WLOG, what I want is a way to arrange that apt when installing mcv21-demo-build-deps will pick acr from stable-backports (because it is necessary to satisfy the versioned dependency) but ckermit from stable. This is important because when e.g. building packages for deployment from CI or similar, sometimes one needs some packages from the relevant -backports suite, but you only want to use those backports that are necessary to satisfy versioned constraints i.e. use the minimal necessary set of backported packages. AFAICT there is no priority mechanism and/or CLI switch that gets this behaviour - you either get no backports at all (if backports priority < 500) or all your dependencies are pulled from backports (because at equal priority they have higher versions). Thanks, Matthew -- 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-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "tasks"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Update ""; APT::Update::Post-Invoke ""; APT::Update::Post-Invoke:: "touch /var/lib/apt/periodic/update-success-stamp 2>/dev/null || true"; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "[ ! -f /var/run/dbus/system_bus_socket ] || /usr/bin/dbus
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Hi, On 07/11/2023 01:14, Patrik Schindler wrote: Am 07.11.2023 um 01:59 schrieb Thorsten Glaser : I have sysvinit-core installed and orphan-sysvinit-scripts was not pulled in automatically. Yeah, it’s not. As I'm learning from a discussion in bug #1055466, this is due to orphan-sysvinit-scripts "only" being recommended and not a hard dependency. Yes, it's a Recommends: which means it'll be pulled in on most upgrades (I agree it would have been better to have got something into the release notes; I don't know if they are still taking updates for the bookworm release notes, but do feel free to propose some text for them). If you find future init scripts missing that aren't in orphan-sysvinit-scripts and the relevant package maintainer isn't willing to restore them, do file a bug report (ideally with the requested details from the README - https://salsa.debian.org/matthew/orphan-sysvinit-scripts/ ) against o-s-s and we can get them into trixie. I had thought we'd caught nearly all of the scripts from bookworm, but if there are missing ones there we could try and get a fix into the next point release. [are we at the point where this bug report can be closed? I feel like there might be a bug report with patch if you want the release notes updating, and/or bugs for particular missing init scripts] Regards, Matthew
Bug#1039859: mixxx: Mixxx GUI is broken / elements not rendered
Hi everyone, This is a wayland related bug, and a known issue upstream: https://bugs.launchpad.net/mixxx/+bug/1850729 https://github.com/mixxxdj/mixxx/issues/9787 It seems the waveform code is incompatible with the QtWayland platform plugin change, which is mentioned on their troubleshooting page: https://github.com/mixxxdj/mixxx/wiki/Troubleshooting#mixxx-on-wayland A workaround is to launch mixxx with $ mixxx -platform xcb Which uses the x11 platform plugin. Upstream actually have -platform xcb set in their desktop file by default, and if you look at debian/patches/0002-desktop_file.patch: diff --git a/res/linux/org.mixxx.Mixxx.desktop b/res/linux/org.mixxx.Mixxx.desktop index bf90e33..35f4b68 100644 --- a/res/linux/org.mixxx.Mixxx.desktop +++ b/res/linux/org.mixxx.Mixxx.desktop @@ -8,7 +8,8 @@ GenericName[fr]=Interface numérique pour DJ Comment=A digital DJ interface Comment[de]=Ein digitales DJ-System Comment[fr]=Une interface numérique pour DJ -Exec=sh -c "pasuspender -- mixxx -platform xcb || mixxx -platform xcb" +Exec=mixxx +Keywords=dj;music;alsa;jack:realtime;standalone; Terminal=false Icon=mixxx Type=Application The exec line gets changed to remove the pasuspender call and platform plugin changes. I understand removing pasuspender, but maybe we should restore -platform xcb. Gnome-Shell is wayland by default, and I think other desktops are moving the same way, so maybe we should force the x11 backend by default to have a working application while upstream decides how to rebuild their interface for wayland to fix the issue. Thanks, Matthew
Bug#1054629: conmon: Healthcheck containers write error to system journal
Package: conmon Version: 2.1.6+ds1-1 Severity: normal X-Debbugs-Cc: m...@matthoran.com Dear Maintainer, When running a Podman container which leverages a healthcheck (e.g. docker.io/jacobalberty/unifi) via systemd service, conmon will write an error to the system journal when the check completes. See upstream issue https://github.com/containers/conmon/issues/438. I built my own conmon 2.1.8 package which includes the fix here: https://github.com/containers/conmon/commit/77ce3127c3956d65f9400621d7e2d89fcde7f2e1 and the errors went away. In the process of creating this package I also noticed that https://salsa.debian.org/podman-team/conmon looks to be out of date, in that it's missing the last release (2.1.6). Thanks, Matt -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages conmon depends on: ii libc6 2.36-9+deb12u3 ii libglib2.0-0 2.74.6-2 ii libsystemd0 252.17-1~deb12u1 conmon recommends no packages. conmon suggests no packages. -- no debconf information
Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package
Hi, On 22/09/2023 14:50, Jonathan Kamens wrote: The current version of the Selenium bindings for all supported programming languages relies on a Rust executable called Selenium Manager for managing the webdriver executables required for the various browsers that the bindings interact with. Selenium upstream has one git repository - https://github.com/SeleniumHQ/selenium which contains bindings for python (packaged in Debian as python3-selenium), ruby (packaged in Debian as ruby-selenium-webdriver), and C#/Java/Javascript (not AFAICT packaged in Debian) as well as the Selenium Manager, which is a rust CLI tool. I agree that having the Manager available in Debian would enhance the experience of python and ruby Selenium users. From the upstream changelog, it seems that version 4.11 is where searching for drivers is done via the Manager: * Use Selenium Manager to locate drivers on PATH [ https://github.com/SeleniumHQ/selenium/pull/12356 ] ...and the Ruby bindings have a similar entry. But the latest version of ruby-selenium-webdriver in Debian is 4.4, so that issue hasn't bitten yet. I'm afraid your analysis of how selenium manager might be made available in Debian is incorrect, however. It would need to be built like any other Rust program - with a source package and so on (Debian packages cannot download things from the internet during their build process); and the various rust dependencies would also need packaging if they're not already available in Debian. This is quite a lot of work, and I can quite see that the (presumably) python specialists who have packaged python3-selenium would not feel able to take on that Rust work. An alternative approach might be to patch python3-selenium to search PATH for drivers (as I think it did before that functionality was moved to the manager) - I'd be interested to hear if the maintainer would consider a patch do so if someone wrote one? I see that python3-selenium now has a NEWS.Debian entry that points to README.Debian, which seems like a reasonable way to bring this to users' attention. Regards, Matthew
Bug#1051471: btrfsd: cron job for calling btrfsd
Hi, Just a note on the libsystemd dependency. On 10/09/2023 10:21, Martin Steigerwald wrote: Sure, that should actually be extremely low-maintenance, there isn't any hard dependency the daemon has on systemd - with one exception: It uses libsystemd to write to the journal if that's available, and I would like to keep that feature. It will however already fall back to syslog in case sd-journal isn't available, and libsystemd is inert on systems without systemd. On Debian systems, libelogind0 Provides: libsystemd0, so a libsystemd0 dependency (which, as you say, util-linux has) isn't a problem. Regards, Matthew
Bug#1050819: pcre2: Please enable JIT on riscv64
Hi, On 29/08/2023 18:01, Aurelien Jarno wrote: PCRE2 gained support for JIT on riscv64 in version 10.41 and it is recommended to enable it [1]. Could you please do that for the next upload? I have tested the following patch without issue: Sure; I'm building an updated package now. I didn't quite take your patch, as I noticed the JIT arch list wasn't sorted, so I tidied that up too :) Regards, Matthew
Bug#1050001: Unwinding directory aliasing [and 3 more messages]
Dear Luca, On 27/08/2023 03:16, Luca Boccassi wrote: [things] You've already been asked by a couple of people to moderate your tone in this thread. I appreciate there is a lot of frustration around /usr-merge, but your contributions are not helping with that at all. Nor do they help us have a constructive discussion. The DEP-17 work continues whilst this discussion is ongoing; this discussion is not delaying that work. I think it is fair to say that when ctte decided on /usr-merge it was expected that a) the process would be reasonably straightforward and b) dpkg could be taught to understand directory aliasing, so we would not have to be doing things "behind dpkg's back", as it were. I think the need for a releases-long moratorium on moving files and the volume and depth of technical work represented by DEP17 demonstrate that those expectations turned out not to be met. Given that, it seems to me that a) warnings that "it's not that simple & easy" were not FUD and describing them thus is unhelpful b) it's reasonable to at least ask the question "given what we know now, are we still sure this is the correct approach?" Any such consideration must be mindful of the fact that the majority of Debian installs are now /usr-merged, which means that the complexity of unwinding such installs has to be a heavy factor in thinking about alternative approaches. I'm hopeful, but not certain, that the DEP17 work will get us to a coherent state again by foxy (which still feels a long time off); I don't think we should underestimate the work to be done in properly completing /usr-merge. This discussion has, I think, been broadly useful in clarifying some folks' thinking in this area. I would very much like if we could keep it focused on the technical matters. Regards, Matthew
Bug#1050001: Unwinding directory aliasing
On Fri, Aug 25, 2023 at 06:50:54AM +0200, Ansgar wrote: > If someone wants to go this way, I suggest to just have a GR about it > instead of iterating this at tech-ctte yet again. It's not very > motivating to have some people endlessly argue against moving forward > and wanting to revisit/reverse/change some decisions endlessly. Ian is a sufficient subject matter expert that I think his concerns are worth analysing. I lean towards disagreeing with his conclusion (I agree that aspects of usrmerge may uncover or result in subtle bugs, but suspect that having Debian diverge from the approach that most other distributions have taken would probably result in a larger number), but I feel it's legitimate to bring this up with the committee. At the moment I think the general feeling seems to be that the concerns aren't sufficient to change the approach we're taking, but when presented with new information it makes sense to take that into account. Please don't interpret this as an attempt to prevent us from moving forward - please think of this as additional verification that we *are* moving forward.
Bug#1043420: orphan-sysvinit-scripts: triggers will be broken by /usr-merge
control: tags -patch quit Hi, On 10/08/2023 17:49, Helmut Grohne wrote: at https://subdivi.de/~helmut/dep17.html). Even though we are still in the process of selecting mitigations, the mitigation for this already is pretty clear: Duplicating triggers (M12). I'm attaching a patch for your convenience. Thanks for the bug report. Maintaining this duplication may be annoying due to the number of interests. If you prefer, we can try generating the trigger file at build to enforce the duplication rule. Let me know if you want me to do that. I'm afraid I really don't want to be making the process of adding scripts to o-s-s any more fiddly (and thus annoying and error-prone) than it already is, so I don't think an approach that relies on every single trigger having to be duplicated by hand is sustainable. Regards, Matthew
Bug#1050179: dgit: unable to clone -security suites (?since bullseye)
Hi,
The commit message in my previous patch was confused (author error, I
have to work hard to remember the order buster-bullseye-bookworm).
Here's a revised version with a correct commit message, the code is the
same.
Regards,
MatthewFrom aab5bd302ff9de69b5e8585ac4051df42049f957 Mon Sep 17 00:00:00 2001
From: Matthew Vernon
Date: Mon, 21 Aug 2023 16:10:11 +0100
Subject: [PATCH] Use the old /updates security map for buster (Closes:
#1050179)
The suite-map and suite-rmap for debian-security are necessary for the
pre-bullseye layout of the security.debian.org archive.
Since bullseye (i.e. after buster), the archive layout has changed,
and these mappings are no longer necessary (indeed, they cause dgit
clone to fail to work with bullseye and later security suites).
Buster is the oldest suite still available on security.debian.org, so
this is the only suite we still need the mapping for.
Signed-off-by: Matthew Vernon
---
dgit | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dgit b/dgit
index 30d76299..1b02f8de 100755
--- a/dgit
+++ b/dgit
@@ -794,8 +794,8 @@ our %defcfg = ('dgit.default.distro' => 'debian',
'dgit-distro.debian.mirror' => 'http://ftp.debian.org/debian/',
'dgit-distro.debian-security.archive-query' => 'aptget:',
'dgit-distro.debian-security.mirror' => 'http://security.debian.org/debian-security/',
- 'dgit-distro.debian-security.aptget-suite-map' => 's#-security$#/updates#',
- 'dgit-distro.debian-security.aptget-suite-rmap' => 's#$#-security#',
+ 'dgit-distro.debian-security.aptget-suite-map' => 's#buster-security$#buster/updates#',
+ 'dgit-distro.debian-security.aptget-suite-rmap' => 's#buster$#buster-security#',
'dgit-distro.debian-security.nominal-distro' => 'debian',
'dgit-distro.debian.backports-quirk' => '(squeeze)-backports*',
'dgit-distro.debian-backports.mirror' => 'http://backports.debian.org/debian-backports/',
--
2.39.2
Bug#1050179: dgit: unable to clone -security suites (?since bullseye)
control: tags 1050179 +patch
quit
On 21/08/2023 15:21, Ian Jackson wrote:
Thanks for the report and the investigation!
Matthew Vernon writes ("Bug#1050179: dgit: unable to clone -security suites (?since
bullseye)"):
The difficulty is that there is AFAICT no version-knowledge in these
map/rmap entries - one would prefer to apply the map for suites <
bullseye and not for >=bullseye
The usual approach is to list *all* old codenames (at least, any that
still have any existence anywhere) and assume that unknown codenames
are newer.
There is in fact only one suite where this is still germane, since
pre-buster suites are no longer available on security.debian.org at all.
Given which, the attached patch works for me (with it I can clone bind9
for stable,-security oldstable,-security and oldoldstable,-security
without needing any -c arguments).
HTH,
Matthew
From 2278aa8b77365599b7f48301502777cfae2bfe3a Mon Sep 17 00:00:00 2001
From: Matthew Vernon
Date: Mon, 21 Aug 2023 16:10:11 +0100
Subject: [PATCH] Use the old /updates security map for buster (Closes:
#1050179)
The suite-map and suite-rmap for debian-security are necessary for the
pre-bullseye layout of the security.debian.org archive.
Since bookworm, the archive layout has changed, and these mappings are
no longer necessary (indeed, they cause dgit clone to fail to work
with bookworm and later security suites).
Buster is the oldest suite still available on security.debian.org, so
this is the only suite we still need the mapping for.
Signed-off-by: Matthew Vernon
---
dgit | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dgit b/dgit
index 30d76299..1b02f8de 100755
--- a/dgit
+++ b/dgit
@@ -794,8 +794,8 @@ our %defcfg = ('dgit.default.distro' => 'debian',
'dgit-distro.debian.mirror' => 'http://ftp.debian.org/debian/',
'dgit-distro.debian-security.archive-query' => 'aptget:',
'dgit-distro.debian-security.mirror' => 'http://security.debian.org/debian-security/',
- 'dgit-distro.debian-security.aptget-suite-map' => 's#-security$#/updates#',
- 'dgit-distro.debian-security.aptget-suite-rmap' => 's#$#-security#',
+ 'dgit-distro.debian-security.aptget-suite-map' => 's#buster-security$#buster/updates#',
+ 'dgit-distro.debian-security.aptget-suite-rmap' => 's#buster$#buster-security#',
'dgit-distro.debian-security.nominal-distro' => 'debian',
'dgit-distro.debian.backports-quirk' => '(squeeze)-backports*',
'dgit-distro.debian-backports.mirror' => 'http://backports.debian.org/debian-backports/',
--
2.39.2
Bug#1050179: dgit: unable to clone -security suites (?since bullseye)
Package: dgit Version: 10.7 Severity: important Hi, It's suggested (in e.g. dgit-user(7)) to clone a combined ,-security suite. But this does not work (transcript 0 below), with an error about missing Release file: E: The repository 'http://security.debian.org/debian-security bookworm/updates Release' does not have a Release file. I think this is because the suit map/rmap for debian-security are wrong: dgit: 'dgit-distro.debian-security.aptget-suite-map' => 's#-security$#/updates#', dgit: 'dgit-distro.debian-security.aptget-suite-rmap' => 's#$#-security#', Debian changed its security suite names starting with bullseye from /updates to -security: https://lists.debian.org/debian-devel-announce/2019/07/msg4.html If I disable both mappings I can then clone pcre2 stable,-security with a warning that pcre2 can't be found in the (security) archive which I think is correct. That was done thus: dgit -cdgit-distro.debian-security.aptget-suite-map='' -cdgit-distro.debian-security.aptget-suite-rmap='' clone pcre2 stable,-security Transcript 1 below contains the full output of that command. By way of checking that this works where there has been a security update, I cloned bind9 stable,-security and checked that left me at 1:9.18.16-1~deb12u1 (the security release) - see Transcript 2. Likewise, dgit merge/pull work with the map & rmap unset. The difficulty is that there is AFAICT no version-knowledge in these map/rmap entries - one would prefer to apply the map for suites < bullseye and not for >=bullseye IMO, this would be worth a backport to at least stable when fixed - it's a bit sad that this functionality is broken since it's quite useful for end-users of dgit and helps make sure they get security updates. Thanks, Matthew *** BEGIN TRANSCRIPT 0 *** matthew@aragorn:~/junk$ dgit clone pcre2 stable,-security fetching stable... canonical suite name for stable is bookworm fetching existing git history last upload to archive: specified git info (debian) % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 2341k 100 2341k0 0 2322k 0 0:00:01 0:00:01 --:--:-- 2324k HEAD is now at be53c99 Changelog for 10.42-1 dgit [stable] ok: ready for work in pcre2 fetching bookworm-security... Ign:1 http://security.debian.org/debian-security bookworm/updates InRelease Err:2 http://security.debian.org/debian-security bookworm/updates Release 404 Not Found [IP: 2a04:4e42:82::644 80] Reading package lists... Done E: The repository 'http://security.debian.org/debian-security bookworm/updates Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. dgit [bookworm-security]: failed command: apt-get -c '/home/matthew/.cache/dgit/aptget/apt.conf#debian' update dgit [bookworm-security]: error: subprocess failed with error exit status 100 dgit: error: failed to obtain bookworm-security: failed with error exit status 255 *** END TRANSCRIPT 0 *** *** BEGIN TRANSCRIPT 1 *** matthew@aragorn:~/junk$ dgit -cdgit-distro.debian-security.aptget-suite-map='' -cdgit-distro.debian-security.aptget-suite-rmap='' clone pcre2 stable,-security fetching stable... canonical suite name for stable is bookworm fetching existing git history last upload to archive: specified git info (debian) % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 2341k 100 2341k0 0 2322k 0 0:00:01 0:00:01 --:--:-- 2324k HEAD is now at be53c99 Changelog for 10.42-1 dgit [stable] ok: ready for work in pcre2 fetching bookworm-security... Hit:1 http://security.debian.org/debian-security bookworm-security InRelease Reading package lists... Done canonical suite name is bookworm-security W: Unable to locate package pcre2 no version available from the archive dgit [bookworm-security]: source package pcre2 does not exist in suite bookworm-security calculated combined tracking suite bookworm,-security HEAD is now at be53c99 Changelog for 10.42-1 dgit ok: ready for work in pcre2 *** END TRANSCRIPT 1 *** *** BEGIN TRANSCRIPT 2 *** matthew@aragorn:~/junk$ dgit -cdgit-distro.debian-security.aptget-suite-map='' -cdgit-distro.debian-security.aptget-suite-rmap='' clone bind9 stable,-security fetching stable... canonical suite name for stable is bookworm starting new git history last upload to archive: NO git hash % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 5334k 100 5334k0 0 2352k 0 0:00:02 0:00:02 --:--:-- 2352k % Total% Received % Xferd Average Speed TimeTime
Bug#1008136: lxcfs takes 2 or 3 CPU cores constantly
bookworm seems better. Issue can be closed. On 2023-08-18 16:27, Mathias Gibbens wrote: Control: tags -1 + moreinfo Tagging with moreinfo. As this was reported against the version of lxcfs in the now oldstable release, without additional information or confirmation that the problem still affects the version of lxcfs in bookworm, this bug will be closed in a few months. Mathias
Bug#1050001: Unwinding the directory aliasing mistake
On 18/08/2023 09:05, Christoph Berg wrote: Re: Ian Jackson Protecting my mental health I will try to avoid regularly reading this thread. I hope that now that I have made the suggestion, others will be able to carry the conversation. I will be configuring my mail client to disregard my personal copies of messages sent to this bug; when I want to read the thread I will look at the mailing list. Also, if you disagree with my decision to raise this now, please don't email me. If you feel I have overstepped a boundary, please contact the Community Team or DAM. I think this is just gross. Submitting a proposal and then telling CT/DAM to deal with the fallout is rude. I disagree; the TC has handled a number of issues now where at least one of the main participants has declined to participate in the discussion thread. It's obviously not ideal, but I don't think it's entirely out of order (and the TC has not considered it as such in the past). Regards, Matthew Disclaimer: I know Ian personally, but I don't think that's affecting my opinion here
Bug#1049392: golang-1.21: FTBFS if dh-golang is installed
On Tue, 15 Aug 2023, Shengjing Zhu wrote: So why would you install dh-golang? It's not listed in golang-1.21's Build-Depends. To build other packages. Building Go and building packages that use Go on the same system doesn't seem weird to me. Is your view that source packages only need to be buildable in isolated chroots/containers that have just essential and their build-deps installed? While the policy manual doesn't seem to be explicit on this, the existence of the Build-Conflicts field seems to imply that the expectation is any breakage is explicitly declared there, and would provide a reasonable solution to this IMO. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824495 has a long discussion on the merits of different possible policy stances on this. https://lists.debian.org/debian-devel/2019/02/msg00204.html continues that discussion, though some of the mesages were also CC'd to the bug. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#1049392: golang-1.21: FTBFS if dh-golang is installed
Source: golang-1.21 Version: 1.21.0-1 Severity: important Tags: ftbfs Context: trying to build local golang-1.21 packages against stable (bookworm) If dh-golang is installed, building the golang toolchain itself fails tests, specifically TestCgoLib in src/cmd/nm/nm_cgo_test.go: --- FAIL: TestCgoLib (2.19s) nm_test.go:264: go tool nm: exit status 1 open /tmp/TestGoLib2084668406/gopath/src/mylib/mylib.a: unrecognized object file After much digging and adding printf-y debugging output to the go toolchain, I eventually tracked this down to dh-golang copying CFLAGS (and related) env vars to CGO_CFLAGS (etc.). This notably includes the `-ffile-prefix-map` flag, which the go toolchain doesn't like, which causes it to put a "preferlinkext" sigil file in the `.a` file the test generates, which then makes the `go tool nm` program under test barf, because it doesn't know what that flag file is. I've reported the issue with `go tool nm` upstream: https://github.com/golang/go/issues/62036 However, I don't think `dh-golang` should be getting pulled in when building the Go toolchain itself, should it, at least not for setting CGO flags since I don't think the toolchain uses CGO, so this is only messing with tests? This also affects golang-1.20, and based on my analysis of the root cause in the upstream issue, I believe will affect golang-1.19 too, but I have not directly confirmed that. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#980900: New watch file for Graphviz package v2
It didn’t occur to me to mention before, but the Graphviz download web page is also driven programmatically from some JSON files: https://gitlab.com/graphviz/graphviz.gitlab.io/-/tree/main/data/releases?ref_type=heads. Another option may be for the watch file to refer to JSON files in this Gitlab repo. Though perhaps it is required for a watch file to refer to a source tarball, not something indirect. The Graphviz repo at https://gitlab.com/graphviz/graphviz also has Git tags for every release.
Bug#1043335: dgit-user(7) should note where dgit build is inappropriate (e.g. CI)
Package: dgit Version: 10.1 Severity: normal X-Debbugs-Cc: mver...@wikimedia.org, matt...@debian.org Hi, I want to build packages from a dgit tree in CI; I spent some time arranging for e.g. git deborig to work so that I could do: git-deborig mk-build-deps dgit -wg build And you pointed out that, in fact, I'd be better just using dpkg-buildpackage -uc -b In particular, that avoids the need to produce a source package at all, which in many cases is desirable (in a gitish workflow, they're not useful). dgit-user(7) does include runes to produce a source-package-for-sbuild (under "Using sbuild") alongside a note that this source package should not otherwise be used (and a reference to #868527). In fact, while a DD always wants to use some flavour of dgit build/sbuild/whatever (since a DD will be uploading a source or binary package), for non-DD-users who don't care about source packages but just want binaries-from-git, they don't want dgit build at all (since that will make a source package), but rather dpkg-buildpackage[0]. dgit-user(7) should note this prominently. A bonus point might be to refer to dcmd(1), since CI often has requirements about where build artifacts go (in particular, gitlab won't take artifacts from out-of-tree, so build artifacts will need moving from .., which dcmd helps with). In bookworm-and-later dpkg-buildpackage has --changes-file. [this bug report is a summary of an IRC discussion] Thanks, Matthew [0] the result of which may well be a lot of rubbish inside the git working tree, but that is already discussed in dgit-user(7) -- System Information: Debian Release: 11.7 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dgit depends on: ii apt2.2.4 ii ca-certificates20210119 ii coreutils 8.32-4+b1 ii curl 7.74.0-1.3+deb11u7 ii devscripts 2.21.3+deb11u1 ii dpkg-dev 1.20.12 ii dput 1.1.0 ii git [git-core] 1:2.30.2-1+deb11u2 ii git-buildpackage 0.9.22 ii libdpkg-perl 1.20.12 ii libjson-perl 4.03000-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-gettext-perl 1.07-4+b1 ii libtext-csv-perl 2.00-1 ii libtext-glob-perl 0.11-1 ii libtext-iconv-perl 1.7-7+b1 ii libwww-curl-perl 4.17-7+b1 ii perl [libdigest-sha-perl] 5.32.1-4+deb11u2 Versions of packages dgit recommends: ii distro-info-data 0.51+deb11u3 ii liburi-perl 5.08-1 ii openssh-client [ssh-client] 1:8.4p1-5+deb11u1 Versions of packages dgit suggests: ii cowbuilder 0.89 ii pbuilder0.231 ii sbuild 0.81.2+deb11u1 -- no debconf information
Bug#1043325: avldrums.lv2: New drum kits listed in Ardour but their soundfonts are not found
Package: avldrums.lv2 Version: 0.6.1-1 Severity: normal X-Debbugs-Cc: mcc...@gmail.com Dear Maintainer, After upgrading both avldrums.lv2 and avldrums.lv2-soundfont to version 0.6.1-1, two new drum kits "Blonde Bop" and "Blonde Bop HotRod" are offered as MIDI instruments in Ardour. Attempting to use them leads to error messages stating that their soundfonts cannot be found. Manually adding symlinks to the sf2 files alongside the existing "Black Pearl" and "Red Zeppelin" in /usr/lib/lv2/avldrums.lv2/ means that they can be used. # cd /usr/lib/lv2/avldrums.lv2/ # ln -s ../../../share/sounds/sf2/Blonde_Bop_LV2.sf2 . # ln -s ../../../share/sounds/sf2/Blonde_Bop_HR_LV2.sf2 . I'm not sure if this is a sensible fix, but it seems to work correctly for me. Thanks for maintaining these packages. -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages avldrums.lv2 depends on: ii avldrums.lv2-soundfont 0.6.1-1 ii libc6 2.37-7 ii libcairo2 1.16.0-7 ii libgl1 1.6.0-1 ii libglib2.0-02.77.1-2 ii libpango-1.0-0 1.50.14+ds-1 ii libpangocairo-1.0-0 1.50.14+ds-1 ii libx11-62:1.8.6-1 avldrums.lv2 recommends no packages. avldrums.lv2 suggests no packages. -- no debconf information
Bug#1018205: (no subject)
For the latest upload (v2023.05.21-1), the QA page linked above once again indicates build and test passed for both arm64 and armel, so I’m still unsure how to repro/view this bug.
Bug#1042082: Please take over udev SysV init script
Hi, On 26/07/2023 19:43, lorenzo wrote: may I suggest to add this script to initscripts package(sysvinit:src) instead of o-s-s? A system without udev is not very common after all and the vast majority of scripts strictly needed to boot and shutdown the system are shipped there. Wearing my o-s-s maintainer hat, I have no problem with this suggest - what do the sysvinit maintainers think? [though I suspect we are going to end up with o-s-s being a dependency of sysvinit-core at this rate] Regards, Matthew
Bug#1042082: Please take over udev SysV init script
On 26/07/2023 15:16, Luca Boccassi wrote: On Wed, 26 Jul 2023 14:24:09 +0200 Michael Biebl wrote: Package: orphan-sysvinit-scripts Severity: normal X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Hi, in one of the upcoming releases of udev, the legacy SysV init script will be dropped. Please take over the file as you see fit. You can find a copy of the script at this stable link: https://salsa.debian.org/systemd-team/systemd/-/blob/6e720b91dd837b71dd81c1d959b21f1b0a48ae29/debian/udev.init Thanks. Are you able to clarify the copyright status of that file, please? The debian/* section in debian/copyright is 51 lines long, and I doubt all of those people should be considered copyright holders in the init script? Regards, Matthew
Bug#1041679: RFS: rumur/2023.05.21-1 [RC] -- model checker for the Murphi language
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "rumur": * Package name : rumur Version : 2023.05.21-1 Upstream contact : Matthew Fernandez * URL : https://github.com/Smattr/rumur * License : Unlicense * Vcs : https://github.com/Smattr/rumur.git Section : devel The source builds the following binary packages: rumur - model checker for the Murphi language To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rumur/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2023.05.21-1.dsc Changes since the last upload: rumur (2023.05.21-1) unstable; urgency=medium . * New upstream release. * Fix build failures with GCC-13. Closes: #1037851. * Update Standards-Version from 4.6.0.1 to 4.6.2. * Relicense debian/ as Unlicense instead of GPL-3+. Regards, Matt
Bug#1037851: (no subject)
Btw, why does this bug not appear when searching for bugs against the package? https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=rumur
Bug#1041552: HFS/HFS+ are insecure
On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist
> directive to prevent automatically loading some file system modules.
I think this would break any existing fstab entries that reference hfs
and hfsplus, and the convenient way to integrate Linux boot with x86
Macs is certainly to have an hfsplus EFI partition so this may be a
legitimate use-case. It also means that anyone who has a need to use one
of these filesystems in a static manner is vulnerable to automount
attacks using them.
Completely untested, but I think something along the lines of:
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"
in a udev fragment should work? Any static fstab or mount units should
still work, but it should disable udisks automounting regardless of the
desktop agent involved, even if the fs modules are already loaded.
Bug#1041073: exim4: Add CLI option to retry delivery for a particular recipient of a mail
Source: exim4
Version: 4.96-15
Severity: normal
Tags: upstream
Hi,
The exim CLI tool has a number of options for selecting particular
messages for {,re-}delivery attempts; but in all cases it will retry
all undelivered recipients of those messages.
It would be nice to be able to specify a subset of undelivered
recipients to retry - e.g. "attempt delivery of message XX-YY-ZZ to
reciepient f...@bar.com".
I sometimes find certain large mail providers get unhappy with
messages that contain a number of their recipients on the same mail,
and being able to just try to deliver to one or two of them at once
can help unwedge stuck mails...
Thanks,
Matthew
-- Package-specific info:
Exim version 4.96 #2 built 10-May-2023 16:30:35
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2022
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS TLS_resume
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP
PIPECONNECT PRDR PROXY Queue_Ramp SOCKS SPF SRS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot external plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Bug#1041072: trixie: Explicitly flag that /usr-merge changes will break skip-upgrades
Package: release-notes Severity: normal X-Debbugs-Cc: debian-c...@debian.org Hi, We don't support skip-upgrades, but in practice they can often be made to work by an experienced administrator. For trixie, though, packages are going to be allowed to assume merged-/usr, and the ongoing work to resolve the outstanding problems around merged-/usr and dpkg is going to concentrate on making sure all bookworm-trixie upgrades will work. But changes that could result in file loss on a bullseye-trixie skip-upgrade will not be considered bugs, so it would be good to particularly emphasise in the trixie release notes that skip-upgrades to it are not supported, and that in all circumstances administrators must upgrade to bookworm first. Thanks, Matthew ps: on a procedular note, whilst I'm filing this bug as an action from a technical committee meeting, this is not a formal TC request.
Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules
Hi, On 11/07/2023 10:21, John Paul Adrian Glaubitz wrote: On Mon, 2023-04-24 at 23:28 +0100, Matthew Vernon wrote: Hi, On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote: While we're currently not building Debian for 32-bit SPARC (sparc), it's still being bootstrapped in the Debian rebootstrap project [1]. The CI job for sparc is currently failing because pcre2 is still being configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was dropped upstream [3]. See also for the corresponding change in buildroot [4]. I can remove sparc, certainly. Is this something you would like me to try and get through the freeze? If not, I'd like to hold off making any pcre2 uploads until after the release. Any chance this can be done now? Thanks for the reminder, and sorry it was necessary. I've pushed 10.42-2 to unstable, which disables JIT on sparc. Regards, Matthew
Bug#1000113: kodi: depends on obsolete pcre3 library
Hi, On 06/07/2023 06:33, Vasyl Gello wrote: Yes I definitely see the bug. However, Kodi extensively uses pcrecpp and the only replacement I see for pcre2 is jpcre2 [1] There is an ITP bug about it since 2017 but no package. Matthew, from your experience, is jpcre2 the only C++ wrapper for pcre2 or there is something more recommended / maintainable? I did the search but found only jpcre2. I should say that I'm not C++ expert; jpcre2 is the only wrapper I find by web-searching. I think, though, that it should be possible to use the pcre2 libraries from C++ in the usual way that you can call C libraries from C++ (and the headers have the usual extern "C" magic)... Regards, Matthew
Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons
Hi, On 04/07/2023 22:38, g1 wrote: please consider adding triggers for restarting daemons when the executables change (usually at package upgrade). Is this always desireable? I'd normally expect a package postinst to invoke-rc.d or similar. Regards, Matthew
Bug#1040306: emacs: MML fails to list any keys thus signing fails
Package: emacs
Version: 1:28.2+1-15
Severity: important
Hi,
Signing emails in emacs isn't working at all; I have I think set
things up in a conventional manner -
I have mml-smime-use set to epg (it's the default, I think)
I have a GPG agent running.
epa-list-secret-keys lists the key I'd expect:
u 12F4D21C8F6A63C8 Matthew Vernon
[cf gpg --list-secret-keys:
sec rsa4096 2009-12-14 [SC]
BA4EF9C84DF96D37D8A1E2D412F4D21C8F6A63C8
uid [ultimate] Matthew Vernon
uid [ultimate] Matthew Vernon
ssb rsa4096 2009-12-14 [E]
]
But if I try and sign a message using MML (i.e. C-c C-m s which adds
--<>-{
--}-<>
round the mail as expected) then when I attempt to send, I get the
expected key selection buffer with the text
"Select keys for signing.
If no one is selected, default secret key is used.
"
...but there are no keys available to select, and if I hit OK, then I
just get the error
GPG error: "Signing failed (unknown reason)"
...which I think is an artifact of MML having failed to find a
suitable key. But epa knows about my secret key, so this _ought_ to
work...
Thanks,
Matthew
-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages emacs depends on:
ii emacs-lucid 1:28.2+1-15
emacs recommends no packages.
emacs suggests no packages.
-- no debconf information
Bug#1040228: Resignation & call for votes to elect the Chair
Hi, On 03/07/2023 17:55, Sean Whitton wrote: ===BEGIN A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Simon McVittie E: Stefano Rivera F: Timo Röhling G: Matthew Vernon H: Sean Whitton ===END I vote: H > A = B = C = D = G > E = F Regards, Matthew OpenPGP_signature Description: OpenPGP digital signature
Bug#1038903: initscripts: orphan-sysvinit-scripts needs to be a prerequisite, not optional.
Hi, On 23/06/2023 02:11, Thorsten Glaser wrote: Nothing for orphan-sysvinit-scripts, which *really* surprises me, as I’m certain we discussed this earlier. You may be remembering bullseye? After quite a lot of wrangling, we got a short note added to the release notes[0] and installation guide[1] both of which basically pointed to the wiki[2]. Hmph. It took me about 20 minutes to find where the source repo for the release notes is and orphan-sysvinit-scripts indeed shows up nowhere in there. Wasn’t it discussed on the mailing list? It really ought to be there. I don't recall any discussion about bookworm release notes; I think if you'd have asked me I would have said that Recommends: should be enough for most cases! I don't feel inclined to try and get a change into the release notes, since it was a lot of effort for bullseye, but happy to eyeball a patch if someone else feels keen. Sorry. Regards, Matthew [0] https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html#inits-xx [1] https://www.debian.org/releases/bullseye/amd64/ch06s05.en.html#idm2887 [2] https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time
Bug#1038903: initscripts: orphan-sysvinit-scripts needs to be a prerequisite, not optional.
Hi, sysvinit-core in bookworm Recommends: orphan-sysvinit-scripts ; have you told apt to ignore recommends? I think I agree with others who have said that it wouldn't be appropriate for all sysvinit systems to install orphan-sysvinit-scripts (which would warrant a Depends: ); obviously that might change if we end up with more init scripts in it. I agree that a note in the release notes might be warranted (it may or may not be possible to get them updated now). Regards, Matthew
Bug#1038903: initscripts: orphan-sysvinit-scripts needs to be a prerequisite, not optional.
Hi, On 23/06/2023 01:24, Mason Loring Bliss wrote: On Fri, Jun 23, 2023 at 02:14:40AM +0200, Thorsten Glaser wrote: The choice to use a nōn-default setup (using rsyslogd at all in bookworm) is up to the local admin. It's not obvious from the release notes that rsyslog is deprecated. Maybe it's too late now for Bookworm, but this speaks to Debian's suitability as a platform for services. Frankly it makes Devuan seem more appealing, for folks with any sort of mental investment in Debian. The release-notes do have a section titled "5.1.7. Changes to system logging"[0] which I think is reasonably clear that the default logging system is moving away from rsyslog. It's definitely an oversight that orphan-sysvinit-scripts hasn't been mentioned in the release notes; but sysvinit-core does Recommend: orphan-sysvinit-scripts, so I would expect a typical installation to have installed them for you. Did that not work, or have you configured apt to skip Recommends? Regards, Matthew [0] https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-system-logging
Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling
On Wed, Jun 14, 2023 at 10:04:54AM +0100, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: roehl...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Timo Röhling be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Timo Röhling > F: Further discussion > ===END I vote R > F signature.asc Description: PGP signature
Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera
On Wed, Jun 14, 2023 at 10:03:19AM +0100, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: stefa...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Stefano Rivera be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Stefano Rivera > F: Further discussion > ===END I vote: R > F signature.asc Description: PGP signature
Bug#1037987: virt-p2v: The script virt-p2v-make-disk attempts to call the redhat package manager 'dnf' during build.
Package: virt-p2v Version: 1.42.3-1 Severity: important X-Debbugs-Cc: thisg...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** Attempting to build a p2v iso to convert machines to vms. When you run virt-p2v-make-disk -o ./p2v.iso it eventually throws an error: ``` [ 6.8] Downloading: http://builder.libguestfs.org/debian-12.xz [ 7.7] Planning how to build this image [ 7.7] Uncompressing [ 13.2] Opening the new disk [ 17.7] Setting a random seed virt-builder: warning: random seed could not be set for this type of guest [ 17.8] Uploading: /tmp/tmp.rs28NvEXtc/policy-rc.d to /usr/sbin/policy-rc.d [ 17.9] Setting the hostname: p2v.local [ 18.9] Running: hostname p2v.local [ 19.0] Running: dnf -y update --exclude=kernel\* /bin/sh: 4: dnf: not found virt-builder: error: dnf -y update --exclude=kernel\*: command exited with an error If reporting bugs, run virt-builder with debugging enabled and include the complete output: virt-builder -v -x [...] ``` Manually changing the script to use 'apt-get update -y' instead of 'dnf update -y' allows the script to work. ```diff 249c249 < --run-command 'dnf -y update --exclude=kernel\*'\ --- > --run-command 'apt-get -y update'\ ``` -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virt-p2v depends on: ii binutils 2.40-2 ii libguestfs-tools 1:1.48.6-2 ii mawk 1.3.4.20200120-3.1 ii xz-utils 5.4.1-0.2 virt-p2v recommends no packages. virt-p2v suggests no packages. -- no debconf information
Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On Wed, 14 Jun 2023 10:04:54 +0100, Sean Whitton wrote: > > ===BEGIN > The Technical Committee recommends that Timo Röhling be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Timo Röhling > F: Further discussion > ===END I vote R > F Regards, Matthew -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmSJhhcACgkQEvTSHI9q Y8hlRxAAqtB1a7wktMYhZbLsgJCGUj6rrWTleVHQUYUA68RTF8zuNiXNsLtOZhFY KpChIb8eHf0tKTGS2QzyPya88b8Y2v5GIomdDrVnm0xik8T0lIFRTO6ojnJDb1sQ Mkb2ookniRp3AhLA4vlmZgtDmtKECBHYcEwXrehN6QQQc1Q0A38r8N/cGhy3d5GI EiyJSDwI9nPw4W8WWWfxGvL+3HDPRKr89uBzOfb8/IPQEJ/LdnCXMUT0FfhEsMMC yl0odXa3iL9MNLvWlOAUClJMKbFu/qdHfEn8GPEM2+wAOj3bsxCa3g1W7677LmOY PRW00wsTln98a/8l/M5854JTCikExQ+UKC7H5UNw/NsfG23et5A8akNN4uFZV1YM 0PStKLrjmTE6FS3j/0s+x5hsgWflr0jtW4tUg+Ra925bGEZJaPaZa5rSCJ8a2dAn xdUL2+YdsCtN0thUnAbqinm9L+ne0SwIENQTf7SY01CWkr9o0QTGV7Gu3OhOuTA+ bLsvG2hP87vmXWl3xPFTwQwY9cZjtXdAV6ammQBsIYmGRKSU638R3MZCsq3LCDKk FR+Tv6slr1xcLqV3xim3cNzooH+vqlBbzSblqgMbub9op2Z6rQ06vER/zKNUCGdn YQ9MDrvo2Y/bnVmAyciSPIhyNG1jEfuY1JfgGer+GkaGEEOrsLA= =cICf -END PGP SIGNATURE-
Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On Wed, 14 Jun 2023 10:03:19 +0100, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Stefano Rivera be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Stefano Rivera > F: Further discussion > ===END I vote R > F Thanks, Matthew -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmSJhd8ACgkQEvTSHI9q Y8jiaw/+K4VyZctMAdD+SvVIefZJ+seSDBPkHR9a8xwfuz4mXIDKycmvGh6lyI8r 1S3ZmyUSAyntac97Wxl8cFWH2Z+BPYQI61tZK5IP+bkQSMj44QWkIxgAlFbrApCi OrshXTup8Nws/IKz6cR5hSvSEtO7f07janwdTmzBAhDpYF/IHoAPKVY+kxX7M4hr Mtt/lZhzdAAZEsojBdpvhx0HDKTJruZQrdf/3dz5ftVdQVPAz/lq1W4oCcxlrs1y 39lzlRhZGdUq62fokoGApoc1B2uVv/mHln1oC6FpyqMfT9ocwotASb5ks3IAz0Ix bdf5ApX8vL/9Q1bpjRMaLDSorkNI8s9Mq1yGPZmhXHYLWFdbh5ucB8DtY85dGkEY u2Ej/C1jgXF0O35nDFFMBpvjXD/BmU52okTIW5qOTa7Ndmt1PWoFchx1TpT9mL2R XJY6DcV7/9AyJUs6M+vVhHJ0EmoDp5o/Z7RMOmPBDYTgyoW6XCNAw3zJdRTVfg+g VIF3YYZP6y+vNeqMmx4Iu9dM+1b4fF0QVIOia+VnSVJjMqWlYy6cLEMSQm5Q37Lk OiGsdNgDyCl5CoKnsvS88PF+EnLY1k2WHWrdrDZ6MhYdmh9+9H9KKf5wQvSVcFGu XPVyoO0bek8UOZ3OWyXtpV6WMbRlflIhmpS1462y3W9s+1AfW2k= =//2f -END PGP SIGNATURE-
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Tue, Jun 13, 2023 at 09:14:53PM +0200, Ansgar wrote: > On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote: > > After discussing this at our monthly meeting, we concluded that the > > technical committee isn't going to take action on this at the moment. > > There's a legitimate technical consideration behind the warning, and > > it's necessary for derivatives to ensure that they handle the > > associated scenarios properly. > > Okay, I take that as "Debian doesn't care about derivatives". > Suggesting users to revert to split-/usr *will* break stuff for users > once more code Debian assumes merged-/usr. With my non-CTTE hat on, I think this is a demonstration that Debian *does* care about derivatives. It's important to ensure that derivatives are aware of the subtle interactions between dpkg and usrmerge, otherwise they may suffer from hard to diagnose issues on upgrades. The message from dpkg says nothing about reverting to split-/usr, and instead points at a wiki page. If our documentation on how to avoid these issues is incomplete (ie, if we're only describing how to avoid it by using split-/usr rather than describing the mitigations we've imposed within Debian to avoid triggering the issues), perhaps a better approach would be to improve that documentation? We don't benefit our users by pretending there isn't a problem here.
Bug#1037303: lxc sets the wrong broadcast address on containers after upgrade to bookworm
Package: lxc
Version: 1:5.0.2-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
Upgraded from bullseye to bookworm.
The broadcast address changed within the container
$ ip route show table local dev eth0 scope link
broadcast 0.0.127.255 proto kernel src 172.21.3.113
broadcast 172.21.127.255 proto kernel src 172.21.3.113
using this configuration:
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.veth.pair = p_dav-test
lxc.net.0.name = eth0
lxc.net.0.ipv4.address = 172.21.3.113/17
lxc.net.0.ipv4.gateway = 172.21.1.1
Expection is that everything works the same as the previous version of lxc.
that we get the following:
$ ip route show table local dev eth0 scope link
broadcast 172.21.0.0 proto kernel src 172.21.3.113
broadcast 172.21.127.255 proto kernel src 172.21.3.113
* What exactly did you do (or not do) that was effective (or
ineffective)?
Upgrade debian 11 to debian 12 and reboot the server.
* What was the outcome of this action?
* What outcome did you expect instead?
Everything work exactly the same.
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lxc depends on:
ii debconf [debconf-2.0]1.5.82
ii dnsmasq-base [dnsmasq-base] 2.89-1
ii iproute2 6.1.0-3
ii iptables 1.8.9-2
ii libapparmor1 3.0.8-3
ii libc62.36-9
ii libcap2 1:2.66-4
ii libgcc-s112.2.0-14
ii liblxc-common1:5.0.2-1
ii liblxc1 1:5.0.2-1
ii libseccomp2 2.5.4-1+b3
ii libselinux1 3.4-1+b6
ii lsb-base 11.6
ii sysvinit-utils [lsb-base]3.06-4
Versions of packages lxc recommends:
ii apparmor 3.0.8-3
pn debootstrap
pn dirmngr
pn gnupg
pn libpam-cgfs
pn lxc-templates
ii lxcfs 5.0.3-1
ii openssl3.0.9-1
pn rsync
pn uidmap
pn wget
Versions of packages lxc suggests:
pn btrfs-progs
pn lvm2
pn python3-lxc
-- Configuration Files:
/etc/apparmor.d/abstractions/lxc/start-container changed:
network,
capability,
file,
# The following 3 entries are only supported by recent apparmor versions.
# Comment them if the apparmor parser doesn't recognize them.
dbus,
signal,
ptrace,
# currently blocked by apparmor bug
mount -> /usr/lib*/*/lxc/{**,},
mount -> /usr/lib*/lxc/{**,},
mount -> /usr/lib/x86_64-linux-gnu/lxc/rootfs/{,**},
mount fstype=devpts -> /dev/pts/,
mount options=bind /dev/pts/ptmx/ -> /dev/ptmx/,
mount options=bind /dev/pts/** -> /dev/**,
mount options=(rw, make-slave) -> **,
mount options=(rw, make-rslave) -> **,
mount options=(rw, make-shared) -> **,
mount options=(rw, make-rshared) -> **,
mount fstype=debugfs,
# allow pre-mount hooks to stage mounts under /var/lib/lxc//
mount -> /var/lib/lxc/{**,},
mount /dev/.lxc-boot-id -> /proc/sys/kernel/random/boot_id,
mount options=(ro, nosuid, nodev, noexec, remount, bind) ->
/proc/sys/kernel/random/boot_id,
# required for some pre-mount hooks
mount fstype=overlayfs,
mount fstype=aufs,
mount fstype=ecryptfs,
# all umounts are under the original root's /mnt, but right now we
# can't allow those umounts after pivot_root. So allow all umounts
# right now. They'll be restricted for the container at least.
umount,
#umount /mnt/{**,},
# This may look a bit redundant, however it appears we need all of
# them if we want things to work properly on all combinations of kernel
# and userspace parser...
pivot_root /usr/lib*/lxc/,
pivot_root /usr/lib*/*/lxc/,
pivot_root /usr/lib*/lxc/**,
pivot_root /usr/lib*/*/lxc/**,
pivot_root /usr/lib/x86_64-linux-gnu/lxc/rootfs/{,**},
change_profile -> lxc-*,
change_profile -> lxc-**,
change_profile -> unconfined,
change_profile -> :lxc-*:unconfined,
/etc/apparmor.d/lxc/lxc-default-cgns changed:
profile lxc-container-default-cgns flags=(attach_disconnected,mediate_deleted) {
#include
# the container may never be allowed to mount devpts. If it does, it
# will remount the host's devpts. We could allow it to do it with
# the newinstance option (but, right now, we don't).
deny mount fstype=devpts,
mount fstype=cgroup -> /sys/fs/cgroup/**,
mount fstype=cgroup2 -> /sys/fs/cgroup/**,
mount fstype=overlay,
}
/etc/apparmor.d/lxc/lxc-default-with-nesting changed:
profile lxc-container-default-with-nesting
flags=(attach_disconnected,mediate_deleted) {
#include
#include
deny
Bug#1037165: vit: Python TypeError: 'str' object does not support item assignment
On 08-06-2023, Jochen Sprickerhof wrote: Hi Matthew, I can't reproduce this in a fresh system (downgrading severity accordingly). Do you have any taskwarrior or vit config files in your home? Judging from the trace above I guess it is a custom taskwarrior config. Can you try without that? Hi Jochen, Thanks for coming back to me. On first look, I thought the issue might have been in the vit config file but following your advice, and on closer inspection with pdb, I seemed to have two problematic lines in my .taskrc config: context.home=project.h context.work=project.w I don't know why these seemed to get by taskwarrior - perhaps they are a legacy format, but this is not correct according to man taskrc for 2.6.2, for creating a context. Fixed by removing these lines. Many thanks and apologies for the "grave" bug drama :-) -- Matthew Lemon signature.asc Description: PGP signature
Bug#1037165: vit: Python TypeError: 'str' object does not support item assignment
Package: vit
Version: 2.2.0-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
Installed vit, ran `vit` to launch program.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Ran `vit` command.
* What was the outcome of this action?
Traceback (most recent call last):
File "/usr/bin/vit", line 33, in
sys.exit(load_entry_point('vit==2.2.0', 'console_scripts', 'vit')())
^^
File "/usr/lib/python3/dist-packages/vit/command_line.py", line 5, in main
Application(options, filters)
File "/usr/lib/python3/dist-packages/vit/application.py", line 77, in __init__
self.refresh(False)
File "/usr/lib/python3/dist-packages/vit/application.py", line 920, in refresh
self.bootstrap(load_early_config)
File "/usr/lib/python3/dist-packages/vit/application.py", line 110, in
bootstrap
self.load_contexts()
File "/usr/lib/python3/dist-packages/vit/application.py", line 104, in
load_contexts
self.contexts = self.task_config.get_contexts()
^^^
File "/usr/lib/python3/dist-packages/vit/config_parser.py", line 333, in
get_contexts
subtree = self.subtree('context.')
File "/usr/lib/python3/dist-packages/vit/config_parser.py", line 292, in
subtree
tree_location[part] = {} if len(parts) else value
~^^
TypeError: 'str' object does not support item assignment
* What outcome did you expect instead?
Program to launch.
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages vit depends on:
ii python3 3.11.2-1+b1
ii python3-tasklib 2.5.1-3
ii python3-urwid2.1.2-4+b1
vit recommends no packages.
vit suggests no packages.
-- no debconf information
--
Matthew Lemon
Email: m...@matthewlemon.com
signature.asc
Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, This thread has rather veered off the initial bug report. On 11/05/2023 13:16, Simon Richter wrote: Hi, On 5/11/23 10:59, Sean Whitton wrote: Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Currently dpkg contains code to emit the merged-/usr warning, that's dead code on Debian, but which becomes active when packages from the Debian archive are copied unmodified into derivatives. The way I see it (but I'm not a dpkg maintainer), the current implementation is correct, as dpkg does not support aliased directories, but Debian has decided to use it in such an environment nonetheless. The tech-ctte decision not to roll back usrmerge accepts responsibility for this decision, so silencing the warning on Debian is correct, but no one has accepted that responsibility for derived distributions. Any derived distribution can easily go on record and request inclusion in the list of distributions where this warning is suppressed, by typing the phrase "Yes, I understand that this is a bad idea." into an email client. I have considerable sympathy for this point of view. Further, given ongoing (and quite fruitful) discussion on how to resolve the outstanding issues around /usr-merge and dpkg, I don't think the question of dpkg's warning (and its unfortunate wording) is one that is useful for the technical committee (and the dpkg maintainers) to be spending time on right now. I think I would feel differently if there were derivatives who had asked the dpkg maintainers to likewise exclude their distro from the warning had been rebuffed (though I suspect such folk will just be patching it out in their own builds). Likewise I would expect that once we have finished sorting out the outstanding /usr-merge & dpkg issues that the warning would be removed. But those scenarios aren't where we're at now, so I think the project should continue to focus on moving ourselves to the point where dpkg does support /usr-merge as implemented in Debian. Regards, Matthew
Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 09 May 2023 21:26:10 +0100, Hi, Sean Whitton wrote: > === BEGIN > > OPTION A: > > Under Constitution 6.1.5, the Technical Committee recommends that the > maintainers of individual packages should not proactively move files > from the root filesystem to corresponding locations under /usr in the > data.tar.* of packages. So, /foo/bar should not move to /usr/foo/bar. > > Files that are in /usr in the Debian 12 release should remain in /usr, > while files that are in /bin, /lib* or /sbin in the Debian 12 release > should remain in those directories. If any files are moved from /bin, > /lib* or /sbin into /usr after the Debian 12 release, they should be > moved back to their Debian 12 locations. > > This moratorium lasts until we vote to repeal it. We expect to do that > during the trixie development cycle, and sooner rather than later. > We will continue to facilitate efforts to resolve the remaining issues > that stand in the way of safely repealing the moratorium. > > OPTION B: > > As option A, except that only maintainers of essential and transitively > essential packages should refrain from proactively moving files from the > root filesystem to corresponding locations under /usr in the data.tar.* > of packages. > > OPTION N: > > None of the above. > > === END I vote A > B > N. Regards, Matthew - -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmRjwrQACgkQEvTSHI9q Y8jZ2g//dP+kxRXBLe/GjgE54NsePfPFmXD4gFaOsr535M3IePVRqA7JNHs9g0Fj kCZLH0lZnM04pTp/EPqUas/9HY4wq6sVTo+SDjWe+seJu6ichdIqLmuKoKUF1jqp ps+ZBi0ppeQBrfirYU1i9xrKXQPMMfcQ+IRgyllvPSwuqB9lpFPDeIYsZGEJjaER KzZ4lm+/56F4SrnannYon5la8IO+nUQFvM3vWuaQJFENnTB8RaMjBm+29kvUnJEl 7JHVdKZppqwgiYtzaOkLfEdAv2zcfpk/fL6Zd/pe6p+nSPXWXzyhUVJvCcuRq6B+ uiGj8F7G0K35jSm/1wozSwE9iyeNfOi9QJS4XnRYT8t6VxUn8KfZUbMBtalh4fIN 3dt10eKkJEPBSNuMzky7uDQszbo6JaQIWRs0Jb7pYftpimcCf0OZ/3ICC/gTHm/I 63CFwXaIm/cSXEw/ol9GBJ1ZIh5zcRH95tK0bLDZtIs6KRMF0aqzUvwaYSBcxCuM sirbd+PaQ87I19nPyyFuwi6yhUDwWsnXCENc/GGsU9LQp/UDaG5Er8YVcfWkpMh2 lM+ih6qP9hLjeYBAywYJlzRWYVieiLvfaOQCrkOlfOSZKQD8tGqGTbBj6+9LTa9e YxJJrSiHXK3g8JY/GLvnIJLlvcEdsE1Ivkae8WaeHBuvc8JUs7w= =Dysi -END PGP SIGNATURE-
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On 15/05/2023 16:54, Bdale Garbee wrote: I could. Can you provide an example of actual value delivered to Debian from merged-/usr? With respect, I don't think this line of argument is going to get us very far - this bug isn't about whether we should undo usr-merge, so I don't think a debate on the merits or otherwise of usr-merge is germane. [I think this applies to the contrary side of the argument also] Regards, Matthew
Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules
Hi, On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote: While we're currently not building Debian for 32-bit SPARC (sparc), it's still being bootstrapped in the Debian rebootstrap project [1]. The CI job for sparc is currently failing because pcre2 is still being configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was dropped upstream [3]. See also for the corresponding change in buildroot [4]. I can remove sparc, certainly. Is this something you would like me to try and get through the freeze? If not, I'd like to hold off making any pcre2 uploads until after the release. Thanks, Matthew
Bug#1013448: pcre2 relies on write+execute mappings unnecessarily
On 12/04/2023 06:13, Trent W. Buck wrote: FYI, systemd's MemoryDenyWriteExecute=yes breaks "git grep" because of pcre2jit. An easy test command is something like this: $ journalctl --user -fn0 & # so you see the error $ systemd-run --property=MemoryDenyWriteExecute=yes --user git -C /srv/vcs/kb grep -Fwi mutt --error--> git[2289491]: fatal: Couldn't JIT the PCRE2 pattern 'mutt', got '-48' A real-world use case is hardening gitit.service, a git-based wiki <https://packages.debian.org/stable/gitit>. With MemoryDenyWriteExecute=yes, gitit works perfectly, EXCEPT for search (which uses "git grep" under the hood). Is there a way for a sysadmin to disable pcre2jit at runtime, e.g. with an environment variable? I understand it makes pcre2 slower, but I might actually prefer to make that security-vs-speed tradeoff. I looked at https://manpages.debian.org/pcre2jit but only found compile-time options. Software authors that use pcre2 can opt to not use jit (e.g. by specifying PCRE2_NO_JIT in the arguments to pcre2_match, not calling pcre2_jit_compile()). So I think if you wanted git to not use PCRE2's JIT, the git authors would be the people to ask for that feature. You could ask the PCRE2 authors to consider an environment variable to disable JIT at runtime, but I suspect they'd say this was the sort of thing that applications using PCRE2 should do instead. Regards, Matthew
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
On 29/03/2023 12:37, Jesse Smith wrote: Given subsequent discussion, could we instead use canonicalize_file_name or realpath here instead? That would give us the "correct" path without pidof having to think hard about symlinks et al. I'm open to the possibility. I'm curious as to what you see as the pros vs cons of changing the approach used by pidof? Broadly, I think there is an expectation that pidof $(which emacs) works on Debian (et al) systems where alternatives are in use (or other setups with >1 symlink), regardless of which user is running the emacs (WLOG). I think using realpath or canonicalize_file_name might simplify matters? But I've not gone poking through the code in detail, just this talk of more than one symlink confusing things made me think of these library functions. Perhaps as an aside, on my system with 3.06-2, I see different behaviour depending on the user running the binary: matthew@aragorn:~/junk$ ps waux | grep emacs root 3905 0.0 0.0 165344 3976 tty1 TMar06 0:00 emacs /etc/mumble-server.ini matthew 5149 0.0 1.0 453684 169224 ? Ss Feb11 61:26 emacs --daemon matthew 13119 0.0 0.3 214776 50076 pts/19 SFeb27 0:37 emacs accparse.py matthew@aragorn:~/junk$ pidof emacs 13119 5149 3905 matthew@aragorn:~/junk$ pidof $(which emacs) 3905 matthew@aragorn:~/junk$ pidof $(readlink -f $(which emacs)) 13119 5149 Here $(which emacs) -> /usr/bin/emacs -> /etc/alternatives/emacs -> /usr/bin/emacs-lucid So the root process is picked up with pidof /usr/bin/emacs and the user processes by pidof /usr/bin/emacs-lucid. pidof emacs picks up all three. In each case /proc/pid/exe is (a deleted version of) /usr/bin/emacs-lucid HTH, Matthew
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 24/03/2023 14:17, Jesse Smith wrote:
On 2023-03-24 6:44 a.m., Markus Fischer wrote:
I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
/* Try to stat the executable. */
snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
p->pathname = (char *)xmalloc(PATH_MAX);
+ memset(p->pathname, 0, PATH_MAX);
if (readlink(path, p->pathname, PATH_MAX) == -1) {
p->pathname = NULL;
}
This patch looks good to me. I'm adding it upstream.
Will run some more tests before publishing 3.07. And would appreciate it
if everyone following this issue could test too and provide feedback.
Given subsequent discussion, could we instead use canonicalize_file_name
or realpath here instead? That would give us the "correct" path without
pidof having to think hard about symlinks et al.
Matthew
Bug#1033039: kde-config-flatpak: Verified
Package: kde-config-flatpak Version: 5.27.2-1 Followup-For: Bug #1033039 Dear Maintainer, I can verify this bug. I have installed the kde-config-flatpak package and I can access the "Flatpak Permissions Settings", but when I select an application from the list all I get is "Select an application from the list to view it's permissions here". I also cannot find any information on a missing dependecy or setting that might be preventing me from accessing the permissions. Matthew -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kde-config-flatpak depends on: ii libc6 2.36-8 ii libflatpak0 1.14.3-1 ii libglib2.0-02.74.6-1 ii libkf5configcore5 5.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5quickaddons5 5.103.0-1 ii libqt5core5a5.15.8+dfsg-3 ii libqt5qml5 5.15.8+dfsg-3 ii libstdc++6 12.2.0-14 ii systemsettings 4:5.27.2-1 kde-config-flatpak recommends no packages. kde-config-flatpak suggests no packages. -- no debconf information
Bug#972950: Another vote for reverting this change
Control: severity -1 important Hi, I'd like to agree - can we have the traditional-in-Debian behaviour of "cal" back (i.e. highlighting the current data), please? As others have pointed out if you want to parse cal's output, then it automatically didn't highlight when piped elsewhere, and there was -h to suppress it. I think for a command like this we should prioritise the interactive use-case - so "cal" highlighting on a terminal should be the default. [bumping the severity, because missing this feature since I upgraded to bookworm is breaking the main thing I ever use cal for...] Thanks, Matthew
Bug#1018023: Update on this bug?
Hi, On 10/03/2023 23:12, Jose Antonio Jimenez Madrid wrote: I have just uploaded to mentors a new version of the package fixing this bug. I will made other improvements after Bookworm is released as we are very close to the full freeze. The new package can be found here: https://mentors.debian.net/package/eterm/ Thanks; I've reviewed these changes and uploaded for you. I expect I'll need to file an unblock request in due course; I'll try and remember to do so. You were right to make the minimal bug-fix changes at this point in the release cycle; once bookworm is out it would be good to look at some of the other packaging issues; I'll be happy to sponsor further uploads if that's helpful. Regards, Matthew
Bug#1032469: smartmontools: startup takes too long for systemd
Package: smartmontools Version: 7.2-1 Severity: normal Hi, On some of our production servers with a lot of JBOD disks, smartd takes so long to start up that systemd's default 90s timeout kicks in and smartd gets killed. Example log extract: Mar 07 14:15:10 ms-be2070 systemd[1]: Starting Self Monitoring and Reporting Technology (SMART) Daemon... [smartd starts monitoring disks] Mar 07 14:16:40 ms-be2070 systemd[1]: smartmontools.service: start operation timed out. Terminating. Mar 07 14:16:40 ms-be2070 systemd[1]: smartmontools.service: Failed with result 'timeout'. Mar 07 14:16:40 ms-be2070 systemd[1]: Failed to start Self Monitoring and Reporting Technology (SMART) Daemon. I fixed this by adding a systemd override: [Service] TimeoutSec=300 And now all is good: Mar 07 14:31:53 ms-be2070 systemd[1]: Starting Self Monitoring and Reporting Technology (SMART) Daemon... Mar 07 14:34:06 ms-be2070 systemd[1]: Started Self Monitoring and Reporting Technology (SMART) Daemon. Note the ~2 minute start time. It seems to me that the default startup timeout ought to be long enough to work "out of the box", so could the unit file we ship be adjusted to set a sensible TimeoutSec value, please? 300s seems likely to be enough. Thanks, Matthew -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/48 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) Versions of packages smartmontools depends on: ii debianutils 4.11.2 ii libc62.31-13+deb11u5 ii libcap-ng0 0.7.9-2.2+b1 ii libgcc-s110.2.1-6 ii libselinux1 3.1-3 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-7+deb11u1 ii lsb-base 11.1.0 smartmontools recommends no packages. Versions of packages smartmontools suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 ii curl 7.74.0-1.3+deb11u7 ii gpg2.2.27-2+deb11u2 pn gsmartcontrol pn smart-notifier ii wget 1.21-1+deb11u1 -- Configuration Files: /etc/smartmontools/run.d/10mail [Errno 2] No such file or directory: '/etc/smartmontools/run.d/10mail' -- no debconf information
Bug#1018023: Update on this bug?
Hi, On 14/02/2023 18:36, Jose Antonio Jimenez Madrid wrote: I will test this patch and let you to know whether the bug is fixed. Any joy? We're approaching the time that eterm is going to be autoremoved from bookworm... Thanks, Matthew
Bug#1023255: NMU to fix
Hi, While preparing the previous, I ran lintian, which found (amongst other things) 3 more problems of this form: E: git-doc: doc-base-file-references-missing-file /usr/share/doc/git-doc/technical/pack-format.txt [usr/share/doc-base/git-doc.git-pack-format:9] E: git-doc: doc-base-file-references-missing-file /usr/share/doc/git-doc/technical/pack-protocol.txt [usr/share/doc-base/git-doc.git-protocol:12] E: git-doc: doc-base-file-references-missing-file /usr/share/doc/git-doc/technical/protocol-*.txt [usr/share/doc-base/git-doc.git-protocol:12] I think they didn't result in separate bug reports because in each case the file contains a working link as well as a non-working one. I've attached revised patches, which I'll upload shortly. I hope NMUing this is OK, my rationale is that: * it's rapidly approaching the last day for uploads to get into bookworm without release team intervention * no code changes are made * bug fix is uncontroversial (it's simply reflecting changed paths in the package) Regards, MatthewFrom 298f793c6d5b456302d93ce84c404fac5b856c7b Mon Sep 17 00:00:00 2001 From: Matthew Vernon Date: Mon, 27 Feb 2023 20:13:22 + Subject: [PATCH 1/2] Correct paths in doc-base control files (Closes: #1023255) As well as the path highlighted by the error in the bug report, also fix three more paths that lintian picks up (that didn't result in an error as there were other correct paths in those control files). --- debian/git-doc.doc-base.git-index-format | 2 +- debian/git-doc.doc-base.git-pack-format | 2 +- debian/git-doc.doc-base.git-protocol | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/debian/git-doc.doc-base.git-index-format b/debian/git-doc.doc-base.git-index-format index 245a1b5..00f9871 100644 --- a/debian/git-doc.doc-base.git-index-format +++ b/debian/git-doc.doc-base.git-index-format @@ -6,4 +6,4 @@ Abstract: The on-disk format of Git's staging area, merging area, Section: File Management Format: Text -Files: /usr/share/doc/git-doc/technical/index-format.txt +Files: /usr/share/doc/git-doc/gitformat-index.txt diff --git a/debian/git-doc.doc-base.git-pack-format b/debian/git-doc.doc-base.git-pack-format index e7c728b..8e2cb9b 100644 --- a/debian/git-doc.doc-base.git-pack-format +++ b/debian/git-doc.doc-base.git-pack-format @@ -5,5 +5,5 @@ Abstract: Git's packed data format. Section: File Management Format: Text -Files: /usr/share/doc/git-doc/technical/pack-format.txt +Files: /usr/share/doc/git-doc/gitformat-pack.txt /usr/share/doc/git-doc/technical/pack-heuristics.txt diff --git a/debian/git-doc.doc-base.git-protocol b/debian/git-doc.doc-base.git-protocol index 4495708..a3a81d7 100644 --- a/debian/git-doc.doc-base.git-protocol +++ b/debian/git-doc.doc-base.git-protocol @@ -7,6 +7,6 @@ Abstract: Reference documentation for the upload-pack and Section: File Management Format: Text -Files: /usr/share/doc/git-doc/technical/pack-protocol.txt - /usr/share/doc/git-doc/technical/protocol-*.txt +Files: /usr/share/doc/git-doc/gitprotocol-pack.txt + /usr/share/doc/git-doc/gitprotocol-*.txt /usr/share/doc/git-doc/technical/send-pack-pipeline.txt -- 2.39.2 From e5b072e6a2e19e473c1897fb1d2a2ce258ee19c2 Mon Sep 17 00:00:00 2001 From: Matthew Vernon Date: Mon, 27 Feb 2023 20:13:37 + Subject: [PATCH 2/2] Changelog for 1:2.39.2-1.1 --- debian/changelog | 7 +++ 1 file changed, 7 insertions(+) diff --git a/debian/changelog b/debian/changelog index a55b587..d4dbf36 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +git (1:2.39.2-1.1) unstable; urgency=medium + + * Non-maintainer upload (only changes to git-doc). + * Correct paths in git-doc doc-base control files (Closes: #1023255) + + -- Matthew Vernon Tue, 28 Feb 2023 09:25:32 + + git (1:2.39.2-1) unstable; urgency=medium * new upstream point release (see RelNotes/2.39.2.txt). Addresses -- 2.39.2
Bug#1023255: NMU to fix
Control: found -1 1:2.39.2-1 Control: tags -1 patch quit Hi, I tripped over this on my bookworm system, and it's both a bit annoying and an easy fix. I've prepared an NMU to fix this so it'll get into bookworm - OK for me to upload? Thanks, MatthewFrom 716d196b0c5dc9f3fe13a87d8010ae07048d4e7c Mon Sep 17 00:00:00 2001 From: Matthew Vernon Date: Mon, 27 Feb 2023 20:13:22 + Subject: [PATCH 1/2] Correct path to git index format doc (Closes: #1023255) --- debian/git-doc.doc-base.git-index-format | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/git-doc.doc-base.git-index-format b/debian/git-doc.doc-base.git-index-format index 245a1b5..00f9871 100644 --- a/debian/git-doc.doc-base.git-index-format +++ b/debian/git-doc.doc-base.git-index-format @@ -6,4 +6,4 @@ Abstract: The on-disk format of Git's staging area, merging area, Section: File Management Format: Text -Files: /usr/share/doc/git-doc/technical/index-format.txt +Files: /usr/share/doc/git-doc/gitformat-index.txt -- 2.39.2 From 5881f8267534637b591a079c7c284cbdc7d325e7 Mon Sep 17 00:00:00 2001 From: Matthew Vernon Date: Mon, 27 Feb 2023 20:13:37 + Subject: [PATCH 2/2] Changelog for 1:2.39.2-1.1 --- debian/changelog | 7 +++ 1 file changed, 7 insertions(+) diff --git a/debian/changelog b/debian/changelog index a55b587..cb78cd1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +git (1:2.39.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Correct path to git index format doc (Closes: #1023255) + + -- Matthew Vernon Mon, 27 Feb 2023 20:12:04 + + git (1:2.39.2-1) unstable; urgency=medium * new upstream point release (see RelNotes/2.39.2.txt). Addresses -- 2.39.2
Bug#1031854: orphan-sysvinit-scripts: should cope with defective rsyslog-rotate
On 24/02/2023 11:20, Lorenzo wrote: On Fri, 24 Feb 2023 09:20:29 + Matthew Vernon wrote: rsyslog-rotate should HUP rsyslog as appropriate for the installed init system. It doesn't, so orphan-sysvinit-scripts should work around this on sysvinit systems, without causing problems on systemd systems. Isn't a conflict with systemd-sysv package enough? No (and in general I don't want to end up with orphan-sysvinit-scripts conflicting with anything). rsyslog-rotate is part of the rsyslog package, and the problem relates to its integration with logrotate. As systemd starts rsyslog with '-iNONE' another approach could be to test for the PID file before HUP Testing for "running init is systemd" has a standard canned answer, which we can use. Regards, Matthew
Bug#1031854: orphan-sysvinit-scripts: should cope with defective rsyslog-rotate
Package: orphan-sysvinit-scripts Version: 0.13 Severity: important rsyslog-rotate should HUP rsyslog as appropriate for the installed init system. It doesn't, so orphan-sysvinit-scripts should work around this on sysvinit systems, without causing problems on systemd systems. The problem as a whole is RC, but it's not a fault in o-s-s; important seems the right severity for this bug. [I have a plan to do so, but wanted to record the issue in the BTS] Matthew -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages orphan-sysvinit-scripts depends on: ii ucf 3.0043+nmu1 orphan-sysvinit-scripts recommends no packages. orphan-sysvinit-scripts suggests no packages. -- no debconf information
Bug#1031399: rsyslog: Log rotation broken on non-systemd systems
Hi, I've provided a minimal patch; given this is a Debian-specific file and not something you're going to have to deal with upstream about, is there any chance of you applying it for bookworm, please? Log rotation isn't just about disk filling, other systems rely on its correct operation (hence my view this is RC) - I picked up on this when I realised that fail2ban had stopped working for ssh! It looks in /var/log/auth.log for entries, and that file was empty because of this failure. Thank you for your consideration, Matthew From 4f17fb24be2d1f34a772298258f2352d864e7a75 Mon Sep 17 00:00:00 2001 From: Matthew Vernon Date: Fri, 17 Feb 2023 06:39:43 + Subject: [PATCH] attempt to rotate on non-systemd systems (Closes: #1031399) On non-systemd systems, /etc/init.d/rsyslog is sometimes available; in those cases, use it (via invoke-rc.d) to do log rotation. --- debian/rsyslog-rotate | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/rsyslog-rotate b/debian/rsyslog-rotate index ef3954b1..143523ab 100755 --- a/debian/rsyslog-rotate +++ b/debian/rsyslog-rotate @@ -2,4 +2,6 @@ if [ -d /run/systemd/system ]; then systemctl kill -s HUP rsyslog.service +elif [ -x /etc/init.d/rsyslog ]; then +invoke-rc.d rsyslog rotate > /dev/null fi -- 2.39.1
Bug#1031360: rsyslog: SEGV on startup with truncated files in spool
Hi, On 16/02/2023 20:48, Michael Biebl wrote: The important bits were in 30-remote-syslog.conf indeed. With that the issue was reproducible and I therefor forwarded this to upstream. See https://github.com/rsyslog/rsyslog/issues/5085 Great, thank you. I didn't explicitly ask you, if I could attach your config files/spool files there, but I assumed as you attached it to the Debian bug tracker, that this is ok. If not, please let me know. Yes, that's fine. Regards, Matthew
Bug#1031399: rsyslog: Log rotation broken on non-systemd systems
On 16/02/2023 20:43, Michael Biebl wrote: I don't plan to re-add this (btw, this would break if orphan-sysvinit-scripts is not installed). A check for the presence of the init script would not be hard (and I'd happily write it and volunteer to fix any issues with it). I'll add a note to README.Debian to the logrotate section though, what users of non-default inits need to consider. Can I urge you to reconsider, please? Unless I'm missing something there isn't a way for this to work without /usr/lib/rsyslog/rsyslog-rotate doing the "rotate" of rsyslog, since that's what /etc/logrotate.d/rsyslog calls in its postrotate. The only way this can plausibly work is if rsyslog-rotate does the rotation, and that means there has to be _some_ "else" clause in rsyslog-rotate. I'm happy to offer patches to your spec, but I really do think the rsyslog package has to do a smidge of enabling work here. Regards, Matthew
Bug#1031360: rsyslog: SEGV on startup with truncated files in spool
Hi, Oops, rsyslog.conf would be useful as well, sorry! Here it is. Regards, Matthew# /etc/rsyslog.conf configuration file for rsyslog # # For more information install rsyslog-doc and see # /usr/share/doc/rsyslog-doc/html/configuration/index.html # MODULES # module(load="imuxsock") # provides support for local system logging module(load="imklog") # provides kernel logging support #module(load="immark") # provides --MARK-- message capability # provides UDP syslog reception #module(load="imudp") #input(type="imudp" port="514") # provides TCP syslog reception #module(load="imtcp") #input(type="imtcp" port="514") ### GLOBAL DIRECTIVES ### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Where to place spool and state files # $WorkDirectory /var/spool/rsyslog # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf ### RULES ### # # First some standard log files. Log by facility. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.*-/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err/var/log/mail.err # # Some "catch-all" log files. # *.=debug;\ auth,authpriv.none;\ mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg :omusrmsg:*
Bug#1031360: rsyslog: SEGV on startup with truncated files in spool
Hi, On 15/02/2023 18:27, Michael Biebl wrote: Am 15.02.23 um 18:16 schrieb Michael Biebl: Control: tags -1 + moreinfo Am 15.02.23 um 17:16 schrieb Matthew Vernon: I attach a tarball of the offending files in case they help. Can you share your rsyslog configuration and the output of running "rsyslogd -d -n" ? I can try to reproduce the issue once I have the full rsyslog config. Otherwise, a backtrace (with debug symbols) would be helpful as well. Here's a tarball of our rsyslog config (except the ssl keypair for obvious reasons :-) ) - it's the contents of /etc/rsyslog.d and /etc/rsyslog.lookup.d/ I've included everything for sake of completeness, but I suspect you really only need 30-remote-syslog.conf (and maybe 40-swift.conf) I hope this helps; the affected system is a production server where we have limited redundancy, so I had to get it back into service ASAP. Hopefully you can now reproduce this :) Thanks, Matthew wmf-rsyslog-conf.tar.bz2 Description: application/bzip
Bug#1031399: rsyslog: Log rotation broken on non-systemd systems
Package: rsyslog Version: 8.2212.0-1 Severity: serious Hi, When removing the systemv init scripts from rsyslog (which can be managed by orphan-sysvinit-scripts), the following was also removed from /usr/lib/rsyslog/rsyslog-rotate: else invoke-rc.d rsyslog rotate > /dev/null This means on non-systemd systems logrotate tries but fails to tell rsyslog to rotate its logs. Could you restore this, please? It will have no impact on systemd systems (since the else clause will never match there), and otherwise log rotation with rsyslog cannot work properly on non-systemd systems, which is quite a serious isssue. And I can't do anything about this in orphan-sysvinit-scripts. Thanks, Matthew -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages rsyslog depends on: ii libc6 2.36-8 ii libelogind0 [libsystemd0] 246.10-1debian1 ii libestr0 0.1.11-1 ii libfastjson4 0.99.9-2 ii liblognorm52.0.6-4 ii libuuid1 2.38.1-4 ii libzstd1 1.5.2+dfsg2-3 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages rsyslog recommends: ii logrotate 3.21.0-1 Versions of packages rsyslog suggests: pn rsyslog-doc pn rsyslog-gssapi pn rsyslog-mongodb pn rsyslog-mysql | rsyslog-pgsql pn rsyslog-openssl | rsyslog-gnutls pn rsyslog-relp -- Configuration Files: /etc/rsyslog.conf changed [not included] -- no debconf information
Bug#1031189: libogre-dev: Does not automatically derive plugin path
Sorry for wasting your time, I think I was wrong to raise this bug and it can be closed. I see that /usr/lib/x86_64-linux-gnu/OGRE/cmake/OGREConfig.cmake defines OGRE_PLUGIN_DIR, and that this path contains a plugins.cfg file that includes the correct PluginFolder filepath. Therefore, no magic is required - I simply needed to pass this variable to my application. Thanks again for maintaining this package - and thanks also Andreas for moving on my report to the correct list, Matthew
Bug#1031189: libogre-dev: Does not automatically derive plugin path
Package: libogre-dev
Version: libogre-1.12-dev
Severity: normal
Dear Maintainer,
libogre-1.12-dev installs Ogre plugins to /usr/lib/x86_64-linux-gnu/OGRE -
however, by default, Ogre is not searching in this directory when loading
plugins at run time.
matthew@matthew-laptop:~$ ls
/usr/lib/x86_64-linux-gnu/OGRE/RenderSystem_GL.so.1.12.10
/usr/lib/x86_64-linux-gnu/OGRE/RenderSystem_GL.so.1.12.10
When I try and load RenderSystem_GL using:
root.getRenderSystemByName("OpenGL Rendering Subsystem");
I see that Ogre searches the following locations:
Loading library RenderSystem_GL.so.1.12.10
8615: find library=RenderSystem_GL.so.1.12.10 [0]; searching
8615: search cache=/etc/ld.so.cache
8615: search
path=/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib
(system search path)
8615: trying
file=/lib/x86_64-linux-gnu/tls/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying
file=/lib/x86_64-linux-gnu/tls/haswell/RenderSystem_GL.so.1.12.10
8615: trying
file=/lib/x86_64-linux-gnu/tls/x86_64/RenderSystem_GL.so.1.12.10
8615: trying
file=/lib/x86_64-linux-gnu/tls/RenderSystem_GL.so.1.12.10
8615: trying
file=/lib/x86_64-linux-gnu/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying
file=/lib/x86_64-linux-gnu/haswell/RenderSystem_GL.so.1.12.10
8615: trying
file=/lib/x86_64-linux-gnu/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/x86_64-linux-gnu/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/tls/haswell/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/tls/x86_64/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/tls/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/haswell/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/x86_64/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/x86_64-linux-gnu/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/tls/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/tls/haswell/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/tls/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/tls/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/haswell/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/lib/RenderSystem_GL.so.1.12.10
8615: trying
file=/usr/lib/tls/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/usr/lib/tls/haswell/RenderSystem_GL.so.1.12.10
8615: trying file=/usr/lib/tls/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/usr/lib/tls/RenderSystem_GL.so.1.12.10
8615: trying file=/usr/lib/haswell/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/usr/lib/haswell/RenderSystem_GL.so.1.12.10
8615: trying file=/usr/lib/x86_64/RenderSystem_GL.so.1.12.10
8615: trying file=/usr/lib/RenderSystem_GL.so.1.12.10
8615:
But cannot find the library in any of these paths, and throws the following
exception:
C++ exception with description "InternalErrorException: Could not load dynamic
library RenderSystem_GL. System Error: RenderSystem_GL.so.1.12.10: cannot open
shared object file: No such file or directory in DynLib::load at
./OgreMain/src/OgreDynLib.cpp (line 113)" thrown in the test body.
I can work around this by adding:
PluginFolder=/usr/lib/x86_64-linux-gnu/OGRE
to the top of my plugins.cfg file. But, I was wondering if it would be possible
for the package to allow Ogre to derive the correct search path automatically -
perhaps using rpath?
Thanks for maintaining this package.
Matthew
-- System Information:
Debian Release: 11.6
APT pr
Bug#1018023: Update on this bug?
Hi, Do you have plans to fix this before the bookworm freeze, please? I think netbsd at least have patched eterm to work with the newer imlib; at least per the comment here https://github.com/mej/Eterm/issues/4 That linked to http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/eterm/patches/ Which has a couple of patches that seem like they'd do the trick... Thanks, Matthew
