IRC channel logs

<cehteh>i havent tried for some time, but so far i always managed to kill it with stress tests AND there are no really reliable fsck/repair tools for all cases

<the_tubular>All I know is raid5/6 is terrible on btrfs

<maximed>the_tubular: I don't know how well the bios option works, maybe try "memtester"

<lfam>RAID 5/6 are not supported on btrfs, so that's true

<the_tubular>It is supported (?)

<maximed>cehteh: What stress tests are these? I'm sure the btrfs developers want to knox

<maximed>*know

<the_tubular>You are making me doubt no lfam

<cehteh>it may be better, but formyself i watch it since many years and when you look at the past years commits its not really implemeting the missing features but mostly chasing existing bugs

<cehteh>maximed: yeah sorry i gave up on it, when encryption and raid6 is there then i may try again

<lfam> https://btrfs.wiki.kernel.org/index.php/RAID56

<maximed>tbf I never used BTRFS with raid6 and encryption

<lfam>"it should not be considered production-ready"

<cehteh>it was extremely pomising in the beginning, but whenever i tried i got disappointed

<lfam>I'd say that it is unsupported

<cehteh>exactly

<the_tubular>Right, I guess we disagree on the term, but we meant the same thing

<cehteh>i am waiting for that before even testing again

<maximed>(except if you include BTRFS on LUKS cryptodisk)

<cehteh>which is bad

<cehteh>in a raid setup

<lfam>So, it would be great to figure out what happened to the_tubular. It sounded like some kind of data corruption

<the_tubular>"It's supported, but it is as stable as a drunk 3 legged dunkey"

<cehteh>single disk mkay, but except for laptops (which are SSD's) i dont use single diks

<the_tubular>Everything seems like it works now

<lfam>I would scrub the filesystem, for sure. And I would also check the SMART stats (if using a spinning disk) and run memtest86 overnight

<lfam>*Something* is fish

<lfam>fishy

<cehteh>i had that once too, my syslog spewn out a lot errors prolly some transitent ram error, rebooted and everything was ok

<lfam>Huh

<cehteh>the_tubular: do you have ecc ram?

<the_tubular>Yes

<lfam>It could also be a kernel bug. They do happen all the time

*lfam afk

<cehteh>btrfs bugs are kernel bugs :D

<cehteh>anyway i also managed to kill zfs on my first try, confirmed bugs, i am really good in killing filesystems

<the_tubular>Dumb question, can I use docker in a declarative way ?

<cehteh>the only filesystem i never managed to kill in some tests is nilfs2 .. too bad it gets so little attention/care/updates

<the_tubular>Like using it trough config.scm ?

<vats>the_tubular: Do you mean using scheme to generate dockerfiles?

<vats>Or writing configuration files like docker-compose files from scheme?

<the_tubular>I'm not even sure what I meant, like declaring which docker container should starts, but I just remember you can do this trough docker

<the_tubular>So it doesn't really makes sense

<the_tubular>There is something like --restart-policy IIRC

<vats>Yes. But I'd like, for example, a way to specify the default mount point for docker volumes through configuration. That's not doable from scheme right now, I guess. Only in a json configuration.

<the_tubular>can't you do this trough docker-compose ?

<vats>docker-compose is in yml. And that is ad-hoc, for a given set of containers only. I'm talking about the default storage location in the filesystem where docker keeps all its files.

<vats>I mean, docker-compose is configured in yaml, not scheme.

<the_tubular>Got it

<the_tubular>Well thanks for your help

<the_tubular>I got scarred, but everything seems to be working

<the_tubular>I wish I knew what happened though

<cehteh>first time that happend?

<the_tubular>Yeah

<cehteh>its ssd or spinning disk?

<muradm>this is services/seatd.scm: https://paste.rs/8oe this is services/greatd.scm: https://paste.rs/pI3 and this is how they are used in place of elogind/mingetty/agetty: https://paste.rs/h1F

<cehteh>and ecc or non ecc ram?

<the_tubular>SSD, ecc ram

<muradm>seatd replaces elogind, greetd replaces mingetty

<cehteh>uhm ... ok thats the hard nut, aka, dont use btrfs :D

<the_tubular>Really cehteh ?

<cehteh>be rather happy it works again, i killed btrfs beyond repair

<the_tubular>Is that documented

<cehteh>and have backups

<cehteh>no, experience but from some time ago, ofc i dont know what happend there

<muradm>there are also few related packages

<muradm>any suggestions how to submit this and where?

<cehteh>also many laptops have a sd cardreader, i usally place a card into that, have a encrypted fs on that and a script that does daily backups of important data (and then unmounts that fs, its only decrypted/mounted while backing up)

<vats>the_tubular: Actually, changing the default container location might be configurable from scheme, since we can specify the daemon package to use for docker. And there's a `--graph` option we can pass to the docker daemon to use a different location.

<cehteh>that gives backups even when you are of the net

<muradm>greetd requires a bit more cleanup tho..

<muradm>currently greetd has only bash as session command, but adding graphical login with sway/greetd-gtk will be trivial

<cehteh>i'd wish for some featureful vt/text based or maybe raw framebuffer session manager, which also uses the linux vt's for seat switching

<cehteh>for my wifes computer i did that with some scripting

<cehteh>because vt switching is *much* faster than what gdm does

<cehteh>ctrl-alt-F4..6 and bam you are on the other dektop

<the_tubular>vats I gotta get good in shceme

<muradm>cehteh: that works for me with seatd/greetd

<muradm>but that is not seat switching as far as i understand )

<cehteh>muradm: never tried, on my wifes computer is dont have any session manager, just some scripting in profile and depending on what vt/user it is it starts different things

<cehteh>she logs in into differnt accounts, business/private

