<zimoun>mbakke: patch submitted in #44049. <mbakke>PotentialUser-15: glad it was such a benign issue <mbakke>zimoun: thanks! I'll apply it tomorrow. <civodul>mbakke, jlicht: sorry i didn't follow, but i don't think 5dbfdf8be4dc6250ab8475874e232e653b042cbf can possibly have an adverse effect, can it? <civodul>mbakke, jlicht, PotentialUser-15: fixed in 6be71461309bad19dcd96faa151ca691d87f28df <civodul>PotentialUser-15: if you can try to "guix pull --commit=6be71461309bad19dcd96faa151ca691d87f28df", and then reconfigure from there, it should be fixed <mbakke>civodul: awesome, that was fast :-) <civodul>it was a recent change, still fresh on my mind <mbakke>creds to PotentialUser-15 for persevering :-) <PotentialUser-15>civodul: confirmed, works just as expected, thanks for the quick response <PotentialUser-15>mbakke: least i can do given years of free OS use ;), if i ever figure out how to make my own packages i'll be sure to submit them hah <maav>PotentialUser-15: info "(guix-cookbook) Packaging Tutorial" ;-) <maav>PotentialUser-15: it's not so hard, and very fun :) <PotentialUser-15>maav: i'm interested in building signal-desktop, but it requires npm/yarn, which i don't see in guix (yet?) <anarkat>just finished installing guix , i run guix pull everthing goes smoothly then at the end spits 2 hints one says "after setting `PATH' , run `hash guix' to make sure your shell refers to `/home/user/.config/guix/current/bin/guix" <PotentialUser-15>i'm not an expert, but i *think* that's a misleading error that you don't need to worry about, because guix system sets your path correctly for you <PotentialUser-15>you only need to use sudo to update your operating system, not for packages installed in the default profile <anarkat>to upodate i would run sudo guix pull && sudo guix package -u <PotentialUser-15>tbh, i found the easiest way to keep my packages up to date is make a manifest file, and i just "guix pull && guix package --manifest=[filename]" every time i want to update, but i have no clue if that's what other people do <jlicht>PotentialUser-15: `guix install node' for npm, although node is stuck at version 10 (for now) <jlicht>and packaging npm packages is kind-of terrible at the moment, although the recently packaged esbuild might help in getting some important things unstuck <PotentialUser-15>jslicht: thanks, i'll try that, it doesn't appear when searching npm ^_^ <sss2>hi all, is it possible to have key file for luks device on external filesystem ? <sss2>i mean via guix system configuration ***catonano_ is now known as catonano
<apteryx>Brendan[m]2: haha, vegemite! That brown stuff that tastes like what it looks like. <wleslie>it's oestensibly true, and yet still somehow highly addictive on dry toast ***wleslie is now known as KineticUser-1729
***KineticUser-1729 is now known as wleslie
*Brendan[m]2 tries gimp 3D rotate => mind blown *orly_owl presses ^z so Brendan[m]2 can have a mind again <Brendan[m]2>Is there any advantage in giving someone a swap partition instead of a swapfile? <apteryx>swap files don't work for Btrfs RAID <apteryx>other than that... none that I know. <Brendan[m]2>the default installer creates a simple ext4 setup with a swap partition. i think a swapfile may be preferable <apteryx>I'd prefer that too; I find swap files easier to manage. <vagrantc>if you have a swap file on a filesystem there's filesystem overhead <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, efraim says: what's the benefit of using linux-libre-arm64-generic over linux-libre? <vagrantc>efraim: not having to play whack-a-mole to figure out which modules to add to your system config <Brendan[m]2>vagrantc dont filesystems have special code for handling swapfiles? <vagrantc>efraim: it's also maintained upstream to some degree, so when a new relevent kernel feature is available, it's often enabled. <vagrantc>Brendan[m]2: don't know; maybe they do nowadays <Brendan[m]2>in anycase i dont think swap is something that is supposed to be used unless your really in trouble and using too much ram <vagrantc>in which case, any extra overhead will be very painful :) <Brendan[m]2>no, a little overhead will be only a little bit painful <vagrantc>if some of the overhead uses ram, and you are short on ram... <Brendan[m]2>we are talking about the overhead of a swap file on a file system when it is in use <sss2>is it possible to build guix installation iso image on goreign host system ? <sss2>is here documentation anywhere ? <sss2>but it is a bit confusing <sss2>here mentioned "gnu/system/install.scm" i do not know what is it and where is it <Brendan[m]2>cd guix; guix system disk-image --file-system-type=iso9660 gnu/system/install.scm <Brendan[m]2>It mentions underneath that it's in the "source tree". perhaps that is not clear enough <sss2>does current guix master support lvm ? <sss2>i have a bit overcomplicated storage setup .... <sss2>which involves mdadm, lvm, cryptsetup <vagrantc>the lvm tools are there, but there aren't services to initialize the lvm volumes or support in the initrd, last i recall ... <sss2>currently i am using custom init <sss2>selfwritten, because non of existing tools support my setup ... <vits-test>vagrantc: Hello. -generic lacks nftables support (arm64), it seems? <vits-test>vagrantc: also i read in `nconfig` that conservative, ondemand, and schedutil do fall-back to performance. Can any of those be default if not in -generic, then in default kernel? <vagrantc>vits-test: i've tried to modify only minimal things for the *arm*-generic kernels ... like things needed specifically for guix <vagrantc>vits-test: not quite sure i understand your question though ... are you asking how to set the cpufreq governor? <vits-test>vagrantc: no: can conservative be default in default kernel (not -generic)? <vits-test>i set it in my custom, but think it should be default :| <vagrantc>i don't get too opinionated on such things ... always been happy enough with ondemand or schedutil <vits-test>Ok, let it be shedutil. Point is that 'performance' as default is may be pointless: if any of three unavailable, 'performance' is a fall-back governor. <vagrantc>though i think i've found schedutil to be smarter with things like disparate CPUs (e.g. big.LITTLE architectures) <vagrantc>well, the pinebook-pro for example has a slow quad-core CPU and a fast dual-core CPU ... schedutil seems to load up the fast CPUs when it's doing a lot of work, and the slow ones when it's mostly idle <vits-test>on rockpro i'd prefer conservative, as it seem to use lower frequency (idk, "it seem") *vagrantc wonders the power-draw of the fan vs. the cpu :) <vagrantc>i mostly run the rockpro64 fan at pretty slow speeds, as it's too loud otherwise :) <vagrantc>well, mostly, it sits turned off, actually :) <Brendan[m]2>syncthing crashed at some point and was never restarted by the shepherd service <siraben>How do I replicate the Guix bootstrap using Nix? <janneke>siraben: what bootstrap exactly are you referring to? <siraben>Using this it's possible to bootstrap GCC, correct? <siraben>janneke: Does this apply to x86-64 systems as well? <janneke>there are two branches that i know of that implement some preliminary bits that may be helpful to use or look at <siraben>And what about doing the same on macOS/ <janneke>siraben: yes, but x86_64 systems are bootstrapped by using the 32 bit x86 persona <janneke>i don't know of anyone who tried, it may work -- dunno ;) <siraben>Not sure if it's stuck at "parsing: input" or it's still compiling <janneke>yes, compiling tcc may take up to 10min <janneke>that adds nyacc, mescc-tools and mes as regular (non-bootstrap) packages <siraben>Great, tcc finished building. Is that all that is needed to boostrap gcc? <siraben>janneke: Ah. Is it being merged yet? <janneke>using those, the first bootstrap binaries for mescc-tools and mes can be built, that you then inject into the bootstrap you're using; you need both <janneke>siraben: i don't think any of this has been merged ***amfl_ is now known as amfl
<janneke>building tcc is a great first step, but there's more... <siraben>With tcc built, what else needs to be done to get to gcc? <siraben>Also, I saw a project, stage0 that supposedly would get the bootstrap to gcc using a core of <1K bytes, but looks incomplete <janneke>siraben: yes, work is going on to bridge that gap, that will probably take another year or so <icefox>I seem to have found a terrible error <siraben>janneke: would it be possible to use nix to continue the rest of the bootstrap? <janneke>you'll have to port some of that to nix, i guess <janneke>in short, after tcc-boot0 (mescc-built tcc), you need tcc-boot (tcc-boot0-built tcc) ***wavuwav[m] is now known as spaceyaac[m]
<janneke>then binutils-2.14, gcc-core-2.95.3, glibc-2.2.5, and on from there <janneke>siraben: well...you can see how guix currently does it <janneke>it would certainly be nice to have fewer steps in between <janneke>i understand that in nix you can (more easily?) build several packages at once <janneke>siraben: guix only shows a possible (first or second) route, there are surely better ways to do it <vagrantc>but not many projects have actually done it better, done at all is state of the art! :) <siraben>Does Guix have the smallest bootstrap to gcc currently? <siraben>Heh, it's been decades since that "trusting trust" paper came out, I assumed it would be a solved problem by now <vagrantc>janneke: finally heard back from dwheeler about our little experiment at the reproducible builds summit :) <janneke>vagrantc: yeah, i heard that we are "amazing" <janneke>first real-world application of ddc, etc. *vagrantc was pretty amazed :) <janneke>vagrantc: yes, it was great that you talked with him <janneke>i understand that he had some very valid criticism about the current state of the bootstrap (we still inject binaries), but in a constructive way <vagrantc>janneke: yup, nothing y'all didn't already know, though :) <janneke>vagrantc: indeed, that's very good; and nothing dismissive <janneke>we know that things can always be improved <siraben>Has Forth even been a viable bootstrapping strategy? <sss2>guix system disk-image --target=i686-pc-linux-gnu -t iso9660 -v1 gnu/system/install.scm <sss2>guix system: error: gnu/packages/freedesktop.scm:373:2: elogind@243.4: build system `meson' does not support cross builds <janneke>sss2: the error message seems pretty clear? <janneke>maybe you want "--system=i686-linux", instead of cross-compiling using --target <sss2>janneke, yes error is clear, i gues i should clarify my question, it is: "what am i doing wrong in order to achieve i686 installation iso on x86_64 host" <sss2>i will try --system option, thx <sss2>janneke, looks like it works, at least it downloading something <janneke>sss2: i mean, it would be great to teach the 'meson' build system to cross-compile <sss2>biggest problems i faced is: 1. building package from source, 2. cow storage problem <sss2>not sure which approach will be best to avoid building from source on low-end hardware, or maybe this is already possible and i just lack of knowledge <sss2>this is also question, about offloading, i have pretty performant pc's in my network <sss2>and it would be nice to setup something like distcc for guix, i have read in few places about offloading, which is looks like what i need, but not digged into details yet <lispmacs>sss2: there is a section in the manual on offloading. It took me about an hour to figure out how to set up offloading correctly, but once I did it worked well for me. <sss2>if it is possible to distribute work across whole network, it will be very nice <sss2>is it planned any work to implement lvm support for initramfs ? <Brendan[m]2>sss2 use of distcc would result in changing the package definitions completely, so you'd be off the beaten track. probably its better just building multiple packages simultaneously on different systems instead <sss2>Brendan[m]2, yes, but here is some like chromium, libreoffice, krita, inkscape <Brendan[m]2>i was wondering if chromium could actually be split up into multiple different packages that are all assembled at the end <sss2>i guess it will be not easy task <sss2>even qtwebengine sucked in most of it <wleslie>I'd been hoping that keeping g++ but separating libstdc++ for a later build stage would yield me a working cross compiler, but I think I'm going to have to specify languages=c and then build newlib <wleslie>otherwise I get a bunch of failures in the libcpp build, around things like "undefined reference to `xmalloc`"` <sss2>is it possible to use custom init inside initramfs on guix system ? <sss2>or completely custom initramfs <janneke>i guess so, guix uses guile for the initial ramdisk <sss2>chapter 10 in GNU Guix Reference Manual is 10 Installing Debugging Files, which manual i need ? <lispmacs>sss2: chapter 10 is system configuration, section 12 is Initial Ram Disk. <lispmacs>sss2: you can use a low level function that allows you to pass in an scheme expression to be executed in the initramfs <lispmacs>as well as specify what modules you need loaded <sss2>and i can add necessary binaries into initramfs ? <lispmacs>sss2: there is a flag you can pass called #:helper-packages <sss2>thx, thats enough for now, anyway i am far from this just yet <lispmacs>these packages are copied into the initrd <sss2>for now i guess i have another try with my netbook <sss2>from what i learned, i think it will not be too hard to implement all i need inside init <sss2>in worst case i think i always can replace it completely by my own (i know this is against whole concept) <sss2>why xfs utils not included in guix installation media ? <wleslie>here's the current state of (gnu packages capos). up until now I've been running `./pre-inst-env guix build capos-capros-toolchain`; but now I want to build capos-capros-gcc, however I get `guix build: error: capos-capros-gcc: unknown package`. what have I misunderstood? <wleslie>oh I added (properties '()) and it found it <wleslie>what does (properties '()) do, anyway? <Brendan[m]2>i think its just a place to dump any extra information that might be useful <wleslie>right, but visibility is a strange side-effect for it to have <Brendan[m]2>it may have had (properties '((hidden? . #t))) and you've over written that <wleslie>apparently specifying a newlib is not ok. I guess I can patch into inputs <wleslie>my newlib build can't find i386-unknown-capros-ar, but I have my xbinutils (which provides it) in native-inputs. what might I be missing? <rekado>wleslie: have you been able to glean any insights from the arm noeabi toolchains in (gnu packages embedded)? <wleslie>I've been using both embedded and cross-base as a reference <wleslie>dang. I'm passing the wrong binutils. <icefox>How should I permanently disable the iptables kernel module in Guix System? <icefox>I am using nftables and I don't want iptables to conflict with it. <zimoun>roptat: hi! I do not have super power to push the announce. Could you dod so? <mfg>How do i get debugg symbols for qt packages? it seems they don't have a debug output <mfg>ah nvm they are built as RelWithDebInfo <xelxebar>mfg: Debug are kept around by default but end up getting deleted unless a "debug" output exists in outputs. <mfg>would be nice, if the default behaviour was to create a debug output... <xelxebar>Yeah, it's really unfortunate that so few packages actually choose to include "debug" :/ <mfg>Not sure if i understand it correctly: It's enough to just add a (outputs '("out" "debug"))? <sss2>what if i want to append some C/CXX FLAGS during compilation ? <mfg>depends on the build-system, for cmake i would guess it's #:configure-flags '("-DCXX_FLAGS=...")? but i never tried so it might be wrong <sss2>so i should do it on per-package basis ? <mfg>ah, you want something like Gentoo's make.conf? <sss2>yes, something like this <sss2>i think -march is not bad ) <mfg>i might be wrong, but i think such a thing doesn't exist yet :/ <mfg>for personal use this would be awesome, but it also implies (?) not using substitutes, which menas building things takes much longer. So it might not be as practical as it sounds. đ¤ <sss2>i have powerful pcs in my net, and even few percent performance gain for slow/old pcs would be nice <mfg>i see, you might want to have a look at the build-systems in guix/build-system then, maybe it's possible to alter the default values used for a given build-system there :) <mfg>guix/build-system is a folder in the repo :) <roptat>zimoun, I did it yesterday evening, it's already on the website! <g_bor[m]>I don't remember exactly, is it possible to define channels on the operating system level? <divoplade>g_bor[m], you can edit /etc/guix/channels.scm <mfg>what exactly do you mean with this? you want to use packages defined in those channels in your os config? <divoplade>How to make one's computer crash: call (make-forkexec-constructor '()) in your config! <divoplade>That made me reboot twice: once because... well, it crashed, and the second time because the shepherd socket was not re-installed :) <divoplade>vits-test, I don't know and I don't want to check if it's reproducible ^^ <vits-test>icefox: Guix has no iptables service enabled by default. All i know. <maav>hi, everybody, one quick (and maybe dumb) question... how could i test extlinux bootloader? <divoplade>Hello, I don't have enough knowledge about guix to turn this into a reproducible example, but running a guile script in a shepherd forkexec service does not work (as opposed to a shell script calling guile, like what cuirass does). Any I/O will silently fail and somehow terminate the program. <divoplade>(that applies even if I/O is redirected to a file) <maav>divoplade: this could be related to something i've been hitting these days, do you have any locale-related environment variables defined? <maav>guile calls setlocale by default, and it raises an exception when the locale is not available <divoplade>maav, the thing is, it's difficult to know for sure what's in the environment, since I can't do any I/O ^^ The guile compile/load paths are modified, for sure, and LTDL_LIBRARY_PATH too. <leoprikler>you could use the #:environment argument if that's really necessary <divoplade>But that would just add things to the environment, wouldn't it? <leoprikler>not sure if it's adding or setting, it might be the latter <maav>anyway, the cheap old trick (exec env > logfile) may be used in desesperate times ;) <maav>(cheaper is to give it a while sleep and check /proc/pid/environ, i feel dirty for what i've done sometimes...) <Zambonifofex>Hello, Guix! Is there any reason the âbase32â hash information has to be stored for Git URLs? Doesnât Git itself perform integrity checks based on the commit hash itself? <leoprikler>Guix won't allow you to use git unless it has a hash to check things against and that hash is the `guix hash` of the working directory. <leoprikler>I'm not quite sure what magic flows into git hashes, but it's not just file hashes <maav>leoprikler: git stores the file hashes into their blobs and trees, so the hash for the top tree of a version should identify only the content, it's the commits which contain the history (which usually are the ones used, not the tree hashes) <mfg>well, compiling qt related stuff is slower than i thought - it's compiling for ~3.5 hours i think... <divoplade>Zambonifofex, in case the history is huge, guix can make a shallow clone, which saves a lot of disk space and bandwidth <maav>the commits are the ones that don't contain only file hashes* <Zambonifofex>Well, I was invited (on #hurd) to send a patch updating the commit info for a package, so it just got me wondering, I suppose. I also donât know how to `guix download` a specific commit by hash. <leoprikler>guix download sadly doesn't have git support yet <Zambonifofex>Are there any differences between `guix hash -rx foo` and `cd foo && guix hash -rx .`? <maav>i've just pushed the old changes for grub localization and the fix for the language names that I sent to the mailing list (i hope that was ok, only one line) <maav>but the translation for the entries in grub and extlinux is getting close too :) <maav>i'll be afk probably until late, but I will continue with #44027 <Zambonifofex>Is there any way to verify whether my changes to the package are valid without having to build Guix? <rekado>Zambonifofex: the alternative is to interpret everything, which is much slower <rekado>is there a problem that prevents you from running make? <Zambonifofex>Well, not a *problem* per se. But the âRequirementsâ section lists a lot of software that I donât have installed that Iâd have to install. <leoprikler>You should get most of what you need by running `guix environment guix` <Zambonifofex>I donât have Guix installed on this computer, though! I have only ran it through QEMU. (And on my other computer, but with Hurd, and it has no network support.) <Zambonifofex>Neither âGuix the distroâ nor just âGuix the package managerâ. <mfg>Hm, how do i add debug to a packages outputs? i added (outputs '("out" "debug")), that doesn't seem to be enough? <leoprikler>you need to make sure, that the package does have debug info to buid <leoprikler>IIRC gnu-build-system already handles the case for C packages built with -g, but I'm not sure what other configurations exist out there <mfg>It's built with cmake and uses the target RelWithDebInfo, so it is there at some point đ¤ <mfg>but i also found in the source of cmake-build-system that it sets strip-flags to --strip-debug <leoprikler>I think it's worth investigating cmake-build-system and check whether it supports debug outputs <bandali>zimoun, hey, i *finally* got around to replying to your email about streaming/recording the upcoming Guix conference <bandali>sorry again for the super long delay <mfg>leoprikler: okay i'm reading the source :-) <mfg>Hm, reading the source doesn't help to much , because it's difficult to understand what is happening where... <leoprikler>regarding #43976: They're obviously using the MIT license ;) <mbakke>phew, the final linking step of ungoogled-chromium is at 11.3G resident memory and growing... <mbakke>i had expected it to fail by now, so that's something <mfg>okay, it seems cmake-build-system should support debug outputs <Zambonifofex>rekado: Should I change e.g. the revision or something else too? <jgart[m]>It's another relatively lightweight and fast browser <jgart[m]>I'm not completely sure yet what freedom issues it might have, if any <cbaines>apteryx, that doesn't look like a derivation, as it doesn't end with .drv <mbakke>LLVM is growing a steady ~10MiB per release :/ <mbakke>apteryx: is that with 'guix build --log-file' or via Cuirass? <Zambonifofex>Iâm getting a `error: Guile-JSON is missing` running `./configure`, both inside `guix environment guix` and outside it, with my own distroâs packages. (I have the `guile-json` package installed, though.) <cbaines>Zambonifofex, the important question is whether it's on your GUILE_LOAD_PATH when you try to run ./configure <cbaines>I'd perhaps try guix environment guix --ad-hoc guile-json@3 <drakonis>sorry for more nix talk in here but this came up yesterday on nixcon <Zambonifofex>Iâm slowly starting to feel like I should just give up and let rekado do it as they had proposed! đ¤ đ
<ryanprior>jgart: if you use Falkon & want to package it, I don't see why it wouldn't be included. <ryanprior>Zambonifofex: I saw your question about verifying changes without having to build Guix. There's no tool to do that I'm aware of, any and such tool would be a guess at best, because the packages are part of the Guix code base and could depend on any other part of Guix. <ryanprior>There's a proposal for a package format that wouldn't be entangled with Guix itself, and thus could be checked for correctness without needing the whole of Guix installed. But it's been stalled for years. <Zambonifofex>I see. Well, to be honest, I just wanted to be able to verify whether the hashes I put in are actually valid. I suppose itâs a too specific request, though, so it makes sense that itâs not an available option. <ryanprior>A tool to create Guix hashes of a file or directory does seem like a thing that should be able to work without needing all of Guix. I'm interested in building that actually, but it's not a high priority yet. <roptat>ryanprior, well there's "guix hash", I'm sure you can extract its content without needing a lot of what guix comes with <ryanprior>Yes that's my idea is to read how `guix hash` works and turn that into a standalone tool. <vagrantc>ryanprior: i'd like such a tool as well :) <Zambonifofex>Ah, I did generate the hash with `guix hash -rx`, but I wanted to make sure I havenât done anything dumb, I suppose. <rekado>Zambonifofex: you may also need to update the revision <rekado>itâs there to make sure that the version string increases monotonically <rekado>commit hashes cannot be sorted alphanumerically to get the most recent first <rekado>so we prefix it with a revision number that we update manually, even if the version string itself (here the Linux version) has not changed <rekado>Zambonifofex: if you want you can send me the diff and Iâll test the build and push it. <rekado>also please tell me how youâd like to be credited (name, email) as the commit author <mbakke>why are the Berlin build nodes capped at four cores? <mbakke>they were idle before, now they are just as idle but jobs are running at 1/8 the capacity? :P <civodul>but i guess they have --max-jobs > 1 right? <Zambonifofex>rekado: See if this looks good enough! You can credit me as either âZamfofexâ or âZambonifofexâ (I prefer just âZamfofexâ, though). If you need my email, itâs zambonifofex at gmail, but Iâd rather it not be included if possible. <mbakke>civodul: indeed, but it doesn't matter much when they average at <1 concurrent jobs :P <mbakke>I think a better default would be 2x32 cores or 4x16 <civodul>yeah i agree that it makes more sense <civodul>if you commit the change we can happily redeploy! <civodul>oh the Cuirass watchdog is unhappy: "Scheduler 0 blocked since 101 seconds." <mbakke>went with 4x16, and adjusted machines.scm accordingly <mbakke>the big machines should probably get different settings though <mbakke>civodul: the last commit gives the big nodes 4x24 jobs <dftxbs3e>i quit all shitty jobs, im back, im free, probably will do some GNU Guix again *civodul runs "guix deploy" <vagrantc>guile-zlib and guile-lzlib landed in debian! *vagrantc is struggling to keep up with guix's dependencies :P <vagrantc>target for next guix release is roughly end-of-october? <vagrantc>or is that the target for a release-candidate? <vagrantc>either way, i should give an updated guix build a try... <fnstudio>just found out about the guix conference in november, that's great news! congratz and thanks to all involved