bug#53253: Guix home test failing additional information

[Gábor Boskovits]

I managed to get the following result:

I could make the test pass by including elogind in my system.

Then I made it fail again by the following:
1. sudo unmount /run/user/1000
2. sudo rm -rf /run/user/1000

bug#53253: Guix home test failing

[Gábor Boskovits]

The guix home test is failing on the testsuite, when the requirement to
provide XDG_RUNTIME_DIR is not met. The test should be set up to provide a
proper environment irrespective of the setup.

The test log ends with:
+ cat
+ guix home reconfigure /tmp/tmp.zQT5LdzYx7/home.scm
/gnu/store/f8pjw90hv5176rjq126zbmy2vm2jdggw-home
guix home: error: mkdir: Permission denied
+ chmod -Rf +w /tmp/tmp.zQT5LdzYx7
+ rm -rf /tmp/tmp.zQT5LdzYx7
FAIL tests/guix-home.sh (exit status: 1)

I did not see anything interesting before these lines, but I can provide
the whole log if needed.

Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#40316: core-updates nss not reproducible

[Gábor Boskovits]

Hello Danny,

Danny Milosavljevic  ezt írta (időpont: 2020.
márc. 30., H, 4:38):
>
> Hi,
>
> core-updates' nss is not reproducible (commit
> aebcbb27bc2f192cc06163251bab66a4ceb7b7d6).
>
> diffoscope says:
>
> --- /gnu/store/gfpgqvwrixhf3sf1bnzsfxzvld0nd8b7-nss-3.50
> +++ /gnu/store/gfpgqvwrixhf3sf1bnzsfxzvld0nd8b7-nss-3.50-check
> ├── lib
> │ ├── nss
> │ │ ├── libfreebl3.chk
> │ │ │┄ xxd not available in path. Falling back to Python hexlify.
> │ │ │ @@ -11,19 +11,19 @@
> │ │ │  5c80e3430a9e943586d458a1ca22b973460bfb3e33f1d5d3b426bf50d7f20933
> │ │ │  6ec0311b6d077086ca57f70b4a63f06fc88aed5060f311c744f3ce4e50422d85
> │ │ │  335457038ddc664d6183171c7b0d65bc8f2c1986fce29f5d67fcd4a5f823a11a
> │ │ │  a2e5843201ee88f15530e9743c1a2b54452e39b977e132af2d97e021ecf5
> │ │ │  58e1c72ee0713d29a4d6e25f859c0504464189033cfab2cffad567ccec68fc83
> │ │ │  d91f2e4e9a5e77a1ffe66f048bf96b47c649d2886e29a31baee04f728a28940c
> │ │ │  1d8c99a26ff8ba9990c7e5b13c1034866a6a1f396358e15e9795454038456f02
> │ │ │ -b5866eae2f327ea13a342c1cd3ff4e2c381caa2e66be323e3c065f010029
> │ │ │ -713ef8afdc7c8efcff89e8c420bfdd8835e6d08bb934ce160fe927b99ac8f997
> │ │ │ -c043c16bfe67abbbd27a97b4aa4df753c33f5a093d9598413edfb4c6a0a68309
> │ │ │ -4f3a160aec8a5e8e383c108c802580e5f117f9b2be6d496f6eb6e85937258e53
> │ │ │ -f3f55ac49f7ffa955e91e054d1dd6b19f725506e2242fbb2f8acf81c9ff4278c
> │ │ │ -5c6ad6528d1a8505c6c83fd643660e3a31dddff7eb5f046f0df6d47ea455c82c
> │ │ │ -78ec32d8a1aaa29c9deed1053feae3029eacce8b9ff88777ff964757aeb1ccce
> │ │ │ -bd14d326b7fb0822bbc982250e51d4eaa73599ef8e4fd2298f076edf9a9be41e
> │ │ │ -94da645f57dc12af730b3661973390672cbcf767caf495e1f3656f06f0fae300
> │ │ │ -4030361665e91e760d37d9117256e4f698d2b124115e83aafcc92c2751fa
> │ │ │ -f2b3384c22c76a207da12a4c4b72662e9ae53f356d6b6d98a066cd240cb06fed
> │ │ │ -337d6d
> │ │ │ +b5866eae2f327ea13a342c1cd3ff4e2c381caa2e66be323e3c065f0100a3
> │ │ │ +35c76bfe38266728b573ef4fedcb22131ce275a8a484902b3ad994ca3a87a754
> │ │ │ +998b5c5807e4fa0e9b83a6677eca9140b8bbeeb4c36897473065b8305c4d1ddd
> │ │ │ +3f967b7041217df53ae6ec4211b031cc12df895a35efcde570dd2c7a610151c9
> │ │ │ +ef0acdf28a646db355ece183e2e71275c51b4331e61ca7948c7aa62d420e8b17
> │ │ │ +481f427197c78094832de5e3f21d27bf701e6fc524e5f700567969f91e8864c0
> │ │ │ +fae4da549d548ce8b134456e0720d083c8649bdb44ac6383d2e5a41bd2ec3b64
> │ │ │ +e9b6d281708447aefdd60be32f7d9093fef2579d6c122b48e449b2266bdc4678
> │ │ │ +9639fd997f0d8fe649b51a5f3097603b130bb5e8a811b5f3c121ed6d7bb58300
> │ │ │ +4004c38a443627df69c2bc659e2e810b24b0e4dc042311fb9b2c99d18e7b
> │ │ │ +242fc7729f9e5facc1dc69ced89ea571bd69f95277894e9954c28c2f8ab77d62
> │ │ │ +e96c1d
> │ │ ├── libfreeblpriv3.chk
> │ │ │┄ xxd not available in path. Falling back to Python hexlify.
> │ │ │ @@ -11,19 +11,19 @@
> │ │ │  5c80e3430a9e943586d458a1ca22b973460bfb3e33f1d5d3b426bf50d7f20933
> │ │ │  6ec0311b6d077086ca57f70b4a63f06fc88aed5060f311c744f3ce4e50422d85
> │ │ │  335457038ddc664d6183171c7b0d65bc8f2c1986fce29f5d67fcd4a5f823a11a
> │ │ │  a2e5843201ee88f15530e9743c1a2b54452e39b977e132af2d97e021ecf5
> │ │ │  58e1c72ee0713d29a4d6e25f859c0504464189033cfab2cffad567ccec68fc83
> │ │ │  d91f2e4e9a5e77a1ffe66f048bf96b47c649d2886e29a31baee04f728a28940c
> │ │ │  1d8c99a26ff8ba9990c7e5b13c1034866a6a1f396358e15e9795454038456f02
> │ │ │ -b5866eae2f327ea13a342c1cd3ff4e2c381caa2e66be323e3c065f0100a3
> │ │ │ -298c351142cb4107acceb8e07a997cc63fade4c4dd6cc0d3f5dedad25fca66bc
> │ │ │ -d58fb35b3a1f8ce3c90c795a8066cb4312b2b11558daf3c388ee3865d1cbc75d
> │ │ │ -88832d044dd267885c36455be97ee5ff17ee95a9377170441267b604d6bea8d2
> │ │ │ -c7fbaebd2c39506220d5d2c4a34e6a848fc139bd38f95c7e48160d847c270a78
> │ │ │ -e88519f1a5f2f36c6d6d4c16d621b2e763e48d42818b1a3b76421a52c7c209b9
> │ │ │ -a70fe921ad9b80411150a5e4d800bd89fe4486361412b39a9b5c68abec6bb68d
> │ │ │ -8f7d1b823c9d455d0062d9b819b1d5173a493cdbea00dcfc98a52537bd373acb
> │ │ │ -cb046c7fe4246590c9875413f19dba8f63a2f05771d161513efeb2e663ebf400
> │ │ │ -40299e7b6851b43d6f40d1704237831bbb5a1fd4e38c041f1b7222480338
> │ │ │ -c27b4e655f1846220c4950db84ce7da9b2c1b2c6530304a73c8caff757be8ba4
> │ │ │ -51d8ec
> │ │ │ +b5866eae2f327ea13a342c1cd3ff4e2c381caa2e66be323e3c065f010032
> │ │ │ +0bdce77a4aabe0b8a8b97469180a5882104d30c155dfc227f99b7add6aedda98
> │ │ │ +b9aee674e8a2f43377eea0e32f4382f8818a9cd39dfe0f2217b989ab695b1317
> │ │ │ +971ae96efde5a3610306a7a60b3075204f77543509fb48d1605d0ae6d7cd
> │ │ │ +dd5b3576d2d09d9e4d5357ea21e7376e2fa69ba804a19161ab639219592efef5
> │ │ │ +ad5b8714ad21118b1fa53453b6e4222e267b0a692704de6bcd10895afeaf5f21
> │ │ │ +f721c406a796e092b344bc78abd953205e6d932c87fef89e80715a9eefbd6417
> │ │ │ +eef4e8c8630fe92927d81870c50f64aa15f2dbb965d9aa51a450d0c53607d60a
> │ │ │ +8c4ad1461e32c7dc78bf606eaacf38a88a2c47f496b3ba289e104e8d25a84400
> │ │ │ +408df400964ed23bd859d524136afbf355cce08ae540f65bbfe055e81950
> │ │ │ +6b84f52240c447ad47c53ee31e9fed82d08905f65adfedd54f5b91b6b9d6105b
> │ │ │ +f2f8f4
> │ │ ├── libnssdbm3.chk
> │ │ │┄ xxd not 

bug#37679: [PATCH 0/2] Local git configuration interferes with testsuite

[Gábor Boskovits]

Create a fake home in tests with a gitconfig so that the user configuration
does not get picked up.
I investigated how to solve this best, but git only respects HOME for the
commands we are using.
Also note that this does not affect libraries, only the git cli, as libraries
do not use the environment variables.

Gábor Boskovits (2):
  tests: Isolate git from user configuration.
  tests: Ignore files created by the testsuite.

 .gitignore |  4 +++-
 Makefile.am|  2 ++
 build-aux/test-env.in  |  4 
 tests/fake-home/.gitconfig | 21 +
 4 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 tests/fake-home/.gitconfig

-- 
2.25.0

bug#37207: nginx serving files from the store returns Last-Modified = Epoch

[Gábor Boskovits]

Hello Vincent,

Vincent Legoll  ezt írta (időpont: 2020.
márc. 27., P, 0:07):
>
> This bug prevents repology [1] to show
> the latest versions of packages in guix,
> as it relies on 'Last-Modified' for:
> https://guix.gnu.org/packages.json
> changing in a meaningful way...
>

Does it also use etags, or just last-modified?

I ask this because we already have bug similar to this, and it would
be interesting to know if
it would be enough to have a meaningful etags generation, or we still have to
deal with last-modified.

> [1] https://repology.org/
>
> --
> Vincent Legoll
>
>
>

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37679: [PATCH 2/2] tests: Ignore files created by the testsuite.

[Gábor Boskovits]

* .gitignore: Add /tests/fake-home/.guix-profile.
Ignore test result files in tests subdirectories.
Ignore top level files staring with t-.
---
 .gitignore | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index de058dda5e..19aae6c5ae 100644
--- a/.gitignore
+++ b/.gitignore
@@ -137,7 +137,8 @@
 /scripts/guix
 /test-env
 /test-tmp
-/tests/*.trs
+/tests/**/*.trs
+/tests/fake-home/.guix-profile
 GPATH
 GRTAGS
 GTAGS
@@ -152,3 +153,4 @@ tmp
 /.version
 /doc/stamp-[0-9]
 /gnu/packages/bootstrap
+/t-*
\ No newline at end of file
-- 
2.25.0

bug#37679: [PATCH 1/2] tests: Isolate git from user configuration.

[Gábor Boskovits]

* tests/fake-home/.gitconfig: New file. Provide minimal git
configuration for tests.
* build-aux/test-env.in: Set HOME to the fake home.
* Makefile.am(EXTRA_DIST): Add fake-home/.gitconfig.
---
 Makefile.am|  2 ++
 build-aux/test-env.in  |  4 
 tests/fake-home/.gitconfig | 21 +
 3 files changed, 27 insertions(+)
 create mode 100644 tests/fake-home/.gitconfig

diff --git a/Makefile.am b/Makefile.am
index 344ecdbc42..5eb918d599 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,6 +14,7 @@
 # Copyright © 2018 Oleg Pykhalov 
 # Copyright © 2018 Alex Vong 
 # Copyright © 2019 Efraim Flashner 
+# Copyright © 2020 Gábor Boskovits 
 #
 # This file is part of GNU Guix.
 #
@@ -560,6 +561,7 @@ EXTRA_DIST +=   
\
   build-aux/update-NEWS.scm\
   d3.v3.js \
   graph.js \
+  tests/fake-home/.gitconfig   \
   tests/test.drv   \
   tests/signing-key.pub\
   tests/signing-key.sec\
diff --git a/build-aux/test-env.in b/build-aux/test-env.in
index 59ab58cc94..1121570fbc 100644
--- a/build-aux/test-env.in
+++ b/build-aux/test-env.in
@@ -2,6 +2,7 @@
 
 # GNU Guix --- Functional package management for GNU
 # Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès 

+# Copyright © 2020 Gábor Boskovits 
 #
 # This file is part of GNU Guix.
 #
@@ -151,6 +152,9 @@ export GUIX_BUILD_OPTIONS
 # Ignore user settings.
 unset GUIX_PACKAGE_PATH
 
+# Provide fake home for tests using git
+HOME="@abs_top_srcdir@/tests/fake-home"
+
 storedir="@storedir@"
 prefix="@prefix@"
 datarootdir="@datarootdir@"
diff --git a/tests/fake-home/.gitconfig b/tests/fake-home/.gitconfig
new file mode 100644
index 00..c32de560e7
--- /dev/null
+++ b/tests/fake-home/.gitconfig
@@ -0,0 +1,21 @@
+# GNU Guix --- Functional package management for GNU
+# Copyright © 2020 Gábor Boskovits 
+#
+# This file is part of GNU Guix.
+#
+# GNU Guix is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or (at
+# your option) any later version.
+#
+# GNU Guix is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+[user]
+  email = al...@example.com
+  name = Alice
-- 
2.25.0

bug#40062: nscd: Domain name resolution errors when travelling

[Gábor Boskovits]

Hello,

Pierre Neidhardt  ezt írta (időpont: 2020. márc. 14.,
Szo 19:14):

> When I move with my Guix laptop, I frequently get domain name resolution
> errors.
>

I believe this is on Guix System. Are you using NetworkManager as
networking service?


> To fix the issue, I need to run
>
> --8<---cut here---start->8---
> # herd invalidate nscd hosts
> # herd restart nscd
> --8<---cut here---end--->8---
>
> The issue is fixed as long as I don't move again.
>
> This is impractical and the solution is very much non-obvious :p
>
> --
> Pierre Neidhardt
> https://ambrevar.xyz/

Best regards,
g_bor


>

bug#39685: Guix pull fails on qemu image

[Gábor Boskovits]

Not a bug.

bug#39685: Error on guix-pull using the qemu image

[Gábor Boskovits]

Hello,

Eilene Tomkins-Flanagan via Bug reports for GNU Guix  ezt
írta (időpont: 2020. febr. 20., Csü 5:31):

> I downloaded the qemu image from
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.1.x86_64-linux.xz.
> It had a valid signature.
>
> After booting the machine with qemu 3.1 (I'm on debian-amber):
> `qemu-system-x86_64-net user -net nic,model=virtio-enable-kvm -m
> 512-device virtio-blk,drive=myhd-drive
> if=none,file=./guix-system-vm-image-1.0.1.x86_64-linux,id=myhd`
>

-m 512 looks a bit low.


> I tried installing hello for the guest user. It worked fine.
>
> I then tried running `guix pull && guix package -u`, and received the
> following error:
> ```
> [...]
> substitute: updating substitutes from 'https://ci.guix.gnu.org'...100.0%
> Backtrace:
>   1 (apply-smob/1 #   0 (apply-smob/1 #)
>
> ERROR: In procedure apply-smob/1
> In procedure fport_write: Broken pipe
> ```
>
> On the second attempt, it failed immediately with this message:
> ```
> Updating channel 'guix' from Git repository at '
> https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://guix.savannah.gnu.org/git/guix.git 6dde98c
> Computing Guix derivation for 'x86_64-linux'.../guix pull: error: You
> found a bug: the program
> '/gnu/store/mr5q5qcwinaxy7f4cyfm08s05aj9rr6-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "6dde98c3d9e7a0385da57abedd9b41ca733acfc6"; system: "x86_64-linux";
> host version: "1.0.1-1.8204295"; pull-version: 1).
> Please report it by email to 
> ```
>
> After asking on the IRC to find out if I'd made a mistake, they directed
> me to send in the error as the message said.
>

Could you check if the disk is full? The image is small should be resized
before use.


> Let me know if other info is necessary for reproduction.
>
> -Eilene
>

Best regards,
g_bor

>
>

bug#39648: Reverse my commits on GNOME meta-package

[Gábor Boskovits]

Hello Tobias,

Tobias Geerinckx-Rice via Bug reports for GNU Guix 
ezt írta (időpont: 2020. febr. 17., H, 20:03):
>
> Raghav Gururajan 写道：
> > Could you please reverse my following commits:
> >
> > 1) d36fa50fbf8169018193774782fd21f1b13b9c0e
> >
> > 2) 7922b6f795eb575084546ec9bfb9d40508a9378e
> >
> > 3) 8d8c6bffc528b60574f84620bd6c3ee9bfa1173f
> >
> > 4) a8cda7f57992e9ce9ae4a694eba54e3eab42c39b
>
> Copy-pasted from #guix:
>
> Whoa there, that's drastic, let's put that on hold.

I agree.

>
> The first two only add packages (did they break anything? what?),
> the third has no effect on packages if your commit message is
> accurate.

These findings are accurate. I checked the diff of the third, it's ok.

>
> The fourth is the only one that removes packages, and even that
> might be better tweaked (this time: with comments noting what each
> non-core package brings to the GNOME table) than flat-out
> reverted.
>

I believe the fourth can be reverted if needed.

> What do you think?
>
> Kind regards,
>
> T G-R


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39562: python-keras build fails: test_selu: Not equal to tolerance rtol=1e-07, atol=0

[Gábor Boskovits]

This resembles to the babl issue we are having. Is it possible that this is
hardware related?

Pierre Neidhardt  ezt írta (időpont: 2020. febr. 11., Ke
16:19):