<muradm>i do similar thing, vt1 main desktop, vt2 some unrelated browsing, vt3 emacs in pure terminal without graphics

<muradm>hmm... but not different accounts

<cehteh>for myself i jsut use workspaces, but with differnt accounts that needed some other solution

<cehteh>i3 workspaces

<cehteh>f1..f3 gives normal VT's at here computer with text login f4..f6 doing startx

<the_tubular>I haven't drinked the emacs kool-aid yet

<the_tubular>I wonder if I should, I feel I'll have to re-learn everything from the ground up

<cehteh>vi user?

<the_tubular>Yes, I use vis

<cehteh>jsut use emacs and start right with one of the vi modes, viper or whatever they are called

<the_tubular>But why ?

<the_tubular>I feel like I'm gonna get stuck in emacs

<cehteh>actually i tried exwm now .. but i think i wont use it, i was just curious, it works but i had to do a lot configuration to make it familar to me

<cehteh>and i want to be able to restart emacs without my x session restarting D:

<muradm>does adding user-account to (operating-system (users ...)) require reboot?

<the_tubular>I don't think so muradm

<muradm>i tought it will just add entry to /etc/passwd|shadow etc. and bum

<the_tubular>Yes, that's also what I think

<cehteh>and create the home dir

<the_tubular>Is this wrong ?

<muradm>ah my bad

<cehteh>and beware, i havent fugured out whats gone wrong, i added 'bob' (Bob the Builder) as user for the offload build server and gave him /var/somewhere as home .. for some reason that didnt worked, while /home/bob did

<cehteh>but i am too bad to track such bugs in scheme/guix to report them

<muradm>i don't understand why http://issues.guix.gnu.org/47938

<lfam>muradm: In Guix, we don't make changes that affect more than 300 packages without going through a quality assurance cycle

<lfam>Wlroots requires a wayland update, and updating wayland will affect 2474 packages, so we have to go through that quality assurance process which is called "core-updates"

<lfam>Does that make sense?

<muradm>lfam: yeah, i missed wayland-next on top of my packages.. )

<muradm>first this does not work, second how to make it more readable? https://paste.rs/lsi

<muradm>this does not work either https://paste.rs/J8O

<dstolfa>muradm: isn't there an acons*?

<dstolfa>it would go a long way

<dstolfa>same with alist-delete*?

<dstolfa>and if there isn't... :(

<dstolfa>muradm: also i guess you could do a let*-kinda thing

<dstolfa>as in... (let* (consed-alist (acons ... (acons ...))) (deleted-alist (alist-delete "elogind")) (final-alist (alist-delete ...)))

<dstolfa>it's awful as well

<dstolfa>but at least it's more legible IMO

