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

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

Package: wnpp Severity: wishlist X-Debbugs-Cc: Chris Lamb , Sascha Steinbiss * Package name: keydb Version : 6.3.4 Upstream Contact: https://github.com/Snapchat/KeyDB * URL : https://keydb.dev/ * License : BSD-3-clause Programming Lang: C, C++ Description

Extended description of filesystem namespace clashes

Hi! On Wed, 2024-02-28 at 07:41:50 +0100, Helmut Grohne wrote: > That said, I appreciate your work on analyzing the situation as it also > uncovers tangential problems e.g. where different packages put programs > with different functionality into bin and sbin. It is up to > interpretation of Debia

Re: Package marked for autoremoval due to closed bug? [and 1 more messages]

Hi! On Tue, 2024-03-19 at 10:32:04 +, Ian Jackson wrote: > [2] In my case src:dgit depends on git-buildpackage. The autoremoval > robot wants to remove git-buildpackage because of the time_t bugs > against rpm, xdelta, and pristine-tar. One root cause is that > src:dpkg isn't migrating becau

Re: Another take on package relationship substvars

Hi! On Fri, 2024-02-23 at 17:59:14 -0800, Steve Langasek wrote: > One generic case that this doesn't handle is Essential: yes packages. For > many of these, the ${shlibs:Depends} gets promoted in debian/control to > Pre-Depends, not to Depends. Ah! Good point. I think the particular case of the

Re: time_t progress report

Hi! On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote: > I have coordinated with the gcc maintainer so that we can have the default > flags in gcc-13 changed this week. > > We are therefore targeting Friday for the mass NMUs to unstable though there > is a possibility this won't start un

Re: Another take on package relationship substvars

Hi! On Thu, 2024-02-22 at 23:14:13 +0100, gregor herrmann wrote: > On Thu, 22 Feb 2024 19:32:21 +0100, Niels Thykier wrote: > > If you forget to add a susbtvars that you should added, it is a latent RC > > bug with only a warning from dpkg-gencontrol that you might miss if you grab > > a coffee wh

Re: Another take on package relationship substvars

Hi! On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote: > Our current way of dealing with package relationship substvars such as > ${misc:Depends} has been annoying me for a while. As it is, we are stuck in > this way setup where the "Depends" field in debian/control is de facto > mandatory

Re: Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang

Hi! On Fri, 2024-02-16 at 15:07:55 -0800, Loren M. Lang wrote: > Package: wnpp > Severity: wishlist > Owner: Loren M. Lang > * Package name: golang-github-cheggaaa-pb > Version : 3.1.5-1 > Upstream Author : Sergey Cherepanov > * URL : https://github.com/cheggaaa/pb >

Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

Hi! On Fri, 2024-02-02 at 08:21:57 -0800, Steve Langasek wrote: > Once all of these packages have built in experimental and we have identified > and addressed all adverse interactions with the usrmerge transition, the > plan is: > > - dpkg uploaded to unstable with abi=time64 enabled by default[

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

> are a number of newly-identified packages that fail to compile and have a > > large number of reverse-dependencies. I will continue to work to identify > > false-positives here in the hopes of bringing this count down before pulling > > the trigger on an actual transition. &

SOP migration (was Re: Reaction to potential PGP schism)

Hi! Daniel thanks for all your work on the OpenPGP working group, and on SOP! :) On Wed, 2023-12-20 at 22:16:28 -0500, Daniel Kahn Gillmor wrote: > # What Can Debian Do About This? > > I've attempted to chart one possible path out of part of this situation > by proposing a minimized, simplified

Re: Signature strength of .dsc

Hi! On Fri, 2023-12-01 at 00:20:16 +, Dimitri John Ledkov wrote: > Currently dak requires signatures on .changes & .dsc uploads. .changes with > signatures are publicly announced and then .dsc are published in the > archive with signatures. .changes references .dsc. > > All .dsc have Checksums

Re: New Essential package procps-base

Hi! On Tue, 2023-11-14 at 17:29:01 +1100, Craig Small wrote: > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an Essential > package and only contain pidof. > > Why: > This would bring the pidof varia

Re: Linking coreutils against OpenSSL

Hi! On Thu, 2023-11-09 at 17:38:05 -0500, Benjamin Barenblat wrote: > coreutils can link against OpenSSL, yielding a substantial speed boost > in sha256sum etc. For many years, this was inadvisable due to license > conflicts. However, as of bookworm, coreutils requires GPL-3+ and > OpenSSL is Apac

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

