Bug#1068960: python-pybedtools: FTBFS: testsuite error: 14 failed, 491 passed, 2 deselected, 3 xfailed
Source: python-pybedtools
Version: 0.9.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer,
python-pybedtools fails to build from source due to errors in the
testsuite. From my build log on amd64:
| === short test summary info
| FAILED pybedtools/test/test_gzip_support.py::test_gzipped_file_types_are_bed
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipped_files_can_be_intersected
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipped_files_are_iterable_as_normal
| FAILED
pybedtools/test/test_gzip_support.py::test_str_representation_of_gzipped_files_is_the_same_as_normal
| FAILED
pybedtools/test/test_gzip_support.py::test_head_of_gzipped_files_is_the_same_as_normal
| FAILED pybedtools/test/test_gzip_support.py::test_gzipped_output -
FileNotFou...
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipping_is_default_when_extension_is_dot_gz
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipping_can_be_turned_off_even_for_dot_gz
| FAILED pybedtools/test/test_issues.py::test_issue_169 - UnicodeDecodeError:
'...
| FAILED pybedtools/test/test_issues.py::test_issue_196 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_180 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_181 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_258 - gzip.BadGzipFile:
Not...
| FAILED pybedtools/test/test_issues.py::test_issue_343 - UnicodeDecodeError:
'...
| === 14 failed, 491 passed, 2 deselected, 3 xfailed in 9.27s
| E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.11_pybedtools/build; python3.11 -m pytest
-k "not test_chromsizes"
| dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12
3.11" returned exit code 13
| make: *** [debian/rules:30: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
2
A full build log on riscv64 is available here:
https://buildd.debian.org/status/fetch.php?pkg=python-pybedtools=riscv64=0.9.1-1%2Bb2=1713040255=0
Full build logs on amd64 and arm64 are also available on reproducible
builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-pybedtools_0.9.1-1.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/python-pybedtools_0.9.1-1.rbuild.log.gz
Regards
Aurelien
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
On Sat, 13 Apr 2024 17:29:48 +0200 Martin Steigerwald wrote: > Martin Steigerwald - 13.04.24, 15:05:41 CEST: > > No PATH defined. > > > > The script defines it. See line 8 in my changed script. However it > > does not export it. Thus adding line 9 fixes the bug I reported: > > > > 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin > > 9 export PATH > > > > The network is configured just fine after adding that line. > > Since configuring networking works on physical machines – I know for > sure with Devuan 5 aka Daedalus and Devuan Ceres which was at a > similar state Devuan Excalibur is currently – regarding the right fix > the question remains: > > What is different with the PATH in both cases and why? > > Why is it empty inside the (unprivileged) Incus managed LXC > container? Is it empty on the physical machine? I doubt it. But where > does the difference come from? And anyway the PATH is being set in > both stage 1 and stage 2 scripts, just not exported. So on a physical > machine it appears that PATH is being exported before already. It > might be exported before already on a container as well, albeit > undefined / empty. If I remember correctly, it's the kernel that sets environment for init; and it's different even when it boots "statically" vs via initramfs as the latter defines a lot of extra and unecessary stuff > > In both cases /bin/sh points to /bin/dash. Both the VM with Excalibur > and the physical host with Daedalus are usrmerge'd. >
Bug#1068588: redesign of how autopkgtest talks to the testbed
Hi, On 09-04-2024 6:23 p.m., Paride Legovini wrote: * runner/autopkgtest talks to the backend with a simple text protocol. While this enables users to add another backend without changes to the src:autopkgtest code trivially, the drawback of that is loosing all nuance of what really is going on on both sides of the communication. That is particularly bad when unexpected events happen. All events need handling on both sides, including unexpected events. However this simple text based protocol also has advantages: it makes it easy to repurpose the virt servers for other uses, like what sbuild does. That's exactly what I meant. These other projects do not need to be written in Python, or we could in principle have a virt-server not written in Python. Currently all our backends are written in Python, so the requirement to have it already exists. I could imaging (just an idea) that we have a (hopefully small) glue script that connects the new or rewritten backends to the old protocol for users like that. * unify the communication with test beds via ssh. This ensures that the environment is much more likely to be the same across the different backends and also ensures the right session. I agree nowadays ssh is a reasonable common denominator. As you noted below, there are some virt servers where it doesn't apply well, but they are probably special enough to be treated differently. Obviously if there are too many of those, the value of the redesign drops. I think standardizing on ssh is desirable, but this implicitly means that we'll have some more specific requirements for the testbed images (in random order: sshd, some sort pubkey authentication, a "normal" (non-root) user, cloud-init to initialize all these things?, ...). We are currently shipping tools to prepare test images (tools/autopkgtest-build*), but at the same time we are very flexible on the image requirements. Should we accept being more strict on this, and state that the virt server are meant to be used to purpose built images? Or should we have a better spec on what the virt servers expect from the image? What I was thinking (but absolutely open for debate) is that the new virt-servers would be responsible for setting up the sshd-server in their supported testbed and handling the key generation and passing on of the information. But, as you suggested, we could also leave that to the image generators (being them our "own" or otherwise created) and document what we need in the testbed. E.g. we could spec that the ssh key lives somewhere in the testbed, to be picked up by the virt-server which transfers the info to the ssh driver. If we go that route, we would remove quite some logic from the `autopkgtest` code path, into the preparation step, which I think would be good. However, a large price (is this worrying? at first sight it doesn't look like anything bigger than already is exposed) would be that the key is probably going to be shared between all autopkgtest runs that are started from the same template testbed. Currently autopkgtest-virt-ssh works around this by using the "ssh setup" script, but my impression is that we want to move away from that kind of approach. So that was my initial idea, but indeed, might be better to transfer as much of that as possible to to the testbed creation phase. I'm wondering how much is possible with those maas and nova setups? I would assume they already do only what's needed. * make the change to use ssh for communication, without a change of the virt server protocol. Do you think this can be done incrementally, that is: 1. modify the virt-servers we have to use ssh for communication with the testbed systems, keeping it in a common library. That's what I was thinking indeed. But it's hard to judge where it's better to try and keep steps small and manageable to get results versus the addition work required if we finally reach the end goal. 2. keeping the implementation above, or most of it, also reimplement the autopkgtest<->backend communication protocol. The two problems should be quite decoupled after all, and while I'm convinced that point 2 is good, I am less sure about point 1, for the reasons I stated initially. I think I miss the point you are trying to make here. * we could consider supporting the current protocol in parallel, which would enable us to migrate one backend at a time and enable our users to migrate their own backends at their own pace. However, it means we'd need to support two code paths. So the open question is: (how long) do we want to maintain the current protocol. I wonder how many other backends are out there. Are we aware of any other consumer of the virt servers apart from autopkgtest itself and sbuild? I was not, but last days I learned that reprotest copied our virt servers: https://salsa.debian.org/reproducible-builds/reprotest/-/tree/master/reprotest/virt (documentation ongoing in issue #3) I think
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Hello Martin, thanks for the detailed info and the time spent on it On Sat, 13 Apr 2024 15:05:41 +0200 Martin Steigerwald wrote: > Martin Steigerwald - 13.04.24, 14:32:16 CEST: > > Any idea how to find the cause of what is happening here? > > I found the cause: > > The container starts out with an almost empty environment. In > [...] > > root@zdevuan:~# cat rcS.log > >> environment > container=lxc > PWD=/ > >> end of environment > > No PATH defined. > > The script defines it. See line 8 in my changed script. However it > does not export it. Thus adding line 9 fixes the bug I reported: > > 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin > 9 export PATH > > The network is configured just fine after adding that line. > > > > Same goes for stage 2. In /etc/runit/2 I added: >[...] > > Exporting the PATH there as well like > > 1 #!/bin/sh > 2 > 3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin > 4 export PATH > 5 SVDIR=/etc/service > > fixes > > root@zdevuan:~# cat /etc/boot.d/network > #!/usr/bin/env sh > > /etc/init.d/networking restart > > The network is configured even without the "export PATH" fix in > /etc/runit/1. OK, so if I undertand correctly we either export PATH in the /etc/init.d/networking script or we export PATH both in stage 1 and 2 (so the script does not fail during boot and can be called during runtime): is that correct? If yes I think it's better to fix the networking script (ifupdown pkg) so that the fix works for sysvinit users too. Different story if multiple scripts fails during boot because of empty PATH; many scripts in /etc/rc.S/ set their PATH but others don't.. Could you confirm that no other scripts fails in your container setup when PATH is not exported in stage 1 ? > > I just wonder why stage 2 contains /usr/local bin directories. I think > that should not be the case. Shall I report this as a different issue? PATH is passed to env call for runsvdir, so I guess one can exec a bin from local as runscript (not sure) without setting the PATH. I can't think of other use cases.. I'm fine with removing, just a bit wary, I'm afraid to break some custom setup > > > > I am now undoing my debug output. > > I think I could provide a merge request for the fixes at a later time. > For now I like to finish the Devuan template and actually use it. > > That bootlogd does not seem to work inside a container is a different > issue I may report at another time. > > I added empty "debug" and "verbose" files in /etc/runit but did not > find any debug output. Maybe those files needed to have some content. > Maybe it requires bootlogd. those files only work for runit stuff (runscripts and the sv trigger), boot scripts are for sysvinit and do not obey to runit settings :( perhaps it's time to roll some native runit bootscripts.. > > But that is for another time :) > > Best, Best regards, Lorenzo
Bug#1066479: closed by Debian FTP Masters (reply to Cyril Brulebois ) (Bug#1066479: fixed in opendnssec 1:2.1.13-1.1)
Debian Bug Tracking System (2024-03-28): > opendnssec (1:2.1.13-1.1) unstable; urgency=medium > . >* Non-maintainer upload. >* Fix FTBFS due to missing utilities.h include for the clamp declaration > (Closes: #1066479): 0018-fix-missing-include.patch This hasn't reached testing yet because of various transitions. Pinging this bug report to avoid having packages removed from testing, including reverse dependencies, as dpkg itself hasn't migrated either. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1068588: redesign of how autopkgtest talks to the testbed
Hi, On 09-04-2024 6:23 p.m., Paride Legovini wrote: PS: would it be worth it to enable dashboards for autopkgtest on salsa to manage this project? I assume issues on salsa are disabled on purpose to avoid bug reports in multiple places. Could we make adding issues project members only? I'm in favor of experimenting with that, of course keeping actual bugs in the bts. Thanks for bringing this up! I have enabled the issue tracker on salsa for members only (to avoid getting bug reports there that should go to the BTS). I started a plan board [1]. I'm not used to use interfaces like this, so please help me get it into an useful shape if you have ideas on how to improve it and even speak up if you think I'm doing it "wrong". Feel totally free to add more issues if you spot something's missing. Ideally I very much don't do this alone. Paul [1] https://salsa.debian.org/ci-team/autopkgtest/-/boards OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068958: RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs
Control: retitle -1 RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs Some obvious silly copy-and-paste error in the title. Now it should be fixed :P -- Xiyue Deng
Bug#1068958: Xiyue Deng
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "elpa-snakemake": * Package name : elpa-snakemake Version : 2.0.0+git20231210.4ad41da-1 Upstream contact : Kyle Meyer * URL : https://git.kyleam.com/snakemake-mode/about * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/elpa-snakemake Section : editors The source builds the following binary packages: elpa-snakemake-mode - provides syntax highlighting for snakekmake files in emacs elpa-snakemake - Run Snakemake workflows from Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elpa-snakemake/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elpa-snakemake/elpa-snakemake_2.0.0+git20231210.4ad41da-1.dsc Changes since the last upload: elpa-snakemake (2.0.0+git20231210.4ad41da-1) unstable; urgency=medium . * Team upload * Sync to latest upstream snapshot (4ad41da) (Closes: #1068956) * Disable autopkgtest as the ERT tests require a writable $HOME * Modernize d/watch with substitute strings to be more robust * Add a version header in snakemake.el to workaround dh-elpa upstream version handling limitation * Commit Debian 3.0 (quilt) metadata * Trim trailing whitespace * Set upstream metadata fields: Repository * Update standards version to 4.7.0, no changes needed Regards, -- Xiyue Deng
Bug#1066334: Redefinition of _Int (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
H again,
Am Sun, Apr 14, 2024 at 07:17:41AM +0200 schrieb Andreas Tille:
> Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden:
> >
> > The one after this looks like a GTK problem, and that's the point at
> > which I bow out.
I was able to fix some more missing declaration issues (which luckily did
not were connected to GTK) but I'm now stumbling upon:
...
In file included from disknew.c:85:
../whooks/systags.h:57:15: error: expected identifier before numeric constant
57 | #define _Int 24
| ^~
../wh/acetypes.h:36:16: note: in expansion of macro '_Int'
36 | typedef enum { _Int, _Text, _Float, _DateType, _Key, _Tag } AceType;
|^~~~
...
which is caused by whooks/systags.h[2]
...
#define _Int 24
#define _Unsigned 25
#define _Long 26 /* not supported */
#define _Long_Unsigned 27 /* not supported */
#define _Float 28
...
Is there any trick I could use here instead of replacing these
definitions by something else like _Int_acedb or so globally to get this
build by modern compilers?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/acedb/-/jobs/5586407#L1893
[2]
https://salsa.debian.org/med-team/acedb/-/blob/master/whooks/systags.h?ref_type=heads#L57-61
--
https://fam-tille.de
Bug#1062068: nvme-cli package fails to download firmware file for nvme
close 1062068 thanks Hi Anubhav, thank you for your report. Unfortunately you're using a very old version of nvme-cli that can not be expected to work with recent firmware files. Please upgrade nvme-cli to a more recent version (at last the one in stable). Regards, Daniel
Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st
Package: wnpp Severity: wishlist Owner: Tobias Frost X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gnome-shell-extension-vertical-workspaces Version : (tbd, likely a git snapshot) Upstream Contact: GdH * URL : https://github.com/G-dH/vertical-workspaces * License : GPL-3.0 Programming Lang: Javascript Description : A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically stacked workspaces. A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically stacked workspaces. Features: - Vertically or horizontally stacked workspaces - Adjust position, orientation, scale and visibility of overview content - Customizable profiles offer predefined configurations for GNOME 3.xx, GNOME 40+ and another 2 custom layouts - 2 overview modes with static windows/workspace. The Static Workspace option allows you to use dash like a dock with auto-hide, but with all advantages of the activities overview - Support for secondary monitors, workspace thumbnails can be placed on the opposite side than on the primary monitor - Wallpaper background with adjustable blur effect and brightness in the overview - Custom Dash icon size and on-click/scroll behavior - Optional workspace isolated Dash - Dash background transparency and corner radius adjustments - Adjustable app grid icon size, number of columns and rows, content, optional active and draggable icons in folder preview in optional 3x3 grid - Custom search view width, app results icons size and number of result lists rows, improved app search - Workspace thumbnails can show background wallpaper and labels (always or on mouse hover) with combination of workspace index, workspace name, name of the current application and current window title - Title captions of window previews moved into the preview (originally beneath the preview) and can be set as always visible. Adjustable window preview icon - Static background in workspace switcher (outside overview). Keeps Conky below, DING desktop icons stay visible (if not covered by windows) - Control over transition animations, including speed - Recent files search provider with Ctrl + Space hotkey - Supports WSP (Window search provider) extension with Space hotkey that allows quick window navigation - Supports ESP (Extensions search provider) with Ctrl + Shift + Space hotkey that allows to search for installed extensions, open their settings and enable or disable them - Reorder workspaces in overview using Shift + Scroll or Shift + Page Up/Down - Adds Force Quit, Close Windows on Current Workspace and Move Windows to Current Workspace items to app icon menu. The latter action can be activated using Shift + click on app icon - Change notification banners and OSD popups position - Window attention handler options can activate the attention-demanding window immediately or silence its notification - Optional position of the hot corner that can follow the dash and expand to hot edge - Super key double-press options - Supports WTMB (Window Thumbnails) extension that allows you to create Picture-in-Picture thumbnail of the window by clicking on its preview in the overview (secondary mouse buttons or window preview icon) This is a replacement for gnome-shell-extension-vertical-overview, which is dead-uptream and will stop working with GNOME 45. gnome-shell-extension-vertical-overview will be removed from Debian once this package is ready.
Bug#1068956: elpa-snakemake: Failure during Debian Continous Integration
Package: elpa-snakemake Severity: serious X-Debbugs-Cc: debian-emac...@lists.debian.org, Xiyue Deng According to Debian Continuous Integration, elpa-snakemake is having an error during installation (see logs on amd64[1].) [1] https://ci.debian.net/packages/e/elpa-snakemake/unstable/amd64/45273239/ -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1064390: mdadm: new upstream version 4.3 available
close 1064390 4.3-1 thanks Hi Graham, thanks - I've just uploaded 4.3. Regards, Daniel
Bug#1042906: ansible: please package new upstream version 8.x
retitle 1042906 please package new upstream version 9.x thanks Hi Lee, any updates since last year? Ansible is currently at 9.x and I'd really like to be able to use a recent enough version of ansible via debian packages. Is there anything I could help you with? Regards, Daniel
Bug#1068955: incompatible with inkscape 1.3
Package: inkscape-open-symbols Severity: wishlist Hi, thank you for maintaining inkscape-open-symbols. As inkscape-open-symbols 1.2 is incompatible with inkscape 1.3 in experimental, it would be nice if you could upload a newer version of inkscape-open-symbols to experimental too. Regards, Daniel
Bug#1068927: ITP: rust-event-listener-strategy -- block or poll on event_listener easily
On Sat, 13 Apr 2024 16:10:31 +0200 Jonas Smedegaard wrote: Package: wnpp > Severity: wishlist > Owner: Jonas Smedegaard > X-Debbugs-Cc: debian-de...@lists.debian.org > * Package name : rust-event-listener-strategy Version : 0.5.1 Upstream Contact: John Nunley * URL : https://github.com/smol-rs/event-listener-strategy * License : Apache-2.0 or Expat Programming Lang: Rust Description : block or poll on event_listener easily event-listener-strategy provides a strategy for using the event-listener crate in both blocking and non-blocking contexts. . One of the stand-out features of the event-listener crate is the ability to use it in both asynchronous and synchronous contexts. However, sometimes using it like this causes a lot of boilerplate to be duplicated. This crate aims to reduce that boilerplate by providing an EventListenerFuture trait that implements both blocking and non-blocking functionality. This package is needed for newer releases of src:rust-async-lock and src:rust-async-channel. It will be maintained in the collaborative Debian section of Salsa, at https://salsa.debian.org/debian/rust-event-listener-strategy Hi Jonas, I already packaged event-listener-strategy and it's in NEW currently. best, -- Matthias Geiger Debian Maintainer OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068794: sane-utils: (x)scanimage only works once, a second scan right after the first one fails
forwarded 1068794 https://gitlab.com/sane-project/backends/-/issues/742 thanks Hello Paul, many thanks. CU Jörg Am Freitag, dem 12.04.2024 um 19:22 +0200 schrieb Paul Cobbaut: > > > > On 4/12/24 18:55, Jörg Frings-Fürst wrote: > > > > Please contact the developers directly at [2]. > > Done. > They already had an issue for it. > https://gitlab.com/sane-project/backends/-/issues/742 > > Paul -- 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 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de 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#1060196: fixed in ghc 9.4.7-5
On Fri, 2024-04-12 at 22:35 +, Debian FTP Masters wrote:
>* Build unregisterised on powerpc (Closes: #1060196)
I am not 100% sure what happened, but this upload produced another
broken GHC compiler on powerpc. Lots of packages fail to build now
due to GHC segfaulting [1]:
Running dh_listpackages
libghc-splitmix-dev
libghc-splitmix-prof
libghc-splitmix-doc
-e: error: debian/hlibrary.setup build --builddir=dist-ghc died with signal 11
at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build
--builddir=dist-ghc died with sig"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm
line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build",
"--builddir=dist-ghc") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 656
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned
exit status 2
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=haskell-splitmix=powerpc=0.1.0.5-1%2Bb1=1713046430=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1068954: bookworm-pu: package libnvme/1.3-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Hi,
when scanning ("nvme list") some buggy NVMe ssds that don't like blocks
of less than 4096 bytes send to them, a buffer overflow happens.
Upstream fixed this in libnvme 1.7, I've cherry-picked this for
bookworm, attached is the full diff for review. Please let me know if I
can upload it to bookworm-pu.
Regards,
Danieldiff --git a/debian/changelog b/debian/changelog
index 2666b0a..d7cef38 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libnvme (1.3-1+deb12u1) bookworm; urgency=medium
+
+ * Uploading to bookworm.
+ * Cherry-picking upstream commits to fix buffer overflow during scanning
+devices that do not support sub-4k reads (Closes: #1054631).
+
+ -- Daniel Baumann Sun, 14 Apr 2024 08:57:21 +0200
+
libnvme (1.3-1) sid; urgency=medium
* Uploading to sid.
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..f31922e
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+upstream/0001-alloc-helper.patch
+upstream/0002-aligned-payloads.patch
diff --git a/debian/patches/upstream/0001-alloc-helper.patch b/debian/patches/upstream/0001-alloc-helper.patch
new file mode 100644
index 000..deafcae
--- /dev/null
+++ b/debian/patches/upstream/0001-alloc-helper.patch
@@ -0,0 +1,52 @@
+commit a2b8e52e46cfd888ac5a48d8ce632bd70a5caa93
+Author: Tomas Bzatek
+Date: Tue Oct 10 18:16:24 2023 +0200
+
+util: Introduce alloc helper with alignment support
+
+Similar to nvme-cli an alloc helper is needed for a couple
+of ioctls sent out during tree scan.
+
+Signed-off-by: Tomas Bzatek
+
+diff --git a/src/nvme/private.h b/src/nvme/private.h
+index 6fb9784a..ee9d738b 100644
+--- a/src/nvme/private.h
b/src/nvme/private.h
+@@ -182,6 +182,8 @@ nvme_ctrl_t __nvme_lookup_ctrl(nvme_subsystem_t s, const char *transport,
+ const char *host_iface, const char *trsvcid,
+ const char *subsysnqn, nvme_ctrl_t p);
+
++void *__nvme_alloc(size_t len);
++
+ #if (LOG_FUNCNAME == 1)
+ #define __nvme_log_func __func__
+ #else
+diff --git a/src/nvme/util.c b/src/nvme/util.c
+index 8fe094d5..20679685 100644
+--- a/src/nvme/util.c
b/src/nvme/util.c
+@@ -7,6 +7,7 @@
+ * Chaitanya Kulkarni
+ */
+
++#include
+ #include
+ #include
+ #include
+@@ -1058,3 +1059,15 @@ bool nvme_iface_primary_addr_matches(const struct ifaddrs *iface_list, const cha
+ }
+
+ #endif /* HAVE_NETDB */
++
++void *__nvme_alloc(size_t len)
++{
++ size_t _len = round_up(len, 0x1000);
++ void *p;
++
++ if (posix_memalign((void *), getpagesize(), _len))
++ return NULL;
++
++ memset(p, 0, _len);
++ return p;
++}
diff --git a/debian/patches/upstream/0002-aligned-payloads.patch b/debian/patches/upstream/0002-aligned-payloads.patch
new file mode 100644
index 000..8c514d0
--- /dev/null
+++ b/debian/patches/upstream/0002-aligned-payloads.patch
@@ -0,0 +1,60 @@
+commit 68c6ffb11d40a427fc1fd70ac2ac97fd01952913
+Author: Tomas Bzatek
+Date: Tue Oct 10 18:18:38 2023 +0200
+
+tree: Allocate aligned payloads for ns scan
+
+libnvme is actually doing some namespace identification
+during tree scan, leading to stack smash on some systems.
+
+Signed-off-by: Tomas Bzatek
+
+diff --git a/src/nvme/tree.c b/src/nvme/tree.c
+index 00cf96f7..5636aa18 100644
+--- a/src/nvme/tree.c
b/src/nvme/tree.c
+@@ -2404,26 +2404,33 @@ static void nvme_ns_parse_descriptors(struct nvme_ns *n,
+
+ static int nvme_ns_init(struct nvme_ns *n)
+ {
+- struct nvme_id_ns ns = { };
+- uint8_t buffer[NVME_IDENTIFY_DATA_SIZE] = { };
+- struct nvme_ns_id_desc *descs = (void *)buffer;
++ struct nvme_id_ns *ns;
++ struct nvme_ns_id_desc *descs;
+ uint8_t flbas;
+ int ret;
+
+- ret = nvme_ns_identify(n, );
+- if (ret)
++ ns = __nvme_alloc(sizeof(*ns));
++ if (!ns)
++ return 0;
++ ret = nvme_ns_identify(n, ns);
++ if (ret) {
++ free(ns);
+ return ret;
++ }
+
+- nvme_id_ns_flbas_to_lbaf_inuse(ns.flbas, );
+- n->lba_shift = ns.lbaf[flbas].ds;
++ nvme_id_ns_flbas_to_lbaf_inuse(ns->flbas, );
++ n->lba_shift = ns->lbaf[flbas].ds;
+ n->lba_size = 1 << n->lba_shift;
+- n->lba_count = le64_to_cpu(ns.nsze);
+- n->lba_util = le64_to_cpu(ns.nuse);
+- n->meta_size = le16_to_cpu(ns.lbaf[flbas].ms);
++ n->lba_count = le64_to_cpu(ns->nsze);
++ n->lba_util = le64_to_cpu(ns->nuse);
++ n->meta_size = le16_to_cpu(ns->lbaf[flbas].ms);
+
+- if (!nvme_ns_identify_descs(n, descs))
++ descs = __nvme_alloc(NVME_IDENTIFY_DATA_SIZE);
++ if (descs && !nvme_ns_identify_descs(n, descs))
+ nvme_ns_parse_descriptors(n, descs);
+
++ free(ns);
++ free(descs);
+ return 0;
+ }
+
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, On 14-04-2024 5:14 a.m., 陈 晟祺 wrote: When using non-ramdisk tmpdir (/var/tmp) and some large tests skipped [1], the tests would run with 2 core + 4GB memory + ~10GB disk space. I also tried 2GB / 3GB, and both will be interrupted by OOM killer. So, let's settle on 2+4 for now. That sounds like a value we could very reasonably support. I'll configure our setup for that. I would have aron to review & upload a new version, then we can test on debci infra and see whether it solves the problem. Ack. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068953: new upstream (10.0)
Package: frr Severity: wishlist Hi David and Ondrej, it would be nice if you could upload the newly released frr version. If you need/want help, I'm happy to do so, just let me know. Regards, Daniel
Bug#1067450: ttyd: does not start
close 1067450 thanks Hi, On 3/21/24 18:03, Daniel wrote: Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: lws_create_context: failed to load evlib_uv Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: libwebsockets context creation failed Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Main process exited, code=exited, status=1/FAILURE Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Failed with result 'exit-code'. this is a stray issue because of the t64 migration when you haven't fully updated your system. on a minimal, up2date sid ttyd works reproducibly fine. Regards, Daniel
Bug#1068952: new upstream required for frr
Package: libyang2 Severity: wishlist Hi Ondrej, it would be nice if you could upload libyang2 >= 2.1.128 as the new frr release requires that. If you need/want help, I'm happy to do so, just let me know. Regards, Daniel
Bug#1068951: new upstream (6.x)
Package: knot-resolver Severity: wishlist Hi, it would be nice if you could upload knot-resolver 6.x to experimental. Regards, Daniel
Bug#1068950: http_loadtime multiple target / escapeUri regression
Package: munin-plugins-core
Version: 2.0.73-1
Hi,
This used to work while there was support for only one target:
[http_loadtime]
env.target http://localhost/?munin_http_loadtime=foo-front-60
The RRD value was just a simple string and it didn't matter what the content
of the target URL was. With the multiple target feature, however, this
returns:
% sudo munin-run http_loadtime
http___localhost_?munin_http_loadtime=foo_front_60.value 0.0946937
Which in turn is broken in Munin - it would create the RRD file for it,
the value would always be critical, and munin-cgi-graph complains like
this:
2024/04/14 05:19:49 [RRD ERROR] Unable to graph
/var/lib/munin/cgi-tmp/munin-cgi-graph/bar.baz.com/foo-front-1.bar.baz.com/http_loadtime-year.png
: foo_front_60_warning is not a vname nor a number
It sounds like the non-alphabetic characters that are included in
the query string bother it, as they aren't escaped by:
escapeUri() {
echo "$1" | sed 's/[:/.-]/_/g'
}
Please fix it. TIA.
--
Josip Rodin
Bug#1068949: libfinance-quote-perl: Quotes failing in Gnucash
Package: libfinance-quote-perl Version: 1.59-1 Severity: normal Dear Maintainer, I ran the Tools > Price Database command in Gnucash using the "Yahoo as JSON" source and got the following response: Unable to retrieve quotes for these items. In the past, this error was resolved by editing /usr/share/perl5/Finance/Quote/YahooJSON.pm. However, this time, I could not find any solutions online. I tried upgrading from version 1.54 (bookworm) to 1.59 (trixie), but that did not resolve the issue either. I hope you can do a better job finding a valid URL for the Yahoo quotes. Alternatively, if you could recommend another, more stable, source for retrieving mutual fund quotes, that would be great too. Thanks! -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (10, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 libfinance-quote-perl depends on: ii libcgi-pm-perl 4.55-1 ii libdatetime-format-strptime-perl 1.7900-1 ii libdatetime-perl 2:1.59-1 pn libencode-perl ii libhtml-parser-perl3.81-1 ii libhtml-tableextract-perl 2.15-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libhtml-tree-perl 5.07-3 ii libhtml-treebuilder-xpath-perl 0.14-1.1 ii libhttp-cookiejar-perl 0.014-1 ii libhttp-cookies-perl 6.10-1 ii libhttp-message-perl 6.44-1 ii libio-string-perl 1.08-4 ii libjson-parse-perl 0.62-1+b1 ii libjson-perl 4.1-1 ii liblwp-protocol-https-perl 6.10-1 ii libreadonly-perl 2.050-3 ii libscalar-list-utils-perl 1:1.63-1+b1 ii libspreadsheet-xlsx-perl 0.17-1 ii libstring-util-perl1.34-2 ii libtext-template-perl 1.61-1 ii libtry-tiny-perl 0.31-2 ii liburi-perl5.17-1 ii libweb-scraper-perl0.38-2 ii libwww-perl6.68-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii perl [libio-compress-perl] 5.36.0-7+deb12u1 ii perl-base [libscalar-list-utils-perl] 5.36.0-7+deb12u1 libfinance-quote-perl recommends no packages. libfinance-quote-perl suggests no packages. -- no debconf information
Bug#981276: pexec FTCBFS: help2man
[Helmut Grohne 2021-01-28] > pexec fails to cross build from source, because it uses help2man. Given > that pexec has very little dependencies, we can add a native build pass > for generating the manual page before performing the cross build. Please > consider applying the attached patch. I suspect a better fix is to convert the package to use 'dh' first. I tried the trivial conversion but it did not work because the configure script do not understand --runstatedir=/run. I just converted the packaging to git and made it available in https://salsa.debian.org/debian/pexec > if you want to update the package yourself. -- Happy hacking Petter Reinholdtsen
