Re: getting rid of "testing"
On Ma, 25 iun 19, 08:08:22, Ansgar wrote:
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
AFAIK "unstable" is always symlinked to "sid", so it wouldn't make a
difference and also manages expectations ;)
"stable", besides significantly changing it's meaning at release may
also be actively harmful if one dist-upgrades by mistake[1] with
'stable' in sources.list.
While dist-upgrades are significantly smoother the Release Notes still
have important items that must be taken care of before/during/after
dist-upgrade.
Depending on your intention using "testing" may or may not be what you
want to have in sources.list even through releases.
Users that dist-upgrade early or install the next release while it's
still in testing for $reasons (e.g. hardware support, newer software
that is not available in backports, etc.) should always use the codename
to avoid surprises at release (as per above for "stable).
Those who want to stick with "testing" no matter what I believe[2] are
actually looking for a rolling distribution so it would probably make
sense to rename "testing" to "rolling"[3][4].
[1] because 'apt-get upgrade' doesn't install new packages many users
have developed a habit to always run 'apt-get dist-upgrade', e.g. to
upgrade their kernel package (in case of ABI change).
Users are slowly migrating to 'apt upgrade', but running 'apt-get
dist-upgrade' on stable just to get security upgrades will not disappear
anytime soon.
[2] based on more than 10 years experience on debian-user.
[3] or remove the "testing" symlink/name and add the "bob" rolling
release that was proposed in
https://lists.debian.org/debian-devel/2011/06/msg00136.html
[4] or "roling" to emphasize that it's incomplete :p
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
Re: Re: Content Rating System in Debian
Bagas Sanjaya writes: > Russ Allbery: >> It sounds like a whole ton of work to get a useful amount of coverage (not >> to mention bothering upstreams with questionnaires that I suspect many of >> them would find irritating -- I certainly would with my upstream hat on), >> and I'm not clear on the benefit. Do you have some reason to believe that >> this is a common request by users of Debian? If so, could you share with >> us why you believe that? > I'm discussing about CRS inspired from Google Play. Do Google Play not pay IARC for this? I would assume that there is a fee that covers IARC's costs in running the service, which is then paid out of the profit that Google makes on the games. What is it going to cost us to get 'bison' rated PG? Why is this useful? Also, it seems clear to me that the same game in all Linux disros is very likely to get the same rating, so this would be better done as a distribution agnostic level, preferably by someone that makes a profit from games or content anyway. For instance, I'd imagine that Steam have some sort of rating mechanism, which might even use IARC already, so one might be able to achieve this aim by talking to them about getting access to their system somehow, and perhaps getting them to include things in their database that they don't actually distribute themselves. One might imagine that one could buy a subscription to their rating database, say. Alternatively, parents who are interested might simply decide to subscribe to Steam if Steam provided a package that allowed subscribers to see the ratings for packages they were about to install. (I'm only saying Steam here because they've been quite Debian friendly AFAIK, but there's nothing stopping anyone else offering such ratings as a service to Debian users). Asking Debian to do it seems like it's just asking for trouble -- what happens when a child is traumatised by content that most people find completely innocuous in a package we've not yet got round to rating? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#914577: ITP: dropwatch -- A tool for detecting and diagnosing packets being dropped
Package: wnpp Followup-For: Bug #914577 Owner: Alexandros Kosiaris
Re: Re: Content Rating System in Debian
Philip Hands writes: > What is it going to cost us to get 'bison' rated PG? Why is this > useful? Erm, not 'PG' -- I meant whatever the "Anyone can watch this" label is. Although, I guess one could perhaps argue PG for bison: One could use it to build something that generates offensive content, and perhaps the joys of compiler writing should be saved for an appropriate age ;-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Content Rating System in Debian
On 2019-06-25 09:31, Philip Hands wrote: Russ Allbery: It sounds like a whole ton of work to get a useful amount of coverage (not to mention bothering upstreams with questionnaires that I suspect many of them would find irritating -- I certainly would with my upstream hat on), and I'm not clear on the benefit. Do you have some reason to believe that this is a common request by users of Debian? If so, could you share with us why you believe that? I'm discussing about CRS inspired from Google Play. Do Google Play not pay IARC for this? App developers are generally forced to self-rate their apps, otherwise they disappear from the store. Kind regards Philipp Kern
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
Even if we stop advertising them, could we keep them as a generic set of
aliases?[1]
> 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 think adding such names would be a good idea, as long as we stay on
simple versions. Or we use "debian-11", then it does not look that ugly
to do "debian-23.42".[2]
What would you do about sid? It got no version.
On related notes:
For Azure we currently plan (yeah, still not finished as MS does not
provide input, be we still need to change it):
- debian-10
- debian-11
- debian-sid
Regards,
Bastian
[1]: I think apt would need to learn about aliases.[2] As would dak, to
maintain them automatically.
[2]: Maybe we could even use them for bullseye/updates ->
bullseye-security and keep the former as alias without apt complaining
about it.
--
There's coffee in that nebula!
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"
Re: getting rid of "testing"
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. -- WBR, wRAR signature.asc Description: PGP signature
Re: Re: Content Rating System in Debian
On Tue, 25 Jun 2019 at 09:31:44 +0200, Philip Hands wrote: > Also, it seems clear to me that the same game in all Linux disros is > very likely to get the same rating, so this would be better done as a > distribution agnostic level Appstream metadata, which is canonically provided by upstreams and is distro- and package-type-agnostic (available in at least apt and Flatpak), has this as an optional field for self-rating: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-content_rating https://hughsie.github.io/oars/ I suspect that's the only way this could possibly work without money changing hands. smcv
Re: Content Rating System in Debian
Philipp Kern writes: > On 2019-06-25 09:31, Philip Hands wrote: >>> Russ Allbery: It sounds like a whole ton of work to get a useful amount of coverage (not to mention bothering upstreams with questionnaires that I suspect many of them would find irritating -- I certainly would with my upstream hat on), and I'm not clear on the benefit. Do you have some reason to believe that this is a common request by users of Debian? If so, could you share with us why you believe that? >>> I'm discussing about CRS inspired from Google Play. >> Do Google Play not pay IARC for this? > > App developers are generally forced to self-rate their apps, otherwise > they disappear from the store. Right, but is that not done by filling out a questionnaire that is somehow administered/rated by IARC, which presumably means that they need to be paid for providing that somewhere along the line (or is it all government funded?). Also, IARC claim to keep ratings under review, which presumably also needs to be paid for somehow. I was guessing that they collect subscriptions from the platforms to cover the costs. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Content Rating System in Debian
On 25/06/19 14.31, Philip Hands wrote: Bagas Sanjaya writes: Russ Allbery: It sounds like a whole ton of work to get a useful amount of coverage (not to mention bothering upstreams with questionnaires that I suspect many of them would find irritating -- I certainly would with my upstream hat on), and I'm not clear on the benefit. Do you have some reason to believe that this is a common request by users of Debian? If so, could you share with us why you believe that? I'm discussing about CRS inspired from Google Play. Do Google Play not pay IARC for this? I would assume that there is a fee that covers IARC's costs in running the service, which is then paid out of the profit that Google makes on the games. What is it going to cost us to get 'bison' rated PG? Why is this useful? Also, it seems clear to me that the same game in all Linux disros is very likely to get the same rating, so this would be better done as a distribution agnostic level, preferably by someone that makes a profit from games or content anyway. For instance, I'd imagine that Steam have some sort of rating mechanism, which might even use IARC already, so one might be able to achieve this aim by talking to them about getting access to their system somehow, and perhaps getting them to include things in their database that they don't actually distribute themselves. One might imagine that one could buy a subscription to their rating database, say. Alternatively, parents who are interested might simply decide to subscribe to Steam if Steam provided a package that allowed subscribers to see the ratings for packages they were about to install. (I'm only saying Steam here because they've been quite Debian friendly AFAIK, but there's nothing stopping anyone else offering such ratings as a service to Debian users). Asking Debian to do it seems like it's just asking for trouble -- what happens when a child is traumatised by content that most people find completely innocuous in a package we've not yet got round to rating? Cheers, Phil. I don't know whether Google Play and Steam pay IARC or not, but if they do, the fee would be so expensive that Debian can't afford (unless we're RedHat or similar). Also, to implement CRS, major overhaul to packaging system (apt/dpkg) and user accounts need to be done in order to accommodate CRS. But CRS can give users insight about maturity of packages. So if sysadmins (parents in home networks) is about to install Apache HTTPD or other packages, they need to answer whether the packages are appropriate for their users' age or not. In multi-user setups (such as in servers) CRS can be a problem, because although majority of users are adults (18+), there are possibilities that children (7+) or teens (12+) also use such packages. Some packages might recommend Parental Guidance (PG) but it is not possible in server setups. I'm agree that CRS should be done on distribution-independent manner. This means that upstream file rating request to IARC in order to get their programs rated. Distributions (Debian/Ubuntu, RedHat, etc.) then package programs which have been rated. In Google Play, rating process is slightly different: upstream upload their applications/games to Google Play, then they fill rating questionnaire provide by Google Play and send it to IARC. Regardless, for CRS, we need a CRS system that is cross-distribution that can be implemented to package managers and user administration tools on most distributions. Erm, not 'PG' -- I meant whatever the "Anyone can watch this" label is. In IARC classification, that is 3+ (for anyone as long as they are not toddlers).
Re: getting rid of "testing"
On Tue, 25 Jun 2019 at 13:11:09 +0500, Andrey Rahmatullin wrote: > On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: > > 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. 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. 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
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
I use these (testing, etc) so getting rid of them would be annoying.
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
Already kind of possible:
deb http://deb.debian.org/debian Debian9.9 main
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
They do have the 'devel' suite, but it is not a proper one:
https://bugs.launchpad.net/ubuntu/+bug/1821272
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2019-06-25 09:46, Bastian Blank wrote: > On related notes: For Azure we currently plan (yeah, still not > finished as MS does not provide input, be we still need to change > it): - debian-10 - debian-11 - debian-sid And docker hub have some similar things with the version tags. stable, 9 and stretch are the same target. And for those not familiar with the docker targets: $ docker run debian:stable cat /etc/debian_version More info https://hub.docker.com/_/debian/ I can see good reasons for having the classic names still (testing, unstable and so on) - the great benefit would be to have the version numbers available as well. Different audiences in target I think. - -- brother http://sis.bthstudent.se -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAl0R4Z0ACgkQOIRDexPY /4tOLA/9EYugAyJWehITg2mpOS0oE75nV1e/UAO1SczBiWNC+io9ostWaANaR4xT eEMLnHfZCtVmiJYlCvepcK6EnSD42vx5nrVbFTUZR82AYR2QyL5yKbYoYUNzC3Px Nj4g2KFzAscr7KXJ6arXdP9GqJmIJR7vao3T0z0TXVcL/gpfyN3kYVt82f99Zpzp 0qAewKZLq5hmhBRSnYHioqWes6WvdybMHzsG9uwVLzuVCTJQQ5BcqXrgBuXJPQG5 5/xhbIxnFpbN74XoiGIydvrPmF2/CcYGGMd8lVS0dwpQbBeTe6wqXOx+edqj3Ioo eSOz8IoQeGVae0THUDSH+Ezp1UMblK47oB/erzyvy3FEufvsyuLxjdz/KuLwL2/H 0uzxhRN5jOlGg+xzR1WeOcxyjrQEKv5sVcuNla64QNuzDopnJqd2gEnxAGiRMKcK N/ftpXRo7WJrROBNu51+hSHxGuACJVajsrE1qQqvCR65ycoRWGj/twABD+HTJ4hm S8392KXpVRqQmFMfZs+u7JPiCAxzzcOmgDolhYZxljNoBRsAosRJfEQvH/tGLpU3 lAbHkzhMjeZ2SmXfFPy11cHbQQVLhBw3C7QZaZaLbxUwVqEMaqQyi8KLlj2DNsP/ jzW2NOXdHogUXL6u6ZzgbDlHAR++lhomKVApYcPaAp8P/b/5J7k= =vGqi -END PGP SIGNATURE-
Re: Re: Content Rating System in Debian
Am Di., 25. Juni 2019 um 10:15 Uhr schrieb Simon McVittie : > > On Tue, 25 Jun 2019 at 09:31:44 +0200, Philip Hands wrote: > > Also, it seems clear to me that the same game in all Linux disros is > > very likely to get the same rating, so this would be better done as a > > distribution agnostic level > > Appstream metadata, which is canonically provided by upstreams and is > distro- and package-type-agnostic (available in at least apt and Flatpak), > has this as an optional field for self-rating: > > https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-content_rating > https://hughsie.github.io/oars/ > > I suspect that's the only way this could possibly work without money > changing hands. Indeed :-) Also, metainfo files can be written for every software component, not only for apps (although I thing GUI applications are the things age-rating is most relevant for). If any features in this are missing, let me or Richard Hughes know. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: AMDGPU+OpenCL with Debian?
Michael Kesper schrieb: > On 18.06.19 22:55, Moritz M=C3=BChlenhoff wrote: >> You may find https://phabricator.wikimedia.org/T148843/#5078403 >> (and later) interesting,=20 > > This seems to require wikimedia authentication. > Is there some information publicly available about it? Ah, that's just an artefact of the URL, simply use https://phabricator.wikimedia.org/T148843 which doesn't need any login. Cheers, Moritz
Re: getting rid of "testing"
On 2019-06-25 09:39, Paul Wise wrote: On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote: Related to that I would like to be able to write something like deb http://deb.debian.org/debian debian11 main Already kind of possible: deb http://deb.debian.org/debian Debian9.9 main With the caveat that as soon as 9.10 happens, the 9.9 symlink will cease existing. Regards, Adam
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> Hi,
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
And for this exact reason so many people want "testing" not "buster".
This way they get 5-days-newest versions of everything, without having to
suffer broken uploads, broken dependencies, etc.
Using "buster" would mean that at some moment their updates suddenly stop,
and they have to manually migrate to the next version.
> 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.
Hell no! Even though I'm among most active DDs around, I just had to look
up whether "debian11" means Buster or Bullseye.
It's same eg. for processor names: "Skylake" means Skylake, which is used
within 6 or 7 different numbering schemes. Even people who care what
processor that is will so often need to look up versioning numbers -- as the
public names are about marketing segments and so on, not about how a
processor behaves.
A code name is also so much easier to talk about, especially in speech -- a
codename is one or two fairly unique syllables, while a number is longer,
and it's usually surrounded by other numeric values within other semantic
domains.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This
⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project.
⠈⠳⣄
Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)
On 5/29/19 11:01 AM, Raphael Hertzog wrote:
> On Wed, 29 May 2019, Ansgar wrote:
>> On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
>>> On Wed, 29 May 2019, Andrey Rahmatullin wrote:
One of the popular answers to this and some other problems is "nobody sat
down and wrote the code". Not sure what can we do about this class of
reasons.
>>>
>>> Use the $300,000 on our bank accounts?
>>
>> I heard that this didn't work out well the last time ("dunc tank"),
>> though that was before the time I followed Debian development.
>
> Yes, I was there (and mention it briefly in the questions of the talk I
> gave) but it's been a long time ago. There are things to learn
> from this failed experiment (such as "don't let the DPL decide alone who
> gets paid") but there are also many reasons to believe that we are no
> longer in the same situation. At that time, the number of persons working
> on open source as part of their paid work was rather low and the jealousy
> aspect was likely more problematic than it would be today.
I clearly remember that one heated topic was about the level of salary
for a release manager. Many thought 6K USD was too much and were shocked
about the amount. I probably was at the time. Now, I'm 43, I have
children, higher life cost, and responsibilities. I'm not shocked
anymore, but I can easily understand others would still be.
Let's *not* start this again.
> The topic still needs to be approached carefully
Yes.
> but I believe that we
> should aim to have this discussion and build some framework where we can
> leverage money to complete projects and tasks that we find important
> but that have not gone forward through volunteer work.
I'm not sure if I'm in the favor of Debian slowly transforming itself
into yet another world company.
Cheers,
Thomas Goirand (zigo)
Re: Re: Re: Content Rating System in Debian
Simon McVittie: Appstream metadata, which is canonically provided by upstreams and is distro- and package-type-agnostic (available in at least apt and Flatpak), has this as an optional field for self-rating: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-content_rating https://hughsie.github.io/oars/ I suspect that's the only way this could possibly work without money changing hands. There are no age classifications, however. So based on content_rating tag on AppStream metadata, we can add logic to apt in order to determine age rating for our packages. However, external review (maintainers) may be need in order to prevent misleading information on content_rating.
Re: getting rid of "testing"
~Ansgar writes ("getting rid of "testing""):
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
Others have pointed out that "testing" has a specific value. Also,
these suite aliases have a documentary value. It can be helpful to
say things like "when this is languishing in oldstable ...".
So I would prefer to keep them.
> 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.
Yes, please, absolutely. And this should be the default.
I know the codenames thing is fun but it is seriously inconvenient
when talking to anyone who is not completely steeped in Debian stuff.
Even Debian people sometimes make slips - and I'm sure they are more
common because we're having to constantly do these kind of codename
lookups.
I agree entirely with Simon.
The syntax "debian11" is precisely right. Please don't add a hyphen
to it, as hyphens are already used for separating things like
-security.
I don't think I have any software which would go wrong if there were
an extra hyphen but I would be amazed if there weren't a ton of ad-hoc
scripts out there that would be fine with the transition from
`bookwork' to `debian11' but would Go Wrong with `debian-11'.
For now, the `debian11' can be an alias. At some future point this
should become the canonical suite name, replacing the codename. But I
think this should not be done retrospectively to old suites, because
there is software outside the archive that wants to name things by a
single canonical name, and changing that name for an existing suite
will cause trouble.
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.
Re: getting rid of "testing"
Ian Jackson [2019-06-25 11:09:06+01:00] wrote:
> ~Ansgar writes ("getting rid of "testing""):
>> deb http://deb.debian.org/debian debian11 main
>> deb http://security.debian.org/debian-security debian11-security main
> Yes, please, absolutely. And this should be the default.
> The syntax "debian11" is precisely right. Please don't add a hyphen
> to it, as hyphens are already used for separating things like
> -security.
> For now, the `debian11' can be an alias.
As a mere user I'd say this is the best approach: add debian10, debian
11 etc. alias or perhaps later make it the proper name.
My first Debian was Woody. I remember that Sarge was after that, then
Etch or Lenny (I think), but it all started to blur at that time. Now I
know that I'm using Debian 9 but don't remember its name. I don't
remember what was the name of the previous version.
I think it's best to use version numbers for communication with users
and to configure Debian (like sources.list).
Anyway, thank you for this excellent operating system.
--
/// Teemu Likonen //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///
signature.asc
Description: PGP signature
Re: Content Rating System in Debian
On Tue, 25 Jun 2019 at 16:33:53 +0700, Bagas Sanjaya wrote: > There are no age classifications, however. So based on content_rating tag on > AppStream metadata, we can add logic to apt in order to determine age rating > for our packages. I think this would be unwise. We can never get this right, because the descriptors that are considered suitable for a particular age vary widely between cultures and countries. The most likely outcome would be angry bug reports from parents who felt that the given age rating was inappropriate. Something like OARS is already somewhat subjective (how much violence can a game have and still be considered "moderate"?) but it's a lot closer to being objective than an age rating. smcv
Re: Content Rating System in Debian
Bagas Sanjaya wrote on 25/06/2019: > Hello Debian Developers, > > Debian provides more than 51000 packages. From those packages, some are > appropriate for every ages, and some others are > only for specific age groups for some reasons. > > In order to inform to users, especially parents, about potentially > objectionable content in Debian packages, Content > Rating System (CRS) can be deployed to Debian. With CRS, users can choose to > install packages that is rated for their > age. In some cases, CRS also filter or block certain contents in certain > jurisdictions when legally required. > > As in Google Play, Debian CRS is based on official ratings from International > Age Rating Coalition (IARC). The rating system in Google Play makes some sense (at least on paper) because you can leave a phone to a kid, configured with their Google account, and Google will allow to install only apps deemed appropriate for the account holder's age. There is no such a thing in Debian. There isn't a Debian account which is able to give you partial access to the repositories. If you are root you can install everything; if you aren't you can't install anything. And when installing a package for a kid then checking its description is probably better than any rating system. We can't achieve the same result as Google, which in my opinion wouldn't be useful anyway; see below. > Pros: > - Users, especially parents, can install packages suitable for their age. In > case of parents, this apply to their > sons/daughters. I don't think there is a meaningful "Pro" here. The first and in most cases only packages that would make sense to control are web browsers. Nowadays not installing a web browser makes a computer almost useless for almost any purpose a kid or teenager may want it for. At this point it's just better to install a browser and leave the machine offline. At least they'll have access to offline documentation! Or to a local Wikipedia mirror. > - For users in some jurisdiction, they can only install packages that is > legal in their jurisdiction. For example, Debian > users in USA can only install US version of GnuPG, but in outside USA, users > can install international version of GnuPG > instead. Didn't this stop to be a thing in the late nineties? The issue wouldn't be age-related anyway. > Based on above, what are your opinions/thoughts/positions about Content > Rating System in Debian? My question is: are we trying to solve an actual problem here? Are there packages that you would consider not suitable for young users, and whose impact wouldn't be greatly inferior to the one of web browsers (which, in my reasoning, are going to be installed anyway)? I hope the answer is not fortunes-off here :-) While this email is mostly a "thumbs down", I agree with Russ Allbery: if a group feels strongly enough about CRS to do the work, I think it will fit well in the debtags labeling system. Paride
Dotyczy Twojego FanPage. Sprawdź.
Dzień dobry, w związku z ciągłymi zmianami jakie zachodzą w social mediach, kontaktujemy się z Państwem,aby zaproponować profesjonalne prowadzenie *FanPage na Facebook’u. * Dzięki zdobytemu doświadczeniu, możemy Państwu zapewnić: -zwiększenie liczby fanów -brak długoterminowych umów -brak ukrytych kosztów -wzrost Państwa sprzedaży. Aby móc Państwu przedstawić więcej szczegółów w tym zakresie, prosimy o odpowiedź o treści *Tak. * .. Z wyrazami szacunku, Prowadzenie FanPage
Re: Content Rating System in Debian
On Tue, Jun 25, 2019 at 12:43:56PM +0200, Paride Legovini wrote: > My question is: are we trying to solve an actual problem here? No, and please note that the author is not even a Debian user: https://lists.debian.org/debian-devel/2019/06/msg00376.html -- WBR, wRAR signature.asc Description: PGP signature
Re: Content Rating System in Debian
On Tue, Jun 25, 2019 at 11:40:04AM +0700, Bagas Sanjaya wrote: > Based on above, what are your opinions/thoughts/positions about Content > Rating System in Debian? just NO. please create a fork and leave Debian without this. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Content Rating System in Debian
Hi, On Tue, 2019-06-25 at 11:40 +0700, Bagas Sanjaya wrote: > Based on above, what are your opinions/thoughts/positions about > Content Rating System in Debian? is this related to your other proposal involving giving "sudo" permissions to teenagers to handle this age recommendation stuff for TV programs? | In fact, many television stations have most programs written for | teens (age 13 and older), so sysadmins there configure sudoers which | allows teens to behave like sysadmins themselves (by giving them full | administrator privileges) on their production systems. Also, parental | monitoring and guidance can reduce likehood of teens breaking such | systems. Maybe because teens are largest marketshare for TVs. Ansgar - rating "kill -KILL" X-rated for extreme violence
Re: getting rid of "testing"
On Tue, 2019-06-25 at 16:39 +0800, Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend using
> > codenames instead as those don't change their meaning when a new release
> > happens.
>
> I use these (testing, etc) so getting rid of them would be annoying.
The "stable" suite names are more annoying than
unstable/testing/experimental as they require updates to suites at
release time that are not related to the release. That shouldn't be
necessary.
For "testing", "unstable" one could probably introduce some `Alias`
field in Release, but I also like minimalist solutions (which already
seem to work well for Ubuntu).
> > Related to that I would like to be able to write something like
> >
> > deb http://deb.debian.org/debian debian11 main
>
> Already kind of possible:
>
> deb http://deb.debian.org/debian Debian9.9 main
Yes, but it gives warnings for issues that I believe should be an error
instead. (And currently a good reason for TLS to talk to mirros so a
MitM that is not a mirror operator cannot give you oldstable when you
want to use unstable.)
debootstrap gives an error for this:
+---
| $ /sbin/debootstrap --print-debs Debian9.9 . http://ftp.de.debian.org/debian
unstable
| [...]
| E: Asked to install suite Debian9.9, but got stable (codename: stretch) from
mirror
+---
As Adam already pointed out having the point release in there also
makes "Debian9.9" rather unhelpful.
> > Ubuntu already has no suite names, only codenames, but having to map
> > "Ubuntu 18.04" to "bionic" instead of just writing the version in
> > sources.list is annoying (I always have to look up the codename to be
> > sure as I don't use Ubuntu that much).
>
> They do have the 'devel' suite, but it is not a proper one:
>
> https://bugs.launchpad.net/ubuntu/+bug/1821272
That is what Debian9.9 (and similar) are currently as well.
Ansgar
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 11:09:06AM +0100, Ian Jackson wrote:
~Ansgar writes ("getting rid of "testing""):
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.
Yes, please, absolutely. And this should be the default.
+1
Having "stable" in sources.list is broken, because one day stuff goes
from working to not working, which requires manual intervention, at
which point someone could have just changed the name. Having codenames
in sources.list is broken, because even people who have been developers
for two decades can't remember which release is which without looking it
up. (Which is harder than it should be; maybe we should have had
/etc/debian-releasenames or somesuch from the beginning. lsb_release -a
is helpful when available but doesn't have context, and many users don't
know it exists.)
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: > Having "stable" in sources.list is broken, because one day stuff goes > from working to not working, which requires manual intervention, at > which point someone could have just changed the name. Having codenames > in sources.list is broken, because even people who have been developers > for two decades can't remember which release is which without looking it > up. (Which is harder than it should be; maybe we should have had > /etc/debian-releasenames or somesuch from the beginning. lsb_release -a > is helpful when available but doesn't have context, and many users don't > know it exists.) Personally, I can remember the names and their order much better than which version goes with which codename or suite :) -- bye, pabs https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:07:51PM +0800, Paul Wise wrote: On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: Having "stable" in sources.list is broken, because one day stuff goes from working to not working, which requires manual intervention, at which point someone could have just changed the name. Having codenames in sources.list is broken, because even people who have been developers for two decades can't remember which release is which without looking it up. (Which is harder than it should be; maybe we should have had /etc/debian-releasenames or somesuch from the beginning. lsb_release -a is helpful when available but doesn't have context, and many users don't know it exists.) Personally, I can remember the names and their order much better than which version goes with which codename or suite :) Well, every problem domain has its rainman :) For the rest of us, there's google.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:03:49AM -0400, Michael Stone wrote: > Having "stable" in sources.list is broken, because one day stuff goes from > working to not working, which requires manual intervention, at which point > someone could have just changed the name. Once I had unattended-upgrades do the upgrade to the new stable for me over night on quite a few systems, almost everything still worked. Regards, Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 02:38:43PM +0200, Bastian Blank wrote: On Tue, Jun 25, 2019 at 08:03:49AM -0400, Michael Stone wrote: Having "stable" in sources.list is broken, because one day stuff goes from working to not working, which requires manual intervention, at which point someone could have just changed the name. Once I had unattended-upgrades do the upgrade to the new stable for me over night on quite a few systems, almost everything still worked. "almost" covers quite a lot of territory, and is the reason it's best not to have the upgrade happen accidentally.
Re: Re: Re: Content Rating System in Debian
Am Di., 25. Juni 2019 um 11:51 Uhr schrieb Bagas Sanjaya : > > Simon McVittie: > > Appstream metadata, which is canonically provided by upstreams and is > distro- and package-type-agnostic (available in at least apt and Flatpak), > has this as an optional field for self-rating: > > https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-content_rating > https://hughsie.github.io/oars/ > > I suspect that's the only way this could possibly work without money > changing hands. > > There are no age classifications, however. > > So based on content_rating tag on AppStream metadata, we can add logic to apt > in order to determine age rating for our > packages. However, external review (maintainers) may be need in order to > prevent misleading information on > content_rating. To clarify: Age ratings vary wildly between countries. So what we expect is that software centers will not actually display content_rating information, but instead compile an age rating out of it based on the user's current location/locale and then display that. Having a "one-size fits all" generic rating isn't very practical. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: getting rid of "testing"
Only a few remarks as former simple user and now maintainer: * Please don't mix things: release names has a value, distribution names like oldoldstable, oldstable, stable, testing, unstable has their value too * the value is that they never change - they are convenient. Especially if one use unstable most of the time, please think of such things like `apt policy $foo` - it is highly unlikely that a sid user want to use old stuff, but will ask from time to time about versions ... * using the release names is convenient to set up systems before the release is done - i can set up a "buster" system now and have to change nothing when it become stable. The other way around is not a good way to go. At all - using distributions like "testing" or "unstable" should mean that the users/admins in charge can handle it - if not they should learn it or never ever do such things again. Might sound stubborn, but hey - i learned it this way. As a user of a rock stable "Sid" system i see no big problems for ten years now - ok, maybe to resist this: Hmm, what will happend if i will hit now ... Cheers Alf
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: Only a few remarks as former simple user and now maintainer: * Please don't mix things: release names has a value, distribution names like oldoldstable, oldstable, stable, testing, unstable has their value too oldoldstable has the value of demonstrating some of what's wrong with the current system
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:06:55PM +0200, Benjamin Drung wrote: Am Dienstag, den 25.06.2019, 11:48 -0400 schrieb Michael Stone: On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: > Only a few remarks as former simple user and now maintainer: > * Please don't mix things: release names has a value, distribution > names like oldoldstable, oldstable, stable, testing, unstable has > their value too oldoldstable has the value of demonstrating some of what's wrong with the current system Then running wheezy will be fine once buster is released, because oldoldstable will point to jessie and wheezy won't have a release name any more? Some admins ask: "How many reboots until the next Debian release?" Others ask: "How many Debian releases until the next reboot?" I can images systems that are getting bought, setup, and after several years shutdown and retired without rebooting or dist-upgrading them. I have no idea what you're trying to say, sorry.
Re: getting rid of "testing"
Am Dienstag, den 25.06.2019, 11:48 -0400 schrieb Michael Stone: > On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: > > Only a few remarks as former simple user and now maintainer: > > * Please don't mix things: release names has a value, distribution > > names like oldoldstable, oldstable, stable, testing, unstable has > > their value too > > oldoldstable has the value of demonstrating some of what's wrong > with > the current system Then running wheezy will be fine once buster is released, because oldoldstable will point to jessie and wheezy won't have a release name any more? Some admins ask: "How many reboots until the next Debian release?" Others ask: "How many Debian releases until the next reboot?" I can images systems that are getting bought, setup, and after several years shutdown and retired without rebooting or dist-upgrading them. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Re: getting rid of "testing"
On 25.06.19 17:48, Michael Stone wrote: oldoldstable has the value of demonstrating some of what's wrong with the current system Can you please explain, i don't get it - maybe i to new at this. For me file like /etc/apt/sources.lists.d/debian.list: deb http://ftp.debian.org/debian/ oldoldstable main contrib non-free deb-src http://ftp.debian.org/debian/ oldoldstable main contrib non-free deb http://ftp.debian.org/debian/ oldstable main contrib non-free deb-src http://ftp.debian.org/debian/ oldstable main contrib non-free deb http://ftp.debian.org/debian/ stable main contrib non-free deb-src http://ftp.debian.org/debian/ stable main contrib non-free deb http://ftp.debian.org/debian/ testing main contrib non-free deb-src http://ftp.debian.org/debian/ testing main contrib non-free deb http://ftp.debian.org/debian/ unstable main contrib non-free deb-src http://ftp.debian.org/debian/ unstable main contrib non-free deb http://ftp.debian.org/debian/ experimental main contrib non-free deb-src http://ftp.debian.org/debian/ experimental main contrib non-free deb http://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free deb-src http://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main contrib non-free deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main contrib non-free deb http://ftp.debian.org/debian/ stretch-backports main contrib non-free is perfectly fine. So it is possible for me -- strictly running sid with buildd on _my_ production system -- doing things like: % apt policy nano nano: Installiert: 3.2-3 Installationskandidat: 3.2-3 Versionstabelle: 4.1-1 1 1 http://ftp.debian.org/debian experimental/main amd64 Packages *** 3.2-3 500 500 http://ftp.debian.org/debian testing/main amd64 Packages 500 http://ftp.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status 2.7.4-1 500 500 http://ftp.debian.org/debian stable/main amd64 Packages 2.2.6-3 500 500 http://ftp.debian.org/debian oldstable/main amd64 Packages and so on - i take the older releases only as reference. So for me there is a use case, i'm not interested in older versions as old or oldoldstable - and i will never change this file without reason. Cheers Alf
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:28:13PM +0200, Alf Gaida wrote: > > oldoldstable has the value of demonstrating some of what's wrong with > > the current system > > Can you please explain, i don't get it That name is stupid. -- WBR, wRAR signature.asc Description: PGP signature
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:28:13PM +0200, Alf Gaida wrote: On 25.06.19 17:48, Michael Stone wrote: oldoldstable has the value of demonstrating some of what's wrong with the current system Can you please explain, i don't get it - maybe i to new at this. For me file like /etc/apt/sources.lists.d/debian.list: wow, that slows down every package operation on the system as you download or search 6+ versions of everything. and so on - i take the older releases only as reference. I just do something like look at https://packages.debian.org/ssh Or, if I'm really curious about versions, then something like http://snapshot.debian.org/package/openssh/ If you've got some kind of weird requirement to have everything local, I'd still rather see something like "debian8" in the output than "oldoldstable"--a name that changes over time and is therefore relative to both a reference system and a specific system at the time that entry was created. If I want a specific version of a package, it will only be in "oldoldstable" up until "oldoldstable" is something entirely different. I'm still not understanding a use case where that's an advantage.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 12:40:01PM -0400, Michael Stone wrote: > > and so on - i take the older releases only as reference. > > I just do something like look at https://packages.debian.org/ssh > Or, if I'm really curious about versions, then something like > http://snapshot.debian.org/package/openssh/ rmadison(1) and https://tracker.debian.org/ are probably better. -- WBR, wRAR signature.asc Description: PGP signature
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 09:43:02PM +0500, Andrey Rahmatullin wrote: On Tue, Jun 25, 2019 at 12:40:01PM -0400, Michael Stone wrote: > and so on - i take the older releases only as reference. I just do something like look at https://packages.debian.org/ssh Or, if I'm really curious about versions, then something like http://snapshot.debian.org/package/openssh/ rmadison(1) and https://tracker.debian.org/ are probably better. Those are also good options for additional use cases. :) At any rate, putting every release ever into sources.list is generally not the best available mechanism.
Re: Content Rating System in Debian
On 6/25/19 8:27 AM, Holger Levsen wrote: > On Tue, Jun 25, 2019 at 11:40:04AM +0700, Bagas Sanjaya wrote: >> Based on above, what are your opinions/thoughts/positions about Content >> Rating System in Debian? > just NO. please create a fork and leave Debian without this. Hard but necessary response :-) > IMO this idea represent a big work. And if you want to involved upstream, maybe will be a problem. Some upstream, could not be interest on participate because could be a "extra" work. But if we implement a content rating system, the freedom could be affected because the opinion on a package may be affected by this new system. -- Emmanuel Arias @eamanu https://eamanu.com signature.asc Description: OpenPGP digital signature
Re: getting rid of "testing"
On 6/25/19 8:08 AM, Ansgar wrote:
> Hi,
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
>
> 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.
>
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
>
> Ansgar
Are we going to have rc-buggy as an alias to Experimental? :)
Cheers,
Thomas Goirand (zigo)
Bug#931089: ITP: ocaml-ffmpeg -- OCaml interface for FFmpeg
Package: wnpp Severity: wishlist Owner: Kyle Robbertze * Package name: ocaml-ffmpeg Version : 0.2.1 Upstream Author : Savonet Team * URL : https://github.com/savonet/ocaml-ffmpeg * License : LGPL Programming Lang: OCaml Description : OCaml interface for FFmpeg The modules currently available are: Av: the module containing demuxers and muxers for reading and writing multimedia container formats. Avcodec: the module containing decoders and encoders for audio, video and subtitle codecs. Swresample: the module performing audio resampling, rematrixing and sample format conversion operations. Swscale: the module performing image scaling and color space/pixel format conversion operations. Avdevice: the module containing input and output devices for grabbing from and rendering to many common multimedia input/output software frameworks. This is a dependency of the new version of Liquidsoap and will be maintained as part of the Ocaml Maintainers team.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 4:39 PM Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
>
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend using
> > codenames instead as those don't change their meaning when a new release
> > happens.
>
> I use these (testing, etc) so getting rid of them would be annoying.
I also should mention that I use all of stable stable-updates
proposed-updates and the equivalents for old/oldold. I have them in
the apt sources of a chdist so I can easily look up old versions, do
apt-file searches on old versions, look up non-amd64 architecture info
etc.
I would also love to have stable-backports be a thing, so I don't have
to change my chdist apt sources from codename1-backports to
codename2-backports every time a release happens.
I use chdist for when I'm offline or when I want to see what is on the
mirrors, since rmadison shows the ftp-master view.
PS: apt-venv is another option for this use-case.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: Re: Content Rating System in Debian
Emmanuel Arias: IMO this idea represent a big work. And if you want to involved upstream, maybe will be a problem. Some upstream, could not be interest on participate because could be a "extra" work. But if we implement a content rating system, the freedom could be affected because the opinion on a package may be affected by this new system. Regarding freedom, yes it can be affected by CRS because CRS can limit freedom to use programs for some users (particularly non-adults). But CRS limit such freedom in order to protect psychology users for long term from negative impacts of programs they used.
