Re: abigail-tools instead of dpkg-gensymbols ?

Hi! On Tue, 2025-09-16 at 13:39:53 +0200, Jérémy Lal wrote: > Le mar. 16 sept. 2025 à 09:28, Guillem Jover a écrit : > > I think using abigail for ABI tracking would be great, yes, but I don't > > think it looks like a good fit for dependency tracking TBH. > > > &

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

Hi! On Tue, 2025-09-16 at 10:20:43 -0700, H.J. Lu wrote: > On Tue, Sep 16, 2025 at 9:26 AM Edgecombe, Rick P wrote: > > On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote: > > > > I'm not aware of any current public activities to enable userspace > > > >

Re: abigail-tools instead of dpkg-gensymbols ?

Hi! On Tue, 2025-09-16 at 14:26:46 +0200, Guillem Jover wrote: > On Tue, 2025-09-16 at 13:39:53 +0200, Jérémy Lal wrote: > > Le mar. 16 sept. 2025 à 09:28, Guillem Jover a écrit : > > > I think using abigail for ABI tracking would be great, yes, but I don't > > >

Re: abigail-tools instead of dpkg-gensymbols ?

Hi! On Mon, 2025-09-15 at 17:45:15 +0200, Simon Chopin wrote: > On lun. 15 sept. 2025 17:35:26, Jérémy Lal wrote: > > following a remark done by someone during t64 transition, > > I wonder if abigail-tools could be a better way to track symbols changes ? Matthias Klose during DebConf25 suggested

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

<https://lists.debian.org/debian-devel/2025/09/msg00059.html>. ] On Sun, 2025-09-07 at 13:14:55 +0200, Florian Weimer wrote: > * Guillem Jover: > > But, if the current IBT approach seems undesirable, I'd still be open to > > switch to -fcf-protection=return for now, and

Re: Action on old unreproducible bug

Hi! On Sat, 2025-09-13 at 13:14:02 +0200, Antoine Le Gonidec wrote: > Le Sat, Sep 13, 2025 at 01:31:49PM +0300, Alexandru Mihail a écrit : > > This is more of a philosophical question. Do I close or keep trying to > > reproduce (unlikely) ? It happened in a very niche situation anyway. > I would

gcc-on-diet (was Re: Size of base system)

Hi! On Sat, 2025-09-13 at 13:52:06 +0900, Simon Richter wrote: > > Hm, seems to be gcc, specifically cc1, cc1plus and lto1, so this > > is less of an issue for the base system as well. > > Ah, known issue: #1113931 As has been mentioned elsethread this is a recurring thing, so for some time, I'v

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

5 a las 17:47, Guillem Jover escribió: > > On Wed, 2025-09-03 at 16:24:50 +0200, Marcos Del Sol Vives wrote: > >> Package: dpkg-dev > >> Version: 1.22.21 > >> Priority: wishlist > >> X-Debbugs-Cc: debian-devel@lists.debian.org > > So, disabling the full C

Re: RFC: Consequences of redesign of .deb signatures

Hi! On Wed, 2025-09-03 at 23:59:05 +0300, Peter Pentchev wrote: > On Wed, Sep 03, 2025 at 09:35:12PM +0200, Philipp Kern wrote: > > On 9/2/25 1:55 PM, Guillem Jover wrote: > > > And IMA has indeed the same exact problem, where I'm also not convinced > > > at all a

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

Hi! On Wed, 2025-09-03 at 16:24:50 +0200, Marcos Del Sol Vives wrote: > Package: dpkg-dev > Version: 1.22.21 > Priority: wishlist > X-Debbugs-Cc: debian-devel@lists.debian.org > Currently, on amd64 and i386 as of Trixie, packages are being built by > default with -fcf-protection=full. This result

Re: deb822 sources.list -> Use the 'Signed-By' field?

