IRC channel logs


back to list of logs

<vagrantc>hrm. well, got a patch to update u-boot, but can't figure out the test failure...
***nonzen is now known as Guest55562
<g_bor_>hello guix!
<civodul>Hello Guix!
<civodul>oops PID 1 is stuck before opening its socket in /var/run
<civodul>"sudo gdb -ex 'attach 1'", nice way to start the day
<jonsger>somehow libzmf fails on i386, so LibreOffice could not be built on i386
<civodul>it turned out to be a process created by make-forkexec-constructor/container (so: 'clone') that was stuck like this:
<civodul>wingo: can it be that libgc internal locks are taken at the time of fork?
<civodul>for instance scm_i_finalizer_pre_fork doesn't (cannot?) do much about this, no?
<wingo>civodul: the only libgc threads are the mark threads. the finalizer thread is guile's
<wingo>in a pre-fork situation, we're still in the parent, everything still making progress
<wingo>scm_i_finalizer_pre_fork will join the finalizer thread (if any), making it so that there's only one guile thread running (unless you have a signal thread!0
<wingo>so the total set of threads at that point would be guile's main thread and the mark threads, which are waiting on a cond (because the world is not stopped) and which i don't think have any locks taken
<civodul>the mark threads could have locks taken no?
<civodul>there's nothing preventing that from happening, is there?
<civodul>oh, IceCat 60 released \o/
<g_bor_>civodul: rekado came up with the idea to do the introductory/whatever videos as an Outreachy project.
<wingo>civodul: i think the mark threads should be sleeping because it's not the mark phase
<wingo>but there's nothing to prevent a spurious wakeup though
<civodul>i had never witnessed it, but i suppose that's what happened here
<wingo>civodul: are you sure you have no signal thread?
<civodul>wingo: there may be one
<wingo>civodul: in that case you need to fix that first imo
<civodul>so you're saying that signal thread might have been consing?
<civodul>but primitive-fork doesn't try to terminate the signal thread for instance, does it?
<wingo>primitive-fork should warn if there is a signal thread
<civodul>oh that's right
<civodul>the signal thread is created lazily right?
<g_bor_>If that happens, then my wife is willing to comentor that. She has been working in education reseach for 3 years, and have a really nice gasp as what to introduce/emphasizing main points, grouping topics, and presenting a complex matter in a digestable from. Here I persume that these videos will be primarily user facing introduction/education/documentation type materials. She also has some exposure to guix :)
<civodul>wingo: created upon the first sigaction, which is hard to prevent in shepherd :-/
<civodul>g_bor_: i think that would be great!
<civodul>my only concern was whether this is a type of project that is acceptable for Outreachy
<civodul>it it is, i'm all for it
<civodul>(i think it's great if your wife is willing to comentor too, along with you or other Guix hackers)
<g_bor_>I guess rekado came to the conclusion that it is, should I ask about this on the mailing list? (I mean the Outreachy list)
<civodul>if that's fine with you, you could check whether the web site says anything, and then you can email the Outreachy list
<snape> what's happening?
<civodul>wingo: the signal thread doesn't show up in (all-threads), and thus primitive-fork doesn't complain:
<civodul>now in theory the signal thread isn't supposed to cons, right?
<g_bor_>civodul: ok, will do. Should I know of any alternative proposals, or this is currently the only candidate?
<civodul>snape: looks like evaluations of 'master' are failing like this:
<civodul>g_bor_: i believe this is the only one though i haven't been following as closely as i should
<g_bor_>all right.
<g_bor_>snape: I had some time to look at the cuirass web interface. It seemed to me that there were changes recently.
<wingo>civodul: i... think you're right? not sure.
<g_bor_>Last time I looked nearly all lines of a jobset summed up to the same number. Now it is vary different.
<ng0>what's this magic max length name we bake into our system?
<g_bor_>Also it seems that sometimes we get a bunch of do nothing stuff, I guess it is when commits follow in quick succession.
<ng0>max lnegth *of* a file name
<g_bor_>Do we have any delay build in, so that if there is for example 30 commits coming in 2 minutes we don't try to evaluate that?
<ng0>okay, got it
<jonsger>civodul: could that error coming from your commit about git-download? I'm using guile-git 0.1.0 on openSUSE
<snape>hi g_bor_! Yes indeed. Now, things that don't need to be built aren't built
<snape>it doesn't have anything to do with the web interface though
<snape>it's done at a lower level
<snape>g_bor_ what do you mean by "a bunch of do nothing stuff"?
<civodul>jonsger: yes, i think so, i'm looking into it
<jonsger>oke. it's definitly this commit. The commit before that works fine
***rekado_ is now known as rekado
<rekado>g_bor: in my opinion this is a project that would be acceptable for Outreachy.
<rekado>last time the organizers also made a point to highlight projects that did not require coding experience.
<civodul>jonsger, snape: 13512e1b8f63b4d8fcb188fac992aa390149fe65 should fix the evaluation errors
<civodul>rekado: oh that's really good then
<rekado>g_bor: I would be happy if we had more project proposals than that, though.
<rekado>g_bor: it would be great if your wife were willing to co-mentor that project.
<snape>civodul: great, thank you!
<civodul>well, i'm sorry for breaking things in the first place :-)
<jonsger>less then 40min for fixing a bug. You could make a lot of money with that :P
<civodul>snape: the bottom line is that Cuirass fails to distinguish between "failed" and "in progress" evaluations
<snape>civodul: true. I'll add a ticket about it
***efraim_ is now known as efraim
<rekado>civodul: can we add a “propagated” search path specification for GUIX_LOCPATH to glibc, so that installing a package using glibc would cause GUIX_LOCPATH to be added to etc/profile?
<divansantana>hello all :)
<divansantana>So... I'm trying to use a custom kernel. When doing a reconfigure it says I have to load shpchp kernel module for my /dev/nvme device. When I add that module for my custom kernel it says not found. Any idea what I can do?
<rekado>divansantana: this is because the newest kernel no longer provides the shpchp kernel module
<rekado>divansantana: Guix tries to keep you from doing something that might end up in an unbootable system.
<rekado>but in this case I think you can safely ask it to skip that check.
<rekado>hmm, I’m getting a bad error in a Python package running on the cluster.
<rekado>“Illegal instruction”
<rekado>that package uses pyqt, so I wonder if the Qt build might be tuned to the build host’s CPU.
<rekado>mbakke: any ideas?
<mbakke>rekado: IIRC Qt detects hardware capabilities at run-time.
<mbakke>Can you reproduce it on "core-updates"? Libffi used to have -march=native until recently.
<rekado>I haven’t tried it on core-updates yet; will see how far I get.
<divansantana>rekado: Excellent, thanks Rekado.
*rekado builds Python 3.7 on core-updates
<civodul>rekado: the more general problem is
<civodul>i think that can be solved at the profile level
<civodul>that would mean that the search path can only be computed once things have been built, though
<janneke>civodul: with one URL fix thanks to g_bor, wip-bootstrap now built `hello' for him too; what could be the next step?
<jlicht>hey guix!
<rekado>civodul: hmm, don’t we rely on the search path for builds as well?
<rekado>this would mean that the fix would not be a generic change to that feature but only to the profile builder.
<mbakke>civodul: (git-file-list ...) does the wrong thing for me in a git worktree. (string=? top directory) is #f, but I don't understand what the broken fallback is supposed to do.
<mbakke>Which causes (current-guix) to fail.
<civodul>rekado: correct
<thomassgn>um, I have a simple guile scriptfile that I run like a executable. I wanna package it, but I'm struggling. Does anyone know of packages that are simple guile (or maybe just a interpreted/script) file put as an executable in the store?
<civodul>mbakke: hadn't thought about worktrees, hmm
<rekado>thomassgn: we have a guile-build-system that might be of interest.
<civodul>janneke: the next step may be me catching up!
*civodul updates his copy of wip-bootstrap
<thomassgn>rekado: aye, I thought that needed autotools and so on, but I have to admit I didn't check. :]
<civodul>unfortunately guile-build-system only works for libraries, not for "scripts"
<civodul>you could use trivial-build-system, though it's a little tedious
<thomassgn>derp, the first sentence from the guile-build-system: "This build system is for Guile packages that consist exclusively of Scheme code and that are so lean that they don’t even have a makefile, let alone a ‘configure’ script."
<thomassgn>oh ok
<civodul>or, upstream, you could use Hall:
<g_bor>hello guix!
<g_bor>finally the time has came for me to put guix to good use :)
<civodul>mbakke: re worktrees, libgit2 has a "worktree" API but Guile-Git doesn't expose it yet
<g_bor>I have some questions however, some with more experience can surely answer me.
<civodul>mbakke: i suppose we'd have to use that...
<civodul>g_bor: sure!
<g_bor>I would like to use guix system vm-s.
<mbakke>civodul: Challenge accepted ;)
<g_bor>Should I use guix on the hypevisor, or is it possible to generate the vm on a guix machine, and just move it to a libvirt enabled host?
<janneke>civodul: \o/
<civodul>mbakke: :-)
<civodul>g_bor: perhaps you could generate a full image, with 'guix system vm-image'?
<g_bor>civodul: ok, sounds nice. Can I also get a configuration xml for the vm?
<g_bor>Also, I would like to use postgres on one of these vm-s, and once, at the first time I use the image would like to initialize the database and load the data. most probably with a script. Is there any way to do that?
<g_bor>Is there a better way?
<g_bor>civodul: I am also thinking about getting ovmf working in GuixSD. The main issue is that an ovmf vm needs a private copy of the ovmf, or at least the nvram area, as vm-s write to the bios image.
<g_bor>Is there any way to keep a per-vm writeable file:
<g_bor>(Actually vm-s work with a read only ovmf, but functionality is reduced)
<jlicht>would anyone happen to have a package for the alpha icecat release that they are willing to share?
<civodul>g_bor: i'm not familiar with OVMF etc. but i'm sure others here or on the ML would know
<g_bor>civodul: fine, thanks
*g_bor afk
*davexunit updates guix for the first time in months
<davexunit>new UI!
<davexunit>looks good!
<davexunit>very colorful
<snape>jlicht: no, we are pretty far from having it
***specing_ is now known as specing
<pkill9>jlicht: is that icecat on the firefox quantum engine?
<snape>pkill9: ^
<davexunit>yeah that's a tough one...
<davexunit>how do I make root user use the same exact guix version my regular user does?
<davexunit>this has been a constant annoyance for all the years I've used guix. I run 'guix pull' as my regular user, then decide I want to update the whole system shortly thereafter, so I run 'guix pull' as root and have to wait a long time for it to compile all over again.
<davexunit>I tried pointing it to the same commit but it's still building everything again
<davexunit>if there was a simple way to do a system update using my regular user's version of guix, that would be ideal.
<snape>davexunit: sudo -E guix pull
<snape>forget what I seaid
<snape>davexunit: I meant: sudo -E guix system reconfigure
<snape>it'll use your user updated guix
<pkill9>davexunit: you could symlink your user's ~/.config/guix to /root/.config/guix and make /root's folder readable
<pkill9>that's what i did for a while, until i wanted separate profiles
<davexunit>I want separate profiles, but I don't really get why I'm getting cache misses
<ecbrown>feel the power of all those cores working for good ;-)
<davexunit>if I use the same commit I shouldn't have to build twice
<davexunit>snape: sudo -E seems to be working, but I do recall this not working for me in the past.
<pkill9>o yeah i know what you mean
<davexunit>so I'm curious what is different now
<snape>davexunit: I use it for years
<pkill9>i would have thought it would work now that guix itself is substitutable
<snape>sudo -E is also very simple: no need to have Guix installed in ~root
<davexunit>snape: thanks
<davexunit>I always wished sudo -E would work like it appears to be doing now
<davexunit>I've definitely had some issues in the past but I've long since forgot the details
<ecbrown>i'm about to throw chairs over magit spinning
<janneke>am i right that to enjoy the new ui colours, you mustn't run guix build in an emacs shell or compilation buffer?
<janneke>ecbrown: "some times" the past month(s?) magit becomes terribly slow for me -- i don't have a clue why
<janneke>the only thing that helped a bit for a short while was to restart emacs
<lrochfort>Hi guys. First time Guix SD install underway. About to guix system int, but I need to provide an http_proxy. What's the best way to do that?
<snape>janneke: probably, but it's dangerous to build in an emacs shell because of long lines anyway
<ecbrown>janneke: yeah... i've returned to running several emacs processes due to the need to kill emacs....
<janneke>snape: on very rare occasions (eg when Mes keeps insisting on displaying the circular list) i don't use the emacs shell or compilation buffer -- usually works for me...
<janneke>ecbrown: you're probably not running emacs as a window manager :)
<janneke>lrochfort: guys&gals please! you must set http_proxy in the context of starting the guix-daemon
<lrochfort>janneke: I just saw that in the manual. So I stopped guix-daemon, then started it manually, specifying the http_proxy env var
<janneke>lrochfort: good luck!
<lrochfort>janneke: Thanks. I'm not sure if the proxy setting took affect.
<lrochfort>If I turn up the verbosity on guix system, I see path `/gnu/store/XXX' is required, but there is no substituter that can build it
<janneke>lrochfort: you did enable substitutes, and used guix archive --authorize?
<lrochfort>janneke: I don't believe so. I'm just walking through the official install guide
<lrochfort>I mounted my clean filesystem, created /mnt/etc/config.scm, and ran guix system init
<janneke>OK, if you boot from the install ISO, the substitute server should already be authorized
<Formbi>I get «guix-geiser-eval: Error in evaluating guile expression: <unnamed port>:17:23: In procedure module-lookup: Unbound variable: %max-returned-list-size» when trying to run emacs-guix
<ecbrown>is it http
<Formbi>what should I do?
<lrochfort>ecbrown: I set the environment variable like this: http_proxy=http://myproxy:port guix-daemon ...
<lrochfort>If I set https_proxy env var, guix states that it is explicitly ignored
<ecbrown>well, my thought is that the communication would be over https, so http_proxy might not do anything
<lrochfort>substitute: warning: 'https_proxy' is ignored
<ecbrown>Formbi: all i see is that you get some error. what are you trying to do? which version of emacs? what is M-x guix-version
<ecbrown>etc etc
<Formbi>GNU Guix 13512e1b8f63b4d8fcb188fac992aa390149fe65
<Formbi>Emacs-Guix 0.5
<Formbi>Emacs 26.1 (from guix) and 27.0.50 (from git)
<rekado>janneke: the colours are disabled when INSIDE_EMACS is set.
<ecbrown>what command do you type to get you to this unfortunate place?
<rekado>janneke: the idea is that people using a shell in Emacs would be using Emacs Guix (guix-build-log-minor-mode).
<janneke>rekado: oh! i need a new minor mode!
<rekado>that minor mode is great when using M-x shell.
<rekado>it highlights things and you can fold up the output for build phases, or jump between build phase start points.
<Formbi>ecbrown: guix, guix-all-packages and some other
<janneke>i guess i should (re?-)read the manual more often
*janneke needs to go afk for a bit
<ecbrown>Formbi: first thought is to `guix pull'
<ecbrown>though that's a recent SHA, i think
<Formbi>ecbrown: I did guix pull several times since that error appeared and it didn't help
<ecbrown>hmm, not sure. i'm a guix wannabe, so perhaps others could help, or perhaps report to emacs-guix' github tracker
<ecbrown>though it works for me, emacs 26.1 guix + spacemacs all up to date
<rekado>that hash is from today
<dustyweb>have to say
<dustyweb>I love the new guix pull
<dustyweb>it's so nice to have.
<dustyweb>now I can just run guix from my git checkout when I'm working on things
<dustyweb>but I have a nice way to stay up to date
<dustyweb>I enjoy it.
<rekado>I’m also very happy about it.
<rekado>It’s impressive how quickly “guix pull” made that turn thanks to civodul’s tireless efforts.
<civodul>it still needs to be made faster :-)
<rekado>first unloved, now a really cool and easy-to-use feature.
*civodul has preliminary code to integrate "inferior packages"
<tune>is "guix-daemon --build-users-group=guixbuild" supposed to take over an hour to finish, or should I ctrl-c out of it? context is trying to set up guix on debian
<nckx>tune: The daemon runs forever, listening for 'guix' client connections. It will never 'finish'.
<nckx>It is eternal.
<tune>ah, so it's just starting it. alright. I was following the instructions pretty literally. I thought maybe it was just slow to do something, so I opened another shell to start and enable it via systemd
<nckx>You can Ctrl-Z out of it, then 'bg' to run it in the background.
<nckx>Or run "guix-daemon --build-users-group=guixbuild &" if you've already killed it.
<nckx>Both do the same thing.
<davexunit>dustyweb: how does the new guix pull make running from a checkout easier?
<davexunit>rekado: re: tune's comments above. I've seen so many new users get stuck on that setup guide because they don't understand what a daemon does.
<davexunit>I think a note is needed that the process is *supposed* to never exit until you kill it.
<tune>to be fair, I am actually familiar with daemons, I was just kind of zoning out and copy/pasting stuff
<tune>sharing a server with a couple guys and one of them keeps removing vim and other programs he doesn't use, screwing over the rest of us. I suggested installin guix so we can have user-level package management, but I'd only used guix on guixsd previously
<tune>btw did that rust issue get fixed? I can't remember. checking before I waste time building
<tune>if I want to make an alias for building stuff more slowly, should both guix pull and guix package have # of cores to use specified?
<tune>'guix pull -c 2 && guix package -c 2 -m ~/manifest.scm' was thinking something like this for user packages, not sure where to fit in the -c 2 for a guix system reconfigure
<tune>I'd rather not do it via environment variable since I don't want it to always use less cores
<bavier>tune: you'd need to give the command-line option each time then, for both
<tune>yeah, I'm making a shell alias
<tune>just wondering how to format it
<dustyweb>davexunit: the new guix pull kind of is closer to running from a checkout, without running from a checkout, than the old guix pull was
<dustyweb>in that you get a reasonably up to date set of packages and etc
<dustyweb>but it also builds quickly
<dustyweb>which also means less headaches when I'm checking out from git
<dustyweb>because what I used to do was do "guix environment guix" before I'd hack on guix things
<dustyweb>but my guix was pointing at git guix
*janneke uses guix pull as a default, and ~/src/guix-stable/pre-inst-env guix ... and ~/src/guix-bootstrap/pre-inst-env ... for checkouts...
<dustyweb>so if I had changed branches
<dustyweb>then suddenly I was running "guix environment guix" from an un-make'd guix so I could make guix
<dustyweb>and sometimes that would go... goofily
<dustyweb>so I can still do that but with less headaches than before
<dustyweb>not sure I'm making sense!
<rekado>davexunit: yes, I wonder if the daemon should print something when it is executed in an interactive session.
<davexunit>dustyweb: I didn't quite understand but that's okay thanks for trying to explain
<joehillen>is it necessary (or even possible) to run `guix pull` against a local clone?
<nckx>joehillen: As in pulling from a file:// URL? Never tried that...
<dustyweb>davexunit: probably my fault
*bavier trying to upgrade the hdf5 package, currently addressing fallout
<nly>Git pull from /path/to/repo works
<nly>I don't know how the `guix pull` command works
<joehillen>nly: what is the exact command? How to do tell it where to pull from?
<nly>Idk the exact command, I'm not at my computer so I can't test it
<nly>joehillen: consider the manual
<nly>`guix pull --help`OR `info guix` or `man guix`
<nly>sry, I am a noob
<joehillen>looks, like this works: ./pre-inst-env guix pull --url=file:///home/joe/src/guix
<ngz>Hmm, once again I cannot remember... what am I supposed to do to silence the locale issue on a foreign distro? Apparently, installing glibc-locales in root does not produce the desired effect.
<ngz>At some point, IIRC, I modified the guix-daemon service, but I'm not sure anymore.
<pkill9>did you log out and back into root again?
<ngz>I read the manual. Multiple times.
<ngz>I just cannot figure it out.
<janneke>ngz: glibc-utf8-locales?
<ngz>Yes, glibc-utf8-locales
<janneke>i'm not sure when you need one or the other
<ngz>I have this in root's .bashrc: export GUIX_LOCPATH="/root/.guix-profile/lib/locale${GUIX_LOCPATH:+:}$GUIX_LOCPATH"
<janneke>ngz: and both locales packages?
<ngz>root have glibc-utf8-locales only
<ngz>user has glibc-locales
<janneke>i think i saw a need for glibc-locales in root too, lately -- i'm not sure; you can try, something may have changed
<janneke>sorry for not having accurate/complete information...
<janneke>i'm not using foreign distro's but collegues are and i think i saw something weird/new there, lately
<ngz>janneke: it looks like it fixed the issue
<ngz>Thank you.
<janneke>ngz: yw -- now to find out why and/or update the documentation...
<ngz>Not easy. It may well be me not understanding correctly what is written.
<lfam>Hm... on core-updates, I'm trying to build a new system generation. The info-dir-build crashes like this:
<kmicu>[Joke] Guix has 1 maintainer‽ it must be a busy person. ;)
<roptat>arg, what I want to package has a dependency on a non-free package :/
<roptat>buried somewhere in the dependency tree of a maven-build-system
<ngz>What is it?
<roptat>at some point I need spring-framework-context which depends on jsr354 (javax.monetary)
<roptat>that's the package they use
<roptat>the specification itself is not free, so I don't know if I can make another implementation
<rekado>it’s part of Java 9 AFAICS
<rekado>(or planned?)
<roptat>I have a recipe for java 9
<roptat>(and 10)
<roptat>but they don't work because of segfaults in gcc (I'm waiting for next core-updates since it's supposed to fix it)
<rekado>(I’m probably wrong)
<rekado>can the other package be patched to remove the dependency?
<rekado>roptat: could it be enough to add this: ?
<roptat>rekado: no, it wants to use*
<roptat>this package doesn't implement it
<rekado>that’s ridiculous.