<civodul>roptat: (guix build-systems) has a comment re host-inputs :-) <roptat>yeah, I think I managed to do what I want <roptat>except now I'm missing some headers because I removed gcc and co <roptat>but at least, I can run the cross build of my package without building a cross-gcc <civodul>well, i'm not sure if using Clang instead of GCC is "good", but glad that it worked :-) <euandreh>In Nix if a file returns an attribute set, I can pick which one to build with 'nix-build file.nix -A my-attribute'. Is there a way to do the same with Guix? Like 'guix build -f file.scm -A my-variable'? <roptat>no, file.scm must return a package or a list of packages, you can't select which one to build <roptat>what you can do is make it a module, load it and build exactly the package you want with guix build my-package ***sneek_ is now known as sneek
<euandreh>hmm, so I would have a bunch of '(define-public my-variable ...)' in the module, and build it <euandreh>All I have to do is have a top-level define-module? <euandreh>I created a module but 'guix build -L. my-package' isn't working yet, it says 'my-package' is still unknown, still trying <guixy>Ok, I have established that something is done on install that sets up gitolite, and it needs to be done on boot as well. <roptat>if your module is in package.scm, it needs to be named (package) <euandreh>guix build -L. -e '(@ (build) my-package)' worked, though <euandreh>Is there a simpler way of doing the same? I expected that 'guix build -L. my-package' would work <roptat>does it show you some warnings/errors? <roptat>did you use define-public for my-package? <roptat>did you call it (name field, not variable name) my-package? <roptat>like, if you have (define-public foo (package (name "bar") ...)), then you need to guix build bar, not foo <euandreh>I was using 'guix build foo' instead of 'guix build bar' <lle-bout>nckx: would it be OK to commit bootstrap binaries that are reproducible only from within a GNU Guix system with a particular system config? Especially kernel version <philipper905>does anyone here have experience getting latex export in org mode to work? <philipper905>I'm currently running into `Math formula deleted: Insufficient symbol fonts` <philipper905>I'm trying to figure out if some texlive package could fix the issue <philipper905>I'm trying to avoid having to download the full texlive package which is gigantic ***catonano_ is now known as catonano
<lfam>I'm curious if anyone has looked into building the forthcoming release of QEMU, which will change the build system to meson? <lfam>I'm taking a look now but it would be nice if someone else already did it :) <lfam>Install the "send-email" output of the Git package <lfam>`guix install git:send-email` <lfam>You can see the list of outputs with `guix show git` <lfam>Most packages only have one, but sometimes it's worth it to split things up <PotentialUser-54>Hello! I just installed Guix system and chose the xfce4 option on graphics install menu. I would like to change the "Applications" menu in xfce to Whisker menu. I've already installed package "xfce4-whiskermenu-plugin" using "guix install", but it's not showing up in the "Add New Itemsmenu in xfce4. Any help is appreciated. <blendergeek>lfam: Thank you! I didn't know that packages have multiple outputs and until today I didn't know how to install the other outputs! <mroh>PotentailUser-54: that plugin does indeed look broken: ~/.guix-profile/bin/xfce4-popup-whiskermenu: line 47: /gnu/store/clmv25gbfjrajvh8bsnhfj3w86kry004-xfce4-whiskermenu-plugin-2.4.6/bin/xfce4-panel: No such file or directory <mroh>PotentialUser-54: I will try to fix it. If you don't mind, please make a bug report to bug-guix@gnu.org <PotentialUser-54>@mroh Thanks. I don't know how to make bug reports though. I'll try to figure out how to make them on my own when I have time (if I ever have time...). <lfam>PotentialUser-54: You can just an email to <bug-guix@gnu.org> describing your problem. It will help us keep track of it and pool our efforts <raingloom_>hmmm... "guix offload: testing 0 build machines defined in '/usr/local/etc/guix/machines.scm'..." <lfam>I believe that is the default location of sysconfdir in GNU. So, perhaps an unconfigured build <apteryx>raingloom_: perhaps you installed Guix from your Git checkout, and forgot to specify --sysconfdir=/etc to the configure script? <raingloom_>apteryx: looks like i did. i only knew about --localstatedir having a bad default. <apteryx>right, I noticed we don't say anything about --sysconfdir in the manual. we probably should <lfam>I think it was mentioned somewhere recently, but I don't remember where <raingloom_>hmm, i'm running guix archive --authorize but it's not actually authorizing my key. ***apteryx is now known as Guest65735
***apteryx_ is now known as apteryx
<cbaines>o/ I'm going to look at getting the fosshost machines in to maintenance.git, I'm pretty sure this is a good idea <cbaines>I'm also planning on adding DNS records through knot as well <cbaines>tput is a command in ncurses, I'm not sure about tputs <olivuser>I've got two unrelated questions: first, does someone else have the problem that profile generation takes like foreeeeeever (I'm talking like 1-2 hours) after installing or upgrading? For me, it has come to the point where the progress bar doesnt move for like an eternity. `top` doesnt show any significant activity <olivuser>second, does anyone here use exwm as their main wm and is willing to share his/her sys-config (specifically the part relating to exwm obviously) :) <civodul>olivuser: maybe it's taking forever because it's building a package? <olivuser>civodul, I dont understand. Because I know that if a package is building, the build process is indicated somehow. But I am talking about the very last process when installing a package, after xdg stuff has happened. Crudely translated, the process is called "Profile with XY packages is created". How is that related to a build process? Am I missing something? <civodul>olivuser: oh ok, so it's specifically the "Profile with X packages" phase that's taking 1-2 hours? <leoprikler>olivuser: all the packages that you've just built are collected (via symlinks usually) into one big directory <civodul>it's an i/o-intensive phase for sure, but 1-2 hours seems one or two orders of magnitude more than what i see <civodul>time taken is roughly proportional to the number of files in the union of all the packages in that profile <olivuser>civodul, yes, and I've come to the conclusion that it might be hanging at some point, even though the rest of the computer works fine (its not clogged). And `top` doesnt show any significant activity either <olivuser>one thing which might have caused this is that I have at some point -- annoyed by the time taken by the process -- interrupted it. <olivuser>also, I have ~150 packages, which might also be a factor. Then again, for about half an hour, the progress indicator has not changed whatsoever <olivuser>is there a way to show whats going on "under the hood"? <civodul>olivuser: interrupting is fine, it's transactional :-) <civodul>i have 303 packages in my main profile and it takes less than a minute <civodul>are you using a spinning disk or some slow file system (VM, etc.)? <olivuser>civodul, yeah I thought so for the packages. afaik I am on btrfs, but not yet on SSD (will get one in the next days tho). by spinning disk you mean hdd right? <olivuser>civodul, but why would hdd (and not sdd) make the difference between "it takes a minute" and "nothing happens for more than an hour, not even the progress bar" <civodul>olivuser: I/O on spinning disks is much slower than on SSDs, but usually not that much <civodul>unless there's also a lot of I/O happening on your disks concurrently <civodul>what you could do is run "guix processes", look at the SessionPID, and run "strace -o log -p SESSION-PID -Tt" for a while <civodul>to get an idea of what's taking time <civodul>(just interrupt it after a couple of seconds) <civodul>actually not SessionPID but rather the ChildProcess PID <olivuser>lol, to be able to do that, I need to install strace xD <olivuser>I had it on for like 2-3 minutes and nothing happens at all <cbaines>olivuser, what's the last syscall that you can see? <olivuser>civodul, sorry, but what do you mean by syscall? <cbaines>olivuser, yeah, strace is showing you system calls <cbaines>and this is when you've asked Guix to install or upgrade your users profile, right? <olivuser>I will now try it with a simple "guix upgrade" and report back <olivuser>ah well, it also stops mid process - it first wants to build the profile because I had interrupted it during an install process <olivuser>thats what I think, I will report back in like an hour or so...^^ <olivuser>well, this time is seems to have worked, for reasons I dont really understand ;-) <olivuser>civodul, thanks for your assistance, will now log back into my primary system. <olivuser>Good to know that ssd is a better choice for guix, because that means I made a good call in finally getting one :) <cbaines>sendmail: this program must be setgid smtpq <cbaines>Meh, now I need to go find the old opensmtpd store item that isn't broken <roptat>ok, I think I understand better what happened yesterday <roptat>want to hear a good story? I want to cross-compile android for the arm-linux-androideabi architecture, but can't build a gcc cross-compiler, because it needs the bionic libc, which can only be built by a cross-compiler for that architecture... <roptat>also, it's built with soong, there's no other build system for it <db48x>getting an ssd is always a good call <roptat>so, let's try and get the simpler targets working... I have another issue when trying --target=i686-linux-gnu: "fatal error: 'gnu/stubs-32.h' file not found" <roptat>which is very similar to the error I would get with gcc -m32 <roptat>recall that I use clang, which is supposed to be able to cross-compile to a number of architectures, I use clang --target=i686-linux-gnu, and I use the standard cross packages in the build environment <roptat>but when building clang, we hard-code the path to the libc, which is specific to one architecture; clang can't use it properly <nckx>cbaines: We can fix that properly after http://issues.guix.gnu.org/44700. Currently, programmes can only be setuid root. For now you can manually create a setuid copy of smtp* instead of using an older version, or at least make sure that [the way you use] your old version isn't affected by the 2020 CVEs. <nckx>I mean good morning, Guix. <cbaines>nckx, luckily I still had a working store item in my bash history <roptat>so I'm trying to build a cross-clang by adding a target-libc to its inputs, and replacing the phase where we hardcode the path to that library <roptat>but during the configure phase, gcc pick up the wrong libc... :( <nckx>cbaines: OK. The new ones work fine if you chmod them yourself. <roptat>actually, the linker: ld: /gnu/store/xvjgg2d7k311y263ykq5b6bxnjxalcj5-glibc-cross-i686-linux-gnu-2.31/lib/crt1.o: file class ELFCLASS32 incompatible with ELFCLASS64 <cbaines>I attempted to do a DNS thing earlier to configure fosshost1.guix.gnu.org and fosshost2.guix.gnu.org, but I still can't see the records... <civodul>cbaines: did you update the "version" field or whatever it's called? <cbaines>civodul, ah, I didn't, I'll try changing that... <cbaines>I think that's worked now, civodul, you should be able to SSH to fosshost1.guix.gnu.org and fosshost2.guix.gnu.org now, assuming they resolve <civodul>cbaines: yup, name resolution works for me! *nckx .oO who got 147.75.35.154 grrr <nckx>Grrr II: the number of test suites that hard code a ridiculous ‘worksforme on my employer-sponsored NVME i7!’ time-out... <lispmacs>on my desktop computer, I wanted to set default cpu frequency governor to "conservative". Do I need to install the TLP service or is there a simpler approach? <nckx>for i in /sys/devices/system/cpu/cpufreq/*/scaling_governor; do echo conservative >$i; done <lispmacs>nckx: does that preserve across reboots? <nckx>We probably have a service for that or you can write your own. <lispmacs>okay, because I knew how to set it with cpupower utility but I think that doesn't preserve across reboots <lispmacs>I see in docs you have TLP service, which is probably what I want <lispmacs>but was wondering if there was a simpler modification <nckx>No kernel stuff preserves across reboots, if it does something's just reading a file to set it at every boot. <nckx>We have a /proc/sys (sysctl) service but nothing out of the box for /sys it seems. <lispmacs>instead of installing TLP service, is there a simple way I can modify my system definition to just run "cpupower frequency-set -g conservative" somewhere in the boot-up process? <lispmacs>or does that amount to writing a new service? <nckx>The simplest modification is the echo above, that's all cpupower/cpufrequtils/TLP do anyway, but with (in TLP's case a huge amount of) more complexity. <lispmacs>where would I insert the echo in my system definition? <nckx>An even simpler (in some ways) modification is to set the default in your kernel configuration, that will (in a way) persist across reboots. <nckx>lispmacs: I don't know. Maybe there's a simple-just-SYSTEM-this-command-service-type? <lispmacs>nckx: is that like an option passed to the kernel, or does that amount to having the rebuild the kernel? <lispmacs>I see there is a sysctrl service for passing settings to the kernel <nckx>That's for /proc/sys above, not /sys. <nckx>Passing cpufreq.default_governor=conservative on the kernel command line should work. <nckx>It would only work if the governor in question is built-in, but they are on default Guix kernels, so should work. <lispmacs>does this look correct: (kernel-arguments (cons "cpufreq.default_governor=conservative" %default-kernel-arguments)) <nckx>Oh, this explains my surprise, it's apparently new in Linux 5.9. If your kernel is older it won't hurt but it will have no effect. <lispmacs>warning, your guix system is 59 days old <nckx>If it does work, you're using the lowest-overhead way imaginable to set this, which is nice. <nckx>All good if you've pulled. <lispmacs>hmm, it looks like the kernel from 2 months ago is 5.7, so I'll have to pull <nckx>I don't use the default kernels so I'm a bit out of my depth here, but it looks like the default ‘linux-libre’ in master is 5.9. <lispmacs>brettgilio: is the stream itself active yet? <lispmacs>emacs does have a few music players, but I haven't used one for six or seven months <dustyweb>hi nckx, I'll try to get it done later today <dustyweb>need to get out a podcast episode right now tho :) <nckx>No hurry, just noticed it ended on a question. <kisaja[m]>how come kaddressbook doesn't have many buttons features when installed in guix, but manual says it does? <chrislck>ooh the famous sashachua is in emacsconf <leoprikler>Which license would you propose for a guix.scm build file? [à la "Build it with Guix"] I'd like to apply the GNU All-Permissive license or similar. <mizukota[m]>is there documentation about the "raw" image type? How should file-systems and bootloader configuration look like for that? Should I use dd to write it? will it be read-only when I boot it or is it fully working system suitable for anything? <leoprikler>Interesting, Polari uses paste.gnome.org when you copy blocks. <cbaines>chrislck, I think it's telling you that libgnucash/scm/price-quotes.scm doesn't exist <cbaines>or maybe that libgnucash/scm/ doesn't exist <cbaines>I'd perhaps look at what the working directory is at that point, maybe add (peek "CWD" (getcwd)) to that phase so you can see <mizukota[m]>leoprikler but what should my-os.scm look like? What should be the bootloader, the filesystems? Or will they be just ignored? <mizukota[m]>I want to make .img and write it to usb device and boot it. I'm sure when creating disk image you should set filesystems and bootloader to something that is expected by disk image creation script <chrislck>Question: a malicious guix package can destroy my system? <mizukota[m]>even bash package can destroy everything if you run sudo rm -rf / <chrislck>Followup: can a malicious package call guix itself to do damage to my guix profile, credentials etc? <mizukota[m]>yes it can damage anything. Running programs on computer is not a safe thing and theres no angel guard who protects you from harmful programs. And antivirus does not solve that <chrislck>thx mizutoka - not being difficult - curious about guix <cbaines>chrislck, I think an actual answer would say that building Guix packages occurs in an isolated environment, without access to general user home directories for example <chrislck>interesting... building is 100%safe then, whereas running is not <cbaines>chrislck, additionally, there aren't any side effects of installing packages, unlike some other package managers where code from the package executes install time <cbaines>chrislck, well, building is as safe as the protections in Linux are for isolating the build <cbaines>cool, what are you doing with the gnucash package? <chrislck>and if i can make it work, I could add a gnucash-manifest.scm in the project root. would this be useful? <cbaines>there's a few things going on in your paste, do you know which is the most significant issue? <chrislck>... all of them! they don't appear in regular build <cbaines>so, it's talking about mixing gtk 2 and gtk 3... <chrislck>(and there's no sign of guile-2.2 in sources) <cbaines>chrislck, this looks suspicious, maybe gnucash packaged through Guix is mixing with the Python module that's available differently <cbaines>chrislck, I also tried this command: ./pre-inst-env guix graph --path gnucash gtk+@2 <cbaines>that says that the gnucash package I'm looking at relates to gtk+@2 through libgnomecanvas, is that library still used/needed by gnucash? <cbaines>If it's not, I'd remove it as an input <chrislck>am I imagining if I think gnucash can have a manifest.scm and the package loads it? <cbaines>That's not very feasible, at least the package recepies in the guix Git repository are standalone <cbaines>Having a manifest/package definition in repositories for development purposes is quite common though <chrislck>ok. building/testing w/o gnomecanvas,... <constfun>hello, new guix system user here, how can I install 'devel' headers and such for a package? looking for ncurses-devel in particular <roptat>in most cases, it's available in the package itself, there's no "devel" separate package <ngz>When building a package, I get the following error during the boostrap phase: "error: possibly undefined macro: AC_MSG_ERROR". Does that ring a bell somehow? I think I already encountered it. <roptat>mh... using i686-linux-gnu as a triplet might have been a mistake <civodul>ngz: that's weird because AC_MSG_ERROR is part of Autoconf <civodul>perhaps there's a stale aclocal.m4 in there or something? <ngz>civodul: Ah. I may try to clean up the build directory beforehand. It's worth a shot. Thank you. <ngz>civodul: but there's a "aclocal --force" in the bootstrap sequence. Shouldn't it take care of that? <ngz>OK, nevermind. It was a missing pkg-config in the native inputs… <civodul>ngz: in general, "autoreconf -vfi" is what you need to run :-) <civodul>the 'bootstrap' phase of gnu-build-system does that <constfun>roptat: thank you, i have ncurses installed, but `make menuconfig` for the linux kernel still complains about missing ncurses-devel packages, yet i do see headers and dll in ~/.guix-profile/include, C_INCLUDE_PATH env var seems to be correct as well... <chrislck>cbaines: thx w/o gnomecanvas gtk-2 conflict still appears:( <cbaines>chrislck, hmm, maybe try ./pre-inst-env guix graph --path gnucash gtk+@2 <cbaines>that might show you what is introducing gtk+@2 <chrislck>i'm hacking from my local copy of gnucash.scm directly <roptat>ah, i somehow managed to cross-compile a hello world with clang, outside a build environment <roptat>constfun, do you also have LIBRARY_PATH correctly set? <constfun>roptat: it seems I do, .guix-profile/lib ncurses is in there as well <roptat>maybe you could strace the process to try and understand why it claims libncurses is not there? <constfun>roptat: duh, i should read the full error message, I didn't have pkg-config installed, thank you for the help! <mroh>constfun: in a (vanilla) kernel tree, try something like `guix environment bash --ad-hoc gcc-toolchain bison ncurses pkg-config coreutils gawk flex -- make menuconfig` I think, you also have to hack the shebang of scripts/ld-version.sh to something like "#!/gnu/store/alfmgg03i759f8ppzkbbad82lbdpv22h-gawk-5.0.1/bin/awk -f". <constfun>mroh: `#!/usr/bin/env -S awk -f` also works <roptat>gah, I don't know what my environment was, now I can't use the linker anymore... ld fails to find crtbegin.o and similar files <roptat>at least it's the correct linkes: /gnu/store/4ng4k7lkdnjnz663pb5c5l4xg64zszz8-binutils-cross-i686-linux-gnu-2.34/bin/i686-linux-gnu-ld <civodul>roptat: you're cross-compiling to i686? <roptat>I'm just doing it to test the cross-compiler <roptat>first, I'd like to be able to cross compile for currently supported architectures, then build bionic and add support for *-android targets <roptat>so, clang calls the linker with /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/crt1.o <lle-bout>civodul: hey! is it OK if bootstrap binaries for powerpc64le-linux-gnu are merged and only reproducible in a certain GNU Guix System configuration (fixed Linux kernel version)? <roptat>oh, ok, I had overriden my $PATH with my cross-clang (built to link to cross-libc and cross-gcc by default) <roptat>however, I'm still missing something, as that one works outside the build environment, but not inside <civodul>lle-bout: at first sight i'd say "no" :-), but we should discuss the specifics <civodul>you're talking about natively-built binaries or cross-built? <roptat>ah, I forgot to add the --target argument to clang ^^" <lispmacs>gtl-dane has a really intense test suite <cbaines>civodul, I did have a thought recently, while trying to get Cuirass and the Guix Build Coordinator to work together is a bit odd, maybe the least worse way to do it is to get the coordinator to act like the guix-daemon, and Cuirass can talk to it that way <cbaines>even if you did that though, you'd still have the problem that Cuirass talks to the "guix-daemon" in batches though <lfam>I made some good progress on getting ready for QEMU 5.2.0, which will use Meson / ninja to build. However, there is at least one stumbling block — the ./configure step is not considered valid when building starts, so it re-configures at the beginning of the build phase, printing this message: "config-host.mak is out-of-date, running configure" <lfam>Is this familiar to anyone? Our QEMU package uses a custom configure phase and it seems to still be needed, but I guess it is missing something now <roptat>alright, I managed to build it except... guix cannot validate its runpath ./ <lfam>Googling for that "out-of-date" message produces some results... quite old <civodul>cbaines: problem is the Coordinator would have to implement a large subset of the RPCs <cbaines>civodul, ah, I was assuming Cuirass just said build these things again and again... <civodul>cbaines: hmm yeah, if we forget about evaluation, it's just (almost?) build-things RPCs <lfam>The only limitations I've found are this wasted re-configuring, and the info manual patch needs to be adjusted <cbaines>lfam, I don't know anything about config-host.mak, but I'd wonder about the timestamps on that file <lfam>Yes, that's my next step. It seems... surprising that they would be incorrect <lfam>I wonder if patch-and-repack was masking some latent bug (currently my WIP doesn't apply any patches to the QEMU sources) <roptat>how does ld know which runpath to set in a binary? <civodul>roptat: from the explicit -runpath flags it gets <mizukota[m]>does meson-build-system support cross-compilation yet? <roptat>ah, that's why cross-compiling doesn't add any: it dosen't use the ld-wrapper <lfam>mizukota[m]: Not sure... are you asking in reference to QEMU? <civodul>roptat: yeah, gnu-build-system has ld-wrapper in its implicit inputs both when cross-compiling and when building natively <civodul>see ld-wrapper-cross in cross-base.scm <roptat>so probably gcc uses it, but clang doesn't know about it <civodul>roptat: clang doesn't have to know about it, you just need to make sure "ld" (or "xyz-linux-gnu-ld") in $PATH is the wrapper, not the real ld <civodul>this works fine if you use clang in master for native compilation <luis-felipe>If "guix upgrade" is an alias of "guix package --upgrade", shouldn't the former accept a list of package names just like the latter does? Or am I misunderstanding? <roptat>civodul, no the first entry in $PATH is binutils <roptat>ld-wrapper appears much later, and there is no cross-ld-wrapper in there <roptat>if you look at standard-cross-packages in guix/build-system/gnu.scm, you'll see there is no cross-ld-wrapper <lispmacs>anybody else having trouble getting gdm to boot up after the latest pull? <lfam>I checked, and this "out-of-date" configure issue for the new QEMU is not affected by patch-and-repack. Digging in some more... <civodul>roptat: cross-ld-wrapper is in cross-base.scm <luis-felipe>For example, running "guix upgrade rygel starfighter" results in the error "guix upgrade: error: starfighter: parámetro no conocido", while using "guix package --upgrade" with the same packages works. <civodul>i wish we had a high-level way to define cross-compilation targets and the various quirks to use for each <civodul>luis-felipe: in English it's "extranous argument" (wrong translation)? <roptat>civodul, I know, but it's not defined as a variable, it's only an input to gcc <roptat>there, adding cross-ld-wrapper did the trick :) <luis-felipe>civodul: I'll report it then. As for the translation, It could be translated as "Argumento extraño/desconocido". But in Spanish argument and parameter are frequently used as synonyms (I don't). <civodul>luis-felipe: but "deconocido" is wrong in this case, no? (that'd be for "unrecognized") <civodul>anyway, thanks for reporting the issue! <apteryx>How can I get a font registered in the build environment? <luis-felipe>civodul: "desconocido" is "unknown", so if the error message is suppossed to tell the user that guix upgrade doesn't know what the given argument is, then using "desconocido" would be fine. <apteryx>I tried setting HOME then running the usual 'fc-cache -rv', with DejaVu Sans installed, but fc-match "DejaVu Sans" still reports 'n019003l.pfb: "Nimbus Sans L" "Regular"' <Mayt>Hello! I'm currently looking for the list of packages in %base-package, I can't find it anywhere :/ <apteryx>oh, I guess our 'fontconfig' package doesn't honor entries from XDG_DATA_DIRS? <apteryx>from the package definition of freetype, it seems to look only in the user profile or system profile for non-standard locations <apteryx>err, I meant freetype rather than fontconfig <philipper905>I asked this question yesterday but I didn't get any responses so I'll give it another shot today <philipper905>Has anyone been able to set up Org mode latex-export without the full texlive package? <philipper905>The error I get is `Math formula deleted: Insufficient symbol fonts.` <davidl>is there any quick and easy way to "dump" a package definition to file? <davidl>say you are working on a package in a REPL, can you do something similar to what in other languages would have been package.dump() or dump(mypackage)? <davidl>what Im really looking for is a way to replace github or gitlab CI workflow, with cuirass by having a channel in the cuirass specification that is continuously updated by a monitoring script that updates the commit and hash of a few packages and commits and pushes it to the channel. <mbakke>civodul: I think D-Bus follows an even/odd release cycle like GNOME (i.e. the 1.13 branch is "unstable") <philipper905>hmm, it seems I only get the error in pdflatex when the package ulem is included ***efraim is now known as efraim1
***efraim1 is now known as efraim
***efraim is now known as efraim1
***efraim1 is now known as efraim
<philipper905>Is there a way to get more helpful/verbose error messages from pdflatex? <mbakke>civodul: were you able to try Jakub's GCC 9 patches? <mbakke>civodul: I might, haven't gotten around to my core-updates TODO yet ... but I do wonder if we should go straight to GCC 10 even though I talked Jakub into GCC 9 :P <mbakke>mainly because there are some significant AArch64 8.1 improvements "for free" when using GCC 10. <mbakke>we should probably make it easier to switch compilers in that case, as in not having to mess with CPLUS_INCLUDE_PATH <civodul>mbakke: what do you mean about not messing with CPLUS_INCLUDE_PATH? <mbakke>civodul: I haven't really understood the mechanics yet, but there are several cases where adding a different GCC as a native-input leads to having to remove the default/implicit GCC from CPLUS_INCLUDE_PATH to avoid "include_next" errors and similar <mbakke>'qt-4' and 'android-libutils' are two examples <civodul>we can now use package-with-c-toolchain when we need a specific version <civodul>that removes the default gcc and adds the specified toolchain <mbakke>ooh, I had not realized that yet, sounds perfect <civodul>pineapples: hi! .dir-locals.el probably contains more than you need for your system configuration <civodul>mbakke: i'm concerned about those #include_next issues though <mbakke>civodul: I'll start hacking on core-updates in the next few weeks, let's see how it goes :-) <mbakke>the weather on 'staging' is looking pretty good, I think I'll go ahead and merge shortly <mbakke>civodul: have you thought about elfutils and enabling the debuginfo server at all? <mbakke>I kind of dropped the ball on mjw back in #38803, but it sounds like a nice feature to have. <mbakke>I have a patch somewhere to update to the latest elfutils (without the extra dependencies), and will try to make GCC use it for starters. <pineapples>civodul: Hi! Thanks! On an unrelated note (I need to get this off my chest, I hope you don't mind): I've got to say that I've really got hooked up on the project, to the point where I'm trying to conform to the project's rules when writing personal configuration-related code even though it will be of no use to Guix. This is unheard for me, especially given the fact that I'm a mere user with no technical background whatsoever. An <pineapples>yway, thanks everyone involved for your hard work! <mbakke>pineapples: thanks for the kind words! Guix can be contagious, even its high standards and courteous community. :-) <cbaines>mbakke, regarding staging, I've been building the packages, and am down to <500 scheduled builds. <mbakke>cbaines: ooh, excellent. I'll check out the non-green items there. <kisaja[m]>it says the former main developer is now patching OpenPrint fork of cups <kisaja[m]>this fork is just following cups, not being a separate program <mbakke>kisaja: Thanks for the heads-up. I heard about that fork and expect that Guix switches to it on the next rebuild cycle. <mbakke>cbaines: that page is really useful! Can confirm most of the listed problems. Investigating... <cbaines>mbakke, great :) I'm quite happy to investigate some failures too, just let me know what you're looking in to so we don't investigate the same thing <sys2>hello guix! I'm trying to workaround this bug: https://issues.guix.info/44559, but am unsure how. I can't `guix pull --without-tests=gnutls`, but I can `guix build xyz --without-tests=gnutls` (but pull tries to build gnutls 3.6.12 directly). Oddly, `guix build gnutls@3.6.12 --without-tests=gnutls` builds gnutls@3.6.14. Does anyone know how I can update? <mbakke>cbaines: ldb and xfce4-calculator-plugin + some rust packages are false positives at least, likely also monero and pulseview (still building) <mbakke>cbaines: fabric fails because python-cryptography emits a Python 2 warning <mbakke>ecl-prometheus probably fails due to the recent SBCL build system changes, looking into that first <mbakke>emacs-elpy fails due a sphinx error <mbakke>cbaines: if you have nothing better to do, feel free to investigate the emacs-elpy issue! <cbaines>I'm also investigating why I haven't built some of the packages on that page, I found and fixed an off by one error, but some are still missing builds... <mbakke>I think the fabric issue can be ignored for now, it has no dependents, and really should not depend on Python 2 in this day and age. <mbakke>cbaines: asymptote is known to fail indeterministically, I doubt it's related to staging (even though it fails here too) :/ <cbaines>I figured out part of my confusion, I'm only building x86_64-linux with no target, and some of the results on that page are not x86_64-linux <mbakke>roguebox-adventures is also a false positive <cbaines>With the current Guix Build Coordinator configuration, it'll build things that fail another two times, and this should help to get rid of intermittent failures <cbaines>so yeah, some probably are showing up incorrectly for non-x86_64-linux systems <mbakke>'exa' fails, which might upset some users <cbaines>mbakke, out of interest, have you clicked through to any of the build logs? <mbakke>cbaines: I did not, just started them locally <cbaines>cool, well they're there if you're interested :) <cbaines>I need to make the links to Cuirass better... <mbakke>cbaines: neat! I skipped the python 2 packages initially, it seems several are hit by the python-cryptography Python 2 deprecation warning. <mbakke>I think it's OK to ignore those, and instead wait for eventual bug reports (or remove them). <mbakke>cbaines: it would also be nice to have links in Cuirass to the relevant G-D-S branch comparison URL. <cbaines>mbakke, if the builds are known, they will be linked to (but the links are not great). The Guix Data Service isn't great at finding the builds though <cbaines>I've just realised I can probably get rid of some i686-linux false positives by just scheduling builds for them :) <mbakke>monero and pulseview built fine on x86_64-linux <cbaines>hmm, two of the failed monero builds are unobvious, and one is a GCC crash <cbaines>anyway, if you've succeeded in building it, that's great <mbakke>cbaines: updating elpy was enough to fix the Sphinx incompatibility <cbaines>mbakke, \o/ great, I've only build 95% of my staging .go files :) <cbaines>I hadn't even got to building the package yet! <mbakke>cbaines: 'exa' is the next target, it's possible updating that will be enough too ... but it might require some deep Rust dependency work :/ <mbakke>hmm, I think I'll leave ecl-prometheus to glv and pierre on 'master' :P <cbaines>mbakke, I added the exa failing test to the list of failing tests in the package definition, and it builds and seems to work <cbaines>It's just adding: (("test!\\(cr:.*") "") to the relevant substitute* bit <mbakke>I think it's ready to merge then! *efraim isn't able to investigate exa ATM <cbaines>I've just pushed a workaround for exa, so that should be fine <cbaines>linkchecker looks to have a test failure too, possibly a sorting/ordering issue with the output its expecting <mbakke>'92 files changed, 6743 insertions(+), 7615 deletions(-)', biggest staging merge ever? <cbaines>I'll need to move more machines back to my substitute server to help it catch up :) <mbakke>thanks for the help (and GDS) cbaines :-) <lle-bout>civodul: I am afraid the reproducibility issues might prevent powerpc64le-linux-gnu port to be merged at all, I am afraid not many people have looked at reproducibility of powerpc64le-linux-gnu binaries in general and that my skills with build tools are not extensive enough to solve them <lle-bout>Debian doesnt even test reproducibility of their ppc64el binaries *mbakke worked a lot with MySQL in a previous life, but only recently started using Postgres... <cbaines>mbakke, awesome, I'm using PostgreSQL 10 in most places, so it would be good to upgrade <cbaines>mbakke, also, if you have ideas about making wrangling staging/core-updates easier, just let me know <mbakke>cbaines: that branch comparison page has already helped greatly and was certainly the main pain point :-) <mbakke>apart from that I suppose we need more people to look at it and test branches <mbakke>also, I've been really busy the last six months in my personal life, causing the branch to go stale ... it would be good to reduce the bus factor. <cbaines>I've thought of having some way to "subscribe" to packages, so you get notified if it fails to build in master/staging/core-updates <cbaines>that might be a way of helping people find out that packages they care about need some attention <cbaines>does rebasing staging/core-updates happen much? the conflicts with master situation seems unhelpful <mbakke>those branches are never rebased <mbakke>merging more often will reduce the complexity of a single merge, at least :P <mbakke>there was an accident on core-updates where several commits got cherry-picked from master, which increased the conflict rate quite a bit <cbaines>is there a particular reason why they're not rebased? <cbaines>that would avoid the issue with cherry picking commits at least, and I find conflicts easier to resolve when rebasing over merging <mbakke>it would overwrite signatures of other committers, and more crucially, 'guix pull' would no longer work <mbakke>(without e.g. --allow-downgrades) <mbakke>also, it's difficult to track (as in reading) a branch that's frequently rebased, with merges you read the commit once, but they can be modified during a rebase without your knowledge <mbakke>many of the conflicts that occur would happen in a rebase anyway :-) <cbaines>with improving the substitute availability hopefully in the near future, that should help with merging faster as well <roptat>is there a guile function that gives me the rest of a list, after its n first elements, like (rest '(1 2 3 4) 2) -> '(3 4)? <roptat>or removing the n first elements of a list <vagrantc>seem slike it will be difficult to do a patchwork-integrated auto-merging workflow, due to the signed commits <sneek>Welcome back vagrantc, you have 3 messages! <sneek>vagrantc, efraim says: dpkg and reprepro pushed! my pbuilder package is still a WIP. haven't looked at apt yet. <sneek>vagrantc, luis-felipe says: Sorry to bother you, but what's the license of the poem you contributed to "Ode to One Two Oh"? I'd like to print the lyrics in apparel for sale... <sneek>vagrantc, civodul says: efraim pushed dpkg! \o/ <vagrantc>now my crazy schemes of comingling debian and guix are just a few steps closer! <nckx>lle-bout: Hi! Missed your question earlier. That sounds more acceptable to me, although requiring a particular kernel is... a lot. <lle-bout>ludo merged my two patches, one on master and another on core-updates! <nckx>Why does the kernel affect the resulting binaries? <lle-bout>nckx: I have no idea, seems very non trivial to find out <nckx>Thanks, I'll take a look tomorrow (nearly bed time here). If all goes well I'm also going to start applying all your patches and ‘bootstrapping’ myself. <nckx>Would your current gitlab Guix get me somewhere interesting? <lle-bout>nckx: current gitlab guix works out of the box <lle-bout>bootstrap binaries arent reproducible though <lle-bout>previously offload didnt work because of issues also present on x86_64, environment setup etc. <roptat>interesting, I'm trying to run my parser on every Android.bp file in android, and it's been taking a few minutes already (one or two just to finish the find-files call ^^') <roptat>I'll need some sort of progress bar at some point... <lle-bout>PotentialUser-46: maybe try installing older Linux-libre kernel (5.4 LTS) <lle-bout>You can modify install scheme file at the end <roptat>PotentialUser-46, that doesn't look like a network issue, more like the shepherd crashing for some reason <PotentialUser-46>I have tried and complete two installations. First one when I tried dhclient <PotentialUser-46>only the message in the top of the picture, but this was not the first time <PotentialUser-46>I disabled the ethernet by bios, and then I was more time without crash, but when I did dhclient the system crashed <roptat>so, you haven't configured your network through guix configuration? <roptat>when you run dhclient, you get that backtrace and the kernel panic? it's not when running a herd or guix command? <PotentialUser-46>I have only installed with the installer, I have not made any modifications <roptat>I think by default it should already connect to the network by itself <roptat>you don't need to run a manual command for that <PotentialUser-46>the system crash even without login. After a minute or so when the boot is complete <roptat>could you send a bug report to bug-guix@gnu.org? I think we also need the content of /var/log/messages to understand what's happening before it crashes <roptat>and why the shepherd crashes entirely... <PotentialUser-46>I got also this message when I log in: Cannot make/remove an entry for the specified session