bug#46663: [Website] 404 redirection on a link in a blog article

[Bengt Richter]

Hi,

On +2021-02-24 18:58:38 +0100, pelzflorian (Florian Pelz) wrote:
> On Mon, Feb 22, 2021 at 08:20:43PM +0100, raingloom wrote:
> > Is there something that scans the website for broken links? Might be
> > worth setting up if not.
> 
> You made me check for other broken links using wget on a local build
> of the website.  Indeed there were some more broken links.  Thanks!
> 
> However I am too lazy to try to set up automatic and continuous broken
> link checking.  I think me and others should just be more careful when
> moving things around.
> 
> Regards,
> Florian
> 
> 
> 

I couldn't believe this is not a stardard tool for web site maintainers,
so i put
web broken link lister
to duckduckgo and got lots of hits. Well,  tl;dr -- having other concerns
at the moment, but at least I felt my hunch validated. I bet it gets
re-invented a lot :-p

-- 
Regards,
Bengt Richter

bug#27100: Unnecessary backtrace by guix/build/download.scm

[Danny Milosavljevic]

Hi,

>$ LC_ALL=C guix download https://192.168.10.1

>Starting download of /tmp/guix-file.Zfy7gX
>From https://192.168.10.1...
>X.509 server certificate for '192.168.10.1' does not match: 
>C=ZZ,ST=Somewhere,L=Unknown,O=libreCMC087d391f,CN=libreCMC
>failed to download "/tmp/guix-file.Zfy7gX" from "https://192.168.10.1;
>guix download: error: https://192.168.10.1: download failed

Nice!

Yes, it's much better now!  Thank you!


pgpEcAl5esT6S.pgp
Description: OpenPGP digital signature

bug#28510: crash: guix build -S foo --with-source=bla

[zimoun]

Hi,

On Tue, 19 Sep 2017 at 14:09, Ricardo Wurmus  
wrote:
> The command “guix build -S guile-git --with-source=guile-git” crashes
> instead of failing gracefully:
>
> rwurmus@bimsb-sys02 in code: git clone 
> https://gitlab.com/guile-git/guile-git.git

[...]

> rwurmus@bimsb-sys02 in code: guix build -S guile-git --with-source=guile-git
> Backtrace:

Still failing.  In ’compute-derivation’, this 

  (s
   (list (package-source-derivation store s)

returns a list of string instead of a derivation, so then

  (for-each show-derivation-outputs drv)

fails because it expects a derivation or a derivation-input (see in
(guix ui)).

Well, I am not sure where the error should be handled.  In (guix ui) and
in (guix scripts build)?  WDYT?


Cheers,
simon

bug#28240: bad backtrace on “guix archive -x”

[zimoun]

Hi Ricardo,


On Sat, 26 Aug 2017 at 14:23, Ricardo Wurmus  wrote:

> wget -q -O - 
> https://mirror.hydra.gnu.org/guix/nar/gzip/ykpfif2wzabhnn0a88sw3f96paa33k2z-r-minimal-3.4.0
>  | guix archive -x /tmp/hydra
> Backtrace:

This example is not relevant anymore.  Instead,

--8<---cut here---start->8---
wget -O - 
https://ci.guix.gnu.org/nar/gzip/bhdixzi1c7x4jyh93zx5aqgwzzw3i182-r-minimal-4.0.4
 | guix archive -x /tmp/ci
--8<---cut here---end--->8---

still returns the ugly backtrace with…

[...]

> ERROR: Throw to key `decoding-error' with args `("scm_from_utf8_stringn" 
> "input locale conversion error" 0 #vu8(2 3 236 189 11 116 92 213 149 32 122 
> 37 99 35 93 140 100 136 1 135 132 230 32 4 37 9 85 233 227 15 178 141 140 74 
> 82 217 85 65 150 148 146 100 96 97 35 223 170 186 85 186 168 126 169 91 165 
> 143 177 19 51 134 4 45 183 50 76 122 186 87 207 116 214 123 204 91 157 76 122 
> 77 86 154 158 204 155 16 186 131 237 5 193 73 175 204 132 204 234 78 210 157 
> 188 78 79 186 211 145 67 62 116 39 33 36 233 224 183 247 62 159 251 169 42 27 
> 99 32 153 181 82 96 221 123 207 103 159 115 246 217 103 239 125 246 217 231 
> 156 171 53 254 203 91 75 65 163 148 156 179 22 204 96 31 124 55 136 240 14 
> 241 188 66 60 203 203 69 19 159 205 226 59 101 149 204 100 185 80 90 22 223 
> 235 197 211 204 151 41 172 30 156 188 145 35 56 235 196 119 194 202 123 227 
> 11 41 138 127 187 234 33 227 227 254 248 215 89 143 43 197 119 201 204 84 178 
> 70 73 211 101 249 75 102 178 82 54 18 89 83 243 252 154 196 51 89 200 151 161 
> 142 246 31 183 243 239 91 111 233 201 228 43 61 54 52 197 236 153 191 179 183 
> 127 231 252 246 5 99 199 64 118 222 40 38 142 36 151 147 169 35 15 221 153 
> 219 158 120 40 177 45 49 16 76 24 246 92 112 91 104 91 168 175 191 7 48 216 
> 131 223 250 173 108 106 206 204 102 2
> …
> [pages upon pages of numbers]
> …

…pages of numbers.


Moreover, the lzip returns something more comprehensive.

--8<---cut here---start->8---
$ wget -O - https://ci.guix.gnu.org/nar/lzip/…-r-minimal-4.0.4 | guix archive 
-x /tmp/ci
--2021-02-25 01:02:04--  https://ci.guix.gnu.org/nar/lzip/…-r-minimal-4.0.4
Resolving ci.guix.gnu.org (ci.guix.gnu.org)... 141.80.181.40
Connecting to ci.guix.gnu.org (ci.guix.gnu.org)|141.80.181.40|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 24343298 (23M) [application/octet-stream]
Saving to: ‘STDOUT’

- 100%[=>]  23.21M  
 486KB/sin 56s 

2021-02-25 01:03:01 (424 KB/s) - written to stdout [24343298/24343298]

guix archive: error: corrupt input while restoring '/tmp/ci' from #
--8<---cut here---end--->8---


All the best,
simon

bug#46760: guix deploy doesn't seem to be authorizing the machine that is deploying to the remote

[pkill9]

I'm using the machine-ssh-configuration, I set `(authorize? #t)` which
the manual states should authorize the deploying machine onto the
remote host, but I get an error:
```
guix deploy: error: unauthorized public key: (public-key...
```

So I add to the OS definition:

```
 (guix-configuration
   (authorized-keys (append `(,(local-file
"/etc/guix/signing-key.pub")) %default-authorized-guix-keys

```

Which makes the error go away. I'm under the impression however that
the 'authorize? #t' field should be doing this without me needing to
add it to the OS configuration.

bug#27100: Unnecessary backtrace by guix/build/download.scm

[zimoun]

Hi,

On Wed, 18 Nov 2020 at 00:27, zimoun  wrote:
> On Sat, 27 May 2017 at 13:36, Danny Milosavljevic  
> wrote:
>> guix [env]$ ./pre-inst-env guix import pypi flex
>> Backtrace:
>
> [...] Ugly 
>
>> guix/build/download.scm:417:6: In procedure tls-wrap:
>> guix/build/download.scm:417:6: X.509 certificate of 'pypi.python.org' could 
>> not be verified:
>>   signer-not-found
>>   invalid
>>
>> Also, the most interesting information, which is which certificates it DID 
>> know and where it got them, is not printed.
>
> Well, the bug #27100 [1] is solved now, I guess.  First, the command
>
>   $ guix import pypi flex
>
> works now.  And the command:
>
>   $ guix import pypi kikoo
>   following redirection to `https://pypi.org/pypi/kikoo/json/'...
>   guix import: error: failed to download meta-data for package 'kikoo'
>
> fails gracefully.  What remains is “guix import pypi kikoo -r” but it is
> tracked by #44115 about the recursive option of all the importers.

I think this bug is now addressed and could be closed.  WDYT?


All the best,
simon

bug#46624: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SEC

[zimoun]

Hi Tobias,

On Thu, 18 Feb 2021 at 23:02, Tobias Geerinckx-Rice via Bug reports for GNU 
Guix  wrote:

> More specifically, it's likely an input cycle (infinite loop of A 
> needs B needs ... needs A).  Guix doesn't [yet] detect these, and 
> takes them literally until memory is exhausted.

Where should this feature go?  Under “guix lint” via another checker or
“guix build” walking the graph to detect cycles before really building?


Cheers,
simon

bug#46669: Godot fails to start

[Leo Famulari]

On Wed, Feb 24, 2021 at 06:47:59PM +0100, Maxime Devos wrote:
> On Wed, 2021-02-24 at 12:03 -0500, Leo Famulari wrote:
> > [...]
> > 
> > It's reserved for security updates, and other very serious problems. An
> > incompatibility with a single package — especially something
> > non-critical like a game engine — does not qualify.
> > 
> > [...]
> 
> Thank you for your response!  This makes Guix a little clearer to me.

To elaborate some more... the problem is that the version of Godot we
package is not compatible with the version of libx11 we package, right?

If that's so, it's basically a normal situation. There are lots of
packages for which we must delay updates until the rest of the distro
can support them.

bug#46580: vim-full fails to build

[zimoun]

Hi,

On Wed, 24 Feb 2021 at 19:02, Alexandru-Sergiu Marton
 wrote:

> Just pulled the latest Guix and this error still happens. I
> attached the build log.

See .

All the best,
simon

PS:
46639 and 46642 and incorrectly merged.
I have tried to unmerge them in order to merge 46642 with this one 46580.

bug#46757: Guix deploy doesn't seem to be respecting (build-locally? #f)

[pkill9]

With (build-locally? #f) set, it should build on the remote, but it
starts building guix on the local machine. Maybe it should be doing
that? I'm not sure.

bug#46580: vim-full fails to build

[Alexandru-Sergiu Marton]

Hi,

Just pulled the latest Guix and this error still happens. I 
attached the build log.


Cheers,
Alexandru-Sergiu Marton



vim-full-build-log.drv.bz2
Description: Vim build log.

bug#46756: guix deploy not copying remote-gexp.scm

[pkill9]

I keep getting this error:

```
(system-error "open-file" "~A: ~S" ("No such file or directory"
"/gnu/store/p3ahdfcwa5yd65l5nzsnzshw9s7x3xc7-remote-exp.scm") (2))
```

when I try to run `guix deploy`. This is on the remote machine. I can
get it to work by using `guix copy` to copy that file from my local
machine to the remote, but i don't know why it isn't copying it over
automatically.

bug#46663: [Website] 404 redirection on a link in a blog article

[pelzflorian (Florian Pelz)]

On Mon, Feb 22, 2021 at 08:20:43PM +0100, raingloom wrote:
> Is there something that scans the website for broken links? Might be
> worth setting up if not.

You made me check for other broken links using wget on a local build
of the website.  Indeed there were some more broken links.  Thanks!

However I am too lazy to try to set up automatic and continuous broken
link checking.  I think me and others should just be more careful when
moving things around.

Regards,
Florian

bug#46555: LVM swap continuously fails guix system: error: service 'swap-/dev/mapper/guix-swap' requires 'device-mapping-guix-swap', which is not provided by any service

[Shyam Saran]

Thanks for response, I am attaching config.scm

If required then will try to make this file cleaner.



On Mon, 22 Feb 2021 at 14:50, Ludovic Courtès  wrote:

> Hi Shyam,
>
> Shyam Saran  skribis:
>
> > LVM/Device Mapper swap continuously fails for os configuration
> >
> >
> > with
> >
> >   guix system: error: service 'swap-/dev/mapper/guix-swap' requires
> > 'device-mapping-guix-swap', which is not provided by any service
> >
> >
> >
> > which originates from code
> >
> >
> >
> > (define swap-service-type
> >   (shepherd-service-type
> >'swap
> >(lambda (device)
> >  (define requirement
> >(if (and (string? device)
> > (string-prefix? "/dev/mapper/" device))
> >(list (symbol-append 'device-mapping-
> > (string->symbol (basename device
> >'()))
>
> You could need to define an LVM “device mapping” that provides
> /dev/mapper/guix-swap:
>
>
> https://guix.gnu.org/manual/devel/en/html_node/Mapped-Devices.html#index-lvm_002ddevice_002dmapping
>
> If you did already, could you send your complete config so we can have a
> look?
>
> Thanks,
> Ludo’.
>


/shyam
;; This is an operating system configuration generated

(use-modules (guix utils))
(use-modules (guix packages))
(use-modules (gnu services networking))
(use-modules (gnu services audio))
(use-modules (gnu) (gnu system nss))
(use-service-modules networking ssh)
(use-package-modules bootloaders certs suckless wm)

(use-service-modules desktop networking cups ssh xorg avahi mail)
(use-package-modules certs gnome cups)

(use-modules (gnu packages shells))
(use-modules (gnu packages vim))

(use-modules (gnu))
(use-package-modules screen)

;; other guix

(use-modules (gnu system locale))
(use-modules (guix store))
(use-modules (rnrs lists))
(use-modules (srfi srfi-1))
(use-package-modules base idutils)
(use-service-modules dns mcron messaging)



(define (open-udev-lvm-device source target)
  "Return a gexp that maps SOURCES to TARGETS as a LVM device, using
'lvm'."
  (with-imported-modules (source-module-closure '((gnu build file-systems)))
 #~(let ((source  #$source)
 (lvm-bin #$(file-append lvm2-static "/sbin/lvm")))
 ;; Use 'lvm2-static', not 'lvm2', to avoid pulling the
 ;; whole world inside the initrd (for when we're in an initrd).
 (begin
   (format #t "Enabling ~a~%" #$target)
   (system* lvm-bin "vgchange" "-ay" (car (string-split #$target #\-)))
   (sleep 1)
   (zero? (system* lvm-bin "lvchange" "-aay" "-y" "--sysinit" "--ignoreskippedcluster"
   (string-join (string-split #$target #\-) "/")))

(define (close-udev-lvm-device sources target)
  "Return a gexp that closes TARGET, a LVM device."
  #~(zero? (system* #$(file-append lvm2-static "/sbin/lvm")
"lvchange" "-an" "-y" (string-join (string-split #$target #\-) "/"
;; The type of LVM mapped devices.
(define udev-lvm-device-mapping (mapped-device-kind (open open-udev-lvm-device)
;; (check check-udev-lvm-device)
(close close-udev-lvm-device)))


(define %local-fs-boot-efi-partition "/dev/sda1")

(define %local-grub-ubuntu-menuentries (list (menu-entry (label "Ubuntu GNU/Linux")
 (linux "(lvm/tf1e5mXubuntu-boot)/vmlinuz")
 (linux-arguments '("root=/dev/mapper/tf1e5mXubuntu-root ro --verbose nosplash debug"))
 (initrd "(lvm/tf1e5mXubuntu-boot)/initrd.img"


(define %localmachine-host-name "komputilo")
(define %localmachine-account-uid   1000)
(define %localmachine-account-user-name "s")
(define %localmachine-account-comment   "shyam")
(define %localmachine-account-group-name"users")
(define %localmachine-account-group-gid  1000)
(define %localmachine-account-supplementry-groups   '("wheel" "netdev" "audio" "video"))
(define %localmachine-account-home-parent-directory "/home")
(define %localmachine-account-shell #~(string-append #$zsh "/bin/zsh"))
(define %localmachine-gdm-auto-login#f)
(define %localmachine-gdm-allow-empty-password  #t)

(define %localmachine-account-create-home-directory #f)
(define %localmachine-guix-substitute-urls  '("https://ci.guix.gnu.org;
  "https://bayfront.guixsd.org;
  "http://guix.genenetwork.org;
  

bug#46669: Godot fails to start

[Maxime Devos]

On Wed, 2021-02-24 at 12:03 -0500, Leo Famulari wrote:
> [...]
> 
> It's reserved for security updates, and other very serious problems. An
> incompatibility with a single package — especially something
> non-critical like a game engine — does not qualify.
> 
> [...]

Thank you for your response!  This makes Guix a little clearer to me.


signature.asc
Description: This is a digitally signed message part

bug#46642: vim-full broken

[zimoun]

Hi,

Thanks for the report.

On Fri, 19 Feb 2021 at 20:02, Softwafe Engineer  wrote:

> Hello. vim-full package is broken.

I suspect the commit: 988ac06ce8cf9b1760094e0e2ff23960355d07eb.

--8<---cut here---start->8---
gnu: vim: Fix test_signals test.

* gnu/packages/vim.scm (vim)[arguments]: Add "CFLAGS=-D_REENTRANT" to

Signed-off-by: 宋文武 
--8<---cut here---end--->8---

It is between 4767ab4b (bad) and e429325d (good).




All the best,
simon

bug#46669: Godot fails to start

[Leo Famulari]

On Sun, Feb 21, 2021 at 10:05:53AM +0100, Maxime Devos wrote:
> Is there any reason the ("libx11" ,libx11) cannot simply be replaced with
> ("libx11" ,libx11-fixed) in the package inputs for godot, where libx11 is
> the updated libx11?  Or alternatively, could the ‘grafts’ mechanism be used?
> Or is that reserved for security updates?

It's reserved for security updates, and other very serious problems. An
incompatibility with a single package — especially something
non-critical like a game engine — does not qualify.

One reason to limit the use of grafts is that they can mask other
compatibility problems. For example, we grafted FreeType in October
2020. In December, we "ungrafted" it, and this revealed that the new
grafted version of FreeType had never worked with our VTK package. But,
since we were still compiling VTK with the old FreeType, and then
patching the compiled VTK objects to refer to the new FreeType, the
problem was hidden for several months:

https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00292.html


signature.asc
Description: PGP signature

bug#46650: Extending package transformation options

[Ludovic Courtès]

Hi,

zimoun  skribis:

> I am confused.  The 'specification->package' returns a regular
> package, right?.  And then,
>
>   (define gnutls
> (specification->package "gnutls"))
>
>   (define dependencies
> (append-map transitive-package-dependencies
> (list guile-gcrypt gnutls guile-git guile-avahi
>   guile-json guile-semver guile-ssh guile-sqlite3
>   guile-zlib guile-lzlib guile-zstd)))
>
> So here, a transformation could be applied.  For example, build all
> the dependencies without testing them;  at the 'define gnutls' ()
> step or in the map.  Why not?

Sure, but how do you get a user-specified transformation to this line?

Ludo’.

bug#46650: Extending package transformation options

[zimoun]

Hi Ludo,

On Wed, 24 Feb 2021 at 12:11, Ludovic Courtès  wrote:
> > On Sat, 20 Feb 2021 at 14:57, Ludovic Courtès  wrote:
> >
> >> Guix as returned by ‘guix pull’ and ‘guix time-machine’ depends on
> >> GnuTLS.  So here, we have a special case: to build Guix itself, you need
> >> to build GnuTLS first, and there’s no way to pass ‘--without-tests’ at
> >> that level.
> >>
> >> I’m not sure how to change that because unfortunately, ‘guix pull’ and
> >> ‘time-machine’ don’t even know that Guix depends on GnuTLS; only the
> >> target Guix knows about this.  :-/
> >
> > If  «“guix pull” and ’time-machine’ don’t even know that Guix depends on
> > GnuTLS» and «to build Guix itself, you need to build GnuTLS first», how
> > does it work?  How does «you» know that they needs to build GnuTLS
> > first?
>
> ‘guix pull’ builds Guix using the method implemented in (guix self).
> The entry point there is ‘compiled-guix’, which returns a compiled Guix.

Thanks.  It perfectly answer to my question. :-)

> It’s not a package so the package API doesn’t apply.

I am confused.  The 'specification->package' returns a regular
package, right?.  And then,

--8<---cut here---start->8---
  (define gnutls
(specification->package "gnutls"))

  (define dependencies
(append-map transitive-package-dependencies
(list guile-gcrypt gnutls guile-git guile-avahi
  guile-json guile-semver guile-ssh guile-sqlite3
  guile-zlib guile-lzlib guile-zstd)))
--8<---cut here---end--->8---

So here, a transformation could be applied.  For example, build all
the dependencies without testing them;  at the 'define gnutls' ()
step or in the map.  Why not?

Well, just to be able to travel back in time if some expiration changed.


Cheers,
simon

bug#46650: Extending package transformation options

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sat, 20 Feb 2021 at 14:57, Ludovic Courtès  wrote:
>
>> Guix as returned by ‘guix pull’ and ‘guix time-machine’ depends on
>> GnuTLS.  So here, we have a special case: to build Guix itself, you need
>> to build GnuTLS first, and there’s no way to pass ‘--without-tests’ at
>> that level.
>>
>> I’m not sure how to change that because unfortunately, ‘guix pull’ and
>> ‘time-machine’ don’t even know that Guix depends on GnuTLS; only the
>> target Guix knows about this.  :-/
>
> If  «“guix pull” and ’time-machine’ don’t even know that Guix depends on
> GnuTLS» and «to build Guix itself, you need to build GnuTLS first», how
> does it work?  How does «you» know that they needs to build GnuTLS
> first?

‘guix pull’ builds Guix using the method implemented in (guix self).
The entry point there is ‘compiled-guix’, which returns a compiled Guix.

It’s not a package so the package API doesn’t apply.

HTH,
Ludo’.

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Mathieu Othacehe]

Hey,

> The bug here is likely due to 32-bit signed integer wrapping.  That can
> only happen in C code, so to me possible culprits would be
> guile-simple-zmq or the layer above it (if there’s a binary protocol
> involved) or the postgresql interface.  Only a vague intuition, though.

Hmm, looks like you're right! There's a memory corruption in the
remote-server process that's really hard to reproduce. I suspect the ZMQ
library or its Guile bindings.

I'm trying to valgrind the process to identify the issue, without much
success for now.

Thanks,

Mathieu