IRC channel logs


back to list of logs

<Tsyesika>has wireless got any better in guixSD yet?
<Tsyesika>last time i was around it was a bit of a pain point
<mark_weaver>we have wicd. works well enough for me.
*Tsyesika nods
<mark_weaver>how to set it up isn't well documented though.
<mark_weaver>basically, replace (dhcp-client-service) with (wicd-service) in the OS config, add 'wicd' to 'packages' and to the list passed to 'dbus-service', and add "netdev" to the list of supplementary groups of all users that should be allowed to mess with the network configuration.
<mark_weaver>and then use wicd-gtk or wicd-curses to configure.
<mark_weaver>xfce will automatically run it, and put a little icon in the tray on the panel.
<mark_weaver>gotta run, good luck!
*mark_weaver goes afk
<Tsyesika>errr right
<Tsyesika>actually that doesn't sound too too bad
<angelic_sedition>Does the GuixSD config file have a setting for console keymap as one would load with loadkeys or put in the vconsole.conf? I didn't see anything in the manual.
<mark_weaver>not yet, but we should probably have something like that.
<angelic_sedition>Thanks, also is there a default password for users specified in the config file when running the vm created with "guix system vm"? I can log in as root, but for a user it asks for a pass.
<mark_weaver>run "passwd <username>" as root if you didn't set the password in the config
<angelic_sedition>Okay, thank you
<paroneayea>hey davexunit
<paroneayea>I have some thoughts about guix environment when you're around
<davexunit>hey paroneayea
<davexunit>what are your thoughts?
<paroneayea>hey davexunit
<paroneayea>so today after dealing with yet another nightmare of python packaging dependency flailures I started thinking
<paroneayea>I wonder if I should commit a package.scm with mediagoblin. I mean, really, you could say "It's showing GNU solidarity"
<paroneayea>in order to really have Guix be an alternative to our virtualenv + bower madness
<paroneayea>a stage beyond what guix environment provides would be needed I think... for the javascript stuff.
<paroneayea>basically, it makes most sense for the package probably to have symlinks to say, jquery
<paroneayea>that way we can have just one directory for all the static assets that's statically served, right?
<paroneayea>so, assume i also want to have an alternative to not just virtualenv, but also bower here
<paroneayea>how could I do that, assuming this is for hacking
<paroneayea>get symlinks to guix-packaged javascript packages
<paroneayea>or for that matter, discoverability of where they are at all
<davexunit>paroneayea: I've thought about this, but I'm not sure how to do it right now.
<davexunit>I'd like some sort of bower build system
<paroneayea>davexunit: yeah.
<davexunit>but I don't know of a way to "play nice" with the bower workflow
<paroneayea>davexunit: so one option is, is there a way to provide something for the guix environment command to run something after the fact, maybe with the same inputs
<paroneayea>but instead, it runs in the current directory
<iyzsong>To let guix manage a assert directory just like profile, right?
<paroneayea>as some kind of "do some stuff *in this directory*" setup
<davexunit>iyzsong: maybe
<davexunit>but I don't *really* like it
<paroneayea>maybe a gexp?
<davexunit>ideally there'd be a JS_LOAD_PATH or something
<davexunit>with a bunch of paths to the JS libs
<paroneayea>davexunit: well what if the packages were just inputs
<davexunit>I don't know how bower actually does shit
<paroneayea>and you had a command run after the environment is built
<paroneayea>so in your scheme could say "oh yeah, here's these inputs... I know where to symlink in this js"
<paroneayea>or something
<paroneayea>there's a problem with that idea though
<paroneayea>what if the symlinks were set up on a previous run?
<paroneayea>it starts to get pretty imperative
<paroneayea>since you might conditionalyl remove things that are there
<paroneayea>but I can't think of any other way
<davexunit>I feel like there needs to be an environment variable or something
<paroneayea>davexunit: maybe... so your script could look at that environment variable and use that to do the symlinking in itself?
<paroneayea>and have some post "guix environment" command you give to users
<davexunit>well at that point it would just be part of the build system
<paroneayea>like "guix environment && ./"
<paroneayea>davexunit: yeah but it needs to get linked *into* the package, right?
<paroneayea>into the dev directory.
<davexunit>I really don't know
<davexunit>I need to learn more about bower does
<davexunit>just making packages for js libs that does the necessary compilation and minification is easy enough
<paroneayea>davexunit: think of it this way
<davexunit>but how to serve them... dunno
<paroneayea>well, so people currently either commit the files into their repo (bad!)
<paroneayea>or they use bower, which basically does checkouts
<davexunit>I do that
<paroneayea>into the directory.
<davexunit>I don't do that
<davexunit>okay, so bower does about what I expected
<paroneayea>it's maybe better than checking things in, but now you have n+1 language package managers
<davexunit>the question I want to answer is: how to setup js files in a way that doesn't make every developer use guix?
<angelic_sedition>Can you specify packages to be installed for a specific user in the config file?
<davexunit>angelic_sedition: no, those are managed separately
<davexunit>since there's no reason to require full system reconfiguration just to tweak a user profile
<davexunit>a user may have an arbitrary number of profiles, as well
<iyzsong>angelic_sedition: well, I use this (manifest.scm):
<iyzsong>And then run 'pre-inst-env guile build.scm', (build.scm):
<davexunit>iyzsong: we should have a tool dedicated to this sort of thing
<angelic_sedition>what is pre-inst-env?
<angelic_sedition>ah nvm I found it in the manual
<davexunit>angelic_sedition: iyzsong assumed that you were running guix from the source tree
<iyzsong>davexunit: yes, but I don't know what to name it :-)
<davexunit>iyzsong: always tough :)
<paroneayea>davexunit: I think the answer to that question is that's why the symlink in stuff to the user's profile
<paroneayea>that way someone can still use bower
<paroneayea>this optional post-environment-setup hook would probably have to be not really as clean and functional as the rest of guix's packaging stuff since it's modifying symlinks in the environment
<paroneayea>but hey, it's just for local dev
<paroneayea>and I think it could be an optional layer to guix environment
<davexunit>I just don't think guix environment is the right place for it
<paroneayea>guix post-environment ;)
<davexunit>if there are no environment variables to set, there's no reason to include them in the environment
<paroneayea>davexunit: so where to include it though?
<paroneayea>I mean really, it seems like the right palce from a "replace virtualenv+bower" side of things
<paroneayea>just not from a guix design side :)
<davexunit>needs more thought.
<davexunit>my first attempt would be: create an environment variable called JS_PATH or something, have configure script search that for absolute paths to JS files and symlink as needed to the directory that assets are served from
<paroneayea>davexunit: maybe it actually belongs in guixops ;)
<paroneayea>davexunit: I think it's unrealistic to expect many projects in the space that are using bower to use configure
<paroneayea>but otherwise probably
<davexunit>substitute 'configure' for any script
<paroneayea>davexunit: also, it's not just JS though
<paroneayea>it's also CSS, common assets including icons
<davexunit>it would be a matter of trying to encourage people to treat JS libs like C libs and have a path
<davexunit>there's that stuff, too.
<paroneayea>one reason bower is popular is that it encourages users to use one package manager for all that crap
<paroneayea>and not have to *think* about where to fit it.
<davexunit>but they still have to be aware of where the files end up and where to serve it from
<paroneayea>davexunit: I know ;)
<paroneayea>I found the answer!
<paroneayea>let's store paths to the proper packages as json encoded hashmaps
<paroneayea>WEB_BULLSHIT={"jquery": "/home/cwebber/.guix-profile/share/js/...."}
<paroneayea>so fitting
<davexunit>there's got to be a way to do what bower does in some not disgusting way
<davexunit>but I think there's a bigger issue present here: web apps are weird. you never actually install them to the root file system or anything. you just bundle all the dependencies in the source tree and run it from there.
<davexunit>it's hard to deal with things that are built to not integrate with the rest of the system
<davexunit>my rule of thumb is "if it's a package manager, then guix can replace it", but bower is indeed tricky.
<davexunit>npm, too.
<davexunit>npm hopefully less tricky
<davexunit>provided nodejs has a sane load path thing
<paroneayea>davexunit: though solving bower + NON_JS_PACKAGE_MANAGER might be the best selling point for "guix environment"
<paroneayea>er, solving that problem space, but with guix instead as an all-in-one
<davexunit>yeah, I would like to do that
<davexunit>needs more thinkin'...
<davexunit>that and guix ops
<davexunit>need to hack together a prototype
<davexunit>so many hacks to hack
<paroneayea>davexunit: I indeed look forward to guixops :)
<davexunit1>would there be any issue with including a video game emulator in the distro, provided there are no blobs required for the emulator to work?
***Digit_ is now known as digitteknohippie
***digitteknohippie is now known as Digit
<taylanub>davexunit: you mean e.g. Mupen64 (N64 emulator)? why not?
<joolean>I'm trying to test the build for a new package, and I'd like to do so in a "pre-installation environment" if I can. HACKING suggests that I run './pre-inst-env guix build PACKAGE'
<joolean>but when I do that, I get "guix build: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory"
<joolean>What gives?
<taylanub>joolean: it sounds like you didn't run the guix daemon, or you used a --prefix option for the guix you built which doesn't correspond to that of the guix installation whose guix-daemon you're running
<taylanub>joolean: does /var/guix/daemon-socket exist?
<taylanub>(without /usr/local in front)
<joolean>taylanub: For sure - but I guess what I'm getting at is that it looks like at the very least I have to run guix-daemon as root, if not make install it outright
<joolean>Like, is there a pre-install way to create that socket?
<joolean>I guess I could re-configure with a different prefix
<taylanub>the daemon seems to have a flag: --listen=SOCKET but I don't know what the corresponding client flag is
<taylanub>joolean: in any case, guix-daemon is primarily meant to run as root so it can populate the global /gnu/store
<joolean>Okay, that's fine. Just wanted to make sure I wasn't missing something.
<joolean>Thanks for your help/
<taylanub>np :)
<Tsyesika>hm my keyboard doesn't work in guix O_o
<jmd>Building from git, I have this error: ice-9/boot-9.scm:106:20: In procedure #<procedure 2859b40 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
<jmd>ice-9/boot-9.scm:106:20: No variable named make-delimited-input-port in #<directory (web response) 2bce240>
<Tsyesika>i will try with trisquel to check it works in there (so i know for sure it's not some blob) but i think it's regular internal usb
<paroneay`>davexunit: even though Wine Is Not an Emulator, I think that's not far off from allowing something like Wine.
<paroneayea>in other words, I think it should be included
<paroneayea>at the very least, the people who hack emulators turn out to be the kind of people we want in free software, as that's a similar skillset to that which allows reverse engineering :)
<cehteh>the part that some free projects aim to clone some non free stuff than beeing innovative and creating something new is what annoys me quite much tough
<taylanub>jmd: I think you need a newer Guile version. (might want to file a bug report so the pkg-config file gets fixed to declared the higher version requirement.) a good way to build guix, if you already have another version installed, is: guix environment guix -E './configure --with-libgcrypt-prefix=/gnu/store/...-libgcrypt-...; make'
<paroneayea>cehteh: I'm talking about drivers though
<cehteh>yes, thats ok then :)
<jmd>taylanub: and if I don't already have another version installed?
<taylanub>jmd: then you'll need to install a newer guile version manually
<cehteh>well ok would be to choose vendors which release specs and support free drivers from the beginning
<jmd>oh dear ....
<taylanub>jmd: or you could use our new shiny "bootstrap" tarballs to easily install guix
<taylanub>jmd: (I'm assuming you're on e.g. Debian stable where the newest Guile version doesn't seem new enough)
<paroneayea>cehteh: the free software user is left with a poverty of options, there
<paroneayea>though that would be a better future
<paroneayea>Tsyesika: super weird re: usb keyboard
*paroneayea has not tried guixsd yet tho
*cehteh goes binding the manual ... chances are good that i get used to gsd, just for testing in a vm now but maybe for real use someday
<cehteh>debian becoming too much of a kindergarden over the years
<paroneayea>I love Guix, but I still also love Debian :)
<paroneayea>so davexunit, further thoughts on guix as a universal virtualenv:
<paroneayea>except for the stuff used in npm, probably *most* of the javascript can be in the same place that css, fonts, etc are
<paroneayea>maybe a WEB_ASSETS_PATH, or something
***drewr- is now known as drewr
<cehteh>oopps .. how do you shutdown the install system? :)
*cehteh should go rtfm
<alezost>cehteh: halt
<cehteh>haha tried shutdown and poweroff .. :D
<paroneayea>okay, trying to rewrite minikanren compile step using the gnu-build-system
<taylanub>mark_weaver: where would I copy the Mesa headers in the Qt build?
<mark_weaver>some directory in /tmp
<mark_weaver>cehteh: halt
<mark_weaver>oh, already answered...
<taylanub>do we have an equivalent of 'mktemp -d' or should I use 'tmpnam' and 'make-directory'?
<paroneayea>mark_weaver: I'm trying to go the gnu-build-system route
<paroneayea>I have to admit that I'm pretty confused as to the right way to do it...
<paroneayea> seems to not be the right way after all :)
<paroneayea>but I'm not really sure.
<paroneayea>ERROR: In procedure memoize-variable-access!:
<paroneayea>ERROR: Unbound variable: gnu-build
<paroneayea>it seems like set-paths is the only other phase I really need...
<paroneayea>oh wait
<paroneayea>I think I see.
<mark_weaver>paroneayea: paroneayea I think you should use 'modify-phases' and delete all the phases you don't want.
<mark_weaver>instead of selecting the ones you think you need.
<mark_weaver>IMO, anyway.
<paroneayea>mark_weaver: okay, I'll try that
<paroneayea>seems like a lot of phases to delete.... :)
<mark_weaver>well, whatever, either way is fine I guess
<cehteh>oops, what network hardware do i choose for gsd in a kvm?
<cehteh>.. or wtf does it rename network interfaces to ensX
<rekado->cehteh: that's a feature of eudev.
*cehteh feeling old
<cehteh>well then the documentation about 'dhclient eth0' seems to be out of date
<_`_>“net.ifnames=0” in the kernel commandline should revert to the interface names you're used to.
<cehteh>after i know it i dont mind, just thinking about the documentation out of sync and poor discoverability
<cjbarnes18>evening all o/, could use some help getting wicd up and running.
<Tsyesika>so i checked and my keyboard does not work at all in guix's SD image
<mark_weaver>cjbarnes18: replace (dhcp-client-service) with (wicd-service) in the OS config, add 'wicd' to 'packages' and to the list passed to 'dbus-service', and add "netdev" to the list of supplementary groups of all users that should be allowed to mess with the network configuration.
<Tsyesika>it does work in trisquel though so it's definitely not reliant on any blobs
<mark_weaver>and then run 'wicd-gtk' to configure the network.
<cehteh>Tsyesika: usb keyboard?
<mark_weaver>'wicd-gtk' will be run automatically within xfce, and add a little icon in the tray on the panel.
<cjbarnes18>thanks mark_weaver
<Tsyesika>yep it's internal usb on my laptop
<mark_weaver>I know that I've tried USB keyboards in the past, but I don't have one with me right now to try...
<Tsyesika>i can plug external usb keyboards and it works fine
<Tsyesika>but the internal laptop one does not, it is a usb one though as it shows up in lsusb
<mark_weaver>hmm, maybe we are missing some boot time step to configure USB things that was present from early on.
<cehteh>some time ago the kernel introduced a usb module (forgot what its name was), i had problems too that usb keyboards where not useable in the initrd because that module was not part of it
<Tsyesika>mark_weaver: but like i said, if i plug in a usb keyboard it works
<Tsyesika>it's just my laptops
<cehteh>thats it, dunno if thats related to your problem
<mark_weaver>Tsyesika: can you email about it?
<mark_weaver>I guess it's something udev-related.
<mark_weaver>Tsyesika: is the problem in text-mode only, or X11-only, or both?
<Tsyesika>text-mode, i've not started x11
<Tsyesika>i can't install it without this being fixed
<mark_weaver>understood, just trying to gather information
<Tsyesika>no problem
<Tsyesika>thanks for your help
<mark_weaver>if you add (slim-service) to the 'services' section of your OS configuration, then it should automatically launch X at boot time, and it might just work.
<mark_weaver>and that would be useful information.
<Tsyesika>i shall do that
<paroneayea>I see what I did wrong
*paroneayea smacks forehead
<paroneayea> OMG
<paroneayea>that looks GREAT
<paroneayea>can we haz
<paroneayea>(sorry for the lolspeak lapse)
<cehteh>can one pass a parallel (-j ...) build option at installing gsd (searching the docs only showed offloading and parallel builds on other machines)
<taylanub>cehteh: you mean while building guix? should work fine.
<cehteh>installing gsd
<taylanub>I haven't tried out GuixSD yet but I don't think 'make' is involved in any way?
<cehteh>building a lot stuff locally but seems to use only one core
<cehteh>whatever build system things use
<taylanub>when the guix daemon is building things, it will adhere to the package recipes. most package recipes should use parallel building (it's enabled by default and a recipe has to disable it explicitly if it causes issues)
<taylanub>cehteh: Guix is a package manager at core; the distro is mostly built around it
<cehteh>ah i see now
<cehteh>when i checked it just ran on something which prolly intentionally was -j1
<mark_weaver>the build phase of our 'gnu-build-system' passes -j<N> to 'make' by default
<mark_weaver>where <N> is auto-detected, or whatever N you pass in via --cores=N when running 'guix' subcommands that accept build options.
<cehteh>is everything build from source? i havent figured that out yet, thinking about nix which can fetch binary packages..
<mark_weaver>no, we support tranparent binary deployment, via our build farm
<taylanub>cehteh: you have to authorize for "binary substitutes". guix archive --authorize <
<mark_weaver>for x86_64, i686 and mips64el anyway. not yet armhf
<mark_weaver>we haven't yet procured a decent armhf slave for our build farm.
<cehteh> is where?
<mark_weaver>in the top-level source directory
<mark_weaver>well, how did you install guix?
<cehteh>i am using the gsd install image
<cehteh>thats sda1 in a kvn, installing on sdb1
<cehteh>the docs should be on some wiki then one could easily add these things here :/
<cehteh>(is there any wiki which can use texi as backend?)
<cehteh>.. that one :)
<cehteh>now: how do i stuff that into the VM :D
<cehteh>no copypaste, no wget, no curl, no fetch .. wtf
<cehteh>ah found it locally :)
<mark_weaver>there's a 'guix system vm' command that builds VM images plus a script to run them properly.
<mark_weaver>using qemu/kvm
<paroneayea>mark_weaver: btw, what's better for the compiled files
<paroneayea>.scm.go or .go
<cehteh>other way around . .i am on debian and trying gsd in a vm
<paroneayea>in the guile-minikanren package
<paroneayea>okay great
<paroneayea>thx )
<paroneayea>thank *you* for all your help, mark_weaver
<mark_weaver>you're welcome :)
<mark_weaver>cehteh: right, so build 'guix' from the tarball release, 'guix pull' and then 'guix system vm ...'
<cehteh>mhm i am just trying to get the install running following the manual
<mark_weaver>or you could use the spiffy new bootstrap tarballs, which are rather binaries of the subset of /gnu/store needed for the 'guix' command.
<cehteh>isnt that what i try?
<paroneayea>okay wooo, submitted.
<cehteh>guix system init ...
<mark_weaver>cehteh: oh, I see. you're trying to run our standard install image within a VM on Debian.
<cehteh>... now when it fails to fetch somthing it aborts, guix build has a --fallback option, but where do i configure that for the system init?
<mark_weaver>do you have working networking to the outside world from our installer shell?
<cehteh>yes some packages are working
<cehteh>seems to be transitent network errors or timeouts or so
<mark_weaver>that does sometimes happen when our build farm is overloaded. we're currently working on replacing the build farm master machine.
<cehteh>i would be fine when i could configure a retry/timeout or the fallback option for the build rather than aborting
<cehteh>well now it looks like it works
<cehteh>if i get this working maybe i can donate some webspace in future for mirroring this stuff (some torrent like protocoll would be awesome for this too)