<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
<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
<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
<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
<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)
<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 : )
<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?
<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)
<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?
<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
<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 firstname.lastname@example.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