IRC channel logs
2018-01-18.log
back to list of logs
<quiliro>i have to leave in a few minutes... i have not been home for 3 days and 2 nights <quiliro>i just want to be clear if the process is: <quiliro>sudo guix system reconfigure config.scm --fallback <str1ngs>guix pull updates the package recipes for the user that is calling guix pull <quiliro>what i don't know is how to recover my system <quiliro>i just want to be able to do it next time correctly <str1ngs>to be safe. do sudo -i guix pull. then reconfigure with sudo -i guix system reconfigure /path/config.scm <str1ngs>sudo guix system configure is subjective to your sudo configuration <quiliro>but sudo -i guix pull does not work! <str1ngs>right but if guix pull as normal user works. the sudo -i guix pull . should use that build anyways <quiliro>so if i do guix pull before sudo guix pull, i would be ok? <str1ngs>they are some what interchangeable. but not always <quiliro>even if i do it without -i considering that i have an uprated guix <str1ngs>meaning if you guix pull as normal then as root. it will use the same build <quiliro>guix pull && sudo guix pull && sudo guix system reconfigure config.scm --fallback <rekado_>(then you don’t need “sudo guix pull”) <quiliro>guix pull && sudo -i guix pull && sudo guix system reconfigure config.scm --fallback <str1ngs>do sudo -i guix system reconfigure /path/config.scm <str1ngs>you need to understand your sudo configuration if not just be safe and use -i <quiliro>what is the required sudo configuration? <str1ngs>there is none, guix does not require sudo. <str1ngs>sudo is used to make invoking guix as root easier <quiliro>guix pull && sudo -i guix pull && sudo -i guix system reconfigure config.scm --fallback <str1ngs>that should work. but there is no *right* way <pkill9>why does `guix package --dry-run -u` say it's upgrading a bunch of things to the versions they're on, e.g. "hello 2.10 → 2.10"? <str1ngs>ideally sudo -i guix pull && sudo -i guix system reconfigure /path/config.scm --fallback . should be enough <str1ngs>quiliro: you'll need the full path to config.scm with sudo -i <quiliro>oh! perhaps that was the problem.... <str1ngs>well if you use relative path. sudo -i will fail <str1ngs>ie sudo -i guix system reconfigure config.smc <str1ngs>-i tells sudo to login. so its like doing su - <return> then as root guix ..... <quiliro>weird then because it did not...as i remember...possibly i am confused <quiliro>how can i make a totally offline server? <rekado_>guix environment: error: build failed: cannot link `/gnu/store/.tmp-link-4157-116612849' to `/gnu/store/.links/1n0pshmza8wh8ns9dxvxx45f2yq3lm4mkwwm2qslmid0l78aczb3': Structure needs <str1ngs>hmm could be the links are mangle and it need fixing. dunno <quiliro>what i mean is to have a machine connect to the net every so often so that i updates all available substitutes (or source if they are not available)...and then take that machine to the offline site <rekado_>8G left is barely enough: 4G for texlive, 4G for the graft temp directory <str1ngs>I suspect it's running out of working space or something <rekado_>str1ngs: yeah, that’s probably it. Luckily it didn’t again abort building. It just failed to dedupe. <lfam>The hard link deduper failed? <quiliro>is there a way to do what i need in this offline use case? <pkill9>why does `guix package --dry-run -u` say it's upgrading a bunch of things to the versions they're on, e.g. "hello 2.10 → 2.10"? <quiliro>str1ngs: how is it possible the hard way? <str1ngs>quiliro: maybe by using an external drive for the store <quiliro>but i would better want a substitute mirror <str1ngs>then you can just carry the external drive to host machine. <quiliro>i would have all packages instead of installed packages <quiliro>ice-9/boot-9.scm:760:25: In procedure dispatch-exception: <quiliro>ice-9/boot-9.scm:760:25: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #<pointer 0x0> <str1ngs>do you guile or guix installed in your root users profile? <lfam>pkill9: The functional packaging model means that if a dependency of hello-2.10 changes, then hello-2.10 needs to be updated based on the new dependency, even though the version of hello has not changed. There are also be new grafts to apply <lfam>I mean, there may also be new grafts to apply <quiliro>please check my help-guix message. it is dark now and i have to go <lfam>ICU woes on core-updates <Apteryx>str1ngs: good suggestion to restart lightdm... I hadn't. I'll try now. <Apteryx>nope, doesn't help; ratpoison still doesn't appear among Ubuntu's session options. <Apteryx>Documentation is scarce and it doesn't seem to do what one configures it to, and doesn't log any clue about why. <PotentialUser-89>I have couple of versions of GUIX studio installed on my machine. If I try to open a .gxp file with an earlier version it still opens in the latest version installed. and cant make the earlier version as default in windows association <Apteryx>This is about GNU Guix, the package manager. <atw>Apteryx: is this a ratpoison-specific problem or does it happen with other WMs? <Apteryx>currently I can't find a way to make it see ratpoison in Ubuntu 16.04; I haven't tried with oher WMs. <Apteryx>I've studied a bit the ratpoison package provided by Debian/Ubuntu; it seems to use something called 9menu to generate X menu entries. <atw>hmm...I know that slim reads .desktop files out of a directory like /usr/share/xsessions. I'm betting lightdm does something similar, and that your ubuntu-installed lightdm isn't reading Guix's xsessions directory? (guessing) <Apteryx>I'm looking forward having all what I need for work packaged in Guix and cannibalizing this system into GuixSD ;) <Apteryx>atw: I've tried making my own /usr/share/xsession/ratpoison.desktop file, but it didn't get listed at the lightdm-greeter... Strangely, the deb package doesn't provide such a file at all. <Apteryx>(but manage to make it available through lighdm) <atw>If my hypothesis is right, then using guix to install another wm that provides a .desktop wouldn't make the wm appear in lightdm either <atw>in ubuntu/debian, it may be that the package manager creates the .desktop if it decides it to be appropriate. <Apteryx>The postinst script from the Debian package seems to shed some light. It does some command like: 'update-alternatives --install /usr/bin/x-window-manager x-window-manager /usr/bin/ratpoison 20 --slave /usr/share/man/man1/x-window-manager.1.gz x-window-manager.1.gz /usr/share/man/man1/ratpoison.1.gz <Apteryx>So maybe some entirely different mecanism than the xsessions file is used to plug it into the system. <atw>that does sound like the used to "publish" ratpoison to lightdm <Apteryx>atw: I managed to start a ratpoison session; I think because I had it in .dmrc from experimenting with Ubuntu's native ratpoison. <Apteryx>this + maybe the file /usr/share/xsession/ratpoison.desktop that I had. <Apteryx>in that file I use just 'ratpoison' for the exec line, so it picks up the one installed from Guix <Apteryx>I think the update-alternatives is still required to have it show at the greeter though <atw>I think you'll need to call update-alternatives, much as the postinst does <Apteryx>didn't add it as a choice to the login greeter... I'm stumped. <Apteryx>But for some reason it now always login with ratpoison, so I guess I'm happy. <Apteryx>The only thing that works seems to be this: 'sudo update-alternatives --install /usr/bin/x-window-manager x-window-manager $HOME/.guix-profile/bin/ratpoison 20' <Apteryx>But it doesn't give you a choice at the greeter; it'll just log in with ratpoison. <Apteryx>it's some priority; I'm not sure about the specifics. <Apteryx>Could probably be 50 or something else. <Apteryx>arg... screw that it still doesn't work... It just remembers the last session I logged in with :( <Apteryx>Or maybe I could try SLiM. It at least works on GuixSD. <vagrantc>ACTION vaguely remembers lightdm having a commandline option to set the greeter <Apteryx>can't find anything relevant there :/ <atw>does "registered in the menu" mean "installed as an alternative" ? <atw>Or could it mean something else? <Apteryx>so it does seem like providing a menu does make it visible through the greeter... that .desktop file don't work at all is beyond me though. <atw>but that's nominally for GDM <Apteryx>update-menus --stdout | grep ratpoison gives: !F /usr/share/menu/ratpoison and command="/usr/bin/ratpoison" needs="wm" package="ratpoison" section="Window Managers" title= <Apteryx>I'll try just keeping the file /usr/share/menu/ratpoison, hacking the path of the ratpoison binary, and re-running 'update-menus' <Apteryx>atw: this is insane. I'm off to bed! Thanks for the support! <atw>such as it was :P I hope you'll find it easier on guixsd <igeek098>i am new to GuixSD and i installed it on virtual machine already, but i want help to install non-free firmware for WiFi chip can i get help here? <igeek098>also is there a link or sth that explains how guix system init do the magic <igeek098>i mean i installed systems like arch debian and LFS, and i know the commands but don't know how is this done with guixsd? <kittybearwolf>Guixsd uses GNU Shepherd so their doco would be the first place to look <g_bor>I'm trying to solve the ant-bootstrap not reproducible problem. <g_bor>I have found that we fix the jar timestamps in our ant-build-system using a strip-jar-timestamps procedure. <g_bor>However, when we are bootstrapping we don't have the ant build system yet. <g_bor>This causes the bootstrap ant build to be unreproducible. <g_bor>Is there a way to reuse the code from the build system, or should I just replicate in a phase in the package definition? <g_bor>Or should that code go to (guix build utils) or (guix build java-utils) and used from there? <civodul>g_bor: you can definitely reuse that code <civodul>simply add (guix build java-utils) to #:imported-modules and #:modules of that package <civodul>(and make sure 'strip-jar-timestamps' is exported) <g_bor>Somehow I cannot access the git repo. I got could not resolve git.savannah.gnu.org <g_bor>Yes, it is just I first have to move that to java-utils from ant-build-system. <civodul>i think Java is still broken on core-updates, so you can probably make those changes there <civodul>(and fix Java while you're at it ;-)) <efraim>if you're looking for inspiration, I used part of emacs-build-system for translate-shell <civodul>efraim: re GCC 4.9 in core-updates, i think you can modify it and that won't trigger a full rebuild <efraim>we need gcc-4.9 for libstdc++-boot0 <civodul>but maybe you could avoid an extra gcc, still <civodul>like by removing the extra patch in the gcc-4.9 used in commencement.scm <efraim>I could test it again, but libstdc++-boot0 should work with gcc5 on aarch64 since it uses gcc5 for the bootstrap gcc <civodul>core-updates is looking rather ok now <efraim>armbian applies 56 patches on top of their odroid-c2 4.14 kernel <efraim>civodul: what do we need for the aarch64 boxes? just power cables? <civodul>efraim: actually one of them is up and running at my place! <civodul>we just need to add it to machines.scm of one of the build farm <rekado>civodul: didn’t you already add one of them to berlin? The problem was just with the firewall here IIRC. <rekado>I already asked IT to change the firewall settings, but haven’t tested since. <Apteryx>sneek: later tell atw for the record, I ended up replacing LightDM by SLiM on my Ubuntu install, and got what I want under 10 minutes... :) <civodul>rekado: i wanted to do that, but then Mark suggested adding it to hydra instead, then i went on vacation, and then i dropped the ball <civodul>but yeah, about everything is in place <Apteryx>anyone having a working dual screen setup with some randr magic to make things readable on a 4K (high DPI) screen? <Apteryx>I looking for something to put in my ~/.bash_profile; I'm using ratpoison. <civodul>Apteryx: i just turn on the external screen with "xrandr --output DP-2-2 --auto" and things like that <civodul>that said my external screen is low-dpi whereas my laptop's screen is high-dpi <civodul>and i don't think there's a good solution for that, apart from playing with font sizes <Apteryx>civodul: Thanks! I'm guessing something in randr exists to scale things, as there is this option in Ubuntu's unity: "Scale for menu and title bars" which makes every font appear bigger (and even the UI elements of applications such as Icecat) <civodul>yes there's "xrandr --dpi", which is supposed to be per-screen <civodul>in practice though, it seems to be for all screens <civodul>also, not all apps/toolkits honor it <Apteryx>OK! I'll try a couple things when I'm back to work, thanks! <str1ngs>Apteryx: the program arandr is good for this. it can be scripted in .xinitrc of bash files aswell <str1ngs>actually it will generate the bash file <rekado>I only know that there’s a global environment variable for integer scaling of GTK widgets. <rekado>there are two things I’d really like to get done before FOSDEM: 1) replace slim with lightdm, 2) add a texlive profile hook <civodul>rekado: sounds like a great plan :-) <rekado>alas I’m still tied up in a big project for a set of reproducible bioinfo pipelines using Guix. <rekado>hope there will be enough time left to squeeze that in. <civodul>that also sounds like a great project to work on <civodul>rekado: could you "herd stop cuirass && guix system reconfigure" on berlin with the latest guix-maintenance.git? <civodul>i've added the build machine there, and "guix offload test" says it's alright <rekado>I see I left a bit of a mess with the config files there. <efraim>mariadb update failed to build on aarch64, someone else will have to do the update to 10.1.30 <shiranaihito>has anyone seen GuixSD not be able to boot under a VM, even when everything is in order on the disk? <civodul>ACTION wonders whether we should remove the "ban" of texlive-texmf on hydra <civodul>and the end result must be about the same size when compressed <efraim>Its also about the time spent compressing it <ng0>I noticed the build of texlive was around 5G <ng0>it would be really good if we could manage this, so that we don't have to figure it out on our selective CI :) <ng0>(provide it I meant) <ng0>civodul: was the reason just the small VM that hydra is on, and/or the size? <ng0>you mentioned it a couple of times in the psat <rekado>civodul: yes! I was thinking the same yesterday when I waited for *hours* to fetch the texlive tarball and then graft it locally. <rekado>I needed ~ 4G + 4G for the graft <civodul>rekado: you'd still need to graft it though :-/ <civodul>the only difference is you wouldn't get that infamous "410 Gone" <rekado>I thought about grafts yesterday night <rekado>at the very end of a package build we’re scanning for references. <rekado>is it feasible to record the locations of references? <rekado>then grafting only needs to seek to these locations and update the references. <rekado>faster than scanning all files from beginning to end *again*, I think <civodul>currently grafting are normal derivations, though <civodul>so what you suggest would essentially require grafting to be delegated to the daemon <civodul>so we'd need to have a "builtin:graft" derivation builder, and that thing could use extra knowledge from the daemon <civodul>i'd rather avoid the big texlive package ;-) <rekado>I found grafting to be a *little* too slow not just for the abnormally large texlive package. <rekado>things like matplotlib are also grafted somewhat slowly. <rekado>big profiles often take quite a bit of time grafting. <efraim>ng0: user namespaces is 3.17+ I think, it hasn't come up in forever though <civodul>rekado: right, grafting takes a significant part of my profile upgrades, too <civodul>the grafting code might be faster with Guile 2.2, but we hit a threading bug back then <civodul>(currently we're grafting with 2.0 as a workaround) <rekado>extending the daemon to have yet another builtin reminds me: I wonder if there’s a way to replace parts of the daemon by embedding Guile. <rekado>by the time all daemon features have been moved to Guile all we’d have to do is “turn it inside out” (i.e. use Guile from the outset instead of embedding it). <str1ngs>rekado: thanks I got yasnippet working and patches off <ng0>efraim: user namespaces? <efraim>I think that's needed for guix containers <civodul>rekado: yeah, i thought about that, but i'm not sure it'd be that easy <civodul>mostly because the daemon is not that modular currently <civodul>and also we'd need to write lots of C-to-Scheme glue <civodul>what we should do is resume what reepca has been doing! <civodul>speaking of which, it's GSoC time (hint, hint :-)) <civodul>ACTION just (re)discovered what "module files" look like <civodul>that makes me quite happy of our search path handling <civodul>and module files are ~50 lines of Tcl for a C library <civodul>half of it is boilerplate to set PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH, etc. etc. <pkill9>is there a way to use a graft to effectively add the equivalent of an LD_LIBRARY_PATH to all binaries? <rekado_>civodul: I think I’ll mention the search-paths feature when introducing Guix HPC at the EasyBuild Users Meeting. <ng0>is there an example in guix already to disable stripping of binaries in the build-system? <ng0>oh, searched for the wrong word <ng0>+CONFIG_GENERIC_CPU_VULNERABILITIES=y <ng0>it's a mirror from jxself. <ng0>would someone happen to be working on a package for botan? <ng0>how well does guile-emacs perform? I've read some use it here. I assume emacs packages for current emacs can not be used with it (from what I remember from the note in the Guile announcement + discussion about it), or how far is it progressed? <nckx>bavier: wine 3.0 already in Guix :-) <nckx>Rutger beat me to it. Must be able to build Wine in finite time. Cheater. <rekado_>building Wine on my laptop takes … much too long. <rekado_>ng0: it is still pretty slow; it starts up very slowly (because it doesn’t compile the elisp packages?), but once it is up it’s bearable. <rekado_>ng0: Emacs packages generally do work with it, but some are known to crash it. <rekado_>(I think it may have been desktop-save-mode) <rekado_>ng0: you might get more info on #guile; AFAIK there hasn’t been any significant progress since a year or more. <ng0>rekado_: ah.. ok, thanks :) <amz3>a toy editor, I made in guile <amz3>no where near to compete with emacs <amz3>but it will when I will have infinite time to work on free softwar <amz3>which means likely never ;) <boegel>is there a clean way to let guix-daemon stop? <ng0>herd stop guix-daemon ? <ng0>or whatever you run it with <rekado_>ACTION watches talk about a GNU Hurd HPC system <rekado_>it is! It’s Hurd as a Single System Image cluster. Wish I had time to work on something like that. <bavier>we're all contributing in one way or another <OriansJ>well I found a fresh hell, trying to manually boot guix from grub in qemu. Would it be unreasonable to request that vmlinuz and initrd.img files have a hard link generated by default in /boot ? <bavier>rekado_: thanks, I'll definitely watch it later <pkill9>what are the benefits of Hurd over other kernels? <pkill9>i love how guix automatically makes packages from other package repositories <rekado_>pkill9: Hurd is not a kernel, but a set of servers on top of Mach (a micro-kernel). <rekado_>pkill9: these servers together provide a very flexible, user-controllable system with a POSIX persona.