<ng0>dieggsy: you can disregard the bootstrapping issue in the email for now. mrustc is getting there eventually <ng0>I had circular dependency building issues <ng0>I started at the very bottom, in 2016 <dieggsy>ng0: wasn't even thinking of it. i haven't even called guix package -i or build, it just fails on guix package -A ripgrep (even just finding it) <dieggsy>I think it's trying to read my crates.scm custom module <dieggsy>well, no syntax errors or the like i suppose <ng0>well throw it into a module and use that <dieggsy>ng0: i think it can't read the module <ng0>I meant: in a guix_package_path exported one, not the package -A filename.scm <dieggsy>ng0: my crates.scm is in GUIX_PACKAGE_PATH <ng0>also I remember having issues with some type of crate.. the one that creates executables? I don't know <dieggsy>ng0: it's a more base issue. i think guix/guile is having trouble registering the module at all. when i delete it, everything goes back to normal. when i add it, it hangs. there's no syntax errors or anything, it just hangs. is it possible to have a module that's too large? <dieggsy>ng0: heh, welp. no idea why it's doing this then <ng0>remember how long perl and pyton used to be <ng0>I could detangle it and add the 0 dependency crates if they aren't already in master <ng0>I also sit on the rust emacs mode, etc <dieggsy>ng0: would circular dependencies cause the issue i'm seeing? <dieggsy>ng0: with circular deps could you even attempt installing a crate <ng0>I haven touched rust in a long time <ng0>well you will even succeed. <dieggsy>i'm not asking about rust, i'm asking purely no the guix package definitio side <dieggsy>like, i can't even begin to see anything build or _do anything_ with guix with this crate file in my GUIX_PACKAGE_PATH <ng0>usually we add bootstrap versions <rekado>dieggsy: yes, circular dependencies can have that effect. <ng0>some examples are in the ghc / haskell module <dieggsy>ng0: do they actually fix these in any way, or <ng0>rust was more of a mindfuck. I don't know if danny 's working on it or someone else, but we could ask upstream how they handle this., <dieggsy>ng0: on the other hand, i could just create a package for the precompiled ripgrep binaries, lol <dieggsy>would be nice to figure out this cargo thing tho <ng0>the rust branch I have is a mess.. I think it can just be a reference. it's bad to get started with so many dependencies <ng0>then walk up, 1 dependency <ng0>until you hit problems <dieggsy>ng0: how do you mean? only crates with 0 dependencies, then crates with 1? <dieggsy>huh. well. that's gonna be annoying to filter out <ng0>we have nothing on rust iirc <dieggsy>ng0: gl.scm has a package definition in a (delay.. to supposedly solve circular dependencies <ng0>so the very basic crates will most likely have 0 or 1 dependency <ng0>the circle in rust is like this: <ng0>A depends on B. B depends on C for the testsuite. the testsuite of C depends on D for some part. D depends on A. ... to make it very short and inaccurate <ng0>I tried to solve it back then but I figured I need to back down and start smaller <ng0>my description wasn't accurate <ng0>but you'll notice it when you look at the dependency drawings of the branch I have <ng0>for some reason they love circles <ng0>ic, the cargo.lock issue is solve too <dieggsy>oh, nvm, delay/force won't help, they made a delayed package without some features so as to break the circular dependency <ng0>that's how it usually works <dieggsy>hmm, i probably don't actually need _all_ of these just to build tho <platoxia>I have GuixSD installed on hardware and was wondering about upgradability between releases...is it currently upgradable between beta releases or does it need to be reinstalled each time and/or once a stable version is released? <davexunit>platoxia: I've had a guixsd system for at least 3 years now and I've never re-installed from scratch after the initial installation <platoxia>Thanks. I'm just a basic user interested more in the fact that this is certified by the FSF and is GNU oriented...I don't even know scheme. Hopefully I will get the hang of the way this system works sooner rather than later. <davexunit>platoxia: have you ever installed parabola or arch before? if you can get through that installation process, you can handle guixsd's <davexunit>if you've only ever used distros with graphical installers, there will be a greater learning curve <davexunit>(until the day we, too, have a fancy pants graphical installer ;) <platoxia>I did Gentoo from stage one many, many years ago as well as doing a LFS build...also many, many years ago. I've never done Arch or Parabola though. I'm very much out of practice on the sys-admin realm though. <rekado>platoxia: in that case you might find GuixSD refreshing. <rekado>platoxia: it avoids the usually “edit this file, then that other file, then restart this thing” drudgery. <rekado>instead it offers a much cleaner, unified configuration. <Apteryx>is it me, or is guix reconfigure system taking *much* longer than it used to recently? <davexunit>platoxia: okay, well given that you've installed gentoo before (something I've never done), I would bet that you can get guixsd installed, too. <rekado>you’d have to learn a bit of Scheme, though. Making yourself familiar with the basics for an hour will go a long way. <davexunit>Apteryx: the usual issue for me is that I always seem to be building most of gnome <rekado>I find it’s been a lot faster for me than before, especially for i686 (because berlin builds a bit more of that) <Apteryx>I'm at 7 min 35 s about, when there's nothing to do (since I've run it multiple times) <dieggsy>platoxia, rekado yes but scheme is _so much fun_ :D not even a chore heh <adfeno>I hhave a problem with things that depend on Qt, and some package related to GNU R seems to depend on it (at least when I last checked three months ago) <adfeno>^ my last message was in regards to "always having to rebuild sometthing" :D <adfeno>... qt stuff takes hours here :S <platoxia>rdkado: lol, it may be drudgery but I'm old and change hurts my brain. I like everything I've read and seen in the video presentations so far. I just need to get up to speed with guile/scheme and translate my old understandings of the way things go together and are configured into a programmer's view of how it works. <Apteryx>I remember that when my config.scm barely changed, it would fly through in seconds rather than minutes. <Apteryx>looking at strace it seems to take multiple long pauses on read(14, ...) calls. <Apteryx>calls like: read(14, "stla\\0\\0\\0\\0", 8) = 8 <platoxia>I encrypted a USB flash drive yesterday from the gnome files gui and as soon as it started writing zeros to the drive (berfore the encryption started) the popup went away. The only way I could follow what it was doing was with top and ps. Don't know if that is a bug or not because I normally do that sort of thing through the terminal. <rekado>Apteryx: are you following forked off processes as well? <Apteryx>I've successfully built mcron with guile-2.2 <Apteryx>now I can successfully use http-get with HTTPS in my jobs. <Apteryx>rekado: isn't it awfully late in europe right now? <rekado>but it was awfully late just a moment ago. <Apteryx>Don't often get to see you around here at this time :) <Apteryx>I'm now retrying guix system reconfigure with strace -f (to follow forks), but my observations remain unchanged. <rekado>you should attach to the daemon process and follow its children. <Apteryx>thanks! so apparently this is slow: connect(14, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("141.255.128.56")}, 16) = -1 EINPROGRESS (Operation now in progress) <Apteryx>or around there; it halts on the call: select(15, [3], [14], [14], {tv_sec=5, tv_usec=0} to be precise. <Apteryx>it is looking for grafts? I don't need to download anything. <Apteryx>also, I commented out bayfront from my substitutes servers earlier, and it was equally slow. let me retry (in 8 minutes, eh) <Apteryx>it seems to give it 5 sec everytime. maybe it could be smarter and disable it after X fails (with a warning to the console)? <Apteryx>yeah... it was bayfront. got had to reboot to get the new herd service. <adfeno>How do I veryfy the list of substitute servers I have enabled? <Apteryx>not sure whether I should log a bug about it: it'd be nicer if the guix-daemon could warn us that a machine is down and stop pinging it, slowing down to a crawl. <rekado_>adfeno: you could check “pgrep -fa guix-daemon”, or you can look in /proc to see the daemon command line <rekado_>Apteryx: there might already be an open bug report for this. If there isn’t please feel free to report it. <adfeno>My args are just: /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon --build-users-group=guixbuild <adfeno>I'm using Guix on foreign distro <Apteryx>adfeno: I'd think no explicit args = defaults substitute servers. <platoxia>platoxia@protonmail.com`\\jc4G[HckDVB/%T#g\\# <ArneBab-work>I found one reason for breakages I see in guix: When I install guile as user but use guix from the root-profile, the user-guile and the root-guix don’t work well together. Updating the user-guile just helped. <ArneBab-work>I see only guix in the guix-profile, but not guile, so these could diverge: /var/guix/profiles/per-user/root/guix-profile/bin/ <efraim>also libreoffice 6 is coming out on the 31st apparently <efraim>I think my odroid swapped or killed sshd, I'll have to wait for the current build to finish to ssh back in :/ <efraim>wow, the armbian download actually maxed out my connection <efraim>now the real question, how to open a 7z archive <efraim>unzip won't do it, tar won't accept it for tab completion <efraim>yeah, that's what I'm getting from searches <efraim>I think the SD card in my build machine died <rekado_>had to pay taxes and extra fees out of my own pocket, but I’ll probably get that reimbursed later as it’s a work laptop. <rekado_>keyboard feels worse than the thinkpad’s, and I already miss the thinkpad’s trackball mouse. But overall the build is very good. <rekado_>it took a long time to get them to release it. Forms here and there, different offices, stamps, print-outs, payments, receipts, more print-outs, signatures… the whole programme. <rekado_>hmm, screen flickers and the touchpad isn’t working. <rekado_>the brightness hotkeys also don’t work. <rekado_>feels like any other laptop, to be honest… <rekado_>looked inside: there are two big blobs of hot glue that are supposed to tie down dangling wires. <rekado_>I don’t know… this doesn’t seem right. <rekado_>clacke[m]: it was by far the most expensive laptop our department has ever bought. <rekado_>it’s 1.9k (with an expensive extended warranty which is mandatory for our purchases) <rekado_>on one hand it’s good that we don’t use our budget for yet another Dell or HP laptop but for hardware that is supported by free software, but I’d feel terrible if this turns out to be of subpar quality. <rekado_>in an alternative universe rekado just bought an old X200s and gutted it for parts to use the old X200s for a couple more months. <jonsger[m]>my "business" Dell is also crap and the Thinkpad x240 I have privately isn't really amazing :( <jonsger[m]>I invested my purism voucher into the librem 5 instead of buying a Librem 13 :P <civodul>rekado_: does your Librem have Guix stickers now? :-) <rekado_>civodul: only after I’ve confirmed that I’ll keep it. <rekado_>the touchpad not working is probably due to my thinkpad-specific xorg config snippet. <rekado_>brightness keys not working is a problem in Linux. <adfeno>rekado_: Re: Brightness keys not working: I think I have the solution. <adfeno>rekado_: Re: Brightness keys not working: I think I have the solution. [2] <rekado_>bleh, can’t find the pipe character on this keyboard (set to dvorak) <rekado_>that’s it. I’m officially old now. I hate change. <rekado_>this keyboard layout has < > where the pipe should be. And it has another < > where they are supposed to be on dvorak. <catonano>rekado_: the pipe character is a problem I often run into, ffor example withh virtual machines <catonano>recently a friend of mine gave me an entry level gaming keyboard for my Fedora desktop. It has every kind of control keys: sound, brightness... so there must be a way to do those things under linux <rekado_>adfeno: I don’t think I should have to do this on a laptop that is designed to work with free software. <rekado_>on my thinkpad this also broke fairly recently, so I’m confident that something changed in linux <rekado_>xbacklight says “No outputs have backlight property” <civodul>rekado_: xbacklight no longer works with KMS <civodul>you have to use 'light', which is lower-level <catonano>I'm excited that this level of hardware integration is being explored :-) <rekado_>I see there’s a nasty i915 backtrace in the output of dmesg. <rekado_>welp, that doesn’t seem to do anything. <adfeno>rekado_: Indeed, we shouldn't need to that kind of hack. I wonder if the support staff of the hardware can aid you on this case <adfeno>If they say that brightness keys' function were not implemented (although the keys are present) then I think one can use that hack. <rekado_>same with linux 4.9. Also still no touchpad (even though I removed my custom config) <rekado_>upon booting I still see a weird backtrace. <rekado_>and something else is weird: my PATH is no longer correct. The current system bin directory is no longer on the PATH. <efraim>odroid is down, SD card isn't corrupted <efraim>I'm incredibly tempted to hook up my firefly as my build slave and to work on getting GuixSD booted on the odroid instead <efraim>and with the eMMC on the firefly I shouldn't keep on killing SD cards <rekado_>so… /run/current-system/profile/etc/profile is empty <rekado_>a corrupt store would explain many things <rekado_>(I’m using my old disk but maybe it really is damaged) <catonano>rekado_: that would be a relief. It'd be disappointing if the Librem experience was so hard <buenouanq>If I can put GuixSD on the forthcoming Librem phone, I might actually consider getting one. <efraim>if I want a custom configuration file for a kernel I put it in as a native-input named "kconfig"? <efraim>gnu/packages/linux.scm:294 makes it look like configuration-file it is <civodul>efraim: re openntpd, you tried it in a VM, right? <civodul>i don't see where guix.ntp.* would come from if you didn't explicitly type it in somewhere <efraim>unless the config file got overwritten by ntp's config <civodul>note that %desktop-services includes ntp-service (which defaults to guix.ntp.*), but %base-services doesn't <civodul>the config you posted uses %base-services so it should be fine, no? <civodul>rekado_: i temporarily commented out overdrive1 on berlin because that offloading to it doesn't work reliably leads cuirass to wait forever for builds to complete, sometimes <civodul>i guess cuirass could have its own timeouts, but for now, that's easier <civodul>debugging cuirass without this problem is enough work ;-) ***phant0mas_ is now known as phant0mas
<civodul>atw: are you the one who did that clever shepherd-user-config-in-profile thing? <civodul>that looked like a great starting point <atw>yes :) I'm flattered. Recently I have realized that the output we got was a scheme-file. Can we use that as the (source) of a package? If so, a user service could then be included in a user's profile. <dustyweb>alas, it just did not work out scheudle wise <atw>dustyweb: congrats on the ActivityPub stuff! <efraim>looking at the READMEs in u-boot, doesn't look like the odroid-c2 can be booted in a libre manner :( <efraim>The c2 isn't listed specifically but same as the other odroid boards. I'll take a look at my pine64 <efraim>has anyone looked into ARM Trusted Firmware? <ng0>rekado_: wrt i915 and screenflickering, i guess you know about the outstanding kernel related work on it? <ng0>right now all but one are trash anyway. but maybe it helps with the flickering <ng0>saw you mentioned i915 messages <wigust>Could I get to it with `guix gc`? <wigust>If I build a system with prosody service. <atw>Make a note of the output directory, then find the file produced inside there <atw>I /think/ that's it, but I trip up often with gexps :) <platoxia>Where are all the procedure files for everything in the config.scm <apteryx_>platoxia: I use Geiser to find them (in Emacs). You need to setup a couple things (such as adding guix sources to the load-path). <apteryx_>After that is done you can M-x run-guile and enjoy interactive programming. <platoxia>okay, so guix sources from git I take it? <platoxia>I'm confused...does guix sources even have the procedure files for the guixsd system config <bavier`>platoxia: they're in the store somewhere, wherever your current guix comes from. Otherwise in the git checkout that 'guix pull' created <wigust>platoxia: If you want to tweak a GuixSD, you probably want to check a Guix manual first. <amz3>TIL: stripping binaries means removing debug symbols.. use ``#:strip-binaries? #f'' in ``arguments'' to avoid that <rekado>reinstalled to a new disk and restoring from backup <rekado>it's very difficult because Linux keeps crashing :( <rekado>looks like it is enough to use the latest kernel and run rsync to crash the system <rekado>installed an older kernel just now, but I don't know if that fixes things <rekado>great timing, because I was going to prepare talks otherwise <rekado>can't boot from the old disk anymore; the crashes were due to heavy spontaneous corruption. <platoxia>What is the reason that there are so many identical .scm procedure files under different hash directories in the store. <rekado>if they are identical they don't take up any additional space thanks to deduplication <civodul>rekado: bah, you're being unlucky :-/ <bavier`>rekado: that sounds really discouraging :( <rekado>I have to take back a part of what I said about the Librem's reliability, because at least initital errors were probably just due to the death of my disk <efraim>I have arm-trusted-firmware for the pine64 built and the package definition for u-boot-pine64-plus, but i'm getting build errors related to dtb :/ <rekado>but I'm pretty underwhelmed with this device for some reason. And the problems with recent kernels (crashed, segfaults in PID 1, locked up CPUs when using rsync, etc) are rather discouraging. <rekado>not a good second or third impression :-/ <rekado>(first impression was waiting for months to have my order accepted and shipped :)) <rekado>this might be the first and last time I buy new hardware :) <jonsger[m]>rekado: maybe we see riscv based laptops sometime "soon". I guess/hope 2022+ <efraim>there's always that arm64 laptop <civodul>rekado: that much crashing is really weird <civodul>efraim: aarch64 laptops, does that exist? <civodul>efraim: dico 2.5 fails to build for me (error while linking against libwn) <rekado>I'm looking forward to building my own crappy, impractical laptop design at some point, delegating the hard parts to CPU cards like the EOMA68 ones. <civodul>ld: /gnu/store/5fs58qwbc51f6ijjv58y8cn4svqwd9rn-wordnet-3.0/lib/libWN.a(libWN_a-search.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC <lfam>Olimex makes a low-power arm64 laptop, the Teres-I <lfam>They say they will offer new iterations of it that are more suited to real workloads <civodul>so this one is for unreal workloads? <lfam>Only 16 GB storage and 2 GB RAM <lfam>I'll hold out for something just a little beefier <lfam>And maybe with at least a Cortex A57 <lfam>The design is totally open / free so one can theoretically upgrade anything ;) <civodul>lfam: BTW, you were right: the A20 is not exactly "beefy" :-) <lfam>Heh, yeah. But immune to Meltdown and Spectre ;) <rekado>I'm feel so pampered by the maintainability of the Thinkpads. Something even more repairable would be amazing. <lfam>I saw your reply to my libreoffice patch civodul. The build completes but unfortunately libreoffice wont' run :( <efraim>civodul: dico built again without problems on aarch64, but if the linking doesn't work feel free to strip it back out <rekado>the Librem appears to be rather limited in this regard. It takes much longer to even swap out the disk. <lfam>I think I'll be upgrading and replacing parts of my x230 for another couple years <lfam>But it really feels like the world of laptop computers has moved on from what I want :/ <rekado>there are no new laptops that have even just half of what I want <lfam>Oh well, computers are such a pain anyways! Maybe I'll stop using them entirely ;) <rekado>I don't want to write a proper review of the Librem, because right from the start with no fault of its own, it fails to meet many of my requirements. <efraim>i need to add scripts/dtc/ to my PATH it looks like <civodul>rekado: if you have GWL examples that you'd like (me) to show at FOSDEM, lemme know :-) <rekado>I sent one example to the mailing list a few days ago <rekado>sadly I don't have access to my system yet (still compiling sbcl) <efraim>@ build-succeeded /gnu/store/inssd56m9gxzarwsav7kzhfd7dpkhcbg-u-boot-pine64-plus-2018.01.drv <buenouanq>ACTION patiently awaits the day when we can 3d print lisp machine processors at home <civodul>dustyweb: how d'you like it? i think it was full of good ideas <buenouanq>the computer revolution hasn't even begun (-‿‿ - ) <efraim>looks like I might need to add itb to the installed u-boot files <efraim>do we have a 'cat' command of some sort? <efraim>I'm looking to do "cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin" <vagrantc>fwiw, the teres-i isn't subject to the spectre/meltdown issues, similar to the pine64 <efraim>my firefly is I think, it has 2 A72 <vagrantc>yeah, the firefly-rk3399 is odd, two out of six cores are subject to spectre/meltdown <civodul>efraim: i have a fix for the dico issue <efraim>that'd be great, I've seen that in other packages like smalltalk <vagrantc>efraim: do you have arm-trusted-firmware in guix? i thought all the arm64 systems required it <efraim>vagrantc: I have it locally, right now I'm working with the vendor version for the pine64 <vagrantc>ACTION is really interested to see the progress on arm* for guix <vagrantc>i'm realyl interested in guix... looking for an excuse to use it for real somehow :) <vagrantc>although maybe starting with really slow resource-constrained machines isn't the best idea... :) <rekado>another crash: as soon as I use rsync to restore from backup. <rekado>one of the stack traces talks about ntpd; CPU soft lock up <civodul>vagrantc: yeah unfortunately i think you're right <vagrantc>i have noticed waiting a few days for major updates on an x86 machines means i can usually just rely on the substitutes <vagrantc>if i get too eager, i have to build it all myself <vagrantc>but i've mostly just been running an old laptop and not doing anything with it other than updating guix ... which feels a bit silly at times <dustyweb><vagrantc> although maybe starting with really slow resource-constrained machines isn't the best idea... :) <dustyweb>you mean there's some irony in a distribution where many of us are frequently compiling from source and yet using ancient machines to do so? <lfam>I'm using new machines that are totally underpowered <bavier`>jonsger[m]: yeah, see the mailing list archives <rekado>weird bootstrapping situation... <bavier`>a few of us would like it for hedgewars :) <bavier`>but something that supports more recent bricks would be nice, yes <bavier`>my backlog is too large, and things are not leaving it fast enough <rekado>ugh, yet another crash, this time from running guix gc --verify <jonsger[m]>^^ it's also not that important for me. first priority is to bring guix 0.14 to opensuse :P <rekado>over at #purism they tell me to use their kernel, or to figure out the kernel differences <adfeno>Perhaps make a diff between the sources, although I don't know if this is practial and if you have time for that. <adfeno>civodul: buenouanq: Doesn't Guile already have STeX? <buenouanq>if that's already a thing I will be so happy <buenouanq>and upset that it was kept hidden from me all this time <lfam>rekado: I have an not-in-Guix kernel config diff tool. Let me know if you are interested <rekado>so far 4.14.15 seems to work ... fine. <rekado>I let this rsync process run till completion now; hopefully it won't trigger a crash