> Tests fail with:
>
> --8<---cut here---start->8---
> === FAILURES
> ===
> __ test_selu
> ___
>
> def test_selu():
> x = K.placeholder(ndim=2)
> f = K.function([x], [activations.selu(x)])
> alpha = 1.6732632423543772848170429916717
> scale = 1.0507009873554804934193349852946
>
> positive_values = get_standard_values()
> result = f([positive_values])[0]
> assert_allclose(result, positive_values * scale, rtol=1e-05)
>
> negative_values = np.array([[-1, -2]], dtype=K.floatx())
>
> result = f([negative_values])[0]
> true_result = (np.exp(negative_values) - 1) * scale * alpha
>
> >   assert_allclose(result, true_result)
> E   AssertionError:
> E   Not equal to tolerance rtol=1e-07, atol=0
> E
> E   Mismatch: 50%
> E   Max absolute difference: 1.1920929e-07
> E   Max relative difference: 1.0726715e-07
> Ex: array([[-1.111331, -1.520167]], dtype=float32)
> Ey: array([[-1.111331, -1.520167]], dtype=float32)
>
> tests/keras/activations_test.py:226: AssertionError
> --8<---cut here---end--->8---
>
> See attached log.
>
> --
> Pierre Neidhardt
> https://ambrevar.xyz/
>

bug#39468: Openbox - Calculator does not load

[Gábor Boskovits]

Hello,

Scott C. MacCallum via Bug reports for GNU Guix  ezt
írta (időpont: 2020. febr. 6., Cs, 22:38):
>
> "I'd like to close your other bugs (39469 to 39474) as I think they all have 
> the same root cause. I'll rename this one Do you agree?"
>
> I agree. And I'll stop submitting bugs for the other broken menu items. :)
>
> Scott
> scmguru - irc.freenode.net
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, February 6, 2020 4:23 PM, Julien Lepiller  
> wrote:
>
> > Le 6 février 2020 16:12:38 GMT-05:00, "Scott C. MacCallum" 
> > smaccal...@protonmail.com a écrit :
> >
> > Please make sure to keep debbugs in CC :)
> >
> > > > To be fair, if you installed only the openbox environment, none of
> > > > the items in the menu would work
> > >
> > > I didn't install just an Openbox environment, I installed all of the
> > > available desktop environments.
> >
> > I understand, and the other environments brought other packages with them, 
> > which made some of the menu items work.
> >
> > > > However, this is not a guix-specific bug, and as an openbox user, I
> > > > don't expect to have all of these items available.
> > >
> > > Perhaps it's not an Guix-specific bug but that's certainly not the case
> > > with other distros. It was my understanding that Guix wanted to reach
> > > the widest audience possible, including those not technically inclined.
> >
> > OK, though I certainly got locked out of my initial installation on arch 
> > linux because I forgot to add xterm for instance, and I'm sure all of these 
> > items don't work ootb on debian or other distros.
> >
> > Maybe having openbox as an initial choice in the installer is a bad idea, 
> > or the installer could add these packages. We could also change the openbox 
> > package to restrict the quantity of default menu entries to some minimum.

I believe we could do something along these lines:
1. Provide an openbox-minimal and an openbox entry.
2. openbox minimal would do what openbox does right now
3. define a %openbox-recommended-packages list that makes most of it work
4. the openbox entry would append the %openbox-recommended-packages to
the package list.

It needs more thought, but I believe this would improve the situation,
and having this list would ease
setup not only on install. Wdyt?

> >
> > I'd like to close your other bugs (39469 to 39474) as I think they all have 
> > the same root cause. I'll rename this one Do you agree?
> >
> > > > I don't really see how to improve the situation, do you have a
> > > > suggestion?
> > >
> > > I actually don't use Openbox as my default desktop environment. I was
> > > thinking about others.
> > > Scott
> > > scmguru - irc.freenode.net
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐ Original Message ‐‐‐
> > > On Thursday, February 6, 2020 4:03 PM, Julien Lepiller
> > > jul...@lepiller.eu wrote:
> > >
> > > > Le 6 février 2020 15:39:36 GMT-05:00, "Scott C. MacCallum via Bug
> > > > reports for GNU Guix" bug-guix@gnu.org a écrit :
> > > >
> > > > > After the installation of all the available desktop environments,
> > > > > in
> > > >
> > > > > Openbox from the Accessories menu Calculator does not load.
> > > > > Scott
> > > > > scmguru - irc.freenode.net
> > > > > Sent with ProtonMail Secure Email.
> > > >
> > > > To be fair, if you installed only the openbox environment, none of
> > > > the items in the menu would work. However, this is not a guix-specific
> > > > bug, and as an openbox user, I don't expect to have all of these items
> > > > available. The menu is static and the same in all distros. You're
> > > > supposed to configure it yourself, which makes it not very user
> > > > friendly, but that's how it works.
> > > > I don't really see how to improve the situation, do you have a
> > > > suggestion?
>
>
>
>
>

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39434: Misselled symbol exported from web services

[Gábor Boskovits]

Tags: easy

The symbol nginx-configuration-nginx is misspelled in the web services module.
I leave this as is, so that it makes an easy initial contribution.

g_bor
-- 
OpenPGP Key Fingerprint:
7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21nginx-ser

bug#39417: [doc] Misspelled example in manual

[Gábor Boskovits]

Tags: easy

Hello Guix,

In the manual, at base services:
file->udev-rule second example misspells user-account.