Hi! On Tue, 2025-09-02 at 14:01:42 +0200, Roland Clobus wrote: > Just before trixie was released, the warning about the deb822 format > for sources.list was removed, now is the time to implement it > properly for forky. > > Recently a MR was prepared for live-build [1] (the generator of the > liv

Re: RFC: Consequences of redesign of .deb signatures

Hi! On Tue, 2025-09-02 at 11:16:56 +0200, Philipp Kern wrote: > On 9/1/25 1:23 PM, Guillem Jover wrote: > > * Make the format extensible to other signature formats or workflows > > (such as x509, secure-boot, IMA, etc., even if there's currently no > > intent

Re: RFC: Consequences of redesign of .deb signatures

Hi! On Mon, 2025-09-01 at 13:41:55 +0200, Simon Josefsson wrote: > Guillem Jover writes: > > * Make the format extensible to other signature formats or workflows > >(such as x509, secure-boot, IMA, etc., even if there's currently no > >intention to add suppor

Re: RFC: Consequences of redesign of .deb signatures

Hi! On Mon, 2025-09-01 at 14:34:33 -0500, Steven Robbins wrote: > > The current support for .deb signatures (as implemented by debsigs > > and debsig-verify, which dpkg can be configured to call by disabling > > the «no-debsig» configuration option), has multiple limitations. > > > > The followin

RFC: Consequences of redesign of .deb signatures

Hi! The current support for .deb signatures (as implemented by debsigs and debsig-verify, which dpkg can be configured to call by disabling the «no-debsig» configuration option), has multiple limitations. The following are the main redesign objectives, which try to fix those limitations: * Make

Re: Rules-Requires-Root, inconsistency in policy?

Hi! On Thu, 2025-08-28 at 21:58:54 +0200, Robin Gustafsson wrote: > With `Rules-Requires-Root: no` as the new default, The default only when using dpkg-buildpackage. > as reflected in > policy section 5.6.31, is the last paragraph of policy section > 4.9(.0) still correct? > > """ > The builder

Re: Maintaining delegations in Git (Was: Updating the FTP Master delegation)

Hi! On Fri, 2025-08-22 at 10:16:39 +0200, Andreas Tille wrote: > Am Thu, Aug 21, 2025 at 03:19:31PM +0200 schrieb Guillem Jover: > > I see there are already some in: > > > > https://salsa.debian.org/debian-dpl/dpl-helpers > > Good catch! I noticed those texts dif

Re: Updating the FTP Master delegation

Hi! On Thu, 2025-08-21 at 08:13:33 +0200, Andreas Tille wrote: > Am Wed, Aug 20, 2025 at 06:22:57PM +0100 schrieb Sean Whitton: > > This is the third or fourth time this has happened with the Policy > > delegation! > > Thank you for pointing this out. I did circulate the text for review, > but u

Re: Please check open Merge Requests before your next upload

Hi! [ Not disputing that review is a substantial effort. ] On Sun, 2025-08-17 at 22:33:16 -0400, Theodore Ts'o wrote: > You could just make the change yourself, and then do a "git commit > --amend", but then the MR won't get closed automatically, becaue the > forge won't recognize the modified co

Re: mixing a cherry-pick workflow with merge requests

Hi! On Mon, 2025-08-18 at 09:47:03 +0100, Simon McVittie wrote: > On Mon, 18 Aug 2025 at 08:57:03 +0200, Marc Haber wrote: > > Additionally, is there a way to accept parts of an MR in Gitlab? > > Not through the web UI, but you can `git cherry-pick` as usual, and > then (ask the contributor to) r

dupload Debian salsa MRs and/or CI checks hook (was: Re: Please check open Merge Requests before your next upload)

Hi! On Sun, 2025-08-17 at 16:46:25 +0900, Charles Plessy wrote: > Le Sun, Aug 17, 2025 at 12:18:57AM -0700, Otto Kekäläinen a écrit : > > How about this strategy: instead of disabling or ignoring Merge > > Requests on Salsa, take a peek at them at least once before uploading > I only see this wor

Re: tooling to perform updates to many packages in a team?

Hi! On Tue, 2025-07-29 at 09:35:15 +0200, Lucas Nussbaum wrote: > I will be looking into doing some mass updates/cleanup in the context of > the Ruby team, and was wondering: what are the useful tools in that > case? > > I'm aware of: > - the salsa CLI tool (in devscripts) > - the glab package >

Re: Bug#1107670: ITP: condense-json -- Python function for condensing JSON using replacement strings

Hi! On Wed, 2025-06-11 at 13:43:51 -0400, Antoine Beaupre wrote: > Package: wnpp > Severity: wishlist > Owner: Antoine Beaupre > X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org > * Package name: condense-json > Version : 0.1.3 > Upstream Contact: Simon

Re: Dropping awk?

Hi! On Mon, 2025-05-12 at 22:52:53 +0200, Simon Josefsson wrote: > Marco d'Itri writes: > > On May 12, Simon Josefsson wrote: > > > Having some mechanism to create package-specific users seems like one > > > useful goal, and I don't understand why each package has to write > > > scripts to invok

Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

Hi! On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote: > Being one of those on the list, I'm even more confused than I'd be about > this anyway. Ok, let me try to clarify, then! > So those people you listed: > > * Did they something wrong (although certainly with best intentions)? I

Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

Hi! On Sun, 2025-03-23 at 18:46:37 -0400, Robert Edmonds wrote: > Guillem Jover wrote: > > Not all of these issues are equally "bad" from a Debian point of view, > > but all are probably bad for the certificate owners, as it might imply > > that people cannot ve

Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

Hi! On Thu, 2025-03-20 at 10:55:16 +0900, Charles Plessy wrote: > sorry but I am confused... can you explain at a beginner level what is the > difference between a certificate and a "key" in the sense it is used in the > Developers Reference? Ah, sorry, the OpenPGP working group and as part of th

BTS not unmangling quoting markers with format=flowed (was: Re: Change the expectation that emails should wrap at 80 characters)

Hi! On Sun, 2025-03-16 at 18:55:52 +0100, Guillem Jover wrote: > On Sun, 2025-03-16 at 18:18:58 +0100, Guillem Jover wrote: > > […] > > such as: > > > > # On time+3, Carol wrote: > > # >On time+2, Bob wrote: > > # >>On time+1, Alice wrote:

Re: Change the expectation that emails should wrap at 80 characters

Hi! On Sun, 2025-03-16 at 18:18:58 +0100, Guillem Jover wrote: > […] > such as: > > # On time+3, Carol wrote: > # >On time+2, Bob wrote: > # >>On time+1, Alice wrote: > # >>>Some long reply line that supposedly gets wrapper at 7x chars or > #

Re: Change the expectation that emails should wrap at 80 characters

Hi! On Thu, 2025-02-27 at 13:29:59 +, Colin Watson wrote: This thread did, however, cause me to work out how to configure my mailer to send format=flowed, since it does look as though that's somewhat nicer for receivers who aren't using the same kind of dinosaur setup as I am, and support se

Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st

Hi! On Tue, 2025-02-25 at 08:14:52 -0800, Otto Kekäläinen wrote: > Salsa CI has had for many years the job 'missing-breaks' that > complements piuparts by checking that the files a package introduce > don't clash with files shipped by any other package in the > distribution without having proper B

Bug#1098361: ITP: golang-github-ergochat-readline -- readline implementation in pure Go

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-ergochat-readline Version : 0.1.3-1 Upstream Author : ergo.chat * URL : https://github.com/ergochat/readline * License : Expat Programming Lang: Go Description

Bug#1095156: ITP: golang-github-xyproto-randomstring -- generate random strings

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-xyproto-randomstring Version : 1.2.0-1 Upstream Author : Alexander F. Rødseth * URL : https://github.com/xyproto/randomstring * License : BSD-3-clause Programming Lang: Go

Re: Invalid check in debian/patches

Hi! On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote: > On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote: > > But also, in this particular case, it's not the issue of the spec but of a > > particular tool trying to enforce the rule. > > > > I'll file a bug to fix it. > I fin

Re: DEP-14: Default branch name 'debian/latest' objections?

On Thu, 2025-01-23 at 17:06:04 -0800, Otto Kekäläinen wrote: > Current https://dep-team.pages.debian.net/deps/dep14/ states that the > default Debian branch name is 'debian/latest': > > > In Debian this means that uploads to unstable and experimental should be > > prepared either in > > the debia

Re: DEP-14: Default branch name 'debian/latest' objections?

Hi! On Mon, 2025-01-27 at 06:28:59 -0600, G. Branden Robinson wrote: > At 2025-01-27T12:27:12+0100, IOhannes m zmölnig (Debian GNU|Linux) wrote: > > as for the original subject of this thread: what's actually wrong with > > 'debian/main' instead of 'debian/latest'? i personally do not really > >

Re: Is HURD's lack of HOST_NAME_MAX and PATH_MAX a good architectural approach

Hi! On Mon, 2025-01-20 at 13:21:32 -0700, Sam Hartman wrote: > TL;DR: Is it time for the rest of Debian to stop conforming to HURD's > lack of maximums for path and hostname? By thispoint I think we > recognize those lack of maximums as an anti-pattern for DOS prevention > and other security reaso

Re: How to conditionally patch a package based on architecture with debhelper?

Hi! On Thu, 2025-01-16 at 13:26:39 -0500, Chris Knadle wrote: > Looking at the manpage for dpkg-architecture, the variable I may want to > conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH. Others have already given pointers about this confusion. I'm more interested in t

Re: Removing manpages from libpam-modules to improve multi-arch

Hi! On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote: > My proposal is to move the man pages into libpam-doc. > I'm not actually convinced that normal Debian users need man pages for > all the pam modules on all Debian systems, and a suggests relationship > should be sufficient. > If people

Re: gettext 0.23.x

Hi! On Mon, 2025-01-06 at 16:45:54 +0100, Simon Josefsson wrote: > Santiago Vila writes: > > Note for Guillem: I've included your suggested fix in the bug template. Great, thanks! > I don't think we should patch upstream code for things that aren't clear > upstream bugs. Patching upstream code

Re: gettext 0.23.x

Hi! On Sun, 2025-01-05 at 19:37:44 +0100, Santiago Vila wrote: > El 5/1/25 a las 19:15, Guillem Jover escribió: > > I think this indicates a problem in the upstream autotools support, > > and it might be better to try to fix that instead of adding what seems > > like a work

Re: gettext 0.23.x

Hi! On Sun, 2025-01-05 at 17:44:33 +0100, Santiago Vila wrote: > I've just uploaded gettext 0.23.1-0.1 for experimental. Ah, great, thanks! > In most cases, the failure is like this: > > make[3]: Entering directory '/<>/po' > *** error: gettext infrastructure mismatch: using a Makefile.in.in fr

Re: Proposal: Optional `Priority: optional` and changed `Section` fall-back

Hi! On Sun, 2024-12-15 at 09:27:06 +0100, Niels Thykier wrote: > Historically, if you omitted `Priority` and `Section` from your > package, `dpkg` would warn and use `-` or `unknown` as placeholder > when it absolutely needed a value for these fields in the `.dsc` and > the `.changes` file. The re

Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?

Hi! On Sat, 2024-12-28 at 20:28:30 +0100, Gioele Barabucci wrote: > There is a possible related, but independent, optimization that has the > chance to significantly reduce dpkg install's time up to 90%. > > There is PoC patch [1,2] to teach dpkg to reflink files from data.tar > instead of copyin

Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?

Hi! [ This was long ago, and the following is from recollection from the top of my head and some mild «git log» crawling, and while I think it's still accurate description of past events, interested people can probably sieve through the various long discussions at the time in bug reports a

Filesystem snapshotting in dpkg (was Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?)

Hi! On Fri, 2024-12-27 at 12:46:02 -0500, Jonathan Kamens wrote: > On 12/27/24 7:34 AM, Geert Stappers wrote: > > Yeah, it feels wrong that dpkg gets file system code, gets code for one > > particular file system. > > I disagree. If there is a significant optimization that dpkg can implement > th

Re: Moving apt (and hence bootstraps) from GnuPG to Sequioa (via gpgv-sq)

Hi! On Mon, 2024-12-23 at 13:20:39 +0100, Chris Hofstaedtler wrote: > * Julian Andres Klode [241223 12:49]: > > Something still pulls in gpgv there > > which is unfortunate, we lack a 5MB savings. I think that would be gpgv being Priority: important, which makes debootstrap and friends pull it i

Re: Building with many cores without OOM

Hi! On Thu, 2024-12-05 at 09:23:24 +0100, Helmut Grohne wrote: > On Wed, Dec 04, 2024 at 02:03:29PM +0100, Guillem Jover wrote: > > On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote: > > > For one thing, I propose extending debhelper to provide > > > --min-ra

Re: Should l10n packages be Recommends or Suggests?

Hi! On Fri, 2024-12-06 at 09:22:43 -, Sune Vuorela wrote: > Though I do also think we have a hole in our dependency system here. I think most of the needed pieces are there already though. > if I set my system up to be in entish, I don't want to chase translation > files all over the package

Re: Building with many cores without OOM

Hi! On Wed, 2024-12-04 at 14:37:45 +, Stefano Rivera wrote: > Hi Guillem (2024.12.04_13:03:29_+) > > > Are there other layers that could reasonably be used to implement a more > > > general form of parallelism limiting based on system RAM? Ideally, we'd > > > consolidate these implementati

Re: Building with many cores without OOM

Hi! On Wed, 2024-12-04 at 14:03:30 +0100, Guillem Jover wrote: > On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote: > > Are there other layers that could reasonably be used to implement a more > > general form of parallelism limiting based on system RAM? Ideally, we&#x

Re: Building with many cores without OOM

Hi! On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote: > I am one of those who builds a lot of different packages with different > requirements and found that picking a good parallel=... value in > DEB_BUILD_OPTIONS is hard. Go too low and your build takes very long. Go > too high and you

Re: Freestanding arch

Hi! On Sun, 2024-11-24 at 16:09:42 +, Bastien Roucariès wrote: > Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit : > > I plan to implement freestanding architecture specification. > > Following Toulouse debian mini debconf and javascript presentation it will > > be really

Re: RFC: "Recommended bloat", and how to possibly fix it

Hi! On Tue, 2024-11-05 at 17:35:59 -0600, Aaron Rainbolt wrote: > With all this in mind, I'd like to call some attention to a feature > request made by Patrick Schleizer some time ago, whom I've copied on > this email. The feature request suggests the addition of a new field to > Debian's binary d

Re: DEP-0, DEP0 or DEP 0?

Hi! On Thu, 2024-11-14 at 00:48:18 -0800, Otto Kekäläinen wrote: > I am the kind of person that gets hugely annoyed by things like this. > Is anyone else feeling it? >· > Can we agree on calling Debian Enhancement Proposals DEP-N with a dash? I'm also all for consistency, although I'm in general

[Summary]: Supporting alternative zlib implementations

Hi! [ I'll try to summarize the current discussion and status, what might be blockers, and a potential incremental way forward. ] On Wed, 2024-09-25 at 10:48:50 +0200, Mark Brown wrote: > On Tue, Sep 24, 2024 at 05:45:49PM +0200, Guillem Jover wrote: > > On Tue, 2024-09-24 at

Re: Re: It makes no sense to link vmlinuz and initramfs to the root directory

Hi! On Tue, 2024-11-12 at 11:02:53 +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Hans (2024-11-12 09:35:08) > > However, maybe a link is alo no more needed, even with a seperated /boot > > partition. > > It's just a symlink. What's the harm? For me, the default location of the symlink

Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?

Hi! On Thu, 2024-11-07 at 02:01:49 +, Colin Watson wrote: > On Thu, Nov 07, 2024 at 02:42:08AM +0100, Guillem Jover wrote: > > Given that I assume the current (non-retracted) upstream version is > > going to be close to surpass the retracted one, I'd go for the +really &g

Re: Rebuilds to enable PAC and BTI support on arm64

Hi! On Wed, 2024-11-06 at 17:28:38 +0500, Andrey Rakhmatullin wrote: > On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote: > > As a final thought, given that new toolchain versions bring multiple > > improvements over the years it's perhaps worth thinking about rebuilding > > the archi

Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?

Hi! On Thu, 2024-11-07 at 01:15:08 +, Colin Watson wrote: > Source: python-catalogue > Version: 2.1.0-6 > Severity: normal > X-Debbugs-Cc: Andreas Tille , debian-devel@lists.debian.org > https://pypi.org/project/catalogue/#history shows that 2.1.0 was yanked > from PyPI, but it's what we curr

Re: efficient way to detect linker script files?

Hi! On Tue, 2024-10-22 at 23:00:29 +0200, Serafeim (Serafi) Zanikolas wrote: > I'd like to discover all installed linker scripts, for the purposes of > #823531 (check for broken linker scripts files). it's not clear to me > that there's a convention I could rely on to avoid brute forcing > filetyp

Re: Epoch for src:fuse-ext2 to replace src:fuse-umfuse-ext2's fuseext2 binary

Hi! On Tue, 2024-10-22 at 00:00:21 +0200, Ben Hutchings wrote: > On Mon, 2024-10-21 at 00:49 +0200, наб wrote: > > On Sun, Oct 20, 2024 at 11:39:36PM +0200, Ben Hutchings wrote: > > > On Sun, 2024-10-20 at 20:03 +0200, наб wrote: > > > > I'd like to use an epoch so I'm asking for consensus per pol

Re: Bug#1085388: ITP: einops -- Flexible and powerful tensor operations for readable and reliable code.

Hi! On Fri, 2024-10-18 at 12:03:46 -0700, Mo Zhou wrote: > Package: wnpp > Severity: wishlist > Owner: Mo Zhou > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name    : einops > * URL : https://einops.rocks > * License : MIT/Expat >   Programming Lang: Python >  

Re: Bug#1081111: ITP: sphinx-toolbox -- Box of handy tools for Sphinx

Hi! On Sun, 2024-09-08 at 08:55:58 +0530, Kathara Sasikumar wrote: > Package: wnpp > Severity: wishlist > Owner: Kathara Sasikumar > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: sphinx-toolbox > Version : 3.8.0 > Upstream Contact: Dominic Davis-Foster > * URL

Re: Bug#1078734: ITP: legacycrypt -- The legacycrypt module is a standalone version of https://docs.python.org/3/library/crypt.html (deprecated), to ease 3.13 transition.

Hi! On Wed, 2024-08-14 at 20:47:56 -0500, eevelweezel wrote: > Package: wnpp > Severity: wishlist > Owner: eevelweezel > X-Debbugs-Cc: debian-devel@lists.debian.org, eevel.wee...@gmail.com > * Package name: legacycrypt > Version : 0.0.3 > Upstream Contact: Christian Heimes > * U

Re: Bug#1085206: ITP: evalidate -- Validation and secure evaluation of untrusted Python expressions

Hi! On Wed, 2024-10-16 at 11:00:31 +0100, Colin Watson wrote: > Package: wnpp > Severity: wishlist > Owner: Colin Watson > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: evalidate > Version : 2.0.3 > Upstream Contact: Yaroslav Polyakov > * URL : http

Re: Bug#1085127: ITP: go-nmap -- Nmap XML parsing library for Go (library)

Hi! On Mon, 2024-10-14 at 22:20:11 -0300, Marcos Rodrigues de Carvalho (aka oday) wrote: > Package: wnpp > Severity: wishlist > Owner: "Marcos Rodrigues de Carvalho (aka oday)" > X-Debbugs-Cc: debian-devel@lists.debian.org, marcosrcarvalh...@gmail.com > > * Package name: go-nmap > Version

Re: signify and signify-openbsd names

Hi! On Tue, 2024-10-08 at 09:01:06 +0200, Simon Josefsson wrote: > 1) Take current non-OpenBSD 'signify' source package and upload NEW > 'signify-mail' with d/control modified as: > > Source: signify-mail > ... > Package: signify-mail > Replaces: signify (<= 1.14-7) > > Do we need 'Breaks: signi

Re: signify and signify-openbsd names

Hi! On Wed, 2024-10-09 at 19:42:45 +0200, Ben Hutchings wrote: > On Wed, 2024-10-09 at 10:26 +0100, Jonathan Dowland wrote: > > On Mon Oct 7, 2024 at 8:58 AM BST, Marc Haber wrote: > > > P.S.: Isnt it about time to rename exim4 to exim? > > > > Or apache2 to apache? > The ASF is responsible for

Re: ITS: aiocoap

Hi! On Tue, 2024-10-08 at 11:37:52 +0200, Mazen Neifer wrote: > Source: aiocoap > Severity: important > I would like to salvage this package because it is no more maintained. > > Last maintainer upload was more than 5 years ago. > Last commit to git on salsa was on February 2019. > > If no obje

Re: Alternative signature mechanisms for upstream source verification

Hi! On Fri, 2024-10-04 at 18:21:01 +, Stefano Rivera wrote: > Picking up a thread that started on debian-pyt...@lists.debian.org: > https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea > > Upstreams that care about supply chain security have been building > mechanisms to authenti

Re: Bug#1082850: ITP: golang-github-mitchellh-pointerstructure -- Addressing and modifying values in Go structures using a string syntax

Hi! On Fri, 2024-09-27 at 12:28:51 +, Francisco Vilmar Cardoso Ruviaro wrote: > Package: wnpp > Severity: wishlist > Owner: Francisco Vilmar Cardoso Ruviaro > X-Debbugs-Cc: debian-devel@lists.debian.org, vil...@debian.org > * Package name: golang-github-mitchellh-pointerstructure > Ver

Re: Supporting alternative zlib implementations

Hi! On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > * Guillem Jover [2024-09-24 17:45]: > > Personally, I think fully migrating from zlib to zlib-ng would sound > > great (even for trixie), but I guess we can take it slow if you do not > > feel confident or ha

Re: Supporting alternative zlib implementations

Hi! On Tue, 2024-09-24 at 15:58:10 +0200, Mark Brown wrote: > In the past I've pushed back on doing anything here since zlib is > essential and it seemed better to be consistent over the ecosystem than > to use a more niche implementation, and some of the early optimisation > efforts had not worke

Re: Question about library package splitting

Hi! On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote: > Here comes the problem: libmodsecurity3 has two types of collection stores: > in-memory and LMDB. It's VERY important: you MUST decide the type of > choosed backend in compilation time, later you can't change it in runtime! I think

Re: Should OpenSSL/ libssl3 depend on brotli?

Hi! On Sat, 2024-09-07 at 00:12:58 +0200, Sebastian Andrzej Siewior wrote: > Is it okay for libssl3 do depend on libbrotli? It would increase minimal > installs by ~900KiB on amd64. > tl;dr > coreutils build-depends on libssl-dev which makes libssl essential. > libssl already supports compression

Bug#1080429: ITP: golang-github-mostynb-go-grpc-compression -- Go gRPC encoding wrappers for compression algorithms missing from google.golang.org/grpc

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-mostynb-go-grpc-compression Version : 1.2.3-1 Upstream Author : Mostyn Bramley-Moore * URL : https://github.com/mostynb/go-grpc-compression * License : Apache-2.0 Programming

Bug#1080428: ITP: golang-github-go-viper-mapstructure -- decode generic map values into native Go structures and vice versa

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-go-viper-mapstructure Version : 2.1.0-1 Upstream Author : Viper * URL : https://github.com/go-viper/mapstructure * License : Expat Programming Lang: Go Description

Bug#1080354: ITP: golang-opentelemetry-collector -- OpenTelemetry Collector (library)

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-opentelemetry-collector Version : 0.108.1-1 Upstream Author : OpenTelemetry - CNCF * URL : https://github.com/open-telemetry/opentelemetry-collector * License : Apache-2.0

Bug#1080351: ITP: golang-github-bboreham-go-loser -- Loser Tree data structure, for fast k-way merge

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-bboreham-go-loser Version : 0.0~git20230920.fcc2c21-1 Upstream Author : Bryan Boreham * URL : https://github.com/bboreham/go-loser * License : Apache-2.0 Programming Lang: Go

Bug#1080349: ITP: golang-github-victoriametrics-easyproto -- simple building blocks for protobuf marshaling and unmarshaling

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-victoriametrics-easyproto Version : 0.1.4-1 Upstream Author : VictoriaMetrics * URL : https://github.com/VictoriaMetrics/easyproto * License : Apache-2.0 Programming Lang: Go

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! On Sat, 2024-07-06 at 13:13:48 +0200, Alexandre Detiste wrote: > Le mar. 2 juil. 2024 à 14:37, Guillem Jover a écrit : > > On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote: > > > On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote: > > > >

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! [ Mostly trying to clarify some of my earlier comments. ] On Fri, 2024-06-07 at 17:20:29 +0100, Simon McVittie wrote: > On Fri, 07 Jun 2024 at 14:32:14 +0200, Guillem Jover wrote: > > I'm a non-native speaker, who has been involved > > in l10n for a long time, while a

Re: Q: Ubuntu PPA induced version ordering mess.

Hi! On Tue, 2024-07-02 at 03:32:53 +0200, Guillem Jover wrote: > On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote: > > Quite. People are quite resistant to spoiling neat version numbers > > with epochs, and no-one likes them, but they don't do any actual harm > > (exce

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote: > On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote: > > On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote: > > > Maybe a compromise would be to at least mandate some UTF-8 locale. > &g

Re: Mandatory LC_ALL=C.UTF-8 during package building

ounter to l10n work, or perhaps to switch to a subset of the locale settings. Niels? Thanks, Guillem From 94c2540fe290ffaa70680d21725e3541642ab2f2 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Tue, 2 Jul 2024 03:34:35 +0200 Subject: [PATCH] dpkg-buildpackage: Require an UTF-8 (or ASCII) locale

Re: Q: Ubuntu PPA induced version ordering mess.

Hi! On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote: > On 2024-07-01 23:59 +0200, Alec Leamas wrote: > > But this is not about third parties, it's about upstream which publishes PPA > > packages. So far these are by far the most used Linux packages. > > > > I also hesitate to add an epoch, aft

Re: Reviving schroot as used by sbuild

Hi! On Tue, 2024-06-25 at 09:32:21 -0700, Russ Allbery wrote: > Simon McVittie writes: > > Persisting a container root filesystem between multiple operations comes > > with some serious correctness issues if there are "hooks" that can modify > > it destructively on each operation: see

Re: Enabling some -Werror=format* by default?

Hi! On Mon, 2024-06-10 at 18:01:58 +0200, Helmut Grohne wrote: > Ideally, we'd not just do a rebuild with the flags, but also do a > rebuild without and then compare the binary .debs. In the event that we > misguide configure, we expect the .debs to differ and otherwise to equal > due to the work

Re: Enabling some -Werror=format* by default?

Hi! On Mon, 2024-06-10 at 20:09:21 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote: > > > Do you think it makes sense to add this a flag that enables -Werror=format > > > to dpkg-buildflags(1), before, or after a test rebu

Re: Enabling some -Werror=format* by default?

Hi! On Mon, 2024-06-10 at 16:06:13 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote: > > > We recently increased the time_t size on certain architectures and some > > > packages started failing to build because they were using a format > > > specifi

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! On Thu, 2024-06-06 at 15:31:55 +0100, Simon McVittie wrote: > On Thu, 06 Jun 2024 at 13:32:27 +0300, Hakan Bayındır wrote: > > C, or C.UTF-8 is not a universal locale which works > > for all. > > Sure, and I don't think anyone is arguing that you or anyone else should > set the locale for you

Re: MBF: drop dependencies on system-log-daemon

Hi! On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote: > On 5/27/24 22:18, Simon McVittie wrote: > > So I think your syslogd-is-journald could not be a Provides on the > > existing systemd-sysv package, and would have to be a separate package. > > I'm not sure that the benefit is worth it

Re: New supply-chain security tool: backseat-signed

Hi! On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote: > On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote: > > Right now the preferred form of source in Debian is an upstream-signed > > release tarball, NOT anything from git. > > The preferred form of modification is not simply up for

Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Hi! On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote: > On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote: > > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > > > On 2024-03-29 22:41, Guillem Jover wrote: > > > I think with my upstream hat on I

Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Hi! On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > On 2024-03-29 22:41, Guillem Jover wrote: > > (For dpkg at least I'm pondering whether to play with switching to > > doing something equivalent to «git archive» though, but see above, or > > maybe generate

autoreconf --force not forcing (was Re: Validating tarballs against git repositories)

Hi! On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote: > Let's try to go in detail on how this was done on the build system > side (I'm doing this right now, as previously only had skimmed over > the process). > > The build system hook was planted in the tarball

Re: Some t64 libraries already in testing; I'm confused

Hi! On Sun, 2024-03-31 at 06:54:10 +0200, Andreas Metzler wrote: > On 2024-03-30 Julian Gilbey wrote: > > My very limited understanding of this major transition was that the > > t64 libraries are being held in unstable until (almost) everything is > > ready, at which point there will be a coordin

Re: Validating tarballs against git repositories

Hi! On Fri, 2024-03-29 at 23:53:20 -0600, Antonio Russo wrote: > On 2024-03-29 22:41, Guillem Jover wrote: > > On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote: > >> Had tooling existed in Debian to automatically validate this faithful > >> reproduction, we mig

Re: Validating tarballs against git repositories

Hi! On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote: > This is a vector I've been somewhat paranoid about myself, and I > typically check the difference between git archive $TAG and the downloaded > tar, whenever I package things. Obviously a backdoor could have been > inserted into the

  1   2   3   4   5   6   7   8   9   10   >