IRC channel logs

<fps>before i start though you might notice that in the package definition i manually iterate over the directories since they all have individual configure scripts, etc..

<fps>what would be the best way to package this in guix?

<fps>i thought about programatically generating a package for each tool in it via a function that takes the subdirectory name.. each of these packages would then use the same source, chdir into the subdir before configure, and then proceed as normal

<fps>in the end i'd also add a alsa-tools package that propagated-inputs all these generated packages

<civodul>if they all have a separate build system, it wouldn't be unreasonable to have one package for each

<civodul>unless in practice one would always want all of them

<civodul>dunno

<fps>ok, i'll give that a shot. i'll learn more scheme in the process.

<fps>;)

<fps>the other option would be a trivial builder that does all that manually, no?

<fps>basically a translation of the nixos package

<civodul>yes, a single package whose builder iterates over the directories

<civodul>yeah

<civodul>that's a lot of tools actually

<efraim>with lots of outputs?

<fps>basically one executable per folder

<efraim>oh, I looked at the gnome updater again, if we're at 3.16.x and 3.19.x is available upstream, we don't get the update notification for 3.18.x

<efraim>i'm looking at the code now, it should be possible to show dev updates if we're already using a dev release, and stable-only otherwise

<fps>maybe odd ones are unstable? or maybe there's another good reason?

<fps>no idea :)

<fps>oh, before running off for breakfast.

<fps>civodul: do you know why precisely this fails:

<fps>guix download http://hg.openjdk.java.net/jdk8u/jdk8u/archive/jdk8u76-b00.tar.gz

<fps>wget gets it fine..

<civodul>fps: Guile's HTTP client is picky and rejects an invalid header, whereas wget ignores the issue

<civodul>we have an open bug for that, but bugs.gnu.org appears to be down currently :-/

<fps>ok, ty

