Re: RFC: Sensible-editor sensible-utils alternative and update
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 > > something like > > SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ; else > > sensible-editor-tty; fi;' > > Couldnt i already put that it in ~/bin/editor and set > EDITOR to that script? Yes but it does not change the need that the editor called should block and be more like ex or vi BTW it is better on debian system to set both EDITOR and SENSIBLE_EDITOR to ~/bin/editor in this case Bastien > > > > signature.asc Description: This is a digitally signed message part.
Porterbox - impossible efficient debugging?
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 currently in Debian, and see that it would worsen with the next release of coq-elpi (!). So the next step to investigate the matter was to reproduce it with the latest upstream of its dependency elpi (which I suspect of being the culprit even though its successful compilation with its extensive compile-time testing says otherwise). 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! I'm quite fond of the single-page just-follow-the-steps tutorial: https://dsa.debian.org/doc/schroot/ hence my dream is to be able to do something like the following to get not only a cross-compilation but also cross-running through whatever virtual system (say provided by a dd-cross-schroot package) : echo -n "Target arch: " && read targetarch && echo -n "Session ID: " && read sessionid && dd-cross-schroot-setup - s $sessionid -a $targetarch /* much, much work would be done here */ dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get build-dep foo dd-cross-schroot-run -s $sessionid -a $targetarch /* do what needs done for foo on the target architecture */ dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install ./*foo*_3.14-159_$targetarch.deb dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get build-dep bar /* installation of its dep foo is hence covered by a local package */ dd-cross-schroot-run -s $sessionid -a $targetarch /* do what I needs done for bar on the target architecture */ dd-cross-schroot-clean -s $sessionid -a $targetarch Of course, that wouldn't be as good as an actual box of the right architecture, but it would definitely help getting many problems solved. As you may have noticed from the above I'm quite clueless on how schroot and cross-compilation work - and to be honest, I'd like to stay so as I have other itches to scratch and hopefully other areas of expertise - but I'm hopeful others have the competence and the will to provide solutions. Cheers, J.Puydt
Re: Porterbox - impossible efficient debugging?
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 usual recommendations are "unpack and try pointing to it via stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your case". Consider using local qemu chroots instead. > dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install > ./*foo*_3.14-159_$targetarch.deb This still runs random code as root. -- WBR, wRAR signature.asc Description: PGP signature
Re: Porterbox - impossible efficient debugging?
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 found myself quite often, too. 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. But I understood that DSA was reluctant to enable unprivileged user namespaces on Debian machines because of security concerns... Couldn't an exception be made for porterboxes? After all, these are dedicated to porting and nothing sensitive should be done there. [1] https://lists.debian.org/msgid-search/20240625081620.ga1354...@subdivi.de I'm quite fond of the single-page just-follow-the-steps tutorial: https://dsa.debian.org/doc/schroot/ hence my dream is to be able to do something like the following to get not only a cross-compilation but also cross-running through whatever virtual system (say provided by a dd-cross-schroot package) : [...] Actually, you can achieve something similar with qemu-user(-static), binfmt and pbuilder: sudo pbuilder create --basetgz sid-ppc64el.tgz \ --distribution sid --debootstrapopts --variant=minbase \ --architecture ppc64el sudo pbuilder login --basetgz sid-ppc64el.tgz Of course, that wouldn't be as good as an actual box of the right architecture, but it would definitely help getting many problems solved. As you may have noticed from the above I'm quite clueless on how schroot and cross-compilation work - and to be honest, I'd like to stay so as I have other itches to scratch and hopefully other areas of expertise - but I'm hopeful others have the competence and the will to provide solutions. Keep in mind that the solution above remains emulation and I've already faced situations where behaviour differed with actual hardware. That being said, it helped me a lot in debugging packages on exotic architectures. Cheers, -- Stéphane
Re: Porterbox - impossible efficient debugging?
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 > > binary packages in the schroot to test it against different coq- > > elpi! > > Yes, the usual recommendations are "unpack and try pointing to it via > stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your > case". It doesn't: it's a mix of languages. C, OCaml, elpi and Coq I would say. > Consider using local qemu chroots instead. > I'd like a one-page easy-to-use tutorial on this. In fact, my question/proposition was to have scripts making it trivial to use. > > dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install > > ./*foo*_3.14-159_$targetarch.deb > > This still runs random code as root. > I don't think running random code as root in a virtual environment I'm going to delete before the end of the day is a security issue. Cheers, J.Puydt
Re: Porterbox - impossible efficient debugging?
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- > > > elpi! > > > > Yes, the usual recommendations are "unpack and try pointing to it via > > stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your > > case". > > It doesn't: it's a mix of languages. C, OCaml, elpi and Coq I would > say. > > > Consider using local qemu chroots instead. > > > > I'd like a one-page easy-to-use tutorial on this. It's like normal sbuild but pass --arch=foo to sbuild-createchroot and to sbuild. You'll need qemu-user-static installed. That's all IIRC. > > > dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install > > > ./*foo*_3.14-159_$targetarch.deb > > > > This still runs random code as root. > > > > I don't think running random code as root in a virtual environment I'm > going to delete before the end of the day is a security issue. Well, that's the only reason I can think for not being able to run root commands in porterbox chroots directly. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1078602: ITP: iaito -- GUI for radare2, a libre reverse engineering framework
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 libre reverse engineering framework This is the official graphical interface for radare2. It aims to conver other r2 features, not just the disassembler but also forensics, networking, bindiffing, solvers, and more.
Re: Porterbox - impossible efficient debugging?
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/debian/grow-your-ideas/-/issues/40 (sorry, I have not had the time/energy to bring this up with the sysadmin team or otherwise promote it). unshare and rootless podman have essentially the same requirements: they use the same parts of the Linux kernel. > But I understood that DSA > was reluctant to enable unprivileged user namespaces on Debian machines > because of security concerns... Couldn't an exception be made for > porterboxes? After all, these are dedicated to porting and nothing sensitive > should be done there. The security concern that I'm aware of is mentioned in the issue I linked, but it's a trade-off: allowing rootless unshare/podman would make us vulnerable to some kernel vulnerabilities that are currently mitigated by disabling user namespaces, but conversely, setuid-root things like schroot and having chroots containing setuid binaries owned by "real root" makes us vulnerable to some attacks that rootless unshare/podman would protect us from. smcv
Salsa connection errors or slowness has improved (Re: Request for feedback on draft: DEP-18)
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.debian.org is about to get a hardware update which should make it a tad snappier. Salsa recently gained a shared riscv64 runner so you can now test a new architecture in Salsa-CI, and based on https://salsa.debian.org/salsa/support/-/issues/266 and https://salsa.debian.org/salsa/support/-/issues/301 more shared runners on various architectures might be coming. Salvo and others also pointed out that "git push" occasionally failed. According to https://salsa.debian.org/salsa/support/-/issues/381 that issue should be fixed by now. I also remember seeing this earlier, but I have not experienced it a single time in at least two weeks. One remaining thing that affects negatively salsa.debian.org are occasional HTTP/2 errors. If you also experience these, you might want to +1 the issue https://salsa.debian.org/salsa/support/-/issues/404 or help the Salsa admins debug it. As you probably guessed, I am a heavy user of Salsa, and very grateful to Salsa admin for maintaining it! - Otto
Intent to MBF: move from fuse to fuse3
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 fuse3 Source: SOURCE Version: VERSION Severity: normal Dear Maintainer, your package currently (Build-)Depends on fuse - that is fuse 2.x. A newer version of fuse, fuse3, is available since at least buster. fuse (2.x) and fuse3 are not co-installable. On a typical Debian Desktop install, fuse3 is installed, and fuse 2.x cannot be installed. This effect can be observed in the popcon graphs: https://qa.debian.org/popcon.php?package=fuse https://qa.debian.org/popcon.php?package=fuse3 Please migrate your package to fuse3, so our users can actually use it, and we can remove fuse 2.x in forky. --- Aaron M. Ucko sra-sdk (U) Alastair McKinstry cctools Alessio Treglia mp3fs (U) Alex Myczko xrdp (U) Aloïs Micard wit Anders Kaseorg openafs (U) Andrea Capriotti fuse-umfuse-fat (U) fuse-umfuse-iso9660 (U) umview (U) Andreas Tille sra-sdk (U) Andrew Ayer disorderfs (U) Anthony Fok fuse-convmvfs (U) Apollon Oikonomopoulos jmtpfs Barak A. Pearlmutter fossil Bastian Blank s390-tools (U) Bastien Roucariès libfuse-perl (U) Benjamin Kaduk openafs Bernd Schubert unionfs-fuse Bernd Zeimetz ceph (U) Blair Noctis rust-cntr-fuse (U) rust-cntr-fuse-sys (U) Boris Pek q4wine Ceph Packaging Team ceph Charles Plessy sra-sdk (U) Chris Lamb disorderfs (U) Chrysostomos Nanakos archivemount Cédric Boutillier ruby-fusefs (U) Daniel Baumann ceph (U) David Paleino fuseiso David Steele cryfs Debian Libvirt Maintainers libguestfs Debian Med Packaging Team sra-sdk Debian Multimedia Maintainers mp3fs Debian Perl Group libfuse-perl Debian PhotoTools Maintainers gphotofs Debian Python Team python-llfuse (U) Debian QA Group fosfat gnunet-fuse obexfs obexftp plptools rdiff-backup-fs tup zfs-fuse Debian Remote Maintainers xrdp Debian Ruby Team ruby-fusefs Debian Rust Maintainers rust-cntr-fuse rust-cntr-fuse-sys Debian S/390 Team s390-tools Debian Security Tools afflib dislocker libbde libewf libfsapfs libfvde libolecf libqcow libregf libsmraw libvhdi libvmdk libvshadow libvslvm winregfs xmount Debian systemd Maintainers casync Debian VSquare Team fuse-umfuse-ext2 fuse-umfuse-fat fuse-umfuse-iso9660 umview Dennis Braun mp3fs (U) Dmitry E. Oboukhov fuse-convmvfs (U) mhddfs Dmitry Smirnov gfarm2fs Dominik George xrdp (U) Dylan Aïssi android-file-transfer Eduard Bloch apt-cacher-ng encfs Eugene V. Lyubimkin bindfs Felipe Sateler casync (U) Felix Zielcke grub2 (U) Filippo Giunchedi fuse-umfuse-ext2 (U) fuse-umfuse-fat (U) fuse-umfuse-iso9660 (U) umview (U) Francisco Vilmar Cardoso Ruviaro libvhdi (U) Gao Xiang erofs-utils Giovani Augusto Ferreira dislocker (U) winregfs (U) GRUB Maintainers grub2 gtkpod Maintainers ifuse Guido Günther libguestfs (U) Guido Trotter fuse-umfuse-ext2 (U) fuse-umfuse-fat (U) fuse-umfuse-iso9660 (U) umview (U) Herbert Parentes Fortes Neto gphotofs (U) Hilko Bengen libbde (U) libfsapfs (U) libfvde (U) libguestfs (U) libolecf (U) libqcow (U) libregf (U) libsmraw (U) libvhdi (U) libvmdk (U) libvshadow (U) libvslvm (U) Holger Levsen disorderfs (U) Hypra Team compiz James Page ceph (U) Joao Eriberto Mota Filho afflib (U) Jonathan Carter btfs Jordi Mallach grub2 (U) Julian Andres Klode grub2 (U) Jérôme Charaoui httpdirfs-fuse Lennart Weller s3backer Ludovico Gardenghi fuse-umfuse-fat (U) Ludovico Gardenghi fuse-umfuse-ext2 (U) fuse-umfuse-iso9660 (U) umview (U) Magnus Holmgren pike8.0 Martin Pitt casync (U) Mate Kukri grub2 (U) Matthew Harm Bekkema fuse-zip Mattia Rizzolo s3fs-fuse Mattias Ellert xrootd Michael Meskes avfs Michael Prokop xmount (U) Michal Suchanek httpfs2 Mike Gabriel xrdp (U) Mike Hommey vmfs-tools Mikhail Kshevetskiy smbnetfs Nicholas Robinson-Wall tmfs Nikolaus Rath python-llfuse Norbert Schlia ffmpegfs Paul van Tilburg ruby-fusefs (U) Pierre Chifflier libewf (U) Ralf Jung osspd (U) Ralph Ronnquist fusefile Reproducible builds folks disorderfs Richard Jones libguestfs (U) Ritesh Raj Sarraf mergerfs uml-utilities (U) Romain Beauxis libfuse-perl (U) Sam Hartman openafs (U) Samuel Thibault compiz (U) Sascha Steinbiss python-fusepy Sebastian Reichel s3backer (U) Sebastien Delafond
Bug#1078659: ITP: emacs-eat -- Emulate A Terminal, in a region, in a buffer and in Eshell
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 a region, in a buffer and in Eshell Eat is a terminal emulator. It can run most (if not all) full-screen terminal programs, including Emacs.
Bug#1078662: ITP: python-auto-pytabs -- Automatically generate code examples for different Python versions in mkdocs or Sphinx based documentations
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 Programming Lang: Python Description : Automatically generate code examples for different Python versions in mkdocs or Sphinx based documentations Python-autopytabs helps to automatically generate code examples for different Python versions, whether you're using MkDocs, Sphinx, or even just plain Markdown. It simplifies the complexities by automatically generating version-specific examples at build time, ensuring consistency while you maintain just one version of each example. I want to package this as it is a reverse dependency of the 'netbox' package that I’m working on. I intent to maintain this package within the Debian Python Team. Thank you, Kathara Sasikumar
Bug#1078664: ITP: sphinx-jinja2-compat -- Patches Jinja2 v3 to restore compatibility with earlier Sphinx versions
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 : Expat Programming Lang: Python Description : Patches Jinja2 v3 to restore compatibility with earlier Sphinx versions Sphinx-jinja2-compat provides patches for Jinja2 v3 to ensure compatibility with older Sphinx versions. I wish to package sphinx-jinja2-compat as it is a dependency for another package that I am working on. I intend to maintain it within the Debian Python Team. Thank you, Kathara Sasikumar
