IRC channel logs


back to list of logs

<brendyn>dtluna: I'm also on Parabola
<dtluna>brendyn: does it emit this message?
<brendyn>dtluna: Yeah
<brendyn>I think that message is coming from the daemon runnin as root
<mark_weaver>dtluna: tell me the version of glibc indicated by the command: ldd /root/.guix-profile/bin/guix-daemon
<mark_weaver>dtluna: and tell me what directories are present in /root/.guix-profile/lib/locale
<dtluna> => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ (0x00007feec4f89000)
<dtluna>no directories
<mark_weaver>oh, well, that explains it
<mark_weaver>you need to install glibc-locales in root's profile
<mark_weaver>dtluna: you need to install glibc-locales in root's profile
<mark_weaver>(glibc-utf8-locales might also be sufficient, depending on your locale setting)
<dtluna>mark_weaver: installing glibc-utf8-locales
<dtluna>The manual says NOTHING about this BTW
<mark_weaver>dtluna: I don't appreciate your tone.
<dtluna>mark_weaver: the problem is still there
<mark_weaver>anyway, the warning is harmless
<ng0>how do we treat software which has the company name in it? the (R) needs to go, but $company - $programm is still something we should name it, right?
<brendyn>I suspect we may have similar issues because we are both on Parabola. mark_weaver One odd thing I get is that guix running as root uses my /home/b/... profile. For example guix package -i hello: outputs error: directory `/var/guix/profiles/per-user/b' is not owned by you
<dtluna>mark_weaver: oh wait, the problem might be that there is no ru_RU.utf8 locale yet for Guix
<brendyn>I setup all the symlinks as per the manual so I'm not sure what I did wrong.
<mark_weaver>dtluna: that locale is certainly not in glibc-utf8-locales, which is quite minimal
<mark_weaver>glibc-locales might have it
<dtluna>mark_weaver: thanks
<dtluna>mark_weaver: and what is wrong with my tone?
<mark_weaver>dtluna: quotes like "GNU Guix should step up its game" and "The manual says NOTHING about this BTW", make you sound very annoyed and entitled to service from us.
<ng0>constrcutive criticism and improvement is welcome. capslock make it harder.
<dtluna>mark_weaver: I am just pointing out what should be improved.
<mark_weaver>the issue I have is the way you said it. but anyway, no need to dwell on this.
<dtluna>mark_weaver: well, I am sorry, I am not a native speaker.
<dtluna>But you seem sensitive, anyway.
<mark_weaver>dtluna: it's okay, fair enough.
<ng0>you what intel... sh ../../build/ ./test_malloc_overload_proxy.exe
<ng0>exe in tests? kay..
<dtluna>It would be awesome if Guix showed the progress of the download
<ng0>what is this.. it runs .exe files and they succeed.
<brendyn>dtluna: I think it counts upwards at the moment ;P
<ng0>or maybe the .exe ones silently fail in a non-fatal way and just say 'done'
<dtluna>brendyn: I kinda want to know the percentage of downloaded
<ng0>I feel trolled by this intel build.
<brendyn>dtluna: It can be added. I think there any many ways to improve the terminal output of guix
<dtluna>brendyn: the only problem with me doing it is Guix being written in Guile :)
<brendyn>dtluna: That's not considered a problem in these parts
<dtluna>brendyn: I mean I don't know anything about LISP
<brendyn>dtluna: Currently I'm still learning guile. I've made a couple package definitions, but I'm not good enough to hack on guix its self yet.
<dtluna>brendyn: shouldn't be too hard tbh
<brendyn>dtluna: You can start by learning to make package definitions if you like.
<dtluna>brendyn: I'll see. Maybe a pygnusocial package would be good. But it requires python 3.5 which is not yet in the repos, surprisingly
<brendyn>dtluna: Would you like to package python-dropbox?
<dtluna>brendyn: no, because Dropbox is awful
<brendyn>Is it not ok to provide support for it?
<dtluna>I suggest you use Syncthing which is free software
<dtluna>brendyn: It is proprietary and you should not use it.
<brendyn>dtluna: Yes, but isn't python-dropbox free software?
<dtluna>Brendyn: maybe. But I personally won't promote anything directly related to Dropbox
<brendyn>I'm not too familiar with it so I'm wondering if it is best to include or not
<dtluna>Use Syncthing. It's much better
<brendyn>I'm not asking about software to use. I'm packaging software that can use dropbox
<dtluna>Where can I see what needs to be done to package Python 3.5?
<brendyn>dtluna: Look on the mailing list. search it for any mentions of python. Then get the guix git repo and have a look in gnu/packages/python.scm
<brendyn>It looks like many people have packaged python software, so most like some people are already working on it
<dtluna>brendyn: thx
<demotri>I hacked togehter my first package: proj.4. It's fine on x86_64 but has test failures on i686.
<brendyn>demotri: Can you upload it?
<demotri>It's not a patch, it's just a package definition, I build it with 'guix build -f proj.4.scm'.
<brendyn>It looks like you malformed the text. the testvarious like is cut off
<demotri>brendyn: Ah, sorry. Hope it works now:
<ng0>wow.. this make all with all the checks and tests takes long
<ng0>30 minutes now... it's not the default, the default does not run the checks.. I think i should disable this.
<ng0>this isparallel computing targeted i think, so i think hpc's etc are the thing where this will run much faster
<brendyn>ng0: maybe there is some option like make -j4 ?
<ng0>what if the build machine has less cores? thisshould not be set i think
<ng0>and even when I do, I seriously doubt this will speed up testing.
<ng0>30+ minutes testing is something admins of HPCs can enable themselves.
<lfam>dtluna: Python 3.5 is on our core-updates branch, where we test updates to core packages
<lfam>dtluna: So, you could cherry-pick the relevant commits to a local branch and build your packages based on that, if you wanted to
<brendyn>lfam: dtluna quit the channel. Use tab complete when typing peoples names and you will discover that ;)
<lfam>Oh, dtluna left
<brendyn>Do you read public chat logs?
<lfam>Only for Guix
<lfam>So I can respond to questions related to things I work on
<brendyn>demotri: Honestly I have no idea why that test fails for i686
<brendyn>demotri: But to let you know, I get the same result
<demotri>brendyn: OK, thank you. At least this part is reproducible.
<demotri>What should I do next? Would the package be acceptable if it fails on 32-bit? Should I talk to upstream?
<brendyn>demotri: If you use the -K flag you can keep the build directory and poke around in the directory like /tmp/guix-build-proj.4-4.9.3.drv-3'
<demotri>brendyn: Thank, I know already '-K', without that I wouldn't be at that point :-)
<brendyn>demotri: Look it up on a search engine
<demotri>brendyn: What I figured out is that under xa64 there is a src/.lib/lt-cs2cs and a src/.lib/cs2cs. Under 32-bit there is only the cs2cs-variant.
<brendyn>demotri: It looks like the numbers are different due to numerical precision differences between x86_64 and i686
<brendyn>demotri: Depending on the use case of the program, that may be possible to simply ignore, i.e, disable the test
<brendyn>As you can see, the test actually "succeeds" to 6 significant figures.
<demotri>brendyn: Well, the use case of the program is to transform coordinates with a very high precision. If it is used for land surveying, that could be too much of an error. Or at least indicate a bigger problem.
<demotri>brendyn: I will google again and then discuss with the maintainers.
<brendyn>Everyone seems pretty lax about it
<brendyn>also, why are you loading so many modules like gnome/
<brendyn>I suppose you copied it from an example.
<OriansJ>anyone else ever see a server with a ED25519 public key that produced an Identical sha256sum but two entirely different ascii arts?
<demotri>Ah, that is just copy/paste. I don't know from which package I started. I know, I really have to clean this up.
<demotri>I was just happy that it worked in the end on one platform.
<brendyn>ok no worries. ;) Essential (use-modules (gnu packages gnome)) loads the file gnu/packages/gnome.scm, making all the guile variables available. Currenly, you're only using (gnu packages glib) plus a couple others
<demotri>OK, I will clean it up and then post a patch.
<demotri>Thank you for your help.
<brendyn>demotri: Also config.sub and config.guess are gpl3+. You always have to do a license check. I typically use ack to scan through all files looking for 'license' and things like that
<brendyn>And then do a comparison of your package definition with debian/arch/gentoo or whatever.
<brendyn>src/PJ_patterson.c is Apache 2.0
<demotri>When comparing package definition, what do you mean?
<demotri>Ah, what I forgot: In Debian they have libproj, proj-bin, proj-java. I should add differnt outputs.
<brendyn>I mean take a look at the code debian uses to package it.
<demotri>You think of patches?
<brendyn>cmake/ is under some Boost license
<brendyn>For example, this is the Arch version
<brendyn>Maybe you want to name it "proj" instead of "proj.4"
<demotri>Officially it is "proj.4" (, but one of the commands is just 'proj' and Debian calls it just 'proj' too.
<brendyn>demotri: checkout everything here
<brendyn>As you can see, debian packagers are mad.
<brendyn>"The software was developed by the USGS and has no copyright
<brendyn> nor license. Do with it what you will."
<demotri>What do you want to tell me with the last sentence?
<brendyn>Nothing, just thought it was funny.
<brendyn>In the license section you want to put all the licenses you can find, brief comments naming the files under each license.
<demotri>What is the syntax for creating complex licenses? '((file . license) ...) ?
<brendyn>No, have a browse through some random .scm files and you will see how
<brendyn>(license (list license:expat license:gpl2+ ...))
<demotri>Thanks again. Have to go to bed now. Bye.
<OriansJ>anyone ran into this one before? guix refresh: error: build failed: the path `/gnu' is a symlink; this is not allowed for the Nix store and its parent directories
<brendyn>OriansJ: ls -lha /gnu
<OriansJ>gnu -> /san-mount/projects/guix
<brendyn>Well I guess that's the problem. It's a symlink, and It can't be ?
<OriansJ>I am just trying to understand why it can't be
<OriansJ>now I know I can simply sudo mkdir /gnu && sudo mount --bind /san-mount/projects/guix /gnu to fix the error message; I am just trying to understand why it happens at all
<brendyn>Well my only guess is that since guix/nix is making symlinks from /gnu to anywhere else, this could cause errors by linking A -> B and B -> A
<OriansJ>I guess that kinda makes sense in the Developers didn't want to deal with several potential problems way of looking at it. Someone may want to mention that in the guix documentation and the mount --bind solution works great fyi
<brendyn>Has anyone packaged pylint?
<bavier1>is it common for tools to write their --help output to stderr?
<janneke>bavier1: i think its wrong, but many tools do so
<bavier1>yeah, hard to grep and such
<bavier1>and then it apparently resets the output formatting of stderr, so a grep only shows "Binary file matches". ugh
<efraim>bavier1: I realized I also need to make sure to build and run the tests, another thing they do is not build&run the tests by default
<sapientech>hi all, after trying for a few days i have been unable to package, but i keep getting the following error
<lfam>sapientech: Did you find anything searching for that error message? "install: will not overwrite just-created"
<lfam>I like this bug. DOS libarchive with a gzip quine:
<Sleep_Walker>nice ;D
<Sleep_Walker>well, fork bomb triggered by tarball
<civodul>Hello Guix!
<sneek>civodul, you have 1 message.
<sneek>civodul, janneke says: seems file-system-/run/systemd is twice in %desktop-services
<efraim>we're 22 packages over my 5% failing rule
<lfam>Is there an "Intro to the Hydra web interface" I can read or watch?
<janneke>lfam: my thoughts eactly...efraim's comment had me dabble in for a bit and i felt lost
<efraim>i get lost easily, so I've pinned in firefox so I can see each build generation
<lfam>Is it expected for the encrypted-root-os test to fail?
<brendyn>efraim: What's this rule?
<efraim>There's a certain number of packages that are going to be broken at any given time, and I try to keep that number below 5% of the suceeding packages
<brendyn>efraim: Ah, such wisdom. So you manage hydra?
<efraim>no, I end up committing a lot of package updates so I try to make sure I don't break stuff
<lfam>efraim, how do you keep track of all the updates?
<brendyn>Do you package python stuff? I've made an update for duplicity but it seems to want pylint, which we don't seem to have.
<brendyn>I've never touched python before
<efraim>guix refresh helps a lot, and I have a couple of packages I keep an eye on
<efraim>I've ended up spending a lot of time with packaging python, don't actually know a lot of python though
<efraim>i don't have a copy of pylint in my GUIX_PACKAGE_PATH though
<brendyn>If a package was working fine, but then fails after a dependancy update, will hydra still serve the old binary substitute?
<lfam>brendyn: If you request to old package (before the dependency update), Hydra will serve it to you
<brendyn>But it will be deleted after the update?
<lfam>But, if you do `guix pull` and get the update, you will request the new, broken package.
<lfam>It won't be deleted from your local system. If you can't build the package, you will still have the working package in your profile
<lfam>Guix only deletes things when you run `guix gc`
<efraim>ACTION goes afk again
<rekado>How do I use "guix container exec"?
<efraim>brendyn: `guix import pypi pylint' looks like it gives a pretty good result, although I haven't tried building it yet
<civodul>rekado: it's meant to be used in combination with 'guix system container'
<civodul>or with 'guix environment --container'
<civodul>you give it the PID of the parent child process of 'guix'
<civodul>the one that's PID 1 inside the container
<civodul>this is getting interesting:
<gnuub1>what would be the preferred way to add a file to the xorg.conf.d ? there seems to be no procedure for it (at least on the manual page Xwindow )
<brendyn>gnuub1: Perhaps the same way you add a file to /bin?. (install-file "file.conf" (string-append (assoc-ref %outputs out) "/share/X11/xorg.conf.d")
<rekado>civodul: ah, I see. Thanks.
<gnoob1>ok thx... i tryed to extract that information somewhere, but there aren't any examples :)
<gnoob1>it is hard for me to figure that out without examples :P
<brendyn>gnoob1: Yeah, I the manual it's self doesn't have exampes, but don't forget there are 4000 "examples" in the git repo of real packages.
<gnoob1>yup... i was working through the git repo...
<brendyn>Personally I often run stuff like `ack xorg.conf.d -A 5 -B 5' and that will instantly show every single file referencing that string.
<gnoob1>that makes sense
<brendyn>(assoc-ref %outputs out) refers to the /gnu/store/...package-x.x.x/ directory, which is effectively /. When you install a package that that gets mapped onto the root of your profile
<gnoob1>i know
<gnoob1>the structure is pretty clear to me, i just have still some issues with the guile syntax, esp. if i need to write stuff from scratch
<brendyn>Well I'm still learning too.
<gnoob1>thx , cu later
<ng0>master is broken.
<iyzsong>oh, what's wrong :-
<ng0>don't know, I can't investigate or fix much, I'm working on gnurl right now.
<ng0>some file (crypto) referenced zsh.
<ng0>I'dguess someone merged an oldpatch before checking on master
<iyzsong>ah, I see it.
<ng0>look for the commit of Tomb
<ng0>fix it to use shells instead.
<ng0>that shouldmake master build again
<iyzsong>ng0: yeah, I'll fix it in some minutes, thanks!
<wingo>guix + gnus + gnupg question
<wingo>i have gpg 2.1.3 installed
<wingo>and emacs and everything else from guix
<wingo>and when i see a mail encrypted to me, gnus asks me if i want to decrypt it
<wingo>and i say 'y'
<wingo>but nothing happens
<wingo>maybe i need gpg-agent running or something
<civodul>wingo: gpg 2.1 spawns its agent automatically
<civodul>could you try 'gpg' on the command line?
<wingo>i think i have done that before and it worked, to sign releases
<wingo>ACTION checks
<wingo>$ gpg --sign -a COPYING
<wingo>gpg: signing failed: No pinentry
<wingo>gpg: signing failed: No pinentry
<civodul>rekado: finding the right PID is slightly inconvenient, but we (you? ;-)) should prolly add an example in the manual
<civodul>wingo: guix package -i pinentry
<wingo>ah :)
<wingo>still failed :/
<wingo>same error
<wingo>i don't have anything gpg-related in my environment, perhaps something went wrong there...
<civodul>oh and you need something like "pinentry-program /home/ludo/.guix-profile/bin/pinentry-gtk-2" in ~/.gnupg/gpg-agent.conf
<civodul>there are plans to make it easier...
<janneke>wingo: are you on guixsd or debian+guix or so?
<janneke>/me also has in gpg-agent.conf: allow-emacs-pinentry
<janneke>ACTION also has in gpg-agent.conf: allow-emacs-pinentry
<janneke>(i had quite some problem getting it to all to work with deb+guix)
<wingo>ok that finally worked
<wingo>tx civodul and janneke :)
<ng0>what's thedifference in git between a branch and a tag? I know branches, but do tags follow something like branches (git checkou -b --tag name maybe?)?
<ng0>i think i nunderstand it now after reading some pages
<ng0>for cherry-picking curl to gnurl there will be no difference in tags anyhow
<dvc>Hi, I must say that I'm getting a little annoyed with the u-boot patches... If someone doesn't want to do the job properly, I don't mind and will do it myself when I get around to it. This reminds me of looking at how I submit patches =P Hopefully my patches aren't annoying anyone xD
<dvc>Sent out the linux-kernel patches, I went over all the commit messages again - I think that the patches shouldn't be too bad =P
<ng0>encryption of /home with cryptdisk is already possible in guixsd or does it introduce some weird behavior of the system/user?
<civodul>dvc: oh, are you Danny?
<dvc>civodul: I'm David xD why?
<cehteh>civodul: apropos: are there any plans/sketches how full disk encryption should be addressed in future, i am going to work on that for myself, using grubs crypt and luks stuff, but to my understanding that would loose the ability to unlock remotely over the network
<cehteh>otherwise one could copy the parts which are used for booting from the store to /boot .. but i think that would be a bit messy
<dvc>cehteh: I think there is already some work done on full-disk-encryption. Look at the tests in gnu tests...
<dvc>cehteh: That test failed for me though...
<cehteh>havent checked recently, i've seen different articles about how to fix it with some hacks but nothing that works out of the box
<civodul>dvc: oh i see, i was wondering based on what you wrote regarding u-boot :-)
<civodul>cehteh: there's a patch needing testing, and there's even a test
<civodul>i started working on it, committed the test accidentally, and then did not complete
<civodul>we'll get there!
<janneke>guix substitute: error: download from '' failed: 410, "Gone"
<janneke>trying to install hydra :-(
<ng0>you need to build texmf from source.
<dvc>janneke: pass --fallback to guix build should get you past this
<dvc>janneke: I'm interested in installing hydra too! If you get it working maybe you could add a section to the guix manual?
<janneke>dvc: ... it bombs out trying to patch
<janneke>hydra package seems broken
<ng0>there's the hydra documentation, upstream.. and work here is being done on curias, hydra grown too much away from what guix can use, the latest releases of hydra at least.
<ng0>can (source) be a local git repo? if so, can someone give me a small example line?
<brendyn>My guix uses my local git repo, is that what you mean?
<ng0>i mean what I wrote with no interpretations. can (source) [in a guix package defintion] use a local git repository of the software I package
<ng0>motivation: I don't want to setup a new profile just for python2 so that make check of new gnurl release can succeed
<dvc>(source (local-file blah
<dvc>#:recursive? #t
<ng0>b8ut maybe i should just do that.. ah. thanks
<ng0>ah cmon.. I'm using this system capable of working with profiles and environment etc.. i shouldn't be lazy and copy it over to gentoo. so I need groff and python2 in an environement which does not affect my profile at all. guix envrionment --ad-hoc can do that, right?
<ng0>yep... ng0@shadowwalker ~/src/gnurl [env]$ python --version
<ng0>Python 2.7.11
<ng0>so cool :)
<bavier>iyzsong: thanks for the quick import fix in crypto.scm
<bavier>I maybe should have done a 'make clean && make' after my rebase instead of just `make`
<brendyn>Maybe I should done make at all. I just run guix and guile automatically picks up the new .scm files and compiles them into cache.
<ng0>how can I execute the patch-shebang script for a repository? curl uses /usr/bin/env perl for some tests and I still haven't noted the full power of guix and guile.
<ng0>not in a package, but outside of the build system
<bavier>ng0: from guile you can call the patch-shebang procedure from (guix build utils)
<bavier>brendyn: you can let guile auto-compile, but the guix scripts will be much faster to execute if compiled
<ng0>ah, thanks.
<dvc`>the new u-boot diffs aren't complete and don't apply to what I already have :/ I hate the reviwer job =P
<dvc`>civodul: Do you want to review the patches? xD
<zacts>nice progress! 0.11.0
<zacts>the last I was here was like 0.8 or something
<bavier>zacts: nice to see you back
<janneke>trying to build hydra i get:
<janneke>patching file
<janneke>File tests/ is read-only; trying to patch anyway
<janneke>trying to fix this drives me mad...
<janneke>if i change (name "hydra") to (name "xhydra") i must type guix build xhydra, guix build hydra does not work anymore
<janneke>but when i add
<janneke> #:phases (modify-phases %standard-phases
<janneke> (replace 'unpack (lambda _ (exit 1)))
<janneke>hydra is still unpacked and patch fails
<bavier>janneke: patching is part of a separate derivation for the origin
<bavier>so removing the unpack phase won't do anything
<janneke>bavier: thanks, *urgh*
<janneke>wow, thanks!!! i never could have guessed that and was slowly going mad here
<janneke>bavier: is there any way to get between unpack and patch?
<janneke>or must i provide a fixed download tarball/url myself?
<bavier>janneke: I think you'll need to fix the origin
<janneke>OK, thanks
<lfam>I'm fixing the openjpeg patches. I'm sorry for sending them to the list in that broken state. I guess I ran out of steam yesterday!
<lfam>Okay, I think we need to update openjpeg from 2.1.0 to 2.1.1. There have been lots of changes between the two releases that make it difficult to cherry-pick the commits that fixed the bugs with CVEs. And there are other bugs fixed anyways
<lfam>Also, they claim no ABI or API changes between the versions, so it should be safe to do
<lfam>If we do that, the difficult thing is handling openjpeg-2.0, which is only used by mupdf
<janneke> g++ does not compile
<janneke>i'm terribly can it be that such important packages FTBFS?
<lfam>janneke: Not enough people paying attention, I'd guess
<bavier>janneke: yeah, hydra has been neglected lately
<lfam>It *is* a pretty important package for us, at least until we can build the distro with Cuirass
<janneke>okay, fair enough ;-)
<lfam>What would we do if we lost Could we get back up and running? Or would we have to spend a lot of time fixing the Hydra package?
<lfam>I guess we could always try building it from an older Git commit
<lfam>This is something I like about acme-client, the "dangerous because it's written in C" tool for getting certs from Let's Encrypt: it is very easy to build and all the dependencies are maintained.
<lfam>The same cannot be said for certbot
<janneke>it also doesn't build with g++-4.7
<lfam>Okay, I think there is no reason to keep this openjpeg-2.0 around for mupdf. It seems that many distros are building mupdf against openjpeg-2.1
<lfam>Even with old versions of mupdf
<pmikkelsen>hi guix
<lfam>Goddamnit. Why would you go to the trouble of patching bundled copies of a library instead of just changing your own code?!
<lfam>ACTION rants against mupdf
<lfam>Do they even issue new releases when bugs are publicized in the libraries they bundle?
<davexunit>lfam: that's the big problem with bundling.
<davexunit>oftentimes the answer is "no"
<lfam>Yeah, I know. Got to get a good rant in if I'm going to make my fingers bleed dealing with it :)
<lfam>Good grief. They bundle curl, freetype, glfw, harfbuzz, jbig2dec, jpeg, mujs, openjpeg, and zlib.
<lfam>Can't miss an opportunity to hang your users out to dry
<lfam>At least mujs is "their" thing
<davexunit>they surely have unpatched security vulns
<bavier>bundled zlib, that's bold
<janneke>Unrecognized character \\x7F; marked by <-- HERE after <-- HERE near column 1 at /gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/bash line 1.
<janneke>phase `check' failed after 0.9 seconds
<janneke>yay, almost build ancient version of hydra...
<lfam>I want to make a blog post about mupdf, detailing every CVE they ship that is fixed upstream.
<bavier>janneke: newer versions of hydra may not be compatible with guix
<lfam>I need a blog for that
<janneke>bavier: that's part of my questions...
<bavier>ISTR civodul mentioning they've made changes that only nix's daemon supports
<janneke>i found that the `nix' package in guix is too old for building current hydra
<janneke>but now i also found that our `nix' package is too new for building our hydra package
<janneke>terribly confusing, not sure how nix+guix relate
<lfam>Heh, another rebuttal to "Guix is just a wrapper around Nix"
<davexunit>yeah civodul has said in the past that hydra is pretty screwed
<davexunit>hence Cuirass
<janneke>and **grmbl**
<janneke>if i add #:tests? #f to hydra's arguments, it still fails
<janneke>phase `check' failed after 0.9 seconds
<lfam>That can't be right
<lfam>So much sympathy for you right now... this sounds like a nightmare
<janneke>thank's like i'm fighting ghosts
<lfam>I *love* this bug report, where the maintainer totally ignores the issue being reported with "use our bundled fork":
<lfam>Thanks for the help
<lfam>Anyways, guess I'll resolve that bug today
<ng0>i looked at todoist, used it for a while, it doesn't work for me.
<ng0>wrong channel
<lfam>ACTION `touch gnu/packages/javascript.scm`
<janneke>latest hydra.git does not build with newest nix-1.11.4 release
<janneke>no sensible info in hydra.git/INSTALL or README
<janneke>what a mess
<lfam>Maybe they can help on #nixos?
<janneke>lfam: yeah!
<lfam>Surely somebody there knows how to build it
<lfam>Suggesting that people use your bundled fork because your changes haven't made it upstream yet is like suggesting that one skips tests because they are failing
<lfam>Okay, I applied the extremely trivial solution that bug report, and can build the latest mupdf against openjpeg-2.1.1 while using the bundled mujs
<dvc`>does anyone know the status of cuirass?
<dvc`>where the gsoc goals met?
<lfam>dvc`: Presumably as shown in the Git repo and the last update on guix-devel:
<lfam>My understanding is that it does build things.
<janneke>nixos is silent, google however says
<janneke>`You have to use NixUnstable or go a few Hydra commits back.'
<lfam>`git checkout a-few`
<mark_weaver>janneke: I can think of two reasons hy #:tests? #f might fail: (1) you mispelled the keyword, maybe missing the '?' or the 's', or (2) there's a custom 'check' phase that doesn't honor that argument.
<janneke>mark_weaver: exactly... i tried removing the `?' and then guix errors out
<janneke>i don't see anything special in the hydra package...
<dvc`>janneke: Are you trying to update the package? Why aren't you keeping the working version for now? Or am I missunderstanding?
<janneke>dvc`: there is no working version...
<janneke>i'm just trying to build hydra
<dvc`>oh, so what's running on gnu's hydra?
<janneke>dvc`: exactly :-)
<lfam>janneke: Skimming the package, I wonder what the effect of '#:tests? #f' is when there is a pre-check phase?
<bavier>dvc`: it's not guix's hydra
<janneke>lfam: pre-check?
<janneke>i do see check-setup
<lfam>janneke: There is a phase 'check-setup' that happens before check. If you skip check, what happens to that phase?
<janneke>...thanks for looking!
<lfam>Did you try commenting it out?
<janneke>no, i did not
<janneke>ugh, newer hydra needs pqxx which we do not yet have
<mark_weaver>lfam, janneke: the 'pre-check' phase should have no effect on this. The default 'check' phase is still there when you pass #:tests #f, it just does nothing in that case.
<mark_weaver>see the 'check' procedure in guix/build/gnu-build-system.scm, which is the default 'check' phase for that build system.
<mark_weaver>janneke: are you still using gnu-build-system for that package?
<janneke>mark_weaver: yes
<mark_weaver>janneke: can you show me the hydra package recipe that's failing it's 'check' phase despite #:tests? #f ?
<lfam>So, if you compare the mujs that is bundled in mupdf-1.9a using a Git submodule with the mujs from its own Git repo, using what are apparently the same commits, there are differences in the code
<janneke>mark_weaver: thanks! but luckily/weirdly: no I cannot
<lfam>How could this be?
<janneke>i checked-out my commit marked: aaargh #:tests? #f still: phase `check' failed after 0.9 seconds
<janneke>and now it builds
<janneke>ACTION is weirdly confused...but i've now got at least one version of hydra building 
<mark_weaver>heh :)
<lfam>It seems that the Git tag of mupdf-1.9a is not the same as what was released as the 1.9a tarball
<lfam>ACTION head -> wall
<lfam>Total insanity
<mark_weaver>lfam: thanks for working on it :-(
<mark_weaver>sorry it's being difficult
<lfam>I think we should just use the bundled mujs for now. Mupdf and mujs are from the same development team, and there are no releases of mujs.
<mark_weaver>if we don't have anything else that uses mujs, that sounds okay
<lfam>And, I will relax for a while and then make a bug report to mupdf pointing out this tag / release mismatch
<lfam>Wow, that bug report I linked to upthread could have been answered with "See our own commit:;a=commit;h=f88bfe2e62dbadb96d4f52d7aa025f0a516078da"
<lfam>Instead the answer was "use our bundled fork"
<lfam>Or perhaps not. The commit came later.
<janneke>ACTION got 2 versions of hydra built...fwiw
<janneke>will send WIP-patch with summary for requests to the ml
<lfam>Summary for requests? Sure, I have lots of requests ;)
<janneke>either nix package needs to be downgraded
<janneke>or hydra needs to be upgraded...but not too new, and nix upgraded too
<lfam>In general, I think it's better to go forward
<janneke>and we need libpgxx ... not sure what that means: does hydra now depend on postgres..etc?
<janneke>oh, and tests still fail; ah... possibly yet another perl package
<janneke>STDERR: Can't locate Net/ in @INC (you may need to install the Net::Statsd module
<janneke>is that CPAN?
<lfam>janneke: Perhaps this thing?
<janneke>lfam: yeah
<janneke>now how to package that?
<lfam>I guess like all the other Perl CPAN modules? I would try the CPAN importer
<lfam>I just sent my mupdf patch to the list. Hoping for reviews on this and openjpeg soon :)
<janneke>guix import cpan Net::Statsd !
<ng0>I made the opensmtpd-extras package grow in lines of code... i don't know if you would be okay with not removing postgres+mariadb and splitting them to individual outputs... I mean we want it to be featureful..?
<lfam>ng0: I myself wondered why it used two different SQL databases. If it can use them both, then I think it's fine to include them. It's true that we want our packages to be full-featured
<ng0>no, it does not use them. you have the option to use it..
<lfam>What do you mean?
<ng0>i have no possibility at the moment to test it.. I think debian splits most of the -extras off to single packages. i think it should be split. if you use one sql db most of the time you use no other. but maybe you have n different hosts and on one you you a different sql db, so you don't want mariadb but postgresql..
<ng0>otoh this added 60 lines or more
<ng0>or 30 at least
<janneke>hydra builds, finally. not sure if it runs or is useful...
<bavier>janneke: thanks for giving it attention
<lfam>We should have a buildable hydra on the master branch
<janneke>thanks for the help all!
<janneke>lfam: sent a patch with rough edges to -devel
<janneke>ACTION -> zZzzz
<civodul>woow, quite an achievement, thanks janneke!
<janneke>tnx, i hope it helps...i'll try to run it tomorrow ;-)