<kozo[m]>Hey all, how do I get a specific .so into /run/current-system/profile/lib <kozo[m]>I am specifically trying to get libSDL2.so from cl-sdl2 into there <lfam>kozo[m]: Specifically to do that, you'd add cl-sdl2 to the packages field of config.scm and reconfigure your system <lfam>There may be a better way to achieve your ultimate goal <lfam>I don't see a package for cl-sdl2 in Guix, however <kozo[m]>Thanks lfam. I'll keep looking for a way to do with either asdf or cffi <kozo[m]> * Thanks lfam. I'll keep looking for a way to do it with either asdf or cffi <lfam>If you'd like, you can tell us what you are trying to do. Someone might have a simple answer <kozo[m]>I am trying to load cl-sdl2 using quicklisp. The problem is the default locations don't include the /profile/lib/ and can not find libSDL2.so or any alternatives. I have to run a separate command in my lisp file to add it to cffi:foreign-library-directories <kozo[m]>example: (pushnew #P"~/.guix-profile/lib/" <kozo[m]> * I am trying to load cl-sdl2 using quicklisp. The problem is the default locations don't include the /.guix-profile/lib/ and can not find libSDL2.so or any alternatives. I have to run a separate command in my lisp file to add it to cffi:foreign-library-directories <mroh>oh, ups, now we have 2 nheko patches, at nearly the same time ;) <vagrantc>though i've used network-manager-service-type for ages and it "just works" <vagrantc>arg. trying to build guix on Debian i386 with guile-2.2 (gah. reasons!) ... it sometimes fails with ... Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <vagrantc>maybe i need to switch back to non-parallel building... <TBC_x>I've just ran `guix pull`, it downloaded le-certs, and now it fails with SSL certificate is invalid. It's fresh manual installation from 1.2.0 in qemu <TBC_x>I'm kinda lost on what to do now <vagrantc>TBC_x: might have to export some environment variables... <lfam>vagrantc: IIRC, you don't need to pass any arguments to wicd-service. It is configured imperatively with one of the clients <lfam>TBC_x: Make sure the date is correct <TBC_x>Was first thing I've checked <vagrantc>In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<procedure wicd-service (#:key wicd)> <vagrantc>it clearly wants some sort of argument... <TBC_x>I want to use this image as my new system once I learn how to use device mapping <lfam>TBC_x: It's a fresh installation of Guix System? Or Guix on another distro? <vagrantc>or i'm holing it wrong ... (services (cons* <lfam>vagrantc: I believe it's just (wicd-service) <lfam>It's the old style of service <vagrantc>lfam: i've never learned the difference between them :/ <lfam>The difference is that the new ones require you to write '(service' first ;) <lfam>I'm just kidding, there's more to it than that. But I don't recall the details <lfam>TBC_x: Hm, I see. I'm sorry you're having trouble <lfam>The certificates for Guix itself (that is, `guix pull`) are supposed to "just work" so I'm not sure what has gone wrong. It might help if you provided steps to reproduce, or gave a little more detail about how you installed it <lfam>Also, can the QEMU VM definitely reach the internet? <TBC_x>Well... I've done guix pull before guix init <TBC_x>I'm not sure if that changed ways the system is installed <lfam>It did, although I'm not sure that matters here <lfam>However, the system that you ran `guix pull` on before `guix system init` no longer exists. You're in a new operating system now <lfam>So, you successfully ran `guix system init ...` and rebooted? <lfam>It would help if you could provide `guix describe` as the user for whom this `guix pull` is failing. That means if you are using sudo or su, use it in the same way. Also, it will be helpful to see the full command and output of the failing command. You could put it on <https://paste.debian.net> or a similar site <lfam>Also, if you share your config.scm (as much as you're comfortable with), one of us could try reproducing the system with `guix system vm-image` <lfam>And then we could try reproducing your bug <TBC_x>Well... I have raw .img if that would help <lfam>Ah, yes, that could also work <lfam>However, it's dinnertime here soon, so I won't be able to test it out for a couple hours <lfam>Hopefully someone else just knows the answer, anyways :) <lfam>vagrantc: I think a difference is that newer services are all service-types, so you can have multiple instances of them <TBC_x>config.scm wouldn't give you any info, it worked before I wiped it and reinstalled <TBC_x>The only thing that changed was that I used Guix System 1.1.0 before <lfam>TBC_x: config.scm will be available in your image at '/run/current-system/configuration.scm' <lfam>vagrantc: It's like, you can only run one wicd-service, but you could have multiple wpa-supplicant-service-types. For example, for multiple network interfaces <lfam>And, I think the new style of services can be composed more flexibly <TBC_x>Where can I upload 300MB file? <TBC_x>Starting it with those parameters: `qemu-system-x86_64 -smp 1 -net nic,model=virtio -net user -enable-kvm -m 4096 -drive media=cdrom,file=/home/t0suj4/Downloads/guix-system-install-1.2.0.x86_64-linux.iso -drive media=disk,format=raw,file=guix/mnt2.img,index=1,if=virtio -boot menu=on,order=d` <TBC_x>Oh... without the cdrom drive <apteryx>has anyone ever encountered 'error: linker `cc` not found' when attempting to build rust things? <apteryx>ah, in link.rs: LinkerFlavor::Gcc => "cc".as_ref(), ***leoprikler_ is now known as leoprikler
<Aurora_v_kosmose>So, despite adding zlib to my packages, and sourcing Guix's profile, I can't seem to get static compile working for sbcl+cffi. Keeps complaining about -lz ***amfl_ is now known as amfl
<apteryx>The shared libraries are made available via the LIBRARY_PATH, which is defined when gcc is part of the profile <apteryx>(gcc gets pulled in as an implicit dependency when using the gnu-build-system). <apteryx>also, why static? In Guix we favor shared libraries over static libraries <Aurora_v_kosmose>apteryx: Deployment of a Lisp system onto a remote host I do not have root on. <apteryx>zlib has a static output in case you really need those. <apteryx>Aurora_v_kosmose: Guix should offer a solution for this, unrelated to the shared vs static issue. <Aurora_v_kosmose>apteryx: A Guix archive would, but I'd need to package the program for Guix. <Aurora_v_kosmose>I'm not sure if I can do that without hosting it somewhere. (Or putting up a git server) <apteryx>You can build a package using local files as its source <apteryx>I didn't know you were trying to build stuff outside of a package. <apteryx>You want the gcc-toolchain package installed in your profile <apteryx>GCC can produce both flavors; there's no static gcc-toolchain package. <apteryx>Oh, I'm wrong, the gcc-toolchain has a static output <Aurora_v_kosmose>I'd been running it in an environment rather than installing directly as for some reason my shell starts segfaulting if I install GCC directly. <apteryx>It's probably caused by one of the environment variables it sets, although that's odd. <apteryx>to build stuff you want to install 'gcc-toolchain', not just gcc <apteryx>gcc is supposed to be a hidden package, unless that changed. <Aurora_v_kosmose>It is indeed hidden in search, but responded (with substitution) when run via "guix install gcc" when I didn't check with a search first. <apteryx>bootstraping rust 1.29 with mrustc takes age... For some reason it seems to use a single core at all time. <Aurora_v_kosmose>Well, installing the static toolchain has changed the point at which my static compile fails. So success of a sort, I guess. <Aurora_v_kosmose>Ah, when I ran it with the system's gcc accidentally, it tried to use guix's ld and failed at relocation steps. <Aurora_v_kosmose>e.g.: $HOME/.guix-profile/lib/../lib/libc.a(strstr.o): relocation R_X86_64_32 against symbol `__strstr_sse2' can not be used when making a PIE object; recompile with -fPIE <Aurora_v_kosmose>I think I'll just try to figure out how to use a local repo as a Guix package source, that'll be less of an exercise in frustration <leoprikler>raghavgururajan: is kwayland really needed for telegram? we already have qtwayland, don't we? ***zimoun is now known as Guest96465
***zimoun` is now known as zimoun
***zimoun is now known as zimoun`
***zimoun` is now known as zimoun
***apteryx_ is now known as apteryx
<nixo_>Fosdem is coming, it's a pity we would not be able to have a beer together ***rekado_ is now known as rekado
<aecepoglu[m]>Where does the 'prefix' in wrap-program come from? In a package I'm developing I started getting this "Unbound variable: prefix" error. The error wasn't there when I first setup the package but recently it showed up <zimoun>Does someone use Coq and Proof-General? “guix environment --ad-hoc coq proof-general emacs-minimal -- emacs -q foo.v” does not work. What do I miss? <civodul>i think there's some Emacs integration breakage <zimoun>civodul: yeah maybe. With “guix environment -C -E TERM --ad-hoc coq proof-general emacs busybox“, I am able to read the manual. But I am not able to access to Emacs functions (mode, etc.). <TBC_x>Well... SSL broke again after fresh installation... <leoprikler>can someone tell me the difference between kwayland@master and kwayland@staging? <leoprikler>specifically why the latter builds and the former fails? <zimoun>civodul: I do not know if the Emacs issues are related. Do you know if what is run at start time have changed recently? <efraim>both being locally, master and staging <efraim>i also just enabled the tests recently <efraim>test 38 failed for me on master the first time, passed the second time. The first time it was still building on staging also. perhaps the timing is too specific and the added load caused it to fail the first time <efraim>I'm also building it now on aarch64 <rekado>I’d like to move a few things from (guix scripts environment) into a separate module with public API that (guix scripts environment) — and other tools that need to set up an environment — can use. <civodul>zimoun: i'm not sure; maybe apteryx knows? <luis-felipe>"We will cover 12 hours to cater for Asia, Europe and the USA time zones. " <pkill9>bikeshedding question: should we call third party repositories "channels" or "repositories"? <luis-felipe>Maybe, "We will cover 12 hours to reach more time zones"? <pkill9>i guess that answers the question lol <leoprikler>"Channels" is not actually Guix newspeak, it has a technical meaning. <leoprikler>whereas "third party" is a 90% buzzword adjective <pkill9>oh i thought it was the other way round <pkill9>plus repository is more associated with traditional model of a third party hosting the binaries <pkill9>but channels provide the build instructions <leoprikler>bah, I hate Telegram even more than I previously did now <leoprikler>Their build system is so insane, even the devs themselves are confused as to what they're actually pulling <efraim>it turns out my lizardfs service definately needs more work, I didn't take into account running multiple chunkservers <apteryx>civodul: About 45781; that's expected. -Q does --no-site-file; the site file is where we call 'guix-emacs-autoload-packages' at run time to load the autoloads file. <deech>Hi! Just starting to investigate Guix, is there any way to get the package manager piece to install on MacOS? The install script doesn't work out of the box because 'gpg', 'getent' and 'groupadd' don't come standard with macos. <pocketroid>(i am also on mac, but haven't installed anything like this yet) <apteryx>zimoun: try with coreutils instead of busybox, just for the kicks <apteryx>Emacs still has unpatched calls to coreutils commands <apteryx>Busybox sometimes behave differently than the "real" tools. Perhaps enough to break something. <zimoun>apteryx: does not change with coreutils. Same with nothing, coreutils or busybox. <rekado>deech: Guix doesn’t use the operating system libraries but bootstrap binaries to build everything. The existing bootstrap binaries won’t work on MacOS, because they don’t support that system. <rekado>it is no option for us to use the proprietary MacOS toolchain either. <zimoun>apteryx: it looks like site-lisp/site-start.d/* is not loaded by default <rekado>so the closest you could get to having Guix on MacOS is to run it inside a virtualized GNU system. <deech>rekado, makes sense. Thanks! <rekado>zimoun: I haven’t tried (for lack of a system to test it on), but it might. <rekado>zimoun: oh, wait, I’m pretty sure it works. <rekado>unless people use homebrew on systems other than MacOS I’d say it does work there. <zimoun>so it should be possible to run Guix on MacOS, just with a bigger seed. Replacing all the Mes bootstrap to have GCC@4.9.4 and then gcc-toolchain by simply clang-toolchain. Instead of 10+120MB of seed, it is clang-toolchain seed. <spock[m]>is there estimate of when HURD will be supported? <zimoun>it is unacceptable for Trusting Trust attack, though. <rekado>zimoun: no, AFAIU there’s no glibc support for macos. Everything must be built with the proprietary Xcode. <rekado>zimoun: Guix is closely tied to the use of the glibc. There’s no glibc for macos, so even if you had that huge proprietary blob that is Xcode you wouldn’t be able to compile the first glibc that would run on macos. <zimoun>why do you need to glibc? Somehow, it should be the same story as for Haskell but for C. <rekado>almost *every* package (other than early bootstrap magic) in Guix links with glibc. <civodul>yup, and porting to another libc is not an option <rekado>if you squint really hard *maybe* you can pretend that the system libraries that the macos SDK provides behaves like a drop-in replacement for glibc and thus fake glibc on macos… but … nah. That’s very unlikely to work. <rekado>zimoun: so really, the most promising route for Guix on MacOS is to transparently virtualize a ‘GNU system as a local service’. <apteryx>zimoun: is Emacs supposed to do that itself? We don't do anything magical except loading autoloads files founds under site-lisp/ <rekado>Apple’s systems are very hostile to free software development. It comes as a surprise to many people I’ve spoken to that it’s much easier to build GNU software on Windows than on MacOS. <apteryx>zimoun: it's perhaps a convention used on other systems through their customized site-start.el files? <apteryx>there's no mention of 'site-start.d' in Emacs sources <zimoun>apteryx: ah, that’s a good explanation :-) <zimoun>so it is just a fix for the package proof-general <zimoun>civodul, rekado: but it is not the same to run in Docker, QEMU or whatever… Anyway, I am not a Mac user :-) And not planning to be. ;-) <apteryx>civodul: had you had a chance to look at the patch+repack patch I sent? I'd like to have it merge to get more support from the build farm when building stuff on top ;-) <rekado>zimoun: yes, it’s not the same experience. But there’s nothing we can do about that. <rekado>zimoun: it’s a technical obstacle (no glibc support) that stems from a legal obstacle (no way to build, distribute, or modify the macos system libraries). <civodul>apteryx: no sorry, i have a hard time keeping up this month :-/ <apteryx>civodul: no worries, I'm just selfishly cranking out patches rather than reviewing. Can't judge ;-) <civodul>(and of course suddenly it's urgent they want an answer now) <civodul>perhaps at some point we should sit down and rethink /var/guix/profiles <apteryx>Although my idea is more to to 'specialize' at bug reports more than review, as this seems the bigger elephant if judging by the sheer count number. <apteryx>sounds tricky to revisit that (/var/guix/profiles). You'll want good test coverage if you tackle it. <civodul>yeah it's definitely not a change that would happen overnight <apteryx>I'm making slow progress on the mrust-based rust bootstrap. It builds 1.29.2. Now I need to figure out what needs to be installed in the output so that its built cargo and rustc can build the next one. <apteryx>Rust must be a big disk space consumer on the build farm. This page (https://github.com/dtolnay/bootstrap) says "Bootstrapping up through rustc 1.40 requires 120 GB.". Now imagine rebuilding this on world rebuild for core-updates. <civodul>apteryx: oh great that you're working on it! <apteryx>perhaps we should modify the linter to stop complaining about missing #t on end of phases on master? <apteryx>and tell everyone they can already stop doing it, to reduce future work? <civodul>"guix lint" never complained about missing #t at the end of phases <civodul>but yes, we can remind people that they can stop (we already had a discussion) <apteryx>hmm. I swear it told me some phases were not ending by #t. <civodul>maybe these were warnings coming from gnu-build-system and pack-and-repack, no? <roptat>that would be during the execution of the phase itself, while building the package, maybe? <liltechdude>Hello! New problem: I install renpy `guix install renpy`, execute `renpy-launcher`, create simple game from template with nothing changes by me, start `Build Distributions` for `Linux x86/x86_64` and get this problem https://paste.debian.net/1182070/ <rekado>civodul: I’m saying this without a thorough understanding of Grid'5000, but would it be an option for them to export the directories under /var/guix/profile/per-user via NFS and restrict mounts of these directories to matching accounts? <liltechdude>also `/gnu/store/fxhma7kcg032lihzw8vlcr9kw0pp5x1i-renpy-7.3.5/share/renpy/lib` does not exist <leoprikler>Unfortunately, our Ren'py is not built with the expectation to adhere to whatever upstream deems "the correct way". <civodul>rekado: yes, it seems like the easiest option, just not their favorite one <leoprikler>You can use it to start and run projects, but I wouldn't trust it to package things in a meaningful way. <leoprikler>Source distributions > binary distributions anyway :) <rekado>there may be a way to change renpy to fix that feature, but I don’t know if that’s at all feasible. <leoprikler>rekado: Ren'py copies its entire source plus Python plus a bunch of precompiled binaries as its bootstrap seed. <leoprikler>I don't think that's a model Guix should endorse. <leoprikler>liltechdude: I'll see if I can dumb it down, so that it only does a source package. <leoprikler>OTOH, you could technically run the launcher in your CI. <liltechdude>at least it would be nice if new game appeared in `projects` list in renpy-launcher <leoprikler>I've set my project directory to /tmp, checked your repo out in /tmp, it shows up <leoprikler>you're probably just missing some part of configuration there <leoprikler>guix environment --ad-hoc renpy:the-question renpy-the-question <leoprikler>For one, there is no renpy-build-system in Guix yet, but also it's part of the renpy package in a sense <liltechdude>is there any example of build system that I could set as a example for abstract renpy-build-system? <rndd>hi everyone! a little bit strange question, but is there way to change a picture in the grub menu? <leoprikler>most build systems are implemented in terms of the gnu-build-system, e.g. python-build-system <leoprikler>our fictional renpy-build-system would not do much, see the renpy package on how the existing games are installed <dongcarl>I'm happy to push it along and do the work, but would just like some guidance and direction-pointing :-) <civodul>dongcarl: hadn't seen your latest messages; great that you found the offending kernel options <apteryx>has anyone else observed some wrong symlinks when using guix build with -K ? I have a file produced there that says "/tmp/guix-build-mrustc-0.9.drv-0/source/run_rustc/output/prefix/lib/rustlib/x86_64-unknown-linux-gnu/lib", but the drv-0 part should have been drv-22. <civodul>apteryx: that's expected: the name within the build environment is fixed to ".drv-0", regardless of its name outside <apteryx>OK, so my use case should work inside a clean build environment, although it breaks when using -K (and with already multiple build failures accumulated under /tmp for this package) ? <liltechdude>creating build system is documented somewhere? is seems rocket science for me honestly <apteryx>in other words, it's safer to always 'rm -rf /tmp/guix-build-$package*' before attempting a build with -K <roptat>since we have now switched to weblate, should we increase our po/packages/POTFILES list? <roptat>iirc it is limited to a small amount of files to keep the pot file small for the TP, but we don't have that constraint anymore, do we? *kmicu sees glitches in Matrix Bridge. <leoprikler>liltechdude: don't worry too much about it, I'll add it to my imaginery Ren'py TODO list <leoprikler>speaking about renpy todos, 7.4.0 will pass the 14 day mark the day after tomorrow <dongcarl>civodul: Thanks! Do you have any recommendations for next steps? <civodul>dongcarl: between CONFIG_EXPERT and CONFIG_UID16, do you know which one is at fault? <civodul>CONFIG_UID16 stores UIDs on 16 bits, right? <leoprikler>In that case there's not much else to do but read what exists and start hacking ._. <leoprikler>fwiw a patch that fixes distribute.rpy would also be considered "helping somehow" <civodul>dongcarl: ah i see you explain it in your message <leoprikler>(and it'd be considerably easier than a build system given that you're just building patched versions of renpy over and over again until it works) <civodul>dongcarl: i'd check how CONFIG_UID16 affects user space; my guess is that it shouldn't change the syscall ABI, and so that stat(2) is affected could be a bug <dongcarl>civodul: So CONFIG_UID16 is only an option when CONFIG_EXPERT is on, I believe <dongcarl>civodul: Perhaps it's not a bug since CONFIG_EXPERT warns: "This is for specialized environments which can tolerate a "non-standard" kernel" <dongcarl>I'm tempted to say that we should detect CONFIG_EXPERT and just yell at the user if it's on? <civodul>dongcarl: yes; given this documentation, warning sounds more reasonable than attempting to support it <civodul>how can it be detected though, apart from parsing /proc/config.gz when available? <dongcarl>civodul: I don't think so unfortunately... This is a shame given that different distros have different places where they place config.gz... <civodul>dongcarl: not an option i'm afraid :-/ <civodul>if we want to emit a warning, we need an inexpensive and portable check <dongcarl>Okay, I guess we need to track down exactly what is making this fail, and write a short C program to reproduce that... <Urist>'theme' field of 'bootloader-configuration' is not documented for easy customization. <Urist>I'm not able to create bootloader theme object without looking it's default definition in code. <apteryx>there's no '/bin/sh' in the build environment, correct? <civodul>dongcarl: maybe a C program that calls 'stat'; you compile it with a 64-bit toolchain and check, then with a 32-bit toolchain <raghavgururajan>> leoprikler: bah, I hate Telegram even more than I previously did now <leoprikler>Although the specifics seem different there, tgcalls appears rather prone to segfaulting <leoprikler>Telega is nice and all, but not really friendly to the uninitiated, let alone Guix users, who don't live in Emacs (rare, I know). <GNUtoo>are there examples of .scm files for using other linux-libre-headers versions to make guix pack work on older kernel versions as well (~3.0.101) <roptat>GNUtoo, maybe with a package transformation option? <GNUtoo>It's a concept defined in the manual or you mean actually inheriting form a package? <roptat>--with-input=linux-libre-headers=linux-libre-headers@3.0 or something like that <roptat>but that might require lots of rebuilds <roptat>I think the libc depends on the headers <roptat>yeah, everything (almost) depends on the libc, so it'll take a lot of time to build everything <roptat>although, the libc has options to support a range of kernels <roptat>but maybe the oldest kernel we support is newer than the one you target <GNUtoo>running hello result in a message like "kernel too old" <GNUtoo>and there is no way around rebuilding things here <roptat>from (gnu packages base), it looks like we support >=3.2.0 by default <roptat>you'll probably need to change the libc to support something older than that <GNUtoo>so I'll just rebuild it shouldn't be that long for the base things <roptat>you'll have to change the argument we pass: --enable-kernel=3.2.0 <Urist>No easy way. Will require guile knowledge <Urist>(theme (image (local-file "/home/user/background.png"))) <Urist>extraneous field initializers (local-file) <roptat>guile thinks image is the name of a record type, and local-file is one of its fields <roptat>(although I don't know what's the context, so I can't help more that translate the error message :p) <Urist>(bootloader-configuration (theme (image (local-file "/home/user/background.png"))) <Urist>`image' function is defined in grub.scm and not in #:export. <roptat>ah, you need (bootloader-configuration (them (grub-theme (image (local-file "/home/user/background.png")))) <roptat>image is a field of the grub-them record type <Urist>^^^^^ roptat provided solution. <kabaulga>Hi, what is the easiest way to revert - (arguments `(#:configure-flags `("--disable-glamor"))) ; TODO: Enable glamor ? <roptat>how do you know it's that change? <kabaulga>I was bisecting the whole day. That commit gives me black screen and awful Guix System experience moving from a working setup to broken setup. <kabaulga>d11948a119 * | | | | gnu: xf86-video-ati: Update to 19.1.0 <kabaulga>Frustrating thing is that is not trivial bump but ALSO that glamour change. <roptat>you know you can roll-back the whole operating system, right? that'll give you a working setup until we fix that <lfam>What is "glamor" in this context? <kabaulga>roptat you know that is half year old commit and I will enjoy all those security holes if I stay on that commit? Hence politely asking how to revert it locally. I am new to Guix. <leoprikler>kabaulga: so 19.1.0 without that flag change works for you? <kabaulga>I would prefer to know how to revert locally or use Guix repo fork to test. <leoprikler>assuming you don't have any channels, you can run the guix system command from ./pre-inst-env <leoprikler>(in a local checkout after bootstrap, configure and make) <kabaulga>Is there thing like 'guix timemachine --commit brokenhash --patch revertpatch -- system reconfirgure /etc/config.scm? <kabaulga>(That is a fresh vanilla Guix System so no chanegs by me.) <kabaulga>Can list-generations be trusted that I am on previous commint d11948a119 * | | | | gnu: xf86-video-ati: Update to 19.1.0 ? <kabaulga>How to check for sure I booten into d11948a119 ? <kabaulga>For sure not system describe that is very misleading command that shows the latest generation not the booted one. <leoprikler>It should give you a number, e.g. /var/guix/profiles/system-42-link <leoprikler>that number is the same as in "list-generations" <lfam>kabaulga: Do you think it's the update, or the glamor thing? <kabaulga>it work on 008a9217c4 and breaks on d11948a119 <kabaulga>Based on Xorg errro message about missing something iirc opengl symbol I think glamour line is to blame. I can check if I figure out how to test. <kabaulga>It would be nice to understand why efraim removed that line in commit comment. <roptat>if you have a local checkout, you could re-introduce just the line that disables glamor <kabaulga>It's a fresh install, I have nothing. I don't event have git. <roptat>probably because it was a TODO and it worked for them <roptat>we can pass many types of changes inline, but not that kind I'm afraid <leoprikler>that should (temporarily) set up with everything you need to pull guix and compile it <lfam>jonsger's suggestion about using `guix pull --url` instead of `./pre-inst-env` will probably be a little faster <lfam>Clone guix.git, revert the commit, do `guix pull --url=/path/to/git/repo && guix system reconfigure ...` <lfam>Or at least, it requires less specialized knowledge <kabaulga>That only nano available in default desktop evironment is fun xD <kabaulga>Fun as in manually writing parens sucks. <rekado>you can install any package as you want <lfam>zile (tiny emacs clone) is also available, although I'm not sure it can match parens or not <rekado>in my experience it doesn’t do that very well. <rekado>you can jump to the matching closing paren but it’s a little buggy <kabaulga>Could --depth=1 be responsible for objct not found during guix pull --url=/path/to/guix ? <kabaulga>I cannot pull my local repo, do I need to be inside ad-hoc environment with git because I exited it. <kabaulga>guix pull gives me no match for id (9edb3f66...) <kabaulga>the same with file:///path/to/local/guix <lfam>kabaulga: --depth=1 means you don't have the Git history <lfam>There's only one single commit in your repo <kabaulga>I thought it generates new system based on *.scm recipe. <roptat>I think depth=1 might interfere, I don't think you can clone from a shallow repo, right? <lfam>I suppose the security features might need history <lfam>Last time I checked, guix.git was between 200 and 300 megabytes, FYI <lfam>kabaulga: You should already have the Git repo at ~/.cache/guix/checkouts <lfam>I think you can find something that works in there <kabaulga>Thank you because on mobile network that counts. <kabaulga>I hope that reverted line let me enjoy the latest Guix System. Thank youf for helpul tips. Appriciated. <kabaulga>Now it pulls so it was... lack of depth ;P <Noclip>There is a file `gnu/packages/sagemath.scm` but no `sagemath` package. Is sagemath currently available in guix (maybe under another name)? <kabaulga>Hello Noclip it looks like only some components of sagemath are packaged. <kabaulga>Whoa, updating channel guix from git repository takes some time, even on SSD. <kabaulga>Lol, first I got cannot locate remote-tracking branch 'origin/keyring' and now I get no match for id ((9edb3f...) that is confusing <kabaulga>I made regular pull which downlaode155MiB. <kabaulga>So guix pull --url=/home/user/guix gives no match for id. <kabaulga>guix pull --url=file:///home/user/guix gives no 'origin/keyring'. <lfam>Do `cd /home/user/guix && git checkout` <lfam>I mean, `cd /home/user/guix && git checkout origin/keyring` <lfam>Also, does `git show 9edb3f` work? Does the commit exist in your repo? <kabaulga>I checkouted that branch and tzdata commit is there <raghavgururajan>leoprikler: In v22, did you make any changes to patches other than tg-owt and/or telegram-desktop? <leoprikler>I only "cleaned up" telegram's inputs and the copying stuff. <kabaulga>Dont get it branch is there, commit is there but git pull url complaints anyway. <kabaulga>Is there another way besides guix pull --url? <lfam>Is it a full Git clone? Or with --depth? <leoprikler>kabaulga: try building locally with "./bootstrap; ./configure --localstatedir=/var; make" <leoprikler>afterwards you can use "./pre-inst-env <guix command>" <lfam>It's better as `./bootstrap && ./configure --localstatedir=/var && make` <lfam>Otherwise, you won't notice if bootstrap or configure steps fail <kabaulga>I removed the original repo with limited depth and cloned full one. <kabaulga>./bootstarp complains about missing autoreconf <lfam>You need to use `guix environment guix` first to provide the dependencies for building the Git checkout <lfam>It will provide autoreconf and all the other dependencies <kabaulga>Maybe I could use .cache/guix/checkouts? I have two them. They look like Guix repos. <kabaulga>A lot of ceremony to try oneline patch ;) <lfam>Yes, it takes a while to set up a Guix development setup, but once it's working, it's very convenient :) <lfam>This is how we develop Guix <raghavgururajan>leoprikler: How to see what flags (configure and make) are applied by build-system? <kabaulga>Hehe, I want to use it first. Making now, it seemts a lot of po file are outdated but I am on fresh master. <lfam>kabaulga: That's okay about the po files. After you finish make you can do `git checkout po` and they will stop complaining <lfam>It takes a while to do a full `make`, but it's not so bad after the first time <leoprikler>but as lfam points out, `git checkout po` fixes it <lfam>Changing the subject, CI failed to build qtwebkit for i686-linux on staging <lfam>Seems to me to be another case of "So?" <kabaulga>Is it possible to skip compiling and try in interpreted mode? I only want to check boot into xorg, no need for fast Guix. <leoprikler>interpreting takes way longer than compiling and interpreting from clean checkout <kabaulga>I hope it does not take oreder of magnitude longer than guix pull. <lfam>There's no way to avoid this compilation <lfam>It's basically the same as `guix pull`, but for `guix pull` of recently pushed commits, you get substitutes for building <leoprikler>if you have a dirty checkout, you may get away with one or two uncompiled files <kabaulga>And I need to do this on each guix pull to keep that line reverted? <lfam>You *either* use `guix pull`, or you use `... && make ; ./pre-inst-env` <kabaulga>What do you mean either? I guix pulled before many times. <leoprikler>you can `guix pull` just fine if upstream works for you <lfam>Both `guix pull` and `pre-inst-env` are methods for changing the version of Guix you use. You can use either one, at different times <kabaulga>guix pull --url does not work so I think we are safe. <leoprikler>but if you need your local patches, "guix pull" only does meaningless work <kabaulga>Ahh, so from now on I need to stick to pre-inst-env <lfam>No, you don't need to stick with it <lfam>You can, but you don't need to <leoprikler>you can revert to guix pull once upstream works for you <lfam>The work you are doing now is to figure out if reverting that commit fixes your bug <lfam>Right. We want to fix your bug <lfam>It loads, and then it compiles <kabaulga>It is libre, including wifi so yes, 2005 probably. <kabaulga>I thought Guix is optimized for libre hardware. <lfam>Sadly, that is basically the opposite of the truth <lfam>In general, Guix aims to support old hardware, but a good experience requires fast CPUs <roptat>although "guix" and "optimized" in the same sentence feels a bit weird tbh ^^' <kabaulga>Then that *Recommended* hardware in manual put me in wrong mindset. <lfam>Guix is a build-from-source distro, and it can transparently "substitute" binaries for anything that needs to be built. But ultimately, building from source benefits from the fastest possible computer <roptat>it's not that it's optimized, it's more that it will only work for that kind of hardware (though you can usually get away with more recent hardware if you don't need wifi) <kabaulga>Now Guix compiles monads.sm which are just endofunctors in category of monoids. <lfam>So, in any case that requires building, a slow computer will be slow <kabaulga>Sure, but I should be able to rebuild only xorg and its dependencies, but I compile Guix too. <lfam>It's not typical that you need to build Guix from source. It's for investigating a bug <kabaulga>Maybe reproducible builds are not strong point for old libre hadware. <lfam>For old hardware, binary distros like Trisquel / Debian-family are a better fit <kabaulga>Tho investigating xorg regression on traditional distro (soruce based) require less compiling. <kabaulga>Its the price for nice things. Ican pay it. <lfam>Do you know the model number of your GPU? <lfam>Maybe somebody reported this bug upstream? <kabaulga>Now I compile go files. clojure.go. It's probably clojure implementation in go ;) <roptat>I wonder which is older though :) <kabaulga>.scm and .go is not very consitent, both are Guile related. <leoprikler>well, so would go source code if it was written in any other language <kabaulga>a lot of things overrides core binding 'delete'. Sounds scary. <kabaulga>possibly unbound variables 'tree...options' <lfam>You can ignore all those warnings :) <lfam>I ignore them safely :) Ignorance is bliss <kabaulga>Ignored warnings is bad smell. No corporation job for you. <kabaulga>stackage.go? I don't need stackage. Why it cannot compile in lazy manner. Bummer. <roptat>it can compile on the fly, but it discards everything afterwards, so that's generally slower <leoprikler>Yes, technically Docker would be a better container solution, but you can't exactly docker a microcontroller. <lfam>We know these warnings :) We see them most days <roptat>you can use ./pre-inst-env directly after ./configure, and that will load the modules as needed, compiling them, but it'll do that every time you call it, and it's slower that let the compiler build everything *kabaulga hopes Lars start usingGuix and fix all those. *roptat fixing warnings in our translation... >1000 strings to check <kabaulga>roptat I will call it only once to boot one time. So that sounds good? <kabaulga>Maybe that glamor change is not to blame and I will need to test bump afterwards. <roptat>from what I'm hearing, you're near 90% already, right? <roptat>oh, I thought the charting warning was closer to the end <civodul>".go" predates the Go language; it was used in an early prototype of the Guile VM <kabaulga>BTW sorry for overflowing backlogs lads. <kabaulga>I can accept .go, but why .go+.scm and not .go+.g <roptat>so it's definitely the faults of the Go developers: they chose a name that could easily be confused with Guile Objects :D <leoprikler>because Guile used to be called in SCM in even older days ;) <leoprikler>not as long and complicated as frames and windows tbh <kabaulga>Meaning it's nice Guix provides gnupg next generation. <lfam>Somebody wanted it, so they volunteered the effort! <kabaulga>(Especially because it is rust and that's difficult to package.) <lfam>Yes, Rust is such a pain <lfam>Rust and Go are both tough <kabaulga>(And because I use Nushell and Alacritty xD <kabaulga>Cups has some ugly warning about -location at <unknown-location> <ngz>Speaking of Rust, haven't we relaxed Rust packaging by allowing #:skip-build? #true for intermediate crates? ***jgarte[m] is now known as jgart[m]
<lfam>ngz: Not sure, but there was a thread on the mailing list <lfam>I mean, I think it's really a case of "whoever sends the patches gets to decide" <ngz>Indeed, but I'm not sure was the conclusion was. <lfam>I don't think anyone is going to follow up to pushed commits and request a change <ngz>It could be nice to have a policy about it. Not packaging hundreds of cargo-development-inputs is tempting, but there might be a price to pay somewhere. <lfam>"How to package rust crates now and in future?" on guix-devel <lfam>I think that, currently, our method of handling Rust already makes *a lot* of compromises <lfam>It's hard to imagine that not building non-leaf Rust libraries will hurt us more <lfam>We are moving towards a system where Rust packaging is totally automated, so if we have to regenerate a thousand packages, that's no big deal <ngz>hmmm, where is such a system documented? <lfam>I'm not sure, but I think that Rust packagers always use the importer, right? <lfam>It's handles transitive dependencies and is version-aware <lfam>I think the next step is have automated tooling for removing Rust packages <ngz>AFAIK, the importer output always require additional tweaking <leoprikler>Well, in some cases it's a bug, in others it's GIGO. <lfam>I guess it's been too long since I packages some crates to remember what had to be tweaked <lfam>There was a bit of tweaking required for the C-language interface, but that's all I recall <ngz>The first thing that comes to my mind is the home-page field. IIRC, the importer cannot get this information about half of the time. <lfam>That's not related to building things or correct operation of tte package, however <ngz>Yes, my mind is selective, sorry. <ngz>That one is more rare. <kabaulga>Ok, ./pre-inst-env and then sudo guix system reconfigure /etc/config.scm <kabaulga>it looks like it builds xorg so maybe it is good <roptat>in the same command line, right? <ngz>Also, the indentation in output makes me cry, but, I know, that's not related to building things :) <lfam>`sudo -i /path/to/repo/pre-inst-env guix system reconfigure ...` <kabaulga>yep, one, command after another, same terminal window, dunno wheter preinstenv spawned new shell, prompt was the same <kabaulga>Ok, something is not right. It builds xorg-server 1.20.8 but master is on 1.20.10 <roptat>kabaulga, because you used pre-inst-env wrong <roptat>it doesn't do anything by itself <lfam>`sudo -i /path/to/repo/pre-inst-env guix system reconfigure ...` <kabaulga>Do I need to bee in guix environment guix ? <leoprikler>nope, pre-inst-env alone works fine *if it's together with the command you're invoking* <lfam>If it complains about a missing dependency, then the answer isyes <kabaulga>I exited guix environment guix and executed your command. Now it builds *-ati 19.1.0 so it make sense. <mbakke>I suspect the problem was that you used "./pre-inst-env sudo" instead of "sudo ./pre-inst-env" <kabaulga>I thought *env will put me into enviroment where I should execute regular system rebuild command. <kabaulga>BTW does Guix has a diplay manager with working auto login? It looks like GDM has an open issue with proposed by hanging fix because no one understands PAM. <kabaulga>build of x86-video-ati fails but there is no log. Are build logs in /var/log/guix/...? <roptat>try ./pre-inst-env guix build xf86-video-ati --log-file <lfam>When it fails, it should print the filename of the log <kabaulga>There is only faild with exit code 1. no log file. I will try roptat's suggestion. <kabaulga>radeon_present.c:281:21: error: dereferencing pointer to incomplete type 'struct radeon_pixmap'. To test lower xf86-video-ati version do I need that long make again? *lfam prepares updated weather reports for the staging branch <lfam>I think we should be ready to merge it soon <lfam>I don't see any serious failures on x86_64 or aarch64 <mbakke>lfam: yay! was "ungrafting" merged yet, or do we just defer to 'staging'? <jonsger>lfam: thanks for your engagement on staging et. al! <lfam>mbakke: ungrafting hasn't been merged yet. It's still part of staging <kabaulga>and that is probably why efraim removed that line disabling glamor <mbakke>last I checked "vtk" failed to build on "ungrafting", I don't think it has been fixed yet <lfam>This is a really good time to run `guix pull --branch=staging && guix package -u . && guix system reconfigure ...`! <lfam>There may be new failures on staging, but we may just have to fix them on master <lfam>vtk only has a few dependents <mbakke>and I still haven't finished the KDE upgrade, but maybe it is not needed <lfam>I didn't realize there was a WIP KDE upgrade on staging. We froze the branch a while ago <mbakke>I was not able to finish it on the really short deadline, and then holidays happened, and I still haven't recovered :P <lfam>In general, I didn't see any interest in fixing things on the staging branch, so my goal is fix all the major problems <lfam>But minor problems will just have to hit the master branch <lfam>I think that will be motivating <lfam>In retrospect, it was probably a mistake to do a staging branch. We should re-evaluate this strategy in the future <lfam>Maybe we should use topical branches instead <lfam>The CI problems have not helped with motivation. I'm very thankful that mothacehe is working on Cuirass now. It's extremely important work <lfam>For example, `guix weather` just told me that qtwayland did not build for x86_64-linux. But, it built fine on berlin when I built it using pre-inst-env <lfam>Many of the bigger failures were like that <mbakke>so Cuirass had not built it yet? <lfam>No. I didn't check if it registered a failure or if it had merely not been built <lfam>But there were soooo many other issues like this <mbakke>if it registered a failure, you would not be able to build it without 'guix gc --clear-failures' first <mbakke>oh wait, maybe not with the new distributed cuirass, hmm <lfam>At least, it was true up to 3 or 4 days ago <lfam>I haven't worked on things since then <lfam>The aarch64-linux platform had soooo many build failures that could not be reproduced by efraim on real hardware <lfam>And, we've simply stopped building for armhf-linux for the time being <lfam>I think that things are looking up now, however. <mbakke>I wonder if we should merge ungrafting to master before staging anyway, just for bisecting purposes? <lfam>Perhaps, mbakke. Do you think it will make merging staging very difficult? <lfam>I guess it shouldn't cause any problems. <lfam>There were some "real failures" from ungrafting but I think they've been fixed. Or we would have noticed <lfam>I wouldn't know how to check that <rekado>kabaulga: it’s just you. No google appears in the list of request URLs. <rekado>(was this a joke that I failed to get…?) <kabaulga>I see no google.com in private tab, but I see in my main Firefox. <jas4711>what is the difference between openntpd's "constraint-from" and "constraints-from"? i don't understand from the documentation <kabaulga>Some third party plugin must do that. :/ <mbakke>jas4711: IIRC it's just single vs multiple servers <jas4711>mbakke: the doc for "constraint-from" says it can be a list <mbakke>lfam: there are some failures related to freetype API change on "ungrafting" (but not ABI change, which is why the graft worked) <mbakke>"vtk" is one instance, I'm sure there are others <mbakke>I don't know a better way to test than trying to build all of 'guix refresh -l freetype' tho <kabaulga>Maybe I could fix my issue with plain 'Option "AccelMethod" "exa"' in xorg's device section. <mbakke>jas4711: 'constraints-from' takes a single argument, 'constraint-from' takes multiple :) <kabaulga>Any hints how to use xorg-configuration to inject string into device-section? Ido not see the way from manual and source code. <lfam>mbakke: Should we fix it? <jas4711>mbakke: i don't get it, but i'll just cut'n'paste stuff i don't understand from the internet and feel like a young person <mbakke>lfam: dunno, maybe we can leave the failures for "motivation" as you say :) <lfam>I think that's only realistic option <mbakke>"build failures on master will occur until morale improves" <lfam>CI didn't even have the VTK source code <mbakke>oh right, mothacehe did a large GC recently <lfam>That will really hurt whoever is left on armhf <kabaulga>Yes, thank you. it looks like xorg specification allows multiple device sections and they should be merged if they share the same identifier. <lfam>One person did speak up to say they are using armhf still <lfam>I extrapolate that to 10 people who didn't say anything <kabaulga>I am using armhf on my UDOO sbc (and MIPS on my NAS). <lfam>Maybe Guix could send then some aarch64 boards <lfam>Do you use it with Guix? <mbakke>I suppose getting server-grade ARM32 hardware is only getting more difficult <lfam>Yes, it's really come to an end mbakke <lfam>We should buy more Beagleboard X-15s if we want to build substitutes for armhf <kabaulga>I wanted to, was reading how to generate image and how to assimilate it. <lfam>Like, a lot more. Maybe 20 <kabaulga>Some blogs are not relevant after motache iirc work. <lfam>It would be a shame to break freecad (depends on vtk) so soon after all the work improving it <kabaulga>I would prefer to generate image or compile via QEMU, current plan was to install Guix on arch arm, and then reconfirgue to guix system <mbakke>kabaulga: that is a common method, but it will be difficult without binary substitutes for armhf <kabaulga>I would also love to have stable Guix System on my MIPS nas but feel free to ignore it. I understand that dozens of users should not hold rest back. <mbakke>kabaulga: if it is MIPS64, Guix already works on it <kabaulga>mbakke is possible with QEMU to use arch64 subs and convert to armhf? <kabaulga>I though MIPS support is on the way out. <mbakke>kabaulga: QEMU can transparently emulate a different architecture, which is what we have been using, but dannym discovered it did some things very wrong <kabaulga>It is for sure not 64bit, it's ~5Watt NAS with some MIPS router chip. <lfam>If it's router-level MIPS, that's not really going to cut it for Guix <kabaulga>Which I am afraid to stouch and update because it is stateful Debian. <lfam>i.MX6 Cortex-A9 at 1 GHz <lfam>Cortex-A9 is good for its time. It a modern CPU that runs out of order <kabaulga>Out of order execution on that board? I will burn it immediately. <lfam>No, that's a good thing! <kabaulga>Out of order execution is the most terrible thing ever. <mbakke>lfam: I looked into VTK before the holidays; the Freetype issue is fixed in version 9, but that has other problems, such as making it impossible to unbundle the dozens of libraries that we are currently unbundling <lfam>It's what makes computers fast <kabaulga>Now we need to slow them down with patches. <lfam>Spectre only really matters if you are using virtualization or (maybe) browsing the web <lfam>It doesn't matter for something like a Udoo <lfam>There is no serious powerful CPU that runs in-order these days <lfam>The performance penalty of in-order execution is good for embedded applications <kabaulga>I will trade preformence for correctness at any time so not for me. <mbakke>it is possible to backport the VTK commits that fix Freetype compatibility, but it will be a lot of work and a huge patch (it was a major cleanup IIRC) <lfam>Okay... then you'll never pass 2005-era performance kabaulga. If that's what you prefer, it's fine <lfam>For a "desktop" use case, the threat of spectre is totally overshadowed by the non-existent security posture of GNU / Linux <kabaulga>It is what I prefer. And when you hit new consequences of out-of-order hack you will share my thoughts ;) <kabaulga>Yey, the latest Guix works with reverted ati bump. yey. <lfam>I don't agree. I'm quite familiar with this situation and helped manage mitigations of those threats for Guix <lfam>They simply don't matter for a workstation <lfam>Like I said, except maybe in terms of web browsing, where you executed untrusted code from random sources <kabaulga>I never assumed workstations. I was talking in general. <lfam>Well, I don't run a VPS company <lfam>That's where these problems are a major threat <kabaulga>Out‑of-order is a hack and it brings trade‑offs and they have negative balance in my case. <lfam>GNU / Linux doesn't really make an effort to protect against a running application, so side-channels from CPU caches are way down on the list of priorities <kabaulga>Though I am Haskell folk, I like formal methods, slower tagged memory, so I amnot your crowd. <lfam>I would call it a genius innovation rather than a hack :) <lfam>It unlocked orders of magnitude higher performance <lfam>In 20 years, side channels will be more fully understood and weaponized <lfam>But right now, it's an extremely esoteric threat <kabaulga>You are focusing on security, not correctness and I understand that those trade offs have positive balance for you. <lfam>Anyways, I was trying to say your Udoo will be okay for Guix, although not amazing <mbakke>kabaulga: good work on finding the faulty commit, will you submit a patch to revert it? <lfam>The i.MX 6 has good support <mbakke>ideally with a comment near the package definition pointing to the upstream issue <kabaulga>mbakke I need to test Option "AccelMethod" "Exa" first, maybe I can run without revert but with a config for pre R600 ARTI cards. <lfam>There is a lot of armhf hardware that "works for Guix" but can't actually do anything with Guix. They cannot sustain high loads <mbakke>kabaulga: great, thanks. Maybe we can add a notice the the package description or something if changing the AccelMethod works. <kabaulga>It handles ffmpeg with 4 CCTV cameras so it is good for me. Highl loads is relative term. <lfam>When the CPU throttles down because the SBC has improper thermal design, the question of "what is high load" is answered <lfam>Since Guix users on armhf need to build almost everything from source, this problem matters <lfam>It's the difference between an upgrade taking a few hours or a few weeks <kabaulga>Not really, that is not an objective language, no need to discuss that. <lfam>Okay, I'm sorry I tried to help <lfam>It's more typical that people ask if the experience will be comfortable <leoprikler>kabaulga: out of order is not even an issue w.r.t. correctness <leoprikler>you can't out-of-order instructions, that would end up doing something else, that's like compiler 101 <ngks>I am trying to create a channel that points to a local (in homedir, no network involved) git repo for purposes of learning how to write packages. I thought that I could do this by just blindy imitating the structure of a well-known 3rd party channel, but `guix pull` fails and points me to a message that seems to show my code fails a very basic sanity check ("no code for module ~S"). Is there a document, wiki entry, etc. that walks the <ngks>user through creation of a private channel in a hand-holdy way? <leoprikler>I don't think there's a primer on channel management in the Cookbook yet, so you only have the manual to work with. <ngks>leoprikler: thanks, I guess I can send cookbook patches once I figure it out <leoprikler>if your channel contains nothing evil, what is $(tree /path/to/channel) and your error?