<ruffni>is it possible guix can't be installed on exFAT partitioned disks? <vagrantc>it is certainly possible exFAT won't work <ruffni>exFAT doesn't support symlinks. so i guess the whole concept of having a store is impossible ;) <rekado_>our LE certs for guix.gnu.org (and others?) will expire soon. <rekado_>looks like the certbot job isn’t working *vagrantc wonders how soon <you-was-here>how do I figure out what provides a package in my current system? I'm trying to add `--with-security-key-built-in` to ssh and have it be available to e.g. guix deploy, ssh-agent <sss>how to install libgcc into environment ? <darth-cheney>I'm trying to install guix system on a laptop here. Installation from USB drive went off without a hitch, but when I boot up it seems to get stuck at "Please wait while gathering entropy to generate the key pair" <darth-cheney>Any ideas about what could be causing this / ways to debug? <roptat>mh, sounds like the ssh service is trying to gather entropy, but something is preventing it from doing so <roptat>I've never seen that with the guix system before, but maybe you can have some influence on the process by moving the mouse, typing some nonsense, etc <roptat>maybe you can also access another tty in the meantime <darth-cheney>hmm should I try to reinstall and not select any of the optional network service options (I think those included Tor and something else) <roptat>I think this is caused by ssh, not tor <darth-cheney>I mean I think this machine should support it if the usb stick booted right? <darth-cheney>yes, right, ok the optional service is OpenSSH sshd daemon <roptat>yeah, something's wrong with ssh <roptat>yeah, if you don't know what that is, you don't need it :) <roptat>(it's used to connect to the machine remotely, and to secure connexions, it needs some crypto that it sets up on first boot, which blocked your laptop for some reason) <darth-cheney>yeah I need remote connections sometimes here in my apartment but I can cross that bridge late <darth-cheney>Also this is a crazy little laptop it's a miracle anything at all runs on it. Lenovo 11e ***sneek_ is now known as sneek
<darth-cheney>Ugh, ok this time to boot is stuck at "making /gnu/store/<etc etc> the current system" <darth-cheney>There are some other preceding errors that are beyond the horizon of my knowledge. Some things about ACPI errors and a GC warning about reading /proc/stat <roptat>mh, so maybe it was not ssh, but whatever is after that, that doesn't print anything and blocks boot <roptat>unfortunately, I don't know how to help you <roptat>looks like most people here are asleep now, maybe you'll have more luck asking help-guix@gnu.org. your first message needs to be moderated by a human, so it can take some time to appear, but following messages will get through immediately <aecepoglu[m]>I'm awake but that is beyond my level of knowledge. I only know how to create basic packaging scripts <terpri>i have an 11e too! incredibly slow though, i wouldn't want to run guix system on it lest it try to compile something, but it makes a decent file server and portable ssh terminal <terpri>(the "e" is for "education"; cheap-chromebook level hardware, and it's the only "thinkpad" i've seen that lacks trackpoint) <apteryx>arf, been loosing the evening trying to get wireguard to do a handshake ***iyzsong-- is now known as iyzsong-w
<apteryx>haha! wireguard doesn't do anything until you send some trafic to it <apteryx>so I just tried to ping the IP and the handshake was made and it works... phew! <mothacehe>fine, thanks :) having a look to your recent installer patch <ss2>I was just wondering, what ere these t-guix-*, t-home-*, and t-profile* directories or files in my guix sources? <civodul>they are leftover temporary files/directories from tests <ss2>are they coming from me building packages? <civodul>tests should remove them, but apparently some of them don't <ss2>ah, so they can all be discarded eventually? <ss2>okay, and then, if I want to test build a package that is actually in my system declaration, how to I put it in there from a guix environment? <ss2>anyway, preparing my first (second) patch submission. <civodul>you could "extra" the package from you OS declaration and "guix build" it <ss2>I think I'd like to do it the other way round. I mean, that there's a packge in my declaration that I'd like to patch and test it in my declaration -- or system. <vagrantc>i always have to chmod -R u+w the test directory before deleting it <jlicht>I recall someone having looking at python-funcparserlib, which is broken on master; is there something I could do to help fix the issue? ***iyzsong-- is now known as iyzsong-w
<efraim>alright! fixed copy-build-system on core-updates for powerpc <iyzsong-w>i'll have some time during the 5.1-5.5 holiday. <tissevert>I've written a simple shell script which I'm not trying to package but simply to run and I get errors calling binaries like sed or wc (both in my PATH, and, most importantly, in the PATH seen from within the execution context of my script — I checked, `which` even resolves those binaries correctly) <tissevert>ok this stopped not working, I have no idea what happened but at least it's not a profile/environment thing as I was afraid ^^' <leoprikler>perhaps `hash wc` or `hash sed` was invalid after gc? <tissevert>hmmm you mean guix gc ? but none was running AFAICT <bdju>anyone have thumbnails working in the qt file picker? <pineapples>bdju: How can I check if they work for me? I can't promise to do it now, but I'll be available here for as long as a few days; feel free to nag me about it, if I forget to do it <bdju>pineapples: if you don't mind, use qutebrowser and go to some sort of file upload dialog, then browse to a directory with pictures in it from there and see if they show something besides a stock icon <bdju>I'm using Sway on top of %base-services (not %desktop-services), so it's possible I'm missing something related to thumbnails there. or I need to install some sort of kde stuff maybe <pineapples>bdju: I'm on Guix' download webpage, and I'm clicking on the x86_64 download option, but I'm getting a gray, in-browser file dialog on the bottom of its window <bdju>pineapples: yeah, you'll have to find an upload button rather than a download button <bdju>I guess that's probably confusing <pineapples>bdju: Alright, sorry about that; I got confused. Anyway, I don't have thumbnails, neither. Images in my ~/Pictures have a placeholder thumbnail, which looks exactly like LibreOffice Writer's icon <bdju>okay, good to know. thanks for checking <pineapples>bdju: You are welcome! And, hey, thanks for introducing me back to qutebrowser :) <pineapples>Speaking of which, qutebrowser fails to start under Wayland. I suppose it's, too, missing `qtwayland' from its inputs.. ***zap1 is now known as zzappie
<bdju>pineapples: ah, interesting. I think my qutebrowser is running with xwayland. is it supposed to work with actual wayland? <PotentialUser-81>I would like to inspect some Guix variables in a Guile REPL, e.g. %base-packages & %base-services. How do I go about making them available? I ran "guix repl", and ",use (gnu packages base)" but the REPL says that %base-packages is unbound <mbakke>PotentialUser-81: those variables are available in the (gnu) module <PotentialUser-81>Thanks! I just needed to "(use-modules (gnu))". What does the ",use (gnu packages base)" do? I copied that from the manual <apteryx>civodul: well done fixing the 100% CPU usage of the installer! <civodul>apteryx: yeah that made my night! :-) <civodul>so, i've kicked berlin some more to get those substitutes for version-1.3.0 <civodul>have you already tagged rc1 locally? <civodul>if not, we could cherry-pick those three commits i pushed yesterday <apteryx>civodul: I got stuck yesterday at some offload machine returning #f again <apteryx>and "guix offload test" was not being helpful in pinpointing which one :-/ <civodul>apteryx: yeah, i noticed that offloading is unstable on berlin <apteryx>I don't have armhf-linux nor powerpc64le-linux offload machines locally, so I'm forced to build things off berlin <apteryx>(I do have virtualized ones, but these often seem to cause test suite failures) <apteryx>at least for the handful of dependencies required by the guix packages <civodul>you need to have offloading set up to these machines though, there's no way around it <civodul>for PPC64 there's just one machine so you need to have that set up <civodul>for ARM, you could add yourself to overdrive1 for instance <apteryx>Yeah, that's where I'm going with the wireguard snippet I've sent to guix-sysadmin <apteryx>I get that you do it via a bunch of SSH tunnels? <civodul>direct SSH connection, no need for tunnels <civodul>so for ARM, you need to add your key to %authorized-guix-keys in (sysadmin overdrive) in maintenance.git <apteryx>I can fix that one via a tunnel for now <apteryx>but I'd really rather bridge to berlin via a VPN so that I can simple access the whole fleet of offload machines without further micro-management <civodul>no, that'd require you to get your know authorized on each machine and/or berlin itself, and that's not a good idea <civodul>ideally the build farm would be entirely isolated <civodul>apteryx: you should be able to connect as maxim@p9.tobias.gr now <civodul>nckx: i added apteryx to the P9 box ↑ <apteryx>I thought overdrive1 only supported building for aarch64-linux though, rather than armhf-linux; is this not the case? <civodul>it can build for both aarch64-linux and armhf-linux <civodul>it's a Cortex-something that Just Works :-) <apteryx>ah, that's nice. Perhaps that's not captured in the current /etc/guix/machines.scm, it seems I was depending on the BeagleBoards for the armhf-linux builds. <apteryx>yeah for overdrive1 aarch64->armhf is disabled until #43513 is fixed <apteryx>so that leaves us with only the beagleboards, which are only exposed via wireguard (10.0.0.5 and 10.0.0.6) <apteryx>what machine are you using for armhf-linux offloading? how do you configure it? <civodul>i think disabling aarch64->armhf is unnecessary <civodul>#43513 was about more specific cases (emulated 32-bit builds on 64-bit hardware) <civodul>but yeah, dunno, it's at least over-conservative <civodul>i use the overdrive for armhf offloading, it just works <civodul>problem is that #43513 got stuck after a flood of back-and-forth :-/ <apteryx>I see! Danny's analysis was concluded by 'That means building stuff for ARMv7 on aarch64 is not reliable at all'; I have only surveyed the thread and I'm not sure I understand what's at stake. <apteryx>I guess if it builds and runs, it's good enough for our purposes. *civodul goes afk for a bit <mothacehe>I removed the cached build failure, let's see if it helps <apteryx>civodul: I've now added myself as a sysadmin to overdrive, so the next time it gets reconfigured I should gain SSH access to it <rekado>oops, accidentally just deleted my Guix git repo :-/ <jlicht>rekado: shucks. Anything of major value lost, or just an inconvenience? <rekado>biggest downside of using worktrees: all git repos derived from the one I just broke are broken too. <rekado>(why does the .git directory take up 3.6GB?) <jlicht>mine is slightly less than 300MB <jeko>creating a 15G Guix disk image takes a while… <jeko>for such tasks I would love my PC to beep so I can forget it <avalenn>do_and_tell () { "$@" ; notify-send "DONE: $*" ; } <efraim>looks like we might need a separate go-cross package for cross compiling. I got runc almost cross compiled to aarch64 but it tried to link it with a linker for x86_64 <efraim>regarding emulated builds, I have far more luck building aarch64->armhf than x86_64->armhf <efraim>(ins)efraim@3900XT ~/workspace/guix$ file /gnu/store/jjqpc1bq6vz8aaag2pkwrbj3722m2ih8-runc-1.0.0-rc93/sbin/runc <efraim>/gnu/store/jjqpc1bq6vz8aaag2pkwrbj3722m2ih8-runc-1.0.0-rc93/sbin/runc: ELF 64-bit LSB executable, MIPS, MIPS-III version 1 (SYSV), statically linked, Go BuildID=MC2DmGt_RZ6YgRjO-mll/5lGT2vfP49Oma5w9xnIl/PT7VnU2fQ2sn1Z3hEbiu/vUen_BkqCD7CrMIcfSa_, not stripped <efraim>well, I guess I can cross build to mips64le-linux-gnu <efraim>oh, it's linked wrong, linked to x86_64 bash and others <bone-baboon>How can I close a bug on the bug mailing list that I opened? <civodul>you're cross-building runc, isn't that written in Go? <civodul>bone-baboon: hi! email NNN-done@debbugs.gnu.org, where NNN is the bug number <civodul>if you use Emacs, try M-x debbugs-gnu, it's very convenient <bone-baboon>civodul: So for bug#47964 I would email 47964-done@debbugs.gnu.org? Is there anything specific that needs to be in the subject or body of the email? Thanks for pointing out the Emacs option. <bone-baboon>For the Emacs option it looks like I need to install an package I will look into in. <apteryx>civodul: I'll send a patch to add my guix system public export key to overdrive1, as that's required for offloading from home. <apteryx>in that patch, there'll be hydra/keys/guix/maxim-desktop-export.pub; that key should be authorized by the OSUOSL machine as well. Does that sound OK? <efraim>civodul: yeah. I think I have most of it, it's still linking to the wrong bash, and not working at all for aarch64 <efraim>so that makes it a better test case *vagrantc wonders if patchwork.kernel.org URLs are stable enough to rely on in guix <vagrantc>i guess since it's a one-liner, better to just merge the patch <civodul>vagrantc: yeah, i wouldn't rely on these URLs <civodul>apteryx: sounds good! you can even commit it directly to maintenance.git and i'll pick it up from there <vagrantc>i did learn how to actually add patches from URLs, at least in the process :) <civodul>bone-baboon: nothing specific; in the body you can just say "Closing because <reason>" and that's it <civodul>katco: nice! is that a project you're working on with distros or other tool developers? <katco>civodul: no, i'm not involved, i just saw it come across and thought i'd pass it on <civodul>i'm not fond of CPE, but i'm not convinced it can be avoided (which they apparently try to do) <apteryx>civodul: the message was all ready to be sent, so I just did :-) ***AppAraat[m]2 is now known as AppAraat[m]
<civodul>rekado: machines .158 and .159 changed their substitute keys; do you know if they were reinstalled recently? <civodul>(these are the ones running childhurds) <rekado>I haven’t installed machines recently, but I know that some machines were dead and have been brought back <civodul>rekado: they have different signing keys than those in maintenance.git <civodul>which suggests they've been reinstalled or something <rekado>guix deploy wouldn’t have that effect, right? <rekado>I haven’t been in the data centre in months <jlicht>if `guix build -f <some-huge-file>.scm' (seemingly) does nothing besides pegging a cpu core to 100%, what are my options to find out what is going on? <efraim>I got syncthing to cross compile <apteryx>civodul: yeah, I had observed the same (and sent guix-sysadmin about it but I wasn't registered -- I guess it got stuck somewhere). I had commented out the machines in /etc/guix/machines.scm on Berlin for that reason. <efraim>I tested syncthing compiled for armhf-linux, I tossed it on my powerpc laptop and used qemu-binfmt emulation, like I normally do <dongcarl>Wondering if people could determine if http://issues.guix.gnu.org/47935 should be added to v1.3.0 blocking? For no-substitute builders on overlayfs (docker, podman), this coreutils is early enough in the dependency graph that it'll stop them from building much of anything useful. I'm happy to contribute the fix! <civodul>dongcarl: hi! we need a fix for that, but that'll be in core-updates <civodul>i agree it puts pressure on putting out another release soon <civodul>but... let's finish this one first :-) <rekado>jlicht: it’s probably a dependency cycle <rekado>jlicht: you could unearch cbaines’s patch to detect and report cycles. <pineapples>bdju: I think so, yes. Most of Qt apps packages by us were compiled without qtwayland available at their compile-time, causing them not use the wayland Qt plugin <jlicht>thanks rekado, but it works if I do (load "myfile") in a guix repl and build the package there <jlicht>might it have something to do with the file having about 30.000 lines? <bavier[m]>thank you to whoever packaged 'pdfarranger'; it's just the thing I've been looking for for years. <vagrantc>i don't believe in miracles, but ... guix weather linux-libre-arm64-generic ... 100.0% substitutes available (1 out of 1) *vagrantc wonders why linux-libre-arm64-generic and linux-libre use different tarballs <efraim>exec format error when trying to build syncthing for x86_64-w64-mingw32 <vagrantc>oh, it's not that they use different tarballs, it re-tried building the tarball derivation when it tried building linux-libre-arm64-generic and succeeded *vagrantc wonders if there's some issue with emulated builds building the linux-libre tarball just being too slow <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, efraim says: I normally use mpv, but when I do use rage I use it like mpv, rage /path/to/file <lfam>Do people have any advice about this config option? Should we enable it in Guix? <vagrantc>if you need to build out-of-tree modules, say N. <efraim>If unsure, or if you need to build out-of-tree modules, say N. <vagrantc>there are a few out-of-tree module packages in guix <vagrantc>lfam: are you about to upload a new kernel version? i've got some patches almost ready for pinebook-pro and would be nice to merge them at the same time <lfam>vagrantc: It's going to be days to a week or two before I add 5.12 <lfam>(I only just started it today and 5.11 will get at least one more stable release) <lfam>I agree, it would be nice to coordinate <lfam>You can submit your patches and I could put them on my local branch so everything gets pushed at one <lfam>I usually don't include the mainline kernel in Guix. Instead I wait for it to get a stable release <lfam>There are good reasons to do that but, really, it's because it means I don't have to rush :) *vagrantc didn't even know 5.12 was out :) <lfam>The releases just keep on coming <rekado>jlicht: interesting. Maybe this is a problem when compiling things? <apteryx>civodul: for the childhurd vm, we can also used private ones, no? So it's not 'blocking the release' per see? <apteryx>but yeah it should be determined whether they were tampered with or safe to reinstate as-is. <rekado>they have been up since 60+ days <lfam>I'm feeling like we need to improve our documentation about the core-updates and staging branches. It seems like people are expecting them to be something besides a mismash of random core packages updates <lfam>Debian failed terribly in this regard, and I see people all over the net suggesting to use Debian "testing" because they think it's a middle ground between "stable" and "unstable" when it's really like our core-updates branch <lfam>We shouldn't let that happen <rekado>apteryx: yes, they are in the same rack <rekado>I think it may just be due to old IPs that we recycled, but I really don’t remember after 60 days uptime <jlicht>rekado: perhaps I'll just have to bite the bullet and strace it :-) <davexunit>does anyone successfully run Dr. Racket via Guix? <davexunit>I tried `guix environment --ad-hoc racket` but drracket doesn't work within <bone-baboon>lfam: Thank you for helping me figure out the build of webkitgtk. Two other packages I remember having to set `--cores` for while building were mariadb and llvm. Those two packages may also be able to benefit from a similar patch as the webkitgtk one. I do not have the details for mariadb or llvm currently as I was able to get them fixed with help from people in this IRC channel and did not submit an email about them to a <lfam>bone-baboon: Okay. We'll leave those alone for now, unless we get other bug reports. I think that compiling with a single core is pretty atypical, so I'd rather avoid having to rebuild those packages unless there are bug reports from users <lfam>We can't change those packages on the master branch, anyways. It would cause too many packages to be rebuilt <lfam>In general, it's typical to use substitutes, and then among people who build everything from source, it's also typical to use multiple threads <lfam>So, the set of people who don't use substitutes and only have one thread is very small <nckx>bone-baboon: Set ‘--cores’ to what, exactly? Identical to webkitgtk? <bone-baboon>lfam: The only reason I was trying one thread was because `sudo guix system --no-substitutes reconfigure configuration.scm` was failing. I should have included that in my initial email about webkitgtk failing. <bone-baboon>nckx: Thanks I think you helped me figure out how to build llvm and I applied the same approach to get mariadb to build. Not sure exactely as I did not keep detail records of the build problems I was having with those two packages. If I remember correctely it was to use `--cores=1 --max-jobs=1` without specifying those the build for those two packages werer failing. These build failures were all happening on a x86_64 comp <davexunit>after searching the guix list, I realized that it was grafts that is breaking racket. <davexunit>sigh, but the package manager doesn't work because it can't verify certificates to update the package list <lfam>Are those TLS certificates? <apteryx>janneke: does this ring a bell to you: secret service: invalid handshake #<eof>, after attempting to deploy 'hurd-vm' on a remote machine (service failing to start) <lfam>Hm, I wonder how racket looks them up <lfam>(Assuming you are talking about a racket package manager and not Guix itself) <davexunit>yes, I'm trying to use the gui package manager interface within drracket <lfam>Seems like it should "just work" if it relies on SSL_CERT_FILE, but maybe you don't have that set <davexunit>lfam: do you know what I could set that env var to? <lfam>On Guix System, the variables should be set automatically if nss-certs is in the packages field of config.scm <davexunit>thanks, I used to know this and then got rusty ;) <davexunit>I totally forgot about that section of the manual ***iskarian_ is now known as iskarian
<iskarian>Hey, I have a package in kernel-loadable-modules which uses the linux-module-build-system, but how do I make sure the build system uses the same kernel version as the OS? Would I just want to put the package in e.g. a make-package that takes a kernel as an argument etc., or is there a more straightforward way? <pascallor>Hi! Does anyone know how to get the stumpwm contrib modules to work on guix? <pascallor>I've installed them (e.g. sbcl-stumpwm-cpu), but I get an error message when loading my stumpwm init file: `Error: Could not load or find module: "cpu"`. <pascallor>I've searched the whole file system (`find / -ipath "modeline/cpu"`) unsuccessfully. <pascallor>I did not have stumpwm-contrib in my guix configuration because I thought I did not need it since all the actual modules inherit from it. <pascallor>Now I tried adding it to the config in case I had to ("error: stumpwm-contrib: unbound variable" "hint: Did you forget a `use-modules' form?") and installing it ("guix install: error: stumpwm-contrib: unknown package"). <iskarian>pascallor: are you looking for sbcl-stumpwm-cpu? It doesn't look like there is a stumpwm-contrib package <pascallor>I have installed sbcl-stumpwm-cpu, but I have no idea how I can use it. I assume this is just me not knowing guix well enough. The stumpwm init file worked under arch linux. <pascallor>As for stumpwm-contrib, I saw it in wm.scm and thought that I might have missed it. But I just checked again and it is defined, but not public, so I guess my initial understanding that it was only there as a base for the actual modules was right. <civodul>lfam: clarifying branch usage is a good idea <lfam>"Just to understand: /if/ at any point in time a user is able to afford the effort to build the entire core-updates /or/ staging branch she should be confident the result is state-of-the-art secure. Am I wrong with this assumption?" <lfam>I just want to make sure that people don't get that impression about these branches <pascallor>iskarian: Thank you! I did look at it a couple of times but the first time was before I got stumpwm to work and after that when I looked at it I thought I had finished doing all that was written there while my config was still the non-guixified one. <pascallor>Probably too late for me, not too early for you ;) <civodul>incidentally, "state-of-the-art secure" doesn't exist <lfam>Well, yeah :) But those branches are not even buildable most of the time <lfam>Let alone secure, compared to the master branch <lfam>We should warn people against trying to use them <civodul>yeah, they're often "kinda buildable" :-) <lfam>It's not great if people are unclear on which branch to use :/ <civodul>though i don't think many people try to use core-updates: (1) it's expensive, and (2) it's often broken <civodul>we would know if people were routinely trying to upgrade to core-updates <lfam>I'd still like to clarify it in the docs <vagrantc>i used core-updates for a while while i had something i needed ... but was relieved to switch back to master once it was merged <lfam>I'm curious, did you expect it to receive security updates while you were using it? <pascallor>iskarian: removing `load-module` for each module did the trick :) <bone-baboon>I have a x86_64 computer I am going to use as a substitute server. Is it possible to also have it build and serve i686 packages? If so could someone point me to relevant documentation? <iskarian>pascallor: Glad to hear that worked! Really, it's too bad there are so many sharp edges still... the manual is great, but there's still so much hidden knowledge <vagrantc>lfam: that was before the gpg-signed commit verification was a thing, so i didn't have much hope for guix at all :) <vagrantc>couldn't take security seriously when your package definitions didn't have more of a trust path than https to the git repository <lfam>Okay, but that's not what I asked about <lfam>We always took security seriously in terms of package updates <lfam>But I guess the answer is that you weren't paying attention to the question of package updates / patching? <pascallor>iskarian: do you happen to know how I could contribute something to the Cookbook? There does not seem to be any information on that in it. <vagrantc>lfam: i paid attention, but not with great rigour <pascallor>I just realized after sending the question that the cookbook also appears among the manuals in Emacs, so it's part of the system and I should probably just send a patch via mail. <vagrantc>but now it's signed, i'm probably even less rigorous ... *vagrantc hopes it isn't too distracting from the issues at hand <vagrantc>i do find the whole discussion of the misleading commit messages to be strange ... clearly mistakes were made, clearly some people have been a bit too abrasive, but there's way too much tension still :/ <leoprikler>That's a discussion we have to deal with in the foreseeable future. People hold strong and differing opinions about it after all. <lfam>The discussion could not have been started in a more inappropriate way. There's a lot of good ways to highlight problems and give feedback, but that's a masterclass in how not to do it <lfam>And yet still, we *all* make mistakes, but the important thing is how we handle them. I'm not satisfied with what's been demonstrated in that regard <lfam>So, I'd say that everyone involved is at fault in some way <lfam>My impression is that the maintainer collective is discussing this situation and will respond <lfam>My opinion is that the whole situation is really disappointing and the project will have to learn from it and get better <lfam>If you want to give your opinion about it, I recommend sending a message to the maintainer collective at <guix-maintainers@gnu.org> <vagrantc>lfam: yeah, that pretty much levels with my take on things, fwiw <vagrantc>hrm. my pinebook-pro patches do display a screen ... but it has some strange issues running sway ... at quick glance, everything is fine <vagrantc>console seems to work fine ... touchpad ... is very much not working correctly <lfam>efraim: Thanks for your work on the syncthing package <efraim>lfam: I used it as part of trying to make go cross-crossbuild so I made some changes <efraim>I do sometimes try using both system and target to see how it builds <efraim>Ever try crossbuilding from x86_64 to x86_64? <jlicht>that sounds like it would not work for many of our packages <civodul>vagrantc: i'm also disappointed by that whole thread; it's by far not as constructive as i'd like :-/ <jlicht>and would therefor probably be a good way to find subtle bugs <civodul>(apteryx merged it in version-1.3.0) <lfam>A couple of us should do `guix pull --branch=wip-ungrafting && guix upgrade`, and maybe we should also reconfigure berlin.gnu.org based on it. <rekado>guix pull: error: aborting update of channel 'guix' to commit e12210dc92098d8581cea3007d57dbb6be16bb41, which is not a descendant of 8b0ae1eb72d2844d83c5da2b3393088446bc73d1 <efraim>guix time-machine --branch=wip-ungrafting -- package -L ~/workspace/my-guix/ -m ~/workspace/guix-config/Guix_manifest.scm <rekado>(should I just pull from version-1.3.0 instead?) <lfam>rekado: I can rebase the branch, which will fix the ancestry problem <civodul>because it's already merged into version-1.3.0 <civodul>rekado: once wip-ungrafting is merged into master, you'll be able to travel from there to master <civodul>it's just that the tip of master right now is not a descendant of the tip of wip-ungrafting *civodul waves hands, draws arrows and circles <lfam>Then we can test with --allow-downgrades <civodul>apteryx, rekado: false alarm regarding .158 and .159 (i sent details to guix-sysadmin) <civodul>silly me hadn't bothered checking whether the keys matched, assuming something was wrong <rekado>wikipedia says that “some perception of loss of honor or dignity […] is involved” in embarassment, so let me say that this perception is unfounded :) <apteryx>re overdrive, do you know how it's reconfigured? <lfam>Minor nitpick: I wish we had renamed wip-ungrafting to ungrafting before merging it into the release branch, but it's not a big deal <apteryx>ah, perhaps it can be deleted now that it lives in version-1.3.0? <apteryx>To avoid confusion. Let's focus next on core-updates and do all the ungrafting there, if that sounds like a plan. <lfam>We were just discussing merging it into master today-ish, after testing it <lfam>After the release I'm going to start a discussion about tweaking the branching workflow <lfam>The current workflow evolved based on constraints that don't exist anymore — specifically regarding the build farm and CI <lfam>I think we should be trying to ungraft regularly <lfam>That was always the goal but we never had the capability, until now <lfam>But, the outcome of that discussion should probably not affect the current core-updates branch. If we decide to change things, we'll apply those decisions to the future *lfam is building private packages based on wip-ungrafting <civodul>apteryx: overdrive can be reconfigured by any of the admins, lemme take a look <fnstudio>hey :) i've been having issues with an app after the latest guix pull (it's meld, but my question is actually more general) <roptat>huh, trying to build openjdk 14, it wants to build openjdk 10, but also download openjdk 9 to 14 (excluding 10) <fnstudio>i've tried with "guix time-machine -- build meld", not exactly sure of what i was doing :) <fnstudio>does that give me access to a recent revision of an app? <lfam>`guix time-machine` is for using different revisions of the Guix package repository. You have to pass it an argument such as "--commit=$oldcommit" <lfam>The Guix package definitions are stored in our Git repo, so that's a Git commit <roptat>oh, the substitute for 10 was baking, so my local guix wanted to build immediately instead of waiting a bit longer <lfam>Without any arguments, it uses the latest version of our packages, but that doesn't necessarily mean that there is a newer version of meld available in our package definitions, fnstudio <civodul>roptat: there's a fix for that on master <civodul>we should include it on version-1.3.0 too <lfam>fnstudio: Is there a newer version of meld that you want to try? <fnstudio>lfam: actually i was thinking of rolling back to an older version first <fnstudio>lfam: i suppose i'll look at the repo, choose a prev commit and use that as an arg for time-machine <lfam>Yeah, that's what I would do <lfam>And then, file a bug report at <bug-guix@gnu.org> :) <fnstudio>lfam: super! thanks, i'll crack on it straightaway <fnstudio>lfam: right, good point re the bug-report <rekado>bah, I can’t pay for the honeycomb boards <rekado>for some reason my payment attempts are not accepted. <lfam>It's probably the payment processor going "rekado doesn't usually spend money in Israel" <lfam>Mine does this whenever I make big purchases to foreign entities <lfam>I have to call the bank and prove that it's me <rekado>even lowered it to two boards (~ 1,500 USD) and something somewhere is rejecting my credit card. Paypal is being opaque. <lfam>I would contact Solid Run sales and ask for a different payment method. It's unlikely paypal will allow the payment <rekado>that’s the only option I’m shown on the Solid Run page. <lfam>Paypal never ever goes back on their fraud prevention decisions <lfam>If you contact Paypal and prove your identity and say the purchase is legitimate, they may allow it in a couple weeks <rekado>I even added an extra account because they insisted… bah. <lfam>Ah, they also flag new accounts <lfam>I went through this several months ago <lfam>Right, if you add a new bank account to your paypal account, your fraud risk increases. Plus the foreign destination = no go ***KE0VVT is now known as frayevelt
*lfam rebuilds Audacity on berlin based on wip-ungrafting <lfam>Something timed out when passing substitutes around <s0ngr4m3>hi everybody, I experiment linux from twenty years. I would want to install Guix which is very interesting but I've got an intel integrated wifi on recent thinkpad <lfam>Yes, that's the solution to use the kernel we offer, linux-libre. You'll have to choose a dongle carefully because linux-libre has very limited support for wifi <lfam>The other option is to use a custom kernel that includes support for your hardware <lfam>But, we don't offer advice about that here, sorry <lfam>Changing the subject, it seems like offloading to aarch64 is not working on berlin.gnu.org <darth-cheney>Hey guix crew, I was here last night while everyone was sleeping trying to get to thebottom of a guix system install issue. I figured I'd try you all one more time before heading to the mailing list <s0ngr4m3>ok many thanks. I will test with usb dongle not cheap ! <lfam>Previously I was able to do `guix build /gnu/store/...-foo.drv` and build aarch64 derivations <darth-cheney>Short of it: new system install, usb boots fine, installation goes without error, but on boot it freezes at `making /gnu/store/<etc etc> the current system` <lfam>s0ngr4m3: I recommend finding a dongle that uses the ath9k or ath9k-htc drivers <darth-cheney>Prior to that there are some GC Warnings, one being "Couldn't read /proc/stat" <lfam>You can also ask in #linux-libre, s0ngr4m3 <lfam>Does it ring a bell to anybody? <darth-cheney>btw this is the machine I'm installing on (except mine has a whopping 4GB ram) <lfam>apteryx: Are you working on the overdrives now? I noticed that I can't offload aarch64 derivations on berlin.gnu.org currently <lfam>I feel like that should be more than sufficient darth-cheney <darth-cheney>It's an AMD chip though and I recall heearing something about AMD compatibility? <lfam>AMD makes the most widely supported CPUs in existence <lfam>It sounds like either 1) a bug in Guix or 2) something wrong regarding the bootloader or file-systems in config.scm <darth-cheney>Ok, now the /proc/stat warning is a little outside of my knowledge, could that be due to some weirdness with the partitioning scheme <darth-cheney>lfam: yeah this is from the current stable iso image and I kind of ran through it will all the default recommendations + xfce <lfam>I don't know how automatic the bootloader and partitioning can be. I don't mean that "I think it's not automatic" but that I literally don't know <lfam>I do think it requires some decision making. At least some checking <lfam>Yes, I thought so, because that's the only thing that recommends a partition scheme <darth-cheney>there's nothing about a bootloader in the graphical setup I don't think <lfam>I guess it decides automagically <darth-cheney>yeah it does because I switched the bios to "uefi only" jsut to see if that made a difference and it changed the recommended config on its own <lfam>Does anyone have any ideas about how to debug this? 