I file this as a bug so that we have a few easy for starting outreachy
applicants.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39301: imported module (guix build utils) overrides core binding `delete'

[Gábor Boskovits]

Ludovic Courtès  ezt írta (időpont: 2020. febr. 2., Vas
22:15):

> Hello!
>
> strypst...@posteo.net skribis:
>
> > Whenever running "sudo guix system reconfigure /path/to/config.scm I
> > get the following warnings:
> >
> > building
> > /gnu/store/vpazjd711byj3jszh7jrk5d8lq51077g-switch-to-system.scm.drv...
> > ;;; WARNING: loading compiled file
> >
> /gnu/store/5bd6ywmfcxxa4gvpzg0pdbjwmf24cxkl-module-import-compiled/gnu/build/activation.go
> > failed:
> > ;;; In procedure load-thunk-from-memory: incompatible bytecode kind
> > ;;; compiling
>
> [...]
>
> > building
> > /gnu/store/alamdi63ns0ahis93jz1x4cndy4w09gf-install-bootloader.scm.drv...
> > WARNING: (guile-user): imported module (guix build utils) overrides
> > core binding `delete'
> > ;;; WARNING: loading compiled file
> >
> /gnu/store/62gvwndkddaq6203mrisshgiv13kkgcd-module-import-compiled/gnu/build/bootloader.go
> > failed:
> > ;;; In procedure load-thunk-from-memory: incompatible bytecode kind
> > ;;; compiling
> >
> /gnu/store/wamhgn5mhgzf9mgp9gxx3w6jn64hw4yc-module-import/gnu/build/bootloader.scm
> > ;;; compiled
> >
> /root/.cache/guile/ccache/3.0-LE-8-4.2/gnu/store/wamhgn5mhgzf9mgp9gxx3w6jn64hw4yc-module-import/gnu/build/bootloader.scm.go
> > guix system: bootloader successfully installed on '/boot/efi'
> > WARNING: (guile-user): imported module (guix build utils) overrides
> > core binding `delete'
>
> All these warnings are harmless and stem from the Guile 2.2/3.0
> transition.  Specifically, it comes from the fact that ‘guix system
> reconfigure’ evaluates this code with the host Guile (in this case 3.0),
> whereas the modules are built for 2.2, which is what the Shepherd
> depends on.
>
> The culprit is ‘local-eval’ in (guix scripts system), which simply uses
> ‘primitive-eval’ to evaluate the code, thus disregarding the Guile
> version that should be used.
>
> One possibility would be to instead evaluate the expression in a
> separate Guile process for the intended Guile version.
>
> I’m not sure it’s worth it though.  The warnings will hopefully
> disappear soon when we upgrade everything to 3.0.
>
> Thoughts?
>

I believe it is ok to wait until the transition complete.


> Ludo’.
>
>
>
>

bug#39394: vis editor doesn't respect user configuration

[Gábor Boskovits]

tsmish  ezt írta (időpont: 2020. febr. 2., Vas 22:08):

> > I would go for renaming it like visrc.lua.example, or similar.
>
> I don't really like this solution because while this particular
> problem will be fixed, underlying issue of system paths having higher
> priority than user ones will stay.
> From what I can figure out from the
> code(
> https://github.com/martanne/vis/blob/a4b64c5c396646bb2f14db3b4145a5482a2ff8bf/vis-lua.c#L2650
> )
> $VIS_PATH is at the top of package.path which will make requires from
> user configuration go there in case of files with same name.
> Also this will probably make commands such as "set theme" ignore user
> files from configuration directory when there is a file in system one
>
Ok, as a real user of vis, I believe you got a better understanding. I will
have a look at the package tomorrow.

>
> Also there is VIS_PATH #define which seems to be intended way to set
> path to system directory. It is set to /usr/local/share/vis by
> default, but I don't see it
> in help, which probably means it gets overwritten with some kind of guix
> magic.
>

bug#39394: vis editor doesn't respect user configuration

[Gábor Boskovits]

tag 39394 easy quit

bug#39394: vis editor doesn't respect user configuration

[Gábor Boskovits]

Thanks for the report.

tsmish  ezt írta (időpont: 2020. febr. 2., Vas 18:57):

> Steps to reproduce:
> 1. Make file ~/.config/vis/visrc.lua with following text:
> ```
> require('vis')
>
> vis.events.subscribe(vis.events.INIT, function()
> vis:command('qall')
> end)
> ```
> 2. Open vis
>
> vis should immediately close on startup, but it doesn't.
>
> It happens because package defines $VIS_PATH search path to directory
> which contains example visrc.lua file and $VIS_PATH is highest
> priority directory according to man page.
>
> Suggestions:
> 1. Remove or rename example visrc.lua in share/vis
>
I would go for renaming it like visrc.lua.example, or similar.

Would you like to propose a patch?

2. Remove $VIS_PATH search path from package. This shouldn't break
> anything, as it seems share/vis is in later resolution path.
>
>
>
>

bug#39294: Can't run ./configure

[Gábor Boskovits]

Hello Damien,

Damien Cassou  ezt írta (időpont: 2020. jan. 26., V, 17:58):
>
> Hi,
>
> I'm on Fedora and just installed Guix by using guix-install.sh. I also
> checked out Guix git repository. When inside this repository, I face the
> following issue:
>
> $ guix environment guix
> ...
>
> guix$ ./bootstrap
> ...
>
> guix$ ./configure
> ...
> checking if (gnutls) is available... yes
> checking if (git) is available... no
> configure: error: Guile-Git is missing; please install it.
>
> I tried passing "--ad-hoc guile-git git" as parameter to "guix
> environment", but this doesn't fix the problem.
>
The issue seems here, is that the current guix is too old.
guix environment guix should be enough if the current guix and the
checked out one shares the dependencies.

Could you try this again after 'guix pull'?

> --
> Damien Cassou
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>
>
>


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39023: binary installation manual doesn't work on Alpine Linux

[Gábor Boskovits]

Tobias Geerinckx-Rice  ezt írta (időpont: 2020. jan.
22., Sze, 20:58):
>
> Gábor,
>
> Gábor Boskovits 写道：
> > Oops, I missed that.
>
> I'm suprised I haven't confused add* & *add once so far in this
> thread :-)

Yes, I am also a bit confused.

>
> > There was some upstream discussion to get useradd and groupadd
> > to
> > busybox upstream,
> > as this seems to be causing problems everywhere. They told that
> > they
> > are unwilling to include them as is,
> > but would accept a wrapper thar forward to their
> > adduser/addgroup
> > implementation.
>
> I don't know which discussion you're referring to, and much might
> have changed since 2016, but I read this[0] to mean the opposite:
> Busybox should provide the shadow-compatible *add variants, and
> reimplement their old add* as simple wrappers around that.  That's
> from an upstream(ish) person.
>
>   “adduser/addgroup tend to be symlinks or wrappers, if they exist
>   at
>all, but by and large are deprecated.  busybox should implement
>applets that mimic shadow here and deprecate the old ones, if
>not
>throw them out. although we can probably rename & massage the
>sources in these cases”
>
> Still, Busybox *add patches welcome, it would seem.  We'll still
> have to deal with this for the lifetime of the older version.

Yes, I referred to this, but I might have misunderstood something.

>
> Kind regards,
>
> T G-R
>
> [0]:
> http://lists.busybox.net/pipermail/busybox/2016-February/083909.html



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39023: binary installation manual doesn't work on Alpine Linux

[Gábor Boskovits]

Oops, I missed that.

Tobias Geerinckx-Rice  ezt írta (időpont: 2020. jan.
22., Sze, 4:53):
>
> Gábor,
>
> Gábor Boskovits 写道：
> >  ezt írta (időpont: 2020. jan. 7., K,
> > 22:32):
> >> I suggest adding another example which works by default on
> >> busybox.
>
> […]
>
> >> addgroup -S guixbuild
>
> […]
>
> > I assume that the command you gave would work on non-busybox
> > also. I
> > would say we should replace the
> > command we have with this more compatible one.
>
> It doesn't even work on Guix:
>
>   nckx@berlin ~$ adduser
>   -bash: adduser: command not found
>
> Kind regards,
>

I believe these can be implemented using simple manipulation of config files.
Also useradd is part of the linux standard base, while adduser is not.

We could add the busybox example, but it might be better to come up
with something
universal.

There was some upstream discussion to get useradd and groupadd to
busybox upstream,
as this seems to be causing problems everywhere. They told that they
are unwilling to include them as is,
but would accept a wrapper thar forward to their adduser/addgroup
implementation.

> T G-R


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38086: RAID installation script with ‘mdadm’ no longer works

[Gábor Boskovits]

Vagrant Cascadian  ezt írta (időpont: 2020. jan. 17.,
Pén 23:42):

> On 2019-11-12, Ludovic Courtès wrote:
> > Gábor Boskovits  skribis:
> >
> >>> + mdadm --create /dev/md0 --verbose --level=stripe --raid-devices=2
> >>> /dev/vdb2 /dev/vdb3
> >>> mdadm: chunk size defaults to 512K
> >>> mdadm: Defaulting to version 1.2 metadata
> >>> [   13.890586] md/raid0:md0: cannot assemble multi-zone RAID0 with
> >>> default_layout setting
> >>> [   13.894691] md/raid0: please set raid0.default_layout to 1 or 2
> >>> [   13.896000] md: pers->run() failed ...
> >>> mdadm: RUN_ARRAY failed: Unknown error 524
> >>> [   13.901603] md: md0 stopped.
> >>> --8<---cut here---end--->8---
> >>>
> >>> Anyone knows what it takes to “set raid0.default_layout to 1 or 2”?
> >>>
> >>
> >> On kernel 5.3.4 and above the
> >> raid0.default_layout=2 kernel boot paramter should be set. We should
> >> generate our grub configuration accordingly.
>
> So, this might be sort of a tangent, but I'm wondering why you're
> testing raid0 (striping, for performance+capacity at risk of data loss)
> instead of raid1 (mirroring, for redundancy, fast reads, slow writes,
> half capacity of storage), or another raid level with more disks (raid5,
> raid6, raid10). raid1 would be the simplest to switch the code to, since
> it uses only two disks.
>
>
> The issue triggering this bug might be a non-issue on other raid levels
> that in my mind might make more sense for rootfs. Or maybe people have
> use-casese for rootfs on raid0 that I'm too uncreative to think of? :)
>

I often see raid 10 as root. I believe it might make sense to test that
setup.

>
>
> live well,
>   vagrant
>

bug#39090: Guix package version bisect update

[Gábor Boskovits]

> > > As it turned out that the problem is in the guix package following an 
> > > update I
> > > started a bisect.
> > >
> > > Updating guix to:
> > > edc58fdada good
> > 970cb5cece good
> 4f0b3368ad bad
ea3e8fad74 good

bug#39090: Guix package version bisect update

[Gábor Boskovits]

> > As it turned out that the problem is in the guix package following an 
> > update I
> > started a bisect.
> >
> > Updating guix to:
> > edc58fdada good
> 970cb5cece good
4f0b3368ad bad

bug#39090: Guix package version bisect update

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
14., K, 18:01):
>
> As it turned out that the problem is in the guix package following an update I
> started a bisect.
>
> Updating guix to:
> edc58fdada good
970cb5cece good
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Guix package version bisect update

[Gábor Boskovits]

As it turned out that the problem is in the guix package following an update I
started a bisect.

Updating guix to:
edc58fdada good

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Update on the installer bug

[Gábor Boskovits]

The problem is introduced by the guix update on
fd885160fcfde710e415252463c1034f22f88e59.

Reverting this commit makes the problem go away, so a bisect on the
guix package version is feasible.

The problem can be triggered in the installer image by doing
'guix build guix' in a root terminal.

The first attempt fails, while subsequent attempts succeed.

rm -rf /var/guix/substitute triggers the error again.

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
12., V, 19:17):
>
> Gábor Boskovits  ezt írta (időpont: 2020. jan.
> 12., V, 17:54):
> >
> > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > 12., V, 16:18):
> > >
> > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > 12., V, 14:00):
> > > >
> > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > 12., V, 12:39):
> > > > >
> > > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > > 12., V, 3:06):
> > > > > >
> > > > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > > > 12., V, 2:15):
> > > > > > >
> > > > > > > Gábor Boskovits  ezt írta (időpont: 2020. 
> > > > > > > jan.
> > > > > > > 11., Szo, 15:49):
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I noticed that the install disk created on current master can't
> > > > > > > > install the system.
> > > > > > > >
> > > > > > > > This is on:
> > > > > > > > e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> > > > > > > > .
> > > > > > > >
> > > > > > > > I have found a reproducer that might highlight where the 
> > > > > > > > problem is.
> > > > > > > >
> > > > > > > > Steps to reproduce:
> > > > > > > > 1. guix pull
> > > > > > > > 2. build the installer image
> > > > > > > > guix system disk-image --file-system-type=iso9660 \
> > > > > > > >   gnu/system/install.scm
> > > > > > > > 3. boot it
> > > > > > > > 4. switch to tty3
> > > > > > > > 5. create a file gexp.scm with this content:
> > > > > > > > (use-modules
> > > > > > > >  (gnu packages package-management)
> > > > > > > >  (guix gexp))
> > > > > > > >
> > > > > > > > (program-file
> > > > > > > >  "a"
> > > > > > > >  (with-extensions
> > > > > > > >   (list guix)
> > > > > > > >   #~(#t)))
> > > > > > > > 6. guix build -f gexp.scm
> > > > > > > >
> > > > > > > > This will fail with as strange error message.
> > > > > > > > This same problem causes the final installation failure in the 
> > > > > > > > installer.
> > > > > > > >
> > > > > > > > This works fine on the latest installation image.
> > > > > > > > This works if you run it again after it fails.
> > > > > > > >
> > > > > > > > Any help on debugging this further would be appreciated.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > g_bor
> > > > > > > > --
> > > > > > > > OpenPGP Key Fingerprint: 
> > > > > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > I started a bisect,
> > > > > > > b1d13e40... is good.
> > > > > > a3569a3 good
> > > > > 92afa57 good
> > > > aa8f64b bad
> > > 6298f32 bad
> > 94c621b bad
> b307b58 bad
1133596 good

> > > >
> > > >
> > > > >
> > > > >
> > > > > > >
> > > > > > > --
> > > > > > > OpenPGP Key Fingerprint: 
> > > > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > OpenPGP Key Fingerprint: 
> > > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > OpenPGP Key Fingerprint: 
> > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > >
> > > >
> > > >
> > > > --
> > > > OpenPGP Key Fingerprint: 
> > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > >
> > >
> > >
> > > --
> > > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> >
> >
> >
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
>
>
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
12., V, 17:54):
>
> Gábor Boskovits  ezt írta (időpont: 2020. jan.
> 12., V, 16:18):
> >
> > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > 12., V, 14:00):
> > >
> > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > 12., V, 12:39):
> > > >
> > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > 12., V, 3:06):
> > > > >
> > > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > > 12., V, 2:15):
> > > > > >
> > > > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > > > 11., Szo, 15:49):
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I noticed that the install disk created on current master can't
> > > > > > > install the system.
> > > > > > >
> > > > > > > This is on:
> > > > > > > e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> > > > > > > .
> > > > > > >
> > > > > > > I have found a reproducer that might highlight where the problem 
> > > > > > > is.
> > > > > > >
> > > > > > > Steps to reproduce:
> > > > > > > 1. guix pull
> > > > > > > 2. build the installer image
> > > > > > > guix system disk-image --file-system-type=iso9660 \
> > > > > > >   gnu/system/install.scm
> > > > > > > 3. boot it
> > > > > > > 4. switch to tty3
> > > > > > > 5. create a file gexp.scm with this content:
> > > > > > > (use-modules
> > > > > > >  (gnu packages package-management)
> > > > > > >  (guix gexp))
> > > > > > >
> > > > > > > (program-file
> > > > > > >  "a"
> > > > > > >  (with-extensions
> > > > > > >   (list guix)
> > > > > > >   #~(#t)))
> > > > > > > 6. guix build -f gexp.scm
> > > > > > >
> > > > > > > This will fail with as strange error message.
> > > > > > > This same problem causes the final installation failure in the 
> > > > > > > installer.
> > > > > > >
> > > > > > > This works fine on the latest installation image.
> > > > > > > This works if you run it again after it fails.
> > > > > > >
> > > > > > > Any help on debugging this further would be appreciated.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > g_bor
> > > > > > > --
> > > > > > > OpenPGP Key Fingerprint: 
> > > > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > I started a bisect,
> > > > > > b1d13e40... is good.
> > > > > a3569a3 good
> > > > 92afa57 good
> > > aa8f64b bad
> > 6298f32 bad
> 94c621b bad
b307b58 bad
> > >
> > >
> > > >
> > > >
> > > > > >
> > > > > > --
> > > > > > OpenPGP Key Fingerprint: 
> > > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > OpenPGP Key Fingerprint: 
> > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > >
> > > >
> > > >
> > > > --
> > > > OpenPGP Key Fingerprint: 
> > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > >
> > >
> > >
> > > --
> > > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> >
> >
> >
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
>
>
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
12., V, 16:18):
>
> Gábor Boskovits  ezt írta (időpont: 2020. jan.
> 12., V, 14:00):
> >
> > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > 12., V, 12:39):
> > >
> > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > 12., V, 3:06):
> > > >
> > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > 12., V, 2:15):
> > > > >
> > > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > > 11., Szo, 15:49):
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I noticed that the install disk created on current master can't
> > > > > > install the system.
> > > > > >
> > > > > > This is on:
> > > > > > e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> > > > > > .
> > > > > >
> > > > > > I have found a reproducer that might highlight where the problem is.
> > > > > >
> > > > > > Steps to reproduce:
> > > > > > 1. guix pull
> > > > > > 2. build the installer image
> > > > > > guix system disk-image --file-system-type=iso9660 \
> > > > > >   gnu/system/install.scm
> > > > > > 3. boot it
> > > > > > 4. switch to tty3
> > > > > > 5. create a file gexp.scm with this content:
> > > > > > (use-modules
> > > > > >  (gnu packages package-management)
> > > > > >  (guix gexp))
> > > > > >
> > > > > > (program-file
> > > > > >  "a"
> > > > > >  (with-extensions
> > > > > >   (list guix)
> > > > > >   #~(#t)))
> > > > > > 6. guix build -f gexp.scm
> > > > > >
> > > > > > This will fail with as strange error message.
> > > > > > This same problem causes the final installation failure in the 
> > > > > > installer.
> > > > > >
> > > > > > This works fine on the latest installation image.
> > > > > > This works if you run it again after it fails.
> > > > > >
> > > > > > Any help on debugging this further would be appreciated.
> > > > > >
> > > > > > Best regards,
> > > > > > g_bor
> > > > > > --
> > > > > > OpenPGP Key Fingerprint: 
> > > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > > > >
> > > > > >
> > > > > >
> > > > > I started a bisect,
> > > > > b1d13e40... is good.
> > > > a3569a3 good
> > > 92afa57 good
> > aa8f64b bad
> 6298f32 bad
94c621b bad
> >
> >
> > >
> > >
> > > > >
> > > > > --
> > > > > OpenPGP Key Fingerprint: 
> > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > >
> > > >
> > > >
> > > > --
> > > > OpenPGP Key Fingerprint: 
> > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > >
> > >
> > >
> > > --
> > > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> >
> >
> >
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
>
>
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
12., V, 14:00):
>
> Gábor Boskovits  ezt írta (időpont: 2020. jan.
> 12., V, 12:39):
> >
> > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > 12., V, 3:06):
> > >
> > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > 12., V, 2:15):
> > > >
> > > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > > 11., Szo, 15:49):
> > > > >
> > > > > Hello,
> > > > >
> > > > > I noticed that the install disk created on current master can't
> > > > > install the system.
> > > > >
> > > > > This is on:
> > > > > e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> > > > > .
> > > > >
> > > > > I have found a reproducer that might highlight where the problem is.
> > > > >
> > > > > Steps to reproduce:
> > > > > 1. guix pull
> > > > > 2. build the installer image
> > > > > guix system disk-image --file-system-type=iso9660 \
> > > > >   gnu/system/install.scm
> > > > > 3. boot it
> > > > > 4. switch to tty3
> > > > > 5. create a file gexp.scm with this content:
> > > > > (use-modules
> > > > >  (gnu packages package-management)
> > > > >  (guix gexp))
> > > > >
> > > > > (program-file
> > > > >  "a"
> > > > >  (with-extensions
> > > > >   (list guix)
> > > > >   #~(#t)))
> > > > > 6. guix build -f gexp.scm
> > > > >
> > > > > This will fail with as strange error message.
> > > > > This same problem causes the final installation failure in the 
> > > > > installer.
> > > > >
> > > > > This works fine on the latest installation image.
> > > > > This works if you run it again after it fails.
> > > > >
> > > > > Any help on debugging this further would be appreciated.
> > > > >
> > > > > Best regards,
> > > > > g_bor
> > > > > --
> > > > > OpenPGP Key Fingerprint: 
> > > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > > >
> > > > >
> > > > >
> > > > I started a bisect,
> > > > b1d13e40... is good.
> > > a3569a3 good
> > 92afa57 good
> aa8f64b bad
6298f32 bad
>
>
> >
> >
> > > >
> > > > --
> > > > OpenPGP Key Fingerprint: 
> > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > >
> > >
> > >
> > > --
> > > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> >
> >
> >
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
>
>
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
12., V, 12:39):
>
> Gábor Boskovits  ezt írta (időpont: 2020. jan.
> 12., V, 3:06):
> >
> > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > 12., V, 2:15):
> > >
> > > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > > 11., Szo, 15:49):
> > > >
> > > > Hello,
> > > >
> > > > I noticed that the install disk created on current master can't
> > > > install the system.
> > > >
> > > > This is on:
> > > > e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> > > > .
> > > >
> > > > I have found a reproducer that might highlight where the problem is.
> > > >
> > > > Steps to reproduce:
> > > > 1. guix pull
> > > > 2. build the installer image
> > > > guix system disk-image --file-system-type=iso9660 \
> > > >   gnu/system/install.scm
> > > > 3. boot it
> > > > 4. switch to tty3
> > > > 5. create a file gexp.scm with this content:
> > > > (use-modules
> > > >  (gnu packages package-management)
> > > >  (guix gexp))
> > > >
> > > > (program-file
> > > >  "a"
> > > >  (with-extensions
> > > >   (list guix)
> > > >   #~(#t)))
> > > > 6. guix build -f gexp.scm
> > > >
> > > > This will fail with as strange error message.
> > > > This same problem causes the final installation failure in the 
> > > > installer.
> > > >
> > > > This works fine on the latest installation image.
> > > > This works if you run it again after it fails.
> > > >
> > > > Any help on debugging this further would be appreciated.
> > > >
> > > > Best regards,
> > > > g_bor
> > > > --
> > > > OpenPGP Key Fingerprint: 
> > > > 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > > >
> > > >
> > > >
> > > I started a bisect,
> > > b1d13e40... is good.
> > a3569a3 good
> 92afa57 good
aa8f64b bad


>
>
> > >
> > > --
> > > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> >
> >
> >
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
>
>
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
12., V, 3:06):
>
> Gábor Boskovits  ezt írta (időpont: 2020. jan.
> 12., V, 2:15):
> >
> > Gábor Boskovits  ezt írta (időpont: 2020. jan.
> > 11., Szo, 15:49):
> > >
> > > Hello,
> > >
> > > I noticed that the install disk created on current master can't
> > > install the system.
> > >
> > > This is on:
> > > e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> > > .
> > >
> > > I have found a reproducer that might highlight where the problem is.
> > >
> > > Steps to reproduce:
> > > 1. guix pull
> > > 2. build the installer image
> > > guix system disk-image --file-system-type=iso9660 \
> > >   gnu/system/install.scm
> > > 3. boot it
> > > 4. switch to tty3
> > > 5. create a file gexp.scm with this content:
> > > (use-modules
> > >  (gnu packages package-management)
> > >  (guix gexp))
> > >
> > > (program-file
> > >  "a"
> > >  (with-extensions
> > >   (list guix)
> > >   #~(#t)))
> > > 6. guix build -f gexp.scm
> > >
> > > This will fail with as strange error message.
> > > This same problem causes the final installation failure in the installer.
> > >
> > > This works fine on the latest installation image.
> > > This works if you run it again after it fails.
> > >
> > > Any help on debugging this further would be appreciated.
> > >
> > > Best regards,
> > > g_bor
> > > --
> > > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> > >
> > >
> > >
> > I started a bisect,
> > b1d13e40... is good.
> a3569a3 good
92afa57 good


> >
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
>
>
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
12., V, 2:15):
>
> Gábor Boskovits  ezt írta (időpont: 2020. jan.
> 11., Szo, 15:49):
> >
> > Hello,
> >
> > I noticed that the install disk created on current master can't
> > install the system.
> >
> > This is on:
> > e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> > .
> >
> > I have found a reproducer that might highlight where the problem is.
> >
> > Steps to reproduce:
> > 1. guix pull
> > 2. build the installer image
> > guix system disk-image --file-system-type=iso9660 \
> >   gnu/system/install.scm
> > 3. boot it
> > 4. switch to tty3
> > 5. create a file gexp.scm with this content:
> > (use-modules
> >  (gnu packages package-management)
> >  (guix gexp))
> >
> > (program-file
> >  "a"
> >  (with-extensions
> >   (list guix)
> >   #~(#t)))
> > 6. guix build -f gexp.scm
> >
> > This will fail with as strange error message.
> > This same problem causes the final installation failure in the installer.
> >
> > This works fine on the latest installation image.
> > This works if you run it again after it fails.
> >
> > Any help on debugging this further would be appreciated.
> >
> > Best regards,
> > g_bor
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> >
> >
> >
> I started a bisect,
> b1d13e40... is good.
a3569a3 good
>
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2020. jan.
11., Szo, 15:49):
>
> Hello,
>
> I noticed that the install disk created on current master can't
> install the system.
>
> This is on:
> e4c9ba4da2a6faf80209488d5c086ea0d5c39214
> .
>
> I have found a reproducer that might highlight where the problem is.
>
> Steps to reproduce:
> 1. guix pull
> 2. build the installer image
> guix system disk-image --file-system-type=iso9660 \
>   gnu/system/install.scm
> 3. boot it
> 4. switch to tty3
> 5. create a file gexp.scm with this content:
> (use-modules
>  (gnu packages package-management)
>  (guix gexp))
>
> (program-file
>  "a"
>  (with-extensions
>   (list guix)
>   #~(#t)))
> 6. guix build -f gexp.scm
>
> This will fail with as strange error message.
> This same problem causes the final installation failure in the installer.
>
> This works fine on the latest installation image.
> This works if you run it again after it fails.
>
> Any help on debugging this further would be appreciated.
>
> Best regards,
> g_bor
> --
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
>
>
>
I started a bisect,
b1d13e40... is good.

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Ricardo Wurmus  ezt írta (időpont: 2020. jan. 11.,
Szo, 17:44):
>
>
> Gábor Boskovits  writes:
>
> > 5. create a file gexp.scm with this content:
> > (use-modules
> >  (gnu packages package-management)
> >  (guix gexp))
> >
> > (program-file
> >  "a"
> >  (with-extensions
> >   (list guix)
> >   #~(#t)))
> > 6. guix build -f gexp.scm
> >
> > This will fail with as strange error message.
>
> What’s the error message?

guix build: error: got unexpected path  from substituter

 varies, currently it was
/gnu/store/0q95b...-libarchive-3.4.0.tar.gz
>
> --
> Ricardo
>


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39090: Installer fails on install disk built from master

[Gábor Boskovits]

Hello,

I noticed that the install disk created on current master can't
install the system.

This is on:
e4c9ba4da2a6faf80209488d5c086ea0d5c39214
.

I have found a reproducer that might highlight where the problem is.

Steps to reproduce:
1. guix pull
2. build the installer image
guix system disk-image --file-system-type=iso9660 \
  gnu/system/install.scm
3. boot it
4. switch to tty3
5. create a file gexp.scm with this content:
(use-modules
 (gnu packages package-management)
 (guix gexp))

(program-file
 "a"
 (with-extensions
  (list guix)
  #~(#t)))
6. guix build -f gexp.scm

This will fail with as strange error message.
This same problem causes the final installation failure in the installer.

This works fine on the latest installation image.
This works if you run it again after it fails.

Any help on debugging this further would be appreciated.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39051: nginx caching headers are broken due to epoch store timestamps

[Gábor Boskovits]

Hello,

Robert Vollmert  ezt írta (időpont: 2020. jan. 9., Cs, 11:54):
>
> I’ve been having hard-to-debug caching issues serving up static files
> with nginx. It turns out this is due to nginx computing e-tag headers
> from file timestamps, which are all epoch in the guix store.
>
> I’ve fixed this on my server by applying a patch from Nix:
> https://github.com/robx/guix/commit/4b406f5bc608b3c0e18e15795d8fe61d3477a3e2

this is a known issue. Could you look around the tracker and merge?
>
>
>
>

Also, on the long run it would be nice to contribute a working etags
computation to nginx, that
is based on the file content hash, or something like that. Does that make sense?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39023: binary installation manual doesn't work on Alpine Linux

[Gábor Boskovits]

Hello,

 ezt írta (időpont: 2020. jan. 7., K, 22:32):
>
> The commands in 
> https://guix.gnu.org/manual/en/guix.html#Build-Environment-Setup
> do not work on busybox-based systems such as Alpine Linux by default.
> This is because they do not have 'groupadd' or 'useradd' by default (from 
> 'shadow' package).
>
> # groupadd --system guixbuild
> # for i in `seq -w 1 10`;
>   do
> useradd -g guixbuild -G guixbuild   \
> -d /var/empty -s `which nologin`\
> -c "Guix build user $i" --system\
> guixbuilder$i;
>   done
>
> I suggest adding another example which works by default on busybox.
> Explanation: -S means 'add system group/user'; -h is 'home directory'; -g is 
> 'GECOS field'
> Also, Alpine Linux fails to boot if /var/empty is not owned by root, so that 
> needs to be fixed afterward as well.
>
> addgroup -S guixbuild
> for i in `seq -w 1 10`;
> do
> adduser -G guixbuild \
> -h /var/empty -s `which nologin` \
> -g "Guix build user $i" -S \
> guixbuilder$i;
> done
> chown root:root /var/empty # /var/empty must be owned by root, fix permission 
> after `adduser` modified it
>
>
>
I assume that the command you gave would work on non-busybox also. I
would say we should replace the
command we have with this more compatible one.

I would wait for a few more responses, though.

If that sounds good to you could you create a patch to that effect?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38357: babl-0.1.72 build failure (test failure) - dependency for gimp

[Gábor Boskovits]

Hello,

Pierre Neidhardt  ezt írta (időpont: 2020. jan. 7.,
K, 12:40):
>
> Any update on this? :)

The upstream discussion has not been touched for a month.
I believe it would be safe to either
- disable the test, as it doesn't
make any sense at all, it requires a too narrow tolerance.
- or apply the patch with the --no-unsafe-math-optimizations,
possibly by the upstream patch, or by doing a setenv.

The second solution would mean more consistent behaviour across
platforms, sacrificing a bit of performance.
>
> Cheers!
>
> --
> Pierre Neidhardt
> https://ambrevar.xyz/


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38806: Bug Report

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2019. dec. 30., H, 22:42):
>
> Hello,
>
> Wayne Wallace  skribis:
>
> > I was doing a guix pull on a new VM setup
>
> Could it be that your VM ran out of memory during ‘guix pull’?  (I’d
> recommend ~2G of RAM at least.)

Last time I checked the VM image was also quite low on disk space.
I had to extend it to use.

>
> Thanks,
> Ludo’.
>
>
>

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38795: "guix build" doesn't find modules from extra channels when building from an expression

[Gábor Boskovits]

This is a possible duplicate of 37399. Can you confirm?

 ezt írta (időpont: 2019. dec. 29., V, 17:07):
>
> I have added my own repository to my ~/.config/guix/channels.scm 
> (https://gitlab.com/pkill-9/guix-packages-free), but when I run `guix build 
> --expression='(use-modules (pkill9 utils))' it returns "no code for module 
> (pkill9 utils)".
>
> It does find modules from the guix repository though, e.g. `guix build 
> --expression='(use-modules (guix packages))` returns "guix build: error: 
> #: not something we can build" without a "no code for module" 
> error.
>
>


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38357: babl-0.1.72 build failure (test failure) - dependency for gimp

[Gábor Boskovits]

