IRC channel logs


back to list of logs

<Acou_Bass>apparently i wasnt auto-logging in here, now i feel sad :(
<Acou_Bass>hi :D
<Acou_Bass>last time i was in here i think you helped me with encrypted drive
<Acou_Bass>been ruining guixSD ever since (though i couldnt get the disk encryption to work), interesting distro to say the least
<rain1>I showed my friend some guixsd tricks and it blew them away
<rain1>they said it's "advanced alien technology"
<rain1>it is really great
<Acou_Bass>its definitely not like anything ive used
<Jookia>Acou_Bass: What kind of disk encryption issues are you having?
<Acou_Bass>Jookia: it was a long time ago... but i was having trouble with getting the password prompt to pop up
<Acou_Bass>so obviously itd go past grub and grub would sit there and shrug its shoulders because theres no / drive to be found ;P
<Jookia>well if you want to try again i'm fine with helping :)
<suitsmeveryfine>Jookia: I just tried a_e's encryption setup and I'm now stuck
<Acou_Bass>;D i may do at some point... despite the machine being a laptop it rarely leaves my sight so im not REALLY fussed about having it encrypted
<Jookia>suitsmeveryfine: Oh, can you link me it and tell you where you're stuck?
<suitsmeveryfine>Sure. I have just completed the install and rebooted. I can open the GuixSD GRUB menu (and view it in GNU screen)
<suitsmeveryfine>but I get a number of error messages
<Jookia>sure, what are they?
<Jookia>is this on a libreboot machine?
<suitsmeveryfine>After completing the install I edited grub.cfg as suggested by inserting these two lines at the very top:
<suitsmeveryfine>insmod luks
<suitsmeveryfine>cryptomount -u 1aa...
<suitsmeveryfine>not "1aa" in my case but a different UID
<Jookia>is this with or without my patches, and is this encrypted /boot
<suitsmeveryfine>I've done unencrypted /boot with encrypted /
<suitsmeveryfine>without your patches
<Jookia>can you paste your grub.cfg
<suitsmeveryfine>In that case I guess that I would need to reboot into the installer
<suitsmeveryfine>I can do that
<Jookia>that'd be great
<suitsmeveryfine>I guess that I would have to upload a photo
<Jookia>that's cool too
<suitsmeveryfine>Strange! My added rows have disappeared
<Jookia>suitsmeveryfine: :O
<Jookia>suitsmeveryfine: reconfiguring will overwrite your grub.cfg
<suitsmeveryfine>Jookia: but this was after guix system init
<Jookia>ah, hmm
<suitsmeveryfine>I've not reconfigured since
<Jookia>well, add the line again? :D
<suitsmeveryfine>I'm doing it now :)
<suitsmeveryfine>error: file `/boot/grub/i386-coreboot/luks.mod' not found.
<suitsmeveryfine>error: PATA passthrough failed.
<suitsmeveryfine>error: no such cryptodisk found.
<suitsmeveryfine>Then I get the same text as posted above
<suitsmeveryfine>This is libreboot 2014-07
<Jookia>is there a /boot/grub/i386-coreboot/ file
<suitsmeveryfine>hmm, I don't know
<Jookia>there probably isn't, it should be i386-pc
<suitsmeveryfine>The funny thing is that the GuixSD GRUB menu loads
<suitsmeveryfine>but if I select the kernel I get "error: no such device:
<suitsmeveryfine>etc. And return to the GRUB menu
***nckx|offline is now known as nckx
<suitsmeveryfine>Have I perhaps edited the installers
<suitsmeveryfine>grub menu?
<suitsmeveryfine>zile /boot/grub/grub.cfg?
<suitsmeveryfine>could that be it?
<Jookia>you have to edit the boot/grub/grub.cfg in your mnt stuff
<Jookia>so /mnt/boot/grub/grub.cfg
<suitsmeveryfine>will I need to run the cow comand also?
<Jookia>not unless you're reiniting
<suitsmeveryfine>ok, good
<suitsmeveryfine>no, I can see that I have the two rows up there
<Jookia>hmm, what are the top rows
<suitsmeveryfine>inmod luks
<suitsmeveryfine>cryptomount -u MYUID
<Jookia>and is there a /boot/grub/i386-coreboot/luks.mod file
<Jookia>/mnt/boot *
<suitsmeveryfine>no it ends with -pc
<Jookia>hmm, i wonder why its looking for -coreboot then
<suitsmeveryfine>Maybe I should try to install a different revision of libreboot
<suitsmeveryfine>and put the HDD in a different computer
<suitsmeveryfine>I will try to reinstall libreboot: the only problem is that the keyboard usually don't work afterwards
<Jookia>that's odd
<suitsmeveryfine>yes, I know
<suitsmeveryfine>new libreboot, let's see
<suitsmeveryfine>Ah: Attempting to decrypt master key...
<suitsmeveryfine>but now keyboard unfortunately :)
<Jookia>That's not good. Have you tried #libreboot for that?
<suitsmeveryfine>not yet, but I will report it
<suitsmeveryfine>now the keyboard is working
<suitsmeveryfine>but I need to look at how a usqwerty keyboard looks like
<Jookia>a friend of mine is also getting i386-coreboot issues
<suitsmeveryfine>It works, hurray!
<Jookia>Oh what
<suitsmeveryfine>with a more recent version of libreboot
<suitsmeveryfine>I even have a working screen in GNU/Linux and working GuixSD in GNU screen
<Jookia>is this on the macbook 2,1 ?
<suitsmeveryfine>No, it's on a T60
<pizzaiolo1>(20:54:18) Jookia: a friend of mine is also getting i386-coreboot issues
<suitsmeveryfine>with a high quality screen
<Jookia>i think this is because libreboot isn't loading the GRUB
<Jookia>but chainloading grub.cfg
<Jookia>and using its own grub in the flash
<Jookia>so my patches would fix this ;-)
<suitsmeveryfine>well I didn't get this error
<Jookia>the i386-coreboot errors
<suitsmeveryfine>maybe pizzaiolo1 should also upgrade libreboot
<pizzaiolo1>suitsmeveryfine: the latest libreboot looks a bit too unstable
<Jookia>Basically i386-coreboot errors is because you're using coreboot/libreboot's GRUB and when grub.cfg runs 'insmod' it tries to load modules suited for that GRUB
<suitsmeveryfine>I agree
<suitsmeveryfine>aha, interesting
<Jookia>The reason libreboot_grub.cfg was invented was so we could have distros that don't run insmod ;)
<Jookia>It's possible updating libreboot would've added those modules to the ROM
<Jookia>I should update to latest libreboot
<Jookia>Doesn't look like there's a ROM for the T400
<suitsmeveryfine>Do you have a T400?
<suitsmeveryfine>The touchpad is working here at least :)
<Jookia>I'll just load up a live USB of Debian and rebuild it
<suitsmeveryfine>Jookia: I just did that with the parabola live USB
<Jookia>I wonder if this would fix my T400 screen issue
<suitsmeveryfine>what is your screen issue?
<suitsmeveryfine>No display in GRUB?
<Jookia>something something EDID
<suitsmeveryfine>OK. Same as me I guess
<suitsmeveryfine>btw, your initramfs module helped me
<Jookia>You still have the screen issue with latest Libreboot?
<Jookia>My what helped?
<suitsmeveryfine>a module for the initial ram disk
<Jookia>Oh, i915
<suitsmeveryfine>I believe that an earlier install worked but that I didn't have any screen then
<suitsmeveryfine>now the install really worked
<suitsmeveryfine>But I chose unencrypted /boot this time
<suitsmeveryfine>I guess that I should put this drive in a non-libreboot machine
<rain1>Are you using UUIDs in the config file?
<suitsmeveryfine>rain1: yes
<suitsmeveryfine>I entered it by hand
<rain1>nice! I'd like to learn that, can I see the file?
<suitsmeveryfine>you don't really need to, just add these two lines:
<suitsmeveryfine>insmod luks
<suitsmeveryfine>cryptomount -u UUID
<suitsmeveryfine>to /mnt/boot/grub/grub.cfg
<suitsmeveryfine>at the very top of the file
<rain1>I'll try setting all that up in qemu
<suitsmeveryfine>to get the UUID, enter: cryptsetup luksUUID /dev/sda2
<Jookia>suitsmeveryfine: I wonder how hard it'd be to make this a default
<rain1>if it's not any trouble I'd like to see the config.scm file
<suitsmeveryfine>no problem. Hold on
<suitsmeveryfine>need to install a webbrowser first though :)
<rain1>you could get curl and use to avoid browser!
<suitsmeveryfine>ok, if you teach me how
<rain1>cat /etc/config.scm | curl -F 'f:1=<-'
<rain1>should print a short url that has the file in it
<suitsmeveryfine>downloading curl...
<suitsmeveryfine>Jookia: it shouldn't be too hard. The installation also worked without any GRUB error.
<Jookia>suitsmeveryfine: thats to be expected since its unencrypted /boot
<suitsmeveryfine>So it means that my setup is completely compatible with GuixSD
<suitsmeveryfine>Damn, downloading curl brings with it gcc and other big packages
<Jookia>define 'compatible', having to re-edit grub.cfg every time isn't good
<suitsmeveryfine>true! that's really bad
<Jookia>it's okay, you can just edit your guix to re-add it
<suitsmeveryfine>yes I know how I can do it, but I mean for other people
<rain1>im sorry thats a shame about curl
<suitsmeveryfine>as default as you said earlier
<suitsmeveryfine>rain1: that's not your fault
<rain1>i just thought it would be easier/faster than getting a browser
<suitsmeveryfine>hmm, I forgot to run `guix pull`. Maybe that's why
<Jookia>suitsmeveryfine: For other people we'd have to find a way to automate it, aka using UUIDs
<suitsmeveryfine>it would be nice to have an ncurses installer for GuixSD
<rain1>oh thats a good idea!
<suitsmeveryfine>How hard do you think it would it be to copy and modify an existing installer like Debian's?
<rain1>It could be written in guile!
<suitsmeveryfine>oh, of course :)
<nckx>\\o Hullo Guix. Is there anything like #:build-targets? Assuming that (system* "make" "foo" "bar") won't take things like parallel builts into account.
<nckx>Or is that not considered a problem.
<Jookia>nckx: build-targets?
<nckx>like #:test-target for the build phase.
<nckx>A quick grep suggests calling make manually is the way to go, but that feels a bit hacky.
<Jookia>test-target, for tests?
<Jookia>what do you mean 'target'
<nckx>Jookia: the... target to make?
<suitsmeveryfine>rain1: I'm sorry but I need to go to sleep now
<Jookia>oh, i see
<suitsmeveryfine>for some reason I can't just install the packages
<Jookia>usually you use a build system like autotools but you could write your own command to run things
<suitsmeveryfine>GuixSD wants to pull down everything
<suitsmeveryfine>just to install curl and/or icecat
<suitsmeveryfine>either something has gone wrong or the dependencies are tremendous
<Jookia>suitsmeveryfine: 'everything'?
<suitsmeveryfine>curl demanded GCC and various other build tools
<Jookia>well you need GCC to build C
<nckx>Jookia: it's the GNU build system but, unfortunately, that doesn't work in this case. I need to ‘make all static’ and there's nothing like ‘--enable-static’ provided AFAIK.
<suitsmeveryfine>but I would be happy with just the prebuilt binaries
<Jookia>nckx: why static?
<Jookia>suitsmeveryfine: did you run guix pull?
<suitsmeveryfine>the first time I didn't
<Jookia>maybe curl isn't built upstream yet
<suitsmeveryfine>I did it as normal user
<suitsmeveryfine>and installed as normal user
<nckx>Jookia: because dynamic libraries are dead #docker #go /s
<nckx>(Because I'm mucking about with btrfs for the initrd :-)
<nckx>Which must be static.
<suitsmeveryfine>I go to bed now. night!
<Jookia>it must be static?
<suitsmeveryfine>rain1: use Andreas Enge's setup
<suitsmeveryfine>mount first the encrypted file system as /mnt and then the unencrypted /boot as /mnt/boot
<Jookia>nckx: Why does btrfs need to be static?
<nckx>Jookia: btrfs-progs. Well, look at its dependencies, for one. It's a bloat party and I don't want to be invited.
<nckx>Never mind, I'll just use (system* "make") and wait a bit longer... :-)
<Jookia>How much space does it take up in the initrfams
<Jookia>It's frustrating there's no way to get a path to a package using guix
<rain1>So if a library dependns on (or transitively depends on) a program that has been given a security fix
<rain1>will that be rebuilt when I do something like guix package -u ?
***orly_owl_ is now known as orly_owl
<Jookia>mark_weaver: A while back you commented on how GTK_DATA_PREFIX wasn't a good solution for setting GTK themes. I've written a patch in the past hour or so which adds the ~/.guix-profile and /run/current-system/profile paths to GTK+{2,3} itself. It seems fine so far, so I'll throw it up on the mailing list soon hopefully
<civodul>Hello Guix!
<Jookia>Hey ludovic
<JeanLouis>is here someone who does not have FB account? Just for opinion, as I got impression Guix users take care of security and privacy very much.
<petter>i don't. Never have. Never will.
<taylan>ACTION uses Facebook to keep in contact with his father and brother, and a few old friends once in a blue moon
<pizzaiolo>civodul: apparently the eo locale is eo_XX-UTF-8:*/
<petter>i don't only think Facebook is now a tool for NSA/CIA. I think it always has been a NSA/CIA project, from the start.
<JeanLouis>petter: taylan: thanks for feedback. I wanted in beginning to use FB for marketing, now I end up being tied in proprietary communication completely controlled by third party company.
<JeanLouis>even removing my data from facebook takes more than 14 days.
<petter>there is no removing data from Facebook. Only hiding it from normal users.
<ringst>With a lot of effort, if you live in the right country, you can request all the data Facebook has stored about you
<ringst>It includes deleted posts, and they're just marked with "deleted"
<roelj>Is the "MIT license" the same as Expat?
<JeanLouis>petter: I guess yes, even if I "delete" data, it will remain forever somewhere
<rain1>I have a facebook account!
<rain1>the funny thing is I never created it or used the site
<rain1>they make shadow accounts about everyone
<rain1>look into shadow account
<rain1>i think twitter is also bad for liberty, but EFF has one
<petter>rain1: interesting. Thanks for link. (Even though it goes straight to the robot wall)
<JeanLouis>rain1: exactly, someone tags you, if they put your picture, and Facebook creates profile about you, now they know it is YOU. Even if you don't have account.
<Acou_Bass>shadow accounts are just weird
<rain1>my conception is that they are able to determine the existence of holesv in their network and do fill in as much data about these people, without their consent, as they can
<rain1>but anyway... :)
<Acou_Bass>im curious though
<ringst>roelj: if I remember correctly, Expat is one of two licenses that are often called the MIT license
<Acou_Bass>if you, as someone whos never used FB, now created an account, having had a 'shadow account' nicely fill-edout
<Acou_Bass>would you then have a nicely-populated FB page complete with past posts from yourself? :P
<Acou_Bass>automatically created from your shadow
<roelj>ringst: Ok, then I will compare the license file to the words of the Expat license and see if it matches.
<roelj>ringst: Thanks for the information.
<rain1>Acou_Bass, they will show you who all your friends should be but I think they let you pretend you're doing the rest
<rain1>sorry for off-topic though
<Acou_Bass>'you checked into xx restaurant... two weeks before creation of your account!!'
<Steap>How to install software:
<petter>Steap: hehe, that is great :)
<Steap>that is so true
<civodul>heh, fun
<rekado>roelj: sometimes "MIT" means Expat, sometimes it means "X11".
<JeanLouis>I am yet on Debian using guix, now I use bash/terminal from guix, and I get: bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
<JeanLouis> mesg: error: tty device is not owned by group `tty'
<JeanLouis>ls -l /dev/pts/1
<JeanLouis>crw--w--w- 1 admin admin 136, 1 Mar 11 14:42 /dev/pts/1
<JeanLouis>maybe something on guix is different to debian that I cannot make it right
<JeanLouis>instead of | I see â
<JeanLouis>hmm I changed from zsh to bash, maybe I need some GUIX_LOCPATH
<janneke>JeanLouis: do you have glibc-locales installed?
<JeanLouis>let me see
<JeanLouis>I changed from zsh to bash, not even "guix" says: "gnu/store/311nvir0pz1mhf0mgsmfrw00qfj7yq0j-bash-4.3.39/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
<JeanLouis>glibc-locales is there
<rekado>is GUIX_LOCPATH set?
<JeanLouis>aha I have restarted computer, did not run manually guix-daemon, let me see, maybe it is it
<rekado>it should be set to ~/.guix-profile/lib/locale
<JeanLouis>my ~/.profile was not read at all
<JeanLouis>hmm I have to change something...
***nckx is now known as nckx|offline
<davexunit>man, even with, things are still quite slow.
<davexunit>I did a 'guix package -i emacs' on a fresh Guix install on a coworkers machine and it's sloooooowly checking for substitutes
<JeanLouis>davexunit: on my side too, very slowly, like 20 minutes
<rekado>davexunit: re NO_LAPACK=1: we do this because ... I forgot. I think I just wanted to make sure we're using the existing lapack package.
<rekado>I don't know if it's needed at all. We *could* remove it if it causes any problems.
<davexunit>rekado: I needed to remove that flag because Kaldi, a speech recognition engine, wouldn't build without it.
<bavier>davexunit: what was the issue without the flag?
<davexunit>bavier: couldn't find lapacke.h
<davexunit>I added our lapack package as an input but it didn't help because it doesn't have this header file.
<bavier>interesting, I wonder if we should enable that feature in our lapack
<bavier>I'd rather do that than have openblas build in lapack support
<davexunit>I wish openblas was substitutable
<davexunit>it's rather low in my dependency graph
<rekado>isn't it substitutable?
<rekado>ATLAS is not, but openblas should be.
<davexunit>oh maybe I read the code wrong
<rekado>(that was the point of switching from ATLAS to openblas in numpy)
<davexunit>ah, it's substitutable on x86_64, i686, and mips
<davexunit>I somehow read the code to mean that it *wasn't* substitutable on those platforms. my bad.
<bavier>davexunit: I'd add a -DLAPACKE:BOOL=YES to the lapack configure-flags instead of modifying openblas
<bavier>I just checked, and it builds and installs lapacke headers and libs
<davexunit>bavier: thank you!
<davexunit>bavier: should we commit such a change?
<bavier>davexunit: I think we could. the lapack size goes up from 6.4 to 9.4 MiB
<davexunit>bavier: okay.
<davexunit>I might send a patch for that later
<davexunit>has anyone run into a situation where a package build produces what guix calls "bogus runpaths"?
<davexunit>also, relevant XKCD about packaging
<phant0mas>davexunit: me when I tried to do guix system init from my arch linux system running guix to another hard drive
<davexunit>phant0mas: hehe ;)
<wingo>does "ping foo.local" work for yall? at some point for me it stopped working on my guixsd machien
<davexunit>phant0mas: I await your mailing list about avr-gcc ;)
<davexunit>mailing list post*
<phant0mas>davexunit: I was hoping I could first fix rekado 's toolchain and then use the same for avr gcc
<phant0mas>but I got too busy with work here..
<phant0mas>davexunit: I will send my ideas today :-)
<davexunit>phant0mas: cool. I am interested in hearing them. :)
<davexunit>I could potentially do the work myself if only I knew what was in your head.
<phant0mas>hehe :-)
<rekado>bleh, ant-build-system gives me a headache.
<rekado>junit now seems to be non-deterministic whereas yesterday it was just fine.
<rekado>maybe my computer is just messing with me. I'd probably do the same to my user on a Friday.
<civodul>wingo: it does for me
<civodul>(generation from March 1st)
<civodul>on browser fingerprinting:
<rain1>there seriously needs to be a new design for web/browser that uses what's been learned
<rekado>yesterday I was thinking about starting a movement to turn a browser into a regular user-controlled application platform.
<rekado>only scripts from ~/.js would be executed
<rekado>users would install JavaScript applications like any other application
<rekado>e.g. with Guix
<rekado>~/.guix-profile/lib/js/ would contain scripts to be run for
<rekado>this probably won't work in real life because web developers usually iterate too quickly and often don't release their unminified sources.
<rekado>I want JavaScript applications to behave just like regular applications.
<rekado>it's so weird that we let other people determine what code is run on our machines.
<rain1>I know it's really terrible
<rain1>the system need to be designed
<rain1>same guy that did the browser fingerprinting, that's an interesting leak
<rain1>maybe guix is safe because it's in Jan 1 1970
<civodul>rekado: the "iterate too quickly and don't release" point may be a showstopper :-/
<rekado>civodul: maybe we should start to treat these web developers like developers of non-free software.
<rain1>what I think needs to be done is a new design created with privacy and users rights in mind
<rain1>then people can choose to use it if they want
<civodul>rekado: yes, that's exactly what LibreJS is doing
<civodul>there's something fundamentally wrong with running random code coming from elsewhere
<rekado>I don't really like the approach librejs takes, though.
<mark_weaver>I use NoScript
<rekado>I'd rather move the installation of javascript applications to the operating system than trust websites to deliver license-tagged scripts.
<mark_weaver>rekado: I agree that is the direction we should be pushing for. I'm not sure how feasible it is, though.
<Jookia>rekado: That's probably a better solution, especially for sites like reddit which ship nonfree code mixed with free code from their repo
<rain1>I agree with splitting 'websites' into two parts: interface and API
<mark_weaver>we would need web sites to cooperate with this vision
<rain1>I don't think javascript should be continued though
<rekado>civodul: the timestamp code from (guix build install) isn't working for me. It results in a couple of files in the jar that are not reset properly.
<mark_weaver>and I don't see that happening unless large numbers of people insist on it
<rekado>civodul: is it bad if I continue to use the existing (ftw ...) code?
<Jookia>mark_weaver: Fortunately I think the number of websites that do would be larger than the websites that don't, especially if we ship Guix packages for JS that builds from website source code
<rekado>ACTION has to go now
<Jookia>larger than don't do LibreJS support*
<Jookia>larger than do*
<rain1>a new thing called webassembly is coming soon
<civodul>rekado: re ftw, this is weird; could you check which files aren't reset?
<rain1>it's a bytecode language instead of scripts
<rekado>civodul: looks like directories are not reset
<civodul>rekado: oh right, it needs (find-files directory #:directories? #t)
<civodul>could you do that, and fix (gnu build install) while at it?
<civodul>and a poney plz? ;-)
<mark_weaver>civodul: I was thinking: maybe instead of having grafts cause things to be built early, maybe instead we should support the idea of doing builds in multiple *stages*, where earlier stages are fully built before the derivations of the next stage are built.
<NiAsterisk>ACTION missed just 1 hour talk, but gnunet.scm patch is incoming :) can't reply afterwards, I'll do that tomorrow/some time today
<mark_weaver>so, grafts would be one case of this, where the ungrafted packages are built in the first stage, and the grafts are done in a second stage.
<mark_weaver>but there's another case where this could be useful: profile generation.
<mark_weaver>at present, we have to resort to terrible heuristics to decide which profile hooks to run, e.g. checking for package names starting with 'ghc'
<NiAsterisk>I'm happy to move again because sitting 1 hour alone makes people look weird at you :D
<civodul>mark_weaver: yeah, agreed
<mark_weaver>but if we did profile generation after the contents of the profile are built, then we could make decisions based on the files in the build outputs.
<civodul>mark_weaver: i like the idea of stages, but it seems like a fairly fundamental change
<civodul>i was thinking maybe we should have a way for the daemon to make "upcalls" to clients, asking for what's next
<civodul>instead of ugly things like exportReferenceGraphs
<civodul>and profile generation and grafts
<civodul>but yeah, pretty big change design-wise
<civodul>another option would have to have built-in support for grafts in the daemon
<civodul>though it's not as elegant
<mark_weaver>I might be missing something, but it seems to me that multiple stages wouldn't require any changes to the daemon. the client could just wait until a stage is fully built before generating the derivations for the next stage and building it. no?
<NiAsterisk>patch send, I'll be away again. have a great weekend!
<civodul>mark_weaver: yes, but in a way that's pretty much what 'graft-derivation' does when substitute info is missing?
<paroneayea>ACTION sees wip_faster_grafting appear when he does a git pull and says "oooh"
<mark_weaver>well, not quite, because instead of the entire first stage being planned and the builds/downloads announced ahead of time, the builds are happening during each call to 'graft-derivation', right?
<mark_weaver>I think it would be nicer if the actual downloads and builds were announced ahead of time, and the later stages were local builds and relatively fast (grafts and profile generation)
<mark_weaver>and at present, grafts and profile-building are the one things I would envision for later stages.
<civodul>are you suggesting that grafting should announce what it's going to do?
<mark_weaver>for now, the second stage would always be grafting, and the third stage would be profile generation.
<civodul>so in effect, you would see "The following things will be built" twice?
<mark_weaver>I guess that was my assumption, but it might not even be needed.
<mark_weaver>with my new code, grafting is quite fast
<mark_weaver>at least for everything that's not texlive-texmf :)
<civodul>heh :-)_
<mark_weaver>I guess the third stage (profile generation) might sometimes involve builds, to build the things needed for profile hooks.
<paroneayea>living the tex life!
<mark_weaver>the patch in wip-faster-grafting works correctly as far as I can tell. I've rebuilt everything on my own system with it, and everything seems to work. but I want to make the code more clear and commented.
<mark_weaver>and maybe switch from a hash table to vhash
<civodul>sounds good!
<civodul>i haven't looked at it yet but i trust your judgement
<civodul>BTW, i've just emailed bug-guix with details on another graft-related optimization to work on
<civodul>though i don't think i can work on it this week-end
<JeanLouis>are NAR packages binaries?
<bavier>JeanLouis: yes
<JeanLouis>maybe it starts working for first time.. I was compiling last days... no binaries ever
<davexunit>it's not just going to magically work
<davexunit>I really think you have misconfigured your system
<JeanLouis>I did all by
<JeanLouis>some links missing in documentation though
<JeanLouis>then if anything is wrong, it is wrong in documentation, I am testing it simply, not that I am able to quickly move to Guix.
<JeanLouis>I have /home encrypted, /tmp is encrypted, swap is encrypted, so I am not sure how to do that on Guix
<JeanLouis>I do it again, now I got bash,mutt from hydra, not bad.
<mark_weaver>davexunit: it might have been that 'guix pull' was using some old binaries no longer on hydra to compile guix
<JeanLouis>to which user/group your /dev/pts/1 or 2 belongs? (just say "user" if not system user)
<mark_weaver>those are dynamically allocated pseudo-ttys
<JeanLouis>user : user? in group of user?
<mark_weaver>user : tty
<JeanLouis>aha thank you
<mark_weaver>ACTION goes afk
<JeanLouis>I have glibc-locales, and still get error cannot set locales
<Jookia>JeanLouis: Do you have GUIX_LOCPATH set?
<JeanLouis>yes like ~/.guix-profile/lib/locale/
<JeanLouis>I did binary install on Debian, new, I did download from hydra, only bash,mutt and glibc-locales
<JeanLouis>maybe to restart X?
<JeanLouis>bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
<JeanLouis>maybe I get this because I run it in xfce4-terminal of Debian, and not guix
<Jookia>JeanLouis: if you're on debian your locale may be different to what guix wants
<JeanLouis>I was thinking I use guix locales
<NiAsterisk>what's the new command for services again?
<NiAsterisk>deco seems to be gone and i had too much input to remember this right now
<davexunit>NiAsterisk: herd
<NiAsterisk>oohh. too obvious
<NiAsterisk>thanks :)
<NiAsterisk>avahi is no service? is it avahi-daemon?
<JeanLouis>cannot get emacs package - i emacs, fail in make[1]: Leaving directory '/tmp-guix/nix-build-glib-2.46.1.drv-0/glib-2.46.1'
<Jookia>whats the full log
<JeanLouis>Testsuite summary for glib 2.46.1
<JeanLouis># ERROR: 2
<JeanLouis>where do I find log, if it says: See gio/tests/test-suite.log
<Jookia>did you run with --keep-failed
<Jookia>Also why are you building emacs/glib
<JeanLouis>I am not, I just did: -i emacs I guess
<JeanLouis>not that I decide to build it, I prefer to donwload it, but it does not
<JeanLouis>aha keep failed, I will do that
<Jookia>did you run 'guix pull' and add the ACL keys to your guix
<JeanLouis>guix pull is to upgrad guix, I used newest anyway. And ACL keys I did add, and it worked for few packages.
<JeanLouis>I have /etc/guix/acl
<JeanLouis>It seems everyone is getting binaries, but me.
<JeanLouis>you are on guix SD and I am on Debian, maybe that is why
<mark_weaver>many people use Debian on GuixSD
<mark_weaver>JeanLouis: architecture?
<mark_weaver>sorry, what architecture are you running this on?
<suitsmeveryfine>mark_weaver: I just want to say that I managed to install by just rerunning `guix system init`. Before I didn't know that the succeeded package downloads would be preserved.
<JeanLouis>I have run now -i emacs --keep-failed, and I see cmake being compiled...
<paroneayea>mark_weaver: do you mean guix on debian?
<mark_weaver>paroneayea: right :)
<mark_weaver>ACTION just woke up from a nap, and not quite all here yet :)
<Jookia>Has there been talk on packaging git-annex?
<bavier>Jookia: yes, I attempted it a while back
<Jookia>what'd you hit?
<bavier>Jookia: I got all the required dependencies packaged, but ultimately git-annex itself wouldn't build
<bavier>with other things going on, I didn't take the time to delve further into the build failure
<Jookia>ah ok
<bavier>and it's been so long now, I feel I'd need to write a hackage/stackage updater to update all my outdated local packages
<cehteh>joeyh_ is here in the channel. shake him awake :D
<bavier>cehteh: :)
<a_e>paroneayea et al: Reading up on the channel logs. If the size of texlive is a problem, you should give texlive-minimal a chance.
<a_e>This is stripped off documentation and most fonts, everything not cm related.
<a_e>I would also like to replace the texlive references in native-inputs by texlive-minimal wherever possible. If someone wants to help, they are welcome!
<paroneayea>a_e: I might help next time I bump into this :)
<JeanLouis>I wish there is VPS with Guix on DigitalOcean
<bavier>JeanLouis: I think someone here was working with ServerRaptor to get a GuixSD offering
<paroneayea>bavier: might be nice to post the deps of git-annex even if git-annex itself isn't ready
<JeanLouis>oh really very nice
<bavier>paroneayea: yes. I've pushed a few, but still many to go.
<paroneayea>bavier: cool :)
<JeanLouis> asking DigitalOcean
<JeanLouis>If 10 people ask -- it will be better
<JeanLouis>I know Norwegian company to implement it
<JeanLouis>someone has mutt + gnupg working?
<a_e>JeanLouis: Yes. But not gnupg@2.1, either gnupg@1 or gnupg@2.0.
<a_e>There are a number of commands to add to .muttrc. I copied something from the internet.
<JeanLouis>gpg (GnuPG) 2.1.9 --- so why it does not...
<JeanLouis>yes I have them, suddenly in guix: mutt+gnupg -- not working, not inside. But works in general
<a_e>Try to go back to a previous gnupg, depending on whether your .muttrc lines call gpg or gpg2.
<a_e>guix package -r gnupg -i gnupg@2.0
<a_e>for instance.
<JeanLouis>that sounds not feasible on my side, I rather change muttrc
<JeanLouis>but connection failed
<JeanLouis>substitute: guix substitute: warning: while fetching server is somewhat slow
<JeanLouis>substitute: guix substitute: warning: try `--no-substitutes' if the problem persists
<JeanLouis>I guess that is WHY I get compiling all the time
<a_e>I repeat, I did not succeed in using gnupg@2.1. You can still try, but you will void your warranty ;-)
<JeanLouis>will try to follow info
<paroneayea>a_e: luckily gpg comes with now warranties ;)
<a_e>The same old trick everywhere!
<a_e>I just wanted to warn JeanLouis that if he follows a path that does not work for others, he will be on his own.
<paroneayea>a_e: I know :)
<paroneayea>and I wasn't being helpful
<paroneayea>but I couldn't resist
<a_e>But this is exactly what I was saying - we cannot be helpful then! :-)
<JeanLouis>a_e: yes sure, but if I get it working, it will be for others
<a_e>JeanLouis: Sure, feel free to try and tell us how it works, if it works.
<JeanLouis>a_e: it does work, sure, I just need to change some settings for mutt
<JeanLouis>sadly, glib-2.46.1.drv' failed with exit code 1 -- even with --keep-failed
<JeanLouis>so no emacs so far
<mik__> I just tried to install guixsd, specifying my root fs by uuid
<mik__>at boot, guile seems to wait for a disk with that id, but boto fails when it doesn't show up
<mik__>I'm wondering what my grub.cfg should look like; is it simply supposed to be linux */gnu/store/bzimage* --root=*the-uuid*?
<suitsmeveryfine>mik__: Did you install with encrypted / and unencrypted /boot?
<mik__>I didn't specify any options for encrypted/unencrypted
<suitsmeveryfine>OK. You could specify your root file system with /dev/...
<mik__>ah, that seems simpler
<mik__>just --root=/dev/sda1
<bavier>mik__: did you use (title 'uuid) in the filesystem config?
<suitsmeveryfine>mik__: no I did not. Just look at the template for desktop
<suitsmeveryfine>and modify it according to your need
<suitsmeveryfine>that should be specified in the OS definition
<mik__>I did use (title 'uuid), then (device "*the uuid*")
<suitsmeveryfine>I've never used UUIDs in the OS definition
<bavier>mik__: I don't use a uuid myself, but the manual mentions the use of the "uuid form", as in (device (uuid "4da..."))
<suitsmeveryfine>I see. Well, the desktop.scm template does not use it
<mik__>bavier: gah, you're right! I hate reading documentation on my phone; bet that's my issue
<mik__>bavier: thank you
<mik__>I'll try with that added
<bavier>great, hope that helps
<JeanLouis>a_e: just sent signed email with mutt + gnupg
<JeanLouis>but what is "legacy key2
<suitsmeveryfine>Ooops, I just entered "export PATH="/home/suitsmeveryfine/.guix-profile/bin:/home/suitsmeveryfine/.guix-profile/sbin"
<suitsmeveryfine>and now sudo stopped working
<suitsmeveryfine>The above command was suggested after having installed powertop.
<Mik__>So using (device (uuid "uuid")) results in an error
<bavier>Mik__: ouch, could you paste the error?
<paroneayea> would be fun to have in guix
<Jookia>paroneayea: I've just started my packaging rampage for the noto fonts
<pizzaiolo>^ woo
<Jookia>turns out google doesn't version their fonts properly
<Jookia>thanks google