Re: ntpd: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
On Fri, Nov 01, 2019 at 10:13:11PM +0100, Matias Jose Seco Baccanelli wrote: > Benvenuti Guixers, > i wanted to share a time riddle which i'm unable to solve. > Actually my timezone is aligned to : > (timezone "Europe/Rome") > > Yet, system time is 1h 20m behind the official one > ~$ date > ven 1 nov 2019, 21.49.30, CET > (23.09 at the time of writing) > > My system was installed with the graphical installer, guix version > 1.0.1, Mate DE. Hm... I'm not sure but I have a guess. By default, ntpd will not change your clock if it is very wrong. If it is only a couple minutes wrong, then ntpd will slowly adjust the time, but if it is wrong by some large threshold, ntpd will simply give up. However, you can run ntpd with '-g, --panicgate', which will allow ntpd to make big adjustments to your clock. In Guix, this is called 'allow-large-adjustment?' and we made it the default in September 2019. [1] Maybe your system has not been updated since then? As root, can you check with `guix describe` and let us know exactly what it says? If that's the root cause, try doing, as root, `guix pull && guix system reconfigure [...] && reboot` to get the new NTP service. Or you could try a more targeted fix by adding the 'allow-large-adjustment? #t' flag to your config.scm. Please ask on IRC #guix if you need help :) [1] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=08b4a10fa6bc535cd99d65f0233dd027153878eb signature.asc Description: PGP signature
Re: `guix install protobuf:static` headers?
zimoun writes: > Dear, > > When I run `guix install protobuf:static -p path/to/profile` then I > expect that the headers are in "path/to/profile" but they are not. > However, they appear without the ":static" flag. > > I am confused. > > Moreover, the static libraries are even copied without the flag ":static". > > --8<---cut here---start->8--- > (add-after 'install 'move-static-libraries >(lambda* (#:key outputs #:allow-other-keys) > ;; Move static libraries to the "static" output. > (let* ((out(assoc-ref outputs "out")) > (lib(string-append out "/lib")) > (static (assoc-ref outputs "static")) > (slib (string-append static "/lib"))) >(mkdir-p slib) >(for-each (lambda (file) >(install-file file slib) >(delete-file file)) > (find-files lib "\\.a$")) > --8<---cut here---end--->8--- > > > What should be the correct behaviour of "out" vs "static"? 'static' outputs typically contain *only* the .a libraries, as you found. If you want the headers, you need to add protobuf:out too. I think there were proposals to start using a 'dev' output for headers and such, but don't know if it got anywhere. signature.asc Description: PGP signature
Re: “Guix Profiles in Practice”
On Nov 3, 2019, at 9:24 AM, Ludovic Courtès wrote > Now, this would be very much stateful: you can’t tell in advance whether > you’re going to build a new profile based on the current Guix, or > whether you’re going to reuse a previously cached profile that could be > arbitrarily old. That doesn’t sound great. What if something identifying the profile (directory name? config file?) included info about the Guix revision it was built from? That way a profile would be reused if it’s built from the same Guix revision, but if you switch revisions it’d be rebuilt. I’m not sure how this would interact with a profile built from packages in multiple channels.
Re: upgrading systems with <= 2 GiB RAM
Marco van Hulten writes: > Marius— > > Je 31 okt 23:49 skribis Marius: >> Marco van Hulten writes: >> >> > I have an oldish amd64 system with 2 GiB of memory, but it is fast >> > enough to use as a media center. Guix was last updated early this >> > year. Upgrading it now takes many days. It keeps on swapping (using >> > quite consistently 2 of 4 GiB of swap available). >> > >> > Do you think the swapping is the reason that it takes so long? >> > >> > Would it be a general strong advice to use more than 2 GiB, or is it >> > likely useful to give details like which program is compiling (as in a >> > proper bug report)? >> >> Ideally you should not have to compile anything. Have you authorized >> the ci.guix.gnu.org signing key? > > I did not authorize that signing key. Now that I have, upgrading the > system and installing packages goes much faster. Glad it worked! It would be ideal if Guix printed a warning when using a substitute server whose signing key is not authorized. Any volunteers? :-) signature.asc Description: PGP signature
Re: “Guix Profiles in Practice”
Hi, "Thompson, David" skribis: > 'guix environment' is a very composable command, and it's not clear to > me how I would add the stuff I want onto it and it's even less clear > if it's a good idea. Probably not. So, I wonder if maybe a new > subcommand, say 'guix develop', could address this common development > use-case while allowing 'guix environment' to continue being the swiss > army knife that it is. Some simple naming conventions could make this > tool "just work." Running 'guix develop' would check for a profile > symlink with some canonical name, for example '.guix-develop-profile'. > If it exists, it applies the environment variables and spawns a > subshell. If it doesn't exist, it looks for a 'develop.scm' file > (canonical name TBD), builds the profile, symlinks it to > '.guix-develop-profile', and then does the prior steps. The tool > would provide a mechanism to update, etc. and it could even be > expanded later to spawn services like databases. That sounds like a good idea. ‘guix develop’ could keep the profiles it manages under ~/.cache/guix. Now, this would be very much stateful: you can’t tell in advance whether you’re going to build a new profile based on the current Guix, or whether you’re going to reuse a previously cached profile that could be arbitrarily old. That doesn’t sound great. Perhaps we should focus on improving the performance of ‘guix environment’ first and foremost? Thanks, Ludo’.
Re: upgrading systems with <= 2 GiB RAM
Marius— Je 31 okt 23:49 skribis Marius: > Marco van Hulten writes: > > > I have an oldish amd64 system with 2 GiB of memory, but it is fast > > enough to use as a media center. Guix was last updated early this > > year. Upgrading it now takes many days. It keeps on swapping (using > > quite consistently 2 of 4 GiB of swap available). > > > > Do you think the swapping is the reason that it takes so long? > > > > Would it be a general strong advice to use more than 2 GiB, or is it > > likely useful to give details like which program is compiling (as in a > > proper bug report)? > > Ideally you should not have to compile anything. Have you authorized > the ci.guix.gnu.org signing key? I did not authorize that signing key. Now that I have, upgrading the system and installing packages goes much faster. Thanks for this! —Marco
Re: ntpd: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
On Fri, 1 Nov 2019 22:13:11 +0100 Matias Jose Seco Baccanelli wrote: > Benvenuti Guixers, > i wanted to share a time riddle which i'm unable to solve. > Actually my timezone is aligned to : > (timezone "Europe/Rome") > > Yet, system time is 1h 20m behind the official one > ~$ date > ven 1 nov 2019, 21.49.30, CET > (23.09 at the time of writing) > > My system was installed with the graphical installer, guix version > 1.0.1, Mate DE. > [...] Salve! In addition to previous information, i wanted to ask if it would be possible to solve the time synchronization by installing further software. Actually my scm declares ntp service through %desktop-service variable. Should i add other properties ? Consider that i'm a beginner for Guix, so i don't know if i'm classifying correctly all the technical elements ^^ Thanks, have a wonderful time, Matias pgpfhOAmMJwnL.pgp Description: OpenPGP digital signature
Re: Unexpected results with Guix.
On Sun, Nov 03, 2019 at 03:26:01AM +, Jone wrote: > Thanks for reminder about /var/guix/profiles. > > ❯ guix package -l | grep Generation > Generation 158Nov 02 2019 15:27:19(current) > ❯ ls -1 /var/guix/profiles/per-user/jone/ > current-guix > current-guix-16-link > guix-profile > guix-profile-158-link > current-guix -> current-guix-16-link > current-guix-16-link -> /gnu/store/bcbvw5n1pna08pj7zqfflb5zs9yfj90y-profile > guix-profile -> guix-profile-158-link > guix-profile-158-link -> /gnu/store/wb3b3mj3spny5jx2bj00imrwf5bjw373-profile > ❯ ls /gnu/store/bcbvw5n1pna08pj7zqfflb5zs9yfj90y-profile/bin/ > guix guix-daemon > > > But it didn't give me any useful information. Please also try `guix gc --referrers`. It is *not* the same as `guix gc -R`. Then you can compare to `guix package -l`. Regards, Florian
