Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[Leo Famulari]

On Thu, Dec 29, 2016 at 01:44:59AM -0500, Leo Famulari wrote:
> Here's a pre-push Git hook that should prevent unsigned commits from
> being pushed to any remote. I'd like to improve it to be applied
> selectively per-remote.

The hook will only apply when pushing to Savannah if you put this test
at the beginning of the hook:

case "$2" in
*git.sv.gnu.org*)
break
;;  
*)
exit 0
;;  
esac

Commit signatures will be verified before pushing to Savannah, but it
doesn't interfere when pushing to another repository. I think this is
right balance between safety and convenience.

If people think the hook is correct, we could recommend it in HACKING.

> #!/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/sh

Oops! It should all work with #!/bin/sh.


signature.asc
Description: PGP signature

Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[Leo Famulari]

On Thu, Dec 29, 2016 at 07:08:18AM +0100, John Darrington wrote:
> How did these commits get into the repository?  Our repository is 
> configured to reject unsigned commits.   Can it be that it doesn't
> actually check that the signature matches? !!!

Here's a pre-push Git hook that should prevent unsigned commits from
being pushed to any remote. I'd like to improve it to be applied
selectively per-remote.
#!/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/sh

# A hook script that prevents the user from pushing unsigned commits.

# Called by "git push" after it has checked the remote status, but before
# anything has been pushed.  If this script exits with a non-zero status nothing
# will be pushed.
#
# This hook is called with the following parameters:
#
# $1 -- Name of the remote to which the push is being done
# $2 -- URL to which the push is being done
#
# If pushing without using a named remote those arguments will be equal.
#
# Information about the commits which are being pushed is supplied as lines to
# the standard input in the form:
#
#  

z40=

while read local_ref local_sha remote_ref remote_sha
do
if [ "$local_sha" = $z40 ]
then
# Handle delete
:
else
if [ "$remote_sha" = $z40 ]
then
# New branch, examine all commits
range="$local_sha"
else
# Update to existing branch, examine new commits
range="$remote_sha..$local_sha"
fi


# Check if push candidate commits are PGP signed.
git verify-commit $(git rev-list $range) >/dev/null 2>&1

exit $?
fi
done

exit 0


signature.asc
Description: PGP signature

Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[Leo Famulari]

On Thu, Dec 29, 2016 at 07:08:18AM +0100, John Darrington wrote:
> On Thu, Dec 29, 2016 at 03:49:51AM +0100, Tobias Geerinckx-Rice wrote:
>  Leo,
>  
>  On 29/12/16 03:10, Leo Famulari wrote:
>  > gpg: BAD signature from "Tobias Geerinckx-Rice "
>  
>  Oh dear.
>  
>  > Does anyone else get the same result? Any ideas?
>  
>  I do, so it's a real?? corrupted signature.
>  
>  Looking back, it turns out that this isn't the first time this has
>  happened: another commit of mine (7d162df, gnu: mcelog: Update to 146.)
>  also has a bad signature, which I probably missed for the same reason.
>  
> 
> How did these commits get into the repository?  Our repository is 
> configured to reject unsigned commits.   Can it be that it doesn't
> actually check that the signature matches? !!!

Yes, it's a known limitation:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#129

We need to improve the hook.


signature.asc
Description: PGP signature

Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[John Darrington]

On Thu, Dec 29, 2016 at 03:49:51AM +0100, Tobias Geerinckx-Rice wrote:
 Leo,
 
 On 29/12/16 03:10, Leo Famulari wrote:
 > gpg: BAD signature from "Tobias Geerinckx-Rice "
 
 Oh dear.
 
 > Does anyone else get the same result? Any ideas?
 
 I do, so it's a real?? corrupted signature.
 
 Looking back, it turns out that this isn't the first time this has
 happened: another commit of mine (7d162df, gnu: mcelog: Update to 146.)
 also has a bad signature, which I probably missed for the same reason.
 

How did these commits get into the repository?  Our repository is 
configured to reject unsigned commits.   Can it be that it doesn't
actually check that the signature matches? !!!




-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Dependencies of pagure, revision of 2016-12-21

[Leo Famulari]

On Wed, Dec 21, 2016 at 11:47:08AM +, ng0 wrote:
> [PATCH 01/11] gnu: Add python-flask-wtf.
> 
> > Danny Milosavljevic: 
> > Subject: Re: [PATCH 01/11] gnu: Add python-flask-wtf.   
> >
> > Date: Wed, 21 Dec 2016 00:10:39 +0100   
> >
> > Since flask-WTF directly imports flask, this package should also propagate 
> > flask.
> 
> Addressed in this new revision of the patch series, thanks Danny!
> 
> [PATCH 02/11] gnu: Add python-flask-multistatic.
> [PATCH 03/11] gnu: Add python-kitchen.
> [PATCH 04/11] gnu: Add python-munch.
> [PATCH 05/11] gnu: Add python-pygit2.
> [PATCH 06/11] gnu: Add python2-openid.
> [PATCH 07/11] gnu: Add python-openid-cla.
> [PATCH 08/11] gnu: Add python-openid-teams.
> [PATCH 09/11] gnu: Add python-straight-plugin.
> [PATCH 10/11] gnu: Add python-trollius-redis.

Thanks! Pushed with these changes:

For python-flask-wtf, I made python-wtforms a propagated-input because
it sounds like flask-wtf needs to use it at run-time.

I also added some detail to a some of the descriptions.

In the commit messages, I mentioned the python-2 variants of the packages.

Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[Tobias Geerinckx-Rice]

Leo,

On 29/12/16 03:47, Leo Famulari wrote:
> I'm also unable to verify the signature of two more commits, as below.

Signing seems to fail both seldom and pseudo-randomly. Oh, and
silently[1]. My favourite kind of bug.

I'm guessing this is what happens:

  $
  $ git commit, am or cherry-pick && git log --show-signatures
  ...everything looks good and signed! Let's push!
  $ git fetch --all && git rebase upstream/master
  ...now signing some non-HEAD commit silently fails...
  $ git push upstream
  ...badness.

