<PotentialUser-52>ah, that's a good tip, thank you, i suppose with guix there isn't much risk in re-configuring since you can always load the previous configuration, unless you screw up the bootloader or disk encryption =P <mbakke>that's true, and partly why I'm excited to move my dotfiles into the Guix configuration system (work in progress) :-) <mbakke>also, using gexps in arbitrary configuration files opens so many possibilities <genr8_>but the guix-install.sh script HAS the code for it. just the file is non-existent <rekado>lle-bout: might be as simple as loading (guix gexp) <rekado>genr8_: re mirrors: they are defined in guix/download.scm <mbakke>PotentialUser-52: instead of using the %sway-login-shell (which is somewhat insane), you can also add '[[ -z "$DISPLAY" && "$(tty)" = "/dev/tty2" ]] && exec sway' or similar to your ~/.bash_profile :P <mbakke>it's funny that Guix has no facilities for adding a system-wide bashrc script...unlike pretty much any other Unix system. I considered adding one, but changing my login shell to a Guile script was much more satisfying. <lle-bout>can someone merge master into staging so my key is in '.guix-authorizations'? <genr8_>rekado, seems very low-level, what do I have to do after I modify that ? <mbakke>lle-bout: I'll give it a shot (but may bail if there are many conflicts, have not paid attention recently) <mbakke>lle-bout: wew, there are some difficult conflicts in there which will take more time than I have tonight :-/ <mbakke>perhaps cherry-picking the key will do? <genr8_>ok its working. that was worth it <lle-bout>sneek later tell lfam another QEMU CVE-2021-3392 <lle-bout>sneek later tell lfam incomplete patch resulting to another QEMU CVE-2021-3409 <genr8_>you will end up needing a whole person just for qemu patches :p <lle-bout>genr8_: QEMU upstream is terrible at delivering security fixes <nallastro>i know it's not a nice question but, how do I delete the store? <nallastro>I can't seem to be able to delete anything, even as a root <nallastro>I tried chown -R root:root , chmod -R 777 and even restorecon -Rv <nallastro>nothing I tried gave me enough permissions to delete the contents of the store <madage>sneek: later tell luis-felipe I've also been having issues with pulse audio since some days back.. eating ram, hanging and muting sound if I plug/unplug headphones. Not every single time I did tho and I also couldn't debug it until now.. ***PotentialUser-52 is now known as constfun
<apteryx>zimoun: fun, I was looking at them right now :-) <zimoun>apteryx: is «maxim@hurd ~/src/guix [env]$» really on Hurd? <Whyvn>does anyone use shepherd to manage their emacs daemon? I am trying to create a shepherd service but the service never seems to start. This is the scheme declaration I have http://paste.debian.net/1190745/ <cdegroot>nallastro: there's usually a sort of overlay read only mount for the store. `umount /gnu/store` and then you should be able to remove it. But please don't. You'll miss it ;-) <genr8_>I inserted a mirror with a broken HTTPS certificate (domain name mismatch), and "guix pull" just connects grabs the archives regardless, no warning <genr8_>I also believe i've uncovered the root cause of all my problems. guix-binary-1.2.0.x86_64-linux.tar.xz version 1.2.0 stable (November 23rd,2020) contains a /var/guix/profiles/per-user/root/ "current-guix" whereas the LATEST binary contains a "guix-profile" link instead <apteryx>raghavgururajan: I think your commits are a bit too micro on the linphone series; that makes the review a bit more tedious than it could be. It's usually OK to combine changes such as enabling tests and enabling optional features in the same commit if they touch the same package. <lfam>genr8_: Can you clarify what kind of mirror you are talking about? <sneek>lfam, lle-bout says: another QEMU CVE-2021-3392 <sneek>lfam, lle-bout says: incomplete patch resulting to another QEMU CVE-2021-3409 <genr8_>the ones in guix/download.scm , i changed ftp.gnu.org to a faster one. but in doing so, i entered a domain name that redirected and didnt match the certificate. yet it did not complain <lfam>That's expected, and okay <lfam>When we are using those URLs, we already know what we are expecting to receive, based on SHA256 hashing. They are used for downloaded package sources <lfam>When doing this, we say we are building things that have a "fixed output" <lfam>If the data received doesn't match the hash, it is discarded <lfam>So, it's a case where HTTPS issues are not relevant for data integrity, barring bugs in our code that handles the input data and computes the hash <lfam>And, by ignoring X.509 validation errors, the reliability of the mirrors increases, from our point of view <lfam>If you think we are missing something here, please let us know! <genr8_>unfortunately, by modifying that file, now i get an annoying message everytime I pull saying the hash doesnt match, and 'gc verify=repair' constantly wants to undo what i changed <lfam>Hm, which file did you modify? <genr8_>since i modified the internal file. guix/download.scm <genr8_> /gnu/store/6rn4l3h0p9x0m615pp1ynlv9v0743kl3-guix-1.2.0/share/guile/site/3.0/guix/download.scm <lfam>You must never alter anything in /gnu/store except by using the Guix tools <genr8_>i thought that was bad but someone told me to do it, and it worked. how else can I add mirrors to there <lfam>On Guix System, it's impossible <lfam>I mean, on Guix System it's impossible to alter things in /gnu/store <genr8_>then we are missing something :) <lfam>I haven't considered how to add more upstream mirrors for sources <lfam>It will be placed into /gnu/store and registered. Assuming the hash matches what Guix expects, the local file will be used <lfam>Usually, people would download substitutes of these files <lfam>The GNU web infrastructure can indeed be slow <genr8_>well, it was undergoing a long automatic sequence of "pull" upgrade & downloads . and I am constantly starting over and nuking my install because i am still dealing with broken-ness in regards to building with no substitutes <lfam>I have long wanted to randomize the order that Guix tries the URLs in guix/download.scm, but it's not trivial <lfam>It's definitely a long road to build the distro from scratch <lfam>It's not possible to do at all, even not that far back, at least without some hacks <lfam>Sources go offline, upstreams change the sources, upstream bugs break compilation after certain dates, etc <lfam>We are working to develop long-term archives of sources <lfam>Well, that effort is outside of Guix, but a close relative :) <lfam>So, in this case, the problem is that downloading things is slow? <lfam>I'm curious, how slow is slow? <genr8_>yes, it can go easily 50-70MB/s from the other ones <genr8_>i would prefer to build my own repo <genr8_>i am wasting a lot of re-downloads in my failed build endeavors <lfam>Guix shouldn't ever re-download something that it already has <lfam>Can you clarify what you mean? <genr8_>right. but i keep nuking the install and using a new disk and new VM <lfam>It's like going to doctor and saying, "It hurts when I do this..." <lfam>Can you give an example of which mirrors are faster? <lfam>Maybe we can re-order the list <lfam>It wouldn't help you until you complete your installation, but it could help other people in the future <genr8_>it only lists the main gnu.org, berlin and finland right now <lfam>Oh, I thought the main GNU site is the final one <lfam>For me, the ftpmirror redirects to the constant.com mirror <lfam>Where does it redirect for you? <lfam>Well, the redirection changes each time I reload <genr8_>yea its not actually auto-detecting the fastest <lfam>I figured it would do some geo-location to pick something close to you, and that all of the mirror members would be fast <lfam>For me, it seems to pick things that are nearby <genr8_>i am in NJ and i am coming out of a NY exit node <lfam>I think it's another case for the doctor :) <lfam>I'd bet the mirror's "nearness" calculator is broken by that <genr8_>no, i think this is gnu's mirror detection fault, the VPN should not have a bearing <lfam>Yes, but not serving traffic from people in NY. Depending on how the "nearness" algorithm works, it could know that and act accordingly. That is, randomly <genr8_>i dont think it can work like that <lfam>We'd have to figure out exactly what the ftpmirror.gnu.org is doing, but it should be expected that any kind of geolocation effort will go haywire when using a VPN <lfam>It can, and many network operators will treat traffic that is known to be from a VPN in special ways <genr8_>thats not how this VPN works. the geolocation is chosen by which server you pick. thats why people choose different locations to watch different regions netflix content <lfam>I didn't read it yet, but this appears to be about how it is set up <lfam>It could be... wildly out of date. I don't know <genr8_>i wonder if the IP used to be in like the EU or something and they re-assigned it to NY... <lfam>It's a big problem with VPNs <genr8_>i dont think its a good geo-location module though. "whatismyip.com" detects it as NY <lfam>It's probably just out of date <genr8_>The geo location data is updated monthly via download0:/etc/cron.d/maxmind, stored in download0:/usr/local/share/GeoIP. <genr8_>hmm, Maxmind is usually pretty good. <genr8_>im gonna guess the VPN shuffled the IP's locations this month, MaxMind already found out, but the GNU db is <1 month behind <genr8_>lfam, so let me ask something. does the build-farm ever rebuild the core packages in guix from source AFTER the build-farm has already Okayed the initial build, and the hash has been calculated, and the substitute created. to re-check ? <genr8_>for example "gnutls" - how do we know when the last time that was built ? cause I'm rebuilding from source, and not using substitutes, and I've located 1 test inside that which fails (always). "gnutls-3.6.12/tests/status-request-revoked.c" <lfam>Right, it's quite unfortunate <lfam>It was built months ago, before the code expired <lfam>It not even the first time it's happened <lfam>Yeah. It's gonna be a few months before it gets fixed, too, at least this time <lfam>You can change your system clock to work around it, I figure <genr8_>i managed to cheat this time and get past it <lfam>I have to go afk. Good luck! <genr8_>thanks. I am doing better than before <lfam>That's what I'm here for :) <tpefreedom>substitutes are failing because of "corrupt inputs" <genr8_>can anyone explain why I need a whole linux-libre-5.4.20 kernel when using guix on a foreign distro ***regtur_ is now known as regtur
<marusich>powerpc64le-linux support is merged to master! \o/ I'm gonna go get some sleep now <mubarak>I have installed Mate Desktop on guix 1.2.0 amd64. and when I login with my username and mate desktop open a dialoge message open asking me to enter my password. I don't want to upload the screenshot to any website, so I write it down and paste it to https://paste.debian.net/1190767/ <mubarak>the question is how I can change polkit policy to allow me to increase backlight without intering my password every time i increase the light or decrease it? ***sorki is now known as srk
<rekado_>genr8_: just for the record, I did not suggest modifying the file in /gnu/store. I merely said that mirrors are defined in guix/download.scm. If you want to change the code you should work with a checkout of the git repository and use “./pre-inst-env guix” after building. <pineapples>I've read the correspondence regarding the future 1.2.1 release and I think this is a good oppurtunity to voice my opinion about the selection of packages available in the installer ISO :-) <mubarak>i tried to add backlight-helper.rules to /etc/polkit-1/rules.d/ directory, but it gives "Error writing /etc/polkit-1/rules.d/blacklight-helper.rules: Read-only file system". I used sudo nano /etc/... and sudo -i & nano /etc/... ***iyzsong- is now known as iyzsong
<mbakke>mubarak: to add custom polkit rules, you need to add them to the polkit service in Guix <mbakke>mubarak: note that if there is already a package that provides the desired rules, you can simply add it to the list in %tv-polkit-rules-service (or anything else that extends polkit-service-type) <leoprikler>hmm, it seems 2.36 should be buildable with both, but maybe we should change it to meson regardless <pineapples>As I was about to say, I, personally, would like to see git-minimal and lvm2-static included in our installator ISO. I see no reason to not include the latter, considering we already support LVM2 <pineapples>This was rather a poor timing on my part to send the above message <avalenn>I am a bit lost on the inner-workings of build-systems. What goes to (guix build) ? What goes to (guix build-system) ? <avalenn>Those are some of the questions I am asking myself at the moment. <avalenn>Is there any documentation or architecture map which could help me ? <sneek>lle-bout, you have 1 message! <brown121407>Sorry, I asked this before but I forgot the answer. Why does Guix feel the need to re-download texlive when I update after a garbage collection? It's pretty annoying to wait for a 2-3GiB download after every garbage collection. <lle-bout>brown121407: you need to register your texlive installation as gc root so it doesnt get garbage collected, you can do that by including it in a profile, otherwise it may be that something indirectly updated texlive packages that they needed to be rebuilt but I am not sure that's been the case recently, we pay attention to those and avoid them <pineapples>I certainly am not in a position to give you an answer to this, but, from my experience with Guix, I learnt to allow it to occupy as much space on the roo fs as it wants, and have it only collect garbage when there's less than, say,5 GBs of free space <lle-bout>pineapples, brown121407: I have a cron job to garbage collect when I have less than 100G of free space, otherwise I just let it grow, with store optimizations deduplication etc. it doesnt grow indefinitely. "guix gc -F 100G" to do that <pineapples>This is what I have set up on my system as well. Having transparent ZFS or Btrfs compression enabled helps a lot, too <brown121407>pineapples: thanks for the tips! I don't know much about filesystems so I always use ext4, but I'll take note to look into ZFS or Btrfs <lle-bout>nckx: hey!! :-D - do you think we can use the OSUOSL machine to add it to Cuirass CI? <lle-bout>nckx: we could choose to restrict who has root access etc. as well, I can share other machines of mine for dev <lle-bout>or I don't know.. maybe broken stale .go <pineapples>I tried to guix pull.. Now I'm getting Input/Output errors <lle-bout>nevermind make clean && make -j$(nproc) solved it <lle-bout>raghavgururajan: glib-networking fails due to gnutls ssl test failing <lle-bout>shepherd also fails on core-updates for obscure reasons *lle-bout bisects shepherd failure on core-updates <efraim>lle-bout: most likely it's the update of guile to 3.0.5. shepherd FTBFS on master also with 3.0.5 instead of 3.0.2 <lle-bout>efraim: still not finished but yes looks related to guile <lle-bout>efraim: bisect says 01f0707207741ce2a5d7509a175464799b08aea6 is the first bad commit for shepherd failures (merge of staging into core-updates) <lle-bout>efraim: FYI this shepherd bug blocks gnome upgrading work <zzappie>is it normal to import (guile services base) insinde shepherd-service start gexp? <lle-bout>efraim: FTBFS -> "Fails to build from source" OK <efraim>lle-bout: sorry, am having network issues at home <efraim>also I'm working on merging master into core-updates <mbakke>hm, my build of librsvg on core-updates is still not done after 21 hours :P <efraim>mbakke: I assume you started by building all the rusts <lle-bout>efraim: thanks! that'll be useful to me! <mbakke>efraim: indeed :) that went fine (after removing LLVM 8, because it fails with GCC 10), but rustc has been stuck on compiling librsvg_c_api for 1269 minutes :/ <lle-bout>The main bottleneck is all the rusts not being compiled in parallel <efraim>oh, if its stuck like that it might actually be stuck <efraim>if you think that's slow I'm on hour 23 of building guile-final on 32-bit powerpc <lle-bout>we have to do something that's not possible <lle-bout>why do we have to recode GNU Guile in GNU Guile to shoot ourselves in the foot performance-wise <zzappie>anyone knows is there a way to make patches available in gexp? <zzappie>I get "patch not found" error during building module-import-compiled ***stikonas_ is now known as stikonas
<Rovanion>I'm tryng to package pymilter with this package definition: http://paste.debian.net/1190811/ I've added `#:use-module (gnu packages mail)` but am getting "package `python-pymilter@1.0.4' has an invalid input: "sendmail"" when I try to build it. Any ideas why that could be? <sneek>Rovanion, you have 1 message! <zzappie>`("sendmail" ,sendmail) => `(("sendmail" ,sendmail)) <Rovanion>Ah, thank you zzappie. Coming from Clojure those extra parenthesis seem to be everywhere. <lle-bout>sendmail package is broken beyond repair <lle-bout>rekado_: maybe, does it need configuration? <lle-bout>ddclient uses sendmail to send logs to local UNIX accounts with 'sendmail -oi << MAIL_CONTENT_HERE' <Rovanion>lle-bout: Well, that sucks. Because it seems like i have to enable milter in sendmail before I build it. <Rovanion>Thought that perhaps Postfix could be an alternative, but that doesn't seem to be packaged for Guix. <Rovanion>Exim can probably replace sendmail in many cases, not sure about mine. <Rovanion>Email is hell. That is what I've learned after working with it way to much. <civodul>guixnoob: hi! the daemon seldom needs to be updated <civodul>but for instance, there was a security advisory recently and we recommend upgrading it in that case <civodul>occasionally there are also new daemon features or optimizations that only become available once you've upgraded the daemon <nckx>civodul: Haven't checked my mail yet: did you want (and not yet have) access to the OSUOSL POWER NINE machine? <civodul>nckx: it must be fun to play with but... i have enough on my plate, so i'll happily let others play with it :-) <nckx>No no no play, hard release toil. <civodul>though wait, for the release i'll need it if we include it <civodul>i can't just stick my head in the sand <nckx>lle-bout: I'm updating my (very outdated) Cuirass/GBC knowledge. (Actually: non-existent.) <civodul>so yes, i'm happy to get an account, please :-) <lle-bout>nckx: what do you mean? cuirass docs? what is gbc? <nckx>Oh, and: Good morning, Guix! <lle-bout>how would you amend an older commit with some staged changes? <nckx>lle-bout: Yes, Cuirass has changed quite a bit for the better since I last refused to install it. GBC is the Guix Build Coordinator and also new to me. <lle-bout>nckx: I think we can use guix system container to run whatever cuirass service on the OSUOSL VM <nckx>I'd commit the changes with g‘it -[p or a]m f’ and use git rebase -i to ‘f’ it at the right place in history. That's actually what I do. <lle-bout>or else, run something with the command line (simplest) <nckx>lle-bout: I'm not sure Cuirass contains well, but it's an option to consider. <lle-bout>civodul: not yet, but what can we do here? graft? core-updates? staging? master directly? <civodul>lle-bout: graft i think, provided there are no ABI compatibility issues *civodul tries "guix build nettle --with-latest=nettle" <civodul>this tool is so powerful, it's just incredible <lle-bout>civodul: oh yes refresh can't seem to respect several release branches, might be nice to say --minor or --patch <lle-bout>civodul: also maybe some way to tag packages in properties to explicitly say they are on a release branch that shouldnt change to new major versions <lle-bout>so refresh can work massively (not on specific packages) without breaking stuff <civodul>"guix environment --ad-hoc libabigail -- abidiff /gnu/store/mz5fvdfks10rmwxf29n95bp9bim6wq7g-nettle-3.5.1/lib/libnettle.so /gnu/store/k4vnk67b64afixbi71d80kn6ypg7phg3-nettle-3.7.2/lib/libnettle.so" says it won't be that easy <efraim>doh, merged rust.scm wrong, good thing I tried to build rust-1.29 before pushing the core-updates merge <lle-bout>efraim: aaa yes thanks but don't break it more than it is aa <lle-bout>the main problem I face with core-updates is that people (probably myself included) tend to push stuff to it without checking it doesnt break stuff and then not coming back to fix it, I think it's also due to inability to build everything because expensive <lle-bout>Would be nice to have a command to explicitly try to build ALL packages in GNU Guix <efraim>./pre-inst-env guix --no-grafts build $(./pre-inst-env guix package -A | cut -f1,2 --output-delimiter=@) <lle-bout>efraim: thanks! lost that one, I remember seeing it <efraim>er, I already had build in there <efraim>When I was working heavily on aarch64 support I built with --cache-failures on the daemon and built with --keep-going. Then I'd come back hours later and see what broke and if it was worth trying to fix it <i1l>hi. --map-user=uid|name, is that option available in recent Guix? Seems not, maybe i forgot how to update. <i1l>it is `unshare` of util-linux. ***civodul` is now known as civodul
<civodul>i1l: 'guix environment --container' has a '--user' option, which allows you to choose the user name <civodul>it lacks a '--uid' option, we should add it <zimoun>what is the reason to name python@3.9.2 as python-next? I expect “guix show python” to list all the versions. Similarly as “guix show gcc-toolchain” or rust, or ghc or etc. <civodul>zimoun: maybe there's bytecode is incompatible and "guix install python python-something" wouldn't work? <civodul>or worse, if you install numpy, it's probably linked against libpython.so from the other python *civodul speaks as if they knew something about Python <i1l>zimoun: it reads as "Python? next!" and means "use Rust". <zimoun>civodul: you mean to prevent users to shoot themself in their feet. Hum, I am not convinced. Well, there is an issue about finding packages and their version. “guix search python” returns too much and “guix show python” does not work. And I end with grepping in the sources. )-: <cbaines>civodul, I'm around today if you want to talk more about error handling in and around http-multiple-get <cbaines>I'm still not sure we agree on what error handling is happening where <Rovanion>Eh, how do I debug a build which doesn't fail? I want the build environment and source code of sendmail to be precise, to figure out why sendmail isn't produced in the output. <dongcarl>Rovanion: Last time I checked, you should just add a stage that fails for sure <zimoun>Rovanion: “guix build -K” I guess <zimoun>Rovanion: what dongcarl said adding “guix build -K” and you should have your stuff in /tmp/ I guess <civodul>i'll be going afk soonish but we can chat until then if you want <civodul>cbaines: it seems to me that the one caller of http-multiple-get does proper exception handling via call-with-connection-error-handling, which is enough to restart faulty connections <civodul>this is coarser than wrapping each 'read-response' call in 'catch', but "good enough" probably <cbaines>right, so currently call-with-connection-error-handling just handles not being able to establish a connection, and doesn't do any retrying <civodul>in the original commit i mentioned, with-cached-connection at the call site would retry *dongcarl just realized that debugging non-failing builds could be a package transformation option... `--fail-{before,after}=<stage>` <civodul>cbaines: perhaps what we could do is restore that behavior? or are there other aspects that make it a bad idea? <cbaines>civodul, so with-cached-connection could be used at the call site, but that's in a different module, and involving that in the (guix substitutes) module would mean it would be handling connection caching <cbaines>currently (guix substitutes) doesn't deal with any connection caching <civodul>cbaines: ah i see, but the big 'catch' block in http-multiple-get is roughly copied from with-cached-connection, no? <civodul>it's here primarily to deal with "flaky ports" due to connection caching <civodul>then how about this: we literally copy with-cached-connection in substitute.scm and use it there <civodul>that way, duplication and purpose become explicit <cbaines>although I don't think any of the error handling in http-multiple-get is specific to cached connections, those issues could happen for any connection <civodul>in theory, yes; in practice, they'd be "exceptional" <civodul>cbaines: the one that calls http-multiple-get :-) <cbaines>so the things to overcome with that approach are how to handle the connection caching, as the code in (guix substitutes) currently knows nothing about cached connections <civodul>in theory, neither http-client.scm nor (guix substitutes) deal with connection caching, right? <cbaines>civodul, exactly, in http-multiple-get it just closes bad connections, and asks for another one <cbaines>it doesn't care whether there's a cache or not <cbaines>that same approach could work in the (guix substitutes) module <civodul>cbaines: 205833b72c5517915a47a50dbe28e7024dc74e57 was essentially wrapping read-response calls in with-cached-connection, inlined, right? <civodul>IIUC, this was needed because the caller would now use call-with-connection-error-handling instead of the former with-cached-connection, meaning it wouldn't handle all the exceptions (such as bad-response, gnutls-error, etc.) <cbaines>there's a little more going on, errors when sending requests are also handled, and the retrying approach is a bit different, but essentialy yes, the error handling in with-cached-connection was copied in to http-multiple-get <cbaines>civodul, yeah, with call-with-connection-error-handling being the new approach for the error handling that used to be in open-connection-for-uri/maybe <civodul>so i guess there are two possibilities: keep this exception handling in http-multiple-get, or reinstate it at the call site <civodul>i'm in general a bit wary of "catching too much", as this can hide real issues <civodul>but if you think it's best to do it in http-multiple-get, let's do that <civodul>it'd be nice to see the performance impact of this compared to no exception handling at all in http-multiple-get <civodul>for example, by talking to a local substitute server <cbaines>I do like http-multiple-get not having to start from scratch if one of these exceptions happen <cbaines>especially as use cases like Guix weather try to make lots of requests <cbaines>I'll have a look at how the performance compares... <civodul>did you observe start-from-scratch behavior, out of curiosity? <cbaines>no, it was just something that occurred to me when reading the code <civodul>anyhow yeah, let's do roughly #47288 <mrb`>Hi, I'm trying to crosscompile ddrescue for arm: guix build --target=arm-linux-gnueabihf ddrescue <mrb`>But file called on the resulting binary tells me it's x86-64: /bin/ddrescue: ELF 64-bit LSB executable, x86-64 <mrb`>During the build I get 4 warnings: <mrb`>configure: WARNING: unrecognized option: '--enable-fast-install' <mrb`>configure: WARNING: unrecognized option: '--build=x86_64-unknown-linux-gnu' <mrb`>configure: WARNING: unrecognized option: '--host=arm-linux-gnueabihf' <mrb`>configure: WARNING: unrecognized option: '--disable-shared' <mrb`>Does that mean guix crosscompile is not compatible with ddrescue or am I doing something wrong. <mrb`>Thanks for your help. Having to use ddrescue is stressfull enough, but I don't know why guix can't crosscompile it. <civodul>mrb`: it may be that ddrescue uses a custom build system rather than an Autoconf-generated 'configure' script <civodul>and thus yeah, what Guix does for cross-compilation doesn't work here <civodul>we'd need to adjust the ddrescue package definition to handle that ***lukedashjr is now known as luke-jr
<mrb`>civodul: Thanks. ddrescue needs the crosscompiler specified in the configure script with: CXX=arm-rcm-linux-gnueabihf-g++ and guix just sets it to CXX=gcc. But I don't understand how guix sets the crosscompiler. <mrb`>And ddrescue does not use autoconf. As for as I understand. I think I have to tell gcc directly to crosscompile. Via flags somehow. <roptat>mrb`, usually it passes the options that are not recognized here: --build and --host are enough to ensure the configure script (well, autoconf generated ones at least) knows what to do <roptat>our gcc doesn't know how to crosscompile, instead I think you'd have to specify the cross-compiler somehow <mrb`>Made it work by adding CXX=arm-linux-gnueabihf-g++ as an extra configure flag. Thanks for your help. <mrb`>But I don't now how to make it more general for guix proper. I should probably file a bug or look if it's already there. <efraim>mrb`: I just patched ddrescue to cross compile correctly <mrb`>efraim: Nice, just looked up your commit. <lfam>That's expected, since it only updates the time zone database and removes some packages <cbaines>one note of caution, I'm not sure the Guix Data Service has up to date build information for that branch <cbaines>so the comparison data will be incomplete <lfam>Thanks cbaines :) I was hoping you'd chime in <lfam>I noticed that it does seem to have some information <lfam>There were some failures previously, fixed by updating the Python time zone stuff <lfam>But, I think it's all ultra-slow emulated aarch64, and I can't imagine that time zones will have an effect on anything <lfam>Or, they would have affected x86_64 too <lfam>I guess we still need to improve hardware support for aarch64 <cbaines>hmm, I'm not sure the Overdrive I have has ever been connected to ci.guix.gnu.org, it's still running, but still idle <lfam>It was connected, since the staging build cycle until recently <lfam>I would see it building things on that page <lfam>Or was it another overdrive? <cbaines>unfortunately I have been neglecting the patch/branch testing stuff lately, but I'm hoping I'll manage to work more on it soon <cbaines>I want to add a proper service for managing submitting builds for branches, so that it's self service, rather than me running a script in a screen session <cbaines>I think I can do authentication via Patchwork, which should make it not too difficult <lfam>cbaines: Would you be willing to connect your Overdrive to the ci.guix.gnu.org build farm? <cbaines>I would be OK with it being connected, I don't know how to make that happen though <cbaines>I'd also prefer if someone else takes care of that part <lfam>I could facilitate it, if you want. <lfam>Alright, I'll start the discussion on guix-sysadmin, and CC when there are concrete steps you need to take <lfam>I mean, "CC you when ..." <lfam>We should keep trying to get more / faster machines, but the Overdrives are still totally worth using <cbaines>OK, ideally it would connect in/out over IPv6, but it could use IPv4 as well if that's difficult <lfam>Okay, I will keep that in mind <cbaines>in either case, if access in via specific ports is needed, let me know and I'll set that up <lfam>I have a weird off-topic question <lfam>How do I form the possessive of your name? baines's? <cbaines>on the subject of other machines, I ordered a HoneyComb LX2 a while back, and I'm hoping that might ship soon <cbaines>In general on the subject of Arm, I've been trying to get aarch64-linux and armhf-linux substitutes on guix.cbaines.net <lfam>I've been curious if the Honeycomb's networking is supported by linux-libre, since we want build machines to run linux-libre <lfam>Even just the basic 1 gbit coppert PHY <cbaines>I've got a couple of Raspberry Pi's, one Pinebook Pro and some x86 machines with QEMU, and I seem to have caught up with aarch64-linux, but still have a way to go for armhf-linux <lfam>I really wonder about the future of armhf-linux, in terms of user demand <htsr>Hi! I can't build tidy-20091223-checkout, here's' the error <lfam>It's tricky since it is, by far, the least capable architecture for compilation <cbaines>lfam, back to the Honeycomb machine, hopefully the one I ordered will arrive eventually, and then I might be able to help answer those questions <lfam>I'm sure it will arrive eventually :) <htsr>csv [checkout aborted]: end of file from server <lfam>Since Layerscape is about super high-performance networking, my impression is that NXP has some special drivers <cbaines>you say that, but I hear things aren't great in the computer component space at the moment... anyway, positive thoughts :) <lfam>True... I figured they are in stock <lfam>And shipping within the USA, let alone across the border, is still totally fubared. I can't imagine inter-continent shipping <cbaines>lfam, I think there's something needed about gathering somewhat anonymous usage stats when serving substitutes, and I'm hoping I'll get around to looking at that at some point. Once there's data, maybe that will help making informed decisions. <lfam>True cbaines. I pushed gently for keeping these kinds of metrics, but it's not a very popular position <lfam>In any case, we are not building for armhf at all, at this point. We still have substitute for "core" packages, but eventually we will have nothing <cbaines>even with stats on substitute usage, that's not the whole picture. A Debian popcon thing for Guix might be nice to have eventually. <cbaines>I need to sort some food, but I'll be back around later... nice talking to you lfam :) <htsr>The cvs server of the package tidy-20091223 (tidy.cvs.sourceforge.net) return a 404 <lfam>I guess we'll have to adjust our package, if the CVS server is gone <civodul>lfam: re wip-next-release, great there are no new build failures! <lle-bout>lfam: it's good! working on upgrading to GNOME 40, and you? <lfam>Trying to facilitate some administrative tasks <lfam>Like, pruning long-inactive committers, improving the build farm, etc <lfam>I'm hoping that later in the day I'll have energy to review the Calibre update patches <lle-bout>I kind of promised the c-lightning guy I would be helping them but I don't feel motivated for it after all <lle-bout>I think it's more important for us if I do the GNOME upgrade <lfam>Well, it's hard to force yourself to work on things when you don't feel like it <lfam>GNOME is really important, I agree <lfam>It would be great if we had closer coordination with them. Like, if a few of their developers used Guix <lle-bout>I would really like if we could have shiny GNOME always latest in GNU Guix with first-class support and every feature working great <lfam>I like to say that "motivation is fungible" <lfam>That's definitely the goal! It was a huge amount of work to get GNOME working in Guix in the first place <lfam>I meant to write, "motivation is not fungible" <lfam>I'm terrible at communicating clearly in chat <lle-bout>I am not sure why I get motivated on things, that's what I am saying <lfam>And when you are motivated to work one thing, it doesn't mean you can take that energy and work on something else <lfam>Even if you think the other thing is more important <efraim>Was I supposed to bump gcc on core updates to 8? <lle-bout>someone said on the ML at some point they tested and no major issues arised <efraim>I couldn't remember by the time I finished the merge <lle-bout>I just rebased my local wip-gnome-40 checkout to yours <lle-bout>efraim: glibc 2.32+ and powerpc64le-linux means gcc 8 required <efraim>I wonder if we should jump to 9 or if it'd be too much work <efraim>I also wanted to poke mesa a bunch, get aarch64 the option of the llvm backend <efraim>Initial tests didn't have it erroring out in the tests <raghavgururajan>lle-bout: glib-networking might be related, will look. php fails before my patches, no idea. atkmm help, I couldn;t figure it out. <lfam>Does anyone have a sense of what comes after the release? I see people committing to both staging and core-updates, but do we really want to do another staging cycle before core-updates? <lle-bout>raghavgururajan: okay! yes php probably fails from before your patches but to actually test the changes I would need that everything builds, I am looking at solving the issues, I am attempting GNOME 40 upgrade in parallel <lle-bout>raghavgururajan: atkmm what's up there exactly? <civodul>lfam: i think we should merge core-updates soon after releasing <lle-bout>lfam: I pushed python-pygments security update to staging <lfam>Okay. Maybe we can do a security-updates cycle <lfam>For things that are "just" security updates but can't be done effectively on master <lle-bout>civodul: what do you think about a security-updates branch? for everything that can't be grafted <lfam>I'm not sure if pygments is in that category <lfam>I think that we should think about "cheating" for Python packages with dependents in the triple digits <lfam>The build farm is largely idle <lle-bout>lfam: your call, I don't want more people getting angry at what I am doing heh <lfam>We have a huge amount of spare capacity on x86_64 these days <lfam>And, basically no capacity for ARM <lfam>But, until we get more ARM hardware, I think we should keep moving <efraim>I'm looking forward to the python changes in core updates <lfam>Like, it's hard to overstate the power of the x86_64 build farm <lle-bout>I don't understand we got this much with nothing in other archs heh <lle-bout>I would be happy to donate a powerpc64le-linux VM with fast PCI-e Gen4 SSD storage, 32GB RAM and 16 threads <civodul>lle-bout: re security-updates branch, it's maybe best discussed on the mailing list, with examples of things that can't be grafted <lfam>With other arches, the problem has always been that there just wasn't any hardware worth using in a build farm. So even when we had some hardware, it didn't really work <efraim>In a few days I'll rebase my powerpc again and send the patches against core updates <lfam>The Overdrive 1000s were the first thing available that could be useful <lfam>Now, there are a few more options <nckx><it's hard to overstate the power of the x86_64 build farm> Well put :) <raghavgururajan>> lle-bout: I would really like if we could have shiny GNOME always latest in GNU Guix with first-class support and every feature working great <nckx>lle-bout: <32GB RAM and 16 threads> Out of curiosity, what percentage of your machine is that? <lle-bout>nckx: I have total 256GB of RAM, 64 threads <civodul>just so you know if it happens again <lle-bout>I have plenty of unused PCI-e 4.0 SSD storage (4x Samsung 980 Pro 2TB), which is 7000MB/s reads, 5100MB/s writes <nckx>That's a decadent amount and donating some to Guix to atone for your vanity is acceptable. <lfam>Here I am with my hyperthreading <lle-bout>nckx: I can't wait to donate it, it's what I bought it for <vldn>whats the right syntax to append a config txt file via the special-file service? *nckx was feeling pretty good about the 16GiB of RAM they managed to jam into the side openings of their X230. <lfam>Haha, similar story here <vldn>'(("/etc/blabla.cfg", (file-append ?? "/home/cfg/blabla.cfg")) ..? <lfam>vldn: file-append is used to pick files from packages <nckx>file-append appends generotes file names (file-append hello "/bin/hello), not file contents. <vldn>how to append a txt config file? <vldn>that lies in my home folder e.g. <lfam>I haven't tried it, but try making the second element of the list a string that is the path of the file? <lfam>Or, the second element of the pair <lfam>Similar to the first element <civodul>raghavgururajan: hi! could you check the bayfront config in maintenance.git, to see if the keys of the machines it offloads to are listed in the config? <nckx>raghavgururajan: Keys used to be added to /etc/guix/acl directly (statefully), now that file is generated from the system.scm. Your key was probably lost in the process. It needs to be added to system.scm and bayfront reconfigured. <civodul>raghavgururajan: check %build-node-keys in bayfront.scm *civodul has ".scm" highlighted these days, thanks to scm (hi! :-)) <lfam>I'm trying the reversion of 25db3b2f8bb4a to fix building the "devel" online manual <lfam>Am I holding it wrong? :) <civodul>lfam: how about this hack: (define guile-lib/htmlprag-fixed (if (string=? (package-version guile-lib) "0.6.1") ...)) ? <lle-bout>pkill9: secure gnu guix offloading? :-) - please post on the ML! <pkill9>so potentially we could have public build servers that build whatever people write <civodul>lfam: over even better: just duplicate (part of) the the 0.7.0 package definition in there <pkill9>and it be up to the user to use one they trust, but tbh probably wouldn't be a good idea <civodul>with a fixme indicating we'll remove it eventually <lle-bout>pkill9: yes, well public is a bit much because UNIX user accounts isnt such a great isolation mechanism but at least wider access <lfam>Thanks, I'll try it civodul <pkill9>completely public would probably not be great, because it would be a huge target <pkill9>and it would be safer just to spin up a VPS to build whatever <pkill9>but would still be good idea with trusted people <lle-bout>pkill9: I am thinking at least a machine to on which all GNU Savannah SSH public keys for GNU Guix members are authorized <lle-bout>Then if we can get more granular signing key trusting for the clients themselves, it means you can distrust the offload machine for anything you don't want to use it for <lle-bout>You can always spin up GNU Guix VMs which has CoW store with virtio-fs IIRC, so that can be used (only trust the offload machine inside there). <lle-bout>It seems lack of access to powerful build machines is one pain point for GNU Guix contributors <lfam>Yes, it has slowed me down in the past <lfam>I think it's important to offer shell access to powerful machines, when possible <lfam>A lot of us just have a laptop <cbaines>I was talking to lfam earlier about a web interface to control what things the Guix Build Coordinator running for QA stuff is building <lfam>Heh, yeah, whatever works! <lle-bout>(but offload shouldnt require two-way store signing key trusting) <lfam>Offload is definitely the Guix way <cbaines>I was thinking maybe that could also allow building arbitrary derivations <lfam>Hm, we may want to be careful with that <lfam>I guess it depends on proper access control <lfam>As long as the user is trusted, building arbitrary derivations should be fine <lle-bout>Building arbitrary derivations on a remote guix-daemon is a rather unprivileged access, no? <lfam>We just fixed that bug that allowed privilege escalation via building derivations <lfam>It's possible that it inspires more research and there are some more bugs like that <lfam>I would exercise caution for a while <lle-bout>Yes of course, with that in, I mean that the intended security model permits it to be rather unprivileged <cbaines>in some ways, I like the idea of treating the Guix Build Coordinator instance used for QA as not particularly trustworthy, as that means you can use any and all resources for the builds <lfam>The security model is that it's safe <cbaines>although that does maybe make using the build results a little awkward <lle-bout>lfam: can't we also update sqlite before the release? even if it means big rebuild? <lfam>There's two things that can take a long time when updating packages with a lot of dependents: 1) Building the packages 2) Fixing breakage <lfam>We really need to spend the next couple weeks testing things (like the installers) <lle-bout>lfam: It should be but I couldnt actually test the grafting with GNU Guix test suite, it's unnecessarily complicated to do so <lle-bout>lfam: yes right link, about easing testing grafts with package's test suites <lfam>Guix itself uses sqlite, so testing that Guix operations with building and the store will exercise sqlite <lfam>To be honest, I have a lot of things on my plate, and I don't see a concise explanation of why the Guix test suite doesn't work here <lfam>But it doesn't work to do `make check`? <lle-bout>lfam: I was trying to build the 'guix' package for that, but the graft isnt applied during the build <lle-bout>I was suggesting we have a way of applying graft before building some packages, as an option, to test grafts <lfam>But does the guix package work when grafted with this? Aside from the test suite? <lfam>Like, you could test operations that use the database, such as `guix gc` <lle-bout>lfam: I will have to try again, but it probably works fine <lfam>Is the Python thing an issue? <lle-bout>no because grafting wont re-run the test suite <lfam>Great, then we can forget about it <lfam>We'll cross that bridge when we ungraft <lle-bout>They fixed it in the 3.8.x release series also <lle-bout>We would have to move away from 3.8.2 that's it <lle-bout>lfam: alright going to retry testing with guix environment <lfam>Do you know how to use the --expression "common build option" to choose specific package variables on the command line? <lfam>For example, `guix build -e '(@@ (gnu packages sqlite) sqlite/fixed)'` <lfam>It comes in handy when dealing with grafts <lle-bout>lfam: yes I think so, but now I remember why I couldnt test this <lfam>It's not directly relevant to what we were just talking about, but it's useful <lle-bout>It's because testing requires like two different checkouts of GNU Guix <lle-bout>one to get the environment with grafted sqlite <lfam>You could just use sqlite/fixed in the Guix package itself, for testing <lle-bout>marusich, efraim: we should 'make update-guix-package' so guix pull can be run for existing powerpc64le-linux installations <lle-bout>is there any policy for updating the 'guix' package? <lfam>We do it when we need to <lle-bout>alright so can I do it now? powerpc64le-linux support needs it <lfam>Pending code review, of course <lfam>Then what is the question? <lle-bout>lfam: if I can update the 'guix' package since powerpc64le-linux support was merged <lle-bout>lfam: on powerpc64le-linux existing installations yes, I am 'guix pull'-ing them to master and it tries to build the 'guix' package which doesnt support powerpc64le-linux yet since it's not up to date so it fails <lfam>Well, yes, we'll need to update the Guix package <lfam>I'm a little disappointed that this wasn't caught during the code review process <lfam>Do you know how to do it? <lle-bout>I don't think it's an actual bug, it's just we need to do it afterwards <lfam>Please do it and test locally before pushing. I think it should be enough to `guix pull --url=/path/to/local/repo` <lfam>And then restart the daemon, etc <civodul>what happened, it doesn't show up on the web page <civodul>oh i think it was a mistake: it's been moved to drafts/ now :-) <civodul>i guess it'll disappear from p.g.o when it gets updated <lle-bout>civodul: pleasure reading it through planet.gnu.org :-P - hadnt read the draft yet, lots of useful info in the post