<lfam>dannym: If the bug is not fixed or filed upstream, here is what I would do: Make a patch of the changes against the claws-mail source tarball we distribute. Apply it to our package definition as in commit 6f74aecdb30d. Finally, file a bug report upstream, and provide the patch. If the patch doesn't apply to upstream's HEAD, adapt it to do so.
<lfam>If it's not a bug but rather working around something Guix specific, then we usually do the patching while building, as in f5a8491b69830
<lfam>The difference is that the former is applied to the source tarball provided by `guix build --source`, and the latter is not. So, real bugs are fixed for someone who may use Guix to get the source code but does not want to build with Guix. But Guix-specific things are only applied while building with Guix.
<lfam>And when fixing upstream bugs in our packaging, I always include a link to the upstream bug report in the package definition.
<lfam>Hm, I have gnupg-2.0 in my profile. If I do `guix package -u`, it wants to upgrade it to gnupg-2.1. This seems wrong.
<lfam>Steap: I just saw this reposted on #reproducible-builds on irc.oftc.net. It's really the core of why I think it's worth the effort
<mordocai>So i've found a number of bad source links due to https redirection and gnutls not being autoloaded, but pkg-config seems to break when I update it. This patch http://lpaste.net/151987 results in this result http://lpaste.net/151988. Any ideas? I can't download/build pkg config due to this error.
<mordocai>In case anyone is curious, so far by doing guix environment guix --no-substitutes i've found libpcap, pkg-config, libva, and libdrm all needed their urls updated to be https or it fails.
<mordocai>But as above, pkg-config doesn't like being updated apparently
<Jookia>calher: What're you trying to package mate?
<mordocai>davexunit: Hey, do you happen to know why this patch http://lpaste.net/151987 results in this result http://lpaste.net/151988? My guess is it causes a circular dependency between pkg-config and gnutls but not sure. In any case, I can't build pkg-config because it is now redirecting to that https url so I downloaded it via hydra for now.
<calher>Jookia: I was originally going to package Mumble, but that sounded too hard. Now I'm thinking about packaging guile-irc, but that may also be too hard. I think I should just stick to something simple, like MCWM.
<sneek>dmarinoj, lfam says: I think you need a working installation of the Nix package manager in order to use the nix importer. I've used it a couple times. It can only do the basic stuff. For complicated Nix package expressions you have to do the complicated stuff yourself.
<davexunit>mordocai: perhaps it is. needs some investigation.
<davexunit>better inform the mailing list so we can sort it out.
<davexunit>there could be a way to break this chain by building a minimal gnutls that doesn't need pkg-config at build time, and use that for these https downloads.
<Jookia>davexunit: Speaking of circular chains, how does git-downloader (might not be the right module name) use the 'git' package without importing it and creating a circular dependency due to packages in the vcs module using git-fetch? I wish to do some tweaks to add socat to the git builder for proxy support, but I run in to that issue
<paroneayea>davexunit: maybe it is that easty... I guess it's also not hard to reproduce the "entry points" into launching scripts
<lfam>Do we have a standard answer to whether the contents of (arguments) should be quoted or backquoted? I've read the difference between the two, and I think I understand it. Of course there are many cases where backquotes are used although nothing is unquoted. Advice?
<paroneayea>since they're usually pretty simply "import this module, run this function"
<davexunit>lfam: don't use quasiquote unless you are unquoting
<dannym>I ran into another (workaroundable) bug when trying to use #:config-file, though, but the report seems to have been... not copied to the mailing list.
<civodul>lfam: BTW, ahem, don't look at what git blame says on this file
<dannym>So just in case: There's this guix system reconfigure functionality that checks the service list and starts new services (that previously were not in config.scm), stops services that are now not in the config.scm; it seems it doesn't notice when the call parameter list changes. In any case, it doesn't replace the postgresql call.
<pecg>The work done with Nix and Guix is going to same countless of hours of fail attempts on trying to reproduce complete operating system environments
<pecg>Althought, I've learnt a lot in the process.
<lfam>I think that one reason it did not happen sooner is that other package management projects, like dpkg or yum, are part of huge community projects. And as any communities grow, they "ossify" and become rigid as a way of handling complexity. I think this is unavoidable. So, there is a huge burst of innovation at the beginning, and then it soon becomes almost impossible to change things in a serious way.
<pecg>lfam: That could happen to guixsd and nixos also
<lfam>I picture the growth of a coral reef. At the beginning, anything is possible. But as the reef grows, it turns rigid and the landscape is more or less permanent.
<calher>lfam: is there a record somewhere? do i just email it?
<NiAsterisk>why does `guix environment --ad-hoc --container --pure guix git guile make gcc-toolchain sed autobuild perl m4 gettext texinfo graphviz help2man automake` not want to run make clean in the git checkout?
<lfam>calher: I'm not sure. Normally I'd scrape it from the terminal emulator but if the system froze and you had to hard reboot, of course that is lost.
<NiAsterisk>why does `guix environment --ad-hoc --container --pure guix git guile make gcc-toolchain sed autobuild perl m4 gettext texinfo graphviz help2man automake` not want to run make clean in the git checkout? <--
<rekado>it's all been a little too much for me lately.
***ringst_ is now known as ringst
***bmpvieira_ is now known as bmpvieira
<NiAsterisk>and how would I deal with this in guix environment guix --container --network 'long list with packages' ... with this error when I ran make; ./bootstrap; ./configure --localstatedir=/var .... guix build: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<rekado>using "guix environment guix" for testing *other* packages seems wrong.
<lfam>Yes, `guix environment $1` is only for getting the environment to build $1
<NiAsterisk>hm. is it? why? maybe I have some wrong expectations / ways to do things I assumed would be like this.. I did all the testing of packages so far in guix environment guix as I needed something interactive. I thought container would work as well..
<rekado>"guix environment guix" gives you a shell session in which all the packages for hacking on guix are available.
<rekado>that doesn't help you when you want to test lispf4, for example
<lfam>For lispf4, you'd do `guix environment lispf4`
<rekado>to get an isolated environment containing only lispf4 you would do: guix environment --pure lispf4
<lfam>You only need to do that when you are building Guix itself
<lfam>If you want to to try to build something else interactively (that is, not by calling `guix build foo` but rather by calling `make`), you would then use `guix environment foo`, because it would make sure you have the dependencies, environment variables, etc
<NiAsterisk>ACTION thinks the documentation really needs a beginners "my first package" section
<lfam>NiAsterisk: It's not a bad idea. A tutorial from picking a package to working with reviewers on the ML.
<NiAsterisk>hm. okay... not a day without learning something new. I like guix
<lfam>Does it make sense? Feel free to ask questions.
<NiAsterisk>lfam: sort of.. I make notes and try to process them tomorrow, the last days weren't good to me with stress from my health insurance.. I intend to do such a thing, "guix packaging for starters" or something at Labor Tage 2016, a small annual convention at a hackerspace here. some hundred people coming, idk.. somebody on their list seems to know ludo from way back, I started talking about guix and the person
<NiAsterisk>mentioned nix and how he still doesn't get the difference and motivation of guix
<paroneayea>time to figure out how to get postgres working on guix...
<lfam>paroneayea: We fixed a bug in the postgres service only a couple hours ago!
<NiAsterisk>I try to compare countries by things which suck... and germany is getting to the point where the things which suck possibly canÄt be changed anymore and might get lifethreating from one day to the next for all kinds of people.. iceland is the rational best at the moment. other things suck, but they don't suck as much as they do here. I wouldn't feel safe in the USA for example.
<civodul>lfam: i agree with rekado, your help on reviews is appreciated!
<paroneayea>. o O (also time to figure out how to write out a postgres config file that does mostly what I want...)
<lfam>NiAsterisk: I think feelings of safety are relative. My city is famous for violent crime and yet I feel safe. Of course we should improve it.
<NiAsterisk>thanks for all the welcoming help so far, it's really amazing how much I have to understand and how patient and friendly the community is. I experienced others in the past which weren't. really a positive note for Guix :)
<lfam>NiAsterisk: I agree. It made a huge difference to me getting started here.
<NiAsterisk>lfam: I feel safe living in the street with most drug dealers, unorganized smalltown crime and much more here.. the way 'germans' (in average) "handle" situations like we have currently (again) in this country is nothing you will probably ever fix. I spend some years trying to figure out why, and I have no ultimate answer, but I could fill a rather long speech with rants on the political unorganized left,
<NiAsterisk>anarchism in germany historicaly and now, and different subtopics. my safety is politically and to other often so-called minority groups I belong. if I can choose safety over unproductive trying to change a deeply rooted authority obedience, and there's a country where politics are relative okay and they treat people mostly like people, the decision is easy.
<paroneayea>NiAsterisk: I'm glad you've found the community so welcoming, and I agree
<paroneayea>wingo: I wonder if some of this can be generalized so that other packages can do some stuff like it
<paroneayea>eg, the <configuration-field> stuff seems nice, and like something a lot of services might be able to be used
<NiAsterisk>okay, I do have a question. using guix environment guix is only for building guix itself. this would imply for me, that this is the way to do the [make clean-recursive; ./configure --localstatedir=/var; make] thing in. or maybe it isn't. it's not really very clear but I can't point right now where in the docs it isn't clear.
<mark_weaver>to make it a bit nicer, you might put (define postgresql-config (plain-file "postgresql-config" "<contents>")) earlier in the OS config file and then refer to that variable in the service call