Re: Fixing non-reproducibility in some guile packages

Hi :) [+guile-devel] On Mon 13 Feb 2017 07:18, Maxim Cournoyer writes: >>> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 >>> ;;; or pass the --no-auto-compile argument to disable. >>> ;;; compiling >>>

Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.

Hi, Christopher Howard writes: > On 02/10/2017 08:31 AM, David Craven wrote: >> Hi Maxim >> >>> +1. I don't see how having blobs helps security at all. >> >> Well the problem I was getting at is that things are not as fixed as >> they may seem. >> Quoting wikipedia:

Re: [PATCH 2/3] gnu: Add libfilezilla.

Hi, ren...@openmailbox.org writes: > Hello Maxim, > > On 2017-02-12 20:26, Maxim Cournoyer wrote: >> Hi, >> > offering/offers/ or s/offering/provides/ >> >>> +(license gpl3+))) >> >> Only license information I could find is the COPYING file which is >> GPLv2. I think gpl2+ would be more

Re: Fixing non-reproducibility in some guile packages

Hi! Christopher Allan Webber writes: > Jan Nieuwenhuizen writes: > >> While building guile2.2-gdbm-ffi an error is printed that does not >> prevent the package from being built >> >> @ build-started >>

Re: [PATCH 2/3] gnu: Add libfilezilla.

Hello Maxim, On 2017-02-12 20:26, Maxim Cournoyer wrote: Hi, offering/offers/ or s/offering/provides/ +(license gpl3+))) Only license information I could find is the COPYING file which is GPLv2. I think gpl2+ would be more appropriate. grepping libfilezilla directory, i see glp2

Re: [PATCH 3/3] gnu: Add filezilla.

Hi, rennes writes: > * gnu/packages/ftp.scm (filezilla): New variable. > --- > gnu/packages/ftp.scm | 48 +++- > 1 file changed, 47 insertions(+), 1 deletion(-) > > diff --git a/gnu/packages/ftp.scm b/gnu/packages/ftp.scm >

Re: [PATCH 2/3] gnu: Add libfilezilla.

Hi, rennes writes: > * gnu/packages/ftp.scm (libfilezilla): New variable. > --- > gnu/packages/ftp.scm | 24 > 1 file changed, 24 insertions(+) > > diff --git a/gnu/packages/ftp.scm b/gnu/packages/ftp.scm > index 7380fcfc3..0fef1b160 100644 >

Re: Archive authentication & ‘guix challenge’

Hello, l...@gnu.org (Ludovic Courtès) writes: > myglc2 skribis: > >> On 02/09/2017 at 17:36 Ludovic Courtès writes: > > [...] > >>> Could it be that the ‘guix archive’ you ran uses a configuration >>> directory other than this one? What does: >>> >>> guile -c '(use-modules

Re: Running services in containers

Hi! Ricardo Wurmus writes: > Ludovic Courtès writes: > >> Those who didn’t have the luck to be at FOSDEM missed this not-so-visual >> demo I made of a Shepherd service running in a container. :-) >> >> I’ve polished the thing on my way back and pushed the

Re: Commits signed by key not registered on Savannah

On Sun, Feb 12, 2017 at 04:55:14PM -0500, Mark H Weaver wrote: > David Craven writes: > > The integrity of our source code is given by peer review - we are > > subscribed to the commits ML so we see other peoples commits. > > If we're concerned about security (and we should be),

Re: Commits signed by key not registered on Savannah

David Craven writes: > The integrity of our source code is given by peer review - we are > subscribed to the commits ML so we see other peoples commits. If we're concerned about security (and we should be), then we should not rely on the commits mailing list (or any web

Re: [PATCH] gnu: ffmpeg: Build with SDL support.

