<clacke[m]>doesn't Fedora use btrfs now? (not saying one should, I have some bad experiences of btrfs) <clacke[m]>Oops, sorry, I'm far bahind on the conversation. :-) <buenouanq>I would love for btrfs to stabilize and become the new standard. ***Piece_Maker is now known as Acou_Bass
***Guest42732 is now known as sturm
<nckx>ACTION just compiled their first bcachefs kernel today. Bye-bye btrfs. <ryanwatkins>Guys, am I correct in the assumption that one cannot easily change a config for dwm in Guix due to the functional packaging system? I am a little bit unsure on how one may do this <buenouanq>I think that fortunately you are very wrong. <ryanwatkins>buenouanq: essentially the idea is that one should edit a config.h and make clean install to see changes <buenouanq>that's far different for anything I'm used to, so maybe I'm wrong <buenouanq>you really have to recompile everytime you want to change your wm? <buenouanq>if that's really the case, it still shouldn't be a big issue, you'll just have to learn to roll your own local guix package <ryanwatkins>'dwm is customized through editing its source code, which makes it extremely fast <ryanwatkins>and secure - it does not process any input data which isn’t known at compile time, <ryanwatkins>except window titles and status text read from the root window’s name', I agree that I may have to specify a local guix package, I guess I just change the tarball location in my local spec? <efraim>Or have a patch file that you throw into the source field <buenouanq>or be a hero and take up the much need challenge of making guile-wm a fully fledged usable window manager <ryanwatkins>buenouanq: this is my long term goal, I am just waiting for when I know guile good enough and know how to debug well enough :D <buenouanq>ryanwatkins: the best way to learn a new language, is to dive head first into a complicated project requiring it :3 <ryanwatkins>buenouanq: I used to do this but I found that my biggest time was wasted driving my head into problems that were really just me missing a concept though I do agree with you, I have it installed and used it periodically but it would crash too often which I found seemed to be some problem with handling x11 errors <buenouanq>make it so it uses wayland and we can abandon X for good <ryanwatkins>buenouanq: that's what I thought about doing, I agree although I still think X is quite nice and fast, albeit old <ryanwatkins>buenouanq: if I could stabilise it, I would actively develop on it but my wm would just crash too often and the stack trace really wasn't pointing to much, then i was spending time trying to figure out how to even deploy a fix and stuff, in which case I need to know more about guix and stuff.. <ryanwatkins>buenouanq: so in my head, I reconciled that I should fully understand guix, guile and unix (x11/wayland) a bit more first :P <ryanwatkins>buenouanq: ofcourse, I want guile-wm to bring my dreams of a lisp machine closer haha <buenouanq>I wish I had the time, skills/knowledge, or wherewithal to help you in this. <slyfox>looking at 'define-public dwm' in guix source it does not seem to provide a mechanism to patch DWM other than applying a patch of a package yourself <buenouanq>if this is how dwm is always configured, it should be made simple for guix or have a guide <ryanwatkins>buenouanq: sorry, my system shut off and I lost my logs :(, I am not sure if there is a way for ERC on emacs to somehow keep IRC history <thomasd>libreoffice on core-updates fails because it's not compatible with icu4c 58. No reason not to try to upgrade to (latest) libreoffice 5.3 (where this should be fixed), right? <efraim>thomasd: go ahead, it has such a long build time is why we don't touch it too often <efraim>The secret is to bump the libreoffice specific dependencies only just enough to get it to build <efraim>Or to match the versions of the dependencies they mirror on their site <efraim>I got vigra to build first attempt on aarch64, not sure why it fails so often on the other architectures <thomasd>efraim: ok, I'll give it a try. I have 8 cores so that's something... (the alternative is to backport a patch from their repository ) <efraim>don't we have it set for not parallel build? <efraim>Icecat also built, 10 hours including the extremely slow patching process <thomasd>so far I'm still building dependencies (currrently at... vigra) <efraim>I bumped samba locally, just have to look up the CVEs for the commit message <civodul>slyfox: when applying patches (the 'patches' field in 'origin'), Guix creates a new .tar.xz <civodul>that's why you're seeing several of them: the upstream one, and several differently-patched ones <rekado_>ryanwatkins: I’m using ZNC on a server to keep my IRC history. <rekado_>ryanwatkins: ERC would connect to ZNC on my server instead of freenode. <thomasd>the libreoffice 5.1.6.3 rabbit hole goes deep :) <catonano>how am I supposed to write the url of a tarball that is on sourceforge ? <catonano>in the terminal I read "ffollowing rredirection to ..." <catonano>I fix it and theh flllowing time it's wrong again <nee```>catonano: guix has some kind of special mirror schema for sourceforge urls. run `guix edit pinball` to see an example. <catonano>nee```: thank you, I copied that schema, but the resilts doesn't change <catonano>every time it turns out that it should have a diferent hash <nee```>catonano: I'm also getting 404 errors for the mirror url. The http url on their sourceforge page works for me and keeps the same hash. But I didn't update guix in some time. <catonano>nee```: could you paste their sourceforge page url, please ? So I try it <catonano>I'm not sure I understand the diference between the mirror url and the sourceforge page url <catonano>ah but in thhe meantime the library reached version 1.4.0 <nee```>catonano: This url works for me: mirror://sourceforge/libxls/libxls-1.4.0.zip <catonano>nee```: uhmm... no. The hash keeps changing :-/ <nee```>catonano: I always get the same hash for that url, namely /gnu/store/al3rrwai9cz9zcx93gdpb0yxp65732rn-libxls-1.4.0.zip <nee```>1g8ds7wbhsa4hdcn77xc2c0l3vvz5bx2hx9ng9c9n7aii92ymfnk <thomasd>ACTION is building libreoffice 5.3.1.2 <ng0>I think the rxvt-unicode patch didn't work out, after reboot the name in at least one window manager is again "rxvt-unicode" for both. <ng0>expected result when you install rxvt-unicode should be that you get two unique entries in menus for rxvt-unicode. Actual result after a reboot is two same entries (which call different, unique binaries). I've only added " (client)" to the urxvtc entry, assuming that this would work for .desktop files. do I have to escape the parens? <quiliro>how can i establish guix to insist indefinitely if there are networking issues? <ng0>what do you mean with insist? <quiliro>ng0: to persist trying to download what it needs <ng0>do you have an actual error message, or is it just unstable connection? <quiliro>or to do other things while the link is re-established <quiliro>guix gives error when the network fails for certain time <thomasd>semi-urgent question: can I run `guix gc` while a build is in progress, and will it keep the build process' dependencies (I assume I can...? :) ) <civodul>things currently in use by a build process are GC roots <civodul>and things currently in use by some process are GC roots too (see nix/scripts/list-runtime-roots.in) <clacke[m]>in my experience this is a bit shaky in Nix. I think the fact that guix creates environment closures when you run ad-hoc packages helps. <clacke[m]>I like running heavy programs ad-hoc, so I don't have to delete old generations when I want to reclaim the space <clacke[m]>I have .desktop files in ~/.local that run "guix environment ..." to run an app <rekado_>I want to make the CRAN importer inspect some source files. May I just unpack the tarball in a temp directory, or are there other ways to inspect a tarball? <ng0>clacke[m]: fascinating <rekado_>I need to check for the presence of certain files (this can be done without unpacking) and I need to search for a string in two files if they are available. <civodul>rekado_: the pypi importer does exactly that for requirements.txt and wheels <thomasd>some comments in libreoffice.scm reek of despair :) <clacke[m]>I'm trying to find an angle how software freedom and reproducibility, and userops, relates to decentralization. <clacke[m]>My talk is planned to 20 mins and so far I've stretched it out to 50 mins, today I'll compress it to 5 mins and add a 5 mins practical demonstration. :-) <civodul>we could have announced it on the web page or something <civodul>rekado_: BTW, do you have material from BOBKonf? slides, video <lfam>How is core-updates doing today? <civodul>lfam: i've tried backporting a coreutils patch for the failing test on ARM <civodul>it's a test that check how 'cut' behaves when passed huge ranges <rekado_>clacke[m]: nice! I wish you success! <rekado_>civodul: I added the BOBKonf slides a while ago to guix-maintenance <civodul>awesome, we need to add them to the web site now <civodul>all this is a little bit to manual :-) <thomasd>clacke[m]: about decentralization: because Guix is so malleable, it makes users much more independent from the distribution (it's super easy to add and/or modify packages etc). So that's another kind of decentralization. (not sure you were asking for ideas, I offer mine anyway :) ) <rekado_>it’s was a little more rambling than usual, IIRC <sirgazil>How do I know what names to put on a manifest file? For example, if I use plain guile or mercurial I get "unbound variable" <rekado_>a specification is what you would use on the command line. <civodul>oh even a guix-web demo, neat (in the BOBKonf talk) <rekado_>sirgazil: if you use the names of variables you have to also load the modules that define them. <rekado_>sirgazil: I suggest using specifications instead of variable names unless you have special requirements. <sirgazil>rekado_: thanks, I'll try specifications. <lfam>civodul: The patch you tried to backport, it's "tests: avoid a spurious failure on older debian"? <lfam>If it's practical for me to launch a Debian machine in qemu-system-arm and try to fix it, I'll do it this weekend. But I don't know how fast or slow it will be to emulate the system <lfam>Do we know which machine is trying and failing to build coreutils? There's a Novena and a Wandboard, right? <civodul>lfam: i tried on redhill, which is a Novena <civodul>seems 100% reproducible, but only in the build env; outside the build env the test just passes <civodul>i also tried with qemu-arm (the userland thing) with binfmt_misc, but there are too many differences it seems <lfam>My relatively naive go-to in cases where it succeeds outside of the build env but fails inside is to compare the results of strace <lfam>Of course it only helps when the difference is at the syscall level <civodul>re rebuilding everything, is it reasonable? :-) <lfam>I *always* think it's reasonable, but some people demand substitutes ;) <lfam>Although for this bug I think we could limit the fix to ARM systems <civodul>i mean, if it's not critical, i'd mege core-updates and restart a new core-updates right after <civodul>i'd rather have the same bugs on all arches no? <lfam>Is it a bug on the other arches? We're not sure yet :) <lfam>The Wandboard and Novena ostensibly use the same processor; it could even be at the level <lfam>I mean to say, it could be at that level <lfam>I don't know, I'm still in the dark :) <civodul>ah no it definitely is arch-independent <lfam>Well, we released 0.12.0 with a graft or two :) <lfam>I'm okay rebuilding everything for the date bug if nobody else objects. We should probably try backporting the patch instead of updating to 8.27 to avoid introducing new problems <lfam>We'll have another round of whack-a-mole with spurious build failures <civodul>yeah that's why i'd rather avoid it, or rather delay it until after the merge <lfam>Avoid patching the bug or avoid updating coreutils? <civodul>avoid updating coreutils for the 'date' bug <civodul>i'm saying that as someone who hasn't carefully looked at the bug, tho :-) <civodul>i guess i'll change my mind if it hits me ;-) <lfam>As somebody who messed something up due to a failure to convert time zones properly, I'd like to fix the bug :) <civodul>so i guess that means a graft for now <lfam>And what about the ARM build failure? <civodul>at worst, we'll skip the offending test <lfam>We'll find out soon after the merge if the test failure indicates something serious :) <civodul>definitely, sounds like the right approach :-) <lfam>I'd like to write a short primer on "How to help with core-updates". I think my recent email on the subject did help, but it could be better <lfam>I originally found it really difficult to learn the Hydra web interface, and I think it reduces the number of people who pitch in <civodul>and there's some sort of a psychological barrier i think <civodul>i definitely had that years ago when there were major updates in Nixpkgs <lfam>So, to graft coreutils we should set (replacement #f) on coreutils-final and coreutils-minimal, right? <lfam>Re: psychological barriers, yes I think it's true. <lfam>civodul: I'm not sure how to set (replacement #f) for coreutils-final <kyamashita>Do we have a dbus update on core-updates pending? <kyamashita>I'm curious if Guix packages D-Bus with nonce-tcp enabled. <clacke[m]>thomasd: Thanks for your ideas, I didn't read it I'm afraid, but I got something like that across. :-) <clacke[m]>given more time, I would have brought up autonomy for unprivileged users, but I did bring up autonomy from distributions <clacke[m]>and the fact that the central build server going away only means you lose pre-built packages, as long as you have guix.git you can reproduce your entire system <clacke[m]>it was very successful I think. I got good questions and I got two people (out of ~100) super excited, mainly because they saw the application to their work right away <clacke[m]>going to sit down with one of them and get guix on their existing GNU/Linux <clacke[m]>what I wanted to get across was the point that it helps UserOps and software distribution by just putting up a repo somewhere, and I think I managed that ***Piece_Maker is now known as Acou_Bass
<amz3>I want to compile a package using guile-2.0 <amz3>I did guix package -i guile-2.0 <amz3>I will send a message at guix-help <amz3>I did: guix environment --ad-hoc guile@2.0 <amz3>And the configure script of guile-charting fails to find the dev files of guile 2.0 <davexunit>you must be missing something from your environment <davexunit>guile-charting is a package so this should work to make a dev env for it: guix environment guile-charting <davexunit>amz3: the environment variable that pkg-config uses isn't configured because you didn't include pkg-config in your environment <davexunit>so it has no idea where to find guile's .pc file <davexunit>my recommendation is to describe complete environments with 'guix environment', because otherwise if you try to use tools you already have on $PATH from something else you'll probably end up missing other important env vars <amz3>indeed "guix environment guile-charting" works <bavier1>Do we have any way to insert "activation code" into a users profile? <bavier1>e.g. for a package that provides bash extensions, but needs some initialization code in .bash_profile or .bashrc <davexunit>bavier1: I don't think so, but it sounds like a good thing to add along with the other profile things we do <bavier1>davexunit: in debian they have a policy that packages cannot modify user's shell environments (iirc), but in guix, since packages are installed by users, I don't think we need to make that stance <clacke[m]>bavier1: by initialization, do you mean something other than setting env vars? <davexunit>ACTION has a package for the grafx2 pixel art editor <davexunit>an interesting piece of software with its roots going all the way back to the amiga <kyamashita>quiliro: The Claws Mail packaged in Guix might not have the "Fancy" plugin enabled. <kyamashita>I just checked, and it is a configure flag. I suppose that the default for the fancy plugin is off. <quiliro>kyamashita: thank you. how did you find out and what can i do to make it on? <civodul>i wonder why we don't see any GSoC candidate this year <civodul>usually there's always a few people emailing the list <bavier1>davexunit: yes, like setting an alias or eval'ing the output of a command <kyamashita>quiliro: I used `guix build -S claws-mail`, unpackaged the source and ran the Claws Mail's configure script with the `--help` option. <kyamashita>quiliro: Also, it looks like it's on the packagers to compile and supply the plugins. The simple solution would be to add the appropriate flag upstream in the Guix package. If it turns out to be a small size difference, I'm sure things will go smoothly. Another option is getting a copy of the Guix repo, modifying Claws Mail's configure flags in its package defintion and installing Claws Mail from your local repo. <clacke[m]>rekado_: Checking out your video. Do you have the slides up somewhere, so I can rip them off for my next talk? <clacke[m]>your illustrations are really neat and explanatory <civodul>clacke[m]: just read your comments post-talk, sounds cool! <civodul>Guix built with 2.0.14 is still not reproducible :-/