Re: dgit view of packages' history

On Wed, 22 May 2024 at 21:55:15 +0200, Paul Gevers wrote: > On 21-05-2024 1:08 p.m., Sean Whitton wrote: > > > PS: I've always wondered if the dgit server shouldn't track history, even > > > if > > > uploads don't happen via it. A dgit clone could (should?) already provide > > > available

Re: finally end single-person maintainership

On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote: > Exact quote: "These commits have intentionally no debian/changelog > updates as it causes every single rebase or cherry-pick of a commit to > always have a merge conflict. It is much better to have all commits > as-is, and then right

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Tue, 07 May 2024 at 07:34:54 -0500, r...@neoquasar.org wrote: > possibly convince those applications to use their own > scratch space such as /tmp// that is more easily identifiable This would be a denial of service at best, and a privilege escalation vulnerability at worst. To be safe, it

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues wrote: > If [files can be deleted automatically while mmdebstrap is using them], > how should applications guard against that from > happening? As documented in tmpfiles.d(5), if mmdebstrap takes out an exclusive flock(2)

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Mon, 06 May 2024 at 13:41:58 +0100, Barak A. Pearlmutter wrote: > As someone who regularly deals with large datasets, and keeps them in > the "approved" don't-back-these-up location /var/tmp Independent of whether we make the change Luca is suggesting or not, I don't think /var/tmp is a good

Re: Binary conflict between Midnight Commander and MinIO Client

On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote: > Philip Hands writes: > > Might I suggest that the link goes the other way, so that the symlink > > lives in /usr/bin? That way the existence of the lib directory is > > somewhat self-documenting. Having the real executable in

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

On Sat, 06 Apr 2024 at 15:54:51 +0200, kpcyrd wrote: > On 4/6/24 1:42 PM, Adrian Bunk wrote: > > You cannot simply proclaim that some git tree is the preferred form of > > modification without shipping said git tree in our ftp archive. > > > > If your claim was true, then Debian and downstreams

Re: Validating tarballs against git repositories

On Sat, 30 Mar 2024 at 14:16:21 +0100, Guillem Jover wrote: > in my mind this incident reinforces my view that precisely storing > more upstream stuff in git is the opposite of what we'd want, and > makes reviewing even harder, given that in our context we are on a > permanent fork against

Re: time_t progress report

On Sun, 24 Mar 2024 at 18:20:30 +0100, Samuel Thibault wrote: > - it's indeed better to avoid loading porters with this, notably because > it'll be most often the same for a set of architectures. The buildd > infrastructure could have an additional build-profile parameter that > can be set

Re: Re: time_t progress report

On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote: > Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit: > > For the specific example of pipewire, I've suggested temporarily > > dropping that feature from pipewire on the affected architectures > > <

Re: Re: time_t progress report

On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote: > 2. FTBFSing packages (those that block further work, anyway) ... > An example of a currently existing obstacle of this kind is snapd-glib > (mainly because it blocks pipewire). For the specific example of pipewire, I've suggested

Re: Another usrmerge complication

On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote: > When /bin is a symlink to usr/bin, > and I install two packages, where one installs /bin/foo and the other > installs /usr/bin/foo My reading of Policy is that this situation is already a Policy violation: To support merged-/usr

Re: 64-bit time_t transition: cargo needs manual intervention

On Sat, 16 Mar 2024 at 15:37:20 +0100, Matthias Klose wrote: > build gdb without libdebuginfo on the bootstrap archs for a while. That's likely also good advice, but the cycle involving gdb isn't the only one involving curl. smcv

Re: 64-bit time_t transition: cargo needs manual intervention

On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: > For example curl isn't building on armel/armhf now and numerous packages that > depend of curl are not building on armel/armhf. I believe a maintainer upload or NMU of #1066981 and #1066982 would now be enough to unblock curl, which

Re: 64-bit time_t transition: cargo needs manual intervention

On Tue, 12 Mar 2024 at 23:13:30 -0500, Steven Robbins wrote: > I checked the build logs for cargo and noticed that most architectures have > been built on the buildds. All release arches except armel & armhf. How is > it that these two have build dep installability problems but others do not?

Re: Any way to install packages+run autopkgtests on porterbox machines?

