<fps>and i'd like to do so for guix, too, since i need envy24control from that package
<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
<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
<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..
<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..
<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..
<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
<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
<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.
<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: "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
<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?
<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.
<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.
<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