<lfam>ACTION tries to replicate the build failure of icedtea@1 on i686-linux <lfam>And pulseaudio failed on mips64el? <lfam>I'm not sure _what_ part of the log represents the failing part: <lfam>Oh, perhaps it's the final line: "guix build: error: corrupt input while restoring archive from socket" <lfam>Or not, since make is already exiting before then <lfam>Although I'm not familiar with that message from `guix build` <nckx>lfam, re: btrfs-progs: will check :-) <lfam>At least it's not just us! <nckx>I'll have to remember/script to test --system=i686-linux as well. Let's see if kdave in #btrfs responds while I test the linked patch... <lfam>Oh, there's a patch? That's helpful <nckx>I spoke too soon. ‘Oops, I mistook the intent of that check. Please disregard.’ -- bug submitter. <nckx><kdave> 4.8.1 will be released soon. I'll do some more build checks for some strange arches we have in buildservice. so maybe tomorrow. <lfam>Sounds like a good resolution! <nckx>Let's hope it goes as planned. <lfam>Presumably one of the many xorg grafts caused trouble for icedtea. It depends on many of them... <lfam>My icedtea@1 build for i686-linux on x86_64 hardware hangs at the same place it failed in the Hydra log. `strace` shows no activity at all! <lfam>What could it be doing? :) <lfam>I guess I will try rebuilding from before all the xorg grafts <lfam>Well, I can see things happening in `iotop`, so it's not stuck <lfam>Oh, it finally started moving again! <lfam>Now I can see it hangs at the same place on my slower machine <lfam>If it succeeds on my slower machine, I'll just retry the build on Hydra <davexunit>Digit: that just installs guix the package manager <davexunit>I don't know devuan's init system works so I can't offer much advice there <Digit>step 6 went smooth. 7 looks like it will leave me at least as befuddled as 4 & 5. <lfam>Digit: Are you still wondering about step 4? <lfam>I think that if each step is successful, there shouldn't be any difficulty with subsequent steps <lfam>The "Build Environment" section has two blocks of commands to execute in the shell. The first one can be executed as-is unless your system has some special way to add users and groups. The second one is really just an example of how to run the daemon. Presumably you will want to run the daemon with your init system / process supervisor <Digit>i suppose i'm alright on track then <lfam>Step 5 really depends on your system. I don't know what Devuan uses but I assume it's just Debian's system pre-systemd. <Digit>yup. ... which you'd think i woulda learned how to use by now. ^_^ <Digit>i'll go back n reinvestigate that, see what i can translate from the systemd/upstart examples, once i've finished step 7 (inc reading the page about substitutes). <lfam>And 6 and 7 should "just work" if prior finished successfully <Digit>just for sake of ~crazy talk~... substitutes (& hydra repo) arent essential, right? i could have guix build everything locally, right? <lfam>Digit: Yes. Substitutes are just a convenience for whoever wants to use them. You could even run your own substitutes server with `guix publish` <lfam>You wouldn't be the first person to forgo substitutes! <lfam>Digit: It's just a warning. It's harmless. I believe the issue is that the locales are not available in the environment that the daemon is running in <lfam>The basic mechanism of providing locales to *some* environment is covered in 2.6 Application Setup <lfam>And I know this is heresy ;-) but you can look at the file 'etc/guix-daemon.service' in our Git repo for an example of putting the locales in the environment of the guix-daemon <Digit>hrm. not sure that's my only problem here. locales warning repeated when i tried guix package -i hello, and also "guix package: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused" <lfam>The second error is a real error. Are you sure the guix-daemon is running? <lfam>BTW, until you fix it, you will see the locales warning for every Guix operating that talks to the daemon, which is most of them <Digit>yep. will look into that after getting the daemon into the init system, if i dont fall asleep first. ((why do these bright ideas always come so late in the day?)) <Digit>there we go. sloppy n ugly, n maybe overly simple, but there it is, as dropped in to /etc/init.d http://dpaste.com/2HJ46D3 twill be a while before i discern whether that worked, since i rarely reboot. i think it maybe only really requires the first and last lines. <lfam>Digit: It's better to use a path that doesn't go directly to /gnu/store. If you use that path, the service will stop working when you upgrade Guix. I recommend '/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon' <lfam>It's an absolute path so it should work in places where ~root/.guix-profile does not <csanchezdll>did you manage to solve it? (I saw you worked it around) <csanchezdll>quite similar, inode reported by stat64 and getdents64 does not match for "guix-build-make-boot0-4.2.drv-0" <csanchezdll>making my own test derivation that compares inode numbers (as suggested then by ludo) works, surprisingly ***htgoebel1 is now known as htgoebel
<fps>hmm, it seems xmonad needs ghc as propagated input, so the user can run xmonad --recompile to get his config.. <fps>that at least removes the one error about ghc not being found. but then.. <fps>ghc cannot find the xmonad modules.. <fps>i can't paste the errors right now since i don't have a browser yet ;) <rekado>fps: have you tried installing ghc manually? <fps>rekado: yes, that's what lead me to introduce ghc as propagated-input in the xmonad package <fps>rekado: oh, you mean instead of through "xmonad --recompile"? <fps>i would have to find out first what command precisely xmonad --recompile runsw <fps>fps@cherry ~/.xmonad$ ghc xmonad.hs <fps>yeah, that gives the same errors as xmonad --recompile. i guess we have to point ghc to the xmonad libs to make it work <fps>i wonder how module lookup works with ghc :) <fps>aha, the xmonad package itself does not show up in <fps>fps@cherry ~/.xmonad$ ls /home/fps/.guix-profile/lib/ghc-7.10.2/package.conf.d <fps>as i have no idea about the ghc package maintenance in guix i might give up now ;) <fps>hmm, maybe xmonad needs to be dual installed? once as bin and once as haskell package? <fps>ahaa, installing ghc-xmonad-contrib into the user profile and exporting the GHC_PACKAGE_PATH took us one step further :) <fps>fps@cherry ~/.xmonad$ ghc xmonad.hs <fps>[1 of 1] Compiling Main ( xmonad.hs, xmonad.o ) <fps>gcc: error trying to exec 'as': execvp: No such file or directory <fps>it seems we need gcc, too <fps>these environment variable suggestions are only collected for packages installed in the user profile? <fps>not for system wide installed packages? <fps>ok, installing gcc-toolchain and exporting all its variables seems to have worked.. <fps>fps@cherry ~/.xmonad$ xmonad --recompile <fps>fps@cherry ~/.xmonad$ <fps>is there a way to tickle the environment variable suggestions out of guix at a later point in time again? <fps>so i can assemble them automatically for a new shell? <rekado>guix package --search-paths, I think <fps>so i could do this in .bashrc? <rekado>there's also ./etc/profile which you can source <fps>that makes everything simpler :) <fps>and reloging into xmonad seems to make the new config take effect.. <fps>usually that should work just via mod-q <fps>oh wow, the xonotic package disappeared at some time? <Jookia>Also if anyone's interested, I'm patching Firefox and LibreOffice to work with dictionaries for NixOS, it should work on Guix too <Jookia>If it doesn't, Guix should make sure to have a 'share' directory contianing 'hunspell' dictionaries (maybe spell) too in XDG_DATA_DIRS <Jookia>If this is an issue it'd be cool to know <htgoebel>I'm looking for some decent "debugging" guide, telling me how to get an interactive environment like the one used for building. … <htgoebel>… So I can look at e.g. pathes, installed stuff, etc. … <htgoebel>… Telling me what do to after `guix build … -K` … <fps>hmm, i forgot. how could i set the PREFIX environment var for a make based build again? <Jookia>htgoebel: I think you have to read the packages and gnu-build-system. If you want to understand what the builder is actually doing, you'd have to find the builder Guile code and format/read it I think <htgoebel>jookia: I do not want to understand the builder :-) I just need to find out why my build fails. <xd1le>does GuixSD have concept of stable/unstable? I'm guessing not because it's "beta" software? I just did a fresh 0.11.0 install, and so I'm wondering if to stay on 'stable', I would just have to avoid running `guix pull` under root until a new release? or is that not recommended? <xd1le>(I know there's rollbacks btw, but just wondering) <Jookia>htgoebel: I think you want to source the environmental variables file that's left over, cd $PWD and also read what happened before the build failed <htgoebel>Jookia: Hmm, I'm not convinced, but this may indeed work. No need to set up an guix environment then? <Jookia>htgoebel: I think sourcing the environment variables will bring you in to the environment, though I could be wrong <ng0>there is no concept of 'stable' / 'unstable' right now, xd1le. It's just rolling. <ng0>and the updates which would cause like 300 packages to rebuild are moved into a separate branch and tested for stability etc, so the rolling is smooth for the users <ng0>generally a regular guix pull + guix package --update should be enough.. and guix system reconfigure /path/to/config.scm for updating kernel etc <ng0>I still got no reply from the local shop about PSUs.. could just walk there, but: was there any change in PSUs in the last 17 years? can I just plug in a 2016 produced PSU into a 1997 board and it works without producing toasted chips? <ng0>anywhere I should read up on? PSUs were never my favorit subject <xd1le>I get "Couldn't resolve host ..." from curl downloads and git clones on a fresh GuixSD install. Not sure what to do, did I miss a step? <xd1le>My system configuration is basically the lightweight-desktop.scm one from the examples (using i3). <ng0>no, there's an environment variable for that, but I don't know which 2 you need right now. someone else will know <xd1le>ng0: HTTP_PROXY, HTTPS_PROXY ? <ng0>more like GIT_CA_something and CURL_CA_something .. it's the something I don't remember :) <fps>xd1le: rerun dhclient <fps>xd1le: dhclient your_ethernet_interface_here <ng0>and also nsscerts or what it was might be needed <fps>oh curl downloads and git clones, yes, it's a certificate issue usually :) <xd1le>fps: that actually worked though.. :/ <fps>xd1le: the dhclient? <jmd>How can one do the Guix logo in ascii-art? <xd1le>yes. don't know why because I did already do that after boot <fps>xd1le: yeah, there once was a bug where this happened only in the installer.. seems to happen in the installed system now, too <fps>i had to re-dhclient, too <ng0>ascii-art: get creative :) and maybe even include that in the artworks repository where the other logos are? <fps>too close to goatse ;) <fps>ah, the internet ruined me forever <xd1le>fps: hopefully setting up auto networking at boot with wicd doesn't do this though (haven't got to that yet) <ng0>lies, ii, lies.. there was a second \\ <jmd>Actually, who is responsible for artwork in Guix? <ng0>who did what currently is, or who is doing it? <ng0>look into the repository where the website is contained :) <ng0>basically everyone who can.. <jmd>Do we consider the ~v~ logo to be current? Have we abandoned the Isle of Man lookalike? <ng0>isn't it both? I don't know <ng0>o.o doing a backup before I'm getting ready to maybe eventually damage my system.. around ~100 GiB in src/ and re-src/ in sourcecode. wow <fps>linux-libre 4.7.0 doesn't have ice1712 alsa modules anymore? <fps>4.8.0 doesn't seem to have it either <fps>i wonder why that is.. i can't see it mentioned in linux-libre's news <fps>gnu/packages/linux-libre-4.8-i686.conf:CONFIG_SND_ICE1712=m <fps>should be available as module <ng0>maybe some change in upstream linux? <fps>i'm enabling it in linux-libre-4.8-x86_64.conf <fps>and see if it builds <fps>ng0: possibly the default changed from m to off? <ng0>I don't do much kernel configuration these days, and not on guix so far. <fps>wasn't there some licensing problem with openssl? <ng0>that's why I ask, I refuse to remember every unimportant little detail. <ng0>well, not umimportant, but we all have our priorities. <fps>ok, rephrasing as statement: iirc there's a license problem with openssl :) <ng0>so the fix I would do is to look at how other systems solve the gnutls functionality. <ng0>look at their patches etc <Jookia>IIRC OpenSSL isn't easily compatible with the GPL without adding an exception <ng0>Gentoo uses libressl, openssl, and gnutls. and there are no patches they use for gnutls it seems, other than the patches they apply for gnutls itself <ng0>has someone tried the develpment version of lynx? <ng0>maybe there are gnutls support fixes. <fps>hmm, interesting. i enabled snd_ice1712, the system reconfigure ran fine, but still the module is not enabled.. <ng0>also some number before that libgcrypt was dropped in favor of gnutls when gnutls is used.. so we should make an exception, test the latest released pre version and if it works use that. <ng0>because clearly right now lynx is broken. <ng0>or backport commit patches. <ng0>I'll add this monologue to my answer later on the mailinglist, reading a book right now <ng0>the dev tarball is just unversioned though. so this needs to be investigated by someone <htgoebel>I found garbage in a source-archive which needs to be remove prior to installing. Should this go into a snippet or into a phase? <ng0>depending on the type of garbage :) <rekado>htgoebel: a snippet will ensure that "guix build -S" returns the patched sources. With a build phase "guix build -S" is unaffected. <htgoebel>rekado: emacs backup-files, .pyc files etc. <htgoebel>rekado: These need to be removed, otherwise they and up in the installed output <ng0>why do people buy chromebooks, like the c201? I would be an interested in one for compiling to arm, but it always looks like you can't change the harddrive or no harddrive exists at all. <ng0>looks like the only good option is novena? <Jookia>There's lots of single board computers <ng0>reads to me like a combination of german and english. do you have a website? <civodul>htgoebel: depends on the kind of garbage :-) <ng0>but the question, at least with udoo, remains: just use external harddrives? <civodul>htgoebel: binaries should be removed in a snippet <ng0>oh, failed to spot that. i should read the specs <ng0>that's even better than another laptop.. less space waster (and less resources hopefully) <htgoebel>civodul: No binaries, except it compiled byte-code counts as "binary" <rekado>htgoebel: I’d consider pyc files as binaries. <htgoebel>rakado, civodul: Okay, so I put this into a snippet and take the chance to remove the other stuff, too. <ng0>now if I could get something i686 that size, I could spare re-activating my very old i686 board for just system-image generation (and testing hurd) <civodul>htgoebel: BTW, could you avoid HTML email on the list? i don't know why, but somehow my mail client hangs when it stumbles upon it <civodul>(arguably an email client bug, but hey...) <janneke`>user-error: Your Emacs was not compiled with xwidgets support <ng0>you should be able to configure emacs to ignore html and only in only-html render it with lynx or others, ludovic <janneke>ACTION wonders what OS Emacs devs might be running? <ng0>there are no i686 boards the size of wandaboard by any chance? I'm pretty ignorant with development of such boards... <civodul>we all know they should be using the Emacs of distros <htgoebel>civodul: I've set up a filter, let's see if it works. <janneke>rekado: someone who advertises xwidget-webkit-browse-url in C-h n <htgoebel>ACTION gets crazy with this python-build-system <rekado>I’d think that Emacs devs run their own development version. <htgoebel>One of the python packages generates *two* .egg-ifo files. Can't find the reason. <rekado>janneke: I have a couple of patches for xwidget that improve the experience (and make it use the Webkit2 API). <rekado>still waiting for copyright assignment to be completed… <janneke>rekado: that could be...but one GNU project advertising a feature and the other building it without is---just doesn't seem to be one community? <ng0>ludovic, can't send it as an email comment right now, but I'd suggest for lynx to look into the patches and or pre versions of lynx. that could fix the gnutls problem, changelog has some gnutls items. <rekado>janneke: we discussed shortly about whether to enable xwidget support in our build, but in my opinion it’s just not mature enough. <rekado>it depends on the old Webkit API, which means that you have to link Emacs with an unsupported version of WebkitGtk. <rekado>handling of the xwidget buffer is also kind of frustrating at this point <janneke>i tried xwidget-webkit about a year ago but now saw that NEWS says it uses webkitgtk3...so i figured there had been a major upgrade <jmd>Aren't parts of webkit non-free? <davexunit>yeah xwidget stuff just doesn't work very well yet, and using an obsolete (read: vulnerable) version of webkit isn't a great selling point, either. <Jookia>Will Guix install dictionaries to a path in XDG_DATA_DIRS <rekado>there aren’t many browser features yet. It’s not clear to me in which direction development should go there. Looks like it won’t easily integrate well with the rest of Emacs. <davexunit>Jookia: not sure what you mean. Guix only installs things to /gnu/store. <ng0>so my phone is now faster than this old celeron 800 computer.. <davexunit>not familiar with how dictionaries and freedesktop fit together <Jookia>davexunit: Will hunspell dictionaries we availabile in a subdirectory in XDG_DATA_DIRS named 'hunspell' or 'myspell/dicts' <rekado>Jookia: usually you’d install a package into a profile and then add the subdirectory of that profile to XDG_DATA_DIRS <ng0>I think as I understood it last week, it's about unbundling hunspell.. right? <davexunit>are we talking about files being installed to something like $prefix/share/hunspell or something? <civodul>FWIW our aspell package automatically looks for dictionaries in ~/.guix-profile/lib/aspell <davexunit>if you know what the appropriate directory suffix is, you can use the native-search-paths package field to have guix do the right thing <Jookia>Each application that uses hunspell loads dictionaries themselves <Jookia>My hack on NixOS is to get them to look in XDG_DATA_DIRS for dictionaries so that they won't be hardcoded to a single unusable path, like /usr/share/hunspell <Jookia>So if /run/current-system/sw/share is in my XDG_DATA_DIRS, LibreOffice will now find dictionaries in /run/current-system/sw/share/hunspell <davexunit>sounds like the right approach. is XDG_DATA_DIRS the correct environment variable for this? <Jookia>I'm trying to fix various upstreams <Jookia>I am wondering if Guix is taking the same approach or plans to <Jookia>So that way you will benefit too <davexunit>but surely getting upstream projects to stop using a hardcoded path sounds good <davexunit>I question if XDG_DATA_DIRS makes sense, though <Jookia>I also fixed GTK's theme paths the same way <davexunit>but I'm not educated on the subject so I don't really know what the right thing is. <civodul>for GTK themes we have a "profile hook" <Jookia>if you have a better idea than using XDG_DATA_DIRS (which defaults to '/usr/local/share/:/usr/share/') then I'm all ears <civodul>maybe that would work for hunspell too? <Jookia>civodul: No, this is a runtime issue <Jookia>Unless you want to rebuild LibreOffice each time you enter a new environment, you need to patch it look for dictionaries elsewhere <ng0>these single board computers are more than twice as fast as my 17 years old board and much smaller and cost only a percentage of what I paid back then.. how fast things develop and progress. <Jookia>This is the same with Firefox and friends <htgoebel>How can I quickly dump the contents of a list of stdout (within a phase)? I need to find the reason for some "find-file" not working as expected <Jookia>It would be nice if Guix used the same approach as what NixOS will do so you don't have to repatch <civodul>htgoebel: it prints the result, and returns it <Jookia>davexunit: HUNSPELL_PATH seems a bit redundant given there's already patches for the same issue in GTK that use XDG_DATA_DIRS <Jookia>Instead of APPNAME_PATH for every application that needs to look for a profile's equivalent to /usr/share, XDG_DATA_DIRS seems fine <davexunit>Jookia: okay, if the accepted way is already to use XDG_DATA_DIRS then that sounds fine <davexunit>I was under the impression that you were leading the charge on this <Jookia>I am, but I already decided when I patched GTK and GTK3 <Jookia>I'm here to understand if Guix has different plans for storing dictionaries <davexunit>you could make the same argument that guile, ruby, python, etc. should just use XDG_DATA_DIRS to search for modules <davexunit>instead of having their own environment variables <davexunit>but it makes sense for them to have their own variables <Jookia>I figure Nix and Guix can handle specificity by profiles <davexunit>so if hunspell has nothing to do with free desktop or gnome, I would be inclined to use a separate environment variable <ng0>I wonder how high the import costs of wandaboard is.. my only local choice seems to be mouser, and they only sell packs of 10.. I can't spend 1200 euro on this. <Jookia>davexunit: You've reminded me that the hunspell checker already has an environment variable that does the same thing as what I want: DICPATH. But is it worth getting Guix/Nix to set this variable in every profile when it already handles XDG_DATA_DIRS the same way? <Jookia>I suppose it'd fall in to the principle of least surprise too <davexunit>the guix package for hunspell just needs this information added to the native-search-paths field <Jookia>Since I did actually try to use DICPATH myself with LibreOffice <Jookia>The issue with Hunspell is that applications load dictionaries, not the hunspell library <Jookia>So every one has to be patched individually <rekado>ng0: the EOMA68 A20 computer card specs seem to be similar to that of the Wandboard. <rekado>I read the specs of the CubieTruck <ng0>hm.. okay, there it would ''just'' be around 40 USD of shipping for me i ncase I don't want to wire money to my visa card <ng0>but in any case, i'd like to test eoma68 a20 for future purposes. <ng0>cubietruck is weaker than wandboat? <ng0>so it seems like what Jookia is suggesting could take a lot of duplicate work from us? <Jookia>I'm trying to do the work for Nix but factoring in Guix's input too <Jookia>So plan is to look for dictionaries in DICPATH like stock hunspell checker program does, but in Firefox and LibreOffice too <Jookia>Oh, now I remember why DICPATH/HUNSPELL_PATH is a problematic idea: There's also other libraries like hyphen mythes too <ng0>related to the other thing, rekado I think the first generation of eoma68 a20 is too weak to compile a complete system including X etc..? I mean the only real limiting builds I experienced on machines where I had to compile webkit, libreoffice, or firefox and failed for obvious reasons. so theoretically I could compile X11 on a 1ghz toaster...? <ng0>or is cross compiling AND system-image something I can outsource? <Jookia>davexunit: Given hunspell/mythes/hyphen all fit this issue, it seems like the better option to include all three really is just checking XDG_DATA_DIRS <davexunit>Jookia: I don't think so, but maybe talking with upstream would help determine what the right thing is. <davexunit>XDG_DATA_DIRS is just too general, and consider that this software should work on machines not running freedesktop stuff or even other operating systems <Jookia>From what I understand XDG_DATA_DIRS isn't specific to freedesktop stuff, it's just an env var that' somewhat standardized. But yes, I do need to explore the problem space more <rekado>htgoebel: I cannot view this paste. (Needs js?) <davexunit>we've recently started using duplicity at work for mariadb backups <paroneayea>I'm not totally sure what I'd do for defining services for these, now that I'm looking at them. They don't really have configs as much as command line args <paroneayea>so it seems more like you'd be producing commands to pass off to the crontab <paroneayea>maybe having procedures that can produce those is still useful. <paroneayea>it's nice that both support encryption, though I think I will do encryption on the disk level rather than on the backup archive level <htgoebel>rekado: yes, it needs js, so you can edit it. Do you know any other tool? (I'm using this stuff very rarely) <paroneayea>mainly because I don't want to have to type it in in order to run backups <davexunit>paroneayea: I haven't used our mcron service, but you should be able to just make a gexp that will run duplicity/borg with the command line args that you want <paroneayea>it's nice that duplicity uses tar; I liked that dirvish also used a "simple" format (in that case, just directories with hard links) <paroneayea>so borg having its own format isn't really a downside comparatively <davexunit>#~(system* #$duplicity "--arg" "--other-arg") <paroneayea>I think for "remote backups", I'm going to trust a sneakernet solution <paroneayea>a friend and I are talking about meeting up once every few weeks and rotating our backup disks <paroneayea>I think that's a better solution than remote backups at some "cloud" service, since encrypted information only stays sufficiently encrypted for like a decade <rekado>they are needed by qtwebengine, which is needed by texmaker. <htgoebel>rakado: Well, paste.lisp.org need cookies, requires you to give some name and a captcha. <rekado>texmaker is broken since we removed webkit from Qt. <efraim>I forget the command I used to use to search the qt modules in my store <efraim>Might've just been find /gnu/store -iname qtqml <efraim>Except its incredibly slow on spinning rust <efraim>Might be faster to run tree -d on the full qt source <rekado>htgoebel: I posted something before seeing your first annotation. <rekado>htgoebel: you’re missing the parens for the list of variable declarations <rekado>htgoebel: inside the parens there’s lists like (a 42) <rekado>htgoebel: so together it’s (let ((a 42)) (use a here)) <ng0>for krita there's the question for qt modules i had.. <ng0>i don't know what's available and what is not <jmd>Do we have some sort of (semi) automatic process to notify us of upstream releases? <ng0>refresh or what it was <ng0>but other than that, not that i'm aware of. I'm jus tsubscribed to lists and have an search:RELEASED 'inbox' <Digit>ACTION gets back to getting reacquainted with guix, after installing guix on devuan before falling asleep last night, and while looking into emacs integrating, installing geiser, thinks "mmm, i really should thank those guys for making this" <Jookia>davexunit: I'm disappearing for a while but I spent a while surveying all the dictionary software and how it fits together and have concluded that DICPATH is the right way to go, as well as ASPELL_CONF. :) Thanks for your input! I'll write up my reasoning tomorrow in the issue I linked to <ng0>eoma68 a20 is just my corner, what i want.. I hate screws. assembling 2 laptops I've delayed re-assembling for 3 months. <bavier>ng0: I'm excited to get my eoma68 :) <ng0>I think I'll order one, to test my theory for lowest resources needed to build one variant of my system. <rekado>I’ve ordered the a20 + desktop case too. Want to use it as a simple web server and cancel my VPS. <ng0>I could not use my domain names at home.. and I'm too busy to look into setting up my own system which works around ows current limitations. <ng0>I haven't yet decided if I ditch all the names, but 70-80 euro per year for just stupid names is too much (currently) <paroneayea>eventually when I start doing more deployment'y things, I think I'm going to want a nice way to automate the "pull down guix from git at this exact revision and build it..." though <paroneayea>I guess the right answer to that is to use guix to build the guix-from-git at a precise revision. <ng0>currently it seems so, yes <paroneayea>though, I guess there's that talk about having guix pull from git anyway <paroneayea>so maybe that mechanism is the right one, in the future. <ng0>I stopped having servers until I can have a lazy-panda-guixsd solution ready <rekado>I only have one domain name. Everything else gets subdomains (for which I don't need to pay) <rekado>paroneayea: yeah, Pjotr and I want the same. This is what this channels feature must include. <rekado>this would make manifests more useful. <rekado>indispensible for reproducibility. <ng0>life skills: I know how to assemble laptops which do not fall appart but have more than 0 screws left over :) <jmd>I think gnunet domains come gratis too. <ng0>there's also eh.. what was the name.. damn, i even participated for a while <ng0>but it's just an alternative dns <ng0>'commercial ad voice questioning: has this ever happened to? 'you plug in your functional guixsd usb disk in your very old Asus AspireOne. You boot it, you select linux-libre, there is activity on the stick, and then it is giving you the black screen? <ng0>ubuntu jsut told me it is an i686 <ng0>we should have that in guixsd boot usb... complain about wrong architecture <rekado>kernel people are using patchwork? <rekado>hmm, so maybe we’re doing something wrong…? <ng0>there was like 5 people here who used it.. <ng0>wit hthat small number it can be considered a failed experiment <ng0>and the minor bugs it has :) <rekado>well, I used it, but it didn’t reliably close patches, which made it hard to see what’s relevant. <rekado>maybe there are magic phrases that it recognises in emails to mark open patches as merged? <ng0>yep.. and it expects you to know that name at signup = forever, and that one user = one email address etc <rekado>I’d really like to use patchwork if it means that I don’t *also* have to log on to a web interface regularly to clean up the cruft. <ng0>I wasn't interested in taking up the offer upstream devs gave me in fixing it <ng0>pointed me to old request to complete it <rekado>and you can abandon an old account if you want to change your name. <rekado>I don’t think it’s a big obstacle. <rekado>it’s not like a social media account. <ng0>just read the upstream bug report.. i don't want to discuss about it anymore :) <ng0>well or don't, i don#t know what the report exactly was anymore.. not so important <ng0>so our i686 system-image is asus eeepc 'aspireone' incompatible <ng0>doesn't even start, while the x86_64 one launches into the grub menu at least <bavier>ng0: I've used the i686 image to install onto an eeepc <ng0>that's one of the first eee pc i have here, not a recent one <ng0>even non-functional I'd expect to make it to grub <OrangeShark>civodul: That has actually happened to me on Fedora, it had crashed while updating... <ng0>has this ever happened to you.. <ng0>so I could theoretically install ubuntu and guix system init from there and clean up the ubuntu rests, right? I can not print a '1' in grub 0.9 menu I'd need to boot from usb <davexunit>I'm at the end of my rope. the hashes are all different between two machines despite running the same guix <davexunit>they must not be the same, but I can't figure out what makes them different. <bavier>davexunit: file content hashes, or store hashes? <davexunit>not *all* of the hashes are different, but enough are that are making my pull my hair out in utter confusion <janneke>davexunit: prolly the biggest feature that Guix misses wrt GUB: a nice diff -u showing what changed in the previous to current dependencies <davexunit>something is up, surely, but I just can't figure it out <paroneayea>did someone put a timestamp into a package definition? ;) <davexunit>no matter what I did I couldn't get them to work without building from source on the machines I was deploying to, which is a dealbreaker. <davexunit>I used to use mirror.hydra.gnu.org + my 'guix publish' server, but when the mirror started having problems I dropped it so I no longer needed to rely on it <davexunit>(it was causing important VM builds to fail) <davexunit>now they just happen very slowly because I can't get substitutes for a number of things <davexunit>it will be okay but it is eating up more time than I expected. <paroneayea>davexunit: are you deploying servers using guixsd? <paroneayea>is anyone deploying servers with guixsd yet? I guess hydra is running guixsd now right? civodul put out that "hack the guix servers config" email <davexunit>I really want to figure out how to run a guixsd system on linode <davexunit>and transition things from my debian server over to it <ng0>servers... reminds me, did someone recently reply to my opensmtpd email thread? <paroneayea>server deployment to guixsd is my next big agenda item after the standards stuff cools down. <fps>anyone experienced with changing the kernel config here? i added CONFIG_SND_ICE1712=m to the x86_64 linux-libre 4.8 config <fps>and reconfigured my system (which rebuilt the kernel, etc) <fps>but after a reboot there still was not snd-ice1712,ko <janneke>paroneayea: in the last 2000 mails on guix-devel don't find any mail by civodul titled `hack', `server' or `config' (well, one reply on kernel config maintainablility)? <ng0>2000, that is like 2 months.. <ng0>what I remember is some 'machine-admin' config / service <ng0>but I don't know what it was named and can't search it for this reason <janneke>ng0: went to 10,000 and still didn't find it <janneke>color me blonde, isn't a server just a desktop without all the overly problematic and complex xorg/gnome/wicd stuff? <detrout>janneke: servers may have multiple cpu sockets and more complex storage technology than you'll usually see on desktops <paroneayea>janneke: let's not propagate the "blonde" stereotype! but, sort of... <paroneayea>janneke: there's also the goal of remote deployment <paroneayea>janneke: if you ran a research lab, you might want to deploy a lot of desktops, and that would be very similar to deploying a lot of servers, yes <janneke>paroneayea: ah, yes if a server implies a farm, then a request for information really makes sense <paroneayea>ACTION wonders what the best parameters are considered today <paroneayea>I would just do "ssh-keygen -t rsa", but I don't know if that's considered "optimal" anymore. <hellcode>well, despite the indeterminism in installing guix, I got it <paroneayea>I think that article probably was what made me think in the back of my brain "maybe the default rsa option isn't best" <paroneayea>detrout: it's probably silly, but I feel like I "know" rsa 4096 is still good, and after the dual elliptic curve attacks, I'm not confident about other types <paroneayea>detrout: "ED25519 keys are favored over RSA keys when backward compatibility ''is not required''." hm! <ng0>I'd use my ed25519 if debian would already move on.. 6 months ago it was not compatible to what some people I wrote with had. <detrout>irritatingly gnome keyring doesn't support ed25519 either. And I'm not sure how to override it and force the ssh or gpg agent instead (under debian/wayland) <rekado>davexunit: have you confirmed that the mode bits on the bootstrap binaries are identical? <ng0> /me is waiting for the backup to finish to send in open new bugs / questions <rekado>I guess it would be useful to see the differences in a graph. <rekado>this would make it easier to see how (if at all) the differences relate to one another <civodul>ACTION ready to start building core-updates <civodul>rekado: can we remove GHC as an example of propagated-inputs in "package Reference"? ***lewo_ is now known as lewo
***paron_re` is now known as paron_remote
***kragniz1 is now known as kragniz
<dejavu89>any progress on arm, libreboot and guix? sometime ago there was a discussion about porting guix to chromebook c201 <dejavu89>which can run without closed firmware, microcodes, etc