Bug#982371: autopkgdest: warns that --force-yes is deprecated
On Mon, 29 Nov 2021 09:06:52 + Julian Gilbey wrote: > tags 982371 +patch > thanks > > On Tue, Feb 09, 2021 at 01:41:43PM +, Julian Gilbey wrote: > > Package: autopkgtest > > Version: 5.16 > > Severity: normal > > > > I tried running autopkgtest on a package I'm working on, and got the > > following messages: > > > > $ sudo autopkgtest > > /home/jdg/debian/spyder-packages/pytest-tornasync/build-area/pytest-tornasync_0.6.0+git20190716.9f1bdee-1_amd64.changes > > -- null > > [...] > > W: --force-yes is deprecated, use one of the options starting with --allow > > instead. > > Reading package lists... Done > > [...] > > > > The rest proceeded fine, and I have no idea where the "--force-yes" > > comes from. > > Well, I should have looked a bit harder; it is in > /usr/share/autopkgtest/lib/adt_binaries.py, line 121, in this command: > > rc = self.testbed.execute( > ['apt-get', '--quiet', '-o', 'Debug::pkgProblemResolver=true', > '-o', 'APT::Get::force-yes=true', > '-o', 'APT::Get::Assume-Yes=true', > '--reinstall', 'install'] + list(pkgs_reinstall), > kind='install')[0] > > The apt-get(8) manpage says: > >--force-yes >Force yes; this is a dangerous option that will cause apt to >continue without prompting if it is doing something potentially >harmful. It should not be used except in very special situations. >Using force-yes can potentially destroy your system! Configuration >Item: APT::Get::force-yes. This is deprecated and replaced by >--allow-unauthenticated , --allow-downgrades , >--allow-remove-essential , --allow-change-held-packages in 1.1. [...] We still support testbeds with apt (<< 1.1~exp1), so we'll have to live with the deprecation warning for now (it is not worth duplicating the code path to get rid of the warning IMHO). -- Paride
Bug#1071456: autopkgtest-virt-qemu: autopkgtest [15:14:50]: ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'
On 2024-05-20 17:55, Christian Kastner wrote: > Hi, > > On 2024-05-19 17:06, Wouter Verhelst wrote: >> Package: autopkgtest >> Version: 5.35 >> Severity: normal >> >>> sudo autopkgtest-build-qemu --architecture amd64 sid >>> /opt/chroots/autopkgtest-qemu.img >> >> followed by >> >>> autopkgtest . --test-name=initrd-boot -- qemu >>> /opt/chroots/autopkgtest-qemu.img >> >> in a directory that is a checkout of https://salsa.debian.org/wouter/nbd.git >> >> It installed the test dependencies, and then failed on: >> >>> autopkgtest [16:55:00]: Setting up user "user" to sudo without password... >>> qemu-system-x86_64: terminating on signal 15 from pid 150414 >>> (/usr/bin/python3) >>> autopkgtest [17:00:02]: ERROR: testbed failure: sent `auxverb_debug_fail', >>> got `timeout', expected `ok...' >> >> which I did not expect... > > I've also starting seeing this recently in the Debian ROCm Team's CI. > > In my case, this happens only with packages that have 2+ tests. When the > testbed is rebooted after the first test concludes, everything works > fine right until the "Setting up user "" to sudo without > password...", and then the timeout occurs. > > In our particular case, the tests first started failing on 2024-05-17. > This was still with autopkgtest 5.34, and nothing else changed in our > infra over the past few days. > > The test trigger we recorded was "linux-signed-amd64=6.8.9+1" but that > could just be coincidental. Hi, this seems to be the same of: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2056461 which turned out to be a kernel bug. If you want to verify that's actually the case, I suggest running autopkgtest --debug and checking that the timeout happens during a "copydown" operation. Paride
Bug#1055370: consider adding security repos by default
On Wed, 15 May 2024 19:26:52 +0200 Paul Gevers wrote: > Control: reassign -1 autopkgtest > > Hi Mathias, > > Sorry for letting this go unanswered for so long. > > On Sat, 10 Feb 2024 20:39:12 + Mathias Gibbens > wrote: > > I suspect debci is either adding options or directly generating a > > sources.list that is injected into the container. The word "debug" > > doesn't appear anywhere within the debian template script and I'm not > > sure how the "deb-src" lines could be introduced with the existing > > template logic. > > > > Maybe there's something else going on in lxc-templates, but I'm not > > seeing anything immediately obvious to explain where debci's > > sources.list is coming from. > > I didn't check the autopkgtest code yet, but I trust your assessment > it's not lxc-templates. Let's assign to autopkgtest for further checking > > Paul > PS: this reply was triggered by bug 1071185 As mentioned in #1071185, it is autopkgtest that configures the sources.list in the testbed images, via the setup-testbed script.
Bug#1071185: autopkgtest: setup-testbed should add -security to sources.list
Package: autopkgtest Version: 5.35 Severity: normal X-Debbugs-Cc: Debian Security Team When using autopkgtest-build-* tools that prepare autopkgtest images from pre-built images, sometimes we end up with images with dependency problems because the pre-built images come with packages from -security baked in. For example, at the moment the incus images:debian/bookworm/amd64 image contains this libc6: $ apt-cache policy libc6 libc6: Installed: 2.36-9+deb12u7 Candidate: 2.36-9+deb12u7 Version table: *** 2.36-9+deb12u7 500 500 http://deb.debian.org/debian-security bookworm-security/main amd64 Packages 100 /var/lib/dpkg/status 2.36-9+deb12u4 500 500 http://deb.debian.org/debian bookworm/main amd64 Packages Note that the installed version comes from bookworm-security. The setup-testbed script clears the existing sources (which would include -security) and only adds bookworm, which can cause installability problems of build or test dependencies. For example libc6-dev is uninstallable in the above situation, as the installed libc6 requires the libc6-dev version from -security, which is not available. This can be fixed by making setup-testbed add the security repository. This already happens when building Ubuntu images (there's code in setup-testbed to detect those), so this is a problem specific to Debian. If we agree this is a bug and on the solution, I'll prepare a MP with it. -- Paride
Bug#1071047: lxd: Please update the default URL for the images: remote
Package: lxd Version: Please update the default URL for the images: remote Severity: normal As of lxd 5.0.2+git20231211.1364ae4-4 the default URL for the images: remote is: https://images.linuxcontainers.org however that endpoint does not accept the LXD user-agent anymore [1]. The following URL should be used instead: https://images.lxd.canonical.com I am aware of #1058592, but hopefully this can fall into the "small tweaks" category you still plan to do for the package. Thanks! [1] https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479 -- Paride
Bug#960729: More issues trying to create an Ubuntu focal image
On 2024-04-11 08:35, Christian Kastner wrote: > Control: tags -1 - pending > > On 2024-04-08 15:21, Paride Legovini wrote: >> Fixed in master by: >> >> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/315 > > Sadly, it turns out that this wasn't the fix, at least not in a wider sense. > > Yes, images can be built now, but without ifupdown their network > interface is left unconfigured, and thus autopkgtests can't download > packages. > > With the move of ifupdown to universe, I was assuming that Ubuntu did > things differently. The cloud images *do* things differently, namely > they have systemd-networkd. But autopkgtest allows for alternative init > systems, so we can't rely on that. Ubuntu did indeed switch to something else: that's netplan.io. On a Bionic system: $ apt show netplan.io Package: netplan.io Version: 0.99-0ubuntu3~18.04.5 Priority: important and by running e.g. sudo tools/autopkgtest-build-qemu --mirror=http://archive.ubuntu.com/ubuntu/ jammy jammy-qemu.img I see it being installed, but left unconfigured. Now, when we have ifupdown, what is configuring it? It's setup-testbed: printf 'auto %s\niface %s inet dhcp\n' "$IFACE" "$IFACE" >> "$root/etc/network/interfaces.d/$IFACE" So we have another option: teach setup-testbed how to configure netplan. This basically consists in dropping a yaml under /etc/netplan containing something like: network: version: 2 renderer: networkd ethernets: eth0: dhcp4: yes This would be a more realistic setup for a modern Ubuntu system, and won't need any extra dependency outside of what debootstrap installs automatically. Or we could enable universe during debootstrap, install ifupdown and hope that it will keep playing fine with netplan, as you suggested. Maybe we should just take this simpler route, I am still unsure, input is welcome. Paride
Bug#1068588: redesign of how autopkgtest talks to the testbed
Hi Paul, On 2024-04-07 16:42, Paul Gevers wrote: > The following issues have come up several times over the years. I > propose to discuss them in one place (this bug report) to define the > solution strategy. I haven't gone through all the details myself, so > I might be thinking in the wrong direction, please correct me if you > think so. Please also voice agreement, if not on the details, then on > the general concept. > > Problem statements > == > > * runner/autopkgtest talks to the backend with a simple text > protocol. While this enables users to add another backend without > changes to the src:autopkgtest code trivially, the drawback of that > is loosing all nuance of what really is going on on both sides of the > communication. That is particularly bad when unexpected events > happen. All events need handling on both sides, including unexpected > events. However this simple text based protocol also has advantages: it makes it easy to repurpose the virt servers for other uses, like what sbuild does. These other projects do not need to be written in Python, or we could in principle have a virt-server not written in Python. > * every backend has its own virt server that does the real > communication with the testbed. A result of that is subtle > differences in test results between different backends when they > don't do exactly the same (code easily goes out of sync). > > * most backends don't automatically provide a testbed as a user would > see when working on a system. I recall smcv saying words like "user > session", "dbus something-something" and the like. +1 to these. > Solution direction > == > > * unify the communication with test beds via ssh. This ensures that > the environment is much more likely to be the same across the > different backends and also ensures the right session. I agree nowadays ssh is a reasonable common denominator. As you noted below, there are some virt servers where it doesn't apply well, but they are probably special enough to be treated differently. > * each virt server would only need to ensure an ssh server is setup > and running in the testbed and leaving the rest of the communication > to a common driver. (Maybe with the exception of the null, chroot and > schroot virt servers, to be investigated.) Obviously it's still > responsible for the tear down of the testbed. And there is also autopkgtest-virt-unshare (probably falling under the chroot category). I think standardizing on ssh is desirable, but this implicitly means that we'll have some more specific requirements for the testbed images (in random order: sshd, some sort pubkey authentication, a "normal" (non-root) user, cloud-init to initialize all these things?, ...). We are currently shipping tools to prepare test images (tools/autopkgtest-build*), but at the same time we are very flexible on the image requirements. Should we accept being more strict on this, and state that the virt server are meant to be used to purpose built images? Or should we have a better spec on what the virt servers expect from the image? Currently autopkgtest-virt-ssh works around this by using the "ssh setup" script, but my impression is that we want to move away from that kind of approach. > * handle communication between runner/autopkgtest and the virt > servers and the ssh driver via Python classes instead of the text > based protocol. Do this in a "plugin" friendly way such that backends > can still easily be used without changes to src:autopkgtest. > Alternatives > > > * make the change to use ssh for communication, without a change of > the virt server protocol. Do you think this can be done incrementally, that is: 1. modify the virt-servers we have to use ssh for communication with the testbed systems, keeping it in a common library. 2. keeping the implementation above, or most of it, also reimplement the autopkgtest<->backend communication protocol. The two problems should be quite decoupled after all, and while I'm convinced that point 2 is good, I am less sure about point 1, for the reasons I stated initially. > Open Questions > == > > * we could consider supporting the current protocol in parallel, > which would enable us to migrate one backend at a time and enable our > users to migrate their own backends at their own pace. However, it > means we'd need to support two code paths. So the open question is: > (how long) do we want to maintain the current protocol. I wonder how > many other backends are out there. Are we aware of any other consumer of the virt servers apart from autopkgtest itself and sbuild? > * we already have an ssh virtual server, is that good enough to be > the ssh driver, or is it missing functionality and/or deserves a > rewrite by itself? To answer the last question, probably yes if we > want to move away from the current protocol. I think we'll probably want a pure Python implementation of that, written using
Bug#960729: More issues trying to create an Ubuntu focal image
Control: tags -1 pending Fixed in master by: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/315
Bug#895570: devscripts: wrap-and-sort should default to -ast
On 2024-03-28 01:42, Otto Kekäläinen wrote: > The research done in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895570#50 looks good. > > Do we have now agreement to default to -ast or -astb for packages that have > Debhelper 14+? I don't think making w-a-s defaults depend on the debhelper compat level was considered, and I think we don't yet have a clear agreement on -st vs -ast. -- Paride
Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)
On 2024-03-12 00:33, Johannes Schauer Marin Rodrigues wrote: > Hi, > > On Wed, 6 Mar 2024 11:04:01 +0100 Paride Legovini wrote: >> On Sun, 03 Mar 2024 16:26:41 +0100 Benjamin Drung wrote: >>> Time to join this discussion. The current default was the preference of >>> the author 14 years ago. My taste has change a bit since then. I am open >>> to change the default. --trailing-comma for wrapped lines is a good >>> idea, --short-indent is okay. I don't like --wrap-always in case there >>> are only two or three entries. >>> >>> The new default should not only based on the preference, but also on >>> what is used the most. Can someone collect the information: which teams >>> use which options, how many packages use what? >> >> I did some unscientific research on codesearch looking for d/changelog >> entries >> mentioning `wrap-and-sort -` (i.e. wrap-and-sort with some options). This is >> the query: >> >> https://codesearch.debian.net/search?q=path%3Adebian%2Fchangelog+wrap-and-sort+-=1 >> >> Apparently -a is the single most used option, very often used together with >> -s and -t. I found similar results by searching GitHub: >> >> https://github.com/search?q=path%3Adebian%2Fchangelog+%22wrap-and-sort+-%22=code >> >> Looks like salsa (GitLab Free) doesn't allow to do instance-wide code >> searches. > > I disagree that the new default should be what is used the most. For example > debhelper versions do not become the default only after they are used the > most. > The thing that makes switching defaults easier for debhelper is the explicit > opt-in for a new debhelper compat version which we don't have for > wrap-and-sort > and I think it would very much be over-engineering to add such a feature for > something that is, in my opinion, of very little consequence. Furthermore, I > would not be surprised if many people using wrap-and-sort use the default > expecting that this is what is most well-liked by the project (because why > else > would it be the default?). The question was asked in this email sub-thread: > > https://lists.debian.org/161289428547.4135738.4002254931040787...@auryn.jones.dk > > In that thread, same as in this bug, -ast was proposed as the default and > unless I missed something, there were no objections on debian-devel. Some even > argued, to make -b the default as well. So instead of asking "what is used > most" I'd like to ask, are there users of wrap-and-sort without -ast who would > be strongly against having to pass -AST to overwrite a potential new default? > > That being said, I downloaded all debian/control files for all 36832 source > packages in Debian and ran the following shell script on them to figure out > how > many source packages comply with which wrap-and-sort set of options: > > for p in control/*; do > rm -f debian/control; > ln -s "../$p" debian/control; > for opt in "" -a -as -ast -astb -at -atb -ab -s -st -stb -sb -t -tb -b; > do > wrap-and-sort --dry-run --file=debian/control $opt \ > | grep --quiet debian/control \ > || echo $p >> w-a-s$opt; > done > done > > It's of course still not possible to say whether a control file adheres to a > certain wrap-and-sort formatting style by accident or intentionally. Also, > packages can easily fall in multiple categories at the same time, for example > packages with only a single binary package which comply with -ast will > automatically also comply with -astb. There are also packages which comply > with > -ast as well as with no options at all simply because they have no > Build-Depends nor Depends fields in debian/control. Here is the result sorted > by popularity in ascending order: > > 96 wrap-and-sort -st > 96 wrap-and-sort -stb >434 wrap-and-sort -as >465 wrap-and-sort -tb >489 wrap-and-sort -t >579 wrap-and-sort -atb >641 wrap-and-sort -at > 1341 wrap-and-sort -sb > 1405 wrap-and-sort -s > 2381 wrap-and-sort -astb > 2705 wrap-and-sort -ast > 2732 wrap-and-sort -b > 3020 wrap-and-sort > 3950 wrap-and-sort -ab > 4089 wrap-and-sort -a > > So, wrap-and-sort -ast is very popular but it is not as popular as the current > default. Hi josch and thanks for this analysis. I'll try to recap where we are at this point, focusing only on -ast (I'll ignore -bk here). 1. This bug (#895570) requests -ast to be the default. The proposal received mostly positive feedback, however bdrung doesn't like -a in case there are only two or three entries. He also thinks we should consider
Bug#1055438: kea: init-scripts not working
On 2023-11-06 02:56, Stefan Klein wrote: > I appreciate that you include init scripts and support init diversity. > > Unfortunately those script don't work as expected. I fixed them and made > them mimic the behaviour of the Systemd service files as closely as > possible. > > It would be nice if you could apply the attached patch to: [...] Hello Stefan, We are not really able to do much QA on the init scripts; what I can offer is a LGTM-level review, and your patch definitely ticks that box. I prepared a MR including your changes: https://salsa.debian.org/debian/isc-kea/-/merge_requests/53 CI passes, but CI only tests on the default init system, so don't trust that too much. Given that some time passed since when you submitted the patch, I'd appreciate your final green light on proceeding with the merge (here on the bts or on salsa, if you happen to have an account there). @Luigi: OTOH your patch does not appear to be complete. I suggest to resubmit it after Stefan's patch lands. Cheers, Paride
Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)
Hi Benjamin, On Sun, 03 Mar 2024 16:26:41 +0100 Benjamin Drung wrote: > Time to join this discussion. The current default was the preference of > the author 14 years ago. My taste has change a bit since then. I am open > to change the default. --trailing-comma for wrapped lines is a good > idea, --short-indent is okay. I don't like --wrap-always in case there > are only two or three entries. > > The new default should not only based on the preference, but also on > what is used the most. Can someone collect the information: which teams > use which options, how many packages use what? I did some unscientific research on codesearch looking for d/changelog entries mentioning `wrap-and-sort -` (i.e. wrap-and-sort with some options). This is the query: https://codesearch.debian.net/search?q=path%3Adebian%2Fchangelog+wrap-and-sort+-=1 Apparently -a is the single most used option, very often used together with -s and -t. I found similar results by searching GitHub: https://github.com/search?q=path%3Adebian%2Fchangelog+%22wrap-and-sort+-%22=code Looks like salsa (GitLab Free) doesn't allow to do instance-wide code searches. > When we change the default, the parameters to disable those again need > some short options. If we want short parameters for the --no- parameters I think the most sensible option are capital letters (e.g. -T for --no-trailing-comma). In [1] I added the --no- options using argparse.BooleanOptionalAction, which we won't be able to use if we also want short options (we'll need a full parser.add_argument() definition for each I believe). Less nice but not a deal breaker. As not all the people reading the bug may know, there is now a MR aiming at changing the defaults [2]. Cheers, Paride [1] https://salsa.debian.org/debian/devscripts/-/merge_requests/390 [2] https://salsa.debian.org/debian/devscripts/-/merge_requests/392
Bug#1045805: isc-kea: Fails to build source after successful build
Control -1 tags + confirmed On Sun, 13 Aug 2023 21:20:48 +0200 Lucas Nussbaum wrote: > This package fails to build a source package after a successful build > (dpkg-buildpackage ; dpkg-buildpackage -S). Thanks for this bug report. This is still the case in 2.4.1-2, the clean target leaves the source tree in a very dirty state, with many modified or deleted files. We don't have a low hanging fruit here, unfortunately. Paride
Bug#1065408: isc-kea: [INTL:pt] Portuguese translation - debconf messages
On 2024-03-04 01:30, Américo Monteiro wrote: > Updated Portuguese translation for isc-kea's debconf messages > Translator: Américo Monteiro Hello Américo and thanks for the translation. Did you have the translation proofread by anybody from debian-l10n-portuguese? That's normally done via RFR requests ([1] is a random example), but we would be happy with any other review process. Cheers, Paride [1] https://lists.debian.org/debian-l10n-portuguese/2023/11/msg00011.html
Bug#1065362: kea-dev: kea-message-compiler is missing from kea-dev package and is needed for building message files
Control: tags -1 + pending On 2024-03-03 13:14, Quentin Armitage wrote: > kea-dev should be updated to include > /usr/bin/kea-message-compiler Hello Quentin and thanks for this bug report. I have a branch up which enables building kea-msg-compiler. Salsa CI is currently broken so I didn't open a MR yet, but it will come soon. The change will land in the current Debian development release (and so in the next stable release, Trixie). I am not sure the fix is suitable for an update to Debian stable, given that it is more of a feature request than of a bug fix. OTOH, given that the fix consists in adding a component that was not present before, the the regression potential is very little. I'll ask what the other Kea maintainers think. In any case first we need to fix the devel release. -- Paride
Bug#1061769: Unexpected VLAN behavior with KEA DHCP
Control: tags -1 + wontfix On 2024-01-29 15:27, kristofer.hans...@icomera.com wrote: > Package: kea-dhcp4-server > Version: 2.2.0-6 > > Hi, this version (and from what I believe all versions) of kea-dhcp4-server > (and probably kea-dhcp6-server) handles vlan tagged traffic in a quite > unintuitive way. When the server is set up in raw socket mode it will accept > all > broadcasted DHCP requests regardless of VLAN tagging. It will then send a > response untagged, again regardless of initial VLAN tag. See below for a > packet > trace where this happens. > > This has been reported to the ISC team quite some time ago here: > https://gitlab.isc.org/isc-projects/kea/-/issues/1117. > A patch has been provided to the ISC team which they have not applied (I can't > say why): https://github.com/isc-projects/kea/pull/119. > The file that is patched has been more or less unchanged since the patch was > created and should still apply (it did for me on 2.2.0-6). > > This behavior was not present in isc-dhcp-server as they filtered out VLAN > tagged broadcasts from what I can tell, so the behavior is changed between the > two DHCP server services. > > As I see it there are two things that shouldn't happen here: > 1. A DHCP server not explicitly configured to listen to VLAN traffic should > not > respond to that traffic. > 2. If a DHCP server answers DHCP broadcasts on a VLAN tagged network it should > respond on the same VLAN network. > > My suggestion would be to include the patch > (https://github.com/isc-projects/kea/pull/119) > to filter out any tagged traffic, as this is inline with how dhcpd from > isc-dhcp-server worked. Hello Kristofer and thanks for this bug report. After looking at the state of the upstream bug and and the patches you pointed to, and discussing the issue with the other Debian Kea maintainers, our opinion is that we should not patch the Debian package to include the requested functionality. There are many reasons for this, in I think the two most important ones are: * The issue is not trivial, and there's the risk to introduce incomplete or buggy code we can't commit to fix or maintain. * If what ISC will ship at some point will be different from what Debian shipped, maybe in a stable release, we'll end up in a difficult to handle situation, with no clear or easy upgrade path for uses that ended up relying on the Debian specific implementation. I think the way forward here is asking upstream what the plans are, and whether there are ways users interested in the feature can help landing it. Cheers, Paride
Bug#698988: O: nvi - 4.4BSD re-implementation of vi
Hi Tobias! On 2024-02-05 10:43, Tobias Heider wrote: > On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote: >> >> The maintainer for the "nvi" package has indicated that he is unable to >> maintain this package for the time being. I'm marking this package as >> orphaned >> now. > > Looks like this is still orphaned over ten years later. > > As an active nvi user I would love to step up and help, but the biggest > problem I see is that the choice of upstream project. Since the original > is gone there isn't a clear successor. > > The BSDs all have their own forks which diverged over time (and those don't > build on Linux). > The other two options there are today are https://repo.or.cz/nvi.git which > d/control currently points to and more recently > https://github.com/lichray/nvi2. > > The first has a very low commit frequency (last commit was 2020, before > that 2016) and sticks very closely to the original source. nvi2 has added > new features such as multibyte support and is starting to receive bug fixes > and features from the different *BSD forks. > > I have been thinking of proposing a new package for nvi2 but maybe it would > make more sense to move this one to the more active upstream. It looks like > some of the issues we are carrying patches for in Debian might be fixed there > already and if not they seem active enough to merge our fixes. > > What would be the best way forward here? ITA and eventually switch the > upstream > or start a new package and let this one continue its slow death? I think making the O bug and ITA and switching upstream is right thing to do here, maybe explaining the history of the package in README.source. I can't think think of a reasonable use case where nvi2 would not be a suitable drop-in replacement for nvi; if neither can you (knowing the editor way better than me!), then I'd say go for the switch. I'll be happy reviewing/sponsoring if needed. Cheers, Paride
Bug#1060021: fscrypt: New upstream version available (0.3.4)
On 2024-01-04 22:17, Salvatore Bonaccorso wrote: > Last year a new upsteam version 0.3.4 was released which might be > worth having packaged in trixie. Thanks Salvatore, I'll try to get to it in the next few days. Paride
Bug#1055438: kea-dhcp4-server: Also create /run/kea/
@Stefan: any idea on why you didn't encounter this while using sysv init? Thanks, Paride On 2023-12-12 12:56, Oleg Broytman wrote: > Hi! Alas, yes. It requires directories /run/kea and /var/lib/kea . > > I didn't want to upgrade any of my systems to testing so I ran a docker > container with debian:testing (age: 3 weeks ago). > > # apt-get update > # apt-get install -y kea-dhcp4-server > # kea-dhcp4 -v > 2.4.0 > > # /etc/init.d/kea-dhcp4-server status > kea-dhcp4-server is not running ... failed! > > # /etc/init.d/kea-dhcp4-server start > # /etc/init.d/kea-dhcp4-server status > kea-dhcp4-server is not running ... failed! > > # kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > Unable to use interprocess sync lockfile (No such file or directory): > /var/run/kea/logger_lockfile > kea-dhcp4: Fatal error during start up: Unable to open PID file > '/run/kea/kea-dhcp4.kea-dhcp4.pid' for write > Unable to use interprocess sync lockfile (No such file or directory): > /var/run/kea/logger_lockfile > > # mkdir /run/kea > # kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > ERROR DHCP4_CONFIG_LOAD_FAIL configuration error using file: > /etc/kea/kea-dhcp4.conf, reason: Unable to open database: unable to open > '/var/lib/kea/kea-leases4.csv' > 2023-12-12 11:48:30.963 ERROR [kea-dhcp4.dhcp4/38.139744226431424] > DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using > file '/etc/kea/kea-dhcp4.conf': Unable to open database: unable to open > '/var/lib/kea/kea-leases4.csv' > > # mkdir /var/lib/kea > # /etc/init.d/kea-dhcp4-server start > # /etc/init.d/kea-dhcp4-server status > kea-dhcp4-server is running. > > PS. Most probably I created /var/lib/kea on my real server after > installation; I don't remember. Unlike /run/kea it's not cleared on > reboots so it's enough to create it once upon installation. > /run/kea must be tested and recreated on every start. > > On Mon, Dec 11, 2023 at 05:03:58PM +0100, Paride Legovini > wrote: >> Control: tags -1 moreinfo >> >> Hello and thanks for this bug report. Are you able to verify that this >> bug still exists in the Kea version currently in Debian testing (2.4.0-1)? >> Some work was recently done on the sysv init scripts, so for sure they >> are working for someone. >> >> Thanks, >> >> Paride > > Oleg.
Bug#1055438: kea-dhcp4-server: Also create /run/kea/
Control: tags -1 moreinfo On 2023-12-11 09:09, Oleg Broytman wrote: > Boom -- there is no /run/kea/ directory so Kea doesn't start and doesn't > report problems via logs as it cannot create log files. I added the > directory creation in /etc/init.d/kea-dhcp4-server; not sure if it's the > most correct resolution but it works for me Hello and thanks for this bug report. Are you able to verify that this bug still exists in the Kea version currently in Debian testing (2.4.0-1)? Some work was recently done on the sysv init scripts, so for sure they are working for someone. Thanks, Paride
Bug#1032495: (no subject)
Luigi Baldoni wrote on 15/10/2023: > Same deal here, but on bookworm using systemd and the installation is some 10 > days old. Hello Luigi, that is likely a different issue. Can you please file a ne bug report, describing the problem you are facing in more detail, possibly providing steps to reproduce from a clean Bookworm system? Thank you, Paride
Bug#1052338: kea: /etc/init.d/kea-dhcp-ddns-server
Control: severity -1 wishlist Hi Alessandro, Alessandro Vesely wrote on 20/09/2023: > I installed kea on Devuan, but bugreport said kea is unforked. > > The server won't start, because DAEMON doesn't exist: > > 799-north:init.d# diff -u /tmp/kea-dhcp-ddns-server kea-dhcp-ddns-server > --- /tmp/kea-dhcp-ddns-server 2023-09-20 19:39:20.0 +0200 > +++ kea-dhcp-ddns-server 2023-09-20 19:39:23.0 +0200 > @@ -17,7 +17,7 @@ > PATH=/sbin:/usr/sbin:/bin:/usr/bin > DESC=kea-dhcp-ddns > NAME=kea-dhcp-ddns > -DAEMON=kea-dhcp-ddns > +DAEMON=/usr/sbin/kea-dhcp-ddns > DAEMON_ARGS="-c /etc/kea/kea-dhcp-ddns.conf" > PIDFILE=/run/$NAME.pid > SCRIPTNAME=/etc/init.d/$NAME In principle I'd like this to be tested on a Debian system, but the fix seems really straightforward. Would you be able to submit it as an MP against the Kea packaging repository [1]? Thanks! Paride [1] https://salsa.debian.org/debian/isc-kea/
Bug#1037297: /usr/sbin/kea-dhcp6: socket error when starting or restarting the server
Bruno Meirelles wrote on 22/06/2023: > Hi Paride, > > I asked on systemd github, see if that might help: > > https://github.com/systemd/systemd/issues/28122# Lennart is right, this is not a systemd upstream issue. It's about the Debian systemd package or the network management system you are using. Paride
Bug#1037297: /usr/sbin/kea-dhcp6: socket error when starting or restarting the server
Bruno Meirelles wrote on 20/06/2023: > Hi Paride, thanks for the reply. > > I checked the systemd file and it says After=network-online.target, it > still doesn't work, I need to restart the service. > > Is the problem in systemd? > > Who should I report to? Hi, https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ says: --- network-online.target is a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network is set up. --- so I'd say it's either systemd or ifupdown (assuming that's what you are using). Paride
Bug#1037297: /usr/sbin/kea-dhcp6: socket error when starting or restarting the server
Bruno wrote on 10/06/2023: > Dear Maintainer, > > when starting or restarting the server, kea-dhcp6-server does not work with > the following error: [...] Hello Bruno and thanks for this bug report. I think this issue falls under the "network-online ordering" category, which is due to the fact that the "networking is ready" or "system is online" status is not well defined. It may me tempting to use an After=network-online.target rule in the systemd service file, but the point defining what that target means. For example: if a secondary network interface of a server is down, should this prevent systemd from starting kea? Unfortunately I don't have a solution at hand at the moment which is guaranteed to do more good than harm. Paride
Bug#1033639: Bug#1033640:
Markus Viitamäki wrote on 30/03/2023: > I have applied your changes from the MR on my machine, and it solves the > problem with apparmor. Hi Markus, I uploaded a new revision of kea to experimental (2.2.0-7). Could you please verify it fixes this bug and #1033639? Once I get confirmation that the bugs are actually fixed I'll upload to unstable. (Note: the version in experimental contains another unrelated change. You should notice no functional differences.) Thanks!
Bug#1033367: kea-ctrl-agent: Unrestricted default RESTful interface on 127.0.0.1:8000
Package: kea-ctrl-agent
Version: 2.2.0-5
Severity: normal
Tags: security
X-Debbugs-Cc: andreas.hasen...@canonical.com, par...@debian.org, Debian
Security Team
Forwarded from: https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/2007312
Originally reported by: Andreas Hasenack
WIP fix:
https://code.launchpad.net/~ahasenack/ubuntu/+source/isc-kea/+git/isc-kea/+merge/439352
Follows copypaste of the original bug as reported by Andreas.
---
The kea-ctrl-agent package, when installed, starts a daemon (kea-ctrl-agent)
that by default listens on 127.0.0.1:8000. It responds to commands like
"shutdown", "config-get", and many others[1][2].
What's problematic is that these commands are accepted without authentication.
Anyone on the localhost system can:
a) shutdown a kea daemon:
ubuntu@j-kea:~$ pidof kea-dhcp4
2884
ubuntu@j-kea:~$ curl -X POST -H "Content-Type: application/json" -d '{
"command": "shutdown", "service": [ "dhcp4" ] }' http://localhost:8000/
[ { "result": 0, "text": "Shutting down." } ]ubuntu@j-kea:~$
ubuntu@j-kea:~$ pidof kea-dhcp4
ubuntu@j-kea:~$
b) read the config file (in this example, I made the config file 0640 root:_kea
so the ubuntu user cannot read it):
ubuntu@andreas-isc-kea-server:~$ cat /etc/kea/kea-dhcp4.conf
cat: /etc/kea/kea-dhcp4.conf: Permission denied
ubuntu@andreas-isc-kea-server:~$ curl -X POST -H "Content-Type:
application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }'
http://localhost:8000/| grep secret
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4049 100 3998 100 51 134k 1751 --:--:-- --:--:-- --:--:-- 136k
[ { "arguments": { "Dhcp4": { "authoritative": false, "boot-file-name": "",
"calculate-tee-times": false, "config-control": { "config-databases": [ {
"name": "kea", "password": "keasecret",
The same could be done via the unix sockets, but the permissions there are not
world writable, so this is avoided:
$ ls -la /tmp/kea*socket
srwxr-xr-x 1 _kea _kea 0 Feb 14 19:13 /tmp/kea-ddns-ctrl-socket
srwxr-xr-x 1 _kea _kea 0 Feb 14 19:14 /tmp/kea4-ctrl-socket
srwxr-xr-x 1 _kea _kea 0 Feb 14 19:13 /tmp/kea6-ctrl-socket
One course of action is to disable listening on 127.0.0.1:8000 via the config
file:
/etc/kea/kea-ctrl-agent.conf:
"Control-agent": {
"http-host": "127.0.0.1",
// If enabling HA and multi-threading, the 8000 port is used by the HA
// hook library http listener. When using HA hook library with
// multi-threading to function, make sure the port used by dedicated
// listener is different (e.g. 8001) than the one used by CA. Note
// the commands should still be sent via CA. The dedicated listener
// is specifically for HA updates only.
"http-port": 8000,
(...)
Or maybe setup authentication with a user created in postinst for this purpose,
with a random password. The documentation[3], in the end of section 7.2, lists
a mechanism to include username and password from an external file, so we don't
have to adjust the permissions of kea-ctrl.agent.conf because of this.
Finally, there is also a question about what to do on upgrades from systems
that have this unprotected open port.
1.
https://kea.readthedocs.io/en/kea-2.2.0/arm/ctrl-channel.html#commands-supported-by-both-the-dhcpv4-and-dhcpv6-servers
2.
https://kea.readthedocs.io/en/kea-2.2.0/arm/ctrl-channel.html#commands-supported-by-the-d2-server
3. https://kea.readthedocs.io/en/kea-2.2.0/arm/agent.html#configuration
Bug#1009303: imv: Upstream homepage has moved, and incorrect watch file
On Mon, 11 Apr 2022 11:05:48 +0200 Gard Spreemann wrote: > Package: imv > Version: 4.3.0-1 > Severity: minor > X-Debbugs-Cc: g...@nonempty.org > > Dear Maintainer, > > The package currently has > > Homepage: https://github.com/eXeC64/imv > > while upstream has moved to > > https://sr.ht/~exec64/imv/ > > This also causes d/watch to monitor stale sources for new releases. Thank you, unfortunately I missed version 4.4.0 because of this. Now Debian is frozen, I'll fix the upstream location and package the latest upstream version once the new development cycle opens. Paride
Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start
Benedikt Spranger wrote on 10/03/2023: > On Fri, 10 Mar 2023 15:04:44 +0100 > Paride Legovini wrote: > >> I am not running sysv systems; The case looks simple enough for me to >> tempt a fix, but I need validation from an actual sysv user. Even better >> if you can submit a salsa MR, which will also speed up the process of >> landing a fix: >> https://salsa.debian.org/debian/isc-kea/ > > Can do that next week. ATM I am busy to prepare stuff for a trade fair > starting next week... Sound good, thanks! Keep in mind that Debian will be in hard freeze. Given that isc-kea is a non-key package with autopkgtests we'll still be able to upload a "small, targeted fix" [1] for this issue, but the sooner the better. Cheers, Paride [1] https://release.debian.org/testing/freeze_policy.html#full
Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start
Control: severity -1 normal bene wrote on 08/03/2023: > On Wednesday, March 08, 2023 20:15 CET, Andreas Hasenack > wrote: > >> I see you are not using the systemd unit, so I suspect you are running kea >> as root directly, instead of as the unprivileged `_kea` user, and you are >> probably tripping over the "owner" flag of the apparmor rules. > > Thanks for the hint... (\me buys some big brown paperbag...) > > It is working now with the following patch to /etc/init.d/kea-dhcp4-server. > --- /etc/init.d/kea-dhcp4-server.orig 2023-03-08 22:00:35.249600025 > +0100 > +++ /etc/init.d/kea-dhcp4-server2023-03-08 22:12:11.80397 +0100 [...] Thanks for the patch. However I have a couple of questions: Are you actually using Bookworm with sysv, having removed systemd, or are you using the init.d scripts for some other reason (integration with other software, habit, ...)? If your init system is systemd, then I strongly advise using systemctl to start/stop/... the daemons. I don't think the init scripts are actively maintained at the moment, as you noticed (FIXME kea team, Cc:). Plus QA on the package (e.g. DEP8 tests) is done assuming systemd. If you are a sysv init user, are you willing to test packages with a candidate fix, before an upload is done? I am not running sysv systems; The case looks simple enough for me to attempt a fix, but I need validation from an actual sysv user. Even better if you can submit a salsa MR, which will also speed up the process of landing a fix: https://salsa.debian.org/debian/isc-kea/ Cheers, Paride
Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start
Benedikt Spranger wrote on 08/03/2023: > Package: kea-dhcp4-server > Version: 2.2.0-5 > Severity: important > X-Debbugs-Cc: none, Benedikt Spranger > > Dear maintainer, > > after an update kea-dhcp4 refuses to start due to an apparmor > missconfiguration. To track down the problem I started the server > manualy. No luck. Same error(s) - Therefore further step backs. > Here to reproduce the problem: > > 1) Install kea-dhcp4-server > 2) Start the server manualy: > > # kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > Unable to use interprocess sync lockfile (Permission denied): > /var/run/kea/logger_lockfile This is expected: in Debian the lockfile path is defined in the systemd service files, like this: Environment="KEA_LOCKFILE_DIR=/run/lock/kea" which is different from the default /var/run/kea/, which got used in your manual attempt. The issue you're seeing is likely not with the lockfile. Running: # KEA_LOCKFILE_DIR=/run/lock/kea kea-dhcp4 -c /etc/kea/kea-dhcp4.conf may show the actual issue, but I suggest using e.g. journalctl -u kea-dhcp4-server.service Please do follow up to this bug if you figure out something more about this issue: if there's a bug in the apparmor profile we want to fix is sooner than later. Thanks!
Bug#1032314: autopkgtest: Specifying --apt-pocket causes wrong unwanted pinning to default release
Package: autopkgtest Severity: normal X-Debbugs-Cc: par...@debian.org Adding a pocket via --apt-pocket= causes the _get_default_release() function to be called. This is needed to construct the sources.list entry for the pocket, which will be in the form of: deb - ... The _get_default_release() function caches the detected default release in the default_release variable, which is the same variable used to store the --apt-default-release= value. This has no effect when only one test is present in d/t/control, but when more than one test is present the tests after the first will have unwanted/wrong pinning (as if --apt-default-release was specified).
Bug#987391: Intent to NMU s-nail to fix longstanding l10n bugs
Helge Kreutzmann wrote on 10/02/2023: > Hello Paride, > I intend to NMU s-nail around 2023-02-25 to fix a longstanding l10n > bug[1]. Hello Helge, Admittedly I missed the bug report about the Spanish translation. I'm preparing a new upload myself. Thanks for the heads-up! Cheers, Paride
Bug#981484: webext-exteditor: not compatible with current thunderbird
On Sun, 31 Jan 2021 20:56:35 +0100 Ivo De Decker wrote: > package: webext-exteditor > version: 2.0.4-1 > severity: serious > > Hi, > > Thunderbird 1:78.7.0-1 has 'Breaks: webext-exteditor (<= 2.0.4-1)', which > means webext-exteditor doesn't work with it. Upstream isn't active anymore. I suggest switching to: https://github.com/Frederick888/external-editor-revived -- Paride
Bug#983578: stterm: defaul variable for TERM didn't appear to work by default
I still can't reproduce the issue. Can you do so on a fresh Debian system? I am prone to think that there's something off on the system where you're hitting it, otherwise we'd be seeing many more bug reports about it.
Bug#1023878: ITP: libgrapheme -- Unicode string library with small footprint and high performance
Package: wnpp Severity: wishlist Owner: Paride Legovini X-Debbugs-Cc: debian-de...@lists.debian.org, par...@debian.org, d...@frign.de * Package name: libgrapheme Version : 2.0.2 Upstream Author : Laslo Hunhold * URL : https://libs.suckless.org/libgrapheme/ * License : ISC Programming Lang: C Description : Unicode string library with small footprint and high performance libgrapheme is an extremely simple freestanding C99 library providing utilities for properly handling strings according to the latest Unicode standard 15.0.0. It offers fully Unicode compliant * grapheme cluster (i.e. user-perceived character) segmentation * word segmentation * sentence segmentation * detection of permissible line break opportunities * case detection (lower-, upper- and title-case) * case conversion (to lower-, upper- and title-case) on UTF-8 strings and codepoint arrays, which both can also be null-terminated. The necessary lookup-tables are automatically generated from the Unicode standard data (contained in the tarball) and heavily compressed. Over 10,000 automatically generated conformance tests and over 150 unit tests ensure conformance and correctness. It is also way smaller and much faster than the other established Unicode string libraries (ICU, GNU's libunistring, libutf8proc). I plan to maintain the package in salsa under the debian/ namespace, unless I get a suggestion for an appropriate team. In that case I'd be happy to team maintain the package. I already maintain packages from the same upstream, with whom I have always had an excellent collaboration. Paride
Bug#1013326: Tests: please add isolation-machine restriction for smoke-tests
Hi Reiner, Reiner Herrmann wrote on 01/10/2022: > Hi Paride, > > On Wed, Jun 22, 2022 at 12:03:50PM +0200, Paride Legovini wrote: >> I'll take care of merging 0.9.70-1 in Ubuntu, keeping the aforementioned >> delta. If you end up adding skip-not-installable (or any other >> workaround for the lack of firefox package on some Ubuntu archs) feel >> free to ping me and I'll bring the package back in sync, so it will also >> auto-sync in the future. > > I have just uploaded firejail 0.9.70-2 to unstable, which has the > architecture restriction in the autopkgtest from the Ubuntu diff. > > Can you please enable syncing again? Thanks for the ping, much appreciated. The Ubuntu archive is currently in pre-release freeze for the Kinetic Kudu release, so this isn't a good moment to do a sync from Debian. I'll do it once the new development cycle opens (likely at the end of October). Paride
Bug#1020791: stterm: Add scrollback posibility
Control: severity -1 wontfix Hello again, eche...@buxtehude.debian.org wrote on 26/09/2022: > Package: stterm > Version: 0.8.4-1 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > * What led up to the situation? > > I wanted to scroll back in the terminal console. > > It is something that doesn't come by default in st/stterm but there is an > official patch by upstream called scrollback as well as an utility called > scroll which is experimental to add this funcionality. > > However, a current Debian GNU/Linux maintainer is not interested in providing > the patch for it. I'm aware of the patch (I even contributed to it, see [1]), but I confirm that the stterm package aims at packaging st as released upstream, with no patches. Note that the patch is not "official": like the others listed at [2] it only happens to be hosted on the st website. I suggest filing a bug against the suckless-tools package requesting the inclusion of 'scroll', however note that [3] still says At the moment it is in an experimental state. Its not recommended for productive use. so the suckless-tools maintainer may object. (The standard upstream suggestion for scrolling back with st is using a terminal multiplexer, see the FAQ file included with the package.) I hope this helps. Paride [1] https://st.suckless.org/patches/scrollback/ [2] https://st.suckless.org/patches/ [3] https://tools.suckless.org/scroll/
Bug#1020790: stterm: Package does not include desktop file
Control: severity -1 minor Hello, eche...@buxtehude.debian.org wrote on 26/09/2022: > Package: stterm > Version: 0.8.4-1 > Severity: normal > > Dear Maintainer, > > * What led up to the situation? > > I just wanted to release st/stterm graphically. By "release" you mean "launch"? > * What exactly did you do (or not do) that was effective (or ineffective)? > > 1. Install the package stterm. > 2. Try to search and release it graphically from various menus. > 3. Check that a .desktop file was not provided in the package nor created > during pre/post-installation triggers. Indeed the package doesn't install a .desktop file. I guess nobody complained so far because most of stterm users are using a tiling window manager, and are using dmenu or similar to launch programs. I'll add a .desktop file in the next upload, thanks for the suggestion. Paride
Bug#1020789: stterm: Make it available as x-www-terminal alternative
Control: severity -1 minor Hello, eche...@buxtehude.debian.org wrote on 26/09/2022: > Package: stterm > Version: 0.8.4-1 > Severity: normal > > Dear Maintainer, > > * What led up to the situation? > > st, aka stterm in Debian GNU/Linux, is not selectable as x-www-terminal > alternative. I take you mean x-terminal-emulator, correct? That's doable, I'll add stterm as an alternative with the next upload. Note: there's something off with the From: address of your bug reports: From: eche...@buxtehude.debian.org, López Romero Is perhaps your DEBEMAIL misconfigured? Paride
Bug#1016747: kea: Adjust log file in default config to match Debian config
Thomas D. wrote on 06/08/2022:
Package: kea
Version: 2.0.2-3
Severity: normal
Dear Maintainer,
the package will install
/etc/kea/kea-{ctrl-agent,dhcp4,dhcp6,dhcp-ddns}.conf
files which all have set
> "loggers": [
> {
> "output_options": [
> {
> // Specifies the output file. There are several
special values
> // supported:
> // - stdout (prints on standard output)
> // - stderr (prints on standard error)
> // - syslog (logs to syslog)
> // - syslog:name (logs to syslog using specified name)
> // Any other value is considered a name of the file
> "output":
"/var/log/kea-{ctrl-agent,dhcp4,dhcp6,dhcp-ddns}.log"
> }
> ]
> }
> ]
However, default kea services cannot write to this location because they
are running as "_kea" user on Debian by default.
You are already creating /var/log/kea so I would suggest to update
default config to use that directory by default.
Thanks, I brought this up upstream:
https://gitlab.isc.org/isc-projects/kea/-/issues/2220#note_313724
I'd like to to get an ACK from upstream on using that path, but even if
we don't I'll fix this before the bookworm freeze.
Note to self: we also don't want to set KEA_LOGGER_DESTINATION in the
systemd service files, as with systemd it's fine to get the early
logging messages (pre conf file parse) to stdout. See:
doc/sphinx/arm/logging.rst
Paride
Bug#1019189: autopkgtest_qemu: wrong ppc64 arch name in kvm_compatible()
Patch: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/199
Bug#1019189: autopkgtest_qemu: wrong ppc64 arch name in kvm_compatible()
Source: autopkgtest Version: 5.25 Severity: normal X-Debbugs-Cc: par...@debian.org Hi, Looks like the ppc64 architecture name introduced in this commit is wrong: https://salsa.debian.org/ci-team/autopkgtest/-/commit/d2350929d7d570aa71d40f15c297c56bc489a014 We need the "uname" arch name there (ppc64le), while ppc64el is the dpkg arch name. -- Paride
Bug#1016109: new upstream (2.2.0)
Daniel Baumann wrote on 27/07/2022: > kea 2.2.0 was released a couple of days ago, it would be nice if you > could upgrade the package in experimental. Hi Daniel, According to the version scheme and release notes [1] Kea 2.2.0 is a stable release, even if it hasn't been announced as such yet [2]. Is there any reason why you suggest uploading to experimental instead of unstable (perhaps with urgency=low)? Thanks, Paride [1] https://ftp.isc.org/isc/kea/2.2.0/Kea-2.2.0-ReleaseNotes.txt [2] https://www.isc.org/categories/kea/
Bug#1014929: kea-dhcp4-server: uses predictable filenames in /tmp
Control: forwarded -1 https://gitlab.isc.org/isc-projects/kea/-/issues/2495 I forwarded this bug report upstream, as ideally I'd like not to diverge from the upstream defaults. If upstream isn't responsive on this issue I'll patch the default config files to put the sockets under /run/kea and warn about this via d/NEWS or use debconf offer an optional conf file migration option, applying a regexp to the conf files at postist. Paride
Bug#1014995: kea-shell does use original includes
Hello Kilian and thanks for this bug report, which I can easily reproduce.
Kilian Krause wrote on 15/07/2022:
> Package: kea-ctrl-agent
>
> After installation the kea-shell does not work because:
> # kea-shell
> Traceback (most recent call last):
> File "/usr/sbin/kea-shell", line 27, in
> from kea_conn import CARequest # CAResponse
> ModuleNotFoundError: No module named 'kea_conn'
> #
>
> Quite obviously with the current python3-kea-connector in Debian
> the following patch does seem correct:
> ---(snip)---
> --- /usr/sbin/kea-shell.orig 2022-07-15 22:20:46.534324145 +0200
> +++ /usr/sbin/kea-shell 2022-07-15 22:21:12.590348119 +0200
> @@ -24,7 +24,7 @@
>
> sys.path.append('/usr/lib/python3.10/site-packages/kea')
>
> -from kea_conn import CARequest # CAResponse
> +from kea.kea_conn import CARequest # CAResponse
>
> if sys.version_info[0] == 2:
> # This is Python 2.x
> @@ -34,7 +34,7 @@
> return unicode(string, 'utf-8')
> elif sys.version_info[0] == 3:
> # This is Python 3.x
> -import kea_connector3 as kea_connector
> +import kea.kea_connector3 as kea_connector
> auth8 = str
> else:
> # This is... have no idea what it is.
> ---(snip)---
I don't think that's the right fix: what we want is this line (in your
patch context):
sys.path.append('/usr/lib/python3.10/site-packages/kea')
to be:
sys.path.append('/usr/lib/python3/site-packages/kea')
which is there the Python files are actually installed. That's templated
upstream:
https://gitlab.isc.org/isc-projects/kea/-/blob/585bd6b4a90287bc659adb414c8ae9cb806b23b1/src/bin/shell/kea-shell.in#L25
but the result is not correct in our case. I'll look into this.
Paride
Bug#1014929: kea-dhcp4-server: uses predictable filenames in /tmp
Ansgar wrote on 14/07/2022:
> kea-dhcp4-server_2.1.3-1_amd64.deb includes:
>
> +---
> | "control-socket": {
> | "socket-type": "unix",
> | "socket-name": "/tmp/kea4-ctrl-socket"
> | },
> +---[ /etc/kea/kea-dhcp4.conf ]
>
> This looks like incorrect use of /tmp as one cannot (without much
> extra work) place files with fixed names there. Clients would also
> need to make sure they actually connect to the right program.
>
> Sockets should be placed in /run or a service-specific subdirectory
> such as /run/kea or /run/kea-dhcp4.
>
> Other kea-* packages probably have similar issues.
Hello Ansgar and thanks for this bug report. I agree we should fix the
location of the control sockets, but see comment #2 here on a reason why
doing that isn't straightforward:
https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100
Paride
Bug#1013407: isc-kea: FTBFS with Sphinx 5.0, docutils 0.18: make[4]: *** [Makefile:902: html] Error 2
control: forwarded -1 https://gitlab.isc.org/isc-projects/kea/-/issues/2451 Lucas Nussbaum wrote on 23/06/2022: > isc-kea fails to build with Sphinx 5.0 and docutils 0.18, both of which > are currently available in experimental. Thanks. I identified a fix and forwarded the bug upstream. Paride
Bug#1013326: Tests: please add isolation-machine restriction for smoke-tests
Hi Reiner, thanks for your reply! Reiner Herrmann wrote on 21/06/2022: > Control: severity -1 wishlist > > Hi Paride, > > On Tue, Jun 21, 2022 at 10:30:41PM +0200, Paride Legovini wrote: >> The smoke-tests autopkgtest fails in containers (at least in LXD >> unprivileged containers) as the tests call mknod to create device >> files, and that's not permitted in such environment. > > Is this documented somewhere that mknod is not permitted by autopkgtest > runners other than isolation-machine? > In my opinion using containers does not imply that devices can't get > created, and using isolation-machine does not imply that creating > devices is successful (as they could also be configured nodev or so). > So it seems to be an orthogonal problem to me, that is not really solved > by choosing a different isolation method. Well, as I understand it the difference is made by the container being privileged vs. non-privileged. In a non-privileged container the root user within the container is mapped to non-root outside the container, and therefore can't create device files. By default LXD containers are non-privileged. Unfortunately we don't have an isolation-privileged-container restriction for autopkgtests, we only have isolation-machine, where it can't be that devices can't be created. You could have partitions mounted as nodev, but not /dev, and the autopkgtest failure we're seeing on armhf is: > Error: cannot create /dev/zero device: Operation not permitted However I agree isolation-machine is a big hammer to ensure that devices can be created. > Yes, I moved the failing tests out of the "smoke-tests" set again, in > the hope that it will pass on Ubuntu, while still being sufficient to find > some regressions. > That change is already in 0.9.70-1 (so they are allowed to fail in the > "simple-tests" set, which is marked flaky), but I have no idea why it did > not get picked up by Ubuntu. This I can explain: the Ubuntu package now has a delta, see this diff: https://launchpadlibrarian.net/591990408/firejail_0.9.68-3_0.9.68-3ubuntu1.diff.gz which means that the package won't sync automatically anymore. I think the delta could be removed if the relevant test is declared skip-not-installable. However I don't know how it's going to behave now that firefox is a transisional package installing the snap... > I don't intend to mark additional tests as isolation-machine, as they > are then not getting run on Debian's test runners, where they are passing > and are useful to find regressions. Admittedly I didn't realize this: the Ubuntu testbed systems allow isolated-machine tests. You're perfectly right in not taking my suggestion as-is then. > But it's probably also no longer needed, as the problematic tests are > now in a "flaky" test set, while the remaining ones in the "smoke-tests" > set should run fine also on Ubuntu's runners. I'll take care of merging 0.9.70-1 in Ubuntu, keeping the aforementioned delta. If you end up adding skip-not-installable (or any other workaround for the lack of firefox package on some Ubuntu archs) feel free to ping me and I'll bring the package back in sync, so it will also auto-sync in the future. Thanks! Paride
Bug#1013326: Tests: please add isolation-machine restriction for smoke-tests
Source: firejail Version: 0.9.70-1 Severity: normal X-Debbugs-Cc: par...@debian.org Hi, The smoke-tests autopkgtest fails in containers (at least in LXD unprivileged containers) as the tests call mknod to create device files, and that's not permitted in such environment. This is handled properly if the isolation-machine Requirement is added to d/t/control for smoke-tests. (This is the reason why autopkgtests fail in Ubuntu on armhf, as [1] mentions.] Thanks! Paride [1] https://salsa.debian.org/reiner/firejail/-/commit/5866cc624be2216a5becbf025146b38a81bc6847
Bug#1002717: Please break the big package into smaller packages according to the language
Control: severity -1 wishlist On Tue, 4 Jan 2022 Amr Ibrahim wrote: > On Tue, 28 Dec 2021 21:52:01 +0100 Adam Borowski > wrote: > > > Could you please describe your use case? I don't quite see what > > screen-equipped machines would care about mere 40MB. This stands in > > contrast to embedded or containers where space might be at premium, > > sometimes as low as 256MB. > > Hello, > > My use case is of typical desktop use: > > - Changing the default font of the desktop environment > - Choosing a font in a LibreOffice document > > It is the annoyance of going through the big list of useless fonts > (from my point of view) in LibreOffice in order to find a good font for > the three languages that I use: English, German and Arabic. Hi Amr and thanks for your suggestion. The sweet spot between splitting packages so one can install exactly what's needed and making things discoverable and straightforward is sometimes not obvious and not the same for everybody. For font packages I think that having a single package installing everything upstream intended makes sense, and I agree with Adam in his considerations on disk space utilization. In other words, while being open for further discussion, I'm -1 for the per-language split. I could be more positive on splitting out the web fonts (/usr/share/fonts-ibm-plex/*), as my impression is that nothing/nobody is using them, but even here I'm not sure it's really worth it. Paride
Bug#868875: Your thoughts about #868875
Hi, IIUC we can mark this as done in Version: 0.31-1, which includes upstream commit 98b048f9d2f4319689d46507537587d391e41332, am I right? See: https://github.com/canonical/cloud-utils/commit/98b048f9d2f4 Cheers, Paride
Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.
On Tue, 9 Jun 2020 Roberto Mier wrote: > Not really. Sorry, but yq releases use the newer Go versions that are not > available in Debian distro. They are not available either as .deb most of the > needed golang deps. It would be tough maintaining two versions of a package, > because in any case the one I’m maintaining in my ppa is the one people want > to use. So I prefer leave this responsibility to others. Hi Roberto and others, FYI I've been able to build the PPA version of yq 4.16.2 in a Debian schroot just my bumping the golang-1.15 dependency to 1.18, and adjusting d/rules GOVERSION accordingly. Paride
Bug#1005976: new upstream (2.1.1)
Control: severity -1 wishlist Daniel Baumann wrote on 18/02/2022: > it would be nice if you could upgrade to 2.1.1 in experimental; 2.1 > closes some important feature gaps to isc-dhcp. Hi Daniel, I can't promise you an ETA, but I'll try to find some spare cycles for this. I'm very interested in the feedback from actual users of Kea: I did my best to bring the package in good shape, but admittedly I'm not using it in production, so feedback from users is especially important. Cheers, Paride
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Ludovic Rousseau wrote on 11/12/2021: Hello Paride, Do you still have the problem with pcsc-lite 1.9.5? Hi Ludovic, It seems to be working fine now. I can't tell if it's a positive side effect of fixing #995814, of the new upstream release, or something else entirely, but I'm not able to reproduce the issue anymore. Feel free to mark this bug as Done in version 1.9.5-1. Cheers, Paride
Bug#999619: Confirmed to be caused by tcmalloc that is default in 10.0
On Wed, 17 Nov 2021 Christian Ehrhardt wrote: Hi, I was able to confirm that rebuilding glusterfs without tcmalloc (now also on x86) fixes this issue. Debugging revealed that this is due to tgt late dlopening optional storage backends. So if you have some of them installed like packages tgt-rbd + tgt-glusterfs they will initialize late. Since glusterfs now will pull in tcmalloc when doing so it will late-override symbols and we have a conflict of allocations by libc and tcmalloc leading to this crash. I've found many similar issues: - https://github.com/gperftools/gperftools/issues/1066 - https://github.com/kcat/openal-soft/issues/134 - https://tracker.ceph.com/issues/23653 - https://bugzilla.redhat.com/show_bug.cgi?id=1569391 The already linked Ubuntu bug also has some more debugging data for those curious about it, but the TL;DR seems to be: "using tcmalloc in a lib (like libgf* of glusterfs) is calling for issues as anyone loading it late or multiple of them will likely crash the program." Therefore this needs the same fix done for [1], just dropping the arch restriction. I'll NMU upload this based on Patrick's request to resolve 999700 as NMU [2] since this one here is essentially the same issue but on x86. Once he is back he can have a look (or discuss with upstream) if there is a way to re-enable tcmalloc without causing all these issues. Hi, After looking at the debugging work done in Debian/Ubuntu and at those upstream issues I fully agree with the proposal of disabling tcmalloc on all the architectures for now, shipping a fix (or at least a workaround) for this RC bug, to then discuss with upstream about better options. The debdiff LGTM, and it seems entirely reasonable to me to NMU it given that Patrick already asked to NMU the same patch, just arch-specific. Cheers, Paride
Bug#985421: Adding DEP8 tests for at package
Hi, On Sat, 28 Aug 2021 Jose M Calhariz wrote:> Now I have the repo full updated and I am preparing a new upstream release of at, with many changes and bug fixes. Do you mind to do a MR at salsa? I just opened a salsa MP cherry-picking Utkarsh's commit: https://salsa.debian.org/debian/at/-/merge_requests/26/ I testes it locally (via autopkgtest-virt-schroot) and it works fine. Paride
Bug#974833: iw: output of 'mpath dump' is wrongly formatted
José Miguel Gonçalves wrote on 15/04/2021: The following patch solves this issue for me: [...] Hi and thanks for submitting a patch. While the patch is straightforward enough, the severity of the bug is also really low, so in evaluating the effort/reward ratio for patching iw in Debian I kind of get in a 0/0 indeterminate form. :-) My general package maintenance philosophy on patches is "don't diverge from upstream unless necessary". In other words I think the patch belongs to upstream iw, and I don't see why it shouldn't get accepted there. Once in upstream git I'll happily cherry-pick it in the Debian package, only to drop it with the first release that ships it. Fixing this upstream will also benefit all the iw users, and not only Debian and derivatives. Would you consider submitting your patch upstream? Documentation on how to do it is available at [1]. Thanks! Paride [1] https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Bug#986881: iw: Incorporate useful bits of crda?
Control: reassign -1 wireless-regdb On Tue, 13 Apr 2021 Diederik de Haas wrote:> I don't really know/understand how/what/when crda did that could still be useful/needed, but Ben's comment indicates that at least the udev rule may still be useful. Looking into crda's package I found /etc/default/crda with which you can set a default regulatory domain. And in /lib/crda/setregdomain it uses that file/value to call 'iw reg set ""'. The udev rule calls the crda binary btw, so I don't know if 'setregdomain' is actually called. This bug is basically to ensure that the useful part of crda doesn't get lost. I'm assuming that the maintainers who'll read this bug can determine if/what/how/where the useful part should be preserved. Maybe the 'wireless-regdb' package is more appropriate, if so feel free to reassign. And if nothing needs to be preserved, you can close it. I filed it against the 'iw' package as I saw the 'iw reg set' call and 'wireless-regdb' doesn't (yet?) have a dependency on 'iw'. Thanks for this detailed and informative bug report. I think the udev rule belongs to wireless-regdb, as the rule isn't really useful without the regulatory db, and I don't think we want to make iw Recommend wireless-regdb. If wireless-regdb adopts the rule then it should at least Recommend iw, which I think makes sense. I'm reassigning this bug to wireless-regdb, but I'm open for further discussion. Cheers, Paride
Bug#994414: lintian(1) says --fails-on defaults to `error`, but looks like it's `none`
Felix Lechner wrote on 15/09/2021: Hi Paride, On Wed, Sep 15, 2021 at 11:36 AM Paride Legovini wrote: It looks like there's a mismatch between the lintian manpage and the actual behavior. Yeah, the current behavior is what I would like to see, but Lintian's new approach to the exit status generated some controversy in the past. At this point, I would simply like to change the documentation. Would that work for you? What is your use case, please? Thank you! Hi Felix, I'm fine with the current behavior. My use case is having lintian in a CI pipeline: I expected it to fail on error (as documented), but it didn't. I can easily add the proper --fail-on. +1 for fixing the doc. Thanks! Paride
Bug#994414: lintian(1) says --fails-on defaults to `error`, but looks like it's `none`
Package: lintian Version: 2.106.1 Severity: normal X-Debbugs-Cc: par...@debian.org Hi, It looks like there's a mismatch between the lintian manpage and the actual behavior. The manpage says that for --fail-on "The default is error." However lintian doesn't actually exit with $? != 0 on errors (E tags) unless `--fail-on error` is explicitly specified. Paride -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.37-5 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.9 ii dpkg-dev1.20.9 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.40 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libconst-fast-perl 0.014-1.1 ii libcpanel-json-xs-perl 4.26-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 pn libdigest-sha-perl ii libdpkg-perl1.20.9 ii libemail-address-xs-perl1.04-1+b3 ii libencode-perl 3.12-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libio-interactive-perl 1.023-1 ii libio-prompt-tiny-perl 0.003-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.005004-2 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libperlio-utf8-strict-perl 0.008-1+b1 ii libproc-processtable-perl 0.611-1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libsort-versions-perl 1.62-1 ii libterm-readkey-perl2.38-1+b2 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.13-1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012004-1 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.83+ds-1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.32.1-5 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.37-5 ii libtext-template-perl 1.60-1 -- no debconf information
Bug#994396: strongswan: Please enable TPM2 via --enable-tss-tss2
MR adding the flag and build-dep:
https://salsa.debian.org/debian/strongswan/-/merge_requests/11
libstrongswan-extra-plugins debdiff:
===
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: libstrongswan (= 5.9.1-1), libc6 (>= 2.25), libcurl4 (>=
7.16.2), libgcrypt20 (>= [-1.8.0),-] {+1.9.0),+} libgpg-error0 (>=
1.14), libldap-2.4-2 (>= [-2.4.7)-] {+2.4.7), libtss2-sys1 (>= 3.0.1)+}
Installed-Size: [-732-] {+752+}
===
Note the new libtss2-sys1 dependency.
Paride
Bug#994396: strongswan: Please enable TPM2 via --enable-tss-tss2
Source: strongswan Version: 5.9.1-1 Severity: normal X-Debbugs-Cc: par...@debian.org Spun-off from: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1940079 Hi Yves-Alexis, The Debian strongswan package doesn't currently have any TPM support, even if d/rules calls ./configure --enable-tpm, as actually enabling TPM requires a TSS (Tpm Software Stack) implementation. To enable TPM2 we need TSS2, which is enabled via --enable-tss-tss2 (which requires an additional build-dep: libtss2-dev). Please consider adding those to the strongswan packaging. Note: this still doesn't enable TPM1.2, for which --enable-tss-trousers is required. My suggestion is to avoid enabling it, and strongswan upstream Tobias Brunner agrees, see the discussion in the Ubuntu bug I linked. Thanks! Paride -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#983160: dput-ng: --override doesn't override profile parameters
On Sat, 20 Feb 2021 wrote: Package: dput-ng Version: 1.32 It seems the `--override` option in dput-ng doesn't really override parameters in profiles. Hi, this is just to confirm this issue. I had a look at the dput-ng commit history and I'm failing to see how this was supposed to work even when --override was first implemented [1]. [1] https://salsa.debian.org/debian/dput-ng/-/commit/a283c444ec73780962c3a1e783d5b957999b1f96
Bug#991950: postfix.postinst fails if /e/resolv.conf contains `search .`
Control: tags -1 + patch I submitted this MP with a fix: https://salsa.debian.org/postfix-team/postfix-dev/-/merge_requests/12 Cheers! Paride
Bug#991950: postfix.postinst fails if /e/resolv.conf contains `search .`
Source: postfix Version: postinst fails if /e/resolv.conf search domain starts with a "." Severity: normal X-Debbugs-Cc: par...@debian.org Dear Postfix maintainers, When the /etc/resolv.conf search domain considered by postfix.postinst to configure postfix as an "Internet site" (the default debconf option), e.g.: search .example.com the installation fails with: Running newaliases newaliases: warning: valid_hostname: misplaced delimiter: debian-sid..example.com newaliases: fatal: file /etc/postfix/main.cf: parameter myhostname: bad parameter value: debian-sid..example.com dpkg: error processing package postfix (--configure): installed postfix package post-installation script subprocess returned error exit status 75 Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: postfix E: Sub-process /usr/bin/dpkg returned an error code (1) Note the double dot in "debian-sid..example.com". Having domain start with a dot is not explicitly mentioned by resolv.conf(5), but the syntax is accepted by the glibc resolver, see: https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;hb=HEAD#l385 (thanks sergiodj@d.o for digging this up). The postfix.postinst file should tolerate those domains and strip off leading dots, as the glibc resolver does: https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;hb=HEAD#l411 The above was verified on an up-to-date Sid system with postfix 3.5.6-1+b1. Paride
Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package
For some reason nss is not getting checked by lintian.debian.org: https://lintian.debian.org/sources/nss says Found no runs for version 2:3.68-1. (and same for the versions currently in bullseye and buster). However the issue this bug is about generates an Error tag: E: libnss3-dev: old-style-config-script-multiarch-path usr/bin/nss-config full text contains architecture specific dir x86_64-linux-gnu
Bug#991562: nss: Disable TLS below 1.2 by default
Source: nss
Version: 2:3.63-1ubuntu1
Severity: normal
Tags: patch
X-Debbugs-Cc: par...@debian.org
To keep NSS in sync with the current security standards and
expectations, and consistent to what OpenSSL now does, I think NSS
should disable TLS below 1.2 by default.
This is already done in Ubuntu, attached is the patch that implements
the change.
Thanks!
Paride
Description: Set TLSv1.2 as minimum TLS version. LP: #1856428
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1856428
Index: nss-3.48-1ubuntu1/nss/lib/ssl/sslsock.c
===
--- nss-3.48-1ubuntu1.orig/nss/lib/ssl/sslsock.c
+++ nss-3.48-1ubuntu1/nss/lib/ssl/sslsock.c
@@ -101,7 +101,7 @@ static sslOptions ssl_defaults = {
* default range of enabled SSL/TLS protocols
*/
static SSLVersionRange versions_defaults_stream = {
-SSL_LIBRARY_VERSION_TLS_1_0,
+SSL_LIBRARY_VERSION_TLS_1_2,
SSL_LIBRARY_VERSION_TLS_1_3
};
Bug#888764: libfreebl3.so should be public, not in the nss subdir
Hi, For reference this is how this was tackled in Ubuntu: https://git.launchpad.net/ubuntu/+source/nss/commit/?h=applied/ubuntu/disco=b2bd7bbfd5fb8e59f618ba30c15677fc8b0737bb https://git.launchpad.net/ubuntu/+source/nss/commit/?h=applied/ubuntu/disco=879bd31a6dc4f9e8242160dbb62aef9a9d538643 https://git.launchpad.net/ubuntu/+source/nss/commit/?h=applied/ubuntu/disco=47980f2a793d19550f2b3442393cb5c588781e05 Cheers, Paride
Bug#991379: ITP: gh -- the Github CLI
Note-to-self and possibly others: The "full text" link of the "Marked Bug as done" entry has the full text of the email sent to control@ to close the bug, and it contains the explanation. I normally use the `Control:` pseudo-headers and didn't think of looking there. Thanks Bart for the pointer. Cheers, Paride
Bug#991379: ITP: gh -- the Github CLI
On Thu, 22 Jul 2021 01:31:02 +0100 Scupake wrote:> * Package name: gh * URL : https://cli.github.com/ * License : MIT Hi, Was this bug closed after some out-of-band discussion? If this is the case I think it's worth leaving a note on the bug itself, as a head-up for people going down the same road in the future. Thanks! Paride
Bug#991350: libnet-snmp-perl: Please drop the upstream-metadata-missing-repository override
Source: libnet-snmp-perl Version: Please drop the upstream-metadata-missing-repository override Severity: minor X-Debbugs-Cc: par...@debian.org Hi, Upstream development is now done on GitHub: https://github.com/net-snmp/net-snmp/ This repository can be added to the upstream metadata and then the upstream-metadata-missing-repository lintian override can be dropped. Cheers, Paride
Bug#991174: autopkgtest: pkispawn should specify `isolation-container` in d/tests/control
Source: dogtag-pki Version: autopkgtest: pkispawn should specify `isolation-container` in d/tests/control Severity: normal X-Debbugs-Cc: par...@debian.org Hi, The `pkispawn` autopkgtest needs to open a TCP port. This fails in simple chroot/schroot environments. The d/tests/control file should specify `isolation-container` to the test is skipped when not running in its own container/VM. For reference see: https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html from which part of the above is copy/pasted :-) Paride
Bug#991173: autopkgtest: missing test dependency: iproute2
Source: dogtag-pki Version: autopkgtest: missing test dependency: iproute2 Severity: normal X-Debbugs-Cc: par...@debian.org Hi, While running the dogtag-pki autopkgtests using a very minimal testbed images I encountered test failures due to `ip` being missing. See d/tests/pkispawn: IP=`ip route get 1.1.1.1 | sed -n -e's/.*src //; s/ .*//; p; q'` This is solved by adding a test dependency on `iproute2`. Paride
Bug#983578: stterm: defaul variable for TERM didn't appear to work by default
Control: tags -1 + moreinfo Hello Richard and thanks for this bug report. The st-256color terminfo file is installed by the ncurses-term package, which is a dependency of stterm: $ dpkg -L ncurses-term|grep st-256color /usr/share/terminfo/s/st-256color so it should really be there. Did perhaps the problem happen running htop on a remote system (via ssh) while using the st terminal? In this case the problem is that the terminfo file is missing on the remote system (missing or outdated terminfo package). Forcing TERM=xterm-256color is a workaround that may work, but it's not a proper solution to be shipped by default, as the two terminfo entries do differ. Paride richard wrote on 26/02/2021: Package: stterm Version: 0.8.2-1 Severity: important Dear Maintainer, With st, i ran $ htop Error opening terminal: st-256color. $ but after I added [ $TERM = st-256color ] && export TERM=xterm-256color to my bashrc, htop worked perhaps a change the default TERM value in config.def.h would be good? thanks -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stterm depends on: ii libc6 2.28-10 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3+deb10u2 ii libx11-62:1.6.7-1+deb10u1 ii libxft2 2.3.2-2 ii ncurses-term6.1+20181013-2+deb10u2 stterm recommends no packages. stterm suggests no packages. -- no debconf information
Bug#979501: apache2: Please build against lua5.3 instead of lua5.2
Source: apache2 Version: 2.4.46-2 Severity: normal X-Debbugs-Cc: par...@debian.org Dear Apache Maintainers, Please bump the liblua Build-Dep from liblua5.2-dev to liblua5.3-dev. I verified that apache2 builds fine using liblua5.3-dev. Thanks! Paride -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#977364: stterm: Please consider scrollback patch
J.P.Malhado wrote on 14/12/2020:
Please consider applying the scrollback upstream patch
https://st.suckless.org/patches/scrollback/
The Shift+{PageUp, PageDown} version would suffice for me.
Asking the user to use tmux or screen just to get this functionality seems out
of proportion to me.
If for some reason you think this is inconvenient, would you consider including
the scroll utility (https://git.suckless.org/scroll/) with the package?
Hi,
I know that a scrollback buffer is a much requested feature for st,
however not having one is an explicit design choice made by the upstream
developers, and in general I prefer to package software as upstream
intended it, when possible. This is especially true for suckless
projects, as the developers and users community is very opinionated. For
this reasons I don't plan to include the scrollback patch in the Debian
package.
However testing and possibly including the scroll tool is in my TODO
list. The tool is still considered experimental [1], so maybe I'll poke
its developer before packaging it.
Cheers,
Paride
[1] https://git.suckless.org/scroll/file/README.html
Bug#976154: libpam-mount-bin doesn't install pmt-ehd's manpage (pmt-ehd.8)
Package: libpam-mount-bin Version: 2.16-10 Severity: normal X-Debbugs-Cc: par...@debian.org Dear Maintainer, The libpam-mount-bin package installs the /usr/sbin/pmt-ehd binary but not its manpage, which is available in the source package in doc/pmt-ehd.8. Please add it to d/libpam-mount-bin.manpages. Thanks! Paride -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-mount-bin depends on: ii libc62.31-4 ii libcryptsetup12 2:2.3.4-1 pn libhx32 pn libpam-mount libpam-mount-bin recommends no packages. libpam-mount-bin suggests no packages.
Bug#976152: gpsd-clients: gpsd apparmor profile prevents gpsfake from running
Package: gpsd-clients Version: 3.20-12+b1 Severity: normal X-Debbugs-Cc: par...@debian.org Hello, The apparmor profile shipped with gpsd prevents gpsfake from running. This can be easily reproduced by running: $ gpsfake and checking the dmesg: [269123.284600] audit: type=1400 audit(1606749402.192:90): apparmor="DENIED" operation="mknod" profile="/usr/sbin/gpsd" name="/tmp/gpsfake-206069.sock" pid=206070 comm="gpsd" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Using an empty file as does trigged the failure. [Bug originally reported in Ubuntu: https://pad.lv/1894330] Cheers, Paride -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gpsd-clients depends on: ii gir1.2-gtk-3.03.24.23-3 ii gpsd-tools3.20-12+b1 ii libbluetooth3 5.55-1 ii libc6 2.31-4 ii libdbus-1-3 1.12.20-1 ii libgps26 3.20-12+b1 ii libusb-1.0-0 2:1.0.23-2 ii python3 3.9.0-3 ii python3-cairo 1.16.2-4+b1 ii python3-gi3.38.0-1+b1 ii python3-gi-cairo 3.38.0-1+b1 ii python3-gps 3.20-12+b1 ii python3-serial3.5~b0-1 gpsd-clients recommends no packages. Versions of packages gpsd-clients suggests: ii gpsd 3.20-12+b1 -- no debconf information
Bug#974833: iw: output of 'mpath dump' is wrongly formatted
José Miguel Gonçalves wrote on 15/11/2020: Package: iw Version: 5.0.1-1 Severity: minor Dear Maintainer, Using iw to display a list of Mesh paths leads to a wrongly formatted output: $ sudo iw dev mesh0 mpath dump DEST ADDR NEXT HOP IFACE SN METRIC QLENEXPTIME DTIMDRETFLAGS 64:69:4e:XX:XX:XX 64:69:4e:XX:XX:XX mesh0 888557 0 0 100 0 0x14 84:eb:18:XX:XX:XX 84:eb:18:XX:XX:XX mesh0 44751 65 0 2292 100 0 0x15 f0:45:da:XX:XX:XX f0:45:da:XX:XX:XX mesh0 51710 66 0 1972 100 0 0x15 0c:1c:57:XX:XX:XX 0c:1c:57:XX:XX:XX mesh0 41711 66 0 2592 100 0 0x15 As you can see form the above iw command output, the table header, between "EXPTIME" and "DTIM" columns, has an extra tab. Hi José, thanks for this bug report. Could you perhaps test how the version of 'iw' currently in testing behaves? Cheers, Paride
Bug#975047: devscripts: Please consider demoting 'at' from Recommends to Suggests
Package: devscripts Version: 2.20.4 Severity: low X-Debbugs-Cc: par...@debian.org Dear Mattia and Pierre-Elliott, devscript currently Recommends 'at', which therefore gets installed by default. I think 'at' should be a Suggests. The rationale is that 'at' is not popular enough to justify the following: - 'at' installs and enables the 'atd' daemon. I think we should try to keep the number of daemons installed on users' systems low, as a general rule. - 'at' Recommends default-mta, which is provided by exim4. I think that getting a full MTA installed is normally not what the user wants when installing devscripts. - The basic function of 'at' can be achieved by using tools installed in Debian by default (namely `systemd-run --on-calendar`). Cheers, Paride
Bug#974612: an: test bug
Package: an Version: 1.2-6+b1 Severity: wishlist X-Debbugs-Cc: par...@debian.org Just a test bug, ignore.
Bug#974611: isc-kea: Please package the *stable* versions of Kea
Source: isc-kea Version: Please package the *stable* versions of Kea Severity: normal X-Debbugs-Cc: par...@debian.org, isc-...@packages.debian.org Dear Maintainers, As you certainly know Kea has a versioning scheme where odd minor numbers are used for development releases, while even minor numbers are considered stable. I.e. 1.5.x development 1.6.x stable 1.7.x development 1.8.x stale ... I think it would make sense for Debian to package only the stable (even) releases, perhaps uploading the development ones to experimental for testing purposes. At the moment this would mean packaging Kea-1.8.0, and not 1.9.1. What do you think? As a related question, do you plan to update the package any soon? If you can use some help please let me know and I'll submit salsa MRs. Thanks! Paride
Bug#726741: distro-info: Support Ubuntu's devel alias
On Fri, 18 Oct 2013 wrote: Package: distro-info Version: 0.11 Severity: wishlist Debian now has a devel alias, we should add alias support to Ubuntu. This now works: $ ubuntu-distro-info --devel hirsute Is it what this bug report was requesting? The bug is >7 years old so I wouldn't be surprised if a devel alias got added in the meantime :) Paride
Bug#973699: webext-browserpass: Ship the native messaging host in a separate package
Package: webext-browserpass Version: 3.4.1-4+b1 Severity: normal X-Debbugs-Cc: par...@debian.org Hello Michael, Could you please consider splitting out the native messaging host in a separate package and make it a Recommends of webext-browserpass? This would allow using browserpass from addons.mozilla.org without manually installing the native messaging host. Thanks! Paride -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages webext-browserpass depends on: ii fonts-open-sans 1.11-1 ii libc62.31-4 Versions of packages webext-browserpass recommends: ii chromium 83.0.4103.116-3.1 ii firefox 82.0.2-1 ii firefox-esr 78.4.0esr-2 webext-browserpass suggests no packages. -- no debconf information
Bug#969521: Browserpass icon disappears
On Fri, 04 Sep 2020 Vincent Bernat wrote:> When Firefox starts, Browserpass icons appear then shortly disappear. Disabling/enabling the extension is enough to fix this as long as Firefox keeps running. I can confirm this issue and that the suggested workaround works. Paride
Bug#972994: iw should no longer recommend crda
Paul Wise wrote on 01/11/2020: On Tue, 27 Oct 2020 11:33:54 + Paride Legovini wrote: * d/control: drop Recommends: crda (deprecated since linux v4.15) Thanks to Diederik de Haas (Closes: #972994) I note that this means wireless-regdb will no longer be installed but that is the location of the WiFi regulatory database and is still needed in order for the Linux kernel to comply with WiFi regulations, so I recommend that wireless-regdb be added to recommends in order to replace the crda dependency on wireless-regdb. Thanks Paul, I agree and by tomorrow I will do a new upload adding a Recommends: wireless-regdb I wonder if any QA tool or practice could have helped me to spot that the package was missing an important indirect dependency. I normally do a debdiff of new uploads with the previous version, but this doesn't help with indirect dependencies. Cheers, Paride
Bug#767577: iw: please add more detail to the manpage
control: severity -1 wishlist control: tags -1 + wontfix On Sat, 01 Nov 2014 David Bremner wrote: Package: iw Version: 3.17-1 Severity: minor The man page refers to "iw help" for more detailed information which is the wrong way around IMHO. Hi David, I agree in principle, however I think this should be fixed upstream rather than downstream (in Debian). Even if the effort of writing a more comprehensive manpage began from Debian, I'd suggest to submit the patch for upstream inclusion, which would have several benefits: - reduced risk of ending up with an out-of-sync manpage - review and feedback from upstream devs - wider reach due to adoption in other GNU/Linux distros This said, I'll certainly review patches against the Debian package improving on the status quo, but for the moment I'm tagging this bug report as 'wontfix' not to create expectations. Paride
Bug#825031: [pkg-wpa-devel] Bug#825031: Outdated package description
RFC: I updated the package description like this: https://salsa.debian.org/debian/iw/-/commit/41c64d01959a5feef36673a3fff2fa3615a4e61d If you have comments or suggestions please let me know, otherwise the next upload of 'iw' will have this new description. Thank you, Paride
Bug#972994: iw should no longer recommend crda
Diederik de Haas wrote on 27/10/2020: Package: iw Version: 5.9-1 Severity: normal https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/commit/?id=f4ef2531698fb9ba006e8b31a223b3269be8bc7c states: "README: add legacy notice As if kernel v4.15 CRDA is no longer needed. Annotate this. The code will still be maintained to help older kernels." Thus, afaict, crda isn't even needed by the current stable (kernel) release, let alone for the next (Bullseye) or later. Thanks! I understand it in the same way and I will do another upload dropping the Recommends. Paride
Bug#68585: looks like it applies holds too late
On Mon, 21 Jan 2013 Adam Borowski wrote: > Looking more closely (because it's especially bad for multiarch), I > see that it appears to be caused by applying holds too late. > > Let's say we have the following versions and dependencies: A=1 > (installed) A=2 Breaks: B B (installed, held) C (installed) Depends: > B > > (or any similar scenario, in my case A having available versions > A:amd64-2 and A:i386-1, B:i386 depending on A:i386) > > > If the resolver wants to upgrade A to version 2, it will decide that > it needs to remove B and C. It only then processes holds, marking B > and (transitively) A as kept. C still remains marked for removal, > even though any reason to do so is gone. I just hit this case with apt 2.1.10. In my case there are no held packages (apt-mark shows none). Apt version: $ apt --version apt 2.1.10 (amd64) The system is in a clean state with 2 packages to be upgraded (this is on Ubuntu, but it shouldn't really matter): $ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: gnome-settings-daemon gnome-settings-daemon-common 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded If I try to full-upgrade the two packages still don't get installed, but other packages get removed: $ sudo apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: apg fprintd gnome-control-center-faces libcolord-gtk1 libfprint-2-2 libgsound0 libhandy-1-0 libpam-fprintd libsysmetrics1 mobile-broadband-provider-info network-manager-gnome xwayland Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: gdm3 gnome-control-center gnome-initial-setup ubuntu-desktop ubuntu-desktop-minimal ubuntu-session The following packages have been kept back: gnome-settings-daemon gnome-settings-daemon-common 0 upgraded, 0 newly installed, 6 to remove and 2 not upgraded. After this operation, 9.264 kB disk space will be freed. Do you want to continue? [Y/n] Same command with debugging info: $ sudo apt -o Debug::pkgProblemResolver=1 full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Starting pkgProblemResolver with broken count: 1 Starting 2 pkgProblemResolver with broken count: 1 Investigating (0) gnome-settings-daemon:amd64 < 3.37.0-1ubuntu1 -> 3.37.0-1ubuntu2 @ii umU Ib > Broken gnome-settings-daemon:amd64 Breaks on gdm3:amd64 < 3.34.1-1ubuntu1 @ii mK > (< 3.37.0) Considering gdm3:amd64 30 as a solution to gnome-settings-daemon:amd64 48 Added gdm3:amd64 to the remove list Broken gnome-settings-daemon:amd64 Breaks on gnome-shell:amd64 < 3.36.4-1ubuntu2~build1 @ii mK NPb IPb > (< 3.37.90) Considering gnome-shell:amd64 72 as a solution to gnome-settings-daemon:amd64 48 Removing gnome-settings-daemon:amd64 rather than change gnome-shell:amd64 Investigating (0) gnome-control-center:amd64 < 1:3.37.90-1ubuntu2 @ii mK NPb Ib > Broken gnome-control-center:amd64 Depends on gnome-settings-daemon:amd64 < 3.37.0-1ubuntu1 | 3.37.0-1ubuntu2 @ii umR > (>= 3.29) Considering gnome-settings-daemon:amd64 48 as a solution to gnome-control-center:amd64 36 Removing gnome-control-center:amd64 rather than change gnome-settings-daemon:amd64 Investigating (0) ubuntu-session:amd64 < 3.36.0-2ubuntu1 @ii mK Ib > Broken ubuntu-session:amd64 Depends on gnome-settings-daemon:amd64 < 3.37.0-1ubuntu1 | 3.37.0-1ubuntu2 @ii umR > (>= 3.24) Considering gnome-settings-daemon:amd64 48 as a solution to ubuntu-session:amd64 33 Removing ubuntu-session:amd64 rather than change gnome-settings-daemon:amd64 Investigating (0) gdm3:amd64 < 3.34.1-1ubuntu1 @ii mK Ib > Broken gdm3:amd64 Depends on gnome-settings-daemon:amd64 < 3.37.0-1ubuntu1 | 3.37.0-1ubuntu2 @ii umR > (>= 3.24) Considering gnome-settings-daemon:amd64 48 as a solution to gdm3:amd64 30 Removing gdm3:amd64 rather than change gnome-settings-daemon:amd64 Investigating (0) gnome-initial-setup:amd64 < 3.37.91-1ubuntu1 @ii mK Ib > Broken gnome-initial-setup:amd64 Depends on gnome-settings-daemon:amd64 < 3.37.0-1ubuntu1 | 3.37.0-1ubuntu2 @ii umR > (>= 3.24) Considering gnome-settings-daemon:amd64 48 as a solution to gnome-initial-setup:amd64 5 Removing gnome-initial-setup:amd64 rather than change gnome-settings-daemon:amd64 Investigating (0) ubuntu-desktop-minimal:amd64 < 1.455 @ii mK Ib > Broken ubuntu-desktop-minimal:amd64 Depends on gdm3:amd64 < 3.34.1-1ubuntu1 @ii mR > Considering gdm3:amd64 30 as a solution to ubuntu-desktop-minimal:amd64 3 Removing ubuntu-desktop-minimal:amd64 rather than change gdm3:amd64 Investigating (0) ubuntu-desktop:amd64 < 1.455 @ii mK Ib > Broken ubuntu-desktop:amd64 Depends on gdm3:amd64 < 3.34.1-1ubuntu1 @ii mR > Considering gdm3:amd64 30
Bug#927302: apache2ctl graceful can cause apache to run in a different cgroup
On Wed, 17 Apr 2019 13:05:08 -0400 Joey Hess wrote: > Package: apache2 > Version: 2.4.38-2 > Severity: normal > > If apache is not running when apache2ctl graceful is run, it starts the > daemon up itself: > > root@darkstar:~>systemctl stop apache2 > root@darkstar:~>apache2ctl graceful > httpd not running, trying to start > > Problem is, that results in an apache daemon running in a cgroup other > than the usual systemd cgroup for apache. > > That prevents systemctl from being used to manage apache. In particular, > both systemctl start apache2 and systemctl restart apache2 then silently > do nothing and exit 0. > > Seems this could happen in a race, if something runs apache2ctl > graceful just as apache is being upgraded or otherwise restarted, it > might see no apache process running and so start its own process up. > > I keep encountering this problem on a server intermittently. It has > resulted for me in apache not loading new letsencrypt certs for long > enough that certs have expired, at least twice. I don't entirely > understand why, since certbot seems to itself use apache2ctl graceful to > reload apache certs. > > IMHO, apache2ctl should not be starting the daemon itself when systemd > is in use; it ought to start it via systemctl or service. And indeed, > apache2ctl start already does do that, but the fix for #839227 missed > that apache2ctl graceful can also start apache. I had a look at the apache2ctl script [1] and I agree in that the "restart|graceful)" case stanza requires the same change that fixed the bug #839227 for the "start" command. I'd also move the need_systemd logic out of the "case" to avoid duplication. Paride [1] https://salsa.debian.org/apache-team/apache2/-/blob/master/debian/apache2ctl
Bug#805310: libsasl2-modules: Annoying message "DIGEST-MD5 common mech free" with slapd
On Fri, 9 Nov 2018 14:04:18 +0100 Thomas D wrote: > Dear Maintainer, > > I can confirm that this is still a bug in Debian 9.5. > I get this message all the time on my subversion server. > > Any advice on how to get rid of this message for now? > And what plans are there to fix this in future releases? I didn't try it, but replacing /etc/logcheck/ignore.d.server/libsasl2-modules with the version proposed by IOhannes m zmoelnig [1] may work around the issue. If the change is confirmed to be working it should be very easy for the package maintainers to include it in the next upload. Paride [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805310#10
Bug#962916: import-ref --upstream-version: manpage/code discrepancy
Package: git-buildpackage
Version: 0.9.19
Severity: normal
Hi,
The gbp-import-ref manpage says that the default value for --upstream-tree
is BRANCH ("BRANCH (the default) merges from the upstream branch."),
while the actual default in the code is VERSION.
I think VERSION is what we want.
Cheers,
Paride
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages git-buildpackage depends on:
ii devscripts 2.20.3
ii git1:2.27.0-1
ii man-db 2.9.2-1
ii python33.8.2-3
ii python3-dateutil 2.8.1-4
ii python3-pkg-resources 46.1.3-1
ii sensible-utils 0.0.12+nmu1
Versions of packages git-buildpackage recommends:
ii pristine-tar 1.47
ii python3-requests 2.23.0+dfsg-2
ii sbuild0.79.1-1
Versions of packages git-buildpackage suggests:
pn python3-notify2
ii sudo 1.9.0-1
ii unzip6.0-25
-- no debconf information
Bug#962590: less: Move to /usr/bin leaves 'pager' broken during upgrade
Package: less Version: 551-1 Severity: important less 551-1 moves the binaries from /bin to /usr/bin, hoewevr the 'pager' alternative is updated only at postinst. This can break system upgrades, as the pager can be used by dpkg during upgrades to show the diff between conf files, but the pager is broken up to the point when less gets configured. First reported in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1874953 Fixed in Ubuntu by running update-alternatives at preinst. Paride
Bug#961672: [debian-mysql] Bug#961672: charset files not installed in a mysql-safe location
Hi Otto, Otto Kekäläinen wrote on 28/05/2020: > A future version of MariaDB might have the charsets in its own > directory, but we can't start changing paths of stuff in existing > stable releases, such as MariaDB 10.3 in Ubuntu 20.04 or Debian > Buster. If MySQL introduces a backwards incompatible change, the new > uploads should test for them and work around issues discovered. > > In MariaDB we are building python-mysql against libmariadb on every > commit in the CI to ensure nothing is broken: > https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines > > If you think MythTV has something unique about this, we could add > MythTV builds to the CI to ensure new uploads of MariaDB does not > break MythTV builds in Debian? I don't think there's anything special about MythTV, in my understading it's just how some users happened to hit the problem. I hit it in a completely different way: as a failure in an autopkgtest of libdbd-mariadb-perl. I have not much to add to your analysis, and I agree in that we can't and shouldn't change the structure of the packages in existing stable releases. However we can take this issue as a good warning on the fact that compatibility between the two DBs can't be assumed, and the packages in the development releases should start taking this into account. Cheers, Paride
Bug#961672: charset files not installed in a mysql-safe location
Package: mariadb-server-core-10.3 Version: 1:10.3.22-1 mariadb-server-core-10.3 installs the mariadb charset files in /usr/share/mysql: $ dpkg -L mariadb-server-core-10.3 | grep charset /usr/share/mysql/charsets /usr/share/mysql/charsets/Index.xml /usr/share/mysql/charsets/README /usr/share/mysql/charsets/armscii8.xml /usr/share/mysql/charsets/ascii.xml [...] /usr/share/mysql/charsets/swe7.xml The location of these files causes the libmysqlclient20 client library to consider them charset files from mysql, and it tries to use them. I think this behavior is wrong, as the charset files do not belong to mysql, however it is not immediately causing user-visible issues. Things are worse with mysql-8.0, not yet in Debian but packaged in Ubuntu. In mysql-8.0 the charset file format is not compatible with the older versions, and this causes the client library to segfault when trying to use the charset files from mariadb. Relevant Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1877504 I'm not sure of the best way to fix this, maybe mariadb needs to use the /usr/share/mariadb namespace for its resources. Paride
Bug#956306: iw: outaded URL in man page
control: severity -1 minor jmranger wrote on 09/04/2020: > Package: iw > Version: 5.0.1-1 > Severity: normal > > Dear Maintainer, > > iw's man page refers to > http://wireless.kernel.org/en/users/Documentation/iw > which no longer works. AFAICT, the correct URL would now be > https://wireless.wiki.kernel.org/en/users/Documentation/iw > > Reporting on my installed version, but unpacking the current > iw_5.4-1_amd64.deb show that the issue is still present. > > Thanks! Thanks. The manpage comes from the upstream source and as of today the error is still present in master: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/tree/iw.8#n71 I'd prefer to have this fixed upstream rather patching the manpage in Debian. I'll try to submit a patch, or at least report the issue. Paride
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Ludovic Rousseau wrote on 06/04/2020: > Le 05/04/2020 à 16:40, Paride Legovini a écrit : >> Hello Ludovic, >> >> On Fri, 3 Apr 2020 15:37:20 +0200 Ludovic Rousseau >> wrote: > >>> When it fails: >>> - is the socket /var/run/pcscd/pcscd.comm still present? >> >> This was a hint in the right direction and I think it makes most of the >> logs I collected useless. Apparently when the problem occurs the >> /var/run/pcscd/pcscd.comm socket is not there anymore, but systemd still >> have a file descriptor open for it, as I found out using lsof: >> >> COMMAND PID TID TASKCMD USER FD TYPE DEVICE >> SIZE/OFF NODE NAME >> systemd 1 root 45u unix 0xa066a5154400 >> 0t0 3172053 /run/pcscd/pcscd.comm type=STREAM >> >> I think the systemd socket unit (pcscd.socket) does not recreate the >> socket because of this, and passes a "dead" file descriptor to pcscd. >> What exactly deletes the pcscd.comm socket is not clear to me. Now after >> fiddling with pcscd I don't think I have clean logs to provide, I prefer >> to wait for the problem to happen again and then check if anything >> relevant is logged. I did try to suspend/resume a few times but but I >> didn't manage to reproduce the issue. But maybe you know what could be >> deleting the socket. > > pcscd can remove the /var/run/pcscd/pcscd.comm socket but only when NOT > started by systemd. This is done on init and exit of pcscd. > When pcscd is started by systemd you have a log message like: > Apr 03 12:51:52 stramonio pcscd[98472]: 0032 pcscdaemon.c:451:main() > Started by systemd > > Maybe, sometimes, pcscd does not detect it is started by systemd. But in > this case the socket should be re-created by pcscd so that should not be > the correct explanation. > > Or maybe the problem is on the systemd side? > > You can continue generating logs. They are a good indication of what is > happening. > You can limit logs to the info level using --info instead of --debug. > You can also remove the --apdu argument. > > If I read correctly your previous message you have logs with: > - pcscd is started by systemd > - pcscd correctly indicates "Started by systemd" > - but the communication is broken (pcsc_scan fails) and I guess the file > /var/run/pcscd/pcscd.comm is missing > - you stop pcscd: systemctl stop pcscd > - you start pcscd: systemctl start pcscd > - pcscd correctly indicates "Started by systemd" > - the communication is still broken and, I guess, the file > /var/run/pcscd/pcscd.comm is still missing All correct, this fits what I observe and I think it is what is happening, but before digging more I want to collect some cleaner logs, just to be sure. While trying to debug this I tried different things, including starting pcscd manually (outside systemd), so my logs are dirty now, and I don't want to lose time on a red herring. > To re-create the file /var/run/pcscd/pcscd.comm you need to use: > systemctl stop pcscd.socket > systemctl start pcscd.socket Correct. > See also > https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html > > > I still have no clue when and why the socket file is removed. Thanks, all useful information. I'll keep the service running with --info and try to understand what happens when the socket is lost. Paride
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Hello Ludovic, On Fri, 3 Apr 2020 15:37:20 +0200 Ludovic Rousseau wrote: > Hello Paride, > > Le 03/04/2020 à 13:20, Paride Legovini a écrit : > > Hi, > > > > I'm also hitting this issue, but after trying a few things I'm not > > convinced it is strictly a "resume after suspend" problem. But > > let's proceed with order. > > > > I normally keep a OpenPGP smartcard in my laptop's smartcard reader and > > I use it via scdaemon with disable-ccid. Sometimes when I suspend and > > resume my laptop I lose access to the smartcard: gnupg/scdaemon can't > > find it anymore. Restarting pcscd helps (systemctl restart pcscd) often > > but *not always* helps. > > > > I tried to collect logs running pcscd in foreground in a shell, but > > guess what, it *never* happens if I run it like this. The problem seems > > to happen only when pcscd is started by systemd, and I found out that I > > can reproduce it by restarting pcscd several time with systemctl. So I > > modified pcscd.service like this: > > > > > > [Service] > > Environment=LIBCCID_ifdLogLevel=0x000F > > ExecStart=/usr/sbin/pcscd --foreground --debug --apdu > > #ExecStart=/usr/sbin/pcscd --foreground --auto-exit > > #ExecReload=/usr/sbin/pcscd --hotplug > > > > > > in order to collect the relevant logs. Here they are. > > Thanks a lot for your tests and logs. > When it fails: > - is the socket /var/run/pcscd/pcscd.comm still present? This was a hint in the right direction and I think it makes most of the logs I collected useless. Apparently when the problem occurs the /var/run/pcscd/pcscd.comm socket is not there anymore, but systemd still have a file descriptor open for it, as I found out using lsof: COMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd1 root 45u unix 0xa066a5154400 0t0 3172053 /run/pcscd/pcscd.comm type=STREAM I think the systemd socket unit (pcscd.socket) does not recreate the socket because of this, and passes a "dead" file descriptor to pcscd. What exactly deletes the pcscd.comm socket is not clear to me. Now after fiddling with pcscd I don't think I have clean logs to provide, I prefer to wait for the problem to happen again and then check if anything relevant is logged. I did try to suspend/resume a few times but but I didn't manage to reproduce the issue. But maybe you know what could be deleting the socket. > - what do you get when you run pcsc_scan? (from the pcsc-tools package) It fails with: SCardEstablishContext: Service not available. as it can't find the socket. > PS: maybe you should change your smart card password if it starts with "c". That was already a temporary password as I did fear the debugging logs might leak it, but thanks for the warning :) Adding a note on the website where the instructions on how to collect logs are given might be a good idea. Thank again, Paride