<amz3>when I do guix `environment guile-next' and then ./autoreconf -vif && ./configure

<amz3>configure complains about missing ffi, is it my a problem with my own environment again?

<amz3>issue is, I can run --pure

<amz3>I can't run --pure

<amz3>And configure works without guix

<civodul>amz3: could you copy/paste the "complaint"?

<amz3>sure

<amz3>civodul: http://paste.lisp.org/display/166135

<amz3>the other complain, is standard configure error about missing libffi

<amz3>civodul: when I use guix environment --pure guile-next, it complains about lesspipe, but guile ./configure works

<civodul>but this one talks about 'less', not about libffi

<civodul>could you paste the libffi thing?

<civodul>i would also check what "pkg-config libffi --cflags" returns

<amz3>ok

<civodul>ACTION goes for lunch

<fps>before going any further i need to get sound working though on this box..

<fps>i have pulseaudio installed, but there seems to be no default alsa pcm device (which is usually a pcm plugin provided by PA)

<anonymiss>hi, should packages be build with gtk-doc support if possible, or not?

<anonymiss>else, there would be itstool support

<fps>sorry, no idea, but maybe grep through the other packages

<amz3>other packages are inconsistent

<amz3>the usual pratice is to split the documentation into its own output if it's big enough ~8M

<anonymiss>hm. it's about glade3-3.18 for gnunet-gtk

<anonymiss>i'll just have a look how this is done in other packages

<amz3>try guix edit network-manager

<amz3>try 'guix edit network-manager'

<anonymiss>ok

<anonymiss>thanks

<amz3>for instance dconf, disable fully gtk-doc

<anonymiss>also, when i send in the patch for gnunet, do you want it all in one patch for gnome.scm and gnunet.scm combined? my last git checkout was yesterday, no idea if this is important. i know i can 'git format-patch -1', but all the patching i have ever done was different. we just worked with hidde-service git daemons, merging each other

<amz3>you have to send one patch per package

<amz3>so, it's git format-patch -2 if you have two packages

<anonymiss>okay, i'll just look at the git documentation to learn more :)

<amz3> https://www.gnu.org/software/guix/manual/guix.html#Submitting-Patches

<amz3>well, this pratice to submit one patch per package is not in the guidelines I think

<anonymiss>no, otherwise i wouldn't ask. i read the guidelines before

<anonymiss>documentation, so 2 packages as in two package definitions or as in (output '("out" "doc")) ?

<amz3>anonymiss: I prefer someone else continue, as I am not a specialist

<amz3>an expert

<amz3>I'm a casual packager :)

<anonymiss>okay, thanks anyway :)

<efraim>anonymiss: 2 packages as in glade3 and gnunet-gtk

<efraim>multiple outputs is normally reserved for when the resulting package is large

<kmicu>ACTION recommends a little bit of entertainment ;): https://github.com/NixOS/nixpkgs/pull/11535#discussion-diff-46944864 https://github.com/NixOS/nixpkgs/pull/11557

<anonymiss>oh, no i meant to ask about documentation of a package, not package definitions

<anonymiss>the part where the docs get build, drop them or make a 2nd output?

<fps>kmicu: indeed funny :)

<fps>i wouldn't see a problem having google inc. as copyright holder in a free project though. the license is still valid ;)

<fps>dunno what the fuzz is about

<davexunit>it appears that most of the nix contributors have *no idea* how copyright works

<anonymiss>in gentoo, this gets separated and dumped into /usr/share/doc/$PN-PV (or similar ), so my approach would be to handle doc as in networkmanager package definition

<fps>especially in a global context which is confusing :)

<fps>i have no idea how copyright works either, btw..

<anonymiss>although glade3 in .bz2 format here is below 500 KiB

<kmicu>fps: “I am doing this at home in my free time [...] they [Google™ Inc] own the copyright on anything I produce while I work for them.” isn’t that funny if a corporation owns your private life? ( ͡~ ͜ʖ ͡°)

<fps>yeah, it's a funny quirk about the US legal system. you can contractually agree to transfer all copyright :)

<fps>in germany for example, authorship is not transferabble at all, while it is possible to transfer rights to monetize your works..

<Sleep_Walker>you can produce babies in your free time :b

<kmicu>They belong to the company though ;)

<anonymiss>all your babies are belong to us!

<anonymiss>--google

<fps>do no evil

<fps>--google

<fps>;)

<anonymiss>use the apple, luke! -- gandalf

<fps>haha :) n1!

<fps>don't trust quotations on the internet -- abraham lincoln

<fps>nation states are soooo outdated really. annoying psychopaths running this world -- fps

<alezost>anonymiss: if the doc is 500KB, there is no need to make a separate output for it

<alezost>... actually, do what seems appropriate to you, you'll receive comments on your patch if something is not according to our conventions

<anonymiss>hm, okay

<davexunit>sometimes its difficult to be a Guix hacker when most people don't care at all about reproducible builds.

<fps>maybe it would help to make the --check and --rounds=2 the defaults :)

<fps>um, no, bad idea. maybe only if the package doesn't exist in the local store yet..

<fps>bad, too.. gotta go to a meeting anyways.. laters..

<davexunit>jumped into a HN discussion about the package manager for Apple's Swift https://news.ycombinator.com/item?id=10695045

<davexunit>maybe got carried away ;)

<Sleep_Walker>_a bit_ :)

<civodul>kmicu: the cultural shock of Nix's traditional sloppiness in that regard and Google's all-your-code-are-belong-to-us rigour :-)

<civodul>davexunit: fun :-)

<davexunit>one of the nice aspects of working on GNU software is that you can be pretty sure that the maintainers have the copyright and licensing stuff down

<davexunit>9 failing tests on the nodejs upgrade...

<davexunit>it's all because /bin/sh isn't available in the container, AFAICT.

<davexunit>but my patching thus far has been insufficient

<civodul>davexunit: maybe they have a function similar to 'system' that needs patching?

<civodul>or 'popen'

<davexunit>civodul: that's what I patched :)

<davexunit>more issues lurking

<civodul>oh ok

<civodul>fps: i'll add a --rounds=N option to the daemon, so one can force the defaults

<davexunit>I found some hardcoded '/bin/sh' strings

<civodul>business as usual :-)

<davexunit>yup

<civodul>ACTION goes afk for a bit

<davexunit>ooh, down from 9 failing to 7

<davexunit>civodul: 'guix build --check' looks great!

<bavier>indeed, excellent

<civodul>yes, it's cool!

<civodul>we owe it to Eelco primarily

<civodul>the only downside is that it detects problems but doesn't help when it comes to investigating

<davexunit>guess it would be good to have it print a diff in the future or something

<civodul>yes, or provide a copy of the result that differs

<civodul>where one could run diff or diffoscope

<davexunit>yeah that sounds good

<civodul>actually, it Would Be Nice if we had an Emacs mode to automatically do what's described at http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html

<civodul>ACTION secretly hopes that alezost is reading this :-)

<civodul>so that would run 'guix challenge' and automatically drop you in a diff-mode buffer

<apa512>does anyone know how icecat tries to play sound? speaker-test works, vlc works, but there's no sound when watching youtube in icecat.

<mark_weaver>ACTION spams the bug-guix list with reports of non-deterministic failures

<mark_weaver>I've been silently collecting failed build logs and restarting the builds. time to finally file some bugs for the most common issues...

<mark_weaver>apa512: I believe that our icecat package uses gstreamer. I've never had an issue with sound in icecat.

<mark_weaver>civodul: it's good to see all the recent work to make it easier to detect non-deterministic builds! :)

<mark_weaver>thanks for that!

<mark_weaver>apa512: actually, the problem might be that you're lacking the needed codecs. you might need to install some of the following packages: gst-plugins-good gst-plugins-ugly gst-libav

<mark_weaver>and make sure that GST_PLUGIN_PATH includes $HOME/.guix-profile/lib/gstreamer-1.0

<apa512>mark_weaver i will try that. thanks.

<mark_weaver>(on GuixSD, that should be taken care of automatically)

<nee`>apa512: I also had icecat not playing any sound with pulseaudio. I had to deactivate my other soundcards pavucontrol.

