Re: Login to a guix container

On Mon, Jan 25, 2021 at 08:29:32AM +0100, Ricardo Wurmus wrote: > In your requirements for an audit, how does a “Guix container” differ > from a “Linux container”? Guix uses the kernel features like cloning > namespaces and unsharing the filesystem directly. It merely mounts > individual store lo

Re: Login to a guix container

Pjotr Prins writes: > Anyway, off-topic on guix-dev, so I apologise. I must say that 'guix > environment -C' is one of the greatest Guix inventions and I just > start thinking of more applications beyond hosting web servers and > development environments. It is lovely :). Thanks everyone! I ag

Re: Qt 5.11 tarballs anyone?

Hi Ludo, On Sun, 24 Jan 2021 at 12:46, Ludovic Courtès wrote: > It’s been two years since commit > 0791437f972caa7e48de91ad5cb150a614f617c2 but we lost key tarballs from [...] > This is a reminder of how important Disarchive is! > (See .) Yeah! Definitively

Re: Guix in Debian!

Hi Vagrant, On Sat, 23 Jan 2021 at 20:04, Vagrant Cascadian wrote: > Now on Debian you should be able to: > > apt install guix > guix install dpkg > guix environment --ad-hoc dpkg -- dpkg -i ./guix_1.2.0-3_amd64.deb > > It is almost like symmetry! Chicken-egg problem. Somehow, Debian alr

Re: Questions regarding Python packaging

Hi Ryan, > I think if we do that then Python will need a treatment similar to GCC, > where we don't expose the package and instead offer a compound package > (could be called "python-toolchain" or just "python") which includes pip > and setuptools. The last decades of python packaging have trained

Re: Qt 5.11 tarballs anyone?

Hi, zimoun skribis: > How could I list all the tarballs that ci.guix.gnu.org has? I suppose you could simply run something like: guix build -n --sources=all $(guix package -A | cut -f1) and see what happens. That said, I think Chris Baines recently added something to the Guix Data Service

Re: Questions regarding Python packaging

On January 25, 2021, Lars-Dominik Braun wrote: > Being able to demote setuptools and pip > to ordinary packages is merely a side-effect, because they’re not > essential any more. I didn't read all of PEP 517, does it deprecate bundling pip with Python? My understanding was that it just gives mai

Re: Guix in Debian!

On Sat, 2021-01-23 at 20:04 -0800, Vagrant Cascadian wrote: > So, a while back I mentioned that Guix was present in Debian > "experimental": > >   https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00254.html > > And it was useable for a brief window of time, but was broken due to > some is

Re: Qt 5.11 tarballs anyone?

Ludovic Courtès writes: > Hi, > > zimoun skribis: > >> How could I list all the tarballs that ci.guix.gnu.org has? > > I suppose you could simply run something like: > > guix build -n --sources=all $(guix package -A | cut -f1) > > and see what happens. > > That said, I think Chris Baines rece

Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'

On Wed, Jan 20, 2021 at 03:19:49PM -0500, Timothy Sample wrote: > Hi janneke, > > Jan Nieuwenhuizen writes: > > > I have reset Guix' wip-full-source-bootstrap branch with a first working > > implementation of the, well, "Full Source Bootstrap" for x86-linux (and > > x86_64-linux). This bootstra

Re: Qt 5.11 tarballs anyone?

Hi Ludo, On Mon, 25 Jan 2021 at 17:52, Ludovic Courtès wrote: >> How could I list all the tarballs that ci.guix.gnu.org has? > > I suppose you could simply run something like: > > guix build -n --sources=all $(guix package -A | cut -f1) This will download only the source at the current Guix.

Re: Qt 5.11 tarballs anyone?

Hi Chris, On Mon, 25 Jan 2021 at 18:49, Christopher Baines wrote: > Kind of, there's this page [1] which tells you about fixed output > derivations for packages, as well as the latest build. > > 1: > https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/fixe

Re: Qt 5.11 tarballs anyone?

zimoun writes: > On Mon, 25 Jan 2021 at 18:49, Christopher Baines wrote: > >> Kind of, there's this page [1] which tells you about fixed output >> derivations for packages, as well as the latest build. >> >> 1: >> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processe

Re: Qt 5.11 tarballs anyone?

On Mon, 25 Jan 2021 at 20:12, Christopher Baines wrote: >>> 1: >>> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/fixed-output-package-derivations?system=x86_64-linux&target=none&latest_build_status=&after_name=&limit_results=&all_results=on >> >> I am

Re: 03/163: build/python: Add a new guix-pythonpath procedure.

Hi! guix-comm...@gnu.org skribis: > apteryx pushed a commit to branch cu/farewell-to-pythonpath > in repository guix. Woow! > commit c3c5bdd2b0ea4588ecba424fdbf6df101d967d3d > Author: Maxim Cournoyer > AuthorDate: Fri Jan 22 09:34:33 2021 -0500 > > build/python: Add a new guix-pythonpath p

Re: 03/163: build/python: Add a new guix-pythonpath procedure.

Hi Ludovic! Ludovic Courtès writes: > Hi! > > guix-comm...@gnu.org skribis: > >> apteryx pushed a commit to branch cu/farewell-to-pythonpath >> in repository guix. > > Woow! > >> commit c3c5bdd2b0ea4588ecba424fdbf6df101d967d3d >> Author: Maxim Cournoyer >> AuthorDate: Fri Jan 22 09:34:33 2021 -

ARM Unified Assembly Language - GNU as does some weird stuff

Hello Paul, we are now implementing ARM inline assembly in TinyCC. The traditional ARM inline assembler is finished now. Now we started implementing the Unified Assembly Language dialect. I'd like to have some help which constructs are valid and which are not. (GNU as 2.34 seems to have some b

RE: [bootstrappable] ARM Unified Assembly Language - GNU as does some weird stuff

> (1) b #60 > It seems that GNU as ignores the immediate entirely and just always encodes > #0 (to test, do ".syntax unified" and then "b #60" in GNU as). WTF? > Likewise with bl, blx. All assemblers (except M1) do that because the linker is to populate that value at link time using the symbol t

Re: ARM Unified Assembly Language - GNU as does some weird stuff

> (1) b #60 > > It seems that GNU as ignores the immediate entirely and just always encodes > #0 (to test, do ".syntax unified" and then "b #60" in GNU as). WTF? > > Likewise with bl, blx. > > It seems that the debug info still has the user-specified immediate value--but > the executable object

Re: Questions regarding Python packaging

Excerpts from Tanguy LE CARROUR's message of January 22, 2021 9:38 am: > Excerpts from Tanguy LE CARROUR's message of January 6, 2021 4:32 pm: >> Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am: So, I've tried packaging `python-keyring` with those two… `pep517