IRC channel logs

<civodul>i'm browsing the manual and it's an interesting read

<aminb>civodul: thanks! I also just saw an example on the bottom of https://www.gnu.org/software/guix/manual/en/html_node/Version-Numbers.html#Version-Numbers

<civodul>right

<aminb>civodul: thanks for all your work on guix* Ludo :)

<aminb>(and everyone else, of course)

<aminb>i've very much enjoyed reading through the Guix manual in the past couple days, and am *very* excited to switch over to GuixSD from Arch

<civodul>aminb: heh thanks, i hope you'll enjoy it!

<aminb>^_^/

<pkill9>civodul: do you have a link to the hibernate code that was being worked on?

<aminb>out of curiosity, with icecat lagging far behind the current firefox version, what's the status of packaging iceweasel on guix?

<aminb>Parabola seems to have a somewhat up-to-date iceweasel package: https://www.parabola.nu/packages/libre/x86_64/iceweasel/ --- https://git.parabola.nu/abslibre.git/tree/libre/iceweasel

<pkill9>i can't find anything to do with iceweasel in the guix-patch mailing list

<civodul>pkill9: https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00962.html

<civodul>aminb: some people looked at packaging Firefox, but nothing concrete that i know of

<civodul>ACTION -> zZz

<aminb>hmmm

<ng0>aminb: they can package iceweasel (different than icecat) in a recent version because the rust crates act differently in their build chroot I think

<sneek>Welcome back ng0, you have 1 message.

<sneek>ng0, apteryx says: Will try it out (sourcing /etc/bashrc to get completion working). Thanks!

<reepca-laptop>how could I install an older emacs for testing purposes?

<reepca-laptop>I don't suppose it would work to just inherit from the current one and change the version number?

<marusich>Invoke guix pull to get an older version, or build Guix from source in an older checkout?

<marusich>That might work, but if dependencies changed, it might not.

<brendyn>reepca-laptop: you can try downloading the source tarball for an older version and running guix build --with-source=emacs-....tar.gz emacs

<marusich>Since the new support for "guix pull"ing to a previous version of Guix (to get older package definitions) was only recently added, I'm not sure if it will let you go back very far in time. However, if it doesn't work, I would suggest checking out an old version of Guix, building from source, and then invoking "./pre-inst-env guix package -i emacs" to install it.

<marusich>But yeah, if you can get away with replacing the source with an older version, that might be good enough!

<reepca-laptop>Ah, I just realized the cutting-the-knot solution: I haven't gc'ed since I had the older version installed. It's still in my store somewhere, I can just run it from there.

<marusich>reepca-laptop, also, if you know an existing store path (e.g., from an old profile) that you want to install, you can invoke "guix package -i /gnu/store/...cafe-emacs-25.0" (or whatever version it is) to directly install the store item into your profile.

<brendyn>reepca-laptop: in that case it should be in `guix package --list-generation| grep emacs`

<reepca-laptop>agh, just remembered I reinstalled on a new hard drive a while ago

<efraim>janneke: I see mcrl2 is built with monolithic qt, I'm testing building it with modular-qt, any reason you can think if not to?

<janneke> efraim: haven't tried; cannot think of a reason it would not build with modular-qt, however i have very little experience with qt

<efraim>janneke: ok, i'll build it in the background on my aarch64 board

<janneke>efraim: nice

<janneke>they moved to git and made some changes to their (cmake -- ugh) build; i should have a look at that some time