Ludovic Courtès  ezt írta (időpont: 2019. dec. 26., Cs, 18:31):
>
> Hi,
>
> Gábor Boskovits  skribis:
>
> > Here is the upstream bug report:
> > https://gitlab.gnome.org/GNOME/babl/issues/49
>
> Thanks for finding it!  The discussion is still on-going, but it seems
> that we could perhaps apply
> https://gitlab.gnome.org/GNOME/babl/commit/84128d538aa4f189c31d296d04084762ce062107
> in the meantime?

Looks good to me. I also believe it would be the safest bet for
upstream, but that is another story.

>
> Ludo’.


Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38357: babl-0.1.72 build failure (test failure) - dependency for gimp

[Gábor Boskovits]

Hello,

Brett Gilio  ezt írta (időpont: 2019. dec. 24., K, 1:43):
>
> Ludovic Courtès  writes:
>
> > Hi,
> >
> > Tobias Geerinckx-Rice via Bug reports for GNU Guix 
> > skribis:
> >
> >> Christopher Howard 写道：
> >>> 22/25 alpha_symmetric_transform   FAIL 0.12 s (exit
> >>
> >> I've built master's babl a few times now, the damned thing keeps
> >> succeeding:
> >
> > It failed on berlin:
> >
> >   https://ci.guix.gnu.org/log/qzz0qv5llrfb6ls8018yjkwg55lk26yk-babl-0.1.72
> >
> > So the test must be numerically unstable or something.
> >
> > Does upstream have patches or bug reports?

Here is the upstream bug report:
https://gitlab.gnome.org/GNOME/babl/issues/49

> >
> > Thanks,
> > Ludo’.
> >
> >
> >
> >
>
> This still looks like an on-going issue. I am where Tobias is at, I
> can't reproduce this on my machine which lends me to believe you are
> right, Ludo'.
>
> Interestingly, the store object hashes are matching.
>
> http://berlin.guixsd.org/log/qzz0qv5llrfb6ls8018yjkwg55lk26yk-babl-0.1.72
>
> --8<---cut here---start->8---
> 22/25 alpha_symmetric_transform   FAIL 0.17 s (exit status 
> 255 or signal 127 SIGinvalid)
> 23/25 types   OK   0.12 s
> 24/25 concurrency-stress-test OK   0.37 s
> 25/25 palette-concurrency-stress-test OK   0.62 s
>
> Ok:   24
> Expected Fail: 0
> Fail:  1
> Unexpected Pass:   0
> Skipped:   0
> Timeout:   0
>
>
> The output from the failed tests:
>
> 22/25 alpha_symmetric_transform   FAIL 0.17 s (exit status 
> 255 or signal 127 SIGinvalid)
>
> --- command ---
> LD_LIBRARY_PATH='/tmp/guix-build-babl-0.1.72.drv-0/build/babl' 
> GI_TYPELIB_PATH='/tmp/guix-build-babl-0.1.72.drv-0/build/babl' 
> BABL_PATH='/tmp/guix-build-babl-0.1.72.drv-0/build/extensions' 
> /tmp/guix-build-babl-0.1.72.drv-0/build/tests/alpha_symmetric_transform
> --- stdout ---
>
> --- stderr ---
> ../babl-0.1.72/babl/babl-internal.h:214 babl_log()
> separate alpha 10.2: 10.007812500!=10.0(ref)
> ../babl-0.1.72/babl/babl-internal.h:214 babl_log()
> separate alpha 11.1: 4.996093750!=5.0(ref)
> ../babl-0.1.72/babl/babl-internal.h:214 babl_log()
> separate alpha 11.2: 49.96875!=50.0(ref)
> ../babl-0.1.72/babl/babl-internal.h:214 babl_log()
> associatd-alpha 10.2: 10.007812500!=10.0(ref)
> ../babl-0.1.72/babl/babl-internal.h:214 babl_log()
> associatd-alpha 11.1: 4.992187500!=5.0(ref)
> ../babl-0.1.72/babl/babl-internal.h:214 babl_log()
> associatd-alpha 11.2: 49.93750!=50.0(ref)
> ---
>
> Full log written to 
> /tmp/guix-build-babl-0.1.72.drv-0/build/meson-logs/testlog.txt
> FAILED: meson-test
> --8<---cut here---end--->8---
>
> Perhaps we should work around the singular failing test-case and open a
> report upstream to include in a comment?
>
> Wdyt?
>
> --
> Brett M. Gilio
> GNU Guix, Contributor | GNU Project, Webmaster
> [DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
>  
>
>
>


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38411: HTTP pipelining of narinfo requests broken for https://ci.guix.gnu.org

[Gábor Boskovits]

This was an upstream regression introduced in nginx 1.17.5.
It is fixed in 1.17.7. Fixed by updating nginx to 1.17.7 in commit:
32dfde905229e593f9fe60795d2490f99c27aad5
and updating berlin config in maintenance on commit:
87d451e9c3381b21e6c7208372576abed84df1e6.

This is mentioned on then nginx 1.17.7 release notes as:

Bugfix: a timeout might occur while handling pipelined requests in an
SSL connection; the bug had appeared in 1.17.5.

g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Gábor Boskovits]

Ricardo Wurmus  ezt írta (időpont: 2019. dec. 20., Pén
22:32):

>
> zimoun  writes:
>
> > Then you ask one question: "Should Guix be volatile software?" with
> > the subtitle "Software developers should avoid traumatic changes".
> > Nothing more.
> > Well, I answer you by trying to fill the gap. Note that "volatile
> > software" is the same argument than the Ludo's concern and the
> > Konrad's example. So, nothing new on the table; except you are
> > starting to throw "feelings" with the "traumatic change" words.
>
> I’m just chiming in here to say that feelings of frustration are very
> valid reasons to make or object to a change.  Guix is or can be a very
> important piece of software — if it remains reliable in the toolbox of
> those using it.
>
> It is difficult striking the right balance between exciting new features
> that make things possible that were previously unattainable and
> dependability through stable interfaces.
>
> The Guix command line is by far the most commonly used interface.  We
> can’t just claim that the Scheme API is stable (which it actually isn’t)
> and change the user-facing CLI as we please.
>
> Personally, I think that it is fine to introduce breaking changes, but
> that for changes that are likely to have a high potential for annoyance
> and frustration there ought to be a documented way to work around them.
> Breaking changes must be communicated through version number bumps and
> accompanying announcements.
>
> While I don’t see how we can make it happen, I do find the idea of a
> stable API whose version can be selected with an environment variable
> intriguing and worth thinking about.  If our Scheme API is as flexible
> as we claim it shouldn’t be too hard to interpose a configuration layer
> between the core facilities and the “porcelain”.
>
This is something that needs consideration. I believe that the original
ideas presented here, and what you say about having a stable api can be
easily synchronized by naming the environment variable to something like
GUIX_CLI_API_VERSION. I would propose it to be of the form 1.0.1.0, so that
the first three numbers could be the current guix  version. Havin it this
way would allow inter releas updates bumping the last number, and the
ability to easily set a new default when the major version is bumped, which
implies a breaking change anyways. From there on the question would be what
should be the default? I would say, that is should be
.0.0.0. Does that make sense?  Maybe we could come up with
something simpler, like dropping the second and third number.

>
> I wonder what the other maintainers think about this.
>
> --
> Ricardo
>
>
>
>
>

bug#38663: postgis is not reproducible

[Gábor Boskovits]

Hello,

Björn Höfling  ezt írta (időpont:
2019. dec. 18., Sze, 22:16):
>
> Package postgis contains many timestamps, making it not reproducible.
>
> Some examples below.
>
> Björn
>
>
> --- /gnu/store/121c447hzz55milkdp7ak15vxmsi1xpr-postgis-2.4.8
> +++ /gnu/store/121c447hzz55milkdp7ak15vxmsi1xpr-postgis-2.4.8-check
> ├── lib
> │ ├── postgis-2.4.so
> │ │ ├── /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/bin/readelf 
> --wide --decompress --hex-dump=.rodata {}
> │ │ │ @@ -253,15 +253,15 @@
> │ │ │0x00083fa0 6e617465  47656f6d 65747279 nateGeometry
> │ │ │0x00083fb0 20646f65 73206e6f 74206861 76652061  does not have a
> │ │ │0x00083fc0 205a206f 7264696e 61746500   Z ordinate.
> │ │ │0x00083fd0 5363616c 65206661 63746f72 2067656f Scale factor geo
> │ │ │0x00083fe0 6d657472 79207061 72616d65 74657220 metry parameter
> │ │ │0x00083ff0 6d757374 20626520 6120706f 696e7400 must be a point.
> │ │ │0x00084000 322e342e 38003230 31392d31 322d3138 2.4.8.2019-12-18
> │ │ │ -  0x00084010 2031323a 33393a35 36002573 20722564  12:39:56.%s r%d
> │ │ │ +  0x00084010 2031323a 33363a35 32002573 20722564  12:36:52.%s r%d
> │ │ │0x00084020 00322e39 2e390031 2e32006c 7767656f .2.9.9.1.2.lwgeo
> │ │ │0x00084030 6d5f6675 6e637469 6f6e735f 62617369 m_functions_basi
> │ │ │0x00084040 632e6300 5368656c 6c206973 206e6f74 c.c.Shell is not
> │ │ │0x00084050 2061206c 696e6500 486f6c65 20256420  a line.Hole %d
> │ │ │0x00084060 6973206e 6f742061 206c696e 6500496e is not a line.In
> │ │ │0x00084070 76616c69 64206f66 66736574 00506f69 valid offset.Poi
> │ │ │0x00084080 6e742069 6e736572 74206661 696c6564 nt insert failed
> │ ├── rtpostgis-2.4.so
> │ │ ├── objdump --line-numbers --disassemble --demangle --reloc 
> --section=.text {}
> │ │ │ @@ -17520,15 +17520,15 @@
> │ │ │ 1d009:e8 52 d4 fe ff  callq  a460 
> │ │ │ 1d00e:66 0f 6f 05 0a 4c 05movdqa 0x54c0a(%rip),%xmm0
> │ │ │ 1d015:00
> │ │ │ 1d016:ba 3a 35 00 00  mov$0x353a,%edx
> │ │ │ 1d01b:c7 00 5c 00 00 00   movl   $0x5c,(%rax)
> │ │ │ 1d021:66 89 50 14 mov%dx,0x14(%rax)
> │ │ │ 1d025:0f 11 40 04 movups %xmm0,0x4(%rax)
> │ │ │ -   1d029:c6 40 16 36 movb   $0x36,0x16(%rax)
> │ │ │ +   1d029:c6 40 16 32 movb   $0x32,0x16(%rax)
> │ │ │ 1d02d:48 83 c4 08 add$0x8,%rsp
>
>
> ├── share
> │ ├── contrib
> │ │ ├── postgis-2.4
> │ │ │ ├── postgis.sql
> │ │ │ │ @@ -2776,15 +2776,15 @@
> │ │ │ │ LANGUAGE 'c' IMMUTABLE;
> │ │ │ │
> │ │ │ │  CREATE OR REPLACE FUNCTION postgis_libxml_version() RETURNS text
> │ │ │ │ AS '$libdir/postgis-2.4'
> │ │ │ │ LANGUAGE 'c' IMMUTABLE;
> │ │ │ │
> │ │ │ │  CREATE OR REPLACE FUNCTION postgis_scripts_build_date() RETURNS text
> │ │ │ │ -   AS 'SELECT ''2019-12-18 12:39:56''::text AS version'
> │ │ │ │ +   AS 'SELECT ''2019-12-18 12:36:52''::text AS version'
> │ │ │ │ LANGUAGE 'sql' IMMUTABLE;
> │
>
>
> │ │ │ ├── uninstall_topology.sql
> │ │ │ │ @@ -4,15 +4,15 @@
> │ │ │ │  -- http://postgis.net
> │ │ │ │  --
> │ │ │ │  -- This is free software; you can redistribute and/or modify it under
> │ │ │ │  -- the terms of the GNU General Public Licence. See the COPYING file.
> │ │ │ │  --
> │ │ │ │  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> --
> │ │ │ │  --
> │ │ │ │ --- Generated on: Wed 18 Dec 2019 12:42:14 PM UTC
> │ │ │ │ +-- Generated on: Wed 18 Dec 2019 12:39:11 PM UTC
>
>
>
It seems that version 3.0.0 is out for two months. I will try to
update this first, then have a look at reproducibility. Wdyt?

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Gábor Boskovits]

Hello Konrad,

Konrad Hinsen  ezt írta (időpont: 2019. dec.
17., Ke 7:52):

> On 16/12/2019 23:09, Ludovic Courtès wrote:
> > So in a more algorithmic manner:
> >> 1. if ad-hoc and inputs-of is present at the same invocation: fail
> >> hard. (With an error like incompatible options present)
> >> 2. if only ad-hoc is present, then print a deprecation warning (yes,
> >> we could make this suspendable with an environment variable, like you
> >> described)
> >> 3. if only inputs-of present, then do the new behaviour.
> >> 4. if neither ad-hoc nor inputs-of present then
> >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour,
> >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the
> >> new behaviour.
> > That sounds like a good plan to me.
> >
> > #4 is the trickiest, and I think it’d be good to give users a bit of
> > time so they can start adjusting before deprecation is in effect.
>
> #4 is trickiest for another reason: there is no future-proof use of
> "guix environment" that works right now and will continue to work. Nor
> is there any way to see, when looking at a command line, whether it's
> old-style or new-style, if neither --ad-hoc nor --inputs-of are present.
> This means that all existing documentation (tutorials etc.) will become
> misleading in the future. Worse, even documentation written today, in
> full awareness of a coming change, can't do better than saying "watch
> out, this will do something else in the future".
>
> The first rule of backwards-compatibility is: never change the meaning
> of an existing valid command/API. Add new valid syntax, deprecate old
> valid syntax, but don't change the meaning of something that was and
> will be valid.
>
> How about a more drastic measure: deprecate "guix environment" and
> introduce a new subcommand with the desired new behaviour?
>
That is also the other option I was thinking about. Do you have any good
idea in mind as how to call it? Of course the classic guix environment2
comes to my mind, but it does not look very appealing to me.

>
>
> Cheers,
>
>Konrad.
>
Best regard,
g_bor

>
>
>
>

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Gábor Boskovits]

Hello Zimoun,

zimoun  ezt írta (időpont: 2019. dec. 13., P, 17:32):
>
> Hi Gábor,
>
> Sorry to be slow. :-)

I probably just did not express myself clearly enough.

>
> On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits  wrote:
>
>
> > So in a more algorithmic manner:
> > 1. if ad-hoc and inputs-of is present at the same invocation: fail
> > hard. (With an error like incompatible options present)
> > 2. if only ad-hoc is present, then print a deprecation warning (yes,
> > we could make this suspendable with an environment variable, like you
> > described)
> > 3. if only inputs-of present, then do the new behaviour.
> > 4. if neither ad-hoc nor inputs-of present then
> >   a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour,
> >   b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the
> > new behaviour.
> >
> > This would minimze friction, as there will be a few scripts falling under 4.
> > This would also allow mirgating such scripts one by one. be defining
> > GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using
> > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are
> > fixed to use the new syntax.
> >
> >
> > What do you think?
>
> I am perfectly aligned! :-)

Great!

> It is exactly what I have tried to describe.
> Sorry again for being slow.

I am sorry for the confusion, my communication tends to slugghish, an
I am also a bit bound to
do some hand-waving :) I hope to improve on that

>
> Thank you.
> Do you plan to implement it? Do I give a try?

I would like to hear something from Ludo, as he was also a participant
of the IRC discussion.

After that I would not mind if you gave it a try, if you would like.
Otherwise I will implement it.

>
>
> All the best,
> simon


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Gábor Boskovits]

Hello,

Let me try again :)

zimoun  ezt írta (időpont: 2019. dec. 13., P, 13:02):
>
> Hi Gábor,
>
>
> On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits  wrote:
>
> > zimoun  ezt írta (időpont: 2019. dec. 12., Csü 
> > 17:47):
>
> >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option
> >> with a different effect? Or why do we want to conserve this option
> >> name?
> >> It appears to me simpler to give another name, for example
> >> "--inputs-of". And it is more meaningful.
> >
> > Sorry for the confusion. Ad-hoc should be retained with the same effect, so 
> > that we do not break existing scripts.
> > Renamin the option would be ok. It even makes sense to me.
>
> What I propose is:
>
>   - keep the option "--ad-hoc" with the current behavior; so same effect
>   - add a new option "--inputs-of" with the new behavior; name more meaningful
>   - and two env variables; to not break existing scripts
>
>
> >> First, when "--ad-hoc" is used then it reports a warning: deprecated
> >> option and falls in the current behavior.
> >> When "--inputs-of" is used then it falls in the new behavior.
> >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc".
> >
> > That could be done. The problem is caused by uses of guix environment that 
> > does not use any of these options. Those mean different things after the 
> > change.
>
> The transition to such use-case was described below with the
> introduction of 2 env variables. :-)
>
>
> >>  # Alice
> >>  $ guix environment foo --ad-hoc bar
> >>  Warning: deprecated... explanations...
> >>instead use:
> >> guix environment bar --inputs-of foo
> >>
> >>  # Bob
> >>  $ guix environment bar --inputs-of foo
> >>
> >>
> >> Second, the previous "guix environment foo" (dependencies of foo) is
> >> inconsistent with the new "guix environment bar" (only the package
> >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED
> >> variable to distinguish both, as you said.
> >
> > Ok.
>
> It is the easy part. ;-)
>
>
> Now the hard part: avoid to break existing scripts.
>
> >>  # Alice
> >>  $ guix environment foo
> >>  Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1
> >>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1
> >>
> >> And Alice has now a new shell with the package foo. If she wants the
> >> dependencies, she has two options:
> >>
> >> $ GUIX_ENVIRONMENT=1 guix environment foo
> >> or
> >> $ guix environment --inputs-of foo
> >>
> >>
> >>  # Bob
> >>  $ guix environment bar
> >>  Warning: previous behavior requires GUIX_ENVIRONMENT
> >>
> >> And if Bob is annoyed by the warnings each time, he globally turns off
> >> with the variable GUIX_ENVIRONMENT_NOWARNING=1.
> >>
> >>
> >> Couple of months later -- after the period adoption -- we remove the
> >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED;
> >> still keeping the warning with the "--ad-hoc" option. And then, after
> >> we can remove the "--ad-hoc" option if required.
>
>
> > We could recommend simply to use something like:
> > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ...
> > Instead in existing scripts that are fixed to use the new syntax. This 
> > indeed looks like a better solution, and it is less of a maintenance 
> > burden. Good idea.
>
> My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only
> be used by the scripts that call "guix environment pkg" without the
> options "--ad-hoc" or "--inputs-of". And I think that it represents
> really few scripts in real life. :-)
>
>
> > Summarizing:
> > Introduce the environment variable.
> > For fixed scripts recommend unsetting the environment variable.
>
> I am not to get your plan. :-)
>
>
> Cheers,
> simon

