<lfam>nixd: With Guix, package management is per-user, so having the package available system-wide (like in the installer ISO) is not the same as installing it with `guix package --install`. <lfam>Also, doing `sha1sum guixsd-install-0.15.0.x86_64-linux.iso.xz` gives me 1029730bf9f11a8039d66a9bf4fc77e8e1b2eb53 <lfam>nixd: The hash you gave is of the uncompressed ISO, so the file is not corrupted <lfam>nixd: I tried to reproduce the issue by booting the ISO in QEMU, but `mkfs.ext4` was on my PATH (found by `which`) <nixd>Ifam Thanks for checking. No idea whats wrong with my image then. <lfam>nixd: After you booted the ISO, did you do anything with `sudo` or `su`? That could mess up the PATH variable <nixd>No. I did not do anything with su or sudo. I just tried to do sudo mkfs.ext4 after it wasn't found. Issue came up before I did that <lfam>Hm... a real puzzler. It would be nice to figure out what's up <snape>ACTION can sleep now, good night everybody <alexshendi>Hi, I have more or less successfully installed GuixSD 0.15. How do I install packages systemwide for all users? ***Guest49727 is now known as benny
<oreloznog>I have not experienced it, but I think you can find something very usefull in this doc <rekado_>The gnome updates are a little difficult. <rekado_>many of the packages have switched to meson so I need to find new ways to pass certain flags or prevent the build system from installing things into the wrong directories. <civodul>rekado_: are there many packages that need special treatment? <rekado_>for example, previously we would install the documentation of at-spi2-core into a separate output. With the meson build system they no longer offer a knob to override the location, so I need to patch some files and then add a build phase to move the documentation to its own output. <civodul>really, there's nothing like --docdir? <rekado_>in other cases we used to have a bunch of patches and configure flags which now seem to be obsolete, but I need to check that the build system doesn’t do anything stupid. <rekado_>annoyingly, there is no --docdir flag. <civodul>they seems to be switching incrementally to Meson, which was ok <civodul>on another topic: what do people use in Emacs to have functionality comparable to recent-addresses.el? <civodul>but mu4e uses message-mode, doesn't it? <snape>mu4e-compose-mode is derived from message-mode <rekado_>civodul: you needn’t be jealous. It’s not that great in my opinion. <rekado_>it just tries to provide auto-completion, but it’s not very reliable. <rekado_>sometimes you can end up with no suggestions for email addresses. <snape>I use it all the time and I think it works quite well <rekado_>hmm, glib-networking now depends on libproxy, which currently has network-manager among its inputs. <rekado_>it builds fine without network-manager. <rekado_>(network-manager ultimately depends on glib-networking) <civodul>rekado_: oh yes, i tried that a month ago or so <civodul>i don't remember, i thought i had posted an email about this but i can't find it <rekado_>I removed network-manager from libproxy and added libproxy to glib-networking <rekado_>it installs the glib-pacrunner.service <rekado_>libproxy builds fine without network-manager, so I guess I’ll just continue with the upgrades and see if we actually need network-manager in libproxy <rekado_>I just don’t know if this will cause problems down the road <efraim>do we want to tell net-tools to stop building ifconfig? we currently have a collision with it and inetutils's ifconfig <civodul>libproxy has a network-manager plugin, which allows it to notify NM when something happens <civodul>efraim: i think it's good to keep both, though perhaps we could rename the net-tools one to "ifconfig.net-tools" or something <civodul>there was a discussion about this a while back <efraim>civodul: ok. also I'm having a hard time pushing the qt-updates branch to savannah, it wants to check all the signatures back to the beginning of the repo. ideas? <efraim>i've been trying 'git push origin qt-updates' <efraim>i also tried 'git push origin master:qt-updates' to try to get around it but it didn't work <g_bor[m]>efraim: I've also notice that signature checking thing. Please tell me if you have a solution. <g_bor[m]>efraim I guess we could solve that by disabling the git hook, but it does not seem to be a good soultion IMHO. <efraim>i thought it was only active on some branches <efraim>i tried pushing to wip-qt-updates, still checking signatures <civodul>efraim: you may need to temporarily disable the pre-push hook on your side <civodul>lfam wrote about it on the mailing list a month or two ago <efraim>I didn't realize it was on my side <civodul>snape: have you looked at Tatiana's contributions to Cuirass? <civodul>i haven't looked in detail, but i think we should merge things soonish <jonsger1>on opensuse I got always "guix offload: command not found". It's installed at "/usr/lib/guix". Configuring with " --libexecdir=/usr/lib" doesn't help here. What am I doing wrong? <g_bor[m]>sneek: later tell snape: It would be nice if you could look at Tatiana's contributions to Cuirass, and contact me or civodul. Thanks! <nixd>Hello. Has anyone ever had a guix system initerror like this?: "guix system: error: No such file or directory: "/mnt/gnu/store/kcm128bw8sykn57qxbhfbjslmmssc1lc-fuse-2.9.7"? The exact command I ran was: guix system init /mnt/etc/config.scm /mnt <mbakke>nixd: Did you run `herd start cow-store /mnt` before running the init command? <nixd>mbakke Yes, I did. As per the manual <mbakke>Okay. Odd, never seen such an error before. <roptat>so I'm still looking for a compiler/transpiler for scala, but can't find anything that doesn't depend on scala or can build a simple source file <brettgilio>roptat, is there an issue with using scala directly? <rekado_>scala depends on older versions of scala; when you go really far back it depends on pizza, which depends on pizza. <roptat>so I don't see any other solution than writting a compiler <rekado_>(and pizza contains proprietary software) <roptat>I found the ast code in scala sources, so I'm rewritting that in java <roptat>I also have enough code to parse scala programs <civodul>roptat: does it parse "real" programs? <roptat>then I need to somehow generate java code (or something else) from the ast which looks even more difficult <rekado_>roptat: there are (already packaged) libraries that generate JVM bytecode. <roptat>civodul: I've tried the parser on some files in the scala sources, and after some adjustments, it was able to parse them <roptat>rekado_: actually JVM bytecode might be simpler than java indeed <roptat>but let's focus on the ast first :) <roptat>I've found a bunch of compilers, like dotty (it adds functionnalities to scala), reasonnable-scala-compiler (which is actually not reasonnable as it is written in scala :p) <rekado_>roptat: please share your progress and your problems on #bootstrappable <roptat>scala.js only builds a subset of scala <civodul>it seems like a huge effort to me, but if you can get there, that's really great <roptat>and scala-native is written in scala too <rekado_>I also looked around for scala compilers, but I only found those that are written in scala or depend on the scala stdlib. <roptat>I mean I don't really have a choice if I want scala at some point <roptat>scala-to-java compiles scala code to .class and decompiles that to java (so it needs a compiler) <civodul>roptat: you write this code in Scheme or in Java? <roptat>and it's easier to use java with antlr :) <snape>hey civodul and g_bor[m], sorry I was having lunch <sneek>Welcome back snape, you have 1 message. <sneek>snape, g_bor[m] says: It would be nice if you could look at Tatiana's contributions to Cuirass, and contact me or civodul. Thanks! <snape>I didn't really look at it, I trusted g_bor[m] and Danny for this :-) <snape>it seems to me that it doesn't conflict with my changes <civodul>snape: speaking of which, i still need to look more closely at them, but i really like the direction it's taking! <snape>yes, I've seen your email, thank you <civodul>that's also why i thought you'd be the right person to go ahead and merge Tatiana's work ;-) <civodul>i'd like to make berlin.guixsd.org the main substitute server within a month or two <civodul>and for that we need improvements to Cuirass such as what you and Tatiana did <civodul>once we've officially switched, things will be smoother i think <civodul>we might have dogfood, but we'll also have everything at our fingertips <snape>So is Tatiana done with her work, or is it still a WIP? <civodul>GSoC is not over, so it's still ongoing <civodul>but there's already a few things that look nice in their branch <snape>are Savannah branches force-pushable? <mbakke>snape: They are. Although I hope it has safeguards in place for 'master'. <minji>Is GuixSD stable enough for a work machine? I can always rollback if something goes wrong until things are fixed right? <snape>minji: it's stable enough, you just need to make sure there is no critical software missing <rk4>depends what you do for work. if i didn't deal with emergencies i'd use it for work <snape>If my work didn't force me to use their Debian packaged stuff, I'd use it :-) <rk4>"emergencies" -> not real ones, just normal IT outages and angry customers <jonsger1>If I wouldn't work for SUSE, I would maybe use GuixSD at work :P <minji>It should be good enough for me then, thanks <civodul>minji: in a way it's perfect for a work machine because you have transactions and rollbacks, so you can't completely screw up <civodul>then there can be glitches, like missing packages or packages that break at one point <civodul>but despite being a much much smaller team than Debian or Arch, i think we're doing a pretty good job at keeping things running :-) <ng0>it gets funny when you start running other package managers on GuixSD though, which is what my new experiments involve :D <civodul>kmicu: heh, thanks for the kind works <civodul>i was speaking with a former Arch user yesterday who shares this sentiment <jonsger1>ng0: things get funny when you package guix for other package managers :P <ng0>I've been thinking about ways to conveniently solve nonexistent paths. possibly services with chroots, but I haven't given it much time yet <ng0>like you can almost run nix on guixsd, but you get some errors, depending on the kind of applications. some leading to non-functional applications. it's not that we would want to empower this, so it's just me tinkering about this. <brettgilio>jonsger1, I use Guix on Parabola. Great package manager to compliment pacman <ng0>fyi I figured out much too late that I don't need my openSUSE vm to compensate for our lack of eclipse IDE :) <civodul>brettgilio: to compliment pacman or to complement it? :-) <brettgilio>civodul, How have I gone all of my life, part of a PhD, and almost done with medical school before I realized that compliment=/=complement. <snape>:-) The difficulty depends on your native language though. In French "compliment" is the same as in English so it makes it easier to spot the mistake <efraim>I was going to look at pkgsrc on GuixSD just to see how it worked out <ng0>oh, was going to. so you didn't do it yet <efraim>ng0: its ok :) from what I've looked at it so far it seems pretty self contained like guix, except perhaps during the bootstrap phase <dvn>"info guix" hmm, now it's in french <g_bor[m]>dvn: you can use info '(guix)' to get the English one. <dvn>ok good to know. we should put that in the manual... <civodul>ACTION stumbled upon a situation where the record ABI check proves to be helpful <ng0>texinfo est difficile :) <ng0>in my user profile it is fixed <ng0>efraim: yes, I started working on bmake + mk a while back <janneke>ACTION removed gcc-4.1.0 from the bootstap equation, and built a very minimal i686-linux gcc-4.7.4 <civodul>now i'm confused: the 'dir' file created by 'guix pull' on master includes the French manual, and there's no 'dir.fr' file <civodul>janneke: so you disabled float128 support? <janneke>civodul: no, it's much more mundane although i do not understand the inner workings <rekado_>janneke: ohhh, gcc 4.7.4! Is this the end of the road for i686? <janneke>the way gcc-4.7.4 was configured (using i368-unkown-linux and probably also using --target) made it so that libgcc got compiled using the CC_FOR_BUILD instead of the newly created xgcc <janneke>so it's either a configure/autoconf/makefile bug, or a user-bug of those <janneke>rekado_: *aaaalmost*, i hope; it's built using --disable-shared, --enable-languages=c (and other disabilities :-) <janneke>but i very much hope that further development is mostly in the packaging area <civodul>we don't need openmp, cilk, asan, mudflap, and all that <janneke>the "best" glibc is currently a static glib-2.2.5, built by gcc-core-2.95.3, but i figure that's also no problem <janneke>civodul: re your question on the list, only the %-*seed packages are seeds, rest (tcc) is built from source <ng0>what magical lullaby do I have to sing to get rust building all the way to the new version? <ng0>but now I seem to be stuck on 1.23.0 <efraim>did it fail? my aarch64 board is up to 1.24.1 <ng0>I thought it was okay, had already a started 1.27.0 build which then had to be paused <ng0>and now on the server it never goes beyond 1.23.0 <ng0>seems stuck, or at least my ssh connection never drops <civodul>EuAndreh[m]: you can install Guix on anything that runs the kernel Linux :-) <EuAndreh[m]>I mean, will there be a conflict with the `daemon` or something like that? <civodul>if you follow the instruction, each daemon will do its own thing independently <jlicht>ng0: my x86_64 system is chugging along on rust 1.27.0 right now <janneke>EuAndreh[m]: let us know how it goes! <lfam>I wonder if call-with-temporary-directory is working as intended? The docstring says "close the directory and delete it when leaving the dynamic extent of this call". However, it uses rmdir, whose documentation says "Remove the existing directory named by path. The directory must be empty for this to succeed." <lfam>The point being that the temporary directory would not be deleted unless it was emptied first <ng0>oh, compiling rust is just very slow <ng0>*sad trombone sound* rust build crashed <ng0>could be restricted resources on the builder I have <OriansJ>I am hoping the testsuite doesn't require more than 4GB, otherwise it becomes impossible for 32bit platforms to test their builds <ng0>I'm waiting for the 32GB RAM update <ng0>but also: I have stared into the void of bureaucracy for too long today, I need a break <OriansJ>That doesn't look like a restricted resource failure but rather the binary produced is not behaving the way the test would require <jlicht>I have built rust 1.27.0 without any problems on x86_64 /w 8gb. <ng0>jlicht: non-reproducible maybe? <efraim>I have it building on aarch64 but it probably wont finish 1.27.0 for another 36 hours <pkill9_>i don't know how kernels/init systems work, so excuse me if this is an ignorant quesiton, but is there a way to set a hard limit on the amount of CPU/RAM a process uses? Icecat just froze up my system and after slugging through the lag i was able to kill it <lfam>pkill9_: Check out ulimit, which is typically available as a shell builtin <lfam>You might also look into cgroups. Although I don't think we really make use of them in GuixSD, there is some nice integration in systemd <ng0>you could switch the /proc/sys/vm/overcommit_memory level, but it has implications you might want to read into. <ng0>for whatever reason I'm now at 1.25.0 rust already, before I was building 1.23.0 i nthe chain <ng0>okay, I don't haev the rust bootstrap memorized <rekado_>lfam: I remember noticing this a few years ago, but I did not report it to bug-guix. <lfam>rekado_: I sent a bug report a little while ago <rekado_>hmm, getting test failures in the updated network manager <pkill9_>is /etc/pm/config.d honoured in GuixSD? <pkill9_>if not, is there a way to add a config that would typically be put there? <civodul>pkill9_: presumably there's no such thing yet <civodul>you should email guix-devel with an example of what's needed <pkill9_>i think i need to reload a kernel module after suspend <pkill9_>i think that's what the solution does, i did look into this a while back actually