IRC channel logs

2018-11-12.log

back to list of logs

<cbaines>civodul, great :)
<cbaines>Your find command looks to have worked as well, I've managed to boot without issue now :D
<pkill9>can i post a patch using the output of `git diff`? i can't remember exactly how i did it last time
<pkill9>can't remember if there's any flags
***ngz` is now known as ngz
<ngz>Hello. I have a package that complains about "ld: cannot find -lglew" at the end of the compilation process (CMake build system). I added glew to the input to no avail. Is there a common workaround for that issue?
<cbaines>At least with my upgrade SSD, my system comes back to life after the python package build kills it :/
<cbaines>I think before I managed to kill the tests during the package build... but I'm struggling to replicate the same feat without htop, which I can't build without python :(
<civodul>cbaines: great that it worked! that was a nasty bug...
<civodul>cbaines: re python, do you take substitutes from berlin.guixsd.org?
<civodul>ngz: i'd check in the 'environment-variables' file whether glew really is in $LIBRARY_PATH
*civodul -> zZz
<cbaines>good reminder about berlin, I haven't added the key yet
<cbaines>and yep, it's downloaded a substitute now
<cbaines>I'll try guix pull again...
<ngz>I'm not sure to understand civodul's advice.
<cbaines>ngz, if you pass --keep-failed when running guix build, in the build directory, you should see the environment-variables file
<ngz>OK. And what if glew isn't in $LIBRARY_PATH?
<cbaines>Try and work out why, maybe the LIBRARY_PATH is explicitly set in one of the phases?
<ngz>Not in my package definition, or so I think.
<cbaines>or maybe the glew package doesn't contain a lib or lib64 directory in the root of the output?
<ngz>hmmm I don't understand that either, sorry.
<cbaines>I've just built the glew package, and I can see /gnu/store/fv3qqs0sli6nwihzv5488jd8za3zf9fb-glew-2.0.0/lib which is the thing that should be appearing on the LIBRARY_PATH
<cbaines>Is this a new package?
<ngz>Yes
<ngz>I'm trying to unbundle stuff, including glew.
<cbaines>Ah, maybe there's some specific logic for glew in CMakeLists.txt (or whatever cmake uses)
<ngz>There is no option to use system's glew, unfortunately.
<ngz>I have to unbundle the hard way
<cbaines>If you can identify the problomatic bits, you might be able to cut them out
<cbaines>I guess by default it should just use the system glew
<cbaines>(without whatever is stopping it doing that)
<ngz>glew is in LIBRARY_PATH
<ngz>I just checked.
<ngz>Oddly, the compilation uses "c++ ... -I/path/to/bundled/glew/include"
<ngz>I need to find how this command is built.
<cbaines>Good luck :)
<cbaines>I'm off to get some sleep...
<apteryx>my network is so unstable... I keep having to hit 'sudo herd restart netwoking'.
<apteryx>cbaines: o/
<ngz>cbaines: OK. Thank you for the guidance anyway :)
<apteryx>again :/
<apteryx>wow, I think I finally got rid of my annoying networking issue.
<apteryx>hm... I spoke too soon.
<apteryx>Nov 11 20:41:09 localhost dhclient: No DHCPOFFERS received --> followed by --> Nov 11 20:41:09 localhost dhclient: No working leases in persistent database - sleeping. --> then my network cuts.
<apteryx>My AP is configured to act as a DHCP server, and until the last message from dhclient my connectivity is working (I have an IP).
<apteryx>somehow now managed to get: Nov 11 20:41:49 localhost dhclient: bound to 192.168.1.111 -- renewal in 2147483648 seconds.
<apteryx>I should be good for a while although I'd like to understand this erratic behaviour...
<apteryx>nope... Nov 11 20:46:12 localhost dhclient: DHCPDISCOVER on wlp18s0 to 255.255.255.255 port 67 interval 3
<apteryx>it's going down again...
<apteryx>I've booted in a previous generation from september (Linux 4.18.7). So far I'm not experiencing the NetworkManager/dhclient DHCP lease issue.
<pkill9>.
***apteryx_ is now known as apteryx
<quiliro>quiliro
<pkill9>i forgot to add '[PATCH]' to the beginning of the email subject for the patch i sent >.<
***rekado_ is now known as rekado
<rekado>sneek_: botsnack?
<thorwil>hello guix!
<thorwil>caps-lv2 happens to be structured such that each plugin has its own dir in "plugins", with a Makfile in it that contains "PREFIX = /usr/local"
<thorwil>do i have to make a list and do a (substitute* ...) for each, or is there a better way, maybe one allowing use of wildcards?
<thorwil>well, looks like a combination of for-each and find-files should do
<roptat>thorwil: (substitute* (find-files "*/Makefile" (("/usr/bin") (assoc-ref %outputs "out")))) or something
<roptat>the firts argument to substitute* can be a list
<nly>Is anyone using guixsd (or guix) on arm?
<roptat>I tried, but it never booted properly :/
<nly>Thanks, still thinking if i should use a small laptop or arm
<thorwil>roptat: ah, thanks!
<snape>The output of 'guix refresh --list-dependent postgresql' is "Building the following 267 packages would ensure 501 dependent packages are rebuilt" -> what is the number of dependent packages, 267 or 501?
<snape>maybe the 267 packages are the direct dependencies (those that explicity have postgresql as input) and the other one are induced
<snape>Hmm that doesn't make sense (there are very few packages with postgres as direct input)
<efraim>qt is one of them
<roptat>snape: 267 are the leaves, and 501 packages are part of the tree rooted at postgresql
<roptat>since specifying a leaf builds modified dependencies (recursively until postgresql), it's only required to specify a list of leaves, not the complete list of dependents
<snape>roptat: I get it, thank you for that explanation!
<roptat>if you want a nice graph of that, you can run "guix graph -t reverse-package postgresql > postgres.dot"
<snape>nice, it shows well that the responsible for all the dependencies is qt
<roptat>maybe we could break qtbase into several packages?
<roptat>like, I don't think every qt application needs audio or databases?
<rekado>can this be done?
<rekado>I thought qtbase already is the result of breaking up the much larger Qt.
<roptat>I don't know
<roptat>qtbase consists of a few libraries
<roptat>most of which are static
<rekado>it would probably be possible to split it into different outputs, but this wouldn’t let us cut dependencies.
<roptat>maybe you're right
<g_bor>hello guix!
<g_bor>civodul, rekado: are you here?
<rekado>I’m here.
<g_bor>Hello rekado!
<jlicht>hey guix
<g_bor>I currently see on the Outreachy page that we are waiting for coordinator approval for one of our applicants.
<rekado>oh.
<rekado>let me check.
<rekado>it’s about sponsorship info, right?
<g_bor>yes, that is right.
<rekado>I find the website very hard to navigate…
<rekado>g_bor: I don’t see anything I can do on the dashboard
<rekado>could you send me a URL where I should approve the applicant sponsoring?
<g_bor>I can send you were I see the message: https://www.outreachy.org/december-2018-march-2019-outreachy-internships/communities/gnu-guix/create-user-video-documentation-for-gnu-guix/applicants/
<g_bor>I see these messages there: Coordinator funding decision: Funding source undecided and Intern pending organizer approval
<g_bor>the second message does not seem relevant.
<rekado>thanks
<rekado>g_bor: could you please check if this is okay now? I just edited the sponsorship info.
<g_bor>I still see Funding source undecided, but it might propagate with some delay.
<rekado>In the community status I see “This community has funding for 1 interns.”
<rekado>maybe I need to associate the funding with a particular intern.
<g_bor>I think that is correct.
<g_bor>I will have lunch now, see you later!
<rekado>hmm, I still don’t see where I would assign the funding source. Frustrating.
<rekado>one of the disks in the storage array already broke. Using a hot spare now. Gotta ask Dell to send a replacement.
<jonsger>rekado: are those used or new disks?
<g_bor>rekado: Actually there is an ambiguity in the text I see.
<g_bor>It is this The deadline for selecting an intern is Nov. 12, 2018 at 4pm UTC. Once mentors select their interns, the community coordinator will need to assign funding sources. The Outreachy organizers will then approve the intern selection and funding source.
<g_bor>So, it is possible that you will only see that only after this deadline is passed.
<g_bor>But it is not clear to me...
<g_bor>If this is the case, then I can send a report and propose a clearer text. WDYT?
<g_bor>(i.e. it is not clear that coordinators see the founding allocation only after this deadline, and it is also not clear what deadline applies to allocating founding)
<g_bor>ok, I've found this: Deadline Nov. 12, 2018: Coordinators decide which interns will be funded from the available sponsorship funds, and which interns won't be funded. If the organization wants to accept more interns than they have sponsorship funds, the coordinator can mark the intern asking for Outreachy general funds. This community has sponsors who will fund up to 1 interns.
<g_bor>it is at: https://www.outreachy.org/december-2018-march-2019-outreachy-internships/communities/gnu-guix/applicants/
<g_bor>rekado: sorry for the confusion, it seems that information is scattered.
<g_bor>The deadline is today, 4 pm UTC.
<g_bor>rekado: Should I contact the mailing list and ask for help?
<rekado>I think I’ve done it.
<rekado>could you please check again?
<g_bor>yes, rekado, that's it!
<g_bor>Thank you.
<g_bor>Would you like to recommend something to document about this? It seem that this site is sometimes confusing...
<rekado>I don’t really know what I did differently this time…
<g_bor>:) oh, yes, that is part of the confusion...
<g_bor>also, for example the deadline spec is missing the 4pm UTC on this site...
<g_bor>I just remembered that for an earlier proposal...
<g_bor>Thanks anyway!
<rekado>hmm, some messages I get from debbugs are just bytevectors.
<rekado>nasty.
<rekado>that’s why issues.guix.info/issue/22039 doesn’t render right.
<g_bor>hello guix!
<g_bor>I have a problem.
<g_bor>After a guix pull to core-updates I get a backtrace.
<g_bor>But only after I get the new in this revision...
<g_bor>I will try it again...
<g_bor>well, the backtrace is gone...
<g_bor>fine.
<rekado>huh
<roptat>hi civodul. I'll be able to come for the guix meetup before r-b summit, but I won't be able to attend the summit itself because I took too much time to think about it
<rekado>I have a user ask about libc++ for use with clang. Our “make-libstdc++” procedure only works with GCC. Does anyone know more about clang/llvm to tell me how clang + clang-runtime + llvm are supposed to be used with libc++?
<civodul>hello!
<civodul>roptat: it's great that you can come to the meetup!
<civodul>feel free to add your name and any topics you'd like to talk about on the wiki page
<civodul>we'll do it "unconference"-style, as people say ;-)
<civodul>rekado: AIUI Clang can link either against GNU libstdc++ or against libc++ (Clang's library)
<civodul>i'm not sure what we're doing by default
<rekado>roptat: are there no free slots any more for participating in the r-b summit?
<rekado>I delayed a decision there as well…
<rekado>civodul: I see. The clang packages seem to noly link with gcc:lib, but this doesn’t include libstdc++.
<roptat>rekado: I sent an email to register today, and the answer was "you're in fact a bit late and we're pretty packed already"
<roptat>they will contact me again if they can accept more people, but said it was unlikely
<rekado>I see.
<rekado>oh well.
<rekado>this time I was just too busy and since we have a few Guix people attend the summit I felt it was okay for me to take it easy ;)
<rekado>but maybe I could attend the guix meetup before
*civodul added a tentative "logo" at https://libreplanet.org/wiki/Group:Guix/ParisGathering2018
<civodul>i wanted to add some sort of an Eiffel tower, but obviously i'm not an artist
<jonsger>civodul: it's fine, but the image is a little huge
<civodul>true!
<civodul>lemme see
<apteryx>civodul: haha :)
<rekado>big is beautiful
<civodul>should be better now
<civodul>well, at least the size should be better :-)
<civodul>(if someone wants to make a better Guix-based Eiffel tower, i'm interested :-))
<apteryx>civodul: can we make an eiffel tower drawn with lambdas?
<apteryx>I could probably make it look worse... ;)
<civodul>apteryx: we could do that too
<civodul>heh :-)
<pkill9>why are all th epackages being updated to fetch sources from git instead of what they were before?
<rekado>pkill9: because the /archive/ URLs from github provide generated tarballs, which are not stable over time.
<rekado>they have changed in the past, leading to breakage due to hash mismatches.
<rekado>in the absence of developer-uploaded release tarballs it is safer to fetch the sources from git.
<pkill9>ah
<snape>Hi, I have cache issues. I need to rm /var/guix/substitue/cache every time I build something, otherwise guix doesn't fetch substitutes. And it seems that 'guix package -m manifest.scm' messes up with the cache.
<snape>Could someone give me a hint on how to troubleshoot it?
<snape>civodul, rekado: for some reason guix-modular evaluations fail on Berlin. (And they succeed on my machine...)
<rekado>snape: civodul wrote yesterday that this seems to be a hook failure, not an actual build failure.
<apteryx>rekado: congrats for the successful deployments of new disk arrays :)
<rekado>apteryx: thanks, I hope it’ll last. We’ll need to make a few changes to Guix to make this setup a little easier to maintain.
<mbakke>rekado: Commit a7e231a2a3edbd6a70949432c1ff434d87f625ff broke a lot of Haskell packages on core-updates.
<rekado>hmm, this means that a lot of packages previously passed the build by accident, no?
<rekado>civodul: do you plan to have dinner together on Dec 10? I’m looking for a bus connection to/from Berlin and the last bus back to Berlin is at 7:35pm.
<mbakke>rekado: I don't think so, the error is about missing dependencies, but it does not show up when reverting the commit.
<rekado>there’s a problem with GHC.
<rekado>we already suffer from miscompilation when substitutes are taken from different build farms.
<rekado>the commit itself shouldn’t cause problems. I think it may just be the fact that we have to rebuild packages.
<rekado>ghc-pkg doesn’t create a deterministic package database
<rekado>and I think that’s what’s biting us her.
<rekado>*here
<mbakke>rekado: I get the same error as Hydra, but have not used any substitutes from there.
<mbakke>E.g. https://hydra.gnu.org/build/3150930
<civodul>rekado: dinner would be nice, yes!
<civodul>i don't have any concrete plan but i'll look into it "in due time" :-)
<civodul>also on Dec. 9 if people are around (i'm arriving in the afternoon)
<mbakke>rekado: Reverting the build system commit makes the build succeed.
<rekado>mbakke: I looked through the diff again and it looks totally fine to me.
<mbakke>rekado: I can't tell what the problem is either.
<rekado>this modification should not cause the behaviour of the build system to change.
<rekado>civodul: do you know of any cheap places to stay at? (E.g. campus guest rooms?)
<rekado>mbakke: I’ll try to play with this tonight or tomorrow in between packing up boxes for the move :)
<mbakke>rekado: Great :-)
<civodul>rekado: no, sorry
<civodul>i could ask colleagues if they have ideas
<rekado>hmm, one thing that bothers me is that on core-updates we still display this ugly invoke backtrace.
<rekado>I thought we had fixed this already.
<rekado>civodul: ah, no worries.
<rekado>civodul: I’ll look for something.
<civodul>ok!
*rekado doesn’t know how best to get there…
<civodul>i like train but it might take quite a bit of time...
<rekado> bus takes 12 hours, but is direct; the train connection is unnecessarily complicated; flight is direct but wasteful (and far out)
<mbakke>rekado: Could there be a race between the call to run-setuphs and the missing config file case?
<rekado>CO2 emissions for the bus route are ~30kg; for the flight it’s half a ton.
<civodul>there's no direct train?
<mbakke>civodul: Can you cancel this job? https://hydra.gnu.org/build/3152167
<rekado>civodul: surprisingly no!
<civodul>woow
<mbakke>Hmm looks like guix.sjd.se may be low on disk space.
<mbakke>It has been flaky the last few days.
<snape>rekado: what is a hook failure?
<civodul>mbakke: done (the hard way)
<mbakke>civodul: Thanks!
<civodul>mbakke: guix.sjd.se seems to have enough space available
<rekado>mbakke: no, I don’t see how there could be a race. A “configure” script only exists in some packages. Or do you mean that “ghc-pkg --package-db=… recache” might not be finished by the time the “configure” phase starts?
<mbakke>civodul: OK, great.
<mbakke>rekado: I don't know, just grasping at straws :-)
<rekado>I’ll try to reproduce this next and then we’ll see.
<rekado>It may become necessary to patch GHC.
<mbakke>rekado: The "lib/ghc-8.4.3/$name.conf.d" directory is missing on packages built with the faulty commit.
<mbakke>I.e. the "register" phase does the wrong thing, and thus dependents cannot find the library.
<mbakke>Instead it drops a .conf file on the top level store directory.
<mbakke>So what is the difference between (or (not foo) (begin bar)) vs (unless foo bar) ?
<roptat>rekado: it seems they can take 5-10 more people after all, so I'll be at r-b summit!
<civodul>woohoo!
<swedebugia>rekado, I think I spotted a missing #t in end of the arguments phase of numpy, L3096 python.scm
<apteryx>swedebugia: you could send a patch for it :-)
<apteryx>I think 'guix lint' warns about those right?
<bavier>mbakke: the first will return the truthy value of (not foo), whereas the second will return an undefined value
<bavier>in case anyone is wondering, i think I figured out why our qutebrowser is broken, but I haven't figured out how to fix it yet
<swedebugia>apteryx, is it only in the end of bodys of (lambda proc that we need this #t?
<swedebugia>apteryx, sounds good if the linter picks these up.
<bavier>the issue is that our python-pyqt, despite declaring qtwebkit as an input, doesn't actually build the qtwebkit bindings
<apteryx>currently every build phases must return #t upon success, or throw an exception in case of errors.
<snape>swedebugia: but in your case, the phase already returns true
<snape>what you can do though, is to replace (zero? (system* with (invoke
<snape>because invoke will throw an exception on failure
<swedebugia>snape, thanks :) Does the linter warn about "(zero? (system*" too?
<efraim>Not yet
<roptat>speaking of which, I think some build systems still use (zero? (system* ...))
<lfam>Hm, with the new Go 1.11 build system, Syncthing failed its tests the first time, but succeeded on the second run. The test was 'github.com/syncthing/syncthing/lib/model' and the successful run took ~42 seconds (!)
<rekado>mbakke: ah!
<rekado>it should totally be “when”, not “unless”
<rekado>(or (not …) …) really confused me
<rekado>had it been (and this that) it would have been clearer
<rekado>it should be (when (file-exists? …) do-things-with-file)
<janneke>roptat: yay!
<rekado>roptat: even on core-updates?
<roptat>not sure about core-updates
<rekado>mbakke: thanks for the crucial hint about the haskell-build-system error. I’ll push a fix to core-updates in a moment.
<roptat>on core-updates, ocaml, dub and cargo build systems still use system*
<rekado>okay, we should fix those
<rekado>this wouldn’t affect too many packages, I think.
<roptat>there seems to be a few uses in guix/build/{bournish,ruby-build-system,rpath,git,utils} too
<roptat>need to go, but I'll try to work on that
<rekado>pushed the haskell-build-system fix to core-updates. Thanks again, mbakke!
<rekado>roptat: I could also fix this now.
<rekado>actually, I think we may want to delay the change to the cargo-build-system as building rust and icecat takes so very long.
<rekado>huh, we have a dub-build-system but no package that uses it.
*jonsger doesn't know any real world application written in D...
<pkill9>does guix's `rename` take regex? I can't seem to match regex
<efraim>I applied at a company that used D, can't for the lift of me remember what they did though
<lfam>pkill9: The Guile procedure index is useful for answering this kind of question: https://www.gnu.org/software/guile/manual/html_node/Procedure-Index.html
<lfam>pkill9: In particular: https://www.gnu.org/software/guile/manual/html_node/File-System.html#index-rename
<lfam>It doesn't say if it accepts regex or not, you may have to check the implementation to be sure
<pkill9>lfam: I wasn't specific enough, i meant the supplied package `rename`, not guile's `rename`
<lfam>Ah
<pkill9>rebuilding rename with newer source fixed it
<pkill9>i guess rename hasn't been updated as it would trigger a mass rebuild of pretty much everything lol
<pkill9>well i suppose it could be grafted, but i guess nobody needs it that much
<lfam>The Perl implementation? Or the one from util-linux?
<lfam>I don't think anything depends on the Perl one, unless I am missing something
<pkill9>the perl implementation i think, the package named 'rename'
<rekado>jonsger: sambamba is written in D.
<mbakke>rekado: Excellent, thanks for the quick response!
<Laalf> https://wiki.gnome.org/Projects/GnomeBluetooth says that there is an applet built into gnome-bluetooth. how can i launch that?