So in a more algorithmic manner:
1. if ad-hoc and inputs-of is present at the same invocation: fail
hard. (With an error like incompatible options present)
2. if only ad-hoc is present, then print a deprecation warning (yes,
we could make this suspendable with an environment variable, like you
described)
3. if only inputs-of present, then do the new behaviour.
4. if neither ad-hoc nor inputs-of present then
  a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour,
  b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the
new behaviour.

This would minimze friction, as there will be a few scripts falling under 4.
This would also allow mirgating such scripts one by one. be defining
GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using
GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are
fixed to use the new syntax.


What do you think?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Gábor Boskovits]

Hello,

zimoun  ezt írta (időpont: 2019. dec. 12., Csü
17:47):

> Hi Gábor,
>
> Thank you for summarizing the discussion on IRC that I missed.
>
> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option
> with a different effect? Or why do we want to conserve this option
> name?
> It appears to me simpler to give another name, for example
> "--inputs-of". And it is more meaningful.
>
Sorry for the confusion. Ad-hoc should be retained with the same effect, so
that we do not break existing scripts.
Renamin the option would be ok. It even makes sense to me.

>
>
> To be concrete, the different cases; (-) means current behavior and
> (+) the new one:
>
> 1.
> - guix environment foo
> + guix environment --inputs-of foo
>
> 2.
> - guix environment --ad-hoc bar
> + guix environment bar
>
>
> First, when "--ad-hoc" is used then it reports a warning: deprecated
> option and falls in the current behavior.
> When "--inputs-of" is used then it falls in the new behavior.
> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc".
>
That could be done. The problem is caused by uses of guix environment that
does not use any of these options. Those mean different things after the
change.

>
>
> In other words, with the same future guix version,
>
>  # Alice
>  $ guix environment foo --ad-hoc bar
>  Warning: deprecated... explanations...
>instead use:
> guix environment bar --inputs-of foo
>
>  # Bob
>  $ guix environment bar --inputs-of foo
>
>
> Second, the previous "guix environment foo" (dependencies of foo) is
> inconsistent with the new "guix environment bar" (only the package
> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED
> variable to distinguish both, as you said.
>
Ok.

>
>  # Alice
>  $ guix environment foo
>  Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1
>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1
>
> And Alice has now a new shell with the package foo. If she wants the
> dependencies, she has two options:
>
> $ GUIX_ENVIRONMENT=1 guix environment foo
> or
> $ guix environment --inputs-of foo
>
>
>  # Bob
>  $ guix environment bar
>  Warning: previous behavior requires GUIX_ENVIRONMENT
>
> And if Bob is annoyed by the warnings each time, he globally turns off
> with the variable GUIX_ENVIRONMENT_NOWARNING=1.
>
>
> Couple of months later -- after the period adoption -- we remove the
> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED;
> still keeping the warning with the "--ad-hoc" option. And then, after
> we can remove the "--ad-hoc" option if required.
>
>
> Maybe a miss a point. But the addition of the flag appears
> "--too-long-to-type" to me ugly.
>
We could recommend simply to use something like:
GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ...
Instead in existing scripts that are fixed to use the new syntax. This
indeed looks like a better solution, and it is less of a maintenance
burden. Good idea.

>
>
> What do you think?
>
> All the best,
> simon
>

Summarizing:
Introduce the environment variable.
For fixed scripts recommend unsetting the environment variable.

That looks like a better plan. Thanks for your insights.

Best regards,
g_bor

>

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Gábor Boskovits]

Hello guix,

Based on discussion on IRC the following plan for deprecation might work.
Comments are welcome:

1.
Make guix environment aware of an environment variable:
GUIX_ENVIRONMENT_DEPRECATED_AD_HOC
if this is defined, then fall back to the current behaviour.

Motivation: this would enable most script users to bypass the problem,
while fixing them, but it makes the users aware that they are using a
deprecated feature.
At the same time this should come with a news entry, an any other
announcements should be made that we usually do, so that support don't
get overloaded. Is should also be announced that two releases later
the code supporting this will be removed, so that we don't have to
maintain it, but allow enough time for adoption.

2. add a flag to guix environment, something like
--ignore-deprecated-ad-hoc, that makes guix environment ignore the
environment variable, and default to the new behaviour.

Motivation: so that scripts can be fixed individually by modifying the
guix environment call to the new version, and adding the flag, so that
it does not cause a problem in the trasitional period while the
environment variable is defined.

3. on the specified release remove the environment variable support
code, and make the flag a noop, and also deprecated.

4. later if needed after an adoption period we can remove the flag.


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38544: gparted segfaults

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2019. dec. 9., H, 11:11):
>
> This segfaults:
>
> sudo /gnu/store/yzxyxnxja4y1riwh3mrqrvb7h4vhxlqb-gparted-1.0.0/bin/gparted
>
> --8<---cut here---start->8---
> …
> (gpartedbin:5364): Gdk-CRITICAL **: 11:06:10.219: 
> gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF (pixbuf)' 
> failed
>
> (gpartedbin:5364): GLib-GObject-CRITICAL **: 11:06:10.219: g_object_unref: 
> assertion 'G_IS_OBJECT (object)' failed
>
> (gpartedbin:5364): Gtk-WARNING **: 11:06:10.273: Error loading theme icon 
> 'drive-harddisk' for stock: Icon 'drive-harddisk' not present in theme Adwaita
>
> (gpartedbin:5364): Gtk-WARNING **: 11:06:10.273: Error loading theme icon 
> 'image-missing' for stock: Failed to load 
> /org/gtk/libgtk/icons/24x24/status/image-missing.png: Unrecognized image file 
> format
> /gnu/store/yzxyxnxja4y1riwh3mrqrvb7h4vhxlqb-gparted-1.0.0/bin/gparted: line 
> 202:  5364 Segmentation fault  $BASE_CMD--8<---cut 
> here---end--->8---
>
> This does not segfault:
>
> sudo -E 
> /gnu/store/yzxyxnxja4y1riwh3mrqrvb7h4vhxlqb-gparted-1.0.0/bin/gparted
>
> The problem here is that when run as root but without the environment of
> the current user gparted fails to find the image loader modules.

Yes, I concur.

I believe this affects multiple packages, but as it is rarely needed
to run them with sudo this did not become apparent. Question is what
needs to be done here. I would say if it is ok to run these with sudo
-E, then we could work it around by documenting this, but the proper
solution would be to ensure that these modules are found.

>
> --
> Ricardo
>
>
>
>

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38198: missing shell for postgresql system user

[Gábor Boskovits]

Hello,

