bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Hello guix, Trying to run 'guix build --target=x86_64-w64-mingw32 perl' results in the following exception in the latest stages of the build: phase `install' succeeded after 36.7 seconds starting phase `remove-extra-references' Backtrace: 13 (primitive-load "/gnu/store/qnavzfxvw5rng7z8rzlx9zw0ji9…") In ice-9/eval.scm: 191:35 12 (_ _) In srfi/srfi-1.scm: 863:16 11 (every1 # …) In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm: 799:28 10 (_ _) In ice-9/eval.scm: 619:8 9 (_ #(#(#(#(#(#(#) …) …) …) …) …)) In ice-9/boot-9.scm: 841:4 8 (with-throw-handler _ _ _) In ice-9/ports.scm: 444:17 7 (call-with-input-file _ _ #:binary _ #:encoding _ # _) In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm: 641:26 6 (_ _) 667:26 5 (_ # …) In srfi/srfi-1.scm: 466:18 4 (fold # …) In ice-9/eval.scm: 202:51 3 (_ #(#(#(#(#(#(# …)) …) …) …) …)) 163:9 2 (_ #(#(#(#(#(#(# …)) …) …) …) …)) In unknown file: 1 (string-append "incpth='" #f "/include'\n") In ice-9/boot-9.scm: 752:25 0 (dispatch-exception _ _ _) ice-9/boot-9.scm:752:25: In procedure dispatch-exception: In procedure string-append: Wrong type (expecting string): #f builder for `/gnu/store/2khcqc5rpc0wizhihpq69x6qn3f7nw5l-perl-5.28.0.drv' failed with exit code 1 I have the full log. Do you wish to see it? Did I do something wrong? Is it the same for you? Is there a workaround? Best regards, Vivien
bug#37388: can lead to syntactically invalid configs
Ludovic Courtès writes: >> I wonder if some errors could be caught at build time, before attempting >> to start the service. >> >> If in the derivation to build the configuration file, nginx is run >> against the built config file with -t, that might spot errors at >> derivation build time. > > Yeah, this is probably doable. > > I would consider it a stop-gap measure though. Fundamentally, I think > we should make it so that, by construction, invalid (or at least > syntactically-invalid) config files cannot be produced. Catching errors earlier is better, but being able to catch any syntactic issues that have snuck through, as well as semantic ones when building the configuration would be good I think. I haven't actually tested out the NGinx configuration check functionality though, so I'm guessing about what it does. signature.asc Description: PGP signature
bug#37388: can lead to syntactically invalid configs
Hi Gábor, Gábor Boskovits skribis: > 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? I think it would deserve a separate issue, but I agree that extension of is tricky due to ordering. Thanks for your feedback, Ludo’.
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Looking at the source code of phase "remove-extra-references" and assuming that the "out" output exists, probably the "libc" input doesn't exist. set-cross-path/mingw guards against this case, so apparently it is normal that "libc" input can be missing and perl should be guarding against it, but doesn't. Otherwise I don't know mingw, so can't help much further. pgp7L7_kX2xtC.pgp Description: OpenPGP digital signature
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Further information: According to gnu/packages/cross-base.scm, cross-gcc contains either "libc" or "mingw-source" in the mingw case--I don't know why, but that's what it says. The purpose of "remove-extra-references" seems to be to shrink the number of recorded dependencies, so maybe compare it with the unshrinked list of dependencies by printing the latter out (apparently it should be inside Config_heavy.pl and Config.pm in the temporary build directory--could you post those?). I tried it myself (with mingw target) and I got: loclibpth='/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib' Hmm. Also, perl seems to fetch libc from the %build-inputs just fine earlier. So try putting (assoc-ref native-inputs "libc") instead of (assoc-ref inputs "libc") in the perl package definition (make sure to accept native-inputs in the function in the first place) in order to debug the problem (or maybe (assoc-ref inputs "mingw-source")). When cross compiling it's important to get right which parts you get from the host libs and which from the target libs, maybe that's messed up there. Also possible would be not to do that shrinking if libc is unavailable, but not sure whether we want that. pgpPClSD86cWZ.pgp Description: OpenPGP digital signature
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
‐‐‐ Original Message ‐‐‐ On Saturday, September 14, 2019 7:53 AM, Vivien Kraus wrote: > Hello guix, > > Trying to run 'guix build --target=x86_64-w64-mingw32 perl' results in > the following exception in the latest stages of the build: > > phase `install' succeeded after 36.7 seconds starting > phase`remove-extra-references' > Backtrace: > 13 (primitive-load "/gnu/store/qnavzfxvw5rng7z8rzlx9zw0ji9…") > In ice-9/eval.scm: > 191:35 12 (_ _) > In srfi/srfi-1.scm: > 863:16 11 (every1 # …) > In > /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm: > 799:28 10 (_ ) > In ice-9/eval.scm: > 619:8 9 ( #(#(#(#(#(#(#) …) …) …) …) …))In > ice-9/boot-9.scm: > 841:4 8 (with-throw-handler _ _ _) > In ice-9/ports.scm: > 444:17 7 (call-with-input-file _ _ #:binary _ #:encoding _ # ) > In > /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm: > 641:26 6 ( ) > 667:26 5 ( # …)In > srfi/srfi-1.scm: > 466:18 4 (fold # …) > In ice-9/eval.scm: > 202:51 3 (_ #(#(#(#(#(#(# …)) …) …) …) …)) > > 163:9 2 (_ #(#(#(#(#(#(# …)) …) …) …) …)) > > > In unknown file: > 1 (string-append "incpth='" #f "/include'\n") > In ice-9/boot-9.scm: > 752:25 0 (dispatch-exception _ _ _) > > ice-9/boot-9.scm:752:25: In procedure dispatch-exception: > In procedure string-append: Wrong type (expecting string): #f > builder for > `/gnu/store/2khcqc5rpc0wizhihpq69x6qn3f7nw5l-perl-5.28.0.drv' failed > with exit code 1 > > I have the full log. Do you wish to see it? > > Did I do something wrong? Is it the same for you? Is there a > workaround? > > Best regards, > > Vivien Seems like cross compiling with mingw is broken for other packages too, I tried the guile example about a week ago and also Lua (which is a super portable language, so it should work everywhere, usually without modifications) and neither worked.
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
P writes: > Seems like cross compiling with mingw is broken for other packages too, I > tried the guile example about a week ago and also Lua (which is a super > portable language, so it should work everywhere, usually without > modifications) and neither worked. Oops. I was hoping I could build my Gtk+ application with guix, and thus get rid of the Fedora container. This bug is so depressing though: perl builds just fine, installs just fine, but guix fails at the very end, in the 'remove-extra-references' step. Vivien
bug#37388: can lead to syntactically invalid configs
Hi, Christopher Baines skribis: > Ludovic Courtès writes: > >> 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. > > I wonder if some errors could be caught at build time, before attempting > to start the service. > > If in the derivation to build the configuration file, nginx is run > against the built config file with -t, that might spot errors at > derivation build time. Yeah, this is probably doable. I would consider it a stop-gap measure though. Fundamentally, I think we should make it so that, by construction, invalid (or at least syntactically-invalid) config files cannot be produced. > An sexp representation sounds good, although I think records will work > out better for the common and high level parts. The way I see it, sexps and records could be almost indistinguishable provided some appropriate macrology. But sexps are definitely easier to implement. Thanks, Ludo’.
bug#37380: gdm doesn't load pam-limits
On Wed, 2019-09-11 at 21:48 +0200, Ricardo Wurmus wrote: > Hi Jesse, > > > I have been trying to set up ardour, but jackd doesn't start in > > real- > > time mode. I made an os definition that replicates this issue when > > I > > use a VM[0]. > > [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.h > > tml > > I asked the gnome and gdm IRC and found out gdm loads the gdm- > > password > > pam config, which seems untouched by pam-limits-service. My > > /etc/pam.d/gdm-password (which should be the default) is attached. > > I can reproduce this. > > (I’m sorry for accidentally misleading you earlier. Turns out I used > JACK a little longer ago than I initially realized.) > > I think it should be pretty easy to fix this: > > 1) we should generate a single file that is used for generic session > settings. > > 2) all login programs (including gdm) should include that file in > their > PAM settings. > > 3) the pam-limits-service should extend that single file instead of > attempting to update a bunch of PAM files for a selected list of > programs. > > -- > Ricardo > Is all this best practice? This solution would have patches for three files: - gnu/system/pam.scm (adding the generic session settings file and patching the "su" and "login" configurations) - gnu/services/base.scm (patching pam-limits-service) - gnu/services/desktop.scm (patching the graphical login configurations). All new login services would require a patch to just one file with these steps implemented(to add the service), whereas they would each need a patch to two files if they are not implemented (one to add the service, another to have pam-limits-service modify the service's pam config. If you think this solution is better design than what we currently have, and others in this mailing list agree, I will work to provide these patches. I previously said adding gdm-password to the list of pam configs amended by pam-limits-service did not work. I then discovered the changes in the environment will not work unless I run "make". I don't know if this is a bug in guix or guile, or if it is intentionally this way; the manual should be updated to clarify that guix needs to be built in the environment for the changes to work. I sent a patch (bug#37405) that fixes this issue for gdm-password. A simple change can probably fix it for gdm-autologin (not added because I haven't tested it) and whatever gdm loads when the user logs in with biometric fingerprints (I don't know the name). When we add ldm and kdm, I think we can do something similar. -- -Jesse
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Hello,
Danny Milosavljevic writes:
> The purpose of "remove-extra-references" seems to be to shrink the
> number of recorded dependencies, so maybe compare it with the unshrinked
> list of dependencies by printing the latter out (apparently it should be
> inside Config_heavy.pl and Config.pm in the temporary build
> directory--could you post those?).
I have several Config.pm files:
./lib/perl5/5.28.0/Net/Config.pm
./lib/perl5/5.28.0/ExtUtils/MakeMaker/Config.pm
./lib/perl5/5.28.0/x86_64-linux-thread-multi/Config.pm
./lib/perl5/5.28.0/x86_64-linux-thread-multi/Encode/Config.pm
In doubt I attach all four, plus the Config_heavy one :)
# This file was created by configpm when Perl was built. Any changes
# made to this file will be lost the next time perl is built.
package Config;
use strict;
use warnings;
our %Config;
sub bincompat_options {
return split ' ', (Internals::V())[0];
}
sub non_bincompat_options {
return split ' ', (Internals::V())[1];
}
sub compile_date {
return (Internals::V())[2]
}
sub local_patches {
my (undef, undef, undef, @patches) = Internals::V();
return @patches;
}
sub _V {
die "Perl lib was built for 'linux' but is being run on '$^O'"
unless "linux" eq $^O;
my ($bincompat, $non_bincompat, $date, @patches) = Internals::V();
my @opts = sort split ' ', "$bincompat $non_bincompat";
print Config::myconfig();
print "\nCharacteristics of this binary (from libperl): \n";
print " Compile-time options:\n";
print "$_\n" for @opts;
if (@patches) {
print " Locally applied patches:\n";
print "$_\n" foreach @patches;
}
print " Built under linux\n";
print " $date\n" if defined $date;
my @env = map { "$_=\"$ENV{$_}\"" } sort grep {/^PERL/} keys %ENV;
if (@env) {
print " \%ENV:\n";
print "$_\n" foreach @env;
}
print " \@INC:\n";
print "$_\n" foreach @INC;
}
sub header_files {
return qw(EXTERN.h INTERN.h XSUB.h av.h config.h cop.h cv.h
dosish.h embed.h embedvar.h form.h gv.h handy.h hv.h hv_func.h
intrpvar.h iperlsys.h keywords.h mg.h nostdio.h op.h opcode.h
pad.h parser.h patchlevel.h perl.h perlio.h perliol.h perlsdio.h
perlvars.h perly.h pp.h pp_proto.h proto.h regcomp.h regexp.h
regnodes.h scope.h sv.h thread.h time64.h unixish.h utf8.h
util.h);
}
##!/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh
##
## This file was produced by running the Configure script. It holds all the
## definitions figured out by Configure. Should you modify one of these values,
## do not forget to propagate your changes by running "Configure -der". You may
## instead choose to run each of the .SH files by yourself, or "Configure -S".
##
#
## Package name : perl5
## Source directory : .
## Configuration time: 1970-01-01
## Configured by : guix
## Target system : linux
#
#: Configure command line arguments.
#
#: Variables propagated from previous config.sh file.
our $summary = <<'!END!';
Summary of my $package (revision $revision $version_patchlevel_string) configuration:
$git_commit_id_title $git_commit_id$git_ancestor_line
Platform:
osname=$osname
osvers=$osvers
archname=$archname
uname='$myuname'
config_args='$config_args'
hint=$hint
useposix=$useposix
d_sigaction=$d_sigaction
useithreads=$useithreads
usemultiplicity=$usemultiplicity
use64bitint=$use64bitint
use64bitall=$use64bitall
uselongdouble=$uselongdouble
usemymalloc=$usemymalloc
default_inc_excludes_dot=$default_inc_excludes_dot
bincompat5005=undef
Compiler:
cc='$cc'
ccflags ='$ccflags'
optimize='$optimize'
cppflags='$cppflags'
ccversion='$ccversion'
gccversion='$gccversion'
gccosandvers='$gccosandvers'
intsize=$intsize
longsize=$longsize
ptrsize=$ptrsize
doublesize=$doublesize
byteorder=$byteorder
doublekind=$doublekind
d_longlong=$d_longlong
longlongsize=$longlongsize
d_longdbl=$d_longdbl
longdblsize=$longdblsize
longdblkind=$longdblkind
ivtype='$ivtype'
ivsize=$ivsize
nvtype='$nvtype'
nvsize=$nvsize
Off_t='$lseektype'
lseeksize=$lseeksize
alignbytes=$alignbytes
prototype=$prototype
Linker and Libraries:
ld='$ld'
ldflags ='$ldflags'
libpth=$libpth
libs=$libs
perllibs=$perllibs
libc=$libc
so=$so
useshrplib=$useshrplib
libperl=$libperl
gnulibc_version='$gnulibc_version'
Dynamic Linking:
dlsrc=$dlsrc
dlext=$dlext
d_dlsymun=$d_dlsymun
ccdlflags='$ccdlflags'
cccdlflags='$cccdlflags'
lddlflags='$lddlflags'
!END!
my $summary_expanded;
sub myconfig {
return $summary_expanded if $summary_expanded;
($summary_expanded = $summary) =~ s{\$(\w+)}
{
my $c;
if ($1 eq 'git_ancestor_line') {
if ($Config::Config{git_ancestor}) {
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Hello, Jan Nieuwenhuizen writes: > Are you using the core-updates-next branch? No, how do I do that? Best regards, Vivien
bug#37388: can lead to syntactically invalid configs
Ludovic Courtès writes: > 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. I wonder if some errors could be caught at build time, before attempting to start the service. If in the derivation to build the configuration file, nginx is run against the built config file with -t, that might spot errors at derivation build time. > 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. An sexp representation sounds good, although I think records will work out better for the common and high level parts. signature.asc Description: PGP signature
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Vivien Kraus writes: > Trying to run 'guix build --target=x86_64-w64-mingw32 perl' results in > the following exception in the latest stages of the build: Are you using the core-updates-next branch? It has a many cross-compilation fixes, notably https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-next=659a2d0f4fff889dff902e32b569e4ca0ae5384a Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
