Re: [video repo] when making videos inside container images break
Hi! > I tried adding it to the container, and it seems to be working fine here. I've been working on the wrong file (the environment.sh) and could not get why it still didn't work. Fixed the script and now will be pushing the remaining videos. Thanks for the explanation :) Regards > > > > Best regards, > > > g_bor > > Best regards, > g_bor
NextCloud integration in Online Accounts of GNOME System Settings
Hello Guix! I have added my nextcloud account in the online accounts section of gnome system settings. But the online folder/drive is not appearing in the gnome file manager (Nautilus). What should I do? Thanks! Regards, RG.
Re: [video repo] when making videos inside container images break
Hello Laura, Laura Lazzati ezt írta (időpont: 2019. márc. 3., V, 20:09): > > > You can go ahead with that. I am busy here tracing down this bug. > > I got strace for both of inside and outside the container, and it seems > > that in the container the wrong pixbuf loader is picked up, namely xmp > > instead of png. > Sorry, so if you make the video "the hard way" -video by video and > gluing-, the issue disappears? it has to do with the cointainer then? > > Yes, the container misses cairo. Could you try adding at, and see if the problem persists? How did I found it? (for myself and for future reference) I identified that the problem is that the container misses something. All work fine, if you don't specify the -C option. Then the hard thing was to find out, what that something was. I straced the thing in the container, and also did that with the working one, outside the container. The svg file was opened quite at the end, and I looked at the trace from that point on. It turned out that the image is tried to be opened as xpm... not as png, as it should be. Then I looked at the inkscape source, for quite a while... The good thing to search for turned out to be Inkscape::Pixbuf, which lead me to find that inkscape uses cairo in concert with pixbuf. Then I looked around the package definition of inkscape, where I found no sign of cairo... I tried adding it to the container, and it seems to be working fine here. > > Best regards, > > g_bor Best regards, g_bor
Re: [video repo] when making videos inside container images break
> You can go ahead with that. I am busy here tracing down this bug. > I got strace for both of inside and outside the container, and it seems > that in the container the wrong pixbuf loader is picked up, namely xmp > instead of png. Sorry, so if you make the video "the hard way" -video by video and gluing-, the issue disappears? it has to do with the cointainer then? > > Best regards, > g_bor
Re: [video repo] when making videos inside container images break
Hello Laura, Laura Lazzati ezt írta (időpont: 2019. márc. 3., V, 18:13): > > Sorry, I realized that the second part of the packaging video has the > same issue. > May I upload the pictures in a separate directory inside the videos > facing this issue, so that people can have them if they want to, and > it to the README (ie: 03-help and 04-packaging2 are facing issues with > embedded images, they are stored temporarily in an image subdir until > the bug is solved). > WDTY? You can go ahead with that. I am busy here tracing down this bug. I got strace for both of inside and outside the container, and it seems that in the container the wrong pixbuf loader is picked up, namely xmp instead of png. Best regards, g_bor
Re: [video repo] when making videos inside container images break
Sorry, I realized that the second part of the packaging video has the same issue. May I upload the pictures in a separate directory inside the videos facing this issue, so that people can have them if they want to, and it to the README (ie: 03-help and 04-packaging2 are facing issues with embedded images, they are stored temporarily in an image subdir until the bug is solved). WDTY?
Re: [video repo] when making videos inside container images break
Hi! > No idea yet. I will have a closer look later. One idea would be to check if > the inkscape conversion fails, or the next step, so that we can narrow the > problem to a single program. Also, do you get any suspicious looking log? I am browsing the internet to see if there is a solution. Hope it is not an inkscape bug. Shall I upload the help video all the same? Regards :) Laura
Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)
Giovanni Biscuolo writes: > OK, so my problem getting ungoogled-chromium installed is not related to > the 504 gateway timeout from the web API > > unfortunately I'm still having problems installing it since my client > does not download the substitute but starts building the derivation: > > $ guix package -i ungoogled-chromium > substitute: updating substitutes from 'https://ci.guix.info'... 100.0% > building > /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv... > \ 'set-paths' phase^C I don't know about berlin, but hydra.gnu.org has *never* successfully built ungoogled-chromium. So far, it has made 3 attempts on x86_64-linux and 5 attempts on i686-linux: https://hydra.gnu.org/build/3387889 (x86_64-linux) https://hydra.gnu.org/build/3381436 (x86_64-linux) https://hydra.gnu.org/build/3380876 (x86_64-linux) https://hydra.gnu.org/build/3386821 (i686-linux) https://hydra.gnu.org/build/3385227 (i686-linux) https://hydra.gnu.org/build/3381453 (i686-linux) https://hydra.gnu.org/build/3380895 (i686-linux) https://hydra.gnu.org/build/3379818 (i686-linux) If the same is true on berlin.guixsd.org, that would explain the lack of binary substitutes. Mark
Re: [video repo] when making videos inside container images break
Hello, 2019. márc. 3., V 4:00 dátummal Laura Lazzati ezt írta: > Hi! > > I am testing the videos to go on adding them to the videos repo, but I > am facing an issue that does not happen in my local private repo or > machine. > Even though I add images embedded and not linked to inkscape, when I > create a video inside the container, instead of showing the picture it > says "linked image not found" Do you have any idea why this is > happening? > No idea yet. I will have a closer look later. One idea would be to check if the inkscape conversion fails, or the next step, so that we can narrow the problem to a single program. Also, do you get any suspicious looking log? > > Thank you :) > Laura >
Re: [HELP] Packaging mupdf
Hi Pierre-Henry,
the mupdf release tarball includes the freeglut sources. We can reuse
the mupdf package’s “source” field and add a build phase after 'unpack
to change directories.
Here’s how (untested):
--8<---cut here---start->8---
(define freeglut-for-mupdf
(package
(inherit freeglut)
(source (origin
(method url-fetch)
(uri (string-append "https://mupdf.com/downloads/archive/";
name "-" version "-source.tar.xz"))
(sha256
(base32
"1psnz02w5p7wc1s1ma7vvjmkjfy641xvsh9ykaqzkk84dflnjgk0"))
(modules '((guix build utils)))
(snippet
'(begin
(for-each
(lambda (dir)
(delete-file-recursively (string-append "thirdparty/"
dir)))
'("curl" "freetype" "harfbuzz" "jbig2dec" "lcms2"
"libjpeg" "mujs" "openjpeg" "zlib"))
#t
(arguments
'(#:tests? #f ; there are none
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'chdir
(lambda _ (chdir "thirdparty/freeglut") #t)))
--8<---cut here---end--->8---
Hope that helps!
--
Ricardo
[video repo] when making videos inside container images break
Hi! I am testing the videos to go on adding them to the videos repo, but I am facing an issue that does not happen in my local private repo or machine. Even though I add images embedded and not linked to inkscape, when I create a video inside the container, instead of showing the picture it says "linked image not found" Do you have any idea why this is happening? Thank you :) Laura
Re: [HELP] Packaging mupdf
Thank you for your reply!
I documented my wondering around below and here is the gist of it:
To update the ~freeglut~ package (found with: ~$ guix edit freeglut~) may mean
to
make guix do (the equivalent of) this:
#+begin_src sh
$ git clone --recursive git://git.ghostscript.com/mupdf.git
$ cd mupdf
$ git submodule update --init
$ tar -zcf freeglut.tar.gz thirdparty/freeglut
#+end_src
so that the source field in the ~freeglut~ package:
#+begin_src scheme
(define-public freeglut
(package
(name "freeglut")
(version "3.0.0")
(source (origin
(method url-fetch)
(uri (string-append
"mirror://sourceforge/freeglut/freeglut/"
version "/freeglut-" version ".tar.gz"))
(sha256 … )))
…))
#+end_src
uses this ~freeglut.tar.gz~ instead of:
#+begin_src scheme
(source (origin
(method url-fetch)
(uri (string-append
"mirror://sourceforge/freeglut/freeglut/"
version "/freeglut-" version ".tar.gz"))
(sha256 … )))
#+end_src
How to update the package to that it does this?
Thanks,
PH
*** mupdf
Build and install ~mupdf~ with: ~$ guix package -i mupdf~
~mupdf~ doesn't work properly because of
[[https://bugs.archlinux.org/task/57227][this bug]].
To make ~mupdf~ work as expected, it should be built against a patched
version of ~freeglut~.
Let's check how ~mupdf~ is currently packaged: ~$ guix edit mupdf~.
We notice this field that denotes a dependency to ~freeglut~:
#+begin_src scheme
(inputs
`(…
("freeglut" ,freeglut)
…))
#+end_src
According to the
[[https://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html#Defining-Packages][documentation]],
the ~inputs~ field is a list of key-value pairs
where keys are strings and values are packages. So, a ~freeglut~ package
should
be defined. Let's find it:
~$ guix package -s freeglut~
gives two versions of ~freeglut~, boths of them with this field: ~location:
gnu/packages/gl.scm:93:2~ wich tells us that ~#:use-module (gnu packages
gl)~
should be used where ~mupdf~ package is defined and it is.
So, we need:
- to update the ~mupdf~ package so that it uses the patched version of
~freeglut~
- to update the ~freeglut~ package so that it uses patched version of
~freeglut~
- find where to get the patched version of ~freeglut~ from.
Patched version of freeglut
Googling things gives
[[https://bugs.ghostscript.com/show_bug.cgi?id=699079][this link]] with this
comment by Tor Andersson:
#+begin_quote
However, since you mention not being able to copy the selection at all,
you should be
aware that you MUST build with OUR copy of FreeGLUT. The standard system
FreeGLUT
does NOT have copy & paste support. We have added clipboard support to our
fork of
FreeGLUT. I have tried to get our additions adopted upstream, but the
maintainers are
slow to respond, so please use our version of freeglut when building mupdf.
#+end_quote
Tor Andersson seems to know what he is talking about since
[[http://git.ghostscript.com/?p=mupdf.git;a=summary][he commits]] to the
~mupdf~ sources. The question becomes: how to fetch « OUR copy of FreeGLUT
».
Let's fetch ~mupdf~ sources and check the ~freeglut~ history there:
#+begin_src sh
$ git clone --recursive git://git.ghostscript.com/mupdf.git
$ cd mupdf
$ git submodule update --init
$ cd thirdparty/freeglut
$ git log
#+end_src
We notice in the logs: ~Import freeglut 3.0.0 from tarball.~ and commits
by Tor
Andersson dealing with things useful for copy-pasting.
So, we should modify the ~guix~ package definition of ~freeglut version
3.0.0~ so
that it uses this patched version of the ~freeglut~ sources.
Since the ~freeglut~ that interests us is a submodule of the ~mupdf~
sources,
let's refresh our memory with
[[https://git-scm.com/book/en/v2/Git-Tools-Submodules][git documentation]]. We
learned that to get the
sources, we should do something like this in the ~freeglut~ guix package
definition:
#+id: 25eff785-d077-430e-aa2e-bfeb0eb07285
#+begin_src sh
$ git clone --recursive git://git.ghostscript.com/mupdf.git
$ cd mupdf
$ git submodule update --init
#+end_src
Then use the sources from there.
‐‐‐ Original Message ‐‐‐
On Saturday, March 2, 2019 11:15 PM, Ricardo Wurmus wrote:
>
>
> Hi Pierre-Henry,
>
> > The problem with the way mupdf is package today[2] is that it
> > does not include the patched version of freeglut that is
> > necessary for the copy-pasting functionality[3].
> > What does work is to follow the build instructions of mupdf[4]
> > which boils down to:
> > git clone --recursive git://git.ghostscript.com/mupdf.git
> > cd mupdf
> > git submodule update --