Giovanni Biscuolo  ezt írta (időpont: 2019. nov. 13., Sze, 
18:38):
>
> Hello Guix!
>
> Current postgresql access rules (pg_hba.conf) defaults to (see
> [bug#36191] for details on that patch):
>
> --8<---cut here---start->8---
> local   all all peer
> hostall all 127.0.0.1/32md5
> hostall all ::1/128 md5
> --8<---cut here---end--->8---
>
> Peer authentication works by obtaining the (local) client's operating
> system user name from the kernel and using it as the allowed database
> user name, and is better than "trust" authentication
>
> To access a database server on localhost for the first time as the user
> postgres (the superuser) a person should use:
>
> --8<---cut here---start->8---
> sudo su postgres -c 'psql'
> --8<---cut here---end--->8---
>
> AFAIK this is the only method available after database initialization,
> with peer authentication
>
> Since the postgres user currently have a nologin shell (from
> gnu/services/databases.scm):
>
> --8<---cut here---start->8---
> (define %postgresql-accounts
>   (list (user-group (name "postgres") (system? #t))
> (user-account
>  (name "postgres")
>  (group "postgres")
>  (system? #t)
>  (comment "PostgreSQL server user")
>  (home-directory "/var/empty")
>  (shell (file-append shadow "/sbin/nologin")
> --8<---cut here---end--->8---
>
> the above command does not work
>
> As a workaround I changed the postgres user shell to /bin/bash
> and I was able to connect
>
> I do not see any security issue giving a shell to postgres, since it's
> password is disabled in /etc/shadow so the only way to access as
> postgres is via `sudo su postgres`

I would not mind this change, I think it is ok. However it is easy to
work around this with su -s.
I usually do that.
>
> Thougts?
>
> Thanks, Gio'
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38088: Guix system becomes unresponsive after backtrace

[Gábor Boskovits]

It seems this was a filesystem corruption. Everything seems fine after reboot,
so closing.

Giovanni Biscuolo  ezt írta (időpont: 2019. nov. 7., Cs, 8:36):
>
> Hello Gabor,
>
> Gábor Boskovits  writes:
>
> [...]
>
> >> From the screenshot, it seems that your root file system (or at least
> >> /tmp and /gnu/store) became read-only, which in turn caused various
> >> things to fail, including guix-daemon (hence the “broken pipe” when
> >> ‘guix build’ was talking to it, I suppose.)
> >
> > Yes, it also became corrupted. fsck on boot fixed it.
> > Since then it works happily again...
>
> if the problem depended on filesystem corruption and all is fine now for
> you, could you also close this bug please?
>
> [...]
>
> Thanks! Gio'
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures



-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38088: Guix system becomes unresponsive after backtrace

[Gábor Boskovits]

Danny Milosavljevic  ezt írta (időpont: 2019.
nov. 6., Sze, 16:52):
>
> Hi Gábor,
>
> On Wed, 6 Nov 2019 15:15:41 +0100
> Gábor Boskovits  wrote:
>
> > This happened when I was trying a pre-inst-env guix build from a
> > core-updates checkout.
> > Previously python3 failed to build, and I was trying to build it again.
>
> Hmm, sounds like disk corruption.  If there's a sudden read-only appearing 
> then
> it's often because the kernel found a file system error and doesn't want to 
> make
> the situation worse.  It then remounts the affected file-system read-only.
> According to the top of your screenshot, even /tmp is read-only.  I think we
> don't use a tmpfs, so that's the root file system.

I also believe it was the root filesystem.

>
> Could you check dmesg for signs?

I believe the dmesg info was lost on force-restart. Logs contain nothing

Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38088: Guix system becomes unresponsive after backtrace

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2019. nov. 6., Sze, 18:42):
>
> Hi Gábor,
>
> Gábor Boskovits  skribis:
>
> > I did not know how to get the info better, so here is a screenshot
> > about the situation.
> >
> > This happened when I was trying a pre-inst-env guix build from a
> > core-updates checkout.
> > Previously python3 failed to build, and I was trying to build it again.
>
> From the screenshot, it seems that your root file system (or at least
> /tmp and /gnu/store) became read-only, which in turn caused various
> things to fail, including guix-daemon (hence the “broken pipe” when
> ‘guix build’ was talking to it, I suppose.)

Yes, it also became corrupted. fsck on boot fixed it.
Since then it works happily again...

>
> Could you check what happened on your machine?  Do /var/log/messages and
> /var/log/guix-daemon.log contain any hints?

No idea actually, I don't see anything really suspicious, but it might
well be that it just refused
to write to the logs also...

>
> Thanks,
> Ludo’.


Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38088: Guix system becomes unresponsive after backtrace

[Gábor Boskovits]

Hello,

I did not know how to get the info better, so here is a screenshot
about the situation.

This happened when I was trying a pre-inst-env guix build from a
core-updates checkout.
Previously python3 failed to build, and I was trying to build it again.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#38086: RAID installation script with ‘mdadm’ no longer works

[Gábor Boskovits]

Hello Ludo,


Ludovic Courtès  ezt írta (időpont: 2019. nov. 6., Sze,
11:14):

> Hello,
>
> Looks like our RAID installation method no longer works, as can be seen
> at :
>
> --8<---cut here---start->8---
> + guix --version
> guix (GNU Guix) c4de60ac3c6aa5b46519011af89988215c347e9e
> Copyright (C) 2019 the Guix authors
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> + export GUIX_BUILD_OPTIONS=--no-grafts
> + GUIX_BUILD_OPTIONS=--no-grafts
> + parted --script /dev/vdb mklabel gpt mkpart primary ext2 1M 3M mkpart
> primary ext2 3M 600M mkpart primary ext2 600M 1200M set 1 boot on set 1
> bios_grub on
> + mdadm --create /dev/md0 --verbose --level=stripe --raid-devices=2
> /dev/vdb2 /dev/vdb3
> mdadm: chunk size defaults to 512K
> mdadm: Defaulting to version 1.2 metadata
> [   13.890586] md/raid0:md0: cannot assemble multi-zone RAID0 with
> default_layout setting
> [   13.894691] md/raid0: please set raid0.default_layout to 1 or 2
> [   13.896000] md: pers->run() failed ...
> mdadm: RUN_ARRAY failed: Unknown error 524
> [   13.901603] md: md0 stopped.
> --8<---cut here---end--->8---
>
> Anyone knows what it takes to “set raid0.default_layout to 1 or 2”?
>

On kernel 5.3.4 and above the
raid0.default_layout=2 kernel boot paramter should be set. We should
generate our grub configuration accordingly.

See this for reference:
https://blog.icod.de/2019/10/10/caution-kernel-5-3-4-and-raid0-default_layout/



> We should then update (gnu tests install) and the manual accordingly.
>
> Thanks,
> Ludo’.
>
Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37917: Kernel Panic

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2019. okt. 25., P, 23:09):

> Hi,
>
> Raghav Gururajan  skribis:
>
> > Whenever I shutdown my system, 50% of the time, I end up with kernel
> > panic. Then I had to do cold restart.
> >
> > Kernel Panic:
> >
> https://upload.disroot.org/r/B5Z3ofx_#/XTJVfcPxwYaDqzEGiQdv0Y6wQal34Oik77HlA7K7BE=
>
> I can’t access it with IceCat over Tor (“Error: the file has not been
> sent entirely.”)  Can someone share it in some other way?
>

Now I see the same error. I could access it eariler though. The only thing
I remember is that it was
an attempted to kill init... I hope Raghav can share it again.

>
> Like Florian writes a panic upon halt could be a Shepherd issue but we
> need to see that last screen before we can draw any conclusions.
>
> Thanks,
> Ludo’.
>
>
>
>
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37929: clojure is not usable out of the box

[Gábor Boskovits]

Hello,
this seems to be a partial duplicate of #32709. Maybe we could merge
these...


Bradley Haggerty  ezt írta (időpont: 2019. okt. 25.,
P, 22:49):

> You cannot get a repl by running `clojure`, and it's lacking java as a
> dependency even though java seems to be needed to use it. Other
> languages are usable out of the box, so I think it would be good to
> change these things.
>
>
>
>

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37900: guix invocation induces guile locale error

[Gábor Boskovits]

Sorry, maybe I was not clear on this. On 37914 there was a message that it
is ok to close 37900. See:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37914#13

Ludovic Courtès  ezt írta (időpont: 2019. okt. 25., P, 22:46):

> Gábor Boskovits  skribis:
>
> > Submitter requested to close the bug on #37914. Closing.
>
> You closed 37900 though, not 37914, or am I missing something?
>
> Ludo’.
>


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37900: guix invocation induces guile locale error

[Gábor Boskovits]

Submitter requested to close the bug on #37914. Closing.

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37682: weston 6.0.1 build failure

[Gábor Boskovits]

Just some further info. This is not deterministic. Did not work on one of
my systems yesterday, today it works just fine. I did not pull in the
meantime.

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37682: weston 6.0.1 build failure

[Gábor Boskovits]

Hello,
I just encountered this. I will first try to update it to 7.0.0, and see if
it helps.

Marius Bakke  ezt írta (időpont: 2019. okt. 24., Cs,
18:54):

> Bradley Haggerty  writes:
>
> >   guix 525ef21
> > repository URL: https://git.savannah.gnu.org/git/guix.git
> > branch: master
> > commit: 525ef21ba0d4a50a7d21f5543db40b6cc328f9cd
> >
> > builder for
> `/gnu/store/i1k1znpbswllwhaja6g3nlbb4g2gpk1c-weston-6.0.1.drv'
> > failed with exit code 1
> > build of /gnu/store/i1k1znpbswllwhaja6g3nlbb4g2gpk1c-weston-6.0.1.drv
> failed
> > View build log at
> >
> '/var/log/guix/drvs/i1/k1znpbswllwhaja6g3nlbb4g2gpk1c-weston-6.0.1.drv.bz2'.
> > guix package: error: build of
> > `/gnu/store/i1k1znpbswllwhaja6g3nlbb4g2gpk1c-weston-6.0.1.drv' failed
> >
> > build log: https://paste.debian.net/1105575/
>
> So apparently this only happens on some systems.  I can not reproduce it
> on my dinky laptop, but I can on a Haswell Xeon server.
>
> Can you file a bug report about this upstream at
> ?
>
> We can probably disable the test in question, but it would be good to
> have an upstream bug report to link to.
>
> On the Guix CI, Weston builds successfully only on armhf:
>
> https://ci.guix.gnu.org/search?query=weston
>
> It is possible that clocking down your CPU while running the tests would
> help as a band-aid...
>


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Gábor Boskovits]

The submitter solved the problem, and requested to close. Closing.

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#29474: Hydra guix tarball build faliure

[Gábor Boskovits]

Hydra is decomissioned for a while, closing.

bug#37669: guile: warning: failed to install locale

[Gábor Boskovits]

Hello Jesse,

Jesse Gibbons  ezt írta (időpont: 2019. okt. 9.,
Sze, 0:51):

> On a GuixSD install, the following message began appearing today (I did not
> record what time):
> guile: warning: failed to install locale
> It appears whenever I run `guix` regardless of the command-line arguments I
> pass to it.
> GUIX_LOCPATH looks like this:
> ~$ echo $GUIX_LOCPATH
> /run/current-system/locale
> I have not today run "guix system reconfigure"
> - Could this be related to the core-updates merge?
> - Is there a work-around?
> --
> -Jesse
>
>
This is most probably a transient core-updates effect. Reconfigure should
fix this, and this should be harmless.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37679: Local git configuration interferes with testsuite

[Gábor Boskovits]

I noticed that the local git configuration interferes with the guix test
suite.

After discussion on IRC with nckx I came up with the attached patch.
Comments are welcome!

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
From abf20477ea139bfaf1f2e21f09c2420fe618c9ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
Date: Tue, 8 Oct 2019 22:41:20 +0200
Subject: [PATCH] tests: Isolate git from external configuration.

* Makefile.am(AM_TESTS_ENVIRONMENT): Add environment variables to
make git ignore the user and system configuration files.
* tests/fake-home/.gitconfig: New file. Provide minimal git
configuration for tests.
---
 Makefile.am|  9 -
 tests/fake-home/.gitconfig | 21 +
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 tests/fake-home/.gitconfig

diff --git a/Makefile.am b/Makefile.am
index 36767c2f47..e7bf819a6b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,6 +14,7 @@
 # Copyright © 2018 Oleg Pykhalov 
 # Copyright © 2018 Alex Vong 
 # Copyright © 2019 Efraim Flashner 
+# Copyright © 2019 Gábor Boskovits 
 #
 # This file is part of GNU Guix.
 #
@@ -472,7 +473,13 @@ SH_TESTS =	\
 
 TESTS = $(SCM_TESTS) $(SH_TESTS)
 
-AM_TESTS_ENVIRONMENT = abs_top_srcdir="$(abs_top_srcdir)" GUILE_AUTO_COMPILE=0
+AM_TESTS_ENVIRONMENT = \
+  abs_top_srcdir="$(abs_top_srcdir)" 		\
+  GUILE_AUTO_COMPILE=0\
+  GIT_CONFIG_NOSYSTEM=1\
+  GIT_ATTR_NOSYSTEM=1\
+  HOME="$(abs_top_srcdir)/tests/fake-home"	\
+  XDG_CONFIG_HOME="$(abs_top_srcdir)/tests/fake-xgd-config-home"
 
 SCM_LOG_DRIVER =\
   $(top_builddir)/test-env --quiet-stderr	\
diff --git a/tests/fake-home/.gitconfig b/tests/fake-home/.gitconfig
new file mode 100644
index 00..079cbd0d30
--- /dev/null
+++ b/tests/fake-home/.gitconfig
@@ -0,0 +1,21 @@
+# GNU Guix --- Functional package management for GNU
+# Copyright © 2019 Gábor Boskovits 
+#
+# This file is part of GNU Guix.
+#
+# GNU Guix is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or (at
+# your option) any later version.
+#
+# GNU Guix is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+[user]
+  email = em...@example.com
+  name = Usman
-- 
2.23.0

bug#37631: service zabbix-server (and zabbix-agent) fails starting (cannot run as root!)

[Gábor Boskovits]

Hello Giovanni,

Giovanni Biscuolo  ezt írta (időpont: 2019. okt. 5., Szo,
14:51):

> Giovanni Biscuolo  writes:
>
> > executive summary: do we really need to start zabbix_server in
> > foreground mode?
>
> executive answer: I don't know **but** this is not the cause of my issue
> :)
>
> > --8<---cut here---start->8---
>
> [...]
>
> >(service zabbix-server-service-type
> >   (zabbix-server-configuration
> >(include-files
> '("/root/secrets/zabbix-server-dbpass"))
> >(log-type "file")))
>
> ouch!... looking at the console (it's a remote VM so I usually connect
> via ssh only, but today I also connected via SPICE):
>
> --8<---cut here---start->8---
> zabbix_server [1942]: /root/secrets/zabbix-server-dbpass: [13] Permission
> denied
> --8<---cut here---end--->8---
>
> unfortunately shepherd did not catch this error (due to foreground
> mode?) in syslog :-(
>
> I just had to adjust the permissions to allow zabbix (I allowed the
> zabbix group to traverse /root/secrets and read the file) to read the
> included file
>
> this now works with both zabbix 4.2.0 and zabbix 4.2.7
>
> [...]
>
> Thanks! Gio'
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures
>
>
>
> Can we consider this resolved then?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux

[Gábor Boskovits]

Hello Marius,

Marius Bakke  ezt írta (időpont: 2019. okt. 5., Szo,
14:40):

> Pierre Langlois  writes:
>
> > Hi Marius,
> >
> > Marius Bakke writes:
> >
> >> Berlin fails to build "linux-libre" for AArch64 on the 'core-updates'
> >> branch.  Here is a recent attempt:
> >>
> >> https://ci.guix.gnu.org/build/1758844/details
> >>
> >> Log file for the latest build:
> >>
> >>
> https://ci.guix.gnu.org/log/aq2rnrmjsgnyk8vmsm7aa3mgdj39dcwh-linux-libre-5.2.17.drv
> >>
> >> This seems to be the salient bit:
> >>
> >> CC [M]  arch/arm64/lib/xor-neon.o
> >> In file included from
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:34:0,
> >>  from
> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
> >>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
> >>  from arch/arm64/lib/xor-neon.c:11:
> >>
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-intn.h:27:19:
> error: conflicting types for 'int64_t'
> >>  typedef __int64_t int64_t;
> >>^~~
> >> In file included from ./include/linux/list.h:5:0,
> >>  from ./include/linux/module.h:9,
> >>  from arch/arm64/lib/xor-neon.c:10:
> >> ./include/linux/types.h:114:15: note: previous declaration of 'int64_t'
> was here
> >>  typedef s64   int64_t;
> >>^~~
> >> In file included from
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:37:0,
> >>  from
> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
> >>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
> >>  from arch/arm64/lib/xor-neon.c:11:
> >>
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-uintn.h:27:20:
> error: conflicting types for 'uint64_t'
> >>  typedef __uint64_t uint64_t;
> >> ^~~~
> >> In file included from ./include/linux/list.h:5:0,
> >>  from ./include/linux/module.h:9,
> >>  from arch/arm64/lib/xor-neon.c:10:
> >> ./include/linux/types.h:112:15: note: previous declaration of
> 'uint64_t' was here
> >>  typedef u64   uint64_t;
> >>^~~~
> >> make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o]
> Error 1
> >> make: *** [Makefile:1073: arch/arm64/lib] Error 2
> >> make: *** Waiting for unfinished jobs
> >>
> >> Not sure what's going on here.  Ideas?
> >
> > Ha, that looks familiar, the same issue happened back in July:
> > https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00175.html
> >
> > I don't think we worked out what was the problem exactly though :-/
>
> So I was able to build it with this patch:
>
>
> It's not very pretty though.  Thoughts?
>

I believe that we encountered similar CPATH related problems earlier, which
were fixed by pathes like this, so it looks good to me. Maybe it would
worth investigating the pattern though, and create some generic mechanism
to deal with it. Wdyt?


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#36785: Impossible to pull on foreign distro

[Gábor Boskovits]

Ludovic Courtès  ezt írta (időpont: 2019. szept. 23., Hét
10:29):

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
> > --- a/doc/guix.texi
> > +++ b/doc/guix.texi
> > @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From
> then on, you can update the
> >  system whenever you want by running, say:
> >
> >  @example
> > -guix pull
> > -sudo guix system reconfigure /etc/config.scm
> > +sudo -i guix pull
> > +sudo -i guix system reconfigure /etc/config.scm
> >  @end example
> >
> >  @noindent
> > @@ -2396,14 +2396,6 @@ This builds a new system generation with the
> latest packages and services
> >  (@pxref{Invoking guix system}).  We recommend doing that regularly so
> that
> >  your system includes the latest security updates (@pxref{Security
> Updates}).
> >
> > -@c See <
> https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
> > -@quotation Note
> > -@cindex sudo vs. @command{guix pull}
> > -Note that @command{sudo guix} runs your user's @command{guix} command
> and
> > -@emph{not} root's, because @command{sudo} leaves @code{PATH}
> unchanged.  To
> > -explicitly run root's @command{guix}, type @command{sudo -i guix
> @dots{}}.
> > -@end quotation
>
> I think these bits were correct.
>
> That is, when running “sudo foo”, “foo” is looked up in the user’s
> $PATH, not in root’s $PATH.  That’s what led to this text in commit
> 796a4491fdaa4a0a3d669457b89356f9fbfc966e.
>
> So this part is fine
>
I believe sudo -H would work in all distros for doing a root guix pull. Can
someone confirm?

>
> Perhaps we need another section for this?  Or perhaps we can drop the
> ball…
>
> Thanks,
> Ludo’.
>
Best regards,
g_bor

>

bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2019. szept. 19., Cs,
23:24):

> Hello,
>
> Timothy Sample  skribis:
>
> > Could this be the same issue as ?  In short,
> > Guix doesn’t guarantee that the “gdm” user will have the same UID if it
> > gets deleted and recreated (which happens when you remove the GDM
> > service and add it again).  You can fix this by ensuring the owner of
> > the files under “/var/lib/gdm” is the current “gdm” user.
>
> If you just (1) configure with GDM, (2) reconfigure without GDM, and (3)
> reconfigure with GDM again, I would expect the original UID of ‘gdm’ to
> be reused in step #3, as long as it has not been reallocated in the
> meantime (for instance because the user created other accounts.)
>
> We could address this by fixing the UID and GID of the ‘gdm’ user:
>
>
> However, looking at the allocation routines in (gnu build accounts), I
> think that this would forcefully set ‘gdm’ to 900/900 on existing
> installations, even if 900 is already used by another account:
>
> --8<---cut here---start->8---
> scheme@(gnu build accounts)> (allocate-groups (list (user-group (name
> "foo")(id 10)))
>   vlist-null
>   (list (group-entry
>  (name "foo")  (gid
> 20
> $2 = (#< name: "foo" password: #f gid: 10 members: ()>)
> --8<---cut here---end--->8---
>
> That’s a valid policy (declaration prevails over state), but it does
> mean that we can’t really apply the above patch.
>
> (Or we could use much lower UID/GID numbers, which are less likely to be
> taken…)
>
> Thoughts?
>
>
Couldn't we simply do what the fix does: ensuring the owner of
the files under “/var/lib/gdm” is the current “gdm” user?


> Ludo’.
>

That would solve this issue, without actually fixing the UID and GID.


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#36785: Impossible to pull on foreign distro

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès  ezt írta (időpont: 2019. szept. 18., Sze,
0:04):

> Hi,
>
> Ludovic Courtès  skribis:
>
> > Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
> > (canonicalize-profile %user-profile-directory), and here’s what I see
> > with ‘sudo’:
> >
> > $ sudo -E ./pre-inst-env guix pull
> >
> > ;;; (pd "/var/guix/profiles/per-user/root")
> >
> > ;;; (upd "/home/ludo/.config/guix/current")
>
> I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
> Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
> the right thing (this is on Guix System):
>
> --8<---cut here---start->8---
> $ sudo guix repl
> GNU Guile 2.2.4
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guix-user)> (getenv "HOME")
> $1 = "/root"
> scheme@(guix-user)> ,m(guix scripts pull)
> scheme@(guix scripts pull)> %profile-directory
> $2 = "/var/guix/profiles/per-user/root"
> scheme@(guix scripts pull)> %user-profile-directory
> $3 = "/root/.config/guix/current"
> scheme@(guix scripts pull)> (cache-directory)
> $4 = "/root/.cache/guix"
> scheme@(guix scripts pull)> (config-directory)
> $5 = "/root/.config/guix"
> --8<---cut here---end--->8---
>
> So ‘sudo guix pull’ really updates root’s profile and writes to
> ~root/.cache, everything is fine.
>
> Done?
>
> I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
> on Ubuntu behaves differently: it preserves ‘HOME’ by default:
>
>   $ sudo env | grep HOME
>   HOME=/home/ubuntu
>
> This is written here:
>
>
> https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
>
> (That’s with sudo 1.8.21p2, FWIW.)
>
> Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
> has (almost) the same /etc/sudoers and yet it does not preserve HOME.
>
> (Time passes…)
>
> Digging further, I fetched the source from
> , and boom! I found the
> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>
> --8<---cut here---start->8---
> Description: Set HOME in initial_keepenv_table
>  Set HOME in initial_keepenv_table; without this, $HOME will never be
>  preserved unless added to keep_env.  There's appropriate logic to handle
>  resetting the home for -H and -i options, so this is the only part that's
>  missing.
> Author: Steve Langasek 
> --- a/plugins/sudoers/env.c
> +++ b/plugins/sudoers/env.c
> @@ -189,6 +189,7 @@
>  "COLORS",
>  "DISPLAY",
>  "DPKG_COLORS",
> +"HOME",
>  "HOSTNAME",
>  "KRB5CCNAME",
>  "LS_COLORS",
> --8<---cut here---end--->8---
>
> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
> consider reporting a bug!)
>
> But anyway, what can we do?
>
> We could ignore the issue, it’s-Ubuntu’s-fault, done.
>
> We could also add some logic to detect whether (1) we’re running under
> sudo, and in that case, and whether (2) $HOME matches $USER’s home
> directory as it appears in /etc/passwd.  If both conditions are
> satisfied, we could ignore $HOME and use the home directory from
> /etc/passwd instead.
>
> But… that’s complicated, and it’d break uses of ‘sudo -H’.
>
> We could apply the patch I posted earlier, which simply disables profile
> migration when SUDO_USER is set.  That won’t address the fact that root
> writes to the user’s ~/.cache, but there’s not much we can do here.
>
> Thoughts?
>

We could simply document a proper sudo invocation for updating root's guix,
that
always works. Wdyt?

We could provide it simply as a hint if it fails.


>
> Ludo’.
>
>
>
>
Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37388: can lead to syntactically invalid configs

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2019. szept. 12., Cs,
9:58):

> Hello Guix!
>
> It’s nice that we have  but I noticed that, unlike
> most or all other configuration records that we have, it’s possible to
> create an  record that leads to a syntactically
> invalid nginx config file.
>
> For example, if you have a location block like this:
>
> (nginx-location-configuration
>   (uri "/manual/")
>   (body (list "alias /srv/guix-manual")))
>
> Guix will silently create an invalid nginx config file, which you’ll
> only notice once you’ve reconfigured and nginx fails to start.
>
> See why?  That’s because we’re missing a semicolon in the “alias”
> directive, and that directive is spit out directly as is.
>
> To address it, we could have record types for , , and all
> the directives out there; it could be tedious, unless we automate it,
> effectively creating a complete EDSL.
>
> Another approach would be to have an sexp representation of the nginx
> configuration language.  That’d effectively replace semicolons with
> parentheses :-), but more importantly, that would allow us to not paste
> strings as-is in the resulting config file.  The downside is that it’s
> very much “free style” compared to records, but we could still
> pattern-match the sexp to validate certain properties.
>
>
I would most probably go for the sexp version.


> Thoughts?
>

I would like to add some more information to this, which I encountered when
trying to find a solution to the last-modified issue:

1. the nginx configuration can only be extended using server blocks, so it
is not possible to inject a location or a nested location.
2. the meaning of the nginx configuration can dependent on the order of
directives in the configuration. Either we should give
and explicit mechanism for dealing with that, or disallow such
configurations.

If you feel these points to be off topic, then I can open a separate bug
for that, but these seem to relate to the confgiuration mechanism,
and should be considered when designing the new interface. Wdyt?


>
> Ludo’.
>
>
>
>
Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37373: python-ipython-documentation build is not reproducible

[Gábor Boskovits]

Hello,


Maxim Cournoyer  ezt írta (időpont: 2019. szept.
11., Sze, 2:30):

> Here's the diff produced by diffoscope:
>
> ---
> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0
> +++
> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0-check
> ├── share
> │ ├── doc
> │ │ ├── python-ipython-documentation-7.5.0
> │ │ │ ├── html
> │ │ │ │ ├── sphinxext.html
> │ │ │ │ │┄ xxd not available in path. Falling back to Python hexlify.
> │ │ │ │ │ @@ -1182,29 +1182,29 @@
> │ │ │ │ │  3d226e223e6461746574696d653c2f7370616e3e3c7370616e20636c6173733d
> │ │ │ │ │  226f223e2e3c2f7370616e3e3c7370616e20636c6173733d226e223e64617465
> │ │ │ │ │  74696d653c2f7370616e3e3c7370616e20636c6173733d226f223e2e3c2f7370
> │ │ │ │ │  616e3e3c7370616e20636c6173733d226e223e6e6f773c2f7370616e3e3c7370
> │ │ │ │ │  616e20636c6173733d2270223e28293c2f7370616e3e0a3c7370616e20636c61
> │ │ │ │ │  73733d226770223e2020202e2e2e3a203c2f7370616e3e0a3c7370616e20636c
> │ │ │ │ │  6173733d22676f223e4f75745b325d3a206461746574
> │ │ │ │ │ -696d652e6461746574696d6528323031392c20392c2031312c20302c2031362c
> │ │ │ │ │ -2033372c20363833363634293c2f7370616e3e0a3c2f7072653e3c2f6469763e
> │ │ │ │ │ +696d652e6461746574696d6528323031392c20392c2031312c20302c2032312c
> │ │ │ │ │ +2031322c20353230363534293c2f7370616e3e0a3c2f7072653e3c2f6469763e
> │ │ │ │ │  0a3c2f6469763e0a3c703e497420737570706f7274732049507974686f6e2063
> │ │ │ │ │  6f6e737472756374207468617420706c61696e0a507974686f6e20646f657320
> │ │ │ │ │  6e6f7420756e6465727374616e6420286c696b65206d6167696373293a3c2f70
> │ │ │ │ │  3e0a3c64697620636c6173733d22686967686c696768742d69707974686f6e20
> │ │ │ │ │  6e6f7472616e736c617465223e3c64697620636c6173733d22686967686c6967
> │ │ │ │ │  6874223e3c7072653e3c7370616e3e3c2f7370616e3e3c7370616e20636c6173
> │ │ │ │ │  733d226770223e496e205b335d3a203c2f7370616e3e3c7370616e20636c6173
> │ │ │ │ │  733d226b6e223e696d706f72743c2f7370616e3e203c7370616e20636c617373
> │ │ │ │ │  3d226e6e223e74696d653c2f7370616e3e0a0a3c7370616e20636c6173733d22
> │ │ │ │ │  6770223e496e205b345d3a203c2f7370616e3e3c7370616e20636c6173733d22
> │ │ │ │ │  6f223e253c2f7370616e3e3c7370616e20636c6173733d226b223e74696d6569
> │ │ │ │ │  743c2f7370616e3e2074696d652e736c65657028302e3035290a3c7370616e20
> │ │ │ │ │ -636c6173733d22676f223e35302e31206d73202b2d20322e3331207573207065
> │ │ │ │ │ +636c6173733d22676f223e35302e31206d73202b2d20322e3135207573207065
> │ │ │ │ │  72206c6f6f7020286d65616e202b2d207374642e206465762e206f6620372072
> │ │ │ │ │  756e732c203130206c6f6f70732065616368293c2f7370616e3e0a3c2f707265
> │ │ │ │ │  3e3c2f6469763e0a3c2f6469763e0a3c703e546869732077696c6c20616c736f
> │ │ │ │ │  20737570706f727420746f702d6c6576656c206173796e63207768656e207573
> │ │ │ │ │  696e672049507974686f6e20372e302b3c2f703e0a3c64697620636c6173733d
> │ │ │ │ │  22686967686c696768742d69707974686f6e206e6f7472616e736c617465223e
> │ │ │ │ │  3c64697620636c6173733d22686967686c69676874223e3c7072653e3c737061
>
>
As far as I can see from the header this is a html file, correct me if I am
wrong. Did you try to look at the file as text?
It might give a more useful diff.


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#36685: ant-bootstrap fails on core-updates (409 dependents)

[Gábor Boskovits]

Ricardo Wurmus  ezt írta (időpont: 2019. szept. 6., Pén
15:40):

>
> Ricardo Wurmus  writes:
>
> >>> So, with the following change I was able to build all the way up to the
> >>> latest openjdk.  Should we use it despite the introduction of a memory
> >>> leak in a bootstrap JVM?  Can we make the patch smaller (fewer uses of
> >>> glibc 2.28 or gcc-5)?
> >>>
> >>> What do you think?
> >>>
> >>
> >> I will have a look at reducing the patch later today. I will report back
> >> tomorrow morning with the results.
> >
> > Did you have any luck with this?
>
> We should decide soon, because core-updates is about to be merged
> (finally!) – any objections to my earlier patch?
>

No objection from here.

>
> --
> Ricardo
>
g_bor

>

bug#37232: git pull warns of http redirection

[Gábor Boskovits]

Hello,

Bengt Richter  ezt írta (időpont: 2019. aug. 30., P, 9:54):

> Hi all,
>
> It seems to be working, but I like to
> eliminate warnings ;-)
>
> To reproduce, cd into your repo dir, then:
>
> $ git status
> On branch master
> Your branch is up to date with 'origin/master'.
>
> nothing to commit, working tree clean
> $ git config -l
> core.editor=emacs
> user.name=Bengt Richter
> user.email=b...@bokr.com
> core.repositoryformatversion=0
> core.filemode=true
> core.bare=false
> core.logallrefupdates=true
> remote.origin.url=http://git.sv.gnu.org/r/guix.git


This line says, that you confgiured remote is git.sv.gnu.org ...


>
> remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
> branch.master.remote=origin
> branch.master.merge=refs/heads/master
> $ git pull
> warning: redirecting to http://git.savannah.gnu.org/r/guix.git/
> Already up to date.
> $
>

And this is the current url:

git clone https://git.savannah.gnu.org/git/guix.git

from

https://savannah.gnu.org/git/?group=guix



>
> Is that http necessary for some load-balancing
> redirection, or could it be done with https?
>
>
So https is fine.

You can try:
git remote set-url origin

https://git.savannah.gnu.org/git/guix.git


--== (the rest of this is ignorable context, FWIW :) ==--
>
> I think I used the advice from guix 1.0.1 info
> to do the initial clone, i.e.,
> --advice
> 14.1 Building from Git
>
> If you want to hack Guix itself, it is recommended to use the latest
> version from the Git repository:
>
> git clone https://git.savannah.gnu.org/git/guix.git
> --advice--
> (though my purpose was not use it for building, but to have the latest
> and greatest to grep around in when trying to figure something out ;-)
>
> uname -a:
> Linux PhantoNv4ArchGx 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16
> 11:29:43 UTC 2019 x86_64 GNU/Linux
>
> guix describe:
> Generation 11   Aug 25 2019 20:58:43(current)
>   guix a707484
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: a707484d64e7e46f8cb8401c660fbb6eb77ab9c6
>
> (cd ~/wb/guix; git log|head):
> commit 43412ab967ee00789fe933f916d804aed9961c57
> Author: Tobias Geerinckx-Rice 
> Date:   Fri Aug 30 03:17:07 2019 +0200
>
> gnu: aqbanking: Update to 5.8.1.
>
> * gnu/packages/gnucash.scm (aqbanking): Update to 5.8.1.
> [source]: Remove FILE-NAME.
>
> commit 521bb336782b8fe04b57ebaadd55be005a85d788
>
> grep -m1 'model name' /proc/cpuinfo:
> model name  : Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
>
> --== (end of ignorable context, FWIW :) ==--
>
> Regards,
> Bengt Richter
>
> Best regards,
g_bor


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37207: guix.gnu.org Last Modified at epoch

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès  ezt írta (időpont: 2019. aug. 28., Sze,
22:32):

> Hello,
>
> Gábor Boskovits  skribis:
>
> > we should create a file with the git last modification time of the files,
> > updated when there is a new commit in the repo => last-modified
> > we should create a file with some hash of the files, updated when there
> is
> > a new commit in the repo => etag
> > we could restrict these operations to the files modified since the last
> > checkout.
> >
> > Retrieve these with embededd perl.
> > Wdyt?
>
> What would the config look like?  AFAICS our ‘nginx’ package doesn’t
> embed Perl, and I think it’s better this way.  :-)  Can we do that with
> pure nginx directives?
>
> We create /srv/guix.gnu.org (as a symlink) with the correct mtime¹.  If
> we can tell nginx to use it as the ‘Last-Modified’ date, that’s perfect.
>
>
I was thinking about this. Yes, we can solve that with pure nginx. There is
an issue however.
It invalidates all cached entries on update, so files not modified will
also need to be downloaded again.

The easiest way to do that would be to simply generate an nginx config
snippet at a configurable location,
setting up the mtime and etags variable, and include that from the main
config.

If this would be ok, then I will have a look at implementing this.

Ludo’.
>
> ¹
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n212
>

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37164: Generated installation image does not include grub.

[Gábor Boskovits]

Hello,

Danny Milosavljevic  ezt írta (időpont: 2019. aug.
29., Cs, 2:36):

> > Jesse Gibbons  skribis:
> >
> > > 1. generate the install image
> > >  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> > > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> > > system install) installation-os)'
>
> There's a typo there :)
>
> You wrote: iso9600
> It should be: iso9660
>
> But the error message could be vastly improved O_o
>

Wow, nice...

Yes, it is quite a hard to spot...

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37207: guix.gnu.org Last Modified at epoch

[Gábor Boskovits]

Hello Tobias,

Tobias Geerinckx-Rice via Bug reports for GNU Guix  ezt
írta (időpont: 2019. aug. 28., Sze, 16:38):

> Gábor, Ludo',
>
> Gábor Boskovits 写道：
> > Supressing the last modified header is just an
> > add_header Last-Modified "";
> > away.
>
> You'll also need:
>
> # Don't honour client If-Modified-Since constraints.
> if_modified_since off;
> # Nginx's etags are hashes of file timestamp & file length.
> etag off;
>
>
You really have a point here.

Based on my reseach, I came up with the following:

we need
etag off;

we should create a file with the git last modification time of the files,
updated when there is a new commit in the repo => last-modified
we should create a file with some hash of the files, updated when there is
a new commit in the repo => etag
we could restrict these operations to the files modified since the last
checkout.

Retrieve these with embededd perl.
Wdyt?


> Turning these off will of course prevent all caching.  I don't
> know if that would add measurable load to guix.gnu.org (it would
> be more problematic if we used a CDN, but it might still make a
> difference).
>
> Nix does something both interesting and icky — as always: patch[0]
> nginx to look up the realpath() instead, so clients can still
> cache using If-None-Match.
>
> Kind regards,
>
> T G-R
>
> [0]: https://github.com/NixOS/nixpkgs/pull/48337
>

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37207: guix.gnu.org Last Modified at epoch

[Gábor Boskovits]

Hello Danny,

Danny Milosavljevic  ezt írta (időpont: 2019. aug.
28., Sze, 17:05):

> Hi Gabor,
>
> On Wed, 28 Aug 2019 12:40:37 +0200
> Gábor Boskovits  wrote:
>
> > Supressing the last modified header is just an
> > add_header Last-Modified "";
> > away.
> >
> > To get the info from the symlink seems to be much trickier, i would do
> with
> > either embedded perl or embedded lua. I am not sure if we should bother
> > with it, though. Wdyt?
>
> Since we already emit ETag, I don't think we need to bother with
> Last-Modified.
>
> Why is the ETag so short, though?
>
>
The ETag we emit is also bad. Nginx calculates this from mtime and
content-lenght,
so in our case it's just content length.


> >wget --debug -O /dev/null   https://guix.gnu.org/packages.json 2>&1 |
> grep -i etag
> >ETag: "1-2f38b1"
>
>
Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37207: guix.gnu.org Last Modified at epoch

[Gábor Boskovits]

Hello,

Supressing the last modified header is just an
add_header Last-Modified "";
away.

To get the info from the symlink seems to be much trickier, i would do with
either embedded perl or embedded lua. I am not sure if we should bother
with it, though. Wdyt?

bug#37164: Generated installation image does not include grub.

[Gábor Boskovits]

Hello,

Jesse Gibbons  ezt írta (időpont: 2019. aug. 27.,
K, 4:48):

> On Mon, 2019-08-26 at 22:44 +0200, Gábor Boskovits wrote:
> > Hello,
> >
> > Jesse Gibbons  ezt írta (időpont: 2019. aug.
> > 23., P, 19:41):
> > > 1. generate the install image
> > >  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> > > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> > > system install) installation-os)'
> > >
> >
> > Just a wild guess, does it work with the verbosity option removed?
> > I had issues with that in the past.
> I tried generating an install image with --verbosity and another
> without --verbosity. There was no difference because guix does not
> expect the --verbosity option to make a difference.
>
> I deleted the link and ran the garbage collector, then tried building
> the image without --verbosity, but file does not detect grub. I think
> it isn't a problem with 'file' because a virtual machine setup with
> virt-manager does not think the ISO is bootable.
>