Good night,

T G-R

[1]: until you check the log, of course.

PS:
  nckx@ubuntu~$ $ /usr/bin/gpg2 --version
  gpg (GnuPG) 2.1.15
  libgcrypt 1.7.2-beta
but I doubt that matters much now. I don't use Guix's gpg [yet].



signature.asc
Description: OpenPGP digital signature

Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[Tobias Geerinckx-Rice]

Leo,

On 29/12/16 03:10, Leo Famulari wrote:
> gpg: BAD signature from "Tobias Geerinckx-Rice "

Oh dear.

> Does anyone else get the same result? Any ideas?

I do, so it's a real® corrupted signature.

Looking back, it turns out that this isn't the first time this has
happened: another commit of mine (7d162df, gnu: mcelog: Update to 146.)
also has a bad signature, which I probably missed for the same reason.

Kind regards,

T G-R



signature.asc
Description: OpenPGP digital signature

Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[Leo Famulari]

On Wed, Dec 28, 2016 at 09:10:15PM -0500, Leo Famulari wrote:
> I see this in the log:
> 
> $ git log --show-signature 6a34f4ccc8a5d4a48e25ad3c9c512f8634928b91
> commit 6a34f4ccc8a5d4a48e25ad3c9c512f8634928b91
> gpg: Signature made Wed 28 Dec 2016 08:38:21 PM EST
> gpg:using RSA key 91CCDB9B48541B99
> gpg: BAD signature from "Tobias Geerinckx-Rice " [unknown]
> Author: Tobias Geerinckx-Rice 
> Date:   Wed Dec 28 23:01:49 2016 +0100
> 
> gnu: python-prompt-toolkit: Update to 1.0.9.
> 
> * gnu/packages/python.scm (python-prompt-toolkit): Update to 1.0.9.
> 
> Does anyone else get the same result? Any ideas?
> 
> Tobias, what version of GnuPG are you using?
> 
> I'm using:
> 
> gnupg 2.1.17  /gnu/store/1sa7k3x3y3chdl31p7y7x3sa7p9h1qa3-gnupg-2.1.17
> 
> ... which is built from Guix commit 791ac6a68d1e4bc80f4760cd968cb6c26dbab9ba.

I'm also unable to verify the signature of two more commits, as below.
I've attached a handy Git signature verifier script.

commit e0f8a520eda6b86a71f99eddf2c6968a95c8de0e
gpg: Signature made Thu 24 Nov 2016 08:21:51 PM EST
gpg:using RSA key 91CCDB9B48541B99
gpg: BAD signature from "Tobias Geerinckx-Rice " [unknown]
Author: Tobias Geerinckx-Rice 
Date:   Thu Nov 24 19:28:52 2016 +0100

gnu: miniupnpc: Improve synopsis and description.

* gnu/packages/upnp.scm (miniupnp)[synopsis, description]: Edit, fix typos,
add some relevant (search) terms from the home page, and expand acronyms.

commit 7d162df8ce4dc90c681ff627b2ed94c192e6342f
gpg: Signature made Thu 15 Dec 2016 09:08:42 PM EST
gpg:using RSA key 91CCDB9B48541B99
gpg: BAD signature from "Tobias Geerinckx-Rice " [unknown]
Author: Tobias Geerinckx-Rice 
Date:   Thu Dec 15 23:17:52 2016 +0100

gnu: mcelog: Update to 146.

* gnu/packages/linux.scm (mcelog): Update to 146.
#!/bin/sh

# This script requires a Git revision selector, such as HEAD, 734713bc0,
# origin/master..HEAD, et cetera:
# https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection

# A revision selector example for guix.git: v0.11.0..HEAD

if test $# -eq 1 ; then
range=$1
else
exit 1
fi

for commit in $(git rev-list $range); do
results=$(git verify-commit $commit 2>&1)
if test $? -ne 0; then
git show --format=full --show-signature $commit
# I'm not sure if the previous line will always include the
# contents of $results, so I re-print it just in case.
printf "%s\n\n" "$results"
fi
done


signature.asc
Description: PGP signature

Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)

[Leo Famulari]

I see this in the log:

$ git log --show-signature 6a34f4ccc8a5d4a48e25ad3c9c512f8634928b91
commit 6a34f4ccc8a5d4a48e25ad3c9c512f8634928b91
gpg: Signature made Wed 28 Dec 2016 08:38:21 PM EST
gpg:using RSA key 91CCDB9B48541B99
gpg: BAD signature from "Tobias Geerinckx-Rice " [unknown]
Author: Tobias Geerinckx-Rice 
Date:   Wed Dec 28 23:01:49 2016 +0100

gnu: python-prompt-toolkit: Update to 1.0.9.

* gnu/packages/python.scm (python-prompt-toolkit): Update to 1.0.9.

Does anyone else get the same result? Any ideas?

Tobias, what version of GnuPG are you using?

I'm using:

gnupg   2.1.17  /gnu/store/1sa7k3x3y3chdl31p7y7x3sa7p9h1qa3-gnupg-2.1.17

... which is built from Guix commit 791ac6a68d1e4bc80f4760cd968cb6c26dbab9ba.


signature.asc
Description: PGP signature

Re: Chicken security bugs [was Re: [pe...@more-magic.net: Irregex packages should be updated to 0.9.6]]

[Kei Kebreau]

Kei Kebreau  writes:

> Kei Kebreau  writes:
>
>> Leo Famulari  writes:
>>
>>> On Sat, Dec 24, 2016 at 02:23:43PM -0500, Kei Kebreau wrote:
 Leo Famulari  writes:
 > On Thu, Dec 22, 2016 at 02:20:37PM -0500, Kei Kebreau wrote:
 >> Subject: [PATCH] gnu: chicken: Fix CVE-2016-{6830,6831}.
 >> 
 >> *
 >> gnu/packages/patches/chicken-CVE-2016-6830+CVE-2016-6831.patch:
 >> New file.
 >> * gnu/local.mk (dist_patch_DATA): Use it.
 >> * gnu/packages/scheme.scm (chicken)[source]: Use it.
 >
 > Thank you for looking into this!
 >
 > Something like this patch is in CHICKEN 4.11.1:
 >
 > https://code.call-cc.org/cgi-bin/gitweb.cgi?p=chicken-core.git;a=commitdiff;h=0d20426c6da0f116606574dadadaa878b96a68ea
 >
 > And there is a patch for the IrRegex bug after the latest tag:
 >
 > https://code.call-cc.org/cgi-bin/gitweb.cgi?p=chicken-core.git;a=commitdiff;h=2c419f18138c17767754b36d3b706cd71a55350a
 >
 > Can you try updating CHICKEN and applying that IrRegex patch?
 
 I can try, but updating to CHICKEN 4.11.1 requires a recent CHICKEN
 binary due to its build system requirements. Do we have any objection to
 bootstrapping CHICKEN 4.11.1 from version 4.11.0?
>>>
>>> Interesting!
>>>
>>> I don't see why we shouldn't use 4.11.0 to bootstrap 4.11.1.
>>>
>>> Changing the build system like that seems unusual for a minor point
>>> release, and I don't see it documented in the 4.11.1 NEWS file:
>>>
>>> https://code.call-cc.org/cgi-bin/gitweb.cgi?p=chicken-core.git;a=blob;f=NEWS;h=545d68583c8375bd5243ec07a53faff9ec1685a3;hb=116f42e7a3eab2a02b853fd038af3cb3aadad5c3
>>>
>>
>> I must have phrased that too vaguely. It's just a "building from release
>> tarball vs from git checkout" thing, documented in the README file of
>> both releases. I've been having trouble with the seemingly identical
>> test suite using the attached WIP patch. Perhaps the dreary wheather is
>> clouding my thoughts.
>>
>
> Update! I found a file "types.db" that is unwritable. However, changing
> access permissions in the (hackish) way I've done in the patch makes the
> build's hash time-dependent.
>
>>> One way or another, we should fix these bugs in our package. Thanks for
>>> taking care of it :)
>>
>> You're welcome!
>
> Merry Grav-Mass, BTW. :)

Here's the CVE patch on top of the chicken 4.11.1 one. I can't get this
git-based build to be reproducible, though.
From cb31f773829fe655d966db469aced7c1ad5bd2ed Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Wed, 28 Dec 2016 20:03:20 -0500
Subject: [PATCH] gnu: chicken: Fix CVE-2016-{6830,6831}.

* gnu/packages/patches/chicken-CVE-2016-6830+CVE-2016-6831.patch: New file.
* gnu/local.mk (dist_patch_DATA): Use it.
* gnu/packages/scheme.scm (chicken)[source]: Use it.
---
 gnu/local.mk   |   1 +
 .../chicken-CVE-2016-6830+CVE-2016-6831.patch  | 116 +
 gnu/packages/scheme.scm|   4 +-
 3 files changed, 120 insertions(+), 1 deletion(-)
 create mode 100644 
gnu/packages/patches/chicken-CVE-2016-6830+CVE-2016-6831.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 106adb235..f21f6c0b9 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -497,6 +497,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/calibre-drop-unrar.patch\
   %D%/packages/patches/calibre-no-updates-dialog.patch \
   %D%/packages/patches/cdparanoia-fpic.patch   \
+  %D%/packages/patches/chicken-CVE-2016-6830+CVE-2016-6831.patch   \
   %D%/packages/patches/chmlib-inttypes.patch   \
   %D%/packages/patches/clang-libc-search-path.patch\
   %D%/packages/patches/clang-3.8-libc-search-path.patch\
diff --git a/gnu/packages/patches/chicken-CVE-2016-6830+CVE-2016-6831.patch 
b/gnu/packages/patches/chicken-CVE-2016-6830+CVE-2016-6831.patch
new file mode 100644
index 0..4865740d5
--- /dev/null
+++ b/gnu/packages/patches/chicken-CVE-2016-6830+CVE-2016-6831.patch
@@ -0,0 +1,116 @@
+From 2c419f18138c17767754b36d3b706cd71a55350a Mon Sep 17 00:00:00 2001
+From: Peter Bex 
+Date: Wed, 14 Dec 2016 20:25:25 +0100
+Subject: [PATCH] Update irregex to upstream 0.9.6
+
+This fixes a resource consumption vulnerability due to exponential
+memory use based on the depth of nested "+" patterns.
+
+Signed-off-by: Mario Domenech Goulart 
+---
+ NEWS|  4 
+ irregex-core.scm| 32 ++--
+ irregex-utils.scm   |  2 +-
+ manual/Unit irregex |  2 +-
+ 4 files changed, 24 insertions(+), 16 deletions(-)
+
+diff --git a/NEWS b/NEWS
+index 052cf13..cbadd61 100644
+--- a/NEWS
 b/NEWS
+@@ -1,5 +1,9 @@
+ 4.11.2
+ 
++- Security fixes
++  - Irregex has been updated to 

staging: django fails to build

[Leo Famulari]

Django is failing its test suite on the staging branch:

https://hydra.gnu.org/job/gnu/staging/python-django-1.10.3.x86_64-linux
https://hydra.gnu.org/job/gnu/staging/python-django-1.10.3.i686-linux

I can reproduce this on my own machine, but I'm not sure what the
problem is.

Does anyone have any ideas?

Here are the failing tests:

==
FAIL: test_timeuntil08 
(template_tests.filter_tests.test_timeuntil.TimeuntilTests)
--
Traceback (most recent call last):
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 58, in testPartExecutor
yield
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 600, in run
testMethod()
  File 
"/tmp/guix-build-python-django-1.10.3.drv-0/Django-1.10.3/django/test/utils.py",
 line 205, in inner
return func(*args, **kwargs)
  File 
"/tmp/guix-build-python-django-1.10.3.drv-0/Django-1.10.3/tests/template_tests/utils.py",
 line 61, in inner
func(self)
  File 
