Re: Epoch for node-markdown-it

On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote: > Epochs cause problems, [...] which are? (I agree they are ugly and should often be avoided, but I don't see any unsolved problems with them, which is why I'm asking.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|r

Re: Epoch for node-markdown-it

On Fri, Aug 19, 2022 at 05:50:46PM +0200, Andrej Shadura wrote: > As Jonas said, an epoch cannot be undone, +really can, regardless when this > is going to happen. Both are ugly solutions, but an epoch is also evil, > unlike +really 🙂 it's still only version number cosmetics, or nit-picking or

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

Andrea Pappacoda writes: > Would alternatives really be that bad? What if the current /usr/bin/muon > was moved to /usr/bin/muon-kde, muon-build was installed to > /usr/bin/muon-build and /usr/bin/muon was shared between the two > packages? What issues could it cause? Debian specifically disall

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

On 2022-08-19 23:14, Andrea Pappacoda wrote: Would alternatives really be that bad? What if the current /usr/bin/muon was moved to /usr/bin/muon-kde, muon-build was installed to /usr/bin/muon-build and /usr/bin/muon was shared between the two packages? What issues could it cause? I don't thi

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

Il giorno ven 19 ago 2022 alle 18:51:31 +01:00:00, Simon McVittie ha scritto: I'm not Paul, but I suspect he was looking at Policy §10.1: Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the

Re: …/doc …/log: .gz → .zst

Quoting Hakan Bayındır (2022-08-19 17:47:42) > I’d object that, because after we rotate the logs, we use a lot of z > commands, namely zcat, zgrep, zless. Which allows us process many gigabytes > of gzip files without extracting them first. > > We have a big cluster at office and a central logging

Re: …/doc …/log: .gz → .zst

On 16595 March 1977, Hakan Bayındır wrote: I’d object that, because after we rotate the logs, we use a lot of z commands, namely zcat, zgrep, zless. Which allows us process many gigabytes of gzip files without extracting them first. So you use zstdcat, zstdgrep, etc.pp, done. -- bye, Joerg

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

Hi, On 19-08-2022 18:10, Luca Boccassi wrote: On Fri, 19 Aug 2022 at 16:54, Paul Gevers wrote: On 19-08-2022 17:41, Luca Boccassi wrote: And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and using the same path should be ok as well? No. Care to elaborate a little? Simon

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

On Fri, 19 Aug 2022 at 19:19:25 +0200, Andrea Pappacoda wrote: > > And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and > > using the same path should be ok as well? > > I had the same idea, even if it is not extremely elegant. But Paul doesn't > seem to agree; why? I'm not Paul,

Re: Epoch for node-markdown-it

On 8/19/22 23:02, Jonas Smedegaard wrote: Quoting Nilesh Patra (2022-08-19 17:45:57) JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1 _now_ (after two years) Going by previous releases, the delta between one major release is atleast an year. Seems to me that roughly... 1

Re: Epoch for node-markdown-it

Quoting Nilesh Patra (2022-08-19 17:45:57) > On Fri, Aug 19, 2022 at 04:43:17PM +0200, Andrej Shadura wrote: > > Hi, > > > > On Fri, 19 Aug 2022, at 16:37, Jonas Smedegaard wrote: > > > Quoting Yadd (2022-08-19 10:21:17) > > >> some months ago, a bad upstream tag changed node-markdown-it version t

Re: debian-devel-digest Digest V2022 #312

Il giorno ven 19 ago 2022 alle 16:11:28 +00:00:00, debian-devel-digest-requ...@lists.debian.org ha scritto: muon-build seems more consistent with its own domain name muon.build, the reference meson implementation's domain name mesonbuild.com, and their shared dependency ninja being packaged

Re: Epoch for node-markdown-it

On Fri, 19 Aug 2022 at 21:36:24 +0530, Pirate Praveen wrote: > Are we going to deny every epoch request or this is going to be subjective? If there was a correct objective rule for what to do, we'd be applying that rule mechanically, not asking our fellow developers for advice. Epochs cause proble

Re: Epoch for node-markdown-it

On Fri, Aug 19, 2022 at 09:51:14PM +0530, Nilesh Patra wrote: > > As Jonas said, an epoch cannot be undone, +really can, regardless when this > > is going to happen. > > I think ignoring when it happens is not the right way to see it. Even if we > assume that > upstream is going to work on this

Re: Epoch for node-markdown-it

Hi Andrej, On Fri, Aug 19, 2022 at 05:50:46PM +0200, Andrej Shadura wrote: > Hi, > > On Fri, 19 Aug 2022, at 17:45, Nilesh Patra wrote: > >> I agree, adding an epoch in this package doesn’t seem appropriate or > >> necessary. > > > > JTFR - Upstream released 12.0.4 in 2020, and they have reached

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

On Fri, 19 Aug 2022 at 16:54, Paul Gevers wrote: > > On 19-08-2022 17:41, Luca Boccassi wrote: > > And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and > > using the same path should be ok as well? > > No. Care to elaborate a little? Kind regards, Luca Boccassi

Re: Epoch for node-markdown-it

On Fri, Aug 19 2022 at 05:50:46 PM +02:00:00 +02:00:00, Andrej Shadura wrote: Hi, On Fri, 19 Aug 2022, at 17:45, Nilesh Patra wrote: I agree, adding an epoch in this package doesn’t seem appropriate or necessary. JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

On 19-08-2022 17:41, Luca Boccassi wrote: And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and using the same path should be ok as well? No. Paul OpenPGP_signature Description: OpenPGP digital signature

Re: …/doc …/log: .gz → .zst

Hi Adam, I’d object that, because after we rotate the logs, we use a lot of z commands, namely zcat, zgrep, zless. Which allows us process many gigabytes of gzip files without extracting them first. We have a big cluster at office and a central logging system. That system handles close to a th

Re: Epoch for node-markdown-it

On Fri, Aug 19, 2022 at 04:43:17PM +0200, Andrej Shadura wrote: > Hi, > > On Fri, 19 Aug 2022, at 16:37, Jonas Smedegaard wrote: > > Quoting Yadd (2022-08-19 10:21:17) > >> some months ago, a bad upstream tag changed node-markdown-it version to > >> 22.2.3 instead of 10.0.0. So I'd like to change

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

On Fri, 19 Aug 2022 at 15:48, Simon McVittie wrote: > > On Fri, 19 Aug 2022 at 13:57:50 +0200, Andrea Pappacoda wrote: > > The upstream name is "muon", but this package and /usr/bin/ name is already > > used by KDE Muon, a [dead] synaptic alternative. > > > > I'm not sure how to handle this confli

…/doc …/log: .gz → .zst

Meow! Because of the trimming changelogs discussion, I just wondered whether it'd be beneficial to switch compression from .gz to .zst (gzip to zstd). Numbers I got from the desktop I sit at: * du of a copy of /usr/share/doc 366692 * rm ! -name "*.gz" 194184 * decompress 656852 * repack as zstd 1

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

On Fri, 19 Aug 2022 at 13:57:50 +0200, Andrea Pappacoda wrote: > The upstream name is "muon", but this package and /usr/bin/ name is already > used by KDE Muon, a [dead] synaptic alternative. > > I'm not sure how to handle this conflict; naming the Debian package "muon- > meson" or "muon-build" se

Re: Epoch for node-markdown-it

Hi, On Fri, 19 Aug 2022, at 16:37, Jonas Smedegaard wrote: > Quoting Yadd (2022-08-19 10:21:17) >> some months ago, a bad upstream tag changed node-markdown-it version to >> 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version >> into 1:13.0.1 > > Since upstream is already at

Re: Epoch for node-markdown-it

Quoting Yadd (2022-08-19 10:21:17) > some months ago, a bad upstream tag changed node-markdown-it version to > 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version > into 1:13.0.1 Since upstream is already at 10, is it unlikely that they will reach 22 in the foreseeable futur

Re: Automatic trimming of changelogs in binary packages

Le jeudi 18 août 2022, 19:18:35 UTC Gioele Barabucci a écrit : > Hello, > > in 2020 there was a brief discussion on debian-devel@ about trimming > changelogs [1,2]. > > Now there is a working implementation of said functionality in > `dh_installchangelogs` [3]. Could you stress on the mapage that

Re: Automatic trimming of changelogs in binary packages

On Fri, 2022-08-19 at 12:44 +0200, Philip Hands wrote: > Ansgar writes: > > >  - Having to spawn an external command ("dpkg --show-changelog") just > >    to access a file is more complicated. > > The fact that it currently needs to dug out of the main data archive > rather than the control arch

Re: Automatic trimming of changelogs in binary packages

Michael Biebl writes: > Am 19.08.22 um 10:35 schrieb Philip Hands: >> Paul Wise writes: >> >>> On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: >>> Does anybody have objective objections against activating automatic changelog trimming in binary packages? >>> >>> Before we co

Re: Automatic trimming of changelogs in binary packages

Ansgar writes: > - Having to spawn an external command ("dpkg --show-changelog") just >to access a file is more complicated. The fact that it currently needs to dug out of the main data archive rather than the control archive to show the user changes at install time seemed like a decent rea

Re: Automatic trimming of changelogs in binary packages

On Fri, Aug 19, 2022 at 09:01:22AM +0800, Paul Wise wrote: > Before we consider enabling this by default, first we need a way for > `apt changelog` to download the full changelog rather than loading the > changelog from /usr/share/doc in the currently installed package. You can tell apt to ignore

Re: Automatic trimming of changelogs in binary packages

On 19/08/22 11:31, Michael Biebl wrote: I guess this could be solved by dpkg creating symlinks from the "master copy" which is per-source to /usr/share/doc/$binpkg/ Maybe the "master copy" could be in `/usr/share/doc/src:$pkg/`? /usr/share/doc/openssh-{client,server}/X → /usr/share/doc/src:o

Re: Automatic trimming of changelogs in binary packages

On Fri, 2022-08-19 at 09:06 +0200, Michael Biebl wrote: > If we turn on changelog trimming by default, we should probably also > turn on apt downloading the changelogs by default. I think the default apt behaviour should be as it is now, show the installed changelog (with the footer suggested by

Re: Automatic trimming of changelogs in binary packages

Am 19.08.22 um 10:42 schrieb Ansgar: On Fri, 2022-08-19 at 10:35 +0200, Philip Hands wrote: P.S. BTW the change Guillem suggests seems like a good idea anyway:    treating changelogs as control files. I'm interested: why? What makes Debian's changelog different from other documentation

Re: Automatic trimming of changelogs in binary packages

Am 19.08.22 um 10:35 schrieb Philip Hands: Paul Wise writes: On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: Does anybody have objective objections against activating automatic changelog trimming in binary packages? Before we consider enabling this by default, first we need a wa

Re: Automatic trimming of changelogs in binary packages

On 19/08/22 10:35, Philip Hands wrote: How about making the end of the trimmed file be a standard footer including a hint about how one can get hold of the rest of the changelog, and then have `apt changelog` look out for that footer in the local copies in order to know that they've been trimme

Re: Automatic trimming of changelogs in binary packages

On Fri, 2022-08-19 at 10:35 +0200, Philip Hands wrote: > P.S. BTW the change Guillem suggests seems like a good idea anyway: >    treating changelogs as control files. I'm interested: why? What makes Debian's changelog different from other documentation such as the upstream changelog, release

Re: Automatic trimming of changelogs in binary packages

Paul Wise writes: > On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: > >> Does anybody have objective objections against activating automatic >> changelog trimming in binary packages? > > Before we consider enabling this by default, first we need a way for > `apt changelog` to download

Epoch for node-markdown-it

Hi, some months ago, a bad upstream tag changed node-markdown-it version to 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version into 1:13.0.1 Cheers, Yadd

Re: Automatic trimming of changelogs in binary packages

Il 19/08/2022 09:43, julien.pu...@gmail.com ha scritto: Le vendredi 19 août 2022 à 09:04 +0200, Fabio Fantoni a écrit : Il 19/08/2022 03:01, Paul Wise ha scritto: On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: Does anybody have objective objections against activating automatic cha

Re: Automatic trimming of changelogs in binary packages

Am 19.08.22 um 09:04 schrieb Fabio Fantoni: I also use many times the changelog view on packages.debian.org, it show the full changelog from source and will still show the full changelog? Correct. The changelogs linked from packages.debian.org are from https://metadata.ftp-master.debian.or

Re: Automatic trimming of changelogs in binary packages

Le vendredi 19 août 2022 à 09:04 +0200, Fabio Fantoni a écrit : > Il 19/08/2022 03:01, Paul Wise ha scritto: > > On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: > > > > > Does anybody have objective objections against activating > > > automatic > > > changelog trimming in binary package

Re: Automatic trimming of changelogs in binary packages

Il 19/08/2022 03:01, Paul Wise ha scritto: On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: Does anybody have objective objections against activating automatic changelog trimming in binary packages? Before we consider enabling this by default, first we need a way for `apt changelog`

Re: Automatic trimming of changelogs in binary packages

On Fri, 19 Aug 2022 00:46:21 +0200, Guillem Jover wrote: My objections from that time still stand: I would also like to highlight David Kalnischkies reply: Dear Gui

Re: Automatic trimming of changelogs in binary packages

Hi Paul Am 19.08.22 um 03:01 schrieb Paul Wise: On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: Does anybody have objective objections against activating automatic changelog trimming in binary packages? Before we consider enabling this by default, first we need a way for `apt cha