<efraim>according to `guix refresh -l qt@5' Building the following 7 packages would ensure 8 dependent packages are rebuilt: monero-core@0.12.2.0 monero-gui@0.12.2.0 mcrl2@201707.1.15162 quaternion@0.0.9.2 simplescreenrecorder@0.3.11 mkvtoolnix@13.0.0 avidemux@2.6.12

<efraim>although monero-core doesn't count

<snape>aminb: nobody seems to be working on updating Firefox/Icecat/Iceweasel to 58. But the difficulty is the same, it doesn't really matter if it's Firefox or Icecat or Iceweasel, in term of difficulty

<snape>s/58/60

<brendyn>probably a few people have tried

<snape>they didn't really talk about it then

<snape>(except ng0)

<ng0>it is 61 now. at least I think my nix package updated to firefox 61 recently?

<snape>maybe, but updating from 60 to 61 isn't really a problem :-)

<snape>the problem is updating from 52 to 58

<ng0>no, the problem for us begins rigfht after 52.7.2 .. basically 53.x introduced the mandatory rust crates

<ng0>we want to go to 58 ideally, but the problem will remain the same

<ng0>I tried some work with the rust crates in firefox and recalculating the hash and so on, but I didn't wokr on it for too long

<g_bor[m]>If I got it right, then the problem is somewhere in the 53.x series, maybe right at the beginning?

<ng0>yes

<ng0>right after 52.7.2. with this version you could still do "--disable-rust"

<snape>Yes, you're right

<ng0>because we path the source bangs of files, we alter the cargo checksums

<ng0>so at least for every file in "third_party/rust" named ".cargo-checksum.json" the checksum has to be recalculated or otherwise worked around

<g_bor[m]>I've seen some cargo-build-system, I guess. What is the current status?

<ng0>that is not the same though

<g_bor[m]>I mean could we reuse something from there? Or extend it in a meaningful way?

<ng0>not 1:1, I already tried that

<ng0>I haven't worked on this in months. most recent snippet I could extract from my package: https://d.n0.is/pub/tmp/snip.txt

<g_bor[m]>snape: I've not looked into this in detail, but I don't think the new web interface and the api changes are documented. What do you know about this? Also is Tatiana's work in the shape to be merged?

<snape>g_bor[m]: I didn't know there were API changes.

<snape>Indeed the web interface isn't documented, but it's pretty intuitive

<snape>Yes I'm currently working on it :-)

<snape>Almost there

<snape>I plan to merge it today

<g_bor[m]>snape: I think there were some extension. I will have a look later.

<g_bor[m]>That is really nice. I would like to see how it performs.

<snape>g_bor[m]: it performs like this: https://cuirass.lassieur.org:8081/

<g_bor[m]>Nice feeling :)

<g_bor[m]>It would be nice to see what's missing. I noticed that communication went to a reactive style recently. I will walk through the question list in my docs, and see what we already have. Thanks for getting involved.

<g_bor[m]>When do you think this can get on berlin?

<snape>Hmm funny thanks to the web interface I just notived that the GLM update broke libreoffice

<snape>I'll report a bug

<snape>it can be on berlin when rekado_ or civodul reconfigure, after I did the merge

<g_bor[m]>fine, thanks.

<snape>and I plan to be done today, so... soon

<ng0>I see, this is about the icecat thread. wrt rust build system and what's required for firefox, I replied on 13th Jul 2018 10:22:18 +0000

<snape>yes I know

<snape>thanks :-) I'm just trying to get more people involved

<civodul>Hello Guix!

<civodul>mbakke: thanks for integrating the mariadb patch in 'staging'!

<rain1>hi

<civodul>heya rain1!

<mbakke>civodul: Thanks for fixing MariaDB properly :-)

<civodul>heheh

<civodul>mbakke: so is everything on track for 'staging', or are you tirelessly waiting for hydra to catch up? :-)

<mbakke>Right now I'm just waiting for Hydra, don't have more patches in my queue.

<civodul>ok

<civodul>ACTION looks forward to the day where we can get rid of hydra.gnu.org

<efraim>i tested mariadb from staging on aarch64, no problems

<efraim>have to test libinput again

<Formbi>how to make programs installed via guix see themes and icons in /usr/share ?

<civodul>mbakke: regarding the Agda patch, you can apply it because i think atw doesn't (yet) have commit access

<civodul>Formbi: there's the XDG_DATA_DIRS env. var. used by GTK+ & co., but it has other side effects

<mbakke>Oh, right, I keep forgetting who has access! Will push later. Thanks for the reminder.

<Formbi>civodul: so what should I put into this variable?

<pkill9>civodul: why will you get rid of hydra.gnu.org and what will replace it?

<ecbrown>ACTION thinks "a hurd of hydras..." but the joke stops there...

<rain1>haha

<ecbrown>starting with guixsd 0.15 release iso, is "guix pull" before "guix system install" meaningful? the documentation mentions guix pull *after* install

<ecbrown>i.e. i want to get something like "what's on master"

<Formbi>ok, i set XDG_DATA_DIRS

<Formbi>and icons are visible, but themes are not…

<civodul>pkill9: hydra.gnu.org is a slow VM and we're replacing it with berlin.guixsd.org, a fast physical machine

<civodul>plus, we're replacing Hydra (the software) with Cuirass

<civodul>currently each one has its own shortcomings ;-), but eventually using Cuirass should make it easier for us to improve things

<Formbi>ah, I had to symlink /usr/share/icons to $HOME/.icons and so on

<cbaines>Has anyone had any success using nftables on GuixSD? I'm a bit stuck it seems.

<civodul>hey cbaines!

<civodul>i've never used nftables

<cbaines>hi civodul :)

<cbaines>I thought I'd give it a try, but the error messages are a little confusing...

<cbaines>oh, and congratulations on the new release, it's great!

<civodul>cbaines: which release? 0.15.0?

<civodul>it's history already ;-)

<civodul>ACTION posted a tentative roadmap for 1.0

<cbaines>Yep, haha!

<vagrantc>ooooh.

<civodul>serious matters

<atw>congrats again on finding that guile bug, civodul :)

<brendyn>civodul: You're a great project leader :)

<janneke>ACTION found that guix system roll-back and friends could do with some more love and hard testing

<janneke>maybe it was too naive to roll-back to a 0.14 system...

<cbaines>janneke, what went wrong?

<pkill9>TIL of the rtcwake command

<efraim>good news, libinput on staging on aarch64 built with no problems, writing off the last failure to gremlins

<pkill9>Guiremlins, or Gnuremlins

<efraim>definately guiremlins, I run the board headless so I'm sure they're bored

<janneke>cbaines: not sure i have enough for a bug report; i did a system reconfigure where i renamed a username and their group name; both specified a UID/GID

<janneke>(that was by accident, btw)

<janneke>roll-back gave an error that UID already exists, or something -- sorry i only have this vague story :-/

<pkill9>civodul: out of interest, for the wifi connection(s) that automatically connect in NetworkManager for you, what does it say in the 'permissions=' line in /etc/NetworkManager/system-connections/<wifi connection that autoconnects> ?

<efraim>monero tests take forever :/

<pkill9>I'm wondering if maybe I need to add my user to a group so I don't have to edit those files for autoconnect to work

<cbaines>janneke, interesting. I can't see any system tests for roll back, so you're proably right with respect to the testing

<janneke>cbaines: if it's not tested, it's broken ;-)

<civodul>pkill9: just "permissions="

<pkill9>interesting, i had to edit the file to change it to just 'permissions='

<pkill9>what groups is your user added to civodul/

<pkill9>?*

<civodul>it's in "netdev" and "wheel", but i think it doesn't make any difference for NM

<g_bor>hello civodul!

<g_bor>I've just seen the 1.0 roadmap.

<g_bor>Do we have something where channel support is being worked on?

<g_bor>Also regarding the install I guess you mean wip-installer2, as that is where current work is done, I guess?

<g_bor>snape told me that the Cuirass improvements are in a good shape, we can expect a merge soon.

<sneek>Okay.

<g_bor>How can one get involved in infrastructure work?

<g_bor>Also, what is need to be done on the misc items?

<g_bor[m]>janneke: Hello!

<g_bor[m]>I've seen civodul added some bootstrap related stuff to roadmap 1.0.

<g_bor[m]>Do you need help there?

<civodul>g_bor[m]: i vaguely started looking at channels and it shouldn't be too hard given the new 'guix pull'

<g_bor[m]>civodul: nice! This is really a showstopper for me right now :)

<civodul>oh, is it?

<civodul>i mean you can always work around it, it's inconvenient but not so bad?

<civodul>for the infrastructure work, you can get involved by asking questions on the ML :-)

<g_bor[m]>Also, we have a section in our manual that describes why this is a system in development with a few points listed. Should we incorporate those?

<g_bor[m]>civodul: I could more easily convince people here to add build infrastructure one we have channels.

<g_bor[m]>civodul: Also, one quite important rekado mentioned is the content addressable packages thing we discussed before FOSDEM. Do you think it could get incorporated into 1.0?

<g_bor[m]>ACTION go to mow some grass

<efraim>'remove' is from srfi-1?

<snape>yes

<civodul>it's also in core

<civodul>g_bor[m]: i'm not sure what you're referring to

<civodul>but yeah, it's a tentative road map, so we can discuss what to put in there

<civodul>the only constraint is that we can't put too many things or we'll have to work very hard :-)

<g_bor[m]>ACTION could not finish before the rain...

<janneke>g_bor[m]: oww...rain is good though?

<g_bor[m]>:) yes, but I will have to wake early to mow the remaining grass :)

<g_bor[m]>Do you need help to get wip-bootstrap into a shape for merging?

<g_bor[m]>What do you miss there?

<g_bor[m]>I've seen civodul would like to merge by 1.0.

<efraim>is there a way to take all the packages I have installed and see which of them depend on gtk+@2 without actually viewing the graph myself?

<g_bor[m]>efraim I guess you could get that from the dot file generated by graph easily?

<g_bor[m]>The node should have label = "gtk+@2".

<efraim>I guess I could graph a 'reverse-package' and then grep for my packages

<g_bor[m]>You could also do that.

<g_bor[m]>Your solution is actually lighter. I like it.

<efraim>parallel grep {} ~/gtk2_output ::: $(guix package -I | cut -f1 | sort -u) gave me false positives, i'll have to work on it

<efraim>with ~/gtk2_output being $(guix graph --type=reverse-package gtk+@2)

<efraim>ah, file tripped kfilemetadata and filezilla, I should've done 'cut -f1,2 --output-delimiter='@'

<efraim>ffmpeg has inkscape, ibus and fcitx in its graph, all of which use gtk+@2

<janneke>g_bor[m]: yes...actually civodul had a quick look a day or so ago

<janneke>i'll be afk for summer though

<janneke>g_bor[m]: it's more than `merging', there needs to be some development/integration done

