<cybersyn>thanks, wish I had more questions there wasn't a ready solution for. I've been on guix as my primary system since november but unfortunately I haven't had too many issues that a search of irc and mail logs didnt solve :)
<aecepoglu[m]>lI'm trying to figure out how to use `pre-inst-env` script. I have created a new environment using `guix environment` and `./pre-inst-env guile` works correctly. However `./pre-inst-env guix ...` fails because no such executable exists.
<cybersyn>sneek tell fossdev "you can already run the Hurd as a service! check out 'childhurd' in the guix blogs. if you're generally interested in microkernels, perhaps take a look at Genode, which is probably the most active user-oriented microkernel system"
<sneek>fossdev, cybersyn says: "you can already run the Hurd as a service! check out 'childhurd' in the guix blogs. if you're generally interested in microkernels, perhaps take a look at Genode, which is probably the most active user-oriented microkernel system"
<cybersyn>sneek can you repeat that message for fossdev when they return?
<tissevert>cybersyn: I think the syntax is «later tell blablabla»
<cybersyn>thanks! it was my first sneek attack but had to try in order to learn
<raghavgururajan>sneek, later tell pineapples: Shoot! I was updating telegram locally few days ago. I yet to clean up some stuff. I'll type out steps to update Telegram and send it you, so that you can update it for upcoming release. Sounds good?
<pineapples>raghavgururajan: Hello! I don't know if you saw the message that sneek relayed, but I've changed my mind and am going to wait with updating Telegram Desktop a little longer
<sneek>Welcome back pineapples, you have 1 message!
<sneek>pineapples, raghavgururajan says: Shoot! I was updating telegram locally few days ago. I yet to clean up some stuff. I'll type out steps to update Telegram and send it you, so that you can update it for upcoming release. Sounds good?
<davexunit>anyone updating guile-3.0-latest to 3.0.6 yet?
<davexunit>curious if that's something I could update and push without major rebuilding
<raghavgururajan>pineapples: sneek gave me only this: "Any tips regarding updating the Telegram package recipe? I would like to do it :)"
<mothacehe>civodul: you can run "guix system image -t uncompressed-iso9660 gnu/system/install.scm" to speed-up ISO creation.
<pineapples>raghavgururajan: This is the message, yeah! My IRC client wouldn't light up my nick in the message in which you asked sneek to relay your message to me, and I assumed you hadn't seen it, or had forgotten to reply to it
<pineapples>Either way, a huge update is up ahead, and it'd be a waste of our limited resources to update to 2.7.x
<pineapples>I will notify you when it's out, and will get on board with helping you update it :)
<apteryx>civodul: phew, guix 1.3.0rc1 was built for armhf-linux
<roptat>well, the website is still stuck in the past, but otherwise, great improvements :)
<vagrantc>making huge progress on pinebook-pro, by the way ... got patches to linux-libre for master to get it pretty functional with only a few lines of code, and u-boot 2021.07-rc1 + 1 patch that even makes you able to see and interact with the bootloader
<dongcarl>I built and installed version-1.3.0 (2d086def643f) from source on Ubuntu hirsute and ran a build of a complex manifest afterwards. Quick summary: Guile-zlib required a newer version than is currently packaged in apt, Guile-lib problem reported as #47924 (already solved), coreutils problem reported as #47935 (easily solvable by mounting a tmpfs on
<mhj[m]>I want to thank the devs for making such a cool system. I'm still learning everything, but I'd like to have btrfs /home snapshots easily implemented as an option in the installer. I dunno if encryption works with btrfs either in the installer... in any case, I just find the possibility of rolling everything back, whether it's the system itself, the home partition or the packages installed to be amazing. My internet connection
<mhj[m]>isn't flaky, so I don't often have to worry about broken packages even on standard distros like Arch, Debian or Void, but I just dislike the fact that one broken upgrade can hose your system on those distros.
<lfam>I agree, some kind of btrfs-snapshot / backup service configured at the system level would be really nice
<nckx>OK, I failed at disabling binfmt_misc (the sysctl interface is a special little boy), second time's the charm. I got the same error you quoted in your mail... autoconf_64b is an aarch64 binary, why...
<jonsger>can someone share me a working coredump config which collects coredumps? mine is not working
<nckx>mdevos: I don't see how the existing Makefile can be used for cross-compiling. If only the author spent half as much time fixing their own broken mess as they do calling others ‘retarded’ and ‘crap’.
<bavier[m]>pretty sure there's an autoconf check already for what they want
<bavier[m]>oops, nvm, confused by the "autoconf" strings there. that's not autoconf :)
<nckx>It's a horrible broken parody. And I'm 100% sure the author is the kind of person who would call GNU autoconf ‘bloated’.
<lfam>Those for whom "other people's use cases" are "bloat"
<mdevos>nckx: Not that I know of, but you could implement it in (guix utils), and do something like (or (assoc-ref `(("x86_64" . 64) ("aarch64" . 64) ("i686" . 32)) ARCHITECTURE) (error "please define the bits of ARCHITECTURE!"))
<nckx>Maybe, or maybe just $ARCH-gcc --gimme-info=bitness. Or... I could make my fix less trivial and patch the makefile to use non-target ‘gcc’ to compile the autoconf_* probes.
<nckx>No, it's a different format. I just meant that if my recollection is correct (and it may well not be), the actual format isn't defined, just that compress | zcat has to work. Anyway, irrelevant by decades.
<Noisytoot>Why does Guix use lzip rather than xz for substitutes?
<Noisytoot>(or ZStandard, which Arch GNU/Linux switched to)
<mdevos>I'm trying to make libtommath cross-compilable. I set CC=(cc-for-target) and set CROSS_COMPILE=TARGET- (specific to libtommath) in #:make-flags. It starts compiling just fine, using the cross-compiler, but then, when linking, it used the native compiler! (libtool: link: gcc -shared -fPIC -DPIC THE-.o-FILES), resulting in: 'ld: .libs/SOME-.o-FILE: error adding symbols: file in wrong format". Any idea?
<terpri>oh nifty, i didn't realize lzip did (or could) support zstd
<terpri>now i just have to wait for the next grub release for btrfs+zstd support...
<roptat>sss, I found that running programs compiled outside a guix package doesn't work well when looking for libraries, but using LD_LIBRARY_PATH fixed the issue for them (in your case I'd run LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib ./client/X11/xfreerdp)
<roptat>I'm not sure what's so different between a local build and a build by the guix daemon though, so maybe there's a better solution
<terpri>oh. i'm really behind on release notes, i guess :p i'll enable compress=zstd and then 'btrfs fi defrag -czstd ...' should do the trick
<roptat>i.e. bringing the two builds closer to one another, so it works immediately
<Frosku>How can I remove network-manager-applet from desktop-services? I want to replace it with nm-dmenu