Re: Videos
Alex Vong writes: > Catonano writes: > >> 2018-05-29 17:45 GMT+02:00 Julien Lepiller : >> >> Le 2018-05-29 16:48, Ricardo Wurmus a écrit : >> >> Hi Guix, >> >> I’d like us to produce a series of short videos (< 4 mins each) that >> introduce functional package management with Guix. >> >> This is supposed to be aimed at people who are intimidated by the manual >> and wouldn’t know where to begin reading. Each of the videos should >> focus on a single feature and be on the point. The final seconds should >> point the viewer to the manual to learn more. >> >> Who would like to be involved in the planning and production of the >> videos? There are many tasks such as: >> >> * collecting topics that should be covered >> * writing canonical narration scripts for each episode >> * translating the scripts into different languages >> * recording the narrations in different languages >> * drafting the storyboard for each video (i.e. what exactly is to be >> shown and for how long) >> * recording the video portions >> * mixing different audio tracks and the video track >> * designing intro and outro frames >> * recording or finding freely licensed music for the intro / outro >> * coordinating with all volunteers >> >> What do you think? >> >> -- >> Ricardo >> >> That sounds like a great plan! Of course I'd like to be involved in >> translating >> the script into French and I could probably record a French version of the >> videos >> too. I don't have any experience in the other fields, but I guess I could >> learn. >> >> I think I have demonstrated my aptitude in recording video fragments on the >> field >> >> As for storyboarding and scripting, instead, I'd love to receive suggestions. >> >> Also, I wouldn't know how to mix audio/video. What software could we use ? >> I don't know. > > You may want to try simplescreenrecorder. I tried it before, it is > reasonably easy to use. Or, if you're using GNOME: Ctrl + Alt + Shift + R. A small red dot will appear in the upper right corner. Press the key combination again to stop the recording, and a webm video will appear in your ‘Videos’ folder. Kind regards, Roel Janssen
Re: 04/05: gnu: swig: Patch for Octave 4.4.
Hi Kei, Kei Kebreau writes: > Mark H Weaver writes: > >> Instead, I suggest creating a different 'swig' package for octave that >> inherits from the primary one and adds this patch. > > I agree that this will work. Is the attached patch something like what > you're thinking? Yes, although I have some suggestions: > From 475a7698fd4c88ea688cb43499344e65ffaf5b84 Mon Sep 17 00:00:00 2001 > From: Kei Kebreau > Date: Wed, 30 May 2018 08:34:42 -0400 > Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4. > > * gnu/packages/machine-learning.scm (swig-for-octave): New variable > * gnu/packages/machine-learning.scm (shogun)[inputs]: Replace swig with > swig-for-octave. > * gnu/packages/patches/swig-octave-patches.patch: New file. > * gnu/local.mk (dist_patch_DATA): Register patch. [...] > diff --git a/gnu/packages/machine-learning.scm > b/gnu/packages/machine-learning.scm > index e135ee0ee..4d54584a7 100644 > --- a/gnu/packages/machine-learning.scm > +++ b/gnu/packages/machine-learning.scm > @@ -365,6 +365,14 @@ value imputation, classifier creation, generalization > error estimation and > sample proximities between pairs of cases.") > (license license:gpl3+))) > > +(define swig-for-octave > + (package/inherit swig > +(name (string-append (package-name swig) "-for-octave")) > +(source > + (origin > + (inherit (package-source swig)) > + (patches (search-patches "swig-octave-patches.patch")) For the patches field, how about something like this: (patches (append (origin-patches (package-source swig)) (search-patches "swig-octave-patches.patch"))) so if someone adds a patch to swig, it will automatically get picked up by this one too. Please add a comment above the 'swig-for-octave' definition explaining what it's for. I was confused at first that you didn't change the octave definition, but now I guess that it's for other packages that wish to use octave via swig, or something along those lines? It should be good to explain in a comment. Also, I think it would be better to put the 'swig-for-octave' definition immediately after the one for 'swig', so that it's more likely to be noticed by people working on swig. This package has more connection to swig than it does to shogun. It has no direct connection to 'shogun' except that shogun is currently the only user of it. Another question: instead of adding the patch, how about changing the origin to build from a git checkout? The advantage of that is that it requires less trust from users. I look at this big patch and I wonder if I should check to make sure it matches what upstream has (I didn't). If it's a git checkout, there's less trust needed. It would also make later upgrades easier. It might also be better to call the package "swig-git" or something, dunno. What do you think? Thanks for working on it. Mark
Re: 04/05: gnu: swig: Patch for Octave 4.4.
Mark H Weaver writes:
> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 3771000f893d4b53e302f5bca07afeba69e76cd4
>> Author: Kei Kebreau
>> Date: Fri May 25 22:25:21 2018 -0400
>>
>> gnu: swig: Patch for Octave 4.4.
>
> On the core-updates branch, "guix refresh -l swig" reports that updating
> swig requires 1453 rebuilds. That's too many, so I reverted it.
>
> Instead, I suggest creating a different 'swig' package for octave that
> inherits from the primary one and adds this patch.
>
> What do you think?
>
> Mark
I agree that this will work. Is the attached patch something like what
you're thinking?
(Apologies if you get two of these messages; it seems to me like the
first one didn't go through.)
From 475a7698fd4c88ea688cb43499344e65ffaf5b84 Mon Sep 17 00:00:00 2001
From: Kei Kebreau
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.
* gnu/packages/machine-learning.scm (swig-for-octave): New variable
* gnu/packages/machine-learning.scm (shogun)[inputs]: Replace swig with
swig-for-octave.
* gnu/packages/patches/swig-octave-patches.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
---
gnu/local.mk |1 +
gnu/packages/machine-learning.scm | 10 +-
.../patches/swig-octave-patches.patch | 1119 +
3 files changed, 1129 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/swig-octave-patches.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 7734586f0..895d33012 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1106,6 +1106,7 @@ dist_patch_DATA =
\
%D%/packages/patches/steghide-fixes.patch\
%D%/packages/patches/strace-kernel-4.16.patch\
%D%/packages/patches/superlu-dist-scotchmetis.patch \
+ %D%/packages/patches/swig-octave-patches.patch \
%D%/packages/patches/swish-e-search.patch\
%D%/packages/patches/swish-e-format-security.patch \
%D%/packages/patches/synfigstudio-fix-ui-with-gtk3.patch \
diff --git a/gnu/packages/machine-learning.scm
b/gnu/packages/machine-learning.scm
index e135ee0ee..4d54584a7 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -365,6 +365,14 @@ value imputation, classifier creation, generalization
error estimation and
sample proximities between pairs of cases.")
(license license:gpl3+)))
+(define swig-for-octave
+ (package/inherit swig
+(name (string-append (package-name swig) "-for-octave"))
+(source
+ (origin
+ (inherit (package-source swig))
+ (patches (search-patches "swig-octave-patches.patch"))
+
(define-public shogun
(package
(name "shogun")
@@ -487,7 +495,7 @@ sample proximities between pairs of cases.")
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
("octave" ,octave)
- ("swig" ,swig)
+ ("swig" ,swig-for-octave)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/patches/swig-octave-patches.patch
b/gnu/packages/patches/swig-octave-patches.patch
new file mode 100644
index 0..9fb64a7b1
--- /dev/null
+++ b/gnu/packages/patches/swig-octave-patches.patch
@@ -0,0 +1,1119 @@
+This patch represents the recently added support for Octave version 4.4 found
+here:
+
+https://github.com/swig/swig/commit/12c66f9b7d884020e896ce92b9783bc3bac95d2d
+
+diff -urN swig-3.0.12.old/CHANGES.current swig-3.0.12.new/CHANGES.current
+--- swig-3.0.12.old/CHANGES.current2017-01-27 18:52:02.0 -0500
swig-3.0.12.new/CHANGES.current2018-05-26 08:40:06.501850058 -0400
+@@ -4,6 +4,14 @@
+ Issue # numbers mentioned below can be found on Github. For more details, add
+ the issue number to the end of the URL: https://github.com/swig/swig/issues/
+
++Version 4.0.0 (in progress)
++===
++
++2018-05-12: kwwette
++[Octave] add support for version 4.4
++- Should not introduce any user-visible incompatibilities
++
++
+ Version 3.0.12 (27 Jan 2017)
+
+
+diff -urN swig-3.0.12.old/Examples/Makefile.in
swig-3.0.12.new/Examples/Makefile.in
+--- swig-3.0.12.old/Examples/Makefile.in 2017-01-27 18:52:02.0
-0500
swig-3.0.12.new/Examples/Makefile.in 2018-05-26 08:39:16.510124553
-0400
+@@ -463,7 +463,7 @@
+ # -
+
+ octave_run:
+- OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE) $(OCTAVE_SCRIPT)
$(RUNPIPE)
++ env OCTAVE_PATH= OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE)
$(OCTAVE_SCRIPT) $(RUNPIPE)
+
+ # -
+ # Version display
+diff -urN
Re: An reason qtwebkit is not at 5.11?
Am 30.05.2018 um 17:47 schrieb Hartmut Goebel: > I just discovered, qtwebkit was not updated to 5.11 when qt was. Any > reason for this? Answering myself: There is no qtwebkit 5.11. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
An reason qtwebkit is not at 5.11?
Hi, I just discovered, qtwebkit was not updated to 5.11 when qt was. Any reason for this? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0x7B752811BF773B65.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Update KDE frameworks to 5.46: trivial test-case fails
On Wed, May 30, 2018 at 02:54:02PM +0200, Hartmut Goebel wrote: > Hi, > > I'm just about to update KDE Framekworks to 5.46, when I find a quite > trivial test-case to fail. Since this test-case is about detecting > "file" URLs, I'm afraid of pushing the update. > > May I push it to a WIP-branch instead, thus anybody else could pick up? Yes, please push it to a wip-kde-updates branch. signature.asc Description: PGP signature
Re: 04/05: gnu: swig: Patch for Octave 4.4.
Mark H Weaver writes:
> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 3771000f893d4b53e302f5bca07afeba69e76cd4
>> Author: Kei Kebreau
>> Date: Fri May 25 22:25:21 2018 -0400
>>
>> gnu: swig: Patch for Octave 4.4.
>
> On the core-updates branch, "guix refresh -l swig" reports that updating
> swig requires 1453 rebuilds. That's too many, so I reverted it.
>
> Instead, I suggest creating a different 'swig' package for octave that
> inherits from the primary one and adds this patch.
>
> What do you think?
>
> Mark
I agree that this will work. Is the attached patch something like what
you're thinking?
From 475a7698fd4c88ea688cb43499344e65ffaf5b84 Mon Sep 17 00:00:00 2001
From: Kei Kebreau
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.
* gnu/packages/machine-learning.scm (swig-for-octave): New variable
* gnu/packages/machine-learning.scm (shogun)[inputs]: Replace swig with
swig-for-octave.
* gnu/packages/patches/swig-octave-patches.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
---
gnu/local.mk |1 +
gnu/packages/machine-learning.scm | 10 +-
.../patches/swig-octave-patches.patch | 1119 +
3 files changed, 1129 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/swig-octave-patches.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 7734586f0..895d33012 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1106,6 +1106,7 @@ dist_patch_DATA =
\
%D%/packages/patches/steghide-fixes.patch\
%D%/packages/patches/strace-kernel-4.16.patch\
%D%/packages/patches/superlu-dist-scotchmetis.patch \
+ %D%/packages/patches/swig-octave-patches.patch \
%D%/packages/patches/swish-e-search.patch\
%D%/packages/patches/swish-e-format-security.patch \
%D%/packages/patches/synfigstudio-fix-ui-with-gtk3.patch \
diff --git a/gnu/packages/machine-learning.scm
b/gnu/packages/machine-learning.scm
index e135ee0ee..4d54584a7 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -365,6 +365,14 @@ value imputation, classifier creation, generalization
error estimation and
sample proximities between pairs of cases.")
(license license:gpl3+)))
+(define swig-for-octave
+ (package/inherit swig
+(name (string-append (package-name swig) "-for-octave"))
+(source
+ (origin
+ (inherit (package-source swig))
+ (patches (search-patches "swig-octave-patches.patch"))
+
(define-public shogun
(package
(name "shogun")
@@ -487,7 +495,7 @@ sample proximities between pairs of cases.")
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
("octave" ,octave)
- ("swig" ,swig)
+ ("swig" ,swig-for-octave)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/patches/swig-octave-patches.patch
b/gnu/packages/patches/swig-octave-patches.patch
new file mode 100644
index 0..9fb64a7b1
--- /dev/null
+++ b/gnu/packages/patches/swig-octave-patches.patch
@@ -0,0 +1,1119 @@
+This patch represents the recently added support for Octave version 4.4 found
+here:
+
+https://github.com/swig/swig/commit/12c66f9b7d884020e896ce92b9783bc3bac95d2d
+
+diff -urN swig-3.0.12.old/CHANGES.current swig-3.0.12.new/CHANGES.current
+--- swig-3.0.12.old/CHANGES.current2017-01-27 18:52:02.0 -0500
swig-3.0.12.new/CHANGES.current2018-05-26 08:40:06.501850058 -0400
+@@ -4,6 +4,14 @@
+ Issue # numbers mentioned below can be found on Github. For more details, add
+ the issue number to the end of the URL: https://github.com/swig/swig/issues/
+
++Version 4.0.0 (in progress)
++===
++
++2018-05-12: kwwette
++[Octave] add support for version 4.4
++- Should not introduce any user-visible incompatibilities
++
++
+ Version 3.0.12 (27 Jan 2017)
+
+
+diff -urN swig-3.0.12.old/Examples/Makefile.in
swig-3.0.12.new/Examples/Makefile.in
+--- swig-3.0.12.old/Examples/Makefile.in 2017-01-27 18:52:02.0
-0500
swig-3.0.12.new/Examples/Makefile.in 2018-05-26 08:39:16.510124553
-0400
+@@ -463,7 +463,7 @@
+ # -
+
+ octave_run:
+- OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE) $(OCTAVE_SCRIPT)
$(RUNPIPE)
++ env OCTAVE_PATH= OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE)
$(OCTAVE_SCRIPT) $(RUNPIPE)
+
+ # -
+ # Version display
+diff -urN swig-3.0.12.old/Examples/octave/module_load/runme.m
swig-3.0.12.new/Examples/octave/module_load/runme.m
+---
Update KDE frameworks to 5.46: trivial test-case fails
Hi, I'm just about to update KDE Framekworks to 5.46, when I find a quite trivial test-case to fail. Since this test-case is about detecting "file" URLs, I'm afraid of pushing the update. May I push it to a WIP-branch instead, thus anybody else could pick up? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0x7B752811BF773B65.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Videos
Catonano writes: > 2018-05-29 17:45 GMT+02:00 Julien Lepiller : > > Le 2018-05-29 16:48, Ricardo Wurmus a écrit : > > Hi Guix, > > I’d like us to produce a series of short videos (< 4 mins each) that > introduce functional package management with Guix. > > This is supposed to be aimed at people who are intimidated by the manual > and wouldn’t know where to begin reading. Each of the videos should > focus on a single feature and be on the point. The final seconds should > point the viewer to the manual to learn more. > > Who would like to be involved in the planning and production of the > videos? There are many tasks such as: > > * collecting topics that should be covered > * writing canonical narration scripts for each episode > * translating the scripts into different languages > * recording the narrations in different languages > * drafting the storyboard for each video (i.e. what exactly is to be > shown and for how long) > * recording the video portions > * mixing different audio tracks and the video track > * designing intro and outro frames > * recording or finding freely licensed music for the intro / outro > * coordinating with all volunteers > > What do you think? > > -- > Ricardo > > That sounds like a great plan! Of course I'd like to be involved in > translating > the script into French and I could probably record a French version of the > videos > too. I don't have any experience in the other fields, but I guess I could > learn. > > I think I have demonstrated my aptitude in recording video fragments on the > field > > As for storyboarding and scripting, instead, I'd love to receive suggestions. > > Also, I wouldn't know how to mix audio/video. What software could we use ? > I don't know. You may want to try simplescreenrecorder. I tried it before, it is reasonably easy to use. signature.asc Description: PGP signature
lvm2/device-mapper (dmeventd): libdevmapper-event-lvm2mirror.so: error: depends on 'libdevmapper-event-lvm2.so.2.02', which cannot be found in RUNPATH
The quest to update udisks is decidedly long...
One of the dependencies is dmraid, which in turns need
device-mapper-event, which is part of lvm2 but it's not part of the Guix
package as of now.
I'm trying to add device-mapper-event (a.k.a. dmevent) to lvm2. I've
added the following to the configure flags:
"--enable-cmdlib"
"--enable-dmeventd" ; Requires '--enable-cmdlib'.
But now I get the following error:
--8<---cut here---start->8---
starting phase `validate-runpath'
validating RUNPATH of 8 binaries in
"/gnu/store/gh7rda7y5nfh7v5njlll45ckbm4aigmd-lvm2-2.02.177/lib"...
/gnu/store/gh7rda7y5nfh7v5njlll45ckbm4aigmd-lvm2-2.02.177/lib/device-mapper/libdevmapper-event-lvm2mirror.so:
error: depends on 'libdevmapper-event-lvm2.so.2.02', which cannot be found in
RUNPATH
("/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib"
"/gnu/store/xfjba1kww8ngdc6nxldd8ly93nh13ayy-gcc-5.5.0-lib/lib"
"/gnu/store/xfjba1kww8ngdc6nxldd8ly93nh13ayy-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..")
[...]
/gnu/store/gh7rda7y5nfh7v5njlll45ckbm4aigmd-lvm2-2.02.177/lib/liblvm2cmd.so:
error: depends on 'libdevmapper.so.1.02', which cannot be found in RUNPATH
("/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib"
"/gnu/store/xfjba1kww8ngdc6nxldd8ly93nh13ayy-gcc-5.5.0-lib/lib"
"/gnu/store/bcvm220bjrx39g67hajjssgn20mlhyfr-eudev-3.2.5/lib"
"/gnu/store/xfjba1kww8ngdc6nxldd8ly93nh13ayy-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..")
validating RUNPATH of 3 binaries in
"/gnu/store/gh7rda7y5nfh7v5njlll45ckbm4aigmd-lvm2-2.02.177/sbin"...
phase `validate-runpath' failed after 0.0 seconds
--8<---cut here---end--->8---
Indeed, the new libraries don't have the right paths:
--8<---cut here---start->8---
> ldd libdevmapper-event-lvm2.so.2.02
linux-vdso.so.1 (0x7fffb2127000)
liblvm2cmd.so.2.02 => not found
libdevmapper.so.1.02 => not found
libpthread.so.0 =>
/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
(0x7f3fd36c)
libgcc_s.so.1 =>
/gnu/store/xfjba1kww8ngdc6nxldd8ly93nh13ayy-gcc-5.5.0-lib/lib/libgcc_s.so.1
(0x7f3fd34a9000)
libc.so.6 =>
/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
(0x7f3fd30f7000)
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/ld-linux-x86-64.so.2
(0x7f3fd3ae1000)
--8<---cut here---end--->8---
Apparently the following snippet
--8<---cut here---start->8---
(string-append "LDFLAGS=-Wl,-rpath="
(assoc-ref %outputs "out")
"/lib")
--8<---cut here---end--->8---
from the lvm2 package declaration is not enough.
Any clue how to enforce the right path into the new libraries?
--
Pierre Neidhardt
signature.asc
Description: PGP signature
Re: ndctl: I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl (xmlto?)
Adding ("libxml2" ,libxml2) to the native-inputs was enough.
Thanks!
That said, should we patch xmlto or leave it be?
--
Pierre Neidhardt
signature.asc
Description: PGP signature
Re: Help needed to update VLC to 3.0.3 on the master branch
Mark H Weaver writes: > Hello Guix, > > I just pushed a major VLC update to the 'core-updates' branch, commit > 76277052939524d1ea3394f83739f06efd0dd8ae. I pushed it to 'core-updates' > because I've been living on that branch for months, and so it's the only > branch that I can easily test for. > > However, I strongly suspect that the old VLC on master, and the old > ffmpeg-2.8 that it depends on, are most likely a security risk. > > So, I would be grateful if someone could cherry-pick this commit to > 'master', do some basic testing on it, and then push it on my behalf if > it works. I've had the VLC 3.0.1 commit applied on the master branch and VLC works fine. I only use ‘vlc’, and not ‘cvlc’. We may have to wrap ‘cvlc’ as well. But we can do that at a later time if someone finds a problem. Kind regards, Roel Janssen
Re: Help needed to update VLC to 3.0.3 on the master branch
Mark H Weaver writes: >> I can push it on your behalf if you tell me it's ok. > > Please do so. Thanks! Done. Thank you and Roel for that great work! Clément
Re: Help needed to update VLC to 3.0.3 on the master branch
Hi Clément, Clément Lassieur writes: > I just tested it and it works. Great, thank you! > With this output though: > > [01d03880] main libvlc: Running vlc with the default interface. Use > 'cvlc' to use vlc without interface. > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-clement' > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-clement' > [01cd23d0] main playlist: playlist is empty > Non-native QFileDialog supports only local files > Non-native QFileDialog supports only local files > Non-native QFileDialog supports only local files > libva info: VA-API version 1.1.0 > libva info: va_getDriverName() returns 0 > libva info: Trying to open > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/dri/i965_drv_video.so > libva info: va_openDriver() returns -1 > [7f2110001f60] glconv_vaapi_x11 gl error: vaInitialize: unknown libva > error > libva info: VA-API version 1.1.0 > libva info: va_getDriverName() returns 0 > libva info: Trying to open > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/dri/i965_drv_video.so > libva info: va_openDriver() returns -1 > [7f2110001f60] glconv_vaapi_drm gl error: vaInitialize: unknown libva > error > libva info: VA-API version 1.1.0 > libva info: va_getDriverName() returns 1 > libva error: va_getDriverName() failed with operation failed,driver_name=i965 > [7f2110001f60] glconv_vaapi_drm gl error: vaInitialize: operation failed > Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object > file: No such file or directory > QObject::~QObject: Timers cannot be stopped from another thread I see the same on core-updates. I'm not worried about it, or at least not as worried as I am about the security issues in the old version. I'm content to let someone else fix this up later, if anyone cares. > I can push it on your behalf if you tell me it's ok. Please do so. Thanks! Mark
Re: Don't change "+" syntax in guix/.dir-locals.el
Ludovic Courtès (2018-05-29 21:31 +0200) wrote:
> Alex Kost skribis:
>
>> Ludovic Courtès (2018-05-28 11:34 +0200) wrote:
[...]
>>> Basically if you don’t have it, when you type “#$(foo)”, Paredit inserts
>>> a space before the opening parenthesis.
>>
>> OK, I see now. Paredit inserts a space ('paredit-space-for-delimiter-p'
>> does it) if the point is placed on a symbol. So by fixing this gexp
>> stuff, you also break the default behavior of Paredit:
>>
>> - the default paredit inserts a space after ‘foo+’ symbol: foo+ ()
>>
>> - and with this dir-locals setting, it doesn't: foo+()
>
> To me that’s a feature
A feature of "dir-locals"?
> , because in Scheme ‘+’ is acceptable within
> identifiers, so there’s no reason to automatically insert a space after
> ‘+’.
So do you think that inserting a space after ‘+’ is a Paredit
misfeature? Then maybe it should be reported upstream.
Anyway, I just want to say, ".dir-locals.el" should not modify the
default syntax table, because all emacs packages and Emacs itself can
rely on it. For example, evaluate the following 2 definitions with
Geiser:
(define foo 1)
(define foo+ 2)
Now if you put the point on ‘foo’, the minibuffer will show you
“(guile-user):foo => 1”. And it shows the similar message for ‘foo+’,
but if you use "dir-locals", you will not see “(guile-user):foo+ => 2”.
So if the intention is to fix paredit, I think "dir-locals" should
change paredit, not scheme-mode.
>> Now I understand why this problem should be fixed, but my opinion is
>> that ".dir-locals.el" *should not* break the default syntax table of
>> scheme-mode just to make one emacs package work as desired.
>
> Do you think .dir-locals.el could perform this change in a buffer-local
> fashion?
The only other way I see, is to set
‘paredit-space-for-delimiter-predicates’ variable. The easy way is to
replace those 3 ‘modify-syntax-entry’ lines in "dir-locals" with:
(paredit-space-for-delimiter-predicates ignore)
But ‘ignore’ predicate is too strict: the space will never be inserted
not only for ‘foo+’ but also for ‘foo’. Maybe, a better predicate can
be chosen, but I don't have a wish to think about it more, sorry :-)
--
Alex
Re: Code of Conduct and Diversity Statement
Ludovic Courtès writes: > Hello Guix! > > Tobias Geerinckx-Rice skribis: > >> Leo Famulari wrote: >>> On Wed, May 16, 2018 at 11:26:07PM -0700, Chris Marusich wrote: These all seem like good improvements to me. I think we should upgrade to 1.4! >>> >>> +1 >> >> Oh, is this still under review? +1! > > I was waiting for Ricardo’s “+1” and he just wrote on IRC that we could > go ahead, so commit a076f19908d06b6df49f1c25c40de8838213cd71 finally > switches to version 1.4. \o/ I’m very sorry for the delay. I have just read the new version and I agree that it is an improvement over the previous version. Thank you, Tonton, for the initiative, and to everyone else who evaluated the new version! -- Ricardo
Re: Help needed to update VLC to 3.0.3 on the master branch
Hi Mark, I just tested it and it works. With this output though: --8<---cut here---start->8--- [01d03880] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-clement' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-clement' [01cd23d0] main playlist: playlist is empty Non-native QFileDialog supports only local files Non-native QFileDialog supports only local files Non-native QFileDialog supports only local files libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/dri/i965_drv_video.so libva info: va_openDriver() returns -1 [7f2110001f60] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/dri/i965_drv_video.so libva info: va_openDriver() returns -1 [7f2110001f60] glconv_vaapi_drm gl error: vaInitialize: unknown libva error libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 1 libva error: va_getDriverName() failed with operation failed,driver_name=i965 [7f2110001f60] glconv_vaapi_drm gl error: vaInitialize: operation failed Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory QObject::~QObject: Timers cannot be stopped from another thread --8<---cut here---end--->8--- I can push it on your behalf if you tell me it's ok. Clément
Re: 04/05: gnu: swig: Patch for Octave 4.4.
kkebr...@posteo.net (Kei Kebreau) writes: > kkebreau pushed a commit to branch master > in repository guix. > > commit 3771000f893d4b53e302f5bca07afeba69e76cd4 > Author: Kei Kebreau > Date: Fri May 25 22:25:21 2018 -0400 > > gnu: swig: Patch for Octave 4.4. On the core-updates branch, "guix refresh -l swig" reports that updating swig requires 1453 rebuilds. That's too many, so I reverted it. Instead, I suggest creating a different 'swig' package for octave that inherits from the primary one and adds this patch. What do you think? Mark
