David Craven writes:
>> If the attacker *is* vendor who supplies the proprietary device then they
>> would
>> not have to reverse engineer it.
>
> You can always choose not to apply the vendors update. If for example
> the company you initially trusted with by purchasing their
Hi again :)
l...@gnu.org (Ludovic Courtès) writes:
> Howdy!
>
> Maxim Cournoyer skribis:
>
>> Ricardo Wurmus writes:
>>
>>> Ludovic Courtès writes:
>>>
Those who didn’t have the luck to be at FOSDEM missed this not-so-visual
Hello Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Hi Maxim,
>
> Maxim Cournoyer skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> myglc2 skribis:
>>>
On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>
>>> [...]
>>>
> Could
On Tue, Feb 14, 2017 at 12:28:28AM +0100, Mekeor Melire wrote:
> From 04f94c306f99a7bacc96b60ed60e9bb83a9cf767 Mon Sep 17 00:00:00 2001
> From: Mekeor Melire
> Date: Tue, 14 Feb 2017 00:21:08 +0100
> Subject: [PATCH] gnu: Add dzen.
>
> * gnu/packages/xdisorg.scm (dzen):
From 04f94c306f99a7bacc96b60ed60e9bb83a9cf767 Mon Sep 17 00:00:00 2001
From: Mekeor Melire
Date: Tue, 14 Feb 2017 00:21:08 +0100
Subject: [PATCH] gnu: Add dzen.
* gnu/packages/xdisorg.scm (dzen): New variable.
---
gnu/packages/xdisorg.scm | 48
> Is the vendor always trustworthy?
I agree with you. But the thing is that we already bought the device.
It says on the label that the device does A and only A at time x when
we bought the device. The question is do we need to add more trust
than that to the equation.
If we look at security as
Leo Famulari wrote:
> GNU Guix is discussing the possibilities created by Savannah's
> offering of Git-over-HTTPS:
...
> If anyone from Savannah has anything to add to the discussion, feel
> free to jump in :)
Thanks for the invite! I'll jump in. :-)
I am not subscribed. Please CC me on
On Thu, Feb 09, 2017 at 06:36:09PM +, ng0 wrote:
> today I had a short message exchange with the hoster "IN-Berlin"[0], a
> non-commercial group predating the widespread access of internet in
> Germany.
>
> It turns out that it could be as simple as providing them with the raw
> disk image,
On Wed, 08 Feb 2017 12:17:31 +0100
l...@gnu.org (Ludovic Courtès) wrote:
> Hello!
>
> Minor issues:
>
> Julien Lepiller skribis:
>
> > +(synopsis "Feature-full driver for OCaml AST transformers")
> > +(description "A driver is an executable created from a set of
>
Am 13.02.2017 um 20:24 schrieb David Craven:
> You can always choose not to apply the vendors update.
Is the vendor always trustworthy?
Think about vulnerabilities in e.g. router firmware from companies like
Cisco and Juniper, which were undiscovered for a long time – and one can
reasonably
> "Mark was completely right - it's total BS".
Well I did some work on running guixsd on arm, part of which involved
trying to make the linux-libre package more extensible. Mark
criticized it as not being very well thought out, and I found that it
was not very extensible.
Coming from a
Sorry, I just came by to this topic, and I'm somewhat interested in the
context of the phrase "Mark was completely right - it's total BS".
> Students, mentors, and hackers: please discuss your ideas on this list
> and add them to the wiki page!
RISCV port.
I've made a lot of progress on the bootloader stuff. I'll be posting patches
for commenting soon.
I have a riscv toolchain up and running and it boots the riscv-linux. I rewrote
Marius Bakke writes:
> 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
Mathieu Lirzin writes:
> Hello,
>
> GNU is applying as an organization for Google Summer of Code 2017. So
> this is time to start gathering ideas for possible Guix/Shepherd related
> projects.
>
> I have created a page based on the one from last year:
>
>
On Fri, Oct 28, 2016 at 08:36:06PM +0300, Theodoros Foradis wrote:
> * gnu/packages/embedded.scm (openocd): New variable.
> * gnu/packages/patches/openocd-nrf52.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add the patch.
FYI, there is a new release of OpenOCD. Would anyone like to try
> If the attacker *is* vendor who supplies the proprietary device then they
> would
> not have to reverse engineer it.
You can always choose not to apply the vendors update. If for example
the company you initially trusted with by purchasing their device gets
bought by another company or you
On Mon, Feb 13, 2017 at 04:08:00PM +0100, Ludovic Courtès wrote:
> In general, I think we can agree on reverting changes that break the
> tests until a solution is proposed (and once the original author has
> been notified, of course). That sounds like reasonable policy to me.
>
> Thoughts?
I
Hi Andy, and thank you for your detailed answer!
Andy Wingo writes:
> Hi :)
>
> [+guile-devel]
>
> On Mon 13 Feb 2017 07:18, Maxim Cournoyer writes:
>
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or
On 02/13/2017 at 14:05 Ludovic Courtès writes:
> Hi Maxim,
>
> Maxim Cournoyer skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> myglc2 skribis:
>>>
On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>
>>> [...]
>>>
> Could it be
Ludovic Courtès writes:
> Christopher Allan Webber skribis:
>
>> (let* ((out (assoc-ref %outputs "out"))
>> -(module-dir (string-append out "/share/guile/site/2.0"))
>> +(module-dir (string-append out "/share/guile/site/"
>> +
It doesn't make sense to run non-test executables (which is what "dub run"
would do).
The "check" function already invokes "dub test" and that's enough.
* guix/build/dub-build-system.scm (build): Remove "dub run" invocation.
---
guix/build/dub-build-system.scm | 4 +---
1 file changed, 1
Andy Wingo writes:
> In some future (is it near or far?), the source -> compiled function
> needs additional inputs: checksums or timestamps of "build inputs" or
> so, so that when for-syntax definitions (like macros) change, users of
> those definitions will recompile. That is a harder problem
On 17-02-13 15:35:25, Ludovic Courtès wrote:
> ericbav...@openmailbox.org skribis:
>
> > From: Eric Bavier
> >
> > * website/www/packages.scm (git-description): New variable.
> > (location-url): Include "?id=..." if possible.
>
> Looks like a good idea, please push!
>
>
Hello,
Federico Beffa skribis:
> On Sat, Feb 11, 2017 at 6:15 PM, David Craven wrote:
>> Hi!
>>
>>> Revert "import: json: Explicitly ask for JSON data."
>>> This reverts commit 81e0bc1834490a1a8092c75a0733b15c2b407285.
>>
>> I reverted this commit in my local
ng0 skribis:
> we have 20 - 25 fonts (I didn't really count), and only 2 are using a
>
> system* make args
>
> in their build phase, every other font just extracts, creates folders
> and copies the fonts to the folders.
> This is much repetition which could be avoided
José Miguel Sánchez García skribis:
> From 8b9659a427ef460d91a985a4d014bef05a0341d8 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:26:42 +0100
> Subject: [PATCH] gnu: Add
rsiddharth skribis:
> * gnu/packages/haskell.scm (ghc-hslogger): New variable.
[...]
> +(home-page "http://software.complete.org/hslogger;)
> +(synopsis "Logging framework for Haskell, similar to Python's logging
> module")
> +(description "Lets each log
Sergei Trofimovich skribis:
> ghc stopped using libedit (via editline) in 2009:
>
> https://git.haskell.org/ghc.git/commitdiff/46aed8a4a084add708bbd119d19905105d5f0d72
>
> * gnu/packages/haskell.scm (ghc, ghc-8): remove 'libedit' input
Good catch. Applied, thanks!
Ludo’.
Julien Lepiller skribis:
> * gnu/packages/python.scm (python-openid): New variable.
LGTM, thanks!
José Miguel Sánchez García skribis:
> From 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
ericbav...@openmailbox.org skribis:
> From: Eric Bavier
>
> * website/www/packages.scm (git-description): New variable.
> (location-url): Include "?id=..." if possible.
Looks like a good idea, please push!
Thanks,
Ludo'.
Hi Chris,
Sorry for the late reply!
Christopher Allan Webber skribis:
> (let* ((out (assoc-ref %outputs "out"))
> -(module-dir (string-append out "/share/guile/site/2.0"))
> +(module-dir (string-append out "/share/guile/site/"
>
Danny Milosavljevic skribis:
> * guix/build/dub-build-system.scm (build): Modify.
Please describe the actual modification, like “Remove "dub run"
invocation.”
Also, please explain the change somewhere: either as a comment in the
code, if you think someone might wonder
Howdy!
Maxim Cournoyer skribis:
> 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. :-)
Hi Maxim,
Maxim Cournoyer skribis:
> 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
Leo Famulari skribis:
> 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:
Hello,
Hartmut Goebel skribis:
> 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
* guix/build/dub-build-system.scm (build): Modify.
---
guix/build/dub-build-system.scm | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/guix/build/dub-build-system.scm b/guix/build/dub-build-system.scm
index 7c7cd8803..b2cb02e63 100644
--- a/guix/build/dub-build-system.scm
"pelzflorian (Florian Pelz)" skribis:
> On 02/12/2017 06:01 PM, Hartmut Goebel wrote:
>> Am 12.02.2017 um 15:37 schrieb David Craven:
>>> I think that it is a minor
>>> issue at best, since anything that isn't accessible over the network or
>>> running
>>> with any
* guix/build/dub-build-system.scm (build): Modify.
---
guix/build/dub-build-system.scm | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/guix/build/dub-build-system.scm b/guix/build/dub-build-system.scm
index 7c7cd8803..b2cb02e63 100644
--- a/guix/build/dub-build-system.scm
Just as a note, there was this talk at the Fosdem and I think it adds some
bits I had missed (mostly because I don' t know nodejs)
http://ftp.osuosl.org/pub/fosdem/2017/K.4.601/deploying_npm_packages_with_nix.vp8.webm
From: Huang Ying
* gnu/services/dict.scm (): Rename databases
to items to reflect more general configuration.
(): Add new record type to describe handler (module).
(): Add more fields.
(dicod-configuration-file): Support convert more configuration items
to
On Sun, Feb 12, 2017 at 10:18:02PM +0100, Ludovic Courtès wrote:
> Manolis Ragkousis skribis:
>
> > Locally on Hurd I am using this patch
> > http://paste.lisp.org/display/338954 on the glibc/hurd package to work
> > around that test failure. Ideally we need to modify the
On Sat, Feb 11, 2017 at 06:15:08PM +0100, David Craven wrote:
Hi!
> Revert "import: json: Explicitly ask for JSON data."
> This reverts commit 81e0bc1834490a1a8092c75a0733b15c2b407285.
I reverted this commit in my local repository for now, it breaks the
pypi,
On Sat, Feb 11, 2017 at 6:15 PM, David Craven wrote:
> Hi!
>
>> Revert "import: json: Explicitly ask for JSON data."
>> This reverts commit 81e0bc1834490a1a8092c75a0733b15c2b407285.
>
> I reverted this commit in my local repository for now, it breaks the
> pypi, crate and some
On Sun, Feb 12, 2017 at 11:02:29PM -0800, Maxim Cournoyer wrote:
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.
>>
On Sun, Feb 12, 2017 at 02:59:57PM +0100, Ludovic Courtès wrote:
> 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,
On Fri, Feb 10, 2017 at 5:18 PM, Ludovic Courtès wrote:
> Hello!
>
> Federico Beffa skribis:
>
>> +(define* (package-with-explicit-compiler compiler bs-name
>> + old-prefix new-prefix
>> +
49 matches
Mail list logo