IRC channel logs


back to list of logs

<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 nods
<madage>catonano: no, i'm not
<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: , though it does mention make-flags
<civodul>Hello Guix!
<kmicu>( ^_^)/
<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
<civodul>it's not me, i swear :-)
<civodul>you're very welcome to fix it tho
<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
<civodul>heheh :-)
<efraim>then would be the license: prefix for everybody
<efraim> score one for armhf
<g_bor>hello guix!
<janneke>hi g_bor!
<roptat>hi guix!
<g_bor>hi janneke!
<g_bor>hi roptat!
<civodul>hi all!
<g_bor>roptat: I'm thinking about how to get these geo stuff rolling.
<civodul>roptat: BTW did you see ?
<roptat>ah yes, we need some services
<roptat>civodul: ah yes, thanks for that :)
<jonsger>civodul: would it make sense to create a test for "make check" which tests if all patches used are in gnu/, to avoid bugs like ?
<civodul>jonsger: yes, definitely
<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>yes, that is right
<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>jonsger: yes
<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=" 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
<g_bor>yes, that is fine :)
<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 as an authorized server
<g_bor>Another crazy usecase where I could use some workflow magic is live-migrating postgresql.
<roptat>please explain
<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?
<g_bor>yes, that is 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?
<roptat>I don't think so
<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>If I got it right.
<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>Hello guix!
<g_bor>I'm back.
<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.
<fps>civodul: a little writeup that's still messy and still misses the last part ;)
<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)
<roptat>swedebugia: I'd go with 2
<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>roptat, what do you mean go with 2?
<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
<bavier`>sorry for the noise
<civodul>fps: thanks for the writeup!
<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
<swedebugia> (fold-packages
<swedebugia> (lambda (package lst)
<swedebugia> (if (string-prefix? "python"
<swedebugia> (package-name package))
<swedebugia> (cons package lst)
<swedebugia> lst))
<swedebugia> '()))
<pkill9>i can't find where i read it
<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>anyways ipfs is neat
<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
<fps>pkill9: ok
<madage>catonano: you may tell this person that I've successful compiled gnutls with the patch jonsger proposed
<jonsger>catonano: what's broken?
<catonano>madage: I did already . I poined them to the ticket on Gitlab I saw here, they were happy
<catonano>jonsger: Here's the part of the thread that you can read publicly
<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?
<Swedneck>i'm at step 4 in, should i just follow the linked guide?
<fps>Swedneck: assuming you're on a linux system that's probably a good idea :)
<Swedneck>yeah, fedora 29 (in a virtual machine)
<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>fps, do you know how match works?
<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..