IRC channel logs


back to list of logs

<joshuaBPMan>Hey guix, I think my simple firewall may be preventing ntpd to run...what port does ntpd use?
<joshuaBPMan>It seems like it is port 123
<atw>joshuaBPMan: is your system clock wrong and that's what you're trying to fix? I ask because I had that problem and fixed it with a magic tlsdate invocation
<joshuaBPMan>atw: actually no. My system clock seems just fine.
<joshuaBPMan>Tor is not working.
<joshuaBPMan>I take that back. "Feb 5 14:39:57 localhost ntpd[333]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized"
<joshuaBPMan>maybe, I need to open port 333?
<atw>to be clear, running date gave an answer that I knew was wrong. Is that the case with you?
<joshuaBPMan>Not really. It seems to be just fine.
<atw>ah, unfortunately your issue is beyond me, then :/
<joshuaBPMan>I need to get going night all.
<scmguru>Good night, all.
***daviid is now known as Guest84229
***Guest84229 is now known as daviid
***calher is now known as KE0VVT
***stallman is now known as akko
<apteryx>atw: even if your system clock is wrong, with current Guix and the default ntp-service-type, it does large adjustments which should sync the date with the NTP servers.
<apteryx>(if your machine is connected to the Internet, that is)
<apteryx>it used to be that it'd be configure to refuse doing so, leaving you with a broken date until you fixed it in the BIOS/UFI, or changed your CMOS battery.
***apteryx_ is now known as apteryx
<civodul>Hello Guix!
<efraim>can I run a service from a specific directory? 'with-directory-excursion' didn't work at first attempt and I didn't see any examples of it in gnu/services
***w2gz is now known as w1gz
<iyzsong>efraim: For shepherd service's working directory? 'fork+exec-command' has a '#:directory' keyword argument for that.
<efraim>iyzsong: thanks!
***nly is now known as nlyy
***nlyy is now known as nly
<jfred>So I'm trying to write a service, and I'm looking at an existing service for reference because I'm running into issues. I'd like to just try running it by hand to see what's going on, but looking at an existing service for reference... I'm not sure where to find the correct binary. I'm guessing this is because the
<jfred>server package isn't installed in root's profile here? Is there a separate profile used for services/is there a quick way to find the store path my shepherd service will attempt to use?
<jfred>I think what I'm looking for is an equivalent of 'systemctl show' because the gexp for my 'start' action should've been expanded at install-time... I think
<kirisime>Guix now uses guile 3, but my daemon is old. Should my things still work or do I need to upgrade te system profile now?
<Nios34>How to install guix without Internet connection?
<Nios34>I use --no-subtitles, but it still download from Internet
<wingo>--no-substitutes you mean?
*wingo not sure what the answer is though!
<kirisime>Nios34: It needs to download sources.
<Nios34>the option in the "guix system" command
<Nios34>So, How to
<kirisime>The way you might be able to perform an offline install is if your installer system has everything, bit by bit, that the installed system needs already present in the store.
<kirisime>Or if it has all the sources and you're actually willing to sit through all that compiling.
<Nios34>No Official images including that, right?
<Nios34>can I assign a mirror for These sources?
<kirisime>Nios34: You can run your own substitute server if your offline machine is actually on an isolated LAN.
<kirisime>You can also easily import and export store paths between guix systems.
<kirisime>The official install media contains enough stuff for itself, which includes a kernel. Therefore during the install you neither need to download or build a kernel.
<kirisime>It follows that if you have a guix system running that system should be able to replicate itself offline.
<Nios34>So how to install a very small guix
<Nios34>Only use the built-in store
<kirisime>If you need one, guix disk-image can be used to create an ISO from a system definition.
<NieDzejkob>I think Nios34 might be highly constrained by the bandwidth of their internet
<Nios34>I mean Installing to a PC
<kirisime>You want to download everything only once then?
<Nios34>I'm close to crashing :-(
<Nios34>I think all in one images is the best solution
<efraim>A rough estimate about 2 years ago had all of the packages for one architecture at 75 GB. Probably less for just sources.
<zzappie>Hello guix!
<sneek>zzappie, you have 1 message.
<sneek>zzappie, sirgazil says: some of the talks in already have videos (click the links to go to each talk page and watch them).
<zzappie>sneek: Cool! Thanks
<zzappie>I think i did already ask this. But I can't find it neiter in chat logs nor in manual... What shall I do to update profile env?
<zzappie>I have GUILE_LOAD_PATH set to
<zzappie>".../2.2" but i got guile-next installed
<NieDzejkob>what is GUILE_LOAD_PATH set to by ~/.guix-profile/etc/profile?
<NieDzejkob>If it's 3.0, you need to relaunch your shell (relogin, reopen terminal, recreate tmux pane, something like that)
<NieDzejkob>oh, and you'll need some guile3.0-* package too, I think
<NieDzejkob>so that there's a point in setting the variable
<zzappie>NieDzejkob: It set to /share/guile/site/2.2
<zzappie>but yea I've installed guile3.0-readline and now I have GUILE_LOAD_PATH pointing to 3.0
<zimoun>hi Guix!
<zzappie>Is it normal that I have some variables set twice? e.g. I got EMACSLOADPATH and GUILE_LOAD_PATH prepending emacs27:emacs26 and guile2.2:guile3.0 accordingly
<zzappie>hi zimoun!
<civodul>hey zimoun!
<civodul>zzappie: yes, that's normal
<civodul>for example, both guile-next and guile claim the GUILE_LOAD_PATH variable, that's why
<zzappie>but what happens when guile2.2 lib stumbles upon 3.0 compiled path that is listed first in GUILE_LOAD_COMPILED_PATH?
<NieDzejkob>zzappie: it will skip the incompatible bytecode
<NieDzejkob>(I know that because it prints a warning when it does that and it's REALLY annoying)
<zimoun>I am trying to give at look at and have the same for Guix. Killer feature if SWH could ingest all the sources of Guix packages. :-) However, I am bit lost about our patches (the ones living in gnu/packages/pacthes/) and the other ones living upstream (see llvm-pacth in gnu/packages/julia.scm for example).
<zimoun>The sources.json is defined here:
<jonsger>civodul: nice that we can reproduce the libgc issue on Guix itself...
<kirisime>How come GNOME boxes depends on govirt-1.0 when 0.3.7 is the latest version
<zzappie>NieDzejkob: cool I was thinking that I've messed up something when saw these messages :)
<civodul>zimoun: did you take a look at packages-json-builder in guix-artwork.git?
<civodul>this is what produces , which is almost like sources.json
<ngz>Hello. I'm looking at "crates-io.scm", and I wonder what is the reason to add #:skip-build? #t to a Rust package. Likewise, when one should hide a package with hidden? property? This is rather obscure to me.
<NieDzejkob>ngz: Rust libraries get compiled differently based on settings set by the program that uses them, that might be one of the reasons for skip-build?
<ngz>NieDzejkob: OK. Could you give an example ? How do I know, as a packager, when I need #:skip-build? or not?
<zimoun>civodul: Yes. :-) It is just that I do not understand if patches are part or not of sources. For "our" patches, it is ok because they are in Git so fixed by the Guix commit when falling back. However, I do not know what to do with upstream patches.
<civodul>zimoun: the patches in the Guix source tree are in the source tree :-)
<civodul>those that are not there are those referred to by an origin, as you found out
<civodul>i guess if you compute the closure of a set of packages (similar to 'package-closure') and restrict to origins, you should have all the sources
<zimoun>civodul: I see. Thank you.
<NieDzejkob>efraim: Why does rust-autocfg-0.1 skip build, while rust-autocfg-1.0 doesn't?
<civodul>oh, Anki, thanks smithras! :-)
*zzappie afk
<dftxbs3e>civodul, hey! I'm so disappointed I couldnt come to the rest of GNU Guix talks, we were up late due to some partying the previous day and GNU Guix talks were all in the morning..! :-( -- Been very happy to finally put a face behind the GNU Guixers! -- By the way, why are some talks not recorded on FOSDEM page? Did you refuse recording or is it FOSDEM technical teams having some delay?
<NieDzejkob>So, it looks like the sources of the ocaml package ship a 3MB binary blob that's required for building (see boot/). Is that not a violation of Guix policy?
<mjw>dftxbs3e, the presenter has to review the recording before they publish it. So it just takes time till everybody has reviewed their talk, I believe everything was recorded. Review is simply making sure it starts and ends correctly and that the right audio track was used. It was all automated.
<dftxbs3e>mjw, alright I see! Interesting & great process. Thanks.
<mjw>dftxbs3e, there was even a talk about it :)
<dftxbs3e>mjw, ah yeah.. friends told me about that! Will have a look :)
<pkill9>is there an email cline that lets you read emails like reddit threads?
<NieDzejkob>I'm not sure what you mean here, but I'm using neomutt and it does support sorting by thread
<nckx>NieDzejkob: There is no policy, just a very stern frowny face. It's also a judgement call: $fun_game with a 3 MiB binary blob is unlikely to be accepted; $important_lang is tolerated.
<nckx>Same with many MLs and Schemes. :-/
<pkill9>NieDzejkob: i mean that you can read the contents of all the emails in an email thread under each other
<pkill9>so all the emails are open, and replies are indented
<civodul>hey dftxbs3e!
<civodul>actually i'm trying to review my video but somehow failing to fix the A/V offset in there
<civodul>pretty weird
<civodul>apart from that, their video machinery is truly impressive
<efraim>NieDzejkob: just saw the hilight now. no reason in particular. Ideally we'd have no packages hidden and we'd not have skip-build on rust packages but sometimes its unavoidable. I'm slowly going through to unhide and build the rust packages
<civodul>on core-updates Python 3.8 is taking ages while running its test_asyncio
<civodul>anyone else seeing this?
<civodul>it's been running for 1hr and seemingly doing not much apart from printing the load average
<bandali>ngz, hey, anything else needed for getting emacs-gnus-harvest merged?
<ngz>bandali: Hmmm. I somehow lost track of your patch.
<scmguru>Good afternoon, all.
<bavier>scmguru: hi!
<mbakke>civodul: that does not sound right (the hanging python test)
<civodul>mbakke: it eventually completed!
<civodul>but it took 1h30 or so
<civodul>just that one test
<civodul>(i'm testing core-updates with my patches)
<mbakke>weird, I have certainly built Python on that branch in shorter amounts of time
<civodul>yeah, dunno, non-determinism?
<mbakke>sounds like it, maybe dependent on kernel version or some specific hardware
<mbakke>I have patches for glibc 2.31 and binutils 2.34 coming up, as well as bumping the kernel headers to 5.4
<civodul>we might be entering an endless loop, but that's part of the game!
<mbakke>the bad news is that glibc 2.31 requires patching each and every GCC we have, as well as the other glibc packages :/
<mbakke>heheh :)
<civodul>oh, patching GCC?
<mbakke>yes, libsanitizer specifically
*mbakke prepares patches
<civodul>aaaah, that one again
<civodul>i wonder if we could unbundle it
<dftxbs3e>civodul, following your talk at FOSDEM, we're thinking of using GNU Guix to build container images and kubernetes to orchestrate and scale an infrastructure with them. We're looking into providing non-profit reliable managed hosting for Free Software around France, as well as maybe re-engineering YunoHost with that as well (with lighter k3s).
<civodul>dftxbs3e: sounds exciting!
<civodul>who is "we"?
<dftxbs3e>civodul, few friends and myself that you don't know so it's not really relevant to say heh
<civodul>note that YunoHost is mentioned in :-)
<dftxbs3e>we arent structured yet, I'll be sure to give a link or something once we are
<kirisime>My GNOME boxes doesn't work because GUIX doesn't provide a populated osinfo database. How would I get one?
<vagrantc>so, i was looking at packaging reprotest ... but then i wondered if it wouldn't make sense to integrate that into guix instead
<vagrantc>or rather, integrate that sort of functionality
<civodul>vagrantc: it could be useful, that's for sure
<civodul>i don't know exactly how it could be integrated
<civodul>in the meantime having a reprotest package can help!
*civodul has to run, ttyl!
<vagrantc>well, the basic idea would be to *not* do some of the things to normalize the build environment and then do two builds and compare the results
<vagrantc>e.g. build-path, time, timezone, locale, etc.
<bavier>or have the daemon randomize those things
<vagrantc>normally, you *want* those things normalized, but if you want to do a more thorough test ...
<bavier>time is typically checked for already with --check
<vagrantc>there's time, and then there's time :)
<bavier>but other things that differ between systems would be nice to check
<vagrantc> varies time by something slightly over 1 year and 32 days or something
<vagrantc>to ensure the month and year are also different
<bavier>ah, nice
<vagrantc>many things will embed a timestamp, but only the year/month parts of it
<vagrantc>not sure if there's a way (other than libfaketime) to vary time in a container ... uses virtual machines with a clock set in the future
<vagrantc>also catches failure-to-build-in-the-future bugs
<vagrantc>libfaketime triggers issues in many cases
<zzappie>Anyone having issues with geiser hanging when importing and autocompleting big guix package modules?
<bandali>ngz, my luck :p
<ngz>bandali: Could you send me the patch again, in private, so that I can apply it? Thank you.
<bandali>ngz, sure, just forwarded the message. let me know if that works
<ngz>bandali: Got it. Thanks. I'll apply it in a while. I suspect an aggressive inbox clean-up on my side.
<bandali>ngz, cool, and thank you!
*zzappie just realized that sneek is a bot
<ngz>bandali: I applied it. Now closing the report.
<mbakke>zzappie: humansnack
*zzappie wonders what'll happen if one'll tell sneek to later tell sneek to tell sneek something
<NieDzejkob>this has been tried a few times already...
<NieDzejkob>sneek: later tell sneek: botsnack
<NieDzejkob>sneek: later tell sneek: you rock
<sneek>Umm, I'm right here.
<NieDzejkob>sneek: later tell zzappie: if you say botsnack, it ignores you and just smiles >:(
<zzappie>well I didn't get the last one
<NieDzejkob>efraim: Is there any reason for the rust-grep-cli-0.1 package to depend on rust-winapi-util? It's only required when building on windows, which is far from a supported platform :D
<zzappie>NieDzejkob: ah now I got the botsnack thing :)
<bandali>ngz, thank you kindly :-)
***dftxbs3e_ is now known as dftxbs3e
<vagrantc>is there a way for guix build to just show the spinner rather than the full build log? i see --quiet, but that disables all output
<vagrantc>when i do guix environment --ad-hoc package ... it just shows a one-line with spinner
<ngz>bandali: yw
*lispmacs[work] has landed
<efraim>NieDzejkob: if it doesn't have skip-build and it builds without rust-winapi-util then it can be removed, although we do ocasionally do cross-building to windows
<NieDzejkob>efraim: OK. If I'm updating a package, should I remove skip-build? Also, does your comment on cross-building to windows apply here, or is it just an inconsequential (yet still interesting) remark?
<NieDzejkob>(I'm working on updating ripgrep to 11.0.2)
<bavier>meson-build-system doesn't support cross-compilation?
<efraim>you should remove skip-build if it's not too much work. I found that often the packages don't build without the windows specific crates even if we don't need them
<bavier>so disappointing...
<efraim>i ran into test errors with ripgrep 11.0.2
<NieDzejkob>yeah, one of the closely-tied deps needed an update
<efraim>here's what I have in my stash from the last time i tried:
<leoprikler>If I do guix build --system=SYSTEM, do I get the same result as berlin, or do I cross-compile?
<vagrantc>if you enable the qemu-binfmt stuff, i think it should in theory come outthe same, but i woudl guess cross-compile would come out different
***deesix_ is now known as deesix
<jbnote`>hi, is it expected that after installing emacs-gnuplot, I still have to manually add ${GUIX_PROFILE}/share/emacs/site-lisp/guix.d/gnuplot-0.7.0 to EMACSLOADPATH so that I can do (require 'gnuplot) or load gnuplot-mode in emacs ? other packages like forge installed in a directory alongside under guix.d/ seem not to require this. Should I investigate/report the behaviour?
***jbnote` is now known as jbnote
<vagrantc>anyone able to help with a description of:
<vagrantc>otherwise, i have the package ready to push
<bavier>vagrantc: "@code{jsondiff} is a Python library which lets you compare, diff, and patch JSON and JSON-like structures in Python."?
<NieDzejkob>jbnote: do you have emacs installed in the same profile?
<vagrantc>bavier: sold!
<vagrantc>bavier: and thanks :)
<bavier>vagrantc: np
<vagrantc>the descriptions and synopsis often seems the most difficult part of packaging :)
<vagrantc>is it possible to generate something that gets included in the description as part of the package build process?
<vagrantc>diffoscope has many optional dependencies, and a way of outputting them ... but it would easily get out of sync if i had to hard-code those into the description
<bavier>vagrantc: no way to do that, no. unless you run the tool after a build and then update the description.
***jonsger1 is now known as jonsger
<vagrantc>i guess i should just add a note to the description about diffoscope --list-missing-tools
<shader>heyo, what's the right syntax for setting my shell to zsh in the user config part of the system definition? I'm guessing I need to use some function that returns the actual path to the binary...
***jonsger1 is now known as jonsger
<leoprikler>(file-append zsh "/bin/zsh")
<alextee[m]>does guix work on pinephone?
<Telior>please say it does lol
<vagrantc>it somewhat works on pine64+ and pinebook, so probably not terribly hard to get to work on pinephone ... but you'll probably need external wifi or something
<bavier>and iirc someone has done some work to get guix working on the purism 5
<nckx>leoprikler: --target cross compiles, --system performs a ‘native’ (or emulated by qemu-binfmt-service vagrant mentioned) build. The latter is what build farms use.
<leoprikler>So if I specify --system without binfmt, it fails? Or does it use magic to still work?
<nckx>binfmt is the magic.
<nckx>Without it, no dice.
<leoprikler>Huh. Then I seem to have binfmt without even knowing about it.
<leoprikler>Very well, I shall not complain.
<bavier>binfmt is very cool
<nckx>leoprikler: Well, x86_64 can ‘natively’ run i686 code, and maybe there's some similar situation on ARM. Maybe that's what you're doing?
<nckx>Or it's been added to the defaults 🙂
<leoprikler>You got me, I'm fixing sane-backends on i686
<nckx>Thank you for your service.