<albertoefg>sneek: tell lfam that he is very kind to allow robots to take vacations <sneek>lfam, albertoefg says: that he is very kind to allow robots to take vacations <Petter>albertoefg: tell sneek lfam is very kind to humans too. <atw>lfam: what was the bug number? Can't seem to find it <lfam>atw: I'm not sure if there was one or not. I just meant that you should look for recent discussion of connman or wpa-supplicant <atw>hmm, think I found it on -devel ***atw` is now known as atw
<albertoefg>sneek: later tell lfam to tell me if he wants to play hedgewars <atw>what's the make target for the documentation? ***reepca` is now known as reepca
<sankey>i could be wrong, but i'm pretty sure that guix really needs your pius patch from many months ago :) <rekado>we could use a later commit for the pius package <rekado>(if it’s urgent and a new release won’t happen in a while) <sankey>indeed. in general, a new release would resolve this issue for any distirbution that upgraded to gpg 2.1 <sankey>a guix user would have to attend a keysigning party that provides a keyring file for pius to work <sankey>but i think most people just sign keys one-at-a-time, and not during parties <sankey>i've never been to a keysigning party *that* organized <sankey>now that you mention it, i'll probably just make a new guix package definition using the tip of master <Sleep_Walker>mcron is stopping and disabling itself after start - how can I find why? <civodul>sankey: i thought they had integrated the patch for gpg 2.1? <civodul>or maybe they did but didn't make a release? <civodul>Sleep_Walker: not ideal but i would try to start it by hand with the same config file <civodul>you can find out what the config file is by running "guix gc -R $(readlink /run/current-system| grep mcron)" <ng0>ACTION compiles libreoffice the 5th time in 2 days because of a typo in the patch <ng0>i think around 4 hours or something <ng0>depends on where you compile <rekado>do you apply a patch to the sources or just install symlinks in a build phase? <ng0>I had libreoffice between 2 and 13 hours differeces <ng0>in the build phase, yes <rekado>when I do something risky I like to put the new build phase right after unpack and fake it <ng0>snape: *I had libreoffice building very fast (2 hours) and the maximum was 13 hours, it depends on where you build it on <snape>yeah. I used to work with libreoffice, and it built it in 2 hours with linux <snape>and around 20 hours on the VM for windows :) ***Guest21007 is now known as sturm
<aggelos_>hey all. I'm looking into a way of building program binaries for analysis purposes (research) and was wondering if guix would be suitable for that <aggelos_>is it easy enough to describe the exact versions of the software + deps for others to reproduce? <aggelos_>last time I looked, it looked like you'd probably have to specify the commit id of the repo that you built from? <aggelos_>any docs or blog posts on guix from that PoV? <thomasd>aggelos_: AFAIK yes, because guix upgrades will contain new versions of packages <thomasd>though the situation will likely improve <aggelos_>thomasd: is it easy enough to fork the repository and have your local changes? (possibly for upstream submission, but initially just to try stuff out) <thomasd>yes it's easy, in my opinion, the easiest way is add a local directory to GUIX_PACKAGE_PATH (e.g. ~/my-packages), and define your own packages there <thomasd>i.e. create "~/my-packages/research.scm", in which you (define-module research ...) and add your packages <aggelos_>thomasd: hmm, but then I would not be capturing which deps I'm building against, right? <thomasd>it would still use the dependencies defined in the version of guix you're currently running <thomasd>so you could specify the guix version number together with your custom module definitions to precisely define your dependencies, but until we have `guix channel' or a similar features, it's not trivial for others to reproduce the exact setup, AFAIK <thomasd>(not trivial, but probably not too hard either :) ) <aggelos_>thomasd: so using my own branch of the guix repo is not an option? <aggelos_>or, better: where do I find that in the manual? I must be looking at the wrong place <thomasd>and also the next section, "running guix before it's installed" is useful <thomasd>What I do is, install the binary guix distribution, then setup my environment for guix with "guix environment guix", and (from the git checkout) use ./pre-inst-env guix ... <aggelos_>thomasd: thank you, that's the info I was looking for <thomasd>yw. Though I understand that features to make these things easier (reproducing specific versions without explicitly using git) are one of the areas of interest. <jmd>I'm considering writing macchanger service, to set the mac address of interfaces. <jmd>Do people think that is a good idea, or would it be better as an option to <jmd>some existing service? <ng0>my theory is, it is because I run ntpd <ng0>so it should be okay when I stop ntp and test tlsdate then, so I can finish the tlsdate-service <cbaines>I'm having trouble getting a specific version of ruby within an environment, guix package --show=ruby@2.1.10 seems to work, but guix environment --ad-hoc ruby@2.1.10 just gives the newest version of ruby? <roelj>rekado: Cool! What exactly is BOB? <roelj>rekado: A technology preview conference for developers? <rekado>roelj: they say they are a "conference for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today" <rekado>since they had a talk on Nix before they asked me to also discuss differences. <rekado>I'll do that by showing off how one can interact with packages on the REPL and how Guix can be used as a library for tools like "guix web" or "guix graph" <civodul>it seems we'll have to do that more and more <civodul>because now many people know Nix, which was not the case in the past <rekado>I don't really like doing this, because it usually shifts the tone from "hey, this is cool" to "we're better" <rekado>it depends a little on the audience <rekado>looking at the programme I think I'll also have to answer questions about typing... :) <roelj>rekado: Cool! Good luck with the talk. <roelj>By that time we maybe have some more differentiated features in Guix (differentiated from Nix). <cbaines>I thought I'd try using an expression as that has worked around similar problems in the past, but that does not seem to be working either: <cbaines>→ guix environment --container --ad-hoc --pure -e "(begin (use-modules (gnu packages ruby)) ruby-2.1)" -- ruby --version <cbaines>ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux] <buenouanq>nix pioneered something wonderful, and you have taken what they started, learned from it"s shortcomings, and improved upon it <roelj>cbaines: I get the same results when running 'guix environment --container --ad-hoc --pure ruby@2.1.10' <rekado>cbaines: FWIW I get the same result. <rekado>is this because they all inherit from "ruby" and "ruby" has a replacement? <buenouanq>how do I find which perl package contains the text::aspell module? <buenouanq>I don't even know if what I said makes sense. <rekado>buenouanq: usually, we name perl packages after the module, i.e. Text::Aspell would be perl-text-aspell. <rekado>buenouanq: looks like we don't have it yet. <cbaines>roelj, rekado ah yes, if I comment out that replacement line in the 2.3.1 ruby definition, then I get the right version <roelj>buenouanq: So we don't have that package yet. Pro tip: guix import cpan Text::Aspell <buenouanq>I'm still new to this - What does import do? <rekado>cbaines: this looks like a bug. Could you please send an email to bug-guix@gnu.org lest we forget about it? <rekado>buenouanq: it creates a package definition. <rekado>it downloads metadata from upstream and formats it nicely <roelj>buenouanq: It gets you started to package it for use in Guix <rekado>it only takes a little bit of work to bind it to a variable and build the Guix package it describes. <ng0>do we have no (conflict) or something field for shepherd? <ng0>for example tlsdate conflicts with ntpd <cbaines>if I remember correctly, only one service is allowed to provide a single "provide" at a time <ng0>so I make it (provision '(ntp)) instead of (tlsdate) <roelj>I have had a problem for a while running an R session in a container: guix environment --container --pure --ad-hoc r r-nmf <roelj>In the container I cannot run R and load: library(NMF) <roelj>But this seems to work when building packages that depend on NMF. So I wonder.. what am I missing here? <rekado>roelj: is this a problem only for r-nmf or also for other packages? <roelj>rekado: I've seen a similar error on r-deseq2 I think, but I cannot reproduce at the very moment. <roelj>I haven't found this code in the NMF package anyway <roelj>Mine is installing r-deseq2. Curse the alternative store path prefix ;) <rekado>I get an error: Error : .onAttach failed in attachNamespace() for 'NMF', details: <rekado>but that could be because of this: "sh: wc: command not found" <roelj>No, including coreutils just removes that error. <roelj>Then the call: if (n > 2) n <- n - 1L remains <rekado>error: missing value where TRUE/FALSE needed <roelj>Yes, and that also happens when loading r-deseq2, because of BiocParallel <roelj>Though, there it isn't fatal <roelj>Funnily enough, both have that sh: wc: command not found right before the error. <rekado>do you know where this comparison is made? <roelj>No.. It isn't made in the NMF source code. <roelj>I start to think this could be somewhere in the R source code itself <roelj>since it affects multiple packages (though in a slightly different way) <roelj>I tried to strace for open, access, and stat calls, but couldn't pinpoint the problem. Both inside and outside the container look the same (apart for different store paths). <roelj>Nothing obviously smuggled from the environment beyond Guix. <rekado>on line 128 "runHook"; that's where the error is thrown <roelj>So, what if sys.nframe() on line 181 is not available? <roelj>Nah, that is part of 'utils'. <roelj>I can't find anything non-trivial that the R build system does that would avoid this error. <fredmanglis>Hi people. Do you allow packaging of software in beta stage, or must it always be stable? <rekado>fredmanglis: we usually stick to stable releases, but sometimes we make exceptions. <fredmanglis>Okay. cool. So, what would the exceptional conditions be? Is there a place these are documented, so that I can read through? <rekado>in general that's a case-by-case decision. <fredmanglis>Okay. Thank you. I will submit my patch and see what happens :-) <snape>what's the Guix policy concerning GPL licenced programs that don't have licence notices on top of files? <rekado>snape: if there's a readme file that states that the GPL applies to this software I think that's also acceptable. <civodul>rekado: re tone of the audience, i really agree with you; sadly, i've noticed that people often want to be spoonfed with an executive comparison <ng0>I assume tlsdate-service is functional. there's this old problem again where I would have to setup an network brige and start qemu with the right parameters to make the lookup of dns succedd in the machine. <ng0>i'm very open to suggestions on how to test this. so far I just know I pass the right commands to tlsdate <ng0>networkmanager can add bridges.. and iputils. but is there something guix specific for the config of the host? or is it still manual? <thomasd>I'm packaging kdevplatform. Most test will only work *after* you have run 'make install'. Does it make sense to move the 'check phase after the 'install phase for this package, or do I just skip the tests? <rekado>thomasd: we move the check phase in some python packages. Moving the phase (if there's no other way to run the tests) is fine. <thomasd>rekado: thanks, I'll look at those packages. <quiliro>how can i tell what version of GuixSD I have booted with? <quiliro>Also...'loadkeys dvorak-es' gives me an error (on the boot USB): <rekado>quiliro: /run/booted-system/parameters shows you some info about the booted system. <quiliro>rekado: I cannot find the file where it say wether i have GuixSD 11.0 <rekado>quiliro: another way is to do "grep -A1 guix /run/current-system/profile/manifest" <quiliro>what do you think is the best way to learn about GuixSD when i have no internet connection <quiliro>i have read the whole manual already <quiliro>in theory, i know haw guix and guixsd work <quiliro>i have installed it a few times already <quiliro>but i cannot progress very fast because i am mostly offline <rekado>quiliro: what is it you want to learn about it? <quiliro>i want to learn how to contribute to create packages to install <quiliro>i like guixsd to be an end-user friendly distro <quiliro>so that anyone can install as easily as trisquel <quiliro>with scm files for diffferent pre-established confs such as destop.scm is <quiliro>by the way..it is an honor to chat with <rekado>users would probably benefit from a front-end that allows them to edit the operating-system configuration without fear of breaking things. <quiliro>i saw your talk at libre planet from last year i think it was <rekado>(I gave talks at fosdem last year) <quiliro>well..i want to contribute...that is it <rekado>quiliro: I don't know if anyone has started working on such a front-end yet. Maybe this would be something you could take over? <rekado>it's a little hard to come up with the right set of requirements for such a thing <quiliro>i have version 10 so i am downloading 11 now to instal in a centrino duo <quiliro>rekado: don't worry..i will find out how to help when i get to learn offline <rekado>on the one hand we want to make it easy for people to customize their system, but on the other hand we don't want to restrict them by dumbing down the customization interface. <quiliro>but how can i download the current repo so i can install and reinstall, offline? <rekado>you will need the source tarballs of all packages you want to install in addition to the Guix source code. <quiliro>i will follow your instructions ...i won't become a load but will help <rekado>I haven't done any offline installations yet, so I can't really help here. <quiliro>ok....with your tip...i will try to figure it out <rekado>you can download sources with "guix build -S ..." and a list of packages. <rekado>how do you get access to the internet? <rekado>is your GuixSD machine not online? <rekado>does it have a network connection to a system that is online? <rekado>if so you might be able to configure offloading <ng0>i will post the first version of tlsdate-service to the list when I'm back in one or two hours, I definitely need to get input on vlan0 and connection to the outside of host from qemu. the service works, but it would make it easier to test. <quiliro>rekado: were you suggesting installing guix on a running system and not guixsd? <rekado>if you're currently using GuixSD you can update to the latest version by "guix pull" and "sudo -E guix system reconfigure /etc/config.scm" <rekado>but that requires that your machine be online <rekado>if it is not and you have another machine that *is* online you might be able to set up offloading by installing Guix on that other machine. <rekado>yeah, I've seen it (and upvoted your comment) <davexunit>looks like flatpak works by explicitly distinguishing "common" dependencies and bundled stuff. <rekado>it's hard for me to understand why flatpak is considered exciting <sankey><civodul> sankey: i thought they had integrated the patch for gpg 2.1? <sankey><civodul> or maybe they did but didn't make a release? <sankey>my personal rationalization about flatpak popularity is that its somehow easier to explain without using math or computer jargon, and it closely resembles the process that most people in the world package software (proprietary software bundling dependencies) <rekado>one can explain Guix without jargon, too. <rekado>davexunit: FWIW I'm using "runtimes" with Guix as well :) <rekado>some users don't like to wait for me to package R stuff, so they have a shared Guix profile with gcc-toolchain and a couple of common libraries. Then they can use their usual workflow to build software. <rekado>without any of the guarantees Guix provides, of course. <rekado>I find it interesting that with Guix we could totally offer something like flatpak <rekado>it's just that we choose not to. <rekado>(because it's a bad goal to aim for) <davexunit>I think it's OK as a transition step towards a fully-specified Guix package <davexunit>thought I think flatpak also has the goal of helping proprietary software but just won't say it. <rekado>yeah, that's been my impression too <civodul>they talk about "ISV applications", which i think is a nice way to say "proprietary stuff" <civodul>rekado: emacs-org installs its Info file in the wrong place, which is why we don't see it <davexunit>the author of the blog post I posted above got mad at me <davexunit>says that guix solves none of the problems he cares about <jmd>Well maybe he has different cares. <roelj>I am reading the original article, but cannot find what his problems really are <roelj>Only "Releasing ISV applications on Linux is often hard." <bavier>they have issues trusting other people's dependencies, but want users to run their flatpak? weird <bavier>well, by "trust" they might be "trust they work for my application" <davexunit>"Something like the Windows API or OS X API would seem to provide a reasonable approximation of what functionality ought to belong in the base system. These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries." <civodul>i like how they insist on "security-related sandboxing features" for flatpack/snap <civodul>what they don't tell is that you absolutely need them because you're running an opaque binary <davexunit>"...where the target distro [GuixSD] has almost no users, no traction, no user acceptance, no institutional knowledge, and a crap first-run UX that involves mangling bashrc." <davexunit>the ideas of guix are really controversial on HN <lfam>At least they got the capitalization correct ;) <sneek>lfam, albertoefg says: to tell me if he wants to play hedgewars <[df]>afaics things like flatpak are only useful for proprietary software <davexunit>but I haven't yet seen any Flatpak evangelist admit that. <lfam>davexunit: I remember getting a patch for some bioinfo software where all the inputs where custom Git URI origin fields, because the packager wanted to use particular Git commits of each direct dependency. They are worried about the same thing as the flatpak advocates in that thread. <[df]>and even then they're no good if your end user happens to be using a different hardware architecture <lfam>You know I'm on our side, but they have valid concerns IMO <lfam>If their application is in the GNU Guix packages, and they ask their users to install it with Guix, then they do have to ride the wave of updated packages to make sure everything keeps working. Of course, with their model, they still have to ride the wave of all the unbundled dependencies, but that's a smaller set of packages to watch <davexunit>lfam: the concerns are valid, but if only they would give Nix and/or Guix a chance <davexunit>Flatpak software still needs to ride the wave of the people updating the "common" stuff <lfam>It's extremely frustrating to see them dismiss it like that, when they surely haven't investigated it fully <davexunit>in Guix, it's up to you what the "common runtime" is. <lfam>It would be useful to have an example of some complex end-user application being packaged for Guix in a way that satisfies their concerns <lfam>This would make for a great conference presentation <lfam>Packaged for *or* with Guix. It might not be something we'd accept in GNU Guix <lfam>It might resemble that bioinfo example I gave <lfam>Or it might use a guix.scm <davexunit>something like that might get some people to stop dismissing us instantly. <lfam>How to use our tooling to provide a very stable experience for *years* <lfam>Eh, people like to speak that way on the internet <lfam>It's easy to be rude when you are face to face with a computer screen <lfam>And something about our forums encourages this attitude <lfam>I think I've never had a conversation like that IRL <lfam>Sometimes I wonder what it would be like <OrangeShark>seems like that one user thought Nix and Guix use latest versions of software to always build all the software <davexunit>I'm definitely guilty of it at times. it's not good. <lfam>OrangeShark: Well, we *do* do that, if we are paying attention to upstream updates :)( <lfam>We tend to just update to the latest version after spot-checking a few referring packages <lfam>For core packages, it takes a little while longer <OrangeShark>yeah, but some packages do specify specific versions if necessary <lfam>Yes, when we notice breakage :) <lfam>But we don't try to put the whole puzzle together at once like the "mutable /usr" distros <lfam>So, users are protected against breakage that manifests in the form of fail-to-build-from-source. But more subtle breakage does get into user profiles <OrangeShark>I am sure if a project wants to only allow specific versions of dependencies, they would clearly state it somewhere in their documentation <lfam>I noticed that Haskell packages have this info on Hackage <lfam>It could be useful to programatically take advantage of it <davexunit>I think it's good for applications to depend on the latest stuff, but promote particular builds as "blessed" or whatever, meaning that the maintainer built the software with *exactly* this and it works well. <bavier>yeah, that information is available for most perl packages too, just a matter of deciding how to make use of it I think <lfam>We need to have a clear demonstration of how so-called "ISVs" can offer an equally stable experience for their users as with bundling, and also be something that requires equal or less work for the vendor <davexunit>with guix, you *could* bundle if you really wanted to, but we give you the tools to avoid that. <lfam>Heck, it's dead simple to build Syncthing with all the bundled stuff. <lfam>Just use the default invocation of the Go build tool <lfam>I do this in my 3rd party repo (all the dependencies are free software) <lfam>*HINT* Any Go programmers are invited to help me package Syncthing properly :) :) :) <davexunit>it's nice to be able to decide your own level of "fuck it" <lfam>I did that, but I'd really like Syncthing in GNU Guix. It's an awesome tool with some a large community <bavier>we often note input version dependencies in comments, but I suppose we could declare the constraints in code somehow too <lfam>I'm about to rebase that branch <lfam>I rebase it on master and sign the HEAD <lfam>Seems like it's in a poor state ATM <jmd>Using git reminds me of my school days. <lfam>It's also wrapped up in my work maintaining our Go package <lfam>jmd: Yes, it's not a great solution. Time to package it for real :) <lfam>I updated the branch. I'm doing that dumb rebase method because I want all the Syncthing commits to stay together. But I'm sure it's a PITA for anyone using it <bavier>davexunit: I wonder what sort of event will need to happen to get guixsd out of the "no users" stigma <jmd>I don't think we should worry about that too much. <lfam>"Desktop GNU / Linux has no users" <jmd>One of the things I like about guix is that it to some extent removes this artificial distinction between users and developers. <lfam>BTW, I hope that anyone who is interested in Syncthing, and wants to build it from source, will try my package. I've been using Syncthing for a long time and I am sure this package works properly. It includes documentation and all the server-side tools for anyone who is interested in using those too. <lfam>I have not been able to figure out a good solution for a Go build system, so I've kept it in my own repo all this time, but I'm sure that with some more attention, we could figure something out <lfam>I *still* see people who are in the world of FOSS software talk about using Dropbox. Syncthing could totally eat their lunch <davexunit>I agree with jmd on this one, though I wish people wouldn't assume that no one uses guix because clearly many people do. <lfam>Eat Dropbox's lunch, that is <davexunit>active IRC channel, active mailing lists, etc. <lfam>Commodify reliable and useful file sync <davexunit>I want to confirm that Dolphin (gamecube and wii emulator) has no hidden proprietary bits and get my package upstream. <lfam>With a partially copyleft code base <davexunit>been using it for awhile, works great. GPLv2 software. <Petter>lfam: I write Go code, and could possible help if there are any language questions. Not so much with packaging unfortunately :/ <lfam>Syncthing lacks the centralized "always-on" server node, but I see this as a business opportunity <bavier>davexunit: I'd review your dolphin package, if you'd like; I've been wanting to give it a try <lfam>Some enterprising free software sysadmin could provide this for users who don't want to run any servers <lfam>Petter: The big stumbling block for me is setting up the GOPATH before building <lfam>Petter: From what I can tell, most Go packages require this to be set properly, with the directory structure to match, in order to build. But, I can't figure out if this path can be determined programatically, or if a human needs to figure it out, and set it manually <lfam>I need to take a really long train ride and dig in <bavier>davexunit: thanks, I'll look it over <Petter>lfam: The directories must match the imports in the code, which is of the form: "github.com/boltdb/bolt". <lfam>Petter: Right, I know that much. But is there a way to learn that path string without using human intuition? :) <Petter>It matches the git location usually. Are you getting the dependencies with git? <davexunit>efraim: does that work? the package list isn't an alist <lfam>Petter: We could do that, although it can be very inefficient to fetch the Git repo compared to a release tarball (Git repo's may be huge). Although Go libraries seem to not have tagged releases, so fetching from Git may be the only option in that case. <davexunit>each element is a list, (cons a (cons b '()), not a pair, (cons a b) <lfam>Petter: Of course, my Syncthing package fetches the Git repo to get at the manpages, so it's a wash :) <davexunit>it would just match the car and remove the element entirely <bavier>davexunit: I think the alist functions just operate on the cdr, which is a list then <lfam>Petter: Do you think it makes sense to try fetching everything from Git? <lfam>And then somehow extracting the Go path from the Git URL? <Petter>lfam: Well, you at least need the git address. <Petter>lfam: And it would need to be put correctly in GOPATH. <lfam>I mean, it sets the GOPATH manually for now, but I could change the package to fetch from a Git commit and extract the GOPATH from the Git URI <lfam>Do the Go build tools let you use symlinks? That would be cleaner if it worked <lfam>Rather than using (with-directory-excursion) to jump into the directory when necessary <Petter>I'd assume so, that `import "github.com/boltdb/bolt"` just uses what it finds at "$GOPATH/src/github.com/boltdb/bolt". <lfam>So, the package could have the Git URI and the GOPATH both referring to some variable, and getting the correct string for each use case somehow <lfam>Er, the go-build-system, not the package <lfam>So, the human packager would need to provide the value of this variable, the hash of the source code, and in many cases the Git reference hash <Petter>I think I would make the GOPATH workspace a temporary place during build, and symlink in those dependencies with their git address. <Petter>Then the dependencies could be in /gnu/store as usual. <Petter>I'm probably cross-talking with what you said. <lfam>Right, that's something I considered before. Create a symlink forest in the build directory of the package that is being built <lfam>I have to say, I'm not in love with the choices made by the Go authors in this respect <lfam>Even seasoned Go programmers complain to me about this <lfam>Like, it seems to be designed around the needs of Go programmers building software for themselves on their workstations <lfam>Anyways, if Debian can do it, so can we <Petter>If I remember correctly from early on, I think they said they'd leave it to the community to work this out. <lfam>Hm, well, here we are :) <Petter>Right, so, maybe not the best call :P <lfam>I want Syncthing and the Let's Encrypt CA server (Boulder) to package available with Guix <Petter>Is Boulder written in Go as well? <lfam>Yes, whereas their client is Python <lfam>And there are no other implementations of the CA server yet <lfam>albertoefg: It's not a web app, it's a peer-to-peer client application, and it works great :) <lfam>But we are trying to figure out how to package it for Guix <lfam>It's written in Go, and Go doesn't have a good story for distro packagers yet <lfam>The primary user interface is a locally-hosted web page <albertoefg>how can people complain of stupid stuff like Google drive <lfam>I think that Google Drive also has collaborative editing tools, and that's outside of what Syncthing tries to do. I understand why people choose Google Drive <lfam>OrangeShark: I recommend it highly :) <albertoefg>I've never needed collaboration tools lol that's why i keep forgotten those exist <lfam>OrangeShark: It builds the bundled free software dependencies from source <lfam>This is not really acceptable for GNU Guix, so I haven't advocated to include it yet <lfam>Cool, please let me know if you have trouble with the package. And there is help available on Freenode #syncthing and on forums.syncthing.net <lfam>Owncloud seems like a good thing to work on if one is interested in a replacement for the Google collaboration tools <lfam>OrangeShark: We do have a "system tray" tool for Syncthing in GNU Guix, qsyncthingtray <lfam>efraim packaged that recently :) <OrangeShark>Didn't owncloud get forked by a lot of the main devs? <lfam>Yeah, I heard about that. Hopefully the project continues to thrive <lfam>I don't use it so I'm not sure which is the "good" fork <lfam>So, do we want to graft zlib? :) That might be the entire distribution <lfam>I request some expert C programmer advice on this subject. bavier, mark_weaver? Who else? <Petter>lfam: There's another issue. A Go package with two dependencies, where each of those refers to the same third dependency, but of different versions. <lfam>Well, we'd have to create versions of the 3rd dependencies with differente upstream Git commits <Petter>If such a situation is detected I think it would be necessary to prepare GOPATH for one dependency, build it, then switch some symlink in GOPATH and build the other. <lfam>How do Go programmers deal with this? My understanding is that they just use "whatever is in my ~/src tree", which means there would only be one Git commit checked out while building. Is that right? <lfam>That "use whatever is there" practice is why upstream repos all refer to seeminly arbitrary dependency commits, in my totally naive understanding. <Petter>Yes. So, some people have different workspaces pr. project and updates GOPATH when they'll be working on another project. <lfam>I mean... do Go programmers actually notice with dependency commits they are using? It seems abitrary from my perspective <Petter>It also makes it difficult to collaborate, when the next person sets up their workspace, they'll get different versions of the dependencies. <lfam>And that's why Syncthing bundles all the Git repos <lfam>Using whatever Git tool enables such a crazy idea ;) <Petter>Because there's no one good way of doing it, different projects provides different solutions. <Petter>In GOPATH though, there's a /pkg which fills up with .a files. I presume these take priority when building. <lfam>What are .a files in this context? <Petter>I believe /pkg is a cache of built packages. <Petter>To avoid compiling unmodified packages. <Petter>In case you don't know, GOPATH has /bin, /pkg and /src. <lfam>Petter: What do you recommend we do from here? Are you interested in taking on a go-build-system project for Guix? :) <lfam>It could even just be something can build one significant package, like Syncthing. And we'd improve it from there. <lfam>Something that could be used to build Syncthing it its dependencies, of which there are a few dozen <Petter>I could participate at least, I've got ideas I think would take us all the way home :) <lfam>You certainly have more knowledge than I do <Petter>And it would give me a reason to look into more of this stuff which i don't deal with consciously at all when I'm programming. <lfam>You would definitely get help about the Guix system, but I think none of us know enough about Go <Petter>My experience is limited to one guy projects. Things tend be slightly easier in such cases. <Petter>I guess we would need different strategies depending on how the project to install has solved their dependency situation. <lfam>Right, but this is why I think we should start with one significant project (that is, not a simple library with no dependencies), and then generalize or change the go-build-system as necessary <Petter>How are bundled dependencies usually solved? <lfam>Ideally, we delete them in an "origin snippet" and rely on the upstream build system to find and use the copy we provide. Most build systems do this on their own, but sometimes we have to apply some patches <lfam>These patches usually just change a path somewhere <lfam>Sometimes, it's not feasible to unbundle, so we document it and just accept it, or leave it for later <Petter>This doesn't account for a specific version though, does it? <lfam>Well, if the package needs a particular version of some software that is different from the version we have packaged, we can make a package variant that selects a different version <lfam>In that case, the packager needs to know the version ID (tag or commit) and the hash of that source code <Petter>Ah yes, you would specify the version in the recipe. Doh. <lfam>These variants can even be constructed in the inputs list of the package <lfam>For Go, that might be the thing to do, since these variants typically won't refer to a tagged release version of the dependency, so there won't be much point in defining and exporting the variant <lfam>I'm trying to think of an example in our packages... <lfam>The icedtea packages in (gnu packages java) do something interested with the source code "drops". See icedtea-7 <lfam>It defines a procedure 'drop', and then uses it in native-inputs <lfam>But, you can define package variants without using a custom procedure <lfam>I mean, you can define package variants in the inputs list without using a custom procedure <lfam>Unfortunately, I can't remember any at the moment <Petter>I envisioned a list of dependencies and corresponding git commit. What do you think of this? <lfam>You can see the (gnu packages ldc) for an example of defining inputs directly in the inputs list <lfam>We'd need to figure out exactly what information was necessary, and offer a nice interface to packagers. It could be like you suggest ***Steap_ is now known as Steap
<Petter>Well, it looks doable. May not be super elegant though. <Petter>I will make some efforts, and we can discuss more then. <lfam>Petter: Cool, let us know if you have any questions! <civodul>lfam: i'm working on putting hydra back to life <civodul>with the migration to the new offload thingie <wingo>showing appropriate respect :) <ng0>Petter: i think the first version of a build system doesn't have to be super perfect, it's always subject to change <ng0>is there anything in place for guixsd where (network) bridges can be added other than the usual (ifconfig, networkmanager,..) tools? <ng0>ok, thanks. so I'll add the bridge myself everytime I need it I think.. I don't use bridges very often but it would help if I could give the guix generated vm full access to outside <civodul>you could always add a service that invokes the right command <ng0>so far I did stick to what we have or created new services which aren't ready yet.. is this documented in shepherd or in guix? <ng0>a yes to an 1 or 2 means I should read both I asume :) <quiliro>is it possible to install guixsd offline? <quiliro>i do not have time to install but i can download anything now to install at home offline <quiliro>there i can spend all the time in the world <quiliro>i suppose i have to download the binaries or the source and then point the installer to the files <bavier>I've only tried this once before with a minimal os configuration <bavier>the idea is to create an os configuration that inherits from the one defined in the (gnu system install) module, then have 'guix system disk-image' build it <bavier>you can then boot that and install as usual. if the configuration you declare is a subset of the one you created the disk image with, you shouldn't need to access the network, since packages will be in the installer store already ***Dezponia_ is now known as Dezponia
<quiliro>how can i download all the binaries and point the guixsd usb installer to them? <bavier>quiliro: they're in the store, but you'll want to use 'guix system disk-image' pack them up for an offline installer <quiliro>bavier: ok i will study the command so i send the right parameters <bavier>the network I'm on currently is too slow to try anything myself <quiliro>bavier: will you please tell me what to investigate? <lfam>But bavier's idea about putting them in an installer is probably the rigfht thing as well <bavier>lfam: quiliro would like to install guixsd offline <lfam>Putting all the binaries in the installer seems like it would take up a huge amount of disk space. Wouldn't it be more feasible to include the sources? <lfam>Perhaps there isn't a big size difference <bavier>lfam, idk, it's certainly a decision that would require compromises <bavier>and you certainly wouldn't need *all* packages in a single image, just those you're interested in <reepca>... now I'm curious how much space it would take to have all packages on a disk. <lfam>civodul: Will you let me know when I should try restarting the staging evaluation? <bavier>blah, problems in that paste, beware <bavier>I don't think services is a good example, better would be just packages <quiliro>please tell me what i should try or study to install binary (or source) guixsd offline <bavier>quiliro: check out the modules in gnu/system/* <quiliro>bavier: so what should i do with that? 'guix system disk-image' ?? <bavier>quiliro: yes, with the first chunk <bavier>that'll give you an image that you can dd to a usb <quiliro>bavier: so i boot from guixsd usb and then use the paste with 'guix system disk-image' to create a usb image? <quiliro>and with that image i can install offline?? <bavier>quiliro: if everything works, yes <civodul>lfam: as usual, not everything is going as expected, grrr <quiliro>ok ... iwill test next time because i only have 20 more minutes <quiliro>willl you suggest what to study to learn in order to be prepared appropriately for next connection? <quiliro>so i can do it quickly on my next connecction <bavier>civodul: is there any way to inject arbitrary store items into an operating-system disk-image? <civodul>bavier: yes, via 'gc-root-service-type'; see (gnu tests install) for an exampl <quiliro>or how can i help in order to achieve offline installation <bavier>quiliro: check out the gc-root-service-type that civodul just mentioned, you should be able to use that to inject package source tarballs into an installation image <cbaines>So, I'm having some fun trying to get the postgresql service working with the en_GB.utf8 locale. There was a thread on help-guix about this recently, and looking at that suggests that the postgresql binaries might need wrapping such that they have GUIX_LOCPATH set? I'm unsure though, as there doesn't seem to be any examples of this being done? <lfam>cbaines: Shouldn't it be enough to set GUIX_LOCPATH in the environment, without wrapping the package? This is what we suggest in the installation docs, under Application Setup <cbaines>lfam, I did consider that, but then you couldn't ensure that GUIX_LOCPATH that was set in the service matches the right version of glibc that postgresql was built with? <cbaines>I also can't see any examples of other services setting the GUIX_LOCPATH <lfam>cbaines: This is on GuixSD? <cbaines>No, but its within a system container, so it should be very similar to GuixSD <lfam>There is the (locale-libcs) field that the administrator can populate with a variety of locales versions <lfam>cbaines: Okay, let us know if locale-libcs is insufficient for your use case <Petter>lfam: Do you think it would make sense for Guix to provide a way of setting up a Go workspace, for Go developers? With specific versions of dependencies. <lfam>Petter: We already offer `guix environment`, which is a language agnostic tool for setting up development environments <lfam>So, I don't think it's too far out of scope :) <lfam>Beyond that, I don't know. guix-devel is the place for real discussion of these things; not everyone will see questions on IRC <cbaines>lfam, I've tried setting GUIX_LOCPATH to /run/current-system/locale within the postgresql service activation script, but initdb still complains, and when running locale -a it still gives just C and POSIX <quiliro>bavier civodul: where in guix manual is the document i should read? <bavier>quiliro: it's in gnu/services.scm <quiliro>IN THE USB I CAN ONLY FIND GNU/STORE <bavier>quiliro: is there a /run/current-system/profile/share/guile/site/2.0/gnu/services.scm ? <bavier>quiliro: but you could adapt it to use package-transitive-sources for a subset of packages you're interested in <quiliro>bavier: no gnu directory for services.scm