Hi,
Am Wed, Jan 15, 2025 at 12:50:55AM +0100 schrieb Thorsten Glaser:
> >Task description
>
> There should be something in this that says that they need to do so
> in a way that matches ftpmaster policies.
I gave the ftpmaster team about three weeks response time to the text of
the delegation.
Le 2025-01-15 00:37, Chris Hofstaedtler a écrit :
Maybe a viable option for the debian namespace is to blanket close
any MR that is older than 6 months. But I don't know how that will
fare for the Janitor MRs.
Given the "Debian time" scale, a much longer delay would be appropriate
IMO. I would
Hi,
Am Tue, Jan 14, 2025 at 07:14:09PM -0800 schrieb Otto Kekäläinen:
> > I gave this, specifically reviewing MRs in the debian namespace, a
> > try after your last message on this topic. Unfortunately I have to
> > say, it feels like a huge waste of time and is mostly frustrating.
>
> Thanks! Se
Hi,
Le 2025-01-14 23:14, Otto Kekäläinen a écrit :
619 (1242) https://salsa.debian.org/groups/java-team/-/merge_requests
FWIW I took a look at that and most of them are Janitor merge requests.
Please just skip them as some are outdated, and I'm planning to take
care of them later this year
On Tue, Jan 14, 2025 at 07:14:09PM -0800, Otto Kekäläinen wrote:
> > The other big category of MRs in the debian namespace was and still
> > is: MRs where the maintainers don't get mails from salsa. If one is
> > active with the project, one can know who is currently around and
> > assign / ping th
Hi folks,
It seems that "AI PC" was everywhere in the CES 2025, which basically indicates
the presence of the NPU device. Both AMD and Intel have integrated the NPU
device
into their own new CPUs -- in that sense I guess the NPU device will be more
popular
than discrete GPUs in the future, in te
> > 938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests
> [..]
> > If you have some spare time for Debian today, please consider
> > collaborating with another maintainer by providing them
> > review/feedback on an open Merge Request.
>
> I gave this, specifically reviewing MRs in th
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: openvino
Version : 2024.6.0
Upstream Contact: Intel
* URL : https://github.com/openvinotoolkit/openvino
* License : Apache-2.
Hi!
On Mon, 2025-01-06 at 16:45:54 +0100, Simon Josefsson wrote:
> Santiago Vila writes:
> > Note for Guillem: I've included your suggested fix in the bug template.
Great, thanks!
> I don't think we should patch upstream code for things that aren't clear
> upstream bugs. Patching upstream code
Hi,
On 1/13/25 17:27, Ahmad Khalifa wrote:
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 :)
Agreed 100%, the openness for editing is really what makes wi
On Tue, 14 Jan 2025, Andreas Tille wrote:
>Task description
There should be something in this that says that they need to do so
in a way that matches ftpmaster policies.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
* Otto Kekäläinen [250114 23:14]:
> Numerous people are posting Merge Requests on Salsa. Please help review them!
>
> There is no single dashboard to show all Merge Requests for all Debian
> packages, but here are the largest teams listed to show how many they
> have open (and total count in pare
> On SSDs, it does not matter, both because modern media lasts longer than
> the rest of the computer now,
That has not been my experience.
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo
Hi,
Numerous people are posting Merge Requests on Salsa. Please help review them!
There is no single dashboard to show all Merge Requests for all Debian
packages, but here are the largest teams listed to show how many they
have open (and total count in parentheses):
938 (9657) https://salsa.debi
Package: wnpp
Severity: wishlist
Owner: Hilko Bengen
* Package name: acstore
Version : 0~20240407
Upstream Author : Joachim Metz et al.
* URL or Web page : https://github.com/log2timeline/acstore
* License : Apache 2.0
Programming lang: Python
Description : Attribu
On Tue, Jan 14, 2025 at 06:10:22PM +0100, Simon Josefsson wrote:
>
> Do you have earlier examples of Debian modifying upstream's desired wire
> crypto-sensitive protocol in the way like what is being done for GnuPG?
> Maybe there are some older OpenSSH or OpenSSL patches like that.
To reiterate,
Marco d'Itri writes:
> On Jan 14, Simon Josefsson wrote:
>
>> Do you have earlier examples of Debian modifying upstream's desired wire
>> crypto-sensitive protocol in the way like what is being done for GnuPG?
>> Maybe there are some older OpenSSH or OpenSSL patches like that.
> Like the Kerbero
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: gnupg24
Version : 2.4.7
Upstream Author : Werner Koch, et al
* URL : https://www.gnupg.org/
* License : GPL
Programming Lang: C
Description
On Jan 14, Simon Josefsson wrote:
> Do you have earlier examples of Debian modifying upstream's desired wire
> crypto-sensitive protocol in the way like what is being done for GnuPG?
> Maybe there are some older OpenSSH or OpenSSL patches like that.
Like the Kerberos patch for OpenSSH?
--
ciao,
Marco d'Itri writes:
> On Jan 14, Simon Josefsson wrote:
>
>> I don't think it is a good idea to use the powers that comes by being a
>> package maintainer or distribution to force changes of how some piece of
>> software is supposed to work by patching it without changing its name.
> We have be
Quoting Steve McIntyre (2025-01-14 17:27:20)
> Jonas wrote:
> >Quoting Steve McIntyre (2025-01-14 15:16:49)
> >> Jonas wrote:
> >> >Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
> >> >>
> >> >> thank you for the offer but why not have the follow up in a publicly
> >> >> archived list?
Simon Joseffson wrote:
If the justification for those modifications are disagreement with
upstream about how GnuPG should behave with regard to the wire
protocol, it becomes even more clear to me that we are talking about a
fork.
The disagreements are not so much about which wire formats sho
Jon Dowland wrote:
>
>I'm *fairly* sure that a more pressing issue is that MoinMoin requires
>Python 2, which has been abandoned.
>
>At least the stable and deployed versions: 2.0.0a1 is the first release
*nod*
I think we have moin2 packages just about ready for use, but I have
worries: it's not
Jonas wrote:
>Quoting Steve McIntyre (2025-01-14 15:16:49)
>> Jonas wrote:
>> >Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
>> >>
>> >> thank you for the offer but why not have the follow up in a publicly
>> >> archived list? happy to switch to -www, if -devel is not ideal
>> >
>> >Th
On Jan 14, Simon Josefsson wrote:
> I don't think it is a good idea to use the powers that comes by being a
> package maintainer or distribution to force changes of how some piece of
> software is supposed to work by patching it without changing its name.
We have been doing this since Debian exis
Quoting Steve McIntyre (2025-01-14 15:16:49)
> Jonas wrote:
> >Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
> >>
> >> thank you for the offer but why not have the follow up in a publicly
> >> archived list? happy to switch to -www, if -devel is not ideal
> >
> >Then let's move to the
Jonas wrote:
>Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
>>
>> thank you for the offer but why not have the follow up in a publicly
>> archived list? happy to switch to -www, if -devel is not ideal
>
>Then let's move to the tinker team mailinglist:
>https://alioth-lists.debian.net/c
si...@josefsson.org wrote:
>
>Fundamentally, I believe that forking upstream projects in this way is
>bad for users of distributions like Debian. Each project should own the
>moral compass of its own destiny, and users can decide what to use if
>they agree with that compass. That's why I personal
Thank you for clarifying a bit about who is behind FreePG!
Andrew Gallagher writes:
> Simon Joseffson mailto:si...@joseffson.org>> wrote:
>
>> It seems there is push from the anti-GnuPG people to promote a fork
>> called FreePG instead of real GnuPG, will you package that?
>>
>> https://gitlab.c
On 2025-01-14, Stephan Verbücheln wrote:
> This appears silly from an engineering perspective, but there is a
> specific motivation behind it: Proton (the mail company) wants this to
> simplify the implementation of PGP with Browser APIs.
But is this motivation more important than a coherent ecos
Simon Joseffson mailto:si...@joseffson.org>> wrote:
> It seems there is push from the anti-GnuPG people to promote a fork called
> FreePG instead of real GnuPG, will you package that?
>
> https://gitlab.com/freepg/gnupg
FreePG is not an anti-GnuPG project, if anything it’s trying to keep GnuPG o
On Mon, Jan 13, 2025 at 02:04:00PM +0100, Simon Josefsson wrote:
> 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
On Mon Jan 13, 2025 at 10:27 PM GMT, Ahmad Khalifa wrote:
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 :)
The two git-backed wikis I am familiar with (Ik
First a big thank you for all your efforts re OpenPGP! It is hard to
navigate when there are conflicting requirements around. We need more
boats attempting to navigate rather than less, increasing the chances to
reach fertile grounds.
Daniel Kahn Gillmor writes:
> But the schism is, as far as
This appears silly from an engineering perspective, but there is a
specific motivation behind it: Proton (the mail company) wants this to
simplify the implementation of PGP with Browser APIs.
As you said, too many optional ciphers are bad for compatibility. Note
that the key preferences do not hel
Le 2025-01-14 02:58, Ángel a écrit :
reading /proc/fs/ext4/*/options:
Thank you.
It appears that these options lack auto_da_alloc, which may (still
hypothetical at this point) explain the much better performance of
--force-unsafe-io in your case.
Cheers,
--
Julien Plissonneau Duquène
On Tue, Jan 14, 2025 at 08:52:39AM +0100, Philip Hands wrote:
> I'd really like to know how it is possible for one to use an LLM to make
> a contribution to a permissively licensed project (e.g. Expat) without
> in effect stealing the code from one's own tribe of Copyleft authors.
>
> Can one even
37 matches
Mail list logo
