Re: guile_load_path not set?
Le 27 juin 2019 01:28:51 GMT+02:00, Amar Singh a écrit : >To reproduce >1. guix package -S 1 >(switch to 1st gen or the oldest gen around) >2. guix package --rollback (now you have a blank env) >3. guix package - i emacsy (install a guile library) >4. emacsy-gtk-webkit (run code that uses guile lib) > >guix package --search-paths shows no guile_load_path, or compiled load >path. > >is it a bug? > >Amar Singh > >Sent fromK-9 Mail. Please excuse my brevity. There should probably be a wrapper around the binary, otherwise you're supposed to install guile in the same profile to get the corresponding environment variables.
Re: Documenting current state of isolating icecat
I'd love to be able to get a discussion going on this again. I really wish I had time to spend on this, since it's something I'm really interested in helping with. But I either need to do a lot more research or need the help of people more familiar with Guix than me. On Wed, Jun 26, 2019 at 12:58:39 -0400, Christopher Lemmer Webber wrote: > If you want to have the hairs on the back of your neck stand up and not > lie down for a while, why not read this: > > > https://robertheaton.com/2019/06/24/i-was-7-words-away-from-being-spear-phished/ > > Previously there were some threads about isolating icecat and other > graphical applications: > > https://lists.gnu.org/archive/html/help-guix/2018-01/msg00056.html > > However, it's not obvious to me if we have an answer yet on what to do. > Whatever it is, I'd like to do it. > > Could someone point me in the right direction? Much appreciated. > Maybe we should even include it as an example in the documentation? > That could be a big win, and make it clearer to users how Guix comes > with tools that can help empower them. First: I should mention that later on in that thread, I solved the font issues and Ludo provided a script to containerize programs. I unfortunately still haven't had the time to give it a try, and I still have some outstanding issues that I haven't had time to research: 1. XDG_DATA_DIRS=$HOME/.guix-local/share is required within the container. Perhaps we should provide a wrapper for icecat to do this automatically, otherwise it's broken by default (broken font rendering). 2. I notice that if I run icecat outside of a container, save to a directory, and then run within a container that does not have such a directory, icecat segfaults. I haven't even looked at a backtrace yet. 3. I haven't researched what may be needed for audio to work. Videos work, but no audio. TBH, this is currently a feature for me. ;) 4. Icecat is significantly less stable. Tabs crash more frequently, especially when dealing with video, and the entire browser will occasionally crash. But it's stable enough for use---I still run it within a container. 5. Attempting to print (just attempting to show the print dialog) immediately segfaults. I don't even have printers configured, so this is at the very bottom of my list of priorities to investigate. 6. /etc/machine-id is required, and could be used to deanonymize users if ever it is leaked within the container. I haven't researched potential mitigations. Otherwise, it seems performant (again, videos play just fine without audio) and works well overall. Here is my current script: #+BEGIN_SRC sh #!/bin/bash mkdir -p /tmp/.icecat-tmp && cd /tmp/.icecat-tmp || exit # .X11-unix and .Xauthority are requird for X11 session sharing with the # host. /etc/machine-id is required for DBUS. The rest is optional, but # .mozilla is ideal for persisting sessions, and .cache for performance. # A unique `Downloads' directory is mounted to keep its eyes away from # anything that might have been downloaded outside this container, though # note that it _will_ have access to downloads from previous sessions (if # you don't want that, then just create a random dir each time). guix environment \ --container \ --link-profile \ --user=user \ --network \ -r "$gc_root" \ --expose=/etc/machine-id \ --expose=/tmp/.X11-unix/ \ --expose=$HOME/.Xauthority \ --expose=$HOME/.config/icecat-hosts=/etc/hosts \ --share=/dev/snd \ --share=$HOME/.mozilla/ \ --share=$HOME/Downloads/icecat-container/=$HOME/Downloads/ \ --ad-hoc mtg-icecat-containerized \ #-- \ #icecat --display=:0.0 "$@" \ # || zenity --error \ #--title 'Error starting container' \ #--text 'Icecat failed to start in a container' # #+END_SRC The comments above are so that I enter a shell to manually set XDG_DATA_DIRS---I haven't yet researched the best way to handle that; I'm a packaging noob. :) If someone wouldn't mind enlightening me... The creation of the temporary directory prevents exposing the CWD. That can go away once I can actually get around to addressing Ludo's concerns for my --no-cwd patch... (which was actually just brought up in #guix on Freenode). Here's my package definition for mtg-icecat-containerized: #+BEGIN_SRC scheme (define-module (mtg personal) #:use-module ((guix licenses) #:prefix license:) #:use-module (guix packages) #:use-module (gnu packages) #:use-module (guix build-system trivial) #:use-module (gnu packages gnome) #:use-module (gnu packages gnuzilla) #:use-module (gnu packages fonts) #:use-module (gnu packages fontutils) #:use-module (gnu packages pulseaudio)) (define-public mtg-icecat-containerized (package (name "mtg-icecat-containerized") (version "1.0") (home-page "https://mikegerwitz.com/";) (build-system trivial-build-system) (source #f) (native-i
Re: PLEASE! Input Attach Service
On Wed, 2019-06-26 at 19:22 -0400, Raghav Gururajan wrote: > On Wed, 2019-06-26 at 19:15 -0400, Raghav Gururajan wrote: > > On Tue, 2019-06-11 at 19:21 -0400, Raghav Gururajan wrote: > > > Hello Guix! > > > > > > I have been trying to make "inputattach-service-type" work on my > > > x200-t, but it > > > never works. During boot I see a warning/error message > > > "inputattach: > > > can't set > > > device type". Can someone please help with this? > > > > > > Regards, > > > RG. > > > > Hello Folks! > > > > Anyone have any ideas for this issue please? > > > > Regards, > > RG. > > Just CCing T-G-R for insight. Hello Tim! Hope you are doing good and sorry if I am disturbing you. I have been told that "inputattach" service was added by you. Could you please help me with the issue? Thank you! Regards, RG.
guile_load_path not set?
To reproduce 1. guix package -S 1 (switch to 1st gen or the oldest gen around) 2. guix package --rollback (now you have a blank env) 3. guix package - i emacsy (install a guile library) 4. emacsy-gtk-webkit (run code that uses guile lib) guix package --search-paths shows no guile_load_path, or compiled load path. is it a bug? Amar Singh Sent fromK-9 Mail. Please excuse my brevity.
Re: PLEASE! Input Attach Service
On Wed, 2019-06-26 at 19:15 -0400, Raghav Gururajan wrote: > On Tue, 2019-06-11 at 19:21 -0400, Raghav Gururajan wrote: > > Hello Guix! > > > > I have been trying to make "inputattach-service-type" work on my > > x200-t, but it > > never works. During boot I see a warning/error message > > "inputattach: > > can't set > > device type". Can someone please help with this? > > > > Regards, > > RG. > > Hello Folks! > > Anyone have any ideas for this issue please? > > Regards, > RG. Just CCing T-G-R for insight.
Re: PLEASE! Input Attach Service
On Tue, 2019-06-11 at 19:21 -0400, Raghav Gururajan wrote: > Hello Guix! > > I have been trying to make "inputattach-service-type" work on my > x200-t, but it > never works. During boot I see a warning/error message "inputattach: > can't set > device type". Can someone please help with this? > > Regards, > RG. Hello Folks! Anyone have any ideas for this issue please? Regards, RG.
Re: List available versions of package.
Philippe Veber writes: > I suppose dependencies of these > packages have to be maintained in the same channel right? Otherwise, if I > rely on packages from guix distribution, they can be dropped or updated to > an incompatible version at any moment. That scares me a little, because it > could break my channel anytime, or am I mistaken? This is correct; it’s the Linux model of API stability: you need to make sure that your code remains compatible. -- Ricardo
Re: List available versions of package.
Hi Ricardo, > Also, is it expected that packages from guix commits dating > > from a few years ago will still work in this setting? Thanks! > > Commits before the introduction of inferiors likely won’t work, > unfortunately. > Sounds natural, thanks for the confirmation. > For running old versions I recommend writing new package variants > instead and including them in a channel. Using inferiors is a good idea > when you want to reproduce a Guix environment that somebody else (or > your younger self) recorded, but I would not recommend them as a way to > make past software variants available. If you are not interested in a > particular old state of the world but only care about a particular > version of a single piece of software (that may be built with current > toolchains and libraries) then package variants are a better idea. > Alright, thanks! One question though: I suppose dependencies of these packages have to be maintained in the same channel right? Otherwise, if I rely on packages from guix distribution, they can be dropped or updated to an incompatible version at any moment. That scares me a little, because it could break my channel anytime, or am I mistaken? > > For bioinfo package variants also take a look at the guix-bimsb channel: > > https://github.com/BIMSBbioinfo/guix-bimsb > > (I should update the README to recommend using channels instead of > GUIX_PACKAGE_PATH…) > Looks interesting for me! I'll ping you there for further questions! > -- > Ricardo > >
Re: List available versions of package.
Hi Tobias, Le mar. 11 juin 2019 à 09:43, Philippe Veber > a écrit : > > Hello Tobias, and thanks a lot for your answer! > > I completely missed this reply. I am so sorry. > Really no worries, and thanks for lending your help! > > Philippe Veber wrote: > > Hello everyone, > > > > FWIW, I tried the exact example given in the manual [0] and it > > failed, > > although for a different reason. It does a lot of work until it > > reaches an > > exception (the build of profile.drv fails). Could someone > > confirm this > > should work? > > Pasting the contents of that first code box into ‘foo’ and running > ‘guix environment -m foo’ works fine for me on today's guix. > > Could you tell us which command you're using and what the result > is? > The command is guix environment --manifest=manifest.scm and the log is available here: https://gist.github.com/pveber/c6e9437f4964ec9f00e7f1ec6e52 > > > Also, is it expected that packages from guix commits dating > > from a few years ago will still work in this setting? Thanks! > > I'm not sure. There have been some watershed moments in those > years, and I don't know how well inferiors would isolate those > changes, if at all. > Ok, that limitation makes a lot of sense. I think I'll follow Ricardo's advice to enable installation of old versions. Again, thanks a lot! ph.
Documenting current state of isolating icecat
If you want to have the hairs on the back of your neck stand up and not lie down for a while, why not read this: https://robertheaton.com/2019/06/24/i-was-7-words-away-from-being-spear-phished/ Previously there were some threads about isolating icecat and other graphical applications: https://lists.gnu.org/archive/html/help-guix/2018-01/msg00056.html However, it's not obvious to me if we have an answer yet on what to do. Whatever it is, I'd like to do it. Could someone point me in the right direction? Much appreciated. Maybe we should even include it as an example in the documentation? That could be a big win, and make it clearer to users how Guix comes with tools that can help empower them. - Chris
Nextcloud-client gets the wrong version of OpenSSL
Hello Guix, I've been trying to package the nextcloud-client for a while and am stuck at a weird issue. Since it is a fork of owncloud-client, I have just adapted the package definition. With the addition of a patch from Parabola to strip out the need for qtwebengine, I've gotten it to build. However, it immediately segfaults on launch. Running it in gdb I see the following: > ssl3_cleanup_key_block () from >/gnu/store/m9ngbfyi8wrwiwyr7dkfnhn5fyfalq3r-openssl-1.0.2p/lib/libssl.so.1.0.0 And running 'nextcloud --version' gets me: > Using 'OpenSSL 1.0.2p 14 Aug 2018' But it is supposed to have been built with openssl-next, i.e. version 1.1.1c, and it requires 1.1.x at least. Adding openssl-next to native-inputs vs inputs does not make a difference. Turns out this is also the case for the existing owncloud-client package, which even though it depends on openssl-next also returns 'Using OpenSSL 1.0.2p'. So I'm stumped. Where is it getting this version of OpenSSL from? The build environment has the right version. It's not explicitly installed in any profile. Is it propagated from somewhere? Is there something obvious I'm missing? Or any idea what to try? Thanks, Jens M signature.asc Description: PGP signature
