[00:02] <slangasek> Noskcaj: looking
[00:03] <slangasek> Noskcaj: it's not correct that it only fixes a CVE; there are changes to thread support handling, which I'm in no position to vet at the moment
[00:05] <Noskcaj> oops, ok
[00:10] <sarnold> I believe there's more work to be done to fix the security issues: http://www.openwall.com/lists/oss-security/2013/10/11/8
[10:49] <infinity> pitti: I just vomited a little at that udev/hv patch.
[10:50] <infinity> pitti: How do these people not have a kernel driver that's doing the right thing here?  Letting userspace manage cpu/memory hotplug sounds like madness.
[10:50] <infinity> pitti: Aaanyhow, now that that's out of my system, closing my eyes and pressing "accept".
[12:16] <c_korn> hello, a question regarding gensymbols. when building a package there is a warning: "warning: debian/liboyranos0/DEBIAN/symbols doesn't match completely debian/liboyranos0.symbols.amd64" but running "dpkg-gensymbols -pliboyranos0 -Pdebian/liboyranos0" does not do anything.
[12:48] <mdeslaur> yesterday's iso gets stuck at the timezone selection screen...is that a known issue?
[12:50] <sladen> mdeslaur: file it
[12:50] <sladen> mdeslaur: dups can be sorted out later
[12:50] <mdeslaur> sladen: thanks
[12:55] <mdeslaur> bug 1239127 for the curious
[17:27] <Laney> wgrant: did you forward the gst-base change?
[17:39] <reaby> hello everybody, i'm new to this, and found out that it's very challenging to create a new launcher (shortcut) to desktop
[17:39] <reaby> could it be possible for next release to have easier way ?
[17:40] <reaby> thanks.
[17:42] <reaby> native linux apps are fairly easy since you can just make a link, but a wine app or launcher for minecraft is impossible to do
[17:43] <reaby> what i tried for minecraft was to do a bash script to launch it, but even if i put executable flag for the file, it still wants to open the file at gedit
[17:43] <reaby> and when i try to change the file opener, there is no way to "just open"
[17:44] <reaby> and if i try the search button from internet is just crashes
[17:50] <doko> Laney, pitti: any chance to have a look at the gmime test failure?
[17:58] <doko> looking at 2.6.18
[18:00] <doko> same failure with this version
[18:04] <Laney> doko: probably https://git.gnome.org/browse/gmime/commit/?id=bb1c6094e04ce54de52289cd5ba7f9b73694ef1f
[18:04] <Laney> let me try this
[18:11] <Laney> seems to work
[18:17] <doko> Laney, please upload
[18:17] <Laney> sec
[18:17] <Laney> just being killed on hitman
[18:19] <Laney> ok, I died :( /me uploads
[18:25] <Laney> done, it is
[20:24] <halfie> hi, do you guys turn on "-Werror=format-security" by default in Ubuntu?
[20:27] <halfie> cjwatson, are you around?
[20:27] <halfie> what do you guys think about "prelink" in general? is there demand for it from Ubuntu users?
[20:27] <Noskcaj> halfie, I don't think we do because Werror has many false positives. One of the more experienced devs might actually know.
[20:28] <halfie> Noskcaj, oh I see. I was told that it had very very few false positives. weird.
[20:28] <halfie> if it has known false positives then I can't "fight" to get it enabled.
[20:29] <Noskcaj> Well, when Werror get false positives, it makes things FTBFS
[20:30] <halfie> yes ;(
[20:31] <slangasek> prelink defeats ASLR and modifies files owned by the package system; it should be avoided.
[20:32] <slangasek> Noskcaj, halfie: we absolutely do turn on -Werror=format-security by default
[20:32] <Noskcaj> slangasek, Thank you for knowing far more than i do about this stuff
[20:32] <slangasek> Noskcaj: that's not the same as turning on -Werror generally, it's about treating a specific class of warnings as errors
[20:32] <Noskcaj> ok
[20:33] <halfie> slangasek, how do I verify / see the default flags? (I am a Fedora guy ;( )
[20:33] <cjwatson> they always show up in gcc -dumpspecs, although reading that takes practice
[20:33] <slangasek> halfie: 'dpkg-buildflags' tells you the defaults; build logs for individual packages should show how these flags are actually applied, though many packages misbehave and hide their compiler commandlines in the output
[20:33] <halfie> slangasek, yes, prelink is the first thing I remove. I am trying to get Fedora to disable it and give the choice to the user instead.
[20:34] <slangasek> Fedora uses prelink? oy
[20:34] <halfie> slangasek, BY DEFAULT!
[20:34] <cjwatson> (my answer is the default for the compiler; slangasek's answer is the default for package builds, at least those that honour dpkg-buildflags)
[20:34] <halfie> :-(
[20:34] <halfie> cjwatson, both answers are useful for me. thanks!
[20:35] <halfie> so, I have two action items. 1) do *not* use prelink by default 2) enable "-Werror=format-security" by default.
[20:36] <slangasek> man, that sounds like a lot of work - maybe you should just switch to Ubuntu instead ;)
[20:37] <halfie> slangasek, I did run Ubuntu for some years :-) ... I get paid to work on Fedora these days ;) have to be "loyal", right? :D
[20:38] <halfie> (but I am trying to pick-up Ubuntu packaging stuff)
[20:44] <halfie> Ubuntu also has "-Bsymbolic-functions" turned on. I have read that "it is permitted for users of the shared library to override a symbol (function name or global variable) with their own versions." ... how is this overriding actually done?
[20:46] <soren> I'm confused. I'm looking at an ELF binary that doesn't seem to have an RPATH set ("objdump -x `which binary` | grep RPATH" is silent), says it needs libwhateverclient.so. libwhateverclient.so resides in /usr/lib/whatever, which isn't in /etc/ld.so.conf. Somehow it manages to find it anyway.
[20:46] <soren> "ldconfig -v | grep libwhatever" is also silent.
[20:47] <soren> Oh, hang on. Now it doesn't work anymore.
[20:47] <soren> what the..
[20:48] <soren> Eeeek.
[20:48] <soren> postinst has: "ldconfig /usr/lib/whatever"
[20:49] <soren> Running "ldconfig -v" restored normalcy.
[20:49] <soren> That's a first.
[20:50] <soren> (and hopefully last)
[21:11] <mdeslaur> soren: wow
[21:24] <infinity> soren: Eww, seriously?
[21:25] <infinity> soren: Is this packaged IN THE ARCHIVE?
[21:30] <soren> infinity: Gosh, no.
[21:30] <soren> infinity: It just has a built-in facility for producing (some sort of) debian packages.
[21:31] <infinity> soren: Some sort of, indeed.
[21:31] <soren> Ok, so according to http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html, it's fine for this package (let's call it "whatever") to have binaries specify /usr/lib/whatever as an RPATH.
[21:32] <soren> Nonsense.
[21:33] <soren> Or is it? Man, my packaging-fu is really rusty.
[21:33] <infinity> soren: Yeah, a self-contained RPATH like that is fine.
[21:34] <soren> No, my initial statement seems accurate... but how does that work with multiarch?
[21:34] <infinity> soren: With multiarch, the rpath should also be multiarch?
[21:34] <soren> infinity: Let's pretend that I'm an idiot...
[21:34] <infinity> soren: lib in /usr/lib/$(triplet)/package
[21:34] <infinity> soren: And RPATH of same in binary.
[21:35] <infinity> soren: Not that it would matter desperately if it was /usr/lib, since your binary is /usr/bin (which isn't multiarch already), and the exlicit allowance here is for private libraries *in the same package*.
[21:36] <infinity> (If you choose to read that as "from the same source package", which might be valid, then yeah, you could multiarch the private libs package, and use a multiarch RPATH).
[21:36] <soren> infinity: Ah, ok. Yeah, it was the bit about the binary being in a non-multiarch location that got me confused.
[21:37] <soren> Does one of the dh_* things remove rpath automatically?
[21:37] <infinity> Not that I know of, unless someone made dh_strip more clever.
[21:37] <infinity> I used to build-dep on chrpath and strip it myself.
[21:37] <soren> I just wonder why my more proper debian packaging spits out binaries without this rpath set.
[21:37] <soren> Now I know better where to look. Thanks.
[21:38] <infinity> Oh, is the RPATH set in upstream's binaries, but stripped in yours?
[21:38] <infinity> Curious.
[21:38] <soren> Yeah.
[21:38] <soren> This thing is a treasure trove of curiosities.
[21:41] <infinity> soren: The only debhelper/rpath mention I see is:
[21:41] <infinity> debhelper (7.3.9) unstable; urgency=low
[21:41] <infinity>   * cmake: Avoid forcing rpath off as this can break some test suites.
[21:41] <infinity>     It gets stripped by cmake at install time. Closes: #538977
[21:41] <infinity>  -- Joey Hess <joeyh@debian.org>  Sat, 01 Aug 2009 15:59:07 -0400
[21:42] <soren> Yeah, saw that. Maybe I'm full of it. The only RPATH I see mentioned now is pointing to my dev area (presumably, as Joey also mentions, for testing).
[21:43] <soren> I wonder how this is mean to work anywhere.
[21:43] <infinity> Well, it's meant to "work" due to that postinst snippet and a funamental misunderstanding that subsequent ldconfig calls will make it explode. :P
[21:44] <infinity> It's not the first upstream who doesn't understand ldconfig.
[21:45] <infinity> I've been in a long and heated debate with McAffee over their insistence that it's not a bug for one of their random crap libraries to claim an SONAME of ld-linux.so.2
[21:45] <infinity> You can guess what happens to user's systems on the next ldconfig run after installing their software.
[21:46] <mlankhorst> well
[21:46] <mlankhorst> not much any more, I guess
[21:46] <infinity> *rimshot*
[21:47] <soren> infinity: whuh?
[21:50]  * soren falls asleep, confused
[22:13] <slangasek> halfie: overriding the symbol is done by simply providing a symbol of the same name in your application, which then takes precedence in the linker resolution
[22:15] <Noskcaj> What is the best way to see what things on the iso still need porting to python 3?
[22:36] <infinity> Noskcaj: germinate, or walking package dependencies would be the "right" way, but fiddly if you're not sure how.  The simple way would be to install ubuntu-desktop and ubuntu-live in a chroot and then "apt-get remove libpython2.7-minimal" and see what goes with it. :P
[22:48] <cjwatson> soren: man-db does that very thing (although with RUNPATH, not RPATH - which means it remains overrideable using LD_LIBRARY_PATH) for its private libraries.
[22:48] <cjwatson> (Not sure my last attempt at that got through.)
[23:07] <ersi> Noskcaj: If you start pulling in that mess, feel *very* free to write up findings. I got "Help with porting to python3" on my TODO (albeit not at the top spots)