<Acou_Bass>apparently i wasnt auto-logging in here, now i feel sad :( <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" <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 :) <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>After completing the install I edited grub.cfg as suggested by inserting these two lines at the very top: <Jookia>is this with or without my patches, and is this encrypted /boot <Jookia>suitsmeveryfine: reconfiguring will overwrite your grub.cfg <Jookia>is there a /boot/grub/i386-coreboot/ file <Jookia>there probably isn't, it should be i386-pc ***nckx|offline is now known as nckx
<Jookia>you have to edit the boot/grub/grub.cfg in your mnt stuff <Jookia>and is there a /boot/grub/i386-coreboot/luks.mod file <Jookia>hmm, i wonder why its looking for -coreboot then <suitsmeveryfine>I will try to reinstall libreboot: the only problem is that the keyboard usually don't work afterwards <Jookia>That's not good. Have you tried #libreboot for that? <Jookia>a friend of mine is also getting i386-coreboot issues <suitsmeveryfine>I even have a working screen in GNU/Linux and working GuixSD in GNU screen <pizzaiolo1>(20:54:18) Jookia: a friend of mine is also getting i386-coreboot issues <Jookia>i think this is because libreboot isn't loading the GRUB <Jookia>and using its own grub in the flash <Jookia>so my patches would fix this ;-) <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 <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 <Jookia>I'll just load up a live USB of Debian and rebuild it <Jookia>I wonder if this would fix my T400 screen issue <Jookia>You still have the screen issue with latest Libreboot? <suitsmeveryfine>I believe that an earlier install worked but that I didn't have any screen then <rain1>Are you using UUIDs in the config file? <rain1>nice! I'd like to learn that, can I see the file? <rain1>I'll try setting all that up in qemu <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 <rain1>you could get curl and use ix.io to avoid browser! <rain1>cat /etc/config.scm | curl -F 'f:1=<-' ix.io <rain1>should print a short url that has the file in it <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 <Jookia>define 'compatible', having to re-edit grub.cfg every time isn't good <Jookia>it's okay, you can just edit your guix to re-add it <rain1>im sorry thats a shame about curl <rain1>i just thought it would be easier/faster than getting a browser <Jookia>suitsmeveryfine: For other people we'd have to find a way to automate it, aka using UUIDs <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! <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. <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. <nckx>Jookia: the... target to make? <Jookia>usually you use a build system like autotools but you could write your own command to run things <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. <Jookia>suitsmeveryfine: did you run guix pull? <Jookia>maybe curl isn't built upstream yet <nckx>Jookia: because dynamic libraries are dead #docker #go /s <nckx>(Because I'm mucking about with btrfs for the initrd :-) <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 <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 <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>the funny thing is I never created it or used the site <rain1>they make shadow accounts about everyone <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. <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 <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 <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 <Acou_Bass>'you checked into xx restaurant... two weeks before creation of your account!!' <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>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>hmm I changed from zsh to bash, maybe I need some GUIX_LOCPATH <janneke>JeanLouis: do you have glibc-locales installed? <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>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 ***nckx is now known as nckx|offline
<davexunit>man, even with mirror.guixsd.org, 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>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 <rekado>ATLAS is not, but openblas should be. <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 <bavier>davexunit: I think we could. the lapack size goes up from 6.4 to 9.4 MiB <davexunit>has anyone run into a situation where a package build produces what guix calls "bogus runpaths"? <phant0mas>davexunit: me when I tried to do guix system init from my arch linux system running guix to another hard drive <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 ;) <phant0mas>davexunit: I was hoping I could first fix rekado 's toolchain and then use the same for avr gcc <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. <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. <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>~/.guix-profile/lib/js/gnu.org would contain scripts to be run for gnu.org <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>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. <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 <Jookia>larger than don't do LibreJS support* <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? <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 <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>but yeah, pretty big change design-wise <civodul>another option would have to have built-in support for grafts in the daemon <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>I guess the third stage (profile generation) might sometimes involve builds, to build the things needed for profile hooks. <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. <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>maybe it starts working for first time.. I was compiling last days... no binaries ever <davexunit>I really think you have misconfigured your system <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) <JeanLouis>I have glibc-locales, and still get error cannot set locales <Jookia>JeanLouis: Do you have GUIX_LOCPATH set? <JeanLouis>I did binary install on Debian, new, I did download from hydra, only bash,mutt and glibc-locales <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 <NiAsterisk>deco seems to be gone and i had too much input to remember this right now <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' <JeanLouis>where do I find log, if it says: See gio/tests/test-suite.log <Jookia>Also why are you building emacs/glib <JeanLouis>not that I decide to build it, I prefer to donwload it, but it does not <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>It seems everyone is getting binaries, but me. <JeanLouis>you are on guix SD and I am on Debian, maybe that is why <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... <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 <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 <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 <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! <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 <bavier>paroneayea: yes. I've pushed a few, but still many to go. <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>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 <JeanLouis>that sounds not feasible on my side, I rather change muttrc <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 ;-) <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. <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 <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*? <mik__>I didn't specify any options for encrypted/unencrypted <bavier>mik__: did you use (title 'uuid) in the filesystem config? <mik__>I did use (title 'uuid), then (device "*the uuid*") <bavier>mik__: I don't use a uuid myself, but the manual mentions the use of the "uuid form", as in (device (uuid "4da...")) <mik__>bavier: gah, you're right! I hate reading documentation on my phone; bet that's my issue <JeanLouis>a_e: just sent signed email with mutt + gnupg <suitsmeveryfine>Ooops, I just entered "export PATH="/home/suitsmeveryfine/.guix-profile/bin:/home/suitsmeveryfine/.guix-profile/sbin" <Mik__>So using (device (uuid "uuid")) results in an error <bavier>Mik__: ouch, could you paste the error? <Jookia>paroneayea: I've just started my packaging rampage for the noto fonts <Jookia>turns out google doesn't version their fonts properly 