Hi Mark,
Mark H Weaver skribis:
> That the scanner fails to find all references is clearly an important
> problem that should be fixed ASAP, but as far as I can tell, improving
> the grafter would not make that problem any worse or create any new
> problems.
>
> Improving the grafter should have
Hi Mark, hi Ludo,
> After applying the patch you sent, I confirm that Nyxt starts just fine
> when running:
>
> ./pre-inst-env guix environment --ad-hoc nyxt -CN -E ^DISPLAY
> --share=/tmp/.X11-unix -- nyxt
>
> … whereas on master it fails to start with:
>
> --8<---cut here-
On Mon, 2021-04-05 at 21:54 +0200, Ludovic Courtès wrote:
> [...]
>
> OK. It does mean that the bug is hardly exploitable in practice: you
> have to be able to log in at all,
Yes.
> and if you’re able to log in, you have
> to log in precisely within the 1s (or less) that follows account
> creat
Hi,
Ludovic Courtès skribis:
>> chino@asus-laptop:~$ guix build opencv
>> --substitute-urls="https://mirror.sjtu.edu.cn/guix
>> https://mirror.guix.org.cn https://mirror.c1r3u.xyz https://ci.guix.gnu.org";
>> substitute: updating substitutes from 'https://mirror.sjtu.edu.cn/guix'...
>> 100.0%
On my system, Racket 8.0 contains a *.zo file that contains a *chunked*
store reference. As a result, it retains a reference to the ungrafted
Gtk+, and therefore to the ungrafted glib, cairo, and libx11.
The file is:
/gnu/store/…-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/compil
I am no expert cryptographer, it is likely that if I try backporting
such patches I will get something wrong that introduces more flaws.
https://security-tracker.debian.org/tracker/CVE-2021-20305 - no patch
backported yet
https://packages.ubuntu.com/source/focal/nettle - no patch backported
either
Here's a revised draft of the patch, which updates the comments and
refactors the code a bit to (hopefully) make it a bit more readable.
Mark
>From 6eec36e66d20d82fe02c6de793422875477b90d8 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Fri, 2 Apr 2021 18:36:23 -0400
Subject: [PATCH] D
Hi Maxime,
Maxime Devos skribis:
> On Mon, 2021-04-05 at 21:54 +0200, Ludovic Courtès wrote:
>> [...]
>>
>> OK. It does mean that the bug is hardly exploitable in practice: you
>> have to be able to log in at all,
> Yes.
>
>> and if you’re able to log in, you have
>> to log in precisely withi
On Thu, 01 Apr 2021, Ben Sturmfels wrote:
> 5. Get a basic Guix service working, with sqlite3 and without the
> offloaded media transcoding currently using Celery task queue with a
> Redis broker.
Woo! After a lot of trial and error, I finally have a basic MediaGoblin
running entirely under Guix
On Mon, 05 Apr 2021, Léo Le Bouter wrote:
> On Tue, 2021-04-06 at 00:17 +1000, Ben Sturmfels wrote:
>> On Thu, 01 Apr 2021, Ben Sturmfels wrote:
>>
>> > 7. Work out why H264 support is missing.
>>
>> This is now fixed MediaGoblin's master branch guix-env.scm by adding
>> gst-libav to propagated
Hi Leo!
Leo Prikler writes:
[...]
>> Shouldn't we wrap all the binaries to be on the safe side? Things
>> such
>> as emacsclient probably ought to have EMACSLOADPATH set correctly,
>> no?
> The remaining binaries are
> - emacsclient, which inherits its EMACSLOADPATH from the server it
> connec
Hi,
For the record, changing ‘qt-build-system’ would trigger a rebuild of
less than 400 packages according to the back-of-the-envelope calculation
below. In that case, it’s tempting to fix on ‘master’ and include it in
the release.
Thoughts?
Ludo’.
--8<---cut here---sta
On Tue, Apr 06, 2021 at 03:17:52PM +0200, Ludovic Courtès wrote:
> Hi,
>
> For the record, changing ‘qt-build-system’ would trigger a rebuild of
> less than 400 packages according to the back-of-the-envelope calculation
> below. In that case, it’s tempting to fix on ‘master’ and include it in
> t
divoplade writes:
> Le lundi 05 avril 2021 à 19:45 +0100, Pierre Langlois a écrit :
>> Do you know at which guix commit this happened? I'm wondering which
>> version of libvirt triggered this. AFAICT, right now, if you create
>> a
>> fresh VM using gnome-boxes, it initializes the xml config wit
On Tue, Apr 06, 2021 at 04:43:46PM +0300, Efraim Flashner wrote:
> On Tue, Apr 06, 2021 at 03:17:52PM +0200, Ludovic Courtès wrote:
> > Hi,
> >
> > For the record, changing ‘qt-build-system’ would trigger a rebuild of
> > less than 400 packages according to the back-of-the-envelope calculation
> >
Hi Leo et al.,
Leo Famulari writes:
> On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote:
>> I see now that I'm using an older version, although I would have
>> preferred the newer one. I refer to the variable name 'inkscape' from
>> my manifest file, and I expected that to point to
Hello Guix!
I had this surprise today, after reconfiguring my Guix System with an
upgraded docker:
Upon attempting to run an existing container created with the previous
Docker version, I got:
--8<---cut here---start->8---
ERROR: for moodle-docker_db_1 Cannot
Below, --do-not-upgrade appears to be behaving like "--only-upgrade". I realised
this comes about because I didn't use '='. guix upgrade takes all other
arguments to be upgrade regex's, but it still seems. _wrong_. Some long
arguments in guix require and = sign after them, and the cli help indicat
Hi Maxim!
Am Dienstag, den 06.04.2021, 08:09 -0400 schrieb Maxim Cournoyer:
> Hi Leo!
>
> Leo Prikler writes:
>
> [...]
>
> > > Shouldn't we wrap all the binaries to be on the safe
> > > side? Things
> > > such
> > > as emacsclient probably ought to have EMACSLOADPATH set
> > > correctly,
> >
CVE-2021-30046 15:15
VIGRA Computer Vision Library Version-1-11-1 contains a segmentation
fault vulnerability in the impex.hxx read_image_band() function, in
which a crafted file can cause a denial of service.
Upstream issue: https://github.com/ukoethe/vigra/issues/494
No fix provided yet.
sig
On Mon, Apr 05, 2021 at 09:45:43PM +0200, Ludovic Courtès wrote:
> The GC’s scanner still gets it wrong though. I wonder whether having
> the grafting code more capable than the scanner could lead to bad
> surprises. WDYT?
I'm going off-topic, but I've wished we had a generic fast string-search
I think that probably replacing arbitrary paths in built binaries is a
risky and maybe unreliable engineering choice and that mechanisms
inside kernels should be preferred to give processes a different view
of the file system (retaining the path but changing the contents of the
folder).
OTOH, what
Hi again!
The attached patch fixes this problem AFAICS by filtering out of
XDG_DATA_DIRS directories that are unlikely to be of any use. It
follows the same strategy as ‘glib-or-gtk-build-system’, which is to
only include share/ sub-directories that also contain one of the given
“selectors”: /gli
On Tue, Apr 06, 2021 at 03:17:52PM +0200, Ludovic Courtès wrote:
> Hi,
>
> For the record, changing ‘qt-build-system’ would trigger a rebuild of
> less than 400 packages according to the back-of-the-envelope calculation
> below. In that case, it’s tempting to fix on ‘master’ and include it in
> t
Hello Simon,
zimoun writes:
> Hi,
>
> Using Guix 55685e4, I get:
>
> $ guix build -S --no-substitutes runc
> The following derivations will be built:
>/gnu/store/19iqvzkdx514xm8hs5sn2clcn5pvfswm-runc-1.0.0-rc6.tar.xz.drv
>/gnu/store/ml7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.
Read:
https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/
I have not had time to investigate deeply, posting here so the info is
not lost. I have already fixed one issue related to perl-data-validate-
ip in 8ec03ed5475ca7919a7d11541ff8cbf33a9ffe67, but it seems there's
se
September 14, 2020 1:36 AM, "Timotej Lazar" wrote:
> I tried [1] and it works with `sxiv -a` here. What does `file
> picture.gif` say for your file?
Thank you for pointing me in the right direction. I had an mp4 named as
a gif! mpv could play it as-is, so I thought sxiv was to blame. Consider
this
On Mon Sep 21, 2020 at 2:22 AM CDT, Efraim Flashner wrote:
> On Thu, Sep 17, 2020 at 11:36:21PM -0500, bdju via Bug reports for GNU
> Guix wrote:
> > My PDFs are opening in GIMP! I went to fix it, but it seems I don't have
> > a generated zathura.desktop file.
> > guix (GNU Guix) 679d5e6b3dcac4ee1f
On Fri Oct 2, 2020 at 3:50 PM CDT, Ludovic Courtès wrote:
> Hi bdju,
>
> "bdju" skribis:
>
> > It seems just the debug symbols for dino weren't quite enough to get
> > good info. I also need debug symbols for the other dependencies. For
> > sure glib or libglib, whichever it is. If there are other
Hi Léo,
Léo Le Bouter writes:
> I think that probably replacing arbitrary paths in built binaries is a
> risky and maybe unreliable engineering choice and that mechanisms
> inside kernels should be preferred to give processes a different view
> of the file system (retaining the path but changing
Hi Leo,
Leo Famulari writes:
> While using `guix system vm`, I noticed this warning. I think it's new,
> maybe from the 5.2.0 update?
>
> --
> qemu-system-x86_64: warning: 9p: degraded performance: a reasonable
> high msize should be chosen on client/guest side (chosen msize is <=
> 8192). S
On Tue Dec 22, 2020 at 10:34 AM CST, Michael Rohleder wrote:
> Hello bdju,
>
> "bdju" writes:
> > guix (GNU Guix) 91e35e32a4938e0e37499c64fa8ed3e7cf51dce3
> > some example sites with browser checks:
> > https://gitlab.com/users/sign_in
> > http://livechart.me/
> >
> > I already contacted the peopl
On Tue Apr 6, 2021 at 4:41 PM CDT, bdju wrote:
> While I was able to bypass the cloudflare checks in IceCat with that
> User Agent Switcher addon, I found I so far haven't been able to get
> past them in qutebrowser by changing my useragent. I tried both your
> example and copying one of the userag
On Tue, Apr 06, 2021 at 05:42:15PM -0400, Maxim Cournoyer wrote:
> From c720e68229322e5c38c0321b021e8d6430636111 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer
> Date: Tue, 6 Apr 2021 17:37:33 -0400
> Subject: [PATCH] system: vm: Set a larger value for the msize option of the 9p
> file system.
On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote:
> Hi Léo,
>
> Léo Le Bouter writes:
>
> > I think that probably replacing arbitrary paths in built binaries
> > is a
> > risky and maybe unreliable engineering choice and that mechanisms
> > inside kernels should be preferred to give proces
CVE-2021-21404 06.04.21 22:15
Syncthing is a continuous file synchronization program. In Syncthing
before version 1.15.0, the relay server `strelaysrv` can be caused to
crash and exit by sending a relay message with a negative length field.
Similarly, Syncthing itself can crash for the same reason
FYI, since updating to webkitgtk-2.32.0 (commit
3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no
window appears, although GNOME Shell shows an empty outline in overview
mode, as if there's a window but it has never been painted.
When running 'epiphany' from the command line,
On Wed, Apr 07, 2021 at 12:40:03AM +0200, Léo Le Bouter via Bug reports for GNU
Guix wrote:
> CVE-2021-2140406.04.21 22:15
> Syncthing is a continuous file synchronization program. In Syncthing
> before version 1.15.0, the relay server `strelaysrv` can be caused to
> crash and exit by send
retitle 47628 webkitgtk-2.32.0 is broken on my system
thanks
Mark H Weaver writes:
> FYI, since updating to webkitgtk-2.32.0 (commit
> 3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no
> window appears, although GNOME Shell shows an empty outline in overview
> mode, as if t
Hi Leo,
Leo Famulari writes:
> On Mon, Apr 05, 2021 at 09:45:43PM +0200, Ludovic Courtès wrote:
>> The GC’s scanner still gets it wrong though. I wonder whether having
>> the grafting code more capable than the scanner could lead to bad
>> surprises. WDYT?
>
> I'm going off-topic, but I've wis
Hi Leo!
Leo Famulari writes:
> On Tue, Apr 06, 2021 at 05:42:15PM -0400, Maxim Cournoyer wrote:
>> From c720e68229322e5c38c0321b021e8d6430636111 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer
>> Date: Tue, 6 Apr 2021 17:37:33 -0400
>> Subject: [PATCH] system: vm: Set a larger value for the m
Ah, I see the thread for https://issues.guix.gnu.org/47614 wasn't cc'ed
here:
Forwarded Message
Subject: Re: Racket 8 and store references (was [security] Chunked store
references in .zo files in Racket 8 #47614)
Date: Tue, 6 Apr 2021 21:38:57 -0400
From: Philip McGrath
To:
42 matches
Mail list logo
