Re: Bug#1072521: fakeroot hangs on some commands with faked-sysv using 100% CPU
Control: found 1072521 fakeroot/1.25.3-1.1 Control: found 1072521 fakeroot/1.31-1.2 (CCing d-devel@ for awareness) Hi Clint, On Wed, Jun 05, 2024 at 07:54:07PM +, Debian Bug Tracking System wrote: > fakeroot (1.35-1) unstable; urgency=medium > . >* New upstream version. > - Use close_range when available. closes: #1072521. thanks for fixing this (fd closing with "unlimited" range) in unstable. The same problem occurs in build(d) chroots for stable (bookworm) and older, if the host is running trixie or newer. As a result, basically everyone preparing updates for bookworm is affected, when building them on an unstable/trixie host. It would be great if the fix could be backported to bookworm and maybe bullseye. Aurelien Jarno mentioned that the buildds will needs this too. Do you have the bandwidth to drive this as a stable-update sometime soon? Many thanks, Chris
Bug#1086153: ITP: virtualbmc -- virtual BMC for controlling virtual machines using IPMI commands
Package: wnpp Severity: wishlist Owner: harry-c...@outlook.com X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: virtualbmc Version : 3.1.0 * URL : https://github.com/openstack/virtualbmc * License : Apache-2.0 Programming Lang: Python Description : virtual BMC for controlling virtual machines using IPMI commands The VirtualBMC tool simulates a Baseboard Management Controller (BMC) by exposing IPMI responder to the network and talking to libvirt at the host vBMC is running at to manipulate virtual machines which pretend to be bare metal servers. This is a pure Python package. And it could be used along with libvirt. I plan to maintain this package within the python team. Thanks, Shengqi Chen
Re: Bug#1072521: fakeroot hangs on some commands with faked-sysv using 100% CPU
On Sun, Oct 27, 2024 at 04:32:57PM +0100, Chris Hofstaedtler wrote: > Do you have the bandwidth to drive this as a stable-update sometime > soon? Probably not within the next two weeks. https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/2068702 might be relevant as well if any very old kernels may be involved.
Re: Most optimal way to import NMU into existing git-builpackage repository?
Hi! > > Seems this is still the most optimal way to ensure git is correct: > > > >gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid > > > > Also, dgit pull can be used to get the latest source automatically, but > > unfortunately those > > git commits are made as a custom "Debian as a git repo" representation, and > > is not > > compatible with using CI testing and code review before upload in the way > > many of us > > are doing on Salsa currently. > > 'dgit pull' integrates the NMU automatically, when it can. It doesn't > just fetch the source. I don't follow how it's different from 'gbp > import-dsc'. Could you say more? In a gbp checkout of g...@salsa.debian.org:debian/j4-dmenu-desktop.git, how would you invoke 'dgit pull sid' to import the NMU? Without any parameters, it will create branch 'dgit/sid' which has unrelated history and patches are applied and nothing can be merged or cherry-picked to the git-buildpackage master branch. Perhaps I am just missing something on how this should work, or perhaps https://manpages.debian.org/unstable/dgit/dgit-maint-gbp.7.en.html#INCORPORATING_NMUS implies the functionality isn't yet there?
Re: Most optimal way to import NMU into existing git-builpackage repository?
Hello, On Sun 27 Oct 2024 at 05:29pm GMT, Otto Kekäläinen wrote: > Hi! > >> > Seems this is still the most optimal way to ensure git is correct: >> > >> >gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid >> > >> > Also, dgit pull can be used to get the latest source automatically, but >> > unfortunately those >> > git commits are made as a custom "Debian as a git repo" representation, >> > and is not >> > compatible with using CI testing and code review before upload in the way >> > many of us >> > are doing on Salsa currently. >> >> 'dgit pull' integrates the NMU automatically, when it can. It doesn't >> just fetch the source. I don't follow how it's different from 'gbp >> import-dsc'. Could you say more? > > In a gbp checkout of g...@salsa.debian.org:debian/j4-dmenu-desktop.git, > how would you invoke 'dgit pull sid' to import the NMU? > > Without any parameters, it will create branch 'dgit/sid' which has > unrelated history and patches are applied and nothing can be merged or > cherry-picked to the git-buildpackage master branch. Perhaps I am just > missing something on how this should work, or perhaps > https://manpages.debian.org/unstable/dgit/dgit-maint-gbp.7.en.html#INCORPORATING_NMUS > implies the functionality isn't yet there? This is one of the cases where it can't do it completely automatically, but a manual merge may be possible. -- Sean Whitton
Re: Most optimal way to import NMU into existing git-builpackage repository?
Hello, On Sun 27 Oct 2024 at 05:29pm GMT, Otto Kekäläinen wrote: > Hi! > >> > Seems this is still the most optimal way to ensure git is correct: >> > >> >gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid >> > >> > Also, dgit pull can be used to get the latest source automatically, but >> > unfortunately those >> > git commits are made as a custom "Debian as a git repo" representation, >> > and is not >> > compatible with using CI testing and code review before upload in the way >> > many of us >> > are doing on Salsa currently. >> >> 'dgit pull' integrates the NMU automatically, when it can. It doesn't >> just fetch the source. I don't follow how it's different from 'gbp >> import-dsc'. Could you say more? > > In a gbp checkout of g...@salsa.debian.org:debian/j4-dmenu-desktop.git, > how would you invoke 'dgit pull sid' to import the NMU? > > Without any parameters, it will create branch 'dgit/sid' which has > unrelated history and patches are applied and nothing can be merged or > cherry-picked to the git-buildpackage master branch. Perhaps I am just > missing something on how this should work, or perhaps > https://manpages.debian.org/unstable/dgit/dgit-maint-gbp.7.en.html#INCORPORATING_NMUS > implies the functionality isn't yet there? Ah, I was thinking that you had already been using 'dgit --gbp push' to upload the package. In that case the histories would be related, just with some additional commits on top, and a manual merge would be possible. -- Sean Whitton
Bug#1086139: ITP: golang-github-c2sp-cctv -- Community Cryptography Test Vectors
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-c2sp-cctv Version : 0.0~git20240306.3ec4d71-1 Upstream Author : Community Cryptography Specification Project * URL : https://github.com/C2SP/CCTV * License : https://github.com/C2SP/CCTV/issues/14 Programming Lang: Go Description : Community Cryptography Test Vectors The Community Cryptography Test Vectors . CCTV is an experiment, part of the Community Cryptography Specification Project (https://c2sp.org), in test vector collection and reuse. . All cryptography-related test vectors are welcome, and projects are encouraged to reuse them and contribute back any new vectors they generate. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-c2sp-cctv /Simon signature.asc Description: PGP signature
