<tune>did qutebrowser ever get fixed? I uninstalled it since it was broken for so long <tune>it seemed like only a couple people used it so it was low priority or something ***jonsger1 is now known as jonsger
<jackhill>tune: I'm not sure if it got fixed, but I think the difficulty was not just the popularity, but packaging qtwebengine (i.e. chromeium). <jackhill>hmm, so can I install GuixSD to a disk wile running Guix on a foreign disto, as opposed to using the install media? <tune>it should still work with webkit <tune>last update had just broken it and it stayed that way <jackhill>tune: ah, I don't know then. I just remember there being long browser threads on the lists :) <jackhill>I'm still playing with Icecat an tridactyl <tune>I think some were considering getting it to work with webengine to be more future-proof or something <tune>I'm using icecat and vim vixen <tune>but post-webextension firefox vim addons are crap <tune>they don't work on all pages, there's a delay as they load <tune>a page can steal input so that you can't use the vim bindings <jackhill>and to answer my question about installing directly using guix on a foreign distro: guix system disk-image is probably the way to go. ***rekado_ is now known as rekado
<catonano>madage: oh ok. There's someone on Mastodon who was struggling with building GnuTLS too and the sympthom seemed to be similar to yours <catonano>madage: so I thought you were the same person <noobly>the other day I was on here asking about guixSD having any system wide declarations for building packages, similar to what gentoo has with use flags.. Someone responded with something interesting, but I can't seem to find again. I know it had to do with "graph" of some sort, and I don't think it's this article: https://www.gnu.org/software/guix/blog/2018/a-packaging-tutorial-for-guix/ , though it does mention make-flags <jonsger> .3% Substitute verfügbar (25 von 9.144) :) <efraim>civodul: my dictionary would like to have a word with you, "pha" comes before "pho" in gnu/local <efraim>if I let that bother me too much I'll end up trying to line up the backslashes <efraim>off-by-one is good enough for now <efraim>then would be the license: prefix for everybody <g_bor>roptat: I'm thinking about how to get these geo stuff rolling. <roptat>civodul: ah yes, thanks for that :) <roptat>g_bor: I've been experimenting with tegola and imposm, so I might be able to write a service for them <civodul>jonsger: maybe you can send that suggestion as a wishlist to bug-guix, so we keep track of it <roptat>for imposm though, you need to import a first version of the database (planet or smaller parts), which takes a long time, then you can run it to automatically load and apply minutely diffs <g_bor>It seems to me that it would be nice if I could create a service-like thing, that populates the database from a current os extract, but is only run on instance creation. <g_bor>The same for most of the stuff. <roptat>that's what an activation service does I think <roptat>but it's going to run for a very long time <jonsger>civodul: I try to have a look at the weekend first :) <g_bor>Also, most of the updaters erode the database. <g_bor>We currently have a workflow like we periodically spin up a new vm instance, reimport the databes, then redirect the traffic to the new one, dropping the old. <roptat>that sounds crazy, why do you need that? <dvn>Helping a friend follow the installation instructions from the manual for the Binary Install. Everything has been good so far, but we're near the end and it's time to "guix package -i glibc-utf8-locales" and it has just been sitting with no output for about 10 minutes <g_bor>We currently update a postgis database using osm2pgsql append. <dvn>I've tried setting the --verbose option, but no change. <g_bor>This leads to a constanct grow of the db size. <g_bor>No thing is ever deleted from that. <roptat>ah, so deleted objects in osm aren't deleted from your db <g_bor>it seems to me that an activation service would run on reboot, wouldn't it? <roptat>dvn: is it doing something (cpu, io, ...?) <jonsger>g_bor: you working at work with osm? <g_bor>But we are only experiment with guix there. <jonsger>oh nice, I'm just a tiny, little mapper :P <efraim>dvn: the hydra substitute server is down, make sure you've authorized the berlin server and add "--substitute-urls=https://berlin.guixsd.org" to the end of your guix command <g_bor>dvn: We had some problems with --verbose recently. <g_bor>I don't know if that has been corrected. <roptat>g_bor: we could detect the presence of the database and not run the initial import at every reboot <g_bor>roptat: I've been thinking along similar lines, but don't know what would be the best way to do that... <roptat>if you wanted to re-import everything, you would just rename the database in the config.scm, and that would be detected <roptat>but I'm also wondering how to implement something like that <civodul>rekado: we missed the FOSDEM HPC devroom CfP deadline :-/ <g_bor>I guess we could just list the databases... <roptat>it's very similar to an initial import for a web service (we have pootle but I think it's broken), and migrations when the service is upgraded <g_bor>I mean by querying the server. <roptat>so we could have something common to both cases <dvn>ah thanks efraim and g_bor - I guess --verbose just wasn't working. It finally started the fallback and downloading the sources. I had forgotten to add berlin.guixsd.org as an authorized server <g_bor>Another crazy usecase where I could use some workflow magic is live-migrating postgresql. <g_bor>It is not possible to simply configure a wal replica when migrating between version. <roptat>ah, when upgrading postgresql itself <g_bor>We usually start a new cluster on the new version, and set up slony and make the new cluster a replica. <g_bor>That way we can avoid this limitation. <roptat>that's the limit of my knowledge about postgresql <g_bor>When the new one catches up we can failover, and drop the old one. <roptat>I have no idea how guix could help you with that <roptat>we don't really have tools to manage multiple machines at the same time <g_bor>This currently involves 3 reconfiguration even when done on the same machine. <g_bor>Last Guix Days we discussed stuff like that with Cris, and it seems to me that it would be natural to go towards a direction when we can manage multiple machines. <roptat>mh... and you probably can't roll-back that configuration, right? <roptat>so we loose most of the advantages of guix with this issue... <g_bor>Sometimes you don't have the capacity to roll back, even if you could... <g_bor>Also the managing multiple machines stuff has to solve serious problems with consistency... <roptat>sure, but that'd be great to have :) <g_bor>I currently have a very basic workflow, I keep config files in a repo, when I change something, the provisioner copies the new configs over scp, then ssh-s to the machines and reconfigures them. <g_bor>Most of the times this work fine... <g_bor>This is a very small deployment, about 10 machines. <g_bor>Update ordering is kept track manually, and we don't really have the tooling to check if we were successful. <g_bor>Does GuixSD provide a way to get the last successful configuration? <roptat>you can list the system generations, if that's what you mean <g_bor>roptat: I know that, but can we extract the infomation from that how it was generated? <g_bor>I believe that might be useful... <g_bor>For example it could enable to regenerate the system on another machine. <g_bor>It would also enable us to inspect the differences between generations. <janneke>g_bor: what do you need besides profile/etc/manifest? <g_bor>janneke: I will have a look a that <g_bor>janneke: I have the following porblems with etc/mainfest: <g_bor>It is really a full package description, an os config file with the guix commit specified can be much more compact. <g_bor>And it misses all other configuration information, like mount point, filesystems, users... <g_bor>But it does not seem to hard to simply provide something like /etc/current-config, in the same spirit as a manifest <g_bor>I mean profile/etc/current-config, for system profiles. <roptat>g_bor: I'm thinking about something: we could extend the postgresql service with a structure like (db-name, activation-thunk, migration-thunk) <roptat>postgresql's activation service would check whether db-name exists, if not create it and run activation-thunk, and then run migration-thunk <roptat>these thunks would take keyword arguments like #:db-name and #:postgresql, and return a gexp <roptat>ah, not sure if that would work actually <roptat>if it does, it probably solves the two use-cases I mentionned <roptat>but not the live-migration issue <g_bor>actually the live-migration issue is missing some abstraction not present in guix yet. <g_bor>But solving the first two problems would already be nice. <g_bor>I mean that we mainly stuck with the workflow and the multi machine stuff, because we were not sure that we have working abstractions for that. <g_bor>I was thinking along the lines to create some equivalence relations. <g_bor>My network seems to be not very stable :) <efraim>Sounds like you need an irc bouncer <fps>jonsger: well, i only started leeching the builds from berlin yesterday ;) i don't know what amont to expect to be available really.. <fps>so everything that has not been changed/rebuilt since then is not available. <swedebugia>Installed the desktop-config on my i686 test machine yesterday. It took some hours in total but it was a well working system that greeted me in the end :) <sneek>swedebugia, you have 1 message. <sneek>swedebugia, ArneBab says: Do you mean similar to this? (define-syntax-rule (comment ignored ...) (list)) (display `(test ,@(comment this is never seen outside))) <swedebugia>Some points to take from my experience: 1) binaries for 0.15 was not found on either hydra or berlin. <swedebugia>2) the mirror was down and this was not clear from running guix command (just took a long time doing nothing instead of telling me that it had a hard time reaching the mirror) <swedebugia>Picking a reasonable commit id to feed the guix pull before guix build was hard from the installer because both wget and lynx and curl triggered a lot of builds. <swedebugia>Essentially I would not recommend to try to install guixsd without a second device with internet access. <swedebugia>The commit I picked was not build by berlin so the installation took some hours, mostly building guix on a 2 core 1,8Ghz celeron laptop. <swedebugia>ArneBab, is that syntax rule able to let me produce a (package record with some inputs commented out? <swedebugia>I would like to build all node- packages in my node.scm. Is fold-packages the right proc to build that list? <bavier`>swedebugia: you could use 'fold-module-public-variables' from (guix discovery) <bavier`>fold-packages goes over all packages available to guix; though I guess you could filter out just your node- packages <bavier`>swedebugia: or 'find-packages-by-name' <bavier`>swedebugia: oh, actually, I just discovered 'fold-packages' has a "modules" optional argument <civodul>i hope we can make a 'guix publish' hook to write the bits together <civodul>you should email guix-devel if you haven't already! <fps>civodul: nah, i'm not signing up to email lists ;) i'll let you know when i have finished the last part,,, <civodul>you don't need to subscribe to post, but either way is fine :-) <pkill9>i don't like that ipfs wants to rely on namecoin for ipfs domain names <fps>pkill9: is that mandatory? <pkill9>lemme check, i'm pretty sure it's not, but they wrote that they plan to use it <swedebugia>bavier, thanks! I found this in the manual (define snakes <pkill9>they probably aren't planning on relying on it then, i get the impression from looking around that they'll probably add support for different naming systems <pkill9>oh i found where i read it, it was on a blog and it only said they plan on supporting namecoin <pkill9>some other blog not associated with ipfs <madage>catonano: you may tell this person that I've successful compiled gnutls with the patch jonsger proposed <catonano>madage: I did already . I poined them to the ticket on Gitlab I saw here, they were happy <jonsger>oke fine as I don't have Mastadon/GNU Social... <swedebugia>bavier, emacs-guix is so nice. I just selected them all in the list generated by guix-search-by-name. <bavier`>swedebugia: ahh, seems nice indeed. I've not used emacs-guix much yet <swedebugia>bavier`, all the 36 node- packages built and I finally understood how the build system works when they dont :D <fps>hmm, it seems my mail doesn't show up in the guix-devel archives.. oh well.. <rekado>fps: it may need to be approved first <ngz>I have a question about Go packages. Some of them bundle stuff in a "vendor/" subdirectory. Is it enough to provide some of the bundled stuff as `native-inputs' to un-bundle it? <fps>Swedneck: assuming you're on a linux system that's probably a good idea :) <fps>oh i see. when i mentioned installing in a vm i thought of the complete guixsd :) <fps>but you can of course install just guix ontop of another system, too.. <fps>following the guide should be relatively painless.. <fps>this channel is rather quiet at night in europe [now] <Swedneck>yeah i want to try guix on fedora, so i'm testing in a VM first <Swedneck>it was extra quiet when the matrix-irc bridge didn't tell me it wasn't bridging my messages :P <swedebugia>i'm trying to iterate over a blacklistlist and see if a package matches. <swedebugia>e.g. npm import async -> needs "tape" which is blacklisted <swedebugia>there is very little examples and documentation of the match and match-lambda and none where matching against a list is done. <Swedneck>so how well does guix work ontop of other package managers? <bavier`>Swedneck: pretty well, I've used it that was on a couple of my systems for quite a while <Swedneck>i'm a bit worried about distro specific things though, guess i'll just have to see how the VM fares <fps>swedebugia: match, as from guile scheme? <fps>this goes into matching over lists..