bug#22619: postgresql-service error checking wtf

[Glenn Morris]

Danny Milosavljevic wrote:

> Package: postgresql

There's no postgresql package on debbugs.gnu.org, so your report
went to the help-debbugs mailing list.

>From the rest of your report, I'm guessing this should have been
assigned to guix, so I did that.

> When I first configure operating-system with postgresql-service with
> default config file, then run
>
> guix system reconfigure config.scm,
>
> then configure operating-system with postgresql-service with custom
> config file, then run
>
> guix system reconfigure config.scm,
>
> I get:
>
> ---
> initdb: directory "/var/lib/postgresql/data" exists but is not empty
> If you want to create a new database system, either remove or empty
> the directory "/var/lib/postgresql/data" or run initdb
> with an argument other than "/var/lib/postgresql/data".
> making '/gnu/store/byn534fg4agm0vv9szl5kkfl19n080b2-system' the
> current system...
> Installation finished. No error reported.
> 
>
> Postgresql doesn't run and the error message still references the
> default config file.

bug#25020: guix refresh does not discover updates if URLs are "non-standard"

[Glenn Morris]

This was sent to submit@debbugs with no Package: specified and so ended
up on the help-debbugs list. I have reassigned it to guix.

Hartmut Goebel wrote:

> Hi,
>
> I just updated kde-frameworks to 5.28 and found that not all updates
> have been discovered.
>
> Those where the URL is following the standard schema where found:
> "mirror://kde/stable/frameworks/" (version-major+minor version) "/" name
> "-" version ".tar.xz"))
>
> Those having a different name of the archive or having an additional
> directory behind the first version-part have not been found.
>
> Update found for:
>
> (name "extra-cmake-modules")
> (version "5.27.0")
> (source (origin
>   (method url-fetch)
>   (uri (string-append
> "mirror://kde/stable/frameworks/"
> (version-major+minor version) "/"
> name "-" version ".tar.xz"))
>
> Update not found for (archive-name has "5" appended):
>
> (name "oxygen-icons")
> (version "5.27.0")
> (source (origin
>   (method url-fetch)
>   (uri (string-append
> "mirror://kde/stable/frameworks/"
> (version-major+minor version) "/"
> name "5" "-" version ".tar.xz"))
>
> Update not found for (additional directory level):
>
> (name "kross")
> (version "5.27.0")
> (source
>  (origin
>(method url-fetch)
>(uri (string-append
>  "mirror://kde/stable/frameworks/"
>  (version-major+minor version) "/portingAids/"
>  name "-" version ".tar.xz"))

bug#25969: guix-patches debbugs appears to mangle patches

[Glenn Morris]

Ludovic Courtès wrote:

> Hello!
>
> Leo Famulari  skribis:
>
>> The guix-patches debbugs thing causes a regression in this workflow by
>> rewriting the commit messages to include the debbugs ticket number.
>>
>> So, a commit that begins with this:
>>
>> gnu: gitolite: Fix shebangs in hooks.
>>
>> ... becomes this:
>>
>> bug#25966: [PATCH 2/2] gnu: gitolite: Fix shebangs in hooks.
>>
>> Am I missing something, or is debbugs really rewriting the patches?
>
> Good question.  Maybe Glenn and others at help-debbugs have an idea?

I think it's over the top to describe this as "mangling" or "rewriting"
patches. The system relies on adding a bug number to the subject, so
that replies to the maintainer address can be associated with the right
bug. I don't see any prospect of this changing. If you are using a tool
that is sensitive to the subject line in emails, I can only suggest
using eg a trivial sed command to take out the bug number before passing
the mail to your tool.

bug#28232: openvpn service configuration fails by default

[Glenn Morris]

Reassigned from non-existent "openvpn" package to guix.

charly bion wrote:

> Package: openvpn 
> Version: 2.4.3 
>
> Backtrace: 
> In srfi/srfi-1.scm: 
> 592:29 19 (map1 (#< type: # ?)) 
> 592:29 18 (map1 (#< type: # ?)) 
> 592:29 17 (map1 (#< type: # ?)) 
> 592:29 16 (map1 (#< type: # ?)) 
> 592:29 15 (map1 (#< type: # ?)) 
> 592:29 14 (map1 (#< type: # ?)) 
> 592:29 13 (map1 (#< type: # ?)) 
> 592:29 12 (map1 (#< type: # ?)) 
> 592:29 11 (map1 (#< type: # ?)) 
> 592:29 10 (map1 (#< type: # ?)) 
> 592:29 9 (map1 (#< type: # ?)) 
> 592:29 8 (map1 (#< type: # ?)) 
> 592:17 7 (map1 (#< type: # ?)) 
> In gnu/services/vpn.scm: 
> 409:24 6 (_ #< openvpn: #) 
> 379:9 5 (openvpn-config-file client #<) 
> In ice-9/ports.scm: 
> 549:4 4 (call-with-output-string _) 
> 473:4 3 (with-output-to-port _ _) 
> In ice-9/boot-9.scm: 
> 268:13 2 (for-each # ?) 
> In gnu/services/vpn.scm: 
> 112:19 1 (serialize-tls-auth client #f) 
> In unknown file: 
> 0 (string-append #f " " "1") 
>
> ERROR: In procedure string-append: 
> ERROR: In procedure string-append: Wrong type (expecting string): #f 
>
>
>
> To have this error, I tried do build a vm-image using the openvpn service: 
> (service openvpn-client-service-type 
> (openvpn-client-configuration 
> (proto 'tcp) 
> (ca "ca.crt") 
> (cert "client.crt") 
> (key "client.key") 
> )) 
>
>
> Guix doesn't want to build the VM, because of the openvpn service. The
> problem is in the function serialize-tls-auth (line 110 of the file
> /gnu/services/vpn.scm). The function tries to concatenate a string
> with the input of the "tls_auth" field in
> openvpn_client_configuration. But by default this input's value is #f.
> Test function are implemented just after this one, but not used.
>
> As I don't know what the function is supposed to return, I can't correct 
> this. 
>
> I'm using Guix 0.13.0 

bug#31170: Package: nix build failed

[Glenn Morris]

[The "Package:" at the start of the body confused debbugs.
Report reassinged to "guix" from non-existent packages "nix", "build",
"failed".]

> Package: nix build failed
>
> starting phase `build'
>   GEN    Makefile.config
>   CXX    src/nix-hash/nix-hash.o
>   CXX    src/libmain/shared.o
>   CXX    src/libmain/stack.o
>   CXX    src/libstore/build.o
>   CXX    src/libstore/builtins.o
>   CXX    src/libstore/derivations.o
>   CXX    src/libstore/download.o
>   CXX    src/libstore/gc.o
> src/libmain/stack.cc: In function 'void nix::sigsegvHandler(int,
> siginfo_t*, void*)':
> src/libmain/stack.cc:23:21: error: 'ucontext' was not declared in this scope
>  sp = (char *) ((ucontext *) ctx)->uc_mcontext.gregs[REG_RSP];
>  ^
> src/libmain/stack.cc:23:31: error: expected primary-expression before ')' 
> token
>  sp = (char *) ((ucontext *) ctx)->uc_mcontext.gregs[REG_RSP];
>    ^
> src/libmain/stack.cc:23:33: error: expected ')' before 'ctx'
>  sp = (char *) ((ucontext *) ctx)->uc_mcontext.gregs[REG_RSP];
>  ^
> At global scope:
> cc1plus: warning: unrecognized command line option
> -Wno-unneeded-internal-declaration'
> make: *** [mk/patterns.mk:3: src/libmain/stack.o] Error 1
> make: *** Waiting for unfinished jobs
> phase `build' failed after 11.2 seconds
> builder for
> /gnu/store/wqzgh59kpkgix8w673h6r07r8n5i2mnk-nix-1.11.9.drv' failed
> with exit code 1
> guix package: error: build failed: build of
> /gnu/store/wqzgh59kpkgix8w673h6r07r8n5i2mnk-nix-1.11.9.drv' failed

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Glenn Morris]

Mark H Weaver wrote:

> (1) This bug is not listed on , although
>  shows it as an open bug for Guix.

There was a problem with the pagination. It's (now) on page 2.

> (2) The original bug report was never delivered to me, although I'm
> subscribed to .  If Eric hadn't CC'd me on his
> original submission, I might not have seen it. 

I would guess that you are subscribed to bug-guix with the "filter out
duplicates" Mailman option, so it is precisely because you were cc'd
that you did not get the mailing list copy (with the bug number).

> I was unable to find out the bug number until I asked Eric directly,
> so unfortunately the commit does not reference the bug number.

(You could have searched for the bug by subject?)

If Eric had used X-Debbugs-CC instead of Cc in the initial report, the
mail you got would have included the bug number in the subject.
I believe this is well documented (eg on the "how to report a bug"
section on https://debbugs.gnu.org/).

> I've reported these problems to the FSF sysadmins, and I'd like to give
> them an opportunity to diagnose the problem before we change the status
> of this bug.

The FSF sysadmins don't maintain debbugs.gnu.org, so the help-debbugs
list would have been better. I (debbugs.gnu.org maintainer) happened to
see your mail although I don't normally read bug-guix.

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Glenn Morris]

Mark H Weaver wrote:

> I feel embarrassed for not noticing that there were multiple pages. I
> rarely use the web interface, and I guess the projects I've worked
> tend to have fewer than 400 active bugs.

No need to feel embarrassed. :)
The results pages feature was broken for projects with 400-500 bugs,
such that bugs over 400 weren't being shown, so there was no second guix
page till I fixed it. Thanks for bringing this to light! :)