bug#67800: File guix-publish.service missing on foreign distro installations

[Philippe SWARTVAGHER]

Hello,

I'm running Guix on a foreign distro, Debian, with systemd. I installed 
Guix with the shell installer script.


The documentation 
https://guix.gnu.org/manual/en/html_node/Invoking-guix-publish.html 
mentions (at the bottom) that I can execute the following command to 
enable the Guix Publish service:


ln -s ~root/.guix-profile/lib/systemd/system/guix-publish.service 
/etc/systemd/system/


However, the file 
~root/.guix-profile/lib/systemd/system/guix-publish.service does not 
exist (actually, ~/root/.guix-profile doesn't exist).



Philippe.

bug#67566: Package cube fails to build

[Philippe SWARTVAGHER]

Hello,

On an up-to-date Guix version, the package cube fails to build:

guix build cube

[...]

checking Qt specification... linux-g++
checking for Qt's version...
configure: error: Cannot detect Qt's version.
configure: error: ./configure failed for build-backend

This impacts the package scorep-openmpi, which depends on cube.

And while solving this bug, cube could be updated to version 4.8.2

Thanks!

--
Philippe SWARTVAGHER
Assistant Professor @ ENSEIRB-MATMECA
Research team Topal @ Inria Bordeaux-Sud Ouest

bug#54557: “fakechroot” execution engine doesn’t work for Bash

[Philippe SWARTVAGHER]

Le 24/03/2022 à 22:02, Ludovic Courtès a écrit :

Hello!

The “fakechroot” engine fails when applied to ‘bash’:

--8<---cut here---start->8---
$ guix pack -RR bash -S /bin=bin
/gnu/store/mnbmklbvd1pk7yby0k8h26msk6z11m1m-bash-tarball-pack.tar.gz
$ (cd /tmp/pack; tar xf 
/gnu/store/mnbmklbvd1pk7yby0k8h26msk6z11m1m-bash-tarball-pack.tar.gz)
$ unshare -mrf sh -c 'mount -t tmpfs -o ro none /gnu/store; 
GUIX_EXECUTION_ENGINE=fakechroot /tmp/pack/bin/bash --version'
/tmp/pack/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin//bash: out 
of memory to store relocation results for /tmp/pack/bin/bash
--8<---cut here---end--->8---

The message comes from ld.so.  My guess is that the problem comes from
Bash’s terrible ‘malloc’ replacement:

--8<---cut here---start->8---
$ objdump -T /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash | 
grep malloc
004ae6f0 gDF .text  003b  Basemalloc_usable_size
004ae850 gDF .text  0009  Basemalloc
00484e70 gDF .text  005b  Basexmalloc
004ee020 gDO .bss   0004  Base
malloc_trace_at_exit
004e8c24 gDO .data  0004  Base
malloc_mmap_threshold
00484f70 gDF .text  00dd  Basesh_xmalloc
004f7a04 gDO .bss   0004  Basemalloc_trace
004f7a08 gDO .bss   0004  Basemalloc_flags
004ae730 gDF .text  0005  Basesh_malloc
004f7a00 gDO .bss   0004  Basemalloc_register
004ae660 gDF .text  000c  Base
_malloc_unblock_signals
004ae630 gDF .text  002e  Base
_malloc_block_signals
--8<---cut here---end--->8---

[Time passes…]  I confirmed this hypothesis by running:

   guix pack -RR -S /bin=bin -m manifest.scm

on this manifest:

--8<---cut here---start->8---
(use-modules (guix) (guix utils)
  (guix profiles)
  (gnu packages bash))

(define bash-sans-malloc
   (package/inherit bash
 (name "bash-sans-malloc")
 (arguments
  (substitute-keyword-arguments (package-arguments bash)
((#:configure-flags flags ''())
 `(cons "--without-bash-malloc" ,flags))

(packages->manifest (list bash-sans-malloc))
--8<---cut here---end--->8---

Works just fine:

--8<---cut here---start->8---
$ unshare -mrf sh -c 'mount -t tmpfs -o ro none /gnu/store; 
GUIX_EXECUTION_ENGINE=fakechroot /tmp/pack/bin/bash --version'
GNU bash, version 5.1.8(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
--8<---cut here---end--->8---

So in the end, it’s a bug report that’s kinda closed already.

Perhaps we should build Bash ‘--without-bash-malloc’ unconditionally in
‘core-updates’?  The ‘INSTALL’ file reads:

--8<---cut here---start->8---
'--with-bash-malloc'
  Use the Bash version of 'malloc' in the directory 'lib/malloc'.
  This is not the same 'malloc' that appears in GNU libc, but an
  older version originally derived from the 4.2 BSD 'malloc'.  This
  'malloc' is very fast, but wastes some space on each allocation.
  This option is enabled by default.  The 'NOTES' file contains a
  list of systems for which this should be turned off, and
  'configure' disables this option automatically for a number of
  systems.
--8<---cut here---end--->8---

There might be other options if we want to keep it, such as changing the
ELF visibility of those symbols, but I wonder if it’s worth the effort.

Thoughts?

Ludo’.


Hello,

FTR, the --without-bash-malloc is used in the Debian bash package:

apt source bash

cd bash-5.1/debian

grep -Irn without-bash-malloc
changelog:145:  * Configure the normal build --without-bash-malloc as well.
changelog:1125:  * Configure the static build --without-bash-malloc.
changelog:1462:  * Disable the GNU/kFreeBSD kludge 
(--without-bash-malloc). Closes: #234137.
changelog:1546:  * Configure --without-bash-malloc on GNU/FreeBSD 
(closes: #194182).
changelog:1739:  * Configure --without-bash-malloc. At least on hppa, 
this fixes an error,

rules:79:    --without-bash-malloc


This option is also advised in Linux From Scratch: 
https://www.linuxfromscratch.org/lfs/view/stable/chapter08/bash.html


--
Philippe

bug#50026: Specify a pull-request in --with-branch package transformations

[Philippe SWARTVAGHER]

Le 12/08/2021 à 17:30, raingloom a écrit :
> How is this different compared to just using the git URL and branch that
> the pull request is from?
>
> For example, here we have a merge request:
> https://gitlab.com/guile-git/guile-git/-/merge_requests/30
> From this repo:
> https://gitlab.com/plattfot/guile-git
> and this branch:
> git_ignore_path_is_ignored
>
> This is how merge requests work, there is always a (pretty easy to
> find) source repo and branch that should be merged into a branch of the
> target repo.
>
> This is how you would build it in this case:
> guix build \
> --with-git-url=guile-git=https://gitlab.com/plattfot/guile-git \
> --with-branch=guile-git=git_ignore_path_is_ignored guile-git
>
> Someone could make a script that extracts this information from the
> various git forges (Gitea, GitLab, GitHub, etc), but all you get is
> that you can copy one URL instead of one URL and one branch name.
When the fork repository is private and you don't have access to it, you
can't use --with-git-url=package=https://someforge/user/private-fork
because you won't be allowed to. However, you can have access to the
pull request made in the public origin repository.
>
> I'm not aware of any standard way to access merge requests that would
> work across all git forges, 

Me neither, but maybe just asking Git to fetch all exisitng remote
references (including these kind of special references representing pull
requests) before trying to switch to the asked pull-request/branch may
do the trick (it's maybe more complex than that, I don't know).


> so IMHO the implementation complexity is
> not worth it for such a tiny improvement. There is more important work.
Sure, it was just to point out this use-case, and since other tools can
handle, maybe it is not so hard to implement. I'm totally aware this is
a non-prioritary corner-case.

-- 
Philippe SWARTVAGHER

PhD Student
TADaaM team, Inria Bordeaux Sud-Ouest

bug#50026: Specify a pull-request in --with-branch package transformations

[Philippe SWARTVAGHER]

Hello,

A nice feature would be to be able to use a pull-request as branch to
specify in the `--with-branch` transformation option.

A use-case is to use a pull-request coming from a private fork, thus we
can't use the combination `--with-git-url= with-branch=`.


As an example, if I follow
https://gitlab.inria.fr/help/user/project/merge_requests/reviews/index.md#checkout-merge-requests-locally-through-the-head-ref,
I should be able to do something like:

```bash

guix build chameleon --with-branch=chameleon=merge-requests/262/head

```

(with 262 being the pull-request I'm interested in) However, this fails:

```

guix build: erreur : impossible de récupérer la branche «
merge-requests/262/head » depuis
https://gitlab.inria.fr/solverstack/chameleon : cannot locate
remote-tracking branch 'origin/merge-requests/262/head'
```

While commands stated in the documentation work well:

```bash

git clone https://gitlab.inria.fr/solverstack/chameleon && cd chameleon

git fetch origin merge-requests/262/head:mr-262

git checkout mr-262

```

I guess the fetch step is lacking in the way Guix handles the
`--with-branch` transformation.


FYI, Ansible is able to do things like that (see
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/git_module.html),
by combining options `refspec` and `version`.


I'm aware a workaround is to download the patch corresponding to the
pull-request and using `--with-patch`, however handling it directly with
`--with-branch` would be more handy !

Thanks,

-- 
Philippe SWARTVAGHER

PhD Student
TADaaM team, Inria Bordeaux Sud-Ouest

bug#45300: [Suggestion] Add option --with-patch

[Philippe SWARTVAGHER]

Hello,

We already have `--with-branch=`, `with-commit=`, ... An additional
option could be `--with-patch=package=add-extra-feature.patch` which
would apply the patch file `add-extra-feature.patch` located in the my
current directory to the sources of `package` before Guix starts
building `package`.

This would bring the possibility to easily share patches (for tests,
reviews, ... for instance) without having to commit the patch in the
source repository of the package, without changing the package
definition, and without applying ourselves the patch to our local source
repository of the package.

Thanks !

-- 
Philippe SWARTVAGHER

PhD Student
TADaaM team, Inria Bordeaux Sud-Ouest