"/tmp/guix-build-python-django-1.10.3.drv-0/Django-1.10.3/tests/template_tests/filter_tests/test_timeuntil.py",
 line 66, in test_timeuntil08
self.assertEqual(output, '1\xa0week')
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 820, in assertEqual
assertion_func(first, second, msg=msg)
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 813, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: '1\xa0week, 1\xa0day' != '1\xa0week'

==
FAIL: test_timeuntil09 
(template_tests.filter_tests.test_timeuntil.TimeuntilTests)
--
Traceback (most recent call last):
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 58, in testPartExecutor
yield
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 600, in run
testMethod()
  File 
"/tmp/guix-build-python-django-1.10.3.drv-0/Django-1.10.3/django/test/utils.py",
 line 205, in inner
return func(*args, **kwargs)
  File 
"/tmp/guix-build-python-django-1.10.3.drv-0/Django-1.10.3/tests/template_tests/utils.py",
 line 61, in inner
func(self)
  File 
"/tmp/guix-build-python-django-1.10.3.drv-0/Django-1.10.3/tests/template_tests/filter_tests/test_timeuntil.py",
 line 71, in test_timeuntil09
self.assertEqual(output, '1\xa0week')
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 820, in assertEqual
assertion_func(first, second, msg=msg)
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 813, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: '1\xa0week, 1\xa0day' != '1\xa0week'

