<pkill9>is the x86_64 version of jack supposed to have it's library fiels in lib64? ***mbowcutt_ is now known as mbowcutt
<reepca>Hmm, I've got a package that likes to install machine-specific stuff under an architecture-specific directory (for example, it ends up in ~/.guix-profile/share/PACKAGE_NAME/site/amd64). I'm trying to tell guix about the location so that it can set an environment variable accordingly, but that would require knowing at package-definition-time which architecture it's going to be built for, and I don't see any way to do that. Any ideas? <efraim>reepca: first thought that comes to mind is the enlightenment service and setuid binaries, I had one of those <efraim>do we have a default set of ld flags set somewhere? <reepca>hmm, what's the "site" directory usually for anyway? I get the impression it's for stuff shared between different versions of the same software, but any web search involving "site directory" gets derailed pretty fast. <rekado>so… we were aiming for the release of 0.15.0 on June 30. Are there any blockers left at this point? <rekado>civodul: should we wait for the release of Guile 2.2.4? <reepca>How could I modify a build-system (cmake in particular) so that it uses a newer version of gcc? So far the best way I can see is to wrap the LOWER procedure with one that does the replacement - is there an easier way of doing this I'm missing? <civodul>i'll send an update to the list as well <civodul>we should test the ISO installation image, things like that <rekado>reepca: do you want the modification to apply to all packages using the cmake-build-system? <reepca>rekado: alas, no, just this one that insists on C++17 support <rekado>reepca: then adding the version of GCC that you need to the native-inputs should be enough, I think. <g_bor>rekado,civodul: sahithi contacted me, I left a message on ##guix for you. <g_bor>Finally I'm quite near to get icedtea fixed on gcc5. The I will check if it solves the libsnappy linking problem. <reepca>okay, I was worried for a moment there that the build system would do something special with the gcc it supplies itself <g_bor>Guix is a real learning opportunity :) go, then texinfo, then gcc internals, hg... Never done those before... <g_bor[m]>civodul: sent the message again to ##guix. <efraim>do we have a default set of ld flags set somewhere? <g_bor[m]>efraim: I don't know, but if we do, I suspect that's in gnu-build-system... <ng0>hm, has anyone ever encountered this: <ng0>In procedure scm_lreadr: /gnu/store/2i56lk5ks40gm62w1dpjmqqbn1yh1lch-boot-builder:1:1348: Unknown # object: #\\< <ng0>where the end of the file reads: <ng0>(primitive-load "/gnu/store/lplnjghsfrb1wf6z7296s0fb1493jdgd-activate") #<procedure 3c467e0 at gnu/services/shepherd.scm:70:4 (state)>)))))) <civodul>ng0: looks like a misuse of a monadic procedure or something <ng0>guix pull'ing on both ends now to sync up <ng0>I think boith systems are now on 6e65eb3cad1d1148eade9ed2228cdea90d531a94 <ng0>I really need this dedicated server -.- the VM is computing slower than my laptop. <ng0>civodul: I'm deleting the store item right now, but other than that: is the error in guix or on my side? <ng0>I think without grafts it worked <ng0>ah.. someone mentioned a while back that very big stores can start showing problems? <mbakke>I don't get why meson builds fails for armhf on staging; by changing line 155 of (guix build-system meson) to read x86_64 instead of arm, the 'fix-runpath' phase never runs. What am I missing? <civodul>ng0: there was a change recently in this area (commit 378daa8cb677121e1893f9173af1db060720d6e4), but i think here you might be mixing code from previous and after this change <ng0>156.6GiB, 20765737 items.. does that count as "big"? <ng0>what would you suggest I could try? I'm in my lunchbreak :) <civodul>mbakke: do you have a link to a log? <reepca>for some reason gcc-7 is trying and failing to find a stdlib.h. It tries including it with #include_next from include/c++/cstdlib, so it can't see it in its own include/c++/stdlib.h, but I'm really puzzled why it isn't finding glibc's stdlib.h which is also in CPLUS_INCLUDE_PATH (listed after it). According to the cpp info page, it should start searching "starting with the directory in the search path after the one where the current <rekado>reepca: does sounds vaguely familiar <rekado>was this not changed in GCC 6 and thus requires a shift from C_INCLUDE_PATH to CPATH and similar for C++? <ng0>civodul: I guess I could pull from one commit before 378daa8cb677121e1893f9173af1db060720d6e4 and then pull again <reepca>rekado: CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH are all set to the same values according to the set-paths phase's report <reepca>I wonder if the build process is overriding any of those variables. It'd be a *really* bad idea, but it's one of the few possible explanations I can think of <roelj>Does anyone have a recursive importer for pypi? <mbakke>The things is, that phase is not supposed to run on armhf. <rekado>roelj: I don’t think so, but the recursion mechanism has recently been moved to guix/import/utils.scm <mbakke>reepca: Try to unset C_INCLUDE_PATH and CPLUS_INCLUDE_PATH. <rekado>roelj: so I think it won’t be difficult to make it work for pypi. <rekado>roelj: it is currently shared by the cran and elpa importers. <rekado>(since the change I only used it once and found some unusual behaviour when importing CRAN things, so this might deserve a second look) <reepca>mbakke: feels weird to write (add-after 'set-paths 'unset-paths ...), but I'll try it <reepca>I think I sort of understand. Silly stackoverflow people not being pedantic enough with their explanations... #include_next isn't "include the file with this name that isn't in this directory", it's "starting from right after here in the search path (which is formed from multiple variables, among other things), include the next file with this name" <mbakke>civodul: Ooh, I see; there is a system variable already. <mbakke>Unfortunately fixing that will rebuild meson on all architectures...again :/ <civodul>mbakke: do you want to push the fix? <ng0>oh, dvn got the nim compiler to work yesterday, there'll be a patch today or some time soon :) and more patches whic haddress the other changes we made together <civodul>mbakke: well, everything was built with "x86_64-linux" hardcoded in there, because hydra/berlin is on x86_64 <mbakke>civodul: Woah, you're right (of course)! :-) <civodul>but if you did a native build on i686, you were getting a different derivation because you wer getting "i686-linux" in there <civodul>so, people on x86_64-linux won't see any difference <civodul>people on i686-linux etc. won't have to rebuild, but this time they'll be able to get substitutes <ng0>civodul: a while back you mentione dthat there were/could be problems with using g-exps in package definitions..I think it was at a talk? Do you remember what kind of problems you see and maybe how we could proceed to work on them, if it's a good idea at all? <rekado>ng0: things like inheriting from other package definitions becomes more difficult. <rekado>currently, we can use “(assoc-ref inputs "foo")” to refer to the package labelled “foo”, independent of what it really is. <rekado>for example, this really could be a Python 2 variant in one package and a Python 3 variant in another. <mbakke>civodul: #31971 indeed. I've pushed the fix. Will start a new evaluation shortly. <ng0>is there still a problem with pulling or anything self-build related on machines with 32GB+ ? <rekado>ng0: I haven’t tried it recently. <rekado>ng0: I suppose the bigger problem was the number of cores; <rekado>this should be fixed with Guile 2.2.4. <ng0>a bit offtopic.. I'm starting to miss a feature from Thunderbird when using neomutt/mutt: encrypt messages send to one group with the keys of a group of defined gpg pubkeys.. has anyone done this in mutt/neomutt or Gnus before? <ng0>so foo@bar.tld would actually encrypt to (1@bar.tld, 2@bar.tld,...) <rekado>is foo@bar.tld a local alias or is it something like a mailing list? <ng0>like an existing mailinglist <ng0>I supposed Gnus could be programmed to do this. neomutt feels trickier or I haven't read every config option <efraim>mbakke: i'm testing json-glib for armhf-linux on staging now <reepca>I don't suppose there's a magic solution for "the headers are in include/packagename/ instead of just in include/ where the developers assumed they were" also now (build process isn't using pkg-config for some reason...)? <ng0>monkey patching isn't enough? to just substitute it <efraim>mbakke: it works for me, building on aarch64 for armhf <rekado>ng0: mml-sec.el provides support for encrypting messages and it seems to be flexible enough for your usecase. <rekado>ng0: unfortunately, the documentation does not say anything about this, though you may find something useful by reading the code of mml-sec.el. <ng0>thanks :) now I only need to reduce the number of mails in inboxes, since last time I used Gnus it did not cope very well with my amount of mail <mbakke>efraim: Excellent, thanks for testing :-) <mbakke>Does patchelf actually work on aarch64? <ng0>civodul: I think after a long time waiting for compilations I'm getting over the commit now :) <rekado>ng0: you don’t need to use Gnus to use mml-sec / message mode. mu4e also reuses these existing features. <ng0>So far I liked Gnus better, but I did not give mu4e much time <g_bor[m]>I'm quite sure that I fixed the gcc5 problem on icedtea, but I'm still running checks. <efraim>ng0: it might work with mutt and groups/aliases being a group of emails <efraim>mbakke: it hasn't failed for me in the past, so I assume its working <ng0>efraim: okay, I could look into aliases again. thanks :) <nckx>I get a host of Unbound variable errors after importing kde-frameworks in graphics.scm. I guess that's what a circular dependency looks like? What's the idiomatic way to solve or work around those? <efraim>mbakke: yeah, json-glib builds fine on aarch64 <g_bor[m]>Can we do something like apply this commit, then build these derivation (i.e. not all reverse dependencies) in cuirass? It would be quite nice to have this. <nckx>mbakke: Thanks! I'll stare at that for a while. (I don't quite get the sudden appearance of abiword.scm in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31392#8. Is that just because it was lexically {almost,then} the first module? It does often show up in backtraces and does in this one; I've always assumed for that reason.) <nckx>Guile says no ,bt for me: GC Warning: Failed to expand heap by 8388608 bytes | Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS | Aborted <nckx>ACTION puts on their rabbit ears and goes spelunkin' <rekado>I don’t know when this started, but java-cisd-jhdf5 no longer builds. <rekado>g_bor[m]: do you know about this? <rekado>huh, java-jmock only installed its license file. <rekado>guess it failed to build, but since we ignore #f return values this wasn’t caught. <rekado>maybe related to the java-asm changes <rekado>yes, lots of ignored errors there. <civodul>perhaps we can use invoke in ant-build-system on master? <rekado>looks like java-hamcrest-all also has a problem. <rekado>not all jars are actually installed. <rekado>this is weird because when I build this locally they do exist. <rekado>it’s also strange that the java packages stopped being reproducible <xrs>Hey guys :) I'm just installing my first guixsd. I need a little help. I know that my wifi card is not supported by free software drivers. Is it possible to install the binary blob without the guix packet manager? <rekado>oh, I suppose it’s just jmock, which has a file “signed.jar” <rekado>I don’t understand why java-hamcrest-all differs when built locally vs built on the build farm. <rekado>the local build includes hamcrest-all.jar, hamcrest-integration.jar, and hamcrest-library.jar. <rekado>xrs: hi, we cannot help you with installing software without Guix. <rekado>so, on hydra the build actually failed. <xrs>rekado, ok, nevermind :) <rekado>on hydra, the build failure is due to a race condition in the build system. (I believe we have a bug report open for that.) <rekado>a workaround is to build with only a single core, which cannot be conveniently specified in the ant-build-system at the moment. <alpgeek>I'm trying to boot an installed (on hardware) guixsd install but it's failing in many ways. Firstly the install cd didn't even have the capability to run guix system so I had to copy-paste libsqlite3.scm from the guix package install location to where guix expected it. <alpgeek>This allowed guix system init and grub shows up fine and everything. However, it failed to find the partitions so I had to manually point it to the grub hd and manually fix the search paths (they weren't rooted correctly based on the partitioning scheme) <alpgeek>"you must load the kernel" otherwise <alpgeek>Then it didn't find any video mode so I had to insmod a bunch of things in the grub boot entry. <alpgeek>Now I'm stuck at a kernel panic during boot that's not giving anything very meaningful (to me): <alpgeek>Call Trace top is <IRQ> kick_ilb+0x72/0xa0 trigger_load_balance+0xa2/0x1b0 ? tick_sched_do_timer+0x60/0x60 schedular_tick+0xae/0xd0 update_process_times+0x47/0x60 (top to bottom) <alpgeek>Couldn't find any info on that kernel panic and the previous errors I seem to be the first one to fix... <alpgeek>Can I get any meaningful information out of this and is it possible to either upgrade or downgrade the kernel to hopefully fix that? <xrs>alpgeek: I'm having the same problem with the grub not finding the right partition. <alpgeek>xrs: due to the kernel panic I'm putting solving that on hold, but I replaced the search line by 'set root=<partition' and then pointed everything to the right btrfs subvolume explicitly instead of relying on the defined mount points. <xrs>I followed the manual, but in my case it seems that something is wrong with the luks configuration. I'm using ext4. <g_bor>I'm also waiting for the ant-build-system fix to get merged to master. It makes finding these problems really hard. <g_bor>I intend to rebase the java8 branch on master, once the ant-build-system fix is merged. I guess that then in a few days we can get it rolled out. <g_bor>something is not right... I just pushed to master, but cannot fetch it... <roptat>g_bor: I can see 1cdff8cdb7b4822bd16fe713bc0b138a01a546aa "Work around gcc segfault" <sirmacik>weird thing remained, I was asked for partition password twice, once by grub and than by system <xrs>I got it booting too, the error was a wrong keylayout for entering my luks password <xrs>sirmacik: same for me :) <sirmacik>is it normal for system to ask for password despite grub decryption? <efraim>I've been told entering your password twice is normal <sirmacik>one thing i like about obsd, encryption is handled by softraid so no external boot partition is needed an you enter your password only once <sirmacik>but entering your password twice isn't so bad <xrs>how can I configure the keylayout? (loadkeys in config.scm?) <sirmacik>yup, than it can quickly become really annoying <xrs>the locale is configured <roptat>xrs: we don't have a way to change the layout for grub, but there's a service for changing the layout in the linux console <roptat>for instance, I use (console-keymap-service "fr-bepo") in the services field of the os declaration <roptat>but then, the grub password must be entered in qwerty, while the linux password is in another layout <xrs>robtat: ok, thanks. I guess, I'll change my passphrase then ;) <roptat>what I was suggested to do is to add another password that is the same, but for qwerty layout <roptat>(not sure if that's understandable) <xrs>but I had look to think of that. Maybe other people will get frustrateted, entering their password in grub with the wrong keylayout <roptat>there must be a way to change grub's layout too, but we don't implement it yet <ng0>civodul: change to gexps is causing a lock to a commit before that commit which introduced it here <ng0>I can reconfigure with --commit=378daa8cb677121e1893f9173af1db060720d6e4 but that's it <mbakke>LUKS has several key "slots", so you can add a secondary passphrase written in US layout. <brendyn>I always have to type my password into slim with the wrong layout, it's rather annoying. <civodul>ng0: could you reproduce the issue on master, run "make clean-go && make" before doing it, and report all the details to bug-guix@gnu.org? <civodul>ng0: or you can reproduce with a guix pull'd copy of master and an empty GUIX_PACKAGE_PATH <ng0>this is not from a git checkout <ng0>hm.. empty guix_package_path will be a problem <ng0>I can try and empty the dependencioes on custom packages <civodul>ng0: i mean, give us a way to reproduce the issue with just Guix <nckx>roptat: Yeah, there is. You compile X keymaps (with ‘grub-mklayout’) into something Grub can load (with ‘keymap’). <ng0>problem will be the kernel.. but I can build a vm <nckx>civodul: Yeah, I'm looking into it now. <roptat>nckx: I think I remember testing it, but grub-mklayout depends on a tool we didn't package <nckx>roptat: Do you remember which tool? <roptat>but basically grub-mklayout is a script that calls this tool <roptat>it seems I don't have grub-mklayout on this computer though <nckx>Oh. Guess I can ^C the ‘find’ on my spinning drive then :-) <roptat>oh, actually I just "guix build grub" and it contains a grub-mklayout that's an executable, not a script <rekado>java-hamcrest-all builds everything sequentially. <rekado>the javac invocations in build.xml are within “sequential” tags. <ng0>civodul: did this have implications to the way services are written? I can send the link to my config <ng0>swapping out the kernel and firmware is easy <rekado>I don’t see where the race condition comes from. <ng0>I think I'll read the commit tonight <roptat>nckx: the internet says ckbcomp is required (ckbcomp fr | grub-mklayout) <nckx>roptat: That's what I'm trying to find now. If it's even packaged. It's not in the store of my build farm. :-/ <nckx>grub-kbdcomp [--help] ‘generates a keyboard layout for GRUB using ckbcomp’ <nckx>ACTION wonders if xkbcomp could do the job. <brendyn>roptat: can that be used with the slim-service? <nckx>I've generated a colemak keymap for GRUB using only an unmodified console-setup (the Debian-is-upstream thing that provides ckbcomp) on GuixSD, and Guix's own grub-mklayout. Testing will have to wait until I reboot my laptop which doesn't like VMs :-) <brendyn>nckx: cool. can that be integrated with guix? <nckx>brendyn: Absolutely, after a bit of hacking. <nckx>ACTION packages ckbcomp. <ng0>I dropped some notes a while ago into the bugtracker on adding localization for keyboards to slim and the other thing <brendyn>slim is more trouble than it's worth i think, might just go back to startx <roptat>brendyn: the link I sent you should help you define the x keyboard layout, so slim is affected by that too <brendyn>roptat: slim-service is defined within %desktop-services in my os definiton. i dont know how to edit that <brendyn>i'd need to somehow delete it from that list <roptat>that's what (modify-services %desktop-services ...) does <roptat>it's used in the example at the bottom of the page <brendyn>oops i was looking right that and didn't realise it already solved my problem <roptat>g_bor: I think your commits broke icedtea-7 <roptat>/tmp/guix-build-icedtea-2.6.13.drv-0/icedtea-2.6.13/openjdk-boot/hotspot/src/share/vm/opto/output.cpp:1832:109: internal compiler error: Segmentation fault <roptat>civodul: yes, that's what g_bor wanted to patch <roptat>I think icedtea-6 is patched, but not icedtea-7 <roptat>civodul: is this patch patched in core-updates, then? <civodul>roptat: the patch is patched in core-updates, yes :-) <civodul>but i think mbakke applied the patched patch in master to gcc@8 <civodul>on berlin Cuirass shows frequent "hook-failed" build errors, which i suspect are due to hangs somewhere while it's building things <civodul>snape: do you experience that as well on your instance? <rekado>roptat, g_bor: We cannot wait for core-updates to be merged; can you think of a way to fix the build of icedtea-7? <roptat>I didn't work on the fix for icedtea6, so I don't know <roptat>I guess the same kind of fix would work for icedtea7 <snape>civodul: the only issue I've seen so far is Guix not being able to build guix-modular, which is the multithreading issue you fixed. <snape>but I now run a highly modified Cuirass <snape>civodul: you're not compiling the input are you? Because I suspect there is an issue about it <snape>well I don't think it's related to your issue <rekado>I also get a segfault trying to build icedtea-7 on master. <noobly>what's the status of full disk encryption on guixSD? <snape>noobly: works with Libreboot, I didn't test without it. <roptat>why would it have anything to do with the firmware? <rekado>I use full disk encryption without Libreboot. <roptat>it works with propriatory bios/efi too <roptat>grub itself isn't encrypted, so grub is the one asking for the password first <snape>roptat: it has to do with the firmware because in the case of Libreboot, the grub being used is the one of Libreboot, so Guix doesn't have to install its own <roptat>so i guess with libreboot you really have full-disk encryption? <civodul>noobly: full disk encryption also works without Libreboot, there's an example in the manual <civodul>snape: well i do fresh-auto-compile for the 'guix' jobset, and no auto-compile for 'modular' <noobly>civodul: ok, I'm planning on using libreboot boot regardless, but thanks for the info! <snape>civodul: what I meant is that if #:no-compile? is set to #f, the compilation, which takes time, would prevent other evaluations to happen because it's in the same fiber <civodul>snape: but i think the problem is that under high load, like lots of build jobs in parallel, we have stuff somewhere blocking a bit, and so fibers not making progress, eventually leading to timeouts <snape>this, in practice, never happens because #:no-compile? is always set to #t <civodul>snape: oh true, we should simply get rid of that feature i guess :-) <noobly>snape: so boot is encrypted on FDE w/ libreboot? why have I never heard this before <snape>civodul: yeah that would be great to find out what is blocking <civodul>snape: indeed, feel free to go ahead with the removal (though we can't really change the database schema yet but the rest is okay) <snape>civodul: I'm doing quite a lot of changes ATM <snape>and it will definitely change the database schema <civodul>before we can change it, we need machinery so that db-init will automatically upgrade existing databases <civodul>you can look at how Hydra does it for inspiration :-) <civodul>it's not difficult, "just needs to be done", as we say <snape>ouch. That would be quite some work wouldn't it? <civodul>it's mostly about adding a "schemaversion" table, checking it upon init, and running schema-N.sql on the database when upgrading from version N-1 to version N <civodul>snape: re "Reset the Fiber dynamic environment in %NON-BLOCKING.", did you actually hit the bug? <snape>yes, when I fetch several inputs in parallel <snape>for a reason I don't understand, I don't have it if I fetch only one input <mbakke>noobly: /boot is encrypted without libreboot too, if you follow the example in the manual. <snape>sneek: later tell noobly: as mbakke said, /boot is encrypted without libreboot too. The difference is that there is no need for an unencrypted GRUB on disk with libreboot, because the one being used is on the firmware. <efraim>libcrashreporter-qt in owncloud-client's 3rdparty folder has its own bundled 3rdpart libraries <g_bor[m]>according to roptat's comment my patch broked icedtea. I'm trying to rebuild it locally again, but I built it before locally, and it went smooth... <efraim>apparently qt@5.11.1 restored the qt_use_module macro which broke a whole bunch of qt programs <g_bor[m]>Hello guix! I need some help. What doe drop do? <lfam>g_bor[m]: In the IcedTea packages? <janneke> Return a list containing all but the first I elements of LST. <lfam>g_bor: The "drops" are just the upstream names for extra source code archives. The drop procedures are defined at the beginning of the IcedTea packages and they are just convenience wrappers for source origins <lfam>For example, on line 962 of the java package module <g_bor>lfam:ok, now I can see the definition, thanks. <lfam>Unfortunately, the builds fail <lfam>But at least the source code archives are updated in the patches <g_bor[m]>lfam: I guess that it is really my patch that broke the build, it's just I can't see why it did build here. The fix is trivial, but needs some time to make sure. <lfam>I haven't been following the Java discussion, not sure what's wrong :) <g_bor>I reverted a change to build on gcc 4.9, then patched icedtea-6 to build. <noobly>do i install guixsd or libreboot first? <sneek>Welcome back noobly, you have 1 message. <sneek>noobly, snape says: as mbakke said, /boot is encrypted without libreboot too. The difference is that there is no need for an unencrypted GRUB on disk with libreboot, because the one being used is on the firmware. <noobly>does anyone here use hurd under guix? <lfam>g_bor[m]: Always look on the bright side ;) <alezost>is 'wine' available from hydra in general? I mean does hydra (or berlin) build wine at all, or is it intended to be built only on user side? <nckx>alezost: AFAIK there are no more ‘blacklisted’ packages since texlive. Isn't wine just broken at the mo'? It was very recently... <ng0>so, 20th try in 24 hours and I finally have an up to date guix again oO <ng0>however that happened <alezost>nckx: I don't know if it is broken or not; I have just noticed that it is not going to be substituted; thanks for letting me know about the absence of blacklisted packages! <nckx>I'd check but Hydra never ever talks to me. <nckx>ACTION tries here: 2 dependencies couldn't be built. <snape>noobly: Hurd isn't supported yet, but there are people working on it <noobly>snape: isn't it technically in a somewhat usable state though? <snape>I'm not sure, I think the person who is working on it uses a Debian Hurd as support <noobly>well anyway it seems like a cool project, can't wait for it to mature of the years <snape>noobly: also, about Libreboot, it's probably easier to install it from your current OS because you'll comfortable with the needed tools. But otherwise it doesn't matter <noobly>snape: awesome, thansk for the reply <g_bor>I've been thinking about lvm. The main problem is that it currently very badly maps to our mapped-device definition. <g_bor>actually a vg, which is very fundamental to lvm is not a source and not a target in our current definition. It is more similar to a target... but it has no source... So, it is strange... <jlicht>g_bor: You are working on the icedtea segfault rn? <g_bor[m]>It seems to me that the fix will be very similar to the icedtea-6 case. Somehow it built locally earlier, it must have been some mistake on my side... <noobly>I'm having trouble verifying the key signature of my .iso. I imported the public keys, then ran it against my download, and got this curious response: Good signature from "Ludovic Courtès <ludo@gnu.org>" [unknown] gpg: aka "Ludovic Courtès <ludo@chbouib.org>" [unknown] gpg: aka "Ludovic Courtès (Inria) <ludovic.courtes@inria.fr>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indicat <noobly>he owner. Primary key fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 <noobly>oh i guess I didn't need that end quote, but anyway any advise would be great. I also got this "no ultimately trusted keys found" after importing the publickey <nckx>noobly: That message is just to be taken very literally. You've never marked Ludo's key as trusted by you, so GPG doesn't know it's the right key (anyone could make a key under that name and/or mail address). <noobly>nckx: so you would trust this output? <snape>you would need to see Ludo in person, with his key, and then you'll know it's the good one and you can say so to gpg :p <nckx>I would, but you technically shouldn't trust me since I'm just a rando on the Internet. <lfam>That message is normal for GPG. It means that the archive was indeed signed with the key named in the fingerprint. It's warning you that you haven't marked that key as "trusted" <noobly>nckx: and this fingerprint is unique? any attacker couldn't just copy and paste said fingerprint onto a modified download? <noobly>lfam: ok, so nothing is abnormal here? is it standard and secure protocl to check something like the link nckx posted and compare fingerprints? <nckx>noobly: Yes (unless someone has access to currently-classified computing technology) and no. <snape>noobly: this the fingerprint of the public key used to sign the download. The attacker would need Ludo's private key to produce a fake download with that fingerprint. <nckx>So you're safe as long as you trust the Guix web site and the consensus in this channel. <lfam>The fingerprint is of the key used to sign the archive. I agree with what nckx is saying <noobly>nckx: ok, great. out of curiosity why did only Ludovic's fingerprint show up? <nckx>I'm not intimately familiar with the release process, but I guess only Ludo signs them? <noobly>snape: oh ok got it, standard crypto stuff, just making sure I'm truly ok as I'm trying to take my opsec a bit more serious <lfam>As long as the browser you used to download the files is reasonably up to date, and is a major browser, the security of the downloads is about as good as it can get <noobly>lfam: great, thanks guys! the original messages in my terminal were just a bit offputting. I will proceed with using the images :-) <nckx>noobly: Off to the fun bit! <lfam>Yeah, the GPG interface and messages are a bit overwhelming, even for seasoned users like me <nckx>ACTION sets the fun bit. <snape>unfortunately GPG is way more complicated to use than HTTPS <nckx>Yeah, the message is deliberately spooky, but this can sometimes be counter-productive. <nckx>I'm thankful for and like GPG. I also think it's horrible. <nckx>ACTION unsets the fun bit. <lfam>I wonder if anyone has found a key fingerprint (SHA-1) collision yet <noobly>is it possible for me to edit the install manual if I find typos? <noobly>found this "dd if=guixsd-install-0.14.0.x86_64-linux.iso of=/dev/sdX" but it should say *system*, not x86_64-linux <snape>noobly: sure, you can send patches to guix-patches@gnu.org, you're very welcome! <noobly>snape: awesome, I think this will be my first real contribution.. lol <snape>noobly: but it might also be that the documentation you're using isn't up to date <snape>the one that is online is the same age as 0.14, I believe <snape>noobly: and I think it has already been renamed <nckx>λ grep -w dd doc/guix.texi dd if=guixsd-install-@value{VERSION}.x86_64-linux.iso of=/dev/sdX <nckx>So patches still very welcome :-) <g_bor>yes, it seems that this problem is still there :) <nckx>I don't want to spread FUD, but doesn't the 0.14 installer deadlock itself with the guile-sqlite mess at this point, unless you know what you're doing? <g_bor>rekado:Nice, i didn't know that. <g_bor>rekado: It seems that I have a fix for icedtea-7. Sorry for the mess... <mbakke>nckx: As long as you don't `guix pull`, the 0.14 installer today should work the same as last year. <rekado>no worries about the mess; these things happen, unfortunately. <rekado>(and I had a good excuse today to do something else) <nckx>OK. Seems risky, but OK.