IRC channel logs


back to list of logs

<quiliro>str1ngs: doing it successfully now
<quiliro>in progress....
<quiliro>loading... 20.6% of 661 files
<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>guix pull
<quiliro>sudo guix pull
<quiliro>sudo guix system reconfigure config.scm --fallback
<quiliro>would that be correct?
<str1ngs>guix pull updates the package recipes for the user that is calling guix pull
<quiliro>guix pull is compiling now
<quiliro>str1ngs: i know
<quiliro>what i don't know is how to recover my system
<quiliro>i have spent 3 days without success
<quiliro>but now i have to go
<quiliro>i just want to be able to do it next time correctly
<quiliro>the best would be to do it offline
<quiliro>so i do not have to sleep here
<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>cool then
<quiliro>but i cannot sudo guix pull
<quiliro>let me test again after guix pull
<quiliro>next time i come i will do:
<quiliro>guix pull && sudo guix pull && sudo guix system reconfigure config.scm --fallback
<quiliro>so i can go to sleep home
<str1ngs>sudo -i guix pull
<rekado_>(then you don’t need “sudo guix pull”)
<quiliro>guix pull && sudo -i guix pull && sudo guix system reconfigure config.scm --fallback
<quiliro>is that correct now?
<rekado_>don’t mind me, I’m tired.
<str1ngs>do sudo -i guix system reconfigure /path/config.scm
<str1ngs>to be safe
<str1ngs>you need to understand your sudo configuration if not just be safe and use -i
<quiliro>what is the required sudo configuration?
<quiliro>the correct command then is:
<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
<quiliro>is this right?
<str1ngs>that should work. but there is no *right* way
<quiliro>but other ways have not worked
<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....
<quiliro>i might have a config.scm on /root
<quiliro>no...i don't
<str1ngs>well if you use relative path. sudo -i will fail
<str1ngs>ie sudo -i guix system reconfigure config.smc
<str1ngs>err scm
<str1ngs>-i tells sudo to login. so its like doing su - <return> then as root guix .....
<quiliro>weird then because it did i remember...possibly i am confused
<quiliro>how can i make a totally offline server?
<rekado_>Huh, that’s a new one:
<rekado_>guix environment: error: build failed: cannot link `/gnu/store/.tmp-link-4157-116612849' to `/gnu/store/.links/1n0pshmza8wh8ns9dxvxx45f2yq3lm4mkwwm2qslmid0l78aczb3': Structure needs
<rekado_>“Structure needs cleaning”?
<str1ngs>do you have disk space?
<rekado_>8G left
<str1ngs>hmm could be the links are mangle and it need fixing. dunno
<rekado_>(this is trying to build texlive…)
<str1ngs>oh gawd texlive
<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
<str1ngs>textlive is huge
<quiliro>s/"i updates"/"it updates"
<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"?
<str1ngs>quiliro: not easily no
<quiliro>str1ngs: how is it possible the hard way?
<str1ngs>quiliro: maybe by using an external drive for the store
<quiliro>str1ngs: that sounds cool!
<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>i could run guix pull as user
<quiliro>but sudo -i guix pull gives error
<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?
<str1ngs>you have*
<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>str1ngs: i have nothing on root
<quiliro>please check my help-guix message. it is dark now and i have to go
<quiliro>thank you for the pointers
<quiliro>see you soon
<str1ngs>nighty night
<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>I'm growing to dislike lightdm...
<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
<PotentialUser-89>how can I overcome that problem
<Apteryx>PotentialUser-89: wrong channel?
<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.
<atw>(further guessing)
<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'll try to narrow it down...
<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.
<atw>why '20'?
<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>I'll use startx for now...
<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
<vagrantc>er, default desktop
<vagrantc>somewhere hidden in /usr/lib/
<Apteryx>can't find anything relevant there :/
<vagrantc>ACTION waves
<atw>" - no longer ship a .desktop file as already registered in the Debian menu" from 1.4.0.dfsg-1
<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>maybe lightdm does not use .desktop files to figure out what is available? The patch for I linked adds a .xsession file
<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>there is some info here:
<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>hello people!
<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>hello guix!
<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.
<civodul>oh, good catch
<g_bor>This causes the bootstrap ant build to be unreproducible.
<g_bor>Bug was reported by Chris.
<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
<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
<civodul>since we build with GCC 5
<efraim>we need gcc-4.9 for libstdc++-boot0
<civodul>ah, oh
<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>and the module and snippet
<civodul>ah, well, ok
<civodul>oh wait, i misread the patch
<civodul>you did what i had in mind in fact
<civodul>sorry for the confusion :-)
<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
<civodul>sorry for taking so long
<civodul>i should just get my act together
<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
<civodul>lemme see
<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
<civodul>(which is good enough for me)
<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>in my experience at least
<civodul>also, not all apps/toolkits honor it
<civodul>it's a mess
<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
<ng0>1 sounds good
<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>will do
<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?
<shiranaihito>i updated VMWare today and now that happened
<civodul>ACTION wonders whether we should remove the "ban" of texlive-texmf on hydra
<civodul>the source tarball is 2.2G
<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
<shiranaihito>is "4.x or later kernel 64-bit" correct for GuixSD?
<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 :)
<shiranaihito>(VM settings)
<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
<civodul>did you sleep well nonetheless?
<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>hmm yeah
<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>doable, but not trivial
<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>not great
<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?
<pkill9>ah nvm
<rekado_>civodul: I think I’ll mention the search-paths feature when introducing Guix HPC at the EasyBuild Users Meeting.
<civodul>sounds like a good idea
<civodul>pkill9: yes, see --with-graft
<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>I think there are
<civodul>ng0: julia for instance
<civodul>#:strip-binaries? #f
<ng0>or (delete 'strip)
<ng0>thanks :)
<ng0> <- should we add those new lines to our kernel configs?
<ng0>for example
<ng0>it's a mirror from jxself.
<ng0>would someone happen to be working on a package for botan?
<bavier>wine 3.0 out
<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 :-)
<bavier>nckx: cool ;)
<nckx>Rutger beat me to it. Must be able to build Wine in finite time. Cheater.
<rekado_>hehe :)
<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.
<amz3>azul.scm ftw
<amz3>ACTION hides
<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
<bavier>sounds fun
<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
<bavier>but yeah, Hurd work is cool
<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 ?
<rekado_>If you’re interested: here’s the video of the Hurd cluster talk:
<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.