bug#32360: gst-plugins-base has test failures (when built as a dependency)

2018-08-19 Thread Pjotr Prins


On Sat, Aug 18, 2018 at 01:34:09PM +0200, Tobias Geerinckx-Rice wrote:
> Pjotr, Leo, Guix,
> 
> Pjotr Prins wrote:
> > Someone still needs to push the patch.
> 
> I went ahead and did so in 399c5fafcdb2d0c13ab51e4ab57d451d2c7cb1bd
> since it's not really acceptable to have this broken in master.

It has been broken for a while. And, miracle, guix pull just worked :)

Thanks Tobias, Björn and Leo!

Pj.





bug#32293: wrap-program with non-colon separtor produces incorrect bash substitutions

2018-08-19 Thread Ludovic Courtès
Hello Jelle!

Jelle Licht  skribis:

> While working to package some lua-related stuff, I need to deal with the
> LUA_PATH environment variable. This variable uses `;' as a separator, and
> as such, I wanted to wrap one of my programs
>
> ...
> (wrap-program (string-append out "/bin/fennel")
>`("LUA_PATH" ";" prefix (,path)))
> ...
>
>
> ... which gives me the following snippet for the fennel script:
>
> export 
> LUA_PATH="/gnu/store/3yjzvzwczi37snccrxbw7xsmbns1qc7a-fennel-1-1.f2a3d3b/share/lua/5.3/?.lua${LUA_PATH;+;}$LUA_PATH"
>
> ... which is not a correct bash substitution. I _think_ the first `;' in
> `{LUA_PATH;+;}' needs to be a colon instead, at least if `wrap-program'
> is only used to generate bash-compliant wrappers.
>
> It seems this can be (easily?) fixed around guix/build/utils.scm:1055,
> but any changes I made there had me starting to build bash and other
> things from scratch.

It’s indeed where the bug lies.  Changing that file involves a full
rebuild (because every package build process uses it), but that’s OK:
you can test the ‘wrap-program’ procedure independently (at the REPL,
for example), and then we can push this change to ‘core-updates’.

We need to check whether ‘core-updates’ still accepts full-rebuild
changes at this stage, though.

Thanks,
Ludo’.





bug#32473: Broken menu entry in manual, section 4.1

2018-08-19 Thread HiPhish
I noticed a broken menu entry in the Info version of the Guix manual: the node 
`Defining Packages` (4.1) has an extra space between the last word and the 
closing colons:

* package Reference ::  The package data type

The standalone Info reader tolerates it, but not the Info.vim reader, which 
considers the space to be part of the target node name. Neither the Texinfo 
manual (section 4.9) nor the Info manual seem to allow for this extra space, 
so it looks like a bug in the manual to me.

PS: I am the author of the Info.vim reader, if that matters.
https://gitlab.com/HiPhish/info.vim







bug#32347: gzip cannot be patched

2018-08-19 Thread Ludovic Courtès
Hello,

Efraim Flashner  skribis:

> On Thu, Aug 02, 2018 at 01:32:02PM +0200, Marius Bakke wrote:
>> Hello!
>> 
>> I'm trying to add a patch to 'gzip', but it causes an infinite loop and
>> eventually the system runs out of memory.
>> 
>> It can be reproduced by adding this hunk:
>> 
>
>> modified   gnu/packages/compression.scm
>> @@ -215,6 +215,7 @@ adding and extracting files to/from a tar archive.")
>>  (method url-fetch)
>>  (uri (string-append "mirror://gnu/gzip/gzip-"
>>  version ".tar.xz"))
>> +(snippet '(#t))
>>  (sha256
>>   (base32
>>"16h8g4acy7fgfxcjacr3wijjsnixwsfd2jhz3zwdi2qrzi262l5f"
>> 
>> [back]
>> 
>> I guess this is because gzip itself is a patch input.  Is this something
>> that can be fixed, or do we have to use "patching phases" in these cases?
>
> Its also in commencement.scm, so that might be the loop instead. You
> could try "unpatching" it there. It looks like it has a pseudo-package
> inside of glibc-utf8-locales-final, with grep-final a few packages lower
> being potential inspiration for undoing the modifications in "real
> gzip".

Indeed.  The ‘bootstrap-origin’ procedure, defined in (gnu packages
bootstrap), arranges to use the bootstrap binaries of gzip, patch,
guile, etc. when patching origins.

Perhaps we’re missing a use of ‘bootstrap-origin’ somewhere in (gnu
packages commencement)?

HTH,
Ludo’.





bug#31974: If a phase returns #f, a warning is issued, but the build continues

2018-08-19 Thread Ludovic Courtès
Mark H Weaver  skribis:

> Mark H Weaver  writes:
>
>> I just noticed that I made a mistake in commit
>> d8a3b1b9e847d4a44d2695f95af77170d4d2788f, which changed 'gnu-build' in
>> (guix build gnu-build-system) to issue a warning if a phase returns a
>> value other than #t.
>>
>> The result is that if a phase returns a value other than #t, a warning
>> is issued, but the build nonetheless continues to the next phase, and
>> the build could ultimately "succeed" even some phases returned #f.
>>
>> In other words, the return values of phases are effectively ignored,
>> except for the warning, so the only way to cause a build with phases to
>> fail is to raise an exception.
>
> This should be fixed by commit 82230603ce06de7aa3e4aef2fa093a6dbf0ef8df
> in core-updates.

Cool, thanks for not forgetting!  :-)

Ludo’.





bug#32234: [PATCH 2/2] database: Serialize all database accesses in a thread.

2018-08-19 Thread Ludovic Courtès
Hi Clément!

Clément Lassieur  skribis:

> Fixes .
>
> * bin/cuirass.in (main): Keep only one WITH-DATABASE call around all fibers.
> Remove all DB arguments.
> * src/cuirass/base.scm (evaluate, update-build-statuses!, spawn-builds,
> handle-build-event, build-packages): Remove all DB arguments.
> (clear-build-queue, cancel-old-builds): Wrap in WITH-DB-CRITICAL-SECTION,
> remove all DB arguments.
> (restart-builds): Remove the NON-BLOCKING call, remove all DB arguments.
> (process-specs): Remove all DB arguments, remove the WITH-DATABASE call.
> * src/cuirass/database.scm (%db-channel): New parameter.
> (with-db-critical-section): New macro.
> (db-add-input, db-add-specification, db-get-inputs, db-get-specifications,
> db-add-evaluation, db-add-build, db-update-build-status!, db-get-outputs,
> db-get-builds, db-get-build, db-get-pending-derivations, db-get-stamp,
> db-add-stamp, db-get-evaluations, db-get-evaluations-build-summary,
> db-get-evaluations-id-min, db-get-evaluations-id-max, db-get-builds-min,
> db-get-builds-max): Wrap in WITH-DB-CRITICAL-SECTION, remove all DB arguments.
> (with-database): Wrap BODY in PARAMETERIZE form that sets %DB-CHANNEL to the
> channel returned by MAKE-CRITICAL-SECTION.
> * src/cuirass/http.scm (handle-build-request, handle-builds-request): Remove
> all DB arguments.
> (url-handler): Remove all DB arguments, remove the DB-CHANNEL state, remove
> the WITH-CRITICAL-SECTION calls.
> (run-cuirass-server): Remove the DB arguments, remove the
> MAKE-CRITICAL-SECTION call.
> * src/cuirass/utils.scm (make-critical-section): Replace SPAWN-FIBER with
> CALL-WITH-NEW-THREAD.  Wrap body in PARAMETERIZE form that clears
> CURRENT-FIBER.
> * tests/database.scm (with-temporary-database, db-add-specification,
> db-add-build, db-update-build-status!, db-get-builds,
> db-get-pending-derivations): Remove the DB arguments.
> (db-init): Set the %DB-CHANNEL parameter to the channel returned by
> MAKE-CRITICAL-SECTION, and return #t.
> (database): Set %DB-CHANNEL to #f during cleanup.
> * tests/http.scm (db-init): Set the %DB-CHANNEL parameter to the channel
> returned by MAKE-CRITICAL-SECTION, and return #t.
> (cuirass-run, fill-db): Remove the DB arguments.
> (http): Set %DB-CHANNEL to #f during cleanup.

Excellent, thanks for working on this!  This looks great to me, and I
think the pros outweigh the cons.  Did you check on a big database how
well it performs?

One comment:

> -(define* (handle-build-event db event)
> +(define* (handle-build-event event)
>"Handle EVENT, a build event sexp as produced by 'build-event-output-port',
> -updating DB accordingly."
> +updating the database accordingly."

[...]

> +(define %db-channel
> +  (make-parameter #f))
> +
> +(define-syntax-rule (with-db-critical-section db exp ...)
> +  "Evaluate EXP... in the critical section corresponding to %DB-CHANNEL.
> +DB is bound to the argument of that critical section: the database
> +connection."
> +  (call-with-critical-section (%db-channel)
> +  (lambda (db) exp ...)))
> +

I think I find it nicer to keep the ‘db’ parameter everywhere (except
that it’s now a channel instead of an actual database) rather than using
this global variable.

WDYT?

Really happy we have a solution to this problem!

Thank you,
Ludo’.





bug#32377: guix gc -> build failed: executing SQLite statement: FOREIGN KEY constraint failed

2018-08-19 Thread Ludovic Courtès
Hello,

Benjamin Slade  skribis:

> I'm running the latest GuixSD, and when I run:
>
> `guix gc`
>
> I get the error:
> build failed: executing SQLite statement: FOREIGN KEY constraint failed

That happens with ‘guix gc’ without any options?  Do all runs of ‘guix
gc’ fail like this?

Does ‘guix gc --verify’ (not ‘--verify=xyz’) fail as well?

Thanks for your report,
Ludo’.





bug#32385: no code for module (guix build utils) - info-dir.drv - e921234d02 (master)

2018-08-19 Thread Ludovic Courtès
Hi Chris,

Chris Marusich  skribis:

> On commit e921234d02 (current master branch head), I've noticed that
> attempting to run "guix system reconfigure" using pre-inst-env on one of
> my x86_64-linux systems fails with a message like:
>
> ERROR In procedure scm-error:
> no code for module (guix build utils)
> builder for `/gnu/store...j1kz-info-dir.drv' failed with exit code 1

What version of Guile did you use to compile Guix?

(If you used ‘guix pull’, then Guile 2.2.4 was used.)

Thanks,
Ludo’.





bug#32397: GCC 4.8 Failed to build.

2018-08-19 Thread Ludovic Courtès
fis trivial  skribis:

> guix Version:
>  guix (GNU Guix) cc48997de56864191a4a4ed4bed8763139c3add6
>
> Platform:
>  Fedora 27
>
> Original command:
>  guix environment --ad-hoc gcc@4.8

Fixed in 0b93d04ac537d6413999349ebe7cdcb1e961700e, thanks!

Ludo’.





bug#32382: libchop has build failures

2018-08-19 Thread Ludovic Courtès
Hello,

Björn Höfling  skribis:

> Build log at failure:
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../include/chop -I../include 
> -I../i
> nclude -I../lib -I../lib -DGCRYPT_NO_MPI_MACROS -DGCRYPT_NO_DEPRECATED 
> -I/gnu/st
> ore/dysmb6hz7rr5rvcb05p23dazc5hz26qm-libgcrypt-1.8.2/include 
> -I/gnu/store/a5rd4s
> qyljb9gs58z9hq4kswqmxa45nr-libgpg-error-1.28/include -Wcast-align -Wall 
> -Wmissin
> g-prototypes -Wpointer-arith -fno-strict-aliasing -g -O2 -MT 
> libchop_la-chopper-
> anchor-based.lo -MD -MP -MF .deps/libchop_la-chopper-anchor-based.Tpo -c 
> chopper
> -anchor-based.c  -fPIC -DPIC -o .libs/libchop_la-chopper-anchor-based.o
> chopper-anchor-based.c:120:3: warning: #warning "Not compiling the Lightning 
> cod
> e" [-Wcpp]
>  # warning "Not compiling the Lightning code"
>^
> In file included from chop.c:545:0:
> class-lookup.c:115:1: error: conflicting types for 'chop_lookup_class_entry'
>  chop_lookup_class_entry (register const char *str, register size_t len)
>  ^
> chop.c:542:1: note: previous declaration of 'chop_lookup_class_entry' was here
>  chop_lookup_class_entry (const char *str, unsigned int len);
>  ^
> make[2]: *** [Makefile:1253: libchop_la-chop.lo] Error 1

Fixed in c9f898cd313db2f0bd320357c7571e155feffc4c, with additional fixes
in 6d1a7ce8ea52613963684e6545f6fb3e32d84181.

Note that the thing is unmaintained though…

Thanks,
Ludo’.





bug#32385: no code for module (guix build utils) - info-dir.drv - e921234d02 (master)

2018-08-19 Thread Chris Marusich
l...@gnu.org (Ludovic Courtès) writes:

> What version of Guile did you use to compile Guix?
>
> (If you used ‘guix pull’, then Guile 2.2.4 was used.)

Yes, I believe it was Guile 2.2.4.  I reported the bug on August 6th.
The last time I ran "guix pull" before reporting the bug was on July
29th.  The version reported by "guix environment guix -- guile
--version" when using that July 29th Guix installation is 2.2.4.

Is that the information you were looking for?

-- 
Chris


signature.asc
Description: PGP signature