Hello,
On Thu 06 Jun 2024 at 11:25am -06, Gunnar Wolf wrote:
> Let me chime in with all of the people that have been amazed at your
> depth of analysis and your commitment to implementing the *properly
> right* situation. It cannot be overstressed that, for this release
> cycle, one of the main r
Package: wnpp
Severity: wishlist
Owner: Martin Quinson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name : odin-lang
Version : O.0.dev2024.06
Upstream Contact: (this community goes over Discord, not emails)
* URL : https://odin-lang.org
* License : BSD-
Package: wnpp
Severity: wishlist
Owner: Aurélien COUDERC
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Qt/KDE Maintainers
* Package name: plasma5support
Version : 6.0.5
Upstream Contact: Plasma Developers
* URL : https://invent.kde.org/plasma/plasma5support
*
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org
Control: affects -1 src:tracker
Owner: jeremy.bi...@canonical.com
Package Name: tinysparql
Version: 3.8 (not yet released yet)
Upstream Author: Sam Thursfield, Carlos Garnacho and others
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org
Control: affects -1 src:tracker-miners
Owner: jeremy.bi...@canonical.com
Package Name: localsearch
Version: 3.8 (not yet released yet)
Upstream Author: Sam Thursfield, Carlos Garnacho an
On Thu, Jun 06, 2024 at 06:39:15PM +0200, Marco d'Itri wrote:
> On Jun 06, Simon McVittie wrote:
>
> > I believe the change Luca describes is increasing rlim_max (hard limit)
> > but not rlim_cur (soft limit), and the code touched by that patch is
> > looking at rlim_cur, so it should be unaffect
We recently increased the time_t size on certain architectures and some
packages started failing to build because they were using a format
specifier too narrow for the wider time_t, e.g. #1067829.
But the only reason those package FTBFS is they enable either -Werror or
some more specific non-defaul
Simon McVittie writes:
> On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote:
>> Something did, because inn would start reporting ~1G available fds and
>> then explode, and that patch solved the issue. :-)
> It might be worthwhile to try to track down what larger component did
> this, beca
On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote:
> On Jun 06, Simon McVittie wrote:
> > I believe the change Luca describes is increasing rlim_max (hard limit)
> > but not rlim_cur (soft limit), and the code touched by that patch is
> > looking at rlim_cur, so it should be unaffected any
Hi Helmut,
Russ Allbery, on 2024-06-06:
> Marc Haber writes:
> > Helmut Grohne wrote:
>
> >> Thanks for bearing with me and also thanks to all the people (release
> >> team and affected package maintainers in particular) who support this
> >> work.
>
> > Thank you for doing this work. I have r
Helmut Grohne dijo [Thu, Jun 06, 2024 at 09:28:52AM +0200]:
> Hello,
>
> I have just uploaded
> * base-files
> * bash
> * dash
> * glibc
> * util-linux
> to unstable. These were the last remaining packages shipping aliased
> files inside the package set relevant to debootstrap.
> (...)
> Than
Am 06.06.24 um 18:52 schrieb Andrey Rakhmatullin:
On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues
wrote:
Or whether we should switch the default and require that d/rules is run in an
environment (for example as set-up by dpkg-buildpackage) where these variables
are se
Marc Haber writes:
> Helmut Grohne wrote:
>> Thanks for bearing with me and also thanks to all the people (release
>> team and affected package maintainers in particular) who support this
>> work.
> Thank you for doing this work. I have rarely seen a change of this
> magnitude in Debian that wa
On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Or whether we should switch the default and require that d/rules is run in an
> environment (for example as set-up by dpkg-buildpackage) where these variables
> are set?
(a previous discussion on this:
https://list
On Jun 06, Johannes Schauer Marin Rodrigues wrote:
> A question that goes in a similar direction is whether every d/rules that
> needs
> it should have to do this:
>
> export DPKG_EXPORT_BUILDFLAGS=y
> include /usr/share/dpkg/buildflags.mk
>
> Or whether we should switch the default and requir
On Jun 06, Simon McVittie wrote:
> I believe the change Luca describes is increasing rlim_max (hard limit)
> but not rlim_cur (soft limit), and the code touched by that patch is
> looking at rlim_cur, so it should be unaffected anyway - unless some larger
> component is raising rlim_cur.
Somethin
Processing control commands:
> retitle -1 Dead keys stopped working in unspecified environment
Bug #1072491 [libglib2.0-0t64] libglib2.0-0t64: Dead keys stopped working,
again!
Changed Bug title to 'Dead keys stopped working in unspecified environment'
from 'libglib2.0-0t64: Dead keys stopped wo
On Thu, 06 Jun 2024 at 12:56:10 +0200, Johannes Schauer Marin Rodrigues wrote:
> If we imagine a hypothetical switch to LC_ALL=C.UTF-8 for all source
> packages by default, then there will be bugs.
Do you mean: there will be bugs that break the build of certain packages,
which previously built suc
I believe debhelper already sets LC_ALL=C.UTF-8 for the cmake, meson,
and ninja buildsystems; therefore many but definitely not all packages
are already built with LC_ALL=C.UTF-8.
Thank you,
Jeremy Bícha
On Thu, 06 Jun 2024 at 15:21:22 +0200, Marco d'Itri wrote:
> On Jun 06, Luca Boccassi wrote:
> > The last time this was tried some packages were still not ready, so it
> > was patched out to let them be fixed.
>
> I missed the venerable inn 1.x at the time, and I never noticed that it
> allocates
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 your interactive terminal session, your GUI desktop
environment, or even your se
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: buteo-syncml
Version : 0.5.15
Upstream Contact: https://sailfishos.org/contact/
* URL : https://github.com/sailfishos/buteo-syncml.git
* License : B
Package: wnpp
Severity: wishlist
Owner: Timo Röhling
X-Debbugs-Cc: debian-devel@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: tl-optional
Version : 1.1.0
Upstream Author : Sy Brand
* URL : https://github.com/TartanLlama/optional
* L
On Thu, 06 Jun 2024 at 14:40:23 +0200, Daniel Gröber wrote:
> On Thu, Jun 06, 2024 at 11:32:33AM +0200, Simon Richter wrote:
> > If your package is not reproducible without it, then your package is
> > broken.
>
> At build-time, if a program doesn't call setlocale before using locale
> dependent s
On Jun 06, Luca Boccassi wrote:
> The last time this was tried some packages were still not ready, so it
> was patched out to let them be fixed. Enough time has passed now, and
> it's time to let any unknown leftover just break and be fixed. In all
> known cases, the buggy pattern was to manually
Hi,
On Thu, Jun 06, 2024 at 11:32:33AM +0200, Simon Richter wrote:
> If your package is not reproducible without it, then your package is
> broken. It can go in with the workaround, but the underlying problem
> should be fixed at some point.
It's easy to say "should be fixed" but finding the sour
On Thu, 6 Jun 2024 09:28:52 +0200, Helmut Grohne
wrote:
>Thanks for bearing with me and also thanks to all the people (release
>team and affected package maintainers in particular) who support this
>work.
Thank you for doing this work. I have rarely seen a change of this
magnitude in Debian that
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org
Control: affects -1 src:papers
Owner: jeremy.bi...@canonical.com
Package Name: papers
Version: 46.1
Upstream Author: Pablo Correa Gómez, Markus Göllnitz, Evince authors
License: GPL-2+
P
Hi,
On 6/6/24 19:56, Johannes Schauer Marin Rodrigues wrote:
At the same time though, I also get annoyed of copy-pasting d/rules snippets
from one of my packages to the next instead of making use of a few more
defaults in our package build environment.
Same here -- I just think that such a wo
Hi,
Quoting Hakan Bayındır (2024-06-06 12:32:27)
> On 6.06.2024 ÖS 1:08, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Simon Richter (2024-06-06 11:32:33)
> >>> Would it be possible to set in stone that packages are supposed to always
> >>> be built in an environment where LC_ALL=C.UTF-8, or
Hi,
PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.
(I meant to send this last week but it fell off the wagon and
languished in the draft folder, sorry!)
This a
Hi,
On 6.06.2024 ÖS 1:08, Johannes Schauer Marin Rodrigues wrote:
Hi,
Quoting Simon Richter (2024-06-06 11:32:33)
Would it be possible to set in stone that packages are supposed to always
be built in an environment where LC_ALL=C.UTF-8, or, in other words, that
builders must set LC_ALL=C.UTF-8
Hi,
Quoting Simon Richter (2024-06-06 11:32:33)
> > Would it be possible to set in stone that packages are supposed to always
> > be built in an environment where LC_ALL=C.UTF-8, or, in other words, that
> > builders must set LC_ALL=C.UTF-8?
>
> This would be the opposite of the current rule.
>
Hi,
> Would it be possible to set in stone that packages are supposed to
> always be built in an environment where LC_ALL=C.UTF-8, or, in other
> words, that builders must set LC_ALL=C.UTF-8?
This would be the opposite of the current rule.
Setting LC_ALL=C in debian/rules is an one-liner.
If yo
On Thu, 6 Jun 2024 at 09:07, Gioele Barabucci wrote:
>
> Hi,
>
> setting LC_ALL=C.UTF-8 in d/rules is a common way to fix many
> reproducibility problems. It is also, in general, a more sane way to
> build packages, in comparison to using whatever locale settings happen
> to be set during a build.
On Thu, 6 Jun 2024 at 10:02, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi Helmut,
>
> Quoting Helmut Grohne (2024-06-06 09:28:52)
> > I have just uploaded
> > * base-files
> > * bash
> > * dash
> > * glibc
> > * util-linux
> > to unstable. These were the last remaining packages shipping ali
Hi Helmut,
Quoting Helmut Grohne (2024-06-06 09:28:52)
> I have just uploaded
> * base-files
> * bash
> * dash
> * glibc
> * util-linux
> to unstable. These were the last remaining packages shipping aliased
> files inside the package set relevant to debootstrap.
thank you (and freexian for f
Hello,
I have just uploaded
* base-files
* bash
* dash
* glibc
* util-linux
to unstable. These were the last remaining packages shipping aliased
files inside the package set relevant to debootstrap.
Once any of these packages has been built until the last of these has
been built, debootstrap
38 matches
Mail list logo
