Re: GNOME Core Applications
> For what is worth, GNOME Help (Yelp) is packaged, but not the > documentation of the GNOME desktop, which I think is essential to > have a better desktop experience. Thanks for the info. :-) Regards, RG. signature.asc Description: This is a digitally signed message part
Re: GNOME Core Applications
> This wasn't anything I did, but I believe that Simple Scan is > packaged as > simple-scan, so it's status can be updated :) Thanks for the info, I have updated it. :-) Regards, RG. signature.asc Description: This is a digitally signed message part
Re: Mailman packaging (was: Re: Python package naming: Dots vs hyphens)
Hello Efraim!
I need the attached patch to be able to run `mailman start`, `mailman
info` etc. I will continue to set up mailman on a server of mine and
then report back.
Regards,
Florian
>From 9945d2203362851fb24a829f2a27eead0273ffdc Mon Sep 17 00:00:00 2001
From: Florian Pelz
Date: Sun, 10 Nov 2019 11:38:16 +0100
Subject: [PATCH] gn: mailman: Patch configuration to refer to the right
binaries.
* gn/packages/mailman.scm (mailman): Patch schema.cfg.
---
gn/packages/mailman.scm | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/gn/packages/mailman.scm b/gn/packages/mailman.scm
index 6fd6291..359fdf6 100644
--- a/gn/packages/mailman.scm
+++ b/gn/packages/mailman.scm
@@ -16,7 +16,8 @@
#:use-module (gnu packages python-xyz)
#:use-module (gnu packages python-web)
#:use-module (gnu packages time)
- #:use-module (gnu packages tls))
+ #:use-module (gnu packages tls)
+ #:use-module (gnu packages web-browsers))
(define-public mailman
(package
@@ -30,6 +31,32 @@
(base32
"1qph9i93ndahfxi3bb2sd0kjm2c0pkh844ai6zacfmvihl1k3pvy"
(build-system python-build-system)
+(arguments
+ '(#:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'patch-config
+ (lambda* (#:key outputs inputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out"))
+ (lynx (assoc-ref inputs "lynx")))
+ (substitute* "src/mailman/config/schema.cfg"
+ (("bin_dir:.*") (string-append "bin_dir: " out "/bin\n"))
+ (("html_to_plain_text_command:.*")
+ (string-append "html_to_plain_text_command:" lynx "/bin/lynx"
+ " -dump $filename\n")))
+ #t)))
+ (add-after 'wrap 'restore-helper-progs
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(bin (string-append out "/bin")))
+ ;; Mailman calls os.execle on these, which retains
+ ;; PYTHONPATH anyway and fails with wrappers.
+ (rename-file (string-append bin "/.master-real")
+(string-append bin "/master"))
+ (rename-file (string-append bin "/.runner-real")
+(string-append bin "/runner"))
+ #t))
+(inputs
+ `(("lynx" ,lynx)))
(propagated-inputs
`(("python-aiosmtpd" ,python-aiosmtpd)
("python-alembic" ,python-alembic)
--
2.21.0
wip blog post: running Guix System on ARM
Hi, attached is a draft for a blog post (or a section in the cookbook) for explaining how to install the Guix System on an ARM board. WDYT? Guix on an ARM Board Increasingly people discovering Guix want to try it on an ARM board, instead of their x86 computer. There might be various reasons for that, from power consumption to security. In my case, I found these ARM boards practical for self-hosting, and I think the unique properties of GNU Guix are making it very suitable for that purpose. I have installed GNU Guix on a Cubietruck, so my examples below will be about that board. However, you should be able to change the examples for your own use case. Installing the Guix System on an ARM board is not as easy as installing it on an x86 desktop computer: there is no installation image. However, Guix supports ARM and can be installed on a foreign distribution running on that architecture. The trick is to use the Guix installed on that foreign distribution to initialize the Guix System. Most boards can be booted from an existing GNU+Linux distribution. You will need to install a distribution (any of them) and install GNU Guix on it, using e.g. the installer script. Then, my plan was to install the Guix System on an external SSD drive, instead of the SD card, but we will see that both are perfectly possible. The first part of the article will focus on creating a proper u-boot configuration and an operating system declaration that suits your board. The second part of this article will focus on the installation procedure, when there is no installer working for your system. Writing a configuration file for an ARM board - A configuration file for an ARM board is not very different from a configuration file for a desktop or a server running on another architecture. However, most boards use the u-boot bootloader and require some less common modules to be available at boot time. ### The root file system First of all, you should decide where your root file system is going to be installed. In my case, I wanted to install is on the external SSD, so I chose it: ```scheme (file-systems (cons* (file-system (mount-point "/") (device "/dev/sda1") (type "ext4")) %base-file-systems)) ``` If you instead want to install the root file system on an SD card, you'll need to find its device name, usually `/dev/mmcblk0` and the partition number. The device corresponding to the first partition should be `/dev/mmcblk0p1`. In that case, you would have: ```scheme (file-systems (cons* (file-system (mount-point "/") (device "/dev/mmcblk0p1") (type "ext4")) %base-file-systems)) ``` ### The bootloader Because of the way the Guix System is designed, you cannot use an already existing bootloader to boot your system: it wouldn't know where to look for the kernel, because it doesn't know its store path. It wouldn't be able to let you boot older generations either. Most boards use the u-boot bootloader, so we will focus on that bootloader here. Contrary to grub, there are multiple variants of u-boot, one per board type. The installation procedure for u-boot is also somewhat specific to the board, so there are two things that you need to take care of: the u-boot package and the bootloader declaration. Guix already define a few u-boot based bootloaders, such as `u-boot-a20-olinuxino-lime-bootloader` or `u-boot-pine64-plus-bootloader` among others. If your board already has a `u-boot-*-bootloader` defined in `(gnu bootloader u-boot)`, you're lucky and you can skip this part of the article! Otherwise, maybe the bootloader package is defined in `(gnu packages bootloaders)`, such as the `u-boot-cubietruck` package. If so, you're a bit lucky and you can skip creating your own package definition. If your board doesn't have a `u-boot-*` package defined, you can create one. It could be as simple as `(make-u-boot-package "Cubietruck" "arm-linux-gnueabihf")`. The first argument is the board name, as expected by the u-boot build sysetem. The second argument is the target triplet that corresponds to the architecture of the board. You should refer to the documentation of your board for selecting the correct values. If you're really unlucky, you'll need to do some extra work to make the u-boot package you just created work, as is the case for the `u-boot-puma-rk3399` for instance: it needs additional phases to install firmware. You can add the package definition to your operating system configuration file like so, before the operating-system declaration: ```scheme (use-modules (gnu packages bootloaders)) (define u-boot-my-board (make-u-boot-package "Myboard" "arm-linux-gnueabihf")) (operating-system [...]) ``` Then, you need to define the bootloader. A bootloader is a structure that has a name, a package, an installer, a configuration file and a configuration file
Re: Profiles/manifests-related command line interface enhancements
Hi Andy, Guix... On +2019-11-12 09:55:27 +0100, Andy Wingo wrote: > On Sun 10 Nov 2019 10:36, Konrad Hinsen writes: > > > One direction could be to add a sandboxing feature to Guile, which would > > be nice-to-have for other uses as well if Guile is to become a > > general-purpose systems scripting language. There are some interesting > > ideas in shill (http://shill.seas.harvard.edu/) for this scenario. > > I wrote this for that purpose: > > > https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html > > However I can't recommend it as a robust security layer because of the > weaknesses in the heap allocation limit; discussed in the page above. > > I agree that Shill has some great patterns that go beyond what Guile or > Guix has, and that adopting some of them is a really interesting idea > :-) > > I admit that I was a bit depressed at the impact that Spectre et al has > had on language-level sandboxing abstractions :-( and haven't much ┌───┐ │ > pursued this line since then. In practice Guix's "containerized" build │ │ > jobs are much more effective than in-language barriers. │ └───┘ > > Cheers, > > Andy > Would it be possible to have a sand-box daemon like the build daemon which could run sandboxed guile expressions safely? If designed for the future, maybe such a daemon's interface could anticipate replacing the daemon and talking to a hypervisor dom0 as in Qubes-OS? -- Regards, Bengt Richter --8<(OT PS)---cut here---start->8--- Andy, have you looked at glTF and sketchfab? Would you be interested in bringing that kind of 3D graphics into the Guix package world? (or are you or someone already doing something? :) https://sketchfab.com/features/gltf Have a look with firefox (my icecat on top of weston-launch shows the static images beautifully, but no dynamics, need to get js going). Play with rotating and zooming, really nice, plus animated stuff ;-) I think it would be super-cool to have this 3D modeling capability for Guix presentations, toys and fun ;-) --8<(OT PS)---cut here---end--->8---
Re: Parallel downloads
On Wed, Nov 13, 2019 at 11:16:53AM -0500, Mark H Weaver wrote: > For these reasons, I'm inclined to think that parallel downloads is the > wrong approach. If a single download process is not making efficient > use of the available bandwidth, I'd be more inclined to look carefully > at why it's failing to do so. For example, I'm not sure if this is the > case (and don't have time to look right now), but if the current code > waits until a NAR has finished downloading before asking for the next > one, that's an issue that could be fixed by use of HTTP pipelining, > without multiplying the memory usage. > > What do you think? I agree that parallel downloads is a kludge to work around the issue of slow set-up and tear-down of our download code. Pipelining would help a lot, and we could also profile the relevant Guile code to see if there are any easy speedups. This issue was actually discussed a year ago: https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00148.html I'll quote Ludo's suggestion from then: > I’d be in favor of a solution where ‘guix substitute’ is kept alive > across substitutions (like what happens with ‘guix substitute --query’), > which would allow it to keep connections alive and thus save the TLS > handshake and a few extra round trips per download.
Re: #850644: RFP: Guix in Debian
On Tue, 2019-11-12 at 20:43 -0800, Vagrant Cascadian wrote: > On 2019-05-28, Vagrant Cascadian wrote: > > On 2019-05-16, Vagrant Cascadian wrote: > > > So in a bit of a focused run of packaging, I've been chasing the > > > dependency chain necessary to get guix building on Debian: > > Summary: all the dependencies are in Debian! > Congratulations! signature.asc Description: This is a digitally signed message part
Re: Clang c++ include path
I've sent a quick fix for this to guix-patches (sorry if I haven't followed the right process for this!) I'd like to think more about how to write a make-clang-toolchain procedure properly so you can pick libstdc++/libc++ versions etc, as my current implementation is pretty lacking. My patch should fix clang if all you want is to use the default gcc from guix though. David Truby On Mon, 2019-11-11 at 15:12 +, David Truby wrote: > Hi, > > This patch doesn't work for me as it seems to have a similar issue > finding the libc++ headers. > > > I do have a fix for the libstdc++ header issue though, I'm just > trying > to clean up the patch and then will send it to paches-guix. It > involves > patching the source, so will trigger a rebuild of anything depending > on > clang (however it doesn't touch llvm). I haven't yet worked out a way > of fixing libc++ but it should be fixable in a similar way. > > > I actually have two ways of fixing it though and am unsure which is > more appropriate. The non-controversial one is to just get the > libstdc++ header directory for the default gcc and patch clang to > look > there. However, as an end user of the clang package I would rather > have > a make-clang-toolchain procedure that takes a gcc-toolchain version > and > gets the standard library from that. I've got implementations of both > of these, does anyone have an opinion which one would be preferred? > > David Truby > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you.
Re: Parallel downloads
Hi, Ludovic Courtès writes: > Pierre Neidhardt skribis: > >> Ludo, what do you think of Tobias suggestion and have an extra knob to >> specifically configure the number of download jobs? > > Like I wrote, it’s not that simple (we’d first need the daemon to > distinguish substitution jobs from other jobs, but note that there are > also “downloads” that are actually derivation builds), and it’s not > clear to me that it’s overall beneficial anyway: it’s not supposed to be > faster to download 10 things in parallel from ci.guix.gnu.org, than to > download them sequentially. I'll also note that parallel downloads would increase the memory usage on the server. If users, on average, configured 4 parallel downloads, I guess that would have the effect of multiplying the server memory usage by about 4. It might also create an incentive for users to configure more parallel downloads in order to grab a larger ratio of the server's available resources. For these reasons, I'm inclined to think that parallel downloads is the wrong approach. If a single download process is not making efficient use of the available bandwidth, I'd be more inclined to look carefully at why it's failing to do so. For example, I'm not sure if this is the case (and don't have time to look right now), but if the current code waits until a NAR has finished downloading before asking for the next one, that's an issue that could be fixed by use of HTTP pipelining, without multiplying the memory usage. What do you think? Mark
Re: GNOME Core Applications
On Wed, 13 Nov 2019 02:04:46 -0500 Raghav Gururajan wrote > Hello Guix! > > Based on information from [1], [2], [3] and [4]; I have formulated a > chart to keep track of things easily. :-) > > CHART: https://calc.disroot.org/2nu6mpf88ynq.html > > As a start, I will be working on packaging gnome-contacts, gnome-music > and gnome-weather. Nice, thanks :) > If anyone did any task(s) from the chart, please let me know and I will > update the chart accordingly. For what is worth, GNOME Help (Yelp) is packaged, but not the documentation of the GNOME desktop, which I think is essential to have a better desktop experience. --- https://sirgazil.bitbucket.io/
Re: A better XML, config is code (was Re: Profiles/manifests-related command line...)
Hi Giovanni, > The real question is: a configure file is code or data? IMHO is code, Code is data with execution semantics, so "code" is a subset of "data". I'd reformulate the question as: should configuration data be literal data, or the result of a computation? The second opton is more general, and therefore more powerful. If that is good or bad depends on the application. If you are writing the configuration, you appreciate more power. If you use someone else's, you might well prefer it not being more powerful than what you can understand. > Mumble... but every user *is* a power user when installing and > configuring a system, no? "Is", no. That would assume that everybody knows their limits. Not true in my experience with human nature. > ...so yes, if it's not a channel under your control - or of someone you > decide to trust - you should better not use it (and do not copy/paste > configuration files you do not understand) Fine with me, but then we should (1) say so somewhere in the manual and (2) not recommend using such configuration files for performing tasks that ought to be accessible to ordinary users. > I recently read this "Curl to shell isn't so bad" article (thanks ARota) > https://arp242.net/curl-to-sh.html > > «In the end it’s still just running code you didn’t personally audit on > your computer, and a matter of trust.» Exactly. It's OK for us to ask users to trust the Guix team, which they have to do anyway if they use Guix. So configuration files provided by Guix itself are not a problem. But if we tell people that Guix is great for reproducing someone else's computation, and that the best way to share a computation is publishing a manifest file, then we are encouraging people to run code from untrusted sources. Which leaves three options: 1. Provide a safe way to re-create environments from untrusted sources. 2. Don't recommend reproducing someone else's computation using Guix. 3. Explain why reproducing someone else's computation is a risky procedure that should be reserved to power users. Cheers, Konrad.
Re: GNOME Core Applications
On Wed, 13 Nov 2019, Raghav Gururajan wrote: CHART: https://calc.disroot.org/2nu6mpf88ynq.html Neat! If anyone did any task(s) from the chart, please let me know and I will update the chart accordingly. This wasn't anything I did, but I believe that Simple Scan is packaged as simple-scan, so it's status can be updated :) Best, Jack
Test-suite for guix deploy?
Hi, is there a test-suite for "guix depoly" already? Is it run on ci.guix.gnu.org? -- 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
Re: gnu: python: Update to 3.8.0.
Hi Tobias! Le 11/13, Tobias Geerinckx-Rice a écrit : > Tanguy Le Carrour 写道： > > 4. everything else is "Max report size reached"! > > I don't really know where to go from here? Am I supposed to investigate > > errors of type 4?! > $ diffoscope --max-report-size BYTES I'll use `--max-repost-size` and `--exclude-directory-metadata` next time! Thanks! -- Tanguy
Re: gnu: python: Update to 3.8.0.
Hello, Tanguy Le Carrour ezt írta (időpont: 2019. nov. 13., Sze 14:23): > Le 11/13, Gábor Boskovits a écrit : > > Tanguy Le Carrour ezt írta: > > > 2. different paths for `python3.8` in the shebang of some scripts. > > > 3. different paths in prefix for `python3.8` (some origin as above). > > > > > 3 and 2 should be investigated. Do you get these diffs even with grafts > > disabled? > > ``` > $ ./pre-inst-env guix build --no-grafts --rounds=2 python@3.8 > ``` > > This works! \o/ > > Unfortunately, I only have a vague idea of what a graft is and what it > is used for! … shame on me! ^_^' > So, it goes without saying that I have no clue what the next step should > be! :-) > This actually means that the build is ok as is, so if there are no other things beside this issue, I would say it is safe to push. > > Regards, > > -- > Tanguy > Best regards, g_bor >
Re: gnu: python: Update to 3.8.0.
Le 11/13, Gábor Boskovits a écrit : > Tanguy Le Carrour ezt írta: > > 2. different paths for `python3.8` in the shebang of some scripts. > > 3. different paths in prefix for `python3.8` (some origin as above). > > > 3 and 2 should be investigated. Do you get these diffs even with grafts > disabled? ``` $ ./pre-inst-env guix build --no-grafts --rounds=2 python@3.8 ``` This works! \o/ Unfortunately, I only have a vague idea of what a graft is and what it is used for! … shame on me! ^_^' So, it goes without saying that I have no clue what the next step should be! :-) Regards, -- Tanguy
Re: gnu: python: Update to 3.8.0.
Hello, Tanguy Le Carrour ezt írta (időpont: 2019. nov. 13., Sze 9:03): > Hi Marius, hi Gábor! > > Le 11/04, Gábor Boskovits a écrit : > > Tanguy Le Carrour ezt írta (időpont: 2019. nov. > 4., H, 11:50): > > > Le 11/04, Gábor Boskovits a écrit : > > > > Tanguy Le Carrour ezt írta (időpont: 2019. > nov. 4., > > > > > `./pre-inst-env guix build --rounds=2 python@3.8` always fails > with: > > > > > """ > > > > > output ‘/gnu/store/…-python-3.8.0’ of > ‘/gnu/store/…-python-3.8.0.drv’ > > > > > differs from previous round > > > > > """ > > > […] > > > First time I hear of diffoscope! I had a look at the output (html > > > attached), but couldn't make sense of it! > > Nice, one thing that looks problematic is that there seems to be a > mismatch > > in the hash. > > At one line you can see the shabang modified to a different path... > > I don't yet know the reason of that, but it quite suspicious... > > One thing, when dealing with things like like this, one should first fix > > the readable differences, > > and only then dig deeper, as fixing those often cascade, and fix more > than > > anticipated. > > Sorry it took me so long, but I finally had some time yesterday evening to > go > through the report! > > I found 4 types of errors: > > 1. `stat` reporting a different "Birth" for folders, which I assume are > perfectly normal. > This is fine, you can use the option to ignore directory metadata from diffoscope output, so that this won't pollute the output. > 2. different paths for `python3.8` in the shebang of some scripts. > 3. different paths in prefix for `python3.8` (some origin as above). > 3 and 2 should be investigated. Do you get these diffs even with grafts disabled? > 4. everything else is "Max report size reached"! > Should not be a problem, it shows the diff is too big. You have diffoscope options to increase that, but as problems are fixed the output should return to the normal range. > > I don't really know where to go from here? Am I supposed to investigate > errors of type 4?! > > Regards, > > -- > Tanguy > Best regards, g_bor >
Re: gnu: python: Update to 3.8.0.
Hullo Tanguy, Tanguy Le Carrour 写道： 4. everything else is "Max report size reached"! I don't really know where to go from here? Am I supposed to investigate errors of type 4?! $ diffoscope --max-report-size BYTES See ‘diffoscope --help’ for more local maxes. Kind regards, T G-R signature.asc Description: PGP signature
Re: Parallel downloads
Hi Efraim, On Wed, 13 Nov 2019 at 08:44, Efraim Flashner wrote: > > guix build `guix show PKG | recsel -R dependencies` > > guix build PKG --no-substitutes > 'guix environment PKG -- guix build PKG --no-subsitutes' Thank you. It is a better solution, indeed! :-) All the best, simon
Re: GNOME Core Applications
I have a patch for gnome-contacts bit rotting around: https://gitlab.com/jonsger/Guix/commit/6c4103783ec937026e270c347b471673eb6ee0aa I think it build but didn't start. Back then it was required to base it on top of core-updates. But I think it now can be done on top of master. On 13.11.19 08:04, Raghav Gururajan wrote: Hello Guix! Based on information from [1], [2], [3] and [4]; I have formulated a chart to keep track of things easily. :-) CHART: https://calc.disroot.org/2nu6mpf88ynq.html As a start, I will be working on packaging gnome-contacts, gnome-music and gnome-weather. If anyone did any task(s) from the chart, please let me know and I will update the chart accordingly. [1] https://git.savannah.gnu.org/cgit/guix.git [2] https://blogs.gnome.org/mcatanzaro/2017/08/13/gnome-3-26-core-applications/ [3] https://blogs.gnome.org/mcatanzaro/2016/09/21/gnome-3-22-core-apps/ [4] https://issues.guix.gnu.org/issue/35586 Regards, RG.
Re: Make geckodriver part of Icecat package [Was: Packaging "single file"]
Hi Guix, Le 11/06, Tanguy Le Carrour a écrit : > Le 11/05, Tanguy Le Carrour a écrit : > > But, all of sudden, I wonder if `geckodriver` could not be part of > > icecat, like `chromedriver` was part of ungoogled-chromium?! > > 1) could geckodriver be built and distributed with icecat? or > 2) should I work on packaging it? or > 3) is there a way to package the pre-built binary? Sorry to see that I'm the only one having the problem! :-( Anyhow, thanks to the discussion about profiles, I found a solution! Actually, a workaround: go back in time where `ungoogled-chromium` was available and install it in a dedicated profile! Profiles are very handy, indeed! :-) If the discussion around icecat/geckodriver comes up again in a near (or distant) future, I'd still be very much interested! Regards, -- Tanguy
Re: #850644: RFP: Guix in Debian
Vagrant Cascadian writes: > On 2019-05-28, Vagrant Cascadian wrote: >> On 2019-05-16, Vagrant Cascadian wrote: >>> So in a bit of a focused run of packaging, I've been chasing the >>> dependency chain necessary to get guix building on Debian: > > Summary: all the dependencies are in Debian! Awesome :D signature.asc Description: PGP signature
Re: gnu: python: Update to 3.8.0.
Hi Marius, hi Gábor! Le 11/04, Gábor Boskovits a écrit : > Tanguy Le Carrour ezt írta (időpont: 2019. nov. 4., H, > 11:50): > > Le 11/04, Gábor Boskovits a écrit : > > > Tanguy Le Carrour ezt írta (időpont: 2019. nov. 4., > > > > `./pre-inst-env guix build --rounds=2 python@3.8` always fails with: > > > > """ > > > > output ‘/gnu/store/…-python-3.8.0’ of ‘/gnu/store/…-python-3.8.0.drv’ > > > > differs from previous round > > > > """ > > […] > > First time I hear of diffoscope! I had a look at the output (html > > attached), but couldn't make sense of it! > Nice, one thing that looks problematic is that there seems to be a mismatch > in the hash. > At one line you can see the shabang modified to a different path... > I don't yet know the reason of that, but it quite suspicious... > One thing, when dealing with things like like this, one should first fix > the readable differences, > and only then dig deeper, as fixing those often cascade, and fix more than > anticipated. Sorry it took me so long, but I finally had some time yesterday evening to go through the report! I found 4 types of errors: 1. `stat` reporting a different "Birth" for folders, which I assume are perfectly normal. 2. different paths for `python3.8` in the shebang of some scripts. 3. different paths in prefix for `python3.8` (some origin as above). 4. everything else is "Max report size reached"! I don't really know where to go from here? Am I supposed to investigate errors of type 4?! Regards, -- Tanguy