Hi! On Sat, 2023-09-16 at 10:31:20 +0530, Hideki Yamane wrote: > ## More bandwidth > > According to https://www.speedtest.net/global-index, broadband bandwidth > in Nicaragua becomes almost 10x > > - 2012: 1.7Mbps > - 2023: 17.4Mbps Well that page still does not look too great for many othe

Re: Enabling branch protection on amd64 and arm64

Hi! On Sun, 2023-08-27 at 12:51:53 +0200, Guillem Jover wrote: > On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote: > > OK. We're all agreed on that then. Guillem can stick it in the next > > dpkg upload. So this happened, and Johannes reported that this seems to be bre

Re: Enabling -fstack-clash-protection for trixie

Hi! On Sun, 2023-08-06 at 23:25:23 +0200, Moritz Mühlenhoff wrote: > Following the procedure to modify default dpkg-buildflags I propose to > enable -fstack-clash-protection on amd64. The bug for dpkg tracking this > is #918914. > > | -fstack-clash-protection > | Generate code to prevent stack cl

Re: Enabling branch protection on amd64 and arm64

Hi! On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote: > On 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote: > > Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca: > > > On 2022-10-26 08:20, Moritz Mühlenhoff wrote: > > > > I think this should rather be applied early after the Bookw

Re: Issues in the Patch Tagging Guidelines

Hi! [ Started this some days ago and only finished it now, I see Jonathan has covered some parts of this. ] On Thu, 2023-08-10 at 15:42:03 +0200, Lucas Nussbaum wrote: > On 08/08/23 at 01:25 +0200, Guillem Jover wrote: > > Lately I've been updating metadata in patches in packa

Re: Potential MBF: packages failing to build twice in a row

On Wed, 2023-08-09 at 22:10:51 +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Guillem Jover (2023-08-09 20:55:17) > > I think I've mentioned this before, but dpkg-source is supposed to be > > generating reproducible source packages since around the time dpkg-deb >

Re: Potential MBF: packages failing to build twice in a row

Hi! On Wed, 2023-08-09 at 19:55:41 +0200, Johannes Schauer Marin Rodrigues wrote: > I would only consider switching the default if at the same time, some checks > were done that made sure that the result is bit-by-bit identical to the > original. > > The source package is the *input* to sbuild no

Issues in the Patch Tagging Guidelines

Hi! Lately I've been updating metadata in patches in packages I maintain and noticed several issues with the Patch Tagging Guidelines, and after Lucas created the new great patches UDD service [P] and we discussed some other issues there, it looked like the guidelines could do with some fixes and

Re: hardening flags

Hi! On Sat, 2023-07-29 at 16:59:29 +0200, Martin Uecker wrote: > are there any plans to add -fstack-clash-protection to > the hardening flags? See #918914. Thanks, Guillem

Re: systmd-analyze security as a release goal

Hi! On Thu, 2023-07-06 at 18:41:38 +1000, Trent W. Buck wrote: > "Trent W. Buck" writes: > > e.g. I expect "SystemCallArchitectures=native" to break for a lot of > > people (anyone doing dpkg --add-architecture) Yes, see #982456. > Short version: > > • SystemCallArchitectures=native + debian

Re: Policy consensus on transition when removing initscripts.

On Tue, 2023-06-27 at 21:05:57 -0700, Russ Allbery wrote: > Simon Richter writes: > > On 6/28/23 02:31, Russ Allbery wrote: > >> Normally Conflicts is always added with Replaces because otherwise you can > >> have the following situation: > > >> * Package A version 1.0-1 is installed providing fi

Re: 64-bit time_t transition for 32-bit archs: a proposal

ft that can be cleaned up lazily > > What do you think? Yeah, sounds good to me. > On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote: > > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > > > > Hmm, rechecking the script, I think we'd want to at le

Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy

Hi! On Sat, 2023-06-17 at 11:39:51 +0200, Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the bu

Re: 64-bit time_t transition for 32-bit archs: a proposal

Hi! On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote: > > Enabling time64 explicitly is what also had first come to my mind, > > which does not seem too onerous if all the debhelper override > > di

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

Hi! On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote: > Guillem Jover wrote: > >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > >> > […], I'm also dubious about this, and introduces a special case > >> > and complexity that does not se

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote: > > On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > > > === Technical details === > > > > The proposed implementation of

Re: 64-bit time_t transition for 32-bit archs: a proposal

