Re: Staging freeze
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&compare=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
Re: rust: cargo build-system: how to handle libraries
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: rust: cargo build-system: how to handle libraries
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: [PATCH] Add r-scran 1.2.0 and all its dependencies
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
> 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 1/2] gnu: libmtp: Grant "audio" group access to device files.
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: [PATCH 2/2] gnu: multiqc: Update to 0.8.
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 >
rust: Crate Dependencies
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)
Rust packages I am working on - read or reply to prevent duplicate work
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
Re: GuixSD + StumpWM
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,
Re: Shutdown of googlecode end of the year - we have affected packages!
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
rustc (rust and cargo): Update to 1.14.0
[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.
[PATCH] gnu: rustc: Update to 1.14.0.
* 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
staging: django fails to build
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'... Destroying
Re: Chicken security bugs [was Re: [pe...@more-magic.net: Irregex packages should be updated to 0.9.6]]
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 0.9.6, which fixes an exponential
++explosion in compilation of nested "+" patterns.
++
+ - Compiler:
+ - Fixed incorrect argvector restoration after
Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)
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: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)
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
Re: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)
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, 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: Dependencies of pagure, revision of 2016-12-21
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.)
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: Bad signature on commit 6a34f4ccc8a5d (gnu: python-prompt-toolkit: Update to 1.0.9.)
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.)
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.)
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