Is it possible that you are hit by this issue?
https://issues.guix.gnu.org/issue/36865
Could you try again after guix pull?

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37164: Generated installation image does not include grub.

[Gábor Boskovits]

Hello,

Jesse Gibbons  ezt írta (időpont: 2019. aug. 23.,
P, 19:41):

> 1. generate the install image
>  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> system install) installation-os)'
>
>
Just a wild guess, does it work with the verbosity option removed?
I had issues with that in the past.

2. examine the resulting iso
> readlink installation-os-x86_64.iso | xargs file
>
> output: /gnu/store/3xp541s4zrxass6h6rcwfz7bc33wv84p-disk-image: DOS/MBR
> boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-
> CHS (0xe3,198,58), startsector 2048, 3657239 sectors; partition 2 :
> ID=0xef, start-CHS (0xe3,198,59), end-CHS (0xe8,224,16), startsector
> 3659287, 81921 sectors
>
> 3. Compare this output with what file says about the official
> installation iso:
> wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.x86_64-linu
> x.iso.xz
> unxz guix-system-install-1.0.1.x86_64-linux.iso.xz
> readlink guix-system-install-1.0.1.x86_64-linux.iso
>
> output:guix-system-install-1.0.1.x86_64-linux.iso: DOS/MBR boot sector;
> GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2
> address 0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201;
> partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3f6,38,4),
> startsector 1, 2694403 sectors, extended partition table (last)
>
> It appears file discovered the GRand Unified Bootloader in the official
> iso but not in the generated iso.
>
> When I try to use the generated iso in virt-manager, it claims there
> are no bootable drives. I think this is because the generated iso has
> no GRUB.
>
> The manual says to specify the file gnu/system/install.scm instead of
> the value (@ (gnu system install) installation-os)) but ultimately they
> give guix the same value, so I think that wouldn't make a difference.
>
> removing --system=x86_64 does not trigger a full rebuild, so it looks
> like guix does not expect to build anything different.
>
> Guix describe outputs:
>
> Generation 47   Aug 23 2019 09:22:24(current)
>   guix d78bc23
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: d78bc23411b1351ff9495a511c22b27d17f9226f
>
> GUIX_PACKAGE_PATH="/home/jesse/Documents/broken-guix/Broken-Guix-
> Packages"
>
> Thanks
> -Jesse
>
>
>
>
Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#36685: ant-bootstrap fails on core-updates (409 dependents)

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2019. júl. 21., Vas
13:29):

> So, with the following change I was able to build all the way up to the
> latest openjdk.  Should we use it despite the introduction of a memory
> leak in a bootstrap JVM?  Can we make the patch smaller (fewer uses of
> glibc 2.28 or gcc-5)?
>
> What do you think?
>

I will have a look at reducing the patch later today. I will report back
tomorrow morning with the results.


>
> --
> Ricardo
>

bug#36685: ant-bootstrap fails on core-updates (409 dependents)

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2019. júl. 19., P,
8:09):

