Yadd writes:
> On 1/13/25 11:14, Simon Josefsson wrote:
>> nick black writes:
>>
>>> i'm beginning to see use of minisign[0] as an alternative to GPG
>>> for signing releases[2]. i'm completely ambivalent with regards to
>>> the merits of minisign, but would like to be able to verify them
>>> w
(it seems the forwarding broke the thread 😕)
On 2025-01-13 at 11:10 +0100, Julien Plissonneau Duquène wrote:
> > normal dist-upgrade: 1m6.561s
> > eatmydata: 0m1.911s
> > force-unsafe-io: 0m9.096s
>
> Thanks for these interesting figures. Could you please also provide
> details about the underly
Simon Josefsson left as an exercise for the reader:
> Sorry I confused it with signify:
minisign is derived from (openbsd's) signify, so easily done!
> See https://lists.debian.org/debian-devel/2024/10/msg00031.html
thanks!
--
nick black -=- https://nick-black.com
to make an apple pie from scr
Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.torproject.org
* Package name: llm-ollama
Version : 0.8.1
Upstream Contact: https://github.com/taketwo
* URL : https://github.com/taketwo/llm-ollama
hi Jonas,
On Mon Jan 13, 2025 at 12:45 AM CET, Jonas Smedegaard wrote:
> Hi Serafeim, and others,
>
> Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)
> > what would be truly amazing, imho, would be the whole wiki on git. that'd
> > allow
> > for mass-updates, and reusing one's code (sal
Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
> On Mon Jan 13, 2025 at 12:45 AM CET, Jonas Smedegaard wrote:
> > Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)
> > > what would be truly amazing, imho, would be the whole wiki on git.
> > > that'd allow for mass-updates, and re
On Mon Jan 13, 2025 at 9:43 PM GMT, Jonas Smedegaard wrote:
Anyone interested in discussing practicalities of migrating away from
MoinMoin for the Debian wiki, please join the tinker mailinglist at
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
What is "Tinker blend
Ahmad Khalifa left as an exercise for the reader:
> Wikis have their own version control and they're meant for a much wider
> audience. I think general documentation definitely belongs on a wiki, not
> git. Edit, fix typo, done in 30 seconds :)
there are of course wiki-git bridges, at least for Me
On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:
> On Sat, 2025-01-11 at 13:49 +0100, Fabio Fantoni wrote:
> >
> > Today trying to see how a new person who wants to start maintaining new
> > packages would do and trying to do research thinking from his point of
> > view and from simple s
On Sun, Jan 12, 2025 at 01:52:13PM +, John Lines wrote:
> Package: wnpp
> Severity: wishlist
> Owner: John Lines
> X-Debbugs-Cc: debian-devel@lists.debian.org
>
> * Package name: gnudip
> Version : 2.3.5
> Upstream Contact: none
> * URL : https://gnudip2.sourcefor
On Sun Jan 12, 2025 at 8:54 PM GMT, Serafeim (Serafi) Zanikolas wrote:
what would be truly amazing, imho, would be the whole wiki on git.
that'd allow for mass-updates, and reusing one's code (salsa)
workflows for documentation
Back before we adopted MoinMoin (the previous wiki tech was kwiki
On 2025-01-13 22:43:59 +0100 (+0100), Jonas Smedegaard wrote:
[...]
> Anyone interested in discussing practicalities of migrating away from
> MoinMoin for the Debian wiki, please join the tinker mailinglist at
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
Out of cur
On 13/01/2025 21:43, Jonas Smedegaard wrote:
Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
also, I'd think that nailing down the requirements for a new platform
and for the content to be migrated (e.g. drop any pages that are >X
years old) would be an important prerequisite for any t
On 2025-01-13 22:27:21 + (+), Ahmad Khalifa wrote:
[...]
> I can't imagine there are more features in MoinMoin that can't be
> migrated to MediaWiki and friends, so I want to find out what I'm
> missing.
Another free/libre open source software community I'm involved in
migrated a fairly la
Quoting Jonathan Dowland (2025-01-13 23:15:35)
> On Mon Jan 13, 2025 at 9:43 PM GMT, Jonas Smedegaard wrote:
> > Anyone interested in discussing practicalities of migrating away from
> > MoinMoin for the Debian wiki, please join the tinker mailinglist at
> > https://alioth-lists.debian.net/cgi-bin/
Daniel Kahn Gillmor writes:
> Thanks for this discussion, all--
>
> On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
>> I believe this would be good, I frequently run into GnuPG bugs in the
>> 2.2.x branch that was fixed years ago in 2.4
>
> Can you identify some of those bugs? It would
Simon Josefsson left as an exercise for the reader:
> nick black writes:
> That would be great -- upstreams are using other mechanisms to sign
> their releases today, like Sigsum, Sigstore, gitsign S/MIME etc, and I
> don't think there is any reason why 'uscan' shouldn't support all of
> them.
i'
On 1/13/25 11:14, Simon Josefsson wrote:
nick black writes:
i'm beginning to see use of minisign[0] as an alternative to GPG
for signing releases[2]. i'm completely ambivalent with regards to
the merits of minisign, but would like to be able to verify them
with uscan.
That would be great --
One of the prominently announced features of the 2.3/2.4 branches was
multi-smartcard support and support for TPM 2.0 key wrapping.
Regards
signature.asc
Description: This is a digitally signed message part
Daniel Kahn Gillmor writes:
> Aside from GnuPG's ongoing architectural challenges, the thing i
> personally most want to avoid for Debian would be contributing to the
> schism where longstanding users of OpenPGP are suddenly migrated to
> non-OpenPGP artifacts that other OpenPGP implementations c
On Fri, 10 Jan 2025 19:33:01 +0100
Andreas Metzler wrote:
> On 2025-01-10 Frank Guthausen wrote:
> >
> > Is this still a problem with GnuPG 2.4.7? Can this be adjusted by
> > changing default configuration in the Debian package? Does it need
> > a code patch?
>
> Patch. This is about AEAD OCB
Hi,
Le 2025-01-13 01:14, Ángel a écrit :
Resending without the attachments,
I would suggest using paste.debian.net or snippets on Salsa for
attachments.
normal dist-upgrade: 1m6.561s
eatmydata: 0m1.911s
force-unsafe-io: 0m9.096s
Thanks for these interesting figures. Could you please also
On Sun Jan 12, 2025 at 3:52 PM GMT, Ahmad Khalifa wrote:
Understandable of course, but the email slows things down a bit.
MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
and writes python, it's typically very straightforward:
https://moinmo.in/EasyToDo/implement%20oauth
(Sorry, replying to an old email)
On Thu, 21 Nov 2024, Philipp Kern wrote:
> That said: There hasn't been much innovation in this space so far - in a
> way that was usable by Debian. Making builds something based off tasks
> (e.g. in a pipeline) when a package is uploaded rather than diffing the
>
On Wed, 8 Jan 2025 at 23:08, Daniel Kahn Gillmor wrote:
>
> Thanks for this discussion, all--
>
> On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
> > I believe this would be good, I frequently run into GnuPG bugs in the
> > 2.2.x branch that was fixed years ago in 2.4
>
> Can you identify
On Mon 2025-01-13 10:53:30 +0100, Simon Josefsson wrote:
> I actually meant missing features. From my recollection it was features
> related to support for some subset of combinations of 25519, gpgsm,
> smartcards and the gpg/ssh agent. Things didn't work in GnuPG 2.2 but
> was fixed years ago in
On Mon, Jan 13, 2025 at 11:08:11AM +0100, Simon Josefsson wrote:
> Daniel Kahn Gillmor writes:
> > I welcome review and critique of the packaging for this tricky package,
> > which is pretty deeply embedded in Debian (though getting less so, as
> > apt no longer requires it and we have many other
Since GnuPG 2.4 probably does not have any features removed (compared
to 2.2), is there anything other to do than patching the defaults for
new keys?
Debian has patches regarding GnuPG key defaults anyway, e.g. RSA key
size of 3072.
Regards
signature.asc
Description: This is a digitally signed
On 2025-01-13, Simon Josefsson wrote:
> the way you want. This is even more true considering that the people
> who are patching GnuPG seems to be the same people who are working on
> replacing GnuPG with Seqoia.
Not only that, but some of these people were also in the standardization
workgroup k
On Mon, Jan 13, 2025 at 10:10:25AM +, Jonathan Dowland wrote:
> On Sun Jan 12, 2025 at 3:52 PM GMT, Ahmad Khalifa wrote:
> > Understandable of course, but the email slows things down a bit.
> > MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
> > and writes python, it's t
Daniel Kahn Gillmor writes:
> On Mon 2025-01-13 10:53:30 +0100, Simon Josefsson wrote:
>> I actually meant missing features. From my recollection it was features
>> related to support for some subset of combinations of 25519, gpgsm,
>> smartcards and the gpg/ssh agent. Things didn't work in Gnu
nick black writes:
> i'm beginning to see use of minisign[0] as an alternative to GPG
> for signing releases[2]. i'm completely ambivalent with regards to
> the merits of minisign, but would like to be able to verify them
> with uscan.
That would be great -- upstreams are using other mechanisms
nick black writes:
> Simon Josefsson left as an exercise for the reader:
>> nick black writes:
>> That would be great -- upstreams are using other mechanisms to sign
>> their releases today, like Sigsum, Sigstore, gitsign S/MIME etc, and I
>> don't think there is any reason why 'uscan' shouldn't
Jonathan McDowell writes:
> On Mon, Jan 13, 2025 at 11:08:11AM +0100, Simon Josefsson wrote:
>> Daniel Kahn Gillmor writes:
>> > I welcome review and critique of the packaging for this tricky package,
>> > which is pretty deeply embedded in Debian (though getting less so, as
>> > apt no longer r
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: lomiri-printing-app
Version : 0.4.1
Upstream Contact: UBports Developers
* URL :
https://gitlab.com/ubports/development/apps/lomiri-printing-app
* License
Hi,
I'm once again working on packaging ngscopeclient, which comes with a
few unit tests that submit workloads via Vulkan.
I've patched the package to skip tests if the Vulkan runtime does not
have access to any execution units -- which is basically any autobuilder
environment.
Can we do b
Hi,
I've been parsing a few package lists lately for nefarious reasons. Some
packages have Built-Using or Static-Built-Using tags, which seem to
serve the same purpose.
Is there a subtle difference I need to be aware of?
Simon
Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić
* Package name: opaque-store
Upstream Author : Stefan Marsiske
* URL : https://github.com/stef/opaque-store
* License : GPLv3
Programming Lang: Zig, Python
Description : store encrypted blobs of informat
On 2025-01-13, Daniel Kahn Gillmor wrote:
> The idea that the other members of the working group were "forcing the
> schism" doesn't line up with my experience. Werner decided to step away
> from the process of standardizing something in an open and interoperable
> way.
At some point, one might
"M. Zhou" writes:
> On Sun, 2025-01-12 at 16:56 +, Colin Watson wrote:
>>
>> (I have less fixed views on locally-trained models, but I see no very
>> compelling need to find more things to spend energy on even if the costs
>> are lower.)
>
> Locally-trained models are not practical in the cu
Hi,
> I've been parsing a few package lists lately for nefarious reasons. Some
> packages have Built-Using or Static-Built-Using tags, which seem to
> serve the same purpose.
>
> Is there a subtle difference I need to be aware of?
I suspect the best summary of the situation is in the attachment i
Hi,
Le 2024-12-26 20:57, Michael Stone a écrit :
showing how it works is probably a better place to start.
Let's start with this then. I implemented a PoC prototype [1] as a shell
script that is currently fairly linux-specific and doesn't account for
cgroup limits (yet?). Feedback is welcome
On 2025-01-13 Simon Josefsson wrote:
> Jonathan McDowell writes:
[...]
> > I agree, but in this instance given the reliance we have upon GnuPG
> > throughout the Debian ecosystem I believe it's important we ensure that
> > the default configuration of what we ship is compatible with OpenPGP.
> >
Sune Vuorela wrote:
> Not only that, but some of these people were also in the
> standardization workgroup knowingly forcing the schism by wanting,
> what GnuPG upstream describes as, 'useless complexity' (my wording,
> not theirs).
Hi there! In addition to having helped maintain GnuPG in Debia
44 matches
Mail list logo
