***nonzen is now known as Guest55562
<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>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? <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? <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>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>(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 <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>g_bor_: i believe this is the only one though i haven't been following as closely as i should <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? <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>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 <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. <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>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>that package uses pyqt, so I wonder if the Qt build might be tuned to the build host’s CPU. <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. *rekado builds Python 3.7 on core-updates <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? <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. <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." <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... <g_bor>I would like to use guix system vm-s. <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? <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>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 *davexunit updates guix for the first time in months <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? <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>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. <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>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 <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 <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 <Formbi>GNU Guix 13512e1b8f63b4d8fcb188fac992aa390149fe65 <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' <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 <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 <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'. <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. <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>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 *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>then suddenly I was running "guix environment guix" from an un-make'd guix so I could make guix <dustyweb>so I can still do that but with less headaches than before <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... *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` <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. <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" <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 <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. <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 <roptat>at some point I need spring-framework-context which depends on jsr354 (javax.monetary) <roptat>the specification itself is not free, so I don't know if I can make another implementation <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>can the other package be patched to remove the dependency? <roptat>rekado: no, it wants to use javax.money.* <roptat>this package doesn't implement it