<lfam>It really should just be the default <lfam>Already it's way too complicated <lfam>I bet we would get so many questions about tofu š¢ <lfam>I wonder if we would get more questions about the trust warning or about tofu <vagrantc>--trust-model=tofu+pgp gets the ... best of both worlds! :) <vagrantc>you can set a default policy for tofu ... but also use the web of trust <lfam>Well, maybe send a patch for the tofu bit and see what people think? We field questions about those warnings *all the time* <lfam>Is there anything besides wicd-curses and connman for interactive wifi setup on the console? <lfam>wicd simply won't activate my wireless card for some reason. It does work with wpa_supplicant but I'd like something less involved <lfam>I figured it out. wicd failed to autodiscover the wireless interface (wls1) although it did know the wired interface <lfam>Once I configured that it works <lfam>Blackbear[m]: Thanks for the tip! I don't see it in Guix yet <jackhill>lfam: if you're fine with network-manager this is also nmtui <lfam>Thanks, since I got it working with wicd I'll probably forget about it until the next time I reinstall :) <Blackbeard[m]>nmcli exist on fedora but i am pretty sure that require systemd ***renich_ is now known as renich
<rvgn>civodul I wanted to ask you this for long time. I saw that Guix was written in Guile and C++. When I was reading GNU Coding Standards, it seemed more or less similar to Python Coding Standards. So any ideas of porting Guix to Guile and Python instead of Guile and C++? Just a thought. <jonsger>rvgn: only the daemon itself is written in C++, as it was forked from NixOS. But there is an attempt to rewrite the daemon in Guile. Then Guix will be Guile "only"... <rvgn>jonsger Oh that's so better then. <rvgn>So Guix was forked? I thought it Guix was distro of Nix that provides Software Freedom and Guile Advantages. So Guix is not synced with Nix Upstream? <jonsger>rvgn: only the daemon programm was forked from Nix long time ago <rvgn>jonsger Kind of confused. So Guix and Nix are like Linux-Libre and Linux? Guix development is synced with Nix development just like how linux-libre development with main line Linux? <rvgn>Sorry I got off guard. Can you please explain? Thanks. <jonsger>no, only the guix-daemon was forked from Nix one time, but never got synced after that. And the rest of Guix like packages or features of the "guix" command have "nothing" to do with Nix <nckx>Blackbeard[m]: NetworkManager doesn't require systemd. <nckx>Wonder how that misunderstanding got started. <jonsger>btw, nckx are you trying to topping the contributer stats for the 1.0 release? *nckx just woke up; is fuzzy. <nckx>jonsger: :-D Pretty sure Ricardo'd take that cake, if there was one. <rvgn>jonsger Ah I see. Thanks! <rvgn>nckx any estimate on 1.0 release? I heard it's early march but any updates? <nckx>rvgn: Have you seen the āStatus update on 1.0ā thread on guix-devel? 1.0 is being worked on. <nckx>^ probably what jonsger just linked to. :-) <nckx>s/so far/because it's ready when it's ready/ <nckx>1.0 isn't going to be some wildly different experience. You're basically using Guix 0.99 now. <rvgn>to be default. It's happening in 1.0 right? <nckx>GDM's close, maybe even usable, and actively being worked on. But I'm not interested so no idea if it's a blocker for 1.0. <civodul>GDM is definitely usable and highly recommended if you use GNOME <rvgn>I have no idea what "dropped the ball" meant in that article for GDM. XD <civodul>there's just one tiny issue that prevents us from making it the default <rekado>(Iād like to release 1.0 on April 1st) *nckx is going to try it once, for the perverse pleasure of launching GNOME OS to drop them into i3. <rvgn>civodul Ah I see. Thanks. So once fixed, I should just to system --reconfigure right? Or should I change some thing in config.scm? <civodul>rvgn: yes; until then you can also modify your config to use GDM instead of SLiM <rvgn>civodul Anyway, support for GNOME was prioritised over support for KDE for past Guix releases? Is there a specific reason? Is majority of GNU users using gnome? <rvgn>rekado I see what you did there regarding April 1st ;) <rekado>rvgn: it was just easier to package all of it. <rekado>there are not many people working on KDE, but slow progress has been made already. *efraim would like (service login-service-type (login-manager slim-service-type ... <rvgn>Hmm. Why is that? (asking out of curiosity). KDE seems to be more hackable than GNOME, but why less devs are intrested in it? <civodul>i'm under the impression that GNOME is more widely used in general than KDE, so maybe that's just what we're seeing here <rekado>KDE requires a lot of libraries that werenāt used by other packages. For GNOME many packages already existed because existing applications already needed them. <rvgn>rekado Ah that makes a good rationale to prefer GNOME over KDE. <rekado>but itās probably also true that a lack of KDE packages results in a continued lack of KDE packages. <rvgn>Speaking of GNOME, I filed a bug report few weeks ago. When an online account is added in "gnome-online-accounts", it's not being synced with other GNOME apps like calendar, to-do etc. <rvgn>Also no webdav files showing up in file manager. <rekado>rvgn: have you tried to dig deeper into this to figure out what might be the cause? <rvgn>rekado I tried to. I found out that the issue is related to webkit package. <rvgn>But just don't know how. <rekado>i would have guessed that it doesnāt know where to store the information. <rekado>e.g. that it tries to write to /gnu/store/ā¦/var or that it attempts to connect to some dbus service thatās not running. <rvgn>It seems that package is responsible for syncing web accounts. <rvgn>rekado Ah I see. That goes beyond my knowledge about system services. :( *kmicu knows the true reason behind avoiding KDE is Qt compilation times š¤ <rvgn>Because I had same issue with KDE when I was using hyberbola. Turns out that KDE's webkit is not packaged as it has non-free codes. <rvgn>So thought same would be related to GNOME's webkit. But since this is free package and is already installed. Don't know how the problem is emerging. <rvgn>rekado Regarding our conversation about Evolution, here are the dependencies required by evolution-app: 1) enchant 2) gsettings-desktop-schemas 3) gtkspell3 4) libcryptui 5) libnotify 6) libytnef 7) evolution-data-server (already packaged in guix). <rekado>we donāt have cryptui and libytnef, but the rest is already there. <rekado>but Iād assume there to be more dependencies. <rekado>AFAIK Evolution has support for Microsoft Exchange and thatās not provided by any of these libraries. <rvgn>Oh yes I mentioned with out MEx support. ***ng0_ is now known as ng0
<rvgn>The FULL list of dependencies are: <rvgn>2. gsettings-desktop-schemas <rvgn>rekado did you get full list of 30??? <civodul>looks like you're almost done packaging it gentlefolks :-) <jonsger>civodul: it's maybe easier then Thunderbird. There I didn't made any valuable progress <civodul>anyone knows how to get QEMU to use a 16/9 resolution? <mbakke>rekado: GNOME crashes after a few seconds on the staging branch. Was this a known problem, or did something else break it? <rekado>I found that itās related to notifications (or other binary state) <rekado>I avoided the crashes with ārm .local/share/gnome-shell/notificationsā <rekado>I assumed that the problem was really just due to the fact that I used applications from an earlier GNOME generation. <rekado>Iām currently rebasing the gnome 3.30 branch on top of staging <mbakke>I observed the crashes in a `guix system vm`, so no prior state is necessary. <rekado>I used that branch for a few weeks before. <rekado>the only problems I had were due to state such as notifications. <rekado>is there a paredit command to āspillā the contents of an expression one level up? <rekado>thereās paredit-raise-sexp, but itās only for one expression (or for N); Iād like this to be automatic. <rekado>e.g. for all of the contents of a now obsolete let expression <pinoaffe>btw, setting up guixsd by booting the livedvd in a vm and mounting the actual hardware worked, I'll just have to set up a bootloader myself, but I didn't expect that to work off the bat anyhow <rekado>civodul: AFAIU the resolution is to be set by the guest operating system. <rvgn>That link contains all dependencies required to build Evolution <civodul>rekado: ok, i figured it'd be easier to just crop the image, which i just did <joshuaBPMan>possible a dumb question, but do I need to run "guix pull" as root every now and then? followed by "guix system reconfigure" to upgrade? <mbakke>joshuaBPMan: You don't have to run guix pull as root, unless you intend to use the root account. That is, `sudo -E guix system reconfigure` will work fine. ***MinceR_ is now known as MinceR
<civodul>mbakke: problem is there's always something that fails to build on the way to the guix that's used to evaluate jobs <civodul>in this case there were GMP test failures <civodul>apparently non-deterministic since they didn't show up when i retried <lfam>So I reinstalled my GuixSD system to see if it had an effect on #30993 (OpenSSH sshd killed by Shepherd 0.4.0) <lfam>It did... but not for the initial installation of Guix 0.16.0 <lfam>After I pulled / reconfigured it did start working <lfam>It should be the same system as before since I re-used the config.scm <mbakke>lfam: Sounds like the failure is still indeterministic, no? <lfam>mbakke: Depends on what state you account for ;) <lfam>Previously, it *always* failed for me, so I had stayed on Shepherd 0.3.0, where it still worked. In the past week or so, that workaround stopped working, so I tried updating to Shepherd 0.5.0, but it was still failing. <lfam>So, I reinstalled Guix. Only after I reconfigured to the latest did it work, and it's worked ~5 times in a row, which is pretty good <lfam>For me, sshd either starts or it doesn't. Since I filed the bug it has never been inconsistent <lfam>I think there must be some state not accounted for by Guix <lfam>Probably related to changes made in the Guix system since I initially installed so long ago <lfam>Maybe I should have tried deleting all the files associated with OpenSSH and avoided reinstalling, but oh well <nckx>mbakke: You can build ceph? Hm. <mbakke>nckx: I built it on btrfs, actually. Where does it fail for you? <nckx>mbakke: ā¦I didn't keep the logsā¦ <civodul>lfam: weird, it shouldn't make a difference whether you reinstall or not <civodul>but apparently it's non-deterministic <lfam>civodul: Maybe some file permissions or something <civodul>so what happens is that sshd doesn't produces its PID file in a timely fashion <civodul>it'd be great to see whether/why sshd is "hanging" at that point <lfam>Hm... if it's really a race, then reinstalling could have an effect. It's a 10 year old spinning hard drive and it was getting full. Maybe it couldn't write the file in time <lfam>And maybe SSH really wants the write to hit the disk before proceeding <lfam>These sorts of thoughts for further debugging are what led me to just reinstall :) <lfam>I had tried running sshd with debugging but I didn't find any useful info :/ <civodul>one hypothesis is that it hangs while binding ::1 (IPv6) <civodul>since that's the difference we see in /var/log/messages <civodul>but to verify that hypothesis we'd need to get a backtrace or debug output at that poit ***ng0_ is now known as ng0
<civodul>and i failed to reproduce the issue in a VM that i started like 15 times in a row <civodul>lfam: if it fails often for you, hopefully you can gather more data? <lfam>Heh, I hope it doesn't fail again but if it does I'll collect debug logs again <nckx>guix refresh -l perl-test-harness ā Building the following 24 packages would ensure 139 dependent packages are rebuilt: ā¦ guix-minimal@ā¦ <nckx>guix-minimal is a hidden-package. Now, it's not wrong, but is it intentional? <nckx>It makes it a slight pain to paste the output to āguix buildā, but it is true. ***e^x is now known as nekomancer
***MightyJoe is now known as cyraxjoe
***nekomancer is now known as e^x
*lfam waits......... for the bug number ***Server sets mode: +cnt
<civodul>all the printer-related code is terrible, really terrible <civodul>it's littered will all sorts of tricks to run non-free stuff on your machine <civodul>including udev rules to start an automatic downloader <civodul>and hp distributes that on its "open source" web page <nckx>Oh, OK, just code āweā install. <civodul>fortunately, it's crappy like hell so the download stuff cannot work for us :-) <civodul>nckx: do you know if they hp-* command-line tools of hplip are of any use? <civodul>i mean for hplip-minimal, it seems that we could keep only lib/cups and none of the hp-* tools, no? <nckx>civodul: They work, if that's what you mean. There are things that only the tools can do (like find out how much ink is in that overpriced little black box, and *I think* I needed hp-something to align my print heads once). <nckx>If you mean whether standard CUPS features work without them, I'm pretty sure they do. *nckx is AFP or would have more useful things to say. <nckx>I'd say it's worth the bet to remove them from -minimal. <nckx>(Speaking of terrible code, by the way.) <civodul>nckx: i found --enable-lite-build, which disables the Python CLIs <civodul>so it seems like can do that in hplip-minimal *nckx isn't sure what exactly the definition of minimal is. More precisely: assumed that it excluded hplip already; was wrong. <civodul>that prevents Guix compilation, which in turn means the evaluation cannot happen <katco>i don't get a lot of chances to hack on guix, so everytime i sit down to do so i realize i've forgotten a bunch of things. i wanted a check on my workflow. i've just created a new local branch with an aim to upgrade go to 1.12.1. i did a `make clean && ./bootstrap && ./configure --localstatedir=/var && make check`. then i do `guix environment guix`. when i ran that last command it kicked off a couple-hour (and counting) process. surely <katco>there must be an easier way to make changes to packages and test them locally?