Bug#1028120: ...
Package: wnpp Severity: wishlist Owner: Israel Galadima X-Debbugs-CC: debian-devel@lists.debian.org * Package name : node-xregexp Version : 3.1.1 Upstream Author : Steven Levithan * URL : http://xregexp.com/ * License : Expat Programming Lang: JavaScript Description : Extended JavaScript regular expressions XRegExp provides augmented (and extensible) JavaScript regular expressions beyond what is natively supported. This package is part of my effort to package corepack for Debian. Package will be maintained by the Debian JavaScript Team. OpenPGP_0x3679ECB87B7CEC0C.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Multi-host networking software, autopkgtests
Hi Ian,
On Fri, Jan 06, 2023 at 04:59:58PM +, Ian Jackson wrote:
> Paul Gevers writes ("Re: Multi-host networking software, autopkgtests"):
> > I guess this is best discussed in https://bugs.debian.org/908274 (added
> > in the To)? Maybe with Wouter and other interested parties?
>
> Hmmm. Well, a way of doing this "officially" in autopkgtest would be
> nice. But:
>
> Think such an "official" thing ought to allow the specification of
> different dependencies for the different hosts in the test. And I
> don't much like the mini-DSL suggestion. Maybe it would be better to
> offer the test script an adt virt server interface to control the
> "other" hosts.
>
> This all seems very complex. I definitely want to have something
> working before something like that could exist. Also, I think it
> would be a good idea to do something ad-hoc, ideally in a number of
> packages, to gain experience so we know what shape the "official"
> thing ought to be.
>
> I think therefore that I need to pursue some kind of within-testbed
> nesting, as an interim approach at the very least. I was hoping that
> someone else had solved (part of) this problem already...
Unfortunately not.
We also had a discussion during the "autopkgtest office hours" session
during debconf21[1], where an alternate method (that would be slightly
easier to implement) was proposed: to have an autopkgtest helper command
that allows you to easily create and run a Debian VM for the host
architecture, and run stuff on it. This might be a bit easier to
implement than the dsl in the proposal.
[1]
https://debconf-video-team.pages.debian.net/videoplayer/#/event/2021/debconf21?video=debconf21-82-autopkgtest-office-hours.webm&start=2028
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Multi-host networking software, autopkgtests
Hi, Quoting Ian Jackson (2023-01-06 17:59:58) > This all seems very complex. I definitely want to have something working > before something like that could exist. Also, I think it would be a good > idea to do something ad-hoc, ideally in a number of packages, to gain > experience so we know what shape the "official" thing ought to be. > > I think therefore that I need to pursue some kind of within-testbed > nesting, as an interim approach at the very least. I was hoping that > someone else had solved (part of) this problem already... there already exist a number of autopkgtest scripts that start a qemu virtual machine and then run some script inside of it by connecting to it via ssh. Maybe this can be helpful to you for now: https://sources.debian.org/src/dropbear/2022.83-1/debian/tests/remote-unlocking/?hl=112#L137 https://sources.debian.org/src/sbuild/0.85.0/debian/tests/unshare-qemuwrapper/?hl=206#L206 https://sources.debian.org/src/cryptsetup/2%3A2.6.0-2/debian/tests/utils/cryptroot-common/#L505 Thanks! cheers, josch
Re: Multi-host networking software, autopkgtests
Johannes Schauer Marin Rodrigues writes ("Re: Multi-host networking software,
autopkgtests"):
> there already exist a number of autopkgtest scripts that start a qemu virtual
> machine and then run some script inside of it by connecting to it via ssh.
> Maybe this can be helpful to you for now:
Thanks. I considered this but it seemed overkill (and it won't
inherit the dependency versions selected by autopkgtest).
For now I'm working on an adhoc thing that uses
- Restrictions: needs-root
- overlayfs to make an editable clone of the fs provided by autopkgtest
- chroot
- ip netns
- apt-mark and apt-autoremove to get rid of unwanted deps
It's not particularly pretty but it's not much code and I feel I'm
making progress. I'll report back here when I've succeeded - or
failed :-).
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1028131: ITP: libretro-nestopia -- libretro wrapper for Nestopia
Package: wnpp Severity: wishlist Owner: Sébastien Villemot X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libretro-nestopia Version : 1.52.0+20221230.gitdd78611 Upstream Contact: libre...@gmail.com * URL : https://github.com/libretro/nestopia * License : GPL-2+ Programming Lang: C++ Description : libretro wrapper for Nestopia Nestopia is a Nintendo Entertainment System (NES) / Famicom emulator, with a high compatibility rate. This packages provides a wrapper allowing the Nestopia engine to be used with libretro frontends such as RetroArch and GNOME Games. The libretro-nestopia binary package used to be shipped by the nestopia source package. But this is no longer the case, since the libretro backend maintenance has moved elsewhere, hence the need for a new source package. his package will be maintained under the umbrella of the Debian Games Team.
Re: Multi-host networking software, autopkgtests
Quoting Ian Jackson (2023-01-07 16:35:17) > Thanks. I considered this but it seemed overkill maybe > (and it won't inherit the dependency versions selected by autopkgtest). Yes it will. When creating the chroot for the virtual machine, you use the apt sources configured by the autopkgtest runner: https://sources.debian.org/src/sbuild/0.85.0/debian/tests/unshare-qemuwrapper/#L62 or here: https://sources.debian.org/src/dropbear/2022.83-1/debian/tests/remote-unlocking/?hl=80#L80
Bug#1028151: ITP: python-pyproject-parser -- Parser for pyproject.toml
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-pyproject-parser Version : 0.7.0 Upstream Contact: Dominic Davis-Foste * URL : https://github.com/repo-helper/pyproject-parser * License : MIT/expat Programming Lang: Python Description : Parser for pyproject.toml This package is an essential dependency for the python-coincidence package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481 Observation: python-coincidence is required to run all tests in these packages: * python-dom-toml * python-consolekitm * python-dist-meta * python-shippinglabel * python-apeye * python-apeye-core * domdf-python-tools * python-shippinglabel All under ITPs.
Re: setting sysctl net.ipv4.ping_group_range
On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote: > On Jan 03, Adam Borowski wrote: > > Debian's default sysctl settings should reside in procps (as it owns > > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated > > package. > Nowadays systemd is a source of common sysctl settings among different > distributions. Debian still supports other init systems in the archive besides systemd. Should ping fail to run on a Debian system that is not using systemd? We also recently ran into a bug with systemd in Ubuntu because the "common sysctl settings among different distributions" that they had added clobbered settings that had been shipped for years already in the Ubuntu procps package. No thank you. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038 What would really be a great place for shipping common sysctl settings among different distributions would be in the Linux kernel, instead of diverging from the kernel defaults in userspace and representing this as "common". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1028182: ITP: throttler -- Provides rate-limiting features using asyncio
Package: wnpp Severity: wishlist Owner: Diane Trout X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: throttler Version : 1.22 Upstream Contact: Ramzan Bekbulatov * URL : https://github.com/uburuntu/throttler * License : MIT/expat Programming Lang: Python Description : Provides rate-limiting features using asyncio Zero-dependency Python package for easy throttling with asyncio support. Originally snakemake was using a different package to provide a similar rate limiting feature called ratelimiter. However the last release for ratelimiter was in 2017, and the package contains syntax that no longer works with Python 3.11. So in snakemake 7.18.2 they switched to using this package instead. https://snakemake.readthedocs.io/en/stable/project_info/history.html#id5 This is a small package I intend to add to the python modules team. Diane
Bug#1028183: ITP: vim-eblook -- EPWING/Electric Dictionary interface for vim
Package: wnpp Severity: wishlist Owner: Yukiharu YABUKI X-Debbugs-Cc: debian-devel@lists.debian.org, yyab...@debian.org * Package name: vim-eblook Version : 1.2.3 Upstream Contact: KIHARA Hideto * URL : https://github.com/deton/eblook.vim * License : MIT Programming Lang: vim script Description : EPWING/Electric Dictionary interface for vim eblook provide a simple and unitfied interface for vim . like a emacs's lookup-el package.
