<leoprikler>nij: WMs are usually handled at OS config.scm level, did you add xmonad to the packages field there? <nij>leoprikler: actually I put (specifications->manifest '("xmonad" "foo")) in package.scm, and ran <nij>guix package -m ./package.scm <nij>leoprikler: not sure if xmonad comes as default wm in Guix. How would you do that if that's not the case? <nij>And I guess this is a more general problem.. <nij>I have ghc as guix packages.. I have haskell libraries.. <nij>How do I make ghc to look at the the right haskell libs? <nij>In haskell, there are package/version managers too. One of them is cabal. <nij>How to integrate such haskell devel tools within guix? <apteryx>sneek: later tell rekado civodul; ah! my url-fetch was that of (guix build download), while it shoud have been (guix download) <khassanov>Hey guys! Could you share how can I set up an automatic Wi-Fi connection for a computer without desktop services? Maybe one can give an example like a piece of config. I just learn Guix. Thanks! ***sorki is now known as srk
<lfam>khassanov: I add that to the (services) part of config.scm and reconfigure and reboot (not sure if rebooting is necessary) <lfam>The wpa_supplicant.conf is done in the normal way <lfam>I don't remember exactly but it may also require dbus-service, and I'd recommend (service ntp-service-type) and (service dhcp-client-service-type) <lfam>Let us know if you need any help! <raghavgururajan>lfam: Only with dhcp-client-service-type and wpa-suppicant-service-type? Do you know how to [1] connect specifically in 5GHz frequency [2] set custom dns server [3] spoof mac address? Thanks! <lfam>In my experience, the frequency used by a wifi network is set by the access point, not the client <lfam>Not sure about the others ***apteryx_ is now known as apteryx
<sneek>nckx was in #guix 27 days ago, saying: jackhill: ppc64 == ppc64be(-only)?. <civodul>looks like there's more people than usual on this channel, no? ***w2gz is now known as w1gz
<abcdw>what is a proper way to start user's shepherd automatically? <civodul>janneke: dunno but i think we're usually slightly below 300 and here ERC says 362 <civodul>abcdw: i do that from my ~/.xsession but i'm not sure it qualifies as a "proper way" :-) <abcdw>civodul: curios if there is a some established way to do it. In systemd "user's systemd" IIRC is not a separate process and always avaliable with systemctl --user SUBCOMAND and you don't have to care about starting user's systemd at all. Just trying to understand, when I have to run my user's shepherd :) <jlicht>abcdw: I start shepherd in my bash profile, if there is no XDG_RUNTIME_DIR/shepherd/socket yet <jlicht>seems to work well enough for my workflows :-) <civodul>abcdw: i agree it'd be nice if it were started automatically, but it's not implemented yet <abcdw>civodul: ok, I'll think what I can do about it. My current idea is to implement a Guix service, which will run shepherd for each user listed in users except %base-user-accounts. <jlicht>abcdw: so system-level-shepherd running another shepherd, as another user? <abcdw>jlicht: yep, probably something like that <civodul>abcdw: yes, the way i see it, account-service-type could extend shepherd-root-service-type with one service per account, which would spawn "shepherd-abcdw", "shepherd-jlicht", etc. <abcdw>The only question I have is: How to access users field of operating-system record? is it possible to pass OS object to extension function somehow? <civodul>definitely not, you're too much used to NixOS :-) <civodul>instead, extensions have to be declared <abcdw>civodul: I read the doc about extensions mechanism and few patches/mails about possible improvements to it. It seems some use cases is hard to implement in current version of extensions. For example I declare user-space-shepherd-service-type, which extends shepherd-root-service-type, but how to understand for which users I have to spawn new shepherds? <abcdw>I can create another service this-host-users-service-type, which will extend both user-space-shepherd and account-service with list of accounts needed in the system, but it is a little hacky, and it seem that it will "break" users field for OS record (if someone inherits from the record and would like to add new user with users field the new user won't go to user-space-shepherd). <civodul>in the option i outlined, account-service-type extends shepherd-root-service-type, because account-service-type is the one that knows about user accounts <civodul>now yes, there are things harder to achieve <civodul>but the general approach where any service can change anything in the system seems wrong to me <civodul>i think this needs to be structured, not the wild west :-) <refpga>Hello, has anybody encountered problems with sddm recently? My config broke without any changes to the config file. I get the error that 'elogind' is not provided by any service, which is required by 'xorg-server'. <efraim>when did you last reconfigure? sddm was just updated a few days ago. <refpga>It's probably been a month or two. Is there any way to see the timestamp for last reconfigure? <refpga>I did perform a guix pull before attempting to reconfigure. <refpga>Thanks. That directory is dated November 9th 2020. <mbakke>refpga: you need to add (elogind-service) to your system services <mbakke>the dependency was made explicit in 0ae9bbe4f5f89e6f597bdb1f6df646fc5f504876, I'm surprised it worked without it <refpga>Thanks mbakke. That solved the issue. <abcdw>civodul: No doubts about the structure, services approach is very nice, but I didn't understand the option you outlined. Do you mean that I should add extension to account-service-type, which will create user-space shepherds? <leoprikler>I think you'd write a system shepherd service (format #f "shepherd-~a" user), which spawns a shepherd service for that user <leoprikler>I'm not sure how exactly that would go though, since you'd have to spawn that service at user login. <leoprikler>I'm not exactly sure how systemd does this, but there's interaction with logind for sure. <efraim>You could spawn it running as that user but I'm not sure how you'd be able to interact with it as your user <leoprikler>fwiw i already have shepherd running on login through gnome autostart, so that's not really an issue <abcdw>leoprikler: Not exactly what I want. I want a user-space-shepherd-service-type, which creates a new record in shepherd-root-service-type for each user defined in account-service. And it will start on boot, not login time. <leoprikler>so you'd start everyone's shepherds regardless of whether they're logged in or not? I don't think that <abcdw>Yep, I plan to do so. Why not? <abcdw>For some systems it's undesired behavior, that's is why I try to implement it with a separate service, which can be included if necessary. <leoprikler>Well, let's assume a family PC used by three people with three separate accounts. If one of them spawned a shepherd service from their init.scm, the other ones would have that running even if that person wasn't using the PC and wasn't logged in. <Anonymous__>How can i setup a script to run during eh boot time in sheperd? <wleslie>ls /gnu/store/*binutils-2.34*/**/config.h -> no such file or directory <leoprikler>you're also adding a lot of donothing shepherds for users which won't ever even invoke herd <civodul>abcdw: yes, account-service-type would have an additional extension in its 'extensions' field, and that would be for shepherd-root-service-type <wleslie>however /gnu/store/m1z7cdbq...-binutils-2.34/include/bfd.h says "#error config.h must be included before this header" <wleslie>given that gcc built using this bfd works I must be missing something obvious <civodul>wleslie: yeah it's weird; this is for a user of libbfd outside Binutils? <abcdw>leoprikler: Seems ok to me. Maybe that person wants to have his bitcoin miner up and running all the time PC is up?) If not, do not include user-space-shepherds in your OS config. Anyway, despite the usage of such service, I more interested in implementation details of the case when service one depends on the data of service two and extends service three. <civodul>(bfd is not really meant to be used outside binutils) <rndd>abcdw: ohhhh, there are user-space services? <wleslie>it turns out that when you co-author the ELF spec, and later have to design a filesystem, evidently you just kind of C-k C-y <leoprikler>abcdw: how would you even know about this bitcoin miner tho? Those shepherds would have to run the user's init.scm, would they not? <abcdw>rndd: Depends on what you mean by user-space services) <wleslie>I have a bfd built from source outside guix, I'll see how that worked <rndd>abcdw: is there possible to run, for example nginx as user0, and it will be isolated from othe users (of cource u have to open tcp ports as admin, but i mean something like docker). <abcdw>leoprikler: Why do I need to know? I don't see a lot of difference between case, when person logged in and logged out to have shepherd runned and the case, when shephered was launched during the boot. <abcdw>rndd: You can launch a shepherd as a user, which will run everything you want. <rndd>abcdw: oh, is there an article about it? <leoprikler>abcdw: granted, there may not be "a lot", but speaking qualitatively instead of quantitatively it is still a huge difference <civodul>abcdw: nice! i'm not sure we need an accept/reject list <civodul>probably enable/disable is enough, no? <civodul>but then, make sure to exclude system accounts <civodul>what you can do is to *not* add user-shepherd-service-type to %base-services <civodul>that way it'll be auto-instantiated, unless the user explicitly added it with different options <apteryx>is it is it possible to select a test under the tests/ directory via its name rather than its file name? <apteryx>I only know the make check TESTS=tests/some-file.scm trick <apteryx>also, we have to grep the test-suite.log every run for the actual FAIL because the summary is not detailed; is this configurable? <apteryx>perhaps AM_SCM_LOG_DRIVER_FLAGS = --brief=yes <apteryx>info '(automake) Overview of Custom Test Drivers Support' also mentions the VERBOSE environment variable, to "get verbose output on testsuite failures". <apteryx>but 'make check TESTS=tests/packages.scm VERBOSE=1' still only prints a spartan summary. <maav>apteryx: I think it should be "VERBOSE=1 make check ..." if it's talking about an environment variable <maav>nvm, isn't it an issue with the scm_log_driver then? <apteryx>I have to read more; I know next to nothing about autotest and how we're currently using it. <apteryx>just that we have a custom test driver at: build-aux/test-driver.scm <leoprikler>fair enough, but in that case user-space-shepherd-services is a misnomer in my opinion <civodul>yes, should be "user-shepherd" (shepherd always runs in user space) <abcdw>civodul: Thank you for catch. For some reason I thought user-account? will return true only on non-system accs, but I see need another addtitional predicate for that. <civodul>right, user-account? is the type predicate <leoprikler>it should be lingering-user-shepherd to distinguish from normal user shepherds <leoprikler>and to allow comparison with lingering systemd sessions <leoprikler>and should probably be explicitly instantiated per user <morgansmith>hey so where is the code that installs symlinks in the user profile? I'm trying to install extra file extensions to .guix-profile/share/emacs/site-lisp <leoprikler>what exactly do you want to install into site-lisp? A normal package? <morgansmith>doing native comp stuff. so installing the .eln files. Thanks so much! <abcdw> (filter user-account? accounts+groups)) <leoprikler>If you're doing native compilation on a per-package level, nothing should change for you. <leoprikler>If you want to enable it as a hook, you'll have to look into hooks <leoprikler>That hook should then create it's own share/emacs/site-lisp, which will be union-built into the rest <leoprikler>on another note, do .eln files really belong into share and not lib? <abcdw>civodul: 3 cases: disabled; enabled and populated only with provided input; enabled and populated with provided input and account-service <morgansmith>leoprikler: nah, currently they belong in .config/emacs/eln-cache or in the emacs lib dir. that's just what comp-eln-load-path is set to. Maybe I'll give eln it's own folder then <abcdw>civodul: don't plan to add to %base-services. I heard that service will be automatically instantiated if its service-type extended by another service. Am I wrong? <leoprikler>If Emacs already says it should go into $prefix/lib/emacs/eln or anything among those lines, please try to respect that :) <maav>apteryx: VERBOSE seems to fit into what you want, as it shows the test log when it fails <leoprikler>abcdw: It sounds like you're overengineering a rather complicated solution: why not have (lingering-shepherd-configuration (users "abcdw" "jlicht" ...)) and for those given users simply check whether they exist? <abcdw>leoprikler: it's very good solution and I already thought about it, but I want to achieve following: I define OS, someone inherits from it and adds users, all non-system user gets lingering-shepherds automatically, maybe I'll implement it more explicitly, but that was my original idea. <zimoun>rekado: Hi! The commit cf289d7cfa adding extensions breaks some UI, for instance “guix foo” returns a backtrace instead of the usual “not found”. <apteryx>maav: Oh, it seems to work on a well behaved (passing) test. <apteryx>The test I'm currently working on doesn't behave well (it crashes). I'd still expect this to be handle graciously and reported. <maav>that isn't an environment variable but a make variable, you have to define VERBOSE=something before the make invocation <maav>nonetheless, it depends on the log file being created <apteryx>in my experience GNU Make treats 'make VAR=value' the same as VAR=value make; I've tested the variable to be effective on a well-haved test (works both ways). <apteryx>I think it's our custom SCM test driver that could handle exceptions better <leoprikler>abcdw: I don't think that's a good way to approach operating-system creation. You could write your service in a way, that the extender can add their own lingering shepherd services or extend lingering-shepherd-service type. <maav>apteryx: no, they aren't the same thing, the first VAR is a macro definition (think of it as placed at the end of the Makefile), the second one is an environment variable (which some standard variables take into account like CFLAGS) <maav>the first shouldn't escape make internals if it isn't used on the actual target, the latter will be available to the processes called by make too <maav>with a target calling "env" you'll see VAR on the second case but not on the first one <leoprikler>imo using the "one service per user" model you could also do it the mingetty style, and simply instantiate that service a bunch of times <leoprikler>i.e. (lingering-shepherd-service-type (lingering-shepherd-configuration (user "alice"))) (lingering-shepherd-service-type (lingering-shepherd-configuration (user "bob"))) ... <apteryx>maav I suppose that's technically true, but make macros exist in the environment of the child process that make invokes, so the result is effectively the same, unless I'm missing something. <leoprikler>then you'd merely have to write a procedure, that creates a list of such services and (append (lingering-shepherd-services "alice" bob" "carl") <other services>) <maav>apteryx: i'm checking info make, it seems that GNU make put the command line variables on the environment too <maav>so yes, the result is the same :( <maav>(unless VAR is assigned on the file, which would mean that only the first case would work) <abcdw>leoprikler: agree, looks like a good solution. I alread think for few days about using a function for OS creation instead inheritance. That's way I will be more flexible on what happens under the hood, without overengineering. <sneek>Welcome back rekado, you have 1 message! <sneek>rekado, apteryx says: civodul; ah! my url-fetch was that of (guix build download), while it shoud have been (guix download) <civodul>confusing that there are two of them <rekado>zimoun: I’ll fix this later today <abcdw>leoprikler: Probably will go for mingetty-style lingering-shepherd) Will do patch tomorrow with fresh mind. <apteryx>civodul: right, and for test1 I needed (guix build download) but for test2 (guix download), so I fell easily into the trap :-) <zimoun>rekado: I have sent a quick fix. See patch#45714. <rekado>I need to go now, but I’ll apply it later. <zimoun>rekado: Thnaks, feel free to tweak the commit message. :-) <zimoun>civodul: Hi! Giving a look at bug#45615, it seems that SWH changed something. Well, I am confused because ’visit-snapshot-url’ returns nothing and I was expecting the field ’snapshot-url’ containing a string or #f and not #<unspecified>. See (origin-visits (lookup-origin "https://github.com/Genivia/ugrep/")). What do I miss? <mdevos>The following error from ‘guix package -u’ has me puzzled somewhat: https://paste.debian.net/hidden/6da5c3d9/. gtk+2 and gtk+3 should be co-installable, right? I presume the conflict detection logic just looks at the name and version, so if the gtk+@2.* package were named gtk+2 and the gtk+@3.* were named gtk+@3.*, there wouldn't be a problem? <civodul>zimoun: i see "status: ongoing" for this one, so maybe snapshot-url will become a string once the snapshot is complete? <zimoun>civodul: the problem is: instead of a clean expected message, because of that, “guix lint -c archival” returns an ugly Backtrace <zimoun>The function swh-url fails uglily because its argument path is not a string. <zimoun>from my understanding, the define-json-mapping <visit> should return a string or #f for snapshot-url, not #<unspecified>. <civodul>could you file a bug with the backtrace and all? <civodul>because the problem will likely vanish once there's a snapshot of the repo <civodul>zimoun: could you check the raw HTML? <mdevos>nij: why did you name the module ‘(gnu packages version-control)’? <civodul>you should name it something else, like (my-packages) <civodul>here is overrode the actual (gnu packages version-control) module <mdevos>Guix already has a module (gnu packages version-control), and expects to find the git-minimal package (among others there) <nij>Don't really know why I need it :() <mdevos>that example was extracted from the source code (and somewhat modified), it's an example for defining an extra git-related package <mdevos>conventionally, packages for version control are in (gnu packages version-control) <mdevos>That's probably not the case with your package, so I suggest what civodul suggested <zimoun>civodul: you have #f with which Guix commit? <civodul>you need to make sure you have the latest packaged guile-json too <nij>(detailed error is cat-ed in the same link, with the only "failure" happens in the last line.) <zimoun>civodul: my tests are with 0d3f271 (today) and 947aed127a (first Jan.) then “guix repl”. <civodul>zimoun: ah ha! i see the problem with 0d3f271 <civodul>guix time-machine --commit=0d3f271 -- repl <civodul>zimoun: the difference is that i have guile-json 4.3.2, whereas the other one has 4.4.1 <civodul>i'd check the raw JSON and then see whether it's the new guile-json that's buggy or whether the old one had no reason to return #f in the first place <zimoun>guile-json is a good explanation. :-) <zimoun>civodul: is it possible to check the guile-json version from “guix repl”? ***sorki is now known as srk
<mdevos>nij: I presume your using the Autoools? Then they need to be added as dependencies (native-inputs). Guix can't guess what the package depends upon! <mdevos>‘./configure: No such file or directory’ ---> add autotools inputs is usually a safe bet <zimoun>civodul: with old ad2c3ba, it works. :-) So the recent guile-json seems a reasonnable culprit. I will give a look later if you do not beat me. ;-) <nij>mdevos: Thanks for your hint. I have added dependencies in propagated-inputs (just in case), but it still has the same error.. <mdevos>nij: I see you do not use the Autotools, but rather have only a Makefile. That's not really the gnu-build-system, so you'll probably need to delete some build phases (e.g. 'configure) <mdevos>It's in the guix manual: 8.4 Build Systems <nij>mdevos: THanks! I'm making progress after your hint. <nij>Now it says /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh: c99: command not found <nij>But `guix search c99` does not give anything close.. <nij>What should I do then? <nij>PotentialUser-71 I like your ID. <nij>I'm PotentialUser-72, nice to meet you. <mdevos>nij: search for ‘c99 compiler’ on a search engine. You may need to substitute c99 for gcc <mdevos>that's one of the reasons many packages use the Autotools or something similar. Autoconf would automatically try a few different names of compiler binaries, and observe which one works <nij>How to use gcc instead of c99? I've tried to put `#:configure-flags '("CC=gcc")` in arguments. <nij>It did not work @@.. <mdevos>nij: I don't know, these kind of things depend on the build system. Also, #:configure-flags won't do anything because suckless-terminal doesn't have a configure script, remember? <mdevos>search the guix source code for substitute* for some examples <nij>I haven't built a package from scratch before, so I might be missing some basics. Thanks for helping though! <nij>what I need to do now is to change 'c99' to 'gcc' as the compiler, right? <nij>s/In the/According to the/ <mdevos>nij: also possible, I guess. Search gnu/packages/*.scm for setenv <nij>I have passed that phase, now stuck at the install phase... <nij>mkdir: cannot create directory ‘/usr’: Permission denied <nij>jgart[m]: OH great! Can't wait will do it now. <nij>(It's like solving a math problem =_=) <jgart[m]>I'm been using it for about 3 months now as my main way of getting his fork (i.e. via guix) <mdevos>nij: guix doesn't install packages in /usr. You'll need to change the relevant makefile to install the package in the right location <jgart[m]>It would be nice to have a guix channel for suckless forks/mods <mdevos>nij: search for (assoc-ref outputs in guix source code for examples <jgart[m]>the package manager probably works but I haven't tried yet <jgart[m]>I'll report back once the pinephone comes in the mail this month <jgart[m]>a guix binary cache for linux mobile apps would be great <mdevos>yjftsjhtsd: no particular reason it couldn't. What's a mobile device but a very compact laptop? I don't know anyone who installed Guix System on a ‘very compact laptop’, though <yjftsjthsd>Darn, I hoped you would tell me that there was a full Guix System image for it already (kinda like nixos has https://mobile.nixos.org/index.html). I would indeed expect guix running on another OS on pinephone to work just like any other LInux-on-aarch64 <mdevos>yjftsjthsd: I don't know anything about how pinephone works, can't help you with that <nij>mdevos and jgart thank you so much. <nij>jgart[m]: have you tried sxmo on a pinephone? <jgart[m]><nij "jgart: have you tried sxmo on a "> only vicariously through videos by others :) <jgart[m]><nij "jgart: How do you configure luke"> I haven't setup the search-patches procedure on that package definition <jgart[m]>I imagine that would be the way to do it <jgart[m]>then you'd need an aux patch laying around somewhere <jgart[m]>nij: I finally gave in and ordered a pinephone for Christmas <nij>jgart[m]: you mean something like "(substitute* "Makefile" (("\ttic .*") "")) ? <nij>jgart[m]: Good luck! I'm still wondering if I should get one. <nij>I didn't know sxmo has more videos coming out. <nij>I will binge them later. Need a rest.. <nij>Now I have my-luke-st packaged and built.. how do I add it into my user's PATH (in GUIX way)? <jgart[m]>there's a random example of using search-patches <jgart[m]><nij "Now I have my-luke-st packaged a"> have you tried guix package -f my-luke-st.scm <nij>Ah I see! Haven't, but I will try it soon. <jgart[m]>that should do it :) atleast it did for me <nij>Very happy to compile for the first time. <nij>Thank you very much :D <apteryx>civodul: Could it be better to use the Guile '#:guess-encoding' parameter of the call-with-input-file procedure (used in with-atomic-file-replacement called from substitute) instead of hard coding UTF-8 as default via the %default-port-encoding fluid? <apteryx>the doc says it tries to guess via the file-encoding procedure else uses UTF-8. <apteryx>ah nevermind; this looks for an Emacs-like character coding declaration; not very useful. <apteryx>I thought it'd peek at the binary BOM of the file or something <jgart[m]>does anyone know of an extant icecast-service-type lying around anywhere? <nij>jgart[m]: Regarding making a channel for suckless utils, there are many user patches on their websites. By choosing different patches, there will be many different versions. How would such channel be possible? Do we need to package one for each configuration? <nij>For example, (st +module1 +module2 -module3), (st +module1 -module2 +module3).. etc <civodul>apteryx: yes, file-encoding is not super useful <jgart[m]>nij: I imagine the best way would be to inherit from a master suckless package each time with different patches. If someone knows a better way please chime in. I would love to know. I'll be back online later <jgart[m]>i.e. a master package definition for each program. All forks would inherit from upstream dwm with different patches <nij>Hmm.. but if there are N modules.. <nij>Then we have to package 2^N of them.. <nij>Am I doing the math right? <jgart[m]>I'll be back later. Would love to continue discussing <leoprikler>nij you're doing the math right, but I don't think Guix has to explicitly instantiate every combination <leoprikler>for instance, there's the --with-patch transformation ***nij` is now known as nij
<lfam>Is Cuirass ci.guix.gnu.org supposed to be able to build aarch64 substitutes? <lfam>AFAICT, all the builds are failing with "while setting up the build environment: executing <lfam>`/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such <lfam>Is it expected? Does anyone understand it? <apteryx>perhaps using QEMU transparent emulation, and missing a --chroot argument to the daemon? <cbaines>That could happen I think if the guix-daemon hasn't been restarted on a build machine, and it's using qemu-binfmt <lfam>Is it safe to restart the daemon on the berlin server? <cbaines>is the build failing on berlin itself, or one of the build machines? <cbaines>maybe try building the derivation manually, and see if it offloads or not? <apteryx>or force it locally on berlin with --no-offload <lfam>I did `guix build /gnu/store/....drv` and it started offloading <lfam>It offloaded to overdrive1 which appears to have been idle <cbaines>this might be because the experimental remote building in Cuirass is just using build machines discovered by Avahi <lfam>From what I've seen, aarch64 building is not working at all with Cuirass <cbaines>which means building the derivation isn't replicating what Cuirass is doing <lfam>I haven't looked at armhf <lfam>Well, maybe we'll have to build it all this way, by hand <cbaines>Maybe you can SSH from berlin to one of the build nodes? <lfam>I've never tried. I'm not sure how that is authorized <lfam>What would I do when I get there? <cbaines>I just plucked a ssh command from the root bash history <cbaines>and indeed, when I try and build the derivation in question, I get the error you're getting <lfam>I suppose that what I'm seeing is not actually being offloaded <lfam>I see the build output "live", so that's local to berlin, right? <cbaines>I'm going to try restarting the guix-daemon on hydra-guix-129 <cbaines>it's kind of crazy that there's this 96 core machine sitting basically idle... <lfam>I've started doing development test builds there <cbaines>Ok, I had to restart the qemu-binfmt service as well, but restarting qemu-binfmt and guix-daemon has fixed the issue <cbaines>I mean hydra-guix-129 is a 96 core machine too! <lfam>Now we need to ask Cuirass to retry everything for aarch64 <lfam>If anybody still uses armhf... please test! <cbaines>I'm trying to build core-updates/staging/ungrafting with a sum total of 28 cores across 4 machines <cbaines>lfam, given this was a problem on one build machine, someone probably needs to go around all the build machines and restart the relevant services... <cbaines>maybe there's some automation for this <lfam>I increased root's Bash HISTFILESIZE to 100000 lines <lfam>I've never regretted having a loooooot of shell history <rekado>I use PROMPT_COMMAND to append to ~/.bash_eternal_history <lfam>I don't see it on berlin for ~root <lfam>Well, now we'll start accumulating more history <lfam>Maybe it should go in the skeletons in config.scm <lfam>Anyways, I'm going to log in to all the workers and restart the guix-daemons and qemu-binfmt services <rekado>I think a large HISTFILESIZE by default is a good thing <lfam>I guess this process will break a number of builds <lfam>Will Cuirass retry them? <rekado>jgart[m]: judging by user reports it is not working <efraim>I add 'PROMPT_COMMAND="history -a; $PROMPT_COMMAND"' to my .bashrc <efraim>I think there's a patch to remove the nix importer <lfam>jgart[m]: What rekado said, and also, at this point, it's not very useful. We've already imported or copied the bulk of the trivial packages from Nix, and the importer cannot handle any sort of complication in the nix package <lfam>By complication, I mean things like custom build phases, etc <lfam>In almost every case it will be easier to read the Nix package and rewrite by hand for Guix <jgart[m]>Do you use snippets to generate boilerplate for a new package? <lfam>No, I just type it out furiously, in a sort of fugue <lfam>If I have to make a very large number of them, I will copy and paste something <lfam>I use poor tools, though. Other Guix hackers will have better advice :) <jgart[m]>I'm mostly using vis editor. Maybe I'll make something similar at some point <lfam>Is there a way to ask cuirass to retry everything that failed? <cbaines>did you just run the relevant PostgreSQL query to retry the qtbase build? <cbaines>lfam, I guess you just need to construct a similar query then to do the same for builds on mass <lfam>I was given the sql query. I don't actually know the language <cbaines>I can try and help, I know a bit about the schema <lfam> update builds set status = -2 where id = 163857; <lfam>I'd guess we need to change it to something like "... where state = failed" <lfam>But limit it to aarch64 (and maybe armhf?) <cbaines>(I'm familiar with the SQLite database, but PostgreSQL is now in use, so I'm assuming things have been like for like adapted) <cbaines>assuming you're in psql, you can run: \d builds <cbaines>that'll show you about the builds table <cbaines>system is the column that'll be useful for limiting to specific systems <cbaines>I think this will count failed aarch64-linux and armhf-linux builds for some staging evaluations: SELECT COUNT(*) FROM builds WHERE system IN ('aarch64-linux', 'armhf-linux') AND status = 1 AND evaluation IN (10974, 11190, 12550); <cbaines>Either I'm getting this query wrong, or there aren't any armhf-linux builds for staging on ci.guix.gnu.org <lfam>I'm going to take this delay as an opportunity to update the time zone database <apteryx>OK, to answer my earlier question, ISO-8859-1 allows opening the file (it's equivalent as opening it in binary mode). <efraim>lfam: I guess pushing tzdata would go and reset a bunch of builds on staging :) <lfam>And we haven't made very much progress in building it, so it's not that wasteful <efraim>building on aarch64 is slow, but so far the only thing noticably broken for me is vim, but it's FTBFS on aarch64 also on master *efraim tries to think how to reorder those words to be less akward <lfam>vim often fails to build. I don't think the test suite is meant to be run by distributors <lfam>Or, they don't aren't super serious about validating releases <lfam>The overdrive servers are only Cortex A57. It's basically a state-of-the-art mobile processor <lfam>Oh, it's apparently out-of-order. I had thought the A5* series would all be in-order. I don't really know how it stacks up in that case <lfam>It's a far cry from the A53 you see everywhere <lfam>And at this point denigrating a CPU as a "mobile processor" is a little confused, considering that many phone chips outclass what you get in a laptop <vagrantc>the overdrives aren't particularly fast cores, though, no <vagrantc>it was the system i used to test getting the aarch64 kernel in guix :) <lfam>16 cores of NXP Cortex A72 <roptat>rekado, thanks! I'll have a look <roptat>rekado, is there some documentation somewhere? <vagrantc>lfam: haven't, looks like quite a machine <lfam>Something that sets it apart is that you can actually "just buy it" <lfam>You don't have to call somebody and beg <lfam>And, I've only heard good things about SolidRun's products <vagrantc>i've a few of their older armhf caliber platforms ... they're pretty nice <vagrantc>they do a reasonable job of upstreaming support *vagrantc did get on the bad side of one of their engineers once, through no fault of theirs <lfam>Well, that can happen anywhere. It's remarkable you were even able to communicate with their engineers <lfam>You'd spend about $1250 with RAM, storage, case, etc <bavier[m]>oh, great, sorry. All I saw from the product page was a link to request a quote. <lfam>I'd guess one could get a volume discount, or maybe a FOSS discount <lfam>I think it's already a good price considering what you get <lfam>You know, assuming you want ARM. <bavier[m]>but, really, I already have more systems than I can keep busy. <lfam>cbaines: Did you have any luck retrying the failed builds? <cbaines>I only looked at maybe what builds to change <cbaines>There aren't any armhf-linux builds for staging on ci.guix.gnu.org as far as I can tell <cbaines>and there are 670 aarch64-linux builds that could probably be changed back to the scheduled state <lfam>Yes, I think so. I did change the tzdata, which will cause many rebuilds, but I'd still like to reschedule everything, in case there are some spurious failures of packages that don't depend on tzdata <cbaines>I've run this now, which has changed 670 builds back to scheduled: UPDATE builds SET status = -2 WHERE system = 'aarch64-linux' AND status = 1 AND evaluation IN (10974, 11190, 12550);