<vagrantc>doing it kind of sloppily, though ... guile-zstd has botht he guile-2.2 and guile-3.0 stuff ... because i don't want to deal with the administrative overhead of doing versioned package names ... this is the sort of thing way nicer in guix :)
<vagrantc>mostly for beurocratic reasons ... e.g. waiting for NEW review when you add a new binary package
<leoprikler>mroh: There's probably a long way to go still, given that it's built on Electron
*vagrantc sighs waiting for linux-libre builds on aarch64
<vagrantc>this is one package i really wish i could reliably get substitutes for...
<vagrantc>ok, my tests of guix from debian experimental went ok, now building and going to upload to debian unstable and will hopefully land in bullseye in ~10 days ... and make it into the next debian stable release :)
<sturm>mroh: yes, confirming that it's the same issue - installing the User Agent Switcher add-on for IceCat allows me to access gitlab.com. rekado_: I found your mention of this in the December IRC logs - just FYI in case you hadn't resolved that
<nixo_>I moved to define-foreign-object-type as you suggested, added doc generation and started adding more of the missing bindings when I saw the changes in your repo. When I have some time I'll rebase, I've been busy those days. I'll try to do something today
<leoprikler>Ahh, my bad, it appears I've inadvertently caused you extra work.
<katco>leoprikler: well, maybe? but with the diversity of the internet, they are bound to return things my simple line matcher doesn't expect. the first of which was a meta tag spread across multiple lines.
<civodul>lfam: i'll see if i can upgrade my user profile to begin with!
<lfam>Go is kinda hard to handle from a packaging perspective
<lfam>Every time I thought "it can't be like that", it turned out to be like that
<joshuaBPMan>civodul May I ask what a good use of libvert would be?
<lfam>Sometimes it's easy to fall into the pattern of thinking that something isn't correct so we shouldn't support it. But if the person writing the code aims to support some messy inputs, it's worth thinking of how to help them, especially since they probably have a more complete understanding of the problem space
<civodul>joshuaBPMan: i don't know :-) but i think it has to do with managing typically swarms of VMs
<lfam>There is definitely a "happy path" for Go dependencies, but I found a lot of cases where it didn't work, and we had to work around things
<lfam>Now, Go dependencies have been overhauled upstream, and we have to start ironing out the wrinkles all over again
<lfam>I had basically the exact same experience as this conversation, where other Guix hackers were like, "It can't be! You don't need to do it that way." But it did have to be that way. It's frustrating
<jackhill>Is there a guide from migrating from monolithic texlive to the modular package? I guess I'll have to figure out all the dependencies I need by seeing what can't be found, but which package should I start with?
<katco>lfam: yes, i am particularly upset that proxy.golang.org doesn't serve all the needed info, and the way to get that data is to go pull down html. i do not love the proliferation of markup languages, but more ecosystems have json/yaml parsers on hand than full-on html parsers.
<lfam>If libvirt is not supposed to be required for gnome-boxes, you could at least try it and see if it works, and then we could poke around figure out what the libvirt service is doing that makes gnome-boxes work
<avalenn>katco: if you find a way to do it I would be glad. I am stuck with meta tag too.
<lfam>Ideally, we can make it so the gnome-boxes package "just works". If that's not possible, we could add a section to the Guix cookbook
<katco>avalenn: the only options i see are (1) perhaps the `.info` endpoint will begin returning that info someday (2) we could take the stance that the go importer creates packages that fetch from the proxy server specified by `guix import go`, but that seems bad.
<katco>sorry, packages that fetch the code from the proxy server
<katco>avalenn: yeah. but since it's the wider internet, i think we want as robust a parser as possible to handle weirdness.
<avalenn>Specifically : "The <meta> tag should appear early in the document to avoid confusing the go command's restricted parser. "
<katco>i think sxml might be sufficient, but i don't know
<katco>i'm trying to implement that now. maybe i will take civodul's suggestion and just do the dumb, easy, thing and parse the entire document and pluck the sexp out. i would rather use `ssax`, or something written specifically for html.
<jonsger>lfam: you are right, the node issue is due to third party repo which uses node 10.22 as node-10.22
<jonsger>so sadly I can not test staging, but I hope for the best :)
<lfam>Perhaps something else will break, but this part should work
<mhj[m]>Hi all, new to Guix, although I run NixOS on my laptop currently. Anyways, all I want to do to get started is to be able to run sshd in its default state by reconfiguring the system. It’s just oh the home network. I’m very new to guile(unless it’s the street fighter one), and only have experience with python and c++. I’m a super n00b and want to learn more tho!