=== hggdh_ is now known as hggdh
=== _salem is now known as salem_
[02:05] <infinity> slangasek: Dude.  Lolwut?  I made the mistake of reading the bug log from top to bottom and thinking "oh, sure, this should all come down to something obvious and debuggable".
[02:05] <infinity> slangasek: And then your bisect conclusion broke my brain.
[02:10] <infinity> slangasek: A wild shot in the dark, but would changing that (int) cast to (unsigned int) fix it?
[02:11] <infinity> slangasek: srand() takes a uint, not an int, which could be causing curiosity on 32-bit but not 64-bit systems (perhaps throwing rand off for something else in the same process space, or god knows what).
[02:17] <infinity> slangasek: Is there a simpler reproducer for this than "install a VM with encryption"?  Like, starting a plymouth splash and throwing text at it somehow?
=== salem_ is now known as _salem
[03:41] <slangasek> infinity: I've reproduced it by changing the code to call ply_get_timestamp() *and discard the result*
[03:42] <infinity> slangasek: Oh, that's fun.  WTF does ply_get_timestamp() do?
[03:43]  * infinity grabs the source/
[03:43] <slangasek> infinity: reproducer: install plymouth-theme-ubuntu-logo in a VM, using the vga video driver, *not* the vmvga driver; call 'plymouthd --tty=/dev/tty7 && plymouth show-splash && plymouth ask-for-password --prompt='lolwut'
[03:43] <infinity> ply_get_timestamp seems to be used all over...
[03:44] <slangasek> yup
[03:44] <infinity> As does the incorrect cast to srand() so, yeah, that would be a red herring.
[03:44] <infinity> (Should still be fixed, IMO)
[03:46] <slangasek> infinity: and ply_get_timestamp(), if you haven't already found it, is: http://paste.ubuntu.com/5803595/
[03:47] <slangasek> infinity: and inlining all of that code in script_lib_math_setup() does not trigger the bug
[03:47] <infinity> ...
[03:47] <slangasek> infinity: and creating a *copy* of ply_get_timestamp() as a static function in script-lib-math.c does not trigger the bug
[03:48] <slangasek> and linking with -Wl,-z,now does not change the footprint of the bug.  script.so invokes ply_get_timestamp(), the bug occurs.  script.so does not invoke it, bug does not occur.
[03:48] <infinity> I assume this lands in a libplymouth DSO?
[03:48] <slangasek> ply_get_timestamp() is in libply.so.2; the caller is the script.so theme engine
[03:48]  * infinity nods.
[03:49] <slangasek> LD_DEBUG=symbols shows no differences between the working and broken versions
[03:49] <slangasek> so... what am I missing? :)
[03:51] <infinity> The symbol tables in the amd64 and i386 lib certainly look the same, so that's probably chasing the wrong direction.
[03:52] <slangasek> I suppose I could single-step around ply_get_timestamp(), and see if anything looks crazy
[03:52] <slangasek> but I don't understand how this could be having an effect on text rendering. :P
[03:52] <infinity> Yeah, that's a bit of a stumper.
[03:53] <infinity> You'd expect something this potentially broken to do something more helpful like segv or just plain not work.
[03:53] <infinity> If only it was broken at all.
[04:04] <infinity> slangasek: Good luck with your obscure bug.  I have to run out for a previous commitment.
[04:04] <slangasek> infinity: heh, ok
[04:04] <slangasek> enjoy :)
[04:04] <infinity> slangasek: If I have a half-drunken epiphany, I'll be sure to blurt it out when I get home.
[04:04] <slangasek> sounds good
[04:15] <pitti> Good morning
=== pitti is now known as pitti_
=== sraue_ is now known as sraue
[06:53] <dholbach> good morning
[06:56] <m4n1sh> ev: just a friendly reminder. please look into those 2 bugs when you get time
=== sgnb` is now known as sgnb
=== sgnb is now known as Guest21170
[07:43] <ev> m4n1sh: on it this morning :) thanks!
=== tokarbol is now known as ballock
[07:54] <steveire> Hi there. http://anonscm.debian.org/gitweb/?p=collab-maint/cmake.git;a=summary is a repo of the cmake debian package. It is very useful. Can I find something similar for gcc? http://thread.gmane.org/gmane.linux.debian.ports.arm/12742/focus=12778
[07:59] <geofft> steveire: http://packages.qa.debian.org/gcc-4.8 -> VCS link on the left
[07:59] <geofft> that should work for approximately any Debian package that is maintained in a VCS
[08:00] <steveire> geofft: Great, thanks.
=== Guest21170 is now known as sgnb
[08:01] <steveire> geofft: Is the system down? http://paste.kde.org/783704/
[08:01] <geofft> Bah, is this Alioth being silly again? Try anonsvn instead of svn, maybe
[08:02] <geofft> Er, no.
[08:03] <steveire> anonscm works, thanks
[08:03] <geofft> yeah, that's what I meant.
[08:20]  * xnox wishes pastebinit would be available on ubuntu desktop cd.
=== doko_ is now known as doko
[09:29] <steveire> doko: ping?
[09:36] <doko> steveire, ?
[09:36] <steveire> doko: Hi. Did you see my mail?
[09:37] <doko> about what?
[09:38] <steveire> doko: http://thread.gmane.org/gmane.linux.debian.ports.arm/12742/focus=12786
[09:40] <doko> this is to ensure that you have a standalone cross compiler which doesn't depend on and conflicts with foreign architectures
[09:41] <steveire> Can you say more?
[09:41] <steveire> How does putting the stuff in gcc-cross/ instead of gcc/ have anything to do with foreign architectures ?
[09:42] <steveire> or dependencies (I assume you mean package-dependencies)?
[09:43] <doko> you can't install the -dev packages of the foreign arch
[09:43] <steveire> Ah, so this is all about -dev packages.
[09:44] <steveire> I don't see any available -dev packages actually. What -dev package do you mean?
[09:45] <doko> apt-cache showsrc gcc-4.8
[09:46] <steveire> Some of this stuff? http://paste.kde.org/783890/
[09:47] <steveire> libgcc-4.7-dev specifically I guess.
[09:47] <seb128> doko, hey, did you see the new comment on the gtk bug?
[09:48] <steveire> doko: I still don't understand how this dev package issue relates to the gcc/ vs gcc-cross/ directory.
[09:53] <doko> seb128, yes working with zhen on it
[09:53] <doko> steveire, what don't you understand?
[09:53] <seb128> doko, great, thanks
[09:56] <steveire> doko: I don't understand the need to put the cross compile dirs in gcc-cross/ instead of in gcc/ . I don't understand how that has anything to do with the -dev package of $something, which I assume is libgcc-4.7-dev. The file listing doesn't give me any clues: http://paste.kde.org/783902/
[10:00] <doko> steveire, you can't install libgcc-4.7-dev for the target together with the cross compiler
[10:03] <steveire> doko: Sorry. Are you saying that if there was another version of  libgcc-4.7-dev like libgcc-4.7-arm-linux-gnueabi-dev you could not install that together with gcc-arm-linux-gnueabi? Why not? No matter the answer, how do you get from that fact to the conclusion that the stuff must be in gcc-cross/ instead of gcc/ ? There are missing logical steps in what you have been saying here. The two statements about -dev packages and the gcc-cross/ directory seem
[10:03] <steveire> to be non-sequiturs.
[10:10] <doko> steveire, cross build tools must not get in conflict with the the target arch. why is it so difficult to understand that?
[10:11] <steveire> doko: I can see I've got all the useful information out of you I'm going to get. Thanks.
[10:12] <doko> steveire, and thanks for not answering my question
[10:16] <steveire> "my question" == "why is it so difficult to understand that?" ? What kind of answer would you want to a question like that? If I were to ask you a similar question it would be: 'Why is it so difficult to give a reason for putting the files in gcc-cross?' Doesn't that look like an anti-social question to you? It does to me, so I'll not ask it :).
[10:17] <steveire> Anyway, I'll just post your answer to the mailing list and see if someone else can interpret it.
[10:19] <xnox> steveire: i'm not sure, but on my amd64 host i can have native amd64 compiler, native i386 compiler and cross from amd64->i386. IMHO this is reasonable to co-install native and cross compiler for the same target architecture, thus the requirement for separate /gcc/ and /gcc-cross/ in case native&cross c runtime files are different.
[10:19] <xnox> steveire: same story with arm64 host & armhf native and armhf cross compilers.
[10:20] <doko> steveire, your paste shows libgcc-4.7-dev:amd64, not libgcc-4.7-dev:armhf. maybe that is you misunderstanding
[10:21] <steveire> doko: Maybe. I just guessed the package. You didn't specify one :).
[10:21] <steveire> xnox: Thanks, let me think about that for a moment.
[10:22] <doko> what other -dev packages are in the gcc-4.x sources that I had to specify.
[10:22] <doko> still not knowing what you are trying to achieve, and what it has to do here on this channel ...
[10:22] <steveire> xnox: So a armhf native compiler would run on a arm64 host? Why would you install a armhf cross compiler on the arm64 host if you have a native one?
[10:27] <steveire> xnox: And you are confirming that my point 2.2 here is the correct one: http://thread.gmane.org/gmane.linux.debian.ports.arm/12742/focus=12786 ?
[10:27] <xnox> steveire: to compare the two toolchains, for example and well because you can. Let me rephrase/flip your question into: "Why limit and make them artificially conflict?" plus if both are different yet are using same location then they can't be multi-arch:same
[10:28] <[diablo]> Good morning barry , are you around please?
[10:29] <xnox> xnox: md5sum different, but possibly interchangeable. i'm not sure.
[10:29] <steveire> xnox: Ok, that's clear. Thanks.
[10:41] <cjwatson> steveire: It makes cross-building easier if you have as few conflicts as possible; you can sometimes end up with too many packages installed depending on the precise way build-dependencies are spelled, and it's helpful if things still work anyway
[10:41] <cjwatson> (This is a special case of the principle that it makes everything easier if you have as few conflicts as possible :-) )
[10:42] <steveire> Right. It causes a problem for clang though: http://thread.gmane.org/gmane.comp.compilers.clang.scm/73551/focus=73568
[10:42] <steveire> I think I have the information needed to justify the patch now though. Thanks for the information.
=== MacSlow is now known as MacSlow|lunch
[12:02] <doko> rsalveti, what are these ABI changes you mention in the libhybris upload?
[12:04] <ogra_> doko, apparently there are issues with float vars that get pushed through the socket if one side (android) is built with 4.7 while the other (ubuntu) used 4.8 for building
[12:05] <doko> ogra_, hmm, I'm not aware of such a change. so a test case would be good
[12:06] <seb128> doko, similar to https://code.launchpad.net/~ricmm/platform-api/gcc-4.7-abi/+merge/171643 I guess
[12:06] <seb128> "GCC 4.8 introduces a change for ARM AAPCS calling conventions"
[12:06] <ogra_> doko, ricmm was referring to paragraph 4 in http://gcc.gnu.org/gcc-4.8/changes.html
[12:07] <ogra_> right aapcs
[12:08] <ogra_> rotation and ambient light sensor shoot float data over the socket that arrives as nonsense on the ubuntu side
[12:08] <doko> ahh, thanks
=== 6JTAAX1W6 is now known as tvoss
=== MacSlow|lunch is now known as MacSlow
[12:48] <barry> [diablo]: hi
[12:48] <[diablo]> hey barry
[12:48] <[diablo]> barry, wondered if I could possibly pop quiz you on flufl.lock once again ;-)
[12:49] <barry> [diablo]: sure :)
[12:49] <[diablo]> here or prefer a PM?
[12:49] <barry> pm
=== _salem is now known as salem_
=== sraue_ is now known as sraue
=== echidnaman is now known as JontheEchidna
[13:25] <pitti> jcastro: hey Jorge, how are you?
[13:26] <jcastro> hi pitti!
[13:26] <jcastro> how can I help you this fine morning?
[13:26] <pitti> jcastro: cleaning up old mail, WDYT about mothballing brainstorm now?
[13:26] <jcastro> I didn't want to kill it without having the information available to the community
[13:27] <jcastro> but IS needs to do a review of the database to ensure there is no privacy-sensitive user information there
[13:27] <pitti> ah, ok
[13:27] <jcastro> we could take it down immediately, but I wanted the data dump available if someone wanted to take it and do something with it
[13:28] <pitti> jcastro: we could perhaps disable write access, so that the thing stays there for historic reasons?
[13:28] <jcastro> yeah, I'll go ahead and ask IS and move forward, thanks for the prod
=== francisco is now known as Guest25330
=== wedgwood_away is now known as wedgwood
[14:38] <chrisccoulson> cjwatson, looks like this is going to be a success now (on dactyl): https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4749276
[14:38] <cjwatson> Cool
[14:39] <cjwatson> "Stripping symbols from enormous libraries" is a good progress comment
[14:40] <chrisccoulson> heh
[14:40] <seb128> hum
[14:40] <seb128> is that about dh_strip running out of resources?
[14:41] <seb128> we got a webkit armhf build that failed on that earlier
[14:41] <chrisccoulson> seb128, i'm not sure. maybe ask qengho about that?
[14:48] <sladen> oh my, ubuntu-devel@ is friendly these days
[14:52] <rsalveti> doko: yeah, aapcs related
[14:54] <ScottK> sladen: It'd be easier to have a conversation if the start of the thread was more reality based.
=== zumbi is now known as Guest86750
=== salem_ is now known as _salem
[16:51] <xnox> cjwatson: new debhelper upload has a fix for debbug 713257
[16:51] <xnox> cjwatson: which at the same time, now fails to detect a check target and therefore dh_auto_test doesn't forexample run upstart's test suite.
[17:15] <qengho> seb128: I have never seen dh_strip run out of resources.
[17:19] <manish> ev: actually I was more worried about this one LP #1192778 because I was unable to get it working
[17:19] <ubottu> Launchpad bug 1192778 in Activity Log Manager "Diagnostics tab doesn't show in standalone mode" [Medium,Confirmed] https://launchpad.net/bugs/1192778
[17:20] <ev> manish: I don't understand why we want it to show in standalone mode?
[17:20] <ev> the diagnostics tab is useful for Ubuntu, which uses a-l-m as a control center module
[17:20] <manish> ev: because of ubuntu gnome
[17:20] <ev> ah, *grumbles*
[17:20] <manish> it doesn't have g-c-c patch I guess
[17:20] <manish> but still uses whoopsie for error collections
[17:21] <manish> I mean patched g-c-c to add more panels
[17:21] <ev> yeah, this is a simple matter of playing with automake to build the whoopsie stuff when the control center module is not built
[17:21] <manish> I have added a patch on that bug
[17:21] <manish> but it segfaults
[17:21] <manish> it looks close, but segfaults were making me mad
[17:22] <manish> ev: so you can either work over it or start afresh
[17:23] <ev> :) thanks. I'm at the end of my day, but I'll have a look in the morn'
=== _salem is now known as salem_
[17:23] <manish> that's good to hear
[17:23] <manish> good night
=== robru_ is now known as robru
[18:11] <dobey> kenvandine: ! hey. for the uoa stuff, can a plug-in just create wholly custom UI for doing login/registration for a service, or does only oauth/openid type stuff that opens a browser work?
[18:11] <kenvandine> dobey, you mean you want to open a browser?
[18:12] <kenvandine> it can load a webview or display a form type UI
[18:12] <dobey> kenvandine: no, don't want to open a browser
[18:12] <kenvandine> dobey, however, with system-settings a plugin can provide qml components to display in the UI
[18:12] <kenvandine> so a bit more flexible on the UI
[18:15] <dobey> kenvandine: oh. are there docs on how to do a plug-in in qml that's not standard oauth stuff?
[18:15] <kenvandine> dobey, of course not :)
[18:15] <kenvandine> you can look at what gets installed by account-plugin-facebook
[18:16] <dobey> yeah, we were just looking at the qml for it. and it's OAuth { some_stuff_with_http_and_whatnot() }
[18:16] <kenvandine> humm
[18:17] <kenvandine> not sure what OAuthMain {} really includes
[18:17] <kenvandine> that is from Ubuntu.OnlineAccounts.Plugin
[18:18] <kenvandine> dobey, ah... look at /usr/share/accounts/qml-plugins/example/Main.qml
[18:18] <kenvandine> provided by ubuntu-system-settings-online-accounts
[18:18] <dobey> hmm
[18:18] <kenvandine> that should probably not get installed :)
[18:18] <hallyn> could someone on SRU team please look at (and hopefully accept) https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=qemu-kvm ?
[18:18] <kenvandine> but that is an example that includes other UI elements
[18:19] <hallyn> the 1.0+noroms-0ubuntu14.10 is a better fix than 1.0+noroms-0ubuntu14.9, and meant as a replacement, not a followup
[18:19] <hallyn> (it removes the 1.0+noroms-0ubuntu14.9 fix)
[18:19] <dobey> kenvandine: is that the upstream project name too?
[18:20] <kenvandine> yes
[18:20] <dobey> ick :)
[18:20] <kenvandine> dobey, i'd rather something explicit like that than *indicat*
[18:20]  * kenvandine is looking at tedg
[18:21] <dobey> kenvandine: uss-online-accounts at least would have been "cooler" :)
[18:21] <kenvandine> hehe
[18:22] <dobey> kenvandine: even if it's not a big boat
[18:23] <hallyn> SpamapS: ^ in a case like that, is there a tag should be setting on the bug?  I suppose I coudl set verification-failed, though technically it didn't fail, rather the previous fix was deemed just a workaround...
[18:24] <SpamapS> hallyn: the tags are just signals to us as to whether or not users feel the bug should stop or progress
[18:24] <SpamapS> hallyn: verification-failed is "do not promote this"
[18:24] <hallyn> SpamapS: right, and that's sort of what i want
[18:24] <hallyn> i want the next one in unapproved to take its place
[18:24] <SpamapS> then yes, leave it verification-failed and the sru-accept will replace it
[18:25] <hallyn> ok, thanks
[18:26] <hallyn> (done, this was bug 1189926 fwiw)
[18:26] <ubottu> bug 1189926 in qemu-kvm (Ubuntu Precise) "data corruption in storage attached to VM using KVM" [High,Fix committed] https://launchpad.net/bugs/1189926
[18:26] <hallyn> arges: ^ hopefully that gets the ball rolling again
[18:27] <barry> cjwatson: still around?
[18:29] <arges> hallyn: did i mess something up?
[18:29] <arges> hallyn: oh i see you'll upload the new patch : ) thanks
[18:30] <hallyn> arges: I uploaded it quite some time ago, but it never got promoted because the previos one was still waiting to be promoted
[18:30] <arges> ah
[18:52] <slangasek> infinity: so, no late-night headaches giving you visions to explain what's wrong with plymouth? :)
[18:53] <slangasek> I've looked at gdb disas output on ply_get_timestamp(), and I don't see anything amiss.  maybe this needs someone who's better at x86 asm than me.
[18:56] <infinity> slangasek: I was entirely epiphany-free last night.  And x86 asm is definitely not my forte.
[18:56] <slangasek> infinity: whose forte is it?
[18:57] <infinity> slangasek: I could point you at any number of Intel employees, if that's helpful. :P
[18:57] <slangasek> hmm :)
[19:20] <infinity> slangasek: ( Not relevant to the livecd-rootfs/eatmydata discussion we had, but vaguely related, should someone decide that regular buildds should get such a treatment: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713035 )
[19:20] <ubottu> Debian bug 713035 in eglibc "eglibc: FTBFS when built with eatmydata" [Normal,Open]
[19:20] <infinity> slangasek: TL;DR: eatmydata doesn't wrap sync convincingly enough to not eff up testsuites.
[19:21] <lifeless> surely that should be a bug on eatmydata?
[19:22] <infinity> lifeless: It's been cloned and reassigned already.
[19:22] <lifeless> ah
[19:22] <lifeless> sucks to be me :)
[19:29] <slangasek> infinity: yeah, someone raised that bug to my attention already :)
[19:33] <Noskcaj> kirkland_, roaksoax: This is your daily reminder to find a day for testdrive
[20:20] <gQuigs> I'm trying to build samba to fix a bug, but failing: http://pastebin.ubuntu.com/5805829/
[20:21] <gQuigs> running: debuild -uc -us  in the directory from apt-get source samba
[20:35] <maxiaojun> hi, guys, I find some packages' section is probably wrong
[20:35] <maxiaojun> imho
[20:35] <maxiaojun> unity-webapps-* should belong to 'main'
[20:35] <maxiaojun> ubuntu-sdk and dependencies should belong to 'main'
[20:36] <maxiaojun> dependencies of "ubuntu-restricted-extras" should be long to multiverse
[20:36] <ogra_> maxiaojun, that requires a main inclusion report and an extensive review process
[20:37] <ogra_> packages usually enter the archive in universe before they get promoted to main
[20:37] <jbicha> maxiaojun: multiverse depends on universe
[20:37] <maxiaojun> universe -- community-maintained FOSS
[20:38] <ogra_> just be patient, unity-webapps as well as the sdk will be in main by release day
[20:39] <maxiaojun> multiverse -- Software restricted by copyright or legal issues
[20:40] <maxiaojun> i guess dependencies of "ubuntu-restricted-extras" are indeed "Software restricted by copyright or legal issues"
[20:40] <infinity> maxiaojun: Not all of them.  Is there a specific one you're concerned about?
=== kk2 is now known as Kk2
[20:41] <maxiaojun> i think most of them are
[20:42] <maxiaojun> the problem is, if I disable 'multiverse', the repo still contains non-free software
[20:43] <ogra_> surely not
[20:43] <maxiaojun> on the other hand, if I disable 'universe', I miss some important but non-free software
[20:43] <ogra_> it might contain a metapackage depending on nonfree sw ... but to my knowledge there is no nonfree stuff in universe
[20:44] <infinity> maxiaojun: Which non-free software is in universe?  Names, please.
[20:44] <maxiaojun> the codecs doesn't considered non-free?
[20:45] <infinity> maxiaojun: "All the deps of ubuntu-restricted-extras" is not helpful, since plenty of its deps are free.
[20:45] <ogra_> there are many open codecs, which ones specifically ?
[20:46] <maxiaojun> *-bad *-ugly ?
[20:48] <infinity> maxiaojun: Both of those are free, from a copyright perspective.
[20:48] <infinity> maxiaojun: bad is "bad" because of quality concerns.
[20:48] <ogra_> the package description is pretty informative :)
[20:48] <ogra_> helps to read it ;)
[20:49] <maxiaojun> "GStreamer plugins from the "bad" set" ?
[20:50] <ogra_> thats the title ...
[20:50] <infinity> maxiaojun: ugly is "ugly" due to potential distribution issues in some jurisdictions, but we don't split universe/multiverse according to random patent claims, only copyright concerns.
[20:50] <infinity> (If we put everything that might be covered by a patent in restricted and multiverse, we'd have no main and universe left)
[20:50] <infinity> Perhaps a slightly pessimistic world view of software patents, but probably not inaccurate.
[20:51] <maxiaojun> The code might be widely known to present patent problems.
[20:51] <maxiaojun> http://gstreamer.freedesktop.org/modules/gst-plugins-ugly.html
[20:52] <ogra_> well, it is still opensource code under a free license
[20:52] <ogra_> so it qualifies for universe ... no matter what patents there are
[20:53] <ogra_> (and the patents are pointed out in the package description as you can see)
[20:54] <maxiaojun> but it can be pulled automatically?
[20:56] <ogra_> pulled ?
[20:57] <maxiaojun> open a media file
[20:57] <maxiaojun> then the media player would prompt to install additional package
[20:58] <ogra_> yeah, it does that
[21:29] <ScottK> tvoss_: When you made the XMir video, were you using non-standard settings for kwin effects on KDE?
=== Kk2 is now known as kk2
=== salem_ is now known as _salem
[22:03] <cjwatson> xnox: please report it to Debian - I won't be able to do anything until at least Monday anyway, and in any case Joey is way more familiar with the intricacies of make than I am
[22:03] <xnox> cjwatson: ack. will make a minimal reproducer first.
[22:09]  * ogra_ seriously wonders why infinity and I talked to maxiaojun .... if i have to answer the exact same stuff that was asked above by mail again
=== kentb is now known as kentb-out
[22:17] <Laney> ogra_: the mail came before irc
[22:18] <ogra_> oh
[22:18]  * ogra_ slaps himself to read timestamps 
[22:18] <Laney> still duplication though
[22:18] <ogra_> maxiaojun, sorry
[22:18]  * xnox tries this Mir ppa.....
[22:36] <xnox> it works rather nice.
=== sunweave1 is now known as sunweaver
=== wedgwood is now known as wedgwood_away