IRC channel logs


back to list of logs

<sdgfgdfgd>mark_weaver: ^
<sdgfgdfgd>civodul: Still around?
<civodul>sdgfgdfgd: ↑
<sdgfgdfgd>civodul: I'm still struggling with remove. Will you take a look if I post the code to the list?
<civodul>sdgfgdfgd: if you do it right now :-)
<sdgfgdfgd>civodul: You should see the message in a minute or so.
<civodul>sdgfgdfgd: just replied; basically add (srfi srfi-26) to the list of modules
*civodul -> zZz
<civodul>good night/day!
<civodul>Hello Guix!
<TaylanUB>civodul: Did you look into the FFmpeg v. Libav case ?
<civodul>TaylanUB: not in detail, but yes
<civodul>i don't think we should spend too much energy in that debate, honestly ;-)
<civodul>AIUI both are free software, and both have a similar attitude toward free software
<civodul>so we should just choose the one that "works best" technically
<civodul>(and we're just talking about the *default* choice here, since we can always have both, etc.)
<TaylanUB>So .. which one works "best" ? :P
<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.
<jxself>2.1 just came out for example:
<civodul>i would choose FFmpeg because that's the name i'm the most familiar with
<civodul>(good argument, no?)
<civodul>and i guess jxself has more experience with these things than i do
<jxself>Well, what's the point of being the project maintainer if you don't get to decide the color of the bike shed every now and again? :)
<civodul>heheh :-)
<civodul>anyway, i still have to see patches that bring some of that video stuff :-)
<TaylanUB>Maybe the one that gets packaged up first will win ? :D
<civodul>perhaps that's a good way to give people an incentive ;-)
<jxself>On another note a new kernel's due this weekend, if Linus's prediction is correct & 3.12-rc7 is indeed the last rc.
<jxself>Woot woot.
<jxself>How disruptive are kernel upgrades, I wonder?
<civodul>i admit i rarely upgrade
<jxself>Within the realm of Guix, I mean.
<civodul>totally non-disruptive :-)
<jxself>er; OK
<civodul>well, the thing is it's going to be easy to roll back, and/or to select a kernel version that works
<civodul>so the workflow would be: when you feel like it, upgrade to the latest, and if it doesn't work conservatively switch to another one
<jxself>OK. I seem to recall that certain types of upgrades involve lots of recompiling.
<jxself>The C library would probabl be a good example of that.
<civodul>depends on whether you use pre-built binaries
<civodul>for people who get binaries from, we can arrange so that they are all available when the rebuild-the-world changes get merged to 'master'
<civodul>("make dist" checks that, actually)
<jxself>OK, but if kernel updates don't trigger that then I'm happy.
<civodul>kernel upgrades just trigger a kernel rebuild
<mark_weaver>I'm okay with ffmpeg. I'm sorry for making such a fuss for so long over something so trivial.
<mark_weaver>in other news: gdb built successfully on my YeeLoong after I modified the recipe to patch all makefile shells after the configure phase.
<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 ?
<Steap>mark_weaver: I do.
<Steap>mark_weaver: I think Andreas does not use emacs, nor vim
<Steap>so yeah, there are a bunch of files written with an editor other than emacs
<mark_weaver>heh, okay.
<mark_weaver>(fwiw, I also often use vim when I'm root, or for quick edits on other systems)
<mark_weaver>(I used vim for many years as my primary editor, but now I basically live in emacs)
<civodul>mark_weaver: the indentation rules matches (package (inherit foo) ...), but not just (package (name ...))
<civodul>i don't know how do to that :/
<civodul>IOW, i'm grateful if somebody can fix it
<civodul>didn't someone have a patch for SDL?
<mark_weaver>civodul: hmm. so the rule in .dir-locals is right is there's an (inherit foo), but is wrong in all other cases?
<mark_weaver>s/right is/right if/
<mark_weaver>I'll look into it.
<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).
<davexunit>makes sense.
<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)
<davexunit>(put 'package 'scheme-indent-function 0)
<mark_weaver>civodul: what do you think? ^^
<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.
<mark_weaver>davexunit: sounds good!
<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 don't think it is.
<davexunit>I see "pkg-config... no" a bunch
<davexunit>which usually isn't a problem, but maybe here it is.
<mark_weaver>ah, it's not. I think you need (native-inputs `(("pkgconfig" ,pkg-config))), like the 'guile-2.0' recipe does.
<davexunit>ah, didn't know of native-inputs
<davexunit>I will try this next time I'm at my own computer.
<mark_weaver>when cross-compiling, the distinction between inputs and native-inputs is important.
<mark_weaver>native-inputs are inputs that will be needed during compilation, so they are compiled to run on the system that's doing the build.
<mark_weaver>'inputs' are inputs that will be needed when the built package is run, so they are compiled to run on the system that the package is being built for.
<davexunit>ah, I see.
<davexunit>thanks for the explanation./
<mark_weaver>np :)
<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.
<mark_weaver>but that's just a guess.
<davexunit>ah, I see. well then, more reason to get SDL packages done.
<civodul>+1! :-)
<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.
<civodul>mark_weaver: ah right, so it should be 0
<wm4>maybe slightly off-topic, but any opinions about VP9 (google's free video codec)?
<jxself>I played with it for a little bit.
<jxself>The encoder seems very slow.
<jxself>At the same time, the bitrate when using -crf 10 seems impossibly low, which is amazing.
<jxself>It took 3.2 days to encode 49 minutes and 19 seconds of HD video at 1080p. (See what I mean by slow?)
<jxself>With all 4 CPU cores at full throttle.
<jxself>The encoder needs optimizations, I think, to speed that up. :)
<jxself>Encoding VP8 is much faster; that same video is probably just a matter of a few hours to encode.
<wm4>well, all this stuff is new, so the encoders are bad
<wm4>it's the same with HEVC (aka h265)
<jxself>But I am, overall, happily looking forward to VP9 and I keep on using VP8 for now.
<jxself>I'd also like to play around with Opus. I haven't made time for that yet.
<a_e>Could anyone provide insight into arm related matters?
<a_e>viric: A little bird tells me you have such a machine.
<a_e>I was trying to cross-compile the bootstrap binaries for my guru-plug like seagate device.
<a_e>I am tempted to use armv5tel-linux-gnueabi; I think that is how gmp identifies the system.
<a_e>But binutils do not compile with this setting.
<a_e>gcc -v or the config.log of guile-2.0.9 mention as target arm-linux-gnueabi
<a_e>And the config.sub of binutils contains
<a_e>arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb]
<a_e>So which one to choose?
<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.
<mark_weaver>to get an idea of how much diversity there is on arm, take a look at what I had to do to use a simple signed multiply instruction:;a=commitdiff;h=afa3c37ddc3682939a793a4798f3b55fc8d658ec;hp=f91a1864c365abef807714ed0b664849f099152c
<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.
<a_e>Feroceon 88FR131 rev 1 (v5l)
<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.
<mark_weaver>a_e: --with-arch=...
<a_e>To start with, I would like something simple "that guix does automatically".
<mark_weaver>a_e: see the "ARM Options" node of the GCC manual for values.
<mark_weaver>a_e: well, as you wish, but I think you'll find it performs terribly.
<mark_weaver>floating point in particular
<mark_weaver>you'll end up with software emulated floating point if you don't specify something.
<mark_weaver>(I think)
<mark_weaver>I should confess that I'm not 100% sure of anything I've written here about ARM.
<mark_weaver>but the baseline is pretty horrible, at least if you care about FP.
<a_e>Speaking of which: gcc.scm still contains "--with-abi=64" for mips64el.*n64.
<a_e>We can probably drop this after agreeing on n32.
<mark_weaver>yeah, I noticed that. I'm not sure if it's needed or not.
<mark_weaver>well, I'd still like to support n64. at some point it will be the right thing to do.
<a_e>I am not quite sur for which of the many gcc we compile it is used...
<a_e>Then we can add n64 again.
<mark_weaver>and there's no reason why you can't have n64 together with n32. you could use n64 for some things that need it.
<mark_weaver>(such as pari-gp)
<a_e>Are you sure it will mix freely in the guix setting?
<mark_weaver>I can't imagine why not. they mix together freely on non-Guix, and if anything I'd expect Guix to be much more tolerant of such things.
<mark_weaver>On Guix, all of the fundamental toolchain and libraries are in /nix/store/*
<mark_weaver>so the n64 and n32 worlds will live in different hashes in /nix/store, and should be completely independent of each other.
<a_e>On debian, there are separate subdirectories of /lib and /usr/lib.
<mark_weaver>right, but Guix doesn't use those directories anyway.
<a_e>If we install everything in .guix-profile/lib, the mixture might become explosive.
<mark_weaver>oh well, yes.
<mark_weaver>in a given user profile, you better include only n32 libraries or n64 libraries.
<mark_weaver>however, you could mix n32 and n64 *programs* in the same profile.
<a_e>Yes, I agree for programs.
<a_e>The number of -march=arm* is intimidating.
<mark_weaver>we could make things mix well for libraries too if we built our toolchain with multilib enabled. but I'd prefer not to.
<a_e>There is 5, 5t, 5e and 5te. But not the 5tel that gmp proposes.
<mark_weaver>the 'l' probably mean little endian.
<mark_weaver>but arm processors support both little and big endian modes. my impression is that little-endian is mostly used nowadays in the free software world for arm.
<a_e>Probably so. But I do not see how my v5l maps on the gcc options.
<a_e>And how on the target triples.
<sgsgfgdf>mark_weaver: My i686 machine is still building gdb. Is there a need to continue?
<mark_weaver>sgsgfgdf: I've built it successfully on my Yeeloong.
<mark_weaver>sgsgfgdf: so if you were building it for my sake, no need to continue :)
<sgsgfgdf>OK, I'll stop it, then.
<mark_weaver>a_e: I don't know. However, I notice that GCC has a "-mcpu=native" option that "auto-detects the CPU of the build computer".
<mark_weaver>maybe if you combine that with some verbosity options, and try building something with gcc on your ARM box, it will give you hints about what to pass to --with-arch when building GCC.
<mark_weaver>(--with-arch specifies the default value for -march=... when GCC runs, and -march=... takes that same values as -mcpu=...)
<mark_weaver>oh wait, I was looking at the wrong thing.
<a_e>There are even more -mcpu than -march ;-)
<mark_weaver>a_e: I think you want --with-arch=armv5
<a_e>Okay, I started building like this already.
<mark_weaver>a_e: it occurs to me that #gcc is probably a better place to ask these questions :)
<a_e>Do you know what to read to understand configuration triples, config.guess and their relationship to gcc options?
<a_e>config.guess returns armv5tel-unknown-linux-gnueabi on my machine.
<a_e>I suppose I could use "armv5te" and drop the "l" for "little endian".
<a_e>On the raspberry pi, the standard config.guess returns
<a_e>The one from gmp, which makes more distinctions, chooses
<mark_weaver>ask on #gcc
<a_e>mark_weaver: Okay.
<a_e>It looks like I am blocked; I get an error message such as "cannot send to channel" at #gcc.
<a_e>Ah, as observed before, the "t" does not sit well with binutils.
<civodul>viric: Tor is back :-)
<a_e>civodul: I just reported my cross-build problem for guile.
<a_e>On guix-devel, as I am not sure if this is a guix bug.
<civodul>a_e: good, lemme see
<a_e>civodul: For porting, it looks like one also should modify gcc-configure-flags-for-triplet in gcc.scm.
<a_e>mark_weaver made me realise this when he suggested to adapt -march=... to the target.
<a_e>Maybe something to add to the manual?
<a_e>I suppose these flags are used for compiling all packages of the distribution?
<civodul>a_e: hmm actually the manual sort of mention the ABI issue
<civodul>-march stems from the --with-abi configure flag in GCC
<civodul>ah but the manual doesn't explicitly mention the name 'gcc-configure-flags-for-triplet'
<civodul>it's more vague so the porter has some guess work ;-)
<a_e>Okay, you are right, it is almost there.
<mark_weaver>civodul: the --with-arch option passed to GCC's configure determines the default for -march.
<civodul>ah right
<civodul>well that's the idea anyway :-)
<mark_weaver>for ARM systems, it's probably important to specify that.
<mark_weaver>although maybe it's automatically deduced from some part of the GNU triplet; I'm not sure.
<civodul>yeah, not sure
<civodul>glibc guesses a number of things from triplet, but GCC doesn't usually
<civodul>a_e: does the cross libc have
<a_e>How do I know where it is?
<civodul>so in cross-base.scm, you add (define-public the-libc (cross-libc "armel-linux-gnueabi"))
<civodul>and then you can type "guix build -e '(@ (gnu packages cross-base) the-libc)'
<a_e>Anyway, I have three potential /nix/store/...-glibc-cross-armv5-linux-gnueabi-2.18.
<a_e>All contain a that is the following text file:
<a_e>(Something starting with a comment /* GNU ld script)
<a_e>In the end, there is a
<civodul>and what does "file -L" say?
<a_e>And a libpthread.a (we are speaking of static libraries, right?)
<a_e>The .so:
<a_e>ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.30, not stripped
<a_e>The .a:
<a_e>current ar archive
<civodul>a_e: is $libc/lib in CROSS_LIBRARY_PATH?
<civodul>well i guess it is
<a_e>Yes it is.
*civodul is clueless
<mark_weaver>civodul: do the nix logs get automatically cleaned?
<a_e>civodul: Too bad!
<mark_weaver>some of them seem to be missing
<civodul>mark_weaver: on yes, but not too often
<civodul>and otherwise no
<mark_weaver>so, on my private system, I shouldn't expect $PREFIX/var/log/nix/drvs/* to be cleaned automatically?
<civodul>a_e: i can try locally, but no guarantee
<civodul>ah but there are patches
<a_e>Where are there patches?
<mark_weaver>The mit-krb5 code fails to build on my YeeLoong. Here's some code that initialized 'context': bail_on_err(context, "Error initializing Kerberos library", krb5_init_context(&context));
<mark_weaver>it seems to be written on the assumption that arguments will be evaluated from right to left.
<civodul>mark_weaver: you're next to MIT, right? ;-)
<civodul>a_e: i mean you have patches to cross-build things for ARM, right?
<mark_weaver>apparently that seems to work on intel systems, but on my system it fails with t_cc_config.c:120:16: error: 'context' is used uninitialized in this function [-Werror=uninitialized]
<a_e>civodul: You mean, I should have patches? So far I have done nothing except add the line
<civodul>ah ok
<a_e>((string=? system "armv5-linux") "/lib/")
<a_e>in bootstrap.scm
<civodul>isn't it
<civodul>can you check in your glibc builds?
<a_e>On debian, is a symbolic link to the real thing.
<civodul>yes, on Debian
<civodul>but the actual libc that you cross-built?
<civodul>(Debian sometimes does things differently, uses eglibc, etc.)
<a_e>I just checked. There also.
<civodul>so i'll try to try ;-)
<a_e>mark_weaver: I just looked at the debian package krb5. The patch names do not evoke a solution to your problem.
<mark_weaver>yeah, I always look there too
<mark_weaver>I'll just fix it myself. it's easy to fix.
<a_e>mark_weaver: Where does the problem occur (file and line)?
<mark_weaver>I've already got a patch. just about to start another build.
<mark_weaver>(it's the first statement of main)
<a_e>There is a new version 1.11.3, I wondered if maybe it fixed the problem.
<a_e>It does not.
<a_e>Something to report?
*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?
<Steap>mark_weaver: show us the code, plz
<Steap>mark_weaver: yes, patches has moved to 'uri' I guess
<Steap>see linux.scm for instance
<mark_weaver>Steap: that's only on core-updates
<Steap>mark_weaver: seems to be on master now
<mark_weaver>I'm working on the loongson branch, but I doubt master would be any different.
<a_e>mark_weaver: I just pushed mit-krb5-1.11.3.
<mark_weaver>Steap: I think you're mistaken.
<Steap>see procps
<civodul>it's on master, except for core packages (to avoid a full rebuild)
<civodul>a_e: the ARM triplets are a complete mess
<mark_weaver>ah, okay. damn, I've been doing it the old way.
<civodul>none of binutils, gcc, libc, and config.guess agree
<mark_weaver>well, in any case, the old way is still supposed to work. I still don't think that explains the problem I have here.
<a_e>civodul: Yes. Did you catch up reading my desperate questions in this channel?
<civodul>mark_weaver: the old way will no longer work once core-updates is merged
<mark_weaver>civodul: *nod*
<a_e>How come they do not all use the standard config.guess?
<civodul>that's crazy
<civodul>a_e: which questions? :-)
<a_e>Questions; hm, statements rather, lists of possible first components.
<a_e>There is also a lack of documentation.
<mark_weaver>a_e: here's what I did: and here's what happened:
<mark_weaver>any idea why it failed to find the file?
<civodul>a_e: documentation of what?
*civodul is getting lost
<mark_weaver>(obviously, I'll fix my patches to use the new method before the core-updates merge)
<civodul>a_e: i'm going to sleep but i'll be here tomorrow afternoon if needed
<a_e>civodul: Documentation of how to find good target triples for a given processor.
<civodul>aah, right
<a_e>Good night!
<mark_weaver>I suspect my problem has to do with the weird krb5 unpack method.
<mark_weaver>ah, I see!
<mark_weaver>you cd into the src subdir.
<mark_weaver>that must be it.
<a_e>mark_weaver: Sorry, I did not find it earlier.
<mark_weaver>no worries.
<a_e>Yes, that must be it; the configure is in src.