On Sun, 03 Mar 2024 at 22:52:26 +0530, Nilesh Patra wrote: > If I want to run tests with another package (say a test dependency) that I > fixed > locally on a particular arch (which is not amd64) -- how doI run autopkgtests > with > this combo on a porter machine? Unfortunately, the general

Re: time_t progress report

On Sun, 25 Feb 2024 at 23:56:58 -0800, Steve Langasek wrote: > I have attached the full list of current packages missing correct builds in > experimental here for review. I am also attaching dd-list output for the > same. Please check whether you have packages on this list that need > attention.

Re: Another take on package relationship substvars

On Thu, 22 Feb 2024 at 20:43:21 +0100, Niels Thykier wrote: > Simon McVittie: > > On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote: > > > We could also make unused substvars a hard failure (FTBFS). > > > > I'd prefer not this > > Reminder: M

Re: Another take on package relationship substvars

On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote: > I think our package helper tooling should just automatically aggregate all > provided substvars of the format ${*:Depends} and append it the Depends > field. Rinse and repeat for other relationship fields. I recently added

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

On Fri, 09 Feb 2024 at 15:24:50 +, Bill Allombert wrote: > But fundamentally, how do we know how third-party binaries > are compiled ? We don't, but we can make some inferences. If they are i386 binaries that already worked on Debian 12 or older, and they call into time_t-sensitive ABIs (for

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

