IRC channel logs
2018-07-25.log
back to list of logs
<ecbrown>sorry, this n00b has to ask: i've made changes to my branch of guix git tree, ssh.scm just to confirm, i should do: su; ./bootstrap; ./configure --localstatedir=/var ; make ; make install ; guix system reconfigure /etc/config.scm ? <roptat>ecbrown: usually you can run the guix from your git checkout with pre-inst-env <roptat>from the checkout, simply run ./pre-inst-env guix ... <snape>ecbrown: and you don't need 'su' <snape>ecbrown: and don't 'make install' as roptat said <ecbrown>ok i will kill what i have running, one sec. (finally see where pre-inst-env comes from :-D ) <pkill9>doesn't it come from ./configure && make? <ng0>it could be shorter: guix environment --fallback --no-build-hook --pure guix --ad-hoc guile@2.2.4 followed by: ./bootstrap; ./configure --localstatedir=/var --sysconfdir=/etc; make; ... no idea what you are trying to achieve with the rest, possibly a different OS. <ecbrown>ok, i have: as ecbrown, guix environment guix ; ./bootstrap ; ./configure --localstatedir=/var ; ./pre-inst-env guix system reconfigure /etc/config.scm <pkill9>oh lol, i forgot guix is packaged in guix <snape>ecbrown: don't forget 'make' <snape>and you'll need 'sudo -E' before ./pre-inst-env guix system reconfigure config.scm <jlicht>ng0: why the --ad-hoc with the guile@2.2.4? <snape>it's to make it "even shorter" :-) <ng0>it's not just --ad-hoc, but also --pure. I had some problems before I got to this line in my script <ng0>and the addition of guile@2.2.4 only existed in transistioning to 2.2.4 <snape>I don't use those and I don't have problems, for what is worth <ng0>my setup is not really standard. so if it works for you, might work for the majority :) <snape>Hmm it seems that I can't force push on someone else savannah branch :( <Saone>Hi, I have a couple questions - I'm investigating using guix for a project, and I've downloaded the QEMU VM image and the GuixSD install image. It looks like the QEMU image is a minimal config that I'm supposed to add packages and such to the config, but I'm not sure where I do that - it looks like there's various .scm config files in hashed directories, but I'm not sure how to (for instance) add a DHCP service. Meanwhile, on the <Saone>GuixSD installer, I've been looking at making my own config.scm, but I'm not sure what like, a minimal config with the simplest possible partitioning scheme and such might look like. Are there gists or something available? I haven't been able to find like, simple examples of how to do these kinds of tasks. <snape>Saone: you can either install packages as a user with 'guix package -i <package-name>', or globally by adding them to 'config.scm'. <Saone>Snape: In the GuixSD vm image? I didn't find a config.scm in /etc, and I'm not sure where that would go/be in that image. <snape>I have no experience with GuixSD vm images, but you can create your config.scm from scratch <snape>and then you pass it as an argunent to 'guix system reconfigure' <Saone>In the GuixSD installer, yeah, I've been putting together a config.scm with some base packages and such, but I'm a little confused when it comes to partitioning, especially since we'd like to encrypt the disks. I'm not really sure how to reference the various partitions and if I need to add a (mapped devices *) section in addition to (file-systems *) and such. <Saone>In the GuixSD installer, yeah, I've been putting together a config.scm with some base packages and such, but I'm a little confused when it comes to partitioning, especially since we'd like to encrypt the disks. <Saone>I'm not really sure how to reference the various partitions and if I need to add a (mapped devices *) section in addition to (file-systems *) and such. <Saone>(oh, resent message, for some reason it displayed as white text on a white background in my client?) <snape>anyway, did you see the mapped-devices examples? <snape>it takes a source, which is the original raw device <snape>and the target is the mapped device, that is, the one that is unencrypted by LUKS <Saone>yeah, but I still don't really grok how the partition layout works for LUKS partitions. Do I need an unencrypted boot partition, separate from the LUKS partition(s) as well? <snape>it should work with the whole thing being encrypted, including /boot <snape>grub wouldn't be encrypted, but it's installed outside of the partitions <Saone>right, though, is MBR supported, or do I need to use GPT (or another partition table)? Do I have to use UEFI bootloaders? I see a lot of UEFI references in the manual. <Saone>oh gotcha, I found a non-EFI example for the bootloader config <ecbrown>ok! the ssh patches seem to have built, and they seem to work as expected. thanks all for your help. <Saone>I think I grok this a bit better now, I'm gonna poke at it for a bit. Thanks :) <vzorkic>Is it possible to install GuixSD using only binaries? Is compiling mandatory for the installation? I'm trying to install GuixSD using the bare-bones example config and it wants to compile almost everything. Did I do something wrong? <pkill9>vzorkic: the installation should get binaries, does the [virtual] machine you're installing it on have access to the internet? <vzorkic>Yes, it pings successfuly to gnu.org <vzorkic>I'm trying to install GuixSD on a virtual machine, it has 512mb ram and a 10gb disk <pkill9>i recommend atleast giving it 1.5Gb of RAM for installation <pkill9>though that's not related to your issue <pkill9>i think it *may* normally compile a few things during installation <vzorkic>Alright. Could the installation media being outdated be related to this? I downloaded it a few days ago and only started installing the system today <pkill9>nah, because the build servers keep substitutes for the installation media available <pkill9>did you run `guix pull` before installing? apparently the best installation flow atm is to install a minimal system, reboot into it, then run `guix pull`, then run `guix system reconfigure` with the system config you actually want <vzorkic>Also I've been following the GuixSD installation manual and the commands it gives. Maybe I forgot some step related to the build servers that isn't in the manual? I've seen something about authorizing build servers somewhere, could that be it? <pkill9>by default the main build server is authorized for sure, not sure about hydra <vzorkic>but it started compiling itself and I'm don't really want to do that <pkill9>try running guix pull with --commit=<older commit> and it may pickup substitutes for it <pkill9>but do it after booting into the system, not while in the installation image <pkill9>(hopefully in the future you won't need to do that) <vzorkic>Alright, thanks. If I'd want to authorize a build server for the installation how would I do that? The manual says "guix archive --authorize < prefix/share/guix/hydra.gnu.org.pub <vzorkic>but I couldn't find the prefix on the installation media <vzorkic>I'm not really sure where could it be <pkill9>i think it's in /run/current-system/profile/share/guix/hydra.gnu.org.pub <Saone>okay, so, I have two partitions, /dev/sda1 (an ext4 luks partition), and /dev/sda2 (a linux swap partition). The /dev/sda1 partition I've followed the instructions on the Preparing for Installation page, and done: <Saone>cryptsetup luksFormat /dev/sda21 <Saone>cryptsetup open --type luks /dev/sda1 my-partition <Saone>mkfs.ext4 -L my-root /dev/mapper/my-partition <Saone>when I `guix system init ...`, I get an error about "device `my-root` not found" - do I need to give /dev/mapper/my-partition in the file-systems definition or something? <Saone>pinging snape since you were helping me earlier :^) <Saone>also s/the example/the first example <Saone>jk, not the first example, but I think I figured it out, I had to add (file-system-label *) around the label - but now guix system init is failing with build errors <Saone>I think I figured it out - I'd forgotten to dhclient -v after rebooting :^) we'll see if this boots in a bit <ecbrown>dang, i think i've seen the openssh daemon not starting at startup bug again, and i have applied the recent commit which closed debbugs #32197 <ecbrown>my test for the fix was on a VM, and i swear it worked at startup. but installing it on this hardware, and i am seeing ssh-daemon not start up <brendyn>Hmm it seems my patch for ecryptfs insnt working. i swear it was before <brendyn>I don't understand why ecryptfs has files in its output under .../sbin/, but those files do not appear in .guix-profile/sbin/ <vagrantc>in particular, in a virtual machine running in kvm? <efraim>sneek: later tell vagrantc you might be able to hibernate from the CLI on guixsd with loginctl <brendyn>vagrantc: I think it is not supported yet but there was some code written for it, so I've heard <vagrantc>ACTION is unfortunately forgetting what the question was :/ :) <sneek>vagrantc, you have 1 message. <sneek>vagrantc, efraim says: you might be able to hibernate from the CLI on guixsd with loginctl <brendyn> civodul pkill9: Mark Weaver posted experimental code to support hibernation one or two years ago, but unfortunately that never went further <brendyn>vagrantc: it was only 3 hours ago you asked xD <vagrantc>basically, i've got guixsd running in a vm and had a long-running upgrade (e.g. kernel build) ... and my laptop doesn't suspend reliable so i wanted to try to hibernate the VM <vagrantc>brendyn, efraim: thanks for the answers, though! <brendyn>I suspend my lapop all the time but I've never tried hibernating <vagrantc>well, i'm pretty sure the real problem is a loose cable inside /o\\ <marusich>Is there a way to tell Geiser's Guile REPL to reload the modules I'm working on? <marusich>I tried the "reload-module" procedure, but it didn't seem to work. Maybe I used it wrong or something. <marusich>Right now, I'm killing the Guile process and starting fresh each time, which is a bit tedious. <snape>marusich: I don't think you can "un-evaluate" stuff, so killing Guile might be the best way <marusich>Makes sense. I'm just hacking around, so an imperfect solution might be nice if it's more ergonomic than the "kill, then restart" pattern. <snape>marusich: you might have more answers on #guile <snape>Hi TSholokhova_! If the rebasing works for you, maybe you can put your branch on my commit (3d0c809), so that we all work on the same basis. <efraim>do we have a bug number for the hplip -> qt dependency issue? <efraim>patch pushed! everyone switch your os-config for the cups service hplip -> hplip-minimal <efraim>now to try to fix the qtvulkan something on qt-updates <efraim>hmm, looking at the qtbase commit logs we might need to change the license fields to include the FDL <snape>g_bor, it's some kind of multithreading/fiber issue I guess <snape>GNU parallel is very good at spotting them <brendyn>I learnt about GNU parallel only recently. It seems quite cool and useful <g_bor[m]>snape: Ok, fine. Is it related to the rebase, the web interface, or something old? <snape>I can't reproduce it without the web interface, and I reproduce it always with the web interface (with or without the rebase) <g_bor[m]>snape: fine, I think we can wait for Tatiana to have a look. <rekado_>mbakke: when in doubt in the future just use Mark’s fixes over mine :) <snape>g_bor[m]: I'll have a look anyway <snape>I've spent a lot of time with Fibers already <brendyn>I'm getting a hash missmatch for fuse source <g_bor[m]>I have an almost trivial problem. I would like to remove the first blank line from a file in one of our packages. What would be the easiest way to do that? <snape>g_bor[m]: pressing the Delete key on your keyboard? <g_bor[m]>I mean in a build phase I need to remove the first blank line from a file. The file currently contains only two blank lines, so for now I could remove the blanks and add one blank at the end, but it feels like a hack :) <brendyn>if anyone already had the old fuse source could they diff it with the new one? <g_bor>rekado_: I will have a look at removing the manifest generation code from picard. The comment says that it is there, for the case we would like to run the jar file as executable. I guess I can simply test if it still works, and then it is fine to remove. <g_bor>Unfortunately I did not find any hints in the documentation, that the index takes over this role, so if you have any reference please point me there. <g_bor>Also the error we see in java-picard is most probably because the ant manifest task adds a newline, so breaking the first manifest section. <g_bor>rekado: simply removing the mainfest generation from picard does not work. <rekado_>g_bor: the index only helps in finding class files, IIUC. <rekado_>g_bor: we still need a manifest to specify the Main-class, but I think we can do without specifying the class path there. <g_bor>Actually it does not work. I've just tried this. It can't find htsjdk if I try to run it like 'java -jar picard.jar'. <g_bor>rekado: I now have a working version, it seems. It goes like I remove the blanks from the file using replaceregexp, then do the echo. It seems ok. <ng0>guix post-1.0 would be great to get the pull mechanism to work on the lowest specs possible. Like I have an itch to scratch with afaik unsupported hardware but the capability to run a full Debian, maemo5 / n900. this is 256 MB RAM, 600 MHz Cortex-A8 CPU, and PowerVR SGX530 GPU. <brendyn>ng0: Yep it's an great goal to work towards. <rekado_>g_bor: does the manifest still contain a list of classes/jars? If so, are the lines still broken up? <rekado_>the manifest specs impose a line length limit, so we should not exceed it. <ng0>on official guix side powervr sgx530 can probably not be supported, but lowering the requirements would be great nevertheless. <brendyn>ng0: would you like a guix-lite that was substitute only? <rekado_>“guix pull” uses substitutes already. <rekado_>I’m sure that with ongoing development in Guile the memory requirements can be lowered. <ng0>brendyn: no. it's more about the resources used when compiling. <g_bor[m]>rekado_: Yes, I know it. Fortunately the code in java-picard was taking care of that already. <brendyn>when i run guix pull it says it is compiling some .scm files <g_bor[m]>The bug was introduced by switching to the manifest task, which introduced a linebreak before the classpath attribute. <rekado_>g_bor[m]: I see. Does this mean that we still need that custom phase in java-picard? <rekado_>I don’t like it and would be happy to see it replaced. <ng0>so let's say you have toasterWHYFI, and it has a wifi connection, 20 GHz CPU and only 256 MB because it is a toaster. So ideally - if hardware supported - the toaster would be able to compile guix, even if it took days or weeks, to not rely on substitutes for guix being available; make the guix infrastructure less centered on one server cluster. <rekado_>brendyn: we don’t have substitutes at all times for all derivations that “guix pull” builds. <g_bor[m]>rekado_: Unfortunately yes. Where are we calling picard as an exectuable? <jlicht>ng0: in that specific case, I'd rather have a thin wrapper that tranparantly uses guix pack and unpacks that <rekado_>ng0: if I were to use Guix on a toaster and not use substitutes from hydra / berlin I’d definitely set up offloading and *not* compile on the toaster. <brendyn>yeah, so I was thinking a substitute only guix would need to have it's guix pull cooperate with a server that was building for it, rather than pulling from the main master <g_bor[m]>Another possibility is to provide a wrapper with the classpath. WDYT? <rekado_>Compiling for hours could produce enough heat for toasting, of course, but I don’t think you’d toast bread for hours on end. <rekado_>g_bor[m]: that would be a little too crude. <rekado_>g_bor[m]: people expect to be able to run it with “java -jar picard.jar Command” <rekado_>g_bor[m]: another possibility is to implement a custom class loader that would be used by our JDKs. <mbakke>I would prefer to flash Guix on my toaster instead of building locally. <mbakke>`dd if=$(guix build toaster.scm) of=/dev/toaster` <rekado_>g_bor[m]: but then the jars would not work with any non-Guix JDK. <ng0>I've been reading into Elixir and Erlang lately. And they have this OS, "Nerves", which has some pretty amazing deployment methods for small hardware. and after the initial burning of the firmware you get to upgrade the OS via ssh.. I'm thinking about safe ways we could reuse that without being as safe as Elixir. <ng0>mbakke: maybe we could have toast as punchcards <rekado_>what do you mean by “without being as safe as Elixir”? <ng0>ACTION bad ideas at 36°C room temperature <ng0>rekado_: nvm, I am still looking into the whole process. it differs from our OS pretty much because of beam. <g_bor[m]>rekado_: Well, I think that then the current solution is the best we can do. <rekado_>g_bor[m]: thanks for investigating this! Do you think we could generalize this custom phase? <rekado_>ng0: and we use the Guile VM. ¯\\_(ツ)_/¯ <rekado_>ng0: at 36 degrees you should probably stop compiling Guix on that toaster ;) <ng0>the toaster already handed in complains at the toaster union.. they have a hot handshake. <g_bor[m]>It seems that we don't often need to set the runtime classpath, but we could generalize this phase. <rekado_>g_bor[m]: one thing that’s still problematic, I think, is grafts in this case. <rekado_>g_bor[m]: the paths in the manifest are still split and thus would be missed by the reference scanner. <rekado_>we retain references because the index does not have this problem, but we wouldn’t be able to *update* these references when grafts are necessary. <efraim>i copied a bunch of changes from qtbase to qt, hopefully I can fix the qt-5.11.1 compile problem on x86_64 today <rekado_>this means that for picard.jar the ungrafted references would be used. <efraim>I keep on trying to use vim keyboard movements inside quassel, is there another irc client that does support that? <efraim>(preferably not an irc.vim style addon) <ng0> https://www.youtube.com/watch?v=jmkq4SwV2Ss so basically they have some NIFs to C applications iirc, then they have their own bootloader and tooling in Elixir and Erlang, and the entire thing hooks into buildroot. They can enable "hot swap" OS switching through having 2 partitions on the device, and firmware is written with fwupd. the interesting thing is, that you can send firmware updates to the device after <ng0>its initial flash over the network. where we already have parts of the process in our own tooling, just the way you update small devices over the net is interesting. however it is probably not applicable to our style since we have a different approach at OS. I got sidetracked... just something interesting I learned last week. <jlicht>efraim: I guess emacs + evil + rcirc does not count ;-)? <efraim>jlicht: preferably not in emacs either :) <g_bor[m]>Yes, this is problematic. I have an optimization in mind. We already have the index, so we could do a smarter reference scan on the manifest, if the index meets certain criteria. I can organize the classpath in the manifest so that it looks like '[SPACE]jarname[SPACE][NEWLINE]' rows. This can still be broken up by the manifest format, but it only happens if the absolute path turns out to be longer than 69 characters, and we <rekado_>do we *need* to use absolute file names in the manifest? <rekado_>or can we use plain names and let Java figure out the exact locations via the index? <g_bor[m]>rekado_: No. But in case of picard we do that. I will have a look at the spec. <efraim>looks like I want irssi with the vim plugin <g_bor[m]>Actually what we do right now is not legal according to the specification. It says that all paths must be relative. <pimi>@_rekado I am on this channel <g_bor>I need a bit of help, maybe someone has more insight. Currently I hand edited the build.xml in picard, so I have a matches " "... <g_bor>How can I get sxml to write this. <g_bor>Or moge generally how to get character references? <rekado_>g_bor: I don’t really understand the question, but you can define XML entities and use them with the sxml procedures. <rekado_>but 13 and 10 look like newline characters. <efraim>mbakke: I'm looking at monolithic qt-5.11.1 on my laptop and on hydra, it's a race condition all 4? times on hydra <g_bor>What I would like to do here is to match against two cr-lf newlines. So I need these in character reference form. <g_bor>It is actually valid xml 1.1, but not valid xml 1.0. <efraim>I feel like the best bet would be to build libQtCore.so* first and then everything else, but I'm not confident on patching qtbase, so parallel-builds? #f it is <g_bor>efraim: Yes, actually having a look at the logs it seems that libQtCore.so was not found by the vulkan something... Does disabling parallel builds solve the issue for you? <efraim>g_bor: I have my laptop set to build with 1 core, it found libQtCore.so at that same point just fine <mbakke>efraim: Great that you found the issue. Do you think we can merge the branch? <efraim>I'm building out monolithic qt on my aarch64 machine to make sure the other changes I made don't cause problems and then I'll merge it in <efraim>I even added some changes from qtbase, so we might actually be able to mix and match if necessary <mbakke>Will the changes rebuild 'qtbase'? If so we should do another Hydra evaluation to make sure we have substitutes. <efraim>i fixed python2-pyqt, monolithic qt looks good so far, python-qscintilla(?) needs fixing on the install phase <efraim>also haven't tested kxmlgui recently <mbakke>kxmlgui is already broken, no? I'm sure we can deal with the remainder on 'master'. <efraim>Sounds good, I'll merge it in when I'm back at my computer <bavier>ugh, openmpi 3.*'s new oversubscription policy causing me problems <bavier>I think we want it to allow oversubscription by default in our build environments <bavier>e.g. the scalapack build fails in my environment unless I set OMPI_MCA_rmaps_base_oversubscribe=yes in the build environment <mbakke>efraim: Great! I've started Hydra. <efraim>I meant to go master -> qt then qt back to master <efraim>But it turns out the second wasn't needed <thomassgn>huh. cups keeps giving me "can't create temporary file" when I try printing. <thomassgn>it did the same last time I tried making it work with a different printer (half a year ago) <wigust>thomassgn: it seems a printer is not a problem :-) <ng0>how do you try to print? <ng0>the command line interface is tricky, I'd suggest the webinterface <thomassgn>I'm using zathura's print function - which is a generic print dialog. I use the webinterface to add printers and check status. So the web interface is where I see the error... <thomassgn>zathura uses gtk, so I guess it's using gtk's printing facilities <wigust>thomassgn: What about adding yourserlf to ‘lp’ group? I had ‘can't create temporary file’ issue before, but I don't remember the way to solve it. <janneke>i'm getting: guix offload: error: corrupt input while restoring '/gnu/store/9mzwra1vbf4lp1fci02gaq09i8c3l2a4-grub.cfg' from #<unknown channel (freed) 1ddd540> <efraim>mbakke: i seem to love those extra quotes :) <mbakke>efraim: Hehe. Splicing is just too fun ;) <thomassgn>wigust: added myself to lp and lpadmin groups. 'sudo -su username' so I am in "new login", check with 'groups' that I'm in the groups. Run zathura from there and print as I tried previously. Same error... <thomassgn>do you have any special things in your cups service config? <wigust>thomassgn: Except ‘location-access-controls’ which is for web interface URL restrictions (as I think doesn't related to your issue), no special things. <wigust>thomassgn: Is it possible to print a test page from a web interface? <jlicht>if someone has time, could they perhaps help me debug an issue with readline? I basically have my Guile REPL crash when loading *certain things*, of which one is the git-module. The script at http://paste.debian.net/1035179/ demonstrates the issue: running this script with `guile -q <script>', as does `cat <script> | guile -q'. When pasting the script into the guile repl by hand, I seem to have a frozen repl though.