Hello Steve,
I do understand your concern about the time_t structure change and I
also admit that there are some room of improvement how the syslog-ng
package manage the library versioned dependency, but this is not the
solution.
Based on https://wiki.debian.org/NonMaintainerUpload, the binNMU sh
Hi!
On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote:
> On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote:
> > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote:
> > > On 2024-03-29 22:41, Guillem Jover wrote:
> > > I think with my upstream hat on I'd rather ship a clear manifest (c
Package: wnpp
Severity: wishlist
Owner: Xiyue Deng
* Package name: emacs-corfu-terminal
Version : 0.7
Upstream Author : Akib Azmain Turja
* URL or Web page : https://codeberg.org/akib/emacs-corfu-terminal
* License : GPL-3
Programming lang: Emacs Lisp
Description
Package: wnpp
Severity: wishlist
Owner: Xiyue Deng
* Package name: emacs-popon
Version : 0.13
Upstream Author : Akib Azmain Turja
* URL or Web page : https://codeberg.org/akib/emacs-popon
* License : GPL-3
Programming lang: Emacs Lisp
Description : Pop floating te
Am 05.04.24 um 12:31 schrieb John Paul Adrian Glaubitz:
Hello,
On Tue, 2024-04-02 at 12:40 +0200, Pierre-Elliott Bécue wrote:
If at all, this whole situation is a plea to finally end single-person
maintainership of packages.
It is my opinion that all packages should be either in collab maint o
Hi Attila,
On Fri, 2024-04-05 at 09:47 +0100, Attila Szalay wrote:
> Based on https://wiki.debian.org/NonMaintainerUpload, the binNMU
> should
> be careful
I think you are confusing binNMUs and NMUs.
See https://wiki.debian.org/binNMU
They are handled more or less automatic as soon as a rebuild
Hi
Sent to d-devel and d-mentors, since the members of both lists are the
target audience. If you reply, please consider whether both lists should
see the message (and prune the recipient list accordingly as necessary).
In response to a recent thread on debian-devel about editor support for
On Sat, 30 Mar 2024 at 14:16:21 +0100, Guillem Jover wrote:
> in my mind this incident reinforces my view that precisely storing
> more upstream stuff in git is the opposite of what we'd want, and
> makes reviewing even harder, given that in our context we are on a
> permanent fork against upstream
On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote:
> I find that having the upstream source code in git (in the same form that
> we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> but excluding any files that we exclude by repacking) is an extremely
> useful t
On Fri, 5 Apr 2024 at 16:18, Colin Watson wrote:
>
> On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote:
> > I find that having the upstream source code in git (in the same form that
> > we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> > but excluding any fi
Pierre-Elliott Bécue wrote on 31/03/2024 at 14:31:37+0200:
> Wookey wrote on 31/03/2024 at 04:34:00+0200:
>
>> On 2024-03-30 20:52 +0100, Ansgar 🙀 wrote:
>>> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
>>> Possibly also TPM modules in computers.
>>>
>>> These can usually b
Dear Debian Team,
Whenever I try to select a file in any application, the file picker (or file
manager) opens in the background, giving me a very hard time right now.
Could you please provide some guidance on how to resolve this issue? Any
assistance or suggestions you could offer would be grea
Am Freitag, dem 29.03.2024 um 23:20 +0100 schrieb Moritz Mühlenhoff:
> Russ Allbery wrote:
> > I think this question can only be answered with reverse-engineering of the
> > backdoors, and I personally don't have the skills to do that.
>
> In the pre-disclosure discussion permission was asked to
In days of yore (Fri, 05 Apr 2024), Daniel Leidert thus quoth:
> Am Freitag, dem 29.03.2024 um 23:20 +0100 schrieb Moritz Mühlenhoff:
> > Russ Allbery wrote:
> > > I think this question can only be answered with reverse-engineering of the
> > > backdoors, and I personally don't have the skills to
There's also a very through exploration at https://github.com/amlweems/xzbot
Including, very interestingly, a discussion of format(s) of the
payload(s), and a mechanism to replace the backdoor key to play with
executing commands against a popped sshd, as well as some code to go
along with it.
p
On Fri, 2024-04-05 at 20:47 +0200, Sirius:
> > If there is a final result, can we as a project share the results on a
> > prominent place? Or at least under d-devel-announce and/or d-security-
> > announce? I was also wondering about what could have been compromised,
> > what data might have been s
On Apr 05, Simon McVittie wrote:
> I find that having the upstream source code in git (in the same form that
> we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> but excluding any files that we exclude by repacking) is an extremely
> useful tool, because it lets me trace
17 matches
Mail list logo