Arun Isaac writes: > SDL is required for the `ffplay' executable to be built. > > * gnu/packages/video.scm (ffmpeg)[inputs]: Add sdl2. This increases ffmpegs closure size from 518.9 MiB to 525.7 MiB, which seems fine to me. If no one objects I will push this tomorrow

Re: server and client in one package -> security issue

Am 12.02.2017 um 13:53 schrieb David Craven: > By development files I assume you mean header files? I don't see how those can > pose a security problem. Can you elaborate? Yes, I meant header files, but also pkgconfig files and all this stuff (including documentation). Having this (and compilers,

FAIL: tests/cpan.scm, tests/gem.scm, tests/pypi.scm, tests/crate.scm

After merging a very recent master, I get four test failures when running make check: FAIL: tests/pypi.scm FAIL: tests/cpan.scm FAIL: tests/gem.scm FAIL: tests/crate.scm Looking in test-suite.log there is the rather odd messge: actual-value: #f actual-error: + (wrong-number-of-args + #f +

Re: Auditing CPE names

On Sat, Feb 11, 2017 at 02:53:46PM -0500, Leo Famulari wrote: > It's important to name the package in accordance with the CPE or set > the cpe-name property, or else `guix lint -c cve` won't work for that > package. In commit 84b60a7cdfc (gnu: lcms: Fix an out-of-bounds read.) I tried to set the

Re: Auditing CPE names

Leo Famulari skribis: > I wonder if anyone checks the Common Platform Enumeration (CPE) names of > new packages when creating them? > > It's important to name the package in accordance with the CPE or set > the cpe-name property, or else `guix lint -c cve` won't work for that

Re: Add murmur.

> You read too much between the lines in my words. > I'm not counting on the certifications of Harmut. I simply agree with > the reasoning that no client and server should be combined if possible > to limit the attack surface. That's all. That may be true. It was my intention to back Ludo. I

How to M-x debbugs-gnu with new guix-patches

So! We have a new debbugs tracking of guix-patches. Great! Those who are emacs users in the know probably like to use the M-x debbugs-gnu interface. Here's what you need to do: Add this to your .emacs: (add-to-list 'debbugs-gnu-all-packages "guix-patches") Now open up debbugs-gnu: C-u

Re: [PATCH 1/1] gnu: screen: Fix CVE-2017-5618.

Leo Famulari skribis: > * gnu/packages/patches/screen-CVE-2017-5618.patch: New file. > * gnu/local.mk (dist_patch_DATA): Add it. > * gnu/packages/screen.scm (screen)[source]: Use it. LGTM, thank you! Ludo'.

New guix-patches mailing list hooked to Debbugs!

Hello Guix! We now have a new guix-patc...@gnu.org mailing list hooked to Debbugs to handle patches! https://bugs.gnu.org/guix-patches https://lists.gnu.org/mailman/listinfo/guix-patches You’re welcome to subscribe to it right away. Patches should now be sent to guix-patc...@gnu.org,

Re: [PATCH] gnu: Add tftp-hpa.

Hello! #1 A post on the list cought my attention regarding security of packages with both server and client. I think that should also apply to this package. I am waiting for follow ups on that. #2 I have discussed the licensing issues with Thomas Danckaert, but waiting for confirmation wether the

Re: Debbugs handling of Guix patches

Glenn Morris skribis: > I see you got this sorted out, so I've now completed the debbugs part. > It may take an hour or so for the mailing list redirection to take effect. It seems to be working now: https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix-patches Thanks, Glenn!

Re: Add murmur.

On 17-02-12 14:57:05, David Craven wrote: > > Okay. I prefer to wait for the outcome of the discussion around > > server+client merging. I'm in favor of separating for the reasons Harmut > > mentioned. > > This is a free software community. Anyone that needs to assert his authority > with

Re: Announcement regarding the oss-security mailing list

Hi Leo, Leo Famulari skribis: > I look at the lwn.net security advisories, the Debian security-announce > mailing list, `guix lint -c cve`, the upstream bug trackers of a handful > of packages, and even some Twitter personalities. For me it’s mostly oss-sec, LWN, and ‘guix

Re: Add murmur.

> Okay. I prefer to wait for the outcome of the discussion around > server+client merging. I'm in favor of separating for the reasons Harmut > mentioned. This is a free software community. Anyone that needs to assert his authority with external certifications rather than actions and sound

Re: Add murmur.

On 17-02-12 14:37:53, Ludovic Courtès wrote: > ng0 skribis: > > > On 17-02-11 15:31:15, Ludovic Courtès wrote: > >> ng0 skribis: > > [...] > > >> > As far as I know right now, it does not have any graphical features or > >> > dependencies.

Re: bug#25463: guile-2.0.13 Check errors

Hello Renes, On 02/12/17 10:37, ren...@openmailbox.org wrote: > Now the following error is left: > > Running time.test > FAIL: time.test: internal-time-units-per-second: versus times and sleep > Running tree-il.test > > Totals for this test run: >

Re: Commits signed by key not registered on Savannah

Hi! The idea that I had while trying to see how to map TUF to Git¹ was to store keys in the Git repo we’re authenticating. We’d store a list of “authorized keys” for each “role” that we define. One of the roles would be “update the authorized committer keys”, for instance. Thus, to

Re: Add murmur.

ng0 skribis: > On 17-02-11 15:31:15, Ludovic Courtès wrote: >> ng0 skribis: [...] >> > As far as I know right now, it does not have any graphical features or >> > dependencies. >> > >> > mumble:murmur -> total: 1072.6 MiB >> > mumble:out

Re: `guix pull` over HTTPS

Ricardo Wurmus skribis: > Leo Famulari writes: > >> However, I think that pulling code over HTTPS using a certificate store >> like nss-certs or from the host distro is a huge improvement over what >> we have now. If we can do that sooner, we should. > >

Re: server and client in one package -> security issue (was: Add murmur)

> And from my point of view Guix already has a medium problem of acceptance > since it munges development-files and run-time files into one package - as we > do for all libraries. By development files I assume you mean header files? I don't see how those can pose a security problem. Can you

Re: server and client in one package -> security issue (was: Add murmur)

On 17-02-12 13:23:09, Hartmut Goebel wrote: > Am 09.02.2017 um 23:50 schrieb Ludovic Courtès: > > I think the only reason to separate things usually is size, not > > “aesthetics.” So I’d be in favor of keeping both in the same output if > > there’s no size problem. > > Separating clients and

Re: Commits signed by key not registered on Savannah

> Would the git repository, or a new git repository (guix-keys.git?) be a > bad idea? Best case, we craft something which serves as an GNUPG_HOME > for the keys which then live in the keyring of this thing (compare to > gentoo-keys, debian-keys, etc). I don't think that is a good idea. Placing it

[PATCH] gnu: Add simh.

-- José Miguel Sánchez GarcíaFrom 1b3ed6f71861cc59493cde95171834139317b561 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?= Date: Sun, 12 Feb 2017 12:33:49 +0100 Subject: [PATCH] gnu: Add simh. * gnu/packages/simh.scm: New