IRC channel logs


back to list of logs

<lfam>wget failed to build on armhf and mips64el
<lfam>In both cases, the test failed
<ng0>anything I'm more or less in charge off which failed? I need to go to bed soon, early appointment.
<lfam>ng0: I sent a couple messages to you + copied guix-devel. Python packages whose test suites silently skipped with Python 3.4 (master branch) but fail with Python 3.5 (core-updates)
<lfam>We should try to make the tests pass but if we have to disable them, we haven't actually gotten worse
<ng0>thanks. I'll take a look tomorrow when I have a functional email setup here, I don't want to reply with webmail
<lfam>perl-www-curl is failing due a change in curl. There's a patch on the bug tracker but no upstream response as far as I can tell:
<ng0>is that url in one of the emails? If not i'll safe it
<lfam>ng0: I didn't send a message about that package to the list yet. I was just "thinking out loud" :)
<lfam>Hoping for some feedback on the patch
<ng0>hope this will still apply with the next curl release
<ng0>i'm not very good with perl.. I know people who write in perl since forever, so if I run into problems which are not obvious I ask them usually
<lfam>Yeah, I don't really know Perl either. But I did get a tiny patch into a Perl project yesterday!
<ng0>naive me says it looks ok
<ng0>cool :)
<lfam>I'm going to apply that patch and, if it works, send it to the list
<ng0>I know too little perl so that the one time I reported a bug on perl itself I could just give a very detailed output of what's broken and how to reproduce, but not patch it
<ng0>if I only could create factoids..
<ng0> <- bloat
<ng0>ah wrong channel
<ng0>just pretend this never happened
<Common_Era>Hmm, is a working guix package -f <file.scm> command supposed to give no output?
<lfam>Common_Era: Nope :)
<ng0>good night o/
<Common_Era>Okay, lfam, but why does it not install the command?
<Common_Era>Or am I confused?
<lfam>Hard to say without seeing the file.scm
<Common_Era>I'll get a paste up.
<Common_Era>File Edit Options Buffers Tools Geiser Help
<Common_Era>(define-module (gnu packages war)
<Common_Era> #:use-module (guix packages)
<Common_Era> #:use-module (guix download)
<Common_Era> #:use-module (guix build-system gnu)
<Common_Era> #:use-module (guix licenses)
<Common_Era> #:use-module (gnu packages ncurses))
<Common_Era>(define-public war
<Common_Era> (package
<Common_Era> (name "war")
<Common_Era> (version "0.1")
<Common_Era> (source (origin
<Common_Era> (method url-fetch)
<Common_Era> (uri (string-append "file://home/ben/war-" version
<Common_Era> ".tar.gz"))
<Common_Era> (sha256
<Common_Era> (base32
<Common_Era> "081c247qf66iz19m50jfh3x9rw9c88wcnsrhacy40r6cn41njb5a"))))
<Common_Era> (build-system gnu-build-system)
<Common_Era> (arguments '(#:configure-flags '("--enable-silent-rules")))
<Common_Era> (inputs `(("ncurses" ,ncurses) ("guile" ,guile)))
<Common_Era> (synopsis "A CLI strategy game.")
<Common_Era> (description "A CLI grand strategy game.")
<Common_Era> (home-page "")
<Common_Era>Sorry, not what I meant to do.
<Common_Era>It makes the format a bit weird.
<lfam>(define-module (gnu packages war)
<Common_Era>That's what I thought. Should it just be (define-module (war))
<lfam>That module path (gnu packages war) needs to match the filesystem path from wherever Guix is looking for package modules
<Common_Era>How's that?
<lfam>If you set the variable GUIX_PACKAGE_PATH to '~/', you could write (define-module (pkgs war) and put war.scm in ~/pkgs
<Common_Era>Oh, I see. Thank you.
<lfam>For the GNU Guix packages, the package modules are in 'gnu/packages', so that's why they export that module path
<lfam>The example of how to use `guix package -f` in the manual is even simpler. It doesn't involve GUIX_PACKAGE_PATH and the package definition doesn't export a public package
<Common_Era>I was going off the defining packages section.
<lfam>Check out the example in 3.2 Invoking guix package
<lfam>That's probably a good place to start
<Common_Era>Alright, thanks.
<lfam>For use of GUIX_PACKAGE_PATH, I have some examples here:
***reepca` is now known as reepca
***MinceR_ is now known as MinceR
***abbe_ is now known as abbe
<citronputride>i wonder if i put my home partition on my hdd instead of my ssd beside my root partition, will i lose speed to launch my applications and use it?
<atw>assuming you're talking about GuixSD, I imagine that application launch speed will depend most on where you put the store
<atw>citronputride: ^
<citronputride>atw, yeah GuixSD. i will do a standard installation, with or without home partition, so the store will be on the root partition. (don't know if what i say is clear ><)
<citronputride>in fact, i have a SSD with 128GB and an HDD with 1TB. I wonder if i will do a single partition, root, on my SSD or a root partition on my SSD and an home partition on my HDD.
<citronputride>i will create a single root partition. When i will be ease whith Guix and GuixSD i'll : )
<Digit>talk like this gets me dreaming of a ssd raid for guix store.
<Digit><3 <3 <3 guix. thnx for coming up with this idea of making nix advantages more palatable and freedom respecting.
<efraim>is anyone else having trouble building from git with the new svg changes?
<marusich>efraim, I saw one test failing (tests/pypi.scm), but thats it
<efraim>marusich: with ludo's grub boot-image generation change?
<marusich>Which commit is that?
<marusich>If thats the one, then I didnt have it locally at the time I noticed the tests/pypi.scm failure.
<marusich>Looks like b5c347ad3d83ee580c111bd14c80b469b0dcb294 (import: pypi: All inputs are propagated-inputs by default.) is causing tests/pypi.scm to fail
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, wingo says: re _IO* deprecation -- the new names are better and they correspond to r6rs. what advantage does staying with the current names have?
<marusich>Hello there!
<efraim>civodul: how much does switching from imagemagick to a pure guile implementation shrink the size of the install image?
<civodul>efraim: it significantly reduces the amount of software needed for that conversion
<civodul>$ guix size imagemagick inkscape | tail -1
<civodul>total: 878.7 MiB
<civodul>$ guix size guile-rsvg guile-cairo | tail -1
<civodul>total: 232.8 MiB
<civodul>and it's roughly the same amount of code on our side
<civodul>and the resulting image quality is marginally better
<rekado>I find it inelegant how we’re treating updaters differently from importers.
<rekado>updaters are organised very nicely
<rekado>whereas importers are not
<civodul>we could have a single <remote-repo> kind of interface, maybe
<rekado>I’d like to bring importers closer to how we deal with updaters
<civodul>yeah, that makes sense
<civodul><remote-repo> could have roughly two methods: 'latest-release' and 'import'
<civodul>or something along these lines
<rekado>sounds good
<civodul>good idea
<rekado>I’ll push this to my list for later.
<civodul>cool :-)
<rekado>right now I’m working on running the matching importer when doing an in-place update. Once that works and my changes to the recursive importers are in place I’ll take on the <remote-repo> idea.
<rekado>(or maybe just <upstream>?)
<kmicu>civodul: is ‘inkscape’ omitted from ‘guix size guile-rsvg guile-cairo | tail -1’ on purpose?
<civodul>kmicu: yes, because we no longer need it
<kmicu>Ahh, that comparison makes sense now and looks great!
<civodul>rekado: maybe <upstream> just needs to be expanded and we don't need an extra interface, yeah
<civodul>running the updater upon refresh to check for missing inputs and such will be great
<efraim>I was thinking about sourceforge, and I think they have an rss style something for new releases which could work for checking for new releases
<civodul>should we trust SF? :-)
<Gottox>we at voidlinux have a tool that checks upstream urls.
<Gottox>and generates this:
<efraim>civodul: `guix pull` failed on my soon-to-be offloading machine
<efraim>("no code for module" (rsvg))
<civodul>efraim: should be fixed now, could you try again?
<thomasd>civodul: work for me now
<thomasd>workS for me :)
<civodul>cool, thanks for the quick feedback
<efraim>looks like I have bad luck with machines, the one I was testing it on overheated and shut down
<thomasd>Maybe I do have an issue building master from git. I'm getting some warnings and ERRORs compiling svg.scm, though it does seem to build.
<thomasd> ;;; Failed to autoload rsvg-handle-new-from-file in (rsvg):
<thomasd>;;; ERROR: missing interface for module (rsvg)
<rekado>hmm, hacking around the lack of importer organisation is more complicated than expected.
<civodul>thomasd: but 'make' succeeds, doesn't it?
<thomasd>yes, it does.
<thomasd>for some definition of succeed :)
<civodul>i mean what's its exit status?
<thomasd>yes, it's 0, so successful
<civodul>so the "error" message is actually a warning, QED :-)
<civodul>in fact it's not very useful to build that file when running 'make'
<civodul>but that's ok
<thomasd>yes, probably I should properly learn how guile modules work. maybe all the warnings won't be as scary anymore
<civodul>are you seeing so many warnings?
<thomasd>I think I regularly get some "possibly unbound variable" warnings. Don't know if it's related to the staging stuff in the packaging code.
<civodul>ah, oh
<civodul>well there are a couple of modules where we play dirty tricks like in svg.scm
<thomasd>as I said, I don't know Guile well enough at this point, to know when/if I should worry about warnings. So far I usually ignore them, everything seems to work when it compiles.
<civodul>the compiler doesn't know about the dirty tricks, hence the "possibly unbound" warnings
<civodul>but yeah, you can ignore them, except when they're in a module you're working on :-)
<civodul>so, we really need a more pleasant and convenient news section on the web site
<civodul>as per
<civodul>how should we proceed?
<civodul>davexunit: what would be your recommendations? Haunt?
<davexunit>civodul: the rest of the site doesn't use haunt so probably not
<civodul>(i'm asking because i need to post a news entry that includes pictures of the new machine, and we can't post pictures on Savannah's thing...)
<civodul>davexunit: but should we convert?
<civodul>what's the easiest way?
<davexunit>I haven't taken a good look at the website's code in awhile
<davexunit>it's possible to convert
<rekado>my attempt to run “guix pull” in a qemu-system-arm VM just failed with “ERROR: no code for module (rsvg)”
<rekado>ACTION reruns “guix pull”
<civodul>davexunit: or is it easier to just use guile-commonmark and do our own thing?
<rekado>(I’m still trying to set up an ARM test machine to experiment with patches to fix GCJ on ARM.)
<civodul>sounds a bit sad if we duplicate things
<civodul>i see that paroneayea used Haunt for
<davexunit>yeah he did
<davexunit>and I recently added commonmark support
<civodul>rekado: works for me :-)
***ifur_ is now known as ifur
<rekado>civodul: looks okay now
<rekado>(it’s just terribly slow)
<civodul>davexunit: there are 2 small issues regarding Haunt mentioned at
<civodul>do they still apply?
<ng0>i wonder how you could test a service for mailserver with no incoming/outgoing traffic... can a guix system test be written for this?
<ng0>potentially I want to have a server next year again, running guixsd as a first try
<davexunit>civodul: the first issue still needs to be addressed with a command-line flag
<davexunit>civodul: not sure what the second issue is.
<davexunit>you can add arbitrary static files to a haunt site that simply get copied to the build directory
<ng0>i think the traffic un-limitations I have at my prefered organization would even allow publishing packages
<civodul>davexunit: the 2nd thing was the "precious file" proposal that you made
<civodul>but yeah, i can work around that
<civodul>guile-commonmark support is not in any release yet, is it?
<davexunit>guess I need to re-read the whole thread
<davexunit>civodul: no, I need to make a release.
<civodul>ok :-)
<davexunit>I can do that soon. building from git is easy though, in the meantime.
<davexunit>civodul: simply tweak this expression
<civodul>right, thanks!
<ng0>obviously "in october I will finish gnunet-service and psyced-service" failed, so it's best I work on this step by step, and work on more than one service at the same time. the mailserver question is about opensmtpd. in my environment I could only test that it starts, shutsdown and throws no mistakes.. but I have no static ip and don't use any dyn-service.
<quigonjinn>Should guix package revision numbers start from 0 or 1?
<rekado>(icecat crashed twice today)
<davexunit>the new icecat is ridiculously unstable
<ng0>guix revision numbers?
<rekado>argh, I think I lost my huge browser session
<rekado>I get the “Well, this is embarrassing” screen but there are no windows or tabs listed.
<rekado>ACTION shakes fist
<quigonjinn>ng0: thanks
<efraim>i've replaced my aarch64 static-binaries with ones I generated more recently and hopefully that takes care of of the 'patch' problem I ran into before
<efraim>still have to figure out the clone problem :/
<Apteryx>I found a nice font which is included in the Guix packages: font-hack (Hack)
<Apteryx>Great for my monospace needs.
<Apteryx>Also, enabling antialiasing for the fonts made things cripser. For that I used the fonts.conf supplied by Antergos:
<Petter>Eh, I did "guix package -i font-hack", and it building openssl now.
<Apteryx>Petter: Are you sure? I don't see why it would pull open-ssl as a dependency.
<Apteryx>Unless the fetch method requires it
<Apteryx>It gets the ttf files from a github https URL.
<Petter>Yeah, I've tried it a couple of times, and it gets going with openssl.
<Apteryx>I did a "guix edit font-hack" to see the package definition and didn't see openssl as an input.
<Petter>I did too.
<Petter>Not sure what's going on, or if it's even intended for this to happen.
<cehteh>mhm .. i am using terminus, but hack looks nice too
<Apteryx>cehteh: Interesting, didn't know about that one.
<Apteryx>Very "future" looking :)
<cehteh>its fixed pitch, so always crisp when you dont scale it
<cehteh>err pixel font i meant
<cehteh>too bad the hack font playground doesnt let one compare
<Apteryx>cehteh: Do you mean that there is no need for antialiasing it?
<cehteh>antialiasing is a hack
<cehteh>ideally you have high enough res on the display :D
<Petter>I also use terminus in my terminal.
<cehteh>or you get older :D then res doesnt matter that much
<cehteh>20 years a go i wanted a ultra high res display :D
<ng0>or you get older and fonts don't matter anymore as much as styling your application etc
<ng0>hm.... what's so special about guix xterm that it does not recognize shift+arrow-pad-key-down in midnight commander to mark more items? in gentoo it just works
<Apteryx>ng0: I'm test driving weechat. Like it so far, although it uses 3 times more ressources (ram) than irssi in its default config.
<rekado>“guix refresh -t bioconductor -u” is very slow for me. Not sure why. It takes a very long time to print anything at all.
<ng0>Apteryx: aha
<Apteryx>Would anyone know how I can change the background color of all the X/GTK applications?
<Apteryx>I've got a *background: #0D1012 entry in my .Xresources config, but it doesn't seem enough.
<ng0>for gtk you want something to theme gtk with
<ng0>i can't give names because i don't do that, but it's definitely not in .Xresources
<Apteryx>ng0: OK! Thanks for pointing me in the right direction.
<ng0> apply to guixsd as needed
<ng0>"i don't do that": I did not mean "I don't hand out information about that", I meant I do not theme anything
<ng0>ACTION writes on black on white xterm
<Apteryx>ng0: aha, I was thinking the former :D. I thought that's a strict rule to follow.
<ng0>no.. I just stopped doing that (themes/colors). there's an old "cyberpunk'ish" theme but some applications break the colors so I don't care
<Apteryx>Yeah... it's kind of a pain to setup, but somewhat fun too.
<ng0>civodul: I don't have an email client here at the moment, but I might be in berlin around that time and would be interested to meet up if I go
<civodul>ng0: noted!
<civodul>ng0: would be great to meet
<ng0>yeah :)
<ng0>i should setup email again before it's one month later and I have to fetch 1500+ new emails..
<civodul>heh :-)
<ng0>i want franken-mutt... but i would have to package that
<ng0>or I
<ng0>'ll give gnus another try.. last period where I used it I got stuck with my gnus.el growing too long
<efraim>gcc-cross-boot0 on aarch64 can't find -lstdc++
<ng0>there are no stupid questions, so: can someone show me (part of) their guixsd system config.scm where the tor-service is extended, or some other service which works similary to extend? I need to take a look at one functional piece to understand why what I tried did not work
<marcello__>I just installed hello via guix, and I got a bunch of 'warning: failed to install locale: Invalid argument'
<marcello__>how can I fix that? Thanks!
<marcello__>well, I just found that
<roptat>I'm trying to use module (system foreign), but '(dynamic-link "libnl-3")' fails to find that is installed in my profile and in the system configuration
<roptat>it works when I start guile with LTDL_LIBRARY_PATH=/home/roptat/.guix-profile/lib guile
<rekado>roptat: instead of the plain library name pass the whole path to dynamic-link.
<rekado>GuixSD doesn’t have a global linker cache.
<rekado>roptat: when a library is installed in a profile this doesn’t change any global state
<rekado>roptat: so you have to take steps to make other applications find it.
<roptat>ok, thanks
<roptat>my goal is to create some functions that would be useful to have virtual networks in guix containers
<roptat>I'm able to create a bridge and veth pairs right now, so I only have to connenct them together now :)
<davexunit>roptat: well that's exciting!
<roptat>then I'll have to put that somewhere in guix
<rekado>roptat: cool!
<rekado>is there a way to check if a tarball for a given URL is already in the store?
<rekado>I’d like to avoid rerunning download-to-store repeatedly when running the importer together with the updater.
<rekado>never mind, I’ll just use “mock” to stub out “download-to-store”
<thomasd>is there a solution for the "fonts look weird in guix-installed emacs on a foreign distro" problem? :)
<rekado>thomasd: I’m using Emacs from Guix on Fedora at work, and fonts look nice after installing them via Guix.
<thomasd>I'm on ubuntu, and they don't :) Though it affects different fonts differently
<thomasd>yes, e.g. Liberation Sans looks strange (no antialiasing as far as I can see), but the default "Sans" looks fine
<thomasd>the Monospace font looks bad, too
<thomasd>I see roelj had the same problem on 2016-05-25
<thomasd>oh, `fc-cache -fv' fixed it
<civodul>roptat: woow, that sounds cool!
<civodul>so what's the status of core-updates?
<zilti>Hi! Short question, is the Guix kernel efistub-ready?
<civodul>zilti: i don't think so
<zilti>civodul: :/ thanks
<civodul>short answer :-)
<lfam>civodul: re core-updates: I've been running a headless x86_64 system on it for a week or so now. There are still plenty of broken leaf or near-leaf packages, and some br
<lfam>and some broken core packges on other architectures. For example, mesa is not building on mips64el
<rekado>I’m working on updating all of bioconductor right now. This should fix a couple of broken packages.
<rekado>(I’ll commit those to master, though)
<lfam>I'll take another look at the failures on x86_64 / i686 later tonight. I'll also try diagnosing some of the armhf / mips64el failures in case there is anything I can fix without having hardware access
<lfam>rekado: Awesome
<rekado>I’m compiling guix in an armhf VM since two days :(
<rekado>the first time it failed with a segfault after a day.
<rekado>it’s now at 77.3% (and has been since about an hour)
<civodul>lfam: cool, thanks for the update ;-)
<civodul>i'll take another look myself
<civodul>i'd really like to get this merged
<lfam>Lots of "failures" are actually network failures or OOM conditions. It's worth checking the build log to find those
<lfam>Let's Get This Merged
<Common_Era>Alright, I've got it getting to the configure stage and not being able to find pkg-config, which is installed.
<Common_Era>The weird part is that it configures fine outside of Guix.
<rekado>Common_Era: could you provide some context?
<Common_Era>Yes, sorry.
<Common_Era>I've written a small program that I am trying to test. I have a package definition written.
<rekado>Common_Era: could you share the definition with us?
<Common_Era>Yes, but I think it's PKG_CHECK_MODULES in my that's breaking things.
<rekado>is pkg-config among the native-inputs?
<Common_Era>No. I thought stuff like that was added by default.
<Common_Era>Alright, that might fix it.
<rekado>rebuilding openssl-1.0.2j again after “guix gc”. Why is there no substitute?
<fr33domlover>is it normal for a package to not be available in the mirror? it returns 410 Gone
<fr33domlover>I'm trying to `guix package -i mpv` and hoping not to build because it takes forever on the x60 and there will be /tons/ of deps
<civodul>rekado: i wonder, this is getting annoying
<civodul>fr33domlover: that happens; use "--fallback" in that case
<civodul>sorry for the inconvenience!
<fr33domlover>civodul, but then it starts building from source. mpv is the first GUI i'm installing, it's gonna be a lot of deps... and i'm using thinkpad x60 so builds aren't exactly fast...
<fr33domlover>i just wonder how common these 410s are
<fr33domlover>should i really resort to build-from-source or just try again in an hour
<ng0>did you run guix pull recently?
<civodul>fr33domlover: hopefully dependencies won't be built from source
<rekado>gah, another segfault trying to compile guix in my armhf VM
<ng0>the amount of emails i get per month must be more than 1500.. 48 hours without getting the mail: 380 emails
<rekado>I get about 500 per day. Sometimes more.
<civodul>rekado: what's segfaulting?
<rekado>guix pull: error: build failed: build of `/gnu/store/h57k0jns1lwbzjk0rqr0fi6v0rnvf1ax-guix-latest.drv' failed
<rekado>I’m just trying to get Guix updated in the VM so I can download substitutes for git and guix-dev, and then to build gcj.
<civodul>does the VM have enough RAM?
<rekado>(with one additional patch)
<rekado>ah, this might be the problem
<rekado>it’s just the default which may not be enough.
<rekado>(but a segfault when running out of memory…?)
<rekado>ACTION —> zzZ
<ng0>I found out in the last 7 days: without virtualization speedup, initial guix pull in guixsd in qemu machine takes more than 30 hours.. that's when I canceled it.