<mbakke>looking forward to a wave of libgdx games!
<NieDzejkob>hmm, I wrote a package definition with a transitive module dependency missing from #:imported-packages (instead of using %gnu-build-system-modules I manually specified utils, gnu-build-system and python-build-system and it couldn't import gremlin), and when I tried to build it a derivation for module-import-compiled failed. Now when I fixed the problem, I get a different error, In procedure symlink: File exists https://paste.debian.net/1136253/
<lfam>NieDzejkob: It means the filename of the symlink you are trying to create already exists
<NieDzejkob>Turns out that's what you get when there are duplicates in #:imported-modules and it's not, as I thought, a weird statefulness in the store
<vagrantc>the older pinebook is pretty good, other than the wifi which probably requires binary blobs and isn't even supported in linux, let alone linux-libre
<vagrantc>but the boot firmware for the original pinebook all the way down is in guix and debian, and i recently tested that it boots (using the same OS that boots on pinebook pro, just swapped out bootloader)
<lfam>What wifi chip isn't supported in linux at all?
<vagrantc>honestly, i haven't checked recently ... happy enough with my atk9k usb wifi :)
<KE0VVT>vagrantc: I thought the Pinebook was d̲e̲s̲i̲g̲n̲e̲d̲ for Linux. Why would they put such a card in it?
<guix-vits>not a big trouble, but if someone have a time to kill: please try to install the nomad-git. i can run it from the git dir using `guix -L ./guix nomad-git` and `./autogen.sh && ./configure.sh && make run`, but not with `guix package -i nomad-git -L ./guix` and `nomad`. The software version is alpha.
<Parra>This is really problematic to me because I've spent time packaging my software with guix because I thought this feature was available.. and it isn't, it should be reflected in doc at least. If there is any alternative I would be glad to hear about it.
<guix-vits>Parra: i'm just `guix build --target=mips64el-linux-gnu hello` on my x86' and currently a download started.
<usney>How is russia handling the corona guix-vits
<Parra>I will try mingw through build instead of pack later on
<Parra>if it works, I possibly implement darwin even if it's not libre, some people may benefit from it
<guix-vits>usney: i'm living in Kemerovo, in Western Siberia, and know not much about this; heard that people pass a temperature control before enter the factories, and seen a signs "quarantine /!\" in the Cardiology Hospital.
<guix-vits>though i'm doubt that the letters is so different (seen a persian at ask.fedora -- that is hardcore, i guess)
<usney>I am thinking about getting a pinebook pro. Since it seems there is no user friendly distro approved by GNU that supports the aarch64 arch. I am thinking about installing debian and installing the libre-linux-kernel then install guix for only free software. Is there anything else I can do to find out and remove non free software or make it more free?
<usney>perhaps there is already a guide somewhere I will have to search online for it.
<usney>Will I be able to see the app in gnome or can I only launch it via terminal? I'll find out shortly after it is installed anyways though.
<usney>it keeps complaining that it cannot change to the locale for each language file how do I get rid of that warning?
<Kimapr>oh, seems like i messed up with versions. setting `version` back to 1.2 fixed the issue, but the reason i edited the file was to patch the latest version and install it
<guix-vits>usney: i'm not a developer; if you'd installed Guix as a package manager on top of an other GNU Linux system, then you need to `pull` as root by default. i'm totally have no experience outside of System installation.
<guix-vits>usney: idk, but if guix-daemon isn't found, then it's not in the calling user PATH variable. Probably you need to reread the section of manual that was used to install Guix (as it's worked before reboot).
<rekado>the reason is that they have written scripts to convert the Bazel output to Ninja.
<guix-vits>usney: idk, seriously. i'd never installed Guix on top of something.
<rekado>Now I wonder how to approach this. For Linux libre we take Linux sources and run the deblobber script to generate the clean sources.
<rekado>I suppose we can’t do the same for generating the build system for Tensorflow, because the tools needed to run the scripts are unpackageable.
<rekado>But the alternative does not sound very appealing either: to have a lone maintainer run Bazel locally to generate the build system files, and then either host these files somewhere or add them to Guix.
<guix-vits>civodul: usney have had a troubles with the installation script today.
<rekado>usney: which user account imported the key and which is running the script?
<bricewge>lfam: BTW I managed to reproduce #36380 with your instructions.
<bricewge>I'm trying the fix suggested by Ludovic.
<andydarcyjewell>seems I've got past the "extraneous field initializers" error now, but now I need to add an argument to the "make" invocation. do I use #:make-flags for that, or is it only for things starting in "-" ?
<bricewge>That's when I noticed ssh-keygen doing it's business fine while the boot was still waiting for urandom-seed.
<jonsger>leoprikler: I would support that because MATE is heavily broken on master. I'm not so optimistic that my update on master branch will improve that situation a lot...
<andydarcyjewell>so, in my (inputs ...) section, I have to include a number of dependencies, such as libx11; assuming I need a #:use-module (gnu packages *whatever*) for each, how can I find out which package contains the library?
<leoprikler>either grep or just fire up the interpreter and let it tell you what module is missing
<guix-vits>Kimapr: cow-store needed for installation media which is read only, so during `guix system init` the items are downloaded and builded in RAM. As this can exhaust the RAM, cow-store copies things from RAM to target device and frees the RAM. NieDzejkob, correct?
<guix-vits>Kimapr: this service is defined in gnu/system/install.scm
<NieDzejkob>built*. cow-store doesn't exactly copy the things, it uses overlayfs to assign the target device as a "backing store", but the essence is there
<raghavgururajan>rekadoSO I have  option(ENABLE_VIDEO "Build mediastreamer2 with video support." YES).  cmake_dependent_option(ENABLE_FFMPEG "Build mediastreamer2 with ffmpeg video support." YES "ENABLE_VIDEO" NO).  cmake_dependent_option(ENABLE_SDL "Enable SDL support." NO "ENABLE_FFMPEG" NO).
<apfel>hi there, can i specifiy the version of an input? I tried (native-inputs `(("email@example.com" ,protobuf))) guix does not complain but uses the most recent version anyway.
<lfam>NieDzejkob: I was thinking about the ROP package. I'm not so familiar with that kind of work so I'm wondering what the potential use cases are?
<mbakke>NieDzejkob: you're better off with @dfn, unless you want to hack on Guile's Texinfo support
<mbakke>apfel: you'll need to refer to the correct variable name, i.e. `(("protobuf" ,protobuf-3.6.1))
<apfel>mbakke: well, the problem is that the name is always protobuf, no matter what version
<mbakke>apfel: you can choose whatever name you want, `(("bananas" ,protobuf-3.6.1)) will work just as well :-)
<apfel>mbakke: sorry, to be more specific, no matter what version of protobuf you want, the package is always called protobuf, only the package definition contains the version not the name
<apfel>mbakke: ok sorry, yea, you are right, my bad
<mbakke>apfel: the name only matters if you need to refer to it in a build phase, i.e. (assoc-ref inputs "bananas")
<roptat>and a package has two "names": its variable name (the thing after the define or define-public) and its package name (the thing in the name field of the package definition)
<roptat>the cli uses the package name, but package definitions refer to packages by their variable name
<NieDzejkob>lfam: well, it's a domain specific tool. Do you want to know about the domain, or how the tool is useful within the domain?
<roptat>in inputs, you have ("some-arbitrary-name" ,some-variable-name)
<roptat>the right part of the inputs refers to the package, so it uses the variable name
<lfam>NieDzejkob: I guess I'm trying to tease out some insight about a sensitive question. Does the program have white-hat use cases?
<roptat>the left part is an identifier that can be used inside the package definition if you need to, but is usually skipped
<roptat>usually they are both the same in inputs, but the name on the left is a string, the name on the right is a variable reference
<NieDzejkob>lfam: it's not really sensitive, I'm just trying to understand your question well so that I don't type a lengthy explanation to a question you didn't ask :P
<apfel>roptat,mbakke: yea, sorry, i was confused. I somehow was working with the assumption that there where no protobuf packages with the correct version name. Package as in package definition, or symbol name.
<lfam>I've only heard about ROP chains in the context of what we might call bad behavior
<apfel>roptat,mbakke: but i think i was not explaining the problem very well
<lfam>But obviously it's important to learn these techniques and be able to discover exploits in order to fix them
<NieDzejkob>lfam: exploit development does have white-hat usecases. The one I'm interested in is CTF competitions, but the skill is necessary to, for example, create a proof of concept that a bug is exploitable
<NieDzejkob>lfam: as for phrasing the description to emphasize the light side, I'm not sure there's a much better way of phrasing it than "Oh hey, by the way, if you're wondering if this has non-illegal usecases, [explanation]"
<lfam>No, you don't have phrase it like that. I don't think legality comes into it; it's more about ethics. But I think you can talk about it in terms of security research and educational tools
<drakonis>python has a lot of scaffolding for generating bindings
<roptat>so, currently only surefire-plugin (the plugin that runs tests) is broken; it's supposed to fork itself and run the tests in the fork, using Junit4Provider. If there is not provider, it forks itself and the fork fails because it can't find the class. If it's present (and with the correct version), I get a NullPointerException in the main process, before the fork is created
<roptat>I'm pretty sure it has something to do with classpath handling, because the fork process will execute a generated jar that contains only a manifest with a specific classpath, so it can load junit and the junit provider
<rekado>with a lot of time we could probably untangle all the BUILD and *.bzl files in the tensorflow repository and write an equivalent build system.
<roptat>when their is no provider, the generation of the jar is incomplete, but it doesn't trigger the null pointer
<roptat>anyway, this is going to be more difficult than I thought...
<rekado>I suppose we could even parse all the BUILD files and implement a “bazel lite” that allows us to produce a build script
<rekado>…and this is where python-on-guile could come in handy again: the .bzl files look like a Python subset.
<rekado>but I gotta say that I don’t like the feeling of being tricked into engaging with a project that doesn’t care about conventions
<rekado>innovation is fine, of course, and it’s great that this is free software, but …
<lfam>I feel like it's always tough when Google makes a free clone of one of their internal tools. I've never heard that they are a joy to use
<drakonis>this is a second generation of their internal tools
<drakonis>bazel is the tool they designed with the lessons learned from blaze
***pkill9_ is now known as pkill9
<leoprikler>the first lesson is you can never have enough boostrap jars
<goldenshimmer>Have solved my question from last night by a change of mindset — even after getting past the unbound input variable, I couldn't do anything with it — seems that snippets don't have the build environment available, hence all my invokes failing; I have to stop thinking about the extra origin as part of this package, but as its own separate hidden one, to only be returned by guix build --sources=all (indeed, that is how
<goldenshimmer>works for adanaxisgpl). That resolves the mystery. Thanks again!