Bug#1061421: Fails to start after an upgrade
Quack, On 2024-05-08 09:40, Marc Dequènes wrote: Not sure this is the same problem but I would say it's worth a try. I'll prepare the package and let you know how it goes. I packaged and uploaded 0.5.0 and this bug is fixed for me now, but I'd like to hear from you all before closing this bug. I'm still not sure 0.5.0 fixes this bug and I do not have time to explore all possibilities. As Peter found in #1065506 building with newer wayland and smithay versions can cause problems because there's important changes in newer versions and that may be the real source of this problem. Until upstream works on bumping the deps they are now locked. It's annoying to keep multiple versions around but there's no way around it at the moment. I'm using greetd 0.10.0 as upstream bumped the requirement for the greetd_ipc component. I don't think that's necessary to have such combination according to what changed in 0.10 and I left the link between both packages loose as before. Tell me if you encounter any problem. Regards. \_o< -- Marc Dequènes
Bug#1061421: Fails to start after an upgrade
Quack, On 2024-04-22 00:44, Jeremy Bícha wrote: There have been a huge amount of changes, but most of those changes were in Unstable and haven't reached Testing yet. I can confirm the problem is still there in latest unstable. Marc, there is a fix for sway 1.9 in wlgreet 0.5. Do you want to try if that improves anything here? Not sure this is the same problem but I would say it's worth a try. I'll prepare the package and let you know how it goes. Regards. \_o< -- Marc Dequènes
Bug#1064480: aardvark-dns - upcoming rust-nix update.
Quack, On 2024-02-23 07:59, Peter Green wrote: To build with this new version of nix, aardvark-dns needs a small patch taken from upstream. A debdiff is attached, if I get no response I will likely NMU this once the new version of rust-nix is in unstable. Thanks for letting me know. The debdiff looks good. I do not have a proper Internet connexion in my new Pond yet so I'd gladly let you upload it :-). Thanks a lot. \_o< -- Marc Dequènes
Bug#1063424: nmu: wlgreet_0.4.1-3
Quack, On 2024-02-08 15:50, Arto Jantunen wrote: This is needed to fix #1061421 (crash with recent sway versions). This is caused by the same underlying issue as #1061563 in alacritty, it was already fixed via binNMU there. Thanks a lot. I'm in the middle of moving to a new Pond and lacked time to debug more, so this is really helpful. Regards. \_o< -- Marc Dequènes
Bug#1063477: libruby3.1 contains bundler 2.3.7 with a very annoying bug and needs to be updated
Package: libruby3.1 Version: 3.1.2-7 Severity: normal X-Debbugs-Cc: yellowrubberd...@cock.li Dear Maintainer, A half of Ruby projects can't be run with bundler 2.3.7 due to this bug: https://github.com/rubygems/rubygems/issues/5351 For the reason I don't understand a default debian system uses the old bundler from this libruby3.1 package instaead of bundler 2.3.15 from ruby-bundler. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-15-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libruby3.1 depends on: ii libc6 2.36-9+deb12u4 ii libcrypt1 1:4.4.33-2 ii libedit2 3.1-20221030-2 ii libffi83.4.4-1 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libncurses66.4-4 ii libruby2.7 [ruby-webrick] 2.7.4-1+deb11u1 ii libssl33.0.11-1~deb12u2 ii libtinfo6 6.4-4 ii libyaml-0-20.2.5-1 ii rake 13.0.6-3 ii ruby-net-telnet0.2.0-1 ii ruby-sdbm 1.0.0-5+b1 ii ruby-webrick 1.8.1-1 ii ruby-xmlrpc0.3.2-2 ii zlib1g 1:1.2.13.dfsg-1 libruby3.1 recommends no packages. libruby3.1 suggests no packages. -- no debconf information
Bug#1061421: Fails to start after an upgrade
Control: tag -1 +help Quack, On 2024-01-24 19:04, Arto Jantunen wrote: After a semi-recent upgrade (I'm not sure which one, as I don't reboot or restart my session after each one) of testing wlgreet no longer starts. Here is what I get when trying to start it under a manually launched sway session: Thanks for the report. I stumbled onto the same problem but so far was not able to identify what's going on. Rebuilding the package does not help. I guess it's related to libraries that are loaded dynamically, possibly mesa, but it does not seem like an ABI breakage. I'll try to dig deeper but l’m open to suggestion. Regards. \_o< -- Marc Dequènes
Bug#944469: Using bash-completion with python-argcomplete
Quack, On 2023-11-04 23:22, Stefano Rivera wrote: I updated the package to put a thin loading shim into /etc/bash_completion.d. That should be safe to have as a conffile. I first went down the road of a symlink, but I think that could be problematic if a package is left in the conffiles state. Thanks for digging in to it and providing a fix, as well as a version bump too along the way :-). I did not test it yet but that looks solid. Go ahead and upload when you're ready, or I will when I have time. Regards. \_o< -- Marc Dequènes
Bug#1050769: dh-cargo: should provide a build() method
Quack, Sorry for the lag, I really lacked time and energy recently but I'll try to upload a fix soon. On 2023-10-07 04:09, Jeremy Bícha wrote: No, greetd needs to build itself correctly regardless of whether there are helper functions available. You're right and I did not realize nocheck would be used for real in this package. I never saw this as a perfect solution but until debcargo implements what's needed that seemed fine. https://salsa.debian.org/debian/greetd/-/merge_requests/4 It looks fine but that's precisely what I wanted to avoid: I do not want to maintain the build steps and have to update the calls and flags when cargo or any other piece of tooling changes. Maybe that won't change often but that's still silly to implement that in each and every leaf package and as a consequence there's no unified policy. Unfortunately I do not have the bandwidth to propose debcargo changes. So I guess I'll apply the patch you kindly provided but I'm thinking about handing over the maintainership of wlgreet and greetd to people who really have time to do it properly, or… maybe comaint. Anyway, thanks for the report and patch everyone. \_o< -- Marc Dequènes
Bug#1039873: pam-auth-update --disable does not work
Quack, Sorry for the lag, I'm deep in Bookworm upgrades :-). On 2023-06-30 02:03, Sam Hartman wrote: I just tried: * pam-auth-update --enable mkhomedir * confirm pam_mkhomedir is in the config p * pam-auth-update --disable mkhomedir * Confirm that it is not in the config. Indeed it works… for mkhomedir, but still not for sss. Also the fact that used interactively it does not remember my setting from the command line is not right. Let's suppose I borked the config, then --remove which really works and reset the config clean (at least for the pam_sss lines), then --enable followed by --remove should work. I could reassign to libpam-sss but I did not see anything weird in /usr/share/pam-configs/sss, so I can only guess there's a problem with the matching when removing the lines. I'll try to have a deeper look when I'm clear of migrations. \_o< -- Marc Dequènes
Bug#1040708: Acknowledgement (Wrong database scheme for postgresql)
I forgot to say it can be reproduced with a fresh install of mailman3-full. -- Marc Dequènes
Bug#1040747: dwz: makes wlgreet FTBFS with "Couldn't find DIE"
Package: dwz Version: 0.15-1 Quack, I've now disabled dh_dwz but the original build log can be found here: https://salsa.debian.org/debian/wlgreet/-/jobs/4401335 The package is awaiting NEW but sources are on Salsa if you wish to experiment. I honestly have no idea how dwz works so I cannot help with the code but tell me if you need me to make some tests. Regards. \_o< -- Marc Dequènes
Bug#1040708: Wrong database scheme for postgresql
Package: mailman3 Version: 3.3.8-1 Quack, The generated configuration in /etc/mailman3/mailman.cfg contains a database URL with the postgres:// scheme but this has long been deprecated in SQLAlchemy and needs to be replaced with postgresql://. The service refused to start without this change after migrating to Bookworm. Regards. \_o< -- Marc Dequènes
Bug#1032289: libdiplay-info: Keep out of the Bookworm release
Quack, On 2023-07-08 01:30, Jeremy Bícha wrote: Could you upload the version from Experimental to Unstable? I just got back Pond and checked if there was a new version first; no luck with that but I uploaded the version in experimental in unstable and it just got ACCEPTED, enjoy. \_o< -- Marc Dequènes
Bug#1040331: postfix-mta-sts-resolver: redis support broken
Package: postfix-mta-sts-resolver
Version: 1.1.2-1.1
Severity: important
Quack,
I upgraded a server to Bookworm and the service crashed with:
2023-07-04 15:05:43 INFO MAIN: Eventloop started.
Traceback (most recent call last):
File "/usr/bin/mta-sts-daemon", line 33, in
sys.exit(load_entry_point('postfix-mta-sts-resolver==1.1.2',
'console_scripts', 'mta-sts-daemon')())
^^
File
"/usr/lib/python3/dist-packages/postfix_mta_sts_resolver/daemon.py",
line 123, in main
evloop.run_until_complete(amain(cfg, evloop))
File "uvloop/loop.pyx", line 1517, in
uvloop.loop.Loop.run_until_complete
File
"/usr/lib/python3/dist-packages/postfix_mta_sts_resolver/daemon.py",
line 65, in amain
await cache.setup()
File
"/usr/lib/python3/dist-packages/postfix_mta_sts_resolver/redis_cache.py",
line 40, in setup
self._pool = aioredis.from_url(url, **opts)
^
AttributeError: module 'aioredis' has no attribute 'from_url'
This is due to `from_url` only being introduced in python3-aioredis 2.0
that is not in Debian at the moment (thus no backport to save the day).
As a side note the 'address' parameter was silently renamed in upstream
commit 2ba659c.
Moreover the trace does not appear in the systemd service log and you
need to call the binary yourself with the right user to get any useful
information, this is not very handy. I'm not sure how to fix that
though.
I have pushed branch `aioredis_before_2.0.0_fix` on Salsa that fixes the
problem, could you have a look please?
I would suggest to create a branch for bookworm to work on this fix.
Also the changelog change in 1.1.2-1.1 could be added even if
retroactively.
Regards.
\_o<
--
Marc Dequènes
Bug#1039873: pam-auth-update --disable does not work
Package: libpam-runtime Severity: normal Version: 1.5.2-6 Quack, Thanks for adding the feature in #1004000 but it unfortunately does not work. I don't recall if I tested the feature extensively but I updated my Ansible rules and it is ineffective. After switching a machine to bookworm I still get the module I want disabled around (it is reenabled during upgrade) and that breaks authentication. I then started to check manually: # grep sss /etc/pam.d/* /etc/pam.d/common-account:account [default=bad success=ok user_unknown=ignore] pam_sss.so /etc/pam.d/common-auth:auth [success=2 default=ignore] pam_sss.so use_first_pass /etc/pam.d/common-password:password sufficient pam_sss.so use_authtok /etc/pam.d/common-session:session optional pam_sss.so # pam-auth-update --disable sss => same result # pam-auth-update --force --disable sss => same result If I use pam-auth-update interactively and uncheck sss then it works. I then used `pam-auth-update --enable sss` and sss reappeared in the config and tried again --disable but to no avail. Could you please have a look? Regards. \_o< -- Marc Dequènes
Bug#1035326: greetd: Refers to nonexistent wlgreet package
Quack, On 2023-05-01 07:11, Marie Janssen wrote: The greetd package suggests: wlgreet but it is not available, causing the confusing situation where it's recommended (and seems likely to be preferred, given the lightdm situation that caused greetd to be added) but not available. I'd recommend removing it from Suggests: until #1010248 is resolved. Indeed it's confusing. wlgreet packaging is taking more time than expected but should not be too far from completion. Now it's only a Suggests and not a Recommends, so it's not going to cause any harm during installation. As for the release this is way too late to change the recommendation as we're deep in the freeze and this is not severe enough for an exception. As for unstable it should not deviate from the release target so as not to block last minute fixes, therefore I'll hopefully get wlgreet finished soon and it would be solved. If I hit problems then I'll consider your suggestion. Thanks for report. \_o< -- Marc Dequènes
Bug#1032914: phog: ships /etc/pam.d/greetd
Quack Arnaud, greetd was unblocked today. Thanks for your help :-). \_o< -- Marc Dequènes
Bug#1033966: unblock: greetd/0.9.0-3
Package: release.debian.org Control: affects -1 + src:greetd X-Debbugs-Cc: gre...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package greetd. [ Reason ] This is related to #1032914. I coordinated with the phog package maintainer to fix the situation. [ Impact ] PAM configuration conflicts with phog's embedded version (in previous version). [ Tests ] There are no upstream tests that cover this code. I have no idea how to make autopkgtests for interactive graphical programs yet, so none either. I have manually tested it on my system, the phog maintainer too, and the package has been in unstable for some time without complaint. [ Risks ] None I can see. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing [ Other info ] Thanks for all the hard work. unblock greetd/0.9.0-3 \_o< -- Marc Dequènesdiff -Nru greetd-0.9.0/debian/changelog greetd-0.9.0/debian/changelog --- greetd-0.9.0/debian/changelog 2023-02-09 00:38:57.0 +0900 +++ greetd-0.9.0/debian/changelog 2023-03-31 12:12:29.0 +0900 @@ -1,3 +1,29 @@ +greetd (0.9.0-3) unstable; urgency=medium + + [ Arnaud Ferraris ] + * Update PAM configuration(s) +Except for the gnome-keyring bits, all items currently set in the +`greetd` PAM config are already part of the `login` config. Including +the latter makes the `greetd` config simpler. +This commit also calls the PAM modules needed for unlocking the KDE +wallet as well, and adds the `greetd-greeter` config (simply including +`login` as the greeter itself doesn't need to deal with keyrings). +Finally, switch to using debhelper for installing the configs instead of +handling those manually. + * Add Breaks/Replaces relationships on older `phog` +`phog` used to ship the `greetd` and `greetd-greeter` PAM configs, +leading to conflicts with the latest version of the `greetd` package. +This commit ensures we avoid this conflict and maintain a clean +upgrade path for both those packages. + + -- Marc Dequènes (Duck) Fri, 31 Mar 2023 12:12:29 +0900 + +greetd (0.9.0-2) unstable; urgency=medium + + * Provide PAM configuration (Closes: #1032786). + + -- Marc Dequènes (Duck) Mon, 13 Mar 2023 02:41:02 +0900 + greetd (0.9.0-1) unstable; urgency=medium * NUR: diff -Nru greetd-0.9.0/debian/control greetd-0.9.0/debian/control --- greetd-0.9.0/debian/control 2023-02-09 00:38:57.0 +0900 +++ greetd-0.9.0/debian/control 2023-03-31 12:12:29.0 +0900 @@ -35,7 +35,8 @@ adduser Provides: x-display-manager Suggests: wlgreet +Breaks: phog (<< 0.1.3-2) +Replaces: phog (<< 0.1.3-2) Description: minimal Wayland login manager greetd is a minimal and flexible login manager daemon that makes no assumptions about what you want to launch. - diff -Nru greetd-0.9.0/debian/greetd.greetd-greeter.pam greetd-0.9.0/debian/greetd.greetd-greeter.pam --- greetd-0.9.0/debian/greetd.greetd-greeter.pam 1970-01-01 09:00:00.0 +0900 +++ greetd-0.9.0/debian/greetd.greetd-greeter.pam 2023-03-31 12:12:29.0 +0900 @@ -0,0 +1,2 @@ +#%PAM-1.0 +@include login diff -Nru greetd-0.9.0/debian/greetd.greetd.pam greetd-0.9.0/debian/greetd.greetd.pam --- greetd-0.9.0/debian/greetd.greetd.pam 1970-01-01 09:00:00.0 +0900 +++ greetd-0.9.0/debian/greetd.greetd.pam 2023-03-31 12:12:29.0 +0900 @@ -0,0 +1,8 @@ +#%PAM-1.0 +@include login + +-authoptionalpam_gnome_keyring.so +-authoptionalpam_kwallet5.so + +-session optionalpam_gnome_keyring.so auto_start +-session optionalpam_kwallet5.so auto_start diff -Nru greetd-0.9.0/debian/rules greetd-0.9.0/debian/rules --- greetd-0.9.0/debian/rules 2023-02-09 00:38:57.0 +0900 +++ greetd-0.9.0/debian/rules 2023-03-31 12:12:29.0 +0900 @@ -30,10 +30,13 @@ # bad perms chmod a-x debian/greetd/lib/systemd/system/greetd.service +override_dh_installpam: + dh_installpam --name=greetd + dh_installpam --name=greetd-greeter + override_dh_installsystemd: dh_installsystemd --no-stop-on-upgrade --no-start execute_after_dh_auto_clean: make -C man clean rm -f debian/cargo-checksum.json -
Bug#1032914: phog: ships /etc/pam.d/greetd
Quack, On 2023-03-24 18:24, Arnaud Ferraris wrote: Well yes, it was only supposed to be transitional waiting for https://lists.sr.ht/~kennylevinsen/greetd/patches/36264 to land upstream, but I went a bit too optimistic on that one, my bad... That's fine. The greeter PAM config drops the gnome-keyring/kwallet bits in order to be a bit lighter at runtime (those lines cause at least "gnome-keyring-daemon" to be started for user "_greetd", which is basically useless as it's a system user with no actual use of a keyring). Therefore I feel it's best to keep both config separate, but I'd be fine with a single config if you prefer it that way. Ok, makes sense, I was not aware it spawned anything. Thanks for the comments, I'm attaching the updated patches. Thanks for your work. I just merged it and will be uploading shortly. Regards. \_o< -- Marc Dequènes
Bug#1032914: phog: ships /etc/pam.d/greetd
Quack, On 2023-03-21 18:49, Arnaud Ferraris wrote: @duck, any comment on the above? Thanks for the contribution. Honestly when I read the title I really wondered how phog could have ended-up shipping this file. I forgot it initially, was asked about it and added it quickly, so it's not like I would have rejected the idea. Anyway, back to the patch itself. First I wonder if it's useful to ship the second PAM config since in the code (greetd/src/server.rs#211) it simply use the base greetd PAM configuration as a fallback; this is not a blocker though. Then I would prefer if the changelog entries were shipped with the corresponding changes and not in a lump afterwards. Also the "debian:" and "d/*:" prefixes are not the style I use. Maybe I'm missing why some people still use it but with the VCS taking care of remembering which files have been changed I don't feel the need to add this anymore and it's not very non-DD friendly. I like your comments to clearly explain the rationale. Regards. \_o< -- Marc Dequènes
Bug#1032289: Keep out of the Bookworm release
Source: libdisplay-info Severity: serious The library is new and just starting to be stable, with no rdepends yet, so even if the binary is useful to get info I'm not sure it's worth maintaining a full release cycle. \_o< -- Marc Dequènes
Bug#1030047: ruby-sanitize: CVE-2023-23627
Quack Salvatore, Thanks for the patch, it looks good. I'm in the Ruby team but not involved in this particular package but I think we can let your NMU flow. It's causing havoc on other packages so the sooner the better :-). Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, I just packaged DXVK 2.0 which brings lots of improvements. It is the first time since I took over that the requirements were bumped and the bar is high: Wine 7.1 and Mesa3d 22.0 (minimum version, not recommended): https://github.com/doitsujin/dxvk/wiki/Driver-support With the current lag of the Wine packaging it is not sufficient to use wine-stable at the moment. I'm not closing this bug but I really think that if someone really wants DXVK with stable then a dxvk-stable package would be needed. As stated before I'm not interested in maintaining such package but if someone would step up then we could sync our packages and collaborate. Regards. \_o< -- Marc Dequènes
Bug#975475: package takes much more space
Quack, Alexis, thanks a lot for looking into it. I just uploaded a package that seem to work fine with the debug symbols loading using winedbg+gdb as you described. And indeed it's taking way less space :-). Regards. \_o< -- Marc Dequènes
Bug#1026085: O: cdbs -- common build system for Debian packages
Quack, On 2022-12-14 23:00, Bastian Germann wrote: I am orphaning cdbs. @foka @js @duck Would you please move the cdbs repository to salsa's debian namespace? DH made so much progress that we all left :-). Jonas needed it for some packages and maintained it as long as he could. We did discuss the situation a few years back but no real plan/announcement followed unfortunately. I moved the repo to the Debian namespace. I also archived the cdbs-doc repo; the package is not build anymore anyway. The gnulib and licensecheck packages already have new git homes. I archives their repo. I suggest to create a lintian warning tag for cdbs-using packages so that they know that their build system is no longer developed. That's a good idea. I'll try to work on this. \_o< -- Marc Dequènes
Bug#1025872: installing greetd immediately reboots and prevents any logins
Quack, On 2022-12-11 09:20, Johannes Schauer Marin Rodrigues wrote: 1. do not start the greetd service by default installing a package should not result into logging out the currently active user I only tested greetd in the console after having started my previous login manager and did not hit this problem but that's indeed an unpleasant behavior. I had a quick look at lightdm and gdm3 and I don't see anything preventing them from doing the same thing. Not starting is an option but I'd like to look around a little bit more before making a decision. 2. provide a sensible default. Using $SHELL makes no sense when the default shell of the user running greetd is /usr/sbin/nologin. Maybe replace $SHELL with /bin/bash? I tested agreety but did not check it again before the upload. I'll try it with dash first, maybe we do not need a dependency on bash. Thanks for the report, I hope to have this sorted out soon. Regards. \_o< -- Marc Dequènes
Bug#1025744: greetd - FTBFS with new version of rust-nix.
Control: tags -1 + pending Quack, On 2022-12-08 22:21, Peter Green wrote: I have updated rust-nix in experimental, and intend to do so in unstable soon, the code in your package builds fine with the new version, but the Cargo dependencies don't allow it to be used. The attached patch updates the Debian and Cargo dependencies in your package to be consistent with each other. Thanks for the report and patch. I have never tested with 0.24 so I chose to enforce 0.25 instead. I pushed the changes on Salsa and I intend to upload soon but I have other fixes pending that should land soon. Regards. \_o< -- Marc Dequènes
Bug#1023982: greetd should use alternatives system to manage display-manager.service alias
Control: tag -1 +help Quack, On 2022-11-13 22:58, Taavi Väänänen wrote: greetd service specifies an alias (display-manager.service). That alias should instead be managed via the alternatives system that other display manager packages are using to make it possible to switch between installed display managers. That would be nice indeed. I looked at lightdm and gdm3 for example and I don't get how that's supposed to work. lightdm brings a service file with the same Alias. Both manage the /etc/systemd/system/display-manager.service symlink in their postinst, similarly, but lightdm does not handle all possible errors. None manages it using the alternative system (debian/gdm3.alternatives is about PAM options). So I think before doing any change we need to have all these packages agree on some configuration and snippet to do that properly, and documented. Regards. \_o< -- Marc Dequènes
Bug#1023980: Vcs-* control fields do not point to the packaging repository
Quack, On 2022-11-13 22:51, Taavi Väänänen wrote: According to policy 5.6.26, the Vcs-* fields in d/control most point to the packaging repository, not to the upstream repository as currently done in src:greetd. Indeed, this is a silly mistake and I'll fix it soon. Regards. \_o< -- Marc Dequènes
Bug#1010248: ITP: wlgreet raw wayland greeter for greetd
Quack, On 2022-10-31 05:35, Johannes Schauer Marin Rodrigues wrote: greetd is packaged and even in testing already. Any status update on wlgreet? There's several layers of dependencies that needed packaging and going through NEW took a while. Now I'm dealing with owned-ttf-parser and after some requested changes I hit some potential licensing issues and I'm checking this with the ftpmasters. After that rusttype can be built and need to go through NEW. Then I can finally upload wlgreet. Sorry it's taking so much time. \_o< -- Marc Dequènes
Bug#1022830: apt ignores versioned provides if non-matching version is installed via another dep
Quack, On 2022-10-27 08:51, David Kalnischkies wrote: You are right that libruby3.0 which provides 3.1.9 is not enough to satisfy the build-dependency of redmine, but libruby3.1 is installed, too, and that certainly does satisfy ruby-csv (>= 3.2.0). It is therefore correct for apt to not install the real ruby-csv package as that dependency is already satisfied. Indeed, thank you for finding this out. You might or might not be able to workaround this with Build-Conflicts, but in the end libruby3.1 and ruby-csv should really agree on what they are providing at what version or not… hence reassigning to both. This is due to ruby-all-dev (needed by gem2deb) dragging all supported versions. As long as we build multiple versions in the same source package I do not see how we fix this. In the archall case then we may modify all the dep chain to only use the latest supported Ruby version but that won't solve the problem globally. I added the Ruby list to the discussion. Regards. \_o< -- Marc Dequènes
Bug#1022830: apt ignores versioned provides if non-matching version is installed via another dep
Package: apt Version: 2.5.3+b1 Severity: important Control: affects -1 redmine Quack, I had a weird FTBFS in #1022340 and it looks like the resolver is just skipping the versioned dep because another dep provides the same virtual package. Unfortunately it does not resolve the required version and should install the non-virtual package providing the right version (they are co-installable). More info in the referenced BR. I bumped the severity because I don't see any way to work around this. We certainly cannot drop the provides or that would break things. We also cannot change the content of the Ruby standard library. Maybe redmine does not need the new features in 3.2.0 but since they specifically bump the dep I would not bet on that. Could you have a look please? Regards. \_o< -- Marc Dequènes
Bug#1022340: redmine: FTBFS: Could not find gem 'csv (~> 3.2.0)' in cached gems or installed locally. The source contains the following gems matching 'csv': csv-3.1.9
Quack, Thanks for the report. When I first read the logs I could not fathom what was going on: we B-D on ruby-csv (>= 3.2.0) and it's not even installed! So it happens that libruby3.0 provides ruby-csv but it explicitly specify ruby-csv (= 3.1.9). I seems the resolver is confused by the fact libruby3.0 also has to be present to satisfy another dep. I'm going to open a BR to get some help. Regards. \_o< -- Marc Dequènes
Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups
Quack, First, Steinar, I had the same crash and you need to exclude 'inline-signing yes' if your zone uses 'allow-update' or 'update-policy'. A proper error message would have been welcome indeed. I was also struck by this breakage and my whole infra was down because I use unattended-upgrades + needrestart. This really has no place in a security updates but clearly upstream made a mistake. I would be in favor of a rollback to the previous version but maybe by the time it's already too late. Regards. \_o< -- Marc Dequènes
Bug#944469: Using bash-completion with python-argcomplete
Quack Gabriel, I salvaged python-argcomplete and I'm now looking at loading completions when the package is installed but that does not work as planned. Could you lend me a hand please? python-argcomplete ships with a script (activate-global-python-argcomplete) which installs completion in /etc/bash_completion.d/python-argcomplete. It works very well but does required a manual step and also leaves a file that users should not modify in /etc. I updated the package to use dh_bash-completion instead: the file is properly installed but completion does not work. I read on the wiki (https://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap) that you implemented dynamic load completion and I suspect this is the problem here (I could not read the details though as the link is broken). If bash-completion expects the config to be named after a command then it will not work as python-argcomplete needs to be enabled for every python command. Do I understand it well? Any idea how I could do this integration? Regards. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Quack, Thanks a lot for your feedback. On 2022-07-16 14:56, Johannes Schauer Marin Rodrigues wrote: Issue 1: your choice of _greetd lets my postinst fail because my NAME_REGEX in /etc/adduser.conf is "^[a-z][-a-z0-9_]*\$" This naming scheme is becoming quite common in Debian now. Since you do not have problem with _apt or _chrony etc, I wondered if there was any adduser magic option and indeed apt is using --force-badname. I'll add the option but please not chrony, and probably other packages, do not necessarily use it and you'll probably have to make an exception (or fill bug reports). Issue 2: after installing it, I get a black screen printing "/bin/sh: 1: exec: agreety: not found" -- maybe this is because the user "greeter" doesn't have /usr/sbin/ in their PATH? I did not have time to test agreety and sway is in the path, but I checked and agreety does not work when run as non-root (not sure how useful that would be anyway) so I'm in favour of changing the default config to use the absolute path. Did you try this solution? Issue 3: /etc/greetd/config.toml says: I have not yet packaged wlgreet yet but that's coming; I added this config as example for the future. The config I'm using is: -- exec "wlgreet; swaymsg exit" bindsym Mod4+shift+e exec swaynag \ -t warning \ -m 'What do you want to do?' \ -b 'Poweroff' 'systemctl poweroff -i' \ -b 'Reboot' 'systemctl reboot -i' output * bg /etc/greetd/background fill include /etc/sway/config.d/* -- I guess I'll remove the background line, or maybe add another greetd-specific config directory for easy customization, I'm not sure yet. [some time later…] I pushed these changes, so hopefully that should help. I could not get any reply from the Debian Rust team unfortunately, so enquote cannot be uploaded yet. I need to package greetd_ipc in the team too and that should be enough for wlgreet I think. I'll keep you posted. Regards. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
On 2022-07-13 12:14, Johannes Schauer Marin Rodrigues wrote: Yes, that's what I did. The last command fails with: I recreated my workdir and realized the build directory is missing. I looked into it and you can recreate the missing pieces with (at the top dir): ./repackage.sh enquote Then the build worked. I'm not sure how you ended-up with this error because I cannot run the build from the top dir without the above. What extra step did you do? does using repackage.sh help? Sorry, I'm a total beginner with this toolchain, -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
On 2022-07-12 22:39, Johannes Schauer Marin Rodrigues wrote: you don't happen to have that package for arm64, do you? ;) Sorry, I do not have this arch around :-/. I'd like to build it myself no matter what I try running from that README I'm getting: debcargo failed: Couldn't find any crate matching enquote * Try `debcargo update` to update the crates.io index. First, setup the build tools: sudo apt-get install devscripts reprepro debootstrap sbuild dh-cargo schroot autopkgtest sudo sbuild-createchroot --include=eatmydata,ccache,gnupg,dh-cargo,cargo,lintian,perl-openssl-defaults \ --chroot-prefix debcargo-unstable unstable \ /srv/chroot/debcargo-unstable-amd64-sbuild http://deb.debian.org/debian (you need space for /srv/chroot, or wherever you wish to store the sbuild chroots, and also /var/lib/sbuild/) Then the build itself: git clone https://salsa.debian.org/duck/debcargo-conf.git cd debcargo-conf/build/ ./build.sh enquote Enjoy! -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Quack, On 2022-07-12 21:31, Johannes Schauer Marin Rodrigues wrote: the salsa link above is 404. If you share your enquote packaging (cannot find it on salsa) then I'll build and test greetd over here. Feel free to ping me for wlgreet testing as well. I've never packaged rust either so I doubt I'll be helpful with any rust-specific packaging stuff. Sorry, the fork was for some reason private but I just fixed it. The Rust team packaging practices are a tad special so here is the doc: https://salsa.debian.org/rust-team/debcargo-conf#id7 I can provide the deb somewhere if it's too much of a hassle. Regards. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Quack, Just to let you know, I now have a working greetd package: https://salsa.debian.org/debian/greetd The enquote build dependency is missing and I'm trying to get it added in the Rust Team: https://salsa.debian.org/duck/debcargo-conf/-/commit/c64a4a911fd1f04970d982fa53c2d8db2e9cd2b4 Once unblocked I'll upload them. I asked Rust folks to have a look since that's my first time packaging Rust; I might make some improvements but hopefully it should not delay things too much. agreety is included but I have not tested it as I'm using wlgreet (planned next), so if anyone could test it that would be helpful. Regards. \_o< -- Marc Dequènes
Bug#1014813: RM: ruby-deckar01-task-list -- ROM; Already packaged
Package: ftp.debian.org Quack, As pointed out by #1011414, ruby-deckar01-task-list was already packaged as ruby-task-list. This is a wrong and misleading naming that led me to loose time and energy and today to bother you to get it removed from the archive. Please help me forget about this quickly. \_o< -- Marc Dequènes
Bug#1011443: faker,ruby-faker: error when trying to install together
Quack, On 2022-07-06 06:18, Antonio Terceiro wrote: I just did that. Remember that you need to add Breaks:/Replaces: on your package for upgrades to work. Thanks Antonio. The initial report did not have this analysis and I did not did not have time to dig into it. Regards. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Quack, On 2022-07-04 14:11, Johannes Schauer Marin Rodrigues wrote: how is the packaging going? Are you still intending to package it? Is there already a git repository on salsa? Sorry, I've been delayed but I still intend to get this in :-). Regards. \_o< -- Marc Dequènes
Bug#1010941: python-argcomplete salvaging and possible team (re)join
Quack, On 2022-05-14 04:03, Yaroslav Halchenko wrote: I have just uploaded to --delayed 5 a workaround fix for #1010941 (FTBFS). The diff is attached Thanks for the workaround. I'm going to proceed with the salvaging soon now that the delay has passed. Please give me a few days without NMUs so I can bring it up to shape. would also be nice to add tags (may be original from Marco?) for prior upstream/debian releases. When I made my previous upload I did not realize everything was not in the VCS and unfortunately removed past changes. I plan to recreate history and add the tags but commits you made will have to be recreated on top of them and won't have the same id. Regards. \_o< -- Marc Dequènes
Bug#1010472: blhc: false positive NONVERBOSE BUILD when using Meson
Package: blhc Version: 0.13-2 Quack, When building dxvk I got this error: NONVERBOSE BUILD: C++ linker for the build machine: c++ ld.bfd 2.38 You can find an example here: https://salsa.debian.org/aviau/dxvk/-/jobs/2726822 This is due to Meson's discovery: C compiler for the host machine: x86_64-w64-mingw32-gcc (gcc 10.0.0 "x86_64-w64-mingw32-gcc (GCC) 10-posix 20220324") C linker for the host machine: x86_64-w64-mingw32-gcc ld.bfd 2.37 C++ compiler for the host machine: x86_64-w64-mingw32-g++ (gcc 10.0.0 "x86_64-w64-mingw32-g++ (GCC) 10-posix 20220324") C++ linker for the host machine: x86_64-w64-mingw32-g++ ld.bfd 2.37 C compiler for the build machine: ccache cc (gcc 11.3.0 "cc (Debian 11.3.0-1) 11.3.0") C linker for the build machine: cc ld.bfd 2.38 C++ compiler for the build machine: ccache c++ (gcc 11.3.0 "c++ (Debian 11.3.0-1) 11.3.0") C++ linker for the build machine: c++ ld.bfd 2.38 In case one don't use mingw-w64 then it might even match more lines. Regards. \_o< -- Marc Dequènes
Bug#1010269: crashes immediately at start
Control: severity -1 grave Control: affects -1 src:dxvk Quack, Not sure why the severity was not raised but as it is this package is unusable. It also breaks dxvk's autopkgtest which I needed before releasing fixes. There were changes in the nls files packaging in 6.9~repack-1 but no problem was spotted at the time so I guess new files might be needed and not included but I did not have time to check this supposition. Regards. \_o< -- Marc Dequènes
Bug#1010301: ITS: python-argcomplete
Source: python-argcomplete Version: 1.12.3-0.1 Severity: important X-Debbugs-CC: mnen...@debian.org Quack, This package has not received love from their maintained since 2017-01-24. It was NMUed multiple times since then without acknowledgement. The git repo is still on a guest account thus limiting contributions. In fact I myself made a mistake when NMUing because I did not realize all NMU contributions where not in the repo that I used to base my work. Also the package reproducibility build FTBFS and this was left unanswered for quite some time. This is strange because Marco Nenciarini seems to have had some concrete activity recently (barman and repmg uploads), but libapache2-mod-auth-pgsql was left with a RC bug since 2019-12-19. So maybe Marco is back and that would improve but since there has been no communication from them so far I'm proceeding with this ITS. Marco, if you're still interested in taking care of this package please answer. There are various options ranging from no time/not interested anymore to collaborative maintenance. In absence of reply I plan to bring the package into shape under the Python Team umbrella where hopefully having the backing of an experimented and caring group of folks that would ease maintenance and avoid such fate again. Regards. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Quack Jonas, I hope you're fine. On 2022-04-27 16:28, Jonas Smedegaard wrote: I'd be happy to co-maintain if you are interested in doing so outside of the Rust team - e.g. using the more loose debian collaboration section at salsa. I'm really new at Rust but really interested in learning more. The team process seems complicated but the static compilations with features is not something easy to handle and I have no idea how I would do better. Contrary to older languages most libraries are not packaged and I think that would be easier to work with the help of the team. I'd like to handle the initial packaging by myself to learn but if you want to later contribute through me without having to handle team interactions, you're welcome. Regards. \_o< -- Marc Dequènes
Bug#1010248: ITP: wlgreet --
Package: wnpp Severity: wishlist Owner: Marc Dequènes (Duck) X-Debbugs-Cc: debian-de...@lists.debian.org Control: block -1 with 1010247 * Package name: wlgreet Version : 0.3 Upstream Author : Kenny Levinsen * URL : https://git.sr.ht/~kennylevinsen/wlgreet * License : GPL-3 Programming Lang: Rust Description : raw wayland greeter for greetd Greeter to be run under sway or similar. Note that cage is currently not supported due to it lacking wlr-layer-shell-unstable support. This ITP is intended to be fulfilled once greetd is packaged, see #1010247. I was thinking about maintaining it into the Rust team but I have not joined yet. Regards. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Package: wnpp Severity: wishlist Owner: Marc Dequènes (Duck) X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: greetd Version : 0.8.0 Upstream Author : Kenny Levinsen * URL : https://git.sr.ht/~kennylevinsen/greetd * License : GPL-3 Programming Lang: Rust Description : minimal and flexible login manager daemon greetd makes no assumptions about what you want to launch. Use gtkgreet to launch sway if you want a fully graphical session, or use agreety to launch a shell if you want a drop-in replacement for agetty(8) and login(1). If you can run it from your shell in a TTY, greetd can start it. If it can be taught to speak a simple JSON-based IPC protocol, then it can be a greeter. Most login managers historically assumes X11. The most compatible one is probably GDM but unless you use GNOME you may wish to have a more lightweight solution. Lightdm worked well until recently despite not having Walyland support itself but it is now afflicted by this bug: https://github.com/swaywm/sway/issues/6655 The last release dates 2018 and there is no recent coding activity. I think greetd's architecture properly decouples authentication and the login UI and makes for a good replacement for Wayland users. I was thinking about maintaining it into the Rust team but I have not joined yet. Regards. \_o< -- Marc Dequènes
Bug#1009208: ruby-i18n breaks ruby-faker autopkgtest: FrozenError: can't modify frozen Array
Quack, Indeed, I failed to see it was assigned to both, thanks for the fix. \_o< -- Marc Dequènes
Bug#1009912: RM: ruby-clean-test, ruby-gli -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Quack, On behalf of the Ruby Team, please remove these two packages which are dead upstream: respectively archived since 2020 and upstream site vanished. ruby-gli is the only rdepends of ruby-clean-test and itself has none. If they are not broken yet they probably will with the new version of ruby-faker we plan to upload. They have 0 popcon. Regards. \_o< -- Marc Dequènes
Bug#1009891: hexchat locks up hard when connecting to bip server
Quack Seven, I'm involved with bip packaging and upstream and we wondered what version of bip you are using. Did you upgrade bip recently? We have yet no reason to think that it could be triggered by a bug in bip, just checking. Clearly hexchat should behave better anyway. Can you reproduce this problem by connecting directly to the IRC server? Regards. \_o< -- Marc Dequènes
Bug#988449: redmine: run the testsuite during the build
Quack, Thanks a lot for preparing all this. I have no idea why this was not integrated before. I see in the history the focus was on the autopkgtest and I myself continued on that path when I took over with Kanashiro-kun so I can only speculate the test suite was not great before. Anyway, currently redmine is all broken because we had to update Rails before being out of upstream support and Redmine authors really took their sweet time to support the new version but since yesterday this is solved. I prepared Redmine 5 and today finished integrating your work. I had to disable ~9 tests but it will not regress from this point on. One new dep is in NEW and I'll need to do more tests but it should be in unstable soon. Thanks again. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, On 2022-03-11 21:52, Adrian Bunk wrote: dxvk should have an RC bug documenting why it is not in testing, and this bug in dxvkshould be fixed by using the non-development version of wine. I agree documenting is nice but this is not my decision. It is unlikely that wine maintainers would change their mind and push -devel in a stable release but if that were to happen then this package would needlessly be blocked by this bug now. The fact that it does not work with wine-stable is another matter entirely. As for the use of wine-stable as stated previously I have no idea what are the consequences of building with an old version and using it with the -devel one. Creating a dxvk-stable would be safer but since I never use wine-stable I would not wish to maintain it. I do not have any knowledge of the DXVK or wine code and did not have time to look into it or ask upstream about it, but if you do then I'll be happy to hear about it (you seem to be sure that's the obvious solution so I guess you do). For testing migration of dxvk this does not make a difference, but it highlights that there is a bug in dxvk that needs fixing. This is a new feature of the package, thus "wishlist" severity. And I'm not going to skip over this BR just because the severity is not RC. Anyway, that does not change much but I find it very annoying when people play with severity without explaining why. I think mixing the not-in-stable and does-not-work-with_wine-stable questions is confusing. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Btw, Adrian could you clarify with you bumped the severity? wine-development was already blocked from entering Bullseye and that blocked dxvk as well, so no need to add a RC bug just for that. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Could you please test the changes in branch 'br982159' on Salsa and tell me if it works for you? Regards. \_o< -- Marc Dequènes
Bug#1005761: python3.10: problem with the switch to libedit
Source: python3.10 Version: 3.10.2-1 Severity: important Control: affects -1 src:python-cmd2 X-Debbugs-CC: Federico Ceratto Quack, I was working with python-cmd2's maintainer to get a newer version packaged in #1002463 and noticed Python is now using libedit, so I proposed a patch since libedit seems to work fine as well (in my use case). Unfortunately when suggesting upstream to also make the change they replied that libedit does not implement the `rl_completion_display_matches_hook` hook and that breaks various cmd2 features: https://github.com/python-cmd2/cmd2/issues/1186 I just found out #977732 and the reason for the switch but since libedit is not equivalent would you consider rolling this change back? Regards. \_o< -- Marc Dequènes
Bug#1001583: fish: Version info is empty
Control: severity -1 critical Control: tag -1 +patch Coin, Breaks unrelated software as well as python-argcomplete's build, maybe others, thus raising severity. I have created a merge request with a fix: https://salsa.debian.org/debian/fish/-/merge_requests/6 Regards. \_o< -- Marc Dequènes
Bug#977821: dxvk FTCBFS: build vs host confusion
Quack, Sorry for the lag and thanks for your explanation and patch. I have committed it and it will land in the next upload. Currently the Salsa check is broken due to #991384 so I cannot be sure it builds fine. As for the headers, `Multi-Arch` is already set to `foreign` for all three binary packages, is that ok? Regards. \_o< -- Marc Dequènes
Bug#1005326: no-code-sections triggered on non-ELF files
Package: lintian Version: 2.114.0 Quack, no-code-sections is triggered on dxvk, and also on wine, but these are not ELF files since it's targeted for Windows. Of course an override is possible but here there's an obvious way to avoid a false positive since readelf fails with "readelf: Error: Not an ELF file - it has the wrong magic bytes at the start", or maybe by using `objdump -a` or some other method to first check the archive format (I'm really not an expert in this area). Could you consider improving the check? Regards. \_o< -- Marc Dequènes
Bug#991384: libwine-development fails to install on arm*: head: cannot open '/usr/aarch64-w64-mingw32/lib/zlib*.dll' for reading: No such file or directory
Quack, Could you have a look at this bug please? I'm trying to fix cross-compilation problems on dxvk but cannot even get a test build to run because of this issue: https://salsa.debian.org/aviau/dxvk/-/jobs/2455425 Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Sorry for the late reply. You're right DXVK can now handle wine-stable version (5.0.3). I have not tested it but upstream claims 3.10 as the minimum version needed. That still won't let this package into testing though as it is built against libwine-development-dev that will never reach testing. Without making two separate packages I don't think that would work. Also, with the important gap between stable and devel versions I'm wondering how DXVK is going to perform. Again without another package built with libwine I don't see how we can be sure that's not gonna break. I personally stopped using the Debian packaged wine-development because they are unable to keep up with the release frequency (and also did not seem willing to accept me in their team to contribute) and I've been using the packages provided on winehq and that never broke so far. That is to say I may have overestimated the risk. I'm not really interested in creating another package for stable knowing I would never use it myself and thus would not be able to test it, but I'm ok to remove the restrictions on dxvk-setup. I'll schedule that for the next upload. Regards. \_o< -- Marc Dequènes
Bug#1004000: libpam-runtime: please add pam-auth-update --disable option
Package: libpam-runtime Version: 1.4.0-11 Severity: wishlist Quack, I use a weird configuration because I need sssd for caching and SSH keys in LDAP and nslcd for pam_authz_search with variable resolution and neither provide all the things. Because of this I disabled sssd for PAM in /etc/sssd/sssd.conf and that was working fine until sssd implemented service activation. I then used pam-auth-update to disable it and that was fine again for a time but this config keeps being reenabled regularly. I used: pam-auth-update --remove sss but it seems this is only intended for package maintainers to cleanup when uninstalling. Using pam-auth-update interactively confirmed the module was not disabled and I was able to make the change but I would like to automate that change (I use Ansible for my configuration). Could you please add a --disable option? Regards. \_o< -- Marc Dequènes
Bug#1002463: cmd2: please consider packaging 2.3.3
Package: src:cmd2 Version: 2.1.2-1 Severity: wishlist Quack, I needed a newer version and made a port for myself. The bump requires a small patch but is otherwise rather trivial. Here is the bug I opened upstream about the "not libedit" requirement, which is not true anymore with our version of Python 3.10 in unstable: https://github.com/python-cmd2/cmd2/issues/1186 Attached is the diff for the new version. Regards. \_o< -- Marc Dequènesdiff --git a/debian/changelog b/debian/changelog index 995dd2e..4e7c1c2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +cmd2 (2.3.3-1) UNRELEASED; urgency=medium + + * NUR. + * Add patch to allow using libedit. + + -- Marc Dequènes (Duck) Wed, 22 Dec 2021 20:36:25 +0900 + cmd2 (2.1.2-1) unstable; urgency=medium * New upstream release (Closes: #984798) diff --git a/debian/control b/debian/control index 17fd8c6..47ef611 100644 --- a/debian/control +++ b/debian/control @@ -7,7 +7,6 @@ Build-Depends-Indep: dh-python, python3-all, python3-attr, - python3-colorama, python3-contextlib2, python3-pyperclip, python3-pytest, diff --git a/debian/patches/py3.10_libedit.patch b/debian/patches/py3.10_libedit.patch new file mode 100644 index 000..29c54c8 --- /dev/null +++ b/debian/patches/py3.10_libedit.patch @@ -0,0 +1,11 @@ +--- a/cmd2/rl_utils.py b/cmd2/rl_utils.py +@@ -126,7 +126,7 @@ + + elif 'gnureadline' in sys.modules or 'readline' in sys.modules: + # We don't support libedit +-if 'libedit' not in readline.__doc__: ++if 'libedit' not in readline.__doc__ or True: + try: + # Load the readline lib so we can access members of it + import ctypes diff --git a/debian/patches/series b/debian/patches/series index 8d193a1..1390604 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1 +1,2 @@ 001-drop-setuptools_scm.patch +py3.10_libedit.patch
Bug#1000948: grub2: Could not make LUKS2 work
Source: grub2
Version: 2.04-20
Severity: normal
Quack,
My system originally was created as LUKS2 and then I found out GRUB did
not support it and converted it to LUKS1. That was a while ago but that
is to say it's already using PBKDF2 so it's easy to switch back and
forth.
I upgraded my system with the recent release and the signed packaged
came yesterday and now GRUB is properly displaying "2.06".
I had enabled GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub already. I
thus used the Debian installer rescue mode to convert with:
cryptsetup convert --type=luks2 /dev/nvme0n1p2
I then got into the root fs (via the rescue menu) and issued an
update-grub.
I rebooted and then was dropped into the GRUB shell.
I also added GRUB_PRELOAD_MODULES=luks2 just in case before switching to
LUKS2 but that did not help. For the record while debugging in the GRUB
shell I got:
grub> insmod cryptodisk
grub> insmod luks2
error: file `/boot/grub/x86_64-efi/luks2.mod' not found.
IIUC it would need to be added to debian/build-efi-images.
I also found out the new grub.cfg does not contain any cryptodisk or
luks* modules, so it seems grub-mkconfig is unable to generate a proper
configuration in this case. I'm adding the working and broken
configuration files as a reference.
My /etc/crypttab:
#
nvme0n1p2_crypt /dev/nvme0n1p2 none luks
Could you give me a hand?
Regards.
\_o<
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.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
--
Marc Dequènes#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
insmod luks2
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u ff654a895d9f47869f38dddc1e1f509b
set
root='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
abcc3b9a-9e49-493b-80f5-825eaec521a1
else
search --no-floppy --fs-uuid --set=root abcc3b9a-9e49-493b-80f5-825eaec521a1
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=C
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u ff654a895d9f47869f38dddc1e1f509b
set
root='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
abcc3b9a-9e49-493b-80f5-825eaec521a1
else
search --no-floppy --fs-uuid --set=root abcc3b9a-9e49-493b-80f5-825eaec521a1
fi
insmod png
if background_image /usr/share/desktop-base/spacefun-theme/grub/grub-16x9.png;
then
set color_normal=light-gray/black
set color_highlight=white/black
else
set
Bug#1000885: ansible: version in experimental is uninstallable
Package: ansible Version: 4.6.0-1 Severity: important Quack, Despite the fix in #995879 it is not installable: # apt install -t experimental ansible Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: ansible-core python3-resolvelib Suggested packages: cowsay sshpass Recommended packages: python3-kerberos python3-libcloud python3-winrm python3-xmltodict The following NEW packages will be installed: ansible-core python3-resolvelib The following packages will be upgraded: ansible 1 upgraded, 2 newly installed, 0 to remove and 177 not upgraded. Need to get 20.8 MB of archives. After this operation, 67.6 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://HTTPS///deb.debian.org/debian unstable/main amd64 python3-resolvelib all 0.8.1-1 [25.4 kB] Get:2 http://HTTPS///deb.debian.org/debian experimental/main amd64 ansible all 4.6.0-1 [19.6 MB] Get:3 http://HTTPS///deb.debian.org/debian unstable/main amd64 ansible-core all 2.12.0-1 [1153 kB] Fetched 20.8 MB in 5s (4339 kB/s) Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done apt-listchanges: Mailing root: apt-listchanges: news for Annael Selecting previously unselected package python3-resolvelib. (Reading database ... 553625 files and directories currently installed.) Preparing to unpack .../python3-resolvelib_0.8.1-1_all.deb ... Unpacking python3-resolvelib (0.8.1-1) ... Preparing to unpack .../ansible_4.6.0-1_all.deb ... Unpacking ansible (4.6.0-1) over (2.10.7+merged+base+2.10.8+dfsg-1) ... Selecting previously unselected package ansible-core. Preparing to unpack .../ansible-core_2.12.0-1_all.deb ... Unpacking ansible-core (2.12.0-1) ... Setting up python3-resolvelib (0.8.1-1) ... Setting up ansible-core (2.12.0-1) ... [Errno 2] No such file or directory: '/usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py'dpkg: error processing package ansible-core (--configure): installed ansible-core package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of ansible: ansible depends on ansible-core (>= 2.11.5-1~); however: Package ansible-core is not configured yet. dpkg: error processing package ansible (--configure): dependency problems - leaving unconfigured Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: ansible-core ansible needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) $ ls -l /usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py lrwxrwxrwx 1 root root 13 Nov 18 21:42 /usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py -> ../release.py But this file does not exist. I purged ansible and ansible-core, reinstalled and obtained the same result. In fact upgrading or installing after purge does not change anything. It seems this symlink is not owned by any package, is it generated??? I did not have time to dig deeper, hope that helps. And thank for the hard work, the split seems to be a real pain in the ass to handle. Regards. \_o< -- Marc Dequènes
Bug#931812: Driver does not work in Debian buster
Quack, Interestingly we used 8.046.00-1, with 4.19.0-17 until 2021-10-21 and it worked fine. Then we upgraded to bullseye and the package was upgraded to 8.048.03-3. After rebooting the host never came back until we were able to reach the sever and debug today. It turns out modprobe was not able to locate the module and as you can see here: https://paste.debian.net/1216568/ It says: Status: This module version was INACTIVE for this kernel. I had no idea a DKMS module could be installed, compiled properly but not enabled, that's really confusing. Anyway, we're now using the realtek driver included in the kernel along with firmware-realtek and it works fine. Hope that helps. \_o< -- Marc Dequènes
Bug#993994: vulkan-validationlayers: Requesting VK_LAYER_KHRONOS_validation crash with undefined symbol: _Z14GetEnvironmentB5cxx11PKc
Quack, There has been no response for almost a month and this breaks the sole usage of this package, therefore I just made an NMU. You can find my changes on Salsa: https://salsa.debian.org/xorg-team/vulkan/vulkan-validationlayers/-/merge_requests/1 Thanks Kienan for providing a link to the patch. Regards. \_o< -- Marc Dequènes
Bug#981396: lynis: Illegal number: SOLARIS_LOGHOST_LOCALHOST
Quack, On 2021-01-30 23:32, Nigel Horne wrote: This cronjob: /usr/sbin/lynis audit system --cronjob | mail u...@example.com Sends this e-mail: /usr/sbin/lynis: 430: [: Illegal number: SOLARIS_LOGHOST_LOCALHOST Sorry for the lag. It's and upstream bug fixed in 3.0.6 (https://github.com/CISOfy/lynis/commit/c8175cf74da87d44328cca2d30d0df2ae2eb9a24). I was going to package it but there's a little problem at the moment: https://github.com/CISOfy/lynis/issues/1211 Once it's fixed I'll upload it. Regards. \_o< -- Marc Dequènes
Bug#994807: [Pkg-sssd-devel] Bug#994807: sssd-common: capabilities restrictions break the service
Quack, On 2021-09-22 18:28, Timo Aaltonen wrote: But since the 'run sssd as a non-privileged user' -feature is still not used in Fedora either, best to make it run as root and change the file permissions to match. I guess it's not ready yet and following Fedora seems the best thing to do. I've pushed a new version to salsa, could you build and test that in your environment? The autopkgtest at least passes so the daemon should work (and didn't on the current version, which I didn't notice, boo). I built it and restarted, no problem. I removed sbus-monitor, restarted, and it was able to recreate it. Thanks for the quick fix :-). Regards. \_o< -- Marc Dequènes
Bug#994807: sssd-common: capabilities restrictions break the service
Package: sssd-common Version: 2.5.2-2 Severity: important Quack, This morning sssd got upgraded from 2.4.1-2 to 2.5.2-2 and I could not log in as user. I use sssd-ldap + sssd-dbus + sssd-tools (the rest is automatically installed). I tried to downgrade but that did not solve anything, that was weird. The service failed with: ● sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: activating (start) since Tue 2021-09-21 12:11:07 JST; 30ms ago Main PID: 3094 (sssd) Tasks: 1 (limit: 38361) Memory: 2.2M CPU: 14ms CGroup: /system.slice/sssd.service └─3094 /usr/sbin/sssd -i --logger=files Sep 21 12:11:07 Annael systemd[1]: Starting System Security Services Daemon... Sep 21 12:11:07 Annael sssd[3094]: Starting up Sep 21 12:11:07 Annael sssd[3094]: dbus[3094]: arguments to dbus_server_get_address() were incorrect, assertion "server != NULL" failed in file ../../../dbus/dbus-server.c line 835. Sep 21 12:11:07 Annael sssd[3094]: This is normally a bug in some application using the D-Bus library. Sep 21 12:11:07 Annael sssd[3094]: D-Bus not built with -rdynamic so unable to print a backtrace Then the daemon crashed because in src/sbus/server/sbus_server.c sbus_server_socket_listen() only logs the problem without stopping: Storage: /var/lib/systemd/coredump/core.sssd.0.b78fd458dc7e43a29506481bb2d20de3.3094.163219386700.zst Message: Process 3094 (sssd) of user 0 dumped core. Stack trace of thread 3094: #0 0x7f3ba7170e71 __GI_raise (libc.so.6 + 0x3ce71) #1 0x7f3ba715a536 __GI_abort (libc.so.6 + 0x26536) #2 0x7f3ba6c25d62 n/a (libdbus-1.so.3 + 0xed62) #3 0x7f3ba6c48b60 _dbus_warn_check_failed (libdbus-1.so.3 + 0x31b60) #4 0x7f3ba6c40592 dbus_server_get_address (libdbus-1.so.3 + 0x29592) #5 0x7f3ba73214ba sbus_server_create (libsss_sbus.so + 0x284ba) #6 0x7f3ba730e7b4 sbus_server_create_and_connect_send (libsss_sbus.so + 0x157b4) #7 0x560ec6eada62 n/a (sssd + 0x5a62) #8 0x7f3ba715be4a __libc_start_main (libc.so.6 + 0x27e4a) #9 0x560ec6eadbba n/a (sssd + 0x5bba) Anyway, dbus was started and now that I found a workaround (see below) I can say it works fine and that is not the problem. I tried various things to no avail and decide to put aside my config and purge/reinstall all *sss* packages. After putting back my config and starting again I got: # systemctl restart sssd Broadcast message from systemd-journald@Annael (Tue 2021-09-21 17:12:14 JST): sssd[11845]: Could not open file [/var/log/sssd/sssd.log]. Error: [13][Permission denied] Job for sssd.service failed because a fatal signal was delivered causing the control process to dump core. See "systemctl status sssd.service" and "journalctl -xe" for details. And more precisely in the journal: Sep 21 17:13:45 Annael sssd[11975]: Starting up Sep 21 17:13:45 Annael sssd[11975]: dbus[11975]: arguments to dbus_server_get_address() were incorrect, assertion "server != NULL" failed in file ../../../dbus/dbus-server.c line 840. Sep 21 17:13:45 Annael sssd[11975]: This is normally a bug in some application using the D-Bus library. Sep 21 17:13:45 Annael sssd[11975]: D-Bus not built with -rdynamic so unable to print a backtrace Sep 21 17:21:55 Annael systemd[1]: Starting System Security Services Daemon... Sep 21 17:21:55 Annael sssd[14233]: Could not open file [/var/log/sssd/sssd.log]. Error: [13][Permission denied] Sep 21 17:21:55 Annael sssd[14233]: Error opening log file, falling back to stderr Sep 21 17:21:55 Annael sssd[14233]: [sssd] [ldb] (0x0020): Unable to open tdb '/var/lib/sss/db/config.ldb': Permission denied Sep 21 17:21:55 Annael sssd[14233]: [sssd] [ldb] (0x0020): Failed to connect to '/var/lib/sss/db/config.ldb' with backend 'tdb': Unable to open tdb '/var/lib/sss/db/config.ldb': Permission denied Sep 21 17:21:55 Annael sssd[14233]: [sssd] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb] Sep 21 17:21:55 Annael sssd[14233]: [sssd] [confdb_setup] (0x0010): The confdb initialization failed [5]: Input/output error Sep 21 17:21:55 Annael sssd[14233]: [sssd] [load_configuration] (0x0010): Unable to setup ConfDB [5]: Input/output error Sep 21 17:21:55 Annael sssd[14233]: [sssd] [main] (0x0010): SSSD couldn't load the configuration database. Sep 21 17:21:55 Annael sssd[14233]: SSSD couldn't load the configuration database [5]: Input/output error. Sep 21 17:21:55 Annael systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION Sep 21 17:21:55 Annael systemd[1]: sssd.service: Failed with result 'exit-code'. After trying various solutions I found out that if I comment
Bug#994085: closed by Debian FTP Masters (reply to Dylan Aïssi ) (Bug#994085: fixed in wireplumber 0.4.2-5)
Quack, It works great, thank you. \_o< -- Marc Dequènes
Bug#994085: wireplumber: fails to start without SPA bluetooth plugin
Package: wireplumber Version: 0.4.2-4 Severity: important Quack, I just switch a working Pipewire installation from pipewire-media-session to wireplumber and since it is supposed to be a drop-in replacement I was expecting it to work without any tweaks. I use pipewire-pulse and pavucontrol told me no cards were detected. wpctl status also showe an empty list of devices. The service is properly enabled and tied to the start of pipewire but failed. It would be nice to get the error in the journal btw but I got it when starting the binary manually: W 19:06:06.279451 wp-device ../lib/wp/device.c:620:wp_spa_device_new_from_spa_factory: SPA handle 'api.bluez5.enum.dbus' could not be loaded; is it installed? C 19:06:06.279480 wplua (null):(null):(null): wplua_pushobject: assertion 'G_IS_OBJECT (object)' failed W 19:06:06.279504 wplua ../lib/wplua/wplua.c:49:_wplua_errhandler: [string "bluez.lua"]:132: attempt to call a nil value (method 'connect') stack traceback: [string "bluez.lua"]:132: in local 'chunk' [string "sandbox.lua"]:95: in function 'sandbox' Runtime error while loading 'bluez.lua' M 19:06:06.279580wireplumber ../src/main.c:299:on_disconnected: disconnected from pipewire After some research I found out libspa-0.2-bluetooth need to be installed. It would be nice if the lua script could just skip over scanning bluetooth devices entirely if missing in order to make this only a Recommends but at the moment I think it's really needed to ensure the package will work in all environments. Regards. \_o< -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireplumber depends on: ii init-system-helpers 1.60 ii libc6 2.32-2 ii libglib2.0-0 2.68.4-1 ii libpipewire-0.3-0 0.3.35-1 ii libwireplumber-0.4-0 0.4.2-4 ii pipewire 0.3.35-1 Versions of packages wireplumber recommends: ii pipewire-pulse 0.3.35-1 wireplumber suggests no packages. -- no debconf information -- Marc Dequènes
Bug#992835: ckb-next: cannot create new profile
Package: ckb-next Version: 0.4.3+dfsg.1-0.1 Severity: important Tags: upstream fixed-upstream Quack, Creating a new profile is not possible due to a crash. This is fixed in 0.4.4: https://github.com/ckb-next/ckb-next/releases/tag/v0.4.4 Could you please package it? Regards. \_o< -- Marc Dequènes
Bug#992385: x11-common: use of deprecated tempfile breaks login
On 2021-08-18 16:17, Timo Aaltonen wrote: What if you just do s/tempfile/mktemp? It works fine, thanks. -- Marc Dequènes
Bug#992385: x11-common: use of deprecated tempfile breaks login
Package: x11-common Version: 1:7.7+22 Severity: grave Quack, Since debianutils has dropped the deprecated `tempfile` in 5.0-1 /etc/X11/Xsession fails around the WRITE_TEST and this breaks graphical login completely. Commenting this section allowed me to log in. There is another call line 85 that needs to be changed too. Regards. \_o< -- Marc Dequènes
Bug#969206: Info received (redmine: Could not find gem 'rails (~> 5.2.2)' in any of the gem sources listed in your Gemfile)
Control: affects -1 redmine-plugin-custom-css Quack, I finished packaging 4.2.1 a few days ago and I can confirms this totally does not work. Upstream had piled on many patches and now targeting Rails 6.1. Unfortunately this is not over and 5.0 has many tasks assigned which are not done. \_o< -- Marc Dequènes
Bug#987331: ruby-mysql2: flaky autopkgtest
Version: 0.5.3-3 I forgot to close it in the changelog, sorry. -- Marc Dequènes
Bug#741450: iwlwifi: wifi failure to work after suspend with 7260AC
Quack, On 2021-04-25 06:36, Salvatore Bonaccorso wrote: Is this still reproducible on current kernels? I changed hardware last December and it's not the same chipset anymore thus I cannot tell, sorry. The new one is also using iwlwifi though: 00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30) and I have not experienced any problem with it so far, but due to covid-19 I'm not using WIFI very often… Regards. \_o< -- Marc Dequènes
Bug#987659: release-notes: redmine not available, please wait backports
Package: release-notes Quack, Sorry for the late request, I entirely forgot. I also hoped it would not be necessary in case 4.2 could work with a few patches but I just finished packaging it and that's not working. If not too late, here is the message I wish to convey: Redmine is unfortunately late migrating over to newer Rails version despite end of upstream support soon (currently only severe security fixes). In Debian we had to update Rails for other applications thus Redmine is not provided in bullseye. We are following upstream closely and will be releasing a version via backports as soon as it is released and we have working packages. Until then you may wait before upgrading, or use a VM or container running Buster to isolate this specific application. Regards. \_o< -- Marc Dequènes
Bug#981166: support origin pins based on path
Quack, Sorry for the lag. On 2021-01-27 21:01, Julian Andres Klode wrote: So effectively, what you are asking for is to allow origin to pin based on the path, not just the hostname, like we allow for apt_auth.conf. I need to way to securely restrict sources, so that a custom source for a handful of packages is not going to touch anything else on my system. From a security point of view that's not sufficient of course but I would like to avoid a project adding a custom build of some lib to workaround a problem or other such situation. Since o= is taken from the repo metadata it's clearly not a good fit, so I tried with the origin, and if I do not use acng that's working fine. Unless you could suggest anything else with the current features it would be nice to add path support. It could totally be another keyword, I can adapt to the syntax you prefer. It's possible to do this in 2.x since we have an extensible cache API with private pointers where we could store an extended origin, without breaking existing uses of origin. :-) Arguably we could also hack up a solution for acng's hack, but that feels like the wrong approach. I'm not sure how other caches handle the HTTPS case but yes clearly there's no reason to add dirty hacks. Regards. \_o< -- Marc Dequènes
Bug#985926: bind9: cannot create /run/named
Package: bind9 Version: 1:9.16.11-2~bpo10+1 Quack, I got these errors at startup: Mar 26 08:51:46 Orfeo named[14057]: couldn't mkdir '/run/named': Permission denied Mar 26 08:51:46 Orfeo named[14057]: generating session key for dynamic DNS Mar 26 08:51:46 Orfeo named[14057]: couldn't mkdir '/run/named': Permission denied Mar 26 08:51:46 Orfeo named[14057]: could not create /run/named/session.key Mar 26 08:51:46 Orfeo named[14057]: failed to generate session key for dynamic DNS: permission denied and apparmor is unhappy: type=AVC msg=audit(1616745106.778:13945868): apparmor="DENIED" operation="mkdir" profile="named" name="/run/named/" pid=14057 comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=102 ouid=102 type=AVC msg=audit(1616745106.778:13945869): apparmor="DENIED" operation="mkdir" profile="named" name="/run/named/" pid=14057 comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=102 ouid=102 Creating the directory _after_ changing user is clearly a problem that should be fixed in Bind, so changing the apparmor profile would not help. I added this in the service file: ExecStartPre=/bin/mkdir -p /run/named ExecStartPre=/bin/chown bind: /run/named and it works now: # ls -la /run/named/ total 8 drwxr-xr-x 2 bind bind 80 Mar 26 09:06 . drwxr-xr-x 40 root root 1300 Mar 26 09:06 .. -rw-r--r-- 1 bind bind6 Mar 26 09:06 named.pid -rw--- 1 bind bind 102 Mar 26 09:06 session.key but of course the directory is not cleaned when the service stops. I think the best would be to reconsider this PR at least partially and run the service directly as `bind` user: https://salsa.debian.org/dns-team/bind9/-/merge_requests/1 I would suggest using `RuntimeDirectory` to create/cleanup the directory automagically. Regards. \_o< -- Marc Dequènes
Bug#969206: redmine: Could not find gem 'rails (~> 5.2.2)' in any of the gem sources listed in your Gemfile
Quack, Indeed we'll have to wait for 5.0. I had hope for 4.2 but it was pushed back and despite interesting fixes planned for this release that's most probably not going to work. It's unfortunate Redmine's development is going so slowly. Anyway we plan to provide a package in backports whenever possible. \_o< -- Marc Dequènes
Bug#958934: bind9: named fails to start after upgrade to 9.16.2
Quack,
I had a similar problem just now when migrating from
1:9.11.5.P4+dfsg-5.1+deb10u2 to 1:9.16.11-2~bpo10+1.
Aside from the similar permission errors I also had this output:
# aa-status | grep -E '^[0-9]+|named'
34 profiles are loaded.
18 profiles are in enforce mode.
/usr/sbin/named
named
This means there's two conflicting profiles loaded.
Btw `journalctl -k -b0 | grep -F apparmor` does not catch apparmor
messages in my case, but they are available in /var/log/audit/audit.log
(I have auditd installed but no specific rules).
So I looked at the rules:
# rgrep /usr/sbin/named /etc/apparmor*
/etc/apparmor.d/apparmor-profile:/usr/sbin/named {
/etc/apparmor.d/apparmor-profile: /usr/sbin/named mr,
/etc/apparmor.d/usr.sbin.named:profile named /usr/sbin/named
flags=(attach_disconnected) {
/etc/apparmor.d/usr.sbin.named: /usr/sbin/named mr,
I have no idea where apparmor-profile comes from but it's not of my
doing:
# dlocate /etc/apparmor.d/apparmor-profile
bind9: /etc/apparmor.d/apparmor-profile
I did not find in which version it came from though, maybe some previous
bpo; it's dated 2007 and a very basic profile (I can paste it if one
wants to look at it).
A reload of apparmor was not sufficient but this worked:
apparmor_parser -R /etc/apparmor.d/apparmor-profile
rm /etc/apparmor.d/apparmor-profile
apparmor_parser -r /etc/apparmor.d/usr.sbin.named
systemctl restart named
Hope this helps.
\_o<
--
Marc Dequènes
Bug#981166: apt-cacher-ng HTTPS URLs cannot be pinned
Package: apt Version: 2.1.18 Severity: wishlist Control: affects -1 apt-cacher-ng Quack, I am using apt-cacher-ng and in order to use https I'm using the method recommended by its author by prepending HTTPS/// to the host, which gives URLs of the like: http://HTTPS///myrepo.example.com/debian Previously I was using o= to match but now prefers matching with the origin. I realized that when using a proxy with this trick, and even if I encode the slashes as %2f it is not matching. In fact after looking into the code I found out it simply split at the first slash, and matches with "HTTPS" which means it de facto matches all my configured sources, not very practical. I did not find any way to work around this problem. Would it be possible to split using the non-decoded string maybe? (and we could ask the apt-cacher-ng to recommend the encoded version instead) Or any other solution? Regards. \_o< -- Marc Dequènes
Bug#955479: apparmor fixes for xline_db and geoip
Quack, On 2021-01-17 02:20, Filippo Giunchedi wrote: On Wed, Apr 01, 2020 at 07:03 PM, Marc Dequènes wrote: I added this line to the apparmor policy: /usr/share/GeoIP/GeoIP.dat r, Btw the package could also Suggest geoip-database needed for this module. Thank you for the report, I'm not an apparmor expert but I'm happy to include support in the package (at https://salsa.debian.org/debian/inspircd) Suggesting 'geoip-database' is a good idea, I'll add that! So that works for Inspircd v2. Not sure that's of much value now since the release is close. v3 now uses the GeoLite2 DB and that's not available without registration IIUC. But for people OK to register there is the geoipupdate package that can use a token to download it. I have no idea where it stores the files but it should not be difficult to get this information. Then you can simply update the path in the apparmor profile. Another suggestion: to allow admins to add little fixes or adaptations to the apparmor policy I saw that several packages include a file in /etc/apparmor.d/local/ (chronyd for eg), which is ignored if the file is missing, very practical. For Inspircd that would give (at the end of the rules but inside the braquets): #include Hope that helps. \_o< -- Marc Dequènes
Bug#980437: libdqlite-dev: missing dependency on libsqlite3-dev
Package: libdqlite-dev Version: 1.6.0-1+b1 Severity: serious Quack, Similarly as libdqlite0 depends on libsqlite3-0 this dependency is needed too. Regards. \_o< -- Marc Dequènes
Bug#977532: gscan2pdf: save option not available
Quack, On 2020-12-16 16:54, Jeff wrote: The version of libtiff-tools in testing still outputs to stderr, so I am inclined to say this is not (yet) a Debian bug, and certainly not important. That's a tad rude. I understand you're preparing the release but the meaning of a bug is not up to discussion, problems in unstable, and even in experimental have always been considered bugs. As the package was almost unusable since my scans were lost I could even have raised the severity to prevent a broken version to enter testing and end-up in the release. I think you're confusing the severity of the bug itself and the priority generated by the situation (which has no real field in the BTS). Indeed, your patch will break the version of gscan2pdf in testing. As expected libtiff flowed into testing so this is no longer valid. Does the attached patch also fix your problem? Yes it does. Using 'both' is clever and I think proposing the patch upstream would be a better solution (considering other distros and custom installs). Regards. -- Marc Dequènes
Bug#977532: gscan2pdf: save option not available
Package: gscan2pdf Version: 2.10.1-1 Severity: Important Tags: patch Quack, At startup I got this warning: Warning: missing packages Save image requires libtiff And indeed I can scan but not save. I looked in the code how the detection work and found out that `tiffcp -h` is now outputting to stdout and this breaks the detection; I have libtiff-tools 4.1.0+git201212-1 installed. The following patch fixes the situation: --- /usr/bin/gscan2pdf.orig 2020-12-16 14:05:41.74021 +0900 +++ /usr/bin/gscan2pdf 2020-12-16 14:05:49.604293788 +0900 @@ -935,7 +935,7 @@ 'djvu', 'stderr', qr/DjVuLibre-([\d.]+)/xsm, [ 'cjb2', '--version' ] ], [ -'libtiff', 'stderr', +'libtiff', 'stdout', qr/LIBTIFF,\sVersion\s([\d.]+)/xsm, [ 'tiffcp', '-h' ] ], Regards. \_o< -- Marc Dequènes
Bug#977499: python3-argcomplete is quite outdated
Package: python3-argcomplete Version: 1.8.1-1.3 Severity: wishlist Quack, The current version in Debian is really old (January 2017), so I prepared an updated package for my own needs and I've put my work on Salsa so it can be merged or cherry-picked, or serve as an example to help update this package: https://salsa.debian.org/duck/python-argcomplete Regards. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
Quack,
On 2020-12-10 07:39, Michael Biebl wrote:
It might be, that ckb-next is affected by this, especially when it
deals with handling/creating (input) devices.
I'm inclined to reassign this to ckb-next. WDYT?
Indeed it seems the change described in this article would affect
ckb-next.
I made the fix on my system but it did not solve anything. Then I looked
deeper and it seems there is a syntax error in the rule, so I fixed it
too. The resulting file is:
--
ACTION=="remove", GOTO="ckb_end"
# Mark ckb devices as not a joystick and create symlinks to the virtual
input devices
SUBSYSTEM=="input", ATTRS{name}=="ckb[0-9]: [A-Za-z0-9]*",
ENV{ID_INPUT_JOYSTICK}="", PROGRAM="/usr/bin/env sed 's/[0-9]: /-/'
/sys/class/input/%k/device/name", ENV{.INPUT_NAME}="%c",
SYMLINK+="input/by-id/%E{.INPUT_NAME}-event"
LABEL="ckb_end"
--
But if the symlinks look better (there was some kind of underscore or
something before "-event"), that does not solve anything. In fact it
seems these rules are really not that important to make the device work.
So we're back to square one, there is no reason to think the bug is in
ckb-next, so I would wait a bit more before reassigning. Also if you
don't mind I'd be happy to get your help some more :-).
If the comments in the upstream ticket are right, is it not strange that
the way you present available keys affect its availability?
Regards.
\_o<
--
Marc Dequènes
Bug#975475: package takes much more space
Control: tags -1 +help Quack, I tried building with LTO but it does not work with problems similar to this: https://sourceware.org/bugzilla/show_bug.cgi?id=12762 I tried the workarounds to no avail. I do not wish to sacrifice the hardening flags just to save some space, knowing that's still a small amount compared to the size of most games. Help welcome. \_o< -- Marc Dequènes
Bug#975475: package takes much more space
Quack, You're right, that's a big increase and I did not realize. After some digging it seems this is due to compiling with _FORTIFY_SOURCE (you can see the difference popping up between 1.7.2-1 and -2). Some folks suggest enabling LTO. I'm not familiar with all this so I need some more digging and testing. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
Quack, I was wondering what make my system so peculiar and stumbled onto this bug report: https://github.com/ckb-next/ckb-next/issues/671 I haven't tried the ckb-next git version yet but it seems strange that simply presenting a device's features differently would break things. If there is a problem in udev or libinput I think it would be good to track before jumping to an easy workaround. So I'm not reassigning yet and I'd be happy to have your input. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
Quack, On 2020-12-05 05:00, Michael Biebl wrote: hidepid is known to cause problems and no longer a supported configuration: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#hidepid-unsupported Thanks for pointing this out, I did not know it was officially unsupported. I was already using the workaround for logind for quite a while and it is working fine. As for the polkit workaround it requires polkit from experimental. I tried (with systemd 246.6-5) but it seems the client also do things of its own and that is not sufficient. I then disabled hidepid and polkit is now working with 246.6-5. Switching back to 247.1-3 I'm hitting the same problem. If a polkit agent is absolutely necessary then I'm not sure how it's supposed to work since it is launched (in the recommended sway config) after a graphical session is created by sway and it's already too late (the error messages came from sway initializing inputs). I cannot run the polkit agent before because it complains there is no display and quit. I have no idea how desktop environments handle this. I could not find anyone using sway doing differently but 247 is fairly recent. Would you have any idea? Anything to experiment? Regards. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
On 2020-12-04 17:04, Michael Biebl wrote: Is policykit-1 installed and working? I dug a little bit more on this front and I am affected by this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860040 which then made the polkit agent quit on start. I have not tested yet if removing hidepid would be sufficient but polkit's behavior is really annoying. -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
On 2020-12-04 17:04, Michael Biebl wrote: Control: tags -1 + moreinfo Am 04.12.20 um 07:00 schrieb Marc Dequènes (duck): After upgrade from 246.6-5 to 247.1-3 I experienced impossibility to use my keyboard after login on graphical session. I'm using Lightdm + Sway and could input with my usual keyboard for encrypted disk passphrase, GRUB, and lightdm login screen too. Console also was working fine. But after login on lightdm I could not input anything in Sway while the mouse worked fine (but I could not do much). I wonder if this is related to https://github.com/systemd/systemd/issues/17473 Is policykit-1 installed and working? Is libpam-systemd installed and enabled? They are both installed. libpam-systemd seems to be enabled properly: $ rgrep pam_systemd.so /etc/pam.d/ /etc/pam.d/lightdm-greeter:session optional pam_systemd.so /etc/pam.d/runuser-l:-session optionalpam_systemd.so /etc/pam.d/common-session:session optionalpam_systemd.so [with 246.6-5] I got a XDG_SESSION_ID defined and /run/user/ is properly created too. As for policykit, the polkit service is running. How can I test it works well? Regards. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
Package: systemd Version: 247.1-3 Severity: critical Justification: breaks graphical session input Control: affects -1 sway Quack, After upgrade from 246.6-5 to 247.1-3 I experienced impossibility to use my keyboard after login on graphical session. I'm using Lightdm + Sway and could input with my usual keyboard for encrypted disk passphrase, GRUB, and lightdm login screen too. Console also was working fine. But after login on lightdm I could not input anything in Sway while the mouse worked fine (but I could not do much). I was able to capture this error in sway log: 00:00:00.142 [ERROR] [backend/session/logind.c:75] Failed to take device '/dev/input/event5': No such device 00:00:00.143 [ERROR] [backend/session/logind.c:75] Failed to take device '/dev/input/event6': No such device These files existed and were using the usual root:input rw/rw/- permissions. These are devices for my keyboard and LightDM X session enumerates them properly: [31.282] (II) config/udev: Adding input device ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB (/dev/input/event5) [31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: Applying InputClass "evdev pointer catchall" [31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: Applying InputClass "evdev keyboard catchall" [31.282] (II) Using input driver 'evdev' for 'ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB' [31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: always reports core events [31.282] (**) Option "config_info" "udev:/sys/devices/virtual/input/input27/event5" [31.282] (II) XINPUT: Adding extended input device "ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB" (type: KEYBOARD, id 12) [31.282] (**) Option "xkb_rules" "evdev" [31.282] (**) Option "xkb_model" "pc105" [31.282] (**) Option "xkb_layout" "us" [31.282] (**) Option "xkb_variant" "altgr-intl" [31.282] (**) Option "xkb_options" "compose:menu,level3:ralt_switch" [31.283] (II) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: initialized for relative axes. [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) keeping acceleration scheme 1 [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) acceleration profile 0 [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) acceleration factor: 2.000 [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) acceleration threshold: 4 [31.284] (II) config/udev: Adding input device ckb1: Corsair Gaming K70 LUX RGB Keyboard vM (/dev/input/event6) [31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Applying InputClass "evdev pointer catchall" [31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Applying InputClass "evdev keyboard catchall" [31.284] (II) Using input driver 'evdev' for 'ckb1: Corsair Gaming K70 LUX RGB Keyboard vM' [31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: always reports core events [31.284] (**) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Device: "/dev/input/event6" [31.284] (--) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Vendor 0x1b1c Product 0x1b33 [31.284] (**) Option "config_info" "udev:/sys/devices/virtual/input/input28/event6" [31.284] (II) XINPUT: Adding extended input device "ckb1: Corsair Gaming K70 LUX RGB Keyboard vM" (type: KEYBOARD, id 13) My /etc/systemd/logind.conf is unaltered from the default. I did not find any apparmor denial. I could not find anything meaningful in systemd logs or others. Then I checked what packages were upgraded recently and gave it a try downgrading to 246.6-5, and after a reboot it worked. Tell me if I can provide any other information. Regards. \_o< -- Marc Dequènes
Bug#969683: dico: please upgrade to guile-3.0 soon, if feasible
Quack, I packaged 2.10 and no Guile 3.0 support yet. I just sent a mail upstream to ask if that would be feasible. Regards. \_o< -- Marc Dequènes