<muradm>dstolfa: (acons* unbound

<dstolfa>sad times

<muradm>this is interesting https://paste.rs/EoE

<muradm>Throw to key `match-error' with args `("match" "no matching pattern" ("seatd" . #<package seatd@0.5.0 gnu/packages/freedesktop.scm:835 7fcc4d91bd20>))'.

<muradm>eh.. this seems to be working https://paste.rs/Ury

<iskarian>muradm, this would be closer to the usual idiom: https://paste.debian.net/1206616/

<iskarian>though this will likely be replaced by MODIFY-INPUTS when the input list changes come down from core-updates

<muradm>iskarian: yeah, thanks.. this is better

<muradm>this works except commented out line: https://paste.rs/DGa

<iskarian>glad to see someone(s) are working on wayland stuff :)

***califax- is now known as califax

<muradm>why does this works? https://paste.rs/f7d

<muradm>i would expect it to fail on source uri

<muradm>i would expect uri to expand to https://wayland.freedesktop.org/releases/wayland-next-1.19.0.tar.xz

<muradm>which is 404

<muradm>but it expands to https://wayland.freedesktop.org/releases/wayland-1.19.0.tar.xz

<lfam>muradm: Try changing the hash

<lfam>My guess is that you already have the file corresponding to 05bd2vphyx8qwa1mhsj1zdaiv4m4v94wrlssrn0lad8d601dkk5s in /gnu/store, so Guix doesn't even try to download it

<iskarian>Also, are you trying to use the regular wayland tarball? in that case you wouldn't need to supply a new source field

<muradm>lfam: hmm.. hash would be a good guess..

<muradm>any way to specifically delete from store by hash content?

<lfam>No

<lfam>When you say "it expands to ...", what do you mean?

<lfam>What do you see?

<lfam>If you change the hash in wayland-next, then Guix will try to download it and you'll be told the correct hash

<lfam>There's no need to delete anything

<muradm>yes, just change the hash and see if it downloads, already tested, you are right

<muradm>thanks

<lfam>Great!

<muradm>great cleanup: https://paste.rs/Xcl

<muradm>replaced all copy pastes with inherited modifications ~400 lines down to < 100

<muradm>just commented out line is not working

<muradm>((#:configure-flags flags ''()) '())

<muradm>i just want to set configure-flags to empty list

<muradm>within substitute-keyword-arguments

<muradm>isn't '() empty list?

<lfam>I'll find an example for you

<the_tubular>One of my container is throwing this error : Unable to bind to http://localhost:1242 on the IPv6 loopback interface: 'Cannot assign requested address'.

<the_tubular>Is this guix related ?

<muradm>lfam: everybody in guix only adds flags in this way :))

<muradm>as much as i searched sources

<lfam>No, that's a weird syntax

<lfam>Try this: https://paste.debian.net/1206624/

<lfam>Also, note that if you clear #:configure-flags, there are still some configure options that are set by Guix, "behind the scenes"

<lfam>I don't think you'd want to clear these, however

<lfam>substitute-keyword-arguments is a little harder than other parts of packaging

***rt is now known as robin

<muradm>wlroots in guix is built with `(#:configure-flags '("-Dlogind-provider=elogind") in gnu/packages/wm.scm

<muradm>i definetly want to clear it :)

<muradm>lfam: that is really weird syntax, but it worked..

<lfam>If you look at the build log, you'll see those other configure flags that Guix adds

<lfam>For example, something like `vim $(./pre-inst-env guix build --no-grafts wlroots --log-file)`

<lfam>Depending on how you are building the package

<lfam>By the way, I adapated that syntax from the package of arpack-ng-openmpi

<muradm>i'm still miles away from pre-inst-env unfortunately, i look at guile-builder /gnu/store/didqxhm3l7kn1jxyj647fp18lg110vn0-wlroots-next-0.13.0-guile-builder

<lfam>Oh yeah, that works too

<muradm>it wrong place to look at?

<lfam>No, it's good

<muradm>this is finally ok then :) https://paste.rs/YPZ may be some one needs next sway :)

<muradm>lfam: that dependency issue on wayland

<lfam>Nice

<muradm>i use 1.6 for month or so, but all other programs come from guix it self compiled with older wayland

<muradm>and i didn't face any issue

<muradm>i suppose that wayland keeps backward compatibility

<muradm>in the end of the day, they call it wayland-protocol

<lfam>If you want an easier-to-read way to delete inputs, you could try this:

<lfam> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/video.scm?h=v1.3.0#n1638

<muradm>i suppose it does not mean that all applications all the time should be compiled against the same version of it

<muradm>oh.. perfect fold!

<lfam>Does sway 1.6 have any new features? :)

<muradm>oh that's so much better https://paste.rs/9YB

<muradm>lfam: yes :) can be running without elogind :)))

<lfam>Oh, cool

<lfam>Simple!

<lfam>Like i3

<muradm>yes

<lfam>I'm still using i3 and X

<muradm>uses libseat

<lfam>That's cool

<lfam>It's nice to see people working on this stuff

<muradm>last weekend i finally switched to seatd/greetd/sway, no elogind, no mingetty, earned ~400mb of free ram, and dramatically decreased power consumption on batteries

<muradm>very happy

<lfam>No mingetty!

<lfam>Do you use agetty?

<muradm>greetd

<muradm>minimalistic greeter

<lfam>I see, it includes agreety

<muradm>lfam: seatd: https://paste.rs/JZc greetd: https://paste.rs/xyd (still in progress) and usage: https://paste.rs/2wS

<muradm>greetd currently uses agreety and drops to bash, but next step is to add sway/greetd-gtk

<lfam>You are making a lot of progress

<muradm>tell me where and how to submit it )

<lfam>You have to put a GPL3+ license on it, and then email the files to <guix-patches@gnu.org>

<lfam>Guix is GPL3+

<muradm>i don't care about license ) it is all toys.. )

<muradm>i have last thing to decide on how to make greetd greeters switchable

<muradm>then it will be ready

<lfam>Cool

<lfam>We are working on core-updates now, so sway-next should become regular sway in a month or so

<muradm>sway 1.6 can run on libseat, may be we can make seatd and greetd services also there?

<muradm>i suppose it will take few days to complete greeters for greetd

<lfam>It sounds like you know best, so you should act accordingly

<muradm> https://paste.rs/BVl this is ps --ppid 2 -p 2 --deselect -fh

<muradm>on my host

<muradm>config is very lightweight, keeps like ~600-700mb on boot

<muradm>anyway, i will ping when second sway/greet-gtk based greeter ready and switchable ) this weekend i will try to complete it then let's see

<muradm>have to sleep now

<apteryx>lfam: hey I encountered the same glib-networking test issue on core-updates

<apteryx>retrying with: guix build glib-networking --with-latest=glib-networking --with-latest=glib

<lfam>No resolution yet in the upstream bug report, but I'm optimistic

<apteryx>yes, they seem responsive!

<apteryx>lfam: my experiment failed on building glib 2.68.3 on this test: 266/274 glib:glib / spawn-test FAIL 0.01s exit status 1

<lfam>I was concerned about if we should upgrade glib but I think they probably know what they are talking about when they said we need to use "2.68.*"

<lfam>Hopefully we can leave glib alone at this point in the cycle

<lfam>I don't have a sense of the state of the branch yet. ci.guix.gnu.org hasn't built Rust yet, so a lot of packages that I use (media-related) aren't built yet

<lfam>Since ffmpeg depends on rust now, transitively

<lfam>Regarding glib-networking, it's weird that the test suite does not even appear to begin running the failing test

<lfam>Oh, I misread it

<lfam>It does begin it (the test suite doesn't announce beginnings of tests)

<lfam>IIUC it spends 30 seconds on "verifying peer certificate" and then timesout

<lfam>I wonder if I can increase the timeout

<lfam>I wonder if it would ever finish

<abrenon>hi

<MysteriousSilver>\o

<abrenon>: )

<abrenon>o/

<bsturmfels>thanks efraim!

***dragestil is now known as dragestil-bot

***dragestil-bot is now known as dragestil

<efraim>:)

<abrenon>hey https://discuss.ocaml.org/t/ann-opam-2-1-0/8255

<abrenon>I hope they don't change the repository structure : )

<jas>hi! i realized i had 100+ system generations, and I'm running 'guix system delete-generation' on each of the old generations, but it is downloading a lot of stuff and is quite slow. why is this? the manual says the command is re-installing the bootloader, is that the reason?

<abrenon>well since the bootloader keeps track of all the old versions to generate an entry to boot directly into them, yeah, it has to update it every time it deletes a generation

<abrenon>there's a pattern to capture several generations at once I think but I never remember what it is

<abrenon>I think it can be found from $GUILE_LOAD_PATH/guix/scripts/system.scm

<jas>i can live with the bootloader part, but what explains the downloading?

<jas>it has finished running now, but i'm still curious

<jas>output is like this: https://pastebin.com/awJSRZBT

<abrenon>downloading sounds a bit weird except if you've previously garbage collected on your system, and it's deleted things that were used for instance to generate those old entries, corresponding to older versions of your system

<abrenon>your system has "indirect" dependencies required to build it, but that you didn't specifically asked for in your environment

<jas>sounds reasonable -- thanks! i do run gc in a cron job. i wasn't expecting it to gc things that are needed to re-install the bootloader

<abrenon>so they can get removed during a guix gc

<abrenon>well, once it's installed, they're not needed, right ?

<jas>yep, running gc after deleting all generations free up things again

<abrenon>it's the difference between telling your system "I want this" and "I want to be able to change this"

<abrenon>: )

<abrenon>yeah they don't seem to be specific to the bootloader

<abrenon>they are the parts needed to build the older states of your system

<abrenon>and even current states

<jas>garbage collection always leads to strange behaviour... i have to learn to live with it

<abrenon>it's not weird per se, it can be counter-intuitive if you don't have a clear view of "what's needed"

<jas>eventually, when we have a gazillion devices running unattended-upgrades+gc, this seems like something that could be improved though. seems unfortunate for things to be gc'd when they will be needed later on during 'delete-generations'

<abrenon>technically, it's any package referenced starting from one of the GC roots and recursing till nothing is produced

<abrenon>depends on what you're trying to optimize : )

<abrenon>but I get your point, it makes perfect sense

<jas>thanks for explaning! everything makes sense now. eventually internet usage for ci.guix.gnu.org may be a bottle-neck though

<abrenon>you could get this behaviour by identifying the parts that are needed to build your system and which get re-downloaded, and adding them explicitly to your system

<abrenon>I think you can use local caches to speed up things if you have several machines running guix (the package manager, not necessarily the system)

<abrenon>though I don't know how to do it

<jas>i suppose the parts that are needed change over time, though, so i would need to do this programmatically.

<abrenon>yeah, possibly

<jas>looking at the output, i wouldn̈́'t want to add, e.g., 'graphviz-2.42.3-doc' forever

<abrenon>in the end, maybe the easiest rational for what is kept and what isn't is "guix keeps what you are aware of and that you have asked for directly"

<jas>it was probably only required at some point and later fixed

<abrenon>the rest are artifacts, they merely happen to be there

<abrenon>but yeah, a good advice could be: don't guix gc right before delete-generations

<abrenon>…hmmm but then the things deleted right after the previous delete-generation would be needed and… ^^ I guess I don't really make sense and it can't be avoided unless you specifically ask for it : )

<raghavgururajan>Hello Guix!

<raghavgururajan>Hmm. What is the syntax to specify package output in config.scm? "foopackage:foo" didn't work.

<abrenon>hi raghavgururajan

<abrenon>with the quotes ? how do you specify the other packages ?

<raghavgururajan>abrenon: foopackage "foo" also didn;t work.

<raghavgururajan>hmm. manual uses quotes.

<raghavgururajan>May be I should use cons instead of append

<efraim>(list foopackage "foo")

<abrenon>ahhhh

<abrenon>thanks efraim !

<raghavgururajan>efraim: Does it have to be in separate list?

<raghavgururajan>Also, how to use outputs in file-append? Is (file-append packagename:foo "/dir") correct?

<leoprikler>raghavgururajan: inner list, yes

<fnstudio>hi :) my curl says it can't deal with https urls because it doesn't have any CAfile; i'm on guix on a foreign distro and using guix curl

<maximed>fnstudio: Do you have any certificates installed?

<roptat>fnstudio, did you follow the additional steps here: https://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html

<maximed>maybe test if "CURL_CA_BUNDLE" isset

<fnstudio>maximed roptat: brilliant, thanks, let me check that

<fnstudio>maximed roptat: yay, this is great! it works, i installed nss-certs and exported those env vars as reported in the link above

<fnstudio>thanks!!

<muradm>hi guix

<lfam>Howdy

<muradm>good, too more scuba dives today )

<lfam>Literal diving? Or diving into the code? :)

<muradm>literal :) because scuba infront ) otherwise would be code diving :D

*lfam just built the kernel in 5 minutes with 48 cores on the berlin server 😭

<lfam>That's cool. I did it a few times like 20 years ago and I really liked it. It's so peaceful down there

<muradm>i'm diving for 15 years or so almost every opportunity ) scuba dive, code dive, scuba dive, code dive, very productive )))

<muradm>and yes, silent and peaceful )

<lfam>And... no bugs under the ocean. Except for lobsters

<muradm>scuba diving - dealing bugs in my head, code diving - dealing with bugs in the software :D

<muradm>i have question, in before guix, other distributions adopted primary user group named after user. for instance muradm:muradm.

<muradm>as far as i saw, guix does it like muradm:users, am i right?

<lfam>Yeah, and we have 'users'

<lfam>I think it's been discussed on the mailing lists, but I don't remember what people said about it

<muradm>ok, then next question, seatd is supposed to be limited replacement of elogind, currently i run it as root:users.

<lfam>I guess it's kind of old-school, like where people shared files on multi-user Unix systems

<muradm>seatd interacts via unix socket, so I decided to run it as root:users. then socket can be accessed by members of users.

<muradm>is it fair decision? or should i have dedicated user for seatd daemon?

<muradm>personally, i don't see reason to have dedicated user for it

<lfam>Can somebody with more experience than me chime in? I don't really know about these things

<muradm>if i don't miss gnu/services/desktop.scm elogind runs as root

<muradm>root:root to be correct

<muradm>on the other hand it could be dedicated seatd user and seatd group, then user member of seatd group can login, but that is too complex imho, users should be enough

<muradm>user and group of seatd is configurable btw

<muradm>another question is cgroups file system

<muradm>as far as i see the only service mounting it is elogind

<muradm>this causes akward dependency from docker-service to elogind

<muradm>first i think mounting of cgroups should be done independently on demand with something like (cgroups-service-type ...)

<muradm>and then elogind, docker or whoeverelse depend on/extend it

<muradm>personally i use docker in some projects, so for now i solved it by seatd provides '(seatd elogind) which is also akward

<muradm>seatd it self does not require cgroups

<muradm>but because no elogind, some one should mount it

<muradm>these are 2 questions i have in my mind

***apteryx_ is now known as apteryx

<muradm>lfam: is this usable? https://github.com/pjotrp/guix-notes/blob/master/INSTALL.org#building-gnu-guix-from-source-using-guix---the-bullet-proof-way

<muradm>it looks more clear and simplier to understand, however this is more complex and scary https://guix.gnu.org/manual/en/guix.html#Building-from-Git

<muradm>all places say to run guix build daemon, but i'm on guix and already have one

<leoprikler>so does guix --version return something meaningful?

<muradm>in section 16.1 of manual there is an example guix environment guix --pure --ad-hoc help2man git strace

<muradm>as far as i understand it is incomplete to run ./bootstrap and ./configure

<muradm>any one has ready to use snippet of it?

<muradm>also is it better to run guix environment -C guix --pure ... so that it is in container?

<muradm>but later on it says to specify localstatedir same as host guix state dir

<muradm>is there any chance i will harm my host guix while doing ./pre-inst-env etc.?

<leoprikler>you won't harm your Guix, but you might "harm" some profiles

<leoprikler>i.e. you can e.g. ./pre-inst-env guix install guix, which is evil

<leoprikler>if you do something more reasonable, e.g. ./pre-inst-env guix install hello, you will get hello built from you pre-inst-env

<muradm>in general i never use guix install in everyday life

<muradm>why should i use it for development?

<leoprikler>you can even reconfigure your system from pre-inst-env with the same semantics that installed guix would have, only difference being that some stuff can't be tracked from pre-inst-env last I checked

<leoprikler>'twas an example, tbf I do all my development with environments as well, but I've seen some manifests and config.scms that would make you cry

<muradm>what if i say localstatedir=/something/other/than/host/state/store?

<muradm>i don't care wasting space, i care more not to touch my host )

<leoprikler>then guix can't talk to the daemon afaik, which is bad

<muradm>leoprikler: do you have guix environment command that includes all necessary dependencies for ./bootstrap and ./configure?

<leoprikler>again "touching" your host is no problem if you only `guix build` anyway

<muradm>ah, so ./pre-inst-env guix build ... will use guix build daemon from host?

<leoprikler>I'm somewhat dirty, I simply do `guix environment guix`

<leoprikler>if you are hyper pure, you might need to add git for checkout, autoconf&automake should already be part of guix' description

<muradm>so guix environment guix --pure supposed to have everything needed to run ./bootstrap and ./configure?

<leoprikler>yup

<leoprikler>I think the problem might be with some weird part of Guix, that uses autoloaded libraries

<leoprikler>some features, e.g. importers, are optional

<leoprikler>oh and recently the translations broke for me at least, dunno about others

<leoprikler>so if you get some weird error in doc/, try touching that file and see if it helps

<muradm>me always pure, will go hard way with --pure for now

<muradm>guix environment guix --pure --ad-hoc

<muradm>which git

<muradm>bash: which command not found

<muradm>lol :)

<rekado_>that’s expected, no?

<rekado_>the built-in command is “type”

<rekado_>but you won’t have git inside that environment

<muradm>guix environment guix --pure --ad-hoc git help2man strace -- ./bootstrap

<muradm>Makefile.am:756: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS

<muradm>should not be critical i guess

<iskarian>I made an alias to just do 'guix environment guix --pure --ad-hoc <dev packages>'

<muradm>if my host example package is /gnu/store/<hash>-git.../bin/git then --localstatedir=/gnu or --localstatedir=/gnu/store?

<muradm>iskarian: how exactly?

<iskarian>typically --localstatedir=/var

<iskarian>I put a line in my ~/.bashrc: "alias geg='guix environment guix ...'"

<muradm>ah ok, i mean what exactly in <dev packages>.. )

<muradm>iskarian: why /var?

<muradm>from what i understand it should point to the store, no?

<muradm>and my store is /gnu/store

<iskarian>ahhh, I think right now I have nano, git, git:send-email, less, help2man, strace, nss-certs, and whatever provides readelf

<iskarian>I haven't yet figured out how to have it open something in my running emacs, though, hence nano

<irfus>yes

<iskarian>re: localstatedir, take a look at /var/guix on a system configured like that :) It has stuff like profile links, gc roots, daemon sockets, substitute info, and so on

<iskarian>to set the store dir, you would use --with-store-dir=

<muradm>rtfm... https://guix.gnu.org/manual/en/guix.html#The-Store => --localstatedir=/var

<iskarian>well, I try to be a little more tactful than 'rtfm' :)

<iskarian>(my favorite configure option is "--with-courage")

<muradm>iskarian: rtfm was in answer to my self.. )

<muradm>--with-courage? what it does?

<muradm>./configure --localstatedir=/var seems ok

<roptat>to build on a system that's not supported

<iskarian>Yes, I was explaining why that wasn't my answer to you, haha

<muradm>make gives warnings on 'po' files

<roptat>it's fine

<muradm>the amount of entries blah blah blah

<roptat>po4a is not very happy we have a single file for the two texi files

<roptat>but it's not a real issue

<muradm>ok then.. waiting

<muradm>iskarian: why not add emacs to the list? why bother with nano?

<iskarian>I haven't figured out how to make it open in my current emacs session rather than open a new emacs

<muradm>;;; Failed to autoload semver-*

<muradm>;;; no code for module semver

<muradm>but it proceeds

<roptat>that's fine too

<iskarian>it's fine, it's used for one importer

<muradm>guix/monads.scm: shadows previous definition ...

<iskarian>it's fine also

<muradm>let it go until fails you say.. )

<roptat>don't worry, unless the build breaks, it's all fine

<muradm>guix environment guix --pure --ad-hoc git help2man strace

<muradm>here guix is package?

<muradm>or a command?

<roptat>the first guix is the command, the second guix is the package

<muradm>why not: guix environment --pure --ad-hoc guix git help2man strace?

<muradm>is it different?

<roptat>yes, without --ad-hoc (or before it), it adds all the dependencies of the package, not the package itself. After --ad-hoc, it adds the package itself to the environment

<abrenon>hi roptat

<roptat>hi abr

<abrenon>I'm making some progress with the fix

<roptat>\o/

<abrenon>although in between I've found https://opam.ocaml.org/doc/Manual.html#opam-root which seem to claim that the assumptions you made on browsing the repositories are valid

<abrenon>while I'm still taking some time to write a guile equivalent to : find ${dir} -type d -name '<some-package>.*' ^^

<muradm>roptat: btw, what about this one? http://issues.guix.gnu.org/49804 :)

<roptat>muradm, I don't feel competent to review this one, I'm not sure why we had this computed file before

<roptat>maybe try to ping the author of the code to see if they think it's ok?

<muradm>roptat: ok, thanks

<roptat>abrenon, you can use find-files and filter: (find-files dir "some-package.*" #:directories? #t), and then filter that with stat and stat:type (or whatever it's called) to return only the directories

<abrenon>hmmmm… I love it when the tools already exist ^^

<abrenon>(also, I'm assuming the second one was for me: and it's what I did, I mailed them and asked them if they had some more evidence than what they did would stay supported appart from the fact that opam does currently support their structure)

<muradm>FAIL: tests/channels.scm

<roptat>it was still for muradm ^^

<abrenon>oh, sorry ^^

<roptat>you mean you contacted the authors of *checks notes* grew?

<abrenon>that's right : )

<roptat>ok, not sure why you asked that, http repositories seem to have always been supported, and it doesn't seem opam plans to drop them

<abrenon>no, not http repositories, repos with a packages/<package-name>/<package-name>.<version>/ structure

<roptat>oh, they have an index.tar.gz too

<abrenon>the page I linked seem to suggest they're required, but at least as of now opam supports other

<abrenon>which is why I'm writing something that recurse and expects to find version directories anywhere

<roptat>I see

<abrenon>no harm in being to lenient and accepting malformed structures, but I wouldn't want to rewrite too much of your code for no reason

<podiki[m]>Hi guixers! Trying to boot the installer (usb stick) and getting "error in finalization thread: Success" and "Error: Driver 'pcspkr' is already registered, aborting..."

<podiki[m]>This is just after gathering entropy for key pair

<roptat>the first one is harmless

<roptat>not sure about the second one, is nothing else happening? does the system work?

<podiki[m]>It just hangs after like 3 messages after finalization thread message

<muradm>podkiki[m]: i have the same things in my host and it seems to work

<podiki[m]>other messages: one from udevd "no sender credentials received, mssage ignored", "watchdog hardware is disabled" and igc "no suspend buffer for PTM"

<podiki[m]>none of them give me any clues, any ideas?

<roptat>podiki[m], I can't help you unfortunately, but you might get more help if you ask on help-guix@gnu.org

<podiki[m]>(also some GC Warnings to start"

<podiki[m]>any of those messages seem important? they don't to me at least

<muradm>podiki[m]: maybe imgur screenshot?

<muradm>photo with phone? :)

<muradm>guix environment guix --pure --ad-hoc <dev-packages>

<muradm>is it possible to turn it to:

<muradm>guix environment guix --pure --ad-hoc -m manifest.scm ?

<podiki[m]> https://i.postimg.cc/vT5mmHRP/20210805-140554.jpg

<muradm>will packages specified in manifest.scm be --ad-hoc?

<roptat>muradm, no need for --ad-hoc with -m

<roptat>you'll get the list of packages specified in the manifest

<muradm>podiki[m]: lol postimg.cc is blocked in country where am i now )

<roptat>podiki[m], type the enter key maybe?

<podiki[m]>i was just searching for no-login image share, sorry (any good ones?)

<podiki[m]>tried enter and attempt to switch ttys, nothing

<muradm>make check failed

<muradm> https://paste.rs/B1a

<muradm>FAIL: tests/channels.scm

<podiki[m]>even if it was a non-free firmware thing, shouldn't just hang there without further messages right?

<roptat>can you report to bug-guix?

<roptat>podiki[m], yeah, not sure what's happening in your case, like I said, people on help-guix might be more helpful

<cehteh> https://lists.x.org/archives/xorg-announce/2021-August/003101.html long awyited release right? :)

<muradm>cehteh: so mission critical

<podiki[m]> https://imgur.com/a/sJ7nKVl

<cehteh>what hardware is that?

<cehteh>and did the prev generation boot?

<muradm>guix environment guix --pure --ad-hoc git help2man strace -- guix --version

<podiki[m]>cehteh: me? this is the installation image, does not have an os on this computer. it is the 1.3.0 image on usb stick

<muradm>guix environment: error: execlp: No such file or directory: "guix"

<roptat>muradm, guix environment guix doesn't put guix in the environment

<roptat>only its dependencies

<muradm>ah.. now it is clear, then it could be:

<cehteh>podiki[m]: i would guess it dislikes your hardware for some reason, but yeah only uneducated guess

<muradm>guix environment guix --pure --ad-hoc guix git help2man strace?

<roptat>yes, that way you have guix in your environment

<roptat>but it's an older guix that what you had outside

<roptat>if it's the guix repository, you should instead call ./pre-inst-env guix after you've run make

<podiki[m]>cehteh: yeah....i'll investigate and file to help-guix if I don't figure it out soon (will report back)

<muradm>roptat: ./pre-inst-env make authenticate ?

<roptat>oh

<muradm>16.1 manual didn't state that

<roptat>mh... you probably don't need --pure for that

<muradm>guix environment guix --pure --ad-hoc guix git help2man strace -- make authenticate did it actually

<podiki[m]>I think it is a non-free issue, probably amd microcode; that's all I'll say here unless I find out otherwise

<podiki[m]>would be good to have more helpful message in the boot, but not sure how that would work with something like that

<roptat>:(

<apteryx>podiki[m]: non-free issue with AMD graphic card?

<leoprikler>it happens more often than you think

<podiki[m]>not sure how to diagnose that...I did have the same AMD card in another system and a live USB worked

<apteryx>think again about the helpful error messages. It may not output any video if it doesn't have its blob served for breakfast.

<podiki[m]>now on a newer AMD CPU. but maybe some combo or from bios?

<podiki[m]>yeah, tough

<apteryx>One would think that with 100 kloc of free software drivers you'd at least be able to get 2D working without binary blobs, but no!

<apteryx>thanks, AMD

<podiki[m]>though it did work on the live USB I had, so might be this motherboard/AMD cpu combo (previous was different mb and Intel)

<apteryx>you probably tried the nomodset kernel argument already?

<muradm>after make check on guix repo, there are some t-profile* links/lock-files remain in git root

<muradm>should i just cleanup after every make check?

<podiki[m]>apteryx: have not, let me try. I can do that by editing the boot command in grub right?

<muradm>these are remainings after make check https://paste.rs/aBC

<apteryx>yes, you pret the 'e' key, then edit the linux line, and boot with C-x or F10 IIRC

<apteryx>and sorry for the typo, it's 'nomodeset'

<vagrantc>why did the world give up on perfectly usable serial consoles... :)

<podiki[m]>success! dunno why I didn't think of that (being long time sufferer of nvidia especially)

<podiki[m]>throws a warning about amdgpu nomodeset something, but got the installer up

<apteryx>great!

<podiki[m]>I wonder why the live image I made had worked (on slightly different hardware), will have to compare that config to the installer in case it is useful

<podiki[m]>it was also current, not 1.3.0; a good sign that newer was better at least

<apteryx>podiki[m]: it probably has nomodeset on

<apteryx>hmm, (gnu system install) says no.

<podiki[m]>I don't think it did from my quick search but I'll have to look more thoroughly later

<apteryx>muradm: yeah, I guess we should ignore these in the .gitignore

<muradm>apteryx: definetly :) have to do make && make check again after accidential make distclean

<muradm>or do them under /tmp or something

<podiki[m]>hitting an error in partitioning (all on one partition, ext4, just the defaults): match-error with args `("match "no matching pattern" (#f ext4))

<apteryx>is this in the installer?

<podiki[m]>it is trying to do some matching and not finding matching pattern with (#f ext4)

<podiki[m]>yes, the installer

<apteryx>did you make the installer yourself from the master branch?

<apteryx>or it's the one from 1.3.0

<podiki[m]>this is 1.3.0

<podiki[m]>i see others have hit a partioning error in the past

<podiki[m]>this is defaults, no encryption

<podiki[m]>let me see if i can grab the log...

<apteryx>perhaps a bug in guile-parted

<apteryx>I had encountered one with NVMe drives in the past

<muradm>any clue about FAIL: tests/channels.scm ?

<podiki[m]>no curl in installer image, was hoping to send directly to ix.io from there

<podiki[m]>apteryx: yeah, nvme here too

<podiki[m]>so I'd have to manually partition then

<apteryx>muradm: see info '(guix) Running the Test Suite'

<apteryx>podiki[m]: if you have the time, you could try a recent version of the installer, and report the bug if it's reproducible.

<podiki[m]>has there been changes to guile-parted that should help?

<podiki[m]>recent = from master? (could do that yes)

<apteryx>I'm not sure. mothacehe would know but they aren't here

<apteryx>the latest x86_64 image can be found here: http://ci.guix.gnu.org/build/921061/details if you want to try

<muradm>apteryx: read that, didn't help, do you mean send to bugs-guix@gnu.org?

<podiki[m]>i'll do it now and report back. thanks for the help so far all!

<apteryx>muradm: no I meant I usually run the tests with make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1

<apteryx>to see the errors on my terminal directly (rather than grepping the test-suite.log)

<muradm>ah

<podiki[m]>apteryx: is that image bootable? doesn't look like it

<apteryx>hmm. Actually I'm not sure how it's made.

<podiki[m]>i could build it from master, the system config install.scm or something right?

<apteryx>yes! I think the manual covers that.

<podiki[m]> https://guix.gnu.org/manual/en/html_node/Building-the-Installation-Image.html knew I saw it somewhere

<leoprikler>only 100 issues to go to reach 50k

<leoprikler>Whoever wins that should get some (friendly) spam mail about winning a RISC board or something :)

<drakonis>noice

<muradm>roptat: that pam-limits issue is caused here https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/services/base.scm?id=909147e43f8c9f8c9b9d33597d5dd83facca699c

<muradm>like 5 or more years ago

<muradm>lfam: do you remember that commiter ^^^

<roptat>that's rekado_ :)

<roptat>leoprikler, like this https://gu-witness.s3.amazonaws.com/image/14411945894879494be8fa2eaaa6ce42624364a90fa4e-mediumoriginalaspectdouble.jpg ? :)

<muradm>rekado_: hi, here is an issue: http://issues.guix.gnu.org/49771 and here is solution: http://issues.guix.gnu.org/49804

<muradm>could you please comment on this?

<muradm>right now i have to do this, in order to have some other files under /etc/security/ https://paste.rs/sFG

<rekado_>I don’t understand the solution

<rekado_>(I’m also busy with something else right now)

<roptat>I think instead of having one service specify the content of /etc/security (by creating a computed-file for it), the solution is to create only the one file that's needed and let other services expand /etc/security for other files

<roptat>I think it's ok, but I was wondering if there was a specific reason you used a computed file?

<roptat>maybe after 5 years it's hard to remember ^^'

<rekado_>I don’t recall. But I guess back then I just needed /etc/security/limits.conf and there was no need for anything else.

<podiki[m]>partitioning worked in installer from master

<podiki[m]>even gave an error about not liking a partition that must have been partially created by previous installer

<muradm>roptat: how it can be be expanded by others?

<muradm>if it is possible to "expand" by others, why pam-mount-service-type didn't do so?

<podiki[m]>thanks apteryx for your help too

<muradm>from what i see pam-mount-service-type does it very clean, simple and non-conflicting

<podiki[m]>(thankfully all my playing with guix on foreign distro helped as I had everything on the laptop to help)

<muradm>patch provided adapts same behavior for pam-limits as for pam-mount

<roptat>muradm, I need the patch again

<muradm>roptat: http://issues.guix.gnu.org/49804

<roptat>so, it's a pam-extension, right?

<apteryx>podiki[m]: glad you got it solved!

<roptat>I mean, it's still an extension of pam-root-service-type

<muradm>both pam-limits and pam-mount are pam-extensions, but problem is how they use etc-service-type extension

<muradm>pam-mount says to etc-service-type "i need /etc/security/pam_mount.conf.xml"

<muradm>pam-limits says to etc-service-type "i need /etc/security" and then mkdir "security" and writes "limits.conf" there

<muradm>pam-limits could simply say to etc-service-type "i need /etc/security/limits.conf"

<podiki[m]>apteryx: may have spoken too soon, doesn't look like it did the efi partition correctly....

<muradm> http://issues.guix.gnu.org/49804 does exactly that

<podiki[m]>grub-install fails with "doesn't look like an efi partition"

<podiki[m]>ugh

<podiki[m]>let me check manually what it did...

<muradm>with current behavior of pam-limits-service no one else can't ask from etc-service-type "i need /etc/security/something"

***xgqt_ is now known as xgqt

<muradm>and pam-limits-service does not need /etc/security it needs /etc/security/limits.conf thats all

<podiki[m]>installer made the efi boot partition ext4 (needs to be fat32 no?)

<muradm>when fixed, ls -la /etc/security gives security -> /etc/static/security

<muradm>when non fixed ls -la /etc/security gives security -> /gnu/store/some-derivation-for-computed which cannot be written by anyone else other than lambda in pam-limits-service-type

<muradm>even if it is supposed that others "expand" (how?) "/etc/security", then i suppose pam-limits-service-type should provide extension for that, and all others should depend on pam-limits-service-type or something like that

<muradm>but that is wierd point of view for me, pam-limits-service-type just needs /etc/security/limits.conf and should not do more than that

<muradm>i hope i could explain it.. )

<roptat>that's very clear, thanks

<roptat>I'll push your patch when I can :)

<muradm>roptat: thanks :)

<podiki[m]>my final report on the installer: partioning seems a bit fragile, doesn't like some partitions that were already created or created manually. when I manually deleted everything and rebooted the installer it was fine

<apteryx>podiki[m]: thanks for the report! It could be useful to log this experience to bug-guix@gnu.org while it's still fresh

<podiki[m]>yeah, unfortunately I'm light on some specifics, but can run down the things I saw

<podiki[m]>(and for obvious reasons don't want to test partitioning anymore on the live system :-P; maybe a vm later)

<podiki[m]>and for the record I used the graphical partitioning, deleted the swap and remade / partition; worked and now in a guix system (hooray!)

<elb>I'm using guix pulled as of ten minutes ago with mutt 2.0.7 (the currently packaged version) on a Debian foreign system, I have locales (including my LANG, en_US.UTF-8) in ~/.guix-profile/lib/locale, but mutt sets my charset to us-ascii

<elb>does anyone know why that might be?

<elb>debian native mutt and neomutt (both moderately ancient) work fine, I assume it's a locale problem of some sort

<elb>(symptom is, non-ASCII chars render as ? or \nnn codes, :set &charset ?charset returns "us-ascii" instead of "UTF-8")

<podiki[m]>is it common to get the warning that "cannot determine provenance for current system" on a fresh guix install and doing a reconfigure for the first time?

***jess is now known as j

<podiki[m]>(or because using new config file?)

<maximed>podiki: IIUC, provenance information should be available after the first "guix pull"

<maximed>(and, for system generations, after the first "guix system reconfigure" after the "guix pull")

<podiki[m]>already did that, but sounds like expected on new system until something happens

<podiki[m]>makes sense, just checking after my adventures with the installer

<roptat>elb, have you set GUIX_LOCPATH?

<bost>Hi. As a guix newbie, I'm struggling shared clipboard when running in VM with qemu. The https://guix.gnu.org/manual/en/html_node/Running-Guix-in-a-VM.html is not specific enough. And I tried a lot of combinations. See https://github.com/Bost/dotfiles/blob/master/fish/functions/guix-os.fish

<bost>Can anybody help please?

<leoprikler>roptat: I said RISC, not RISK :(

<bost>*with shared clipboard. SRY

IRC channel logs

2021-08-05.log