***felixfahrbahn[m] is now known as tessssann[m]
<raghavgururajan>mroh: I used that package it doesn;t have library called libinotify.so[.a]. <mroh>raghavgururajan: inotify on linux is part of glibc, afaik. maybe you have some bsd sources that needs this lib? <wleslie>so I've been somewhat aware that I'm "not doing it correctly" as I'm packaging my cross environment, today (while battling with some linker errors) I figured I'd actually test using --target https://bpa.st/PMOA <wleslie>now, it's not picking up my cross toolchain, and I think that this is because I'm not using native-inputs vs inputs properly <wleslie>how do I tie crt, newlib, and libstdc++ into the gcc that I export as part of the toolchain? and how do I get guix to find my toolchain from the requested --target? <wleslie>janneke: when you have some spare time, I'd love your thoughts on those questions ^ <brown121407>Guix's IceCat seems to make Cloudflare protected sites loop infinitely on the "Checking your browser before accessing" page. Is there any way to make this stop besides using another browser? *wleslie is reading commencement and is a little daunted but can probably muddle through ***jsndjsjsjsjaj[m] is now known as felixfahrbahn[m]
<pinoaffe>brown121407: I have not yet encountered this issue, it might be caused by one of the plugins that icecat comes with by default ***apteryx is now known as Guest67518
***apteryx_ is now known as apteryx
<leoprikler>I don't necessarily think that's IceCat. Cloudflare is prone to looping in Epiphany as well. <pinoaffe>brown121407: oh wow, that site is not working for me either <pinoaffe>even though I've previously used this particular site as well as lots of cloudflare-protected sites without issues <pinoaffe>looking at the network log while loading that page, it does not seem to contact any cloudflare servers, so it may not be a cloudflare-related issue in the case of gitlab (or maybe that's the problem, I don't know) <leoprikler>IIUC it should communicate with Cloudflare in some fashion to do some weird "sanity" checks. <janneke>wleslie: that's a whole lot of questions, that i don't fully get; i can have a look later *raghavgururajan 's zopiclone is kiking in <wleslie>thanks, I think I found a way to proceed for now <leoprikler>I don't have bayfront substitutes, so it'll take some time <civodul>hi tgamblin-llnl! looks like you have networking issues :-) <leoprikler>raghavgururajan: small hint, you should probably call the package "telegram-desktop" (like the command) <raghavgururajan>leoprikler: Yep, was gonna change the package name in the next revision. <leoprikler>According to gdb it fails in Ui::Emoji::UniversalImages::generate(int, int) const <raghavgururajan>I think it is Qt related. My another package 'nextcloud-desktop' (#45889) also doesn't launch in similar way. <leoprikler>apropos qt if telegram depends on qresources, that probably won't work <mdevos>does someone have an IPFS service definition for Guix? <leoprikler>however, not grafting doesn't appear to be a solution <jeko>I have installed Emacs in a custom profile on my Guix System. Gnome app list does not contains Emacs. Do you know why? <iyzsong>is the custom profile in gnome's XDG_DATA_DIRS, also it may need restart gnome to refresh the list. <raghavgururajan>leoprikler, Can you try with "-DTDESKTOP_DISABLE_GTK_INTEGRATION=ON"? <jeko>iyzsong: Hey! Yep I added it but don't remember if I restarted Gnome... let me retry it ! <jeko>iyzsong: I set XDG_DATA_DIRS in the .bashrc file. is it ok to do so ? <iyzsong>i think it need to gnome-shell's environ. I don't know how to set environment varibales for gdm though. <wleslie>jeko: if you want your desktop session to pick up environment variables, you can put them into ~/.profile <jeko>wleslie: Thank you, on my way to try it ! <jeko>sounds like I failed haha will retry after lunch <wleslie>ok so I have a nice toolchain now, how do I get `--target` to use it? <leoprikler>raghavgururajan: the issue is this->_sprites being empty <leoprikler>Interestingly this code seems to run in the initializer, so⌠<leoprikler>(Well in the initializer of Ui::Emoji::Instance) <civodul>wleslie: hi! --target creates a cross-compilation toolchain by calling the procedures in (gnu packages cross-base) <civodul>cbaines: hey! do you know the status of the package browsing interface that Danjela worked on? <civodul>or maybe i'm looking at the wrong place? <civodul>apparently the web site was rebuilt 20mn ago so it should be up-to-date <civodul>mothacehe: ooh indeed, rather hidden :-) <civodul>BTW, i'm sorry for commenting on the name "Cuirass"; i hadn't read the other thread on guix-devel when i did <civodul>(i find the the logo pretty nice actually) <mothacehe>hehe no worries, lots of exchanges about that recently. Maybe we need a new section on the website to point to Guix ecosystem software such as Cuirass, the Data Service and so on <civodul>yes, not sure how to best present it <civodul>but i agree it'd be nice to have pointers to these projects <cbaines>I haven't had time to look further at it, I think there's still some thinking needed around where it could go and how it should integrate with the rest of the website <civodul>cbaines: alright; would be nice to move forward here <civodul>building all the package pages statically has become a bit of an issue :-) <kiwi_guixer>Hi is there some bug with recent GDM? I guix pulled and now I see black screen after reboot. I can login with previous revision but not with new. <cbaines>civodul, ah, OK. One approach would be to have packages.guix.gnu.org be the part of the website for looking at and searching for packages <cbaines>and splitting it off to a separate domain would remove the need to tightly integrate the dynamic content in to the static website <civodul>cbaines: we could keep /packages and have the nginx config direct it to the other thing <efraim>sneek: later ask vangrantc do you have any suggestions for setting up a debian build environment in Guix System? <apteryx>what would you think of moving a few core python building modules to (gnu packages python-build) ? <zimoun>civodul, cbaines: hehe! thanks about option hints. Well, Friday procrastination, I have implemented levenshtein-distance and started to be able to hint. My question is: where do put this kind of stuff? (guix ui) or (guix scripts) or else? <civodul>cbaines: having everything at guix.gnu.org might facilitate css sharing <civodul>zimoun: neat! i'd put the Levenshtein bit itself maybe in a separate module <civodul>and then hinting in (guix ui), i think <zimoun>I was thinking to tweak parse-command-line in (guix scripts) <cbaines>civodul, I think having a somewhat consistent style is a must, but how to implement that is one of the things remaining to work out <cbaines>using the CSS from the website elsewhere could get a little tricky when making changes to either the website, or other things using the same CSS <zimoun>civodul: a module for a 21 lines function? <civodul>cbaines: i think it's ok here; the generated pages could have the 2-3 CSS links that they need and then be done with it <kiwi_guixer>Is there a working alternative for GDM, ideally with auto login support? <zimoun>well, let propose a patch and then the v2 can revamp :-) Keep in touch <kiwi_guixer>aH, it looks like regression RADEON(0): Setting screen physical size to 338 x 211 <cbaines>civodul, out of interest, what's the technical issue with the static generated pages? <civodul>cbaines: building the web site in one language takes some time, largely due to the package pages, and now there are several languages <kiwi_guixer>Anyone familiar with /gnu/store/8kvz928qp7fdv4bak5zjqhm05r3ccx9f-xorg-server-1.20.10/bin/X: symbol lookup error: /gnu/store/7nnnzsrlflq60pp08g1y1amjk891vgp3-xf86-video-ati-19.1.0/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate <rekado_>kiwi_guixer: I saw the same problem a few days ago! I had to revert to an older kernel. <kiwi_guixer>Thank you, I am new user, any pointers what to set in config.scm appriciated <kiwi_guixer>So operating-system takes kernel parameter but there is no reference to available values. <kiwi_guixer>There is also that Warning about debugfs during reconfigure. Some match-error but I did not change my config.scm and it worked in the past. <rekado_>civodul: oh, itâs possible I only rolled back to an older system generation. I donât remember; itâs a different machine. *apteryx has a fix for the PYTHONPATH uglies <rekado_>apteryx: like⌠for a *all* the PYTHONPATH nastiness? <rekado_>what happened to you? Youâre casually tackling all the difficult problems! <kiwi_guixer>Thank you civodul but after reading those pages is not clear if adding (kernel "linux-libre-5.4") is what I should do. <civodul>kiwi_guixer: you'd write (kernel linux-libre-5.4), without quotes <civodul>that said, i doubt it'll fix the unresolved symbol issue you mentioned <civodul>IWBN if you could report the issue by emailing bug-guix@gnu.org with your OS config and the output of "guix describe" <civodul>apteryx: thumbs up for addressing all these issues! <kiwi_guixer>rekado_ wrote older kernel fixed the issue and Guix System worked for me too before pull <rekado_>kiwi_guixer: I may be wrong. Could be that itâs just the combination of older kernel and older packages (including xorg-server) that fixed it for me. ***rekado_ is now known as rekado
<kiwi_guixer>Ah so it is a symbol and Guix suggest importing (use-modules (gnu packages linux)) Nice <kiwi_guixer>I will try to downgrade xorg too if lower kernel is not enough <kiwi_guixer>Then Mesa, I hope downgrading is as easy as downgrading kernel <apteryx>civodul: will check a bit later :-) I'm still busy fixing the collaterals of Python 3.9.1 on core-updates. <kiwi_guixer>I am already thankful because now I know its not gdm. Tough pulling and seeing dead system sucks, fortunately thanks to Guix I could boot into a working revision yey <kiwi_guixer>That warning about debugfs match-error is supr confusing to new users <kiwi_guixer>Ok time to reboot, wish me luck. Thank you for excellent suggestions. Cheers <davidl>janneke: thx for fixing the childhurd! <civodul>i got "TLS error in procedure 'handshake': An unexpected TLS packet was received" from the substituter while talking to ci.guix <civodul>i wonder if it's a problem on that network or if it's on our side <civodul>but i don't see anything in the nginx logs on berlin <civodul>is anyone else experiencing this today? <kiwi_guixer>Ok, downgrading xorg looks super advance, is there a way to set a previous working revision as default boot? <rekado>kiwi_guixer: you can delete the broken system generation <civodul>or run "guix system roll-back" if you know the previous one was ok <kiwi_guixer>From boot menu or by some guix system reconfigure invocation? <kiwi_guixer>Can I take a working commit and reconfigure to it? Does guix system reconfigure take revisions? <kiwi_guixer>I knew I should take btrfs snapshot that way I could easily revert to a working system. <kiwi_guixer>I already generated dozen of broken generations but manual of giox system does not say how to roolback to a specific generation <rekado>kiwi_guixer: you can use âguix time-machineâ to go to any commit you want <rekado>and then pass the reconfigure command to it. <kiwi_guixer>Can I guix pull --commit=workingrevision and then reconfigure? <rekado>but if you donât want this to be a full downgrade of your guix, then you can use âguix time-machineâ to affect only the âguix systemâ command. <kiwi_guixer>I did kostek@kos ~$ guix time-machine --commit=c03875b0361f114634caeb54935fe37a9b7b05af <kiwi_guixer>kostek@kos ~$ sudo guix system reconfigure /etc/config.scm <kiwi_guixer>That warning about debugfs match error is still there but I did not have it in my working generation <rekado>I meant: âsudo su -â, then âguix time-machine --commit=⌠-- system reconfigure /etc/config.scm <rekado>âguix time-machineâ has no side effect <rekado>it affects only the command it is told to run <kiwi_guixer>Root now updates channel Authenticating channel 'guix', commits 9edb3f6 to c03875b (11âŻ553 new commits) <kiwi_guixer>Ok downgrade should fix the issue, I will wait with pull another 6 months. <kiwi_guixer>BTW it is depressing that libre laptops now will stat get regressions, I assume you work on modern less libre laptops if that regression is barely known. <rekado>my laptop doesnât have an ATI card <kiwi_guixer>But guix system describe shows GNU with Linux-Libre 5.10.7 <kiwi_guixer>I noticed because I time machined into recent broken guix <kiwi_guixer>How to show guix system describe *currently* run/loaded system? <kiwi_guixer>Is that by design? To show guix system describe from not currently booted generation? <civodul>kiwi_guixer: ah good point, it shows the "current" generation, but that's not necessarily the booted generation <kiwi_guixer>I thought it shows what I run. That's not clear from man page. <kiwi_guixer>This time guix asked me to allow downgrades so maybe I will 'fix' default boot this time. <bavier[m]>llnl peeps not really sure if they want to join :) <kiwi_guixer>Folks I am lost. Is there a way to set /var/guix/profiles/system-1-link as default boot? <kiwi_guixer>I know that generation works and time machine doesnt work for me, I also cannot find, for sure, the revision of that system profile, because guix describe shows only latest revisions. <kiwi_guixer>Maybe I remove all other symlinks and garbage collect, then if gc regenerates boot entry that should only leave one working generations. *bavier[m] hasn't followed the conversation closely <kiwi_guixer>guix system list-generations shows commits too. Maybe that could put time machine on track <kiwi_guixer>Then I will try to bisect which bump broke Guix System here <zimoun>civodul: draft for hint when command-line options typo in #45893 :-) <civodul>i'll take a look hopefully later today ***fever is now known as Guest31059
<Guest31059>I'm struggling to write a config.scm for SDDM that uses my xorg config, when I try and put xorg-configuration into sddm-configuration it throws "error: service 'xorg-server' provided more than once" <jonsger>Guest31059: I think you need to remove the gdm service <Guest31059>Ah thanks, I tried doing that but it's possible I messed up there. Let me send a snippet. <Guest31059> (service sddm-service-type (sddm-configuration (auto-login-user "fever"))) <Guest31059> (set-xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout))) <cbaines>does anyone know how to generate a client certificate to access Zabbix on berlin? <civodul>cbaines: i just use "ssh -L" to set up a tunnel and connect that way :-) <cbaines>civodul, are you sidestepping NGinx when doing that? Given it looks like NGinx is providing the Zabbix frontend, I'm not sure if the need for a client certificate can be avoided through SSH <civodul>cbaines: hmm i was thinking of the Cuirass admin interface, but i guess that should also work here? <cbaines>civodul, unless I've missed that Zabbix is available not through Nginx, I think you still need a certificate <mzbm>hello everyone, i'm trying to switcht my workflow to free (as in freedom ;)) software. I'm used to using jetbrains intellij but thats obviously proprietary. What is a good IDE that comes close to IntelliJ? Is the majority here using emacs? <cbaines>mzbm, are you looking specifically for something to use for working on Guix? <mzbm>no, more in the direction of go programming <cbaines>I'd try asking on #go-nuts perhaps then, I think that's a more relevant channel <mzbm>ok, sorry if this was the wrong channel here.. <Aurora_v_kosmose>mzbm: Pretty much any editor which supports LSP is a valid candidate these days. <Aurora_v_kosmose>Language-specific support is less of a priority than it was a decade ago. <Aurora_v_kosmose>Ah yes, there's a few service frontends like that. Such as Nitter for twitter. <jgart[m]>I tried nitter a few days ago. It's nice too. <mroh>jgart: imho, invidious is a big burden to support, because it needs to be updated very frequently to function (often every few days, because yt changes something...) Also, it's written in crystal which we don't have (yet)... <jgart[m]>If only we had a guile, racket, common lisp, or/and chicken port of invidious... :) We still need a racket-build-system. <Sharlatan>It's tricky to pack pgloader it has all build wizardy inside Makefile depending on Quicklisp and Buildapp :) <Sharlatan>I've packed all dependencies now time for the main app... <roptat>yeah, unless they're different packages with the same name? <roptat>looks like the same. Do you want to close it yourself? <apteryx>when a build produces many wheels; are they supposed to all be installed? <apteryx>luis-felipe: it should! I think I made a review for MyPaint, there were still things to address but the conversation came to a halt IIRC. <lfam>luis-felipe: I'm enjoying my Guix apparel :) *roptat is learning more English words ^^' <roptat>what's the difference between apparel and clothing? <lfam>roptat: Same thing, but saying "I'm enjoying my Guix clothing" is not idiomatic <roptat>I see, I'll try to remember it :) <lfam>Instead, you might say "I'm enjoying my Guix shirts", if you didn't say apparel <lfam>I consider it "European English" ;) <lfam>It's so great to have beautiful and eye-catching graphics for Guix <cbaines>I was trying to remember if I ordered one, then I remembered it's literally hanging in my cupboard! <PotentialUser-38>Hi and thanks for gnu guix. The only available first language of Libreoffice in preferences is US English. It is not possible to add another one. What's will I have do to getting it localized? Thanks in advance <roptat>PotentialUser-38, you can speak any other language here too (although less people might be able to help) <roptat>but your English is pretty good :) <roptat>PotentialUser-38, I think you need to install a language pack, as an addon <roptat>I don't think they're packaged as part of guix <PotentialUser-38>Yeah, I didn't detect anything like locales in the gnu guix package list. <Aurora_v_kosmose>There's nothing strictly preventing them from being made as "multiple outputs" for those packages, but it hasn't been done so far. <jonsger>does ci.guix.gnu.org already provide zstd substitutes? <roptat>PotentialUser-38, tools -> extension manager <roptat>there's a link "get more extensions online" <roptat>PotentialUser-38, actually, looking for French for instance, I don't find anything interesting there <civodul>jonsger: nope! i'm not sure what to do <civodul>for the time being, we'd have to do zstd in addition to gzip + lzip <civodul>which is going to be quite resource-intensive for the server <civodul>plus, few users support zstd, and those who do for now would still fetch lzip most of the time <civodul>because currently the only criterion is size <roptat>so languages are added at build-time only, so there's nothing a user can do if we only include English :/ <civodul>then i "ran out of time" and forgot about it <civodul>so there's still some work to be done, but i think i had gone quite far already <civodul>if you or anyone wants to start from that, feel free! <rekado>I always associated apparel with clothing thatâs sold in stores. <lfam>That's a good observation rekado. I wouldn't usually call the clothes in my closet "apparel" <rekado>where the commercial part is worth mention <lfam>It does have a commercial connotation <PotentialUser-38>Thank you all, I'll just hold out with Epiphany and Ungoogled Chromium. Fortunately Abiword is available located but Gnu Icecat is also limited to US English. *vagrantc is in the awkward position of wearing a guix t-shirt under a guix hoodie and not having run guix once this entire year <vagrantc>don't know if i'll get the chance to try building guix 1.2 with guile-2.2 on debian to actually get it into the next release... <vagrantc>only have a couple more weeks to even consider it <zimoun>vagrantc: by entire year, you mean fifteen days? Because on Julian calendar, today it is the Janurary, 2nd 2021 ;-) <vagrantc>though in my heart, the year begins at solstice :) <lfam>So, since the staging branch has gotten bogged down in CI problems, the ungrafting branch has also stalled <lfam>Should we re-try the ungrafting branch separately, so that we can merge it soon? Does it matter? <jeko>A reader of the Guile Hacker Handbook told me there is a default .guile on Guix System. Is it also created when installing Guile on foreign distro ? <lfam>I don't have that file on my Guix / Debian system <lfam>Or rather, I don't have one from Guix <zimoun>I created this file by hand after installing Guile. <jeko>on my guix system i have it ! <cbaines>lfam, I guess if merging branches is dependent on good substitute availability on ci.guix.gnu.org, that'll require waiting until that's the case <lfam>cbaines: True, but I don't think it's a matter of waiting, at least for the staging branch. The staging branch requires actual work, whereas the ungrafting branch should not <lfam>It seems like we should cancel this round of staging <lfam>It doesn't seem like people are interesting in working on it <jeko>Thanks for your feedback lfam and zimoun <lfam>But, we should skip ungrafting just because staging won't happen <lfam>I mean, we shouldn't skip ungrafting <lfam>I might also do an alsa-lib updates branch, since that fixes a serious bug <lfam>We can extract the new commits from the existing staging branch and cherry-pick them to a new branch, and set it aside for a few months <lfam>Right, and it's really useful to see, but it has build on ci.guix.gnu.org in order to count as "ready", since that is where people get substitutes <lfam>We also need to decide what to do about niche / obsolete platforms like i686 and armhf, since they are in poor shape and are not getting much attention from Guix hackers <cbaines>I realise that, I'm more referring to the ungrafing branch not requiring work theory <cbaines>In principle, removing grafts can introduce build changes, and cause build failures <lfam>Yes, and now that I think about it, I remember there being new failures on ungrafting <lfam>Most SBCs in the last few years are aarch64 <lfam>There is still a lot of 32-bit ARM hardware being produced but it will not be for products that can be used with Guix. For example, automotive embedded systems or locked-down TV boxes <cbaines>anyway, I'm still pretty excited about the future of QA and substitute distribution stuff, I still have quite a few exciting ideas <cbaines>on that note, I'm going to go back to hacking on the Guix Build Coordinator :) <lfam>Aurora_v_kosmose: The previous beagle device (X-15) is the probably the only 32-bit ARM SBC worth using with Guix, but it's a poor value compared to aarch64, unless you need 32-bit for some reason <lfam>I think they are creating the hardware to drive software development <lfam>If you want one, you have to explain what software you will develop on it <vagrantc>there is a semi-official port of debian for riscv64, and i believe similar for fedora, and at least one of the embedded distros supports riscv <jgart[m]><nij "jgart: That's usually how you se"> nij: This is what I'm using to jump to other code in a given source tree <lfam>cbaines: Your worse on QA / CI is the future of Guix :) <vagrantc>beagleboard.org hasn' *moved* to risc-v, it's also supporting a new risc-v board <lfam>Okay, but are they going to keep creating new 32-bit ARM boards? It seems unlikely <nij>I have a working guile. While module should I load in for it to understand <vagrantc>lfam: they might ... they might start doing some 64-bit arm as well <lfam>What is the use case for 32-bit ARM now? When you can pay a fraction of the price for more capable 64-bit ARM <lfam>Anyways, I also ranted about this on the mailing list <lfam>We are supporting these platforms but I can't perceive that anybody is using them <jgart[m]>nij: I'm just sharing how I integrate ripgrep into my editor to do recursive searching in a source tree. Continued from yesterday's convo <lfam>(armhf and i686, that is) <nij>jgart[m]: Oh oh! Thanks :D <Aurora_v_kosmose>lfam: Presumably systems you can't replace easily due to widescale deployment. <lfam>At least, if people are not going to help maintain the support, they should let us know they are using it <lfam>Aurora_v_kosmose: Right, but what does that have to do with Guix? <vagrantc>i wonder if something like debian's popularity-contest package would work for guix? opt-in reporting about what you have installed, etc. <Aurora_v_kosmose>lfam: Well, in this case Guix is probably too young for it to have yet been used in such a way, but I can't certify that. <roptat>it's painful not to have substitutes :/ <lfam>I agree Aurora_v_kosmose. But I don't think we will gain users on armhf in the future. Guix is just a poor fit for these devices, which lack CPU power or fast and reliable storage <Aurora_v_kosmose>I used to build on a qemu VM for my stuff. The board I had died though so I retired it. <lfam>armhf embedded deployments will likely never get software updates and, if they do, they will be ultra-optimized binary diffs, in order to extend the storage lifetime <vagrantc>i had hopes i could get guix running reliably on my veyron-speedy ... but it's never been reliable enough ... really quite close, though <lfam>What was unreliable about it vagrantc? <lfam>roptat: I can imagine it's very painful! <vagrantc>lfam: never managed to get a linux-libre kernel newer than 5.5 working on it <roptat>running "guix pull" for days... fun ^^ <lfam>And there's no 32-bit ARM server that we can use to build the substitutes <nij>I pulled the guix repo from savannah. <nij>Add it to the load path. <nij>But (use-modules (guix channels)) doesn't work. <lfam>Yes, emulation is an option. But it means that the build farm will spend most of its time doing that <srk>emulation is possible but too slow, armv7 on aarch64 virtualization is possible as well but there are corner cases where it fails <nij>What's the difference?!?! <roptat>guix repl launches guile with its modules available in its load path <srk>there's tons of armv7 hw out there, NixOS has similar issues supporting it <lfam>Anyways, there needs to be a critical mass of people-power to support these platforms, so that they are usable. It's a question of the chicken and the egg <roptat>sorry, it launches guile with guix's load path <roptat>guix's modules in guile's load path <srk>is cross-compilation to armv7 and similar viable with guix? <roptat>so you should be able to ",use (guix channels)" in there <nij>roptat: so I don't have to pull codes from savannah? <roptat>it'll use the pre-compiled modules from guix <nij>roptat: You won't believe me that I have wasted 8hrs on this issue yesterday. <nij>any chance for me to check the current load-path? <roptat>lfam, do you know of a good hardware we could use as part of the build farm? I'm seriously considering buying something to help the build farm <lfam>I don't think we plan to drop it (I'm the only person suggesting that). <lfam>I would research the BeagleBoard X-15 (we already have a couple). I think it's the only hardware available for retail purchase with what counts as high-performance armv7 CPUs and reasonable storage (eSATA) <lfam>There could be some other devices available â I haven't searched exhaustively <srk>I'm running armv7l Novena laptop (was running previously as part of build farm as well), odroid-xu4 is decent but no SATA <srk>there were some bananaPIs that had SATA but limited to like 10Mb/s due to (USB?) controller used, way faster to use ethernet and nbd/nfs <lfam>The Novena uses Cortex-A9, but at this time I would only consider Cortex-A15 or Cortex-A17 <srk>yeah, imx6q is little dated <lfam>We have (had?) some Novenas in the build farm. They were good for their time but are not really fast enough to be worth the high price anymore <rekado>looks like the Overdrive is no longer sold any more. Otherwise we may have bought more. <lfam>Sharlatan: We have an asdf-build-system. Maybe you could try that? <lfam>rekado: For 64-bit there is the Honeycomb LX2K, which is sold at retail and has a good reputation. I don't know if it requires any nonfree firmware or anything like that <srk>lfam: nice, I think it (Novena) reached EOL last year, still not fully supported by Linux :) <srk>LX2K does require binary blobs (at least for memory controller iirc0 <lfam>It would be good to have a citation, since it is by far the best and only option available for purchase <srk>don't take my word for granted, I've only played with it for few weeks like a year ago <lfam>I feel like we shoot ourselves in the foot if we avoid hardware because the DDR PHY firmware is not free <lfam>Is it a case where the "good option" doesn't even use firmware but instead a ROM? <lfam>My impression is that DDR firmware is always closed source and a trade secret <nij>roptat: What if one day I want to contribute to the source repo? <roptat>nij, you'll need the checkout, and to build it <nij>Do I at least need to learn autotools for that? as the code directly pulled from savannah isn't complete. <roptat>nij, there's a section in the documentation, basically, run "./bootstrap" then "./configure --localstatedir=/var" and "make" <srk>lfam: anyway, you would hit issues when building in armv7 qemu on aarch64 <Aurora_v_kosmose>lfam: Right. It puts an annoying reverse-engineering burdne on support. But mostly meant ROM vs firmware? <lfam>Aurora_v_kosmose: The GNU stance is that ROM is not software, because it cannot be updated, so it doesn't matter if it has a free license or not. Whereas upgradeable firmware must be free <lfam>So, a memory controller based on non-upgradeable firmware is okay, whereas the upgradeable option is considered bad <Aurora_v_kosmose>Isn't the difference only the existence of in-place runtime binary patching infrastructure? <lfam>I don't quite understand your question <Aurora_v_kosmose>The difference between upgradable firmware and a ROM is simply that you don't have to reflash it manually to upgrade it with firmware, no? <nij>roptat: I got stuck while configuring. It requires "Guile-Git". <lfam>That is a difference, yes. I don't see the significance of it <roptat>nij, oh, you can build in an environment: guix environment guix <roptat>that will give you all the dependencies you need <lfam>It's not a matter of effort <roptat>from a foreign distro, add --pure <lfam>But rather of possibility <roptat>(for the configure stage, then drop the --pure) <lfam>If the firmware can be upgraded or changed, then GNU wants it to be freely licensed. If it is "baked in" at the factory and cannot be changed, that is considered okay <Sharlatan>@lfam I could not find how to pass some lisp code to ASDF buld, there is #:lisp keyword but it's not docuemnted. <lfam>A line has to be drawn somewhere. Personally I think it's a mistake <lfam>I think it's based on ignorance of how computers are designed and created, and how these parts (PHYs) work <Sharlatan>Curtly patchin Makfile to exclude push (pwd) pard couse it's failing on bulid stage, tehre is an option to have binary by loading 'buildapp::build-buildapp' <lfam>It's also the reason that we can't ship CPU microcode <lfam>But, GNU is about software, not hardware. So it's the way it is <joshuaBPMan>lfam: I totally agree that free software requires no proprietary software... <nij>roptat: It is running T_T Wish you were here yesterday. <lfam>I think there is a lack of understanding of how much software is running in a computer. It seems like every part has its own CPU and its own OS, and they are all totally closed. This is considered okay, but if it's possible to upgrade one of those OSs, that is considered to be going too far... <joshuaBPMan>however, I run a T400, and without the updated CPU microcode, my laptop just craps out on me once a week. Typically under heavy load. <joshuaBPMan>Leah Rowe started chatting to me and told me that the problem was that I was not using the updated microcide. <Aurora_v_kosmose>lfam: Yeah. It seems weird that the existence of a write fuse is sufficient to make a difference. <lfam>Of course, the CPUs are full of bugs that must be fixed in microcode <joshuaBPMan>I then found out that libreboot.org uses librebooted machines with the updated microscode. Essentially, you don't want your web server crashing under heavy load. <lfam>Aurora_v_kosmose: The problem seems intractable, and GNU had to choose a line, in order to be able to make judgements. I think the placement of this line may have become less good over time <lfam>joshuaBPMan: Right, many of us exercise freedom zero (the freedom to use the software as we see fit) to use things without a free license <Aurora_v_kosmose>Personally I'd have drawn it at the component's ability to interfere with others' software. <lfam>I think the presentation "Impedance Matching Expectations Between RISC-V and the Open Hardware Community" by Bunnie Huang (Novena designer) is a good exploration of the problems <lfam>And of how far we have to go <lfam>I guess I feel that the free software movement seems to think that we have free implementations of everything we need, so that it's reasonable to only use free software and free firmware. But I think we are still quite far from the goal <lfam>I think that by ignoring what is missing we are actually slowing down our progress <joshuaBPMan>lfam: I'm aware of SSDs having proprietary code running...what else it there? <lfam>Almost every bit of hardware has a little operating system at this point <lfam>"Computers" are really made of many different computers <lfam>The CPU is really just another component <lfam>The talk by Bunnie is really good :) I recommend it for everyone <Aurora_v_kosmose>A GPU is a full secondary computer capable of DMA. With better specs than my early computers to boot. With a buggy IOMMU, it could basically take the machine over. <Rovanion>When I do a `guix environment --pure` backspace stops removing characters in my bash prompt/readline. Which package do I need in order to get it working again? <rekado>â--pureâ unsets environment variables, so perhaps you need to restore the TERM variable. <nij>On machines of different types (eg i686, x86_64), can I expect the binaries are built exactly the same, meaning that they have the same sequence of 0 and 1s? <rekado>nij: binaries for different architectures will not be identical <rekado>re firmware: FWIW, I only cared about being able to use Linux libre when picking the servers for the build farm. You canât get the purchasing department to buy old servers. <nij>lfam: I'm just curious about what "reproducible" really means in this context. <nij>rekado: But for same architectures, will they be identical? <nij>Aurora_v_kosmose: so do guix volunteers have to package one for each architecture ? <rekado>Aurora_v_kosmose: research institutes and organizations like them arenât really concerned with cost as long as it fits in the budget and doesnât steal resources from other things that need to fit in the budget. <Aurora_v_kosmose>nij: Not usually no, Guix checks the checksums of inputs, but for outputs, you can challenge or do multiple build runs and find differences. <rekado>a budget that isnât maxed out will be adjusted to fit the reduced demand <Aurora_v_kosmose>For those packages which build reproducibly, a challenge will find an indentical package after building it. <rekado>so thereâs an incentive to spend <Aurora_v_kosmose>It essentially incentivizes bloating costs as much as possible just in case. <Sharlatan>How to get the abs path to the source during the build phase? <lfam>On the other hand, using old hardware will result in lower performance. It's worth it to buy new <lfam>Plus, you will waste money on salaries dealing with broken things in the old hardware <Aurora_v_kosmose>Sometimes yeah. Though a 20x as expensive machine won't necessarily (or usually) perform 20x as well. <Aurora_v_kosmose>(Which is usually the difference between the very same machine new & used) <lfam>The time spent acquiring dozens of identical old hardware is not worth the money saved, especially since you won't get a support contract for it <lfam>I buy used computers for personal use, but for a high-performance computing clusters, you have to buy new <lfam>I work in a different industry that also is technology-focused, and nobody buys used equipment. It's always more cost-effective to buy new and negotiate a volume discount <Sharlatan>While patching Makefile before build phase I need to provide full path to asd file, which symbol holds the abs path to the current source? <lfam>But I buy my personal equipment used on ebay :) <rekado>Aurora_v_kosmose: yes, budgeting in institutes is ⌠weird. In some years people had to justify their department budgets and felt compelled to order an office load of books. <rekado>budgets are inflexible, so you get punished for being frugal <Aurora_v_kosmose>I wonder if the management overhead would be justified by possible savings if budgets were made flexible instead. Or if it'd simply fail to work out. <rekado>Aurora_v_kosmose: budgets rarely have just *one* source, so making them flexible would involve a *lot* of work with an unmanageably large number of parties. Itâs one of those things that probably cannot be fixed as long as we all behave like humans. *rekado stops talking about budgets