>
> Ricardo Wurmus  writes:
> > Here’s a shorter patch:
> >
> > --8<---cut here---start->8---
> > diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> > index 403c446a82..bd98784232 100644
> > --- a/gnu/packages/java.scm
> > +++ b/gnu/packages/java.scm
> > @@ -152,6 +152,13 @@ and binary format defined in The Java Virtual
> Machine Specification.")
> >   "--disable-gjdoc")
> > #:phases
> > (modify-phases %standard-phases
> > + (add-after 'unpack 'foo
> > +   (lambda _
> > + (substitute* "native/jni/java-io/java_io_VMFile.c"
> > +   (("result = cpio_isFileExists.*" m)
> > +(string-append m "
> > +//Without a long comment the Java side will return \"true\" on x86_64
> all the time.")))
> > + #t))
> >   (add-after 'install 'install-data
> > (lambda _ (invoke "make" "install-data"))
> >  (native-inputs
> > --8<---cut here---end--->8---
> >
> > This only adds a comment.  If the comment is too short it won’t work.
>
>
I confirm this path works.
I tested a modified version, where I took out the comment text. It also
works that way.
We might contact the classpath devs to get a proper fix, and maybe a new
release, they
were super responsive the last time.


> No, that’s wrong.
>
> To my eternal embarrassement but also great relief this substitution has
> the effect of commenting the *following* line which frees up previously
> claimed resources (a bunch of characters making up the file name).  The
> other comments I tested must have ended on \n, so they did not have this
> effect.
>
> Thanks to Julien for pointing this out!
>
> So!  Creating a memory leak lets us successfully build ant-bootstrap.
> It does not, however, get us all the way through the Java bootstrap.
> When configuring the first icedtea I get this error:
>
> --8<---cut here---start->8---
> checking if the VM and compiler work together... ./configure: line 9614:
>  697 Illegal instruction $JAVA -classpath . $BYTECODE 1>&5 2>&1
> configure: error: VM failed to run compiled class.
> command
> "/gnu/store/h9c5g3inn5zmkixk08m27zzpj58zbfgy-bash-minimal-5.0.7/bin/bash"
> "./configure"
> "CONFIG_SHELL=/gnu/store/h9c5g3inn5zmkixk08m27zzpj58zbfgy-bash-minimal-5.0.7/bin/bash"
> "SHELL=/gnu/store/h9c5g3inn5zmkixk08m27zzpj58zbfgy-bash-minimal-5.0.7/bin/bash"
> "--prefix=/gnu/store/802356lxpjkqk66kv35mdzxhvaw6rghp-icedtea-1.13.13"
> "--enable-fast-install"
> "--docdir=/gnu/store/d4c4w9bka2bnnrwrmph1ilgjss5i37h9-icedtea-1.13.13-doc/share/doc/icedtea"
> "--build=x86_64-unknown-linux-gnu" "--enable-bootstrap" "--enable-nss"
> "--without-rhino" "--with-parallel-jobs" "--disable-downloading"
> "--disable-tests"
> "--with-ecj=/gnu/store/6dijv9ynn5j2bya86dgjn8v0qfd1nv3j-ecj-bootstrap-3.2.2/share/java/ecj-bootstrap.jar"
> "--with-jar=/gnu/store/hw67b3w83cc2abbgrf0wqzra07iiz3a1-fastjar-0.98/bin/fastjar"
> "--with-jdk-home=/gnu/store/1agbz95p2ljcvbb88w7p7jn2hnd6z3gv-classpath-0.99-1.e7c13ee0c"
> "--with-java=/gnu/store/ril2kk63p1grib14vl88z3aladfs33gf-jamvm-2.0.0/bin/jamvm"
> failed with status 1
> --8<---cut here---end--->8---
>
> Illegal instruction?  This uses JamVM 2.0.0 as the JVM.  I’ll try to
> figure out what instruction this is and where it comes from.
>

I hit the same bug now.


> --
> Ricardo
>
>
>
Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#36685: ant-bootstrap fails on core-updates (409 dependents)

[Gábor Boskovits]

Hi,

Chris Marusich  ezt írta (időpont: 2019. júl. 16., Ke
8:59):

> Hi,
>
> At commit 464a29d3d74e7d2f27042db6ab166bfdbe1f992e ('git branch --all
> --contains 464a29d3d74e7d2f27042db6ab166bfdbe1f992e' tells me that only
> core-updates has this commit at this time), the following error occurs
> when trying to build ant-bootstrap, which causes the 409 dependent
> packages to fail, also:
>
> --8<---cut here---start->8---
> $ guix build -e '(@@ (gnu packages java) ant-bootstrap)'
> ...
> Issued 1 semantic warning compiling
> "src/main/org/apache/tools/ant/filters/FixCrLfFilter.java":
>
> <-
>665. case '\r':
>. . .
>684. }
> >
> *** Semantic Warning: This switch block can fall through to the next case.
> Did you forget a break statement?
>
> Issued 1 semantic warning compiling
> "src/main/org/apache/tools/ant/taskdefs/Zip.java":
>
>   1555. Vector resources = new Vector();
>^---^
> *** Semantic Warning: Local "resources" shadows a field of the same name
> in "org.apache.tools.ant.taskdefs.Zip".
>
> Issued 1 semantic warning compiling
> "src/main/org/apache/tools/ant/taskdefs/Get.java":
>
>633. URLConnection connection = aSource.openConnection();
>   ^^
> *** Semantic Warning: Local "connection" shadows a field of the same name
> in "org.apache.tools.ant.taskdefs.Get$GetThread".
>
> Issued 1 semantic warning compiling
> "src/main/org/apache/tools/ant/taskdefs/rmic/XNewRmic.java":
>
> 34. public static final String COMPILER_NAME = "xnew";
>^---^
> *** Semantic Warning: Field "COMPILER_NAME" shadows a field of the same
> name in "org.apache.tools.ant.taskdefs.rmic.ForkingSunRmic".
> ... Copying Required Files
> ... Building Ant Distribution
> Buildfile:
> /tmp/guix-build-ant-bootstrap-1.8.4.drv-0/apache-ant-1.8.4/build.xml
>
> BUILD FAILED
> Could not load the version information.
>
> Total time: 0 seconds
> ... Failed Building Ant Distribution !
> command "bash" "bootstrap.sh"
> "-Ddist.dir=/gnu/store/jd6jm79d0r5g59d0l2l3w445adykp5p9-ant-bootstrap-1.8.4"
> failed with status 1
> builder for
> `/gnu/store/76apf0hpcdabpjy0839nhkwgfrz3m8z5-ant-bootstrap-1.8.4.drv'
> failed with exit code 1
> build of
> /gnu/store/76apf0hpcdabpjy0839nhkwgfrz3m8z5-ant-bootstrap-1.8.4.drv failed
> View build log at
> '/var/log/guix/drvs/76/apf0hpcdabpjy0839nhkwgfrz3m8z5-ant-bootstrap-1.8.4.drv.bz2'.
> guix build: error: build of
> `/gnu/store/76apf0hpcdabpjy0839nhkwgfrz3m8z5-ant-bootstrap-1.8.4.drv' failed
> --8<---cut here---end--->8---
>
> It fails quite quickly, so you can easily get a copy failing locally if
> you want to test it out.
>
Thanks for the report.
I will have a look at this soon.

>
> --
> Chris
>
Best regards,
g_bor

>

bug#36589: Sway fails to launch

[Gábor Boskovits]

Hello martin,

martin  ezt írta (időpont: 2019. júl. 11., Cs, 4:28):

> After installing sway it fails to launch from the command line. The
> resulting error is
>
>
> XDG_RUNTIME_DIR is not set in the environment. Aborting.
>
>
This can be resolved either by setting XDG_RUNTIME_DIR, for example in
a shell startup file, or by using and elogind service in you configuration
on Guix
System.

I hope that helps.

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#35521: Mariadb test suite failures on x86_64-linux

[Gábor Boskovits]

Hello,

Arne Babenhauserheide  ezt írta (időpont: 2019. júl. 14.,
Vas 13:11):

> Hi Mark,
>
> Mark H Weaver  writes:
> > My log file contains the same error in the 'tokudb_bugs.mdev4533' test:
> >
> >   mysqltest: At line 6: query 'CREATE TABLE t1 (a INT(11), b CHAR(8))
> ENGINE=TokuDB' failed: 1005: Can't create table `test`.`t1` (errno: 28 "No
> space left on device")
>

Could you test using df -i if the file system is not running out of inodes?
That is another reason when the no space left on device error is reported.

>
> > After the build attempt, the failed build directory is ~3.4 GB, and I
> > still have ~7.4 GB.  That seems to imply that I had over 10 GB free
> > before starting the build, which sounds about right.  I don't have a
> > separate /tmp partition.
> …
> > I should mention that I'm using Btrfs.
>
> I use ext4, but I saw no space left on device errors when running guix
> lint. Since I had 700GiB free, that does not sound like real missing
> disk space, but rather that something else is wrong.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>
Best regards,
g_bor

>

bug#36333: Misleading hint for url-fetch

[Gábor Boskovits]

Hello,

Tobias Geerinckx-Rice  ezt írta (időpont: 2019. jún. 22.,
Szo, 20:24):

> Guix,
>
> I just encountered the following:
>
>
I've also seen that.

  foo.scm:4:2: error: url-fetch: unbound variable
>   hint: Did you forget `(use-modules (guix build download))'?
>
> Actually importing that module, instead of (guix download), will
> cause some other very hard-to-debug error that I can't remember
> but coincidentally helped someone fix on #guix the other day.
>
> Now I understand how they got to that bad place.
>
> Kind regards,
>
> T G-R
>

Best regards,
g_bor

bug#36264: shepherd doesn't capture service stdout/stderr

[Gábor Boskovits]

Hello guix,

Robert Vollmert  ezt írta (időpont: 2019. jún. 17., Hét
18:55):

> On a pretty fresh Guix System install, I see some regular
> sshd error messages on tty1 (which I guess means they’re
> written to /dev/console). Also, setting up a regular
> shepherd service via make-forkexec-constructor for a
> program that logs to stderr (postgrest which I’m in the
> process of packaging), all output goes to tty1.
>

This is also on my todo list for a while, so I can provide some additional
information. I noticed this on two services I was using:
ntp-service-type with default config and
prometheus-node-exporter-service-type with default config. I hope that
helps somewheat.


> Compare the discussion at
>
> https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00186.html


Best regards,
g_bor

>
>
>
>
>

bug#35996: User account password got locked when booting old generation

[Gábor Boskovits]

Hello,




pelzflorian (Florian Pelz)  ezt írta (időpont:
2019. jún. 3., Hét 8:04):

> After I booted to a Guix install USB, chrooted as described on the
> Arch wiki and started a Guix daemon, I could reconfigure as before.
> There was no need to fiddle with grub-install.
>
> After multiple reconfigures, it happened again, my /etc/shadow has !
> again in the password field.  My recently changed root password became
> empty as well, like 35902.  I did not even run sudo concurrently.  The
> password just got locked.
>
This is the same thing that happened to me, and there is another report,
regarding passwords being reset. I believe we should merge these two bugs.
I am on a mobile with no convinient way to look up the issue number.

>
> The /etc from the “populating from /gnu/store/*-etc” messages has no
> significant differences either.
>
>
>
> On Sat, Jun 01, 2019 at 11:37:51PM +0200, Ludovic Courtès wrote:
> > "pelzflorian (Florian Pelz)"  skribis:
> > > AccountsService appears to only be usable for reading /etc/shadow, not
> > > for writing it, contrary to what the Guix manual claims (??).
> >
> > That might be a bug.
> >
>
> AccountsService obviously can change passwords.  No bug here.  Sorry.
> I was confused.
>
>
> > > For writing passwords, gnome-control-center does not use
> > > AccountsService, it calls /usr/bin/passwd directly in its source code
> > > in panels/user-accounts/run-passwd.c.
> >
> > That’s definitely a bug to fix: it should invoke
> > /run/setuid-programs/passwd instead.
> >
>
> Find attached two patches that fix GNOME password changing.  Both are
> required.
>
> Regards,
> Florian
>

On my machine it turned out that the hdd is faulty, so this might be a
hardware error, I will get a replacement drive tomorrow, and check if the
problem still persist.

Best regards,
g_bor

>

bug#35902: Guix resets passwords on reconfigure

[Gábor Boskovits]

Hello,



Marius Bakke  ezt írta (időpont: 2019. máj. 26., Vas
9:39):

> Marlon  writes:
>
> > My user and root passwords have been reset about 3 times in 4 days upon
> running guix system reconfigure.
> >
> > I can't seem to recognize any pattern, it appears to occur randomly, and
> it requires setting passwords manually.
> >
> > The password is left blank, and could be a security issue, as anybody
> would be able to access the root account easily.
>
I have also noticed this once, but could not reproduce it since then. This
happened to me not too much after the 1.0.1 release, on a vm with 512 mb
ram. I later cleared up that machine, as it was too small. So in my case it
was either a sporadic thing, a specific commit from guix pull fixed later,
or a not obvious out of memory. Wdyt?

>
> This sounds really odd.  Can you share your system configuration?
>
> Do you manage users outside of the Guix configuration system by any
> chance?  Or can you reproduce it by simply invoking `guix system
> reconfigure` enough times?
>
Best regards,
g_bor

>

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

[Gábor Boskovits]

Hello Jesse,

Jesse Gibbons  ezt írta (időpont: 2019. máj. 8.,
Sze, 0:33):

> I brought this to the help mailing list, and now I see it as a
> particular bug in guix. When I change into a guix environment and try
> to run a Python project that uses the WebKitGTK2 library, it cannot
> find the specified shared library, even though it is in $LIBRARY_PATH.
> As a result, the project crashes. This does not happen when I call guix
> build. On a side note, guix build fails due to another error (possibly
> related).
>
> Thanks in advance for looking into this.
> -Jesse
>
>
> Package Definition:
> #!
> see https://github.com/jendrikseipp/rednotebook
> !#
> (define-module (custom packages rednotebook)
>   #:use-module (guix packages)
>   #:use-module (guix download)
>   #:use-module (guix build-system python)
>   #:use-module (guix licenses))
> (define-public rednotebook
>
>   (package
>(name "rednotebook")
>(version "2.11.1")
>(source
> (origin
>  (method url-fetch)
>  (uri (string-append
>"https://github.com/jendrikseipp/rednotebook/archive/v;
>version
>".tar.gz"))
>  (sha256
>   (base32
>"15n1ziypfj3lzpvhha7r637zrb259l9yrcsvkic9cg5mndiaivs3"
>(build-system python-build-system)
>(inputs
> `(("python" ,(@ (gnu packages python) python-3
>(propagated-inputs
> `(("python-pygobject"
>,(@ (gnu packages glib) python-pygobject))
>   ("gtk+" ,(@ (gnu packages gtk) gtk+))
>   ("gtksourceview"
>,(@ (gnu packages gtk) gtksourceview-3))
>   ("webkitgtk"
>,(@ (gnu packages webkit) webkitgtk-2.24))
>   ("python-pyyaml"
>,(@ (gnu packages python-xyz) python-pyyaml
>(home-page "https://www.rednotebook.app;)
>(synopsis #f)
>(description
> "RedNotebook is a modern desktop journal. It lets you format, tag and
> search your entries. You can also add pictures, links and customizable
> templates, spell check your notes, and export to plain text, HTML, Latex or
> PDF.")
>(license gpl2+))
>   )
>
>
> Program log (streams merged):
> Adding /home/jesse/Documents/rednotebook/rednotebook-2.11.1 to sys.path
> 2019-05-07 16:15:41,122 INFO Writing log to file
> "/home/jesse/.rednotebook/rednotebook.log"
> 2019-05-07 16:15:41,122 INFO System encoding: utf-8
> 2019-05-07 16:15:41,122 INFO Language code: None
> rednotebook/journal.py:161: PyGIDeprecationWarning: Since version 3.11,
> calling threads_init is no longer needed. See:
> https://wiki.gnome.org/PyGObject/Threading
>   GObject.threads_init()
> 2019-05-07 16:15:41,182 WARNING  For spell checking, please install
> enchant (python3-enchant).
>
> ** (journal.py:2179): WARNING **: 16:15:41.209: Failed to load shared
> library 'libwebkit2gtk-4.0.so.37' referenced by the typelib:
> libwebkit2gtk-4.0.so.37: cannot open shared object file: No such file or
> directory
>
> ** (journal.py:2179): WARNING **: 16:15:41.209: Failed to load shared
> library 'libjavascriptcoregtk-4.0.so.18' referenced by the typelib:
> libjavascriptcoregtk-4.0.so.18: cannot open shared object file: No such
> file or directory
> /gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py:226:
> Warning: cannot derive 'rednotebook+gui+browser+Browser' from non-derivable
> parent type 'void'
>   _gi.type_register(cls, namespace.get('__gtype_name__'))
> Traceback (most recent call last):
>   File "rednotebook/journal.py", line 168, in 
> from rednotebook.gui.main_window import MainWindow
>   File
> "/home/jesse/Documents/rednotebook/rednotebook-2.11.1/rednotebook/gui/main_window.py",
> line 45, in 
> from rednotebook.gui import browser
>   File
> "/home/jesse/Documents/rednotebook/rednotebook-2.11.1/rednotebook/gui/browser.py",
> line 41, in 
> class Browser(WebKit2.WebView):
>   File
> "/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py",
> line 235, in __init__
> super(GObjectMeta, cls).__init__(name, bases, dict_)
>   File
> "/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py",
> line 214, in __init__
> cls._type_register(cls.__dict__)
>   File
> "/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py",
> line 226, in _type_register
> _gi.type_register(cls, namespace.get('__gtype_name__'))
> RuntimeError: could not create new GType: rednotebook+gui+browser+Browser
> (subclass of void)
>
> So it seems that the guix environment  misses some environment variables.
Can you check if this is still the case, when you keep the build output
using guix build --keep-failed --check, and then guix environment
, and source the environment variables dropped at the kept build
directory?

If that helps, then can you send the two environments?

bug#35631: shepherd: dies on invalid code

[Gábor Boskovits]

Observed behaviour:
Shepherd dies on loading invalid code.

Expected behaviour:
Send an error message to the log and back to the herd, that the given
service could not be loaded. (Maybe a more detailed one, that helps in
debugging).
Continue operation without the offending service.

Steps to reproduce:
shepherd -s ~/shepherd.sock -c ok-service.scm &

and then

herd -s ~/shepherd.sock load root failing-service.scm

results in the following backtrace:
Backtrace:
  15 (primitive-load "/root/.guix-profile/bin/shepherd")
In shepherd.scm:
   270:10 14 (main . _)
58:17 13 (call-with-server-socket "/root/shepherd.sock" _)
   288:20 12 (_ #)
In ice-9/boot-9.scm:
829:9 11 (catch system-error # …)
In shepherd.scm:
325:9 10 (_)
In ice-9/boot-9.scm:
829:9  9 (catch quit # …)
In shepherd.scm:
   378:11  8 (_)
   380:50  7 (_ _ #)
In shepherd/service.scm:
   270:14  6 (condition->sexp #)
In srfi/srfi-1.scm:
   592:29  5 (map1 (#f "definition in expression context, where d…" …))
   592:29  4 (map1 ("definition in expression context, where defi…" …))
   592:17  3 (map1 (((line . 2) (column . 40) (filename . "fai…")) …))
   592:17  2 (map1 ((line . 2) (column . 40) (filename . "failing…")))
589:5  1 (map #< result->sexp (8)> (line . 2))
In unknown file:
   0 (scm-error wrong-type-arg "map" "Wrong type argument: …" …)

ERROR: In procedure scm-error:
In procedure map: Wrong type argument: (line . 2)
herd: premature end-of-file while talking to shepherd

and shepherd dies:
[1]+  Kilépett(1)shepherd -s ~/shepherd.sock -c ok-service.scm
at the end of ps ax output.

The only relevant line in the logs is:
May  8 13:35:46 localhost shepherd[365]: Loading failing-service.scm.

This causes serious problems when shepherd is running as pid1.

The content of the configuration files:
ok-service.scm:
(register-services (make 
 #:provides '(ok-service)
 #:start ((const #t
failing-service.scm:
(register-services (make 
 #:provides '(failing-service)
 #:start ((const #t)(define x 1

bug#35380: disk-image fails to install efi grub

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2019. máj. 1., Sze,
22:21):

> Hi rendaw,
>
> rendaw <7e9wc56emja...@s.rendaw.me> skribis:
>
> > On 4/25/19 5:44 PM, Ludovic Courtès wrote:
>
> [...]
>
> >> Exactly: currently QEMU is run with a plain old BIOS, and not with the
> >> UEFI firmware, so what you want is not implemented yet (see the comment
> >> in gnu/system/vm.scm:799).
> >>
> >> I’m closing this bug, but you can open a wishlist item about it if you
> >> want!
> >>
> >> Thanks,
> >> Ludo’.
> >
> > I'm not going to comment on the wishlist thing, but this seems like a
> > fairly huge problem:
> >
> > 1. The documentation doesn't mention this anywhere!  Not in the
> > bootloader docs, not in the disk-image docs, not in the "limitations",
> > not in "hardware considerations"
> >
> > 2. I've spent several _days_ now digging through Guix source code and
> > never found that message.
>
> I’m sorry to hear that.  I guess that the reason the documentation
> doesn’t mention it is that users didn’t find it all that important.
> My guess is that to many of us, using a VM is a way to test an OS, and
> it doesn’t matter in that context whether the emulated machine uses a PC
> BIOS or UEFI.
>
> I understand that it does matter in some cases, so I agree we should
> support it.  I don’t know exactly what it would take, but if you have
> ideas, they’d be welcome.
>
>
I've already looked into that earlier, and supporting this usecase would
not be
so hard. We have ovmf after all, and we could stat qemu in efi mode. It
would not
be so hard to get the thing in place to do an emergency efi booting setup.
Why I did not feel comfortable to carry on work in this direction, is that
we should
associate a state with the VM-s, namely the file contatining the nvram
variables of
the efi firmware. This is needed for full support, but not needed to create
a bootable
system. Wdyt?

We would also need an efi installation procedure, but this would also mean
that we
could create an efi install system test, which would be really nice indeed.

Also the parameters should be extended to be able to select if we would
like to generate
a bios or and efi image.

These are the thing from the top of my head, but it might well be that I am
missing something.

> 3. The build still completes with a successful exit code.  The only way
> > to find out the image doesn't have a bootloader (-> is unusable) is to
> > try to boot it
>
> Yes, that’s an unfortunate bug reported here:
> .
>
> Thanks,
> Ludo’.
>
>
>
> Best regards,
g_bor

bug#33639: ISO installer image is broken on i686

[Gábor Boskovits]

Hello people,

Thomas Schmitt  ezt írta (időpont: 2019. ápr. 15., H, 19:54):
>
> Hi,
>
> Florian Pelz wrote:
> > Well this is strange.  I got fine ISO images each time (fine with no
> > complaints from xorriso or fdisk and bootable in QEMU without errors),
> > but after dd’ing them to different USB flash drives each time I get
> > kernel output when inserting the flash drive:
> > [   10.025223] GPT:Primary header thinks Alt. header is not at the end of
> > the disk.
>
> The alternative/backup header is a property of GPT which makes it
> rather unsuitable for disk images. xorriso puts it correctly into the
> last 512-byte block of the image. But when copied to a storage device,
> it should move up to the last block of the device.
> Even worse, the main GPT header at 512-byte LBA 1 needs to learn the
> new address.
>

Yes, this is a really painful point.

Could we create a simple tool to write the disk images to a disk
correcting this problem?

Does not look too hard?

I am also forwarding this to guix devel. I removed the xorriso bug
list, as I feel this does not belong there.

Best regards,
g_bor

bug#34934: deeptools is not reproducible

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès  ezt írta (időpont: 2019. márc. 23., Szo, 18:01):
>
> Hi,
>
> Maxim Cournoyer  skribis:
>
> > │ │ │ │ ├── tree.cpython-37m-x86_64-linux-gnu.so
> > │ │ │ │ │ ├── 
> > /gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/readelf 
> > --wide --dynamic {}
> > │ │ │ │ │ │ @@ -2,15 +2,15 @@
> > │ │ │ │ │ │  Dynamic section at offset 0xcd90 contains 30 entries:
> > │ │ │ │ │ │TagType Name/Value
> > │ │ │ │ │ │   0x0001 (NEEDED) Shared library: 
> > [libz.so.1]
> > │ │ │ │ │ │   0x0001 (NEEDED) Shared library: 
> > [libpython3.7m.so.1.0]
> > │ │ │ │ │ │   0x0001 (NEEDED) Shared library: 
> > [libgcc_s.so.1]
> > │ │ │ │ │ │   0x0001 (NEEDED) Shared library: 
> > [libpthread.so.0]
> > │ │ │ │ │ │   0x0001 (NEEDED) Shared library: 
> > [libc.so.6]
> > │ │ │ │ │ │ - 0x001d (RUNPATH)Library runpath: 
> > [/gnu/store/9z98cvjm7p7z21xdid1ryydxy5vyz6wr-python-3.7.0/lib:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib:/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib:/gnu/store/nq4lsyipmfb0q7g26ra45rwwqrh3x8zw-zlib-1.2.11/lib:/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..]
> > │ │ │ │ │ │ + 0x001d (RUNPATH)Library runpath:
> > [/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/lib:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib:/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib:/gnu/store/nq4lsyipmfb0q7g26ra45rwwqrh3x8zw-zlib-1.2.11/lib:/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..]
>
> Hmmm, what’s the difference between these two RUNPATHs?
>

At first They looked ver similar to me, but the hash of the first
python-3.7.0 differs, right at the beginning. I could not dive deeper,
but maybe this can help you out.

> Ludo’.
>
>
>

Best regards,
g_bor