[Ffmpeg-devel-irc] ffmpeg-devel.log.20151130

[burek]

[04:05:40 CET] <Compn> wtf is this http://www.acm.org/about/se-code
[09:29:29 CET] <fritsch> wm4: https://trac.ffmpeg.org/ticket/5047 <- that's for you I think :-)
[09:29:50 CET] <fritsch> wm4: cause when looking through the commits i saw some by you in that direction
[09:32:43 CET] <wm4> fritsch: that's not even a mp3, that's a mp4, so my dealings with the mp3 demuxer can't have broken it
[09:33:07 CET] <wm4> it's probably a problem with enabling parsing
[09:34:11 CET] <wm4> also getting 403 on the sample url
[09:35:04 CET] <fritsch> wm4: retry fixed permission
[09:35:06 CET] <fritsch> sorry for that
[09:35:34 CET] <fritsch> plays nicely in the browser even :-)
[09:39:33 CET] <wm4> and yes it's just mp3 in mp4
[09:48:05 CET] <wm4> unconditionally enabling full parsimg helps
[09:48:32 CET] <nevcairiel> supposedly that breaks other things
[09:50:15 CET] <nevcairiel> personally I would enable it and then try to fix the parser to not break things, even better if someone has a sample handy of such a case right now
[09:58:13 CET] <wm4> nevcairiel: I'd feel better about that than about the arbitrary and unreliable heuristic that enables parsing
[10:14:31 CET] <rcombs> https://github.com/rcombs/FFmpeg/commits/auto-bsf now with mpegts support
[10:15:01 CET] <rcombs> also, I changed mpegts's write_header to init because it never actually writes anything, which also lets me remove some duplicated cleanup code :D
[10:17:13 CET] <rcombs> so that leaves AVI and WTF still using ff_check_h264_startcode and needing auto-filtering for AVC, and MOV and FLV still needing auto-filtering for AAC
[10:38:10 CET] <ubitux> so what happened to the idea of dropping -fno-tree-vectorize?
[11:25:04 CET] <rcombs> nevcairiel: I'm good at typing; meant ff_stream_&
[11:25:11 CET] <nevcairiel> i figured
[11:25:24 CET] <wm4> so where does one get truehd specs?
[11:25:38 CET] <rcombs> unless you have a better idea for the name
[11:25:41 CET] <nevcairiel> one doesnt
[11:25:47 CET] <rcombs> `ff_stream_&` feels super awkward
[11:26:00 CET] <rcombs> specs?
[11:27:27 CET] <rcombs> but I guess it just feels that way because `av_stream_&` mirrors the struct name
[11:27:31 CET] <rcombs> so w/e
[11:28:16 CET] <wm4> nevcairiel: why not?
[11:28:20 CET] <wm4> is it like the DVD spec?
[11:28:25 CET] <fritsch> wm4: from kodi's bitstream parser code
[11:28:34 CET] <nevcairiel> dunno, but it seems rather carefully guarded
[11:29:12 CET] <fritsch> wm4: https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/AudioEngine/Utils/AEBitstreamPacker.cpp
[11:29:13 CET] <nevcairiel> whats so special about the kodi code thats not in the ffmpeg decoder? :d
[11:29:32 CET] <wm4> yeah ffmpeg has such code too
[11:29:45 CET] <fritsch> nevcairiel: it was there before and no one yet replaced it
[11:29:47 CET] <wm4> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/spdifenc.c
[11:30:01 CET] <nevcairiel> when I worked on Atmos extensions last year, I googled for alternative truehd implementations
[11:30:07 CET] <nevcairiel> all of them were based on the ffmpeg code
[11:30:18 CET] <fritsch> see the author of the ffmpeg code
[11:30:24 CET] <fritsch> he is also kodi audio dev
[11:32:02 CET] <nevcairiel> so in short, all that is known about truehd/mlp can be found in ffmpeg, to get some extra info i had to get the disasm on
[11:34:15 CET] <fritsch> nevcairiel: the reason we still have our part of the code is the architecture ... which needs some work to get the ffmpeg bits into place
[11:34:40 CET] <nevcairiel> isnt that always the reason =p
[11:34:56 CET] <wm4> I don't understand that... the ffmpeg code could just be used in place there
[11:35:17 CET] <wm4> spdifenc is a big hack API-wise (it's a muxer, really?)
[11:35:21 CET] <nevcairiel> i've been using spdifenc from avformat for a couple years now, and can confirm it works for all dolby and dts codecs, i didnt have hardware to test aac
[11:37:43 CET] <fritsch> Anssi: ^^ our reason to not use it was "lack of time right"? I cannot remember the architecture argument
[11:41:29 CET] <Anssi> fritsch: unfortunately I don't remember why gnif reimplemented it in our own code... I remember the ffmpeg code working just fine, but maybe I just forgot
[11:42:55 CET] <Anssi> the code has grown some extra E-AC-3 support now, I think, though, that ffmpeg is missing, but it is somewhere in my long todo list to port it to ffmpeg
[11:47:01 CET] <nevcairiel> ffmpeg supports eac3 in spdifenc
[11:47:10 CET] <nevcairiel> my software uses it fine
[11:47:27 CET] <fritsch> yeah - then lack of time is left as argument :-)
[11:48:05 CET] <nevcairiel> although i'm not 100% sure if it works perfectly, as a few select people reported that eac3 didnt work for them, but it works on my hardware .. maybe their hardware is just more picky, or just plain out doesnt support it, hard to judge
[11:48:51 CET] <fritsch> yeah - ours also works - just revisited it with pulseaudio some days ago as we restructed stream_type handling
[11:49:00 CET] <fritsch> cause of android wants to have non IEC streams
[11:50:32 CET] <wm4> I never can get pulse to pass through compressed audio
[11:50:43 CET] <fritsch> wm4: then check our AESinkPULSE
[11:50:44 CET] <fritsch> :-)
[11:50:52 CET] <wm4> that's not the problem
[11:50:59 CET] <fritsch> and follow the wiki: set device to stereo and enable dts/ac3/eac3
[11:51:03 CET] <wm4> the problem is configuring pulse in a way it does it at all
[11:51:08 CET] <fritsch> ah
[11:51:12 CET] <fritsch> yeah i have screenshots in the wiki
[11:51:16 CET] <wm4> lol
[11:51:25 CET] <fritsch> and the sink which works :-)
[11:51:27 CET] <fritsch> so what is left?
[11:51:27 CET] <wm4> so you're confirming my point or what?
[11:51:45 CET] <wm4> (that it's a pain to setup pulse to do that if you need screenshots)
[11:51:46 CET] <fritsch> just said: we are succesfully using PA for DTS /AC3 / EAC3
[11:51:48 CET] <nevcairiel> users need to do careful setup of audio settings for bitstreaming to work? yeah comfortable much :)
[11:52:06 CET] <fritsch> wm4: open pavucontrol, check your hdmi device click ac3, dts, eac3, make sure it is stereo profile
[11:52:16 CET] <fritsch> http://kodi.wiki/view/PulseAudio#Passthrough_Mode
[11:52:33 CET] <nevcairiel> note that HD audio doesnt use stereo, it uses more channels, but maybe you just dont do HD
[11:52:40 CET] <fritsch> hd audio won't work with PA
[11:52:48 CET] <wm4> "REMEMBER: To use passthrough you need to be using 2.0 channel configuration via pavucontrol (e.g. Digital Stereo (HDMI)"
[11:52:49 CET] <wm4> lol
[11:52:52 CET] <fritsch> that's why I talk about dts, ac3, eac3
[11:53:08 CET] <wm4> what does hd audio mean?
[11:53:13 CET] <fritsch> dts-hd, truehd
[11:53:15 CET] <nevcairiel> truehd and dts-hd
[11:53:19 CET] <fritsch> everything that needs more than 2 pcm channels
[11:53:22 CET] <fritsch> to be sumbitted
[11:53:28 CET] <wm4> lol
[11:53:30 CET] <fritsch> in our case 8 + 192 khz
[11:53:50 CET] <wm4> pulse, how to make your audio not work
[11:54:27 CET] <fritsch> wm4: anything left? :-) the rest is in the AESinkPULSE
[11:54:49 CET] <wm4> I implemented this years ago
[11:54:56 CET] <fritsch> yeah, me too
[11:55:00 CET] <wm4> but every time I test I have to struggle with pulse
[11:55:05 CET] <fritsch> hehe
[11:55:14 CET] <fritsch> it's straight forward
[11:55:17 CET] <wm4> no
[11:55:18 CET] <fritsch> only for eac3 you need to take care
[11:55:29 CET] <fritsch> with old api using 4*encoded_sample_rate
[11:55:34 CET] <fritsch> the new one does it automatically
[11:55:55 CET] <wm4> what old and new API?
[11:55:57 CET] <nevcairiel> I always have to suppress an evil laughter if i have to hear about the "fun" with linux audio
[11:56:13 CET] <fritsch> yeah - not to mention the fun of windows directsound api ...
[11:56:16 CET] <wm4> nevcairiel: I have my own share of fun with other platforms too
[11:56:27 CET] <fritsch> which supports also only dts, ac3 and no eac3
[11:56:33 CET] <fritsch> and wasapi is a big mess
[11:56:45 CET] <fritsch> if you need to handcode the delay measurements ...
[11:56:45 CET] <nevcairiel> i can bitstream even HD through a directsound renderer
[11:56:54 CET] <fritsch> nice - we can't
[11:57:24 CET] <fritsch> https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkPULSE.cpp#L627 <- wm4
[11:57:37 CET] <fritsch> prior to 2.0
[11:58:57 CET] <fritsch> nevcairiel: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538534(v=vs.85).aspx <- we use this
[11:59:06 CET] <fritsch> ac3 for both so that directsound "eats" it
[11:59:12 CET] <fritsch> and then the header decides
[11:59:18 CET] <wm4> fritsch: so you just hope PA assumptions somehow matches kodi assumptions about the raw format?
[11:59:28 CET] <nevcairiel> i would have to find the code that deals with this
[11:59:29 CET] <fritsch> nope - i know about the assumptions
[11:59:32 CET] <fritsch> cause I read the PA code
[11:59:47 CET] <fritsch> wm4: which assumptions btw.?
[12:00:28 CET] <fritsch> it's not that complicated ... it takes eac3 format type  iec encapsulated, stereo speaker config + matching format
[12:00:31 CET] <fritsch> that's it
[12:00:33 CET] <fritsch> and obviously the samplerate
[12:01:05 CET] <wm4> ah ok, the kodi params are set in info?
[12:01:41 CET] <fritsch> yes
[12:02:06 CET] <fritsch> encoding, sample_format, channel_map, samplerate
[12:02:33 CET] <fritsch> that's it the rest is "buffer" management and api management
[12:02:34 CET] <wm4> that's weird, my code doesn't even use pa_sample_spec
[12:02:45 CET] <wm4> (at init anyway)
[12:02:53 CET] <fritsch> you most likely don't use pa_stream_new_extended
[12:02:54 CET] <fritsch> then
[12:03:11 CET] <wm4> I do
[12:03:17 CET] <fritsch> argh wait
[12:03:21 CET] <fritsch> see where we use it
[12:03:21 CET] <wm4> it takes a pa_format_info
[12:03:26 CET] <fritsch> ours, too
[12:03:31 CET] <fritsch> https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkPULSE.cpp#L634
[12:03:34 CET] <fritsch> just used here
[12:03:35 CET] <fritsch> for validation
[12:03:48 CET] <wm4> seems pointless
[12:03:53 CET] <fritsch> and for estimating bytespersecond, framesize and so on
[12:03:59 CET] <fritsch> not really
[12:04:09 CET] <fritsch> that way you can make sure that PA likes what you setup
[12:04:17 CET] <wm4> I have my own functions for calculating bitrate etc.
[12:04:18 CET] <fritsch> and can easily get the management data you need
[12:04:28 CET] <fritsch> yeah - if you like implementing it yourself
[12:04:38 CET] <fritsch> i thought letting the API do as much as possible
[12:04:43 CET] <fritsch> give me less code to maintain
[12:05:10 CET] <wm4> mpv's pulse sink source file is slightly shorter than kodi's
[12:05:15 CET] <fritsch> i think so
[12:05:22 CET] <fritsch> we have a lot management stuff in there
[12:05:24 CET] <fritsch> device hotplug
[12:05:26 CET] <fritsch> enumeration
[12:05:28 CET] <wm4> me too
[12:05:36 CET] <fritsch> the addpackets method should be the same size
[12:05:55 CET] <wm4> well, not that it means anything, but I still don't think the sample_spec thing is really needed
[12:05:58 CET] <fritsch> and some AE_TYPE to pa_type static conversion stuff could be moved into a util method
[12:06:17 CET] <fritsch> http://maemo.org/api_refs/5.0/5.0-final/pulseaudio/sample_8h.html#0d9ad972ee71ef6bff8aaafd44fdb229
[12:06:20 CET] <fritsch> yeah
[12:06:30 CET] <fritsch> most likely you would fail when you try to create the stream
[12:06:47 CET] <wm4> I would hope so
[12:07:51 CET] <wm4> the site you linked doesn't have pa_stream_new_extended
[12:09:07 CET] <fritsch> it was about the valid
[12:09:10 CET] <wm4> http://freedesktop.org/software/pulseaudio/doxygen/stream_8h.html#acf41f201c5e6ac94b7fcbc8626b6c933
[12:09:14 CET] <wm4> "While connecting, the server will select the most appropriate format which the client must then provide."
[12:09:16 CET] <wm4> whatever that means
[12:09:27 CET] <wm4> (one format from the list, or possibly something very different?)
[12:09:36 CET] <fritsch> we don't want something different
[12:09:45 CET] <fritsch> and therefore ask before
[12:09:48 CET] <fritsch> if the combination works
[12:09:51 CET] <wm4> where?
[12:09:58 CET] <fritsch> the _valid_ call
[12:10:09 CET] <wm4> but that's probably client-side only, without involving the server
[12:10:28 CET] <fritsch> yeah - but the server side is covered with the enumeration
[12:10:35 CET] <fritsch> there we know what we can provide / server has
[12:10:49 CET] <fritsch> -> lunch time :-)
[12:10:56 CET] <fritsch> so the very moment the spec is valid
[12:11:04 CET] <fritsch> and we have setup a format our sink can do (enumeration)
[12:11:08 CET] <fritsch> -> it should work (TM)
[12:11:15 CET] <wm4> why not use this? http://freedesktop.org/software/pulseaudio/doxygen/format_8h.html#a9efd301cfd24b37737c6a2e2b47c9261
[12:11:31 CET] <wm4> fritsch: well it could change after enumeration
[12:31:34 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:376a3bdb7bbe: avfilter/af_sidechaincompress: add level_in and level_sc options
[12:31:34 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:6b978dadc654: avfilter/af_sidechaincompress: do not require writable input frames for acompressor filter
[12:55:18 CET] <fritsch> wm4: see the our registering for the callback
[12:55:23 CET] <fritsch> wm4: we get informed when this happens
[12:55:26 CET] <fritsch> and change accordingly
[12:55:44 CET] <fritsch> and ask AE factory to care for it, e.g. reinitializing us
[13:59:18 CET] <Anssi> nevcairiel: yeah the ffmpeg e-ac-3 code works fine for normal streams, but it doesn't have any substream handling code, so e-ac-3 streams using substreams with independent streams might not (I haven't looked into this yet)
[14:00:40 CET] <nevcairiel> i guess they might not work, i'm not sure, luckily discs using that concept are exceedingly rare
[14:00:55 CET] <rcombs> yeah, substreams don't work at all
[14:02:44 CET] <rcombs> adding support for dependent substreams (e.g. 7.1 eac3) will require some internal tweaks to how channels are handled, but it shouldn't be too bad
[14:02:55 CET] <rcombs> for multiple independent substreams& I'm not even sure how that should work
[14:03:01 CET] <nevcairiel> we're talking about bitstreaming
[14:03:33 CET] <rcombs> oh, like spdif passthrough?
[14:03:39 CET] <nevcairiel> yes
[14:04:21 CET] <rcombs> I wonder how multiple independent substreams should be treated
[14:04:22 CET] <rcombs> you'd probably want those as separate AVStreams, really
[14:04:48 CET] <rcombs> but there's no mechanism for a parser or a decoder to output multiple streams
[14:05:06 CET] <rcombs> there probably should be, though
[14:05:12 CET] <rcombs> also for things like H.264 with embedded 708 captions
[14:07:43 CET] <rcombs> here be all sorts of dragons
[14:33:33 CET] <ubitux> why is fate-api-seek depending on fate-lavf?
[14:35:54 CET] <Compn>  mp3 in mp4 is a hack...
[14:37:50 CET] <fritsch> Compn: in general or in ffmpeg realization?
[14:38:23 CET] <nevcairiel> everything in multimedia is a hack
[14:38:27 CET] <fritsch> lol
[14:38:27 CET] <nevcairiel> especially  Compn's existance
[14:38:42 CET] <fritsch> concerning "the standard" it is perfectly fine
[14:38:48 CET] <Daemon404> how is it a hack
[14:38:51 CET] <Daemon404> doesnt it have a spec even
[14:38:57 CET] <fritsch> it has - therefore I asked
[14:40:10 CET] <wm4> anyway my funny little patch breaks the sample that was pointed out
[14:40:36 CET] <wm4> and I'm too lazy (which actually means: busy) to analyze and fix it
[14:40:57 CET] <fritsch> as 2.7 worked - a bisect should find the bugger
[14:41:02 CET] <fritsch> i can do that if it's welcome tonight
[14:41:45 CET] <wm4> might be a patch-that-fixes-one-sample-breaks-another thing
[14:42:05 CET] <fritsch> funny the linked patch also talks about handbrake encoder
[14:42:11 CET] <fritsch> the linked bug
[14:42:34 CET] <fritsch> it's probably the third bug I file that happens with users using handbrake
[14:42:53 CET] <wm4> oh yes we discussed it with a handbrake dev too
[14:42:55 CET] <fritsch> which I think also uses ffmpeg under the hood?
[14:43:15 CET] <fritsch> so that might be an ffmped 2.7 produced "stream" cannot be decoded properly with 2.8
[14:43:18 CET] <fritsch> that would suck
[14:43:35 CET] <nevcairiel> handbrake likes to play a bit loose with the spec sometimes, the argument pretty much ended in "but the spec says this is valid" =p
[14:44:02 CET] <fritsch> for us we always get: does not play in kodi 16 - but worked in kodi 15
[14:44:08 CET] <fritsch> fix it, it s regression they say :-9
[14:46:11 CET] <Compn>  does quicktime play it ?
[14:46:56 CET] <fritsch> without audio my colleague said
[14:47:00 CET] <fritsch> i don't have quicktime
[14:47:21 CET] <Compn> if quicktime cant play it, then its not valid mp4 :P
[14:47:25 CET] <fritsch> mpv based on ffmpeg 2.7.x works
[14:47:31 CET] <fritsch> ffplay 2.7.x also works
[14:47:41 CET] <Compn> i realize that we can play such files of course
[14:47:45 CET] <Compn> and that it is a regression
[14:47:49 CET] <Compn> just sayin...
[14:47:52 CET] <fritsch> the biggest problem here is:
[14:47:57 CET] <fritsch> handbrake produces such stuff _right now_
[14:47:59 CET] <wm4> I bet mplayer with its old builtin mov demuxer can play it
[14:48:07 CET] <Compn> of course mplayer can still play it :P
[14:48:09 CET] <fritsch> I did not try
[14:48:25 CET] <fritsch> i use kodi - if it fails I try mpv - if that also fails -> file is broken
[14:48:27 CET] <fritsch> :-)
[14:48:27 CET] <wm4> because mplayer uses mpg123, so mpg123 somehow pieces the data together
[14:48:28 CET] <Compn> dont we have a handbrake author here on irc ?
[14:48:49 CET] <Compn> fritsch : we should strongarm this person into disabling mp3 audio
[14:49:43 CET] <fritsch> jstebbins seems the main author
[14:49:45 CET] <fritsch> cannot find him here
[14:49:58 CET] <Daemon404> fritsch, he is j45
[14:50:06 CET] <fritsch> j45: ping
[14:50:16 CET] <fritsch> Daemon404: thx - yeah yours pinged him already
[14:50:28 CET] Action: Compn goes afk
[14:50:36 CET] <fritsch> Compn: haha
[14:50:45 CET] <Compn> gotta run, 8:50 am on monday.
[15:01:57 CET] <wm4> just tried it with mplayer, fails on at least 1 of the samples too
[15:06:07 CET] <durandal_1707> kierank: whats status?
[15:06:33 CET] <kierank> durandal_1707: ?
[15:06:51 CET] <durandal_1707> of vc5
[15:07:39 CET] <kierank> dunno it's a weekend project
[15:07:55 CET] <kierank> smpte people are investigating whether I can get reference decoder
[15:09:49 CET] <durandal_1707> they contacted you?
[15:32:29 CET] <kierank> Yes I asked for samples
[15:33:07 CET] <kierank> Basically I understand bitstream now
[15:33:17 CET] <kierank> Haven't found out how they choose Huffman tables
[15:33:20 CET] <wm4> wait, do you mean the reference encoder source, or just a binary?
[15:33:45 CET] <kierank> Reference Encoder source for vc-5 and samples (not the same as cfhd)
[15:36:16 CET] <durandal_1707> vc-5 is just cfhd with extra bytes?
[15:37:04 CET] <durandal_1707> cfhd is in avi, and vc-5 is raw format?
[15:37:34 CET] <kierank> Vc-5 is a different format inspired by cfhd
[15:37:51 CET] <kierank> But they share a few features
[15:38:33 CET] <kierank> I will upload my tree to github later
[15:39:10 CET] <kierank> I basically have a bitstream parser and a semi-working lowpass decoder
[15:40:18 CET] <durandal_1707> for cfhd samples we have?
[15:42:22 CET] <kierank> I have 3
[18:09:21 CET] <Daemon404> so many mjpeg variants
[19:54:34 CET] <nevcairiel> if anyone cares, vs2015 update 1 final is available now
[19:57:39 CET] <wm4> are there release notes or anything somewhere? interested about the supposed clang stuff
[19:58:09 CET] <nevcairiel> thats not part of the update, but an extra addon, didnt find that one yet
[19:58:19 CET] <Plorkyeran> there will probably be a blog post up today at http://blogs.msdn.com/b/vcblog/
[19:58:25 CET] <Plorkyeran> with more useful information than the marketing stuff
[19:58:57 CET] <nevcairiel> another interesting feature is that VS can now talk to GDB and play debugging frontend with GDB as a backend
[19:59:13 CET] <nevcairiel> breakpoints, memory inpsection, et al
[20:00:10 CET] <nevcairiel> also, there is a tool now to only install the compiler and sdk without the IDE
[20:00:22 CET] <nevcairiel> which might be useful for build systems or wine setups
[20:10:32 CET] <Daemon404> nevcairiel, im one of those freaks that only uses the ide for debugging
[20:10:40 CET] <Daemon404> and cl.exe directly
[20:12:29 CET] <nevcairiel> my fate box would've probably used such a tool
[20:12:33 CET] <nevcairiel> but alas its already setup now
[20:13:01 CET] <Plorkyeran> should make it easier to update to newer versions, though
[20:13:19 CET] <Daemon404> ... can you actually uninstall now?
[20:23:29 CET] <Plorkyeran> the toolchain-only version should be uninstallable
[20:23:43 CET] <Plorkyeran> since it doesn't have all the extra crap
[20:23:55 CET] <Daemon404> hmmm
[20:24:12 CET] <Plorkyeran> and they're switching to sqlite for intellisense etc.
[20:24:21 CET] <nevcairiel> that reminds me to t urn on that option
[20:24:24 CET] <nevcairiel> its apparently much faster
[20:24:24 CET] <Plorkyeran> so maybe one day in the future there won't be a million sql server things that have to be uninstalled
[20:26:00 CET] <BtbN> Doesn't it use an embedded sql express server, unless you explicitly enable a full one?
[20:26:10 CET] <nevcairiel> it does
[20:26:21 CET] <nevcairiel> but its still installed as a separate thing
[20:26:22 CET] <BtbN> So basicaly MS-SQLite
[20:26:30 CET] <nevcairiel> and apparently SQLite is faster
[20:26:43 CET] <nevcairiel> so they added an option to switch to SQLite in update 1
[20:26:50 CET] <nevcairiel> its still considered experimental, so no default
[20:26:54 CET] <nevcairiel> but in the future it may move there
[20:43:02 CET] <nevcairiel> ..installing the upgrade takes as long as ever
[20:47:45 CET] <jamrial> speaking of compilers, gcc 6 reached stage 3 (feature freeze) and fate passes
[20:48:35 CET] <nevcairiel> 5.3 is also scheduled for release this or next week
[20:48:38 CET] <nevcairiel> as is binutils 2.26
[20:51:38 CET] <wm4> do they specifically include fate in their tests now, or why is it passing even though it's not even released yet?
[20:52:31 CET] <nevcairiel> a bunch of people here test fate on gcc master builds and instantly report breakage, that usually helps
[20:54:48 CET] <nevcairiel> there fate box updated, lets see what happens
[21:01:56 CET] <jamrial> i'm running a gcc trunk fate box, yeah
[22:42:20 CET] <durandal_1707> Is it ok to use complex.h?
[22:53:13 CET] <nevcairiel> probably not
[22:53:29 CET] <nevcairiel> if you do, add a configure test and dependency and everything
[00:00:00 CET] --- Tue Dec  1 2015