[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Porterbox - impossible efficient debugging?



Hi,

Le 13/08/2024 à 12:15, julien.puydt@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.GA1354821@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


Reply to: