On 26/09/25 13:33, Jonas Smedegaard wrote:
Quoting Aryan Karamtoth (2025-09-26 09:42:09)
On 26/09/25 12:30, Andrey Rakhmatullin wrote:
On Fri, Sep 26, 2025 at 10:36:36AM +0530, Aryan Karamtoth wrote:
Hi,
I'm currently writing some software in C that I'd like to package
into Debian once its s
Quoting NoisyCoil (2025-09-26 15:10:39)
> On 26/09/25 12:07, Jonas Smedegaard wrote:
> > Crate librust-font-kit-dev version 0.14.2-2 is impossible to install in
> > unstable, currently: It depends on
> > librust-yeslogic-fontconfig-sys-5+default-dev which is unavailable.
> >
> > Cc'ing Rust team l
On Fri Sep 26, 2025 at 8:36 AM BST, Aryan Karamtoth wrote:
Again in general, i went through the teams list and found that there's
no dedicated team for cmd line tools. I suppose a new one could be
made but I'm thinking about it. If I do feel that there's a gap that
could be filled in, I might p
Version: 0.14.3-1
On 26/09/25 12:07, Jonas Smedegaard wrote:
Package: librust-font-kit-dev
Version: 0.14.2-2
Severity: grave
X-Debbugs-Cc:debian-r...@lists.debian.org,debian-devel@lists.debian.org
Crate librust-font-kit-dev version 0.14.2-2 is impossible to install in
unstable, currently: It de
Hi,
* Simon McVittie [2025-09-24 15:13]:
The affected bugs are
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=cm...@packages.debian.org&tag=cmake-4
of which (at the time of writing) 794 out of 974 are still open. Is
that correct?
Yes, that is correct.
(cc release team since they might
Hi Jonas
On 2025-09-26 12:07:35 +0200, Jonas Smedegaard wrote:
> Package: librust-font-kit-dev
> Version: 0.14.2-2
> Severity: grave
> X-Debbugs-Cc: debian-r...@lists.debian.org, debian-devel@lists.debian.org
Please keep your feud with the Rust team off of debian-devel. Thanks
Cheers
>
> Crate
Quoting Jerome BENOIT (2025-09-26 10:01:05)
> On 26/09/2025 09:27, Aryan Karamtoth wrote:
> > It's a CLI tool so I thought there's some team where I could discuss and
> > get help with the packaging once I develop it further.
>
> CLI is the rule in GNU/Linux not the exception, so it is a far too
Quoting Aryan Karamtoth (2025-09-26 09:42:09)
>
> On 26/09/25 12:30, Andrey Rakhmatullin wrote:
> > On Fri, Sep 26, 2025 at 10:36:36AM +0530, Aryan Karamtoth wrote:
> >> Hi,
> >>
> >> I'm currently writing some software in C that I'd like to package
> >> into Debian once its stable enough. I've g
Hi,
On 26/09/2025 09:27, Aryan Karamtoth wrote:
On 26/09/25 11:46, Jerome BENOIT wrote:
Hi,
On 26/09/2025 07:06, Aryan Karamtoth wrote:
Hi,
I'm currently writing some software in C that I'd like to package into Debian
once its stable enough. I've gone through the teams wiki [1] and I notic
* Niels Thykier [2025-09-23 21:08]:
Ok. It should be possible based on the `HTTP site (recursive directory
scanning)` example from `man debian-watch`. Not entirely sure what you
are missing. The only notable difference I spot is that a @VAR@ pattern
is used in `Source` as well. Might be needed
On 26/09/25 12:30, Andrey Rakhmatullin wrote:
On Fri, Sep 26, 2025 at 10:36:36AM +0530, Aryan Karamtoth wrote:
Hi,
I'm currently writing some software in C that I'd like to package
into Debian once its stable enough. I've gone through the teams wiki
[1] and I noticed that there isn't a team
On 26/09/25 11:51, Johannes Schauer Marin Rodrigues wrote:
Hi,
Quoting Aryan Karamtoth (2025-09-26 07:06:36)
I'm confused about which team i should choose to maintain my software with.
For context its a minimal package manager for C.
which one? I think it would make sense to make your questio
On 26/09/25 11:46, Jerome BENOIT wrote:
Hi,
On 26/09/2025 07:06, Aryan Karamtoth wrote:
Hi,
I'm currently writing some software in C that I'd like to package
into Debian once its stable enough. I've gone through the teams wiki
[1] and I noticed that there isn't a team that maintains softwar
On Fri, Sep 26, 2025 at 10:36:36AM +0530, Aryan Karamtoth wrote:
Hi,
I'm currently writing some software in C that I'd like to package into
Debian once its stable enough. I've gone through the teams wiki [1]
and I noticed that there isn't a team that maintains software written
in C or command
Hi,
On 26/09/2025 07:06, Aryan Karamtoth wrote:
Hi,
I'm currently writing some software in C that I'd like to package into Debian
once its stable enough. I've gone through the teams wiki [1] and I noticed that
there isn't a team that maintains software written in C or command line tools
in g
Hi,
Quoting Aryan Karamtoth (2025-09-26 07:06:36)
> I'm confused about which team i should choose to maintain my software with.
> For context its a minimal package manager for C.
which one? I think it would make sense to make your question more concrete
instead of asking about a hypothetical soft
On Wed, 24 Sep 2025 at 14:39:45 +0200, Timo Röhling wrote:
this is a heads-up that I'm planning to upload the next minor release
of CMake 4 to unstable. The release is scheduled about two weeks from
now, around October 8th. Once CMake 4 hits unstable (again), I will
upgrade the remaining open C
* Timo Röhling [2025-09-23 21:17]:
Download-Url-Mangle:
s,festival.*-release(@ARCHIVE_EXT@),voices/festvox_kallpc16k$1,
Okay, this needs to be
Download-Url-Mangle:
s,festival@ANY_VERSION@-release(@ARCHIVE_EXT@),voices/festvox_kallpc16k$2,
because .* is too greedy.
--
⢀⣴⠾⠻⢶⣦⠀ ╭───
Andreas Tille:
Am Tue, Sep 23, 2025 at 08:13:47PM +0200 schrieb Niels Thykier:
[...]
I did so:
$ cat debian/watch
Version: 5
Source: http://festvox.org/packed/festival/
Matching-Pattern: @ANY_VERSION@/voices/festvox_kallpc16k@ARCHIVE_EXT@
... and it fails as well:
$ [...]
Ok. It sh
Am Tue, Sep 23, 2025 at 08:13:47PM +0200 schrieb Niels Thykier:
> > $ cat debian/watch
> > Version: 5
> > Source: http://festvox.org/packed/festival/
> > Matching-Pattern: @ANY_VERSION@/voices/festvox_kallpc16k@ARCHIVE_EXT@
>
> The v5 has a header stanza followed by one or more "fetching" stanzas
profile (basically dev/test + optimizations) might be a sensible
compromise? that should catch most optimization-related issues, while
still keeping (test) compilation times down..
Sigh ("Modern"), Compilation time wouldn't be an issue with Ada SPARK
(faster than C++) and it's an easier to
On 9/22/25 2:36 PM, Preuße, Hilmar wrote:
Am 22.09.2025 um 17:42 schrieb Jonas Smedegaard:
It can be (arguably) even smaller: If you have debian/upstream/metadata
you can add "Archive: Github" to that and remove the watch file.
Will the QA page [1] still work or do we have to keep the d/watch
Quoting PICCA Frederic-Emmanuel (2025-09-22 18:46:57)
> It can be (arguably) even smaller: If you have debian/upstream/metadata
> you can add "Archive: Github" to that and remove the watch file.
>
> Where is it documented ?
I found it reading the source code for devscripts.
I found "metadata" in
On Mon, Sep 22, 2025 at 04:46:57PM +, PICCA Frederic-Emmanuel wrote:
It can be (arguably) even smaller: If you have debian/upstream/metadata
you can add "Archive: Github" to that and remove the watch file.
Where is it documented ?
I don't think it is.
--
WBR, wRAR
signature.asc
Descri
Quoting John Paul Adrian Glaubitz (2025-09-22 13:57:35)
> Hi Yadd,
>
> On Sat, 2025-09-20 at 21:18 +0200, Yadd wrote:
> > could you try this debian/watch file ?
> >
> > Version: 5
> >
> > Template: Github
> > Owner: FrodeSolheim
> > Project: fs-uae
>
> Wait, what? It can be that minimal?
>
> I
On Mon, Sep 22, 2025 at 01:57:35PM +0200, John Paul Adrian Glaubitz wrote:
could you try this debian/watch file ?
Version: 5
Template: Github
Owner: FrodeSolheim
Project: fs-uae
Wait, what? It can be that minimal?
It can be even nonexistent if your debian/upstream/metadata has "Archive:
Gi
Hi Yadd,
On Sat, 2025-09-20 at 21:18 +0200, Yadd wrote:
> could you try this debian/watch file ?
>
> Version: 5
>
> Template: Github
> Owner: FrodeSolheim
> Project: fs-uae
Wait, what? It can be that minimal?
I have to try that :D.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian
On Sun, 14 Sep 2025, Preuße, Hilmar wrote:
> I had a look at [1]. As my client is > 0.10.0 I used the automatic
> installation, which seemed to work fine, at least I can create work
> requests. The test mentioned on the page below however fails. Is it expected
> work?
> [1]
> https://freexian-team
Quoting NoisyCoil (2025-09-22 00:07:59)
> On 21/09/25 23:05, Jonas Smedegaard wrote:
> > Please do not do that. When you know(!) that dependencies are not
> > satisfied but are at the risk of month-long NEW queue processing,
> > upload to experimental instead of to unstable.
>
> I started doing t
On 21/09/25 23:22, Jonas Smedegaard wrote:
I have been contacted discretely and kindly requested to a) explicitly
mention crate name in email topic and b) cc additional contact points,
by the reasoning that the Rust team is too overwhelmed to handle their
packaging mailinglist.
I'm happy somebo
On 21/09/25 23:05, Jonas Smedegaard wrote:
Please do not do that. When you know(!) that dependencies are not
satisfied but are at the risk of month-long NEW queue processing,
upload to experimental instead of to unstable.
I started doing that an hour ago with matrix-pickle{-derive,}. I don't
wn
> >> > broken packages to experimental, re-releasing to unstable only when
> >> > dependencies are all there.
> >
> >> [...] there's no such thing as
> >> *knowingly* uploading broken packages to unstable in Rust team.
> > [...]
> >&g
Quoting NoisyCoil (2025-09-21 22:26:04)
> On 21/09/25 10:41, Jonas Smedegaard wrote:
> > Please do not knowingly destabilize Debian unstable, but release known
> > broken packages to experimental, re-releasing to unstable only when
> > dependencies are all there.
> [..
Quoting NoisyCoil (2025-09-21 22:43:53)
> On 21/09/25 21:26, Matthias Geiger wrote:
> >> debian-devel@l.d.o is Cc'ed, and debian-rust@l.d.o as well since
> >> apparently the Rust team treats their Maintainer field email address as
> >> something else than for human conversations.
> >>
> > This is n
On 9/21/25 11:05 PM, Jonas Smedegaard wrote:
Quoting NoisyCoil (2025-09-21 22:26:04)
On 21/09/25 10:41, Jonas Smedegaard wrote:
> Please do not knowingly destabilize Debian unstable, but release known
> broken packages to experimental, re-releasing to unstable only when
> depende
On 21/09/25 21:26, Matthias Geiger wrote:
debian-devel@l.d.o is Cc'ed, and debian-rust@l.d.o as well since
apparently the Rust team treats their Maintainer field email address as
something else than for human conversations.
This is not fair, and you know it. Many teams use an alioth mail as
Mai
that Debian suite.
>
> Please do not knowingly destabilize Debian unstable, but release known
> broken packages to experimental, re-releasing to unstable only when
> dependencies are all there.
>
> debian-devel@l.d.o is Cc'ed, anddebian-rust@l.d.o as well since
> apparentl
unstable, but release known
broken packages to experimental, re-releasing to unstable only when
dependencies are all there.
Hi,
in my packaging work, I rarely, if all upload packages to NEW that have
unsatisfied dependencies or are not installable. Otherwise I upload to
experimental. Likewise
On 9/21/25 12:40 AM, Holger Levsen wrote:
On Sat, Sep 20, 2025 at 02:04:09PM -0700, Bas Couwenberg wrote:
On 9/20/25 12:18 PM, Yadd wrote:
could you try this debian/watch file ?
We need a backport of devscripts 2.25.19 first.
for trying? you can use the unstable version.
Yes, logging into
Hello,
As others already clarified the question of whether it is supported,
allow me to suggest options.
On Fri, Sep 05, 2025 at 12:14:47PM +, Haddad, Serge wrote:
> Our systems in the field run on an armv5 chip (armel architecture) which we
> can't replace with newer boards with a different
* Upload $package + its missing dependencies to experimental
> * Wait for all parts to pass through NEW
> * Re-upload everything to unstable
>
> cu Andreas
Sure.
This sounds to me like it should be a Debian wide policy. If this is a
problem, why are uploads to unstable
On 21/09/25 15:35, Jonas Smedegaard wrote:
I am not part of the Rust team. I am part of Debian.
I am raining an issue generally in Debian, about a seemingly team-wide
behaviour that I find inappropriate for Debian.
I did not initially talk about build flags, but if others want to mix
that into
On 21/09/25 00:51, Jonas Smedegaard wrote:
Quoting NoisyCoil (2025-09-20 21:16:08)
On 20/09/25 18:37, Jonas Smedegaard wrote:
What is sensible to me is to enable optimization by default and support
DEB_BUILD_OTIONS=noopt. Then it is clearly visible to Debian developers
when a package apply some
(sorry for the late reply)
On Sun, Aug 17, 2025 at 01:35:08PM +0100, Simon McVittie wrote:
> If the 32-bit ports are going to survive, then the affected packages either
> need to be cross-compiled from a 64-bit architecture (which is not something
> that Debian has traditionally done and not somet
Quoting NoisyCoil (2025-09-21 15:05:09)
> On 21/09/25 00:51, Jonas Smedegaard wrote:
> > Quoting NoisyCoil (2025-09-20 21:16:08)
> >> On 20/09/25 18:37, Jonas Smedegaard wrote:
> >>> What is sensible to me is to enable optimization by default and support
> >>> DEB_BUILD_OTIONS=noopt. Then it is cle
On 9/21/25 6:07 AM, IOhannes m zmölnig wrote:
Am 21. September 2025 14:05:16 MESZ schrieb Bas Couwenberg :
Yes, logging into a sid chroot on trixie systems is too much effort to quickly
test the watch file version.
If you want people to use version 5, make it available in trixie via backports
Am 21. September 2025 14:05:16 MESZ schrieb Bas Couwenberg :
>
>Yes, logging into a sid chroot on trixie systems is too much effort to quickly
>test the watch file version.
>
>If you want people to use version 5, make it available in trixie via backports.
>
as a regular workflow: sure.
however,
$random, posibly very
> > very long time))
> >
> > to
> >
> > B)
> > * Upload $package + its missing dependencies to experimental
> > * Wait for all parts to pass through NEW
> > * Re-upload everything to unstable
> >
dom, posibly very
> > very long time))
> >
> > to
> >
> > B)
> > * Upload $package + its missing dependencies to experimental
> > * Wait for all parts to pass through NEW
> > * Re-upload everything to unstable
> >
> > c
On Sat, Sep 20, 2025 at 02:04:09PM -0700, Bas Couwenberg wrote:
> On 9/20/25 12:18 PM, Yadd wrote:
> > could you try this debian/watch file ?
> We need a backport of devscripts 2.25.19 first.
for trying? you can use the unstable version.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(de
$random, posibly very
very long time))
to
B)
* Upload $package + its missing dependencies to experimental
* Wait for all parts to pass through NEW
* Re-upload everything to unstable
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Hello Bjørn,
As much as I and probably others agree that the networkd update and the
communication on the bug are problematic, your way of communicating is
not acceptable on any Debian list.
The volume of your mails fails on the code of conduct item 4 ("try to be
concise").
On Tue, Sep 09, 2025
Quoting NoisyCoil (2025-09-20 21:16:08)
> On 20/09/25 18:37, Jonas Smedegaard wrote:
> > What is sensible to me is to enable optimization by default and support
> > DEB_BUILD_OTIONS=noopt. Then it is clearly visible to Debian developers
> > when a package apply some tradeoff.
>
> We're talking abo
On 19/09/25 23:56, Jonas Smedegaard wrote:
Why are such inconsistencies done in unstable? Have the Rust team
considered using experimental for preparing such reorganisations, and
if not, why not?
This has nothing to do with "reorganizations". The actual issue here is
that zerovec, for whatever
On 9/20/25 12:18 PM, Yadd wrote:
On 9/20/25 12:39, John Paul Adrian Glaubitz wrote:
could you try this debian/watch file ?
Version: 5
Template: Github
Owner: FrodeSolheim
Project: fs-uae
We need a backport of devscripts 2.25.19 first.
Kind Regards,
Bas
On 20/09/25 18:37, Jonas Smedegaard wrote:
What is sensible to me is to enable optimization by default and support
DEB_BUILD_OTIONS=noopt. Then it is clearly visible to Debian developers
when a package apply some tradeoff.
We're talking about policy, so we don't really care about non-default
D
On 9/20/25 12:39, John Paul Adrian Glaubitz wrote:
(Please CC me when replying as I'm not subscribed to debian-devel)
Hi,
I'm currently trying to update fs-uae [1] to the latest upstream version which
now
publishes their releases on Github which means I had to update the debian/watch
file.
I
On 9/10/25 23:48, Bastien Roucaries wrote:
Le mercredi 10 septembre 2025, 22:40:59 heure d’été d’Europe centrale Jérémy
Lal a écrit :
Le mer. 10 sept. 2025 à 21:49, Simon Josefsson a
écrit :
Hi. Recent NSD support XDP and install some eBPF *.o files. Upstream
puts them in /usr/share/nsd/ w
Quoting Alexander Kjäll (2025-09-20 19:45:07)
> > It helps me (and Debian generally, I assume) that packages do not have
> > missing dependencies or build-dependencies when introduced to unstable,
> > and it is my understanding that when NEW queue is involved there is no
> > way to know if they are
> It helps me (and Debian generally, I assume) that packages do not have
> missing dependencies or build-dependencies when introduced to unstable,
> and it is my understanding that when NEW queue is involved there is no
> way to know if they are missing or not because that would requre a
> crystal
On 20/09/2025 11:39, John Paul Adrian Glaubitz wrote:
version=4
opts="searchmode=plain,\
filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.xz%" \
https://api.github.com/repos/FrodeSolheim/fs-uae/releases?per_page=100 \
https://api.github.com/repos/[^/]+/[^/]+/tarball/v?@ANY_VERSION@
This matche
Hi Matheus,
On Sat Sep 20, 2025 at 6:07 PM CEST, Matheus Polkorny wrote:
I understand that the tracker might be following the DEP-3 rule as
written, but it seems illogical to flag a patch as
"to be forwarded upstream" when its Origin field already indicates
it came from there.
This is a known
On 20/09/25 18:14, Fabian Grünbichler wrote:
no, I am open to suggestions here. for example, running the dh_auto_test
`cargo build/test` and/or the default features autopkgtest with a custom
profile (basically dev/test + optimizations) might be a sensible
compromise? that should catch most optimi
Quoting Fabian Grünbichler (2025-09-20 18:14:39)
> On Sat, Sep 20, 2025, at 5:59 PM, Jonas Smedegaard wrote:
> > Quoting Fabian Grünbichler (2025-09-20 17:31:44)
> >> On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote:
> >> > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote:
> >> >> Quoting
On Sat, Sep 20, 2025, at 5:59 PM, Jonas Smedegaard wrote:
> Quoting Fabian Grünbichler (2025-09-20 17:31:44)
>> On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote:
>> > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote:
>> >> Quoting Alexander Kjäll (2025-09-20 16:08:26)
>> >> > And regardin
On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote:
> On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote:
>> Quoting Alexander Kjäll (2025-09-20 16:08:26)
>> > And regarding running tests in debug, debug have additional checks for
>> > numeric over-/underflows, something that easily happens w
Hi Timo,
On Fri, 2025-09-19 at 17:17 +0200, Timo Röhling wrote:
> Hi Sven,
>
> * Sven Geuer [2025-09-19 16:41]:
> > * Package name : python3-pyglm
> > Version : 2.8.2
> See https://bugs.debian.org/1114819 and
> https://ftp-master.debian.org/new/python-pyglm_2.8.2-1.html
Thanks for
ay have a different
> understanding about this.
>
> > In your reflections above, you seem to consider experimental a place
> > for cross*team* coordination.
>
> No, I was only thinking about that in the context of transitions.
>
> > I urge to use experimental more generally
Quoting Alexander Kjäll (2025-09-20 16:55:12)
> On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote:
>
> > Quoting Alexander Kjäll (2025-09-20 16:08:26)
> > > Two quick thoughts from my mobile:
> > >
> > > Since transitioning through NEW takes so long, I typically upload as much
> > > of the depen
Quoting Fabian Grünbichler (2025-09-20 17:31:44)
> On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote:
> > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote:
> >> Quoting Alexander Kjäll (2025-09-20 16:08:26)
> >> > And regarding running tests in debug, debug have additional checks for
> >>
nt
understanding about this.
In your reflections above, you seem to consider experimental a place
for cross*team* coordination.
No, I was only thinking about that in the context of transitions.
I urge to use experimental more generally as a staging place for cross
*package* coordination
On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote:
> Quoting Alexander Kjäll (2025-09-20 16:08:26)
> > Two quick thoughts from my mobile:
> >
> > Since transitioning through NEW takes so long, I typically upload as much
> > of the dependency tree as possible. But NEW is not a FIFO, so sometimes
Quoting Alexander Kjäll (2025-09-20 16:08:26)
> Two quick thoughts from my mobile:
>
> Since transitioning through NEW takes so long, I typically upload as much
> of the dependency tree as possible. But NEW is not a FIFO, so sometimes
> thing pop out that is not buildable. A similar problem happen
On 20/09/25 16:08, Alexander Kjäll wrote:
Since transitioning through NEW takes so long, I typically upload as
much of the dependency tree as possible. But NEW is not a FIFO, so
sometimes thing pop out that is not buildable. A similar problem happens
if something is in NEW a long time and upgra
Hello Holger,
On Sat, 2025-09-20 at 10:53 +, Holger Levsen wrote:
> On Sat, Sep 20, 2025 at 12:39:38PM +0200, John Paul Adrian Glaubitz wrote:
> > (Please CC me when replying as I'm not subscribed to debian-devel)
>
> ack.
Thanks!
> > I followed the guide from the Debian wiki [2] and used t
On Sat, Sep 20, 2025 at 12:39:38PM +0200, John Paul Adrian Glaubitz wrote:
> (Please CC me when replying as I'm not subscribed to debian-devel)
ack.
> I followed the guide from the Debian wiki [2] and used the following options
> and URLs
> for debian/watch:
there has been quite some developm
able?
In your reflections above, you seem to consider experimental a place
for cross *team* coordination.
I urge to use experimental more generally as a staging place for cross
*package* coordination: Release known broken packages to experimental,
and then re-release to unstable only when the package is
On Tue, Sep 16, 2025 at 9:26 AM Edgecombe, Rick P
wrote:
>
> On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote:
> > > I'm not aware of any current public activities to enable userspace
> > > IBT. I haven't see any recent attempt to define a userspace/kernel ABI,
> > > or to test (and port wh
Quoting NoisyCoil (2025-09-19 23:06:39)
> On 19/09/25 13:40, Jonas Smedegaard wrote:
> > Package: librust-zerovec-dev
> > Version: 0.11.1-1
> > Severity: grave
> > X-Debbugs-Cc: Debian Rust
> > Maintainers, Sylvestre
> > Ledru
> >
> > Crate zerovec depends on missing librust-twox-hash-2+xxhash64
Hi Sven,
* Sven Geuer [2025-09-19 16:41]:
* Package name : python3-pyglm
Version : 2.8.2
See https://bugs.debian.org/1114819 and
https://ftp-master.debian.org/new/python-pyglm_2.8.2-1.html
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁
Le jeudi 11 septembre 2025, 00:05:43 heure d’été d’Europe centrale Matthias
Klose a écrit :
> On 9/10/25 23:48, Bastien Roucaries wrote:
> > Le mercredi 10 septembre 2025, 22:40:59 heure d’été d’Europe centrale
> > Jérémy Lal a écrit :
> >> Le mer. 10 sept. 2025 à 21:49, Simon Josefsson a
> >> é
On Tuesday, 16 September 2025 01:34:46 British Summer Time
aquilamac...@riseup.net wrote:
> Hi debian-devel,
>
>Best regards,
> Aquila
>For those interested in a bit more detail, I also wrote a blog post
>about my
>final report:
> https://aquilamacedo.xyz/gsoc/debian/salsa-ci/2025/08/31/gsoc
Hi!
On Tue, 2025-09-16 at 13:39:53 +0200, Jérémy Lal wrote:
> Le mar. 16 sept. 2025 à 09:28, Guillem Jover a écrit :
> > I think using abigail for ABI tracking would be great, yes, but I don't
> > think it looks like a good fit for dependency tracking TBH.
> >
> > Its XML representation seems too
On Tuesday, September 9, 2025 1:39:21 PM Mountain Standard Time Soren Stoutner
wrote:
> On Tuesday, September 9, 2025 1:15:20 PM Mountain Standard Time Julien
Lecomte
> wrote:
> > Hello
> >
> > I'm trying to create a package nwnxee that depends on package
> > nwnee-dedicated.
> >
> > But both v
Hi,
Am 13.09.25 um 12:08 schrieb Santiago Vila:
Matthias Klose wrote:
It allows to get the complete stack traces in case of internal
compiler errors.
An archive rebuild was made with gcc-15 in unstable, and no traces of
internal compiler error was found.
.. on amd64. Or maybe even on arm64,
On 08/09/25 4:04 pm, Marc Haber wrote:
> On Mon, Sep 08, 2025 at 11:57:04AM +0200, Bjørn Mork wrote:
>> bluca is neither willing nor capable of that and must therefore be
>> removed as a maintainer
>
> The first thing is to go ahead and step up to offer co-maintaining
> systemd. bluca has stated
On Tue, Sep 16, 2025 at 12:34:46AM +, aquilamac...@riseup.net wrote:
> Build reverse dependencies job
Given that this is a quadratic job: Please reproduce the dicussion done
with the Salsa admins about that.
Bastian
--
Hailing frequencies open, Captain.
* Emanuele Rocca:
> Hi,
>
> On 2025-09-06 06:50, Guillem Jover wrote:
>> Someone would need to check which shared objects are still not marked,
>> in a similar way as what Emanuele Rocca has been doing for arm64 (with
>> its PAC and BTI counterparts).
>
> On arm64, ELF files supporting what in Deb
Hi!
On Tue, 2025-09-16 at 10:20:43 -0700, H.J. Lu wrote:
> On Tue, Sep 16, 2025 at 9:26 AM Edgecombe, Rick P wrote:
> > On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote:
> > > > I'm not aware of any current public activities to enable userspace
> > > > IBT. I haven't see any recent attempt
Russell Coker writes:
> https://www.freedesktop.org/wiki/Software/systemd/kdbus/
>
> The systemd people say that kdbus will give extra features that the Unix
> domain sockets can't provide.
There is no such thing, is there? Do you have the kdbus.ko module that
document refers to? Did you try
On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote:
> > I'm not aware of any current public activities to enable userspace
> > IBT. I haven't see any recent attempt to define a userspace/kernel ABI,
> > or to test (and port where necessary) userspace.
>
> Thanks. So, do any of you (Florian, R
o testing, especially in that common case of DSP binaries not having
been updated at all. And users will have to keep re-downloading
unchanged hexagon-dsp-binaries updates every time firmware-nonfree is
updated. It seems like this would run counter to the concept of package
versioning entirely.
3)
Hi!
On Tue, 2025-09-16 at 14:26:46 +0200, Guillem Jover wrote:
> On Tue, 2025-09-16 at 13:39:53 +0200, Jérémy Lal wrote:
> > Le mar. 16 sept. 2025 à 09:28, Guillem Jover a écrit :
> > > I think using abigail for ABI tracking would be great, yes, but I don't
> > > think it looks like a good fit fo
Am 16.09.25 um 13:58 schrieb Russell Coker:
https://www.freedesktop.org/wiki/Software/systemd/kdbus/
The systemd people say that kdbus will give extra features that the Unix
domain sockets can't provide.
https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/
People a
On Tue, Sep 16, 2025 at 09:58:18PM +1000, Russell Coker wrote:
https://www.freedesktop.org/wiki/Software/systemd/kdbus/
https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/
These links and kdbus itself are all from 2015.
In 2017 on https://github.com/systemd/system
On 2025-09-16 13:58, Russell Coker wrote:
https://www.freedesktop.org/wiki/Software/systemd/kdbus/
The systemd people say that kdbus will give extra features that the
Unix
domain sockets can't provide.
https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/
People a
Le mar. 16 sept. 2025 à 09:28, Guillem Jover a écrit :
> Hi!
>
> On Mon, 2025-09-15 at 17:45:15 +0200, Simon Chopin wrote:
> > On lun. 15 sept. 2025 17:35:26, Jérémy Lal wrote:
> > > following a remark done by someone during t64 transition,
> > > I wonder if abigail-tools could be a better way to
On Tue, Sep 16, 2025 at 10:41:50AM +0200, Emanuele Rocca wrote:
> On arm64, ELF files supporting what in Debian we call the "branch"
> hardening features (PAC, BTI, GCS) are marked with a special ELF note.
>
> $ readelf -n a.out | grep Properties
> Properties: AArch64 feature: BTI, PAC, GCS
Hi!
On Mon, 2025-09-15 at 17:45:15 +0200, Simon Chopin wrote:
> On lun. 15 sept. 2025 17:35:26, Jérémy Lal wrote:
> > following a remark done by someone during t64 transition,
> > I wonder if abigail-tools could be a better way to track symbols changes ?
Matthias Klose during DebConf25 suggested
Hi,
On 2025-09-06 06:50, Guillem Jover wrote:
> Someone would need to check which shared objects are still not marked,
> in a similar way as what Emanuele Rocca has been doing for arm64 (with
> its PAC and BTI counterparts).
On arm64, ELF files supporting what in Debian we call the "branch"
harde
1 - 100 of 3282 matches
Mail list logo