<janneke>wip-bootstrap's gnu/packages/mes.scm can produce a gcc-4.7.4, by doing ./pre-inst-env guix build gcc-mesboot

<janneke>but that gcc-4.7.4 then somehow needs to replace the one in bootstrap-binaries that commencement.scm uses

<civodul>efraim: oh, i didn't expect gtk+@2 to be used (indirectly) by crucial packages like ffmpeg

<civodul>something we should fix, i guess

<civodul>snape: re Bootstrap in Cuirass, we should add the files to Makefile.am

<civodul>and i guess we must have them installed in a place where the web server of Cuirass will find them

<snape>yes, it's in the next commit

<snape>not pushed yet

<civodul>oh ok, perfect

<snape>I pushed the first so to motivate me to finish the work :p

<civodul>as i was writing this i figured it must have been done already, or you wouldn't be running it on your server

<civodul>excellent :-)

<snape>should be pushed tonight

<snape>I'm writing the commit message

<civodul>awesome

<civodul>i'll be afk but if rekado_ is available he can deploy it on berlin when you think it's ready

<aminb>i also saw the 1.0 roadmap, and wanted to mention/ask a couple things:

<aminb>1. what's the status with using *.gnu.org subdomains vs. guix.org? what's the consensus/aim of the project?

<aminb>2. i'd like to help out with some of the infra tasks if possible. in particular, with guix.gnu.org and/or its LE certs

<Formbi>Guix is the package manager of the GNU system

<Formbi>so the gnu domains are not so strange

<aminb>3. under "misc", what's the word on "renaming GuixSD to Guix System?" ?

<aminb>(sorry for 2. i meant guixsd.org instead of guix.org. do we even own guix.org?)

<snape>civodul: sure!

<aminb>Formbi: i'm aware. i was just curious since i saw mentions of guixsd.org

<aminb>i should probably mention civodul so that he'd see my questions above

<snape>g_bor[m]: pushed :-)

<civodul>aminb: in short, "GuixSD" is a name many people don't like, and having two names also complicates things like the web site ("is it about GuixSD or about Guix?")

<civodul>re guix.gnu.org, we need to figure out how to handle redundancy basically

<civodul>currently it points to 2 machines we control, but we/i don't quite know how to arrange the nginx/LE config on these machines

IRC channel logs

2018-07-29.log