IRC channel logs

2020-02-20.log

back to list of logs

<terpri>"OS Type: Linux" "Origin: USA" 🤔
<tsmish>Answering questions from bug#39671 mail: /run/current-system/profile/bin/modprobe exists, I also don't see any errors in dmesg and /var/log/messages.
***daviid` is now known as daviid
***nikita is now known as Guest87463
<roptat>USA because GNU I guess
<OriansJ>roptat: here I was thinking FSF
<smithras>bdju: If we want more distrowatch attention we should do another minor release sometime soon
<bdju>smithras: That's a good idea as well. IIRC the last review was not the best, hopefully the issues from before are fixed now.
<OriansJ>personally, I think guix could benefit from a monthly release process
<OriansJ>along with a very public way for people to reproduce the bootstrap binaries using only a trivial build script and reproduce the ISOs using a guix script
<smithras>OriansJ: I think the ISOs can already be reproduced using `guix system dist-image`, it's just not advertised
<smithras>*disk-image
<smithras>bdju: yeah I agree that more frequent, regular releases would work well with our dev process
<OriansJ>smithras: now that there is guix time-machine; yes it is possible to reproduce the disk images but the commit used and the exact build file
<OriansJ>are needed to be more publicly known (or more quickly discovered)
<lfam>Using the recursive version-aware Rust crate importer from the mailing list, I have a working package for rav1e
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, janneke says: i reverted my kernel to 5.4.18 but that didn't fix it; my last OK reconfigure was ~10 days ago, but sadly uses master from 30 dec
<smithras>OriansJ: I agree. It would be nice if we always used the tagged release commits to build the ISOs, because then you could always use '--branch=v1.0.0' for example to verify then in guix time-machine
<lfam>Of course... it comes with 8000 lines of Rust packages
<lfam>Yikes
<OriansJ>smithras: of course all of this ultimately become a non-issue when mes-m2 is finally done; as then there is only a single 357byte binary in the bootstrap chain (or add a second 737byte shell if you want to do an init bootstrap)
***jonsger1 is now known as jonsger
<bavier`>anyone here use the "onion browser button" in our icecat and notice that when enabled you aren't actually connected to tor?
<raghavgururajan>bavier` Currently the Tor Button does not work in IceCat.
<raghavgururajan>bavier` I saw a conversation in #icecat where bandali mentioned that they are working on it.
<bavier`>raghavgururajan: mhm, thanks, good to know
<bavier`>I wonder if it might be good to disable it temporarily until a fix is ready
<bandali>that's a good idea. anyone know if/how one could ship an extension disabled?
<bavier`>bandali: I think there is a way to simply prevent a bundled add-ons from being installed, but I don't really have the time to look at the moment
***uix-vitsg is now known as guix-vits
<raghavgururajan>bavier` I didn't have to disable it. It never showed up. :P
<bavier`>raghavgururajan: oh
<raghavgururajan>It is installed but never appears on the tool bar.
<bavier`>I've seen the button disappear and reappear over time on different systems. maybe a user configuration on my side
<raghavgururajan>I see.
<bandali>hmm
<morrigan__>hello, I just downloaded the virtual image and tried `guix pull`, it says I "found a bug" and should report it, but I'm not sure if it's a bug or just something I did wrong
<bandali>i'll look around, but feel free to ping me here in or in #icecat if anyone knows anything
<morrigan__>ah, sorry to interrupt
<bandali>no worries! i was done anyway :-)
<bandali>also, hello :p
<morrigan__>hello! nice to meet you
<bavier`>bandali: thanks
<bandali>bavier`, cheers, and thank you
<bavier`>I'm starting icecat in a fresh vm to see what the default experience is
<bandali>+1
<bandali>morrigan__, nice to meet you too :-)
<bandali>so what setting is this? is it on a foreign distro?
<bandali>or, are you installing guix system perhaps?
<bandali>oh, based on what you said, the latter i'm guessing?
<morrigan__>I'm using the qemu image on debian uhh... I wanna say buster?
<morrigan__>I think I'm on buster
<morrigan__>Just trying it out to use on a small server later
<bandali>aha
<bavier`>doesn't hurt to share the error text; could you possibly copy-paste to a pastbin somewhere?
<bandali>^
<morrigan__>I'll go ahead and do that
<bandali>also, did you get that error after a successful install of the Guix System?
<bandali>(while doing guix pull)
<morrigan__>I just downloaded the prebuilt image
<morrigan__>So far the only thing I've done is install `hello`
<bandali>ha
<bavier`>that's what it's for :)
<Croiskae>hi
<Croiskae>hi
<Croiskae>hi
<bandali>hmm, i won't know for sure until we see the context around the error, but it *may* be because of missing glibc-locales
<morrigan__>I have realized the most expedient way to get the text out of the VM and into ghostbin is just to copy by hand so this will be about 2 minutes
<morrigan__> https://pastebin.com/HKjRCrQj
<morrigan__>That was harder than it had any right to be
<morrigan__>I could try building my own image, see if it makes any difference
<bandali>roptat, your latest commit seems to have broken quite a few things :p including icecat, it seems ?
<roptat>Ouch :/
<morrigan__>oh no lol
<bandali>morrigan__, hmm, that's weird :-/ i hadn't seen that one before ?
<bandali>also, not implying that the error you got is because of roptat's commit
<bandali>that was totally unrelated :p
<bandali>(though, not to be ruled out, i guess)
<morrigan__>This was my second attempt. The first one said "updating substitutes" a lot and then ended in an error out. I'll pastebin that too.
<bandali>please do
<bavier`>morrigan__: does your `guix describe` have a commit hash?
<bavier`>I was able to pull the commit your paste mentioned, but it's possible pulling from your version somehow doesn't work
<roptat>bandali: do you have a list of broken packages?
<bavier`>roptat: `guix refresh -l icecat`? :)
<bandali>roptat, besides icecat, not off top of my head, but i was looking at https://ci.guix.gnu.org/eval/11016
<bandali>which corresponds to your commit if i'm not mistaken
<roptat>Ok
<morrigan__> https://pastebin.com/zr9PExSg
<roptat>I didn't see icecat was on the list of packages to be rebuilt
<morrigan__>bavier`: how do I query for the commit hash? I'm very new to Guix
<bandali>morrigan__, try running `guix describe' as mentioned
<morrigan__>Oh sorry I read guix-describe
<morrigan__>Thought it was a separate program
<bandali>:-)
<morrigan__>It does not
<morrigan__>`error: failed to determine origin`
<bavier`>morrigan__: oh, ok, let's lookup the git tag then...
<morrigan__>I am not sure how to do that
<roptat>bandali: the weird thing is for instance I successfuly built tmux from my commit, but ci didn't
<roptat>I'm rebuilding icecat locally
<bavier`>morrigan__: no worries, I should have know, we put the first few chars of the hash in the guix version string: 'host version: "1.0.1-1.8204295"'
<bandali>roptat, hmm, yeah i'm not sure what's going on. ci seems to have shit the bed indeed. icecat's build was log from the ci seemed cut off too, so not sure
<bandali>roptat, btw, on what kind of machine do you build icecat and how long does it usually take?
<morrigan__>bavier`: Oh I see. Yes, that's the tag I've got.
<roptat>bandali: on x86_64, not sure, maybe an hour?
<roptat>Same with transmission for instance, built here but not on ci
<bandali>roptat, ha. and how long for libreoffice? if you don't know that one, could you tell me your cpu specs instead?
<bandali>and yeah that's *weird*..
<roptat>How do I find out?
<bandali>compile time? not sure, besides roughly eyeballing it :p as for cpu model, lscpu
<roptat>No, cpu spec
<morrigan__>Should I report it? I'm not sure how helpful this error message will be.
<bandali>lscpu
<roptat>Says 4 processors, intel core i7-6500U @ 2.50GHz
<bandali>gotcha, ty
<bavier`>morrigan__: a message to bug-guix@gnu.org would be fine. The message even says "please" :)
<bavier`>outline the steps you took to get there, if possible
<morrigan__>Will do
<bavier`>thanks!
<roptat>Same with tor, I built it locally too
<roptat>And the log is cut
<bandali>*_*
<roptat>Not sure if this is really my fault then :p
<bandali>:p
<roptat>Built knot locally too, anl log is cut on ci
<bandali>gonna try pulling and building (icecat) locally
<roptat>Feel free to revert if that doesn't work for you, I'm going to bed soon
<bandali>sure, thanks for checking, and sorry for my metaphorical finger-pointing :-)
<vagrantc>janneke: yay! got pinebook pro booting with your patches and a slight modification
<morrigan__>I sent the email. I'll maybe try building my own image and seeing how that goes.
<morrigan__>bavier`: thanks for helping
<bavier`>morrigan__: np, thank you for the report
<bavier`>bandali: in a fresh vm, our icecat starts with the onion browser button extension enabled
<bandali>bavier`, right. and its icon is visible in the top right area e.g. near librejs's icon?
<bavier`>bandali: yes
<bandali>right
<bavier`>and even when tor is not installed it says it connects successfully
<bavier`>an uncareful user might not check the connection and assume everything is fine
<guix-vits> https://2019.www.torproject.org/docs/torbutton/
<guix-vits> https://blog.torproject.org/toggle-or-not-toggle-end-torbutton
<guix-vits>it's abandoned since 2011...
<bavier`>guix-vits: different project
<bavier`> http://mybrowseraddon.com/tor-button.html
<bandali>i agree, it's pretty bad
<bandali>looking at the logs, mark updated the extension back in november: https://git.savannah.gnu.org/cgit/gnuzilla.git/log/data/extensions/tortm-browser-button@jeremybenthum?h=68
<bandali>i should see if it works in a non-guix setting, or if it's universally broken
<bavier`>that'd be a good next ste
<bandali>if anyone would like to help check that, that'd be great too
<bavier`>*step
<guix-vits>bavier`: Your link: "Attention required!". Tor-button behind the captcha... :)
<bandali>yeah. if it's universally broken i think i'll push a commit to either disable it (if i can figure out how) or remove it
<guix-vits>I'll check this on my F-droid's IceCat...
<bandali>thanks
<bandali>debian, trisquel, and/or other distros would be great too
*guix-vits tries to not pull the loossy USB cable...
<bavier`>a couple reviews at https://addons.mozilla.org/en-US/firefox/addon/tortm-browser-button/reviews/ say "not working"
<bandali>i see
<bavier`>apparently there's a new version available
<bavier`>9 days after mark's update in gnuzilla
<bandali>oh, right
<bandali>i was looking at https://github.com/jeremy-jr-benthum/tor-button
<bandali>bavier`, can you try the updated version and see if that works?
<bavier`>sure, I'll try
<bandali>thank you
<bavier`>the 0.1.8 version seems to be no better afaict
***uix-vitsg is now known as guix-vits
<bavier`>again, in a vm with no tor running, it says "TOR is running. Connected to 127.0.0.1:9050"
<bavier`>and "check tor connection" fails
<guix-vits>i'm seen something like "addon can't be verified", and reinstalled IceCat (F-Droid). No torbutton at all.
<bavier`>but this was on Guix System; I think verification on other OS's would be good
<bandali>okay, thanks for the reports
<guix-vits>Maybe the security politics of engine which IceCat uses isn't allow the addon button to do much? I'm just sure, that if one set the proxy in Settings, it will even not load any page without working tor.
<morrigan__>My vm build seems to be going alright. I've got to head out now, so I'll just let it go. I will report it if I find another bug
<bandali>guix-vits, yeah, but the add-on shouldn't give false positives anyway
<bandali>hmm, latest version seems to work fine on debian
<bandali>actually, this seems to have do with something in icecat
<bandali>the extension doesn't report a false positive on debian's firefox-esr
<bandali>but it does on an icecat i'd built on debian, as seems to be the case with guix's icecat
<morrigan__>I'm back, it's giving me a nondescript build error. It also says the error may have been caused by a lack of free disk space
<morrigan__>How much space does guix usually need?
<bavier`>building things usually needs much more than if substitutes are available
<morrigan__>Yeah I suppose
<morrigan__>I didn't get an option to pull substitutes
<morrigan__>I resized the virtual machine to 50G, I'll run it overnight and see how it goes
<gfleury>hello guix? someone with a powerful machine could packaging d language in gcc 9
<bavier`>gfleury: I'll add it to the wishlist. In the meantime, we have and "ldc" package, if that might work for you.
<bavier`>gfleury: is this what you had in mind? https://gdcproject.org/
<gfleury>bavier: yes
<gfleury>bavier: d front end was add in gcc 9 upstream
<bavier`>I see, ok
<bavier`>gfleury: added to https://libreplanet.org/wiki/Group:Guix/Wishlist#Programming_languages
<gfleury>bavier: Thanks!
<Demosthenex>what's a recommended virtualization layer for guix that can run windoze 10?
<bavier`>Demosthenex: that would be off-topic for this channel
<Demosthenex>bavier`: i'm evaluating a move to guix from gentoo, and i'm looking for virtualization solutions... i have a mix of vm types, so i ask about the difficult one ;]
<bavier`>good luck :)
<Demosthenex>and if you scratch out mentions of windoze (i don't care for it either), i'm poking around in the packages list and trying to find a virtualization solution. clearly virtualbox isn't fully OSS, so the question remains what is recommended for virtualization on guix?
<bavier`>I use libvirt (through virt-manager)
<bandali>we also have qemu
<bavier`>I think I heard someone was working on packaging gnome-boxes
<bandali>see the (gnu packages virtualization) module
<Demosthenex>so i thought libvirt was a frontend, not itself a virt tech
<bavier`>kvm I suppose
<Demosthenex>ah, so it requires a backing tech
<alextee[m]>is there some conflict between gtk+ and mesa?
<alextee[m]>i did a guix pull and upgrade and it tells me profile contains conflicting entries for mesa and to upgrade both mesa and gtk+ or remove one of them
<alextee[m]>i guess i can remove mesa if gtk pulls it in
<leoprikler>Is there a reason to have libraries in a profile?
<alextee[m]>yeah for building stuff
<alextee[m]>i don't like using environments
<leoprikler>Fair enough
<kahiru>hi, any ideas how to get past this https://p.teknik.io/fmpVF ?
<civodul>Hello Guix!
<janneke>hello civodul!
<nckx>kahiru: Install nss-certs.
<kahiru>nckx: I have them installed
<kahiru>(note, guix on fedora, not guix-sd)
<guix-vits>I'm at the first few pages of SICP. The idea that the code is for humans to read, and only to be ocassionally run by machines, is hitting. Sometimes, it's all almost looks like a "pictures". Despite the fact of my ignorance about the `2>&1 |`, until it was presented to me yesterday.
<nckx>kahiru: Then I don't know ☹ ‘guix import gem clamp’ actually works for me on a fedora machine with 0 Guix packages installed (not even bootstrapped, in fact) and no SSL-lookin' vars in ‘env’.
<nckx>guix-vits: When you get tired of typing ‘2>&1 |’ you can use ‘|&’. But the former is much clearer.
<raingloom>i think gdm is broken again. i'll make a proper bug report later.
<nckx>kahiru: Even ‘env -i guix import …’ works. This is /usr/bin/guix, though, and has never been pulled. Maybe that matters. I don't understand how it could, but here we are.
<kahiru>nckx: https://p.teknik.io/AxALd no luck
<janneke>nckx: do you know what the status is with power9, iwbn te play with that some time
<nckx>janneke: 3 people are working on it, 3 people are stuck, AFAIK 😛
<janneke>nckx: ok, thanks!
<nckx>Including me ☹
<janneke>let's not add myself and have 4 people stuck ;-/
<janneke>yeah, i figured
<nckx>Well, you'd be the bootstrap expert.
<janneke>good; we'd get bootstrapping project stuck :-)
*kmicu [jokin’] |& ‽ Get of my bashismfree lawn!
<nckx>oh no it's old man posix
*kmicu quotes Bash’s man page ‘BUGS It's too big and too slow.’
<nckx>old man posix has scared guix-vits away.
<nckx>‘There are some subtle differences between bash and traditional versions of sh’ is even better.
<kmicu>“There are some subtle differences between Guix and traditional package managers”—ancient proverb
<janneke>there are also subtle differences?
<janneke>;)
<efraim>how far does power9 go before failing? powerpc (power4?) makes it as far as glibc-intermediate
<bricewge>Hello Guix!
<bricewge>I would like a probably, forgotten patch, 2 years old patch from wigust to be (re)evaluated https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00290.html
<bricewge>It's a patch on how to setup emacs to auto-update the copyright notice.
<bricewge>Should I send it to guix-patches or ask the author to resubmit it?
<efraim>we haven't switched gdb on core-updates to 9.1
<efraim>bricewge: if it seems helpful and you'd like it to be reconsidered then go ahead
<efraim>is there a way to have shepherd read the files in ~/.config/shepherd/init.d/ ?
<civodul>bricewge, wigust: it LGTM; i think you can push it, wigust!
<civodul>efraim: not directly, but you can load whathever you want from your config file
<efraim>I could impliment (implement? spelling is hard) a "read that directory and load the .scm files" function
<efraim>for the cookbook!
<efraim>or the examples section of the shepherd manual
<efraim>shepherd bug!
<efraim>shepherd --version -> 0.6.1, man shepherd shows 0.5.0
<efraim>i'll check 0.7.0
<efraim>0.7.0 shows 0.6.1
<bricewge>civodul: Nice!
*efraim apparently still reports bugs in IRC and not the mailing list
<raghavgururajan>Hello Guix!
<bricewge>Hello raghavgururajan!
<civodul>efraim: 0.7.0 shows 0.6.1 in the man page?
<efraim>civodul: yep
<efraim>man shepherd | head
<civodul>oops
<civodul>can you file a bug?
<civodul>or a fix actually? :-)
<civodul>sounds like a makefile issue
<efraim>i'm going to try to fix it first
<efraim>man herd shows 0.6.0 :)
<efraim>halt and reboot show 0.3.2
<civodul>nooo
<civodul>you mean the man pages?
<civodul>ah yes
<civodul>"$(guix build shepherd)/sbin/halt --version" shows 0.7.0
<roptat>efraim: for user services? It would be useful for the home manager!
<efraim>civodul: you did the last release for shepherd? can you check the man files in the doc folder on your computer?
<nckx> https://paste.debian.net/plain/1131255 errrr
<nckx>No mention of pkexec or setuid anywhere in the source, of course.
<bricewge>nckx: I did *not* rebuild all the dependents.
<nckx>Didn't have a week to spare, eh? Fine by me. I looked at the release notes, they *should* be trivial.
<bricewge>Is it mandatory? `./pre-inst-env guix build $(guix refresh -l bluez)` ?
<nckx>I guess not. I do it just to be on the safe side.
<bricewge>BTW it looks like it should go on staging.
<nckx>I wrote the first sentence before running the command myself, ‘whoa that's a lot’, then wrote the 2nd. Should have removed it then.
<jackhill>for what it's worth, I wish I had done that with the go upgrade, but didn't think about it until after the problems cropped up…
<bricewge>Ok, will do then. It'll probably take a looong time on my machine.
<jackhill>bricewge, nckx: If it's going to be applied to staging though, then the build farm will pick it up, so may not be as important compared to commits directly to master?
*jackhill is looking forwared to continued guix-data-service patch review work :)
<nckx>bricewge: No, don't bother if it's a bother. As jackhill notes, it's more important on master. As I noted, I should've deleted that bit 😉
<nckx>bricewge: I suggested c-u because it rebuilds two chromiums and Qt stuff (but no webkits, that's something) but it could go on staging if you want. It's expensive, not disruptive.
<roptat>bandali: in the end the packages that-seemed to have failed are available as substitutes now
<bandali>roptat, hah, weird! btw i let icecat build off of your commit last night, and it built successfully; sorry again
<bandali>i wonder what is happening with ci then
<roptat>So I managed to reduce the system closure size by 100MB :), which is spmething like 7%
<bricewge>nckx: Cool! This release contains mostly fixes https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/ChangeLog
<nckx>Anyone here familiar with Meson, and how it uses polkit magic? I would like to avoid learning about it. Very much.
<bandali>kudos roptat
<nckx>roptat: Wow. Rad.
<nckx>bricewge: Yeah, I'd read that in the meantime, should be safe right…
<roptat>That's because libevent used a different pytgon from the rest of the system, moving the reference to another output hides it from the system, so we remove a python3 package from the closure
<roptat>I still have another one used by certbot
<bricewge>How should I go on rebuilding all the dependencies if I need to do so someday? The command I posted previously doesn't work.
<civodul>efraim: yeah they were not rebuilt; like i wrote, it's a makefile issue
<efraim>civodul: I was wondering if they were just sitting there in the folder
<efraim>I just sent off a patch to add them to the 'make clean' target
<janneke>roptat: very nice
<jackhill>bricewge: it's because of the caption printed before the list of packages, I used `guix build $(guix refresh -l <name> | sed -e 's/.*://')` with success
<civodul>efraim: it should be removed upon "make distclean", not "make clean"
<civodul>however there's a missing dependency: "halt.8" should depend on "halt", etc.
<bricewge>janneke: Thank you :)
<roptat>Another target for reducing closure sizes is boost: it has 155MB of include files that are probably not needed at runtime
<roptat>Compare to 15MB of libraries :)
<civodul>155MB of headers? how do people write this much code?
<roptat>The issue is that dependents use cmake, which installs a cmake file with a reference to the includes…
<civodul>uh
<civodul>our llvm package is also enormous, because it includes cross-compilers for every arch
<civodul>we should fix that
<roptat>I also looked at it, mesa and clang
<roptat>But they are difficult to split, because it's not supported upstream
<roptat>I might have had a patch for llvm, but I don't remember where it is
<efraim>do we want to move static libraries to a "static" output in general?
<roptat>Oh, I see it in core-updates
<roptat>I don't remember the figures for that one
<roptat>I think it had the effect of removing python from the closure
<efraim>for example, subversion is 18 MB, lib/*.a is 5.4 MB
<roptat>Yes, it oas python, so 80MB out of the closure
<civodul>efraim: so far we've usually removed static libraries
<civodul>i.e., --disable-static
<civodul>we should do that for subversion i guess
<efraim>sounds good, might want to look at clang also then
<efraim>find /gnu/store/ -name '*.a' -size +1M -exec du -h {} \;
<efraim>static libraries of at least 1MB in size
<joshuaBP`>morning guix.
<roptat>civodul: ci is consistently failing huix-modular-master on armhf and àrch64. It seems to be due to guile3.0-git, but I successfully pulled on my armhf system yesterday. The build log says it failed after 1 hour of silence, so maybe you could restart the evaluation?
<efraim>i'm building subversion without static libs now, will test after
<civodul>yay
<roptat>civodul: actually guile3.0-git built on ci for armhf, the log says build succeeded, but the status on ci is failed
<NieDzejkob>Hmm. On one hand, DRY. On the other hand, it takes more cleverness to avoid repetition. (thinking about https://debbugs.gnu.org/db/39/39633.html - opinions?)
<civodul>i have an installation test that completes
<civodul>but then, when booting GRUB, it enters the passphrase, and GRUB barfs
<civodul>"file '/boot/grub/i386-pc/normal.mod' not found"
<civodul>does that ring a bell?
<civodul>boo our test in that area has been failing for some time: http://ci.guix.gnu.org/search?query=encrypted-root-os
<civodul>last success: https://ci.guix.gnu.org/build/2272424/details
<civodul>first failure: https://ci.guix.gnu.org/build/2272938/details
<civodul>so it broke between d39885a8a9e0e03c2bf6277d475d384168bba642 and 8b9cad01e9619f53dc5a65892ca6a09ca5de3447
<civodul>the shepherd upgrade, again!
<civodul>ah well, that's the kernel module autoload bug
*vagrantc is finally figuring out why you don't want to use guix from the packaged guix due to https://issues.guix.gnu.org/issue/39352
<vagrantc>every generation i build gets an older and older version of guix :)
<civodul>exactly :-)
<janneke>boot-stripping!
<vagrantc>so with janneke's patches, i've got guix system on a pinebook pro ... going to use to test it on other pinebook models to see if the regular linux-libre, bootloader, etc. works on those too
<vagrantc>same OS image, different generations for different models :)
<janneke>vagrantc: woohoo!
<janneke>i was hoping to create a sd card image; to put up on the pinebook wiki
<vagrantc>the hard part is getting multiple incompatible bootloaders on the same image... but there was a talk at fosdem 2019 about doing that ... might toy with that a bit
<vagrantc> https://fosdem.org/2019/schedule/event/one_image_to_rule_them_all/
*janneke adds to watch list
*raghavgururajan just realized that there is no working SIP client available in guix.
<nckx>raghavgururajan: I thought Jami supported SIP but 🤷
<raghavgururajan>nckx Yes, it does. We have twinkle and jami. Twinkle is not under development since 2009. And jami, buggy, but in active development (upstream).
<nckx>Yah, I was just looking at Twinkle. Shame.
<raghavgururajan>But it is listed as one of the FSF's High Priority Projects. Not sure how.
<kmicu>Is Jami in a working condition? There’s a long theard on ML about ‘hepl with Jami something something’ 😺
<raghavgururajan>Best bet is on Linphone and Ekiga.
<vagrantc>the fsf's high priority projects are pretty much a wishlist and ... not all that much more?
<raghavgururajan>kmicu Not in working condition yet. :/
<raghavgururajan>vagrantc Oh is it? I thought funds were prioritised for those.
<vagrantc>maybe they are, but i suspect it's a longer list than funds are available for...
<raghavgururajan>That's true too.
<raghavgururajan>Any body intrested in packaging Linphone and/or Ekiga?
<roptat>I think I have a linphone definition in guix-more, not sure what's the state of it since I haven't touched that repo for a year or two
<roptat>There was a roadblock somewhere though, which is why I didn't contribute it to guix
<roptat>I can.t remember what it was
<raghavgururajan>roptat Nice. Let me send out an email in dev list, to see if anyone is intrested. And your base might be very useful.
<morrigan__>My problem last night was just that I needed to resize the image
<morrigan__>Adding 5G made it go fine.
<morrigan__>The update, that is
<morrigan__>Scratch building in a VM also seems to have worked.
<roptat>raghavgururajan: https://framagit.org/tyreunom/guix-more/blob/master/more/packages/messaging.scm
<morrigan__>Oh, since I'm here: If I would like to install using a config file I wrote myself, is there a page that explains how to do that? The manuals have been very helpful so far.
<raghavgururajan>roptat Thanks!
<nckx>morrigan__: You mean a customised installer live system?
<drakonis1> https://git.savannah.gnu.org/cgit/guix.git/tree//gnu/store/zzbxvr0f2bkh65702jh91q4sv7gyy30l-guix-module-union/share/guile/site/3.0/gnu/packages/statistics.scm#n4353
<drakonis1>hrm
<drakonis1>this is some weirdness
<roptat>Your link is broken
<morrigan__>nckx: No I just meant if there's a guide for using the shell install process. I should have tried running it before asking because there absolutely is lol.
<morrigan__>I have to give Guix a lot of credit for putting the effort into the documentation/guides
<nckx>morrigan__: Thank you! 🙂 The command-line install process is fully documented from beginning to end. Just don't skim the text.
<morrigan__>Of course
<bandali>speaking of jami an sip, does anyone know how to configure a linphone sip account in jami?
<bandali>raghavgururajan, ^
<morrigan__>I do intend to eventually build my own live image just for DevOps reasons, but that doesn't seem terribly difficult
<raghavgururajan>bandali Yes. There should be a button to toggle to SIP. Then it will ask for SIP address.
<nckx>morrigan__: Not at all. And also in the manual.
<raghavgururajan>server: linphone.org ; username: foo ; password: bar
<bandali>raghavgururajan, i was able to add the account just fine, but it showed me a red exclamation point icon, and seems to require further configuration?
<morrigan__>nckx: Wonderful
<raghavgururajan>bandali Kinda similar to setting up XMPP
<raghavgururajan>bandali Ah I see. Just a sec.
<bandali>sure, ty
<nckx>Which reminds me… g_bor[m]: Have you published anything on your automated installer?
<raghavgururajan>bandali Hmm. How did you start jami from terminal? Suddenly neither jami nor jami-cient-gnome does not work.
<bandali>raghavgururajan, ah i'm not currently using it in guix, but i have it installed on a debian machine and on an android phone. i was looking for instructions/documentations on configuring a linphone sip account in desktop or mobile jami clients
<raghavgururajan>bandali I see. I just wanted to see the config screen so that I could remember what I did. Could you send me a screen shot please?
<bandali>raghavgururajan, sure, i'll /msg you in a bit
<raghavgururajan>bandali Cool!
<raghavgururajan>bandali Shoot! forgot to mention that peer to peer IRC messaging doesn't work on my end. I am using Gajim and connected via XMPP to this channel.
<bandali>raghavgururajan, no worries, i'll link them
<raghavgururajan>bandali I am getting you messages. You are not receiving my replies correct?
<bandali>raghavgururajan, i seem to be getting them
<raghavgururajan>Cool!
<bandali>:-)
<apteryx>kmicu: There are still some issues with the build in Guix, last time I tried (couldn't search contact by username).
<kmicu>Thank you apteryx
<thomassgn>Hi guix!
<thomassgn>anyone know why I can't get mysql/mariadb running? I've got this config: http://dpaste.com/2VM83H8 As it is I get errors on the mysql-config part. If I just write (mysql-service) I can build this config but it throws me a rescue shell on boot... Removing mysql service altogether gives me no errors - and no sql service :)
<thomassgn>'Invalid keyword: #<<mysql-configuration> mysql: "MARIADB" port: "3306" extra-content: "">'
<mbakke>thomassgn: try removing the (mysql "MARIADB") line -- mariadb is the default and it should refer to a package variable, not a string
<nckx>thomassgn: mysql-service → mysql-service #:config and port should probably not be a string (although I didn't try).
<nckx>Oh, it's also just the default. thomassgn: You just want my configuration, which is (mysql-service), full stop 😛
<thomassgn>nckx: aye, they're the default, but with only (mysql-service) I get a guile (shepherd?) rescue shell on booting the VM...
<nckx>thomassgn: That's weird because it's what I use on all my ‘production’ machines.
<thomassgn>hahahaha, darn. It was a broken pipe. I added '-m 1024' to the qemu command, and it worked... Sorry. :)
<bavier1>anyone here use Guix's mumble client with success?
<dongcarl>Hi all, running on a foreign distro here... I can't seem to find `~root/.guix-profile/lib/systemd/system/guix-publish.service`, as I want to start guix publish as a systemd service
<dongcarl>Do I need to `guix install guix` for root?
<janneke>vagrantc: watching this talk now, pretty nice arm introduction for me too
<vagrantc>janneke: cool
<janneke>just learned about this bsp thing; man...
<janneke>i saw that tla before but just ignored it as noise
<raghavgururajan>janneke Which talk?
<dongcarl>raghavgururajan: https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/
<raghavgururajan>dongcarl Thanks
<dongcarl>Might be my stupidity but arm boards have historically been much harder to get working than x86 ones
<dongcarl>some of them even require vendor blobs and ayunfan's custom kernel for BIG.little
<ATuin>hi
<ATuin>I need some help with guix, when running "guix system reconfigure" (updating to kernel 5.4.20) the new kernel is not able to load any kernel (same behaviour in 2 different machines). Has any one experience this problem?
<raghavgururajan>dongcarl IIRC, ARM® Cortex®-A9 NXP i.MX6 doesn't require blobs.
<ATuin>an old generation (kernel 5.4.18) works fine
<raghavgururajan>doncarl It's GPU driver is Etnaviv, which I think is free software.
<NieDzejkob>ATuin: sounds familiar, I'd grep the IRC logs for the past few days
<NieDzejkob>(logs.guix.gnu.org)
<ATuin>ahh nice
<ATuin>thanks, i thought it was something specific to my machine but i happened in another machine running guix :)
<dongcarl>raghavgururajan: Yes, wumpus reverse engineered everything and made it all work :-)
<ATuin>i also get this " In procedure load-thunk-from-memory: incompatible bytecode kind" when running reconfigure, dunno if related
<raghavgururajan>dongcarl Nice! Great work. :-)
<ATuin>i'm wondering if i have messed guile libraries or something
<jackhill>ATuin: I believe your kernel module issue is https://issues.guix.gnu.org/issue/39671
<NieDzejkob>ATuin: it's a leftover from the guile 2->3 migration
<raghavgururajan>jackhill Mine too, I guess.
<jackhill>raghavgururajan: I suppose so.
<jackhill>I haven't actually tested it on more than one machine to see if its just a sometimes problem or if it happens more reliably
<ATuin>NieDzejkob: the error is a leftover right?
<ATuin>should i be worried or just ignore it?
<ATuin>jackhill: taking a look at it
<jackhill>it appears to be the shepherd upgrade, but it's not clear how (it it was, we could fix it :))
<NieDzejkob>ATuin: it's just a warning because guile is trying to load a 2.2 library before finding the 3.0 library
<lfam>Is the shepherd upgrade working for anybody?
<ATuin>jackhill: that's exactly my problem, yes. In the other machine i can just load the kernel modules in the initramfs but this machine hangs because thermald not finding the hardware
<janneke>lfam: we need an anti-bug list! ;-)
<lfam>Ha
<ATuin>NieDzejkob: ahh, good to know. I was imagin something similar. I'm confused with which part is using guile-next exactly since when inspecting the code of packages in emacs it points me to 2.2
<lfam>jackhill: I'm curious, have we narrowed down the use cases of people with problems yet? Are we all using custom kernels? Or maybe working from Git with ./pre-inst-env?
<ATuin>yeah, comparing both generations (the one working and the one failing) the big changes seems to be the sheperd upgrade
<joshuaBPMan>Hey ATuin:
<sneek>joshuaBPMan, you have 3 messages.
<sneek>joshuaBPMan, guix-vits says: x=`mktemp`, `sudo guix system reconfigure -n /etc/lightweight-desktop.scm &> ${x}`, then `grep openvpn ${x}`. It should highlight location.
<sneek>joshuaBPMan, guix-vits says: or `grep 'drv$'`, then grep ... khm :)
<sneek>joshuaBPMan, guix-vits says: better do as roptat: no file, `... 2>&1 | grep ...`
<joshuaBPMan>sudo guix time-machine --commit=d39885a8a9e0e03c2bf6277d475d384168bba642 -- system reconfigure /home/joshua/prog/guile/guix-config/sway.scm
<joshuaBPMan>that's how I'm reconfiguring now.
<joshuaBPMan>that commit works for me.
<ATuin>ohhh nice command!
<joshuaBPMan>I know right? Someone here told me gave me that suggestion. That's how I've been reconfiguring. I suppose you could modify your initramfs, which would be a cool thing to learn about, but that is another solution.
<joshuaBPMan>also, I do have a question...let me know if this question doesn't belong in guix.
<ATuin>well the problem is that there is a list of modules loaded lazily ... the initramfs worked for the ethernet and the gpu (since i thought at the beginning that was the problem)
<ATuin>but i doubt i can load everything needed there
<mfg>Hi, so i'm trying to read command-line arguments with guile. i currently try: (open-input-file (cadr (command-line))), because i want the first argument. this doesn't work because it isn't a string... how do i make this a astrng in guile?
<joshuaBPMan>I'm a little concerned, because guix does not provide the cpu-microcode updates from intel, which alledgedly leave my computer vulnerable to spector stuff. What are the security ramifications of not using the cpu microcode updates?
<NieDzejkob>mfg: what do you mean by "isn't a string"?
<joshuaBPMan>ATuin: Why not? can't you load any module in the initramfs?
<ATuin>anyway is it expected to have the guile guix modules under "share/guile/site/2.2"?
<mfg>NieDzejkob: 'Error in procedure open-file: Wrong Type (expecting string): (my_argument)'
<mfg>do i need to put the argument in parantheses?
<mfg>errr i mean ''
<ATuin>joshuaBPMan: yes, but i need to know all of them in advance i guess. The system i did that works but with no sound and with problems when showing some characters
<ATuin>so, it's just safer i think to boot the generation that works without problems
<joshuaBPMan>ahhh. gotcha. lspci -v should show you some idea of the modules that you will need.
<joshuaBPMan>also lsmod
<NieDzejkob>mfg: post a minimal example script and the command you're using to run it. It seems to work on my side
<NieDzejkob>(paste.debian.org or some other paste site)
<joshuaBPMan>but you have to run that on a generation where all your modules are loaded properly.
<ATuin>yeah ... i have it here, 148 lines of modules with the deps and so on (netfilter and what more ...) :)
<lfam>joshuaBPMan: It's basically the same as not patching against any security vulnerabilities. Eventually you might suffer some negative consequence
<lfam>It would be a good thing for someone to implement outside of Guix...
<mfg>NieDzejkob: this: https://pastebin.com/QB67ddnb.
<joshuaBPMan>lfam: let me ask it another way, I currently store my bank account information on a peice of paper. I DO NOT store it on my computer.
<joshuaBPMan>information = username and password.
<joshuaBPMan>am I being tooo cautious?
<lfam>Honestly, if it is a personal account in the USA I wouldn't worry about it. The way that banks handle fraud for personal accounts is very good for customers. If it's a business account then you need to take security seriously
<ATuin>hh is it not easy to use an old computer instead for that? :)
<joshuaBPMan>lfam: ok thanks.
<joshuaBPMan>I'll think about your suggestion.
<mfg>NieDzejkob: forgot my command: https://pastebin.com/1JQA6QVS
<lfam>I'm not saying you *should* keep your password on the computer. I'm just saying that if somebody steals from your account, the bank will make you whole, if it is a personal account. If it's a business account you will be screwed and should have insurance
<lfam>It's not really something you can meaningfully impact one way or the other
<lfam>Your account is constantly under attack. The banks use machine learning heuristics to decide which charges are legit. People are constantly trying to steal your money and the bank will not tell you about it unless they are actually unsure
<joshuaBPMan>lfam: ok. That's good to know.
<joshuaBPMan>would specifing all the kernel modules that I know I will need in the initrd-modules, will my laptop boot a little faster?
<ATuin>i don't see how ...
<jackhill>lfam: florian just posted a patch, so I assume they have narrowed it down :)
<nckx>joshuaBPMan: Nope.
<joshuaBPMan>nckx: bummer.
<nckx>joshuaBPMan: See ‘lscpu’ for how your (libre) kernel takes care of these known CPU vulnerabilities already.
<joshuaBPMan>I guess I've heard that a custom kernel would help you boot faster.
<joshuaBPMan>nckx: Oh thanks.
<NieDzejkob>mfg: You said cadr, but your code contains cdr
<joshuaBPMan>nckx: thanks fro the tip... That's super cool.
<nckx>joshuaBPMan: Sure, it does (mine shaves a few seconds). But specifying a few known modules does not a custom kernel make. You win much more by disabling whole features, most of which are not modular to begin with.
<nckx>Happy to have been of service o7
<joshuaBPMan>nckx: Why do you roll a custom kernel?
<joshuaBPMan>Is it just for the sheer fun of it?
<joshuaBPMan>and may I ask which features you disable?
<nckx>Don't focus too much on kernel boot times, Guix boots a lot slower than other distributions and none of that has to do with the kernel. Plenty of lower-hanging fruit before you get to that point.
<mfg>NieDzejkob: (command-line) only consists of two elements so this should be the same. I found out that i have to (apply string-append (cdr (command-line))) to make it work. Makes sense to me but seems awkward to me :D.
<bavier1>mfg: no, not the same
<bavier1>(cdr (command-line)) is a list, while (cadr (command-line)) is a string
<bavier1>your apply effectively flattens the list
<mfg>Ah ok, thank you bavier1 :)
<bavier1>mfg: np, good luck
<nckx>joshuaBPMan: Mainly for fun, and because I'm a control freak, and because I do use a few kernel features that [I] haven't Guixed yet (e.g. pstore), and because it's the best way to learn, and after that a very good way to stay abreast of kernel news, and because I've used the same (ever-updating) kernel for the past ~20 years which is a nifty feeling, and because I apply all kinds of zany patches (-pf, bcache, tuxonice, previously Wireguard), but ‘fun’ covers it.
<nckx>Guix makes it a lot more fun, too. I can keep different commented/abstracted kernel configurations around without losing my way or mind.
<nun>Hi, I'm currently trying to install guix for the first time on my Thinkpad T420s, but I'm having issues with the configuration file. https://paste.debian.net/1131302/ this is my config so far, and https://paste.debian.net/1131303/ this is the error I get
*janneke trying florians patch now
<lfam>I couldn't apply Florian's patch, janneke and jackhill
<lfam>I'm trying it "by hand"
<nckx>nun: Move one ) from %base-file-systems)))← to (type "ext4"))←
<janneke>lfam: yeah, (c) line does not apply
<lfam>Huh, it didn't work for me even when I commented that hunk out
<nckx>nun: You're basically calling append on a single but nested list instead of on 2 flat ones. Which won't work.
<nun>oh… thank you very much :)
<janneke>git am --show-current-patch | patch -p1
<janneke>worked for me
<nckx>nun: You should then also align %base-file-systems with the (list but hopefully you're using a sane editor that does it for you 🙂
*lfam mystified
<nckx>It'll work either way.
<ATuin>talking about boot speed, me coming from slackware ... I think that guix boot fast :)
<joshuaBP`>ATuin: hahah.
<nckx>I was wondering whether a recent package update was too new/unstable to push. Then saw that Slackware shipped it. In it went.
<nckx>ATuin: I assume Slackware still uses BSD init, right?
<ATuin>yep
<nckx>Cool. It was my first distro and I will always love it.
<ATuin>i still use it at work place
<nun>nckx, I'll fix that when I have my system up and running, with a proper editor installed :p
<ATuin>i'm really attached to it but i'm migrating to guix slowly
<ATuin>nckx: yes, the stability and being very conservative is what i love most of slackware, easy to fix and predict problems
<drakonis>its so conservative it added a linux feature from 20 years ago last week!
<ATuin>on the other side ... keeping it in order is very manual
<nckx>drakonis: Which one? 😮
<ATuin>drakonis: you can also use -current if you feel brave :)
<drakonis>PAM
<drakonis>brave?
<ATuin>maybe wrong word, english is not my main language
<nckx>OMG PAM.
<nckx>Wow.
<ATuin>well PAM was not there on purpose
<drakonis>i'm not sure if running current makes me brave, its like joining the rest of the world
<ATuin>drakonis: yes, it was a joke, seems that bad. Sorry
<drakonis>no problem
<ATuin>what i meant is that -current is pretty actual
<drakonis>slackware still offers kernels without smp
<drakonis>there hasnt been hardware without smp in at least 16 years
<drakonis>its like a time machine
<nckx>ATuin: Does it run Guix?
<drakonis>now that's a good question
<ATuin>i run guix at work (on top of slackware)
<nckx>Excellent.
<ATuin>actually i was using before the sbo packages until i discovered guix
<ATuin>now i manage everything not included in the system with guix
<ATuin>well ... still learning guix so i'm doing the transition. Anyway i will try one day to install guix in another disk using "system init". That should be possible right?
<nckx>Yep.
<nckx>It even works on the same disk (often useful on VPSes and the like).
<nckx>me@debian $ guix system init /etc/not-anymore.scm /
<drakonis>does it hose the existing install?
<nckx>Which is both a promo and a warning.
<ATuin>mmm interesting ...
<nckx>drakonis: Your Debian won't feew so gud after booting Guix, no.
<drakonis>clearly not
<ATuin>that's why i got another disk, i want an alternative i feel confortable with just in case
<drakonis>sounds like an alien parasite lives inside the debian
<nckx>Guix will work fine and (in my experience) ignore any old distro files but of course you'll never have that squeaky clean feeling. Which is why I don't use it. But it worked once, in an emergency, and I was thankful.
<drakonis>i'd prefer to move everything to another dir before that
<nckx>drakonis: People informally call it ‘borg-ing’ your system.
<ATuin>can this be possible: "guix init /etc/system.scm /guix-root"
<ATuin>and let the initramfs to pivot root there
<ATuin>?
<drakonis>fun.
<drakonis>i figure it might have some issues with prebuilt packages due to the store location?
<nckx>ATuin: If you add code to support that to the initramfs.
<ATuin>home could be share since i use LVM
<ATuin>that looks like a nice experiment actually
<ATuin>well i need to understand guix initramfs, what i looked into it i liked it.
<ATuin>very clean
<nckx>A nice way to say that it doesn't do much, but indeed, it's a relief coming from busybox sh.
<ATuin>well it does what it needs i guess
<nckx>It loads modules!
<nckx>Oh wait.
<nckx>It used to load modules!
<ATuin>hehe
<nckx>lfam: By the way, AFAIK you were the first to imply that this issue doesn't affect everyone. Did I get that right?
***Noctambulist is now known as Sleep_Walker
<ATuin>anyway debuging initramfs is not a nice experience so something simple is a good thing
<lfam>nckx: I was asking if it affected everybody
<lfam>I feel like it must not or the commits would not have been pushed
<nckx>Ah, OK, your ‘have we narrowed down’ implied the same to me. Thought maybe you were one of the unaffected.
<ATuin>ahh i forgot, one more question. The other day i extended the docker service to be able use a daemon.json file but seems that the docker.scm does not export the docker-configuration and son (just the service-type if i remember properly). Why is that? What are the benefits of it?
<lfam>I am affected
*nckx did not mean to sound like a zombie film.
<ATuin>*and so on
<nckx>ATuin: #:export (docker-configuration
<nckx>So I'm not sure what you mean.
*nckx doesn't use Docker tho' so bows out.
<ATuin>mmmm weird i did not see that export when i did it so i ended up wrapping the whole thing :)
<ATuin>ahh sorry my bad, not configuration. The "docker-sheperd-service"
<ATuin>since that was the one i needed to change (the #:start keyword)
<janneke>lfam: looking good!
<lfam>Yeah, it works for me janneke!
<janneke>yes, for me too!
<nckx>ATuin: It's just not customary to export those. IMO the service-type interface should expose all ‘interesting’ parameters. What did you need to change?
<ATuin>the "start" field in the service, to change the binary called
<nckx>Right, but to what?
<ATuin>to read daemon.json as config file
<ATuin>so it also generates a config file in the store
<nckx>And that requires a different binary? I'm confused.
<ATuin>no, talking about the service, not the binary
<ATuin>maybe i was not clear ... i replaced the shepherd service starting docker
<nckx>We're obviously miscommunicating here, but I don't even know how 😛 So you didn't need to replace ‘/bin/dockerd’ with ‘/bin/foo’, right?
<ATuin>exactly, not that
<ATuin>"gnu/services/docker.scm"
<ATuin>"docker-shepherd-service" inside that file
<nckx>I'm only talking about docker-shepherd-service in gnu/services/docker.scm.
<ATuin>ahh ok, now i understand
<nckx>Proof: you typed the same thing while I was pasting that because I forgot to look up :-/
<ATuin>no, not the docker binary. This line "(start #~(make-forkexec-constructor ..."
<nckx>But that's what I mean 😛
<nckx>‘/bin/docker’ *is* the binary.
<nckx>Did you mean add an argument?
<ATuin>yes but i did not replace that, just the arguments
<nckx>OK.
<ATuin>exactly, it was a very small change but ir required a very convoluted solution :)
<ATuin>i'm pretty sure that what i did is not idiomatic at all :D
<nckx>No, but you had no other choice. Let's just add an extra-arguments field to the service. The guix-daemon does this.
<nckx>* guix-daemon-service, to be clear.
<nckx>* guix-service-type, grr, sorry, that's what I get for working from memz.
<ATuin>ahh yes, not bad idea. That could replaced in the config, so the only thing needed is the code that creates the file in the store
<nckx>(guix-configuration (extra-options (list "--max-jobs=6" "--cores=6")))
<nckx>is what we want here, right?
<ATuin>nckx: it took me a while to get teh concepts of service-type, service and so on :)
<ATuin>yep, i can show you the code i did
<nckx>ATuin: How'd you feel about going one better and showing everyone by sending it to guix-patches@?
<ATuin> https://pastebin.com/E5uRsfDL
<nckx>Maybe after adding such a field if you're up to it.
<ATuin>sure, but i don't think the code is really good
<ATuin>it was my first experience with a service
<ATuin>but i can modify it to get an extenstion field in the config
<ATuin>that looks easy to do
<nckx>Then it's not bad at all. But ideally none of this would be needed, that is true.
<nckx>Adding a field will make a much less impressive patch but is the right fix.
<ATuin>agreed!
<ATuin>i will try to implement this weekend then. I think i read enough about that service to know how it works
<pkill9>does anyone have a link to the npm recursive importer that was apparently working?
<joshuaBP`>hmmm, "make check" failed channels.scm
<NieDzejkob>Should packages using hg-fetch or svn-fetch be using (file-name (git-file-name ...))? Maybe the procedure should have a more generic name?
<civodul>pkill9: i found this: https://lists.gnu.org/archive/html/guix-devel/2016-08/msg01567.html
<nckx>NieDzejkob: Uh-huh.
<civodul>pkill9: and then: https://github.com/jellelicht/guix/tree/gsoc-final
<nckx>Dunno if the original naming was to keep it opaque but IMO it's a bit too much.
<NieDzejkob>hmm, how about checkout-file-name?
<lfam>version-control-checkout-file-name
<lfam>You can also do (file-name (string-append name "-" version "-checkout))
<nckx>But that's the hard problem that git-file-name was engineered to solve.
<lfam>Yes, for the version control system that is the most popular
<lfam>We also have git-version
<joshuaBP`>question for you all...I am trying to build guix from a git repo...
<joshuaBP`>the info documentation just say run bootstrap; configure --localstatedir=/var;
<joshuaBP`>then make check;
<joshuaBP`>I guess ./pre-install-env is what I would run next....
<joshuaBP`>when do I run make?
<joshuaBP`>and make install?
<lfam>`make check` includes `make`
<lfam>And you shouldn't run `make install`
<joshuaBP`>lfam, oh I did not know that.
<lfam>I don't know what the current recommendation is for manual installation but `make install` has always been not recommened
<joshuaBP`>lfam. Gotcha. I should just run sudo -E ./pre-install-env guix system reconfigure config.scm
<lfam>Yeah, something like that
<joshuaBP`>ok thanks.
<lfam>joshuaBP`: The manual page Binary Installation explains how to create the binary installation package yourself
<lfam>If you wanted to go that route
<PotentialUser-28>hey, i am trying to install guix and am having problems with building openssl, cant find anything on the internet about that. is there anybody here who may help?
<lfam>PotentialUser-28: What's up
<joshuaBP`>lfam: I'm wanting to test some changes to guix. I'm essentially wanting to test the patch for the linux modules not loading.
<joshuaBP`>and try to tweak the vpn-client-service.
<lfam>joshuaBP`: I would use ./pre-inst-env for that
<joshuaBP`>lfam: ok. So I'll just try sudo -E ./pre-inst-env guix system reconfigure config.scm
<lfam>Yeah
<PotentialUser-28>ifam: it just says "build of '/gnu/store/somerandomnumbers-openssl-1.0.2p.drv' failed" and before that a list of derivations that failed because of one dependency
<lfam>PotentialUser-28: What command did you run
<lfam>Also my name starts with an L, not an I
<PotentialUser-28>lfam: i'm sorry. i ran "guix system init /mnt/etc/config.scm /mnt" as it was written in the manual
<lfam>No need to be sorry, just wanted to let you know I wouldn't be notified of your messages unless my name was spelled right
<lfam>PotentialUser-28: Okay, it should have told you about a log file of the failing build. Can you look in that file and tell us what the error was?
<PotentialUser-28>lfam: i see its an archive, so should i unarchive it to open or something? im kind of a noob
<lfam>What text editor do you usually use?
<lfam>Vim should be able to just open it
<nckx>PotentialUser-28: Or ‘bzless <file.bz2>’ or ‘zless <file.gz>’ based on the extension. ‘q’ will exit that.
<lfam>nckx: Do you know if they should be getting substitutes out of the box?
<PotentialUser-28>lfam: vim gives me a command not found (i used nano to edit the config). ill try your second suggestion
*nckx just popped back in lfam, will read backlog.
<lfam>nckx: They are init-ing a new system and openssl failed to build...
<lfam>I feel like they shouldn't need to build anything
<nckx>We would know for sure if they pasted the exact somerandomnumbers. PotentialUser-28: Are you using the Guix installer image from the Web site, or some other message?
<nckx>*method
<nckx>I think the installer should definitely download substitutes, openssl is definitely part of the ‘pinned’ 1.0.1 system.
<PotentialUser-28>nckx: ah, i see i have no network connection :/ that must be the problem. i used the image from the website
<nckx>PotentialUser-28: Oh, sorry, the installer requires network access.
<nckx>All the goodness of a netinstall image in the handy size of a full-blown desktop installer 🙂
<nckx>That's why your openssl .drv is failing, it needs to download a binary (substitute) or the source.
<nckx>Is there any way you could connect to the Internet?
<nckx>Temporary cable?
<nckx>I installed my first Guix system kneeling in front of the modem cupboard; no shame.
<PotentialUser-28>nckx: i actually have plugged in the network cable from the start; ifconfig and all goes fine but ping doesnt :/
<PotentialUser-28>oh wait!!! network connection works now O_O
<nckx>PotentialUser-28: What does the command ‘ip route’ return?
<nckx>Oh!
<nckx>Yay.
<nckx>‘Happy to help.’
<nckx>You can just repeat the previous ‘guix system init’ command now (up arrow).
<PotentialUser-28>thanks a lot! i think the installation started now.
<nckx>I hope your connection's stable now.
<PotentialUser-28>nckx: i think it has installed!! but i logged into i3 and it seems i didnt install a terminal :( how do i edit config to include a terminal now?
<lfam>PotentialUser-28: Change to another TTY with CTRL+ALT+F2
<nckx>PotentialUser-28: Sorry about that, this was fixed in June last year but hasn't made it into a release yet.