==
FAIL: test_both_date_objects (utils_tests.test_timesince.TimesinceTests)
Timesince should work with both date objects (#9672)
--
Traceback (most recent call last):
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 58, in testPartExecutor
yield
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 600, in run
testMethod()
  File 
"/tmp/guix-build-python-django-1.10.3.drv-0/Django-1.10.3/tests/utils_tests/test_timesince.py",
 line 106, in test_both_date_objects
self.assertEqual(timeuntil(today + self.oneweek, today), '1\xa0week')
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 820, in assertEqual
assertion_func(first, second, msg=msg)
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 1193, in assertMultiLineEqual
self.fail(self._formatMessage(msg, standardMsg))
  File 
"/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/unittest/case.py",
 line 665, in fail
raise self.failureException(msg)
AssertionError: '1\xa0week, 1\xa0day' != '1\xa0week'
- 1??week, 1 day
+ 1 week


--
Ran 11263 tests in 107.254s

FAILED (failures=3, skipped=1122, expected failures=4)
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...

[PATCH] gnu: rustc: Update to 1.14.0.

[ng0]

* gnu/packages/rust.scm (rustc): Update to 1.14.0.
%rust-bootstrap-binaries: Update to 1.13.0.
---
 gnu/packages/rust.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index acc555e75..8aa867317 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016 David Craven 
 ;;; Copyright © 2016 Eric Le Bihan 
+;;; Copyright © 2016 ng0 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -37,7 +38,7 @@
   #:use-module (srfi srfi-26))
 
 ;; Should be one less than the current released version.
-(define %rust-bootstrap-binaries-version "1.12.1")
+(define %rust-bootstrap-binaries-version "1.13.0")
 
 (define %rust-bootstrap-binaries
   (origin
@@ -48,7 +49,7 @@
   "-i686-unknown-linux-gnu.tar.gz"))
 (sha256
  (base32
-  "1cvbx7bbhbn3w6pn64rp9fdp2n17rwzxgsnifncw5nqx9p8vksgd"
+  "0fcl7xgm2m21sjv1f27i3v692aa91lk8r867hl8d6l377w8k95r3"
 
 (define (increment-rust-version rust-version major patch)
   (match (string-split rust-version #\.)
@@ -200,7 +201,7 @@ rustc-bootstrap and cargo-bootstrap packages.")
 "rustc-" version "-src.tar.gz"))
   (sha256
(base32
-"112h7qgbn8c7s5880vplpgy5n58sc8css32dq7z5wylpr9slgf7c"
+"0srvmhhdbbcl21nzg9m9zni7k10h88lsy8k1ljz03g8mx79fv467"
 (build-system gnu-build-system)
 (native-inputs
  `(("cmake" ,cmake)
-- 
2.11.0

rustc (rust and cargo): Update to 1.14.0

[ng0]

[PATCH] gnu: rustc: Update to 1.14.0.

This updates rust to 1.14.0 ... Build succesfully, I'll see wether building 
crate libc now succeeds.

Re: Shutdown of googlecode end of the year - we have affected packages!

[Adonay Felipe Nogueira]

I might have found the new repository of our recipe for abbaye, and I
have contacted the developers of abbaye (David Lara, also known as nevat) and he
told me that the repository I found is the successor of the one in
Google Code.

Now, what is left to do is test the noew source files to see if they
build as expected, and also separate the Venice Classic text font into a
new recipe.

For transparency purposes, the new repository is located at:

https://github.com/nevat/abbayedesmorts-gpl

I'll try to help testing and unbundling.


Respectfully, Adonay.
-- 
* pt-BR: Brasileiro | en: Brazilian
* pt-BR: Ativista do software livre | en: Free/libre software activist
* https://libreplanet.org/wiki/User:Adfeno
* pt-BR: Palestrante, consultor e avaliador | en: Speaker, consultant and 
evaluator

Re: GuixSD + StumpWM

[Daniel Pimentel]

I posted about it in my blog[1]: d4n1.org/guixsd.html

[1] Developed with Haunt (thanks David) :)

---
Daniel Pimentel (d4n1)

On 2016-12-27 21:50, Daniel Pimentel wrote:

Guixs,

I'm trying use StumpWM in my config.scm but there's code for module:

guix system: error: failed to load '/etc/config.scm':
ice-9/boot-9.scm:2870:6: In procedure resolve-interface:
ice-9/boot-9.scm:2870:6: no code for module (gnu packages sbcl-stumpwm)

My config.scm:
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
(use-package-modules wm sbcl-stumpwm certs)

...

  (packages (cons* sbcl-stumpwm  ;window manager
   nss-certs ;for HTTPS access
   %base-packages))

I like ratpoison, but stumpwm is very cool (Lisp :)

Thanks,

Rust packages I am working on - read or reply to prevent duplicate work

[ng0]

Hi, here is a one level list of (almost) all packages I am
working on in the next few weeks. If you see a package you want
to work on or already work on, plan to work on, or whatever "what
if" case, please respond or post to the list. I'm more than happy
for any work and find duplicate work sad. I need to work on this
list anyway to get to our current prototype to work.
Here's the list, copied from our gitlab including some not
changed names from the importers (rust- prefix):

  * [ ] qml
  * [ ] libc
  * [ ] lazy-static
  * [ ] spin
  * [ ] psyc
  * [ ] tokio-core
  * [ ] mio
  * [ ] bytes
  * [ ] tempdir
  * [ ] kernel32-sys
  * [ ] rust-winapi-build
  * [ ] lazycell
  * [ ] clippy
  * [ ] miow
  * [ ] net2
  * [ ] rust-ws2-32-sys
  * [ ] nix
  * [ ] nix-test
  * [ ] rand
  * [ ] rustc-version
  * [ ] semver
  * [ ] rust-crates-index
  * [ ] rust-tempdir
  * [ ] rust-semver-parser
  * [ ] tempdir
  * [ ] tempfile
  * [ ] bitflags
  * [ ] cfg-if
  * [ ] void
  * [ ] winapi
  * [ ] rust-advapi32-sys
  * [ ]  rust-bcrypt-sys
  * [ ]  rust-comctl32-sys
  * [ ]  rust-comdlg32-sys
  * [ ]  rust-credui-sys
  * [ ]  rust-crypt32-sys
  * [ ]   rust-d2d1-sys
  * [ ]   rust-d3d11-sys
  * [ ]   rust-d3d12-sys
  * [ ]   rust-d3d9-sys
  * [ ]   rust-d3dcompiler-sys
  * [ ]   rust-dbghelp-sys
  * [ ]   rust-dsound-sys
  * [ ]   rust-dwmapi-sys
  * [ ]   rust-dwrite-sys
  * [ ]   rust-dxgi-sys
  * [ ]   rust-dxguid-sys
  * [ ]   rust-gdi32-sys
  * [ ]rust-hid-sys
  * [ ]   rust-httpapi-sys
  * [ ]   rust-kernel32-sys
  * [ ]   rust-ktmw32-sys
  * [ ]   rust-mpr-sys
  * [ ]   rust-netapi32-sys
  * [ ]rust-odbc32-sys
  * [ ]   rust-ole32-sys
  * [ ]   rust-oleaut32-sys
  * [ ]   rust-opengl32-sys
  * [ ]   rust-pdh-sys
  * [ ]   rust-psapi-sys
  * [ ]   rust-runtimeobject-sys
  * [ ]   rust-secur32-sys
  * [ ]   rust-setupapi-sys
  * [ ]   rust-shell32-sys
  * [ ]  rust-shlwapi-sys
  * [ ]  rust-user32-sys
  * [ ]  rust-userenv-sys
  * [ ]  rust-usp10-sys
  * [ ]  rust-uuid-sys
  * [ ]  rust-vssapi-sys
  * [ ]  rust-wevtapi-sys
  * [ ]   rust-winhttp-sys
  * [ ]  rust-winmm-sys
  * [ ]  rust-winscard-sys
  * [ ]  rust-winspool-sys
  * [ ]  rust-winusb-sys
  * [ ]  rust-ws2-32-sys
  * [ ]   rust-xinput-sys
  * [ ] scoped-tls
  * [ ] slab
  * [ ] env-logger
  * [ ] regex
  * [ ] quickcheck
  * [ ] memchr
  * [ ] regex-syntax
  * [ ] simd
  * [ ] thread-local
  * [ ] utf-8-ranges
  * [ ] futures
  * [ ] log
-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

rust: Crate Dependencies

[Danny Milosavljevic]

Hi,

I'm trying Rust out for a bit and for that I added some Crates. (using David's 
v2 patches as a base)

Right now I'm stuck at rust-c-vec which I tried to add myself. I get:

starting phase `unpack'
c_vec-1.1.0/.travis.yml
c_vec-1.1.0/Cargo.toml
c_vec-1.1.0/LICENSE-APACHE
c_vec-1.1.0/LICENSE-MIT
c_vec-1.1.0/README.md
c_vec-1.1.0/src/c_vec.rs
phase `unpack' succeeded after 0.0 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded after 0.0 seconds
starting phase `patch-source-shebangs'
phase `patch-source-shebangs' succeeded after 0.0 seconds
starting phase `configure'
phase `configure' succeeded after 0.0 seconds
starting phase `patch-generated-file-shebangs'
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `build'
error: failed to load source for a dependency on `libc`

I tried it with the following package spec:

(define-public rust-c-vec
 (package
  (name "rust-c-vec")
  (version "1.1.0")
  (source
(origin
  (method url-fetch)
  (uri (crate-uri "c_vec" version))
  (file-name
(string-append name "-" version ".tar.gz"))
  (sha256
(base32
  "02gkicm59prlhpc2igkvl4gbmclzg6wmancscwdk3z93p04rjqhc"
  (build-system cargo-build-system)
  (inputs `(("rust-libc" ,rust-libc)))
  (home-page "FIXME") ; FIXME fixed manually. It said ()
  (synopsis "Structures to wrap C arrays")
  (description "Structures to wrap C arrays")
  (license (list license:asl2.0 license:expat

I attached a Guile module with some of the Crates I am adding...

What does the error message mean? How to fix it?
(define-module (wip rustmods)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix utils)
  #:use-module (guix build-system cargo)
  #:use-module (guix gexp)
  #:use-module (gnu packages)
  #:use-module (gnu packages rust)
  #:use-module (gnu packages pkg-config))

(define-public rust-bitflags
 (package
  (name "rust-bitflags")
  (version "0.7.0")
  (source
(origin
  (method url-fetch)
  (uri (crate-uri "bitflags" version))
  (file-name
(string-append name "-" version ".tar.gz"))
  (sha256
(base32
  "0v8hh6wdkpk9my8z8442g4hqrqf05h0qj53dsay6mv18lqvqklda"
  (build-system cargo-build-system)
  (home-page
"https://github.com/rust-lang/bitflags;)
  (synopsis
"A macro to generate structures which behave like bitflags.
")
  (description
"This package provides a macro to generate structures which behave like bitflags.
")
  (license (list license:expat license:asl2.0

(define-public rust-glib-sys
 (package
  (name "rust-glib-sys")
  (version "0.3.2")
  (source
(origin
  (method url-fetch)
  (uri (crate-uri "glib-sys" version))
  (file-name
(string-append name "-" version ".tar.gz"))
  (sha256
(base32
  "1cwjfhyvys3hyzfr326sp1spsnj5drf8p9zixgis233zk7gz45d3"
  (build-system cargo-build-system)
  (native-inputs
`(("rust-pkg-config" ,rust-pkg-config)))
  (inputs
`(("rust-bitflags" ,rust-bitflags)
  ("rust-libc" ,rust-libc)))
  (home-page "http://gtk-rs.org/;)
  (synopsis "FFI bindings to libglib-2.0")
  (description "FFI bindings to libglib-2.0")
  (license license:expat)))

(define-public rust-pkg-config
 (package
  (name "rust-pkg-config")
  (version "0.3.8")
  (source
(origin
  (method url-fetch)
  (uri (crate-uri "pkg-config" version))
  (file-name
(string-append name "-" version ".tar.gz"))
  (sha256
(base32
  "1ypj4nj2z9z27qg06v3g40jyhw685i3l2wi098d21bvyri781vlc"
  (build-system cargo-build-system)
  (home-page "https://github.com/alexcrichton/pkg-config-rs;) ; FIXME manually fixed; it said ()
  (synopsis
"A library to run the pkg-config system tool at build time in order to be used in
Cargo build scripts.
")
  (description
"This package provides a library to run the pkg-config system tool at build time in order to be used in
Cargo build scripts.
")
  (license (list license:expat license:asl2.0

(define-public rust-gobject-sys
 (package
  (name "rust-gobject-sys")
  (version "0.3.2")
  (source
(origin
  (method url-fetch)
  (uri (crate-uri "gobject-sys" version))
  (file-name
(string-append name "-" version ".tar.gz"))
  (sha256
(base32
  "13qy4hsh74351969mzc19sx29g1clmh58v75d87pfnsikqi6qdw8"
  (build-system cargo-build-system)
  (native-inputs
`(("rust-pkg-config" ,rust-pkg-config)))
  (inputs
`(("rust-bitflags" ,rust-bitflags)
  ("rust-glib-sys" ,rust-glib-sys)
  ("rust-libc" ,rust-libc)))
  (home-page "http://gtk-rs.org/;)
  (synopsis "FFI bindings to libgobject-2.0")
  (description "FFI bindings to libgobject-2.0")
  (license license:expat)))

(define-public rust-glib
 (package
  (name "rust-glib")
  (version "0.1.1")
  (source
(origin
  (method url-fetch)
  

Re: [PATCH 2/2] gnu: multiqc: Update to 0.8.

[Ra]

Hi Ben,
reading the comments from https://github.com/ewels/MultiQC/issues/376
it seems that in the upcoming release they will solve the problem.
Are we going to wait for the next v. 1.0 or include it now and update later
?

--
Ra

On Mon, Dec 26, 2016 at 1:18 PM Ben Woodcroft  wrote:

> Hi Raoul,
>
>
> On 26/12/16 20:45, Ra wrote:
> > Hi Ben,
> > thanks I will investigate. Does it mean that multiqc is in stand by
> > for now ?
>
> It would be ideal I think to add tests, and because they are failing it
> would be good to know why. I thought the easiest simply to ask the
> maintainers if they knew why the tests were failing:
> https://github.com/ewels/MultiQC/issues/376
>
> I also submitted the exception catching patch here, which we should add
> to our patch if we decide to keep it before pushing our changes.
> https://github.com/ewels/MultiQC/pull/377
>
> I figure it makes sense to give them a week or two to respond, and
> reevaluate after that. I presume you have not observed any problems
> using multiqc after this update?
> Thanks,
> ben
>

Re: [PATCH 1/2] gnu: libmtp: Grant "audio" group access to device files.

[Chris Marusich]

Ricardo Wurmus  writes:

> Chris Marusich  writes:
>
>> * gnu/packages/libusb.scm (libmtp): Set udev group to "audio".
>> ---
>
> I just checked how it’s done on Debian and Fedora.  Neither pass this
> configuration flag.  On a Fedora system I can access I see that the udev
> rules that come with libmtp do not specify any group or mode.
>
> This doesn’t mean that we should not do this, but it’s suspicious.
> Maybe there’s something else we’re overlooking here?

This is a good question.  The answer seems to be a little complicated.

I did some testing with a fresh install of Ubuntu 16.04.1 LTS.  I tried
transferring files via MTP between this Ubuntu system and an Android
device, and it "just worked".  On that system, I noticed that the udev
rules installed by the "libmtp-common" package do in fact set the group
to "audio".  The curious things is: the MTP file transfer "just worked"
even though though my test user was not a member of the "audio" group.
Why did it work?  Well, it turns out that the access to the device file
in question was ACTUALLY being granted via an ACL which provided the
necessary access to my test user specifically.  The "audio" group
ownership was apparently superfluous; I don't know why they set it.

So, presumably, MTP "just works" on Ubuntu not because they've made the
"audio" group the owner of the device file (although they have in fact
done that, too); rather, MTP "just works" because something is
automatically setting the ACL for the device file to grant my test user
the necessary access.  Apparently, this is some kind of feature of udev
or systemd or something.  It seems to have something to do with the
"uaccess" rules which are provided by systemd's udev.  It seems (and
this is just my guess, so I might be wrong) like the udev rules from
"libmtp-common" set an environment variable named "ID_MEDIA_PLAYER" to
the value "1", and then in a later udev rules file (called
"70-uaccess.rules", which is provided by systemd), any device for which
this environment variable (ID_MEDIA_PLAYER) has been set also gets
tagged with the magic value "uaccess."  Presumably, something somewhere
in udev will "do the right thing" for these "uaccess"-tagged devices and
set the ACLs up correctly when this tag is present.  I didn't go down
the rabbit hole that far, though, so I can't really say for certain.

All I know is: Ubuntu does in fact set the group owner in their udev
rules file from the "libmtp-common" package, but the actual access
appears to be granted not via group permissions but rather via an ACL
that seems to be granted via this "uaccess" mechanism.

Does this ring a bell?  Do we use ACLs in GuixSD?  Does our elogind
support this "uaccess" magic, too?  If so, then I imagine we might not
need to set the group owner at all.  But if not, then setting the group
owner seems like a reasonable workaround until we can do better.

> I also think that using the “audio” group would be wrong.  This is for
> MTP devices, so maybe it would be better to add an “mtp” group.

Sure, IMO the "mtp" group would make more sense, since as you point out
MTP is not just for audio.

> https://gmtp.sourceforge.io/usage.html says this about root:
>
> Q. Do I need root access to use gMTP?
> A. […] On Linux, in general No, as libmtp should have set your udev
>rules correctly for libmtp known devices.
>
> And since neither Fedora nor Debian configures libmtp such that the
> devices are owned by a particular group, I wonder if maybe that’s not
> actually necessary.

I wonder if Fedora and Debian are using ACLs, too.  Can you confirm
that?  You can check using "ls -l" (look for the "+" near the file
mode), or by running "getfacl" on the device file (i.e., whatever device
file is pointed to by the /dev/libmtp-2-1 symlink or similar).

I just wanted to put music on my phone, that's all!! :-)

-- 
Chris


signature.asc
Description: PGP signature

Re: rust: cargo build-system: how to handle libraries

[David Craven]

> Of course I meant Cargo.lock, not Cargo.toml ... so I know what I
> have to search for, and this makes it a bit easier than the
> previous search.

See cargo workspaces:
https://github.com/rust-lang/libc/blob/master/Cargo.toml
https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

It's a fairly new thing, you'll have to track down the relevant
commits in cargo and check if the cargo version we are using is new
enough and understand it's semantics and how it applies to the cargo
build system.

My recommendation to fix this issue is to not run the tests if there
isn't a Cargo.lock file, but this is likely not going to solve the
underlying cause in this case. You can also package version 0.2.16
which does not use workspaces.

Re: [PATCH] Add r-scran 1.2.0 and all its dependencies

[Ra]

Hi Ricardo,
there was an issue with the r-shiny patch, the license was wrong. So this
is the new set of patches.



On Tue, Dec 27, 2016 at 10:25 PM Ra  wrote:

> Dear Ricardo,
> I try to satisfy all the requirements. What do you think ?
> In attachment the patches.
>
> Shiny now is in web.scm
>
> I reformat the description and fixed the synopsis. I also re checked the
> licenses.
> I have created a single patch for each r-package.
>
> --
> Raoul
>
>
>
> On Tue, Dec 27, 2016 at 6:06 PM Ra  wrote:
>
> On Tue, Dec 27, 2016 at 6:00 PM Ricardo Wurmus  wrote:
>
>
> Ra  writes:
>
> > guix import cran --archive=bioconductor scater
> >
> > I had to add the missing dependencies by hand, is there a recursive way
> to do so?
>
> Yes, you can just pass “--recursive” or “-r” and the importer will spit
> out package expressions for all unpackaged dependencies.  A current
> limitation is that it doesn’t cross over from Bioconductor to CRAN.
>
> Nice, I will try
>
>
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> http://elephly.net
>
>


0006-gnu-Add-r-shiny.patch
Description: Binary data


0005-gnu-Add-r-statmod.patch
Description: Binary data


0010-gnu-Add-r-scater.patch
Description: Binary data


0008-gnu-Add-r-tximport.patch
Description: Binary data


0003-gnu-Add-r-sourcetools.patch
Description: Binary data


0001-gnu-Add-r-vipor.patch
Description: Binary data


0002-gnu-Add-r-beeswarm.patch
Description: Binary data


0007-gnu-Add-r-shinydashboard.patch
Description: Binary data


0004-gnu-Add-r-ggbeeswarm.patch
Description: Binary data


0009-gnu-Add-r-rhdf5.patch
Description: Binary data


0011-gnu-Add-r-scran.patch
Description: Binary data

Re: rust: cargo build-system: how to handle libraries

[ng0]

ng0  writes:

> David Craven  writes:
>
>>> We run (or this is the default) cargo with `--bin`, which is
>>> necessary for everything which needs to be compiled and features
>>> a Cargo.toml.
>>
>> All crates have a Cargo.toml file. The interesting crates are the ones with
>> a Cargo.lock file.
>>
>>> To "build" libraries, we have to explicitly tell cargo to not
>>> run/build/whatever with --bin ?
>>
>> Building libraries is currently not very useful at the moment, since they are
>> not meant to be libraries in the C sense, but in the sense that it's a
>> collection
>> of source code that can be reused in a rust project. One can create a library
>> in the C sense, but most crates do not do this and are not intended to be abi
>> compatible with C.
>>
>>> Or do I have to interprete what I read a while ago "we just need
>>> to copy the libraries to the store" as literally "if we encounter
>>> no Cargo.toml, let's copy everything to the store as is"?
>>
>> If we encounter no Cargo.lock file it generally means the above.
>>
>
> Thanks for your answer.
>
> But, ouch... note to self, packaging while hanging out with other
> people to watch streamed talks sometimes does not work out.
> The actual failure is different, the build system (currently)
> expects a Cargo.toml everywhere, and the folder `libc-test'
> doesn't seem to have one, breaking the build phase.

Of course I meant Cargo.lock, not Cargo.toml ... so I know what I
have to search for, and this makes it a bit easier than the
previous search.

> phase `unpack' succeeded after 0.1 seconds
> starting phase `patch-usr-bin-file'
> phase `patch-usr-bin-file' succeeded after 0.0 seconds
> starting phase `patch-source-shebangs'
> patch-shebang: ./ci/docker/arm-linux-androideabi/accept-licenses.sh: warning: 
> no binary for interpreter `expect' found in $PATH
> patch-shebang: ./ci/docker/arm-linux-androideabi/install-ndk.sh: changing 
> `/bin/sh' to `/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
> patch-shebang: ./ci/docker/arm-linux-androideabi/install-sdk.sh: changing 
> `/bin/sh' to `/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
> patch-shebang: ./ci/dox.sh: changing `/bin/sh' to 
> `/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
> patch-shebang: ./ci/run.sh: changing `/bin/sh' to 
> `/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
> phase `patch-source-shebangs' succeeded after 0.0 seconds
> starting phase `configure'
> phase `configure' succeeded after 0.0 seconds
> starting phase `patch-generated-file-shebangs'
> patch-shebang: ./ci/docker/arm-linux-androideabi/accept-licenses.sh: warning: 
> no binary for interpreter `expect' found in $PATH
> phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
> starting phase `build'
> error: failed to read 
> `/tmp/guix-build-rust-libc-0.2.18.drv-0/libc-0.2.18/libc-test/Cargo.toml`
>
> Caused by:
>   No such file or directory (os error 2)
> phase `build' failed after 0.5 seconds
> builder for 
> `/gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv' failed 
> with exit code 1
> @ build-failed 
> /gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv - 1 builder 
> for `/gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv' failed 
> with exit code 1
> guix build: error: build failed: build of 
> `/gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv' failed
>
>
> -- 
> ♥Ⓐ  ng0
> PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: rust: cargo build-system: how to handle libraries

[ng0]

David Craven  writes:

>> We run (or this is the default) cargo with `--bin`, which is
>> necessary for everything which needs to be compiled and features
>> a Cargo.toml.
>
> All crates have a Cargo.toml file. The interesting crates are the ones with
> a Cargo.lock file.
>
>> To "build" libraries, we have to explicitly tell cargo to not
>> run/build/whatever with --bin ?
>
> Building libraries is currently not very useful at the moment, since they are
> not meant to be libraries in the C sense, but in the sense that it's a
> collection
> of source code that can be reused in a rust project. One can create a library
> in the C sense, but most crates do not do this and are not intended to be abi
> compatible with C.
>
>> Or do I have to interprete what I read a while ago "we just need
>> to copy the libraries to the store" as literally "if we encounter
>> no Cargo.toml, let's copy everything to the store as is"?
>
> If we encounter no Cargo.lock file it generally means the above.
>

Thanks for your answer.

But, ouch... note to self, packaging while hanging out with other
people to watch streamed talks sometimes does not work out.
The actual failure is different, the build system (currently)
expects a Cargo.toml everywhere, and the folder `libc-test'
doesn't seem to have one, breaking the build phase.

phase `unpack' succeeded after 0.1 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded after 0.0 seconds
starting phase `patch-source-shebangs'
patch-shebang: ./ci/docker/arm-linux-androideabi/accept-licenses.sh: warning: 
no binary for interpreter `expect' found in $PATH
patch-shebang: ./ci/docker/arm-linux-androideabi/install-ndk.sh: changing 
`/bin/sh' to `/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
patch-shebang: ./ci/docker/arm-linux-androideabi/install-sdk.sh: changing 
`/bin/sh' to `/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
patch-shebang: ./ci/dox.sh: changing `/bin/sh' to 
`/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
patch-shebang: ./ci/run.sh: changing `/bin/sh' to 
`/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh'
phase `patch-source-shebangs' succeeded after 0.0 seconds
starting phase `configure'
phase `configure' succeeded after 0.0 seconds
starting phase `patch-generated-file-shebangs'
patch-shebang: ./ci/docker/arm-linux-androideabi/accept-licenses.sh: warning: 
no binary for interpreter `expect' found in $PATH
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `build'
error: failed to read 
`/tmp/guix-build-rust-libc-0.2.18.drv-0/libc-0.2.18/libc-test/Cargo.toml`

Caused by:
  No such file or directory (os error 2)
phase `build' failed after 0.5 seconds
builder for `/gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv' 
failed with exit code 1
@ build-failed /gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv 
- 1 builder for 
`/gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv' failed with 
exit code 1
guix build: error: build failed: build of 
`/gnu/store/wcn4kyhfmp6pi8kdpssdc3k90hkwwhrp-rust-libc-0.2.18.drv' failed


-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Staging freeze

[John Darrington]

On Tue, Dec 27, 2016 at 11:13:05PM -0500, Leo Famulari wrote:
 On Tue, Dec 27, 2016 at 06:56:44PM -0500, Leo Famulari wrote:
 > On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
 > > The last staging branch was merged into the master branch on December
 > > 11.
 > > 
 > > According to the 3 week staging cycle we are trying to adhere to [0],
 > > this would mean we freeze the current branch on December 25 and try to
 > > merge it on January 1.
 > > 
 > > These dates are inconvenient for many people. I propose we freeze the
 > > branch and start building on December 27, and try to merge on January 
3.
 > 
 > And the build failures are rolling in :)
 > 
 > https://hydra.gnu.org/eval/109410?full=1=master#tabs-now-fail
 
 The 'qemu-image' build failed due to a lack of disk space, presumably on
 the VM image file:
 
 --
 registering closures...
 error: setting journal mode: database or disk is full
 ERROR: In procedure scm-error:
 ERROR: failed to register store items "/xchg/system"
 --
 https://hydra.gnu.org/build/1741220
 
 Any advice? I'm not sure where to start looking in the code.

For what it's worth, I find that building *anything* related to qemu fails
for different reasons in about 2/3 attempts. So I think there is a 
fundamental, yet to be diagnosed problem.

Would it be worth restarting the build and crossing fingers?

J'



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature