bug#55358: docker containers stopped when doing guix install or guix shell

2023-05-19 Thread Csepp


Remco van 't Veer  writes:

> Hi Maxim and Zimoun,
>
> 2023/02/09 13:26, Remco van 't Veer:
>
>> I think I know what is causing the issue.  Both the "standard" mysql and
>> postgres containers use user-id 999 to run the database service (this
>> seems like a common practice because the redis container is configured
>> similarly).  That user-id is also configured as guixbuilder01 so I guess
>> the guix daemon is killing those when processes when it finishes doing
>> builds.
>
> I found a solution / workaround for this problem by using
> "userns-remap".  This feature allows the remapping of uids and guids to
> different ranges.  I tried it by hacking the required files into my
> etc-directory and it works; guix no long kills my database containers.
>
> I'd like to add this feature to docker-service-type having a new
> configuration option named enable-userns-remap? which introduces a new
> user and group (both named dockremap) to do the remapping by adding some
> configurable number to the uids and guids of the running container.  In
> /etc/subuid and /etc/subgid it would look like:
>
>   dockremap:10:65536
>
> See https://docs.docker.com/engine/security/userns-remap/ for
> documentation about this.
>
> WDYT?
>
> Cheers,
> Remco

The rootless podman example that was shared a few months ago could be
relevant to this, since that also adds a subuid/subgid mapping.





bug#63596: guix-git-authenticate fails on fresh git clone

2023-05-19 Thread wolf
Hello,

as instructed on the Building from Git documentation page, I am writing
regarding a failing test (guix-git-authenticate) on a fresh git clone of guix
repository.  I am unsure what the exact commit was (sorry!), but I'm pretty sure
it is not relevant in this case (assuming it was not fixed this week).

$ cat tests/guix-git-authenticate.log
+ '[' -d /home/wolf/sources/guix/.git ]
+ guile -c '(use-modules (git))
  (member "refs/heads/keyring" (branch-list (repository-open ".")))'
+ intro_commit=9edb3f66fd807b096b48283debdcddccfea34bad
+ intro_signer='BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA'
+ cache_key=test-3776
+ guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad 'BBB0 2DDF 
2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA' '--cache-key=test-3776' --stats
+'--end=9549f0283a78fe36f2d4ff2a04ef8ad6b0c02604'
guix git: error: Git error: cannot locate remote-tracking branch 'keyring'
+ v1_2_0_commit=a099685659b4bfa6b3218f84953cbb7ff9e88063
+ guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad 'BBB0 2DDF 
2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA' '--cache-key=test-3776' --stats
+'--end=a099685659b4bfa6b3218f84953cbb7ff9e88063'
guix git: error: Git error: cannot locate remote-tracking branch 'keyring'
FAIL tests/guix-git-authenticate.sh (exit status: 1)

As you can see, it complains about branch `keyring' being missing.  Indeed, once
I created it:

$ g co keyring
branch 'keyring' set up to track 'origin/keyring'.
Switched to a new branch 'keyring'

After this the test passed just fine.  I did not have time to look into it more
in depth nor produce a patch, so I thought I will at least report it, as
instructed by the documentation.

Have a nice day,
W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature


bug#63162: Patch submitted

2023-05-19 Thread Felix Lechner via Bug reports for GNU Guix
Hi,

I received no response to my question but included a relevant patch
after seeing a second such line together with other documentation
patches in Bug#63575. [1]

Kind regards
Felix

[1] https://issues.guix.gnu.org/63575





bug#63591: Upstream change for java-xsdlib

2023-05-19 Thread Bruno Victal
Hi,

Since java.net has closed, my attempts at tracking where
MSV (which java-xsdlib is a subproject of) resides have led me to
 which seems to suggest
that  is the new upstream.


Cheers,
Bruno





bug#58308: guix import -r swallows errors

2023-05-19 Thread Simon Tournier
Hi,

On lun., 15 mai 2023 at 19:46, Simon Tournier  wrote:

> Fixed by .

Pushed as d81701a85aa8aa96f4a853f06fe28693fa8bee12.

Closing.

Cheers,
simon





bug#56556: texlive-babel-dutch with and without texlive-hyphen-dutch: No hyphenation patterns were preloaded

2023-05-19 Thread Simon Tournier
Hi,

Argh!  I am just annoyed by this bug too; and again and again.  How to
make progress?

On ven., 07 avril 2023 at 12:47, Emmanuel Beffara  wrote:

>> > I don't really know how we could fix this: maybe build the formats with
>> > all the hyphenation packages enabled?
>>
>> The intertubes suggest running ‘fmtutil --all’ to get hyphenations
>> packages straight.  Is this something we should do in the TeX Live
>> profile hook for example?
>>
>> Emmanuel, is this what you had in mind when you wrote about compilation
>> of hyphenation patterns above?
>
> Indeed !
>
> Doing that is the job of fmtutil and it should be used for building
> environments that include parts of TeXlive.

Well, it does not appear as easy as the intertubes is suggesting. ;-)

First, please note that texlive-babel- drags texlive-hyphen-

--8<---cut here---start->8---
$ guix graph --path texlive-babel-french texlive-hyphen-esperanto -t bag-emerged
texlive-babel-french@59745
texlive-latex-base@59745
texlive-hyphen-esperanto@59745
--8<---cut here---end--->8---

Other said, the profile contains all the hyphenations for all the
languages.  Therefore, I am not sure ’fmtutil --all’ will do the job out
of the box – I do not know.  Savvy TeX folk, WDYT?

--8<---cut here---start->8---
$ guix shell texlive-base texlive-babel-french
$ find $GUIX_ENVIRONMENT -name "*hyph-*" -print | wc -l
318

$ find $GUIX_ENVIRONMENT -name "*hyph-*" -print | head
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/scripts/hyph-utf8.rb
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/scripts/languages/es/eshyph-make.lua
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/dehyph-exptl
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/hyph-utf8
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-cs.tex
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-rm.tex
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-ml.tex
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-lt.tex
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-pt.tex
/gnu/store/iffpalk5vyyykmll7i9g89lnyzcj505b-profile/share/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-mr.tex
--8<---cut here---end--->8---


Now, let try ’fmtutil --all’ as part of some hook:

--8<---cut here---start->8---
$ git diff
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 6467e464c8..b785fefb08 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1854,6 +1854,12 @@ (define (texlive-font-maps manifest)
 (string-append "--pdftexoutputdir="
maproot "pdftex/updmap"))

+(pk 'start)
+;; Generate hyphenations for Babel and friends.
+(invoke #$(file-append texlive-bin "/bin/fmtutil-sys")
+"--all")
+(pk 'end)
+
 ;; Create ls-R file.  I know, that's not *just* for font maps, but
 ;; we've generated new files, so there's no point in running it
 ;; any earlier.  The ls-R file must act on a full TeX Live tree,
@@ -1870,7 +1876,7 @@ (define (texlive-font-maps manifest)

   (mlet %store-monad ((texlive-base (manifest-lookup-package manifest 
"texlive-base")))
 (if (and texlive-base (pair? texlive-inputs))
-(gexp->derivation "texlive-font-maps" build
+(gexp->derivation "texlive-font-maps-debug" build
   #:substitutable? #f
   #:local-build? #t
   #:properties

$ ./pre-inst-env guix shell texlive-base texlive-babel-french --rebuild-cache
The following derivation will be built:
  /gnu/store/hj7gc1phqqai88cq6blrxvmrifsyhy3h-profile.drv

building TeX Live font maps...
-builder for 
`/gnu/store/37mjkgann15rj95m3vqjs8d20kssz8pm-texlive-font-maps-debug.drv' 
failed with exit code 1
build of 
/gnu/store/37mjkgann15rj95m3vqjs8d20kssz8pm-texlive-font-maps-debug.drv failed
View build log at 
'/var/log/guix/drvs/37/mjkgann15rj95m3vqjs8d20kssz8pm-texlive-font-maps-debug.drv.gz'.
cannot build derivation 
`/gnu/store/hj7gc1phqqai88cq6blrxvmrifsyhy3h-profile.drv': 1 dependencies 
couldn't be built
guix shell: error: build of 
`/gnu/store/hj7gc1phqqai88cq6blrxvmrifsyhy3h-profile.drv' failed
--8<---cut here---end--->8---

Hum, let’s inspect the log of this derivation.  See below the complete
log.  Roughly speaking:

--8<---cut here---start->8---
fmtutil [INFO]: disabled 

bug#63274: dia: Fails to build (Meson: Function does not take positional arguments)

2023-05-19 Thread Ivan Vilata i Balaguer
Ivan Vilata i Balaguer (2023-05-04 17:26:48 +0200) wrote:

> Hi!  It looks like the Meson build of `dia` fails to complete in the version
> of Guix shown below:
> 
> ```
> […]
> commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
> ```
> 
> This is the final part of the build log:
> 
> ```
> starting phase `configure'
> The Meson build system
> […]
> ../source/sheets/meson.build:47:32: ERROR: Function does not take positional 
> arguments.
> […]
> ```

The latest commit in Dia's Git repo (just 3 after the one use by Guix) states
"build: Fix deprecated positional argument for i18n.merge_file":


Building `--with-commit=dia=6ef461d8a04ffcd23df26fc4749cebc6322a5322` is 
successful.

I'll send a patch to fix this.

Cheers!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature


bug#55358: docker containers stopped when doing guix install or guix shell

2023-05-19 Thread Remco van 't Veer
Hi Maxim and Zimoun,

2023/02/09 13:26, Remco van 't Veer:

> I think I know what is causing the issue.  Both the "standard" mysql and
> postgres containers use user-id 999 to run the database service (this
> seems like a common practice because the redis container is configured
> similarly).  That user-id is also configured as guixbuilder01 so I guess
> the guix daemon is killing those when processes when it finishes doing
> builds.

I found a solution / workaround for this problem by using
"userns-remap".  This feature allows the remapping of uids and guids to
different ranges.  I tried it by hacking the required files into my
etc-directory and it works; guix no long kills my database containers.

I'd like to add this feature to docker-service-type having a new
configuration option named enable-userns-remap? which introduces a new
user and group (both named dockremap) to do the remapping by adding some
configurable number to the uids and guids of the running container.  In
/etc/subuid and /etc/subgid it would look like:

  dockremap:10:65536

See https://docs.docker.com/engine/security/userns-remap/ for
documentation about this.

WDYT?

Cheers,
Remco


--
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55358





bug#62995: Cuirass evaluation failures not reported as such

2023-05-19 Thread Ludovic Courtès
Ludovic Courtès  skribis:

> I noticed that evaluation failures are not (not always?) being reported
> with a ❎ as it used to be.  For example:
>
>   https://ci.guix.gnu.org/eval/418466
>
> It is marked as successful but it has zero build jobs:
>
>   https://ci.guix.gnu.org/eval/418466/dashboard
>
> The evaluation log on berlin shows a clear failure though:
>
> ludo@berlin ~$ zcat /var/log/cuirass/evaluations/418466.gz
> Computing Guix derivation for 'x86_64-linux'...  
> In thread:
> socket:21:111: Unknown # object: "#<"

I believe this was fixed by Cuirass commit
899391215045513ddd708b12edade8de71e29b9e.

Ludo’.





bug#63418:

2023-05-19 Thread jgart
Hi, 62956 resolves this issue. Thanks for working on gajim, nonetheless.

Closing this issue.

all best,

jgart
quit





bug#63270: d-feet: Fails to build (Function does not take positional arguments)

2023-05-19 Thread Ivan Vilata i Balaguer
Liliana Marie Prikler (2023-05-04 19:48:34 +0200) wrote:

> Am Donnerstag, dem 04.05.2023 um 17:13 +0200 schrieb Ivan Vilata i
> Balaguer:
> > ```
> > ../d-feet-0.3.16/data/meson.build:15:5: ERROR: Function does not take
> > positional arguments.
> > ```
> Looking at d-feet itself, it appears as though it has been all but
> deprecated in the favour of d-spy.  Perhaps guix should simply declare
> it a deprecated package instead of attempting to patch it – a patch has
> already been filed upstream previously, but is not yet merged any
> branch as far as I'm aware.

Thanks for the info!  For reference, this looks like the mentioned patch:


Cheers!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature


bug#63284: proot: Build gets stuck in test-0cf405b0 (and maybe test-25069c13)

2023-05-19 Thread Ivan Vilata i Balaguer
Same for me both building with:

guix build proot --with-version=proot=5.4.0

And altering the definition of the package manually to use `(version "5.4.0")`
(hash `186qsg4yvisqjgf8w5jxhnlig7x341vpqwcgp8as3r59qmqkpmk7`), plus removing
`libarchive` from `inputs` (as v5.3.1 already removed that dependency).

Thanks!


Blake Shaw (2023-05-07 15:55:04 +0700) wrote:

> I'm also dealing with the issue, except for me it gets stuck in
> test-kkk, if that info is helpful at all. 
> 
> Josselin Poiret via Bug reports for GNU Guix  writes:
> 
> > Ivan Vilata i Balaguer  writes:
> >
> >> Hi!  It looks like some tests during the build of `proot` get stuck in the
> >> version of Guix shown below:
> >
> > I already provided fixes for two tests upstream [1] but I'm waiting on
> > [2] since it seems like an actual regression.
> 
> > [1] https://github.com/proot-me/proot/pull/351
> > [2] https://github.com/proot-me/proot/issues/352

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature


bug#63280: encfs: Fails to build (test segfaults)

2023-05-19 Thread Ivan Vilata i Balaguer
Ivan Vilata i Balaguer (2023-05-19 13:40:27 +0200) wrote:

> I repeated the build with Guix commit 14c03807 and `encfs` tests failed in the
> same way.  I tested the fix in ,
> i.e. `guix build encfs --with-input=openssl=openssl@1.1.1q`, and the build
> succeeded, tests and all.  I also tried `--with-graft` instead of
> `--with-input`, but the issue happened again.

I rebuilt `--with-git-url=encfs=https://github.com/vgough/encfs.git` with the
same result.

However, I copied the definition of the `encfs` package to another file,
changed `(inputs (list attr fuse openssl tinyxml2))` to `(inputs (list attr
fuse openssl-1.1 tinyxml2))` (i.e. `openssl -> openssl-1.1`), and the built
succeeded and tests passed.

Please note that
 points out
that, around 3 years after the release of EncFS v1.9.5 (the version used in
Guix), OpenSSL v3 was still very recent, so EncFS may have never been
thoroughly tested with it anyway.

Maybe reverting to its dependency to OpenSSL v1.1 would be a good choice
(esp. since v1.1 still receives fixes).

Cheers!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature


bug#63280: encfs: Fails to build (test segfaults)

2023-05-19 Thread Ivan Vilata i Balaguer
Ivan Vilata i Balaguer (2023-05-04 18:46:54 +0200) wrote:

> Hi!  It looks like one of the tests in package `encfs` consistently segfaults
> in the version of Guix shown below:
> 
> ```
> […]
> commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
> ```
> 
> This is the final part of the build log:
> 
> ```
> starting phase `check'
> Running tests...
> /gnu/store/ygab8v4ci9iklaykapq52bfsshpvi8pw-cmake-minimal-3.24.2/bin/ctest 
> --force-new-ctest-process 
> Test project /tmp/guix-build-encfs-1.9.5.drv-0/build
> Start 1: unit
> 1/1 Test #1: unit .***Exception: SegFault  0.01 
> sec
> Running main() from 
> /tmp/guix-build-encfs-1.9.5.drv-0/encfs-1.9.5/vendor/github.com/google/googletest/googletest/src/gtest_main.cc
> […]
> ```
> 
> I saw a couple of encfs issues regarding segfaults in tests, but I don't think
> they're related: 
> 

I repeated the build with Guix commit 14c03807 and `encfs` tests failed in the
same way.  I tested the fix in ,
i.e. `guix build encfs --with-input=openssl=openssl@1.1.1q`, and the build
succeeded, tests and all.  I also tried `--with-graft` instead of
`--with-input`, but the issue happened again.

I hope that this is useful!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature


bug#63445: guix-build-coordinator guile-gnutls segfault

2023-05-19 Thread Christopher Baines

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> I've seen the build coordinator on bayfront crash a couple of times, and
>> it seems to be segfaulting, maybe in gnutls?
>>
>> May 11 14:31:39 localhost vmunix: [15795370.287670]
>> build-submitted[6013]: segfault at 0 ip 7f1e2e796415 sp
>> 7f1b86ffd640 error 4 in
>> guile-gnutls-v-2.so.0.0.0[7f1e2e79+17000]
>> May 11 14:31:39 localhost vmunix: [15795370.287692] Code: 01 00 41
>> 0f b7 14 24 48 3b 10 0f 85 85 00 00 00 49 8b 6c 24 08 48 89 f3 48 89
>> ef e8 d5 9d ff ff 4c 8b 68 08 41 f6 c5 06 75 0d <49> 8b 45 00 83 e0
>> 7f 48 83 f8 7d 74 3a 31 f6 bf 10 00 00 00 e8 c2
>
> Did you manage to get a backtrace?

Not yet, I've been trying to change the core file size limit with the
prlimit command, but I haven't seen any core dump files yet, so I'm not
sure if I've missed something.


signature.asc
Description: PGP signature


bug#62956: [PATCH] Updates for python-k5test and python-gssapi

2023-05-19 Thread Lars-Dominik Braun
Hi,

> just bumping this thread. ik there's a lot to be done since the
> core-updates merge but I wanted to make sure this wasn't forgotten
> about. haven't been able to contact some friends in a few weeks.

I already bumped k5test and gssapi independently and just added
python-idna to gajim. Looks like it builds and starts.

Cheers,
Lars






bug#62956: [PATCH] Updates for python-k5test and python-gssapi

2023-05-19 Thread Lilah Tascheter via Bug reports for GNU Guix
hey!

just bumping this thread. ik there's a lot to be done since the
core-updates merge but I wanted to make sure this wasn't forgotten
about. haven't been able to contact some friends in a few weeks.

thanks!