Package: wnpp
Severity: wishlist
Owner: Kathara Sasikumar
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: sphinx-jinja2-compat
Version : 0.3.0
Upstream Contact: Dominic Davis-Foster
* URL : https://github.com/sphinx-toolbox/sphinx-jinja2-compat
* License
Package: wnpp
Severity: wishlist
Owner: Kathara Sasikumar
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-auto-pytabs
Version : 0.4.0
Upstream Contact: Janek Nouvertné
* URL : https://github.com/provinzkraut/AutoPyTabs
* License : Expat
Pr
Package: wnpp
Severity: wishlist
Owner: Martin
* Package name: emacs-eat
Version : 0.9.4
Upstream Author : Akib Azmain Turja
* URL or Web page : https://codeberg.org/akib/emacs-eat
* License : GPL3+
Programming lang: Emacs Lisp
Description : Emulate A Terminal, in
Fellow developers,
fuse (2.x) is long obsolete, yet we still have a long tail of packages
(Build-)Depending on it. Given fuse and fuse3 are not coinstallable,
IMO we should get packages off fuse.
Below is my proposed MBF wording, and a dd-list.
Chris
---
Subject: SOURCE: move from fuse to fuse
Hi!
In the DEP-18 thread surprisingly many (e.g. Salvo, Johannes, Andrea,
Gioele) complained about Salsa being slow to load, or having
connectivity issues.
I am thus happy to note that the Salsa admins posted in
https://salsa.debian.org/salsa/support/-/issues/395 a comment stating
that salsa.debi
On Tue, 13 Aug 2024 at 13:01:45 +0200, Stéphane Glondu wrote:
> BTW, IIUC, it is be possible with namespaces to give root privileges (or
> enough to install packages) to anybody inside a container. [1] could be a
> way, but it needs unprivileged user namespaces.
See also https://salsa.debian.org/d
Package: wnpp
Severity: wishlist
Owner: Alex Myczko
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: iaito
Version : 5.9.4
Upstream Authors: pancake
URL : https://github.com/radareorg/iaito
* License : GPL-3
Description : GUI for radare2, a
On Tue, Aug 13, 2024 at 01:35:03PM +0200, julien.pu...@gmail.com wrote:
> > > And of course, this is where I came to my wits' end: I can compile
> > > the
> > > new elpi successfully... but I have no way to install this new elpi
> > > binary packages in the schroot to test it against different coq-
Le mardi 13 août 2024 à 15:54 +0500, Andrey Rakhmatullin a écrit :
> On Tue, Aug 13, 2024 at 12:15:22PM +0200,
> julien.pu...@gmail.com wrote:
> > And of course, this is where I came to my wits' end: I can compile
> > the
> > new elpi successfully... but I have no way to install this new elpi
> > b
Hi,
Le 13/08/2024 à 12:15, julien.pu...@gmail.com a écrit :
And of course, this is where I came to my wits' end: I can compile the
new elpi successfully... but I have no way to install this new elpi
binary packages in the schroot to test it against different coq-elpi!
This is a situation I've
On Tue, Aug 13, 2024 at 12:15:22PM +0200, julien.pu...@gmail.com wrote:
> And of course, this is where I came to my wits' end: I can compile the
> new elpi successfully... but I have no way to install this new elpi
> binary packages in the schroot to test it against different coq-elpi!
Yes, the us
Hi,
there was a thread "Any way to install packages+run autopkgtests on
porterbox machines?" in march already. Let me add another problematic
use case.
I'm trying to work on bug #1078549 about the coq-elpi package on
ppc64el. With platti.debian.org I could confirm the failure with the
package cur
Le lundi 12 août 2024, 21:05:17 UTC Richard Lewis a écrit :
> Bastien Roucariès writes:
>
> >> b) but if im in a terminal (even if running in gnome) then i want a
> >> terminal-based editor (based on what i installed)
> >
> > depends for me I prefer to run under emacsclient so you could do
> > s
13 matches
Mail list logo
