Re: Bug#1110179: ITP: fpm -- Fortran package manager - build tool

On Thu, 31 Jul 2025 at 10:26:44 +0100, Alastair McKinstry wrote: Fortran Package Manager is not to be confused with Jordan Sissel's fpm, a more general, non-Fortran related package manager. Under this name, it absolutely will get confused with Jordan Sissel's fpm. I would suggest packaging it

Re: Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

On Wed, 23 Jul 2025 at 23:53:58 +0200, Simon Josefsson wrote: Is it forbidden for packages to exist in unstable and/or experimental only in Debian? It is allowed. firefox (the non -esr version) and wine-development are examples of packages that exist only in unstable (with a RC bug to stop th

Bug#1108643: Trixie Keyboard Shortcut Issues within VMWare

Control: retitle -1 in VMware with open-vm-tools-desktop, XFCE becomes unresponsive after repeated copy/paste On Wed, 16 Jul 2025 at 08:13:03 +, David Kennedy wrote: after a few Ctrl-C keystrokes it crashes something and I can't use my mouse or keyboard, and worth noting that these open-vm

Bug#1108643: Trixie Keyboard Shortcut Issues within VMWare

On Tue, 15 Jul 2025 at 18:27:46 +, David Kennedy wrote: I am finding that it is consistently easy to crash [a VMWare VM] just doing Ctrl-C many time Does this VM have some sort of VMware "guest agent" installed, like a VMware equivalent of the functionality of qemu-guest-agent and virtual

Re: New contributor experience

On Wed, 18 Jun 2025 at 14:29:05 +0200, IOhannes m zmölnig wrote: discussion on lines of code within the MR can become stale when you push new commits that change the very lines (but the history is kept), and the discussion can be "resolved" (hidden, as no longer relevant; but still there). my

Re: New contributor experience

On Wed, 04 Jun 2025 at 17:44:52 +0200, Marc Haber wrote: Maybe we should not direct newcomers to wnpp but instead to a list of wishlist bugs tagged help (for newbies), and optionally to a list of RC bugs tagged help (with the warning "not for the faint of the heart"). The "newcomer" tag in th

Re: Question regarding Trixie and SFML

On Fri, 30 May 2025 at 20:15:47 +0200, Marc Haber wrote: If the libraries are not backwards compatible, you might want to talk to the Debian Games Team (pkg-games-de...@lists.alioth.debian.org) whether they plan to package the 3.0 series independently from the 2.x series in Debian 14/forky. B

Re: New contributor experience

On Fri, 30 May 2025 at 10:19:19 -0300, Antonio Terceiro wrote: On Fri, May 30, 2025 at 01:46:57PM +0100, Ahmad Khalifa wrote: What should you do in that situation where you have a no-response MR? Open a bug report pointing to the MR. Or, if there is a pre-existing bug report, send mail to it

Re: Questions about hard freeze and autopkgtests

On Wed, 28 May 2025 at 17:06:52 -0400, Richard Hansen wrote: * What does "autopkgtest bounty" mean in the table at ? When we aren't in a freeze, packages with successful non-superficial autopkgtests migrate sooner than packages w

Re: Dependency merging in APT

On Wed, 28 May 2025 at 10:33:26 +0200, Julian Andres Klode wrote: gnupg Depends: gpg (>= 2.4.7-19) overlaps Depends: gpg (<< 2.4.7-19.1~) - solutions: ['gpg=2.4.7-19'] - eliminated: [] ['gpg-from-sq=0.13.1-3'] Where gpg-from-sq would be considered a valid solution for the << depends as it prov

Re: Question about splitting a source package with an epoch

On Thu, 15 May 2025 at 13:39:32 -0700, Soren Stoutner wrote: The changelog indeed says the current epoch is 1: https://salsa.debian.org/debian/dutch/-/blob/master/debian/changelog? ref_type=heads#L1 Also, tracker.debian.org says the same thing: https://tracker.debian.org/pkg/dutch That's the

Re: git branches vs debian specific git tools (Re: RFC for changes regarding NMU in developers reference

On Wed, 14 May 2025 at 09:47:18 +0100, Sean Whitton wrote: On Wed 14 May 2025 at 10:41am +02, PICCA Frederic-Emmanuel wrote: So where do we put the upstream git URL If I read this part of DEP-14, I have the information that the remote should be named 'upstreamvcs' but nothing about where to put

Re: Upcoming d-i release vs. hard freeze

On Mon, 12 May 2025 at 19:58:10 +0200, Cyril Brulebois wrote: For various reasons, I'll be trying to get D-I Trixie RC 1 out this week, and I might freeze udeb-producing packages right away, or in the very next few hours/days. As a general rule, would you prefer maintainers of udeb-producing p

Re: ITN procedure - more words, fewer acronyms please?

On Sat, 10 May 2025 at 11:20:41 +0100, Wookey wrote: ITM Modernise ITU Update ITR Revamp move-to-collective-maintainership (failing to think a good short name here - maybe:) ITC Collectivise ? ITPM Publically Maintain Whichever conventional name is chosen (one of these or something else), m

Re: FTBFS when /bin is before /usr/bin in PATH?

On Wed, 07 May 2025 at 20:43:24 +0200, Simon Josefsson wrote: Simon McVittie writes: I hope that packages don't assume that /usr/games is in the PATH at build time in any case. Is it a bug if they do? Buildd's have /usr/games in the default PATH so I don't think we notice no

Re: FTBFS when /bin is before /usr/bin in PATH?

On Wed, 07 May 2025 at 14:40:01 +0200, Simon Josefsson wrote: I think we should give up on /usr/games and move those executables to /usr/bin, renaming any binaries that conflict. This seems somewhat off-topic for a discussion of FTBFS - I hope that packages don't assume that /usr/games is in t

Re: FTBFS when /bin is before /usr/bin in PATH?

On Wed, 07 May 2025 at 15:21:43 +0200, Santiago Vila wrote: El 7/5/25 a las 13:40, Simon Josefsson escribió: I think we need to separate: ... 2) Removing the /bin symlink. ... (I don't think anybody is proposing 2) right now). My understanding is that the compatibility symlinks /bin, /lib*

Re: Adding Pre-Depends from linux-image packages to linux-base

On Sun, 04 May 2025 at 15:58:55 +, Bill Allombert wrote: Le Sat, May 03, 2025 at 04:08:55PM +0200, Ben Hutchings a écrit : I'm proposing to add a linux-run-hooks command to the linux-base package [1] that will then be used in all maintainer scripts of linux-image packages [2]. This requires

Re: Need advice on architecture exclusion when arch: all packages are involved.

On Mon, 28 Apr 2025 at 09:11:51 +0900, Charles Plessy wrote: on my side I have added a --64 option to the `routine-update` script (from the same-named package) that adds a build-dependency on architecture-is-64-bits, and plan to do the same for little-endian architectures. This seems like a suf

Re: Dropping awk?

On Sun, 20 Apr 2025 at 12:48:08 +0200, Simon Josefsson wrote: has anyone considered if Debian should have official containers without apt and dpkg? What would those containers be useful for? I would have expected that in any use-case for a container without apt and dpkg, what you would really

Re: MBF: Packages which break with nocheck

On Wed, 16 Apr 2025 at 19:59:47 +0200, Santiago Vila wrote: I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck for the second build https://bugs.debian.org/786644 smcv

Re: MBF: Packages which break with nocheck

On Wed, 16 Apr 2025 at 18:40:00 +0200, Paul Gevers wrote: In one of the reports I read this: """ * When a package is built with the nocheck profile, it means: - DEB_BUILD_OPTIONS=nocheck (the tests should be skipped during the build) - DEB_BUILD_PROFILES=nocheck (Build-Depends marked are not

Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.

On Wed, 16 Apr 2025 at 23:04:47 +0900, Charles Plessy wrote: If you need one of the team-maintained r-cran-* packages on a 32-bit or on a big endian architectures, which are not supported upstream, please contact me on the debian-r list and let's see how we can share the workload. It might be b

Re: MBF: Packages which break with nocheck

On Sun, 13 Apr 2025 at 13:22:21 +0200, Santiago Vila wrote: After building all the archive (trixie/sid) with nocheck, I only found 33 new packages which fail to build with nocheck that were not reported before. Admittedly a little bit more than I expected, but certainly not "hundreds" as some pe

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

On Thu, 10 Apr 2025 at 07:37:32 +0200, Helmut Grohne wrote: how about libc6-dev stops depending on libcrypt-dev? I think this is a good idea for early in the forky cycle. I also investigated all apt-cache rdepends libcrypt1. That results in 151 source packages. ... * steam-installer This

Re: Bug#1101076: ITP: rsync -- rsync in Go! implements client and server, which can send or receive files (upload, download, all directions supported)

On Sat, 22 Mar 2025 at 21:50:00 +, Samuel Henrique wrote: * Package name: rsync This is going to need a different name, unless you are aiming for it to completely replace and supersede the original (samba.org) rsync. Upstream seems to call their main executable gokr-rsync, which seem

Re: Growing new FTP-masters (Re: Bits from DPL)

On Sun, 09 Mar 2025 at 19:32:32 +0800, Sean Whitton wrote: IMO it is the maintainer's responsibility to ensure that NEW+unstable together is always all installable, if you see what I mean. Do I assume correctly that this principle can be weakened for experimental-NEW? As a general principle

Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)

On Fri, 07 Mar 2025 at 13:27:54 +0530, Pirate Praveen wrote: > On 7/3/25 12:29 AM, Otto Kekäläinen wrote: > > > Around 12 years ago, I proposed a peer-review system to increase the > > > quality of > > > the packages in the NEW queue. https://wiki.debian.org/CopyrightReview > > For packages that

Bug#1099423: RFP: plutosvg -- Tiny SVG rendering library in C

Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org, libsdl3-...@packages.debian.org Control: affects -1 + src:libsdl3-ttf * Package name: plutosvg Version : 0.0.6 (as of 2025-03-03) Upstream Contact: Samuel Ugochukwu *

Bug#1099422: RFP: plutovg -- Tiny 2D vector graphics library in C

Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org, libsdl3-...@packages.debian.org Control: affects -1 + src:libsdl3-ttf * Package name: plutovg Version : 0.0.13 (as of 2025-03-03) Upstream Contact: Samuel Ugochukwu *

Bug#1099068: RFH: ostree -- content-addressed filesystem for operating system binaries

Package: wnpp Severity: normal X-Debbugs-Cc: ost...@packages.debian.org, debian-devel@lists.debian.org, sjo...@debian.org, m...@debian.org Control: affects -1 + src:ostree I request assistance with maintaining the ostree package. (Other Uploaders cc'd.) Package description: libostree provides

Re: ostree (was: Filesystem snapshotting in dpkg)

On Sat, 15 Feb 2025 at 21:08:03 +0100, Christian Kastner wrote: > On 2024-12-28 15:21, Guillem Jover wrote: > > In this case (filesystem snapshotting), I do think dpkg is (currently at > > least) really the wrong place, for at least the following reasons: > > I read somewhere that Fedora can do fu

Re: cinnamon and VNC/RDP/remote access

On Sat, 08 Feb 2025 at 14:18:28 +, Andrew M.A. Cater wrote: > On Wed, Feb 05, 2025 at 12:44:31PM +0100, Fabio Fantoni wrote: > > For now I know that I should remove vino from the recommended ones but I > > don't know exactly which remote access system would be best to replace it > > with. Sinc

Bug#1095081: RFP: libsdl3-shadercross -- Shader format translation library for SDL

Package: wnpp Severity: wishlist Control: block -1 by 1095077 X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org * Package name: libsdl3-shadercross Version : 3~git20250202 Upstream Contact: Sam Lantinga / SDL team * URL : https://github.co

Bug#1095077: RFP: directxshadercompiler -- compile High-Level Shader Language (HLSL) programs into DirectX Intermediate Language (DXIL) representation

Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, debia...@lists.debian.org, debian-devel-ga...@lists.debian.org * Package name: directxshadercompiler Version : 2024-07-31 Upstream Contact: Microsoft * URL : https://github.com/microsoft/Dire

Re: Future of i386,In debian-ports?

On Sun, 02 Feb 2025 at 14:18:53 -0300, Leo Historias wrote: > As we know, I386 is dropped from Debian Ports  starting with Trixie i386 is not being dropped from Debian in trixie. What *is* being dropped (has already been dropped) is the ability to run i386 as a completely independent, bootable ar

Re: Invalid check in debian/patches

On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote: > Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 I believe the intended DEP-3 syntax for this is: Bug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 so using that instead of Bug-Upst

Bug#1094475: ITP: pytest-tap -- Pytest plugin to generate structured TAP output

Package: wnpp Severity: wishlist Owner: Simon McVittie X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-tap (binary: python3-pytest-tap) Version : 3.4 Upstream Contact: Matt Layman * URL : https://pypi.org/project

Re: Rebuild all the automake-1.16 dependencies? A libltdl-dev issue?

On Mon, 27 Jan 2025 at 20:35:59 +0100, Leopold Palomo-Avellaneda wrote: > El 27/1/25 a les 20:21, Eric Dorland ha escrit: > > Apologies, this is my fault. automake-1.17 landed in unstable today > > and I neglected to "Provides: automake-1.16" on it. I'll fix that with > > an upload tonight. If it

Re: Rebuild all the automake-1.16 dependencies? A libltdl-dev issue?

On Mon, 27 Jan 2025 at 20:15:35 +0100, Leopold Palomo-Avellaneda wrote: > I don't know if it is a problem of just time to have all the mirrors > synchronized, but I'm trying to rebuild a package in sid that has > libltdl-dev as Build-dep. > > However, libltdl-dev is no installable because it depen

Re: how to fix lintian error: library-not-linked-against-libc

On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote: > maybe it's more common these days to have plugin libraries > that aren't linked with libc? Back in the day, it was very rare for people > to successfully manage to write code that never called a libc symbol. In ecosystems with a "platfor

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

On Sun, 26 Jan 2025 at 09:04:52 +0100, Rene Engelhard wrote: > Am 26.01.25 um 02:07 schrieb Otto Kekäläinen: > > Personally if I have some features that are not ready to be uploaded > > for a long time, I would maintain them in a 'feature branch'. In some > > cases that feature branch might live as

Re: Let's make 2025 a year when code reviews became common in Debian

On Sat, 25 Jan 2025 at 17:40:26 +0100, Jonas Smedegaard wrote: > When I post to a discussion at Salsa, then for how long is my post > publicly available? In general: until the project containing the discussion is deleted. A "project" in Gitlab jargon is the thing that wraps a git repository; more

Re: What is going on with atomics?

On Fri, 17 Jan 2025 at 15:32:22 +, Wookey wrote: > Can you explain why this: > -Wl,--push-flags,--as-needed,-latomic,--pop-flags > is better than > -as-needed,-latomic > I thought --as-needed on its own is sufficicent to avoid dpkg-shlibdeps > warnings > about unnecessary linking (because it o

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

On Fri, 17 Jan 2025 at 10:56:39 +0900, Simon Richter wrote: > basically we'd have to give every -dev package containing > manual pages a -doc package In many cases I think this is best-practice anyway, because it takes the documentation generation toolchain out of the critical path for bootstrappi

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

On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote: > (We'd also need to do something about libpam0g-dev man pages). Moving user-facing documentation from libpam0g into either libpam-modules-bin or libpam-doc (depending how often you expect users to need it), and developer documentation from

Re: Bug#1093222: Minimizing build-arch for pam

On Thu, 16 Jan 2025 at 09:38:38 -0700, Sam Hartman wrote: > But the meson setup call is in override_dh_auto_configure. > I don't know at that point how to figure out of I am building arch all > packages. I find that it's often better to do this in terms of "am I building package X?" instead of "am

Bug#1092108: cinnamon: When adding an app to favourites from the menu, it closes immediately

Control: retitle -1 cinnamon: When adding an app to favourites from the menu, it closes immediately Control: reassign -1 cinnamon On Sat, 04 Jan 2025 at 17:34:56 +0100, Roberto Chichiarelli wrote: > Hi, I noticed a minor bug in the desktop GUI. > When adding an app to favourites from the menu, it

Re: Building packages in the future.

On Sun, 05 Jan 2025 at 23:58:40 +0100, Chris Hofstaedtler wrote: > as we've seen in the time_t-64 transition, programs that interpose > library calls like this are extremely hard to get right and very > brittle. > > I would strongly suggest to not put new load-bearing stuff on top of > such a prog

Re: RFC: Running Postfix chrooted in Debian

On Sun, 22 Dec 2024 at 14:39:35 +0300, Michael Tokarev wrote: > And there's no way to fix [an in-process plugin architecture] in current > infrastructure, besides switching to dovecot auth (which works by implementing > a higher-level protocol than saslauthd does). This is a recurring pattern: if

Re: whether we should combine /usr/games with /usr/bin or not

On Mon, 02 Dec 2024 at 21:35:14 +0900, Charles Plessy wrote: > maybe we could also phase out /usr/games? Each time > I think that making a container image with cowsay for teaching purposes > is a good idea, I fail miserably because I forget that /usr/games is not > in the container path by default

Re: Musings about Usernames in adduser and Debian

On Sun, 24 Nov 2024 at 15:37:36 +0100, Giuseppe Sacco wrote: > Moreover, adduser man page on Debian stable, states > that gecos fields will be removed after bookworm. No, it says the --gecos *option* will be removed after bookworm, replaced by --comment, which seems to be another name for the same

Re: FQDN mandatory or can a machine could not have a domain ?

On Sun, 24 Nov 2024 at 15:45:58 +0100, Marco d'Itri wrote: > On Nov 24, Bastien Roucariès wrote: > > > > Do you think it is a good idea to set the testbed hostname to a FQDN ? > > > Please do. This has been a pain for the INN CI as well. A test with needs-root or needs-sudo should be able to set

Re: Musings about Usernames in adduser and Debian

On Thu, 21 Nov 2024 at 23:26:48 +0100, Iustin Pop wrote: > As Richard also replied, full UTF-8 is tricky, and I think it's somewhat > misplaced to focus on the username, as opposed to gecos. Aren't most > other OSes using the "full name" as the "display name", and the username > is mostly one part

Re: Rustc unsoundness on i386

On Sun, 24 Nov 2024 at 13:25:59 +0100, Iustin Pop wrote: > Are there viable/realistic platforms today that are i386 for real, and > don't support SSE2? In other words, if Debian as a whole does B) (not > only for rust), what is the practical impact on any non-toy hardware? SSE2 is well over 20 yea

Re: [Summary]: Supporting alternative zlib implementations

On Fri, 22 Nov 2024 at 12:29:51 +0100, Guillem Jover wrote: > depending on the outcome of this discussion, I think other > (probably better) options would be to perhaps name the compat packages > something like libz-ng-compat*, or drop them completely? You might find the history of the sdl12-compa

Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build

On Tue, 29 Oct 2024 at 16:03:17 +0100, Jakub Wilk wrote: > $ grep -rP 'D_FILE_OFFSET_BITS=(?!64)' /usr > /usr/lib/x86_64-linux-gnu/pkgconfig/globus-common.pc:Cflags: > -D_FILE_OFFSET_BITS= -I${includedir} Thanks, I've reported (plus a wishlist bug report suggest

Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build

On Tue, 29 Oct 2024 at 14:52:17 +0100, Dennis van Dok wrote: > https://buildd.debian.org/status/fetch.php?pkg=lcmaps&arch=amd64&ver=1.6.6-3.1%2Bb2&stamp=1730151515&file=log > > libtool sets [_FILE_OFFSET_BITS] to an empty string. What I think was supposed > to happen is not defining this at all; l

Re: s390x architecture status?

On Mon, 28 Oct 2024 at 10:24:04 +0100, Chris Hofstaedtler wrote: > b) various packages already ignore s390x (gnome? others?) GNOME is currently buildable on s390x, but we have to ignore a lot of test failures related to incorrect endianness of colour channels in image data (for example in GTK 3, G

Re: Debian CI and autopkgtest artifacts

On Sat, 26 Oct 2024 at 21:45:15 +, Daniel Markstedt wrote: > The autopkgtest docs suggest that by putting a file in a particular > directory would have it picked up as a test artifact for the CI job. Yes. During your test, the name of that directory is given by the environment variable AUTOPKG

Re: autopkgtest on s390x (was: Migration blocked by tests of depending package)

On Sat, 26 Oct 2024 at 11:02:29 +0200, Joachim Zobel wrote: > I have tried all available --boot options for autopkgtest with s390x > and was not able to create an image I suspect you mean autopkgtest-{build,virt}-qemu. autopkgtest itself (the test runner) does not have a --boot option. The ci.deb

Re: Local users in autopkgtest hosts

On Sun, 20 Oct 2024 at 19:56:42 +, Daniel Markstedt wrote: > In the end, I went with the "needs-sudo" restriction instead, to be > able to run the actual test suite as non-root. That's often a good choice if only a minority of your test needs to do privileged things. gvfs is one of the canonic

Re: Alternative signature mechanisms for upstream source verification

On Sun, 06 Oct 2024 at 10:02:56 +0200, Simon Josefsson wrote: > Otto Kekäläinen writes: > > git-buildpackage supports dual import from both upstream git and > > tarball to maximize supply chain auditability. > > That setup sounds nice! What is your workflow to import a new upstream > release? T

Re: proposal: Hybrid network stack for Trixie

On Sun, 22 Sep 2024 at 12:22:50 +0200, Chris Hofstaedtler wrote: > d-i could make (or offer) a choice between networkd and > NetworkManager. d-i *already* makes a choice between ifupdown and NetworkManager: if NM has been pulled in by a task's dependencies (e.g. this happens when you install the G

Re: Reviving schroot as used by sbuild

On Fri, 13 Sep 2024 at 11:15:55 +0200, Helmut Grohne wrote: > My initial experiments indicate that we're in > for a factor two [slowdown] whereas we could get this down significantly > by using an overlayfs approach that we cannot shoehorn into podman. Er, podman does use overlayfs, in at least so

Re: DEP5 and spdx shortname of license

On Sun, 08 Sep 2024 at 09:49:39 +0200, Niels Thykier wrote: > Is it really that valuable for us to have a delta here compared to what > upstream projects would use? IMO: no. If (some) upstream projects are now taking copyright/license tracking in general (and machine-readable copyright/license spe

Re: Should OpenSSL/ libssl3 depend on brotli?

On Sat, 07 Sep 2024 at 11:41:34 +0200, Sebastian Andrzej Siewior wrote: > What is the benefit of reducing the pseudo-essential size? I have > libssl installed on all of my systems since it is pulled in at least by > openssh. chroots/containers, mainly. I'm sure you have openssh installed on all y

Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)

On Mon, 19 Aug 2024 at 22:42:53 -0700, Otto Kekäläinen wrote: > ## How many packages have a 'upstream-vcs-tag' and what is it typically? Unlike most of the other questions you asked and answered (thanks!) we should never expect this to be consistent, because it isn't Debian's decision: it's upstre

Re: Re: Accepting DEP14?

On Sat, 17 Aug 2024 at 22:45:59 +0200, Chris Hofstaedtler wrote: > "latest" is illnamed. What do you expect to find in a branch thats > called debian/latest? > > Packaging for unstable? For experimental? For experimental if there's currently a version in experimental (or if there is about to be o

Re: Request for IkiWiki NMU (FTBFS #1074727)

On Sat, 17 Aug 2024 at 13:13:51 +0100, Jonathan Dowland wrote: > intrigeri's patch at > > looks good to me (eyeball test only) > > I would be very grateful if someone would be prepared to Debian-ize > it and NMU IkiWiki (due to be remo

Re: Porterbox - impossible efficient debugging?

On Tue, 13 Aug 2024 at 13:01:45 +0200, Stéphane Glondu wrote: > BTW, IIUC, it is be possible with namespaces to give root privileges (or > enough to install packages) to anybody inside a container. [1] could be a > way, but it needs unprivileged user namespaces. See also https://salsa.debian.org/d

Re: RFC: Sensible-editor sensible-utils alternative and update

On Mon, 12 Aug 2024 at 08:44:51 -0700, Russ Allbery wrote: > What this is telling me is that ideally someone should tighten the > definition of EDITOR in Policy 11.4, which is the specification satisfied > by sensible-editor, to make it clear that GUI editors with these sorts of > properties are no

Re: RFC: Sensible-editor sensible-utils alternative and update

On Mon, 12 Aug 2024 at 14:23:51 +, Bastien Roucariès wrote: > Yes I want sensible-editor to open kate on kde and gnome-editor on gnome. > > Thinks about running latex and typing e for editing, it should run the > desktop editor of choice. > > I do not want to change desktop user choice This

Re: RFC: Sensible-editor sensible-utils alternative and update

On Mon, 12 Aug 2024 at 12:36:37 +0100, Richard Lewis wrote: > Bastien Roucariès writes: > > Sensible-editor could now use EDITOR="emacsclient -n -c" and accept > > that sh -c accept > > > > My goal is to create a sensible-editor.desktop that will lauch by > > default the sensible-editor of choice

Re: salt removed from mirror

On Fri, 09 Aug 2024 at 13:31:02 +, Johannes Drexl wrote: > I was under the impression that the software stack of a > stable/oldstable release does not change anymore (safe for security > updates and suchlike), so I'm pretty flabberghasted by this. More so as > I cannot find a mention about this

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

On Sat, 03 Aug 2024 at 19:16:30 +0200, Guillem Jover wrote: > I'm not sure the current state is ideal, because we are back to > packages being able to rely on some stuff on build daemons, that are > not guaranteed by default for our supported build entry points This was already true, though: the o

Re: Produce extra build artifacts during package builds

On Fri, 02 Aug 2024 at 21:03:05 +0200, Niels Thykier wrote: > I think it is more of a question whether [artifacts in /tmp] will be supported > initially (might require a per-source TMPDIR too for buildd support, so > artifacts does not get tainted because the buildd was running two builds at > the

Re: Produce extra build artifacts during package builds

On Sat, 03 Aug 2024 at 15:15:10 +0900, Mattia Rizzolo wrote: > Consider that in my mind, most packages wouldn't have needed to write > any imperative code. > I was considering it for example within dh_auto_configure and > dh_auto_test, etc, those tools would be responsible for copying the > relevan

Re: Produce extra build artifacts during package builds

On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote: > Simon McVittie: > > In the design that I prototyped, it's declarative, loosely inspired by > > the equivalent Gitlab-CI feature: > > > > - the maintainer can write patterns into debian/build-artifacts fo

Re: Produce extra build artifacts during package builds

On Fri, 02 Aug 2024 at 16:40:15 +0900, Mattia Rizzolo wrote: > Lastly I think https://lists.debian.org/debian-devel/2022/02/msg00216.html > to which Simon had a quite nice answer. I also did some more concrete design and wrote a prototype -

Re: OpenPGP digital signature

On Tue, 30 Jul 2024 at 10:35:18 +0400, Yadd wrote: > On 7/30/24 09:53, imtoas...@mail.com wrote: > > On behalf of the Release Team, > > Paul Please note that imtoas...@mail.com is (presumably) not Paul, the PGP signature does not validate, the subject line is not what the release team would use, a

Re: what about Netplan?

On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote: > Luca Boccassi wrote: > >Networking is not static, it constantly changes in the kernel, > >sometimes in dramatic and incompatible ways. > > Sorry, but no. Networking clearly is *not* changing that fast, in > software terms. Many old too

Re: ifupdown maintenance

On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote: > On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote: > > I believe NM does not have a fixed configuration format, but only a dbus > > API. > > It's perfectly fine to edit configuration files for NM manually, see > man:nm-settings-keyfile

Re: ifupdown maintenance

On Tue, 09 Jul 2024 at 12:27:58 +0200, Bjørn Mork wrote: > Matthias Urlichs writes: > > Somebody could even write a converter. Shouldn't be that difficult, > > AFAIK there's nothing ifupdown can do that systemd[-networkd] can't. > > Run user scripts on up/down events. That's a huge blank spot in

Re: default network management tools (was: ifupdown maintenance)

On Tue, 09 Jul 2024 at 10:57:39 +0200, Matthias Urlichs wrote: > Agreed: either it's drop-in compatible or we may as well switch the > default to NM and/or systemd-networkd. > > Well, here's a heretical thought: why don't we do that anyway, at least for > new > installations? To some ext

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

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. > > dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when > building packages Allowing ASCII seem

Re: Reviving schroot as used by sbuild

On Mon, 01 Jul 2024 at 09:18:19 +0200, Philipp Kern wrote: > Specifically I'm concerned about what [advocating use of podman] > means for tests and if they > should be able to use unprivileged containers themselves to test things. tl;dr: There's no regression here, because you already can't run th

Re: Builds that pass locally but fail on sbuild? (Re: Reviving schroot as used by sbuild)

On Thu, 27 Jun 2024 at 19:56:43 -0700, Otto Kekäläinen wrote: > Could you point me to some Debian Bug # or otherwise share examples of > cases when a build succeeded locally but failed on official Debian > builders due to something that is specific for sbuild/schroot? I can't easily point you to a

Re: Reviving schroot as used by sbuild

On Wed, 26 Jun 2024 at 18:05:15 -0400, Reinhard Tartler wrote: > I imagine that one could whip up some kind of wrapper > that is building a container either from a tarball created via mmboostrap or > similar > using buildah, have it install all necessary build dependencies, and then use > podman to

Re: Reviving schroot as used by sbuild

On Thu, 27 Jun 2024 at 17:26:20 +0200, Johannes Schauer Marin Rodrigues wrote: > But, if everybody is so excited about this, where are the sbuild contributors > implementing this? I'm sorry, consider it added it to my list. As usual, there's no guarantee that I will get there within my lifetime, b

Re: Reviving schroot as used by sbuild

On Thu, 27 Jun 2024 at 11:46:51 +0200, Helmut Grohne wrote: > I am concerned about behavioural differences due to the reimplementation > from first principles aspect though. Jochen and Aurelien will know more > here, but I think we had a fair number of ftbfs due to such differences. > None of them

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 18:55:45 +0200, Helmut Grohne wrote: > At least for me, building container images locally is a requirement. I > have no interest in using a container registry. I expected you'd say that. podman --rootfs is one way to use it without a registry; a trivially short Dockerfile li

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 18:47:49 +0200, Guillem Jover wrote: > I manage my chroots with schroot (but not via sbuild, for dog fooding > purposes :), and use type=directory and union-type=overlay so that I > get a fast and persistent base, independent of the underlying filesystem, > with fresh instanc

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 09:32:21 -0700, Russ Allbery wrote: > Simon McVittie writes: > > I think the > > only model that should be used in new systems is to have some concept of > > a session (like schroot type=file, but unlike schroot type=directory) > > I'm not

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 10:16:20 +0200, Helmut Grohne wrote: > In this work, limitations with --chroot-mode=unshare became apparent and > that lead to Johannes, Jochen and me sitting down in Berlin pondering > ideas on how to improve the situation. That is a longer story, but > eventually Timo Röhli

Re: Suggestions about i386 support

On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote: > > several important upstreams no longer consider i386 to be useful (and > > especially i386-without-SSE2), so so the burden of supporting 32-bit >

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

On Sat, 08 Jun 2024 at 02:14:36 +0900, Simon Richter wrote: > Reproducibility outside of sterile environments is however a problem for us > as a distribution, because it affects how well people are able to contribute > to packages they are not directly maintaining If our package-building entry poi

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

On Mon, 10 Jun 2024 at 16:24:54 +0200, Guillem Jover wrote: > In general I think it's good (in principle) to enable -Werror flags > that detect actual bugs in code, the problem is always going to be > the amount of fallout and work that creates Yes. The difficult thing here is balancing "detect ac

Re: Suggestions about i386 support

On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote: > The point here is that the Debian project is not intending to support > new hardware on the i386 architecture. The architecture is being kept > around primarily to support running old i386 binaries. ... and the most appropriate answers

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

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 at the same time I've pretty much > always run my systems with either LANG=C.UTF-8 or before that LANG=C, > LC_CTYPE=ca_ES.UTF-8 and LC_COLLATE=ca_ES.UTF-8.

  1   2   3   4   5   6   7   8   9   10   >