Bug#1016197: RM: tiddit [s390x] -- ROM; Depends on python3-pysam which is unavailable on s390x
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-...@lists.debian.org Hi, In recent upload of tiddit (new upstream release) it has started to depend on python3-pysam. python3-pysam is unavailable on s390x because of its dep bcftools not being supported on the same arch. Now, this is stallling tiddit's migration to testing. Since there are virtually no users of this package on s390x it should be fine to drop it from there anyway. Please consider doing so! Best, Nilesh
Bug#1016196: po4a: Using preconv to save translated man pages with UTF-8?
Package: po4a Version: 0.67-2 I noticed something with the translated man pages of the LinuxCNC project. The non-ascii characters show up as mojobake in the nb manual pages. I tracked down a solution in https://stackoverflow.com/questions/52732988/nroff-groff-does-not-properly-convert-utf-8-encoded-file >. By converting the UTF-8 files with 'preconv', 'nroff -man file.9' is handled properly. I suspect po4a should do this automatically, but man Locale::Po4a::Man do not mention preconv. Perhaps it should? -- Happy hacking Petter Reinholdtsen
Bug#1003165: scikit-learn testing migration
Am Thu, Jul 28, 2022 at 08:15:45PM -0700 schrieb M. Zhou: > I have a long-term power 9 VM (not QEMU) as testbed. > I'm trying to investigate the issues for release architectures, > but this package is too slow to build with QEMU (multiple hours). > (abel.debian.org is also extremely slow for scikit-learn) > I've not yet given up, but the build speed means I cannot > address this issue in timely manner. I just like to repeat my point: If the package is to slow on release architectures, that we will not manage to fix it, it is in the interest of our users to not support the problematic architectures in favour of providing it for the architetures where the package is used in practice. I have perfectly understood that we will loose several packages on that architectures and that this is not a good step. But having those packages not at all is eve worse. Kind regards Andreas. -- http://fam-tille.de
Bug#1016195: podman: fails to run any container
Package: podman
Version: 3.0.1+dfsg1-3+deb11u1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: vincent.olivert.ri...@gmail.com
Dear Maintainer,
I'm strictly running Debian stable with no packages from testing or
unstable.
When trying to run any container with podman I see the following error:
$ podman run --rm -it debian:bullseye-slim bash
Error: OCI runtime error: container_linux.go:367: starting container process
caused: process_linux.go:340: applying cgroup configuration for process caused:
error while starting unit
"libpod-410aba7b65566d9ddf2f0d2f188a22ed53577b90eea67e773c8294fa8bd252f3.scope"
with properties [{Name:Description Value:"libcontainer container
410aba7b65566d9ddf2f0d2f188a22ed53577b90eea67e773c8294fa8bd252f3"} {Name:Slice
Value:"user.slice"} {Name:PIDs Value:@au [69240]} {Name:Delegate Value:true}
{Name:MemoryAccounting Value:true} {Name:CPUAccounting Value:true}
{Name:IOAccounting Value:true} {Name:DefaultDependencies Value:false}
{Name:DevicePolicy Value:"strict"} {Name:DeviceAllow Value:@a(ss) []}
{Name:DeviceAllow Value:["INVALID", "INVALID", "INVALID", "INVALID", "INVALID",
"INVALID", "INVALID", "INVALID", "INVALID", "INVALID", "INVALID"]}
{Name:TasksAccounting Value:true} {Name:TasksMax Value:@t 2048}]: error
creating systemd unit
`libpod-410aba7b65566d9ddf2f0d2f188a22ed53577b90eea67e773c8294fa8bd252f3.scope`:
got `failed`
I tried replacing runc with crun, but the same problem persist, although
the error message is shorter:
$ podman run --rm -it debian:bullseye-slim bash
Error: OCI runtime error: error creating systemd unit
`libpod-df9c347e24f4ea213f8c81d6211f60e015e48b2f4b9118558f9fa95f8c7610fd.scope`:
got `failed`
Just in case it matters, my system is up to date and the version of
systemd I have installed is 247.3-7.
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.25+ds1-1.1
ii containernetworking-plugins 0.9.0-1+b6
ii golang-github-containers-common 0.33.4+ds1-1+deb11u1
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc62.31-13+deb11u3
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1+deb11u1
ii runc 1.0.0~rc93+ds1-5+deb11u2
Versions of packages podman recommends:
ii buildah 1.19.6+dfsg1-1+b6
ii fuse-overlayfs1.4.0-1
ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7
ii slirp4netns 1.0.1-2
ii tini 0.19.0-1
ii uidmap1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage
pn docker-compose
-- no debconf information
Bug#1003165: scikit-learn testing migration
I have a long-term power 9 VM (not QEMU) as testbed. I'm trying to investigate the issues for release architectures, but this package is too slow to build with QEMU (multiple hours). (abel.debian.org is also extremely slow for scikit-learn) I've not yet given up, but the build speed means I cannot address this issue in timely manner. On Thu, 2022-07-28 at 10:15 +0200, Andreas Tille wrote: > Hi Graham, > > Am Thu, Jul 28, 2022 at 09:15:06AM +0200 schrieb Graham Inggs: > > Hi > > > > On Wed, 27 Jul 2022 at 17:57, M. Zhou wrote: > > > The previous segfault on armel becomes Bus Error on armel and armhf. > > > I can build it on Power9, but it seems that the test fails on power8 (our > > > buildd). > > > > In #1003165, one of the arm porters wrote they are happy to look at > > the bus errors, but the baseline issue should be fixed first. > > ... this was five months ago and silence since then. We've lost lots of > packages in testing and I see no progress here. It seems upstream is not > actually keen on working on this as well. Meanwhile they stepped forward > with new releases and I simply refreshed the issues for the new version > (which are the same and not solved). > > Currently we have bus errors on arm 32 bit architectures and a baseline > violation on power. If there is no solution at the horizon I'd vote for > excluding these three architectures instead of sit and wait (which is all > I can personally do in this topic). > > > > I have skimmed over the build logs and one of the main issues is the use > > > of > > > -march flags to enforce a certain baseline [1]: > > > > > > powerpc64le-linux-gnu-gcc: error: unrecognized command-line option > > > ‘-march=native’; did you mean ‘-mcpu=native’? > > > > This may be the cause of the test failures on power8. > > Could someone give this a try? I know I could use a porter box to do > so but my time is to limited to do it in a sensible time frame. > > Kind regards > > Andreas. >
Bug#938987: Possible solution
Hello, I got bitten by a problem where NSD would not start and looks very similar to what it’s reported here. Since I found a way to make it work without fiddling with systemd I felt like reporting back. In my case, using Debian 11, the service starts correctly when freshly installed. The problem presents itself when using dynamic zones, specifically when the file /var/lib/nsd/zone.list comes into existence. Usually created automatically when using something like this `nsd-control addzone example.com example`. After this the service won’t start with a 'permission denied’ to read the zone.list file. This file gets created with owner nsd and group nsd. What needs to be done is change the ownership of this file to root:root and everything works. Even adding new zones work and the ownership of the file remains root:root. The cause for this could apparently be that the service initially starts as root and then drops to nsd. Not too sure about the cause though. This was discussed here[1]. A definitive solution could be that the package creates that file with the correct ownership “root:root” and no content. Also, please let me know if anyone see any possible problems with this fix. Thanks. [1]: https://www.mail-archive.com/nsd-users@nlnetlabs.nl/msg00078.html
Bug#1006020: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
Hello Luca and Michel,
On 7/28/22 5:50 PM, Michel Alexandre Salim wrote:
> Hi Ben,
> I was independently working on pacman, and (thanks to the name
> collision with the existing pacman package) didn't notice this until
> it's mostly done.
That existing package is orphaned anyway, so it's annoying that it's
already there and not even being maintained. I do think it's still a
good idea to keep the current package name so people don't get confused
and accidentally install a potentially dangerous package manager for
another distribution instead of an arcade game.
> My use case is helping make systemd/mkosi CI easier (since it's hosted
> on GitHub, which provides Ubuntu LTS builders) - I'll flag this to
> some relevant people so they can help get this sponsored.
>
> PS archlinux-keyring is on its way to unstable, and per some feedback
> the keyring target directory is moved to the standard Debian path:
>
> https://salsa.debian.org/michel/archlinux-keyring/-/blob/main/debian
> /patches/use_std_keyring_dir.diff
>
> might want to apply this to your pacman, and configure pacman to use
> this path:
>
> https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/11
Okay, I've added the patch to my package and configured the keyringdir
option in debian/rules.
On 7/28/22 6:27 PM, Luca Boccassi wrote:
> Hi,
>
> I can sponsor this.
>
> A few remarks, aside from the keyring change mentioned by Michel:
>
> - all the doc build-dependencies (asciidoc, doxygen, help2man) can be
> marked with so that nodoc builds can be done
> - are curl and fakechroot really needed to build the package, or are
> they just used by self tests? if they are used only by tests, mark them
> as
> - is pkgconf really needed instead of pkgconfig, which is the default?
> - you need to add a libalpm-dev and ship the headers, pkgconfig file,
> unversioned .so and manpage in it, instead of in libalpm13, and remove
> the lintian override
> - libalpm13 is missing Pre-Depends: ${misc:Pre-Depends}
> - no need to specify the libarchive-tools and libgpgme11 dependencies
> on libalpm13, they will be autogenerated
> - does libalpm13 really need to depend on the binary curl executable?
Thanks, all of those have been fixed.
> - makepkg should not depend on build-essential nor on sudo
I was under the impression that makepkg depended on sudo, but after a
deeper look into the code, it appears to fall back on su if sudo is not
detected. I put build-essential there since makepkg expects base-devel,
the Arch Linux equivalent of build-essential, to be installed. I've now
removed sudo from Depends and moved build-essential to Recommends since
in most cases you would want it installed but it's not required.
> - no need to manually specify the dependency on libalpm13 in makepkg,
> it will be autogenerated
> - libalpm13 is missing the symbols file, you can generate it after
> building the library with:
>dpkg-gensymbols -plibalpm13
> -edebian/tmp/usr/lib/x86_64-linux-gnu/libalpm.so.13.0.1
> -Odebian/libalpm13.symbols
> - makepkg is missing a dependency on ${perl:Depends}
Fixed
> - are you sure all of these can run on GNU/Hurd and debian/kFreeBSD? If
> not, use 'linux-any' instead of 'any' as the architecture
Funny you should say that; I actually have a Debian GNU/kFreeBSD system
that I installed out of curiosity last year. When I was originally
making this package, I tested it out on that system and it worked.
> - it is not necessary anymore to specify the build system in
> debian/rules, meson is autodetected
> - use execute_before_dh_auto_clean instead of override_
Fixed
> - 228 tests fail when running in a pbuilder chroot, this is a strong
> hint that the build might fail once uploaded
I use sbuild instead of pbuilder since it's considered to be legacy at
this point. As Michel noted, these failures are solved by two additional
build depends (one of which you should've already had) which I've added.
> - you should try and fix the reproducible build, rather than disabling
> it in the CI
I've tested reproducibility with reprotest and it's perfectly
reproducible. Salsa CI fails a bunch of tests on its second
reproducibility build, and I haven't been able to find the root cause.
It's been suggested to me that Salsa CI's reprotest job might be faulty.
I'll do some more research into the topic when I have time.
> - the GPL-2+ in debian/copyright says in the last paragraph:
>"On Debian systems, the full text of the GNU General Public
> License version 3 can be found in the file"
> instead of version 2
Fixed
Thank you both for your interest and deep review of this package! I
learned a lot of minor Debian things that I didn't know about before.
I've published my changes to Salsa and Mentors. You've helped me to
address the weaker points of my package that I wasn't so sure about
(dependencies and packaging a library) and I've learned more in my
Debian packaging journey as a result!
Thanks,
--
Ben Westover
OpenPGP_signature
Description:
Bug#1016194: RM: onednn [all] -- ROM; no longer build for arch:all
Package: ftp.debian.org Severity: normal I removed bin:onednn-doc from src:onednn because it feels like a maintenance burden to me, and this doc package has a very low popcon number. Thus, since we no longer build bin:onednn-doc, we need to remove it so that the package can migrate to testing. Thank you for using reportbug
Bug#1016157: Fw: Re: [External] Re: Bug#1016157: systemd-detect-virt fails to detect Openstack on arm64
Thanks for reply. We will try to upgrade to 11 after the next update comes out. From: "Michael Biebl" Date: 7月29日 (周五) 03:00 Subject: [External] Re: Bug#1016157: systemd-detect-virt fails to detect Openstack on arm64 To: "Ruidong Cao", <1016...@bugs.debian.org> Control: fixed -1 251-1Control: user pkg-systemd-maintain...@lists.alioth.debian.org ,Control: usertag -1 + bullseye-backportAm 28.07.22 um 10:28 schrieb Ruidong Cao:> Package: systemd> Version: 241-7~deb10u8> Severity: normal> > Dear Maintainer,> We have an arm64 vm created by Openstack, but systemd-detect-virt returns none. Do you consider backport the upstream patch> https://github.com/systemd/systemd/commit/01d9fbccddd694bc584aed24eaa0543f831dc929 ?> And what about next systemd deb update package release plan?old-stable (debian 10) will only receive security fixes at this point.For stable (debian 11), I marked the issue so we can include it in the next stable point release, which will be scheduled in the next 2-3 months.Thus my advice would be to upgrade to stable if you want to receive a fix for this issue.Michael
Bug#1015845: about gtkhash ITA
Hi Arnaud, Do you want ITA gtkhash package now? This package had orphan now, see #1015845. If you don't want ITA it, I would do ITA. Regards, -- 肖盛文 xiao sheng wen https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com Debian salsa: https://salsa.debian.org/atzlinux-guest GnuPG Public Key: 0x00186602339240CB OpenPGP_signature Description: OpenPGP digital signature
Bug#981118: O: elpa-undo-tree -- Emacs minor mode for handling undo history as tree
control: retitle 981118 ITA: elpa-undo-tree control: owner 981118 aymeric.a...@yandex.com I wish to adopt the package. I already have a lintian clean package up to date with upstream at https://gitlab.com/aagonrambosson/undo-tree. Best, Aymeric Agon-Rambosson
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Fri, 2022-07-29 at 01:17 +0200, Chris Hofstaedtler wrote: > * Ben Hutchings : > [..] > > Right. So this seems like a botched transition - fuse3 should have > > taken over the fuse binary package but instead each reverse-dependency > > has to be updated. I agree it would make sense in the short term to > > force fuse3 installation. > [..] > > Thank you for pointing out the problem. Even if the exact issue > > doesn't occur in Debian, we should sort out fuse vs fuse3. > > I would imagine #918984 is related. Right. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
* Ben Hutchings : [..] > Right. So this seems like a botched transition - fuse3 should have > taken over the fuse binary package but instead each reverse-dependency > has to be updated. I agree it would make sense in the short term to > force fuse3 installation. [..] > Thank you for pointing out the problem. Even if the exact issue > doesn't occur in Debian, we should sort out fuse vs fuse3. I would imagine #918984 is related. Chris
Bug#1006020: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
On Thu, Jul 28, 2022 at 11:27:37PM +0100, Luca Boccassi wrote: > On Sat, 19 Feb 2022 00:13:37 -0500 Ben Westover > wrote: > > Package: sponsorship-requests > > Severity: wishlist > > > > Dear mentors, > > > > I am looking for a sponsor for my package "pacman-package-manager": > > > > Hi, > > I can sponsor this. > > - 228 tests fail when running in a pbuilder chroot, this is a strong > hint that the build might fail once uploaded I spent this morning bashing those tests: to get them to pass, both fakeroot (fixes ~ 200 tests; not needed if running meson test interactively) and fakechroot (for the last ~ 19 tests) need to be added to BuildDepends. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature
Bug#1016191: RM: vzstats -- RoQA; requires unavailable API, obsolete, privacy breach
Package: ftp.debian.org Severity: normal Dear FTP Masters, please remove vzstats. It is related to the old OpenVZ project, and its sole purpose is to submit system stats to OpenVZ.org, using an API which no longer exists. I think nowadays we would also consider the entire package just a privacy breach and not package it. There are no r-deps. Thanks, Chris
Bug#1006020: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
On Sat, 19 Feb 2022 00:13:37 -0500 Ben Westover
wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "pacman-package-manager":
>
> * Package name : pacman-package-manager
> Version : 6.0.1-1
> Upstream Author : Pacman Development Team
> * URL : https://archlinux.org/pacman/
> * License : GPL-2+, MIT, curl, unlicense, public-domain
> * Vcs : https://salsa.debian.org/benthetechguy/pacman
> Section : admin
>
> It builds those binary packages:
>
> pacman-package-manager - Simple library-based package manager
> libalpm13 - Arch Linux Package Management library
> makepkg - Arch Linux package build utility
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/pacman-package-manager/
>
> Alternatively, one can download the package with dget using this
command:
>
> dget -x
>
https://mentors.debian.net/debian/pool/main/p/pacman-package-manager/pacman-package-manager_6.0.1-1.dsc
>
> Changes for the initial release:
>
> pacman-package-manager (6.0.1-1) unstable; urgency=medium
> .
> * Initial Package (Closes: #511994)
Hi,
I can sponsor this.
A few remarks, aside from the keyring change mentioned by Michel:
- all the doc build-dependencies (asciidoc, doxygen, help2man) can be
marked with so that nodoc builds can be done
- are curl and fakechroot really needed to build the package, or are
they just used by self tests? if they are used only by tests, mark them
as
- is pkgconf really needed instead of pkgconfig, which is the default?
- you need to add a libalpm-dev and ship the headers, pkgconfig file,
unversioned .so and manpage in it, instead of in libalpm13, and remove
the lintian override
- libalpm13 is missing Pre-Depends: ${misc:Pre-Depends}
- no need to specify the libarchive-tools and libgpgme11 dependencies
on libalpm13, they will be autogenerated
- does libalpm13 really need to depend on the binary curl executable?
- makepkg should not depend on build-essential nor on sudo
- no need to manually specify the dependency on libalpm13 in makepkg,
it will be autogenerated
- libalpm13 is missing the symbols file, you can generate it after
building the library with:
dpkg-gensymbols -plibalpm13
-edebian/tmp/usr/lib/x86_64-linux-gnu/libalpm.so.13.0.1
-Odebian/libalpm13.symbols
- makepkg is missing a dependency on ${perl:Depends}
- are you sure all of these can run on GNU/Hurd and debian/kFreeBSD? If
not, use 'linux-any' instead of 'any' as the architecture
- it is not necessary anymore to specify the build system in
debian/rules, meson is autodetected
- use execute_before_dh_auto_clean instead of override_
- 228 tests fail when running in a pbuilder chroot, this is a strong
hint that the build might fail once uploaded
- you should try and fix the reproducible build, rather than disabling
it in the CI
- the GPL-2+ in debian/copyright says in the last paragraph:
"On Debian systems, the full text of the GNU General Public
License version 3 can be found in the file"
instead of version 2
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1016190: ship sanitizer with bookworm?
Source: sanitizer Version: 1.76-5.1 Severity: important Hi, sanitizer appears to be a program to introspect and modify incoming email. It also has gone at least 15 years without an upstream release. Personally I find it unlikely that these two facts go well together, and would suspect nobody is using this program anymore. If nobody replies here, I will raise severity of this bug and eventually file for removal, ideally before bookworm freeze. Chris
Bug#1016151: linux-image-686: (EE) open /dev/dri/card0: No such file or directory with Intel 82810E iGPU
Control: reassign -1 src:linux Control: tag -1 upstream wontfix The i810 driver is not compatible with full preemption. Since the introduction of PREEMPT_DYNAMIC, our standard kernel supports full preemption and the i810 driver is not built. This is unlikely ever to be fixed. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#1016189: RM: memtest86 -- RoQA; obsolete, buggy, alternatives exist
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: m...@debian.org, fantonifa...@tiscali.it, fziel...@z-51.de Dear FTP Masters, please remove memtest86. As stated by the last maintainer in #969192, alternatives exist. Actually it appears memtest86+ and pcmemtest have been merged, and memtest86+ 6.0 will be the pcmemtest code base. Having an old, unmaintained memory tester which, according to bug reports, does not even start anymore helps no one. Lets get rid of this variant. I'll tag this moreinfo in a moment, so everyone interested has enough time to say something about this bug. I'll untag it in a month or so. Best, Chris
Bug#1006020: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
Hi Ben, I was independently working on packaging pacman, and (thanks to the name collision with the preexisting pacman package) didn't notice this until it's mostly done. My use case is helping make systemd/mkosi CI easier (since it's hosted on GitHub, and GitHub provides Ubuntu LTS builders) - I'll flag this to some relevant people so they can help get this sponsored. PS archlinux-keyring is on its way to unstable, and per review feedback the keyring target directory is moved to the standard Debian path: https://salsa.debian.org/michel/archlinux-keyring/-/blob/main/debian/patches/use_std_keyring_dir.diff might want to apply this to your pacman, and configure pacman to use this path: https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/11 Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature
Bug#1016188: UDD/lintian: cannot filter only by lintian tag
Package: qa.debian.org User: qa.debian@packages.debian.org Usertags: udd Severity: normal Hi, While testing the new "search by lintian tag" feature in UDD (thanks for taking care of #1016074!), I discovered one cannot filter using only a tag and nothing else in all the other fields. For example, this query (email1=team+pyt...@tracker.debian.org + lintian_tag=missing-prerequisite-for-pyproject-backend) works fine: https://udd.debian.org/lintian/?email1=team%2Bpython%40tracker.debian.org=html%3C_error=on%3C_warning=on%3C_information=on_tag=missing-prerequisite-for-pyproject-backend#all But this one (lintian_tag=missing-prerequisite-for-pyproject-backend) outputs nothing: https://udd.debian.org/lintian/?email1==html_error=on_warning=on_information=on_tag=missing-prerequisite-for-pyproject-backend#all I would've expected the second one to show all the packages in the archive that are tagged with 'missing-prerequisite-for-pyproject-backend' Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1008292: lintian: inconsistent-appstream-metadata-license seems to be a bad rule
Package: lintian Version: 2.115.2 Followup-For: Bug #1008292 X-Debbugs-Cc: 1002...@bugs.debian.org I think Bugs #1002053 and #1008292 are the same. I'm getting the same lintian warning with avogadro 1.97.0: W: avogadro source: inconsistent-appstream-metadata-license avogadro/icons/avogadro2.appdata.xml (cc0-1.0 != bsd-3-clause) [debian/copyright] I think the problem is not the spelling (#1002053) or even the licence discrepancy as such. The problem is that lintian (as it says) is comparing appstream-metadata-license with the License for * from debian/copyright. debian/copyright * refers to the *project* licence. But appstream-metadata-license refers to the licence specifically for the metainfo file itself, not for the project. See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license So in fact lintian is correct, the declared licence is wrong. To fix debian/copyright, an individual entry needs to be added for the specific metainfo file for your package. Once you've done that, I expect lintian will not emit this error. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.38.90.20220713-2 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.9 ii dpkg-dev1.21.9 ii file1:5.41-4 ii gettext 0.21-6 ii gpg 2.2.35-3 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.11.0-1 ii libapt-pkg-perl 0.1.40+b1 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b2 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b8 ii libclone-perl 0.45-1+b2 ii libconfig-tiny-perl 2.28-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.30-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-1+b3 pn libdigest-sha-perl ii libdpkg-perl1.21.9 ii libemail-address-xs-perl1.04-1+b4 ii libencode-perl 3.18-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-2 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-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.12-1 ii libmldbm-perl 2.05-3 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.122-1 ii libperlio-gzip-perl 0.20-1 ii libperlio-utf8-strict-perl 0.009-1+b1 ii libproc-processtable-perl 0.634-1+b1 ii libregexp-wildcards-perl1.05-2 ii libsereal-decoder-perl 4.023+ds-1 ii libsereal-encoder-perl 4.023+ds-1 ii libsort-versions-perl 1.62-2 ii libsyntax-keyword-try-perl 0.27-1 ii libterm-readkey-perl2.38-1+b3 ii libtext-levenshteinxs-perl 0.03-5 ii libtext-markdown-discount-perl 0.13-1+b1 ii libtext-xslate-perl 3.5.9-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b4 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b3 ii liburi-perl 5.12-1 ii libwww-mechanize-perl 2.12-1 ii libwww-perl 6.67-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1 ii libyaml-libyaml-perl0.83+ds-1+b1 ii lzip [lzip-decompressor]1.23-4 ii lzop1.04-2 ii man-db 2.10.2-1 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.34.0-5 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2.1 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no
Bug#1016147: lintian: false positive missing-build-dependency-for-dh-addon python3 when using dh-sequence-python3
owner 1016147 po...@debian.org tags 1016147 patch thanks Thanks for reporting this false-positive. I've sent an MR with a patch [1] and tested it against flask-appbuilder 4.1.3+ds-1. It seems to fix the issue. Cheers, [1]: https://salsa.debian.org/lintian/lintian/-/merge_requests/405 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1016080: buster-pu: package libreoffice/:6.1.5-3+deb10u8
Hi, Am 26.07.22 um 19:11 schrieb Rene Engelhard: actually this is quite a small update for a big package. Should we really do it (and the default change)? Or should we assume people don't use LO from oldstable anymore and either use bullseye or the bullseye version backported to buster? Filing for completeness' sake, though. I didn't have on radar that buster supports ends in a few days anyway. And doing the default change in LTS then even makes less sense for a effectively diff --git a/i18npool/source/localedata/data/hr_HR.xml b/i18npool/source/localedata/data/hr_HR.xml index 4de83e5535cd..eec5a9e98779 100644 --- a/i18npool/source/localedata/data/hr_HR.xml +++ b/i18npool/source/localedata/data/hr_HR.xml @@ -414,7 +414,7 @@ - + HRK kn HRK @@ -422,7 +422,7 @@ 2 - + EUR € EUR only... Hmm. In any case: [ ] the issue is verified as fixed in unstable Update: [x] the issue is verified as fixed in unstable This is not yet fixed in unstable, that will happen with the upload of 7.4.0 rc2 (or someting later) to it This now happened and thus 2) is fixed in unstable too - with 1:7.4.0~rc2-2. Regards, Rene
Bug#1016037: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u2 (was: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u1)
Hi, Am 26.07.22 um 13:24 schrieb Rene Engelhard: [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [ ] the issue is verified as fixed in unstable Update: [x] the issue is verified as fixed in unstable (2) is not yet fixed in unstable, that will happen with the upload of 7.4.0 rc2 (or someting later) to it This now happened and thus 2) is fixed in unstable too - with 1:7.4.0~rc2-2. Regards, Rene
Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.
On 2022-07-08 03:06, Yukiharu YABUKI wrote: How I do check where started ibus read the ibus configration? I did setup with im-config for ibus. It seems to me that ibus-daemon re-read my home configration. What exactly do you mean by "home configuration"? Actually, with im-config installed, there shouldn't be a need for any kind of configuration in your $HOME. ibus should still be started and properly configured. Do you possibly have some extra configuration which conflicts with im-config? -- Gunnar
Bug#1016187: collectd: FTBFS with gcc 12 (bookworm)
Source: collectd
Version: 5.12.0-9
Severity: serious
Tags: ftbfs
`collectd` fails to build from source, both when compiled locally and
when run from a salsa pipeline.
Full log: https://salsa.debian.org/gioele/pkg-collectd/-/jobs/3046171
```
src/capabilities.c: In function 'cap_http_handler':
src/capabilities.c:209:23: error: storing the address of local variable
'({anonymous})' in '*connection_state' [-Werror=dangling-pointer=]
209 | *connection_state = &(int){44};
| ~~^~~~
src/capabilities.c:209:31: note: '({anonymous})' declared here
209 | *connection_state = &(int){44};
| ^
src/capabilities.c:209:31: note: 'connection_state' declared here
cc1: all warnings being treated as errors
make[2]: *** [Makefile:7785: src/capabilities_la-capabilities.lo] Error 1
make[2]: Leaving directory '/build/collectd-5.12.0'
make[1]: *** [Makefile:5456: all] Error 2
make[1]: Leaving directory '/build/collectd-5.12.0'
make: *** [debian/rules:277: build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2
```
Regards,
--
Gioele Barabucci
Bug#1012145: bettercap: It looks like the advertised Bluetooth LE function missing
Hello Tino, Thanks for reporting this. I happen to know that the gps functionality had to be disabled due to a licensing issue (which has been solved now): https://github.com/bettercap/bettercap/issues/938 But I don't remember what was the issue with the Bluetooth feature, so I'd like to do some investigation (either myself or someone else) before removing that from the description, since it might be possible to enable it. If we end up too close to the new stable release without this, then we shall remove it from the description. So just to be clear, the gps functionality should appear at some point in the near future, since the licensing issue has been addressed, and the bluetooth one is TODO to figure out why it's disabled. Thanks, -- Samuel Henrique
Bug#1001669: closed by Debian FTP Masters
On Thu, 28 Jul 2022 19:09:46 +0200 Gianfranco Costamagna wrote: On Sun, 27 Mar 2022 19:24:05 +0200 =?UTF-8?Q?Aniol_Mart=c3=ad?= wrote: > On Wed, 23 Mar 2022 09:09:00 +0100 Aniol Martí > wrote:> I've tried several times and I can't reproduce the bug. I would > need > > further details or assistance. Besides, I also noticed that the last > > test passed fine: > > https://ci.debian.net/data/autopkgtest/unstable/amd64/o/openvpn-auth-ldap/20263239/log.gz > > I've added some verbosity to the test and I've tried in with Salsa and > the problem seems to be the following: > > ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted > (errno=1) > > Although I've added "isolation-container" to the test restrictions it > still fails. Maybe there have been some changes in the Docker configuration? > > Regards, > Aniol > Hello, I tested on Ubuntu the following patch http://launchpadlibrarian.net/615132752/openvpn-auth-ldap_2.0.4-2_2.0.4-2ubuntu1.diff.gz due to new easy-rsa requiring one single "vars" file in the directory, and now at least in Ubuntu autopkgtests are passing. G. Hi, I've just tested it but autopkgtest still fails in Salsa because it cannot open a TUN/TAP device in the container: 2022-07-28 20:05:06 ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1) If I can fix this I will need to temporary disable this test. Regards, Aniol
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
Peter B, le jeu. 28 juil. 2022 20:11:58 +0100, a ecrit: > On 28/07/2022 19:19, Samuel Thibault wrote: > > Peter B, le jeu. 28 juil. 2022 18:01:42 +0100, a ecrit: > > > Thread 4 received signal ?, Unknown signal. > > > __pthread_enable_asynccancel () at cancellation.c:30 > > > 30cancellation.c: No such file or directory. > > > #0 __pthread_enable_asynccancel () at cancellation.c:30 > > Oh, right, of course. Could you try the updated package from > > https://people.debian.org/~sthibault/tmp/hurd-i386/ > > ? > > All working fine now! What happens next? Great :D I'll commit it upstream and set a dep-wait in buildd for duma to be retried with the newer glibc. Samuel
Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library
Hello Adam,
thanks for your review.
Am Mittwoch, dem 27.07.2022 um 04:26 +0200 schrieb Adam Borowski:
> On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
> > Package name : xbase64
> > Version : 3.1.2-14
>
> > xbase64 (3.1.2-14) unstable; urgency=medium
> > .
> > * Migrate to debhelper-compat 13:
> > - debian/control: Add debhelper-compat (= 13).
> > - Remove debian/compat.
> > - Add usr/bin/xbase64-config into new debian/not-installed.
> > - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
> > debian/libxbase64-bin.install.
> > * Declare compliance with Debian Policy 4.6.1.0 (No changes
> > needed).
> > * debian/copyright:
> > - Add year 2022 to myself.
> > * Disable Link time optimization (Closes: #1015707):
> > - debian/rules: Add optimize=-lto to DEB_BUILD_MAINT_OPTIONS.
> > * debian/control: Add Rules-Requires-Root: no.
>
> Is there a reason you include the .la file? From my experience it
> being
> needed for anything suggests severe borkage, and the Policy concurs:
>
[...]
That was my mistake. I only paid attention to the messages from
dh_missing and installed the la file without thinking too much.
Once again, thank you for your advice.
The error is corrected and uploaded to git and mentors.
>
>
> Meow!
CU
Jörg
--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56
Old pgp Key: BE581B6E (revoked since 2014-12-31).
Jörg Frings-Fürst
D-54470 Lieser
git: https://jff.email/cgit/
Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst
My wish list:
- Please send me a picture from the nature at your home.
signature.asc
Description: This is a digitally signed message part
Bug#990353: readline-common: make autocompletion case insensitive and display suggestions by default
Hello Matthias, > As discussed at DebConf, I'll add these as comments in the inputrc file. I > think that the behavior for the completion on first tab is worse, if you have > too many completions and your complete window is scrolled up. I think this is not correct, we were testing this together and we noticed that whenever there's too many suggestions to show, the user needs to confirm that it really wants to get it, for example: $ cd /proc/ Display all 363 possibilities? (y or n) The user needs to type "y" to get all the suggestions. > Same about the case sensitive option. I'm wondering if this setting could be > automated depending on the locale (e.g. if the locale is case insensitive, > LC_COLLATE?) For case sensitivity the same applies, the user needs to confirm to see all of the suggestions if there are too many. > Are these options really meant to be in the emacs-mode section? No, that was me not paying enough attention on where to put the new settings. I appreciate the consideration, and I would like to have these options enabled by default, as new users are not aware of the existence of them and experienced users will know how to disable it, if they wish. But I also think there's still a benefit for our users if you only want to add these commented out (disabled). If you decide to not make it the default, would you mind leaving this bug open so at least I can keep track of this request and possibly point other people to it if they're interested in following it? Thanks for considering! -- Samuel Henrique
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Wed, 2022-07-27 at 14:25 +0200, Arnaud Rebillout wrote: > On Thu, 14 Jul 2022 20:14:15 +0200 Ben Hutchings > wrote: > > > > You should find out why that is, before proposing to override it. What > > if something in KDE really does need FUSE 2? > > I don't think that it can happen. A package might need FUSE3 (in such > case it depends on fuse3), or it might need FUSE (any implementation) > (in such case it depends on fuse, and it's either fuse or fuse3 that > will be installed, as fuse3 Provides fuse). But it cannot really ask for > FUSE2, as far as I understand (there's no fuse2 package). That makes sense. > In the case I described above, if fuse gets installed, it's not because > a package needs FUSE2, it's because no package needs FUSE3. So apt picks > fuse rather than fuse3. > Right. So this seems like a botched transition - fuse3 should have taken over the fuse binary package but instead each reverse-dependency has to be updated. I agree it would make sense in the short term to force fuse3 installation. > > (Since you found that removing fuse doesn't remove anything else, this > > implies that the relationship is only a Recommends and not a Depends. > > But that doesn't mean that removal won't break anything.) > > I believe that if replacing fuse by fuse3 doesn't remove anything, it's > because fuse3 Provides fuse. > > In any case: in Kali we solved that by recommending fuse3 in > kali-desktop-core, a metapackage that is always installed with every > Kali desktop. Therefore we're sure to have fuse3 (we don't let apt > guess), and we're sure that open-vm-tools will be installed if needed. > It's a better solution than modifying hw-detect as I suggested here. > > Therefore I'll close this bug, as I don't think it affects Debian anyway. > > Thanks for your feedback, and sorry for the noise. Thank you for pointing out the problem. Even if the exact issue doesn't occur in Debian, we should sort out fuse vs fuse3. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
On 28/07/2022 19:19, Samuel Thibault wrote: Peter B, le jeu. 28 juil. 2022 18:01:42 +0100, a ecrit: Thread 4 received signal ?, Unknown signal. __pthread_enable_asynccancel () at cancellation.c:30 30 cancellation.c: No such file or directory. #0 __pthread_enable_asynccancel () at cancellation.c:30 Oh, right, of course. Could you try the updated package from https://people.debian.org/~sthibault/tmp/hurd-i386/ ? Samuel All working fine now! What happens next? I will ask for duma to be rebuilt when the libc fix reaches sid. Many thanks, Peter
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
On 19/07/2022 14:06, Emilio Pozuelo Monfort wrote: On 15/07/2022 14:24, Emilio Pozuelo Monfort wrote: Control: retitle -1 buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u2 On 13/07/2022 12:55, Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org This backports LLVM 13 to buster, for Firefox/Thunderbird ESR 102. The changes from the bullseye backport are minimal, debdiff attached. I have already uploaded the package, but let me know if you have any comments. I have noticed a couple of problems: - there's a build-dep that worked for me because of the alternative, but didn't in the buildds. I have addressed that here. - I brought back mips support The mips changes were incomplete. I have uploaded deb10u3 with an additional fix for mips. Unlikely that there's anyone still using firefox in mips, specially as it hasn't been built in a long time, but the fix is easy so let's go ahead with it. Brown paper bag release, this adds mips in one extra place. Uploaded. Thanks, Emiliodiff -Nru llvm-toolchain-13-13.0.1/debian/changelog llvm-toolchain-13-13.0.1/debian/changelog --- llvm-toolchain-13-13.0.1/debian/changelog 2022-07-19 11:37:05.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/changelog 2022-07-21 09:14:44.0 +0200 @@ -1,3 +1,9 @@ +llvm-toolchain-13 (1:13.0.1-6~deb10u4) buster; urgency=medium + + * Disable libunwind on mips. + + -- Emilio Pozuelo Monfort Thu, 21 Jul 2022 09:14:44 +0200 + llvm-toolchain-13 (1:13.0.1-6~deb10u3) buster; urgency=medium * Disable lldb on mips. diff -Nru llvm-toolchain-13-13.0.1/debian/rules llvm-toolchain-13-13.0.1/debian/rules --- llvm-toolchain-13-13.0.1/debian/rules 2022-07-18 10:16:39.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/rules 2022-07-21 09:14:36.0 +0200 @@ -255,7 +255,7 @@ # Enable libunwind (or not) LIBUNWIND_ENABLE=yes -ifneq (,$(filter $(DEB_HOST_ARCH), s390x armel m68k mipsel hurd-i386 powerpc sparc sparc64 x32)) +ifneq (,$(filter $(DEB_HOST_ARCH), s390x armel m68k mips mipsel hurd-i386 powerpc sparc sparc64 x32)) LIBUNWIND_ENABLE=no # do not use compiler-rt builtins for libcxx (libcxxabi) when libunwind is # disabled since the gnu implementation in libgcc_s will then be required
Bug#1016186: gappa: please make the build reproducible
Source: gappa Version: 1.4.0-4 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that gappa could not be built reproducibly. This is because it ships the Sphinx doctree data which contains nondeterministic data, some of which is based on the absolute build path. A patch is attached that uses "--with sphinxdoc" which means these get cleaned up (as well as other "good" things). [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2022-07-28 11:41:11.864847173 -0700 --- b/debian/rules 2022-07-28 11:51:27.283666718 -0700 @@ -1,7 +1,7 @@ #!/usr/bin/make -f %: - dh $@ + dh $@ --with sphinxdoc override_dh_auto_configure: touch stamp-config_h.in
Bug#1016157: systemd-detect-virt fails to detect Openstack on arm64
Control: fixed -1 251-1 Control: user pkg-systemd-maintain...@lists.alioth.debian.org , Control: usertag -1 + bullseye-backport Am 28.07.22 um 10:28 schrieb Ruidong Cao: Package: systemd Version: 241-7~deb10u8 Severity: normal Dear Maintainer, We have an arm64 vm created by Openstack, but systemd-detect-virt returns none. Do you consider backport the upstream patch https://github.com/systemd/systemd/commit/01d9fbccddd694bc584aed24eaa0543f831dc929 ? And what about next systemd deb update package release plan? old-stable (debian 10) will only receive security fixes at this point. For stable (debian 11), I marked the issue so we can include it in the next stable point release, which will be scheduled in the next 2-3 months. Thus my advice would be to upgrade to stable if you want to receive a fix for this issue. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1014764: closed by Hilko Bengen (Re: Bug#1014764: guestfs-tools: CVE-2022-2211)g
* Moritz Muehlenhoff: > Hi Hilko, > But regardless of the rebuild > https://github.com/libguestfs/libguestfs-common/commit/35467027f657de76aca34b48a6f23e9608b23a57 > isn't present in 1.48.2? Uh, I addressed that to the wrong bug. Sorry … and thanks for catching this. Cheers, -Hilko
Bug#1016185: slapd: Broken encoding of non-ASCII organization names
Package: slapd Version: 2.5.12+dfsg-2 Tags: patch The `postinst` maintscript of `slapd` incorrectly encodes organization names with non-ASCII characters. The issue is that values received from debconf (already in UTF-8) are encoded once again via the function `encode_utf8`. This turns "pé" (0x70 0xC3 0xA9 = U+0070, U+00E9) into "pé" (0x70 0xC3 0x8e 0xC2 0xA9 = U+0070, U+00C3, U+00A9) There are two possible scenarios: 1. If one assumes that the string returned by debconf is UTF-8 encoded (that is the case in all modern setups), then there is no need for another round of encoding. 2. If instead, one assumes that the string returned by debconf is not UTF-8 encoded, then one should also know which encoding it is in, in order to perform the right conversion. The current code produces wrong results in both cases. A patch to fix this problem can be found at https://salsa.debian.org/openldap-team/openldap/-/merge_requests/6 Regards -- Gioele Barabucci
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
Peter B, le jeu. 28 juil. 2022 18:01:42 +0100, a ecrit: > Thread 4 received signal ?, Unknown signal. > __pthread_enable_asynccancel () at cancellation.c:30 > 30cancellation.c: No such file or directory. > #0 __pthread_enable_asynccancel () at cancellation.c:30 Oh, right, of course. Could you try the updated package from https://people.debian.org/~sthibault/tmp/hurd-i386/ ? Samuel
Bug#1016168: debootstrap 1.0.123+deb11u1 flagged for acceptance
package release.debian.org tags 1016168 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: debootstrap Version: 1.0.123+deb11u1 Explanation: ensure non-merged-usr chroots can continue to be created for older releases and buildd chroots
Bug#1014907: rustc-mozilla 1.59.0+dfsg1-1~deb10u2 flagged for acceptance
package release.debian.org tags 1014907 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: rustc-mozilla Version: 1.59.0+dfsg1-1~deb10u2 Explanation: inline atomics on arm64; increase allowed test failures on i386
Bug#1016179: shim 15.6-1~deb11u1 flagged for acceptance
package release.debian.org tags 1016179 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: shim Version: 15.6-1~deb11u1 Explanation: new upstream release
Bug#1016178: shim 15.6-1~deb10u1 flagged for acceptance
package release.debian.org tags 1016178 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: shim Version: 15.6-1~deb10u1 Explanation: new upstream release
Bug#1016177: mokutil 0.6.0-2~deb11u1 flagged for acceptance
package release.debian.org tags 1016177 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: mokutil Version: 0.6.0-2~deb11u1 Explanation: new upstream version, to allow for SBAT management
Bug#1016176: mokutil 0.6.0-2~deb10u1 flagged for acceptance
package release.debian.org tags 1016176 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: mokutil Version: 0.6.0-2~deb10u1 Explanation: new upstream version, to allow for SBAT management
Bug#1016169: debootstrap 1.0.114+deb10u1 flagged for acceptance
package release.debian.org tags 1016169 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: debootstrap Version: 1.0.114+deb10u1 Explanation: ensure non-merged-usr chroots can continue to be created for older releases and buildd chroots
Bug#1016184: unattended-upgrades: Unattended-upgrades has file lock after completion
Package: unattended-upgrades Version: 2.9.1 Severity: normal X-Debbugs-Cc: tmcconnell...@gmail.com Dear Maintainer, What led up to the situation? no idea I've been getting this for a awhile now. What exactly did you do (or not do) that was effective (or ineffective)? No idea. I configured it to run daily. What was the outcome of this action? Unattended-Upgrades runs successfully, but if I try to run `apt-get dist- upgrades' when packages are held back I get a message stating unattended upgrades has the file locked (I also get this with Gnome Software center). If I search `ps -ux' for that PID it isn't there. Sometimes I can run `sudo unattended-upgrade --debug --dry-run' and the lock is released other times I have to reboot the computer. It seems it's completed but hasn't let go of the lock. What outcome did you expect instead? To be able to upgrade held back packages. *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.79 ii lsb-base 11.2 ii lsb-release11.2 ii python33.10.5-3 ii python3-apt2.3.0+b2 ii python3-dbus 1.2.18-3+b2 ii python3-distro-info1.1 ii ucf3.0043 ii xz-utils 5.2.5-2.1 Versions of packages unattended-upgrades recommends: ii anacron 2.3-33 ii cron [cron-daemon] 3.0pl1-149 ii systemd-sysv251.2-7 Versions of packages unattended-upgrades suggests: ii bsd-mailx 8.1.2-0.20220412cvs-1 ii exim4-daemon-light [mail-transport-agent] 4.96-3 pn needrestart ii powermgmt-base 1.36 ii python3-gi 3.42.1-1+b1 -- debconf information: * unattended-upgrades/enable_auto_updates: true Enabled logging to syslog via daemon facility Starting unattended upgrades script Allowed origins are: origin=Debian,codename=bookworm-updates, origin=Debian,codename=bookworm-proposed-updates, origin=Debian,codename=bookworm,label=Debian, origin=Debian,codename=bookworm,label=Debian-Security, origin=Debian,codename=bookworm-security,label=Debian-Security Initial blacklist: Initial whitelist (not strict): Marking not allowed with -32768 pin Marking not allowed with -32768 pin Marking not allowed with -32768 pin Marking not allowed with -32768 pin Applying pinning: PkgFilePin(id=12, priority=-32768) Applying pin -32768 to package_file: Applying pinning: PkgFilePin(id=11, priority=-32768) Applying pin -32768 to package_file: Applying pinning: PkgFilePin(id=10, priority=-32768) Applying pin -32768 to package_file: Applying pinning: PkgFilePin(id=9, priority=-32768) Applying pin -32768 to package_file: Using (^linux-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^kfreebsd-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^gnumach-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-modules-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-kernel-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^linux-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^kfreebsd-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^gnumach-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-modules-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-kernel-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$) regexp to find kernel packages Using (^linux-.*-5\.18\.0\-2\-amd64$|^linux-.*-5\.18\.0\-2$|^kfreebsd-.*-5\.18\.0\-2\-amd64$|^kfreebsd-.*-5\.18\.0\-2$|^gnumach-.*-5\.18\.0\-2\-amd64$|^gnumach-.*-5\.18\.0\-2$|^.*-modules-5\.18\.0\-2\-amd64$|^.*-modules-5\.18\.0\-2$|^.*-kernel-5\.18\.0\-2\-amd64$|^.*-kernel-5\.18\.0\-2$|^linux-.*-5\.18\.0\-2\-amd64$|^linux-.*-5\.18\.0\-2$|^kfreebsd-.*-5\.18\.0\-2\-amd64$|^kfreebsd-.*-5\.18\.0\-2$|^gnumach-.*-5\.18\.0\-2\-amd64$|^gnumach-.*-5\.18\.0\-2$|^.*-modules-5\.18\.0\-2\-amd64$|^.*-modules-5\.18\.0\-2$|^.*-kernel-5\.18\.0\-2\-amd64$|^.*-kernel-5\.18\.0\-2$) regexp to find running kernel packages pkgs that look like they should be upgraded: Fetched 0 B in 0s (0 B/s) fetch.run() result: 0 Packages blacklist due to conffile prompts: [] No packages found that can be upgraded unattended and no pending auto-removals The list of kept packages can't be calculated in dry-run mode. APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "true"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Sandbox::seccomp ""; APT::Sandbox::seccomp::allow "";
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
Peter B, le jeu. 28 juil. 2022 18:24:40 +0100, a ecrit: > We have a solution with libc 2.33-9 and DUMA_DISABLE_BANNER Yes, but better have a more complete solution, so that other libraries like duma can work too. Samuel
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
@ Samuel, We have a solution with libc 2.33-9 and DUMA_DISABLE_BANNER if hurd users can live without the banner. I'm happy to do more tests, but probably have to wait till next week now. Cheers, Peter
Bug#1001669: closed by Debian FTP Masters
On Sun, 27 Mar 2022 19:24:05 +0200 =?UTF-8?Q?Aniol_Mart=c3=ad?= wrote: On Wed, 23 Mar 2022 09:09:00 +0100 Aniol Martí wrote:> I've tried several times and I can't reproduce the bug. I would need > further details or assistance. Besides, I also noticed that the last > test passed fine: > https://ci.debian.net/data/autopkgtest/unstable/amd64/o/openvpn-auth-ldap/20263239/log.gz I've added some verbosity to the test and I've tried in with Salsa and the problem seems to be the following: ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1) Although I've added "isolation-container" to the test restrictions it still fails. Maybe there have been some changes in the Docker configuration? Regards, Aniol Hello, I tested on Ubuntu the following patch http://launchpadlibrarian.net/615132752/openvpn-auth-ldap_2.0.4-2_2.0.4-2ubuntu1.diff.gz due to new easy-rsa requiring one single "vars" file in the directory, and now at least in Ubuntu autopkgtests are passing. G.
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
On 28/07/2022 16:53, Samuel Thibault wrote: Peter B, le jeu. 28 juil. 2022 16:22:23 +0100, a ecrit: #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 #1 0x01052ae4 in __pthread_enable_asynccancel () from /lib/i386-gnu/libpthread.so.0.3 Possibly it could be just that, could you try with the updated packages from https://people.debian.org/~sthibault/tmp/hurd-i386/ ? Samuel Sure This is what I got while our messages crossed Starting program: /home/demo/duma-2.5.21/dumatest Thread 4 received signal ?, Unknown signal. 0x0104d986 in __pthread_mutex_lock (mtxp=0x8) at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30 30 ../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory. #0 0x0104d986 in __pthread_mutex_lock (mtxp=0x8) at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30 #1 0x01052ae4 in __pthread_enable_asynccancel () at cancellation.c:28 #2 0x01198991 in __GI___libc_write (fd=2, buf=0x1038bec, nbytes=235) at ../sysdeps/mach/hurd/write.c:25 #3 0x0803d7ee in DUMA_Print ( pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington \nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 #4 0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) at duma.c:905 #5 0x0803aec9 in duma_init () at duma.c:943 #6 0x0803b2a2 in _duma_init () at duma.c:1138 #7 0x0803c386 in _duma_malloc (size=716, filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966 #8 0x0803cc8b in malloc (size=716) at duma.c:2424 #9 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124 #10 0x0104c773 in __pthread_create_internal (thread=0x1039d78, attr=0x1039d7c, start_routine=0x0, arg=0x0) at pt-create.c:120 #11 0x0105145b in _init_routine (stack=) at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66 #12 0x0001164b in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74 #13 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, l=) at dl-init.c:37 #14 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at dl-init.c:88 #15 0x2052 in _dl_start_user () from /lib/ld.so This is with the latest libc Starting program: /home/demo/duma-2.5.21/dumatest Thread 4 received signal ?, Unknown signal. __pthread_enable_asynccancel () at cancellation.c:30 30 cancellation.c: No such file or directory. #0 __pthread_enable_asynccancel () at cancellation.c:30 #1 0x01198991 in __GI___libc_write (fd=2, buf=0x1038bec, nbytes=235) at ../sysdeps/mach/hurd/write.c:25 #2 0x0803d7ee in DUMA_Print ( pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington \nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 #3 0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) at duma.c:905 #4 0x0803aec9 in duma_init () at duma.c:943 #5 0x0803b2a2 in _duma_init () at duma.c:1138 #6 0x0803c386 in _duma_malloc (size=716, filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966 #7 0x0803cc8b in malloc (size=716) at duma.c:2424 #8 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124 #9 0x0104c773 in __pthread_create_internal (thread=0x1039d78, attr=0x1039d7c, start_routine=0x0, arg=0x0) at pt-create.c:120 #10 0x0105145b in _init_routine (stack=) at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66 #11 0x0001164b in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74 #12 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, l=) at dl-init.c:37 #13 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at dl-init.c:88 #14 0x2052 in _dl_start_user () from /lib/ld.so Starting program: /home/demo/duma-2.5.21/dumatest Thread 4 received signal ?, Unknown signal. 0x0104d986 in __pthread_mutex_lock (mtxp=0x8) at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30 30 ../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory. #0 0x0104d986 in __pthread_mutex_lock (mtxp=0x8) at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30 #1 0x01052ae4 in __pthread_enable_asynccancel () at cancellation.c:28 #2 0x01198991 in __GI___libc_write (fd=2, buf=0x1038bec, nbytes=235) at ../sysdeps/mach/hurd/write.c:25 #3 0x0803d7ee in DUMA_Print ( pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington \nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 #4 0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) at duma.c:905 #5 0x0803aec9 in duma_init () at duma.c:943 #6 0x0803b2a2 in _duma_init () at duma.c:1138 #7 0x0803c386 in _duma_malloc (size=716, filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", lineno=0) at
Bug#1016169: buster-pu: package debootstrap/1.0.114+deb10u1
Control: tags -1 + confirmed On Thu, 2022-07-28 at 12:56 +0100, Luca Boccassi wrote: > While preparing for the usrmerge transition as per [0], we have done > some work on debootstrap [1] to ensure that, as per CTTE decision, > buildd machines (and CI machines) can remain unmerged-usr. > The new version of debootstrap with these changes is in unstable, > testing and stable-backports. > [...] > A selected backport of the changes for stable-proposed-updates and > oldstable-proposed-updates seems like a safe approach that removes > the > buildd team/DSA from the critical path, and the buildd team/DSA would > prefer to go down that route. > Please go ahead. Regards, Adam
Bug#1016168: bullseye-pu: package debootstrap/1.0.123+deb11u1
Control: tags -1 + confirmed On Thu, 2022-07-28 at 12:53 +0100, Luca Boccassi wrote: > While preparing for the usrmerge transition as per [0], we have done > some work on debootstrap [1] to ensure that, as per CTTE decision, > buildd machines (and CI machines) can remain unmerged-usr. > The new version of debootstrap with these changes is in unstable, > testing and stable-backports. > [...] > A selected backport of the changes for stable-proposed-updates and > oldstable-proposed-updates seems like a safe approach that removes > the > buildd team/DSA from the critical path, and the buildd team/DSA would > prefer to go down that route. > Please go ahead. Regards, Adam
Bug#1016183: RFH: crun -- lightweight OCI runtime for running containers
Package: wnpp The crun maintainer has requested help in #1014306. On Mon, 25 Jul 2022 17:54:53 +1000 Dmitry Smirnov wrote: On Friday, 22 July 2022 11:43:56 PM AEST Faidon Liambotis wrote: > Dmitry, are you still working on this package? I noticed that it's under > the debian group in Salsa -- would you be OK if someone else made an > upload? I'm not ready to abandon the package yet but can't spare any time for it at the moment, unfortunately... Of course it would be awesome if anyone could help, provided they preserve the current repository layout. > @Faidon, I suppose it would be fine to NMU and put it into DELAYED/10 > atleast till we have time for an ACK. This is triggering a bunch of > auto-rm and hence it is prudent. > Do consider doing so if you agree. Nilesh, of course NMU is OK but it would be nice if changes could be committed to repository... Note that Reinhard already uploaded 0.17+dfsg-1.1 which is committed to branch "bug.997225" which is due to be merged into "master" branch. Thank you all for your help.
Bug#1014907: buster-pu: package rustc-mozilla/1.59.0+dfsg1-1~deb10u1
On 14/07/2022 11:02, Emilio Pozuelo Monfort wrote:
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This updates rustc-mozilla in buster, in preparation for Firefox 102.
I'm attaching the debdiff from the bullseye update. The windows target
is disabled because it was already disabled in buster, and is something
we don't really care about for our purpose.
I've uploaded the package already to oldstable-new.
I've added a couple of changes to fix the FTBFS on i386 and arm64. debdiff
attached and package uploaded.
Thanks,
Emiliodiff -ruNp debian/changelog rustc-mozilla-1.59.0+dfsg1/debian/changelog
--- debian/changelog2022-07-12 00:18:55.0 +0200
+++ rustc-mozilla-1.59.0+dfsg1/debian/changelog 2022-07-28 18:17:01.281355462
+0200
@@ -1,3 +1,10 @@
+rustc-mozilla (1.59.0+dfsg1-1~deb10u2) buster; urgency=medium
+
+ * Inline atomics on arm64.
+ * Increase allowed test failures on i386.
+
+ -- Emilio Pozuelo Monfort Thu, 28 Jul 2022 18:16:59 +0200
+
rustc-mozilla (1.59.0+dfsg1-1~deb10u1) buster; urgency=medium
* Backport to buster.
diff -ruNp debian/patches/d-aarch64-inline-atomics.patch
rustc-mozilla-1.59.0+dfsg1/debian/patches/d-aarch64-inline-atomics.patch
--- debian/patches/d-aarch64-inline-atomics.patch 1970-01-01
01:00:00.0 +0100
+++ rustc-mozilla-1.59.0+dfsg1/debian/patches/d-aarch64-inline-atomics.patch
2022-07-28 13:39:58.740551614 +0200
@@ -0,0 +1,40 @@
+--- a/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu.rs
b/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu.rs
+@@ -8,7 +8,6 @@ pub fn target() -> Target {
+ data_layout:
"E-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128".to_string(),
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+-features: "+outline-atomics".to_string(),
+ max_atomic_width: Some(128),
+ mcount: "\u{1}_mcount".to_string(),
+ endian: Endian::Big,
+--- a/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu_ilp32.rs
b/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu_ilp32.rs
+@@ -12,7 +12,6 @@ pub fn target() -> Target {
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+ abi: "ilp32".to_string(),
+-features: "+outline-atomics".to_string(),
+ mcount: "\u{1}_mcount".to_string(),
+ endian: Endian::Big,
+ ..base
+--- a/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu.rs
b/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu.rs
+@@ -7,7 +7,6 @@ pub fn target() -> Target {
+ data_layout:
"e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128".to_string(),
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+-features: "+outline-atomics".to_string(),
+ mcount: "\u{1}_mcount".to_string(),
+ max_atomic_width: Some(128),
+ supported_sanitizers: SanitizerSet::ADDRESS
+--- a/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu_ilp32.rs
b/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu_ilp32.rs
+@@ -8,7 +8,6 @@ pub fn target() -> Target {
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+ abi: "ilp32".to_string(),
+-features: "+outline-atomics".to_string(),
+ max_atomic_width: Some(128),
+ mcount: "\u{1}_mcount".to_string(),
+ ..super::linux_gnu_base::opts()
diff -ruNp debian/patches/series
rustc-mozilla-1.59.0+dfsg1/debian/patches/series
--- debian/patches/series 2022-03-29 15:18:33.0 +0200
+++ rustc-mozilla-1.59.0+dfsg1/debian/patches/series2022-07-28
13:38:45.892372838 +0200
@@ -52,3 +52,4 @@ d-rustc-i686-baseline.patch
# Experimental patch not yet working
#d-rustc-prefer-dynamic.patch
d-rustdoc-disable-embedded-fonts.patch
+d-aarch64-inline-atomics.patch
diff -ruNp debian/rules rustc-mozilla-1.59.0+dfsg1/debian/rules
--- debian/rules2022-07-12 00:18:55.0 +0200
+++ rustc-mozilla-1.59.0+dfsg1/debian/rules 2022-07-28 18:16:54.829342634
+0200
@@ -51,6 +51,14 @@ RUSTBUILD_TEST = $(RUSTBUILD) test --no-
# See src/bootstrap/README.md for more options.
RUSTBUILD_TEST_FLAGS =
+ifneq (,$(filter buster%, $(DEB_DISTRIBUTION)))
+ifeq ($(DEB_HOST_ARCH), arm64)
+# https://github.com/rust-lang/rust/issues/93166
+RUSTFLAGS = -Ctarget-feature=-outline-atomics
+export RUSTFLAGS
+endif
+endif
+
# https://github.com/rust-lang/rust/issues/89744
# TODO: remove when we update cargo to 1.55 / 0.56
# upstream bug still exists and is under investigation, but is hidden by newer
cargo
@@ -285,7 +293,7 @@ TEST_LOG = debian/rustc-tests.log
# This is advertised as "5 tests failed" in README.Debian because our counting
# method is imprecise and in practise we count some failures twice.
Bug#1016182: roundcube-pgsql: bad parsing of connection parameters to posgres database
Package: roundcube-pgsql
Version: 1.4.13+dfsg.1-1~deb11u1
Severity: normal
Dear Maintainer,
Context :
Two instances of poestgresql, one is listening on socket 5432
(/var/run/postgresql/.s.PGSQL.5432),
one is listening on socket 5433
roundcube database is on the 5433 instance
connection string is defined in /etc/roundcube/debian-db.php
with
$dbserver=urlencode('/var/run/postgresql');
# or else $dbserver='%2Fvar%2Frun%2Fpostgresql';
$dbport='5433';
connection is ok
with
$dbserver='unix(/var/run/postgresql:5433)';
$dbport='';
connection is ok
but with
$dbserver='unix(/var/run/postgresql)';
$dbport='5433';
log analysis shows that roundcube tries to connect thru socket 5432 to the
database ":5433/roundcube"
which is not what I expected...
-- System Information:
Debian Release: 11.3
APT prefers stable-security
APT policy: (990, 'stable-security'), (900, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages roundcube-pgsql depends on:
pn php-pgsql
ii postgresql-client 13+225
ii postgresql-client-13 [postgresql-client] 13.7-0+deb11u1
roundcube-pgsql recommends no packages.
Versions of packages roundcube-pgsql suggests:
pn postgresql
Bug#1012999: keep the issue open until the package can be built in a follow-up test rebuild.
Hello, Where to find information about the rebuild schedule? The some what template text |[This bug is targeted to the upcoming bookworm release] | |Please keep this issue open in the bug tracker for the package it |was filed for. If a fix in another package is required, please |file a bug for the other package (or clone), and add a block in this |package. Please keep the issue open until the package can be built in |a follow-up test rebuild. | |The package fails to build in a test rebuild on at least amd64 with |gcc-12/g++-12, but succeeds to build with gcc-11/g++-11. The |severity of this report will be raised before the bookworm release. does not provide any information about it. Groeten Geert Stappers P.S. Please keep 1012...@bugs.debian.org in the loop. -- Silence is hard to parse
Bug#1012999: Uploaded
FWIW Uploads did happen ( https://tracker.debian.org/news/1349600/accepted-msc-generator-81-1-source-into-unstable/ and https://tracker.debian.org/news/1349742/accepted-msc-generator-81-2-source-into-unstable/ ). At https://buildd.debian.org/status/package.php?p=msc-generator is currently: | Buildd exposure stats all 8.1-2 Installed 1h 5m x86-grnet-02 miscold | all (1) giveback | Buildd exposure stats amd64 8.1-2 Installed 1h 6m x86-ubc-01 miscold | all (1) giveback | Buildd exposure stats arm64 8.1-2 Installed 51m arm-arm-03 miscold | all (1) giveback | Buildd exposure stats armel 8.1-2 Installed 51m arm-ubc-06 miscold | all (1) giveback | Buildd exposure stats armhf 8.1-2 Installed 8m arm-arm-04 miscold | all (2) giveback | Buildd exposure stats i3868.1-2 Installed 1h 6m x86-grnet-01 miscold | all (1) giveback | Buildd exposure stats mips64el8.1-2 Installed 51m mipsel-osuosl-03miscold | all (1) giveback | Buildd exposure stats mipsel 8.1-2 Installed 28m mipsel-manda-04 miscold | all (1) giveback | Buildd exposure stats ppc64el 8.1-2 Installed 1h 6m ppc64el-osuosl-01 miscold | all (1) giveback | Buildd exposure stats s390x 8.1-2 Installed 1h 5m zani misc old | all (1) giveback In other words: Succesfull builds on all release architectures. Groeten Geert Stappers -- Silence is hard to parse
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
Peter B, le jeu. 28 juil. 2022 16:22:23 +0100, a ecrit: > #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 > #1 0x01052ae4 in __pthread_enable_asynccancel () > from /lib/i386-gnu/libpthread.so.0.3 Possibly it could be just that, could you try with the updated packages from https://people.debian.org/~sthibault/tmp/hurd-i386/ ? Samuel
Bug#1016181: ITP: gap-edim -- GAP EDIM - Elementary Divisors of Integer Matrices
Package: wnpp Severity: wishlist Owner: Joachim Zobel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gap-edim Version : 1.3.5 Upstream Author : Frank Lübeck * URL : https://github.com/frankluebeck/EDIM * License : GPL-2+ Programming Lang: GAP 4 Description : GAP EDIM - Elementary Divisors of Integer Matrices This package provides a collection of functions for computing the Smith normal form of integer matrices and some related utilities. I am packaging this because it is suggested by gap-hap where it enables some optional functionality.
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
Peter B, le jeu. 28 juil. 2022 16:22:23 +0100, a ecrit: > On 28/07/2022 16:00, Samuel Thibault wrote: > > Peter B, le jeu. 28 juil. 2022 15:56:27 +0100, a ecrit: > > > Tried your libc and also no difference. > > The backtrace is exactly the same? I don't see how that can be, since my > > patch makes __pthread_self return immediately when ___pthread_self is > > NULL, and at > > > > #21 0x0105146b in _init_routine (stack=) at > > ../sysdeps/mach/hurd/htl/pt-sysdep.c:66 > > > > has not yet be set to non-NULL. > > > > Samuel > > Hi Samuel, > > Sorry, I just meant that the test program still fails. That doesn't mean we didn't make progress. When several bugs have the same end-user symptom, having just one kind of symptom doesn't mean there is just one bug to fix, and getting the symptom doesn't mean one hasn't progressed in fixing them. > Here is the new (different) backtrace. Could you install libc0.3-dbg as well so we get more details? > Starting program: /home/demo/duma-2.5.21/dumatest > > Thread 4 received signal ?, Unknown signal. > 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 > #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 > #1 0x01052ae4 in __pthread_enable_asynccancel () > from /lib/i386-gnu/libpthread.so.0.3 > #2 0x01198991 in write () from /lib/i386-gnu/libc.so.0.3 > #3 0x0803d802 in DUMA_Print ( > pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static > library)\nCopyright (C) 2006 Michael Eddington > \nCopyright (C) 2002-2009 Hayati Ayguen > , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 > #4 0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) > at duma.c:905 > #5 0x0803aedd in duma_init () at duma.c:943 > #6 0x0803b2b6 in _duma_init () at duma.c:1138 > #7 0x0803c39a in _duma_malloc (size=716, > filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", > lineno=0) at duma.c:1966 > #8 0x0803cc9f in malloc (size=716) at duma.c:2424 > #9 0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3 > #10 0x0104c773 in __pthread_create_internal () > from /lib/i386-gnu/libpthread.so.0.3 > #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3 > #12 0x0001164b in ?? () from /lib/ld.so > #13 0x000117f5 in ?? () from /lib/ld.so > #14 0x2052 in ?? () from /lib/ld.so > #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 > #1 0x01052ae4 in __pthread_enable_asynccancel () > from /lib/i386-gnu/libpthread.so.0.3 > #2 0x01198991 in write () from /lib/i386-gnu/libc.so.0.3 > #3 0x0803d802 in DUMA_Print ( > pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static > library)\nCopyright (C) 2006 Michael Eddington > \nCopyright (C) 2002-2009 Hayati Ayguen > , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 > #4 0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) > at duma.c:905 > #5 0x0803aedd in duma_init () at duma.c:943 > #6 0x0803b2b6 in _duma_init () at duma.c:1138 > #7 0x0803c39a in _duma_malloc (size=716, > filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", > lineno=0) at duma.c:1966 > #8 0x0803cc9f in malloc (size=716) at duma.c:2424 > #9 0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3 > #10 0x0104c773 in __pthread_create_internal () > from /lib/i386-gnu/libpthread.so.0.3 > #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3 > #12 0x0001164b in ?? () from /lib/ld.so > #13 0x000117f5 in ?? () from /lib/ld.so > #14 0x2052 in ?? () from /lib/ld.so > > > Cheers, > Peter > > Starting program: /home/demo/duma-2.5.21/dumatest > > Thread 4 received signal ?, Unknown signal. > 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 > #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 > #1 0x01052ae4 in __pthread_enable_asynccancel () >from /lib/i386-gnu/libpthread.so.0.3 > #2 0x01198991 in write () from /lib/i386-gnu/libc.so.0.3 > #3 0x0803d802 in DUMA_Print ( > pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static > library)\nCopyright (C) 2006 Michael Eddington > \nCopyright (C) 2002-2009 Hayati Ayguen > , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 > #4 0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) > at duma.c:905 > #5 0x0803aedd in duma_init () at duma.c:943 > #6 0x0803b2b6 in _duma_init () at duma.c:1138 > #7 0x0803c39a in _duma_malloc (size=716, > filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", > lineno=0) at duma.c:1966 > #8 0x0803cc9f in malloc (size=716) at duma.c:2424 > #9 0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3 > #10 0x0104c773 in __pthread_create_internal () >from /lib/i386-gnu/libpthread.so.0.3 > #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3 > #12 0x0001164b in ?? () from /lib/ld.so > #13 0x000117f5 in ?? () from
Bug#1016180: transition: gnome-desktop 43
Package: release.debian.org Tags: moreinfo User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: gnome-desk...@packages.debain.org Severity: normal Control: block -1 by 1016175 Control: block -1 by 1016171 I am filing this transition bug early. We need to fix the 2 blocker bugs. gnome-books is set to be autoremoved from Testing next week due to FTBFS and other issues. nautilus will get a sourceful upload since the simple backported patch only supports the new gnome-desktop version. Thank you, Jeremy Bicha
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
On 28/07/2022 16:00, Samuel Thibault wrote: Peter B, le jeu. 28 juil. 2022 15:56:27 +0100, a ecrit: Tried your libc and also no difference. The backtrace is exactly the same? I don't see how that can be, since my patch makes __pthread_self return immediately when ___pthread_self is NULL, and at #21 0x0105146b in _init_routine (stack=) at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66 has not yet be set to non-NULL. Samuel Hi Samuel, Sorry, I just meant that the test program still fails. Here is the new (different) backtrace. Starting program: /home/demo/duma-2.5.21/dumatest Thread 4 received signal ?, Unknown signal. 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 #1 0x01052ae4 in __pthread_enable_asynccancel () from /lib/i386-gnu/libpthread.so.0.3 #2 0x01198991 in write () from /lib/i386-gnu/libc.so.0.3 #3 0x0803d802 in DUMA_Print ( pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington \nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 #4 0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) at duma.c:905 #5 0x0803aedd in duma_init () at duma.c:943 #6 0x0803b2b6 in _duma_init () at duma.c:1138 #7 0x0803c39a in _duma_malloc (size=716, filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966 #8 0x0803cc9f in malloc (size=716) at duma.c:2424 #9 0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3 #10 0x0104c773 in __pthread_create_internal () from /lib/i386-gnu/libpthread.so.0.3 #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3 #12 0x0001164b in ?? () from /lib/ld.so #13 0x000117f5 in ?? () from /lib/ld.so #14 0x2052 in ?? () from /lib/ld.so #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 #1 0x01052ae4 in __pthread_enable_asynccancel () from /lib/i386-gnu/libpthread.so.0.3 #2 0x01198991 in write () from /lib/i386-gnu/libc.so.0.3 #3 0x0803d802 in DUMA_Print ( pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington \nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 #4 0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) at duma.c:905 #5 0x0803aedd in duma_init () at duma.c:943 #6 0x0803b2b6 in _duma_init () at duma.c:1138 #7 0x0803c39a in _duma_malloc (size=716, filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966 #8 0x0803cc9f in malloc (size=716) at duma.c:2424 #9 0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3 #10 0x0104c773 in __pthread_create_internal () from /lib/i386-gnu/libpthread.so.0.3 #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3 #12 0x0001164b in ?? () from /lib/ld.so #13 0x000117f5 in ?? () from /lib/ld.so #14 0x2052 in ?? () from /lib/ld.so Cheers, Peter Starting program: /home/demo/duma-2.5.21/dumatest Thread 4 received signal ?, Unknown signal. 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 #1 0x01052ae4 in __pthread_enable_asynccancel () from /lib/i386-gnu/libpthread.so.0.3 #2 0x01198991 in write () from /lib/i386-gnu/libc.so.0.3 #3 0x0803d802 in DUMA_Print ( pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington \nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 #4 0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>) at duma.c:905 #5 0x0803aedd in duma_init () at duma.c:943 #6 0x0803b2b6 in _duma_init () at duma.c:1138 #7 0x0803c39a in _duma_malloc (size=716, filename=0x803e060 "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966 #8 0x0803cc9f in malloc (size=716) at duma.c:2424 #9 0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3 #10 0x0104c773 in __pthread_create_internal () from /lib/i386-gnu/libpthread.so.0.3 #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3 #12 0x0001164b in ?? () from /lib/ld.so #13 0x000117f5 in ?? () from /lib/ld.so #14 0x2052 in ?? () from /lib/ld.so #0 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3 #1 0x01052ae4 in __pthread_enable_asynccancel () from /lib/i386-gnu/libpthread.so.0.3 #2 0x01198991 in write () from /lib/i386-gnu/libc.so.0.3 #3 0x0803d802 in DUMA_Print ( pattern=0x803df60 "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington \nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331 #4 0x0803ae86 in duma_getenvvars (duma_tls=0x8047168
Bug#1016179: bullseye-pu: package shim/15.6-1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of shim, built for bullseye. This is needed for better handling of SBAT-based revocations, plus a range of security updates from upstream. See attached debdiff for the changes. They're not minimal, but in the case of shim we need to be as close to upstream as possible for the sake of getting stuff reviewed and signed. The only local patches now are to revert arm64 build changes so we can still build on bullseye. I've tested locally on various machines and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled shim_15.6-1~deb11u1.debdiff.gz Description: application/gzip
Bug#1016178: buster-pu: package shim/15.6-1~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of shim, built for buster. This is needed for better handling of SBAT-based revocations, plus a range of security updates from upstream. See attached debdiff for the changes. They're not minimal, but in the case of shim we need to be as close to upstream as possible for the sake of getting stuff reviewed and signed. The only local patches now are to revert arm64 build changes so we can still build on buster. I've tested locally on various machines and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled shim_15.6-1~deb10u1.debdiff.gz Description: application/gzip
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
Peter B, le jeu. 28 juil. 2022 15:56:27 +0100, a ecrit: > Tried your libc and also no difference. The backtrace is exactly the same? I don't see how that can be, since my patch makes __pthread_self return immediately when ___pthread_self is NULL, and at #21 0x0105146b in _init_routine (stack=) at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66 has not yet be set to non-NULL. Samuel
Bug#1014522: pipewire: Regressions in 0.3.53-1
OK I've been testing 0.3.56-1 and the ffmpeg encoding problem is fixed too, so you can close this bug.
Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
On 28/07/2022 00:02, Samuel Thibault wrote: Could you try with the libc from https://people.debian.org/~sthibault/tmp/hurd-i386/ Samuel Hi Samuel, Having some issues with file corruption in my VM, so not sure the results are consistent. I tried Jeffrey's suggestions of DUMA_DISABLE_BANNER and DUMA_OUTPUT_FILE and it made no difference. Tried your libc and also no difference. Reinstalled duma after hosing its folder somehow, GNUmakefile was overwritten with binary junk. Tests now pass if DUMA_DISABLE_BANNER is defined. I don't know how to downgrade libc to confirm whether DUMA_DISABLE_BANNER is sufficient, or whether the libc upgrade is also needed. On its own, it (libc) does not seem to fix the problem. Cheers, Peter
Bug#1016176: Acknowledgement (buster-pu: package mokutil/0.3.0+1538710437.fb6250f-1)
Control: retitle -1 buster-pu: package mokutil/0.6.0-2~deb10u1 Gah, forgot to set the version when using reportbug :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Bug#1016177: bullseye-pu: package mokutil/0.6.0-2~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of mokutil, built for bullseye. We need this new version to add support for managing SBAT, the new way to revoke things with UEFI Secure Boot. This is necessary to match up with the new shim 15.6 release. See attached debdiff for the changes. They're not *strictly* minimal, but I'm not confident about splitting out the changes individually here. It's a small, self-contained utility. I've tested locally on a bullseye machine and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled mokutil_0.6.0-2~deb11u1.debdiff.gz Description: application/gzip
Bug#1016033: wireshark: process does not quit
Control: tags -1 moreinfo unreproducible
Hi Erwan,
I tried reproducing the problem in the default Gnome session on
Testing using a randomly created captrure file, but wireshark exited
normally.
Could you please add more steps if it is reproducible for you?
Cheers,
Balint
On Mon, 25 Jul 2022 16:51:50 +0200 Erwan David wrote:
> Package: wireshark
> Version: 3.6.6-1
> Severity: normal
>
> Starting wireshark with wireshark -r req.pcap
>
> At end of use, click on "quit" in the File menu.
> Window disappears, but process still here, blocked in a futex until I ^C in
> the launching terminal
>
> % strace -p 29844
> strace: Process 29844 attached
> futex(0x7ffc5be8ec30, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
> +++ killed by SIGINT +++
>
>
>
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers testing
> APT policy: (900, 'testing'), (800, 'stable-security'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages wireshark depends on:
> ii wireshark-qt 3.6.6-1
>
> wireshark recommends no packages.
>
> wireshark suggests no packages.
>
> -- no debconf information
>
>
Bug#1016176: buster-pu: package mokutil/0.3.0+1538710437.fb6250f-1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of mokutil, built for buster. We need this new version to add support for managing SBAT, the new way to revoke things with UEFI Secure Boot. This is necessary to match up with the new shim 15.6 release. See attached debdiff for the changes. They're not *strictly* minimal, but I'm not confident about splitting out the changes individually here. It's a small, self-contained utility. I've tested locally on a buster machine and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled mokutil_0.6.0-2~deb10u1.debdiff.gz Description: application/gzip
Bug#1014674: FTBFS with fmtlib 9.0.0
On Thu, Jul 28, 2022 at 7:55 PM Andrea Pappacoda wrote: > > On Thu, 28 Jul 2022 04:04:58 +0800 Shengjing Zhu > wrote: > > New version released, which addresses build failure with fmt-9.0.0. > > Please package the new version. > > I don't know why the salsa webhook didn't send a message here, but this > is going to get fixed soon. I've uploaded the new release to mentors: > https://mentors.debian.net/package/dynarmic/ Thanks, uploaded. -- Shengjing Zhu
Bug#1016175: budgie-control-center: Fails to build with gnome-desktop 43
Source: budgie-control-center Severity: important Version: 1.0.2-2 Forwarded: https://github.com/BuddiesOfBudgie/budgie-control-center/issues/31 budgie-control-center fails to build with gnome-desktop 43 which is available in Debian Experimental. I included more details on the upstream bug. Thank you, Jeremy Bicha
Bug#1016174: ifupdown: mapping wildcards does not work as interfaces(5) claims it should
Package: ifupdown Version: 0.8.37 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 interfaces(5) states: * Note that there must still be valid "iface" stanzas for each matching interface. However, it is possible to combine a pattern with a mapping to a logical interface, like so: auto /eth*=eth iface eth inet dhcp * The attached /etc/network/interfaces follows a similar syntax and yet fails. Martin-Éric - -- Package-specific info: - --- /etc/network/interfaces: allow-hotplug enp0s13 /wl*=wifiusb iface enp0s13 inet dhcp iface enp0s13 inet6 auto privext 2 iface wifiusb inet dhcp wpa-ssid wpa-psk iface wifiusb inet6 auto privext 2 - --- up and down scripts installed: /etc/network/if-down.d: total 0 lrwxrwxrwx 1 root root 32 May 15 13:42 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-post-down.d: total 4 - -rwxr-xr-x 1 root root 1409 Mar 24 2016 wireless-tools lrwxrwxrwx 1 root root 32 May 15 13:42 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-pre-up.d: total 12 - -rwxr-xr-x 1 root root 344 Jan 19 2022 ethtool - -rwxr-xr-x 1 root root 4191 Sep 15 2018 wireless-tools lrwxrwxrwx 1 root root 32 May 15 13:42 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-up.d: total 12 - -rwxr-xr-x 1 root root 1685 Jan 19 2022 ethtool - -rwxr-xr-x 1 root root 4938 Aug 14 2020 mountnfs lrwxrwxrwx 1 root root 32 May 15 13:42 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh - -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: i386 (i586) Kernel: Linux 5.18.0-2-686 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ifupdown depends on: ii adduser 3.123 ii iproute2 5.18.0-1 ii libc6 2.33-8 ii lsb-base 11.2 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.3-2 Versions of packages ifupdown suggests: ii ppp 2.4.9-1+1.1+b1 pn rdnssd - -- debconf information: ifupdown/convert-interfaces: true ifupdown/convert-interfaces-hotplug: true -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmLinpAACgkQrh+Cd8S0 17au8w//UTiMkMc8kCGn7Y2m389DDfMz5qX87HP8HvJsaMiZbnb14fHGojNkZWWF x0CmT/xkNpI1I7dSQwPBM6VZP/v1bwxV5dDm6gGm7sBbgWMagIj2tNQQpIdOReuk UmyhV2ga/0R4tQxrYIgtZzwa+sN1SPytS8wS/zhVEU7zT9tKZDzq7oNCZKtQWw/U kqWfZfw2ToHi6pYDYMu3VUjHs078y2WZe6WWhXIlJLxYFEejZNgCtRgRI8o4BbDQ gHVcEGRPABK5NDsmtAngWEdeCIJmCp4jE+WkRofO7FdZUsGLx3Wa105DY+19UP/2 AT5KhswlNPSwu+AiPdf5Hhvl4Bll9lFMQz5Hijy2c2dshSYtGVRpukfiOyEjsewJ lovx9ztNaJwYbbUjGMubU6GHoOz7T9Vm3t3HyV26eQiiCozOY58nQ7lNekbWgs1v l/DHlarnkGZNQl7x2VKUdussi+D1RCPJ2qoxYH+XBFgv5o7Zjfb/vCdTnKPLmk6j 3MyiGq7KFj04EKiwMfTIXR0AjlSTtE+9m6H585Ov5RrLyDQlPQkJDPtLJ0NZkXlk g8pxrW2cLsKa/IUNCjUv+1GdG+lf3fuqs3tPk2C7hzMVd6yng9IGDamgx1qnu2CF ni8P+nIah1GrXLwftYHVFL6of6Q+1d0nPLzexp+vMD5MsWPvYKk= =12zr -END PGP SIGNATURE-
Bug#1014338: openlibm: ftbfs on riscv64('No rule to make target 'riscv64/Make.files')
Source: openlibm Version: 0.8.1+dfsg-2 Followup-For: Bug #1014338 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear openlibm Maintainer, The 0.8.1 has support riscv64 arch but it still has btfs issue due to missing symbols info , the full buildd log is here: https://buildd.debian.org/status/fetch.php?pkg=openlibm=riscv64=0.8.1%2Bdfsg-2=1658831599=0 The issue can be fixed by the symbols file attached and there are any issues please let me know, thanks. -- Regards, -- Bo YU # SymbolsHelper-Confirmed: 0.8.1 mipsel riscv64 libopenlibm.so.4 libopenlibm4 #MINVER# * Build-Depends-Package: libopenlibm-dev #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_aT@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_atanhi@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_atanlo@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pS0@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pS1@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pS2@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pS3@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pS4@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pS5@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pS6@Base 0.4 (arch=arm64)_ItL_pS7@Base 0.6.0 (arch=arm64)_ItL_pS8@Base 0.6.0 (arch=arm64)_ItL_pS9@Base 0.6.0 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_pi_lo@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_qS1@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_qS2@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_qS3@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_qS4@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)_ItL_qS5@Base 0.4 (arch=arm64)_ItL_qS6@Base 0.6.0 (arch=arm64)_ItL_qS7@Base 0.6.0 (arch=arm64)_ItL_qS8@Base 0.6.0 (arch=arm64)_ItL_qS9@Base 0.6.0 __exp__D@Base 0.4 __fe_dfl_env@Base 0.4 __fpclassifyd@Base 0.4 __fpclassifyf@Base 0.4 (arch=!armhf)__fpclassifyl@Base 0.4 (arch=i386 kfreebsd-i386 hurd-i386)__has_sse@Base 0.4 __ieee754_rem_pio2@Base 0.4 __ieee754_rem_pio2f@Base 0.4 __isfinite@Base 0.4 __isfinitef@Base 0.4 (arch=!armhf)__isfinitel@Base 0.4 __isinff@Base 0.4 (arch=!armhf)__isinfl@Base 0.4 __isnanf@Base 0.4 (arch=!armhf)__isnanl@Base 0.4 __isnormal@Base 0.4 __isnormalf@Base 0.4 (arch=!armhf)__isnormall@Base 0.4 __kernel_cos@Base 0.4 __kernel_cosdf@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)__kernel_cosl@Base 0.4 __kernel_rem_pio2@Base 0.4 __kernel_sin@Base 0.4 __kernel_sindf@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)__kernel_sinl@Base 0.4 __kernel_tan@Base 0.4 __kernel_tandf@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)__kernel_tanl@Base 0.4 __ldexp_cexp@Base 0.4 __ldexp_cexpf@Base 0.4 __ldexp_exp@Base 0.4 __ldexp_expf@Base 0.4 __log__D@Base 0.4 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)__p1evll@Base 0.5.0 #MISSING: 0.8.1# (arch=!armhf !powerpc !ppc64el !ppc64 !mips !mipsel !mips64el !s390x)__polevll@Base 0.5.0 __scan_nan@Base 0.5.0 __signbit@Base 0.4 __signbitf@Base 0.4 (arch=!armhf)__signbitl@Base 0.4 (arch=i386 kfreebsd-i386 hurd-i386)__test_sse@Base 0.4 acos@Base 0.4 acosf@Base 0.4 acosh@Base 0.4 acoshf@Base 0.4 (arch=!armhf !mips !mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)acoshl@Base 0.8.1 (arch=!mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)acosl@Base 0.4 asin@Base 0.4 asinf@Base 0.4 asinh@Base 0.4 asinhf@Base 0.4 (arch=!armhf !mips !mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)asinhl@Base 0.8.1 (arch=!mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)asinl@Base 0.4 atan2@Base 0.4 atan2f@Base 0.4 (arch=!mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)atan2l@Base 0.4 atan@Base 0.4 atanf@Base 0.4 atanh@Base 0.4 atanhf@Base 0.4 (arch=!armhf !mips !mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)atanhl@Base 0.8.1 (arch=!mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)atanl@Base 0.4 cabs@Base 0.4 cabsf@Base 0.4 (arch=!mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)cabsl@Base 0.4 cacos@Base 0.5.0 cacosf@Base 0.5.0 cacosh@Base 0.5.0 cacoshf@Base 0.5.0 (arch=!armhf
Bug#1016173: numad: Are the dependencies on systemd-sysv | cgmanager correct?
Source: numad Version: 0.5+20150602-7 Severity: normal Hello, I have just noticed that numad depends on systemd-sysv | cgmanager. However, I have find no use of cgroups in the source. It appears to have been that wasy since the initial upload. This dependency particularly matters now, since cgmanager is no longer available in Debian buster or later. This prevents numad being installed on any non-systemd init installation. My tests indicate that the daemon starts and operates without cgmanager or systemd init. Can you review if this dependency is really required and remove it if not? Thanks Mark -- System Information: Debian Release: bookworm/sid Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1016172: RFP: snapdrop -- local file sharing webapp
Package: wnpp Severity: wishlist X-Debbugs-Cc: j...@nahmias.net, pkg-javascript-de...@lists.alioth.debian.org * Package name: snapdrop Version : 0 Upstream Author : Robin Linus * URL : https://github.com/RobinLinus/snapdrop * License : GPL3 Programming Lang: Javascript Description : local file sharing webapp Snapdrop enables peer-to-peer filesharing using the users' browser.
Bug#1015062: node-shiny-server: FTBFS: ModuleNotFoundError: No module named 'six'
Le jeu. 28 juil. 2022 à 15:48, Andreas Tille a écrit : > Control: tags -1 moreinfo > Control: tags -1 unreproducible > Control: severity -1 important > > Hi Lucas, > > I can't reproduce the issue at my side. It somehow smells like an > issue of some Build-Depends which might have been solved meanwhile. > Oh, yes, totally ! It was a bug in gyp. I merged the bugs, but forgot that one. Jérémy
Bug#1015062: node-shiny-server: FTBFS: ModuleNotFoundError: No module named 'six'
Control: tags -1 moreinfo
Control: tags -1 unreproducible
Control: severity -1 important
Hi Lucas,
I can't reproduce the issue at my side. It somehow smells like an
issue of some Build-Depends which might have been solved meanwhile.
Kind regards
Andreas.
Am Sat, Jul 16, 2022 at 03:31:35PM +0200 schrieb Lucas Nussbaum:
> Source: node-shiny-server
> Version: 1.5.17.973-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220716 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[4]: Entering directory '/<>/obj-x86_64-linux-gnu'
> > [ 50%] Building CXX object src/CMakeFiles/shiny-server.dir/launcher.cc.o
> > cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MT
> > src/CMakeFiles/shiny-server.dir/launcher.cc.o -MF
> > CMakeFiles/shiny-server.dir/launcher.cc.o.d -o
> > CMakeFiles/shiny-server.dir/launcher.cc.o -c
> > /<>/src/launcher.cc
> > /<>/src/launcher.cc: In function ‘int main(int, char**)’:
> > /<>/src/launcher.cc:38:13: warning: ignoring return value of
> > ‘int daemon(int, int)’ declared with attribute ‘warn_unused_result’
> > [-Wunused-result]
> >38 | daemon(1, 0);
> > | ~~^~
> > [100%] Linking CXX executable ../../bin/shiny-server
> > cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/cmake -E
> > cmake_link_script CMakeFiles/shiny-server.dir/link.txt --verbose=1
> > /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=.
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> > -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -rdynamic
> > "CMakeFiles/shiny-server.dir/launcher.cc.o" -o ../../bin/shiny-server
> > make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > [100%] Built target shiny-server
> > make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > /usr/bin/cmake -E cmake_progress_start
> > /<>/obj-x86_64-linux-gnu/CMakeFiles 0
> > make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > node-gyp rebuild
> > gyp info it worked if it ends with ok
> > gyp info using node-gyp@9.0.0
> > gyp info using node@16.15.1 | linux | x64
> > gyp info find Python using Python version 3.10.5 found at "/usr/bin/python3"
> > gyp info spawn /usr/bin/python3
> > gyp info spawn args [
> > gyp info spawn args '/usr/share/nodejs/node-gyp/gyp/gyp_main.py',
> > gyp info spawn args 'binding.gyp',
> > gyp info spawn args '-f',
> > gyp info spawn args 'make',
> > gyp info spawn args '-I',
> > gyp info spawn args '/<>/build/config.gypi',
> > gyp info spawn args '-I',
> > gyp info spawn args '/usr/share/nodejs/node-gyp/addon.gypi',
> > gyp info spawn args '-I',
> > gyp info spawn args '/usr/include/nodejs/common.gypi',
> > gyp info spawn args '-Dlibrary=shared_library',
> > gyp info spawn args '-Dvisibility=default',
> > gyp info spawn args '-Dnode_root_dir=/usr/include/nodejs',
> > gyp info spawn args '-Dnode_gyp_dir=/usr/share/nodejs/node-gyp',
> > gyp info spawn args
> > '-Dnode_lib_file=/usr/include/nodejs/<(target_arch)/node.lib',
> > gyp info spawn args '-Dmodule_root_dir=/<>',
> > gyp info spawn args '-Dnode_engine=v8',
> > gyp info spawn args '--depth=.',
> > gyp info spawn args '--no-parallel',
> > gyp info spawn args '--generator-output',
> > gyp info spawn args 'build',
> > gyp info spawn args '-Goutput_dir=.'
> > gyp info spawn args ]
> > Traceback (most recent call last):
> > File "/usr/share/nodejs/node-gyp/gyp/gyp_main.py", line 33, in
> > sys.exit(load_entry_point('gyp==0.1', 'console_scripts', 'gyp')())
> > File "/usr/share/nodejs/node-gyp/gyp/gyp_main.py", line 25, in
> > importlib_load_entry_point
> > return next(matches).load()
> > File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in
> > load
> > module = import_module(match.group('module'))
> > File "/usr/lib/python3.10/importlib/__init__.py", line 126, in
> > import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> > File "", line 1050, in _gcd_import
> > File "", line 1027, in _find_and_load
> > File "", line 1006, in
> > _find_and_load_unlocked
> > File "", line 688, in _load_unlocked
> > File "", line 883, in exec_module
> > File "", line 241, in
> > _call_with_frames_removed
> > File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 10, in
> >
> > import gyp.input
> > File "/usr/lib/python3/dist-packages/gyp/input.py", line 8, in
> > import gyp.common
> > File "/usr/lib/python3/dist-packages/gyp/common.py", line 14, in
> > from six.moves import collections_abc
> > ModuleNotFoundError: No module named 'six'
> > gyp ERR! configure error
> > gyp ERR! stack Error: `gyp` failed with exit code: 1
> > gyp ERR! stack at ChildProcess.onCpExit
>
Bug#1016069: ceph: CVE-2022-0670
On 7/27/22 09:50, Thomas Goirand wrote: Oh... now I have the problem that Ceph FTBFS with GCC 12... :/ I'll let you know when I can get this fixed. Cheers, Thomas Goirand (zigo) Hi, FYI, I was able to fix the build, so Ceph 16.2.10+ds was uploaded to Unstable, and built on all arch. I also have the information from IRC that CVE-2022-0670 only affects 16.2.x, and not the version in Stable or earlier. So please update the security tracker accordingly. This bug can be completely closed then... (or when 16.2.10 reaches testing). Cheers, Thomas Goirand (zigo)
Bug#1015930: lists.debian.org: Please create debian-livecoding
Hi, I'm sure this is a create initiative from Joênio, so I support the creation of this list. Best regards, -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Diretor do Instituto para Conservação de Tecnologias Livres Site: http://phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450 OpenPGP_signature Description: OpenPGP digital signature
Bug#1015861: bamtools: FTBFS with upcoming doxygen 1.9.4
Control: tags -1 pending This is fixed in Git. Unfortunately the new version is in NEW since 4 months and I do not want to fiddle around with this package. A fix will be uploaded with source-only upload once the package is finally accepted. Kind regards Andreas. -- http://fam-tille.de
Bug#1016171: chatty: fails to build with gnome-desktop 43
Source: chatty Version: 0.6.7-1 Severity: important Forwarded: https://source.puri.sm/Librem5/chatty/-/issues/726 chatty fails to build with gnome-desktop 43 Alpha (currently in Debian experimental). I have reported the bug upstream with more details. Thank you, Jeremy Bicha
Bug#1016170: RM: ospd -- ROM; upstream merged the code into another package (ospd-openvas)
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: sop...@offensive-security.com Hello, Upstream merged the code of ospd into ospd-openvas since version 21.4.5 https://github.com/greenbone/ospd/commit/7070e8f89e88ab40ee29fda57e545f18138780bf It was only used by ospd-openvas. Now it has no reverse-depends. Please remove the package from Debian. Thanks Sophie
Bug#1016169: buster-pu: package debootstrap/1.0.114+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-b...@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
While preparing for the usrmerge transition as per [0], we have done
some work on debootstrap [1] to ensure that, as per CTTE decision,
buildd machines (and CI machines) can remain unmerged-usr.
The new version of debootstrap with these changes is in unstable,
testing and stable-backports.
While talking with the buildd team, it was noted that some buildd
machines are still running oldstable, and there is no hard deadline for
the upgrade to stable. This means stable-backports is not enough to
ensure we can begin the transition, and blocking it on the buildd full
upgrades (which is difficult and time consuming) would put unduly
pressure on the DSA team and risk long delays, as the Bookworm freeze
approaches.
A selected backport of the changes for stable-proposed-updates and
oldstable-proposed-updates seems like a safe approach that removes the
buildd team/DSA from the critical path, and the buildd team/DSA would
prefer to go down that route.
The backport was tested by creating a sid chroot with local packages
that pull in usrmerge|usr-is-merged, and veryfing that with --no-
merged-usr and/or --variant buildd the chroot is still unmerged-usr as
expected.
Debdiff attached.
[0] https://lists.debian.org/debian-ctte/2022/07/msg00019.html
[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/71
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.114/debian/changelog debootstrap-1.0.114+deb10u1/debian/changelog
--- debootstrap-1.0.114/debian/changelog 2019-01-09 13:00:04.0 +
+++ debootstrap-1.0.114+deb10u1/debian/changelog 2022-07-28 12:18:59.0 +0100
@@ -1,3 +1,12 @@
+debootstrap (1.0.114+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * setup_merged_usr: create skip flag when merged-usr is disabled on
+bookworm+
+ * Add usr-is-merged to the required set on testing/unstable
+
+ -- Luca Boccassi Thu, 28 Jul 2022 12:18:59 +0100
+
debootstrap (1.0.114) unstable; urgency=medium
* Revert changes from 1.0.113 (closes: #918722)
diff -Nru debootstrap-1.0.114/functions debootstrap-1.0.114+deb10u1/functions
--- debootstrap-1.0.114/functions 2019-01-09 12:59:11.0 +
+++ debootstrap-1.0.114+deb10u1/functions 2022-07-28 12:16:24.0 +0100
@@ -1323,7 +1323,23 @@
MERGED_USR="no"
fi
- if [ "$MERGED_USR" = "no" ]; then return 0; fi
+ if [ "$MERGED_USR" = "no" ]; then
+ # With the usrmerge becoming pseudo-essential we need to use this flag
+ # to ensure that even if it gets installed the buildd is not converted
+ # when debootstrap needs to create an unmerged-usr installation.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ mkdir -p "$TARGET/etc"
+ echo "this system will not be supported in the future" > "$TARGET/etc/unsupported-skip-usrmerge-conversion"
+ if ! doing_variant buildd; then
+ warning SANITYCHECK "Upgrading non-merged-/usr environments post-bookworm is unsupported. Only do this for CI/QA infrastructure that will be re-bootstrapped rather than upgraded."
+ fi
+ ;;
+ esac
+ return 0;
+ fi
local link_dir
case $ARCH in
diff -Nru debootstrap-1.0.114/scripts/debian-common debootstrap-1.0.114+deb10u1/scripts/debian-common
--- debootstrap-1.0.114/scripts/debian-common 2018-11-20 18:55:53.0 +
+++ debootstrap-1.0.114+deb10u1/scripts/debian-common 2022-07-28 12:16:24.0 +0100
@@ -32,6 +32,20 @@
base="$base apt-transport-https ca-certificates"
;;
esac
+
+ # On suites >= bookworm, either we set up a merged-/usr system
+ # via setup_merged_usr, or we deliberately avoided that migration
+ # by creating the flag file. This means there's no need for the
+ # live migration 'usrmerge' package and its extra dependencies:
+ # we can install the empty 'usr-is-merged' metapackage to indicate
+ # that the transition has been done.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ required="$required usr-is-merged"
+ ;;
+ esac
}
first_stage_install () {
signature.asc
Description: This is a digitally signed message part
Bug#1016168: bullseye-pu: package debootstrap/1.0.123+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-b...@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
While preparing for the usrmerge transition as per [0], we have done
some work on debootstrap [1] to ensure that, as per CTTE decision,
buildd machines (and CI machines) can remain unmerged-usr.
The new version of debootstrap with these changes is in unstable,
testing and stable-backports.
While talking with the buildd team, it was noted that some buildd
machines are still running oldstable, and there is no hard deadline for
the upgrade to stable. This means stable-backports is not enough to
ensure we can begin the transition, and blocking it on the buildd full
upgrades (which is difficult and time consuming) would put unduly
pressure on the DSA team and risk long delays, as the Bookworm freeze
approaches.
A selected backport of the changes for stable-proposed-updates and
oldstable-proposed-updates seems like a safe approach that removes the
buildd team/DSA from the critical path, and the buildd team/DSA would
prefer to go down that route.
The backport was tested by creating a sid chroot with local packages
that pull in usrmerge|usr-is-merged, and veryfing that with --no-
merged-usr and/or --variant buildd the chroot is still unmerged-usr as
expected.
Debdiff attached.
[0] https://lists.debian.org/debian-ctte/2022/07/msg00019.html
[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/71
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.123/debian/changelog debootstrap-1.0.123+deb11u1/debian/changelog
--- debootstrap-1.0.123/debian/changelog 2020-03-14 01:07:20.0 +
+++ debootstrap-1.0.123+deb11u1/debian/changelog 2022-07-28 12:04:03.0 +0100
@@ -1,3 +1,12 @@
+debootstrap (1.0.123+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * setup_merged_usr: create skip flag when merged-usr is disabled on
+bookworm+
+ * Add usr-is-merged to the required set on testing/unstable
+
+ -- Luca Boccassi Thu, 28 Jul 2022 12:04:03 +0100
+
debootstrap (1.0.123) unstable; urgency=medium
* Reinstate safeguard removed in 1.0.121, which is absolutely needed
diff -Nru debootstrap-1.0.123/functions debootstrap-1.0.123+deb11u1/functions
--- debootstrap-1.0.123/functions 2020-03-14 00:53:38.0 +
+++ debootstrap-1.0.123+deb11u1/functions 2022-07-28 11:55:40.0 +0100
@@ -1341,7 +1341,23 @@
MERGED_USR="no"
fi
- if [ "$MERGED_USR" = "no" ]; then return 0; fi
+ if [ "$MERGED_USR" = "no" ]; then
+ # With the usrmerge becoming pseudo-essential we need to use this flag
+ # to ensure that even if it gets installed the buildd is not converted
+ # when debootstrap needs to create an unmerged-usr installation.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ mkdir -p "$TARGET/etc"
+ echo "this system will not be supported in the future" > "$TARGET/etc/unsupported-skip-usrmerge-conversion"
+ if ! doing_variant buildd; then
+ warning SANITYCHECK "Upgrading non-merged-/usr environments post-bookworm is unsupported. Only do this for CI/QA infrastructure that will be re-bootstrapped rather than upgraded."
+ fi
+ ;;
+ esac
+ return 0;
+ fi
local link_dir
case $ARCH in
diff -Nru debootstrap-1.0.123/scripts/debian-common debootstrap-1.0.123+deb11u1/scripts/debian-common
--- debootstrap-1.0.123/scripts/debian-common 2020-03-13 02:04:21.0 +
+++ debootstrap-1.0.123+deb11u1/scripts/debian-common 2022-07-28 11:55:40.0 +0100
@@ -40,6 +40,20 @@
esac
;;
esac
+
+ # On suites >= bookworm, either we set up a merged-/usr system
+ # via setup_merged_usr, or we deliberately avoided that migration
+ # by creating the flag file. This means there's no need for the
+ # live migration 'usrmerge' package and its extra dependencies:
+ # we can install the empty 'usr-is-merged' metapackage to indicate
+ # that the transition has been done.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ required="$required usr-is-merged"
+ ;;
+ esac
}
first_stage_install () {
signature.asc
Description: This is a digitally signed message part
Bug#986204: (no subject)
Hi Guilherme Xavier On 7/27/22 11:23, Guilherme de Paula Xavier Segundo wrote: > I would like to know if you are still interested in packaging molecule > for Debian? I began to package but I was not able to finish it. I think I can finish it in october. But if you need it before please feel free to package it. I don't mind :) Please own the ITP bug if you do so. Here is the repository with the work I have done so far: https://salsa.debian.org/saki/molecule Cheers Sakirnth
Bug#1016139: (net-snmp: CVE-2022-24810 CVE-2022-24809 CVE-2022-24808 CVE-2022-24807 CVE-2022-24806 CVE-2022-24805)
I said: > I had uploaded net-snmp 5.9.3 anyway but I'll add those CVEs to the > changelog. > I'm trying to find where they've made the changes to see if it is possible > to get at least bullseye fixed. > I've had a look and believe these two commits are the fixes: snmpd: fix bounds checking in NET-SNMP-AGENT-MIB, NET-SNMP-VACM-MIB, SNMP-VIEW-BASED-ACM-MIB, SNMP-USER-BASED-SM-MIB https://github.com/net-snmp/net-snmp/commit/67ebb43e9038b2dae6e74ae8838b36fcc10fc937 snmpd: recover SET status from delegated request https://github.com/net-snmp/net-snmp/commit/9a0cd7c00947d5e1c6ceb54558d454f87c3b8341 Both sets of commits look pretty clear and simple to implement. I've asked upstream to confirm these are the only two patches. - Craig
Bug#993798: packaging issue
Hi, we can confirm the workaround solve the problem (thanks to MyMisc). Regards! Guido
Bug#1016167: 389-ds-base: dscreate does not work due to race condition when starting and connecting to LDAP server instance
Package: 389-ds-base
Version: 1.4.4.11-2
Severity: important
X-Debbugs-Cc: mgronczew...@efigence.com
I've tried to create the new instance via dscreate from-file (tried interactive
version with default config with no changes too) and it crashes after starting
server and questionnaire, because it tries to connect to server that is
*started* but not yet listening on the socket:
Enter the Directory Manager password:
Confirm the Directory Manager Password:
Enter the database suffix (or enter "none" to skip)
[dc=ldap,dc=example,dc=com]: none
Do you want to start the instance after the installation? [yes]: yes
Are you ready to install? [no]: yes
Starting installation...
Error: Can't contact LDAP server - 111 - Connection refused
after turning the verbose mode:
...
DEBUG: systemd status -> True
DEBUG: systemd status -> True
DEBUG: open(): Connecting to uri ldapi://%2Fvar%2Frun%2Fslapd-main.socket
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-main
DEBUG: Using external ca certificate /etc/dirsrv/slapd-main
DEBUG: Using external ca certificate /etc/dirsrv/slapd-main
DEBUG: Using /etc/openldap/ldap.conf certificate policy
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 2
DEBUG: open(): Using root autobind ...
DEBUG: {'desc': "Can't contact LDAP server", 'errno': 111, 'info':
'Connection refused'}
Traceback (most recent call last):
File "/sbin/dscreate", line 80, in
result = args.func(inst, log, args)
File "/usr/lib/python3/dist-packages/lib389/cli_ctl/instance.py", line
68, in instance_create
if sd.create_from_inf(args.file):
File "/usr/lib/python3/dist-packages/lib389/instance/setup.py", line 538,
in create_from_inf
self.create_from_args(general, slapd, backends, self.extra)
...
Currently I've applied an ugly fix to my system that appears to solve the
problem:
--- /tmp/__init__.py2022-07-28 13:10:08.806516127 +0200
+++ /usr/lib/python3/dist-packages/lib389/__init__.py 2022-07-28
13:10:20.274329837 +0200
@@ -934,6 +934,7 @@
uri = self.toLDAPURL()
self.log.debug('open(): Connecting to uri %s', uri)
+time.sleep(10)
if hasattr(ldap, 'PYLDAP_VERSION') and MAJOR >= 3:
super(DirSrv, self).__init__(uri, bytes_mode=False,
trace_level=TRACE_LEVEL)
else:
and confirms my suspicion script tries to connect to the server that isn't up
yet (system service dirmgr@main.service is up and responding after installer
fails)
I've checked and both earlier(buster) and newer(bookworm) versions of package
appear to be working fine
-- System Information:
Debian Release: 11.4
APT prefers bullseye-security
APT policy: (500, 'bullseye-security')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages 389-ds-base depends on:
ii 389-ds-base-libs 1.4.4.11-2
ii acl 2.2.53-10
ii adduser 3.118
ii debconf [debconf-2.0]1.5.77
ii ldap-utils 2.4.57+dfsg-3+deb11u1
ii libc62.31-13+deb11u3
ii libcrypt11:4.4.18-4
ii libdb5.3 5.3.28+dfsg1-0.8
ii libicu67 67.1-7
ii libldap-2.4-22.4.57+dfsg-3+deb11u1
ii libmozilla-ldap-perl 1.5.3-3+b2
ii libnetaddr-ip-perl 4.079+dfsg-1+b5
ii libnspr4 2:4.29-1
ii libnss3 2:3.61-1+deb11u2
ii libpam0g 1.4.0-9+deb11u1
ii libsasl2-2 2.1.27+dfsg-2.1+deb11u1
ii libsasl2-modules-gssapi-mit 2.1.27+dfsg-2.1+deb11u1
ii libsnmp405.9+dfsg-3+b1
ii libsocket-getaddrinfo-perl 0.22-3
ii libsystemd0 247.3-7
ii perl 5.32.1-4+deb11u2
ii python3 3.9.2-3
ii python3-lib389 1.4.4.11-2
ii python3-selinux 3.1-3
ii python3-semanage 3.1-1+b2
ii python3-sepolicy 3.1-1
ii systemd 247.3-7
389-ds-base recommends no packages.
389-ds-base suggests no packages.
-- no debconf information
--
Mariusz Gronczewski, Administrator
Efigence S. A.
ul. Wołoska 9a, 02-583 Warszawa
T: [+48] 22 380 13 13
NOC: [+48] 22 380 10 20
E: ad...@efigence.com
Bug#1016166: riseup-vpn: wrong values of Vcs-{Browser,Git} fields in d/control
Package: riseup-vpn
Version: 0.21.11+ds-3
Severity: minor
Tags: newcomer
Dear Maintainer,
Vcs-{Browser,Git} fields in d/control are set to
https://salsa.debian.org/med-team/bitmask-vpn{,git}, which is wrong
since the package's Salsa repository is under Go Packaging team, not
Debian Med team.
Cheers!
Lev
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages riseup-vpn depends on:
ii libc62.33-8
ii libgcc-s112.1.0-7
ii libqt5core5a 5.15.4+dfsg-4
ii libqt5gui5 5.15.4+dfsg-4
ii libqt5qml5 5.15.4+dfsg-4
ii libqt5widgets5 5.15.4+dfsg-4
ii libstdc++6 12.1.0-7
ii openvpn 2.6.0~git20220518+dco-2
ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7+b1
ii python3 3.10.5-3
ii qml-module-qt-labs-platform 5.15.4+dfsg-2
ii qml-module-qtquick-controls2 5.15.4+dfsg-2
ii qml-module-qtquick-dialogs 5.15.4-2
ii qml-module-qtquick-extras5.15.4-2
ii qml-module-qtquick2 5.15.4+dfsg-4
riseup-vpn recommends no packages.
riseup-vpn suggests no packages.
-- no debconf information
Bug#999310: Bug#1016152: RFS: libxml-dumper-perl/0.81-1.4 [NMU] [RC] -- Perl module for dumping Perl objects from/to XML
Control: tag 999310 + pending
On Thu, 28 Jul 2022 08:25:47 +0200, Håvard F. Aasen wrote:
> libxml-dumper-perl (0.81-1.4) unstable; urgency=medium
> .
>* Non-maintainer upload.
>* Include missing build target. (Closes: #999310)
> - Using dh sequencer.
> - Add libxml-parser-perl as build dependency, for testsuite.
> - Add runtime dependency on ${misc:Depends}.
>* d/watch
> - Bump to version 4.
> - Update URI.
>* Remove superfluous dot '.' in package description
>* d/copyright: Change to UTF-8 encoding.
Uploaded to DELAYED/5, thanks for fixing this RC bug.
(For future reference: You changed a bit more than what is necessary
to fix th ebug, which is a bit unusual for NMUs. But is the changes
are all sane, I just went ahead with the upload.)
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
signature.asc
Description: Digital Signature
Bug#1016165: openipmi: ipmilan/ipmilan(1)/ipmi_lan(1) all disagree, sometimes internally, about what the config file is
Package: openipmi Version: 2.0.33-1 Severity: normal Dear Maintainer, -- >8 -- $ strace -e openat ipmilan 2>&1 | grep /etc openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/etc/ipmi/lan.conf", O_RDONLY) = -1 ENOENT (No such file or directory) Unable to open configuration file '/etc/ipmi/lan.conf' $ man ipmilan | grep -B2 /etc OPTIONS -c config-file Set the configuration file to one other than the default of /etc/ipmi_lan.conf -- CONFIGURATION Configuration is accomplished through the file /etc/ipmi_lan.conf. A file with another name or path may be -- FILES /etc/ipmi_lan.conf $ man ipmi_lan | grep -B1 /etc SYNOPSIS /etc/ipmi/lan.conf -- FILES /etc/ipmi_lan.conf -- >8 -- Best, наб -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: amd64, i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openipmi depends on: ii libc6 2.33-8 ii libopenipmi0 2.0.33-1 ii libpopt0 1.18-3 ii libreadline8 8.1.2-1.2 ii libsnmp40 5.9.3+dfsg-1 ii lsb-base 11.2 Versions of packages openipmi recommends: ii kmod 30+20220630-2 openipmi suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1011393: openpace: FTBFS on arm64, armel and mips64el
control: tags -1 patch pending Uploaded. G. On Sun, 22 May 2022 15:32:34 +0300 Adrian Bunk wrote: Control: retitle -1 openpace: frequent parallel FTBFS Control: forwarded -1 https://github.com/frankmorgner/openpace/pull/56 Control: tags -1 patch On Sat, May 21, 2022 at 07:22:29PM +0200, Sebastian Ramacher wrote: > Source: openpace > Version: 1.1.2+ds+git20220117+453c3d6b03a0-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > https://buildd.debian.org/status/fetch.php?pkg=openpace=arm64=1.1.2%2Bds%2Bgit20220117%2B453c3d6b03a0-1=1652780709=0 > > > libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -o .libs/cvc-print cvc_print-cvc-print.o cvc_print-read_file.o cvc_print-cvc-print-cmdline.o ./.libs/libeac.so ./.libs/libvc.a -lcrypto > make[6]: Leaving directory '/<>/src' > /usr/bin/help2man \ >--output=cvc-print.1 \ >--no-info \ >--source='OpenPACE 1.1.2' \ >./cvc-print > /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o cvc-print cvc_print-cvc-print.o cvc_print-read_file.o cvc_print-cvc-print-cmdline.o libeac.la libvc.la -lcrypto > help2man: can't get `--help' info from ./cvc-print > Try `--no-discard-stderr' if option outputs to stderr > make[5]: *** [Makefile:1532: cvc-print.1] Error 127 > make[5]: *** Waiting for unfinished jobs >... This is not architecture specific, it is a parallel build failure. Fix linked above. > Cheers cu Adrian diff -Nru openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/changelog openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/changelog --- openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/changelog 2022-05-17 11:17:33.0 +0200 +++ openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/changelog 2022-07-28 13:17:25.0 +0200 @@ -1,3 +1,12 @@ +openpace (1.1.2+ds+git20220117+453c3d6b03a0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/patches/7de0b27a3d5dfb3ffeb82c37ce7ba4e85f764314.patch: +- Add upstream patch from Adrian Bunk to fix a race condition in parallel + builds (Closes: #1011393). + + -- Gianfranco Costamagna Thu, 28 Jul 2022 13:17:25 +0200 + openpace (1.1.2+ds+git20220117+453c3d6b03a0-1) unstable; urgency=medium * New upstream snapshot (Closes: #1006513). diff -Nru openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/7de0b27a3d5dfb3ffeb82c37ce7ba4e85f764314.patch openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/7de0b27a3d5dfb3ffeb82c37ce7ba4e85f764314.patch --- openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/7de0b27a3d5dfb3ffeb82c37ce7ba4e85f764314.patch 1970-01-01 01:00:00.0 +0100 +++ openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/7de0b27a3d5dfb3ffeb82c37ce7ba4e85f764314.patch 2022-07-28 13:17:25.0 +0200 @@ -0,0 +1,39 @@ +From 7de0b27a3d5dfb3ffeb82c37ce7ba4e85f764314 Mon Sep 17 00:00:00 2001 +From: Adrian Bunk +Date: Sun, 22 May 2022 15:15:29 +0300 +Subject: [PATCH] src/Makefile.am: Fix race condition in parallel builds + +Calling "make" from a Makefile results in several make invocations +in parallel that do not know about each other and might generate +the same files in parallel: +https://buildd.debian.org/status/logs.php?pkg=openpace=1.1.2%2Bds%2Bgit20220117%2B453c3d6b03a0-1 + +Just tell make about the correct dependencies and everything works +automatically. +--- + src/Makefile.am | 6 ++ + 1 file changed, 2 insertions(+), 4 deletions(-) + +diff --git a/src/Makefile.am b/src/Makefile.am +index 22338ba..1f17372 100644 +--- a/src/Makefile.am b/src/Makefile.am +@@ -97,16 +97,14 @@ ENV = env \ + + endif + +-cvc-create.1: cvc-create.ggo.in +- make -C $(builddir) cvc-create$(EXEEXT) ++cvc-create.1: cvc-create$(EXEEXT) + $(ENV) $(HELP2MAN) \ + --output=$@ \ + --no-info \ + --source='$(PACKAGE_STRING)' \ + $(builddir)/cvc-create$(EXEEXT) + +-cvc-print.1: cvc-print.ggo.in +- make -C $(builddir) cvc-print$(EXEEXT) ++cvc-print.1: cvc-print$(EXEEXT) + $(ENV) $(HELP2MAN) \ + --output=$@ \ + --no-info \ diff -Nru openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/series openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/series --- openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ openpace-1.1.2+ds+git20220117+453c3d6b03a0/debian/patches/series 2022-07-28 13:15:15.0 +0200 @@ -0,0 +1 @@ +7de0b27a3d5dfb3ffeb82c37ce7ba4e85f764314.patch
Bug#1012067: [Pkg-freeipa-devel] Bug#1012067: Bug#1012067: jss: FTBFS with OpenJDK 17: no such provider SunJSSE
Emmanuel Bourg kirjoitti 28.7.2022 klo 13.36: Le 2022-07-28 09:49, Timo Aaltonen a écrit : Rebuilding jss with openjdk 11 fails just the same way, so the failure is not caused by jdk 17 but something else.. It seems to build fine with OpenJDK 11 on the reproducible build workers though: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jss.html ok, fails to build on my chroot -- t
Bug#992806: ftjam - ship with bookworm?
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: ftjam -- RoQA; upstream dead, obsolete dh compat levels, replacements exist Hi, * ydir...@free.fr [220728 11:05]: > > I guess some users of the improved jam could still exist, but given > > ftjam has not seen any updates since 2007, and jam before that even > > longer, I find this somewhat unlikely. [..] > > Otherwise I'll raise severity of this bug over time and eventually > > might ask for removal from Debian. > > I've pondered this in the past, and concluded that the maintenance load > was low enough not to bother. ftjam has not been in testing since 2021-12-29, and there are two RC bugs open (debhelper compat level, required build-target). > OTOH the popcon graph clearly shows the decline of this legacy package. > It would seem like a good moment to drop it. Lets do that now. Cloning bug to ftp.debian.org to ask for removal. Thanks, Chris
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
Hi, On 28-07-2022 12:27, Bernhard Turmann wrote: you mentioned bug 1004729 which is marked as done. That might be indeed the case for unstable/testing. Unfortunately, this is not the case for the version bind-dyndb-ldap/11.6-3 in bullseye stable after several newer bind9 releases merged into stable with 9.16.27 being the latest. Means, currently, bind-dyndb-ldap is broken in stable. What is the correct way to get this resolved and maintain it like that? bind-dyndb-ldap needs to be binNMUed in stable too. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#785075: 40kB individual object size increase in util-linux on arm*
Dear ARM Porters, util-linux has an autopkgtest checking if its binaries contain any large chunks of just zeroes. This check has recently began failing on arm64, armel, armhf. I found that /bin/dmesg now has a 56kB size region of just zeroes on arm64. Judging by the sizes of other binaries, this seems to effect many of the util-linux (essential) programs! As I do not see any relevant changes in util-linux, I would suspect this is a lingering issue in the toolchain (ld?) caused by small alignment/size changes in the source or in linked libraries. For now I have bumped the test limit to 80kB, but I imagine people want small binaries, especially on "embedded" archs. Could you please look into this? You can see the size differences between util-linux_2.38-4 and util-linux_2.38-5 in their build logs: https://buildd.debian.org/status/fetch.php?pkg=util-linux=arm64=2.38-4=1649940631=0 https://buildd.debian.org/status/fetch.php?pkg=util-linux=arm64=2.38-5=1657930858=0 Some numbers for arm64: util-linux Installed-Size 5.2MB -> 7.7MB /bin/dmesg 88k -> 141k /bin/findmnt 85k -> 134k /sbin/fdisk 166k -> 198k libmount.so.1.1.0 424k -> 461k Thanks, Chris
