On Tue, 16 May 2023 at 04:22, Russ Allbery wrote:
>
> > It did look like a veto to me. More importantly, isn't relying on
> > passersby to spot alleged harmful changes dangerous, especially for
> > undocumented, uncodified and untested use cases, like unspecified and
> > vague cross-compatibility
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 usual
Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: sudo-rs
* URL : https://github.com/memorysafety/sudo-rs
* License : Apache-2.0, MIT
Programming Lang: Rust
Description : A safety oriented and memory
Package: wnpp
Severity: wishlist
Owner: Blair Noctis
X-Debbugs-Cc: debian-devel@lists.debian.org, n...@sail.ng
* Package name: atuin
Version : 14.0.1
Upstream Contact: Ellie Huxtable
* URL : https://atuin.sh/
* License : MIT
Programming Lang: Rust
Descript
Package: wnpp
Severity: wishlist
Owner: Andrej Shadura
* Package name: jl
Version : 0.1.0-1
Upstream Author : Yunchi Luo
* URL : https://github.com/mightyguava/jl
* License : Expat
Programming Lang: Go
Description : Pretty Viewer for JSON logs
jl (JL)
James Addison writes:
> We've almost certainly all encountered limitations in upstream
> specifications and wondered when it's worth attempting a perceived
> improvement despite potential friction.
> If Debian did want/need to change the PT_INTERP path, is there a way to
> achieve that in both a
Le mardi, 16 mai 2023, 17.06:38 h CEST Russ Allbery a écrit :
> I don't know if anyone has written an ABI compliance test for binaries.
> That sounds like something that would be in scope for the Linux Test
> Project, though, and it's possible their existing tests do some of this.
This has existed
Didier 'OdyX' Raboud writes:
> This has existed in a (now distant) past as the "Linux Distribution
> Checker", in the context of the Linux Standard Base, that Debian and
> Ubuntu stopped caring about in late 2015.
Ah, yes, thank you, that makes sense.
> I'm not aware of more recent efforts in t
On Tue, 16 May 2023 at 04:22, Russ Allbery wrote:
> Luca Boccassi writes:
> > On Mon, 15 May 2023 at 16:18, Russ Allbery wrote:
>
> >> Note that we're not talking about complicated packages with lots of
> >> runtime like, say, Emacs. As I understand it your proposal wouldn't
> >> change PT_INTE
On Tue, 16 May 2023 at 09:27, Simon McVittie wrote:
>
> 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 t
Luca Boccassi writes:
> It does say something interesting. When we started, the assertion was
> that packages not relying on the symlink being present was fundamental
> for portability and cross-compatibility. Then, it shrinked to
> portability and cross-compatibility of a subset of packages. Now
Hi folks,
Over on debian-arm@lists, there has been discussion on and off for several
months now about the impending 32-bit timepocalypse. As many of you are
aware, 32-bit time_t runs out of space in 2038; the exact date is now less
than 15 years away. It is not too early to start addressing the
Steve Langasek writes:
> * Largely via NMU, add a “t64” suffix to the name of runtime library
> packages whose ABI changes on rebuild with the above flags. If an
> affected library already has a different suffix (c102, c2, ldbl, g…), drop
> it at this time.
This is possibly me being too f
For mipsel, we have one more thing to do:
- NaN2008 vs NaN legacy
So I'd prefer rebootstrap (only for mipsel).
And In fact we did it: https://repo.oss.cipunited.com/debian/
Russ Allbery 于2023年5月17日周三 12:31写道：
>
> Steve Langasek writes:
>
> > * Largely via NMU, add a “t64” suffix to the name
14 matches
Mail list logo
