Re: SONAME bumps (transitions) always via experimental
On Thu, Jan 05, 2023 at 02:29:42PM +0100, Sebastian Ramacher wrote: > > From recent memory and assuming there are no issues with d/copyright, > binary-NEW uploads to experimental have been processed swiftly. This is also my experience that binary-NEW uploads for library SONAME bumps are handled very fast, (also) in experimental. (Some time ago sponsored such a package, at is was even accepted within an hour :)) -- tobi
Bug#1028050: ITP: pyqt6-charts -- Python 3 bindings for Qt6's Charts module
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyqt6-charts Version : 6.4.0 Upstream Author : Riverbank Computing * URL : https://riverbankcomputing.com/software/pyqtchart/ * License : GPL-3 Programming Lang: C++ Description : Python 3 bindings for Qt6's Charts module The Charts module of PyQt6 provides widgets and utility classes for chart rendering in a PyQt6 application. This will be maintained in the Debian Python team.
Re: SONAME bumps (transitions) always via experimental
On Thu, 5 Jan 2023, Simon McVittie wrote: 3. experimental packages appear in red on https://ftp-master.debian.org/new.html, which makes me wonder whether that reflects those packages being de-prioritized, but perhaps I'm reading too much into that? Yes, you do. There is no difference between processing of packages in experimental or unstable. Thorsten
Multi-host networking software, autopkgtests
I have two packages which do vpn-like things (hippotat, secnet) which
I want to add autopkgtests for. The two packages have similar kinds
of requirements for their tests.
Ideally, I would:
* Somehow have two test nodes ("hosts")
* With their own /etc and /var (or, relevant parts thereof,
but it would be better to have two completely separate hosts
so I can test that the client package works even if you don't
have the server package installed, etc.)
* With their own networking setups
* With some kind of network connection between them
All of this would have to be set up from the autopkgtest test script,
which would need to be able to run commands in either node.
And ideally it would be easy to run the tests from my normal dev
environment too (without having to, say, install docker).
Ideally it would let me properly test the service startup (init
scripts, etc.) too for a full integration test, but if necessary that
can be done in a separate one-host test, since the software will
*start up* just fine even if it doesn't have a peer.
I guess I could do something ad-hoc with mount and network namespaces
and overlay filesystems. But it feels like this problem must have
been solved already ?
The part I'm not sure how to do ad-hoc is dependency management. An
autopkgtest ought to use the packages desired by the autopkgtest test
runner. So far the best option I can think of is to declare in the
autopkgtest control file *all* the relevant packages needed for any of
the two test nodes and the setup scripts; in each node, unshare the
namespaces enough that I can run apt; manually uninstall the
not-needed dependencies, and run apt autoremove.
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.
Re: Multi-host networking software, autopkgtests
Hi Ian
On 06-01-2023 14:09, Ian Jackson wrote:
I have two packages which do vpn-like things (hippotat, secnet) which
I want to add autopkgtests for. The two packages have similar kinds
of requirements for their tests.
Ideally, I would:
* Somehow have two test nodes ("hosts")
* With their own /etc and /var (or, relevant parts thereof,
but it would be better to have two completely separate hosts
so I can test that the client package works even if you don't
have the server package installed, etc.)
* With their own networking setups
* With some kind of network connection between them
All of this would have to be set up from the autopkgtest test script,
which would need to be able to run commands in either node.
And ideally it would be easy to run the tests from my normal dev
environment too (without having to, say, install docker).
Ideally it would let me properly test the service startup (init
scripts, etc.) too for a full integration test, but if necessary that
can be done in a separate one-host test, since the software will
*start up* just fine even if it doesn't have a peer.
I guess I could do something ad-hoc with mount and network namespaces
and overlay filesystems. But it feels like this problem must have
been solved already ?
The part I'm not sure how to do ad-hoc is dependency management. An
autopkgtest ought to use the packages desired by the autopkgtest test
runner. So far the best option I can think of is to declare in the
autopkgtest control file *all* the relevant packages needed for any of
the two test nodes and the setup scripts; in each node, unshare the
namespaces enough that I can run apt; manually uninstall the
not-needed dependencies, and run apt autoremove.
I guess this is best discussed in https://bugs.debian.org/908274 (added
in the To)? Maybe with Wouter and other interested parties?
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Re: Multi-host networking software, autopkgtests
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...
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.
Re: SONAME bumps (transitions) always via experimental
Hello, On Thu 05 Jan 2023 at 01:13PM GMT, Simon McVittie wrote: > 3. If the ftp team prioritize NEW review of unstable packages higher than >experimental packages (do they?) then that would be >counter-productive under the proposed policy, and they'd have to >stop doing that (and perhaps prioritize binary-NEW higher than >source-NEW, instead). experimental packages appear in red on >https://ftp-master.debian.org/new.html, which makes me wonder whether >that reflects those packages being de-prioritized, but perhaps I'm >reading too much into that? The scripts prioritise binary-NEW over source-NEW by default, though I override this with a shell alias myself. We don't pay attention to unstable vs. experimental. -- Sean Whitton signature.asc Description: PGP signature
Re: propose: provide "docker" package as docker, not wmdocker
Hideki Yamane writes ("propose: provide "docker" package as docker, not
wmdocker"):
> I'd like to propose wmdocker package would rename its source
> package from docker to wmdocker, and then docker.io package
> provides docker binary package and transitional docker.io package.
Do we have a wiki page which gives a procedure for renaming a source
package ?
Source package renames are rather disruptive because we key a lot of
stuff off the source package name. At least bugs need to be
reorganised, and possibly other things. To reuse a source package
name and then upload the new package with dgit, it's necessary to ask
a dgit repo admin to do special by hand adjustments. etc.
This all seems like it could do with a checklist that we can at least
add things to each time we discover a brokenness we should have
avoided...
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.
