<leoprikler>ah well, I had this weird thought in my mind that people were somehow instinctively familiar with gresource <merazi>ekaitz: So the issue is as follows: the icons on the tray are buggy, like if they were rendered in a wrong way or something. It happens on the GNOME3 session menu as well. <ekaitz>merazi: I had issues with that in the past and I had to use some plugins that helped but if i recall correctly that's not an specific guix issue, but a GNOME one <merazi>It happens on xfce4 as well, maybe I'm missing a package (?) <merazi>I installed xfce4 using the config.scm file... Maybe I'm missing something, let me upload it to a pastebin <ekaitz>i have this thing installed: gnome-shell-extension-appindicator <ekaitz>i know it's related with system tray icons <ekaitz>but I can't remember why did I package it <ekaitz>leoprikler: but the python file you showed us (gen-gtk-gresources-xml.py) is just making a list of resources, but it's not playing around with the files contents, is it? <leoprikler>nope, just generating an xml, that later gets compiled (see meson.build) <merazi>ekaitz: lol weird, let me try something else <ekaitz>ugh i can't understand this meson code... i need to know how is it actually compiling them... <ekaitz>merazi: it looks pretty standard to me... i don't see anything wrong <merazi>Oh ok, then I have no clue why this happens :( <iskarian>I have no idea if it has any relation, but the assets.txt is missing bullet-symbolic, check-symbolic, and dash-symbolic... but maybe because they're svg? <ekaitz>i found the same thing...the assets.txt is only used for the rendering to .png files <ekaitz>i didn't find anything... I hope you are more lucky <iskarian>ekaitz, I'm afraid I'm finding myself out of my depth as well... my last easy guess would be that perhaps it is svg icons that are not rendering correctly? <leoprikler>but it shouldn't: gdk-pixbuf+svg is propagated by gtk <iskarian>I don't recall if it was posted yet, but if not, evince generates this message when started from command line: Gtk-WARNING **: 15:51:10.567: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg. <iskarian>This may indicate that pixbuf loaders or the mime database could not be found. <iskarian>of course, it also has a broken icon (a pencil icon) and that's not generating any error messages, so... *shrug* <leoprikler>for the record, both icons work fine for me outside a pure environment <leoprikler>so something within the gnome package makes things work <leoprikler>the bullet-symbolic was what ekaitz and I were investigating before with no real conclusion <ekaitz>it's getting late for me but I'll try to run all this in gnome to see if the gnome shell changes anything <merazi>well, I did a workaround for xfce <merazi>hide the tray icons, when you pull them back they're displayed correctly <merazi>it's not the best solution, but it looks better than having the glitchy icons there <raghavgururajan>Folks! I am trying to package using ant-build-system, but the build fails with the error "jar not found". Thoughts? <raghavgururajan>Hmm, targets are mentioned in build.xml. So should I do #:build-target #f <iskarian>raghavgururajan, would you not want #build-target "init"? <iskarian>That was my first guess, since the "build" target builds a distribution archive... but it does not seem right after all <iskarian>It would be roundabout, but as a last resort you could run "build" and then use the distribution archives it builds haha <iskarian>probably the "real" solution involves messing with the build options as mentioned at the top of build.xml <iskarian>It could be rather difficult... it looks like even gentoo downloads the dist releases <apteryx>what is the (gnu packages xdisorg) module meant to contain? What does 'xdisorg' mean? <apteryx>Seems like a distribution of non-core x11 packages <apteryx>perhaps it would be better named as xorg-xyz.scm for consistency <apteryx>although if it stands for a 'disorganized collection of x11 related packages' I like the pun. <apteryx>leoprikler: beware that if both gdk-pixbuf+svg and gdk-pixbuf (sans svg) are propagated, you can't really be sure which one will be picked. Better check with ldd what is being used. <apteryx>(I see gdk-pixbuf propagation as a bug, if there are instances of it remaining) <raghavgururajan>I now get "Exception in thread "main" java.lang.RuntimeException: Could not create parent directory for lock file /.gradle/wrapper/dists/gradle-5.5-all/66q2j3qadt42ygj9lkubqor18/gradle-5.5-all.zip.lck" <g_bor[m]>Hmm... does it really try to create /.gradle ? ***iskarian_ is now known as iskarian
<raingloom>okay, i can't figure this out. how do you run an executable inside a service with all the environment variables that would be set if you used it inside guix environment? <ss2>hi! So I've got a package decleration, that inherits from another package decleration. How can I put it into the system profile to be widely available -- without needing to push into a local channel repository? <raingloom>ss2: you can use the --load-path option or the GUILE_LOAD_PATH environment variable to use a local channel, or just whatever guile module tree you need <leoprikler>and I agree with your assessment of the gdk-pixbuf situation <leoprikler>okay, so regarding evince, one missing image is "view-sidebar-symbolic" <leoprikler>whoever finds those, gets a (GDPR-conforming) cookie <vivien_>raingloom, you should definitely make your program set up its environment variable with wrap-program. When that’s done, you can invoke the program in any environment, including in a service <vivien_>There are tons of programs doing that, but this morning I thought of guile-hall first: guix edit guile-hall <nckx>document-edit-symbolic sounds familiar, is that the winged pen? I'll miss it when it's gone. It's become part of my visual memory. <ekaitz>leoprikler: I'm back after a good sleep :) I launched GNOME and the icon error we were checking yesterday with iskarian is also there so gnome-shell doesn't fix it for me ***daviid is now known as Guest89136
***Guest89136 is now known as daviid
<abcdw>describe-package and list-packages for some reason doesn't show packages installed by guix. package-directory-list value equal to "/home/bob/.guix-home-environment/profile/share/emacs/site-lisp/elpa", which seems correct (the directory contains all symlinks to necessary packages). <abcdw>Do anyone encountered the same issue? <ekaitz>karthik[m]: yeah, what do you need? <karthik[m]>ekaitz: hi, I just installed gnome+guix on bare metal <ekaitz>i dont think so... it depends on your personal taste <karthik[m]>ekaitz: are you facing/faced any such issues I mentioned above? <ekaitz>I lost the history so can't see them... can you repeat them for me? <ekaitz>karthik[m]: forget about that, it's the irc client which did something wrong... I can see your message, yeah <ekaitz>I have had a similar issue with the touchpad, and I configured it manually <karthik[m]>ekaitz: could you please tell me how you fixed disappearing touchpad options? <ekaitz>I think I didn't, I just configured the touchpad by a lower level interface, because I also wanted some extra configuration <ekaitz>that's my current touchpad config <brendyyn>Yeah just dont say anything rude about it to them. be polite <pkill9>i found a sweet script that lets you search google from commandline, but damn python doesn't seem to recognise symlinks to run <Noclip>brendyyn: I didn't plan to say anything to them xD <brendyyn>im finding cmake is demanding perl for some reason... <Noclip>pkill9: That sounds interesting. Would that also work with other search engines? Eventually even through TOR? <brendyyn>today i read tor got so bad an attacker controlled around 30% of all exit nodes and was man-in-the-middling everthing. make sure you only use https <Noclip>On the other hand I'm not sure if that would be usefull for anything. If you are limited to the command line it might be a better idea to use a command line browser instead. <Noclip>brendyyn: I disabled http in my Tor browser using https everywhere. <brendyyn>that plugin does not guarantee you wont use http <Noclip>(I did the same in the normal firefox.) <pkill9>Noclip: i think it just scrapes google search results, so i dont see why it wouldnt run through tor <brendyyn>try going to my lovely governments site: gov.au <Noclip>It does if you tell it to do so. <leoprikler>karthik[m]: idk about suspend, but hibernation in Guix is a missing feature <leoprikler>sound… prolly depends on the hardware, but it's fine for me <leoprikler>touchpad: can't verify because I don't own one, but I trust you to make a correct report <Noclip><leoprikler "karthik: idk about suspend, but "> Ohh, I always forget which one is which ... <brendyyn>suspend should work. hibernation is poor because linux cant support it well due to all the crappy hardware in the world <pineapples>Isn't hibernation a matter of setting up a swap file/partition, and writing a value to a /sys interface? <pkill9>i thought hibernation works fine in linux, <brendyyn>suspend keeps the computer running and just tries to save power. hibernation means turning it off but saving the state and restorting it <pkill9>its just guix isnt set up to uandle it <sneek>Welcome back civodul, you have 1 message! <leoprikler>IIUC there is a patch for hibernate somewhere in the ML, but it gathers dust quickly and it's known to be a hack <Noclip>Is it possible to use virt-manager from guix on a foreign distro? <Noclip>It needs the libvirt service for that. <pkill9>i would think so, since it could maybe connect to the foreign distro's libvirt <pkill9>it's probably just througha socket or something <Noclip><pkill9 "i would think so, since it could"> Looks like it can't. <Noclip>I think it is hard linked to the version from guix. <Noclip>But let me read the error message again. <Noclip>Didn't get an error anymore after starting virt-manager <Noclip>How does guix handle stuff like adding new user accounts needed by specific packages? <Noclip>So if the service is listed in the os definition guix will make sure that user exists after boot? <pkill9>you can also have it add the package to the system's packages <Noclip><pkill9 "you can also have it add the pac"> Ahh that makes sense. <Noclip>How about guix environment? Will the user be available in it even if it is not installed as system package or service? <Noclip>And with the container option (-C)? Should be technically possible inside a container, right? <pkill9>is there a specific package you're thinking of? <Noclip>pkill9: Currently I'm just trying to understand how guix handles this in general. <Noclip>But apart from that I'm still thinking about libvirt. <Noclip>(But I don't want to run libvirt inside a container ...) <pkill9>did you find where guix's virt-maanager is hardcoded to use guix's libvirt? <Noclip>pkill9: I think you're right. It seems to work with the host distro's libvirt service. <pkill9>you may also need to add your user to the 'kvm' group <pkill9>or configure libvirt to allow your user to access it however way <Noclip>pkill9: When installing libvirt with apt I got automatically added to the new libvirt group. <karthik[m]>leoprikler: Suspend options is not visible in GNOME for me. I wonder why. x230 is a well supported hardware <leoprikler>I'm not sure how GNOME handles suspend normally. It's probably a systemd vs. shepherd issue <pkill9>assign a keybinding that when pressed, opens the currently focused application in a debugger <pkill9>but i don't actually know how to debug, lol <civodul>we should test on foreign distros too, in particular the locale warning (or rather lack thereof!) <lfam>I can test the installer script on x86_64 Debian <lfam>I don't recall seeing the warning while testing RC1 <lfam>It's somewhat misleading that the latest installer scripts says that both civodul's and apteryx's keys are required, but that's very minor <lfam>It's nice that it offers to fetch the keys for the user <lfam>I'm a little annoyed that #47979 didn't make it in, but that we made other significant changes, like the Spice thing <lfam>But, I understand that #47979 required new translations after the strings were frozen <lfam>Why did we add wget to %base-packages instead of using `guix download`? <civodul>lfam: re keys, the installer has to offer both because it can be used for any release in theory <civodul>lfam: re wget, i think apteryx found it more convenient <civodul>and it's true that users probably expect it <civodul>it's more about being less surprising <lfam>Re #47979, the second best time to plant a tree is today :) <lfam>So it will save some bug reports after 1.4.0 <lfam>I notice that Berlin doesn't have a baked substitutes for gettext-minimal, although the derivation is built on berlin.gnu.org <civodul>re #47979, i think we should stick to the string freeze policy <lfam>Maybe my substitutes cache got stale somehow <lfam>Like, I'm running `guix pull` after installation and it wants to build the dependencies of Guix <lfam>I'm just expressing my disappointment. I knew it wouldn't be included <civodul>yes, we missed a couple of useful patches <lfam>Alright, I deleted the substitutes cache and now it's working better <civodul>lfam: re "guix pull", i ran it in the 1.3.0rc2 VM and it didn't build anything <lfam>I'm glad to hear you're testing the VM image <lfam>No locales warnings, which is nice <civodul>lfam: you're testing on foreign distro? <lfam>Re #48316, I'm wondering if somebody asked Filip to make this patch? If so, okay, but otherwise, I'm not sure we should document the ML moderation, which is totally ad-hoc <lfam>It's not really correct to say that "Future acknowledgements should not be delayed". That really depends on the whims of the moderator <lfam>I don't really know. Do the instructions say? <lfam>"Merger is like equality: it is reflexive, transitive and symmetric. " <lfam>I don't think there is a hierarchical relationship between merged bugs <brendyyn>Unknown command or malformed arguments to command. <lfam>I don't understand your messages. Are you saying that it didn't work? <lfam>I sent a message containing only "merge 39527 36508" to <control@debbugs.gnu.org> and it worked as expected <lfam>It should have worked for you, if you did the same <lfam>I noticed you had an extra space between the bug numbers. I don't know if that affects it <lfam>And, I don't know about the '>' character. I think you should not put that <lfam>You can try again, but using unmerge, and then merging them again <brendyyn>thats just from it quoting me in the reply <lfam>Did you send it to the correct address? <lfam>I would try again without that extra space <lfam>I don't think the bugs can be merged more than once, in a meaningful way <brendyyn>btw i wanted to CC them and say it was likely that issue, but im not subscribed so i cant get their email address <lfam>Btw, you can get the full emails with headers from the ML archives <raghavgururajan>karthik[m]: Since you asked for a task to get familiar with packaging, can you try packaging gnome-tour? <karthik[m]>raghavgururajan: just, curious what's the file extension of a guix package? <mbakke>civodul: you have two 2021's in the copyright line of gnu/local.mk :) <mdevos>Anyone interested in two new linters? --> two fresh patches on guix-patches <lfam>I wonder if we can make (replace 'check ...) just do the right thing, rather than requiring (when tests? ...) <mdevos>lfam: possible, but that would require special-casing 'check <mdevos>afaik, all phases are treated the same <lfam>It might be worth it. I always thought it was a subtle bug that (replace 'check) didn't respect #:tests? #f <lfam>Or maybe there is some other way to approach this that improves the situation without requiring extra boilerplate from packagers <mdevos>lfam: if you want to special-case 'check, the procedure gnu-build in guix/build/gnu-build-system.scm seems the right place to do it <mdevos>(replace 'phases' with #{expression for filtering out 'check' if #:tests? is #f}#) <mdevos>would need to be on core-updated, though <raghavgururajan>Exception in thread "main" java.lang.RuntimeException: Could not create parent directory for lock file /.gradle/wrapper/dists/gradle-5.5-all/66q2j3qadt42ygj9lkubqor18/gradle-5.5-all.zip.lck <mdevos>raghavgururajan: is that /.gradle/wrapper/..., or /some/directory/.gradle/wrapper? <mdevos>I don't think the java program has write access to /.gradle *mdevos not familiar with how gradle works <leoprikler>there exist both $HOME/.gradle and $PROJECT/.gradle in a typical setup IIRC <iskarian>Is my ~/.guix-profile/lib supposed to be in LIBRARY_PATH, and if so, is it supposed to be first? For some reason gcc (from gcc-toolchain) is pulling crt1.o and crti.o from there <iskarian>ah, actually, LIBRARY_PATH in my user profile *only* contains ~/.guix-profile/lib <iskarian>but that doesn't seem relevant: even when I set LIBRARY_PATH= GCC tells me that LIBRARY_PATH contains ~/.guix-profile/lib <leoprikler>I'm p sure this package is one of many that would call for gradle-build-system <nckx>leoprikler: Hibernation is 100% supported. Please report bugs! <nckx>(It's also not a hack at all, unless we disagree on that point...) <mdevos>raghavgururajan: Could you check what HOME is set to within the build environment? <mdevos>maybe add a phase after unpack that does (pk 'home (getenv "HOME")) <mdevos>as according to leoprikler, $HOME/.gradle is ‘typical’ <mbakke>oh, iproute2 is an input of gnutls on core-updates <leoprikler>nckx: perhaps my memory is just shaky, but if it works, why is it not yet part of Guix? <nckx>Nov 5 2020. Admittedly not as long as I'd thought, but (like so many) I'd been carrying local patches for $years... *nckx genuinely surprised it's that new. <nckx>Nothing about it is Guix-specific, so it would feel weird (to me) to document it in addition to all the Guix-specific things we do document. <nckx>swapon /dev/stuff; echo disk > /sys/power/state; done <lfam>Should we add a herd sub-command for it? <leoprikler>did that on my other machine now, I'll tell you how it went in a few hours *nckx 's opinion is probably obvious. :) <nckx>‘The purpose of an init system is to pointlessly brand® the shutdown experience™ with pointless aliases.’ <lfam>There should be something more than echo-ing to sysfs <nckx>leoprikler: What needs to be integrated? That shouldn't be too hard. <lfam>We have some integration for sddm (found in the manual) <lfam>That's for reboot and halt <nckx>My question was genuine. <leoprikler>IIRC there's a gnome shell extension, that adds a suspend/hibernate button <leoprikler>we ought to ensure, that this hibernate button works <nckx>Why don't GNOME/SDDM use the standard interface, or call a dbus thingamajig that uses the standard interface? <nckx>leoprikler: Of course. What needs to be done? <leoprikler>I'm not sure, what you call "the standard interface" here. <nckx>Well, the only interface. <leoprikler>that's why branded shutdown commands exist in the first place <leoprikler>I just typed this on my other machine, sysfs really didn't like not having a sudo tee <nckx>That's not the point. The point if that we add a NIH herd subcommand for it (knock yourselves out, seriously), GNOME still won't use it, it will use some dbus thing. Which appears to be upower. <vivien_>There’s a typo in the guile manual, raise-exception is documented with #:continuable but in reality it’s #:continuable? with a question mark <lfam>Thanks vivien_. Can you report it in the #guile channel? <nckx>Hmm. Error org.freedesktop.DBus.Error.UnknownMethod: No such method “Suspend” <vivien_>lfam, I’m not authorized in #guile, the channel says #guile :Cannot send to nick/channel <nckx>Apparently that dbus method is obsolete. Surely the ‘modern’ way isn't to shell out to systemctl... right? Does anyone using GNOME happen to know how it initiates hibernation? <lfam>I heard it uses a Javascript API to contact gnome.org which then proxies your request for hibernation to the device manufacturer, where your hibernation license key is checked *nckx answers self: ...using loginctl, of course. 🤦 <nckx>I just totally not by accident ‘loginctl hibernate’d my machine. It worked. So this sounds very much like a bug in (our) GNOME (package) if it can't even do that. <nckx>lfam: Thanks, I hate it. <lfam>"I wonder if this button works" <lfam>I just swapped out my macchatobin's fan for a quiet fan. Now I can actually keep working on it <nckx>leoprikler: Could you confirm that ‘loginctl hibernate’ works, and GNOME's ‘hibernate’ button doesn't? <lfam>I can't believe anyone would manufacture such a noisy fan <nckx>(Other combinations are also valid bugs, of course.) <nckx>Now that I remember loginctl I can only double down on considering ‘herd foobar’ to be actively harmful. Let's standardise, not fragment, mandatory xkcd link, amen. <lfam>It's a hard argument to make in a distro like Guix :) *nckx forks Guix to make it standard. <lfam>Not to mention, whatever Guix does IS the standard ;) <lfam>All those other distros are holding it wrong <vagrantc>lfam: i did upgrade a few more apm mustang boards to the latest firmware, although i suspect some of the boards have bad ram <lfam>I have a Tianocore / UEFI bootloader installed now. So I think it should be easy to get GRUB working on top of that <nckx>lfam: You're not wrong and it feels so right. <vagrantc>lfam: but will try to triage and send you a couple of them sometime <lfam>You stick the wires in, squeeze, and a liquid sealant is released that then hardens and seals everything in permanently <lfam>My day job will love this <nckx>Oh I used some o' those last week. I wonder if they'll hold up. <lfam>They better! 3M is like the last great USAmerican company <lfam>They actually invent useful things :) <lfam>The "Command strips" product is amazing <lfam>I'm being sarcastic. Obviously Uber and Wework are the future of humanity <lfam>vagrantc: So, is it accurate to assume that "GRUB will work" on tianocore? <nckx>(Not vagrantc and only IME but) yes, or at least it's not GRUB <-> Tianocore that will break. <vagrantc>lfam: what you'll have fund with is initrd-modules <vagrantc>lfam: or get to see why i usually use linux-libre-arm64-generic :) <lfam>Ah, I have to pick the correct modules <lfam>That will be a good learning experience for me <lfam>Well I'm going to start with Debian <lfam>Once that boots, I'll try with Guix <lfam>But I'm happy to use Guix on Debian if Guix System is too much work <vagrantc>i did manage to get the mustang down to only two modules <lfam>The goal is to get these cores into the build farm ASAP <vagrantc>who would be crazy enough to run guix on debian? <vagrantc>fwiw, i did test building 1.3.0rc2 on debian, but nothing really new so will wait till release to do another upload to debian experimental <vagrantc>what's the syntax for referencing a specific part of info pages? e.g. if i want to reference info:guix ... on guix-daemon ? <lfam>I've been building the arm64 linux-libre generic source tarballs "by hand" on the build farm central node. That way they offload to a real aarch64 machine instead of randomly selected an emulated builder which can't complete the task quickly enough <vagrantc>lfam: i had a good run with linux-libre 5.11.18 ... but 5.12.2 and 5.11.19 don't appear to have successfully seeded the tarballs :/ <lfam>5.11.19 was built earlier today <nckx>☆New☆ ‘guix copy: error: failed to connect over SSH to daemon at 'w.x.y.z', socket /var/guix/daemon-socket/socket’ <lfam>5.4 and 5.10 are in progress <lfam>vagrantc: IIUC there is not yet a linux-libre-arm64-generic package for 5.12 <lfam>(The default linux-libre package is still 5.11) <lfam>5.4 should be built. 5.10 is in progress <lfam>I'm trying to have Cuirass "retry" the builds so that the page on ci.guix.gnu.org will show success, but I can't load the admin interface today for some reason <nckx>lfam: Make sure you're connecting over HTTPS. If that doesn't fix it, I can try if you post the link. <lfam>I'm using HTTP over an SSH tunnel to the port <nckx>I'm using a TLS client certificate. <lfam>I read the instructions for the TLS client certificate. The state of maintenance.git on ci.guix.gnu.org is too confusing for me to feel confident reconfiguring the system <lfam>I said this on guix-sysadmin and I hope it gets cleaned up <lfam>Like, there are always a bunch of uncommitted changes, and I can't tell if it's "safe" to reconfigure based on it <lfam>It's hard to be disciplined when using Git in this way. I struggle with it for my own Guix Systems too <lfam>The first step of testing a new Guix installer is to understand and write sensible commit messages for the mess of unstaged and staged changes <nckx>lfam: You need to reconfigure to create a client cert? I don't remember that at all. <nckx>lfam: Sysadmins SHOULD su to root and yank the blessed command from root's history with ‘C-r reconfigure’. Anything else is trouble. <lfam>Looking at 'doc/release.org', setting up the TLS client cert got simpler <nckx>lfam wait are you saying my current HEAD~4 of ‘f’, ‘f XXX’, ‘fuck’ and ‘XXX’ is not bestest practice <lfam>I should do it sometimes. The SSH tunnel is unreliable. I have high latency to berlin.gnu.org at all times <lfam>No, nckx, it's merely better practice <lfam>Best practice is to only use `git add -u && git commit --amend` <lfam>Multiple commits are an anti-pattern ;) <nckx>‘Changes for May’ got it. <lfam>At the end of the year, you can concatenate each month into an annual commit <nckx>We joke like there isn't some ridiculously successful project out there that does this. <lfam>I'm shocked to see an ncurses Git repo. I was going to point to ncurses as an example <lfam>IIRC, historically, they only offered release tarballs, with no development repo available at all <vagrantc>lfam: yeah, i've been trying to get the regular linux-libre working rather than -arm64-generic, as some packages (e.g. iwd) fail to build on -arm*-generic <lfam>It fails to build on the wrong kernel? 😭 <lfam>That's "not supposed to happen" <vagrantc>the pinebook pro should be working with linux-libre@5.10, @5.11 and in theory @5.12 with the patches i pushed yesterday <lfam>I always warned people that the Guix build container could not account for the kernel, but I didn't have any examples in mind <lfam>I guess it makes sense based on the package description: "It optimizes resource utilization by not depending on any external libraries and instead utilizing features provided by the Linux kernel to the maximum extent possible." <lfam>It's lacking the normal abstraction layer <vagrantc>the test suites make use of kernel-specific features ... so fail when they aren't present <civodul>mbakke: oh, wrong conflict resolution maybe? <vagrantc>lfam: thanks for getting the linux-libre source tarballs built though, it was a huge help for some of my recent patches <civodul>apteryx: FWIW i'll be busy all day tomorrow and haven't been able to help on NEWS & co today <vagrantc>(though my recent commits messages really prove that i should've sent them through review) <civodul>apteryx: so perhaps Tue or Wed would be more appropriate <lfam>vagrantc: You're welcome. In the long run we have to stop using "SSH and `pre-inst-env guix build ...`" but for now it works <lfam>It would be nice to mark certain packages or derivations as requiring "real hardware" <vagrantc>lfam: oh, i also noticed that the deblob-check is where it tends to time out ... does adding --verbose help ? <lfam>Even though we don't want to virtualize anything on the build farm, it will be a long time until we can stop doing that <vagrantc>e.g. produce more incremental output, to reset the timer of build inactivity <lfam>It just works when building on real hardware <vagrantc>it will of course spam the build logs then <lfam>I don't think that matter <lfam>Offloading on berlin.gnu.org only uses "real hardware" so it's a handy hack for avoiding the slow emulated builders <lfam>I've also started cancelling certain evaluations if I know they are going to tie up the emulated builders for no result. Like, for any changes to SBCL stuff <vagrantc>so some builds are fine on the emulated builders, but some are problematic? otherwise ... would it make sense to not have the emaulated ones at all? <lfam>The choice is between "having ARM substitutes" and "not having ARM substitutes" <lfam>We have a grand total of 4 Cortex-A57 cores in the build farm right now <vagrantc>i thought there was at least one aarch64 builder in service <lfam>So, we can't really avoid emulation <lfam>But, lots of things fail to build there <lfam>We are in the process of / trying to buy some newer machines too <vagrantc>they really made a huge difference for teh reproducible-builds infrastructure <lfam>Not super impressed by the companies involved though <lfam>It's not that easy to actually buy anything <lfam>The Avantek / Altra store is offline now, which is a bad sign <lfam>And even ARM themself can't access these machines from what I've gathered <cbaines>I'm hoping the Honeycomb I ordered will ship soon, last I heard was the first week of May <lfam>Maybe the Mustangs are the best option in the short-term. Which would be an indictment of the entire ARM64 ecosystem, IMO <lfam>It's easy to forget that there is a global pandemic in the USA these days. It's understandable that things are difficult now <drakonis>it hadnt been up to date when i had last checked <lfam>drakonis: A lot of long-standing annoyances have been fixes <lfam>"Substitute installation has been optimized" is a major one <lfam>A lot of important security fixes <drakonis>the new/updated packages counter isnt here <drakonis>will it only get added it once the release is ready? <lfam>All this stuff is already deployed on the master branch. So, if you've done `guix pull`, you have it <lfam>It doesn't use a standard ARM design (i.e. a "Cortex" design) <lfam>Oh, sorry drakonis. I didn't understand your question <drakonis>1.3.0 isn't officially out, its still in the rc phases, is that why the NEWS file isnt updated with the number of new packages and updated packages? <admas>Does anyone know why I am getting a file not found error when requiring use-package in emacs when package and emacs installed in GNU Guix? <drakonis>new services and noteworthy updates isnt in it either <lfam>A few minutes ago civodul said that they hadn't been able to work on NEWS today. So maybe it's coming <drakonis>now that i'm in no rush to keep everything stable on my machine <admas>The package is .guix-profile/share/emacs/site-lisp and this path is in load-path <drakonis>and now that its time for 1.4.0 to begin, can't wait for guix home to get merged in <lfam>I'm not sure I understand your question admas <lfam>We'll have a lot of work to do after the release, between features like `guix home` and doing the core-updates cycle <civodul>drakonis: there are NEWS updates in the 'version-1.3.0' branch but it's incomplete <rekado>lfam: turns out the poorly trained MDC spam filter ate the reply from SolidRun… <civodul>lfam: when testing on Debian, did you try running 'guix pull' after the install? <admas>@lfam, I am unable to require emacs packages in emacs config when installed with Guix system <lfam>civodul: Yes, I did `guix package -m manifest.scm && guix pull && systemctl restart guix-daemon && guix package -u .` It worked well <drakonis>i wonder whether guix home addresses the separation between user and system services in the same way home-manager does <lfam>Any Emacs wizards around that can help admas? <drakonis>all services had to be written with users in mind and that had some weird annoyances <civodul>lfam: cool; do you know how many commits are authenticated on the first pull? <lfam>civodul: I can try it again and check if you like. I didn't notice <lfam>Alright it will take 5 or 10 minutes <lfam>Anything else you'd like me to check? <civodul>sorry for asking, i thought you might have it handy in a terminal <lfam>I'm around today and tomorrow to help <rekado>…and I just tried paying for three Honeycomb boards again — and it worked this time. <lfam>I told you that Paypal would inscrutable allow your purchase eventually <lfam>I hope you meant for it to work :) <lfam>s/inscrutable/inscrutably <rekado>yeah, I considered the possibility that it might work if I tried now. <lfam>This exact same kind of thing happened to me recently when I had to update my bank details on my paypal account. An account that I opened more than 15 years ago <lfam>Paypal is mysterious and extremely risk-averse <lfam>They must have to contend with an absolute torrent of fraud attempts <lfam>civodul: It authenticates "commits 9edb3f6 to 80c091e (889 new commits)" <leoprikler>nckx: IIUC, GNOME should use the loginctl method <nckx>leoprikler: Do you use GNOME? (I don't, and setting it up just to test this is a bit much.) <drakonis>there's no cc symlink by default, right? <leoprikler>Judging from the boot messages, the manual method did not seem to work <lfam>drakonis: It's in a package definition? <nckx>leoprikler: Did you boot with resume=/dev/ice? <drakonis>doing some ocaml stuff here and i need to use opam <leoprikler>I booted with whatever Guix gives me as standard <drakonis>dying to do something different after two whole years of nonstop nixos <leoprikler>This brings me back to aforementioned lack of documentation <drakonis>oh yeah, what else is coming up for 1.4.0? <drakonis>all the work that ambrevar was doing a while back? <jbv1[m]>Hi guix ! I think I finally managed to package julia 1.6.1, I am not used to work with git and email do you have some pointers I could read to submit my patch ? <nckx>leoprikler: ...did you mkswap? <leoprikler>Why should I mkswap outside of installing the distro? <drakonis>do you have a swap file or a swap partition? <leoprikler>I have a swap partition setup, but it's not found on boot <lfam>jbv1[m]: If you aren't comfortable with Git, just send whatever files you made as an email attachment to <guix-patches@gnu.org> and mention that you don't know how to use Git yet. The reviewer will clean it up for you <jbv1[m]>thanks will do, I am used to git but not via email ;à <drakonis>hmm, have you tried pointing to its uuid? <nckx>leoprikler: That question does not make sense. mkswap to create a swap ‘file system’ on the device, so you can swapiton, or don't. <nckx>drakonis: It's none of that, the swap device is fine, it just needs to be formatted. <lfam>If it's too annoying to set up `git send-email`, just use `git format-patch` to create patch files and send them as an attachment <nckx>They wrote a hibernation image to it. <lfam>jbv1[m]: The important thing is to send your code. It's not very important how you send it <lfam>jbv1[m]: For example, `git format-patch origin/master --stdout > julia.patch` <jbv1[m]>it's sent ! looking forward for feedback <leoprikler>manually resuming worked out somehow, but UX=1/10 <nckx>leoprikler: I think the basic steps to go from zero to hibernation hero are (1) add your swap device as ‘resume=/dev/swap0’ to your kernel-arguments (2) reboot. You could add that to the manual somewhere. I'm a bit nervous about it: the possibility for data loss is real. <nckx>Adding resume=<first swap device> by default is... risky. I don't remember off-hand which heuristic the kernel uses (I use my own fork), and it could easily suspend to a different partition instead.