Bug#1081920: should use ConditionVirtualization=no
Package: powertop Version: 2.15-3 Severity: normal Tags: patch Please add ConditionVirtualization to powertop.service because it does not make any sense to run powertop in a VM or container. -- ciao, Marco signature.asc Description: PGP signature
Bug#1081921: should use ConditionVirtualization=!container
Package: console-setup Version: 1.230 Severity: normal Tags: patch Please add ConditionVirtualization to keyboard-setup.service and console-setup.service, because containers do not have a keyboard or a console. -- ciao, Marco signature.asc Description: PGP signature
Bug#1080459: update initramfs did not help. REverting to 6.10.4-amd64 worked
On Sep 11, ael wrote: > initrd.img-6.10.6-amd64 (8.1M) Try rebuilding this initrd (update-initramfs -u -k 6.10.6-amd64). -- ciao, Marco signature.asc Description: PGP signature
Bug#754809: informational IETF draft
On Sep 09, Andrea Pappacoda wrote: > It does not contain any magical solution, but might be a good starting point > for someone wanting to figure out what is happening and eventually working > on a fix. There is nothing to be figured out: the BTS just has to stop to send mail using the sender's 822.from. -- ciao, Marco signature.asc Description: PGP signature
Bug#1078686: riseup-vpn: missing dependency - qrc:/main.qml: module "org.kde.breeze" is not installed
Hi, following rule nr.0 of bug reporting, i.e. always search for an already existing bug report with an error message similar to what you have before opening a new report, you could have found #1073959. We had already found the root cause and related workaround before this bug was even opened. To confirm the workaround to be the same, you can check Jonas' suggestion and launch QT_QUICK_CONTROLS_STYLE= riseup-vpn If that is confirmed, the issue is -as nheko- that we have Qt6 apps in trixie/sid, while we do not have the full Plasma6 environment there yet. It's pretty evident, this is nor a bug in upstream plasma-mobile, nor in the Debian package I'm co-maintaining. When we want to blame someone, it's a consequence of how the Plasma6 transition is being managed in Debian. But it is like it is, it will be over sooner or later... Kind regards Marco
Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization
On Sep 04, ael wrote: > Or could there be another explanation? Puzzled. This suspiciously looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663436 . -- ciao, Marco signature.asc Description: PGP signature
Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization
On Sep 04, ael wrote: > # cat /boot/initrd.img-6.10.6-amd64 | cpio -t These are multiple concatenated archives. Use lsinitramfs. -- ciao, Marco signature.asc Description: PGP signature
Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization
On Sep 04, ael wrote: > Yet manually correcting with > > # modprobe -r snd_hda_intel > # modprobe snd_hda_intel Unpack your initramfs and check: - if snd_hda_intel is there (so it is probably loaded in early boot) - if so, if the module parameter configuration is there too -- ciao, Marco signature.asc Description: PGP signature
Bug#1033394: Bind v9.18.12+ unmarshall xml error
Control: notfound -1 0.7.0-3 On Aug 09, Marco d'Itri wrote: > > I am also affected by this bug on Debian bullseye (current old stable) since > > bind9 has been updated to 1:9.16.50-1~deb11u1 from bullseye-security. > I am seeing this on stable too, with a supposedly fixed version: My bad: actually I was using an older version. -- ciao, Marco signature.asc Description: PGP signature
Bug#1080344: ITP: bcachfs-tools -- bcachefs userspace tools
On Sep 02, Daniel Gröber wrote: > Based on publically available [information], my previous and recent > interactions with upstream this happend more due to personal > differences with upstream than for technical reasons and I hope to be > able to rebuild that damaged bridge. Based on my own personal experience with trying to package another big Rust application a few years ago (Routinator) Jonathan is completely right and the common Rust practices of dealing with dependencies are rotten and hostile to distributions, but I wish you the best luck. :-) > I would very much appreciate anyone willing to co-maintain the package > with me. Especially someone with any serious Rust experience would be > very helpful. LOL (sorry). -- ciao, Marco signature.asc Description: PGP signature
Bug#1073959: [Pkg-matrix-maintainers] Bug#1073959: happens the same way for me
Hi Jonas, > My thoery is that something (other than nheko) on the affected systems > sets widget style to Breeze. Well, yeah: as I wrote in June/July, plasma-mobile sets that environment variable. > Please, any of you that experience this issue, (double-check if above > helps for you as well, and) check if it also works to unset the style, > like this: > > QT_QUICK_CONTROLS_STYLE= nheko I've tested this on a freshly installed Plasma5 system (on my main system with Plasma6, there's no issue because the needed package is installed): I confirm, unsetting that variable gets nheko to show correctly. I've not logged in, but at least the splash screen is shown correctly. Kind regards Marco
Bug#1079477: plasma-mobile: FTBFS
Hi Patrick, thank you for the note. I'm answering to the shell's bug, but the topic is similar for the other 5 bugs of the packages I'm maintaining, as well. I'm quite inclined to let it broken and then fix it with the Plasma6 upload to sid, if that will be possible in a reasonable amount of time: without making promises, do you think it's going to be matter of couple of weeks / a month / 2 months /... ? As a ballpark, plasma-mobile has the same build-deps like plasma-desktop. Thank you, kind regards Marco
Bug#1079559: plasma-mobile: Plasma 6 transition - kpipewire
Hi Patrick, thank you for the note. I guess you mean qml6-module-org-kde-pipewire [1]. I'm already working on that... Kind regards Marco [1] https://salsa.debian.org/DebianOnMobile-team/plasma-mobile/-/blob/wip/tiol/plasma6/debian/control?ref_type=heads#L36 On Sat, 24 Aug 2024 17:05:30 +0200 Patrick Franz wrote: > Source: plasma-mobile > Version: 5.27.10-1 > Severity: important > X-Debbugs-Cc: delta...@debian.org > > Dear Maintainer, > > plasma-mobile currently depends on qml-module-org-kde-pipewire which > is part of the kpipewire package. > qml-module-org-kde-pipewire will cease to exist once Plasma 6 is > uploaded to unstable. We do not have an ETA for that yet, but this > bug is to inform you that your package needs to be ported to a > Qt 6 based version in order to continue using kpipewire. > > A Qt 6 based version of kpipewire is available in experimental, > such that you can prepare and test your package there. > > > -- > Regards > > Patrick Franz > >
Bug#1079662: plasma-mobile: Plasma 6 transition - qqc2-breeze-style
Hi Patrick, thank you for the note. This should be ok [1], as well. [1] https://salsa.debian.org/DebianOnMobile-team/plasma-mobile/-/blob/wip/tiol/plasma6/debian/control?ref_type=heads#L65 Kind regards Marco On Sun, 25 Aug 2024 23:08:22 +0200 Patrick Franz wrote: > Package: plasma-mobile > Severity: important > X-Debbugs-Cc: delta...@debian.org > > Dear Maintainer, > > plasma-mobile currently depends on qml-module-org-kde-qqc2breezestyle which > is part of the qqc2-breeze-style package. qml-module-org-kde-qqc2breezestyle > will cease to exist once Plasma 6 is uploaded to unstable and will be > replaced by qml6-module-org-kde-breeze which is Qt 6 based. > > We do not have an ETA for the Plasma 6 upload to unstable yet, but this > bug is to inform you that your package needs to be ported to a > Qt 6 based version in order to continue using qqc2-breeze-style. > > A Qt 6 based version of qqc2-breeze-style is available in experimental, > such that you can prepare and test your package there. > > We will raise the severity of this bug report once the Plasma 6 upload > comes closer. > > > -- > Regards > > Patrick Franz > >
Bug#1079627: kmod: Build fixes and improvements
On Aug 25, Guillem Jover wrote: > Here are several fixes and improvements for the build and packaging. Looks good! > - Preserved the environment CC if set in the autopkgtest, but > pondered simply hardcoding gcc (not sure whether the intention was > to be able to support stuff like clang). It was. > diff --git a/debian/.gitignore b/debian/.gitignore Until tag2upload will build the packages then I prefer to not ignore these files to be sure that they will not end up in .debian.tar.xz. > Subject: [PATCH 6/9] Perform full /usr-move on all absolute paths https://github.com/kmod-project/kmod/issues/85 discusses why --with-module-directory cannot be changed. I will not further change the init script, maybe it's time to just remove it for good. -- ciao, Marco signature.asc Description: PGP signature
Bug#1066077: usr-is-merged fails to install on a /usr-merged system
Control: tag -1 wontfix On Mar 12, David W wrote: > In the end, it turned out to be because /usr itself was a symlink, and > although this causes no issues for either the merging process or any > running software, since the check is using "readlink -f" it erroneously > fails. I understand the issue, but right now I cannot see a simple way to make the check work with your setup. Development of usrmerge started 10 years ago and the program will be retired with the next Debian release: at this point I do not feel like introducing major changes anymore for marginal use cases. You can easily rename /usr by installing busybox-static and then running "busybox ash": you will get a shell which magically uses all the busybox built-in commands. -- ciao, Marco signature.asc Description: PGP signature
Bug#1079658: RM: rpki-client [armel armhf] -- ANAIS; does not support 32 bit architectures anymore
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: rpki-cli...@packages.debian.org Control: affects -1 + src:rpki-client User: ftp.debian@packages.debian.org Usertags: remove rpki-client now build-depends on architecture-is-64-bit. -- ciao, Marco signature.asc Description: PGP signature
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
The quick and easy solution would be to rebuild dracut-install, but the release team refused to binNMU it (#1079038). The stupid solution would be to revert the change, and I will not do it because I do not want to diverge from upstream. The elegant solution would be to keep for a while both symbols in the library, but I am not good enough with ld(1) and could not actually manage to do it myself. The nuclear solution would be to make a new upload with "Breaks: dracut-install (<= 103-1)", which at least would make libkmod2 not installable until somebody will be forced to do a new sourceful upload of dracut-install. So I will wait for a while to see if anybody can help with #3, and if not then I will proceed with #4. -- ciao, Marco signature.asc Description: PGP signature
Bug#1079038: nmu: dracut_103-1
On Aug 19, Sebastian Ramacher wrote: > Reserve dependencies failing with unresolved symbols is a sign that > libkmod is missing a SONAME bump. Why hasn't that been done? To make a long story short, upstream did not believe that anything actually used the symbol, and I do not want to have a critical library diverge from upstream. -- ciao, Marco signature.asc Description: PGP signature
Bug#1079038: nmu: dracut_103-1
Package: release.debian.org Severity: normal X-Debbugs-Cc: dra...@packages.debian.org Control: affects -1 + src:dracut User: release.debian@packages.debian.org Usertags: binnmu nmu dracut_103-1 . ANY . bookworm . -m "Rebuild against the latest libkmod" Upstream broke backward compatibility and it looks like my latest kmod upload is a bit more toxic than I tought, and systems will not boot. I think that the easiest solution is to NMU dracut-install. -- ciao, Marco signature.asc Description: PGP signature
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
On Aug 19, Christoph Anton Mitterer wrote: > With the new version, initramfs generation gives: I know, the plan it to rebuild dracut-install. -- ciao, Marco signature.asc Description: PGP signature
Bug#1076995: New root anchors
On Jul 25, Chris Hofstaedtler wrote: > IANA has published new DNSSEC trust anchors, please see > https://lists.dns-oarc.net/pipermail/dns-operations/2024-July/022636.html > and update the shipped data, for unstable but also stable. While IANA has published the new trust anchors, the KSK itself will actually be published in the root zone only in next January, so there is nothing to do right now because we cannot have the KSK yet. In theory I could still make a new upload with only an updated root.ds file, but it would be quite pointless because only dnsmasq uses it of all of our resolvers. -- ciao, Marco signature.asc Description: PGP signature
Bug#925349: src:dns-root-data: Should automate root key transitions (at job? systemd timer?)
On Mar 23, Daniel Kahn Gillmor wrote: > Instead, we could ship all the files that we know about based on their > transition times, and find some way to do an automated transition > between those files. Not really: the only legitimate mechanism for receiving in-band updates of the trust anchors is RFC 5011, which I am not sure how it could be implemented in this package since it tends to be implemented by the resolver themselves. -- ciao, Marco signature.asc Description: PGP signature
Bug#1078773: the backspace binding does not work anymore
ux 6.10.4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 mutt depends on: ii libc62.39-7 ii libgnutls30t64 3.8.6-2 ii libgpg-error01.50-3 ii libgpgme11t641.18.0-5 ii libgsasl18 2.2.1-1+b1 ii libgssapi-krb5-2 1.21.3-3 ii libidn2-02.3.7-2 ii libncursesw6 6.5-2 ii libtinfo66.5-2 ii libtokyocabinet9t64 1.4.48-15.1 ii zlib1g 1:1.3.dfsg+really1.3.1-1 Versions of packages mutt recommends: ii locales 2.39-7 ii mailcap 3.72 ii sensible-utils 0.0.24 Versions of packages mutt suggests: ii aspell 0.60.8.1-1+b1 ii ca-certificates 20240203 ii gnupg 2.2.43-8 ii openssl 3.3.1-6 ii postfix [mail-transport-agent] 3.9.0-3 ii urlview 1d-1 Versions of packages mutt is related to: ii mutt 2.2.13-1 -- no debconf information -- ciao, Marco signature.asc Description: PGP signature
Bug#1078349: probably should be declared Multi-Arch: foreign
Package: python3-dns Version: 4.0.2-2 Severity: normal Md: yes, rbldnsd B-D on python3-dns which might be a candidate for M-A:foreign python3-dns is arch:all so it's impossible to install the host-arch version of the package (arch:all packages are implicitly treated as being of the native architecture) should I open a bug on python3-dns? yes, its maintainer will know whether python3-dns is doing anything crazy or not -- ciao, Marco signature.asc Description: PGP signature
Bug#1033394: Bind v9.18.12+ unmarshall xml error
On Jul 29, Nicolas Peugnet wrote: > I am also affected by this bug on Debian bullseye (current old stable) since > bind9 has been updated to 1:9.16.50-1~deb11u1 from bullseye-security. I am seeing this on stable too, with a supposedly fixed version: bind_exporter, version 0.7.0 (branch: debian/sid, revision: 0.7.0-3) build user: team+pkg...@tracker.debian.org build date: 20240312-13:14:23 go version: go1.22.1 platform: linux/amd64 tags: unknown BIND 9.18.28-1~deb12u2-Debian (Extended Support Version) Aug 09 09:52:34 attila bind_exporter[1800625]: time="2024-08-09T09:52:34+02:00" level=error msg="Couldn't retrieve BIND stats: failed to unmarshal XML response: strconv.ParseUint: parsing \"-1\": invalid syntax" source="bind_exporter.go:391" -- ciao, Marco signature.asc Description: PGP signature
Bug#1073205: docker-compose: new python3-requests dependency brokes docker-compose
Dears,
I am not sure where we stand with this bug, so please accept my apologies
if my comment is of no help.
I've noticed, that docker-compose is not longer part of testing now, but it
looks like the package i have installed on my machine matches with that in
sid.
$ dpkg -l | grep compose
ii docker-compose 1.29.2-6.2
all define and run multi-container Docker
applications with YAML
ii python3-compose 1.29.2-6.2
all Python implementation of
docker-compose file specification
I was definitely able to reproduce the bug just by typing "docker compose
ps" in a directory with a docker-compose file.
$ docker-compose ps
Traceback (most recent call last):
File "/usr/bin/docker-compose", line 33, in
sys.exit(load_entry_point('docker-compose==1.29.2', 'console_scripts',
'docker-compose')())
^
File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 81, in
main
command_func()
File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 200, in
perform_command
project = project_from_options('.', options)
^^
File "/usr/lib/python3/dist-packages/compose/cli/command.py", line 60, in
project_from_options
return get_project(
File "/usr/lib/python3/dist-packages/compose/cli/command.py", line 152,
in get_project
client = get_client(
^^^
File "/usr/lib/python3/dist-packages/compose/cli/docker_client.py", line
41, in get_client
client = docker_client(
^^
File "/usr/lib/python3/dist-packages/compose/cli/docker_client.py", line
124, in docker_client
kwargs = kwargs_from_env(environment=environment,
ssl_version=tls_version)
^
TypeError: kwargs_from_env() got an unexpected keyword argument
'ssl_version'
The patch for python3-compose fixes the problem for me
Thank you
Regards
Bug#1076491: base-files: file clash with libc6
On Jul 31, Santiago Vila wrote: > Marco: Before I go ahead and apply the patch proposed by Helmut, do you have > any comments? I have not actually tested it, but everything looks reasonable. -- ciao, Marco signature.asc Description: PGP signature
Bug#712770: sash: Support xz compression
On Jun 19, Ariel wrote: > I don't know how hard it would be, but perhaps sash should support xz along > with gzip. (And perhaps bzip2 as well.) It would require taking something like minilzma and integrating it, but the big question is: what is the purpose of sash nowadays? I think that for just about all purposes it can be replaced by busybox-static. -- ciao, Marco signature.asc Description: PGP signature
Bug#897277: decrease e2fsprogs' Priority: required
Let's remind Ted about this... On Dec 13, Faidon Liambotis wrote: > Hi Ted, > > On Wed, Aug 18, 2021 at 01:41:36AM +0300, Faidon Liambotis wrote: > > I haven't received a response for this. We are now at the beginning of > > the aforementioned bookworm cycle, so I thought it may be a good > > opportunity to bump this :) Do you have any thoughts? > > It's now been 2½ years since I last followed up on this bug, and 5½ > since your last response where you said you'd "batch it with some other > bug fixes in the next e2fsprogs minor release" and that would happen "by > early June [2018] at the latest". > > Has this fallen through the cracks? Have you changed your mind? Would it > be possible to get an update here? > > Thanks, > Faidon -- ciao, Marco signature.asc Description: PGP signature
Bug#1074303: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian
Am 18.07.2024 um 18:30:44 Uhr schrieb pham...@bluewin.ch: > The command line you asked me to enter is invalid ?!?! > sudo nmcli general logging level LEVEL domains ALL LEVEL must be replaced by the level, e.g. INFO or DEBUG. sudo nmcli general logging level DEBUG domains all After that please check if the change has been applied: sudo nmcli general logging This must show DEBUG for all domains. If not, no debug logs will be produced. If that is the case, help can continue. > On top of that you closed my previous bug for no reason and I had to > reopen it. This wasn't me. > Forgive me for being blunt, but what's the problem? You > don't have time to deal with it? If that's it, there are other > maintainers who are most certainly ready to take over, don't you > think? I can understand that you are annoyed, but unless your system produces DEBUG logs, nobody can further investigate that. -- kind regards Marco
Bug#1076017: purity-off: autopkgtest regression on arm64: output keeps growing
On Jul 13, Paul Gevers wrote: > On the ci.d.n infrastructure our nodes run bookworm and use the lxc backend. > Do you do that too? No, I just run it on bare metal. -- ciao, Marco signature.asc Description: PGP signature
Bug#1076222: tcpd,tcm: install program with same name (tcpd)
reassign -1 tcm On Jul 12, Chris Hofstaedtler wrote: > Please find a solution for your packages. Ideas: /usr/sbin/tcpd has been there since 1990 and is basically a public API. tcm is unmaintained abandonware and its popcon count has been declining for 15 years. -- ciao, Marco signature.asc Description: PGP signature
Bug#1076017: purity-off: autopkgtest regression on arm64: output keeps growing
On Jul 11, Paul Gevers wrote: > You have an arm64 system? If yes, good to know it's not systematic and > apparently only happening on the ci.d.n infrastructure. It would be > interesting to figure out what the differences in setup (hardware) are. Yes. It's a Banana Pi M5 and I cannot see how this could be hardware-dependent. > I realized that. But apparently only arm64 is broken. So it's probably a > (indirect) dependency that broke your test on arm64. Have a look at the test: it just uses purity and perl. I should be able to check on the ci infrastructure myself in two weeks. -- ciao, Marco signature.asc Description: PGP signature
Bug#1076017: purity-off: autopkgtest regression on arm64: output keeps growing
On Jul 09, Paul Gevers wrote: > Your package has an autopkgtest, great. However, on arm64 it recently > started to fill the entire disk with its output file in $AUTOPKGTEST_TMP (in > testing and unstable, I haven't checked stable). On an otherwise empty host, > there's 63 GB free, a watchdog kicks in at 95% disk usage and prevents most > damage, but the current scheduled job for purity-off on arm64 never > finishes. Can you please investigate the situation and fix it? The output > only shows the first test passes: OK: 100. I am not sure of how I can investigate this, since it works fine on my system. The test is written in shell and Perl, so I do not expect it to be architecture-dependent. The package is even "Architecture: all". md:purity-off$ sadt -bv cannot parse package relationship "@", returning it raw -- everything -- O: OK: 100 O: OK: 1500 O: OK: 400 O: OK: 500 O: OK: dabney O: OK: new100 O: OK: pt100 -- everything: PASS OK (tests=1) md:purity-off$ -- ciao, Marco signature.asc Description: PGP signature
Bug#1073959: [Pkg-matrix-maintainers] Bug#1073959: nheko starts into a grey screen, log warns about missing module org.kde.breeze and DRM_MSM_GEM_INFO
Actual workaround is launching "env QT_QUICK_CONTROLS_STYLE=Universal nheko" from terminal. This issue should solve by itself as soon as src:qqc2-breeze-style (6.1.0-1, now in experimental) gets into sid/trixie. [re-posting trying to get layout understood right by BTS] Hi Jonas, I think I can now confirm the issue is Breeze, then the bug is not in nheko itself. Launching "env QT_QUICK_CONTROLS_STYLE=Universal nheko" gets to a working nheko instance. A bit weird in the colours, but that's kind-of expected with this kind of workaround. Idea came after finding where that "org.kde.breeze" comes from, as it is not inside nheko source code: it's plasma-mobile to set that variable [1]. A search brought me then to [2] and to the workaround, I guess every non-Breeze style listed in that page should work fine, maybe looking even better than Universal. Now, where is the bug? That environment variable is still set in plasma-mobile on the master (Plasma6/KF6/Qt6) branch [3]. So it's supposed to be there, yet nheko is not finding it. My best hypothesis at the moment, that "org.kde.breeze" QQC (Qt Quick Controls) style should be supplied by binary package qml-module-org-kde-qqc2breezestyle (source qqc2-breeze-style) that is stil at 5.27.11-1 version at the moment in Debian [4]. I see the version of that package in trixie still build-depends on Qt5/KF5, so that's likely conflicting with nheko already depending on Qt6. Please let me know if it's OK for you to keep this bug assigned to nheko until the situation is fixed, so that it's easier for anyone else to find the workaround. Kind regards Marco [1] https://codesearch.debian.net/show?file=plasma-mobile_5.27.10-1%2Fbin%2Fstartplasmamobile.in&line=15 [2] https://doc.qt.io/qt-6/qtquickcontrols-styles.html [3] https://invent.kde.org/plasma/plasma-mobile/-/blob/master/bin/startplasmamobile.in?ref_type=heads#L14 [4] https://packages.debian.org/source/trixie/qqc2-breeze-style
debian-bugs-dist@lists.debian.org
Hi Patrick, I do not want to put too much burden on the Qt/KDE team. I've seen in the past weeks Qt6, then KF6 and now Plasma6 steadily being packaged and uploaded into experimental, making it easier and easier for me to test the plasma-mobile_6.x packaging. I know it's a big effort, so big thank you for that! When you estimate it being matter of one month or less, I definitely prefer to have Mobian plasma-mobile weekly images' building to fail for a few weeks more (users still have the pre-time64-migration images available, then they can upgrade from there) and let you continue with Plasma6 packaging, in order to get plasma-mobile_6.x available sooner for Mobian users. Kind regards Marco Il 02/07/24 22:48, Patrick Franz ha scritto: Hi, On Tue, 2 Jul 2024 19:39:27 +0200 Marco Mattiolo wrote: Hi Santiago, I'm the maintainer of plasma-mobile package in Debian, plus some of the related apps. At the moment, the present bug keeps meta-plasma- mobile metapackage out of trixie, thus letting the building of Mobian plasma-mobile images to fail [1]. As I wrote in the previous message, looking into buildd and reproducible-builds, I thought this to be solved, but from your attachment I see I shouldn't have assumed. I'm not the maintainer of wacomtablet, so I'm not sure what to touch if tests are still failing. I see in your attachment that the error message is always the same as in the original report, then I'd try e.g. [2] that I see is not implemented in d/rules for wacomtablet, but maybe it's just better to wait for the new version of wacomtablet (6.1.0-1 now in experimental) to be uploaded to sid and check how that new version behaves. I don't have the resources to dig into why the tests are failing, but I could disable them for the time being if wacomtablet is a blocker for something right now. We will definitely revisit this once the new version in exp (now part of Plasma 6) can be compiled there.
Bug#1074791: be_enabled only checks for init scripts and upstart services
Control: reassign -1 ruby-serverspec Wrong package, sorry... -- ciao, Marco signature.asc Description: PGP signature
Bug#1074791: be_enabled only checks for init scripts and upstart services
Package: ruby-specinfra
Version: 2.89.0-1
Severity: important
Tags: upstream
varnish does not ship an init script anymore because it was a bugs
generator, but the varnish modules packages uses be_enabled in their
autopkgtests and now they fail because ruby-specinfra does not know
about systemd.
ruby-specinfra needs to support services which only have a systemd unit.
e.g.:
Failures:
1) Service "varnish" is expected to be enabled
Failure/Error: it { should be_enabled }
expected Service "varnish" to be enabled
/bin/sh -c ls\ /etc/rc3.d/\ \|\ grep\ --\ \'\^S..varnish\$\'\ \|\|\
grep\ \'\^\ \*start\ on\'\ /etc/init/varnish.conf
# ./spec/varnish-modules/install_spec.rb:12:in `block (2 levels) in '
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1069495: wacomtablet: FTBFS on armhf: dh_auto_test: error: cd obj-arm-linux-gnueabihf && make -j4 test ARGS\+=--verbose ARGS\+=-j4 returned exit code 2
Hi Santiago, I'm the maintainer of plasma-mobile package in Debian, plus some of the related apps. At the moment, the present bug keeps meta-plasma-mobile metapackage out of trixie, thus letting the building of Mobian plasma-mobile images to fail [1]. As I wrote in the previous message, looking into buildd and reproducible-builds, I thought this to be solved, but from your attachment I see I shouldn't have assumed. I'm not the maintainer of wacomtablet, so I'm not sure what to touch if tests are still failing. I see in your attachment that the error message is always the same as in the original report, then I'd try e.g. [2] that I see is not implemented in d/rules for wacomtablet, but maybe it's just better to wait for the new version of wacomtablet (6.1.0-1 now in experimental) to be uploaded to sid and check how that new version behaves. Kind regards Marco [1] https://salsa.debian.org/Mobian-team/mobian-recipes/-/jobs/5907189/raw [2] https://superuser.com/questions/1694496/qt5s-qpa-can-not-connect-to-my-display Il 01/07/24 17:45, Santiago Vila ha scritto: retitle 1069495 wacomtablet: FTBFS: failing tests thanks [ Please always Cc: the bug submitter, the BTS does not forward messages sent to the bug address to the bug submitter by default ]. El 28/6/24 a las 19:26, Marco Mattiolo escribió: that looks more an issue with Qt (and xorg?). Is this still failing to build for you or shall we close this? I can reproduce this on m6a.large and r6a.large instances from AWS, but randomly. (See attach). The test which fails is not always the same. If you need an instance to reproduce this, please contact me privately. Thanks.
Bug#1074124: source:pulseaudio-qt: Misalignment between Qt5/Qt6 package names, package description and dependencies
Hi Pino, thank you for the explanation on the SOVERSION topic. I had the feeling for the binary packages' name to be too evident to be mistaken, now it makes much more sense. As for the "messing things up": I'm preparing the plasma-mobile 6.x packaging and, while testing it, I would prefer to have only Qt6 installed. In case I've messed up something and Qt5 is invoked, I prefer to get an evident crash instead of the error to go unseen due to both Qt5/Qt6 being installed... but it's just my belief :) Thank you Marco
Bug#1069495: wacomtablet: FTBFS on armhf: dh_auto_test: error: cd obj-arm-linux-gnueabihf && make -j4 test ARGS\+=--verbose ARGS\+=-j4 returned exit code 2
Hi, this bug seems not to have been seen in the reproducible-builds [1] or in the buildd [2] projects. The FTBFS is related to a failing test 9: qt.qpa.xcb: could not connect to display :99 9: qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. 9: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. 9: 9: Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. 9: 9/22 Test #9: Test.Common.PropertySet ..Subprocess aborted***Exception: 0.02 sec qt.qpa.xcb: could not connect to display :99 qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. that looks more an issue with Qt (and xorg?). Is this still failing to build for you or shall we close this? Thank you Marco [1]https://tests.reproducible-builds.org/debian/history/armhf/wacomtablet.html [2]https://buildd.debian.org/status/fetch.php?pkg=wacomtablet&arch=armhf&ver=3.2.0-5%2Bb1&stamp=1711193918&raw=0
Bug#1074171: RM: rpki-client [i386 hurd-i386] -- ROM; does not support 32 bit time_t anymore
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: rpki-cli...@packages.debian.org Control: affects -1 + src:rpki-client User: ftp.debian@packages.debian.org Usertags: remove rpki-client 9.1 does not support anymore systems with a 32 bit time_t. Note: this was a request for a partial removal from testing, converted in one for unstable -- ciao, Marco signature.asc Description: PGP signature
Bug#1074124: source:pulseaudio-qt: Misalignment between Qt5/Qt6 package names, package description and dependencies
Package: source:pulseaudio-qt Version: 1.5.0-2 Severity: important Dear Maintainer, the pulseaudio-qt source package actually in sid has some weirdness: - binary package libkf6pulseaudioqt-dev is described as Qt6-related but it depends qtbase5-dev - binary package libkf6pulseaudioqt5, it is described as Qt6-related, it depends on Qt6, so shouldn't it be named libkf6pulseaudioqt6? I've been hitting this while working on the plasma-mobile 6.x series packaging (for what is not yet available, I'm doing quick-and-dirty packaging of build-deps myself): plasma-mobile requires plasma-pa and the latter requires KF6PulseAudioQt i.e. this source package. But the first point of this bug report (depending on qtbase5-dev) messes up the situation because it takes Qt5, that ideally should be left out to avoid conflicts. Thank you Marco
Bug#1073959: [Pkg-matrix-maintainers] Bug#1073959: nheko starts into a grey screen, log warns about missing module org.kde.breeze and DRM_MSM_GEM_INFO
Hi Jonas, I think I can now confirm the issue is Breeze, then the bug is not in nheko itself. Launching "env QT_QUICK_CONTROLS_STYLE=Universal nheko" gets to a working nheko instance. A bit weird in the colours, but that's kind-of expected with this kind of workaround. Idea came after finding where that "org.kde.breeze" comes from, as it is not inside nheko source code: it's plasma-mobile to set that variable [1]. A search brought me then to [2] and to the workaround, I guess every non-Breeze style listed in that page should work fine, maybe looking even better than Universal. Now, where is the bug? That environment variable is still set in plasma-mobile on the master (Plasma6/KF6/Qt6) branch [3]. So it's supposed to be there, yet nheko is not finding it. My best hypothesis at the moment, that "org.kde.breeze" QQC (Qt Quick Controls) style should be supplied by binary package qml-module-org-kde-qqc2breezestyle (source qqc2-breeze-style) that is stil at 5.27.11-1 version at the moment in Debian [4]. I see the version of that package in trixie still build-depends on Qt5/KF5, so that's likely conflicting with nheko already depending on Qt6. Please let me know if it's OK for you to keep this bug assigned to nheko until the situation is fixed, so that it's easier for anyone else to find the workaround. Kind regards Marco [1] https://codesearch.debian.net/show?file=plasma-mobile_5.27.10-1%2Fbin%2Fstartplasmamobile.in&line=15 [2] https://doc.qt.io/qt-6/qtquickcontrols-styles.html [3] https://invent.kde.org/plasma/plasma-mobile/-/blob/master/bin/startplasmamobile.in?ref_type=heads#L14 [4] https://packages.debian.org/source/trixie/qqc2-breeze-style
Bug#1073959: nheko starts into a grey screen, log warns about missing module org.kde.breeze and DRM_MSM_GEM_INFO
Package: nheko Version: 0.12.0+~0.10.0+~1.0.0+~0.3.1-1 Severity: normal X-Debbugs-Cc:marco.matti...@hotmail.it Dear Maintainer, thank you for maintaining Nheko in Debian! Here using Mobian Trixie on op6-enchilada with environment plasma-mobile (still at 5.27.10 in trixie). After last upgrade, nheko starts into a gray screen. Tapping on the screen does nothing, the only possible action is to close the application. Launching it from console gives following log: marco@mobian:~$ nheko [2024-06-20 18:55:31.683] [ui] [info] Restoring window size 360x702 [2024-06-20 18:55:31.710] [ui] [info] WebRTC: initialised GStreamer 1.24.4 [5:02:15.126640451] [8231] INFO Camera camera_manager.cpp:313 libcamera v0.3.0 [2024-06-20 18:55:31.890] [qml] [warning] Couldn't load VAAPI library (:0, ) [2024-06-20 18:55:31.922] [ui] [info] jdenticon plugin not found. [2024-06-20 18:55:32.065] [qml] [warning] qrc:/resources/qml/Root.qml: module "org.kde.breeze" is not installed (qrc:/resources/qml/Root.qml:-1, ) [2024-06-20 18:55:32.100] [ui] [info] starting nheko 0.12.0 [2024-06-20 18:55:32.144] [ui] [info] User already signed in, showing chat page [2024-06-20 18:55:32.146] [ui] [info] Switching to chat page [2024-06-20 18:55:32.146] [ui] [info] Unity service available: false MESA: warning: Failed to set BO metadata with DRM_MSM_GEM_INFO: -22 [2024-06-20 18:55:32.402] [db] [info] database ready [2024-06-20 18:55:32.402] [db] [info] restoring state from cache [2024-06-20 18:55:32.403] [db] [info] Removing old cached messages [2024-06-20 18:55:32.403] [db] [info] Message removal done [2024-06-20 18:55:32.407] [db] [info] Restored 36 rooms from cache [2024-06-20 18:55:32.410] [crypto] [info] ed25519 : ejbFUouEci/Y9NQZGKQWw7OvJh+J5q5JIQwr4SHvMIg [2024-06-20 18:55:32.410] [crypto] [info] curve25519: AAvoZ4nMgdZjk6zk0b5XaHw3NvVfpISFvDt37sna7GM [2024-06-20 18:55:32.755] [crypto] [info] Using online key backup. [2024-06-20 18:55:32.812] [crypto] [info] Fetched server key count 52 signed_curve25519 [2024-06-20 18:55:33.107] [mtx] [info] Skipping rule with unknown condition type: event_property_contains [2024-06-20 18:55:33.107] [mtx] [info] Skipping rule with unknown condition type: event_property_is [2024-06-20 18:55:33.107] [mtx] [info] Skipping rule with unknown condition type: event_property_is [2024-06-20 18:55:34.469] [net] [info] TURN server(s) retrieved from homeserver: [2024-06-20 18:55:34.469] [net] [info] username:1718988934:@tiol:matrix.org [2024-06-20 18:55:34.469] [net] [info] ttl: 86400 seconds [2024-06-20 18:55:34.469] [net] [info] uri: turn:turn.matrix.org:3478?transport=udp [2024-06-20 18:55:34.469] [net] [info] uri: turn:turn.matrix.org:3478?transport=tcp [2024-06-20 18:55:34.469] [net] [info] uri: turns:turn.matrix.org:443?transport=tcp ^C Not sure if the issue if related to the warning about missing org.kde.breeze module or the MESA warning. Any idea how to check this? I think, if it's the former, than it's something that could fix by itself as soon as the Qt/KDE team packages the 6.x version of breeze... no idea what to think about the latter. Thank you Marco -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.6-qcom (SMP w/8 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it:C Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages nheko depends on: ii gstreamer1.0-nice 0.1.21-2+b1 ii gstreamer1.0-qt51.24.4-1+b1 ii libc6 2.38-13 ii libcmark0.30.2 0.30.2-6+b1 ii libcpp-httplib0.14t64 0.14.3+ds-1.1+b1 ii libcurl4t64 8.8.0-1 ii libevent-core-2.1-7t64 2.1.12-stable-10 ii libevent-pthreads-2.1-7t64 2.1.12-stable-10 ii libfmt9 9.1.0+ds1-2 ii libgcc-s1 14-20240330-1 ii libglib2.0-0t64 2.80.2-2 ii libgstreamer-gl1.0-01.24.4-1 ii libgstreamer-plugins-bad1.0-0 1.24.4-2 ii libgstreamer-plugins-base1.0-0 1.24.4-1 ii libgstreamer1.0-0 1.24.4-1 ii libkdsingleapplication-qt6-1.0 1.0.0-2+b2 ii liblmdb00.9.31-1+b1 ii libolm3 3.2.16+dfsg-2 ii libqt6core6t64 [qt6-base-private-abi] 6.6.2+dfsg-8 ii libqt6dbus6 6.6.2+dfsg-8 ii libqt6gui6 6.6.2+dfsg-8 ii libqt6keychain1 0.14.3-1+b1 ii libqt6multimedia6 6.6.2-2 ii libqt6qml6 6.6.2+dfsg-3 ii libqt6quick66.6.2+dfsg-3 ii libqt6svg6
Bug#1073294: plasma-settings uses excessive CPU time when doing nothing
Hi, thank you for taking a look into plasma-settings and spending the time to analyse the situation so deeply. As for all issues related to Qt5/KF5/Plasma5, we are unlikely to get any support by upstream developers, as their workforce is limited and focused on Plasma6. On Debian side, the Debian Qt/KDE team has been working a lot in last months to package the stack needed to get Plasma6 into the archive. As far as I see, up-to-date situation has Qt6.6 in sid, hopefully transitioning soon to trixie, while KF6 is being prepared in experimental. After KF6 is uploaded to sid, it should be possible to package new version of plasma-settings. As you pointed out, the root of this issue could be either in plasma-settings, either in plasma-mobile. For the latter to be packaged in its 6.x version, it will also take plasma-workspace and similar packages to be prepared by the Qt/KDE team. Hopefully a matter of few months... To summarize, I suggest to get back to this analysis when we have both plasma-settings and plasma-mobile in their up-to-date releases in Debian. It's likely that the issue is not there anymore in new releases, as Plasma6 was a major rewrite and they addressed a lot of issues in the meanwhile... Kind regards Marco
Bug#1072687: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian
Am 11.06.2024 um 09:21:55 Uhr schrieb pham...@bluewin.ch: > Tell me exactly which log you need to solve this problem ? Please enable trace logging in NetworkManager. The dmesg doesn't show anything unusual at the first view. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/introduction-to-networkmanager-debugging_configuring-and-managing-networking#temporarily-setting-log-levels-at-run-time-using-nmcli_introduction-to-networkmanager-debugging nmcli general logging level TRACE domains ALL Then use journalctl -u NetworkManager -b -- Gruß Marco Send unsolicited bulk mail to 1718090515mu...@cartoonies.org
Bug#1054393: Informational: stable/bookworm/12, ...: #1072035 Re: Bug#1054393: dns-root-data: New IPs for b.root-servers-net
On Jun 08, Santiago Ruano Rincón wrote: > > For oldstable bullseye 11 ... > > I'm not spotting it yet on: > > https://release.debian.org/proposed-updates/oldstable.html > > But presumably that will occur via #1072035, etc. It has been uploaded a few days ago, it only needs to be approved. > I will handle the update dns-root-data for buster LTS and the ELTS > releases. Is there any objection to push the changes to the dns-team > repository? I am not sure. Anyway, please do not push to the debian/bullseye and debian/bookworm branches which are waiting to be pulled from my fork. -- ciao, Marco signature.asc Description: PGP signature
Bug#1072687: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian
Am 06.06.2024 um 16:30:16 Uhr schrieb pham...@bluewin.ch: > RJ-45 wired network does not start when booting Debian. > The problem occurs once for about ten successful starts, about once a > week for me. Attached is a screenshot of my workstation booting with > the problem described. Thanks in advance for trying to fix this. Without more information this isn't useful. Run dmesg when networking isn't successful and show the output. -- Gruß Marco Send unsolicited bulk mail to 1717684216mu...@cartoonies.org
Bug#1072516: "command -v" prints to the terminal
Package: mailcap Version: 3.71gg Severity: important X-Debbugs-Cc: jcris...@debian.org, anto...@debian.org Control: affects -1 mutt After upgrading mailcap, when opening a message with mutt I see strings like "/usr/bin/vim" and "/usr/bin/evince" printed in random places. Looks like it is caused by this change: 79285fc update-mime: convert .desktop file's TryExec to a test= field for the mailcap entry (Closes: #964173) On a more general note, I am not sure that it is a good idea to automatically add entries for text/plain since they cause a useless shell exec in mutt every time a message is opened (maybe the mutt maintainer can add some insight?). -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.11-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 mailcap depends on: ii media-types 10.1.0 ii perl 5.38.2-5 Versions of packages mailcap recommends: ii bzip2 1.0.8-5.1 ii file 1:5.45-3 ii xz-utils 5.6.1+really5.4.5-1 mailcap suggests no packages. -- Configuration Files: /etc/mailcap.order changed [not included] -- no debconf information -- ciao, Marco signature.asc Description: PGP signature
Bug#1072035: bookworm-pu: package dns-root-data/2024041801
On May 30, Emilio Pozuelo Monfort wrote:
> This looks reasonable to me. Should a similar update be proposed for bullseye?
Yes, uploaded.
diff --git a/debian/changelog b/debian/changelog
index 97fdbf8..98e603c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,28 @@
+dns-root-data (2024041801) unstable; urgency=medium
+
+ * Add myself to the Uploaders field, as discussed with Ondřej.
+ * Fix the package description. (Closes: #1064829)
+ * Update the expired Verisign GRS PGP key.
+ * Update the root hints file to version 2024041801, with:
++ updated A and records for B. (Closes: #1054393)
+
+ -- Marco d'Itri Tue, 21 May 2024 16:25:44 +0200
+
+dns-root-data (2023010101) unstable; urgency=medium
+
+ * merge current root hints and signatures (same contents as before)
+ * d/copyright: bump to 2023
+
+ -- Daniel Kahn Gillmor Wed, 11 Jan 2023 10:00:11
-0500
+
+dns-root-data (2022120101) unstable; urgency=medium
+
+ * Updated upstream root data (same contents as before)
+ * d/copyright: update for 2022
+ * Standards-Version: bump to 4.6.1 (no changes needed)
+
+ -- Daniel Kahn Gillmor Tue, 20 Dec 2022 18:51:44
-0500
+
dns-root-data (2021011101) unstable; urgency=medium
* updated upstream root data (same contents as before)
diff --git a/debian/control b/debian/control
index ac3736a..cd14d8a 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Priority: optional
Maintainer: dns-root-data packagers
Uploaders:
Daniel Kahn Gillmor ,
+ Marco d'Itri ,
Ondřej Surý ,
Robert Edmonds ,
Build-Depends:
@@ -13,7 +14,7 @@ Build-Depends:
openssl,
unbound-anchor,
xml2,
-Standards-Version: 4.5.1
+Standards-Version: 4.7.0.0
Homepage: https://data.iana.org/root-anchors/
Vcs-Git: https://salsa.debian.org/dns-team/dns-root-data.git
Vcs-Browser: https://salsa.debian.org/dns-team/dns-root-data
@@ -24,7 +25,7 @@ Architecture: all
Multi-Arch: foreign
Depends:
${misc:Depends},
-Description: DNS root data including root zone and DNSSEC key
+Description: DNS root hints and DNSSEC trust anchor
This package contains various root zone related data as published
by IANA to be used by various DNS software as a common source
of DNS root zone data, namely:
diff --git a/debian/copyright b/debian/copyright
index 83463f6..d389c35 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -3,7 +3,7 @@ Upstream-Name: IANA Root Zone Management
Source: https://www.iana.org/domains/root/files
Files: *
-Copyright: Copyright (c) 2010-2018 Internet Corporation For Assigned Names and
Numbers
+Copyright: Copyright (c) 2010-2023 Internet Corporation For Assigned Names and
Numbers
License: ICANN-Public
ICANN asserts no property rights to any of the IANA registries or
public keys we maintain. You are free to redistribute the IANA
@@ -14,7 +14,7 @@ License: ICANN-Public
Files: debian/*
Copyright: 2014 Ondřej Surý ,
- 2018 Daniel Kahn Gillmor
+ 2018-2023 Daniel Kahn Gillmor
License: Expat
License: Expat
diff --git a/registry-admin.key b/registry-admin.key
index 9c0fb78..22f087a 100644
Binary files a/registry-admin.key and b/registry-admin.key differ
diff --git a/root-anchors.p7s b/root-anchors.p7s
index ff40c7a..fc6cd07 100644
Binary files a/root-anchors.p7s and b/root-anchors.p7s differ
diff --git a/root.hints b/root.hints
index 6d39aad..f0a0934 100644
--- a/root.hints
+++ b/root.hints
@@ -8,9 +8,9 @@
; file/domain/named.cache
; on server FTP.INTERNIC.NET
; -OR-RS.INTERNIC.NET
-;
-; last update: January 11, 2021
-; related version of root zone: 2021011101
+;
+; last update: April 18, 2024
+; related version of root zone: 2024041801
;
; FORMERLY NS.INTERNIC.NET
;
@@ -21,8 +21,8 @@ A.ROOT-SERVERS.NET. 360
2001:503:ba3e::2:30
; FORMERLY NS1.ISI.EDU
;
.360 NSB.ROOT-SERVERS.NET.
-B.ROOT-SERVERS.NET. 360 A 199.9.14.201
-B.ROOT-SERVERS.NET. 360 2001:500:200::b
+B.ROOT-SERVERS.NET. 360 A 170.247.170.2
+B.ROOT-SERVERS.NET. 360 2801:1b8:10::b
;
; FORMERLY C.PSI.NET
;
diff --git a/root.hints.sig b/root.hints.sig
index 389c1ac..630ff8a 100644
Binary files a/root.hints.sig and b/root.hints.sig differ
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1072035: bookworm-pu: package dns-root-data/2024041801
On May 27, Jonas Meier wrote:
> [ ] attach debdiff against the package in (old)stable
diff -Nru dns-root-data-2023010101/debian/changelog
dns-root-data-2024041801~deb12u1/debian/changelog
--- dns-root-data-2023010101/debian/changelog 2023-01-11 16:00:11.0
+0100
+++ dns-root-data-2024041801~deb12u1/debian/changelog 2024-05-30
14:02:49.0 +0200
@@ -1,3 +1,19 @@
+dns-root-data (2024041801~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm. (Closes: #1072035)
+
+ -- Marco d'Itri Thu, 30 May 2024 14:02:49 +0200
+
+dns-root-data (2024041801) unstable; urgency=medium
+
+ * Add myself to the Uploaders field, as discussed with Ondřej.
+ * Fix the package description. (Closes: #1064829)
+ * Update the expired Verisign GRS PGP key.
+ * Update the root hints file to version 2024041801, with:
++ updated A and records for B. (Closes: #1054393)
+
+ -- Marco d'Itri Tue, 21 May 2024 16:25:44 +0200
+
dns-root-data (2023010101) unstable; urgency=medium
* merge current root hints and signatures (same contents as before)
diff -Nru dns-root-data-2023010101/debian/control
dns-root-data-2024041801~deb12u1/debian/control
--- dns-root-data-2023010101/debian/control 2022-12-21 00:52:11.0
+0100
+++ dns-root-data-2024041801~deb12u1/debian/control 2024-05-21
16:25:42.0 +0200
@@ -4,6 +4,7 @@
Maintainer: dns-root-data packagers
Uploaders:
Daniel Kahn Gillmor ,
+ Marco d'Itri ,
Ondřej Surý ,
Robert Edmonds ,
Build-Depends:
@@ -13,7 +14,7 @@
openssl,
unbound-anchor,
xml2,
-Standards-Version: 4.6.1
+Standards-Version: 4.7.0.0
Homepage: https://data.iana.org/root-anchors/
Vcs-Git: https://salsa.debian.org/dns-team/dns-root-data.git
Vcs-Browser: https://salsa.debian.org/dns-team/dns-root-data
@@ -24,7 +25,7 @@
Multi-Arch: foreign
Depends:
${misc:Depends},
-Description: DNS root data including root zone and DNSSEC key
+Description: DNS root hints and DNSSEC trust anchor
This package contains various root zone related data as published
by IANA to be used by various DNS software as a common source
of DNS root zone data, namely:
Binary files /tmp/osYYJAlpQA/dns-root-data-2023010101/registry-admin.key and
/tmp/1ohQbBsBE0/dns-root-data-2024041801~deb12u1/registry-admin.key differ
diff -Nru dns-root-data-2023010101/root.hints
dns-root-data-2024041801~deb12u1/root.hints
--- dns-root-data-2023010101/root.hints 2023-01-11 08:22:00.0 +0100
+++ dns-root-data-2024041801~deb12u1/root.hints 2024-05-21 16:25:42.0
+0200
@@ -9,8 +9,8 @@
; on server FTP.INTERNIC.NET
; -OR-RS.INTERNIC.NET
;
-; last update: January 01, 2023
-; related version of root zone: 2023010101
+; last update: April 18, 2024
+; related version of root zone: 2024041801
;
; FORMERLY NS.INTERNIC.NET
;
@@ -21,8 +21,8 @@
; FORMERLY NS1.ISI.EDU
;
.360 NSB.ROOT-SERVERS.NET.
-B.ROOT-SERVERS.NET. 360 A 199.9.14.201
-B.ROOT-SERVERS.NET. 360 2001:500:200::b
+B.ROOT-SERVERS.NET. 360 A 170.247.170.2
+B.ROOT-SERVERS.NET. 360 2801:1b8:10::b
;
; FORMERLY C.PSI.NET
;
Binary files /tmp/osYYJAlpQA/dns-root-data-2023010101/root.hints.sig and
/tmp/1ohQbBsBE0/dns-root-data-2024041801~deb12u1/root.hints.sig differ
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On May 28, Andreas Metzler wrote: > I think it is bad choice to deliberately have different behavior for > freshly installed and upgraded systems. Offering upgrades has always > been one of the major selling points of Debian, and imho this > implicitely includes that you do not get a worse or second class Debian > installation when you upgrade it than if you installed from scratch. I strongly disagree: it is a bad choice to change on upgrades a default which may cause data loss. -- ciao, Marco signature.asc Description: PGP signature
Bug#1071601: python3-setuptools: Prefix is not exactly honored when installing with --prefix
Oh, actually an even more conservative approach can be by also honoring the DEB_PYTHON_INSTALL_LAYOUT env variable, because if that is set it should have the priority so that `lib/python3/dist-packages` is used instead of `lib/python3.XX/site-packages` setuptools-support-explicit-setup-install-v2.patch Description: Binary data
Bug#1071601: (no subject)
Control: tags 1071601 patch Adding a patch that fixes this issue by using the `posix_prefix` schema when the install prefix is explicitly requested setuptools-support-explicit-setup-install.patch Description: Binary data
Bug#1071601: python3-setuptools: Prefix is not exactly honored when installing with --prefix
Package: python3-setuptools
Version: 68.1.2-2
Severity: important
X-Debbugs-Cc: none, ma...@ubuntu.com
Dear Maintainer,
In a simple distutils project:
$ cat hello
#!/usr/bin/env python3 print("Hello world")
$ cat setup.py
from distutils.core import setup
setup(name='hello', scripts=['hello'])
Installing it with --prefix is not fully honored, as "local" is always
added (--root is optional, used just to make the reproducer easier):
$ python3 setup.py install --root=/tmp/py-root --prefix=/opt/py-prefix
$ find /tmp/py-root/
/tmp/py-root/
/tmp/py-root/opt
/tmp/py-root/opt/py-prefix
/tmp/py-root/opt/py-prefix/local
/tmp/py-root/opt/py-prefix/local/bin
/tmp/py-root/opt/py-prefix/local/bin/hello
/tmp/py-root/opt/py-prefix/local/lib
/tmp/py-root/opt/py-prefix/local/lib/python3.12
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/dependency_links.txt
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/SOURCES.txt
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/top_level.txt
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/PKG-INFO
In fact in such case everything should be installed in
/tmp/py-root/opt/py-prefix prefix and not
/tmp/py-root/opt/py-prefix/local since a prefix is explicitly defined
and so there's no point to add an extra "/local" subpath.
---
In between the others, this breaks jhbuild builds as a test fails for
this specific reason (see bug #1054720 where the missing file is due to
the fact that it gets installed to $PREFIX/local/bin instead of $PREFIX/bin).
---
After some debugging of it, this related to the default scheme change
happened with python3.10 [1] which meant to always use /usr/local as
default and ensure that one should explicitly require for /usr prefix,
but in the case that --prefix= is used, the user request is now ignored because:
- /usr/lib/python3.*/_distutils_system_mod.py:
1. Selects the scheme `posix_prefix` since we've requested a prefix
explicitly
- /usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py
1. Calls sysconfig.get_preferred_scheme("prefix") that now as per the said
change would return by default `posix_local` unless we're building a
debian package.
2. Replaces the variables to use the `posix_local` scheme
So, in order to fix this we may in theory change python3 packages to
make 1. to select another defined prefix say `posix_explicitprefix`, and
then making `sysconfig.get_preferred_scheme("explicitprefix")` to
instead return `posix_prefix`, but that would not be correct, because
being that a public API it should only support the allowed input
arguments for it ("prefix", "home" or "user").
As per this, I feel the best way to handle this is instead in the
setuptools module so that we can check once again if --prefix has been
used and react accordingly.
[1] https://lists.debian.org/debian-python/2022/03/msg00039.html
[2] https://bugs.launchpad.net/ubuntu/+source/python3.10/+bug/1967920
Bug#1070974: network-manager-gnome: do not show local ethernet connection
Am Sun, 12 May 2024 10:52:01 +0200 schrieb Valerio : > ifconfig in the console show regular 'enp5s0' device with its IP > 192.168.1.11 and all computer communication work as expected > > clicking on Network Manager icon, show only Wireless networks > right clicking the icon, Network and WiFi are enabled. > right clicking the icon and choosing Network information, show only > 'lo' network with its IPv4 127.0.0.1 and IPv6 ::1/128 right clicking > the icon and choosing Change connections, the list include Ethernet > and WiFi, but Ethernet has indication of 3 months ago last connection > also adding a new Ethernet with right 'enp5s0' device, DHCP and so > on, and saving, the new connection appear but say never connected, > and doesn't appear in the applet icon > > In the past I remember I can connect and disconnect from ethernet > connection Most likely the connection is not manages by NM. Run nmcli device If it is configured in /etc/network/interfaces, NM won't manage it, so comment the config out for that interface if you want to use it in NM.
Bug#1033012:
On Jan 12, Yangfl wrote: > Please kindly check 2.3.4-1 to see if that fixed your problem. It does not. The problem is that TasksMax in miniupnpd.service is set too low. Set it to something like 10, because it makes no sense to count every single process and it is hard anyway when spawning shell scripts. -- ciao, Marco signature.asc Description: PGP signature
Bug#1070472: Uses the obsolete /sbin/route without a dependency
Package: miniupnpd
Version: 2.3.1-1
Severity: serious
Tags: patch
Pseudo-patch for miniupnpd.config:
- MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C /sbin/route | grep -m 1 default
| awk -- '{ print $8 }')
+ MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C ip -o route show | sed -nre
'/^default /s/^default .*dev ([^ ]+).*/\1/p')
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1036908: expect: Broken use of \c in man page
On May 29, Helge Kreutzmann wrote: > The usage of \c is in mkpasswd(1) is incorrect. It fails when trying > to use po4a to provide translations of the man pages. Im currently > "patching around this" in manpages-l10n. > > For a full explanation of the problem (the man page is different, but > the problem is the same) see Debian #1036826 and the explanations by I have read #1036826 and tested multiple proposed solutions but I could not managed to reproduce the original output. Are you able to propose a patch which does not change the generated man page? > Bjarni, especially in message #25. That solution has been rejected by Branden. -- ciao, Marco signature.asc Description: PGP signature
Bug#1070190: (no subject)
> I have patched sendmail in order to enable O RejectNUL=True directive, Is that already included in 8.18.1? A grep over all files shows _FFR_REJECT_NUL_BYTE. > but I do not achieved the fact to enable it by default. What was the reason for that? -- kind regards Marco Send unsolicited bulk mail to 1714574365mu...@cartoonies.org
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
On Apr 26, Michael Tokarev wrote: > So, should I disable module utils in busybox-udeb now? I think so. > Is kmod udeb ready and used in d-i already, or does it need some > prep first? AFAIK it works. -- ciao, Marco signature.asc Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
On Jan 06, Michael Tokarev wrote: > Yes, some utils in busybox aren't as good as regular implementations. For Yes. Nowadays kmod has many more features related to compressed modules and verification of signatures. Can we agree that kmod should provide these programs for d-i? Or can the d-i maintainers just tell us what they want? -- ciao, Marco signature.asc Description: PGP signature
Bug#1068446: /usr/lib/x86_64-linux-gnu/libetpan.so.20: compile-time options maybe make Claws Mail crash
Package: libetpan20t64 Version: 1.9.4-3.2+b3 Severity: normal File: /usr/lib/x86_64-linux-gnu/libetpan.so.20 Dear Maintainer, Claws Mail links against libetpan. Sometimes it crashes. According to the developers this is caused by libetpan compiled without --with-poll https://lists.claws-mail.org/pipermail/users/2024-March/032788.html https://lists.claws-mail.org/pipermail/users/2024-March/032769.html Maybe this is related to #754729 *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libetpan20t64:amd64 depends on: ii libc6 2.37-15.1 ii libdb5.3t64 5.3.28+dfsg2-6 ii libgnutls30t64 3.8.4-2 ii liblockfile11.17-1+b1 ii libsasl2-2 2.1.28+dfsg1-6 libetpan20t64:amd64 recommends no packages. libetpan20t64:amd64 suggests no packages. -- no debconf information
Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack
On Apr 04, Salvatore Bonaccorso wrote: > While I do agree (and it was filled with this severity), the bug > severity would not be RC, varnish currently seem to lack active > maintainership. Not anymore: https://salsa.debian.org/md/varnish/ . -- ciao, Marco signature.asc Description: PGP signature
Bug#782691: varnishncsa sometimes does not start after reboot
On Apr 16, Oskar Liljeblad wrote: > varnishncsa sometimes does not start after reboot. > I suspect varnishncsa fails because it cannot contact varnish, which has not > started completely yet. This bug is 9 years old: can you still reproduce it? -- ciao, Marco signature.asc Description: PGP signature
Bug#1068311: tcp-wrappers: Can anything be done to avoid the libnsl dependency?
On Apr 03, Colin Watson wrote: > I wondered if anything could be done to avoid this or refactor it > somehow? Sure: I think that it makes sense to just disable NETGROUP (which is the conditional for yp_get_default_domain), because I do not think that anybody in 2024 still uses NIS and if they do then we are only doing them a favour by disabling netgroups support here. -- ciao, Marco signature.asc Description: PGP signature
Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack
Control: found -1 5.0.0-1 Control: fixed -1 7.4.2 On Nov 17, Salvatore Bonaccorso wrote: > CVE-2023-44487[0]: > | The HTTP/2 protocol allows a denial of service (server resource > | consumption) because request cancellation can reset many streams > | quickly, as exploited in the wild in August through October 2023. Fixing this issue would require backporting a significant amount of new features in varnish and I do not believe that it would be practical. I am inclined to downgrade this bug because: - this is just a DoS attack - it only concerns people using hitch for TLS termination instead of a full web server like nginx or haproxy nginx in stable is also vulnerable, BTW. -- ciao, Marco signature.asc Description: PGP signature
Bug#1068184: RM: gup -- ROM; popcon 0
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gup User: ftp.debian@packages.debian.org Usertags: remove As much as I like retrocomputing, let's not waste space in the archive. -- ciao, Marco signature.asc Description: PGP signature
Bug#1067932: usrmerge is dangerous : lost bash and other commands
On Mar 29, Denis Migdal wrote: > Maybe I was better off reinstalling, indeed, but I prefer to properly > plan/prepare for it. This is why the conversion procedure stopped. Then you started thinkering with your system to "fix" it and did worse. > It'd help me if, at least, usrmerge printed the number of duplicates and sym > links. Maybe with a more explicit error message, indicating what to do, "we > strongly advise to reinstall your system", "remove duplicates, but be > careful of symlinks", or whatever. This does not happen frequently enough (only you reported this) to justify investing development resources. -- ciao, Marco signature.asc Description: PGP signature
Bug#987013: Release goal proposal: Remove Berkeley DB
On Sat, 4 Feb 2023 08:50:29 +0100 Paul Gevers wrote: > > Remove Berkeley DB (finally) > > Sure. But I agree with several readers of this bug that there should > be a plan. We shouldn't kill it until the users are able to sanely > move away from it. I doubt that will happen automatically, so > somebody needs to organize it. Is there a reason against switching to this fork under the old license? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010965 There are still applications using bdb by default and that means there should be tools to read and edit them for the next years to support a migration.
Bug#1029826: (no subject)
Update on this: The issue was the way I started the application. I run sol & in xterm and then Hit Ctrl+D. That makes STDOUT unavailable and that seems to cause that schema exception. -- kind regards Marco Send unsolicited bulk mail to 17109193364mu...@cartoonies.org
Bug#1067412: sendmail: Add DANE compile time option
Package: sendmail Version: 8.18.1-2 Severity: wishlist Dear Maintainer, can you include the compile time option -DDANE in an experimental build? That enables DANE support in the compiled binary. Although, DANE must be enabled in the .mc confiuration if needed, so it should not affect users who don't want it.
Bug#1066092: koko: please enable blhc-recommended build hardening
Hi, thank you for the report. I believe this is not a bug in koko: can you please check the build log against blhc 0.14 (not yet in Debian)? Background is [1]. Kind regards Marco [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043522
Bug#1041552: HFS/HFS+ are insecure
On Mar 13, Michael Biebl wrote: > > So I propose this content for a file like > > /usr/lib/udev/rules.d/75-insecure-fs.rules: > Just curious: Why did you pick priority 75? I can't remember. -- ciao, Marco signature.asc Description: PGP signature
Bug#1066420: sendmail: FTBFS: ./debian/./debian/conftest.c:37:(.text.startup+0xb): undefined reference to `__res_query'
Am 13.03.2024 um 13:05:34 Uhr schrieb Lucas Nussbaum: > Source: sendmail > Version: 8.18.1-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Sendmail" | #define PACKAGE_TARNAME "sendmail" | #define PACKAGE_VERSION "8.17.1" | #define PACKAGE_STRING "Sendmail 8.17.1" | #define PACKAGE_BUGREPORT "bug/reportbug or sendm...@packages.debian.org" | #define PACKAGE_URL "" | #define PACKAGE "sendmail" | #define VERSION "8.17.1" Is there something wrong with the version numbers? -- kind regards Marco Send spam to 1710331534mu...@cartoonies.org
Bug#1066094: squidguard: Squidguard does not work with default squid apparmor profile
> I think we need an apparmor config file for squidguard. I suppose the same. Surely better then adding squidguard data to the squid apparmor profiles, as suggested by ubuntu bug. > I never have > written such a config, but perhaps you have an example of such a config > file? No, sorry: never done nothing on apparmor before this; to disable the profile i've simply followed the debian wiki: https://wiki.debian.org/AppArmor/HowToUse > Otherwise I need some time for testing to resolve this problem. If you provide some test apparmor profile i can try it and provide feedback. Thanks to you!
Bug#1066094: squidguard: Squidguard does not work with default squid apparmor profile
Package: squidguard Version: 1.6.0-2 Severity: normal Dear Maintainer, i've tried to use as 'usual' squidguard in my squid configuration, but squid simply start filling logs (syslog and squid's cache.log) with: 2024/03/01 14:22:59 kid1| Starting new helpers 2024/03/01 14:22:59 kid1| helperOpenServers: Starting 1/10 'squidGuard' processes 2024/03/01 14:22:59 kid2| ipcCreate: /usr/bin/squidGuard: (13) Permission denied 2024/03/01 14:22:59 kid2| WARNING: redirector #Hlpr175 exited after fiddling a bit, i've found that the guilty is apparmor squid profile (so, i've not clear if this is a squidguard or a squid bug, indeed ;-). I've simply done: aa-disable /etc/apparmor.d/usr.sbin.squid and now squid (and squidguard) run as expected. I've also looked around and seems that there's an ubuntu bug opened: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1787409 Thanks. -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 squidguard depends on: ii debconf [debconf-2.0] 1.5.77 ii libc6 2.31-13+deb11u8 ii libdb5.3 5.3.28+dfsg1-0.8 ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1 Versions of packages squidguard recommends: ii liburi-perl 5.08-1 ii libwww-perl 6.52-1 ii squid4.13-10+deb11u3 Versions of packages squidguard suggests: pn ldap-utils pn squidguard-doc -- Configuration Files: /etc/squidguard/squidGuard.conf.default [Errno 2] File o directory non esistente: '/etc/squidguard/squidGuard.conf.default' -- debconf information: squidguard/dbreload: true
Bug#1064798: kmod: installs same filename to both bin and sbin
On Mar 09, ca...@allfreemail.net wrote: > I believe the fix is incomplete, because both /usr/bin/lsmod and > /usr/sbin/lsmod are still being created. Actually it has been this way at least since Debian 7. I will not break compatibility for no good reason. -- ciao, Marco signature.asc Description: PGP signature
Bug#1043522: blhc: Please allow -std=gnu++20 inside bin/blhc:L1114 regex exception
Hi Simon, thank you for taking care of this. I can confirm that, using latest build log I have at hand, blhc from Debian repo outputs false positives, while blhc 0.14 built from git outputs nothing. Kind regards Marco On Wed, 28 Feb 2024 09:50:20 +0100 Simon Ruderich wrote: > Hi Marco, > > sorry for the late response. > > On Sat, Aug 12, 2023 at 02:14:37PM +0200, Marco Mattiolo wrote: > > Dear Maintainer, > > > > while building an app (Calindori, calendar for Plasma mobile) to be included > > in Debian, I found what I think is an issue with blhc: in [1] it is found > > > > |/usr/lib/ccache/c++ -std=gnu++20 -dM -E -c > > /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp| > > This is now fixed in blhc [1] [2]. > > Best, > Simon > > [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=766e4499437c6e872cc5870a821c4d10d2d8a63b > [2]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=33f9f4721b73fb4789bff5670cbde41b23071106 > -- > + privacy is necessary > + using gnupg http://gnupg.org > + public key id: 0x92FEFDB7E44C32F9
Bug#1061516: Please add a sshd@.service template for socket activation
On Mar 04, Colin Watson wrote: > Does this patch look workable? It mostly just resurrects the template > unit we used to ship, under a different name. Looks good to me! -- ciao, Marco signature.asc Description: PGP signature
Bug#1065192: RM: gortr -- ROM; abandoned by upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: go...@packages.debian.org Control: affects -1 + src:gortr User: ftp.debian@packages.debian.org Usertags: remove Development of cfrpki and gortr has been discontinued by the upstream maintainers, so there is no reason to keep them in Debian. Users can migrate to rpki-client and stayrtr as suggested by upstream. Another bug has been filed for removal of cfrpki. -- ciao, Marco signature.asc Description: PGP signature
Bug#1065191: RM: cfrpki -- ROM; abandoned by upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: cfr...@packages.debian.org Control: affects -1 + src:cfrpki User: ftp.debian@packages.debian.org Usertags: remove Development of cfrpki and gortr has been discontinued by the upstream maintainers, so there is no reason to keep them in Debian. Users can migrate to rpki-client and stayrtr as suggested by upstream. Another bug has been filed for removal of gortr. -- ciao, Marco signature.asc Description: PGP signature
Bug#1061516: Please add a sshd@.service template for socket activation
On Jan 25, Marco d'Itri wrote: > systemd currently expects the template to be named sshd@.service > (because that is what Fedora uses), but if you prefer to keep the > ssh@.service name then I suppose that we could patch systemd as well. Is there any way I can help with this? The major issue is deciding how you want the template to be called. -- ciao, Marco signature.asc Description: PGP signature
Bug#1064849: dh-exec: Renaming a file using ${env:VARIABLE} substitution does not work
It's worth mentioning that using ${FOO_INSTALL_PATH} instead works, but
I feel it would be better to also support debhelper's ${env:VARIABLE}
format as it's a bit safer.
I'm unsure if that would break further debhelper substitutions, but I
feel that some cases like this could be handled better to have a more
consistent behavior with recent dh.
Bug#1064849: dh-exec: Renaming a file using ${env:VARIABLE} substitution does not work
Package: dh-exec
Version: 0.27
Severity: normal
X-Debbugs-Cc: ma...@ubuntu.com
Dear Maintainer,
When using dh-exec to rename a file using a path provided as variable in
debian/rules such as:
usr/bin/foo-bin => ${env:FOO_INSTALL_PATH}/foo
Does not work and I get this failure:
with FOO_INSTALL_PATH := /usr/libexec/
dh_install: warning: Cannot find (any matches for)
"debian/tmp/dh-exec.RyaTa0ew//usr/libexec/foo" (tried in ., debian/tmp)
dh_install: warning: foo-package missing files:
debian/tmp/dh-exec.RyaTa0ew//usr/libexec/foo
dh_install: error: missing files, aborting.
In fact in debian/tmp I have:
debian/tmp/dh-exec.RyaTa0ew/${env:FOO_INSTALL_PATH}
debian/tmp/dh-exec.RyaTa0ew/${env:FOO_INSTALL_PATH}/foo
The replacement works fine when using normal debhelper syntax and so
when not using `=>` to rename.
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
LANGUAGE=it_IT:en_US:en
Shell: /bin/sh linked to /usr/bin/dash
LSM: AppArmor: enabled
Versions of packages dh-exec depends on:
ii debhelper 13.14.1ubuntu1
ii perl 5.38.2-3
dh-exec recommends no packages.
dh-exec suggests no packages.
Bug#1064829: Shot description of package is misleading and/or confusing
Package: dns-root-data Version: 2023010101 Severity: minor Dear Maintainers, The description of the dns-root-data package is: "DNS root data including root zone and DNSSEC key" However, I believe this is beside the truth. The root zone itself is not included. Only the root.hints file (and the root trust anchor) is. The full description formulates it already somewhat better: "This package contains various root zone related data" My sugestion is to improve the description of the package. -- 𝑴𝒂𝒓𝒄𝒐 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064798: kmod: installs same filename to both bin and sbin
On Feb 26, ca...@allfreemail.net wrote: > This causes a problem on a filesystem layout where bin and sbin are > merged into a single real directory, typically by sbin being a symlink > to bin. Such a filesystem layout has become standard on some > distributions now, and others are moving onto in their next releases. This is not supported by Debian and we have no such plans. But obviously it is still a bug, and I will fix in whenever I will do a new upload. -- ciao, Marco signature.asc Description: PGP signature
Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory
On Feb 12, Salvatore Bonaccorso wrote: > --with-module-directory=/usr/lib/modules > > Looping in Marco for comments. I can revert it if it causes too much trouble, but maybe this is just the right time to switch the kernel packages to /usr/lib/modules/ as well? Please let me know if I am missing anything... -- ciao, Marco signature.asc Description: PGP signature
Bug#1063508: ITP: node-long -- Class for representing 64-bit two's-complement integer value
Package: wnpp Severity: wishlist Owner: Marco Trevisan (Treviño) X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-long Version : 5.2.3 Upstream Author : Daniel Wirtz * URL : https://github.com/dcodeIO/long.js#readme * License : Apache-2.0 Programming Lang: JavaScript Description : Class for representing 64-bit two's-complement integer value A Long class for representing a 64 bit two's-complement integer value derived from the Closure Library for stand-alone use and extended with unsigned support. . This is a class used by various modules that does not use newer bigint. . Node.js is an event-based server-side JavaScript engine. This is a tiny module that is needed for protobufjs (bug #977564), although being widely used according to npm stats, I feel it's better to package it as standalone and not as grouped package. Salsa repository is at: https://salsa.debian.org/3v1n0-guest/node-esm2umd/-/tree/debian/latest Please mark the debian/latest as default branch since I can't change it myself. The package had a dependency on a very tiny project (esm2umd) that was just basically a tiny wrapper to babel. I've also prepared the packaging for it [1], but given that such project has not a clear license (I mailed the maintainer meanwhile), I preferred to avoid using it, also because it's really just a script using babel and I have been able to easily re-implement it, making the build process slightly bigger The package needs sponsor, since I'm only a maintainer, but I'll be happy keeping the maintenance of it. I've given access to the js salsa team. [1] https://salsa.debian.org/3v1n0-guest/node-esm2umd/
Bug#1063503: ERR_MODULE_NOT_FOUND when importing @babel/core in module
Package: node-babel7
Version: 7.20.15+ds1+~cs214.269.168-6
I'm trying to use a project that uses babel, importing it as a module as
stated on babel docs [1]:
However, when loading something as simple as:
❯ cat /tmp/foo.mjs
import { transform } from "@babel/core";
console.log(transform)
❯ node /tmp/babel.mjs
node:internal/process/esm_loader:40
internalBinding('errors').triggerUncaughtException(
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@babel/core' imported
from /tmp/babel.mjs
Did you mean to import @babel/core/lib/index.js?
at new NodeError (node:internal/errors:405:5)
at packageResolve (node:internal/modules/esm/resolve:916:9)
at moduleResolve (node:internal/modules/esm/resolve:973:20)
at defaultResolve (node:internal/modules/esm/resolve:1193:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:403:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:372:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:249:38)
at ModuleWrap. (node:internal/modules/esm/module_job:76:39)
at link (node:internal/modules/esm/module_job:75:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
Node.js v18.19.0
---
Now, using require("@babel/core") things work, but indeed, it (and its
plugisn) should work as ES modules too.
[1] https://babeljs.io/docs/babel-core
Bug#1063476: the sanesecurity configuration is not suitable for a release
Source: fangfrisch Version: 1.7.0-1 Severity: grave Tags: upstream Control: forwarded -1 https://github.com/rseichter/fangfrisch/issues/30 The sanesecurity section of default configuration, if enabled, relies on an unofficial HTTP mirror which is seriously overloaded and probably seriously expensive for their operators, since it is located in Australia. The only other known HTTP mirror is mentioned on https://wiki.gentoo.org/wiki/ClamAV_Unofficial_Signatures, with a vague note about it being available to the public. Until fangfrisch will implement rsync support, I do not think that it is safe to include fangfrisch in a Debian release due to the possible effect on unsuspecting third party mirrors. This has also been discussed upstream: https://github.com/rseichter/fangfrisch/issues/30 -- ciao, Marco signature.asc Description: PGP signature
Bug#1063253: python3 illegal opcode in Raspi 3B+
Am Mon, 5 Feb 2024 22:25:19 + schrieb Stefano Rivera : > Maybe alignment? > > My understanding is that STUR is not supposed to require aligned > access, though. How can I further diagnose that?
Bug#1031140: (no subject)
closed in current release in experimental. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039365#57
Bug#1061516: Please add a sshd@.service template for socket activation
Package: openssh-server Version: 1:9.6p1-3 Severity: normal Control: affects -1 systemd The next release of systemd will contain support to connect to the system with SSH over an AF_VSOCK socket: https://github.com/systemd/systemd/pull/30777/files The server side of this uses what Ubuntu currently ships as ssh@.service, i.e. a template for socket activation of per-connection sshd daemons. systemd currently expects the template to be named sshd@.service (because that is what Fedora uses), but if you prefer to keep the ssh@.service name then I suppose that we could patch systemd as well. -- ciao, Marco signature.asc Description: PGP signature
Bug#1054393: dns-root-data: New IPs for b.root-servers-net 2023-11-27
This is annoying and needs to be fixed in stable too. Do you want me to make a NMU? -- ciao, Marco signature.asc Description: PGP signature
Bug#1061178: usrmerge: Usrmerge fails with a staticly-linked cp command
On Jan 20, Ajax Dong wrote: > Days ago I upgraded one of my machines (I use sudo machinectl shell > network-service to get its shell) from Debian Buster to Debian Bookworm. > The cp and mv command on that machine was staticly-linked and > self-contained. (It does not require any shared library.) UseMerge This does not look like any Debian system I know. > Because /bin/cp is staticly linked, ldd exited with error, $fh is not Not on any of the Debian 10, 11 and 12 systems that I checked: md:~$ ldd /sbin/ldconfig statically linked md:~$ And this ldd output does not cause early_conversion_files() to fail. What's up then? -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
On Jan 10, Michael Biebl wrote: > While we could ship such a udev rule for udisks, I don't think it will > properly solve the issue. The device will still show up in nautilus, plasma > etc and mounting is just an additional click away. The threat model here is: somebody connects a crafted USB stick to a computer with a locked screen. Also, the listed file systems are not used or not used anymore on removable devices. Certainly not on removable devices used by regular users. -- ciao, Marco signature.asc Description: PGP signature
Bug#1060002: usrmerge: support working with a moved coreutils and policycoreutils
On Jan 04, Helmut Grohne wrote: > the way usrmerge works now prevents us from moving /bin/cp and > /sbin/restorecon to /usr for DEP17. I'm attaching a patch that makes > both of them movable and thus decouples their move from when base-files > switches. Do you have any objections? Please just describe in detail why these changes will be needed. -- ciao, Marco signature.asc Description: PGP signature