<civodul>mark_weaver: and thanks Eelco :-) now that we have the tools, we can do the actual work of fixing packages ;-)

<civodul>nee`: i have that problem too, and i don't know why!

<civodul>somehow our IceCat build seems to not be picking PulseAudio

<apa512>installing the gst plugins worked! (using pulseaudio as alsa output)

<civodul>mark_weaver: BTW, consider cloning git.debian.org/git/reproducible/notes.git

<civodul>i'll see how we can arrange to start contributing to it

<mark_weaver>apa512: ah, that's good!

<mark_weaver>civodul: will do, thanks!

<civodul>there's also #reproducible-builds on irc.oftc.net

<mark_weaver>civodul: joined it, thanks!

<mark_weaver>civodul: btw, francis7 brought my attention to a recent upstream change to GRUB that makes the build deterministic. I haven't yet investigated.

<alezost>civodul: I'll look at it (someday), but I don't promise anything :)

<alezost>Currently I'm working on emacs UI for Hydra; teaser: http://i.imgur.com/BvhHlkS.png

<mark_weaver>alezost: oooh, nice!

<roelj>What's going on with Hydra? It's downloading with 916B/s..

<alezost>hydra api does not allow much though: only latest/queued builds, and jobsets. No search by package name, no access to evaluations

<roelj>alezost: You could get some information by package name though: http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=a2ps-4.14.x86_64-linux

<davexunit>alezost: that is *awesome*

<alezost>roelj: yes, I know I fully implemented this "latestbuilds" here; but you can't search for builds by "a2ps" or "linux" name as you can with http://hydra.gnu.org/search?query=...

<roelj>alezost: Ah yes, sorry..

<civodul>alezost: woow, you're a super hero!

<roelj>alezost: The interface looks great!

<civodul>roelj: that's unfortunately not infrequent: download something that nginx hasn't cached yet, and do that at a time where hydra is overloaded, and you get the abysmal throughput

<roelj>civodul: Ok. Is it a matter of not enough resources?

<mark_weaver>roelj: yes, hydra.gnu.org is currently running in a VM that's sorely lacking in RAM, disk, and disk I/O speed (due to a bad RAID configuration).

<alezost>roelj: civodul: mark_weaver: davexunit: thanks :-) it will be available soon

<civodul>\\o/

<mark_weaver>I would be thrilled to be able to monitor hydra without using a complex web browser.

<civodul>ditto

<civodul>roelj: yes, but we have a plan to buy a new machine

<civodul>with your help! :-)

<roelj>mark_Could we offload stuff to other servers? I have a VM that has unmetered network traffic and I could buy storage for not that much money.. Maybe we could move the infrastructure to a more distributed style with which we can share resources..

<roelj>How much RAM are we talking about here?

<civodul>for a build machine, at the very least 4G

<civodul>the frontend is slightly different

<civodul>the goal is to have it hosted on donors fund so that it's not tied to any particular person or entity

<civodul>in an ideal world, there'd be no front-end, but i think we're not there yet

<roelj>Ok. Are you raising funds somewhere? (or where can I donate?)

<civodul>it's just being set up right now, but...

<civodul>... i'm happy to say you can already visit https://my.fsf.org/civicrm/contribute/transact?reset=1&id=50

<civodul>we haven't announced it yet, so don't publicize it too much

<roelj>Ok, that's cool

<roelj>I didn't know the FSF was handling individual project funding as well..!

<civodul>heh

<roelj>I have to run for a meeting. One last thing, how much funding is needed?

<davexunit>civodul: awesome!

<civodul>roelj: this has been discussed on the list but we'll send a message

<anonymiss>hm.. `guix package -s xsltproc` shows me 0 results. is there some other special function then to build man pages?

<davexunit>anonymiss: perhaps xsltproc is a binary provided as part of a bigger package?

<anonymiss>possible

<anonymiss>part of libxslt

<davexunit>anonymiss: yup

<davexunit>was just about to say that

<civodul>anonymiss: "guix package -s xslt" shows useful matches

<anonymiss>ah, right. well i should've searched the www for 2 seconds before answering my own question :/

<civodul>:-)

<anonymiss>i used to have a maemo5 phone before it died.. looking at their bugzilla there's only 2 open OpenSSL related bugs, and none of them points out that openssl (in 2014) has seen no update since 2009/2010. but hey, at least someone still releases new kernel for this platform..

<anonymiss>oh i was wrong. 23 bugs

<civodul>mark_weaver: do you think you could come up with suggestions for the server?

<mark_weaver>civodul: I can make some suggestions, although I confess that it's not my area of expertise.

<mark_weaver>if needed, I can ask for help from people with more expertise

<mark_weaver>if we build our own: the old servers that the FSF offered to give us include good 1U cases with 4 hot-swap drive bays, that take the same physical motherboard type as the KGPE-D16, so we could use one of those and save a few hundred dollars.

<mark_weaver>I'm not yet sure if the power supply and fans would be sufficient. cooling is the thing I'm least confident about.

<mark_weaver>it may be that we should ask for help from someone who's experienced building servers

<civodul>mark_weaver: probably

<civodul>but i don't really feel like "building" it myself

<efraim>I've heard a lot of good things about iXSystems, they're BSD guys

<Digit>ACTION installs brasero, unsure where he'd get wodim from in guixsd

<fhmgufs>Which package definition fields are the correct ones for build or runtime dependeces? (Beginner)

<fhmgufs>dependences

<bavier>fhmgufs: https://www.gnu.org/software/guix/manual/html_node/package-Reference.html#package-Reference describes the different inputs

<lfam>fhmgufs: I'm not an expert, but my understanding is that native-inputs are only required at build-time, inputs are linked to at run-time, and propagated-inputs are required to be in the user's environment at run-time.

<lfam>But there are "wrinkles" depending on the language and probably some other factors

<fhmgufs>Yes, I read it. But will native-inputs also be present after the build process? I can't find that this is not the case on this page.

<lfam>Feel free to ask more questions as necessary

<lfam>fhmgufs: They will be cached in /gnu/store but they won't be used

<fhmgufs>Ok, thanks.

<lfam>fhmgufs: python-setuptools is an example of a native-input.

<lfam>And, the "native" part means that the native-input should be built for the build-machine's architecture, not the target architecture in case you are building for another architecture.

<lfam>Because the native-input is going to be used on the build machine and not the target machine

<lfam>bavier: I'm probably not qualified for the job you spoke about, but I would be interested in seeing the listing whenever it is available.

<mark_weaver>fhmgufs: the distinction between build and runtime dependencies is determined by scanning the outputs of the build for references to /gnu/store/....

<bavier>lfam: sure, I'll make sure to point you to it when it's posted

<mark_weaver>so the set of runtime dependencies is a subset of the build dependencies

<lfam>mark_weaver: Thanks for the info. It's useful to know the mechanism.

<fhmgufs>mark_weaver: Yes, that's clear.

<lfam>That should be added to the manual.

<efraim>bavier: I'd also be interested to see the listing when its available. Would it potentially be a work-from-home position?

<fhmgufs>Other question: if I can choose between git cloning and url fetching in a package definition: which one should I choose?

<efraim>url fetching

<lfam>fhmgufs: I recommend url

<fhmgufs>why?

<lfam>Usually upstream creates a full distribution tarball that is available by url fetching. For example, they should bootstrap the package, include a test-suite, include documentation, NEWS, etc. Often, the git repo is really just a development snapshot.

<fhmgufs>Yes I know, most projects also do changes that are unstable at some moments.

<fhmgufs>Ok, I understood it.

<bavier>efraim: typically local is preferred, but I think work-from-home may be considered.

<lfam>I think that Github by default creates a tarball for release tags, but often upstream ignores those in favor of tarballs distributed on their home page. I see this a lot with Python packages: PyPi > Github

<fhmgufs>lfam: is this tarball updated with avery change?

<lfam>fhmgufs: Which one?

<fhmgufs>the automatic generated github release tarballs

<lfam>fhmgufs: "At their core, Releases are based on Git tags." I think tags are supposed to be immutably linked to commits (unless you --force), so a release from a tag won't change unless you want to confuse your users. https://help.github.com/articles/about-releases/

<fhmgufs>Ok, no, they are static of course (tags).

<davexunit>automatically generated tarballs suck because they aren't bootstrapped

<davexunit>does no one run 'make dist' anymore?

<anonymiss>but one could use commits and their hashes instead of git clone git://whichscm.whereever/repo , that's what we started doing

<lfam>Not unless you file a bug report ;)

<fhmgufs>How can I create something like a chroot for guix package testing and so on where I don't have to install all the basic system tools (they should be used from my normal system)?

<bavier>fhmgufs: `guix environment <package>`

<bavier>optionally with --container

<fhmgufs>And if I don't have a guix system for now and only want to run guix for these testing?

<anonymiss>btw i'm getting somewhere with gnunet-gtk, hopefully it wont take that long until i have a first set of patches i can send in. i'm tempted to just leave it for a while and start working on pybitmessage, but i better finish those first

<bavier>fhmgufs: that should still work. you've built guix by now, yes?

<fhmgufs>yes

<fhmgufs>But I want to use my apt until guix(sd) is stable.

<bavier>fhmgufs: sure, guix can be run as a standalone package manager on top of other distros

<lfam>A lot of do that. I run it on Debian. The Debian system isn't affect at all. It doesn't even "see" Guix and vice versa.

<fhmgufs>Oh, that sounds nice (I use Debian too)!

<anonymiss>it's (guixsd) pretty useable, minus FDE which would be nice to have for some people i know

<lfam>Please excuse my poor English... it's sad when you can't properly communicate in your native language.

<davexunit>GuixSD gets more usable for each new person that is willing to eat some dog food :)

<fhmgufs>Yes, I will change to GuixSd soon. But I have only one system which is my work system too - so I can't change it every week.

<davexunit>feel free to use stuff like 'guix system vm' to play around with guixsd machines without having to risk your bare metal machines

<lfam>fhmgufs: If you carefully follow section 2 of the manual, you should have a working Guix on your Debian.

<fhmgufs>lfam: the problem is that my debian jessie's packages are too old.

<fhmgufs>...for most build processes.

<anonymiss>we're (me and some other people ) discussing on guixsd vs guix build/ integration on top of a minimal gentoo base system.. as there's no ebuild for guix so far

<lfam>Which packages?

<fhmgufs>For example intltool

<lfam>Are you installing the Guix binary or from the Guix source tarball?

<fhmgufs>I took the binary

<mark_weaver>fhmgufs: when guix builds packages, it doesn't use any software from your native host system except the kernel.

<fhmgufs>So it uses the store and really does not affect any packages of my debian system?

<mark_weaver>guix builds software in a container that only has access to the specified inputs, which are always from guix, not your host OS.

<lfam>mark_weaver: I think fhmgufs is trying to install Guix itself.

<mark_weaver>lfam: above, bavier asked "you've built guix by now, yes?" and fhmgufs responded "yes"

<lfam>I'm confused

<mark_weaver>fhmgufs: yes, everything that guix installs goes into /gnu/store, /var/guix and /var/log/guix

<fhmgufs>lfam: no, mark_weaver: yes, guix is installed, I just don't wanted to try anything before I know that it won't change my running system.

<mark_weaver>fhmgufs: the only thing it changes elsewhere is ~/.guix-profile, which is a symlink pointing to your current profile.

<davexunit>everything is self-contained

<lfam>fhmgufs: We really mean it when we say it doesn't affect any of your Debian software.

<fhmgufs>Ok, fantastic, so I can start using it now.

<mark_weaver>so, unless you have environment variables set up, e.g. PATH augmented to include $HOME/.guix-profile/bin, the guix software won't even be visible.

<mark_weaver>it's about as non-intrusive as you can get :)

<fhmgufs>That's what I call a good piece of software!

<fhmgufs>Great!

<bavier>:)

<Digit>how do u guys burn .iso in guix? i usually wodim but couldnt find it for guix, and i couldnt figure how to get brasero how to pick up my burner

<fhmgufs>Is anybody working on packaging of the MATE desktop environment (which is the best DE in the world)?

<davexunit>not that I know of.

<fhmgufs>Fine - so this will be my first big project. If that's ok.

<davexunit>of course it's OK! :)

<mark_weaver>fhmgufs: go for it! :)

<Digit>i'm sure that's better than just ok. :)

<davexunit>more packages? sounds good to us!

<davexunit>we need those.

<fhmgufs>Should I make to files for MATE core and MATE extra or one big file?

<efraim>I don't know how we've lasted this long without cowsay

<davexunit>or nethack!

<Digit>i like the wild pioneering frontier package sparseness, but i like the progress away from such early days better. ;)

<mark_weaver>fhmgufs: I would start with one file and we can always split it later if desired.

<mark_weaver>but gnome.scm is one file, for example

<fhmgufs>ok

<mark_weaver>nethack just recently had its first release in about 10 years

<fhmgufs>Do have to pay attention to something special (above the documentation)?

<mark_weaver>I never played nethack myself, but apparently that makes me an outlier in my generation of computer geeks :)

<davexunit>I've only played it a couple of times and died, but it's one of those things that distros just have to have :)

<davexunit>I found a roguelike for android called Pixel Dungeon and I love it, wish there was a desktop version.

<Digit>ACTION finds xorriso before deciding he should go try make a cdrecord/wodim package definition

<mark_weaver>fhmgufs: probably the best approach is to start with one package that depends only on packages we already have, preferably one of the easier ones, and ask here for help and advise as needed.

<mark_weaver>*advice

<anonymiss>or do a python one, like pybitmessage

<anonymiss>ACTION wants bitmessage

<anonymiss>but no idea about licensing

<fhmgufs>Ok, I just said MATE will be a project. Could you give me a package (except from python ones) I could start with?

<lfam>fhmgufs: Try to find a program you use in Debian that isn't in Guix (probably something smaller than MATE).

<mark_weaver>I'm sorry, I don't know much about MATE, so I don't even know what packages are needed for it, nor which ones would be good starting points.

<mark_weaver>yeah, desktop environments tend to be a bit trickier to get working than most other individual packages.

<mark_weaver>starting with something easier is probably a good idea.

<mark_weaver>I have to go afk. happy hacking!

<fhmgufs>Again: it's a project :)

<anonymiss>you could look at packages.gentoo.org for one source of needed packages, or just mate souces? pybitmessage is plain old MIT fwis, but i could ve wrong: https://github.com/Bitmessage/Pybitmessage/blob/master/COPYING

<anonymiss>is the license of Bitmessage okay for guix?

<davexunit>anonymiss: yes

<davexunit>it is the Expat license

<davexunit> http://www.jclark.com/xml/copying.txt

<lfam>Yes, although I think we'd call that license "expat" to disambiguate it from the x11 license

<anonymiss>ah :) cool, i'm nor familiar with every license out there

<anonymiss>*not

<fhmgufs>I see: GNU XaoS isn't included, so I start with this package. They have a good build documentation.

<lfam>Oh, very cool!

<lfam>I can't wait to play with it

<fhmgufs>Problem: is it gpl2+ or gpl2? COPYING is a normal GPL 2 license. The source files don't contain license information.

<civodul>fhmgufs: i theory you could use "guix import gnu xaos" to get an initial template

<bavier>fhmgufs: https://directory.fsf.org/wiki/Xaos suggests gplv2+

<civodul>however, this package lacks a signature (it predates the policy to add a signature)

<anonymiss>signature?

<lfam>If the files say something about later versions, then it's gpl2+. Otherwise it's just gpl2.

<fhmgufs>civodul: please explain that. lfam: The files don't say anything.

<lfam>In that case, it's just what's in COPYING

<fhmgufs>lfam: OK

<anonymiss>i mean, signature as in what and where? the names in the header of the files?

<lfam>I usually grep for "license" and related terms to get a sense of things. Sometimes, tarballs include components with a different licenses and in that case you give a list of licenses in the package definition, with a note explaining.

<fhmgufs>lfam: that's a good idea!

<fhmgufs>haha - look the last part of their README: https://github.com/xaos-project/XaoS/blob/master/README

<lfam>Heh, I wonder if Microsoft tried to compete with them on fractal viewing

<fhmgufs>They (GNU XaoS) use sourceforge for their publishing (on gnu.org the last version is from 1998) - but the project is active and a part of gnu. How should I handle the mirrors urls? They have autoselect, but this is really slow.

<lfam>fhmgufs: Try grepping in gnu/packages to see what others hvae done

<fhmgufs>lfam: ok

<lfam>fps: I worked on your gparted recipe for a bit but it needs a gtkmm we don't have packaged (gtkmm-2.4 > 2.8). Have you worked on it all?

<fps>lfam: sadly the libuuid issue was a stumbling block for me, so it didn't take it any further..

<fps>lfam: are there principal hurdles to upgrading gtkmm?

<lfam>I noticed you had "libuuid" and "util-linux" in the reverse positions. Does that make sense?

<lfam>We already have two versions of gtkmm, probably for reasons like this. It would be worth researching.

<fps>lfam: ooh. let's see where i have that branch :)

<fps>lfam: right, that was a leftover from a bad attempt :)

<fps>lfam: let me correct that and see if i get to the gtkmm issue :)

<lfam>You'll have to add a few more inputs on your journey to the gtkmm issue

<fps>lfam: or maybe can you show me your current definition?

<fps>is gtkmm 2.8 api compatible with 2.4? it should be, right?

<fps>the nice thing about a source based distro is not having to care about abi compatibility so much? :)

<fps>lfam: thanks for your reply on the --cache-timeout-failures thing btw :)

<fps>just returned from work. making pizza.. brb

<lfam>fps: Here's a WIP patch. It fails to find a suitable gtkmm: http://paste.lisp.org/+3K85

<fps>pkg-config should be a native input, right? i had it as that once, but for some reason played with putting it into inputs

<fps>and intltool, too, i suppose

<Gamayun>civodul: Very nice code-of-conduct commit :)

<fps>lfam: i guess as a first attempt we could add another private gtkmm package for 2.8 and then see if the ML decides that upgrading the public one would be ok

<fps>bb

<fps>oops

<fps>focus fail :)

<civodul>Gamayun: heh, glad you like it :-)

<civodul>davexunit: do you think you could skim over the Ruby packages that rekado sent a while back?

<civodul>Nov. 25th to be precise

<davexunit>civodul: oh did those not get merged?

<civodul>i don't think so

<civodul>i don't think a detailed review is necessary, mostly an overview

<fps>civodul: and good thinking adding --rounds to the daemon :)

<fps>where's version-major+minor defined?

<civodul>(guix utils)

<fps>t

<fps>ty

<civodul>re --rounds, i think we have a few core packages to fix before it's really useful

<fps>hehe, making it the default would force people to fix them ;)

<fps>or give up and flip tables :)

<civodul>right, there's a tension here :-)

<lfam>Oh man, I'm trying to package some python stuff that requires itself to be installed in order to build the docs.

<civodul>ooh, interesting

<fps>silly idea:

<fps>write a function that measures the complexity of a package definition

<lfam> https://github.com/untitaker/vdirsyncer/issues/135

<fps>once it's over a certain threshold automatically assume the build is horrible and send a bug report upstream

<lfam>Lol

<lfam>Look at my link: some projects don't seem to care

<lfam>Know any alternatives for caldav and cardav synchronization?

<civodul>lfam: you could always do as the AUR person wrote: have one phase to install, then one phase to add that to PYTHONPATH, then one phase to install the man page

<bavier>lfam: can the docs be built in a separate step using the tool built in a previous step?

<bavier>s/step/phase/

<lfam>That's what I'll have to do.

<bavier>IIRC several python packages require themselves to be installed before running test suites, which is probably an unrelated issue.

<fps>btw: is it generally safe to use --cores=8 with guix build?

<civodul>yes, but it defaults to the number of available cores anyway

<fps>oh ok. got ya

<fps>ugh, gtkmm-2.9 configures nicely but fails to build..

<fps>recentinfo.cc:172:158: error: invalid conversion from 'gchar** {aka char**}' to 'const gchar** {aka const char**}' [-fpermissive] return gtk_recent_info_get_application_info(const_cast<GtkRecentInfo*>(gobj()), app_name.c_str(), const_cast<gchar**>((app_exec).data()), &(count), &(time));

<fps>oh ok, just a bug ;)

<lfam>fps: I think the error message from gparted says it wants gtkmm from 2.5 through 2.7. Although it could also mean 2.4 through 2.8 if the error message is lazy. I don't think it is asking for 2.9

<fps>lfam: oh ok..

<fps>PKG_CHECK_MODULES(GTKMM, gtkmm-2.4 > 2.8 )

<fps>it should say so then ;)

<fps>anyways packaging gtk-2.99 fails, too :)

<fps>it configures nicely and then fails the build not finding gdk >= 3.0.0 [pkg-config] which is quite odd

<fps>anyways, off to bed..

<fps> https://pastee.org/htat2

<fps>ugh ;)

IRC channel logs

2015-12-09.log