IRC channel logs

2018-11-27.log

back to list of logs

<vagrantc>does the new git-minimal help reduce the dependency graph for "guix pull" ... i've got a slow machine building without on aarch64 (where there are few to no substitutes), and it's taking several days before i've even finished the very first guix pull after installing guix binary 0.15
<apteryx>how do I get emacs to load only the libraries in an environment?
<apteryx>guix environment --pure --ad-hoc emacs emacs emacs-elpy -- emacs
<apteryx>this emacs still has access to all of my emacs packages of my main profile (it's not pure).
<Formbi>emacs -q ?
***daviid is now known as Guest24182
***Guest24182 is now known as daviid
<pkill9>where can i get a copy of the xorg config file used by the login manager?
***jonsger1 is now known as jonsger
<D4RK|R4Z0R|Z|>vagrantc, dunno if you are there but what substitute servers are you using
<D4RK|R4Z0R|Z|>pkill9, there is no xorg.conf anymore but you can generate one
<vagrantc>D4RK|R4Z0R|Z|: https://berlin.guixsd.org https://mirror.hydra.gnu.org
<vagrantc>but they have less than 1% substitutes available
<D4RK|R4Z0R|Z|>hmm that seems odd. Well I checked over a week ago...
<vagrantc>it's pretty much been the same as with --no-substitutres
<pkill9>D4RK|R4Z0R|Z|: how do i generate one?
<D4RK|R4Z0R|Z|>X -configure
<vagrantc>i think it's gotten as far as actually updating guix and not just building the dependencies, finally :)
<D4RK|R4Z0R|Z|>that will make one in current directory
<vagrantc>wow. xorg.conf ... don't miss it :)
<D4RK|R4Z0R|Z|>vagrantc, ahh... well I even stopped using the mirrors as they were not updated but then they all synched up
<D4RK|R4Z0R|Z|>hehe yeha
<pkill9>it didn't seem to work, thanks anyway
<pkill9>what i want is startx
<D4RK|R4Z0R|Z|>well i doubt X is in your path, it's not in mine either
<pkill9>that wasnt the issue, i got X from the xorg-server package
<pkill9>anyways, what i want is startx, but when i run it, no input devices work because it doesn't register any
<pkill9>so i have to kill X through ssh, or reboot
<D4RK|R4Z0R|Z|>hmm maybe install xinit, xterm
<D4RK|R4Z0R|Z|>hmm what else
<D4RK|R4Z0R|Z|>i forget what pulls in the devices isnt it xorg-server
<D4RK|R4Z0R|Z|>i thought it was too
<D4RK|R4Z0R|Z|>i could be wrong but i think xinit will pull in startx
<pkill9>basically in the logfile i get a tonne of "Adding input device ____ ... No input driver specified, ignoring this device"
<D4RK|R4Z0R|Z|>is there a libinput, or evdev?
<D4RK|R4Z0R|Z|>package
<D4RK|R4Z0R|Z|>xf86-input-libinput
<D4RK|R4Z0R|Z|>try that one
<D4RK|R4Z0R|Z|>xf86-input-evdev
<D4RK|R4Z0R|Z|>if the first one dont work :)
<D4RK|R4Z0R|Z|>startx comes with 'guix package -i xinit'
<pkill9>i know, but it doesn't work 'out of the box'
<pkill9>it doesn't even have the right path to the X server by default
<D4RK|R4Z0R|Z|>hmmm
<pkill9>it has <path-to-xinit-package>/bin/X as the X server path
<pkill9>instead of <path-to-xorg-server-package>/bin/X
<D4RK|R4Z0R|Z|>vagrantc, https://mirror.hydra.gnu.org
<D4RK|R4Z0R|Z|> 96.9% substitutes available (8,817 out of 9,103)
<vagrantc>D4RK|R4Z0R|Z|: oh aarch64?
<D4RK|R4Z0R|Z|>pkill9, well hmm i had a LFS vanilla and used guix binary to install xoeg...
<D4RK|R4Z0R|Z|>vagrantc, computing 8,750 package derivations for x86_64-linux...
<vagrantc>D4RK|R4Z0R|Z|: yeah, that's fine. aarch64-linux is the one that has almost no substitutes
<D4RK|R4Z0R|Z|>xinit is a bunch of setup scripts to actually run X if that helps
<D4RK|R4Z0R|Z|>vagrantc, ahh I see I didn't notice that :)
***benny is now known as Guest28660
<vagrantc>i was apparently being way too optimistic about guix pull almost being done
<efraim>bavier`: no, looking around online go for armhf and aarch64 depends on the gold linker
<bavier>efraim: ok, wanted to make sure it wasn't just me
<bavier>would be nice to get it working; I looked at it a little today
<bavier>1.4 seems to have less aarch64 support
<efraim>sneek: botsnack?
<sneek>:)
<efraim>sneek: later tell Bavier I tried before with gccgo but it also needs gold, even for 'gccgo as the go binary'
<sneek>Will do.
<efraim>sneek: botsnack
<sneek>:)
<vagrantc>is it feasible that guix pull is stuck in some sort of build loop ... i swear i've seen the same versions of valgrind being built at least three times ... i know sometimes it builds different variants and whatnot...
***benny is now known as Guest18033
<fps>deleting old system generations is still done via deleting symlinks in /var/guix/profiles/?
<efraim>fps: yeah
<efraim>vagrantc: it shouldn't be possible
<vagrantc>hrm.
<vagrantc>well, that's life building on a slowish arm machine with not a lot of ram i guess.
<civodul>Hello Guix!
*vagrantc waves
<efraim>Hi!
<efraim>vagrantc: do you have plans for fosdem or is it too far?
<vagrantc>efraim: probably not making fosdem, but going to the reproducible builds summit and guix meetup beforehand
<efraim>OK. Sounds like fun. I thought about that one but I can't make it this year
<vagrantc>i'm actually trying to get guix running on the pinebook in some capacity so i'll be able to do some guix work while travelling... but this is probably turning out to be too slow for that
*vagrantc wonders if guix pull will finish by mid-december at this rate...
<vagrantc>all the pieces are in guix to probably even run GuixSD on it
<fps>civodul: is there an rss feed or something to get noticed of a nar/narinfo being done on hydra?
<civodul>fps: there's an HTTP API that allows you to get the list of latest builds for instance
<civodul>like https://berlin.guixsd.org/api/latestbuilds?nr=30
<fps>civodul: ah, nice. are there rate limits on that? ;)
<civodul>fps: well it turns out to be pretty slow currently, so use with care!
<efraim>vim-full is broken on core-updates, I bet someone is going to want that fixed
<fps> https://berlin.guixsd.org/api/latestbuilds?nr=1000
<fps>504 Gateway Time-out
<fps>;)
<efraim>x265 is driving me crazy. I think I have the multilib figured out for the static libraries finally
<fps>ok, i broke it by a single request.. now everything times out ;)
<efraim>nothing like adding a 'fail phase
<fps>ok, i thinkn someone needs to step up and kill the process that was triggered by this nr=10 request ;)
<civodul>fps: i told you :-)
<fps>*nr=10000
<fps>argh, you know what i mean ;)
<fps>civodul: i didn't send MANY requetst ;)
<civodul>slowness is triggered by large nr values, for some reason
<fps>should i publish a CVE? DOS attack on guix' build farm ;)
<civodul>heh
<civodul>it's really a problem but "we're working on it"
<fps>oki :)
<civodul>well, demotri is, maybe? :-)
<efraim>phase `fail' failed after 0.0 seconds
<efraim>but it's depreciated ;p
<roptat>hi guix!
<civodul>hey roptat!
<demotri>civodul: Did I hear my name? Yeah, maybe. Sort-of. I still have it in mind, prioritized it down. Currently looking into core-updates. Not nicer.
<efraim>what's the opposite of concurrent/parallel ?
<efraim>i'm looking for something like "in order"
<demotri>efraim: sequential?
<civodul>demotri: heheh, np :-)
<efraim>demotri: thank you! i lose english words too often
<demotri>efraim: No problem. Same for me.
<vagrantc>serial
<janneke>o/
<civodul>roptat: on Maven and reproducible builds: https://twitter.com/ASFMavenProject/status/1067338555054321665
<efraim>ar is killing me during this build, i'll try the shared libraries and work on the static ones later
<g_bor>hello guix!
<civodul>howdy g_bor!
<g_bor>hi civodul!
<g_bor>fine, thanks
<g_bor>how is core-updates?
<g_bor>I'm thinking about how to get databases rolling using GuixSD...
<g_bor>recently I'm into geo stuff, and it would be nice to be able to do an initial seeding, and then continuous upgrades.
<g_bor>upgrades seem to be ok, as we can run an mcron job, but the inital seed...
<g_bor>I'm not so sure about that.
<civodul>g_bor: core-updates is making slow progress
<civodul>i think mbakke fixed libreoffice
<efraim>if I want to duplicate the 'configure phase with the build-system flags is it enough to call (lambda* (#:keys (configure-flags '()) ... (apply invoke ... configure-flags ... or do I have to re-import the configure phase?
<g_bor>civodul: we also have a workaround for diffoscope, and I've seen some workaround proposal from Danny for the rust issue...
<g_bor>It seems to me that we are getting near...
<demotri>There are some python-related issues fixed and some are open.
<fps>hmm, under what path are the products of berlin.guixsd.org retrivable?
<fps>it has produced e.g. /gnu/store/w7q2kp9bgngaivbll29mnr7jschz5flz-r-hmisc-4.1-1
<fps>so usually the narinfo would be available as https://berlin.guixsd.org/w7q2kp9bgngaivbll29mnr7jschz5flz.narinfo no?
<jlicht>hey guix
<civodul>fps: exactly, and the narinfo has a "URL" field that tells where the nar is to be found
<fps>ah, it seems that a build being finished doesn't necessarily mean that the nars are available from either berlin.guixsd.org or mirror.hydra.gnu.org
<civodul>right, nars need to be "baked" by 'guix publish' before they are available
<fps>civodul: yeah, i'm aware of the redirection in the narinfos. i jsut wondered i couldn't retrieve the narinfo/nar from berlin.guixsd.org
<civodul>see the doc of --cache at https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-publish.html
<fps>soooo, is there another API to get the latest "pastry"?
<civodul>nope :-)
<civodul>but see https://issues.guix.info/issue/33370
<fps>12:12 < JackWinter> wait until he gets into kimonos :)
<fps>oops
<fps>bad paste :)=
<fps> wget --no-cache https://berlin.guixsd.org/w7q2kp9bgngaivbll29mnr7jschz5flz.narinfo
<fps>i guess doing requests that ignore caching directives until the narinfo pops out is good enough
<pkill9>it appears from looking in gnu/services/xorg.scm that gdm has been added as a login service
<civodul>efraim: were you able to look at the gst-plugins-base failures on ARM on core-updates?
<civodul>fps: 'guix publish' responses contain a 'Cache-Control' header that you should honor
<civodul>even for 404 responses
<civodul>namely, 404 responses that triggered "baking" have a short expiry
<civodul>200 responses have an expiry that corresponds to the availability that the server guarantees
<xelxebar>Has anyone thrown together a guixsd image for Google Compute Engine (GCE) yet?
<xelxebar>I came across a discussion on the mailing list about this from last year but it didn't seem to come to any conclusion.
<xelxebar>I'll probably try to give it a go if it's not been done yet.
<civodul>xelxebar: there's a QCOW2 image at https://gnu.org/s/guix/download/ but i don't know if it's suitable for GCE
<civodul>but yeah, you could certainly revive that discussions
<civodul>-s
<xelxebar>Sounds like a fun project!
<fps>civodul: ok
<efraim>civodul: I haven't looked at it past the same orc tests failing for 1.14.3 and 1.14.4, both with the scary assembly output
<pkill9>yesss i got startx working, found the path to the generated xorg config with `pkill -fa slim`
<civodul>efraim: should we report upstream?
<civodul>i looked into that but they've changed bug trackers and all
<efraim>I can look into it more tonight I think
<efraim>I think I almost have x265 multilib in a workable state
<apteryx>hello Guix!
<apteryx>I'm packaging some software called Glad; it's designed to generate source files which can be compiled into a Vulkan/OpenGL loader. It's made with Python. Should I call it "glad" or "python-glad"?
<efraim>Is it used as a stand alone program?
<apteryx>I'd think "glad", since it's not intended to be used as a Python library but some stand alone program, right?
<efraim>s/is it/can it
<apteryx>yeah, the normal use case is to call it with python -m glad or just glad
<efraim>Just 'glad' sounds good to me
<apteryx>OK! Thank you.
<apteryx>Does a origin's snippet need to end with #t like build phases?
<efraim>It should
*civodul adds a --with-branch package transformation option
<jlicht>How do folks around here build/sign/package/use firefox extensions in icecat?
<jlicht>loading extensions from AMO (mozilla) sometimes complains about corrupt data
<jlicht>civodul: what is the use of the new option?
<civodul>jlicht: you could do things like "guix build guile-next --with-branch=master", and it builds from the tip of master
<civodul>the use case is continuous integration or testing
<civodul>like when you want to rebuild a software stack against the latest commit of a package deep down
<jlicht>oh, and convenient building core-updates things :-)
<jlicht>without juggling multiple checkouts
<civodul>hmm that i'm not sure :-)
<civodul>anyway, colleagues of mine wanted that and it's something where Guix can shine i think :-)
<jlicht>ah, you mean the branch of the package itself
<civodul>yes
<efraim>my aarch64 board is too truthful, I'm trying my x265 changes with --system=armhf-linux and I got: CMAKE_SYSTEM_PROCESSOR value `armv8l` is unknown
<pkill9>does the xorg-start-command function in gnu/services/xorg.scm rely on the startx package? I want to fix the startx package so it can be used
<pkill9>but don't want to break anything
<roptat>civodul: thanks for the link!
<roptat>that's a reason why we should avoid getting sources from repo.maven.org
<jlicht>civodul: I'm assuming you can put any `git checkout <...>` thing in the --with-branch transformer :-)?
<roptat>one of my new colleagues is into nix/nixos, so we decided to give an informal presentation about functionnal package management to the rest of the team
<roptat>I've been hearing a lot of complaints about opam lately :)
<roptat>that might be a good opportunity to convert some people ^^
<roptat>btw, our opam importer is still broken...
<civodul>roptat: heh, the opam devs should be receptive to functional package management, we should talk to them as well
<roptat>I'd need to download and decompress opam.ocaml.org/index.tar.gz, but I don't know how to do that
<roptat>http-fetch/cached returns a port to the file, which is not what I want (I think)
<civodul> https://issues.guix.info/issue/33522
<jlicht>`define-gexp-compiler' does its thing and stores the result in %gexp-compilers, right?
<fps>civodul: sooo, berlin.guixsd.org serves substitutes under http://berlin.guixsd.org, i.e. i should be able to sometime get e.g. https://berlin.guixsd.org/guixsd/47mywzkg9mss9yirbnnkzil4z2jsyw5z.narinfo?
<fps>oops
<fps>with the /guix/ removed. that just slipped in from testing if possibly the susbtitute-url is different
<fps>there's no Cache-Control header in there, so i suspect i got the wrong URL
<fps>or is there a hint in the output of curl https://berlin.guixsd.org/api/latestbuilds?nr=10 | jq . as to whether a build output will eventually turn up on mirror.hydra.gnu.org or some other server?
<civodul>fps: try this: wget -q --debug -O /dev/null https://berlin.guixsd.org/p9wm67w3rfw3hlb9iljgvsfn84mz4w9d.narinfo 2>&1 |grep ^Cache
<roptat>civodul: if I run your code twice and the master branch corresponds to the same commit, the result gets the same hash, right?
<roptat>maybe I can use that to import the opam package repository in the store and analyse it to import things from there
<demotri>efraim: Does that mean you will try out arc-theme on core-updates?
<efraim>demotri: unfortunately no, I don't think my computer can handle it
<demotri>efraim: OK, then I will try to free some space, or someone else will give it a try in the meantime.
<civodul>roptat: if you run it twice and the tip of the branch is the same, you get the same result, yes
<roptat>so that's exactly what I want
<efraim>x265 looks like it hates armhf-linux
<efraim>ok, I got it to build
<civodul>yay!
<efraim>now the fun part, splitting it into 3 patches
<efraim>and testing that it doesn't break ffmpeg or something
<civodul>well thanks for working on it
<efraim>i also got multilib to work i think
<civodul>hmm?
<efraim>x265 has 8- 10- and 12-bit modes
<civodul>oh, sounds fun
<efraim>we now have all 3 as .so files and .a files, I wasn't able to join all the static libraries into one
<efraim>and I put the static files in their own output, it was more than 50% of the output
<civodul>maybe we don't need the .a at all
<civodul>if it has a --disable-static option or similar, we should simply do that
<efraim>it does, I could just disable it across all the libraries
<efraim>actually, it looks like shared is optional
<pkill9>does guix not run X rootless?
<pkill9>it seems not if you're using the login manager service
<pkill9>atleast with slim, haven't tested other login managers
<apteryx>efraim: thanks
<apteryx>I asked this question before but I'm afraid I forgot: what is the distinction between guix pack --system vs guix pack --target?
<apteryx>Ah, I think I understand; --system is for targets that my arch natively support, e.g. x86 instead of x86_64
<apteryx>and --target is for a completely different, incompatible architecture, e.g. building ARM packages on X86_64
<tune>I installed the font-ibm-plex package but I don't know how to use it anywhere
<tune>doesn't show up when I do fc-list | grep -i plex
<tune>I even did fc-cache -f
<vagrantc>efraim: so, sounds like the OpenGL vs. GLES debate is still unresolved ...
<efraim>vagrantc: yeah, I saw. I'm leaning opengl atm
<janneke>how do i get the "jdk" output of icedtea-8 inside a gexp?
<janneke>(string-append #$icedtea-8 "/bin") gives me java...i cannot seem to get the bin dir of javac
<efraim>I'm considering offering help for the both option, not a DD though
<vagrantc>efraim: i doubt that would be much of a barrier, if you've got the energy and skills :)
*janneke tries '(#$icedtea-8 "jdk") ...
<vagrantc>oh dear
*janneke sent a real beginers question to help-guix
<vagrantc>guix pull -l .... Generation 1 Nov 27 2018 12:12:28 (current) !!!
<vagrantc>wow. days in the making.
<janneke>\o/
<vagrantc>i now usefully have guix on a virtual machine on the pinebook :)
<tune>is ~/.guix-profile/share/fonts supposed to be owned by root?
<tune>also I found ibmp plex in the opentype directory in there, but it doesn't show up in lxappearance or fc-list, so I don't know how to use it in my terminal or anything
<efraim>looks like ccl on armhf thinks its armv6
<vagrantc>and substitutes are working! yay!
<janneke>tune: everything in the store is owned by root
<vagrantc>although it's only substituting tarballs ... hrm.
<tune>okay
<tune>I don't understand why just installing the font didn't work, really annoying
<tune>I've installed another font in the past
<janneke>did you run fc-cache -f?
<tune>yeah
<tune> https://paste.debian.net/plainh/d17149fb I wonder if these lines saying "skipping, looped directory detected" are the problem
<tune>might just be because they were scanned further up
<pkill9>which fonts did you add tune?
<vagrantc>any suggestions on a way to get "guix system init ..." to copy all the available items in the store?
<vagrantc>often times, when i run it for a new install, then when i guix pull from the new system, it has to rebuild all sorts of items in the store that were already there
<vagrantc>or, were already present in the store of the system used to run guix system init
<vagrantc>or is it safe to simply rsync -avP /gnu/store /mnt/gnu/store at the end of an install?
<vagrantc>or is there some other information needed?
<tune>pkill9: this time I'm trying to install font-ibm-plex, in the past I've managed to install terminus just fine
***rekado_ is now known as rekado
<rekado>vagrantc: there’s the database.
<rekado>the contents of /gnu/store are ignored if they aren’t registered in the database as well.
<ngz>rekado: Hello. ISTR you said Scribus was still failing in core-updates. Could <https://github.com/scribusproject/scribus/commit/d867ec3c386baaed1b8e076dd70b278863411480> be an appropriate fix?
<ngz>Hydra hasn't built Scribus again yet, so I cannot check build log.
<vagrantc>rekado: got it
<ngz>rekado: no worries if you don't have time to look at it at the moment, btw.
<bavier`>oh, 'guix refresh --list-updaters' assumes the updater predicates are disjoint
<sneek>Welcome back bavier`, you have 1 message.
<sneek>bavier`, efraim says: I tried before with gccgo but it also needs gold, even for 'gccgo as the go binary'
<bavier`>let's see if that makes a difference...
<rekado>ngz: yes, this looks like a fix.
<rekado>(or maybe a partial fix; I thought there mere more GooString instances)
<rekado>ngz: thank you for that. I’ll try to build it with this patch.
<ngz>Great!
<bavier`>yup, 'guix refresh --list-updaters' is 5.4% too optimistic