IRC channel logs
2018-07-16.log
back to list of logs
<efraim>ACTION is getting rid of libjpeg@8 <jonsger>ACTION trying to compile glibc for powerpc64le <ng0>OriansJ: a while back I started working on it (torbrowser). I encountered some issues, and torproject and the torbrowser team is helpful, but I layed this off for a while since I have more important issues right now <ng0>OriansJ: furthermore, once (if not already the case) Torbrowser team has addressed all the trademark of firefox mentions "issues", we are officially allowed to ship the real, branded Torbrowser as Torproject trademarks team/person and the browser team was okay with my approach <ng0>as a legal safety net I would ask them again (this time public) to get a recorded "it is okay the way it is") once the guix package is ready <ng0>could be that it already was public, been long time since the last exchange of messages <snape>ng0: What is the trademark issue if you don't use the "Firefox" name? <ng0>I can take time to search the emails, but it was about the browsers theming, logos used in there, etc <snape>on that page they seem to associate open-source and non-commercial... <snape>and it indeed says nothing about free and 'not non-commercial' projects <ng0>fyi, I did not read the FAQ <ng0>I went straight to ask the trademarks team for advice and told them where it'll be included etc <jonsger>civodul: working on it fulltime until wednesday. "bootstrap guilec" tries to kill my PC :P <snape>civodul: do you think it's a good idea to remove the --load-path option to Cuirass? I think it should be done in the long term but it won't simplify the migration for people who use it. Maybe a deprecation warning would be better. <snape>(plus, it'd change the service record ABI) <civodul>snape: it's ok to break the API at this stage IMO, as long as we keep Cuirass usable for our own purposes <civodul>--long-path doesn't seem very useful, indeed <ng0>I'm about to send the updates for erlang and elixir I'Ve been using. Imo, and that's how I've been handling packages in general, we should keep the old ones around in older version… but since nothing/only packages themself depend on elixir and/or erlang, I will go with the Guix way to simply update in place. <jlicht>Is #guix also the place to be at for talking about cuirass? If so, guix environment balks at loading the build-aux guix.scm file, but only if calling guix from a git checkout <jlicht>so tldr: guix environment -l build-aux/guix.scm => all dandy, <git-checkout-guix> environment -l build-aux/guix.scm => crashes <civodul>jlicht: does it make a difference if you explicitly run "guild compile build-aux/guix.scm"? <jlicht>civodul: I get the same error with the same output, so it seems not <civodul>are the relative file names in your GUILE_LOAD_PATH? <efraim>jonsger: working on ppc or ppc64el? I have two macbook G4s i keep meaning to break out <civodul>like an empty entry, something like that <civodul>or do you have "something" that does "guile --no-debug"? <civodul>i mean, AFAICS, current-source-directory can return #f if source location info is unavailable (as in (read-disalble 'positions)), or something's otherwise fishy <jlicht>civodul: I removed all of my .guile customizations, as well as any guix-specific things, and I still run into this issue, so I guess not (unless the --no-debug is a default) <jlicht>hmm, if I reduce the example to it's bare minimum (so just the imports + the src-dir thing), and use my guile from the guix-git-checkout, it works without any issues :/ <jlicht>thanks for the help either way civodul, I will try to see if I can make something break consistently and ping the ML to see if this is an actual bug, or something on my end <civodul>yeah, let's see if we can reduce it to a simple reproducible issue <ng0>In procedure private-lookup: No variable bound to make-vector in module (guile) <ng0>while running make I should add :) <ng0>happnes while/around the time guix/tests/http.go appears <civodul>ng0: what version of Guile do you use? <civodul>2.2.4 appears to fix this bug for me <ng0>I start my work on guix always with guix environment --fallback --no-build-hook --pure guix <ng0>guile should be on 2.2.4 here <civodul>i think it's 2.2.3 in this case, no? <ng0>the host one is 2.2.4 <civodul>what does "guile --version" say in your build env? <ng0>sorry, should've done that :) I'm commiting my changes, as I know they work, tested elsewhere <ng0>yes, 2.2.3 in the env <brendyn>Guix is actually bad since it's reproducible, turning it off and on again isn't going to get rid of your bugs. <snape>civodul: should I push my patches once they are ready or send the updated version on the ml? <jlicht>I have a diff of the generated .go files: http://paste.debian.net/1033899/. The only thing I am able to divine is that the 'broken' version seems to be using guile 2.2.3 instead of 2.2.4, and that the 'file name table' is different <OriansJ>ng0: Thank you for clarifying the Tor-browser situation <ng0>a realistic date could be at some point in 2019? Depends on how often I can work on it. <ng0>there's this rusty train arriving, which could make it just a tiny tiny bit challenging in guix ;) <brendyn>It's a bit over my head, but I would like to learn some Rust, maybe after I finish SICP <OriansJ>jonsger: if you are interested in guix on PowerPC, would you perchance be willing to help with a little testing for the mescc-tools support of PowerPC? That would help put PowerPC into the stage0 bootstrap group. <jlicht>I fixed my problem by building guix with guile 2.2.4 instead of guile 2.2.3. Not sure why this should have lead to issues, but I'm happy now :) <jonsger>OriansJ: yeah sure. At the moment I only have hardware at work, but soon(TM) I'll should have my own :P <oriansj1>jonsger: excellent. The more platforms the better <civodul>snape: if you're confident you can go ahead and push! <gast>just came across guix - looks interesting - who's using it where? <civodul>gast: i suppose a large majority of the people on this channel use it :-) <civodul>as for use cases, there's daily "desktop-style" usage, software development, and high-performance computing <pkill9>it would be cool to have a library of guix configurations for different laptops, that have all the random quirks applied (e.g. i have to set a kernel parameter for the brightness buttons to work). Not that i'm asking anyone to do it, too much effort tbh lol, but it's neat that it could be done <civodul>suprisingly i didn't have to do anything special for my laptop <roptat>I'd be interested in the brightness button kernel parameter :) <brendyn>I'd like to build a complete desktop distro out of GuixSD <brendyn>Such things will need to be included and Just Work <civodul>roptat: actually i just realized i bind this kind of buttons in Emacs, so i'm cheating <brendyn>What do you all use to adjust brightness btw, since xbacklight doesn't work <roptat>cat xxx > /sys/class/backlight/*/brightness :/ <brendyn>I found that sudo light xxx works but requires sudo <civodul>brendyn: oh right, i used to use xbacklight but it broke some time ago <civodul>so i end up using "sudo light -S NN", which isn't great <civodul>i wonder if it's just something that changed in Xorg <pkill9>maybe it will work on non-x220 laptops <civodul>"1.2.2 is already the latest version of xbacklight" <efraim>I have it working with enlightenment, but I had to add the enligtenment backlight binary to setuid <gast>umm, yes, or interested in it. there are 185 here; that's 1 interested non-user(me); 184 potential users... how many are actually using it and where? I'm responsible for the software that delivers the ngsservice for PublicHealthEngland(excepting TB) <efraim>I know it works with the slider, I don't remember if I tried the buttons <efraim>I use GuixSD as my desktop machine <pkill9>gast: i'm using it on this laptop right now <brendyn>archwiki says configuring xorg.conf might work, and xf86-video-intel might be needed <snape>gast: it's difficult to know exactly how many people, and where <snape>because we don't track our users :-) <snape>also, there are people who use it, but aren't here on IRC <roptat>gast: I have two desktop machines and one personal server running on GuixSD <roptat>(actually one desktop computer and one laptop) <snape>gast: my personal computer runs GuixSD, my work computer runs Guix, and I have 3 servers running GuixSD, two of them being mail servers. <roptat>also, I have guix (the package manager) on my work computer <civodul>funny: there's "xrandr --brightness", which does not actually change the hardware brightness level, but instead fiddles with rendering to make it looks bright/dim <Sleep_Walker>mbakke: hi - I have seen your recent update of bluez - have you tried to use it? <Sleep_Walker>it seems that DBus policy is not added to the system and bluetoothd is never started as a service... <mbakke>Time to write a bluez system test! :) <Sleep_Walker>I'd write it myself but I am afraid that I'm still beginner in that... <mbakke>Sleep_Walker: I think you'll find the system tests fairly straightforward, there are plenty examples of just checking that a service is started ;-) <mbakke>Until we can fix the bluez package, you can work around it by adding a "bluez/fixed" variant and use that in the system service. <mbakke>To run the system tests, use `make check-system TESTS=bluez`. <Sleep_Walker>I'll try to dig into guix source to see example of adding DBus configuration first <mbakke>Sleep_Walker: The D-Bus policy files look the same between 5.50 and 5.49. <mbakke>Maybe you need to be member of 'lp' group? <Sleep_Walker>root@doom ~# /gnu/store/jxhdr5d9fz0dfanp7rs67l89dq70j1y3-bluez-5.49/libexec/bluetooth/bluetoothd <Sleep_Walker>D-Bus setup failed: Connection ":1.483" is not allowed to own the service "org.bluez" due to security policies in the configuration file <Sleep_Walker>mbakke: this is as root with bluetooth-service added in system configuration <Sleep_Walker>shepherd is keeping this service disabled because of this <Sleep_Walker>I noticed that you are probably user of bluez so I thought I'd ask you... <Sleep_Walker>both 5.49 and 5.50 has the same issue as it is either my misconfiguration or distribution issue... <mbakke>Sleep_Walker: Only occasionally, it's been a while since I used it last. <mbakke>Did you try rebooting after adding the service? <mbakke>Sleep_Walker: Unfortunately Shepherd does not properly reload all services as required on reconfigure. <mbakke>In this case, it appears D-Bus needs to restart to read the new policy file. <mbakke>You could try restarting D-Bus with shepherd, but it will almost definitively kill your desktop session :P <Sleep_Walker>so, good news is that package is fine as it is (test would still be good idea), but change of dbus configuration doesn't trigger dbus-system reload... <Sleep_Walker>SIGHUP will cause the D-Bus daemon to PARTIALLY reload its configuration file and to flush its user/group information caches. Some configuration changes would require kicking all apps off the bus; so they will only take effect if you restart the daemon. Policy changes should take effect with SIGHUP. <mbakke>Sleep_Walker: Interesting! I wonder how to implement that for the D-Bus service. <mbakke>Perhaps we can do that unconditionally on reconfigure (if the service already runs). <mbakke>Or every time a dbus-root-service-type extension changes... food for thought! :) <mbakke>Sleep_Walker: Excellent, thank you! :) <snape>mbakke, Sleep_Walker: The Shepherd can't (yet) do anything to running services. It would be too dangerous, the goal is to be conservative. So it won't SIGHUP running programs. <snape>but there is a plan to implement 'reload' actions <jackhill>I'm trying to use guix import against melpa-stable. stable.melpa.org uses a let's encrypt certificate, and the import is currently failing with X.509 certificate of 'stable.melpa.org' could not be verified: signed-not-found <jackhill>how should I make the le-cert available to guix import? <jackhill>I wonder if we could make guix import elpa -a melpa-stable add the cert automatically. Although, maybe we don't want to do that to our users? <civodul>jackhill: did you install nss-certs and define the relevant env vars? <jackhill>civodul: nss-certs is insalled, maybe I didn't do the environemnt setup. Checking… <jackhill>civodul: yep, that was it. Sorry for the noise <jackhill>why are some variables set in .guix-profile/etc/profile, but not others. Is this a foreign distro v. GuixSD difference? <jlicht>What do folks here use to manage their ssh keys (and config)? I just hit a 400 line .ssh config file, and it starting to be a bit chaotic IMO. <efraim>jlicht: does ssh config accept include statements? <snape>jlicht: there is a GuixSD openssh service that can be used for authorized_keys, I find it very useful <jlicht>efraim: It does! This is probably what I'll be going for right now <civodul>jackhill: no, it's more that Guix cannot guess about SSL_CERT_FILE & co. <jlicht>snape: I was talking about the configuration for my OpenSSH client, but if I ever run a GuixSD server, that seems very nice <jlicht>I'm really digging the 'New in this revision' listing! <civodul>jlicht: "digging" in what sense? :-) <samplet>janneke: Are you there? Do you have a minute to talk about Gash? <vagrantc>janneke: haven't had a chance to follow-up with mes packaging; i see mention of 0.16.1 being out <samplet>janneke: I’m just finishing an email to you about the “foo=” example. <janneke>vagrantc: yes, i didn't "wait" for an ack from you as i promised, figured this would help you anyway <janneke>samplet: nice...feel free to CC guix-devel <vagrantc>janneke: yeah, figured. seem to have a responsive upstream so i'm confident we can fix outstanding issues. :) <janneke>vagrantc: oh, would you like upstream to include your debian/ directory, or is that counterproductive? <samplet>I have looked at Bash’s tests before. They are quite complicated, and very integrated. They will be good eventually, but they are a bad place to get started, IMO. <janneke>samplet: i spent half of the weekend fighting with PEG and finally got it to parse make-3.79/build.sh -- then you rang for the 2nd time...:) <samplet>Oh no! I was hoping to get your attention before you dove too deep. <vagrantc>janneke: my workflow usually is to keep the debian dir upstream separate <vagrantc>janneke: and then i can merge upstream into a debian branch without conflicts <janneke>samplet: you tried, but i chose to ignore; no problem as Gash is really Rutger's baby and i needed this to get really into it anyway <samplet>janneke: Tonight, I will look at ‘make-3.79/build.sh’ with Geesh and make sure it works. <samplet>My biggest fear is hitting some arithmetic. :p <janneke>samplet: i think it's pretty trivial, maybe some `word'/substitution stuff <janneke>maybe i can steal some snippets from geesh test suite, and just name them 00-exit, 01-assign etc -- not sure yet how to go about a sensible test set for gash <samplet>janneke: Do you think that Geesh’s ‘word’ module might be useful? <janneke>samplet: possibly...we can probably just use things like `normalize-word' in gash/geesh:parse-tree->script <janneke>the globbing and tilde-expansion needs to run just in time, and Gash' script looks different--maybe we can steal bits of the algorithm <samplet>janneke: For sure. The ‘word’ module needs to communicate with the back-end as it goes. <samplet>It’s nice to write the back-end code without thinking too much about globbing or references, though. Which is why I wanted a separate module for those things. <janneke>samplet: ah, words are unnamed atoms or sexps, that makes sense <janneke>i see my current effort mainly as an exploration, before we start to "really" work on broadening it, we need to think about geesh/gash and naming <sh-pipe> vs pipeline and many more things. i still want to see some non-trivial scripts work correctly <samplet>janneke: Exactly. The ‘expand-word’ function is supposed to convert a word to a list of fields (which are just strings). <samplet>janneke: I understand. I have done some exploration myself, and am just a little eager to share my findings. :) <blu3r4d0n>I just installed GuixSD in a vm and I can't seem to login with the user i specified in config.scm <efraim>Burning a CD now, adding tk to xorriso increased the size of the enclosure from 67 MB to like 130 <lfam>blu3r4d0n: Log in as root (no password) and then set the password for your user with the `passwd` command <pkill9>blu3r4d0n: have you rebooted into your GuixSD instlalation? <lfam>Also, do you see the encrypted password for your user in the /etc/shadow file? <blu3r4d0n>Oh that's my problem, when I first started I set the wrong username and then had to guix reconfigure <janneke>samplet: i can imagine, this is an exciting project <blu3r4d0n>But after the guix reconfigure it created a user with the right name <blu3r4d0n>I hope eventually I can run this as a daily driver <samplet>janneke: I think I will do two things in the short term: make sure the files you mentioned parse cleanly, and commit some of the nascent back-end code that I have. The latter I’ll do so that you can see the general direction I was going. And yes, we should discuss a bit on guix-devel. <blu3r4d0n>I tried NixOS but the way the configuration language is built messed with my head a little bit and scheme is familiar <blu3r4d0n>Oh guys now I'm having another problem once my user logs it'll immediately kick out after sitting at the logging in page. <lfam>blu3r4d0n: Can you share your config.scm? <ecbrown>hi all, i'm trying to install xfce on guixsd 0.15, where i have done guix pull. when I try to add xfce, i get "guix system: error: no target of type 'dbus' for service 'polkit'" <efraim>there's also wgetpaste which is easy to use <efraim>you can run 'guix environment --ad-hoc wgetpaste -- wgetpaste /path/to/my/config.scm' <pkill9>ecbrown: are you adding xfce as a service? <ecbrown>pkill9: one sec i'm trying that pastebin <ecbrown>pkill9: i am adding xfce to (use-package-modules ....... xfce) <ecbrown>pkill9: by chance do you see the same error? <efraim>ecbrown: you're using %base-services instead of %desktop-services so you have to add your own dbus-service <efraim>i see that now about needing wget for wgetpaste <ecbrown>efraim: thank you for the suggestion. yes i amalgamated from barbones and desktop <pkill9>ecbrown: yes i get the smae error <pkill9>i use xfce in my own guix configuration <blu3r4d0n>I fixed my issue it was because I didn't have write perms on my /home/user directory <lfam>Hm... was that directory created by GuixSD, or did you make it "by hand"? <lfam>ACTION looks into CUPS bugs <blu3r4d0n>Oh, I believe I created it by hand. I accidentally messed up the user configuration initially <pkill9>ecbrown: try changing %base-services to %desktop-services <ecbrown>yes, i just changed that and it looks like its doing its thing <ecbrown>great pkill9 efraim it is working now <blu3r4d0n>So I'm thinking next summer I might want to do something with GSoC and Guix <blu3r4d0n>What's the best way to start contributing to this project? <janneke>what i did was: install the guix package manager on my main debian computer, move more and more of may projects into guix, install GuixSD on the computer, find what I want to change <blu3r4d0n>I am definitely going to play around with it <janneke>samplet: just wondering, why did you call 'if' sh-cond? <janneke>ACTION is making good progress with test/*.sh and geesh <civodul>janneke: geesh? is that a Gash spinoff? <pkill9>i don't suppose anyone has created a way to include guix pakcage definitions from a remote url in their guix system configuration? <civodul>i suppose you could always do (primitive-load (http-get ...)) but... <pkill9>so you would just do `guix system reconfigure ..` and within the system configuration it would retrieve package definitions froma URL, add the extracted folder to the GUIX_PACKAGE_PATH, and build the system? <civodul>a procedure that runs Scheme code from a file <civodul>running arbitrary code downloaded from the Internet isn't safe <civodul>you would need extra measures to authenticate it <janneke>civodul: i was fighting^H^H^H^H^H^H^H getting aquainted with ash's PEG parser for sh this weekend, and there was samplet: "Hey, I have a SH parser in lalr, it's almost done" <janneke>civodul: "it's called: Geesh" -- can you imagine my deja-vu? (Nyacc) <janneke>so the past day i've been molding Geesh onto Gash :-) <pkill9>really what i need is to write a script that will pack everything needed into the system config file <civodul>woow, funny to see things converge like this <janneke>geesh+gash+guix-bournish = bootstrap, nice guile sh/sexp-scripting, mingle sh/sexp at the prompt... <civodul>also if we can turn part of (guix build utils) into a run-time library of Gash/Geesh, that'd be great <Thra11>Will patch-source-shebangs and patch-shebangs replace any occurrence of #!/bin/sh or only those at the beginning of the first line of a file? <civodul>well, i mean any occurrence at the beginning of the first line :-) <civodul>things that generate scripts need manual twiddling <civodul>blu3r4d0n: on GuixSD: sudo herd start ssh-daemon <snape>blu3r4d0n: if you add the ssh service to your config, you need to reconfigure first <snape>and the ssh daemon will start automatically on reconfigure <blu3r4d0n>Sorry where would I add the service in the config? <blu3r4d0n>Yeah I just found that right before you sent it snape but thanks! <mbakke>ACTION has an update for MariaDB 10.1.34. It now runs a lot more tests by default, what should the package timeout be if the build takes 3-4 hours on a crappy laptop? <mbakke>Also managed to unbundle pcre, zlib, snappy and xz (I think, still building that commit!). <lfam>mbakke: Nice, that's really great. The armhf builders are the slowest. What CPU does the crappy laptop use? <mbakke>Can a GPL2 program link with one that's GPL3 or later? I suspect not. <mbakke>I notice Debian does not compile MariaDB with OpenSSL for compliance reasons (even though MariaDB has an OpenSSL exception). <lfam>mbakke: Do they use any TLS library with MariaDB? <lfam>It's sad but I would set the build timeout to 8 hours for armhf <mbakke>lfam: There's a bundled "yassl" (which Debian uses); it can optionally use OpenSSL for...stuff. Our package currently uses both, it seems. <snape>mbakke: they are not compatible, so you can't link them <lfam>Hm, we should try to avoid the yassl unless MariaDB is really maintaining it <mbakke>snape: Thanks for confirming. Not adding readline then ;-) <mbakke>lfam: YaSSL appears fairly well maintained (and stable). The last release is from 2016-09-22 and it was updated in MariaDB 2016-09-27. <lfam>There is a later release from summer 2017 but sounds okay <lfam>I'm wondering if they are vulnerable to CVE-2018-0495. They did release a patch for WolfCrypt <samplet>janneke: It’s called ‘sh-cond’ because it has ‘elif’ cases, so it is more like Scheme’s ‘cond’ than its ‘if’. <mbakke>MariaDB 10.2 renames itself to 'mariadb' rather than 'mysql', that will be a fun transition. <jonsger1>mbakke: most distors "mysql" is already "mariadb", just the executable is named "mysql". So I find it consequent :P <mbakke>I've seen a lot of '-lmysql' fly by when watching build logs though :-) <mbakke>I was surprised that Arch was still on 10.1, apparently it's the name change that holds it back. <Probie>Is it possible to run Docker on GuixSD? I can't seem to find any documentation on it