Re: 'core-updates' Q4 2019
Timothy Sample writes: > Hi Kei, > > Kei Kebreau writes: > >> Anyone want to see the 54 patches and possibly help me root around for >> the issue? > > I would love to take a look at it! I’ve been a little tied up, but I > should have some time tomorrow or the next day. I think it would be > easiest to push it to some world-readable Git repository rather than > post all 54 patches here, but I can work with whatever suits you. > > > -- Tim I've pushed my changes to the following repository for anyone who wants to take a look: https://notabug.org/kei/guix-gnome-updates signature.asc Description: PGP signature
Re: (Really) Free Software future in the light of systemd
Stefan Huchler wrote: > If I write a program and it's elisp there is only as far as I know one > interpreter and all libs I use are also not replacable without rewriting code. Even if put aside that we have at least two elisp interpreters alive: there is also GNU Guile; GNU Emacs is actually quite bad example to illustrate the systemd lock-in problem. For many years it had had a divergent fork — XEmacs, and many non-core parts of GNU Emacs, like Gnus, still contain code that tries to be portable between them. > So is all my programmes I ever wrote also not Free software because it's not > based on some very primitive Kernel Systemcalls (that have to be then not > even linux specific right? While Linux® is indeed might be a very relevant example. It’s a way more widespread; has software more critical that DE, like Wayland, that targets it exclusively; and since the advent of LLVM is basically the only effectively irreplaceable part of GNU left. I wish open software (that how the standard-based software is properly called) advocates, which are now focused on systemd, would better turn their attention to Linux®. signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
On Sat, 19 Oct 2019 22:52:58 +0200 Ricardo Wurmus wrote: > We always try to unbundle libraries, because that ensures that all > packages benefit from security fixes. > Great, so I have to package everything recursively :) Just to make it clear, because I'm a bit unfamiliar with build systems and the package API - will packing every library pjproject uses and just adding it in the "inputs" field make building possible, or will I have to do magic and copy built packages into "third_party" folder in the pjproject source tree? Also what if pjproject (or any package I want to update) depends on a specific version of a library? Should I just update the package, or should I add a separate version of the library? Jan Wielkiewicz
Help wanted for mumi (issues.guix.gnu.org)
Hello Guix, our bug tracker web interface at issues.guix.gnu.org could really benefit from a more reliable, faster search. Currently, mumi (the application behind issues.guix.gnu.org) uses a slow interface to Debbugs, the bug tracker service that runs at debbugs.gnu.org. The search isn’t great as it returns duplicates and is paginated, which makes it unsuitable for processing. Mumi may need to further filter the search results by status or activity, or any other metric that the Debbugs search API doesn’t let us do. So I decided to switch away from using the Debbugs API and instead operate on a *local* copy of all messages that reach Debbugs. Debbugs operates on email messages, and luckily it allows us to download these original messages. Whenever someone visits an issue page, all related messages are downloaded by mumi, so it amasses a sizeable stash of emails over time. Mumi is using a modified version of “mu”, the mail indexer and search tool, to continuously index the contents of all messages. (“mu” is modified only so that the issue number is indexed alongside the message contents.) Unfortunately, that’s as far as I got before life intervened. The next step is really close, but getting there requires more contiguous segments of time than I can free at the moment. We really only need to do the following things next: 1) keep updating the mu database as new messages are stored 2) using the mu Guile bindings to search messages via mu instead of using the slow Debbugs API. While working on 2 we may find that more properties should be stored in the mu database, and that’s fine. Our variant of mu is easily patched to accomodate our needs. Does anyone here have an interest in playing with and improving mumi? It’s a very simple code base and it’s very easy to get started. The code is here: https://git.elephly.net/software/mumi.git -- Ricardo
Re: Stateful system directories
Hello Efraim, Efraim Flashner skribis: > Ignoring the directories in users' home directories, /var/lib/gdm has > been a source of pain on GNOME upgrades, and we still have some problems > with /var/cache/fontconfig and I believe there is something else with > permissions if you switch between ntp and openntpd. I actually have the > following snippet in my OS-config: > > ;; This directory shouldn't exist > (file-system > (device "none") > (mount-point "/var/cache/fontconfig") > (type "tmpfs") > (flags '(read-only)) > (check? #f)) I think that would work, or we could even make it a writable tmpfs? (Somehow, I do have /var/cache/fontconfig, but never hard any problems with it. It hasn’t been written to in months, and it’s only writable by root anyway. Does that mean that people run into problem when they run GUIs as root?) > While we work on fixing these does it make sense to modify some of these > services to unconditionally recreate their home directories on > boot/activation? Like /var/lib/gdm? Maybe. Or maybe ‘gdm-service-type’ could extend ‘file-system-service-type’ with a tmpfs for /var/lib/gdm? I suppose that might increase startup time a bit since it’d be rebuilding its cache every time. Perhaps we’d also lose bits of state, no? Thanks, Ludo’.
Re: package systems, before and after the core-updates merge
Hi, Christopher Baines skribis: > One thing that I was aware of before the recent core-updates merge was > that the Guix Data Service [1] didn't generate derivations for systems > other than x86_64-linux and i686-linux, at least to the same extent as > the master branch before the recent core-updates merge. Indeed, see this bug fix that landed before the merge: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=bc60349b5bc58a0b803df5adce1de6db82453744 > I think this is down to the use of package-transitive-supported-systems > within the Guix Data Service, but the output of this function for a > package can also be seen by running guix package --show. The patch below fixes ‘guix show’ but it has a noticeable performance impact that makes me thing something’s not quite right with memoization in ‘package-transitive-supported-systems’: diff --git a/guix/ui.scm b/guix/ui.scm index 3e4bd5787e..426e517b54 100644 --- a/guix/ui.scm +++ b/guix/ui.scm @@ -1259,7 +1259,8 @@ WIDTH columns. EXTRA-FIELDS is a list of symbol/value pairs to emit." (format port "version: ~a~%" (package-version p)) (format port "outputs: ~a~%" (string-join (package-outputs p))) (format port "systems: ~a~%" - (string-join (package-transitive-supported-systems p))) + (string-join (filter (cut supported-package? p <>) + %supported-systems))) (format port "dependencies: ~a~%" (match (package-direct-inputs p) (((labels inputs . _) ...) > Also, for the Guix Data Service, all I want to know is for a given > package, is for which systems and targets a derivation can be reasonably > computed. Maybe it is wrong to use package-transitive-supported-systems > for this. You can use ‘supported-package?’ as above. This is also what (gnu ci) does. Let me know if this helps! Ludo’.
Multiseat in Guix
Hi, Guix does not seem to have multiseat support. What would it take to add it? Is anyone on the list familiar with how multiseat is achieved in other distros, such as Fedora? Here is an example of a problem that happens because we don't have good multiseat support: When I launch virt-manager via "sudo -E virt-manager", I can connect a USB device from the host to a running VM by clicking on the "Virtual Machine > Redirect USB Device" menu entry. However, if I launch virt-manager normally (as the unprivileged user "marusich") and try this, it fails due to insufficient permissions: spice-client-error-quark: Could not redirect [the device] at [the device's address]: Could not open usb device: Access denied (insufficient permissions) [-3] (0) I can work around the issue without root privileges by giving myself write permission on the device in question. For example: sudo setfacl -m u:marusich:rw /dev/bus/usb/001/007 Alternatively, I could have just changed the file mode or ownership. Here are the file mode, ownership, and ACLs after I did this: [0] marusich@garuda.local:~ $ ls -l /dev/bus/usb/001/007 crw-rw-r--+ 1 root root 189, 6 Oct 19 13:31 /dev/bus/usb/001/007 [0] marusich@garuda.local:~ $ getfacl /dev/bus/usb/001/007 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/001/007 # owner: root # group: root user::rw- user:marusich:rw- group::rw- mask::rw- other::r-- My user is in these groups: $ id uid=1000(marusich) gid=998(users) groups=998(users),976(libvirt),977(tor),984(kvm),990(netdev),992(video),999(wheel),30001(plugdev) I would like to be able to attach USB devices to VMs without running virt-manager as root, and without manually granting access to device files. How can we achieve that in Guix? Well, to do that we would need an automatic mechanism which grants appropriate permissions on the relevant device nodes. There are many ways to accomplish that. For example, Fedora automatically detects when a device is connected to a user's seat (I'm not sure if that's the right terminology) and grants them access (via ACLs, I believe). Concretely, Fedora accomplishes this by configuring systemd, udev rules, and perhaps other parts of the system in specific ways. This allows two different users Alice and Bob to have access to their own hardware on their own seats (e.g., in a shared computer lab situation), without allowing Alice to access Bob's hardware on Bob's seat, or vice versa. That's really nice. I'm not very familiar with all the mechanisms, but I think anyone would want the result, which is called "multiseat": https://www.freedesktop.org/wiki/Software/systemd/multiseat/ For now, the immediate, course-grained, automatic solution for my virt-manager problem is: I can add udev rules that will unconditionally set the group of USB device nodes to a special group, maybe named "usb". If I then add my user to the "usb" group, I will have access to all USB devices without any extra effort. However, this solution is too course-grained. Alice and Bob would both need to be in the "usb" group to access their own seat's devices, but Alice will be able to access Bob's devices, and vice versa, which is not good. The multiseat solution seems nicer, but it seems complicated to implement. Since it seems to rely on systemd in some fashion, it may be even more difficult to implement in Guix, as we only use extracted parts of systemd (e.g., elogind). What would it take to add multiseat support in Guix? -- Chris signature.asc Description: PGP signature
Re: We need your feedback of the documentation videos!
On Sat, Oct 19, 2019 at 10:13:59PM +0200, Ludovic Courtès wrote: > […] if you wanted to integrate them on > the web site, I think that’d be great. > I suppose the “Discover Guix” section on the homepage should advertise Guix System and the videos, maybe in buttons next to the ALL PACKAGES button. I will look at making a proposal next week. I am nowhere near as creative as the website’s authors, so maybe others will think of better designs. > Especially since we now host the web site by ourselves, we could also > host the videos there, so that can be pretty easy to do. > > WDYT? > > Ludo’. I cannot judge whether audio-video.gnu.org is better or worse than berlin. Regards, Florian
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > Why are third party directories removed if they're necessary to build > pjproject? Should I package contents of these folders as separate > package? We always try to unbundle libraries, because that ensures that all packages benefit from security fixes. -- Ricardo
Re: Maintaining GNU Jami package for Guix
Hello, Dnia 2019-10-19, o godz. 11:02:35 Pierre Neidhardt napisał(a): > Hi Jan, > > glad you are interested in picking this one up! :) > I'm the last packager of Jami, so I might be able to help. Yes, thank you, I definitely will need help. > After a quick glance, here is the situation it seems: > > Jami used to depend on their own fork of pjproject (as packaged in > Guix). > However it seems that recent versions have dropped the fork to use > upstream instead. _This needs to be confirmed._ It seems the latest version still has patches for pjproject in the source code, but I can ask the devs about it. > If this is the case, switching the pjproject input to use upstream > should work when updating Jami. I've tried updating Jami, but pjproject seems to be a problem - don't know what have changed, but now even the currently packaged version of pjproject won't compile. Here's the log: starting phase `autoconf' autoconf: error: invalid option `-vfi' Try `autoconf --help' for more information. command "autoconf" "-vfi" "-o" "aconfigure" "aconfigure.ac" failed with status 1 I've also tried updating pjproject to the current version Jami uses - 2.8, it throws the same error. I managed to skip that by removing the "-vfi" options by commenting it out like this: (add-before 'patch-source-shebangs 'autoconf (lambda _ (invoke "autoconf" "-o" ;"-vfi" "aconfigure" "aconfigure.ac"))) But then it fails later, while doing "make dep": make[2]: Entering directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make[2]: *** gsm: No such file or directory. Stop. make[2]: Leaving directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make[1]: *** [Makefile:7: dep] Error 1 make[1]: Leaving directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make: *** [Makefile:14: dep] Error 1 command "make" "dep" failed with status 2 Why are third party directories removed if they're necessary to build pjproject? Should I package contents of these folders as separate package? Also something is causing builds of Jami to be irreproducible - every time I run guix upgrade, Jami gets upgraded to the same version. Is there a way to check what exactly is unstable? > The rest should be mostly straightforward stuff. Don't hesitate to > come back to me if you need more help. Okay, thanks. > Cheers! > Jan Wielkiewicz
Re: [External] Re: New outreachy participant introduction
Hi Nardos, "Asfaw, Nardos" skribis: > Thanks for reaching out. I am still hanging. I am learning a lot on what it > means to be a developer outside of university courses. I am going through the > documentation (and examples provided in the email by simon) and the chat logs > to sees if my questions have been asked before I come with questions and > solutions I have tried. At any rate, don’t hesitate to ask questions here or on #guix on IRC! It’s surely tricky to get started with a development project so asking questions can be helpful and we’ll be happy to provide guidance. Thanks, Ludo’.
Re: Any interest in using HTML for locally-installed Texinfo documentation?
Hi Gavin, Gavin Smith skribis: > I started another line of development, using the WebKitGTK engine. > http://git.savannah.gnu.org/cgit/texinfo.git/log/?h=webkitgtk-info [...] > I may be able to get an initial prototype that other people could try > ready in a few days. As ever, if anyone is interested in helping > with/taking over this project, please let me know. Thanks for the update, it looks promising. Let us know when you’d like people to give it a try! Ludo’.
Re: Could guix lint check the copyright line?
Hi! Pierre Neidhardt skribis: > Wouldn't it be neat if guix lint would automatically spot missing > copyright lines in the file headers? It could rely on `git blame' to > identify who wrote more than some 15 lines in a file. > > What do you think? That check would have to be optional because ‘guix lint’ is not necessarily running from a Git checkout. Also, I wonder how frequent false-positives would be. Thanks, Ludo’.
Re: Performance improvements
Efraim Flashner skribis: > Blog post? I think performance still leaves a bit to be desired, so maybe we should blog when we have even better news? :-) Ludo’.
Re: Performance improvements
Jan Nieuwenhuizen skribis: > Ludovic Courtès writes: > >> I just wanted to share that recent commits have improved the performance >> of ‘package-derivation’ and related operations quite a bit: >> >> 8f417ed280 gnu: commencement: Further optimize the package object graph. >> f618134e4c build-system/gnu: 'package-with-explicit-inputs' uses >> 'package-mapping'. >> dab669e075 gnu: ld-wrapper: Memoize. >> 099dbc4fd3 gnu: Improve memoization of 'package-with-bootstrap-guile'. >> 99b73d0f0c gnu: commencement: Reduce the graph of package objects. >> 9a45a24f7f gnu: Remove unnecessary uses of 'package-with-bootstrap-guile'. > > Ah, that's great! We get graph images that are actually usable, Yes, that’s a pleasant side effect. :-) > and this makes more space for me to slightly worsen things again with > my Scheme-only bootstrap experiments, coming real soon now ;-) Yay! Ludo’.
Re: We need your feedback of the documentation videos!
Hello! "pelzflorian (Florian Pelz)" skribis: > On Sun, Aug 25, 2019 at 03:55:16PM -0300, Laura Lazzati wrote: >> Hi Guix! >> >> I've uploaded a new version of the video for asking for help. Here is the >> link to it: https://archive.org/details/guix-videos/03-help-new-version.webm >> >> I guess I took into account all the suggestions from Ricardo and Tobias, >> but I would appreciate feedback again :) >> >> Kind regards :) >> Laura > > What is the status on these videos? Have they received feedback yet? > Please someone review and publish and blog about them before the next > Guix release. They would be useful for Guix to grow, I think. I think so too! As is too often the case, I haven’t allocated as much bandwidth to that as I wanted, but if you wanted to integrate them on the web site, I think that’d be great. Especially since we now host the web site by ourselves, we could also host the videos there, so that can be pretty easy to do. WDYT? Ludo’.
Re: Fwd: Running individual system tests
Hi Daniel, I don’t understand why you would want to run a system test without building Guix first. Could you elaborate? -- Ricardo
Re: 'core-updates' Q4 2019
Hi Kei, Kei Kebreau writes: > Anyone want to see the 54 patches and possibly help me root around for > the issue? I would love to take a look at it! I’ve been a little tied up, but I should have some time tomorrow or the next day. I think it would be easiest to push it to some world-readable Git repository rather than post all 54 patches here, but I can work with whatever suits you. -- Tim
Re: Fwd: Running individual system tests
Hello Daniel, Daniel Schäfer writes: > I'm still trying to figure out, how to run a single Guix system test > without building the entirety of Guix. > Does anybody do this? Has anybody written a Guix system test for > something not in Guix? Maybe a personal or work-related project. You only have to build the entirety of Guix once. Later invokations of "make check-system" will re-use the compiled modules from the previous "make" invokation, and only compile those that changed in the mean time. Note that 'run-basic-test' also builds a derivation of your Guix checkout to make it available in the VM. I suspect this is what you are referring to? For out-of-tree tests, you can try to hack 'gnu/tests.scm' and 'build-aux/run-system-tests.scm' to your needs. HTH! signature.asc Description: PGP signature
Re: Stateful system directories
Ricardo Wurmus writes: [...] > I prefer to keep workarounds for real bugs out of the Cookbook. Even in a specific section called "Workarounds" and with a clear warning they are just _temporary_ workarounds users could decide to use, while waiting for upstream to fix that specific issue? We should not cover every single workaround in the Cookbook, but IMHO giving context (i.e. explaining the stateful nature of some system directories giving some example to better understand) and the techniques used are useful information for Guix System users. ...but I still don't have any useful patch to submit, so I'm just still speculating > For both fontconfig and the gdm user account’s home directory we > should push a workaround very soon. Fine, I also think we should (this should also be well documented in comments for each service) Anyway this thread is not specific to any particurar service or package, or at least I interpreted it as: "how can Guix System users overcome occasional configuration statefulness in their systems?", this is the reason why I gave the other example of Nextcloud and how that issue is managed in Nix (and IMHO it is far from an ideal solution) [...] Thanks! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures
Fwd: Running individual system tests
Hi Guix developers, I'm still trying to figure out, how to run a single Guix system test without building the entirety of Guix. Does anybody do this? Has anybody written a Guix system test for something not in Guix? Maybe a personal or work-related project. CC'ing some people who've added guix system tests. Thanks, Daniel Forwarded Message Subject:Running individual system tests Date: Tue, 15 Oct 2019 13:21:45 +0200 From: Daniel Schäfer To: help-g...@gnu.org Hi Guix, Guix System has nice system tests, as described in [1] but they don't easily allow to run a single test. The manual says to run `make check-system TESTS="basic mcron"` in the guix source tree. That, however, (apparently) requires to be bootstrapped, configured and all Scheme files to be fully built. Is there something as simple as: $ guix build -f gnu/tests/rsync.scm guix build: error: #: not something we can build --- I hacked together a solution that works but is far from nice. It is based off of build-aux/run-system-tests.scm and I tried to strip it down to the core. $ cat run-test.scm (use-modules (gnu tests rsync) (gnu tests) (guix store) (guix status) (guix monads) (guix derivations) (guix ui) (srfi srfi-1) (srfi srfi-34)) (define (built-derivations* drv) (lambda (store) (guard (c ((store-protocol-error? c) (values #f store))) (values (build-derivations store drv) store (system-test-value %test-rsync) (with-store store (with-status-verbosity 2 (run-with-store store (mlet* %store-monad ((drv (mapm %store-monad system-test-value (list %test-rsync))) (out -> (map derivation->output-path drv))) (mbegin %store-monad (show-what-to-build* drv) (set-build-options* #:keep-going? #t #:keep-failed? #t #:print-build-trace #t #:print-extended-build-trace? #t #:fallback? #t) (built-derivations* drv) (display out)) $ guile -s run-test.scm (/gnu/store/scifaigbvcj20lplj3mvqj3ndr9w0nlv-rsync-test)Backtrace: 8 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 7 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 6 (_ #(#(#))) In ice-9/boot-9.scm: 2312:4 5 (save-module-excursion _) 3831:12 4 (_) In /home/zoid/guix/gnu/tests/run-test.scm: 19:4 3 (_) In guix/status.scm: 810:4 2 (call-with-status-report _ _) In guix/store.scm: 1737:24 1 (run-with-store _ _ #:guile-for-build _ #:system _ # _) In unknown file: 0 (_ #) ERROR: Wrong type to apply: # It shows the derivation output path before the backtrace and thus I can inspect the log. Can I do this in a nicer way? It would be very helpful for out-of-tree system tests. Thanks - Daniel [1] https://guix.gnu.org/blog/2016/guixsd-system-tests/
