Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 04:50:39PM +0200, Andreas Tille wrote: Hi, On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: I know +1 postings are not really welcome. I've been looking for an excuse to write slightly more than "+1" (to Simon or Phil's messages, in particular), but "+1" is substantively my main feeling However, in this case: I never really understood why we need these codenames. IMHO some marketing thingy which I tend to ignore. I fully agree with Phil that these can lead to confusion and the usage should be restricted to not so important use case. One thing that the code names give is colour. When I was (briefly) involved in debian-desktop stuff, the artists and suchlike enjoyed working on themes that riffed on the codename. I remember in particular being excited about what could be done with "Etch" and the swirl logo. So I would like to see the code names continue to exist, but I agree entirely that they should be reduced in importance and we should lead with the version number. We could consider bumping the version number up to match the current C.E. year, abbreviated (e.g. "19") in common with what Ubuntu do, if we wanted to increase the remember-or-computability of the current version. I do like how easy it is to look at an existing release number and be able to establish how old it is (aah, 18.04, was released in April 2018) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:07:23PM +, Andrew M.A. Cater wrote: Think again about why we have release names at all: Debian 1.0 never happened because somebody packaged a pre-release semi-broken version as Debian 1.0 on their CDs. At that point, Debian chose to also use codenames to refer to releases in progress. Raspbian have released "Buster" before we have. Codenames have not prevented this happening. For me, I like the idea of being able to use the codename as soon as it is usable - that means that the distro tracks from unstable -> testing -> stable without a change. This would work with version numbers instead of code names. Pinning to stable is a silly idea in /etc/apt/sources.list - as soon as a release state changes - so if I have "stable" as my referent with 9.9, there'll be chaos as Buster is released and a forced upgrade This can be prevented by pinning to a version-number-name as well as code names. Having stable, testing, unstable as labels does mean I have to explain more to colleagues but it also means that I can confidently tell my colleagues: "Use the latest released stable Debian version if you want longer term support" They still have to resolve what that means, right? You don't want them putting "stable" in pinning etc. for the reason you list above. So, they still have to map stable → codename, and could just as easily map stable → version number. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:15:49PM +0200, Alf Gaida wrote: Only a last thought: Didn't we have really important problems to solve? It might be only me, but i see the discussion as a minor variation of bike shedding. It may not be important to you, but it's evidently important to some people. I think bike shedding is a mischaracterisation of this discussion, because a) the problems that occur with the current arrangement have been clearly identified and are substantive, not trivial; b) the ratio of proposed alternatives to participants is not near 1:1. To sum it up: Some people like codenames, some not, same for numbers - the real question is: Does it really matters? This is a bad summary. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
Michael Stone writes ("Re: getting rid of "testing""):
> On Wed, Jun 26, 2019 at 01:29:44PM -0300, Antonio Terceiro wrote:
> >As a data point, having "stable" and "testing" stay around is very
> >useful for CI purposes. For example on ci.debian.net all our setup uses
> >"stable" and "testing" instead of the release codenames, and it's useful
> >to have a system that does not need manual intervention when the meaning
> >of "stable" and "testing" changes.
>
> Ideally, a mapping of what is currently "stable" or "testing" or at
> other levels of support would be easy to determine programatically, so
> you could avoid manual intervention for those cases and make it easy to
> support other cases without having to either manually configure things
> *or* make a bunch of new ugly symlinks.
It is available via the ftpmaster API service, and by reading symlinks
in archive mirrors. I think the idea of having this information in a
.deb too (ideally kept up to date in all in-support releases,
including LTS) is a good one.
But that doesn't mean we shouldn't have version aliases.
Stepping back a bit:
Can we have a comment from ftpmaster on their view of the rough
consensus here? I think a Last Call (time-bounded) would be good.
(I really liked the approach Sam took with the dh discussion.)
When an ftpmaster decision has been made, we can close this thread
(which is starting to become a distraction).
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#931174: ITP: libjs-scribl -- HTML5 canvas genomics graphic library
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: libjs-scribl * URL : http://chmille4.github.io/Scribl/ * License : MIT Programming Lang: JavaScript Description : HTML5 canvas genomics graphic library To be team maintained on salsa.d.o/med-team/libjs-scribl
Re: getting rid of "testing"
On Thu, 27 Jun 2019 at 12:04:39 +0100, Ian Jackson wrote: > [What is currently stable, etc.] is available via the ftpmaster API > service, and by reading symlinks > in archive mirrors. I think the idea of having this information in a > .deb too (ideally kept up to date in all in-support releases, > including LTS) is a good one. distro-info-data.deb has this information for Debian and Ubuntu, in a CSV file. It has convenience bindings for Perl, Python and CLI, and is also used by recent versions of Debian's implementation of lsb-release. It doesn't currently get an exemption from (old)stable releases' stability policies, but the data is in src:distro-info-data, separated from the convenience bindings in src:distro-info, presumably so that it could get updated more often if that was felt to be important. smcv
Re: getting rid of "testing"
> "Ian" == Ian Jackson writes: Ian> Stepping back a bit: Ian> Can we have a comment from ftpmaster on their view of the rough Ian> consensus here? I think a Last Call (time-bounded) would be Ian> good. (I really liked the approach Sam took with the dh Ian> discussion.) Seconded. Personally, speaking very much as an individual, I'd appreciate it if Ansgar were to make a consensus call here as the developer who started the discussion. --Sam
Uninformative hyperlink in O: (package orphaning) bug reports
Dear -devel list, (Please forward this email to proper mailing lists if there's other lists that this email would suit in better.) I noticed that for all bug reports that orphan a package in Debian, a semi- standard paragraph of words will be provided like this: ...Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly However, https://www.debian.org/devel/wnpp/#howto-o provides almost zero information for an enthusiast that want to adopt the package, i.e. there's no detailed instruction on how to actually upload a package for a person not quite familiar with Debian's packaging workflow. I'd suggest some kind of rewording on the website given that this link has been posted everywhere in different BTS bug reports. Including a link to https://mentors.debian.net/intro-maintainers might be a good idea. Anyway any kind of improvement would be appreciated. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 01:11:09PM +0500, Andrey Rahmatullin wrote: > On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: > > > Related to that I would like to be able to write something like > > > deb http://deb.debian.org/debian debian11 main > > > deb http://security.debian.org/debian-security debian11-security main > > > in sources.list as codenames confuse people. > > > > Can you please elaborate on the "confuse people"? > I guess only (most?) Debian contributors and hardcore Debian users > remember the order of the codenames and their mappings to current > stable/oldstable/testing and to numeric versions. If even that. Potato was followed by sarge, but I think there was something in between (although I'm not sure). There's an etch somewhere, and a lenny. But what were the orderings again? I honestly don't remember. Yes please, let's use debian11 in the URL somewhere. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Work-needing packages report for Jun 28, 2019
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1434 (new: 0) Total number of packages offered up for adoption: 157 (new: 0) Total number of packages requested help for: 55 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 1434 packages are orphaned. See https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 157 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 939 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker Installations reported by Popcon: 1186 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 2832 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 682 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 535 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1814 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 807 days ago Description: Rust package manager Reverse Depends: cargo-vendor dh-cargo Installations reported by Popcon: 1045 Bug Report URL: https://bugs.debian.org/860116 cyrus-sasl2 (#799864), requested 1373 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-legacy-tools 389-ds-base-libs adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (113 more omitted) Installations reported by Popcon: 194209 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1077 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core Installations reported by Popcon: 55291 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 1762 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 9363 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1367 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero autodeb-worker brz-debian bzr-builddeb customdeb debci debian-builder (31 more omitted) Installations reported by Popcon: 12315 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 285 days ago Description: Linux container runtime Reverse Depends: golang-docker-dev golang-github-fsouza-go-dockerclient-dev golang-github-google-cadvisor-dev golang-github-samalba-dockerclient-dev kubernetes-node subuser whalebuilder Installations reported by Popcon: 1729 Bug Report URL: https://bugs.debian.org/908868 ed (#886643), requested 535 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn Installations reported by Popcon: 17238 Bug Report URL: https://bugs.debian.org/886643 ejabberd (#767874), requested 1697 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 490 Bug Report URL: https://bugs.debian.org/767874 fbcat (#565156), requested 3452 days ago Description: framebuffer grabber Installations reported by Popcon: 196 Bug Report URL: https://bugs.debian.org/565156 fgetty (#823061), requested 1153 days ago Description: console-only getty & login (issue with nis) Installations reported by Popcon: 719 Bug Report URL: https://bugs.debian.org/823061 frama-c (#907946), requested 296 days ago Description: Platform dedicated to the analysis of source code written in C Installations reported by Popcon: 83 Bug Report URL: https://bugs.debian.o
Getting rid of codenames (Was: getting rid of "testing")
How about getting rid of codenames altogether? Like we use unstable for unstable, experimental for experimental as it already is, no testing and buster but debian11, debian12, etc. Although it is eliminating some funs but it is much more predictable and simple to remember. I also confused squeeze with stretch. Yao Wei (This email is sent from a phone; sorry for HTML email if it happens.) > On Jun 28, 2019, at 04:17, Wouter Verhelst wrote: > > On Tue, Jun 25, 2019 at 01:11:09PM +0500, Andrey Rahmatullin wrote: >> On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: Related to that I would like to be able to write something like deb http://deb.debian.org/debian debian11 main deb http://security.debian.org/debian-security debian11-security main in sources.list as codenames confuse people. >>> >>> Can you please elaborate on the "confuse people"? >> I guess only (most?) Debian contributors and hardcore Debian users >> remember the order of the codenames and their mappings to current >> stable/oldstable/testing and to numeric versions. > > If even that. > > Potato was followed by sarge, but I think there was something in between > (although I'm not sure). There's an etch somewhere, and a lenny. > > But what were the orderings again? I honestly don't remember. > > Yes please, let's use debian11 in the URL somewhere. > > -- > To the thief who stole my anti-depressants: I hope you're happy > > -- seen somewhere on the Internet on a photo of a billboard >
Re: getting rid of "testing"
On Thu, Jun 27, 2019 at 10:16:33PM +0200, Wouter Verhelst wrote: > Yes please, let's use debian11 in the URL somewhere. Because debian11 is such a buzz... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This ⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project. ⠈⠳⣄
Bug#931200: ITP: python3-aiorwlock -- Synchronization primitive RWLock for asyncio
Package: wnpp Severity: wishlist Owner: William Grzybowski * Package name: aiorwlock Version : 0.6.0 Upstream Author : Andrew Svetlov * URL : https://github.com/aio-libs/aiorwlock * License : Apache 2.0 Programming Lang: Python Description : Synchronization primitive RWLock for asyncio Read write lock for asyncio. A RWLock maintains a pair of associated locks, one for read-only operations and one for writing. The read lock may be held simultaneously by multiple reader tasks, so long as there are no writers. The write lock is exclusive. This is an useful python to use with asyncio, may be useful for many scripts. I use it myself and I plan to maintain it within DPMT.
Re: Getting rid of codenames (Was: getting rid of "testing")
On Fri, Jun 28, 2019 at 08:51:18AM +0800, Yao Wei (?) wrote: > How about getting rid of codenames altogether? Like we use unstable > for unstable, experimental for experimental as it already is, no > testing and buster but debian11, debian12, etc. > > Although it is eliminating some funs but it is much more predictable > and simple to remember. I also confused squeeze with stretch. > By using symlinks at the apt repositories we can have both. debian10 symlinks to buster debian11 symlinks to bulleye bookworm symlinks to debian12 On Tue, Jun 25, 2019 at 09:38:57AM +0100, Simon McVittie wrote: > On Tue, 25 Jun 2019 at 13:11:09 +0500, Andrey Rahmatullin wrote: > > > > I guess only (most?) Debian contributors and hardcore Debian users > > remember the order of the codenames and their mappings to current > > stable/oldstable/testing and to numeric versions. > > Yes, exactly. This is a frequent request from those of my colleagues > who mostly use other distributions, but occasionally have to interact > with Debian, and can't remember whether stretch is older or newer than > jessie. This is going to be particularly bad after the buster release, > when buster and bullseye are current, and even worse after the bullseye > release, when buster, bullseye and bookworm will all be relevant. > > Ubuntu is easier in some ways (because the alphabetical codenames go in > a logical sequence) but harder in others (because the distinction between > LTS and non-LTS isn't obvious from the codenames). > > Back when the release team decided on a per-release basis whether this > was a "major" or "minor" release, we had the excuse that we had to use > a codename for testing because we didn't know whether etch would be > released as Debian 3.2 or Debian 4.0; but now that we've decided that > every release is a major version, we can predict well in advance that > Debian 10 will be followed by Debian 11 and Debian 12, so there doesn't > seem a whole lot of point in obfuscating it. So true > With more emphasis on the version numbers, my non-Debian colleagues would > still have to learn (or look up) which release is the current stable, > but given that information they would immediately also know which release > was the previous one (subtract 1) and which release is under development > (add 1). > > Referring to testing in speech/writing as something like Debian 10 > alphas/betas/pre-releases (to express that it *will be* Debian 10, but > it isn't really Debian 10 *yet*) might make more sense to non-Debian > people, and might have the desirable side-effect of having more Debian > contributors get the message that it's a means to an end (making > the next release happen) rather than a product in its own right. In > machine-readable contexts like sources.list it's probably best to use > something like debian10 (or deb10, as in stable updates' version strings, > or just 10) so that it doesn't have to change on release day. > > smcv > Groeten Geert Stappers P.S. rolling symlinks to testing tumbleweed symlinks to testing -- Leven en laten leven
