<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
<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>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 <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` 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
<bavier`>I've seen the button disappear and reappear over time on different systems. maybe a user configuration on my side <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 <bavier`>I'm starting icecat in a fresh vm to see what the default experience is <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__>Just trying it out to use on a small server later <bavier`>doesn't hurt to share the error text; could you possibly copy-paste to a pastbin somewhere? <bandali>also, did you get that error after a successful install of the Guix System? <morrigan__>So far the only thing I've done is install `hello` <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__>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 ? <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>(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. <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>which corresponds to your commit if i'm not mistaken <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 <bavier`>morrigan__: oh, ok, let's lookup the git tag then... <roptat>bandali: the weird thing is for instance I successfuly built tmux from my commit, but ci didn't <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>compile time? not sure, besides roughly eyeballing it :p as for cpu model, lscpu <morrigan__>Should I report it? I'm not sure how helpful this error message will be. <roptat>Says 4 processors, intel core i7-6500U @ 2.50GHz <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 <roptat>Same with tor, I built it locally too <roptat>Not sure if this is really my fault then :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. <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`>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 <bandali>i should see if it works in a non-guix setting, or if it's universally broken <bandali>if anyone would like to help check that, that'd be great too <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 <bandali>debian, trisquel, and/or other distros would be great too *guix-vits tries to not pull the loossy USB cable... <bavier`>apparently there's a new version available <bavier`>9 days after mark's update in gnuzilla <bandali>bavier`, can you try the updated version and see if that works? <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" <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 <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 <bavier`>building things usually needs much more than if substitutes are available <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. <gfleury>bavier: d front end was add in gcc 9 upstream <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 ;] <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) <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 <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 <leoprikler>Is there a reason to have libraries in a profile? <nckx>kahiru: Install nss-certs. <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. <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>let's not add myself and have 4 people stuck ;-/ <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 <efraim>how far does power9 go before failing? powerpc (power4?) makes it as far as glibc-intermediate <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>or the examples section of the shepherd manual <efraim>shepherd --version -> 0.6.1, man shepherd shows 0.5.0 *efraim apparently still reports bugs in IRC and not the mailing list <civodul>efraim: 0.7.0 shows 0.6.1 in the man page? <efraim>i'm going to try to fix it first <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>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% <nckx>Anyone here familiar with Meson, and how it uses polkit magic? I would like to avoid learning about it. Very much. <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 <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. <roptat>Another target for reducing closure sizes is boost: it has 155MB of include files that are probably not needed at runtime <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>our llvm package is also enormous, because it includes cross-compilers for every arch <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>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>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 <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 <roptat>civodul: actually guile3.0-git built on ci for armhf, the log says build succeeded, but the status on ci is failed <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>so it broke between d39885a8a9e0e03c2bf6277d475d384168bba642 and 8b9cad01e9619f53dc5a65892ca6a09ca5de3447 <civodul>ah well, that's the kernel module autoload bug <vagrantc>every generation i build gets an older and older version of guix :) <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>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 *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â đş <vagrantc>the fsf's high priority projects are pretty much a wishlist and ... not all that much more? <vagrantc>maybe they are, but i suspect it's a longer list than funds are available for... <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 <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__>Scratch building in a VM also seems to have worked. <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. <nckx>morrigan__: You mean a customised installer live system? <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. <bandali>speaking of jami an sip, does anyone know how to configure a linphone sip account in jami? <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. <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? <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 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 <apteryx>kmicu: There are still some issues with the build in Guix, last time I tried (couldn't search contact by username). <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 <janneke>just learned about this bsp thing; man... <janneke>i saw that tla before but just ignored it as noise <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>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? <ATuin>an old generation (kernel 5.4.18) works fine <NieDzejkob>ATuin: sounds familiar, I'd grep the IRC logs for the past few days <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 <ATuin>i'm wondering if i have messed guile libraries or something <NieDzejkob>ATuin: it's a leftover from the guile 2->3 migration <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 <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 <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>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? <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? <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. <NieDzejkob>mfg: post a minimal example script and the command you're using to run it. It seems to work on my side <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... <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. <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? :) <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>would specifing all the kernel modules that I know I will need in the initrd-modules, will my laptop boot a little faster? <jackhill>lfam: florian just posted a patch, so I assume they have narrowed it down :) <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. <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 <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>(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 :) <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. *janneke trying florians patch now <lfam>I couldn't apply Florian's patch, janneke and jackhill <nckx>nun: Move one ) from %base-file-systems)))â to (type "ext4"))â <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 <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 đ <ATuin>talking about boot speed, me coming from slackware ... I think that guix boot fast :) <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? <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 :) <ATuin>maybe wrong word, english is not my main language <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 <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 <nckx>ATuin: Does it run Guix? <ATuin>i run guix at work (on top of slackware) <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>It even works on the same disk (often useful on VPSes and the like). <nckx>me@debian $ guix system init /etc/not-anymore.scm / <nckx>Which is both a promo and a warning. <nckx>drakonis: Your Debian won't feew so gud after booting Guix, no. <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 <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. <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 used to load modules! <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? *nckx did not mean to sound like a zombie film. <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) <lfam>Yeah, it works for me janneke! <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 <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>"docker-shepherd-service" inside that file <nckx>I'm only talking about docker-shepherd-service in gnu/services/docker.scm. <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 <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@? <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 <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>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? <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? <nckx>Dunno if the original naming was to keep it opaque but IMO it's a bit too much. <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`>I guess ./pre-install-env is what I would run next.... <lfam>`make check` includes `make` <lfam>And you shouldn't run `make install` <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 <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. <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 <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>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>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 :/ <nckx>PotentialUser-28: What does the command âip routeâ return? <nckx>You can just repeat the previous âguix system initâ command now (up arrow). <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.