Re: Update on 1.0.1
Hi Mathieu, Mathieu Othacehe skribis: >> #1 may have a simple fix. #2 less so. WDYT, Mathieu? > > #1 may have a simple fix but it would require to have the output of > "connmanctl services" (as you requested) to better understand why the > name is #f. Plus I cannot find a way to create a network with an empty > SSID. > > So we could change the regex as you suggested but without any guarantee. Yeah. > #2 is much more annoying and hard to fix. As discussed previously, we > shall force a reboot on installer failure, but we have to do it in a > way that allows the user to report the backtrace. True. > So I think we should proceed and fix those issues later. Sorry I don't > have anything better to propose :( Sounds like a good plan to me! (And no need to be sorry! :-)) I’ll create a ‘version-1.0.1’ branch with the aim of releasing the whole thing maybe tomorrow or at least by Tuesday. Thanks for your feedback, Ludo’.
Re: [BLOG] custom kernel config
Another thing: > The next step is to run > > ```shell > make localmodconfig > ``` > > and note the output. Do note that the '.config' file is still empty. > The output generally contains two types of warnings. The first start > with "WARNING" and can actually be ignored in our case. The second read: > ```shell > module pcspkr did not have configs CONFIG_INPUT_PCSPKR > ``` > > For each of these lines, copy the CONFIG__ portion into the > '.config' in the directory, and append "=m", so in the end it looks > like this: > ```shell > CONFIG_INPUT_PCSPKR=m > CONFIG_VIRTIO=m Since I'm not starting from a blank .config, I wanted to compare the output of `make localmodconfig' and, even better, automatically enable all the missing modules. In my case there was some 150 modules and that would have been a lot of work. So I wrote those quick and dirty Emacs functions: --8<---cut here---start->8--- (defun kernel-compare-configs (file1 file2) "Go through all CONFIG_* variables in FILE1 and report those in file2 which are not set." (interactive "f\nf") (let ((buffer1 (find-file-noselect file1)) (buffer2 (find-file-noselect file2)) result) (with-current-buffer buffer1 (goto-char (point-min)) (while (search-forward "CONFIG_" nil 'noerror) (let ((var (symbol-name (sexp-at-point (with-current-buffer buffer2 (goto-char (point-min)) (when (search-forward var nil 'noerror) (forward-char) (let ((value (word-at-point))) (unless (or (string= value "m") (string= value "y")) (push var result result)) (defun kernel-enable-configs (file variables) "Variables must be a list of strings. Example: (\"CONFIG_MODULES\")" (let ((buffer (find-file-noselect file))) (with-current-buffer buffer (dolist (var variables) (goto-char (point-min)) ;; Match exact variable only, e.g. CONFIG_MODULES should not match ;; CONFIG_MODULES_TREE_LOOKUP. (if (not (re-search-forward (concat var "[= ]") nil 'noerror)) (warn "Variable %S not found" var) (beginning-of-line) (let ((kill-whole-line nil)) (kill-line)) (insert (format "%s=y" var))) ;; Example: ; (kernel-enable-configs ; "/home/ambrevar/.guix-packages/ambrevar/linux-laptop.conf" ; (compare-kernel-configs ; "localmodconfig.config" ; "/home/ambrevar/.guix-packages/ambrevar/linux-laptop.conf")) --8<---cut here---end--->8--- The above is not general enough but that's a start. I wonder if there aren't some dedicated tools out there already. Anyone? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Update on 1.0.1
On Thu, May 16, 2019 at 01:38:39PM +0200, Ludovic Courtès wrote: > I’ll create a ‘version-1.0.1’ branch with the aim of releasing the whole > thing maybe tomorrow or at least by Tuesday. > If this does not go through the TP, can we send a download link for a newer PO file adapted to current doc/guix.texi? Also it would be good if you could make sure http://guix.info/manual/en/html_node/Binary-Installation.html#Binary-Installation will mention Guix version 1.0.1 instead of telling users to download version UNKNOWN, but maybe this only happened because of the 1.0.0 %base-packages warning added to the manual. Regards, Florian
Re: Update on 1.0.1
Hi, "pelzflorian (Florian Pelz)" : > On Thu, May 16, 2019 at 01:38:39PM +0200, Ludovic Courtès wrote: > > I’ll create a ‘version-1.0.1’ branch with the aim of releasing the > > whole thing maybe tomorrow or at least by Tuesday. > > > > If this does not go through the TP, can we send a download link for a > newer PO file adapted to current doc/guix.texi? I agree that it should go through TP[1], nonetheless there is a way to generate the pot file to merge it and get an updated po file. From a fresh checkout of the git tree you only have to follow these steps: $ guix environment guix [env]$ ./bootstrap [env]$ ./configure [env]$ make doc-pot-update [env]$ msgmerge /path/to/old/de.po po/doc/guix-manual.pot > /new/de.po And that /new/de.po file will contain the updated messages for the last version of the manual. > Also it would be good if you could make sure > http://guix.info/manual/en/html_node/Binary-Installation.html#Binary-Installation > will mention Guix version 1.0.1 instead of telling users to download > version UNKNOWN, but maybe this only happened because of the 1.0.0 > %base-packages warning added to the manual. This link, the official one I guess, https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation contains the correct version. Is the manual published in guix.info generated automatically? Maybe it is something related with the build process... Happy hacking! Miguel [1] Probably GNU's ftp could be used for that too, as a -pre release. AFAIK, older pre-releases can be removed if the folder grows up too quickly: https://www.gnu.org/prep/maintain/html_node/FTP-Upload-Standalone-Directives.html
Re: Update on 1.0.1
On Thu, May 16, 2019 at 02:41:02PM +0200, Miguel wrote: > Hi, > > "pelzflorian (Florian Pelz)" : > > On Thu, May 16, 2019 at 01:38:39PM +0200, Ludovic Courtès wrote: > > > I’ll create a ‘version-1.0.1’ branch with the aim of releasing the > > > whole thing maybe tomorrow or at least by Tuesday. > > > > > > > If this does not go through the TP, can we send a download link for a > > newer PO file adapted to current doc/guix.texi? > > I agree that it should go through TP[1], nonetheless there is a way to > generate the pot file to merge it and get an updated po file. From a > fresh checkout of the git tree you only have to follow these steps: > > $ guix environment guix > [env]$ ./bootstrap > [env]$ ./configure > [env]$ make doc-pot-update > [env]$ msgmerge /path/to/old/de.po po/doc/guix-manual.pot > /new/de.po > Thank you for explaining. I prefer doing `msgmerge --previous --nowrap /path/to/old/de.po po/doc/guix-manual.pot > /new/de.po` to get the old fuzzy messages and all messages on a single line. Regards, Florian
Re: Update on 1.0.1
Hi, "pelzflorian (Florian Pelz)" : > Thank you for explaining. You're welcome. :) > I prefer doing `msgmerge --previous --nowrap /path/to/old/de.po > po/doc/guix-manual.pot > /new/de.po` to get the old fuzzy messages and > all messages on a single line. I disagree with TP's --nowrap policy for my local copies. I have them in a git repository, and it is easier to check the history when the lines fit in a 80-column page. The --previous option is quite important though, I should have included that one. Best regards, Miguel
New Spanish PO file for 'guix' (version 1.0.1-pre1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix' has been submitted by the Spanish team of translators. The file is available at: https://translationproject.org/latest/guix/es.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
postgresql vs sqlite for Cuirass (was Re: Hackathon: Mumi and Cuirass)
Hello Björn, Björn Höfling writes: [...] >> 2) Cuirass > > On Guix days, we discussed the idea of using Postgresql as a backend. Please do you remember the rationale behind this idea? What is the issue with using sqlite? Why a client/server approach vs an embedded database? I don't have much experience with web applications backed by sqlite, but AFAIU sqlite is sometime "misunderstood" Some interesting arguments from sqlite developer: https://sqlite.org/whentouse.html#website --8<---cut here---start->8--- Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time. --8<---cut here---end--->8--- https://sqlite.org/np1queryprob.html --8<---cut here---start->8--- 200 SQL statements per webpage is excessive for client/server database engines like MySQL, PostgreSQL, or SQL Server. But with SQLite, 200 or more SQL statement per webpage is not a problem. SQLite can also do large and complex queries efficiently, just like client/server databases. But SQLite can do many smaller queries efficiently too. Application developers can use whichever technique works best for the task at hand. [...] N+1 Queries Are Not A Problem With SQLite --8<---cut here---end--->8--- [...] Thanks! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [BLOG] custom kernel config
Hi Efraim,
Efraim Flashner writes:
> I've cleaned up the blog post a bit and run it through a spell checker.
> I'm unsure about Linux-Libre vs linux-libre, regarding talking about the
> kernel and the package. I think I glossed over it well enough that I
> didn't actually get a custom kernel up and running on my laptop, but for
> the purpose of the blog post I don't think it's actually necessary.
>
> --
> Efraim Flashner אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
> title: Creating and using a custom Linux kernel on Guix System
> date: 2019-05-20 00:00
> author: Efraim Flashner
> tags: kernel, customization
> ---
>
> Guix is, at its core, a source based distribution with substitutes, and
> as such building packages from their source code is an expected part of
> regular package installations and upgrades. Given this starting point,
> it makes sense that efforts are made to reduce the amount of time spent
> compiling packages, and recent changes and upgrades to the building and
> distribution of substitutes continues to be a topic of discussion within
> Guix. One of the packages which I prefer to not build myself is the
> Linux-Libre kernel. The kernel, while not requiring an overabundance of
> RAM to build, does take a very long time on my build machine (which my
> children argue is actually their Kodi computer), and I will often delay
> reconfiguring my laptop while I want for a substitute to be prepared by
> the official build farm. The official kernel configuration, as is the
> case with many GNU/Linux distributions, errs on the side of
> inclusiveness, and this is really what causes the build to take such a
> long time when I build the package for myself.
>
> The Linux kernel, however, can also just be described as a package
> installed on my machine, and as such can be customized just like any
> other package. The procedure is a little bit different, although this
> is primarily due to the nature of how the package definition is written.
>
> The linux-libre kernel package definition is actually a procedure which
> creates a package.
>
> ```scheme
> (define* (make-linux-libre version hash supported-systems
>#:key
>;; A function that takes an arch and a variant.
>;; See kernel-config for an example.
>(extra-version #f)
>(configuration-file #f)
>(defconfig "defconfig")
>(extra-options %default-extra-linux-options)
>(patches (list %boot-logo-patch)))
> ...)
> ```
>
> The current linux-libre package is for the 5.1.x series, and is
> declared like this:
>
> ```scheme
> (define-public linux-libre
> (make-linux-libre %linux-libre-version
> %linux-libre-hash
> '("x86_64-linux" "i686-linux" "armhf-linux"
> "aarch64-linux")
> #:patches %linux-libre-5.1-patches
> #:configuration-file kernel-config))
> ```
>
> Any keys which are not assigned values inherit their default value from
> the make-linux-libre definition. When comparing the two snippets above,
> you may notice that the code comment in the first doesn't actually refer
> to the extra-version keyword; it is actually for configuration-file.
> Because of this, it is not actually easy to include a custom kernel
> configuration from the definition, but don't worry, there are other ways
> to work with what we do have.
Thank you for writing this! I'm sure many would-be power users are
stymied by the weird Scheme interfaces :-)
I just want to point out an (IMO) easier way to provide a custom kernel
configuration, that does not involve the "make-linux-libre" procedure:
--8<---cut here---start->8---
(define-public linux-libre/custom
(package
(inherit linux-libre)
(native-inputs
`(("kconfig" ,(local-file "kernel.config"))
,@(alist-delete "kconfig"
(package-native-inputs linux-libre))
--8<---cut here---end--->8---
At the end of the day, Linux-Libre is just a regular package that can be
inherited and overridden like any other :-)
signature.asc
Description: PGP signature
Re: guix package --search slow ?
Pierre Neidhardt skribis: > Ludovic Courtès writes: > >> We could probably improve the cold-cache timings by adding synopses and >> descriptions to the package cache that ‘guix pull’ builds in >> ~/.config/guix/current/lib/guix/package.cache, but that would also make >> that cache bigger. Not sure if it’s worth it. > > To be clear, did you mean it might not be worth it because of the size > it takes on the user's drive or because the increase in size might slow > down the lookup? If the cache is bigger, loading it may take a bit more time. On an SSD, I find the timings to be acceptable now, so I’m also a bit biased. Ludo’.
guix pack -f docker and name ?
Dear, I find a bit annoying 2 things when creating Docker images with `guix pack`. 1. The name of the tar is given at the end of the command `guix pack`. If you forget to track it, then you need to re-run `guix pack` (obviously with the very same parameters) to get it again. It is not super user-friendly. :-) What to think to add an option to name a symbolic link to this file in the store ? Currently, I am doing that by hand: guix pack -f docker ... # copy the name /gnu/store/-docker-pack.tar ln -s paste my-name In general, I choose my-name as - with something to quickly remember what it is and the to be sure of what it is. 2. Once loaded with `docker load < /gnu/store/-docker-pack.tar` then `docker image ls` list all the images. The REPOSITORY and TAG are not super helpful. :-) It is always: profile and . Maybe REPOSITORY should be guix and TAG should be -. Because when one has more than 2 images, after holidays it is not possible to remember or they needs to track in a separate file what it is. Maybe I am missing something. Please correct me if there is way. Or comment if you have suggestion. All the best, simon
Re: [BLOG] custom kernel config
On Thu, May 16, 2019 at 04:29:56PM +0200, Marius Bakke wrote:
> Hi Efraim,
>
> I just want to point out an (IMO) easier way to provide a custom kernel
> configuration, that does not involve the "make-linux-libre" procedure:
>
> --8<---cut here---start->8---
> (define-public linux-libre/custom
> (package
> (inherit linux-libre)
> (native-inputs
> `(("kconfig" ,(local-file "kernel.config"))
>,@(alist-delete "kconfig"
>(package-native-inputs linux-libre))
> --8<---cut here---end--->8---
>
> At the end of the day, Linux-Libre is just a regular package that can be
> inherited and overridden like any other :-)
I added that as an alternative way to use "just" a kconfig file.
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: [BLOG] custom kernel config
On Thu, May 16, 2019 at 01:10:37PM +0200, Pierre Neidhardt wrote: > Great work! > This proved invaluable for me (and I'm sure for many others), thank you so > much! > > Comments: > > > added in since I used replaced them in the extra-options keyword. > > Typo: "used replaced". > Ooops, looks like it was supposed to just be "replaced" > > ```shell > > make localmodconfig > > ``` > > Should be > > ```shell > guix environment linux-libre -- make localmodconfig > ``` Good idea! > > Cheers! > > -- > Pierre Neidhardt > https://ambrevar.xyz/ -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Update on 1.0.1
On Thu, May 16, 2019 at 02:13:02PM +0200, pelzflorian (Florian Pelz) wrote: > On Thu, May 16, 2019 at 01:38:39PM +0200, Ludovic Courtès wrote: > > I’ll create a ‘version-1.0.1’ branch with the aim of releasing the whole > > thing maybe tomorrow or at least by Tuesday. > > > > If this does not go through the TP, can we send a download link for a > newer PO file adapted to current doc/guix.texi? > Please include this updated German PO file: https://pelzflorian.de/guix-manual.de.po It would be nice if a 1.0.1 POT file were published on the TP even if it is not in time, so that the TP can again harbor the most current translations. Regards, Florian
Re: [BLOG] custom kernel config
Hi Marius,
Marius Bakke writes:
> I just want to point out an (IMO) easier way to provide a custom kernel
> configuration, that does not involve the "make-linux-libre" procedure:
>
> (define-public linux-libre/custom
> (package
> (inherit linux-libre)
> (native-inputs
> `(("kconfig" ,(local-file "kernel.config"))
>,@(alist-delete "kconfig"
>(package-native-inputs linux-libre))
>
> At the end of the day, Linux-Libre is just a regular package that can be
> inherited and overridden like any other :-)
I think this is the approach we should promote for now. I would prefer
to leave 'make-linux-libre' as an internal implementation detail, and
hopefully one with a limited life span.
Thanks,
Mark
