<TaylanUB>AFAIK FFmpeg pulls everything from Libav and implements any new APIs they introduce, and supposedly has a bit higher activity; on the other hand Libav states as an explicit goal to make stable releases ...
<jxself>Although FFmpeg does have releases too and would be stable within that branch.
<mark_weaver>there are a lot of failing tests, but to my surprise the build suceeded anyway.
<mark_weaver>civodul: why does .dir-locals.el provide an indentation rule for 'package' that doesn't match the indentation style that's in the (random selection of) gnu/packages/*.scm files I've looked at? (such as base.scm)
<mark_weaver>I'm confused how this could have happened. Are all our recipe writers using vim ?
<mark_weaver>it looks like it could be made to work by putting a function instead of a number into 'scheme-indent-function' property, but then users will get warnings every time they try to edit, because they might be loading unsafe code into emacs.
<mark_weaver>well, I'm punting on this. there are many more important tasks to do.
<davexunit>I'm guessing that we're really set on having inherit be on the same line as package?
<mark_weaver>heh, yeah, changing that convention would be a simple solution to the problem, which I'm tempted to suggest as well :)
<davexunit>seems like the path of least resistance for our Emacs happiness.
<mark_weaver>even if we don't change that convention, I still think the 'package' indentation rule should be tuned to the common case: when there's no (inherit foo).
<mark_weaver>the few people who make inherited packages can always edit it with the (inherit foo) on the next line, and then move it to the same line as the last thing they do (without reindenting after)
<mark_weaver>davexunit was working on SDL, as I recall. what's the status of that?
<davexunit>mark_weaver: I have some things that are almost ready
<davexunit>I have packages for SDL and SDL2, and the beginnings of packages for SDL_image, SDL_ttf, SDL_mixer, and SDL_gfx
<davexunit>I still need to package some things for those extension libraries.
<mark_weaver>having an entry in .dir-locals.el that does the wrong thing in most cases is pessimal. It means that I can't even fix it with a custom entry in my .emacs. I can only fix it by editing .dir-locals.el in my private git checkout.
<mark_weaver>I feel strongly that the 'package' rule should either be removed entirely, or changed from 1 to 0.
<mark_weaver>removing it entirely might very well be the best option, because then some of us could have a fancy function-based one in our .emacs that does the right thing in both cases.
<davexunit>mark_weaver: I plan on sending a patch for sdl/sdl2 "real soon now"
<davexunit>I use pulseaudio as an input, but the configure script prints something to the effect of "checking for PulseAudio support... no"
<mark_weaver>davexunit: someone else could probably give a better suggestion, but since no one else seems to be talking now, I'll take a stab: I'd suggest taking a look at the config.log and seeing why it concluded "no". maybe it was trying to use pkg-config to find pulseaudio? I'm not sure off-hand if 'pkg-config' is one of the standard inputs or not.
<davexunit>I have band practice tonight so I'll have to wait until late tonight or tomorrow to update my packages, but I'll get the patch together. :) was someone else interested in working on SDL packages?
<mark_weaver>I don't know. Civodul wrote here on channel ~90 minutes ago: "didn't someone have a patch for SDL?"
<mark_weaver>I think it's more likely that he wanted SDL for something, not that he wanted to work on it himself.
<civodul>mark_weaver: yeah, agreed that the indentation rule should be for the common case; feel free to commit the change
<mark_weaver>civodul: should I remove the rule entirely, or just change 1 to 0?
<civodul>mark_weaver: the latter, though it seems to be equivalent no?
<mark_weaver>it's not equivalent. if we remove it entirely, then the body will be lined up with 'package'. if it's 0, then it will be indented one more column than that.
<mark_weaver>but perhaps the more important consideration is that it *is* possible to make a rule in your private .emacs that handles both cases correctly.
<mark_weaver>but that fails if your fancy rule gets overridden by .dir-locals.el
<mark_weaver>the fancy rule would require a function in place of the 0 or 1. but if we put that in .dir-locals.el, then users will bget a nasty security warning every time they try to edit something, I think.
<a_e>Do I need "e"? Before or after "l"? And what is "t"?
<mark_weaver>a_e: there are approximately a zillion different variants of arm. it depends what you have on your machine. but if you want something that other people can use, my initial instinct would be to follow what debian did.
<mark_weaver>they have two arm ports, one for old arm systems that won't run well on modern ones. and there's there the armhf port that takes advantage of modern arm features.
<a_e>mark_weaver: I do not know whether I want something that other people can use... First of all, I would like something that runs well on my hardware (we are at least three guix users with a guruplug-like machine).
<a_e>We could easily have zillions of guix ports...
<mark_weaver>okay, then the first step is to find out exactly what processor you have.
<a_e>But it would be reasonable to start with something everybody can use.
<a_e>So the --target parameter of my existing gcc from debian could be a reasonable choice: arm-linux-gnueabi.
<mark_weaver>unlike other processor types, the company that owns the ARM name does not produce its own chips. instead, they license the reference design to other companies, who modify it for their needs and/or integrate it into their own designs, and then create their own chips.
<mark_weaver>the GCC configure script takes some options that specify the default processor type to generate code for.
<mark_weaver>if you want good performance, it's probably important to specify those.
*civodul bravely tries to untangle scripts/package.scm
<mark_weaver>for mit-krb5, I made a patch the same way I've done a bunch of times before, and it didn't find the file. as if it was trying to patch from the wrong directory, or without the -p1 option or something. any tips on how to figure out what's going on?