<the_tubular>So I installed guix, I've hit a strange bugs, but it seems to be working ... <lfam>the_tubular: Sure, just say what's up <the_tubular>So basically when I installed it with the livecd I had no internet on my machine, I had to use another machine to complete the install <the_tubular>Now I tried I try it on my machine and I have internet, I'm confused as to why ...? <the_tubular>But it takes like 15 minutes to boot, and I can only boot in bios, cause it says there's no found partition in efi <the_tubular>I though the internet problem was due to hardware not being supported by linux-libre but now i'm really confused as to why it's working <lfam>If your network hardware isn't supported by linux-libre, and you're still actually using linux-libre... that's weird. Because even if you provide the firmware for your hardware, linux-libre won't let you use it <lfam>So, you can't somehow mix installations and have it work <lfam>linux-libre breaks loading of nonfree firmware <lfam>Regarding EFI, it sounds like maybe the partitioning isn't set up correctly? Did you make the vfat partition, put the correct UUID in config.scm, and use grub-efi-bootloader? <lfam>But, I'm not very experienced with EFI. I might not have understood your situation correctly <lfam>15 minutes to boot is somewhat extreme... Guix System boots at a similar speed to other distros before systemd came around. But 15 minutes is crazy, unless it's a really complicated system <lfam>I think it's normal for it to take 2 or 3 minutes <lfam>I'm curious, what hardware is it that isn't supposed to work? <the_tubular>I wasn't working during the install, when I boot with BIOS they work, but the system hangs for like 15 minutes at grub screen <lfam>Maybe they have a fallback mode where they work at a lower speed without firmware <lfam>Not sure... you might have to look at the relevant Linux source code <the_tubular>I mean if your are able to ping you should be good no ? <lfam>I suggested that as an explanation for why they are working with linux-libre, if they aren't expected to <the_tubular>I mean, if they work I'm all fine, I was just really confused about it <the_tubular>During the installer I choose to encrypt /, but /boot/efi should not be encrypted right ? <the_tubular>Can I boot using BIOS and be sure that I could boot using UEFI ? <lfam>If you are using linux-libre, `uname -a` will report a version like 5.12.16-gnu <lfam>The -gnu suffix is the key <lfam>I'm not sure, have to go afk for a bit <podiki[m]>you can encrypt boot with grub, but has to be set up a certain way (not sure in Guix) <podiki[m]>so generally no, you'd have boot unencrypted <the_tubular>Any idea on why does my bios refuses to boot in uefi ? <podiki[m]>(and that sounds like it could lead to your error the_tubular of not finding an EFI, if it is encrypted and not unlocked it will not be seen) <the_tubular>I doubt that's it, maybe I misspoken earlier, but during the installation I've used the auto-disk partition, the only thing i've changed was to change ext4 to btrfs on my root partition <podiki[m]>I wish I knew more, I know I've had similar issues setting up UEFI in the past (not on guix) <podiki[m]>but I remember making sure the right /boot /boot/efi etc. structure was important, easy to put efi files in the wrong spot <the_tubular>Apart from changing the root partition from ext4 to btrfs, I didn't touch anything else with the auto-disk partition <the_tubular>I doubt that the installer would give you something that wouldn't boot right ? <podiki[m]>sorry, hope someone with experience with the installer can help out. or try again without changing to btrfs to see if it works? maybe bug in installer or some grub/btrfs interaction? <podiki[m]>other things (thinking out loud): bios settings for things like boot mode, secure boot <the_tubular>I've checked and used multiple machines, also I used to boot of uefi before installing guix <the_tubular>So yeah, this is where I am, and I'm kind of lost ... <podiki[m]>hmm. and you can see the /boot/efi/EFI folders and .efi files? <the_tubular>Yes, let me double check. I'll boot the machine, it might take a while <dstolfa>lfam: i tried with a custom config, no dice. even tried without libre <dstolfa>something really weird is going on... <dstolfa>i'll put the laptop under load and within a minute it's on 100C on all cores <dstolfa>i've also tried opensuse now as well, behaves normal. i really don't know what's causing it <the_tubular>I tried it on a very very old machine, it seem to worked and then I kernel paniced :( <the_tubular>Still booting, I'm about to give up and just let it stay in BIOS ... <lfam>My old thinkpad x200 reports a CPU temp of 70C at idle, which does seem high <lfam>I wonder if there is a nice tool for comparing kernel configurations? There used to be kccmp but it depended on Qt 4 <lfam>There is 'scripts/diffconfig' in the kernel source code <dstolfa>lfam: yaeh i'm really unsure as to what's causing it. i thought it was just the laptop having issues with some workloads, but they are perfectly fine on any other distribution, including fully libre ones <lfam>Assuming it's really idle during these periods, it's probably something about how we build the kernel. It would be nice to find out <dstolfa>agreed. it'd also be nice to know why i'm not seeing any of this behavior on my desktop <lfam>Might also try one of the older Guix kernel versions <lfam>100C on a laptop is terrible <lfam>It would also be nice to find a diff tool that can display the info about each config option <dstolfa>lfam: agreed. i can look into it a bit more tomorrow, but i just settled on fedora on my laptop now, as i don't want to damage the hardware <dstolfa>i'll tinker with guix on my desktop until i have a reasonable config to try <lfam>Gotcha. I doubt it can be damaged, aside from wearing out the battery too soon. The firmware should protect itself <dstolfa>i hope it would, but i'd rather not risk running the laptop at 100C when i open a browser all the time :D <dstolfa>in any case, i'd be up to try things to see if it works. i'll get an external drive to test these things <lfam>I see in the 5.12 x86_64 config, CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y <lfam>That's probably not helping <lfam>On Debian, they use ONDEMAND <lfam>We should probably change it <dstolfa>drakonis: do you remember what you found fedora using? was it USERSPACE? <dstolfa>lfam: FWIW, if your thinkpad is idling at 70C, it's probably suffering from the same issue as my laptop, but thinkpads being thinkpads, it doesn't actively cook you with its thin base <lfam>It's usually comfortable except when it's fully loaded <lfam>Then, it's only nice in the winter <lfam>Fedora is using SCHEDUTIL <drakonis> CPU_FREQ_DEFAULT_GOV_PERFORMANCE y -> n <dstolfa>oh... the performance governor seems a little aggressive for laptops yeah <lfam>Fedora doesn't compress their mdules <drakonis>also relevant, they have a specific repository with their kernel tree <dstolfa>lfam: so, reading that link from kernel.org, it seems to me like schedutil is the best one for automated frequency scaling, whereas userspace gives users a lot of choice as to what they want to use and could help with things like tlp and thermald <lfam>Sure, and users can always change it, anyways. We just need to pick a sensible default <lfam>I wonder, ondemand vs schedutil? <dstolfa>to me the kernel.org thing reads like "schedutil is new, ondemand is the current standard" <lfam>Apparently schedutil was introduced in 4.7, which is indeed very recent <dstolfa>i wonder what the newest ubuntu does <lfam>It seems to be using PERFORMANCE? I don't see a Y in the diff <lfam>dstolfa: Are you able to test changing the governor? Or do you need assistance? <drakonis>lfam: if it does not show up, then it is the same as guix <dstolfa>lfam: i can test it, though not right now as it's very late here. i'll need to get myself an external drive to test with so that i don't have to keep reinstalling the laptop <drakonis>dstolfa: you could just shove the data into another folder <dstolfa>i'll look into it tomorrow. i need to get to bed, it's 2:30 AM :(. certainly worth looking into the CPU governor to see if that fixes the issue. <lfam>sneek: later tell dstolfa: You should be able to change the governor at runtime ***baconicsynergy_ is now known as baconicsynergy
<MysteriousSilver>Hello, 'Deprecating support for the Linux kernel' article mentions of some hurd VM image <jackhill>MysteriousSilver: also to be clear, while we're excited to be working with Hurd, linux-libre is not being deprecated, that was an April Fools joke. Not saying you were confused, but it was apparently a sucessful fool for some folks <drakonis>yeah i've seen some people think it was really deprecated <jackhill>yeah, I guess it doesn't help that hyperbola (I think) actually wanted to deprecate it. I guess the best jokes have a kernel (pun inteded!) of truth. <drakonis>they saw the title and thought it was for real <drakonis>instead of checking the date it was published <tissevert>today's a national celebration so I'm resting a bit : ) <paul_j>When guix needs to compile something, does it automatically use all the available cores, or do I need to configure this somewhere? <leoprikler>by default it uses as many cores as possible, but you can configure it to do less <leoprikler>also some packages are restricted in that sense, but they're usually outliers ***apteryx_ is now known as apteryx
<paul_j>leoprikler: Thanks. I don't need to configure it to use less, so I am happy with the default. <sneek>dstolfa, you have 1 message! <sneek>dstolfa, lfam says: You should be able to change the governor at runtime <dstolfa>sneek: later tell lfam: yeah, i tried doing that through `cpupower`, but it said only two governors were available -- performance and powersave. powersave wasn't exactly great either because it would downclock me to the minimum frequency, and i have to keep manually adjusting it. i wonder if our kernel configuration should simply compile all of them in as modules and let the user choose which governor they <dstolfa>want to use through something like `cpupower`, with the default being something like ONDEMAND or SCHEDUTIL which seems to be the popular choice amongst the "big" distros? <dstolfa>sneek: later tell lfam: want to use through something like `cpupower` with the default being something like ONDEMAND or SCHEDUTIL which seems to be the popular choice amongst the "big" distros? <paul_j>Cool - I never knew there was a message bot...! <sneek>From what I understand, Sneek is just picky… <mekeor>apparently sneek is an instance of bobot++ which is not packaged for guix :( <sneek>Welcome back mekeor, you have 1 message! <sneek>mekeor, mekeor says: something <mfg>Hi, leoprikler showed me the other day, how i can use cross-gcc in a manifest to get a cross compiler, i tried with th target riscv32-linux-gnu and got this error http://paste.debian.net/1204338/. What exactly does this mean and what can i do about it? <mfg>riscv64 does work though <mfg>or are those two different enough that it needs its own bootstrap? <mfg>okay nevermind it builds fine with riscv64 but it's not usable :D FeelsBadMan <roptat>would it be ok to push the results of "make download-po" as a single big commit? <roptat>I know we did for the release, but I'm not sure if we want to generalize that, in between releases <roptat>there's been some work since last release, so it'd be great to update the translations <roptat>"52 files changed, 191755 insertions(+), 165535 deletions(-)" <jlicht>roptat: finally got my AS-in-a-box to talk to my usb devices \o/ <roptat>vagrantc, yeah, but those are translations anyway, so I don't think a manual review is possible <jlicht>Android-Studio-on-Guix-System following your blog post :-) *bavier[m] working on onionshare upgrade <lfam>dstolfa: It sounds like you are using Intel P-States <sneek>lfam, dstolfa says: yeah, i tried doing that through `cpupower`, but it said only two governors were available -- performance and powersave. powersave wasn't exactly great either because it would downclock me to the minimum frequency, and i have to keep manually adjusting it. i wonder if our kernel configuration should simply compile all of them in as modules and let the user choose which governor they <sneek>lfam, dstolfa says: want to use through something like `cpupower` with the default being something like ONDEMAND or SCHEDUTIL which seems to be the popular choice amongst the "big" distros? <lfam>sneek: later tell dstolfa: You can check this in /sys/devices/system/cpu/cpu0/cpufreq <lfam>sneek: later tell dstolfa: I mean, you can check it in /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <lfam>Anyways, I sent a patch to change the default to schedutil for all kernel versions where it is available. *vagrantc cheers for schedutil <vagrantc>although i've only ever noticed it on arm64 :) <lfam>Barring complains, I'll push it along with the next set up of updates <dstolfa>lfam: awesome, thanks! i'll give it a test tomorrow <sneek>Welcome back dstolfa, you have 3 messages! <sneek>dstolfa, lfam says: You can check this in /sys/devices/system/cpu/cpu0/cpufreq <sneek>dstolfa, lfam says: I mean, you can check it in /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <lfam>Change it while running: <lfam>`for gov in /sys/devices/system/cpu/cpufreq/policy*; do echo powersave > "$gov"/scaling_governor; done` <dstolfa>lfam: hm, but can i change to something like SCHEDUTIL, or is that just not compiled (yet)? <dstolfa>cpupower allowed me to switch to powersave already, but not others <lfam>dstolfa: Check if you are using Intel P-States: <lfam>`cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver` <lfam>If you are using P-States, then you only have the choices of "performance" and "powersave", and they mean something different than without P-States <lfam>You probably want powersave, which works similar to non-p-states ondemand and schedutil <lfam>It's something native to the CPU <lfam>You can turn off P-States, I think <lfam>Anyways, I know you're busy <dstolfa>tail end of the phd and all that... i need 48 hour days :( <lfam>Oh wow, good luck! My friend did her defense on Monday <dstolfa>i certainly hope so! and i hope your friend's defense went well :) <lfam>Yes, and the party that followed immediately was great fun :) <dstolfa>glad to hear that, what field did she get her phd in if you don't mind me asking? <lfam>Comparative literature, specializing in Russian lit <dstolfa>oof, yeah that stuff is way over my head :D <lfam>At the phd level, I think other fields are always way out there :) <dstolfa>heh, true. but to be fair, this is way over my head even at the high school level, at least my high school teacher seemed to think so (and i tend to agree) <dstolfa>mine's much less exciting, i'm just doing computer science <lfam>I'm biased but I think that's cooler <dstolfa>well, i like it but i prefer the look of real libraries, rather than software libraries (though i only know how to make the latter) <dstolfa>the_tubular: mm, surely the same way as anything else? you'd have your file system specification in the system configuration <the_tubular>I can take a look. Sorry first time using 'full blown' Guix System, where is that system configuration file located, I just rebooted from the installer <Noisytoot>In what package are man pages for C library functions and system calls? <dstolfa>lfam: i've read a bit on how linux handles intel pstates, and i think you're correct to assume that the high temps are being caused by `performance` as default and that `powersave` would resolve all issues. i'll give it a test when i get some time. thanks :) <lfam>Cool dstolfa. I'm probably going to change the default in the kernel updates that will land today or tomorrow <dstolfa>Noisytoot: probably man-pages, i'd assume at least? <dstolfa>the_tubular: perhaps /etc/config.scm? *Noisytoot installs man-pages <lfam>There is also /run/current-system/provenance and /run/booted-system/provenance <lfam>(In case there's nothing in /etc) <the_tubular>I got it in /etc/config.scm I was looking for system.scm <the_tubular>I'm still a big noob on all thing guix / guile related ^^' <mothacehe>maximed: just pushed the meson series on core-updates :) <lfam>And yeah, config.scm seems to be the convention <the_tubular>I'll change it on my other system then. Get the same convention everywhere <dstolfa>the_tubular: well, there's a system.scm in the guix repository, but that's not necessarily the thing you want here <mfg>i remember seeing many patches in the mailing list trying to improve zfs on guix but i think they haven't been merged yet <dstolfa>lfam: i've reproduced it on fedora. it is indeed caused by the performance governor <roptat>do we have a package that provides "etags"? <mfg>well more guix on zfs :D <dstolfa>i generate etags with `find` and universal-ctags, using `ctags -E` <roptat>that provides ctags, but not etags <dstolfa>it can generate etags with a flag if that's all you need, but if you want `etags` the binary, i don't know :( <lfam>dstolfa: Thanks for checking <dstolfa>now i just need to check it on guix system :) <roptat>I don't really know what it is, but I have a package whose makefile complains about missing etags (no 'etags' in ... and five lines of $PATH...) for every target it runs <roptat>as well as missing /etc/os-release but I can't do anything about that *dstolfa wonders if guix should provide /etc/os-release... <dstolfa>it is a systemd thing, but a lot of things are starting to assume its existence <roptat>in the build environment? I don't see the point <roptat>it's used to disable building the doc on ubuntu... <dstolfa>ah. i've seen some vendor drivers (even fully free ones) that do something like grep ... /etc/os-release <dstolfa>but as for etags... i don't know then, sorry :( <dstolfa>it could be that we don't have a package for etags <roptat>it's fine, I substituted it to "true" since it was only a warning, it didn't make the makefile fail <roptat>arg, why are they hard-coding /bin/rm everywhere? <lfam>It's considered best practice to specify full paths in shell scripting, for some reason. When I was learning to write scripts like 10 years ago, that was the advice I got <lfam>As if something bad could happen if you invoked `rm` <lfam>Now I don't understand that advice <dstolfa>lfam: yep. and this is still something taught to newbies <lfam>Do you remember the reasoning dstolfa? :) <roptat>mh, interestingly, I find some places where they simply call "rm" <lfam>blackbeard: I suppose it's equal to `rm` <dstolfa>i think the idea is that if users have really weird environments, it would use the expected binary <lfam>I guess I haven't seen a case where it would matter <dstolfa>and it made sense with the convention of "things go in /bin /usr/bin /sbin" etc <dstolfa>but i don't think it's a reasonable thing to do anymore with all the containers and development environments <roptat>and they have no issue calling "find" or "git" without specifying a full path <dstolfa>90% of my dev time is spent setting flags to explicitly ignore the global thing <lfam>And even the "normal" distros don't agree on /bin, /usr/bin, etc <lfam>roptat: Well, you know, rm is really dangerous so you better give the full path <dstolfa>lfam: i've seen worse though, some of the *BSD shell scripting does #!/usr/local/bin/python <old>Does anyone know a channel for an Ethereum wallet? <bauermann>hi! is there anyone currently looking at the gcc-11 cross-build failures reported by the CI on the core-updates branch? if not, I'll poke at them and see if I can find something out <maximed>bauerman: Not that I'm aware of, though you may want to wait a little to allow others to respond <bauermann>maximed, ok, thanks! the error on the armhf build is either the same or similar to the one on the powerpc build, so these cross failures could have the same root cause. the hurd one looks different though <the_tubular>I'm having trouble formatting guile could someone help me ?