On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote: > if the maintainer > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then > it should enable it also on i386 (changed behavior). > > The reason is that this does not now break ABI for any package (in Debian > or out of

Re: build profile proposal: nogir (second try)

As Johannes mentioned earlier in this thread, the first piece of practical advice on nogir should be: if you don't know that you need to use it, then perhaps you shouldn't. It's primarily aimed at breaking cycles, and enabling buildability in lower-level packages during bootstrapping. (Having

Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs

On Mon, 22 Jan 2024 at 05:31:45 -0800, Steve Langasek wrote: > Others in this list have package names I don't understand, such as a 'd' > suffix that doesn't correspond to anything in the soname I believe this is conventionally used to mean "this is a Debian-specific SONAME that intentionally

Re: X-Windows on PPC in Debian SID

On Sun, 21 Jan 2024 at 17:14:11 -0700, Stan Johnson wrote: > The bottom line is that there appears to be a dependency issue in Debian > SID at the moment You can't *necessarily* draw this conclusion from a failure to upgrade. You are using powerpc, which is a "ports" architecture that is not

Re: build profile proposal: nogir (second try)

On Thu, 18 Jan 2024 at 11:08:30 +0100, Helmut Grohne wrote: > On Wed, Jan 17, 2024 at 11:38:09PM +0000, Simon McVittie wrote: > > The only package where I'm sure that I intend to separate out the GIR > > XML in the short term is src:glib2.0 > > How annoying would it

Re: build profile proposal: nogir (second try)

On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote: > Am 17.01.24 um 23:00 schrieb Simon McVittie: > > Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the > > C headers, but recent versions of gobject-introspection define a canonical > > virtua

build profile proposal: nogir (second try)

Last year, Helmut Grohne proposed a nogir build profile to help with cross-compiling the GLib ecosystem: . After some discussion on #1030223, I have a revised proposal, with the same name but slightly different rules: profile name:

Re: privilege separation by IPC vs. privilege separation by setuid

On Tue, 16 Jan 2024 at 20:13:21 +0900, Simon Richter wrote: > On 1/16/24 03:55, Simon McVittie wrote: > > I would personally like to see *more* privilege separation across IPC > > boundaries rather than less, if that can reduce the total attack surface > > of the setu

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On Mon, 15 Jan 2024 at 19:59:22 +0100, Johannes Schauer Marin Rodrigues wrote: > Just today I had a case where I was building something innocent and suddenly I > had an init system installed because: > > libgtk-3-dev -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service \ > ->

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote: > "Theodore Ts'o" writes: > > I'll argue that best practice is that upstream [should] make the shared > > library useful *without* the daemon Is the argument here that any design that separates into clients and a non-optional server (for

Bug#1060319: ITP: sdl2-compat -- SDL 2 binary compatibility library wrapping SDL 3

Package: wnpp Severity: wishlist Owner: Simon McVittie X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org, pkg-sdl-maintain...@lists.alioth.debian.org * Package name: sdl2-compat Version : currently 2.28.50~git20240108 Upstream Contact: https

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

On Mon, 08 Jan 2024 at 15:01:11 -0800, Steve Langasek wrote: > If a maintainer ignores the NMU and drops the rename, they'll be introducing > a new library transition again on 32-bit archs. Won't they also be caught > again in binary NEW, for those packages that don't have the same runtime >

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote: > Maybe the question is also a bit .. "it depends". ... > So that users actually likely get a system that works? I think the fact that we argue about this every few years, with no simple conclusion, is adequate evidence that the answer is

Re: /usr-move: Do we support upgrades without apt?

On Thu, 21 Dec 2023 at 15:31:55 +0100, Marc Haber wrote: > Do those GUI frontends that work via packagekit or other frameworks > count as "using apt"? Managing apt/dpkg packages via packagekit uses libapt-pkg6.0 (via /usr/lib/*/packagekit-backend/libpk_backend_apt.so). I don't know whether that's

Re: inability to resolve localhost to 127.0.0.1 in IPv6-only environments

On Fri, 01 Dec 2023 at 09:24:00 +0100, Vincent Bernat wrote: > This does not prevent to have 127.0.0.1. I don't think this is a good use of > time to fix builds broken because there is no IPv4 loopback. This is the > same kind of artificial conditions as the 1-core builders. Unfortunately, no,

Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes

Control: retitle -1 general: on hppa, command line of any program invocation is limited to less than 3544 bytes Control: severity -1 wishlist On Tue, 21 Nov 2023 at 17:26:46 +0100, Bruno Haible wrote: > I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU > 8.0.2. hppa is a

Re: DEP17 - /usr-merge - what has happened - what will happen - what you can do to help

On Thu, 16 Nov 2023 at 11:27:36 +0100, Helmut Grohne wrote: > usr-is-merged now enforces a merged layout in trixie and unstable. If > you are faced with failures from debootstrap consider updating your > debootstrap from bullseye-updates or bookworm-updates. I think that should say

Re: [PATCH] schroot: created merged-/usr chroots for trixie and beyond

On Sat, 07 Oct 2023 at 12:47:04 +0200, Helmut Grohne wrote: > would you consider applying the patch to dsa-puppet.git? It is meant to > convert trixie and newer chroots to merged-/usr. This partially reverts my earlier change

Re: /usr/-only image

On Mon, 11 Sep 2023 at 08:58:09 +0200, Gioele Barabucci wrote: > An even bigger prerequisite is that many upstream projects does not yet > support working without /etc or (orthogonally) reading their default > configuration from /usr. I agree that an "upstream first" approach is good here - even

Re: MBF: adding portals.conf(5) to desktop environments

On Tue, 29 Aug 2023 at 11:11:29 +0100, Simon McVittie wrote: > I intend to prioritize opening bugs for the major desktop environments that > have a task-foo-desktop metapackage: cinnamon, gnome-flashback, kde, lxde, > lxqt, mate, xfce. Opened and usertagged: https://udd.debian.org/cg

MBF: adding portals.conf(5) to desktop environments

xdg-desktop-portal is a D-Bus service providing access to desktop-environment-related functionality for applications. It was originally written to provide sandboxed apps (Flatpak, Snap, etc.) with limited access to resources outside their sandbox with user consent, but is increasingly also used by

Re: Issues in the Patch Tagging Guidelines

On Wed, 16 Aug 2023 at 12:25:13 +0200, Guillem Jover wrote: > Here's what a git format-patch patch looks like: > > ,--- > From 9767e87d08803d78208464be3652a9231b6b08e3 Mon Sep 17 00:00:00 2001 > From: Guillem Jover > Date: Thu, 10 Aug 2023 20:31:02 +0200 One particularly popular tool for

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

On Tue, 15 Aug 2023 at 09:21:22 -0400, Boyuan Yang wrote: > I am looking for advice in handling these MBF reports against packages that do > irreversible changes to the source files during build every time (such as > updating timestamp). A broad category would be packages using Gettext + PO >

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

On Tue, 08 Aug 2023 at 10:26:09 +0200, Helmut Grohne wrote: > With this you touch another purpose of `debian/rules clean`: Removing > generated files. Since we currently discourage repackaging and > `dpkg-source -b` is vaguely happy about deleted files, a common > technique for dealing with

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

On Sat, 05 Aug 2023 at 21:29:08 +0200, Andrey Rakhmatullin wrote: > I expect all Python packages that ship > $name.egg-info and don't remove it in clean and don't exclude it via > extend-diff-ignore (all of which is unneeded busywork even if recommended) > to behave the same. Python packages that

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

On Sat, 05 Aug 2023 at 17:06:27 +0200, Lucas Nussbaum wrote: > Should we give up on requiring a 'clean' target that works? After all, > when 17% of packages are failing, it means that many maintainers don't > depend on it in their workflow. I think it's somewhat inevitable that code paths that

Re: Can we distribute pre-built locales to speed up image generation?

On Tue, 01 Aug 2023 at 16:43:59 +0900, Charles Plessy wrote: > In the course of generating singularity/apptainer Debian images at work, > I wanted to make all locales available to the users. If you install locales-all, does that do what you want? > Running locale-gen on everything from

Re: Behavior change for Python packages built with CMake

On Thu, 27 Jul 2023 at 16:33:59 +0200, Timo Röhling wrote: > > Would it make sense for debhelper to set this, either unconditionally > > or in a sufficiently new compat level, and either unconditionally or > > for the cmake and meson build systems? > > > Yes, I think that is a good idea. Should

Re: Behavior change for Python packages built with CMake

On Thu, 27 Jul 2023 at 13:49:33 +0200, Timo Röhling wrote: > recently there have been two independent changes in the Python and > CMake world which conspired to FTBFS a number of packages. > > TL;DR: export DEB_PYTHON_INSTALL_LAYOUT=deb_system in d/rules Is "deb_system" and not "deb" the

Re: 64-bit time_t: an update

On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > to understand the impact that a change to the size of > time_t will have on a library's ABI, it must be possible to compile the > headers that expose that API Would the results of this analysis also be suitable for telling interested

Re: pre-MBF: fail to build (repack) source

On Mon, 17 Jul 2023 at 08:57:51 +, Holger Levsen wrote: > On Sun, Jul 16, 2023 at 11:41:36AM +0100, Simon McVittie wrote: > > On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote: > > > due to Build-Depends > > > being inadequate (per the Policy, B-D-

Re: Proposed MBF: Removal of libfreetype6-dev

On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > Currently, there are 219 build-dependencies and 29 (direct) > dependencies on libfreetype6-dev, which has been released with > bullseye and bookworm. Lintian diagnoses this as "[build-]depends-on-obsolete-package" since 2.116.0 (MR at

Re: pre-MBF: fail to build (repack) source

On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote: > due to Build-Depends > being inadequate (per the Policy, B-D-Indep are _not_ necessarily > installed) For completeness, B-D-Arch are not guaranteed to be installed during clean either. Similarly, Build-Conflicts are guaranteed to be

Re: /usr-merge: continuous archive analysis

On Wed, 12 Jul 2023 at 22:23:08 -0400, Theodore Ts'o wrote: > On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > > There is one major issue where I don't have a good answer: > > bookworm-backports. When this originally surfaced, Luca Boccassi > > suggested that we do not canonicalize

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

On Tue, 11 Jul 2023 at 17:48:40 +0200, Lukas Märdian wrote: > From the discussions above, it seems that NetworkManager is relevant as well, > though, and is being pulled in whenever a desktop task is installed (in > addition to ifupdown or future systemd-networkd). What happens at the moment is:

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

On Thu, 06 Jul 2023 at 16:33:22 +, Thorsten Glaser wrote: > Simon McVittie dixit: > >architecture would need to have a new dpkg architecture name, multiarch > >tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path. > > Bit of bikeshedding on the nam

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

On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote: > On 2023-06-06 11:45 +0100, Simon McVittie wrote: > > 1. i386 as a fully-featured architecture that you can run independently > >on 32-bit x86 systems from roughly the 2000-2010 era > > > > 2. i386 as a mul

Re: systmd-analyze security as a release goal

On Mon, 03 Jul 2023 at 20:21:20 +0100, RL wrote: > (One of the issues for services that send email is that it is very > easy to break exim) It's also very easy to break anything else that relies on running a setuid/setgid/setcap executable (including many mail delivery agents, not just Exim), as

Re: Second take at DEP17 - consensus call on /usr-merge matters

On Thu, 29 Jun 2023 at 19:32:15 +0200, Helmut Grohne wrote: > I think > that we will have to touch debootstrap in any case. If you specify > --variant=buildd, you get an unmerged chroot even when you do it on > trixie or unstable. ... > our buildds, which are still unmerged and get >

Re: Policy consensus on transition when removing initscripts.

On Mon, 26 Jun 2023 at 20:04:11 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > started as root and dropped privileges to some other uid, that permanently > > restricts its ability to read information out of its own /proc, which is > >

Re: Policy consensus on transition when removing initscripts.

On Mon, 26 Jun 2023 at 15:03:51 +0900, Simon Richter wrote: > On 6/25/23 23:15, Mark Hindley wrote: > > The most recent proposal[6] for updating the Policy with a requirement to > > use > > tmpfiles.d(5) states > > > "Init systems other than ``systemd`` should allow providing the same > >

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote: > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 >

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > At the moment I believe the status quo for d-i is that networking is > > managed by NetworkManager if a desktop task happens to have pulled it in, > >

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

On Mon, 19 Jun 2023 at 21:42:08 +0300, Martin-Éric Racine wrote: > I've never had to do this before, so I wonder if moving packages to > severity: standard or higher (in this case, important) requires any > decision from the CTTE or a similar authority, before we proceed? Regarding *whether* to

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote: > On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > > Why does isc-dhcp-client have priority:important to begin with? > > I don't think users care so much about a dhcp client but rather a > > network configuration system > > The

Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.

On Mon, 19 Jun 2023 at 10:47:49 +0300, Yura wrote: > After upgrade to Bookworm, due to certain limitations of the current > PipeWire implementation I had to switch to PulseAudio. The switch was > done by installing pulseaudio package, deleting all PipeWire packages and > finally enabling

Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?

At the risk of stating the obvious, OpenCL seems to be "the same shape" as many other GPU-related APIs like GLX, EGL, Vulkan, VA-API and VDPAU: - applications link to a loader library - the loader library dlopens a concrete implementation of OpenCL (an "ICD", Installable Client Driver) -

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

On Tue, 13 Jun 2023 at 11:10:41 +0800, Paul Wise wrote: > On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 > > shou

Mass bug filing / call for testing: dependencies on SDL 1.2

ian Ramacher vlc (U) Sebastien CHAVAUX xsoldier Sergei Golovan esdl (U) Simon McVittie game-data-packager (U) Simon Tatham chroma Stephen Kitt brandy dosbox gnurobbo (U) heroes (U) xmoto (U) xye (U) Stephen M. Webb viruskiller (U) Steve McIntyre <

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

On Fri, 09 Jun 2023 at 11:04:47 +0800, Paul Wise wrote: > On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > >    modern x86_64 systems > > Are these use-cases likely to work with futu

Re: multiarch vs. multilib

On Thu, 08 Jun 2023 at 19:22:02 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > Debian-style multiarch or Fedora/Arch-style multilib is a much, much > > this is at least the second time you've drawn this distinction > in this thread. for any

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

On Wed, 07 Jun 2023 at 12:25:58 +0800, Paul Wise wrote: > On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > > When considering the future of i386, a factor that we need to bear in > > mind is that there are two major use-cases for i386, with requirements > > th

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

On Tue, 06 Jun 2023 at 21:45:31 +0200, Alexis Murzeau wrote: > On 06/06/2023 12:45, Simon McVittie wrote: > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > > modern x86_64 systems > > 2a. legacy native Linux i386 binaries > > 2b. l

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

On Thu, 08 Jun 2023 at 11:19:15 +0800, Paul Wise wrote: > On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > >    modern x86_64 systems > >    2a. legacy native Linux i386 binaries > &

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

On Wed, 07 Jun 2023 at 07:19:39 -, Sune Vuorela wrote: > On 2023-06-07, Paul Wise wrote: > > I note that there are a number of packages available on i386 but not > > available on amd64, is anyone planning on an MBF about this issue? > > game stuff, mostly contrib, likely binary data for

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

On Tue, 06 Jun 2023 at 12:27:56 -0600, Gunnar Wolf wrote: > there is the possible > case of people running I-don't-know-which proprietay productivity tool > provided as a binary that cannot be convinced of a 64-bit time_t that > will receive errors when the timeocalypse approaches Sure, and

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

On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote: > Judging from the conversation, killing i386 quite obviously is desired > by some participants, but evidently not by all. How quickly we want to > kill it is not obvious to me. When considering the future of i386, a factor that we need

Re: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib

On Sat, 03 Jun 2023 at 23:39:29 +0200, Abou Al Montacir wrote: > I've added support for on the fly converting .typelib files using > g-ir-generate. The normal workflow for GObject-Introspection is: C source code } } ---> GIR XML ---> binary typelib compiled

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

On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote: > I have to ask how someone would conduct an install to a 32-bit x86 machine > running under emulation, assuming no OS on the simulated machine. I see four levels of support that we could reasonably have for i386: 1. same as in

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Tue, 16 May 2023 at 02:50:48 +0100, Luca Boccassi wrote: > This sounds like a very interesting use case, and the first real one > mentioned, which is great to see - but I do not fully follow yet, from > what you are saying it seems to me that what you need is for your > binaries to use the

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Mon, 15 May 2023 at 06:48:04 +0200, Johannes Schauer Marin Rodrigues wrote: > Obviously, with Luca's proposal, binaries from packages built with a different > dynamic linker path in them would not work on distributions without > merged-/usr > symlinks. But if the property of stuff from Debian

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote: > People build things on Debian that are not Debian packages. People > compile binaries on Debian, and expect them to work on any system that > has sufficiently new libraries. *raises hand* Hello, I represent an example of those people.

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

On Tue, 09 May 2023 at 10:03:13 +0200, Andrea Righi wrote: > On Tue, May 09, 2023 at 09:51:42AM +0200, Andrea Righi wrote: > > The original virtme project is not maintained anymore > > Moreover, it's worth mentioning that virtme-ng doesn't break the > compatibility with virtme, meaning that all

Re: DEP 17: Improve support for directory aliasing in dpkg

On Fri, 05 May 2023 at 23:11:54 +0100, Luca Boccassi wrote: > In practice, I suspect that out of ~2000 packages shipping bin/ sbin/ > lib*/, only a small fraction would end up needing to further move > files out to other packages I think the most common case for this is likely to be systemd

Re: DEP 17: Improve support for directory aliasing in dpkg

On Sat, 22 Apr 2023 at 12:43:09 +0200, Helmut Grohne wrote: > Guillem also > raised that this is changing the source of truth from the dpkg database > to the actual filesystem, which Guillem considers wrong and I find that > vaguely agreeable. To be fair, dpkg does already have at least one case

Re: DEP 17: Improve support for directory aliasing in dpkg

On Fri, 21 Apr 2023 at 15:29:33 +0100, Luca Boccassi wrote: > After Bookworm ships I plan to propose a policy change to the CTTE and > policy maintainers to forbid shipping files in the legacy directories > altogether, followed by a debhelper change to adjust any stragglers > automatically at

Re: build profile proposal: nogir

On Sun, 16 Apr 2023 at 13:22:57 +0200, Helmut Grohne wrote: > when adding new general build profiles, we're supposed to consult with > debian-devel. Thus I propose the "nogir" profile. This profile is > supposed to skip building "gir*" packages containing typelib files. Unfortunately, I don't

Re: a naive question about EOL encoding in Debian

On Sat, 18 Mar 2023 at 20:45:37 +0100, Patrice Duroux wrote: > I am facing ^M (\r) character in the .build output file using sbuild > on my system (Sid). > For instance: > > $ file timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build > timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build: ASCII text,

Re: Adding epoch to kworkflow package to correct a wrong upstream version

On Sun, 12 Mar 2023 at 09:15:35 +0100, Tobias Frost wrote: > On Sat, Mar 11, 2023 at 06:35:39PM -0700, Rodrigo Siqueira wrote: > > While working on a new version of the kworkflow package > > (https://tracker.debian.org/pkg/kworkflow), we noticed that the current > > version is 20191112-1.2, and

Re: icc-profiles_2.2_source.changes REJECTED

On Mon, 27 Feb 2023 at 12:22:34 +0100, Jonas Smedegaard wrote: > I am not convinced, however, that this issue is a bug in lintian: > The testcase you ask for is the actual files in the icc-profiles source > package which already is already correctly identified by lintian. I.e. > issue is not that

Re: Reducing allowed Vcs for packaging?

On Mon, 27 Feb 2023 at 00:17:41 +0100, Diederik de Haas wrote: > Russ Allbery wrote: > > dgit maintains a history of every package in Debian. > > AFAIK the Debian Xen Team does use dgit (not surprising given dgit's > maintainer (and author?)) ... and that drives me insane. > I'm very sure that

Re: required targets attempting internet access (was: Bug#1031548)

On Sun, 26 Feb 2023 at 19:09:59 +0100, Daniel Leidert wrote: > Am Sonntag, dem 26.02.2023 um 19:45 +0200 schrieb Adrian Bunk: > > > [..] > > Debian Policy §4.9 says that *attempting* to access the internet > > is forbidden: > > > >   For packages in the main archive, required targets must not

Re: DEB_BUILD_OPTIONS=nowerror

On Fri, 24 Feb 2023 at 09:14:15 -0800, Russ Allbery wrote: > Simon McVittie writes: > > In a typical build system like Autotools, CMake or Meson, it's going to > > be much, much easier for the answer to be yes, because the obvious way > > to make linters easy to run

Re: DEB_BUILD_OPTIONS=nowerror

On Fri, 24 Feb 2023 at 12:11:19 +0100, Helmut Grohne wrote: > On Fri, Feb 24, 2023 at 10:58:37AM +0100, Johannes Schauer Marin Rodrigues > wrote: > > Should other linters like shellcheck be disabled with > > DEB_BUILD_OPTIONS=nocheck? > > I argue for "no" (see above). In a typical build system

Re: DEB_BUILD_OPTIONS=nowerror

On Fri, 24 Feb 2023 at 10:58:37 +0100, Johannes Schauer Marin Rodrigues wrote: > I question the conflation of a hypothetical DEB_BUILD_OPTIONS=nowerror with > other linters like shellcheck (or other tools for other programming > languages). Compiler warnings and lint tools do share some

Re: Bug#1030785: -ffile-prefix-map option and reproducibility

On Tue, 14 Feb 2023 at 10:21:31 +0200, Peter Pentchev wrote: > I can't speak of many other systems, but at least with Perl's XS > (the standard way to write Perl modules parts of which are compiled C code) > and two of the ways this can be done in Python, it is the same: > the C compiler's name

Re: 32bit arch packages are built with wrong ownership due to fakeroot bug

On Fri, 10 Feb 2023 at 03:18:16 +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Santiago Vila (2023-02-09 17:32:08) > > - No intervention from individual maintainers is required for fixing this, > > as > > we already have a binNMU mechanism which we already use for transitions. > > Once

Re: Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility

On Sat, 28 Jan 2023 at 16:41:28 -0500, Jeremy Bicha wrote: > This solves a problem: currently you can use update-alternatives to > choose a default terminal for a Debian system, but what happens when > you have multiple users on the same Debian system with different > preferences? Another problem

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

On Fri, 20 Jan 2023 at 15:52:34 +0100, Marco d'Itri wrote: > I think that it is time to upgrade the warning, because I understand > that interest in continuing to maintain systemd-sysv-generator is > waning. > > I will be happy to assist maintainers who want to add a .service unit to > their

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

On Fri, 20 Jan 2023 at 12:15:31 +0100, Guillem Jover wrote: > I don't think it is redundant though? Just removing the lsb-base > Depends can break packages on partial upgrades in the same way lsb-base > broke stuff before it grew a versioned dependency on sysvinit-utils. Yes, ish. The vast

  1   2   3   4   5   6   7   8   9   10   >