IRC channel logs


back to list of logs

<mark_weaver>dannym: or use GUIX_PACKAGE_PATH
<detrout>I was wondering how Guix is handling CVE-2015-7547 glibc getaddrinfo buffer overflow?
<lfam>detrout: We are rebuilding our package repository based on the patch for it
<detrout>Ah ok
<lfam>Impatient users can try cherry-picking the patch and rebuilding themselves, but either way, it's a lot to rebuild, since everything depends on glibc, AIUI
<detrout>Yeah. It's close to a worst case bug for Guix
<lfam>I'm actually doing that now. I have literally no idea how long it will take
<lfam>Yeah, our grafting system not yet being recursive is really hurting us now
<detrout>How is a guix user supposed to know if they've got the updated version?
<lfam>Nobody has it yet, it's still being built on our security-updates branch. If you want it right away, you'll have to cherry-pick the patch and rebuild locally
<lfam>As for knowing once it's released, I'm not sure. I'd guess a regular end-user of Guix would have to do `guix pull && guix package -u`, and GuixSD users would also want to do `guix system reconfigure`.
<lfam>There was some talk of a tool that could check profiles for vulnerable package versions, but I haven't seen any code yet
<detrout>I was wondering if there was a way to see what patches had been applied or something
<detrout>though that tool would be really useful as well
<detrout>though would need to depend on an external database of some kind
<lfam>It would be useful. It's probably more worthwhile right now to make grafting recursive.
<detrout>How does recursive grafting help?
<detrout>or why is there a difference between grafting and recursive grafting?
<lfam>grafting is a mechanism to apply changes (like security updates) without rebuilding the entire referral tree of the point where you apply the update. Our grafting system currently doesn't recurse through all the referrers, so it's not really that useful when a package like glibc needs to be patched. If it did recurse the tree, it would save us *a lot* of time in situations like this.
<lfam>Here's the relevant bug report:
<lfam>Does anyone know how to determine which git commit corresponds to the version of Guix that's running. Assuming I'm using `guix pull` and not running everything out of git.
<lfam>Answering that question would answer detrout's question about knowing when they have the glibc patch available.
<detrout>so when package-fixed gets grafted, guix goes and finds all the symlinks in the direct dependancies and moves them from the old package to the new package?
<lfam>Oh, is the git hash contained in the store directory name?
<lfam>detrout: I'm not sure exactly how it works.
<lfam>I'm sure some other user does :)
<detrout>Ok. I was staring at the info page trying to figure it out
<lfam>Section 7.4 of the manual says that it also does things like rewrite runpaths
<lfam>So, maybe it searches for references to the store directory of the changed file, and then rewrites the hash in the reference. That's just a guess
***6A4AB3XSW is now known as pizzaiolo1
<NiAsterisk>GNUS is so great, you should comment what you do, because getting a date into this (setq gnus-summary-line-format "%8{%4k│%}%9{%U%R%z%}%8{│%}%*%(%-23,23f%)%7{║%} %6{%B%} %s\\n" part of how I display threads is weird.
<NiAsterisk>I think it summons cthulu if I change something.
<pizzaiolo1>suitsmeveryfine: I tried compiling pommed-light
<pizzaiolo1>but some dependencies were not packaged
<suitsmeveryfine>wow! you already tried that also
<pizzaiolo1>so I needed to compile the dependencies of the dependencies
<pizzaiolo1>and I couldn't find some dependencies
<pizzaiolo1>so I stopped :P
<suitsmeveryfine>Do you have a list of those dependencies?
<pizzaiolo1>and I was also more concerned with xfce theming so pommed-light was put to the side for a while
<suitsmeveryfine>why? How can that be more important :)
<pizzaiolo1> pommed requires: - pciutils / libpci (on Intel machines only) - libofapi aka oflib (PowerMac machines only, see below) - zlib - libconfuse - libasound - libaudiofile - eject
<pizzaiolo1>heh, I was just trying to make my guixSD install look prettier :P
<suitsmeveryfine>pizzaiolo1: eject is the program that francis recommended us to integrate with GRUB
<suitsmeveryfine>if you remember
<paroneayea>hello! I'm back.
<pizzaiolo1>I do
<pizzaiolo1>hey paroneayea
<paroneayea>hi pizzaiolo1 !
<suitsmeveryfine>pizzaiolo1: so which dependencies didn't you find?
<pizzaiolo1>libasound, libaudiofile and eject, ironically
<pizzaiolo1>eject's sourceforge link is down
<pizzaiolo1>it was when I tried anyway
<NiAsterisk>could you try internet archive?
<NiAsterisk>don't know if they index sf
<pizzaiolo1>NiAsterisk: afaik they don't
<detrout>try they'll have a link to a source package as well as debs
<pizzaiolo1>detrout: interesting
<dmarinoj>pizzaiolo1: yeah, debian is really nice like that
<sneek>dmarinoj, you have 1 message.
<sneek>dmarinoj, mordocai says: I have a gitlab mirror at If you make/have a gitlab account i'll add you to my mirror and you can push up a branch with your work from this summer.
<detrout>the debian archives include copies of all upstream source
<suitsmeveryfine>pizzaiolo1: I downloaded the sources when francis mentioned it to us. I'm trying to look for it now
<detrout>right forgot this irc doesn't scroll
<suitsmeveryfine>pizzaiolo1: I've got the eject 2.1.0 source code
<pizzaiolo1>suitsmeveryfine: nice
<pizzaiolo1>I managed to find libaudiofile
<pizzaiolo1>but the compiling failed
<pizzaiolo1>at that point I stopped trying
<suitsmeveryfine>ok, at least you tried and we know where the problems are
<paroneayea>wingo: hey, curious question for you
<paroneayea>from the guix manual:
<paroneayea>> Another example where ‘propagated-inputs’ is useful is for languages that lack a facility to record the run-time search path akin to the ‘RUNPATH’of ELF files; this includes Guile, Python, Perl, GHC, and more. To ensure that libraries written in those languages can find library code they depend on at run time, run-time dependencies must be listed in ‘propagated-inputs’ rather than ‘inputs’.
<paroneayea>wingo: with guile 2.2 using elf, would it be *possible* to do RUNPATH? (and would it be desirable?)
<paroneayea>ACTION considers packaging some roguelikes for guix
<paroneayea>no... resist
<davexunit>guix package -A nethack
<davexunit>*no output*
<davexunit>glibc can hold its horses, we've got a bigger problem here.
<davexunit>Guix is great. I don't know yet if this will work, but I made a new mesa-vulkan package that inherits from the regular mesa package but uses the source from a git branch.
<davexunit>nice how easy it is to make a package variant.
<davexunit>guix is coming in real handy to compile this vulkan branch of mesa.
<davexunit>had to add/change a number of other packages to satisfy it.
<davexunit>but it's compiling now.
<calher>Can't Guix just use the Nix package for Mumble?
<calher>I'm listening to some Nix users on Mumble.
<calher>Not sure what to make of it. Never used Nix.
***remi1 is now known as remi
<cbaines>I have managed somehow to make gnome-shell a bit more stable... but lots of icons are still just grey boxes
<cbaines>Its a definite improvement though :D
<cbaines>(I also found out why shepherd was repeatedly restarting ntpd, it was just that the time was so wrong that ntpd could not cope, so I think I have solved that also)
<pizzaiolo1>kristofer: ping
***the_ktosiek is now known as ktosiek
<rekado>I want a recursive importer for CRAN/bioconductor.
<Jookia>Recursive importers are a thing?
<rekado>since the package names in Guix are all sanitised (lowercase, no periods, no underscores) it is a little harder than usual to manually recurse on the dependencies.
<rekado>recursing over as yet unpackaged inputs should be quite simple to implement.
<efraim>maybe you don't, how many circular dependencies are there that would break stuff?
<rekado>I'll play with the CRAN importer today
<rekado>efraim: I'd use a hash table to mark off previously encountered packages.
<rekado>but R packages usually do not have circular dependencies (unlike Ruby)
<Jookia>github is enforcing HTTPS downloads
<Jookia>thanks github (not)
<guiks>if I install GuixSD right now, will I need to reinstall 1.0 and later versions at some point in the future?
<Jookia>guiks: Probably not
<rekado>guiks: no, once installed you can just reconfigure the system
<Jookia>Unless something MAJOR changes that CAN'T POSSIBLY be migrated (I can't think of anything)
<rekado>guiks: with something like "guix system reconfigure /etc/config.scm"
<rekado>guiks: reconfiguring is a lot safer than reinstalling.
<guiks>that's good to know, thanks
<Jookia>Guix is being weird right now for me- I run 'guix download <url>', it puts the package in the store with the right sha hash.. But Guix tries to download it anyway (and fails)
<guiks>When is the first production-ready release of Guix going to come out?
<guiks>(GuixSD, I mean)
<Jookia>Oh wow, this might actually be a really odd bug
<Jookia>Time to report
<Jookia>Or woops, me just being bad
<Jookia>Or not. Hmm
<rekado>Jookia: what you downloaded has a different name in the store.
<Jookia>rekado: I realized that just after writing (as usual :P)
<rekado>because the package recipe uses "(file-name ...)"
<rekado>guiks: what do you mean by production-ready?
<rekado>guiks: I use GuixSD on three of my machines exclusively for development work and music.
<rekado>it still lacks some popular big packages.
<guiks>On top: The Guix System Distribution (GuixSD) is beta software, which means it is not production-ready. But you can help!
<rekado>the link goes to
<rekado>"more than 2000 packages" is correct, but it's quite a bit more than that.
<rekado>if any of the limitations mentioned there hurt you then it's probably not ready for your use-case right now.
<guiks>What system services aren't supported? Does GuixSD use systemd?
<Jookia>I have no idea
<guiks>There is a guile-emacs package in Guix
<guiks>Last change Tue, 12 May 2015
<guiks>too bad
<calher>The program that weaves the source code to GNU texindex may be non-free: <>. This means Texinfo is non-free.
<Jookia>calher: Seems like a bug to report to Texinfo
<Jookia>calher: Though that doesn't seem to be nonfree software, just documentation
<Jookia>Furthermore, a nonfree compiler doesn't make a program nonfree
<calher>Jookia: You mean it's OK to say "you can edit the code in this source code file, but not the commments"?
<Jookia>calher: Do I think it's okay? No. Do I think it makes the program nonfree? Not sure. Does it make Texinfo nonfree? No.
<calher>Jookia: I sent <>.
<Jookia>calher: I don't know if anyone's ever done a license review on literate software and what makes it free or not
<Jookia>calher: Or what free documentation even is
<calher>Jookia: They would *have* to. GNU Texinfo depends on a literate program that's existed for thirty years. It's called TeX.
<calher>Jookia: TeX is *everywhere* in the free software community.
<Jookia>calher: Sure, but this is one program that isn't a dependency of TeX is it? It's a compiler
<Jookia>Not part of TeX*
***MatthewAllan93_ is now known as MatthewAllan93
<calher>Jookia: So it's OK if GNU software requires non-free compilers? OK, let's write it in XCode.
<Jookia>calher: I think it'd be better to move this to #gnu
<calher>I'm getting angry over this. If I talk anymore, I'll get banned from these channels too. I'm going to go eat.
<rekado>calher: GNU Texinfo contains the free scripts from texiweb-jr. Arguably it does not depend on the non-free documentation (it's not part of the scripts that come with Texinfo).
<rekado>calher: you don't need texiweb-jr to use TeX, nor to use Texinfo.
<rekado>but I think it is a wart and maybe you can raise this with the Texinfo maintainers.
<calher>rekado: texiwebjr.awk is *not* the source code to TexiWeb Jr.
<calher>rekado: TexiWeb Jr. is required to use texindex; texindex is required to use texinfo.
<rekado>Texinfo comes with jrtangle and jrweave.
<rekado>these are free awk scripts.
<calher>Those are written in texiwebjr iirc
<calher>not awk
<rekado>the scripts are written in awk.
<calher>coded in awk but not written in awk
<calher>just as TeX was *not* written in Pascal. It was written in WEB.
<rekado>but the awk code is untangled from a literate documented.
<calher>rekado: But the awk code is *not* the code the author used to write the program.
<calher>It's *output*, not *source*.
<rekado>yeah, I understood this the first time you wrote it.
<calher>So how do I complain to the Texinfo people.
<rekado>calher: you can write to one of the mailing lists:
<guiks>I have no experience with package management and build tools, what's the best way to learn so that I can create Guix packages?
<rekado>calher: I encourage you to write a calm and constructive email.
<rekado>guiks: the manual explains how to do it
<rekado>but there are better ways to get started
<rekado>we have importers that generate package expressions
<rekado>I started by looking at a simple package definition and modifying it.
<calher>Why can't I use the NixPkg for Mumble?
<rekado>guiks: do you have something you'd like to package?
<calher>or use it as a starting point
<Jookia>calher: Not sure it works with complex packages- it'd be best to just read the nixpkg itself and take away what needs to be changed
<calher>The source code to TexiWeb Jr. (ti.twjr) is included with Texinfo 6.1
<rekado>calher: no, that's the texindex source file
<rekado>it's written in the TexiWeb Jr. format.
<calher>In jrweave: TexiWeb Jr. is free software; you can redistribute it and/or modify...
<rekado>calher: it would be better to talk to the Texinfo people about this. We as the Guix project cannot really say much about this other than what Jookia and I already have.
<rain1>I guess I'll install pulseaudio
<rain1>I don't know much about sound on linux but I think I need that to make sound work on guix
<Jookia>It's probably the easiest way
<rain1>then I think I'll build the docs to have a look at the crypto section
<rain1>oh I don't use apple stuff but I think this might be interesting to some people here
<guiks>rekado: Yes, I'd like to package some music programs
<guiks>rain1: lol
<Jookia>guiks: Which ones? :D
<rain1>yeah Jookia, a lot of people were holding back on guix because it couldn't do crypto
<guiks>Jookia: let me see, please wait a sec
<rain1>but now it can! so this is really exciting
***remi1 is now known as remi
<rain1>guiks: my link is about FBI requesting a backdoor
<guiks>rain1: and mine is about iPhones already having ones
<guiks>it's just a PR stunt
<guiks>Jookia: I would like to add LMMS
<Jookia>Sounds cool, have you looked at an existing package on another distro to see what hitches there may be?
<guiks>let me check
<guiks>the Parabola site is down, sadly
<guiks>but I know it uses Cmake
<Jookia>I think Guix supports cmake as the build system
<Steap>Jookia: it does
<rain1>I think that stuff in the GNU link is terrible but I think this is genuine as well
<rain1>just because they're 99% evil doesn't make them 100%
<rain1>on the other hand everything is PR, so you're not wrong
<guiks>Apple is better than Google, I give you that much
<fhmgufs>guiks: May be right - but for example I'm not more interested in these companies.
<fhmgufs>If sth is bad it's bad.
<rain1>I should start using guix inside of emacs rather than in terminal
<guiks>why can't Guix use along withSavannah?
<guiks>at least for issue tracking
<guiks>and/or pull requests
<Jookia>Well, that'd be a big shift for not much gain
<guiks>but Savannah can scare people away
<guiks>it's good to use git and the lists for hosting
<guiks>but Savannah's issue tracker is awful and dated
<Jookia> seems to work well
<guiks>yes, it does, that's why I said *along* with
<guiks>nvm, gotta go
<guiks>see you all, and thanks
<NiAsterisk>I see nothing (in file names) where I could put reverse engineering, disassembler tools. Am I free to create a reasonably named .scm for tools like ?
<NiAsterisk>code.scm is a bit too generic for the specific purpose of panopticon
<NiAsterisk>would the new file gnu/packages/disassembler.scm be okay? it specifies an existing category of software.
<kristofer>what does (assoc-ref %build-inputs "package") do? how is it different than simply putting it in the inputs hashtable?
<NiAsterisk>else there could be the more general reverse.scm with a general purpose of dissassemblers, debuggers (does already exist in debug.scm iirc), hex editors, pe and resource viewers etc
<taylan>interesting news:
<rain1>I posted that a little bit ago there was some discussion about it
<rain1>I like the sound of a new category for disassemblers/debuggers NiAsterisk
<rain1>(its not up to me though)
<Jookia>debugger sounds better /bikeshed
<NiAsterisk>but it's not a debugger, that's my problem.
<rain1>I can't think of a name that includes both
<NiAsterisk>a bit misleading.
<NiAsterisk>there's flashing-tools.scm for example
<fhmgufs>I still haven't understood how these modules are handles. I find it weird that some of them like gnome.scm contain thousands of lines and others, e.g. libcanberra.scm only one package.
<NiAsterisk>reverse-engineering.scm ? I think it would be too long. debug.scm? too general in content and not related to what panopticon seems to be. what about disassemble.scm?
<NiAsterisk>re.scm ?
<NiAsterisk>(as in reverse engineering)
<NiAsterisk>should I just collect thoughts and post to the list later this evening? I only wanted to take a break and start writing for the panopticon package.
<rain1>I'm just wondering how to get sound to work from e.g. youtube in icecat
<rain1>sound works with pulse/mpv playing a video file
<NiAsterisk>gstreamer something
<rain1>I installed some gst things, I'll try adding more
<davexunit>rain1: I think the issue here is that icecat isn't using pulseaudio
<davexunit>it's using alsa directly
<NiAsterisk>but I never tried streaming with icecat so far.
<davexunit>there is a mailing list thread about this topic.
<Jookia>Watch youtube using mpv
<rain1>oh ill search around for it
<davexunit>if anyone knows how to fix the icecat package to use pulseaudio, a patch would be very welcome. :)
<rain1>I wonder if I might just use firefox instead of icecat
<rain1>I'm not very keen on icecat
<davexunit>the problem is not icecat itself here.
<davexunit>the problem is that our build configuration has it not using pulseaudio.
<davexunit>firefox is not FSDG compliant, so we don't provide it.
<NiAsterisk>regarding disassembler, i'll send the question to the list.
<NiAsterisk>but is iceweasel?
<Jookia>davexunit: What makes it not FSDG compliant?
<davexunit>NiAsterisk: no.
<davexunit>Jookia: the most glaring thing is that the add-ons repository contains a lot of proprietary software.
<kristofer>firefox ships with non-free blobs to support things like drm streaming on netflix,
<davexunit>and that too
<NiAsterisk>Jookia: i can think of webrtc and helo.
<Jookia>davexunit: I'll have to ask whether Tor Browser is FSDG compliant. I suspect is is but I'm not sure
<NiAsterisk>davexunit: but would TBB / torbrowser, slightly altered to be compliant, be okay? there was a discussion on packaing this before
<davexunit>Jookia: it could be, I have no idea. my guess is that it's not.
<rain1>I couldn't find the mailing list thread
<davexunit>1) the add-ons repository cannot include proprietary software
<davexunit>2) it needs to remove non-free blobs
<Jookia>I may need to run a git repo for Tor Browser then
<davexunit>even iceweasel is not FSDG compliant
<davexunit>web browsers are kind of terrible
<NiAsterisk>Jookia: it would be better to ask tor to do this or some kind of not-one-person controlled repo
<rain1>I would quite like to run my own fork of firefox that is FSDG but it takes up a lot of time
<Jookia>NiAsterisk: It's difficult since we can't change the Tor Browser source code
<davexunit>this is why GNU icecat uses the ESR firefox releases
<davexunit>because keeping up with a bleeding edge firefox and staying on top of security issues is extremely difficult
<rain1>is anyone interested in midori browser?
<NiAsterisk>Jookia: but we can patch away things which aren't, the gentoo procedure I had for some did this.
<Jookia>NiAsterisk: No we can't with Tor Browser otherwise it weakens the anonymity
<davexunit>you can't patch tor browser?
<Jookia>I can patch it, but it weakens the anonymity since it means it's no longer the same as the other Tor Browser s
<NiAsterisk>you should not patch TBB but you can build your own torbrowser, that's how I do it on gentoo. civodul had a discussion with tor about it, maybe i find the thread if it was on a list.
<NiAsterisk>not on this, but tbb i ngeneral
<davexunit>alright, so upstream tor browser needs to be fixed.
<davexunit>but strangely, projects like this seem to not care about these sorts of issue.
<Jookia>Is IceCat a fork or a patch set
<davexunit>patch set.
<rain1>I guess you could call it a patch set, he has some scripts that rename and delete things
<davexunit>it tracks Firefox ESR
<davexunit>but patches things to be more freedom and privacy friendly
<rain1> this browser
<Jookia>Maybe it'd be worth taking the freedom patches and putting them in Tor Browser
<rain1>it's a bit crashy because it's based on webkit
<NiAsterisk>Jookia: I know parabola had a patchset on top of iceweasel toremove helo and others. If I find the thread with tor on weekend, I'll get to it and write an email on motivation and problems to include torbrowser in guix
<NiAsterisk>*to the tor talk list. or some place else. idk.
<Jookia>Iceweasel isn't FSDG though
<davexunit>parabola may have patched it enough to make it compliant.
<NiAsterisk>maintaining patches can't be the solution, I see where it brought gentoo - collect all the patches - linux
<NiAsterisk>so if it's doable upstream, good, if not, it would be okay
<rain1>we don't have a lot of choice, mozilla does what they want to do and we either take it or leave it
<rain1>they can't be reasoned with
<NiAsterisk>rain1: torproject is not mozilla.
<Jookia>Well I'll obviously be looking in to it since I use Tor Browser and I'll be compiling it anyway because I'm on ARM
<Jookia>(Yes I have Tor Browser compiled on ARM already)
<NiAsterisk>I have done it too, different system, but if you need help, maybe I can help.
<calher>Jookia: You're making a Tor Browser package?
<Jookia>calher: Probably, yeah. It's my only browser
<calher>Jookia: Tell me when it works.
<Jookia>Okay, I also have a bunch of scripts and preferences set so it uses my system daemon
<rekado>I do not use pulseaudio and I do have sound in Icecat.
<rekado>when there are <audio> or <video> tags
<rekado>I don't use any plugins.
<davexunit>hmm, looks like I need to rebuild the world in order to build Mesa with Vulkan support.
<davexunit>it requires a glibc built with newer linux-headers than we use.
<davexunit>anyone know how to maintain a toolchain with an independent glibc?
<rekado>ACTION thinks about ways to use Guix in Galaxy instead of this terrible conda thing.
<davexunit>anyone know why our linux-libre-headers package is so old?
<davexunit>whereas we use kernel 4.4
<davexunit>the headers I want are in 3.17
<rekado>isn't that to make it easier to use Guix on foreign distributions?
<Jookia>davexunit: Oh wow there's an actual script for IceCat, it's not a repo like Tor Browser- I may be able to just use this! :)
<mark_weaver>davexunit: feel free to update the headers and push it to core-updates
<NiAsterisk>Jookia: parabola has a patchset which brands it and disables things. if I look into my repos tonight I maybe could find something I (or collectively with others) did with gentoo which can't rely on TBB alone.
<NiAsterisk>parabola specifically:
<NiAsterisk>^ Jookia
<Jookia>NiAsterisk: Does that remove the nonfree addons repository suggested?
<NiAsterisk>you have to look at other files in the tree, too. in their own description they take debian as upstream and remove certain features debian still has.
<NiAsterisk>for tor, I can dig for possible solutions in the next week.
<Jookia>It does! Hmm, davexunit: Parabola's (patched) Iceweasel looks like a good base
<Jookia>NiAsterisk: This should be fine :)
<NiAsterisk>Jookia: for packaging iceweasel, yes.
<NiAsterisk>if I lookat lynX (and partialy mine with changes) ebuild of torbrowser, if combines 5 sources
<Jookia>IceCat's scripts look a lot easier to modify than patches though.
<davexunit>mark_weaver: okay, I will. should I be conservative in this upgrade or bump to 4.4.x?
<Jookia>I'll have to think more
<davexunit>I ran into this issue because the 3.14 headers don't include linux/memfd.h which I think was added in 3.17
<davexunit>and upcoming Mesa releases will need this header.
<NiAsterisk>it shallow clones git.tor/tor-browser, then 3 gentoo hosted sets, and 1 other tor rooted src
<davexunit>I wish there was an easy enough way for me to substitute the headers used for a smaller dependency graph so I could experiment without rebuilding the world.
<NiAsterisk>Jookia: not the latest release as i didn't push the most up to date one, but here's what happened with 38.3.0_p503:
<rain1>git clone
<rain1>is this the correct way to get guix sources? It errored for me
<mark_weaver>davexunit: maybe update to the latest 4.1.x, since that's a LTS kernel
<mark_weaver>rain1: no, but that page gives the git URLs at the bottom of the page.
<rain1>git clone git://
<NiAsterisk>the latest torbrowser, you can check the repo over at for that, mentioned on or what's the url again. its in onion exclusively.
<davexunit>mark_weaver: thanks, I will do that.
<rain1>this doesn't work either
<rain1>says Please make sure you have the correct access rights
<mark_weaver>davexunit: great, thanks!
<efraim>it was giving me issues too today
<mark_weaver>rain1: the ssh URL won't work, but the other two should
<mark_weaver>the ssh URL is only available to people with commit rights
***tschwing_ is now known as tschwinge
<rekado>davexunit, mark_weaver is this guaranteed not to break installations on older kernels?
<davexunit>I do not know.
<rain1>ah third time lucky git clone
<mark_weaver>rekado: I'm reasonably sure that newer kernel headers support older kernels
<davexunit>but we'll have to cross this bridge at some point if we want to upgrade Mesa.
<mark_weaver>anyway, most of our build farm is already running older kernels than our kernel headers.
<davexunit>I'm just ahead of the curve because I want to try out the Vulkan API that was released only yesterday.
<rekado>ACTION closes his eyes
<rekado>okay, I'm ready :)
<mark_weaver>heh :)
<davexunit>I'll upgrade when I take lunch.
<rain1>where/what should I search if I want to get sound working in icecat? i haven't been to find information
<davexunit>sound works in icecat.
<rekado>rain1: it works for me :-/ (no pulseaudio)
<rekado>rain1: are you using GuixSD?
<davexunit>you probably have an issue where something has already claimed control of ALSA
<kristofer>works for me too
<kristofer>I use pulseaudio as well
<davexunit>because AFAIK icecat doesn't use pulseaudio
<mark_weaver>sound in icecat works for me too
<davexunit>I've encountered a time where icecat didn't play sounds
<davexunit>but most of the time it works
<davexunit>if we rebuild icecat to use pulseaudio rather than ALSA directly, I bet your problem would go away.
<rekado>maybe we should tweak the ALSA defaults to use software mixing.
<rain1>yes guixsd
<rain1>I could remove puleaudio i don't know the best way to set things up
<rekado>(I really hope pulseaudio won't become mandatory; it's such a hassle when using ALSA and switching to JACK for audio work)
<rekado>rain1: if pulseaudio is running it takes control over the soundcard and ALSA-only programmes won't be able to talk to the soundcard.
<rekado>rain1: you might be able to get around this by configuring alsa to use pulseaudio as a backend.
<kristofer>weird, I'm playing back a recording with audacity while youtube via icecat plays a video
<rain1>ill try
<rain1>maybe ill just remove pulseaudio though
<mark_weaver>pulseaudio is an input to our icecat package. not sure if it picks it up or not.
<rain1>i just installed it because sound wasn't working
<mark_weaver>(both pulseaudio and alsa-lib are inputs)
<rekado>rain1: do you have pavucontrol installed?
<rekado>if so it might be easier for you to debug this.
<rain1>yeah but i just reoved it
<rain1>im trying alsa-lib and alsa-utils
<rain1>that didn't work
<rain1>probably just give up on sound for now
<rain1>unless there is a guide ?
<rekado>rain1: can other programmes use ALSA directly?
<rekado>aplay on any WAV for example
<rain1>i guess so, mpv sorta works but not very well
<rain1>ill try aplay
<rain1>(as soon as i skip sound dies)
<rekado>how odd.
<NiAsterisk>surfraw has a rather slow release cycle.. 2013 last release where they do work on it still. would using a specific, stable, git commit be okay in such cases? I will do it anyhow, and change to the tarball if asked, but I guess 3 years get a lot of commits.
***orbea_ is now known as orbea
<rain1>another problem is that it wont shut down
<rain1>when i try to shut down it just goes back to the login screen
<rain1>I wonder if there's a bug report for that or something?
<rekado>rain1: in Xfce?
<rekado>try "sudo halt" instead.
<rain1>ill try thanks
<rekado>I was working on this problem, but haven't figured out why this happens.
<rekado>I'll try again this weekend.
<rain1>it sounds like a hard one to track down
<rain1>cheers for the workaround!
<bavier``>efraim: you're so fast on package updates ;) I was going to just do the moe update myself :)
<efraim>bavier``: I signed up for the GNU release emails a while ago :)
***mordocai_ is now known as mordocai
<kristofer>what does the %desktop-services point to?
<kristofer>to be honest, I'm trying to use geiser to find what it is, but can't figure it out either :-/
<davexunit>kristofer: it's a list of services
<davexunit>see (gnu services desktop)
<NiAsterisk>disregard my last question, I'll just do it. I ask too many questions because of unrelated other things.
<davexunit>kristofer: with geiser, you need to load the relevant modules to see information about the symbols
<kristofer>should I just load it up in the repl or is it a geiser specific command?
<davexunit>so if you just started a fresh geiser REPL and then exepected to be able to lookup arbitrary symbols, it won't work.
<davexunit>kristofer: you need to evaluate the relevant code
<davexunit>your OS config file surely has that
<davexunit>so evaluate it
<kristofer>another probably ignorant question: does my system configuration override the defined %desktop-services, say if I do (services (cons* (slim-service ...) %desktop-services))
<davexunit>kristofer: no, that just adds an additional service to the top of the list
<davexunit>which will cause a conflict when you try to instantiate the system
<davexunit>because there will be 2 slim services
<davexunit>kristofer: see 'modify-services'
<pizzaiolo>kristofer: ping
<Jookia>Colour calibrating is like the mechanical keyboards for screens. :(
<davexunit>mark_weaver: is it okay to rebase core-updates on master?
<davexunit>mark_weaver: nvm, I just pushed a single commit there, no merging or rebasing of master.
<fhmgufs>Normally XDG menu files should load application files from paths within XDG_DATA_DIRS, right?
<fhmgufs>If there's a <DefaultAppDirs/> in it.
<fhmgufs>I've the problem that my lovely MATE panel isn't showing up any .desktop file entries.
<cbaines>I get this error when trying to lint a package generated with the pypi importer "warning: source expression failed to match any pattern"
<cbaines>Is the importer generating invalid packages, or is something wrong with the pypi?
<davexunit>cbaines: you'll need to share the code.
<davexunit>and the backtrace
<davexunit>that's a pattern matcher error
<davexunit>but without any other context there's no way we can tell what it is
***exio4 is now known as y
<cbaines>I am quite willing to learn more about what this scheme code is doing, but I am not really sure where to start?
<cbaines>Is there a way to start guile, such that it evaluates the file and then gives a REPL?
<davexunit>cbaines: well it depends if that file defines a guile module or just has some random code in it
<davexunit>for random code, use 'load'
<davexunit>(load "foo.scm")
<cbaines>Its /gnu/packages/python.scm in the Guix repository, which I think means its a module
<davexunit>so run './pre-inst-env guile' to make a repl
<davexunit>and then type: (use-modules (gnu packages python))
<davexunit>now you've imported that module
<cbaines>Ok, that failed, but I now have a much more detailed description of what the problem is, I'll attempt to continue debugging...
<Jookia>cbaines: Can you get a backtrace using ,bt ?
<cbaines>It says: Nothing to debug
<davexunit>Jookia: he wasn't in the repl before
<davexunit>now he is
<cbaines>I guess as its a compliation syntax error
<Jookia>Surely there's an error message?
<davexunit>yeah that won't put you in the debugger
<davexunit>Jookia: just above, cbaines said they got an error message.
<Jookia>I didn't see that
<cbaines>I think I somehow managed to delete a random line elsewhere in the file (which happened to be in a sources section of another package). Once I got rid of that hunk, lint works fine now :)
<cbaines>Thanks davexunit
<kristofe`>is there an example of how to use (xorg-configuration-file #:extra-config '()) in a system configuration?
<a_e>sneek: later tell rain1 Did you use a mixer to check that alsa sound is actually turned on? For me it is muted every time I reboot (in Guix on Debian), and I use alsamixer to turn it on again. But things may be different in GuixSD.
<a_e>sneek: botsnack
<alezost>kristofe`: I've never used it but I think it should look like this: '("ModulePath ..." "Section \\"Monitor\\" ...")
<alezost>in these lines you can use package names (which will be converted into /gnu/store/... paths) as it is done at: <>
***tschwing_ is now known as tschwinge
***kristofe` is now known as kristofer
<paroneayea>talk on the future of shipping security updates for nix
<pxc>is this about the 'intensional store' idea?
<paroneayea>I'm watching, not sure yet
<pizzaiolo>kristofer: hey, sorry I didn't see your pong earlier
<efraim>CVE on libreoffice
<a_e>At least it is a leaf package and can be updated in master.
<efraim>, 0795, still blank on mitre
<roptat>help, my machine is trying to rebuild everything :(
<roptat>it's running since yesterday
<roptat>and now it failed at guix
<roptat>all I want is to update my system configuration to add an entry in grub though
<myglc2>rekado: re fixing up 'Binary Installation' doc as discussed on gmane.comp.gnu.guix.bugs, does git clone -b master ... have the latest version of the doc, or is it on some other branch?
<Jookia>roptat: You might want to revert then
<roptat>revert what?
<Jookia>your Guix update
<Jookia>Hmm, if you run 'guix package -l' you should have some generations- do you see a recent guix update?
<roptat>I don't see any guix package actually
<davexunit>Jookia: roptat isn't talking about a package profile.
<davexunit>this is a full system configuration
<mark_weaver>roptat: are you running GuixSD or Guix on top of another distro?
<Jookia>davexunit: So you'd roll back Guix as root then run 'reconfigure'?
<mark_weaver>roptat: are you running guix from a git checkout? did you modify any files there? or did you just run "guix pull" ?
<roptat>I have a git checkout, but right now I think I'm running the system one
<mark_weaver>Jookia: no. I appreciate you trying to help, but I think this problem is beyond your knowledge
<roptat>I didn't do any guix pull
<mark_weaver>roptat: the rebuild of everything happened when running "guix system reconfigure" as root?
<roptat>I think it's rebuilding older versions I don't have
<mark_weaver>does ~root/.config/guix/latest exist? if so, where does it point? (it should be symlink)
<davexunit>it could be that roptat is using an old enough guix for this that substitutes are no longer available.
<roptat>if you mean home of root by ~root, then the .config directory doesn't exist
<mark_weaver>okay, then those will be old packages.
<mark_weaver>it's important to keep up-to-date because otherwise you will be missing security updates, of which there have been many lately.
<roptat>so guix pull updates the system, right?
<rekado>myglc2: yes, the master branch holds the latest version of the docs.
<mark_weaver>so, if you want to run guix from your git checkout, then ~root/.config/guix/latest should be a symlink pointing to your built git checkout
<myglc2>rekado: Thanks!
<mark_weaver>or, alternatively, you can run "guix pull" as root, which will build a fresh copy of guix from git master and make ~root/.config/guix/latest a symlink pointing to it
<mark_weaver>(my personal opinion is that the git approach is far superior)
<roptat>ok, thank you for your help
<myglc2>mark_weaver: I have watched you explain Guix/GuixSD/'guix pull'/'git pull' here quite a few times in the last few weeks. I have now used most of the variations. This seems like a stumbling block in getting started with Guix. Maybe we need some kind of overview of the various ways you can get Guix/SD in the doc or a picture on the web site?
<myglc2>or both?
<roptat>maybe you should try to have a quick start guide or something, with basic commands
<roptat>all I could read was a really long manual (which is great, but pretty confusing)
<Jookia>So how would you downgrade Guix from a Guix pull?
<mark_weaver>we don't have any way to downgrade from a Guix pull. that's part of the reason I don't like guix pull.
<Jookia>Ouch, I see
<mark_weaver>but if you use git, you can go back to any revision you like
<Jookia>Maybe guix pull should be replaced with a git checkout some day?
<efraim>so says to update to 5.0.5 or 5.1.0 to deal with the CVEs
<mark_weaver>I want all the functionality of git. I want to be able to manage private branches, cherry-pick commits, rebase, etc.
<mark_weaver>efraim: if it were me, I would probably go to 5.0.5 until the 5.1.x branch has matured a bit
<mark_weaver>but I don't feel strongly about it.
<myglc2>roptat: Agreed. Please take a look at and comment on whether the attached diagrams are helpful.
<efraim>my problem is its currently unbuildable, and if it were it took hydra 7 hours so I'd be looking at 14 to test that it built
<efraim>right now I'm testing the coreutils and binutils update against core-updates
<mark_weaver>efraim: libreoffice is unbuildable? when did this happen?
<efraim>I thought it was broken by vigra
<roptat>myglc2, they're great, but nothing new to me
***y is now known as E4xoi
<myglc2>roptat: Which diagram do you think better explains Guix vs GuixSD?
<roptat>I would say the shortest one, but it lacks something about system management
<myglc2>roptat: Agreed
<paroneayea>mark_weaver: I watched the video
<paroneayea>mark_weaver: I think the direction Nix is talking about going is very similar to the route you were discussing
<paroneayea>re: grafts
<mark_weaver>paroneayea: huh, I assumed they already had that, but I guess maybe not :)
<mark_weaver>unfortunately my entire household has gotten sick, so I may not have the energy to do this work in the next couple of days.
<paroneayea>mark_weaver: I think currently, there's no automated pro
<paroneayea>it's done manually
<paroneayea>by running something similar to the above
<mark_weaver>the plan we have should work well, without sacrificing any of the fundamental goals of guix.
<mark_weaver>of course if anyone learns of some clever idea that would be applicable, I'd like to hear it
<Jookia>From what it looks like they're doing a check to see which packages would be affected if it wasn't being grafted but instead replaced, grafting those, then repeating until there's nothing left to graft/rebuild
<Jookia>Or perhaps I'm misunderstanding the presentation
<Jookia>I think it grafts the grafted? ;)
<paroneayea>Jookia: I think that's right
<Jookia>That sounds kind of like something it should have already done though
<paroneayea>I'm not sure how the grafting *works* though... a lot of things do dynamic linking in different ways
<paroneayea>how do you do grafting without recompiling?
<paroneayea>maybe I need to re-read the plan
<roptat>oh, finally back on my archlinux
<Jookia>paroneayea: It doesn't work with static linking, so I assume it only works for dynamic linking using the system linker. I'd hate to imagine if source code had its own linker
<roptat>the reconfigure did add the entry for arch in my grub menu, but it didn't do it as expected
<roptat>the linux line in the config had an extra /bzImage, and lacked the argument I wanted to add to it
<rekado>how can I globally set LC_CTYPE=zh_CN.utf8 on GuixSD?
***pxc_ is now known as pxc
<rekado>I want it to be set in Xfce, so that when I start Emacs from the launcher it affects Emacs.
<rekado>without this env variable IBus pinyin does not work in Emacs :(
<petter>Brainstorming. Maybe you can have your launcher as: "LC_CTYPE=zh_CN.utf8 emacs..."
<davexunit>rekado: putting it in your bash_profile doesn't work?
<davexunit>paroneayea: IIRC, grafting works by finding references to the bad derivation and replacing them references to the good derivation.
<mark_weaver>rekado: I don't know about globally, but for your Xfce session you could make ~/.xsession be an executable script (with shebang) that ends with "exec startxfce4"
<davexunit>replacing them with*
<mark_weaver>but yeah, putting when in .bash_profile should hopefully work anyway
<roelj>Is openjdk available in Guix?
<roelj>is it the same as icedtea?
<roelj>Ok, thanks :)
<roelj>So, I need to set JAVA_HOME.. And I found this: (setenv "JAVA_HOME" (assoc-ref %build-inputs "jdk"))
<rekado>petter: nah, I tried that but Xfce didn't like it.
<rekado>davexunit: ~/.bash_profile isn't evaluated by Xfce, it seems.
<a_e>The "jdk" is just a name that is given to the package variable in the inputs.
<rekado>it would be enough if I started Emacs from a terminal.
<rekado>I was looking for a way to do this in "(operating-system ...)" because I don't like to fiddle with environment variables...
<a_e>roelj: The corresponding input line looks like this:
<a_e>("jdk" ,icedtea "jdk")
<a_e>The "jdk" in (assoc-ref %build-inputs "jdk") corresponds to the first occurrence in the inputs line.
<roelj>a_e: Yes, I figured that. Now my build is failing because it cannot find 'tools.jar'.
<a_e>Using "assoc-ref" extracts the other parts; precisely, it returns a string "/gnu/store/..." corresponding to the jdk output of the icedea package.
<a_e>Build of what?
<roelj>I'm packaging FastQC.. It's a Java application using ant.
<rekado>roelj: FastQC is on my list too.
<rekado>but I wanted to wait until the ant-build-system is ready.
<a_e>Okay. I have never packaged anything Java. Recado is the person to know...
<rekado>the ant-build-system simplifies this a lot by setting JAVA_HOME and running ant.
<roelj>rekado: Oh. Great..! Because mine is really ugly at the moment
<roelj>rekado: But how does it handle those different targets?
<roelj>Like 'FastQCApplication'?
<rekado>here's the build system patch:
<paroneayea>Jookia: davexunit: thanks... that makes sense!
<rekado>well, so far I only encountered ant files with single build targets.
<rekado>I don't have FastQC in front of me right now.
<rekado>aren't the targets linked somehow?
<roelj>rekado: Great, I didn't see that patch..
<rekado>roelj: did you already package picard?
<roelj>rekado: Well, they are described in build.xml
<rekado>fastqc bundles a binary for the picard libs.
<roelj>rekado: I was working on Picard as well.. But that one is still failing here too.
<paroneayea>as long as it's doing C style linking I guess it's good
<davexunit>paroneayea: one of the big limitations here is that the length of the store path must not change, otherwise you couldn't substitute it in an arbitrary file because you could very well break it.
<paroneayea>davexunit: eep!
<davexunit>so the name and version must stay the same when doing a graft.
<rekado>roelj: picard (not the captain) sent me on this long journey to package maven ...
<paroneayea>davexunit: I guess you could pad or truncate the dest directory when making the graft...
<paroneayea>but that would require some buy-in?
<roelj>rekado: I think we're after the same packages eventually. Could I help you with your list?
<roelj>rekado: Forgive me for my ignorance, but isn't ant going to be all we need for Picard as well?
<rekado>roelj: Picard's ant file demands an additional ant plugin.
<rekado>and I think to build that I needed packages that needed maven...
<rekado>or something like that.
<rekado>I think we should throw away Picard's build.xml and let the ant-build-system create one instead.
<roelj>rekado: Oh and I now see for building with GA4GH API support, maven is needed.
<rekado>by default the picard build includes building htsjdk, for which we already have a package.
<petter>rekado: probably not the solution you're looking for, but it seems to work if you put this in your .emacs file: (setenv "LC_CTYPE" "zh_CN.utf8")
<rekado>petter: I'll try that!
<roelj>rekado: Yes, and FastQC uses htsjdk as well.
<a_e>Is anyone of you interested in German television?
<rekado>roelj: so, I think all we need from Picard's build.xml is the compile-picard target, which can be covered by the ant-build-system
<a_e>I would like to see mediathekview packaged, but am not really motivated to look at java packaging.
<rekado>a_e: oh, I'd like that too.
<a_e>Their download is a terrible mess of bundled jars.
<rekado>a_e: so far I've used the direct video links in the hard-to-find RSS feeds.
<a_e>But the app is just really convenient.
<a_e>And it should be possible to use their download, this is just not a very clean solution.
<a_e>(Right now, I am still using the Debian package.)
<roelj>rekado: And 'compile-picard-tests' probably..
<rekado>roelj: yeah, but that's probably going to fail because of "<jacoco:coverage ..."
<rekado>that's a non-standard tag, handled by the jacoco ant plugin.
<rekado>I have no idea how to deal with ant plugins at this point.
<roelj>Yeah.. I didn't know what Jacoco was..
<roelj>Package them separately?
<roelj>So that it becomes an input for those projects that need it..?
<rekado>roelj: probably. But usually they have a lot of build dependencies.
<rekado>(and these deps are often circular because nobody builds things from source in the Java world.)
<roelj>And all that for building software.. They told me Autotools was 'too complex' one day..
<rekado>I didn't look into this particular case, because I'm a little scared about it all.
<rekado>I told our users to just download the jars for now and use them with our JDK :-/
<rekado>takes me much too long to get Java stuff packaged
<paroneayea>hoisted by my own picard
<roelj>rekado: Well, I know I'm new to both Guix and Java.. but I'd sure like to try to dive into it, so maybe I can help you with this.
<rekado>roelj: that would be great!
<rekado>petter: it works! Thanks! It's much nicer to have this in the Emacs config than somewhere else.
<petter>rekado: Great! :)
<rekado>roelj: I'm trying to fix the open issues with the ant-build-system soon and push it; then things should be a little easier.
<roelj>rekado: Great! I'll wait with FastQC for it.
<rekado>roelj: not finding tools.jar is bad and I wonder why that is. It's part of the JRE, so having the JDK and JAVA_HOME set properly should be sufficient. We can work on this together later.
<roelj>rekado: I read on stackoverflow that tools.jar is part of JDK and not JRE.. I haven't checked the actual java packages myself though..
<rekado>oh, yeah, one or the other. JDK includes the JRE.
<roelj>But I agree, we can work on this together later ;)
<roelj>I'm probably slower than you figuring these things out
<a_e>roelj: Did you add the "jdk" output of icedtea to your package inputs?
<a_e>Otherwise it will only take the "out" output, which I suppose contains the jre.
<rekado>yes, the "out" output only contains the JRE.
<roelj>a_e: Yes I have this: ("jdk" ,icedtea "jdk")
<roelj>In my inputs
<roelj>and native-inputs
<roelj>I should probably place only JRE on the inputs. But I don't know how to do that..
<roelj>Can I just drop the second "jdk", so: ("jdk" ,icedtea) to get JRE only?
<a_e>But tools.jar is in jdk, if I see it correctly
<roelj>a_e: Yes. Can I somehow run an extra test command to find out whether it has the JDK?
<roelj>Possibly (system* "javac") ?
<a_e>I just did a "find" on the output directories of icedtea...
<roelj>Hey! tools.jar is in the lib directory, as expected
<rekado>roelj: do you have more of the output you could share with us?
<rekado>ACTION tries to debug the broken shutdown/reboot from the Xfce menu.
<roelj>rekado: I'm rebuilding to paste the output somewhere. What paste service is OK to use?
***jgay_ is now known as jgay
<rekado>I don't see any error about tools.jar in there?
<roelj>Mm.. You're right
<roelj>Argh, I must've done something wrong initially.
<rekado>I think the target "FastQCApplication" is not the right target.
<rekado>that one will *run* fastqc AFAICS
<rekado>so I think you're almost done (ignoring the Picard problem for now)
<roelj>rekado: Yes, I can instead run "ant" without arguments, and then it builds succesfully..!
<roelj>But.. I have no idea about the install target
<rekado>there is none.
<roelj>AFAIK there is no..
<rekado>you'd have to add your own
<rekado>copying the binary, maybe adding a wrapper.
<rekado>but looking at build.xml I see it needs more work
<rekado>seems that it bundles a couple of jars, which should be built from source.
<roelj>it does
<roelj>And they survive "ant clean" and "ant init"
<rekado>jbzip2, sam-1.103, cisd-jhdf5, etc.
<roelj>You're right
<rekado>gotta go now
<rekado>maybe we can resume this some other time
<roelj>Ok, I have to go sleep