Hi! On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > === Technical details === > > The proposed implementation of this transition is as follows: > > * Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 > by default on 32-bit archs.  (Note that this enables L

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

Hi! On Tue, 2023-04-18 at 17:54:20 -0500, G. Branden Robinson wrote: > At 2023-04-18T16:07:45+0200, Florian Weimer wrote: > > TL;DR: I want to propose a GCC 14 change which will impact > > distributions, so I'd like to gather some feedback from Debian. > > I would appreciate some discussion on th

Re: Dropping debpkg from devscripts (in trixie)

Hi! On Mon, 2023-03-20 at 12:54:18 +, Benjamin Drung wrote: > README for debpkg in devscripts says: "debpkg: A wrapper for dpkg used > by debi to allow convenient testing of packages. For debpkg to work, it > needs to be made setuid root, and this needs to be performed by the > sysadmin -- it

Re: Problems verifying signed github releases (Re: Q: uscan with GitHub)

Hi! On Sun, 2023-02-19 at 18:34:56 +0100, Jens Reyer wrote: > [This is a followup to the thread "Q: uscan with GitHub" at > https://lists.debian.org/debian-devel/2022/10/msg00313.html. I manually set > in-reply-to, but am not sure if it'll work.] > My upstream creates a tarball with git-archive,

Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support

Hi! On Wed, Feb 15, 2023, at 7:51 PM, Fabian Grünbichler wrote: > debcargo, the tool used by the Debian rust team to streamline the work > of transforming upstream crates into Debian source packages generates > d/control entries for librust-* binary packages qualified as arch:any > and M-A:same, i

Re: -ffile-prefix-map option and reproducibility

On Tue, 2023-02-07 at 20:00:06 +0100, Sven Joachim wrote: > On 2023-02-07 17:50 +0100, Guillem Jover wrote: > > On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > >> I suspect this was added to improve reproducibility. Ironically, it makes > >> packages tha

Re: -ffile-prefix-map option and reproducibility

Hi! On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > When building packages, a -ffile-prefix-map option is automatically injected > into CFLAGS. Where does it come from? Since when? This is coming from dpkg-buildflags (in this case probably indirectly via debhelper). AFAICS it was a

Re: Please, minimize your build chroots

On Sun, 2023-01-29 at 12:28:37 +0200, Adrian Bunk wrote: > On Sun, Jan 29, 2023 at 05:00:56AM +0100, Guillem Jover wrote: > > On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote: > > > Removing tzdata from the essential set made sense, and I do see your > > > poi

Re: Please, minimize your build chroots

On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote: > I don't think such arguments are bringing us forward, > we should rather resolve the problem that these differ. > > All/Most(?) packages where they do differ are packages that were until > recently part of the essential set, and since deb

Re: Please, minimize your build chroots

On Sat, 2023-01-28 at 16:32:17 +0100, Adam Borowski wrote: > On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote: > > Unsupported by whom? What is supported or unsupported is explained in > > policy. > > Policy says it must work. Therefore it should be supported (by fixing the > > bugs)

Re: depends-on-obsolete-package lsb-base

On Wed, 2023-01-18 at 18:23:16 +0100, Adam Borowski wrote: > On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote: > > Lintian just started erroring on 'depends-on-obsolete-package > > lsb-base' on many of my packages yesterday. > > It's a very low priority cleanup; the Depends is redun

Re: Please, minimize your build chroots

On Fri, 2022-12-16 at 18:55:42 +0100, Andreas Metzler wrote: > or apt. > > I am wondering if there is point to this or whether policy should be > changed? Is there some value in investing work in having packages > buildable without Prioriry required packages? > > Such installations can only be fo

Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

Hi! On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote: > Package: wnpp > Version: 1.79 > Severity: wishlist > Owner: Juri Grabowski > X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@jugra.de > * Package name: distribution-gpg-keys > Version : 1.7.9 > Upstream Author

Re: R³ by default: not for bookworm

Hi! On Sun, 2022-09-18 at 03:39:43 +0200, Adam Borowski wrote: > A few packages had a value of R³ other than "no" / "binary-targets", > these are deprecated now; bugs filed. Deprecated by who or what? > The process of adding/changing a field in "control" differs between the > three source format

Re: packages expected to fail on some archs

Hi! [ Mostly to summarize the status re dpkg. ] On Sun, 2022-09-11 at 17:08:57 +0200, Samuel Thibault wrote: > The issue we see is that some DDs end up setting a hardcoded list in > the "Architecture" field, rather than just letting builds keep failing > on these archs (and then possibly succeedi

Re: Transition proposal: pkg-config to pkgconf

Hi! On Mon, 2022-08-29 at 15:38:08 +0200, Andrej Shadura wrote: > It seems like the proposal went mostly unnoticed. Any comments, > ideas, anything? I at least read it, and it looked great. But… > Most importantly, I need a green light from the current pkg-config > maintainer (Tollef) to proceed

Re: Automatic trimming of changelogs in binary packages

Hi! On Thu, 2022-08-18 at 21:18:35 +0200, Gioele Barabucci wrote: > in 2020 there was a brief discussion on debian-devel@ about trimming > changelogs [1,2]. My objections from that time still stand: I would also like to highlight D

Re: Done: Switch default from netkit-telnet(d) to inetutils-telnet(d)

Hi! On Sun, 2022-07-17 at 04:18:59 +0200, Guillem Jover wrote: > There's been talk about switching away from netkit-telnet and > netkit-telnetd as the default implementations for some time now, > and replacing them with the ones from inetutils, which is a maintained > pro

Re: RFC: Additions to dpkg's Pre-Depends

Hi! On Wed, 2022-07-06 at 05:13:05 +0200, Guillem Jover wrote: > As per Debian policy §3.5, and given dpkg “Essential: yes” nature, I'm > bringing up the following potential additions to dpkg's Pre-Depends, > and whether there is consensus about each of them individually

Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)

Hi! On Sun, 2022-07-17 at 04:18:59 +0200, Guillem Jover wrote: > There's been talk about switching away from netkit-telnet and > netkit-telnetd as the default implementations for some time now, > and replacing them with the ones from inetutils, which is a maintained > pro

RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)

Hi! There's been talk about switching away from netkit-telnet and netkit-telnetd as the default implementations for some time now, and replacing them with the ones from inetutils, which is a maintained project and does see releases (even though with a long cadence). This has been discussed someho

Re: Bug#1013992: ITP: session-migration -- tool to migrate in user session settings

On Tue, 2022-06-28 at 21:51:44 -0400, Jeremy Bicha wrote: > On Tue, Jun 28, 2022 at 8:07 PM Guillem Jover wrote: > > > Package: session-migration > > > Description: Tool to migrate in user session settings > > > This tool is used to migrate in session user data whe

Re: RFC: Additions to dpkg's Pre-Depends

On Wed, 2022-07-06 at 17:30:22 +0200, Guillem Jover wrote: > > Unless I'm mistaken if dpkg dep on libcap(2) and libaudit, then dpkg > > would transitively dep on both libcap(2) and libcap-ng which seems > > suboptimal. > > Yes, but its an internal implementation

Re: RFC: Additions to dpkg's Pre-Depends

On Wed, 2022-07-06 at 16:45:18 +0200, Andreas Henriksson wrote: > On Wed, Jul 06, 2022 at 05:13:05AM +0200, Guillem Jover wrote: > [...] > > * libaudit-dev > > - Rationale: > > This could allow to add Linux audit support to dpkg on package action > > events

RFC: Additions to dpkg's Pre-Depends

Hi! As per Debian policy §3.5, and given dpkg “Essential: yes” nature, I'm bringing up the following potential additions to dpkg's Pre-Depends, and whether there is consensus about each of them individually and independently. * libmd-dev - Rationale: src:dpkg currently has its embedded MD5

Re: Bug#1008304: ITP: http-nio -- http/s file system provider for Java NIO.2

Hi! On Sat, 2022-03-26 at 14:59:17 +0100, Pierre Gruet wrote: > Package: wnpp > Severity: wishlist > Owner: Debian-med team > X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org > > * Package name: http-nio > Version : 0.1.0 > Upstream Author : Daniel Gomez-S

Re: Epoch bump for gnome-shell-extension-autohidetopbar

Hi! On Mon, 2022-03-28 at 13:21:03 +0200, Tobias Frost wrote: > gnome-shell-extension-autohidetopbar is currently packaged with a date/name > version, eg. > 20209, unfortunatly without a leading 0~... > > I recently agreed [1] with upstream to tag their releases to > match the version as on

Re: proposed MBF: packages still using source format 1.0

Hi! On Tue, 2022-03-15 at 15:36:48 +, Ian Jackson wrote: > However, given that I perceive that: > - there is a campaign to abolish 1.0 > - there are important use cases where 1.0 is needed > - the campaign to abolish 1.0 is being prosecuted anyway > I have deliberately chosen to continue

Re: proposed MBF: packages still using source format 1.0

On Thu, 2022-03-10 at 12:09:14 -0700, Sam Hartman wrote: > You're trying to produce packages from CI builds or other automation > where you sometimes have native Debian revisions. > > * you are producing a package where you have distinct upstream and > debian branches, and you cannot control th

Re: proposed MBF: packages still using source format 1.0

Hi! [ But, this one again… ] On Thu, 2022-03-10 at 18:17:15 +, Steve McIntyre wrote: > Why on earth *would* you mess around using Debian revisions on a > native-format package, though? IMHO it's pointless and is just going > to confuse people. Unless you can explain a good reason to need this

DKIM and Exim (was Re: Gmail bounce unauthenticated @debian.org addresses)

Hi! On Fri, 2022-03-04 at 14:36:01 +, Colin Watson wrote: > I reproduced a similar problem, then set up DKIM for myself and > everything then worked, so I think you're correct. > > The links in the original d-d-a email were mostly stale, but I found > https://bynicolas.com/server/exim-multi-d

deb-porterbox (was: Re: No mips64el porterbox?)

Hi! On Tue, 2022-03-01 at 10:28:28 +0100, Julien Puydt wrote: > one of my package has a failure on mips64el and upstream is ready to > help me find the cause and debug the issue. > > Unfortunately, on https://db.debian.org/machines.cgi I only see five > developer machines on this architecture --

Re: The future of src:ntp

On Mon, 2022-01-24 at 08:08:16 +0100, Guillem Jover wrote: > On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote: > > On 1/19/22 15:04, Bernhard Schmidt wrote: > > > On 19.01.22 20:34, Richard Laager wrote: > > > > 2. I create transitional binary packages

Re: The future of src:ntp

On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote: > On 1/19/22 15:04, Bernhard Schmidt wrote: > > On 19.01.22 20:34, Richard Laager wrote: > > > 2. I create transitional binary packages in src:ntpsec: > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+d

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

Package: wnpp Severity: wishlist Owner: Guillem Jover X-Debbugs-Cc: debian-devel@lists.debian.org, Mark Brown * Package name: zlib-ng Version : 2.0.5 Upstream Author : zlib-ng Team * URL : http://github.com/zlib-ng/zlib-ng * License : Zlib, Zlib-RFC, CC-BY

Re: Unmet :native dependency error when cross-compiling with dpkg-buildpackage

Hi! On Wed, 2021-12-08 at 15:26:10 +0300, Uladzimir Bely wrote: > The conditions are the following: > Build Architecture: amd64 > Host Architecture: arm64 > The package I'm trying to cross-build is 'u-boot' with some patches. It has > build-time dependency 'swig:native'. But swig from Debian rep

Re: devscripts: wrap-and-sort should default to -ast

On Wed, 2021-02-10 at 11:47:12 +, Phil Morrell wrote: > As a user of -satb, I'd like to point out that the flags are not all > equal. Two of them support a (more objective?) desire that "addition to > a list in line-based VCS should have no deletions". That is -at, whereas > -s is a subjective

Re: Epoch bump for golang-github-valyala-fasthttp

On Fri, 2021-11-12 at 10:55:26 +0530, Pirate Praveen wrote: > On 12 November 2021 12:38:23 am IST, Guillem Jover wrote: > >The golang-github-valyala-fasthttp package used to have date-based > >release numbers (current Debian version 20160617-2). Upstream has > >since switc

Re: merged /usr vs. symlink farms

unblock 848622 by 134758 thanks On Sun, 2021-08-22 at 11:21:38 +0100, Luca Boccassi wrote: > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote: > > On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote: > > > The bug is real, nobody doubts that - it has been filed on d

Epoch bump for golang-github-valyala-fasthttp

Hi! The golang-github-valyala-fasthttp package used to have date-based release numbers (current Debian version 20160617-2). Upstream has since switched to semver (latest upstream version 1.31.0). So the version scheme has been reset, and unfortunately given that no prefix was used when initially

Re: merged /usr vs. symlink farms

Hi! On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote: > Afaict we have still no idea on how to move on. > > 1 I think you agree that there is a significant number of usrmerged Debian > installations out there. It does not really matter whether there are 7% or > 40%. They exist and

Re: merged /usr vs. symlink farms

On Wed, 2021-08-25 at 09:57:09 -0700, Russ Allbery wrote: > Wouter Verhelst writes: > > The problem here is also that if there are two packages like that, on an > > usrmerge system, we would not know this is happening. Also this does not need to come from "buggy" packaging practices. > I agree,

Re: merged /usr vs. symlink farms

On Fri, 2021-08-20 at 07:56:33 -0600, Sam Hartman wrote: > > "Theodore" == Theodore Ts'o writes: > Theodore> FWIW, from following the discussion, I've become more and > Theodore> more convinced that a symlink farm is *not* the right > Theodore> answer, regardless of whether it is d

Re: merged /usr vs. symlink farms

On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote: > My recollection (which might be wrong, but a quick look at release > notes seems to support it with 11.04 having multiarch 2 years before > Wheezy) is that Canonical led the way with the multiarch effort in > Ubuntu, and Debian followed w

  1   2   3   4   5   6   7   8   9   >