[01:01] <saiarcot895> Can someone nominate bug 1284190 for Trusty?
[01:01] <ubottu> bug 1284190 in openscenegraph (Ubuntu) "openscenegraph 3.2.0~rc1 doesn't build on ARM (armhf), but builds fine in Debian" [Undecided,Fix released] https://launchpad.net/bugs/1284190
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _TJ_ is now known as TJ-
=== timrc is now known as timrc-afk
[07:42] <dholbach> good morning
[07:44] <sil2100> Morning o/
[07:47] <sil2100> didrocks: hello! Are you busyish right now? :) I'm looking for a volunteer that would do some operations on snakefruit for me ;)
[07:47] <didrocks> sil2100: hey! if it's just for a few minutes, I can handle that
[07:48] <sil2100> didrocks: ok! What I would need is, first: a bzr pull on the cu2d directory on snakefruit to pull in my missing change for copy2distro
[07:49] <didrocks> sil2100: no need for a review?
[07:50] <sil2100> didrocks: it's part of a bigger change, and it's just a tweak now for the new stuff to work wit the old stuff as well
[07:50] <didrocks> sil2100: ok
[07:51] <sil2100> didrocks: because of my lack of this one thing to support back-compatibility (which got removed by accident when all the bazillion workarounds were cleaned), it also caused some packages to be rejected, and I would like their rsync files copied to ./incoming again once the bzr pull is done :)
[07:51]  * sil2100 will give a list
[07:52] <didrocks> sil2100: really man, that's why I offered my help for all the reviews… seems you don't want them and things are breaking
[07:54] <sil2100> It's like almost the finish line! Publishing to ubuntu-rtm works, it would be the same for ubuntu if we would switch to production already, so this got only broken because we have a mix of prod and preprod publishings made
[07:55] <didrocks> sil2100: doesn't answer why you didn't want to get any review from the start, but oh well ;)
[07:56] <sil2100> didrocks: I blame it on being ashamed of my python skills!
[07:56] <sil2100> didrocks: if anything, the missing rsync files ;) paste.ubuntu.com/8033978/
[07:56] <didrocks> you shouldn't! reviews is what enable everyone to get more skills :)
[07:56]  * didrocks grabs
[07:57] <sil2100> I know, it's a bit of like shooting in one's own knee sadly ;/
[07:57] <didrocks> sil2100: ok, trunk pulled and all rsync files in incoming/
[07:58] <didrocks> running a manual sync
[07:58] <didrocks> done, no error message
[07:58] <sil2100> |o|
[07:58] <sil2100> That's... unexpected!
[07:59] <sil2100> didrocks: thanks!
[07:59] <didrocks> yw ;)
[07:59] <didrocks> seems some are already on -changes
[07:59] <didrocks> (ubuntu-keyboard)
=== doko_ is now known as doko
[08:58] <halfie__> hey, why doesn't the openldap / slapd in trusty have support for {SSHA512} hashing scheme?
[09:15] <tjaalton> it's too old?
[09:17] <tjaalton> hm no, looks like the module is under contrib tho
[09:19] <tjaalton> halfie__: slapd-sha2 isn't included, see debian bug #746727
[09:19] <ubottu> Debian bug 746727 in slapd "slapd: Please include slapd-sha2 contrib module" [Wishlist,Open] http://bugs.debian.org/746727
[09:43] <halfie__> tjaalton, cool, thanks, taking a look now.
[09:46] <seb128> doko, hey, are you aware of any issue with the llvm update?
[09:46] <seb128> some autopkgtests started failing yesterday due to it
[09:46] <seb128> e.g http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/149/
[09:46] <seb128> on i386
[09:46] <seb128> "LLVM ERROR: Do not know how to split the result of this operator!"
[09:46] <seb128> seems to be the issue
[09:57] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
=== hobana.freenode.net changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[10:08] <doko> seb128, mlankhorst: do you know how to debug this, get a reproducer?
[10:09] <mlankhorst> do you have a public url?
[10:10] <seb128> doko, no idea how to debug, reproducer is "run autopkgtest for ubuntu-system-settings-online-accounts on utopic"
[10:10] <seb128> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/148/ARCH=i386,label=adt/
[10:10] <mlankhorst> ok
[10:10] <seb128> is a public url
[10:11] <seb128> it's easy to reproduce locally, Laney and I confirmed
[10:11] <mlankhorst> seb128: we have moved to llvm-3.5 on doko's request, when did it start failing?
[10:12] <seb128> yesterday
[10:12] <Laney> downgrading mesa and getting libllvm3-4 back fixes it
[10:12] <mlankhorst> ok
[10:13] <mlankhorst> I'll try with reverting just llvm first since that seems to be the obvious step here
[10:13] <Laney> ta
[10:13] <doko> mlankhorst, well we know how to work around it, but do we know how to debug this?
[10:14] <mlankhorst> doko: I want to rule out it being the  upgrade to 10.2.5 first i also uploaded that
=== tvoss is now known as tvoss|test
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[10:19] <mlankhorst> hm what ppa has online-accounts-ui?
[10:19] <Laney> ubuntu-system-settings-online-accounts in the archive
[10:20] <mlankhorst> ok I don't have a i386 utopic chroot atm, give me a bit..
[10:21] <Laney> I ran it like this http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[10:22] <mlankhorst> the log has enough info
[10:23] <mlankhorst> 06:24:26.845 INFO _launcher:431 - Launching process: ['/usr/bin/online-accounts-ui', '-testability', '--desktop_file_hint=/usr/share/applications/online-accounts-ui.desktop']
[10:48] <prorus> Hello there, little help needed http://askubuntu.com/questions/510706/live-build-lb-config-help-needed
[10:48] <prorus> In short I need to specify in ld config kernel version
[10:49] <prorus> no idea how to do it even google won't help
[10:59] <doko> jamespage, zul: fixed your autopkg test regression in swift
[11:16] <mlankhorst> hm test works for me on real hardware
[11:17] <doko> mlankhorst, does llvm have some means to "downgrade" the cpu it compiles for?
[11:18] <sil2100> hm, it seems I disappeared from the patch pilot list
[11:18] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
[11:18] <mlankhorst> doko: dno, I can run in qemu..
[11:19] <mlankhorst> oh nm the warning happens
[11:22] <mlankhorst> doko: doing a google search.. https://github.com/llvm-mirror/llvm/commit/636a9bece43b3f10c27fb1260467fdc3cf989ea1 ?
[11:22] <mlankhorst> from https://github.com/JuliaLang/julia/issues/7911
[11:23] <mlankhorst> I'll give it a shot
[11:28] <mlankhorst> hm weird, should be applied
[11:31] <mlankhorst> doko: can I crank up the verbosity on llvm?
[11:31] <Laney> tyhicks: hiya, do you think you're going to be able to get to the dbus merge again soon? Having 1.8 would be nice if we can manage it.
[11:32] <Laney> selfishly, I want the dbus-run-session script :-)
[11:32] <doko> mlankhorst, probably, but it's a long time I did some work with llvm
[11:33] <mlankhorst> ok
[11:50] <sil2100> Lunch break :)
[11:50] <sil2100> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== MacSlow is now known as MacSlow|lunch
[12:22] <doko> jtaylor, python-scipy autopkg test failing on i386
[12:23] <doko> this test test_roots (test_interpolate.TestPPoly) fails during the build too, but test results are ignored :-/ but not for the autopkg test
[12:27] <saiarcot895> Can someone nominate bug 1284190 for a Trusty SRU?
[12:27] <ubottu> bug 1284190 in openscenegraph (Ubuntu) "openscenegraph 3.2.0~rc1 doesn't build on ARM (armhf), but builds fine in Debian" [Undecided,Fix released] https://launchpad.net/bugs/1284190
=== _salem is now known as salem_
[12:56] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
[12:57] <pete-woods> jdstrand: hi! I'd like a quick chat about settings for scopes
[12:57] <pete-woods> (when you have a few minutes to talk about it)
[12:58] <jdstrand> pete-woods: hi! now is as good a time as any :)
[12:59] <pete-woods> jdstrand: so as I understand it...
[12:59] <pete-woods> scope settings are (currently) being written to $HOME/.local/share/$SCOPE_ID/settings.db
[13:00] <pete-woods> this is (intentionally) somewhere that the scope cannot read directly
[13:00] <pete-woods> I had (incorrectly) thought that an unconfined part of the scope machinery was going to read these settings
[13:00] <pete-woods> and hand them over the the scope when it was queried
[13:01] <pete-woods> however it seems that the scope really needs to read them in-process
[13:01] <pete-woods> i.e. have filesystem level read-only access to them
[13:01] <pete-woods> jdstrand: so should we move them somewhere else? or is it reasonable to add that path to the confinement profile with read-only access?
[13:03] <jdstrand> pete-woods: this is a global settings db for scopes?
[13:03] <jdstrand> ie, all scopes are using the same settings db?
[13:03] <jdstrand> s/db/file/
[13:03] <pete-woods> jdstrand: nope, it's one file per-scope
[13:04] <pete-woods> jdstrand: literally this path $HOME/.local/share/$SCOPE_ID/settings.db
[13:05] <jdstrand> pete-woods: ok, good!
[13:05] <jdstrand> :)
[13:06] <jdstrand> let me check the policy
[13:07] <jdstrand> pete-woods: does SCOPE_ID contain the version?
[13:07] <pete-woods> jdstrand: no, I really mean the short id
[13:07]  * pete-woods checks
[13:08] <pete-woods> yeah, e.g. com.ubuntu.youtube_youtube/
[13:12]  * jdstrand is thinking
[13:13] <jdstrand> pete-woods: is there any reason why it can't be in the existing directory we have allocated for scopes:
[13:13] <jdstrand> @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}
[13:13] <udevbot> Error: "{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}" is not a valid command.
[13:14] <Laney> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100, Laney
[13:15]  * dholbach hugs Laney
[13:17]  * Laney hugs dholbach ;-)
[13:17]  * Laney hasn't opened the list yet... brace for impact
[13:17] <Laney> 59, could be worse
[13:18] <dholbach> takes you what? half an hour?
[13:18] <Laney> dude
[13:18] <Laney> I've always been a super slow sponsor :P
[13:19] <dholbach> come on everyone, the man needs a challenge
[13:19] <mlankhorst> hm
[13:19] <mlankhorst> 10.3 + git seems to work
[13:19] <pete-woods> jdstrand: we don't want the scope to be able to write to the settings itself
[13:19] <Laney> git what?
[13:20] <pete-woods> as that is where the setting for, e.g. should the scope get location data, is stored
[13:22] <jdstrand> pete-woods: ah, so no writes
[13:22] <mlankhorst> Laney: git mesa :-)
[13:22] <Laney> ah
[13:22] <Laney> bisect time
[13:22] <mlankhorst> well git log anything first
[13:22] <mlankhorst> reverse bisects are awful
[13:23] <pete-woods> jdstrand: that's the idea, yes
[13:25] <jdstrand> pete-woods: I can add read-only access to 'owner @{HOME}/.local/share/@{APP_PKGNAME}_@{APP_APPNAME}/settings.db* rk,'
[13:26] <jdstrand> pete-woods: I wonder if it would be more uniform to do this instead: @{HOME}/.local/share/unity-scopes/@{APP_PKGNAME}_@{APP_APPNAME}/settings.db*
[13:26] <jdstrand> (ie, insert 'unity-scopes' in there)
[13:27] <pete-woods> jdstrand: okay, that would mean that confined scopes would use the same paths as unconfined ones, right?
[13:27] <jdstrand> pete-woods: yes, there is no 'leaf-net' or anything embedded in the path
[13:27] <pete-woods> jdstrand: to be honest, I'm happy with any path you think makes the most sense
[13:27] <pete-woods> I just need everything to tie up
[13:28] <pete-woods> and for confined scopes not to be able to write to it
[13:28] <jdstrand> pete-woods: I like having unity-scopes in there since without it, the path sorta looks like the path apps use, but not quite
[13:28] <pete-woods> okay, sure, that works for me
[13:28] <jdstrand> pete-woods: actually, would it be better served in ~/.config?
[13:29] <pete-woods> jdstrand: probably makes more sense, too
[13:29] <pete-woods> given it's, er, config!
[13:30] <jdstrand> pete-woods: ok, so I will add this to apparmor-easyprof-ubuntu 1.2.18: @{HOME}/.config/unity-scopes/@{APP_PKGNAME}_@{APP_APPNAME}/settings.db* rk
[13:30] <jdstrand> pete-woods: I'm assuming this is sqlite? (perhaps I shouldn't)
[13:31] <pete-woods> jdstrand: fantastic stuff
[13:31] <pete-woods> it's u1db, but underneath sqlite, yes
[13:31] <pete-woods> the next step is making sure u1db doesn't get upset for a RO database
[13:32] <jdstrand> ok, good. that's why I used 'settings.db* rk' (account for sqlite journal and lock files)
[13:32] <pete-woods> :)
[13:33] <jdstrand> pete-woods: not sure about u1db, but sqlite can definitely do it. talk to mardy if you need help (he is using ro on an sqlite db for online accounts)
[13:33] <jdstrand> pete-woods: if you need help with u1db specifically, talk to kalikiana
[13:33] <pete-woods> jdstrand: thanks, will see how this goes first :)
[13:35] <mara__> please help. I have a Java Swing project in Netbeans. I need him to create the Debian Source package. Can someone help me. thanks
[13:37] <saiarcot895> Can someone nominate bug 1284190 for a Trusty SRU?
[13:37] <ubottu> bug 1284190 in openscenegraph (Ubuntu) "openscenegraph 3.2.0~rc1 doesn't build on ARM (armhf), but builds fine in Debian" [Undecided,Fix released] https://launchpad.net/bugs/1284190
[13:47] <hallyn> sigh, was going to merge slof from debian, but the cross compiler appears to be crashing when i test-build locally
[13:52] <darkxst> Laney, let me make that 60 for you then ;) bug 1076232
[13:52] <ubottu> bug 1076232 in nautilus (Ubuntu) "Build with tracker support" [Wishlist,Confirmed] https://launchpad.net/bugs/1076232
[13:59] <mara__> please help. I have a Java Swing project in Netbeans. I need him to create the Debian Source package. Can someone help me. thanks
[13:59] <Laney> darkxst: got a bzr branch?
[14:00] <darkxst> Laney, no, but can make one if you prefer
[14:00] <Laney> darkxst: marginally easier because I have to push it there after uploading
[14:00] <Laney> but as you prefer
[14:00] <sil2100> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
[14:01] <mlankhorst> oh nm some error in how I build things
[14:02] <mlankhorst> 10.3 git is affected after all if I run it in a qemu img
[14:04] <darkxst> Laney, ok, will push something up in a few minutes
[14:06] <darkxst> Laney, nautilus branch is missing  1:3.10.1-0ubuntu12
[14:06] <Laney> who uploaded that?
[14:06] <Laney> me
[14:06]  * Laney RUNS!
=== Ursinha is now known as Ursinha-afk
[14:07] <darkxst> Laney, yep!
[14:07] <Laney> one second
[14:08] <Laney> darkxst: try now
[14:09] <darkxst> Laney, yeh that is better ;)
[14:12] <darkxst> Laney, lp:~darkxst/ubuntu/utopic/nautilus/tracker
=== timrc-afk is now known as timrc
[14:12] <Laney> cheers
[14:16] <hallyn> jamespage: so it turned out i was even dumber than we thought yesterday - there was an existing bug with a debdiff attached for ipxe in debian.  just noone has merged it.
[14:16] <hallyn> (bastian blank awol i guess)
[14:17] <hallyn> wonder if this is a candidate for NMU
=== Ursinha-afk is now known as Ursinha
[14:29] <jelly> hallyn: (fwiw, waldi, that's his nickname, has been active here on freenode recently)
[14:30] <jdstrand> pete-woods: hey, can you look at the denials in https://bugs.launchpad.net/barajas/+bug/1355061/comments/1 ?
[14:30] <ubottu> Error: launchpad bug 1355061 not found
[14:30] <jdstrand> pete-woods: the youtube denials that is
[14:31] <jdstrand> pete-woods: there are a number of issues. disregard the libaccounts denial (they need the accounts policy group)
[14:34] <pete-woods> jdstrand: hmm, that's a bit worrying that the scopes API thinks that youtube is unconfined
[14:34] <jdstrand> pete-woods: well, notice the denial
[14:35] <jdstrand> unconfined/com.ubuntu.scopes.youtube_youtube
[14:35] <pete-woods> yes, that's what I mean
[14:35] <jdstrand> then another for leaf-net/com.ubuntu.scopes.youtube_youtube
[14:35] <jdstrand> there are two things:
[14:35] <jdstrand> a) unconfined was tried first
[14:36] <jdstrand> b) these are appending _youtube, but the policy doesn't allow that
=== Ursinha is now known as Ursinha-afk
[14:36] <jdstrand> the policy was adjusted recently for the end points to use @{APP_PKGNAME}_@{APP_APPNAME}
[14:36] <pete-woods> jdstrand: ah, this is because that's how the scopes API determines if something is confined
[14:37] <jdstrand> but the files in the leaf-net directory have thus far intentinally used only @{APP_PKGNAME}
[14:37] <pete-woods> yep
[14:37] <jdstrand> pete-woods: ok, that was my first question-- I can silence that denial
[14:37] <jdstrand> (the unconfined one)
[14:37] <pete-woods> I think this stuff is pretty messed up, though
=== Ursinha-afk is now known as Ursinha
[14:37] <pete-woods> as you say, it's putting stuff in the wrong directory
[14:37] <jdstrand> but, seems the scope is in error to use @{APP_PKGNAME}_@{APP_APPNAME}?
[14:38] <pete-woods> this has come about because that's the actual scope ID
[14:38] <jdstrand> maybe that is a problem in the scope libraries, not sure
[14:39] <pete-woods> yeah, I think it is
[14:39] <jdstrand> that is what I was afraid of. now, I can change the policy to be more specific, but I want to make sure that is intentional, and if intentional, I want to mention that it means multiple scopes shipped via a single click can't share data, which they could before
[14:39] <pete-woods> it's the actual scope runtime that is doing this
[14:54] <hallyn> jelly: cool, thanks
[14:56] <mlankhorst> Laney: can i run that program stand-alone?
[14:56] <Laney> if you pass --shell to adt-run you can ssh in and then run the script
[14:57] <pete-woods> jdstrand: FYI https://bugs.launchpad.net/unity-scopes-api/+bug/1356409
[14:57] <ubottu> Launchpad bug 1356409 in unity-scopes-api "Confined scopes are using the wrong path for the writable directory" [High,Confirmed]
[14:57] <mlankhorst> Laney: I want to run online-accounts-ui stand-alone
[14:58] <Laney> don't know
[14:58] <Laney> look at what the autopilot test runs
[15:00] <mterry> jodh, hello!  I'm looking at a bug in our Touch image.  Where sometimes (seems racy) an upstart job is failing over and over again.  The  crash files from it aborting (seemingly) due to a missing environment variable show that procEnviron for it is basically empty.  But querying the job's environment via initctl shows the right stuff.  What might cause a difference there?
[15:02] <jodh> mterry: so you are using 'initctl set-env' and a job isn't seeing the variable right?
[15:03] <mterry> jodh, it's not about the use of set-env.  get-env shows full normal environment.  But procEnviron in the .crash file shows an environ with like 5 basic variables in it
[15:07] <jodh> mterry: does the job start with the correct environment?
[15:07] <mterry> jodh, I believe so.  The job is respawning regularly.  And doing a get-env on one of its instances prints the right env
[15:10] <mterry> jodh, I'm not saying it's an upstart bug necessarily.  I'm just curious if you've seen this sort of thing before or if it seems likely that upstart could not pass on the right env
[15:11] <jodh> mterry: could it be corrupting it's own environ pointer?
[15:11] <jodh> mterry: we have pretty extensive tests in this area so I'd be surprised if it's an upstart bug tbh.
[15:11] <jodh> mterry: can you point me at a crash file?
[15:11] <mterry> jodh, the process?  Could do.  It'd have to be pretty early in the sequence, but maybe.
[15:11] <mterry> jodh, yeah I feel like we would have seen this before if it was upstart
[15:11] <mterry> jodh, https://errors.ubuntu.com/oops/c2b19e56-22f2-11e4-9d72-fa163e373683
[15:12] <mterry> jodh, that's a specific version of the general crash problem
[15:16] <jodh> mterry: wait a sec - ProcEnviron is only a subset of the env vars; apport doesn't show the complete set for security reasons.
[15:17] <mterry> jodh, oh really?  I was under the impression it was full.  But that makes some sense...  OK.  So that may be a complete red-herring
[15:17] <mterry> I thought that was why we restricted errors.u.c to ubuntu members and whatnot
[15:18] <jodh> mterry: also, note that 'initctl {get,list}-env' shows the "global" job environment table (ie not job-specific), unless called directly from a job.
[15:19] <jodh> mterry: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L484
[15:20] <jodh> mterry: so you'll have to look at environ in the core file, but it may be that the crash is unrelated to env vars.
[15:21] <mterry> jodh, ok thanks so much for the help.  sigh
[15:22] <mterry> jodh, my sigh was at the problem, not you!  :)
[15:25] <jdstrand> pete-woods: ah, thanks!
[15:27] <jodh> mterry: could you maybe change the job to run 'exec strace -o ... unity8-dash' ?
[15:28] <mterry> jodh, maybe...  It's a bit racy, and I haven't even been able to reproduce myself yet
[15:39] <doko> infinity, can we start building glibc with gcc-4.9?
[15:40] <infinity> doko: Does that magically fix the ppc64el failure we don't know the cause of? :P
[15:41] <infinity> doko: I'll throw a test build at my PPA for my next merge and see how it looks on all arches.
[15:41] <infinity> doko: I assume gcc-4.8 will stick around for jessie, and there's no rush to switch in Debian?
=== pete-woods is now known as pete-woods|away
[15:41] <doko> infinity, no, already checked, but didn't cause any additional test failures
[15:41] <doko> infinity, well, I would like to get rid off it
[15:42] <infinity> doko: Alright, I'll see what I can do on the Debian side too.  That'll take a bit more testing to be sure.
[15:46] <doko> infinity, ahh, and I would need the cross-toolchain-base package working again for multilib builds ...
[15:46]  * doko hides
[15:47] <infinity> doko: Yes, I was going to take ownership of fixing that mess.
[15:47] <infinity> doko: It's about to get worse before it gets better, so I'll fix as we go.
[16:32] <tjaalton> should systemd-sysv be installable now, without removing unity?
[16:32] <seb128> speaking of systemd, who is working on that transition, out of pitti?
=== arrrghhhAWAY is now known as arrrghhh
[16:33] <seb128> I've upgraded to utopic and my system stopped shutting down or rebooting, it hangs on the plymouth logo forever, I need to sit on the power button to get ouf of the situation
[16:33] <seb128> is that a known issue/where that should be reported?
[16:34] <seb128> oh, also "hibernate" is back as an option in the UI, didn't we turn that out on purpose, is that a bug?
[16:34] <seb128> slangasek, ^ you might know? ;-)
[16:34] <slangasek> seb128: the UI is not my department ;)
[16:34] <seb128> slangasek, what about the hang on plymouth? ;-)
[16:35] <slangasek> seb128: but as of the last TB discussion, there were unsolved issues that were considered blockers for re-adding 'hibernate' to the menu
[16:35] <seb128> slangasek, I guess hibernate is a question for pitti, when he's back next week
[16:35] <slangasek> seb128: well, I'm on vacation, so yes but no.  Maybe jodh can help?
[16:36] <seb128> slangasek, thanks for pointing somebody, I was unsure who to ask, usually I would grab pitti but he's on vac as well
[16:37] <seb128> slangasek, enjoy your days off work ;-)
[16:37] <seb128> jodh, hey, can you help debugging the issue I described a bit earlier?
[16:38] <jodh> seb128: hmm, just checked and my systemd vm is suffering similarly. looking... can you raise a bug meantime?
[16:38] <seb128> jodh, sure, against what component?
[16:38] <seb128> upstart?
[16:39] <seb128> not sure what init system I'm using, I didn't do anything special, is systemd default yet in utopic?
[16:39] <jodh> seb128: are you talking about a system booting with systemd here?
[16:39] <infinity> Shouldn't be.
[16:39] <jodh> seb128: no.
[16:39] <jodh> seb128: ps -p1
[16:39] <seb128> jodh, dunno, how do I tell what is booting? that's my laptop, I did no hacking around, just upgraded from trusty to utopic
[16:40] <seb128>     1 ?        00:00:02 init
[16:40] <jodh> seb128: that's upstart. I'm not seeing that issue then. Please raise an upstart bug for now then thanks.
[16:41] <seb128> jodh, do you have any debug hints?
[16:41] <seb128> I feel like that a bug report without details is not going to be useful, if you don't see the issue to be able to debug it
[16:42] <jodh> seb128: get rid of 'quiet' and 'splash' to see if that fixes the problem. If not, it might show what is going on. If that doesn't help, you could maybe apply lp:~jamesodhunt/ubuntu/trusty/sysvinit/log-open-files-on-shutdown that never quit made it into the archive.
[16:43] <seb128> k
[16:43] <seb128> thanks
[16:49] <arges> hallyn: hey. I noticed that kvm_stat wasn't packaged up in qemu. I created a patch to add it to qemu-utils. Any objections or comments? I can point you at a bug/patch soon if you'd like
=== Ursinha is now known as Ursinha-afk
[16:52] <hallyn> arges: would you mind dropping by oftc#debian-qemu and dropping your debdiff there?  we may be syncing (at least at an svn level :) the debian+ubuntu qemu trees so may as well let him know asap
=== Ursinha-afk is now known as Ursinha
[16:53] <arges> hallyn: would it be easier to submit a patch to debian? then post there?
[16:53] <hallyn> arges: might be.  i mean if you want it asap i can always push it in and let it work its way up,
[16:54] <arges> i'll submit the patch to debian and track it in ubuntu launchpad/debian bugs
[16:57] <Laney> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[17:42] <arges> hallyn: so mjt is saying that kvm_stat is part of the qemu-kvm package, but in Ubuntu we don't install this. Is that the solution to just install qemu-kvm? or is that package deprecated?
[17:45] <arges> the old qemu-kvm packages
[17:47] <hallyn> arges: i don't see kvm_stat in qemu-kvm pkg.
[17:48] <arges> hallyn: the older version of it apparently. Anyway I'm replying to the debian bug
[17:48] <arges> s/apparently//
[17:49] <arges> hallyn: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758042 fyi
[17:49] <ubottu> Debian bug 758042 in qemu "qemu-kvm: add kvm_stat to qemu-utils package" [Wishlist,Open]
[17:52] <hallyn> yeah i got the opening email, haven't re-fetched to ge tthe rest of the thread yet
[17:57] <hallyn> oh, i think he means it's aprt of the qemu-kvm *source* pkg
[17:57] <hallyn> in wheezy/squeeze
[17:58] <hallyn> arges: ^ all is fine, he's right, debian will need a replaces in qemu to do it right, he's going to do it
[18:32] <smoser> i've a question about /vmlinu? and /initrd.img.
[18:33] <smoser> what is the expected behavior of those symlinks.
[18:33] <smoser> do they point to the latest installed kernel or the newest (version compare-wise) kernel.
[18:36] <dobey> now that gcc-4.9 is default, how do i "update" my sbuild utopic-amd64-armhf chroot to be able to cross compile again?
=== ming is now known as Guest61014
=== tarpman_ is now known as tarpman
=== halfie_ is now known as halfie
=== henrix_ is now known as henrix
=== io is now known as IdleOne
[18:42] <hallyn> smoser: context?
[18:43] <smoser> well, just what is it supposed to point to
[18:43] <smoser> it points to *something*
[18:43] <smoser> but i'm not sure what htat something is supposed to be.
[18:43] <sarnold> whichever kernel the sysadmin wants to boot next, right?
[18:46] <smoser> http://www.tin.org/bin/man.cgi?section=5&topic=kernel-img.conf
[18:46] <smoser> i *think* says "latest installed". b
=== ValicekB_ is now known as ValicekB
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== mardy_ is now known as mardy
[19:52] <israel_> Hi does anyone know of a library to convert X11 colornames to hexidecimal, or rgb?
[19:54] <sladen> israel_: grep MistyRose /usr/share/X11/rgb.txt
=== salem_ is now known as _salem
[19:58] <sladen> israel_: grep MistyRose /usr/share/X11/rgb.txt | awk '{printf("%02x%02x%02x\n",$1,$2,$3);}'
[20:02] <israel_> sladen: Thanks, I am wondering if there is a library for C++... sorry I forgot to mention that, I had been asking on a different channel.
[20:03] <asac> xnox: hey ho. wonder, whats the plan about https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot? are we still trying to get that out of proposed/
[20:03] <asac> ?
[20:03] <israel_> I can also use awk to get each column... but I really want something where I can feed in an x11 colorname and get out a hexcolor (or rgb...)
[20:06] <asac> infinity: hey, i see https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot failed to upload on i386
[20:06] <asac> do we need to give that back? can you do?
[20:06] <asac> thanks
[20:07] <sladen> israel_: XLookupColor(), returns *exact_def which are the RGB colours
[20:07] <sladen> israel_: XLookupColor(), returns *exact_def which are the RGB colour values
[20:09] <israel_> sladen: thanks So do I pass in something like  const char* color = "white"  and get out something like 255255255
[20:09] <israel_> where can I find the documentation?
[20:10] <infinity> asac: No.,
[20:10] <infinity> asac: It failed to upload for good reason, retrying won't fix it.
[20:11] <asac> infinity: ok, what's up there?
[20:11] <infinity> asac: Looks like most of its binaries were replaced by llvm-toolchain-3.5
[20:11] <infinity> asac: The upload log makes that fairly clear.
=== _salem is now known as salem_
[20:12] <asac> infinity: any suggested way forward?
[20:12] <infinity> asac: Remove llvm-toolchain-snapshot?
[20:12] <asac> infinity: yeah. guess so. thanks for finding the -3.5 thing
[20:12] <infinity> asac: I assume you're not actually waiting on it for anything, since the bianries you probably care about are built from another source.
[20:13] <asac> we have a regression during test build and it didnt make sense as that -snapshot thing was uploaded ages ago
[20:13] <asac> but now i see the -3.5
[20:13] <asac> was pushed yesterday by doko
[20:13] <asac> https://launchpad.net/ubuntu/+source/llvm-toolchain-3.5
[20:13] <asac> 1: Test timeout computed to be: 9.99988e+06
[20:13] <asac> 1: LLVM ERROR: Do not know how to split the result of this operator!
[20:13] <asac> https://launchpadlibrarian.net/182181736/buildlog_ubuntu-utopic-i386.messaging-app_0.1%2B14.10.20140813-0ubuntu1_FAILEDTOBUILD.txt.gz
[20:14] <infinity> We're actually building with llvm?
[20:14] <infinity> Are we masochists?
[20:14] <asac> infinity: its used for graphics tests
[20:14] <asac> infinity: not for building... we use a xvfb setup to do strong testing during build it seems
[20:14] <asac> tvoss knows more
[20:14] <infinity> Ahh, llvmpipe fun, not the compiler.
[20:15] <asac> guess so (/me kind of detached from smart things :))
[20:15] <doko> asac, mlankhorst identified a patch for 3.5 to fix i386. I don't know the current state
[20:15] <asac> mlankhorst: ^
[20:15] <doko> and synced the snapshot
[20:16] <asac> doko: the -snapshot is in proposed since jul 25 ... guess thats not what he synced?
[20:16] <asac> (thanks for coming back btw)
[20:18] <tvoss> infinity, yup, likely llvm-pipe
[20:18] <infinity> tvoss: Right, that's what I assumed when I actually read the log.
[20:18] <infinity> tvoss: Which was slightly less scary than the idea that we're using llvm to compile things. :P
[20:19] <tvoss> infinity, yup, I initially thought about something qml-ish or a shader-compilation in the qml engine, but xvfb is a strong hint towards llvmpipe
[20:19] <infinity> Apologies to the Apple fanboys who are now silently frothing with rage.
[20:19] <tvoss> infinity, yup
[20:21] <asac> doko: any suggestion we could do to unblock landings of our UI software while we wait for mlankhorst ?
[20:25] <infinity> asac: Your only three viable options are probably to find someone else to debug and fix llvm, wait for mlankhorst, or temporarily disable the testsuite with big red flashing warnings to turn it back on Very Soon.
[20:26] <asac> infinity: yeah. thanks for confirming what i thought. any idea who knows enough about llvm that it might worst trying option 1. ?
[20:27] <infinity> asac: I know some llvm, but llvmpipe is a complete black box to me.  My ramp up time would be far too long for your quick landing goal.  I imagine that's true of most of us.
[20:27] <asac> infinity: general proposed question. i know that proposed runs reverse dependency autopkgtest one level up, right?
[20:27] <asac> infinity: does it also do build testing?
[20:27] <asac> one level up?
[20:29] <infinity> asac: As in, rebuild all rdeps?  No.
[20:31] <asac> infinity: kk thanks
[20:31] <asac> thought so, just wanted to get confirm
[20:39] <mlankhorst> infinity: I can't get that autopkgtest to run in a debugger, does autopilot3 have some debugger support for it?
[20:40] <infinity> mlankhorst: Hrm?  The failing test is a build-time testsuite, not an autopkgtest.
[20:40] <mlankhorst> yeah but it's triggered with autopkgtest too
[20:40] <mlankhorst> autopilot3 run online_accounts_ui iirc
[20:40] <infinity> Ahh, different test.
[20:41] <mlankhorst> oh which one is failing?
[20:41] <infinity> mlankhorst: This one might be easier for you to reproduce: https://launchpadlibrarian.net/182181736/buildlog_ubuntu-utopic-i386.messaging-app_0.1%2B14.10.20140813-0ubuntu1_FAILEDTOBUILD.txt.gz
[20:41] <infinity> mlankhorst: Looks like a very clear xvfb call.
[20:41] <mlankhorst> yeah more sane
[20:42] <mlankhorst> seems more tests are failing atm then
[20:44] <asac> could we somehow be sneaky and depend on llvm 3.4 thingy to make that build pass while we fix things?
[20:45] <asac> mlankhorst: infinity: ?
[20:46] <asac> (and thanks for coming back mlankhorst)
[20:51] <saiarcot895> Wait, there's a plan to use the LLVM compiler for Ubuntu?
[20:56] <infinity> saiarcot895: No.
[20:58] <asac> depends on the defintion of plan and use i am sure :)
[20:58] <infinity> I'm sticking with "no".
[20:58] <asac> hehe
[20:58]  * asac checks secret roadmap
[20:59] <asac> infinity: mlankhorst: in case there is a build-depend trick for these packages to still build and land without disabling tests, please let pmcgowan; otherwise lets check tomorrow where we are
[20:59] <asac> thanks
[21:01]  * asac break
[21:07] <mlankhorst> doko: mind if I revert to llvm 3.4 for now?
[21:11] <sladen> israel_: https://gist.github.com/sladen/833d4d23d89aa12e9dc8
[21:11] <doko> mlankhorst, sure, but please make sure that we do the switch for 14.10
[21:11] <mlankhorst> doko: yeah this will make my 14.04.2 a lot easier for me too
[21:12] <israel_> sladen: you are amazing!! thank you!!
[21:13] <mlankhorst> but that will fail for that other arch right?
[21:14] <mlankhorst> oh well hope it gets forced through..
[21:18] <israel_> sladen: this is great, I can totally adapt this for my uses, and I will give you credit in the appropriate places :)
[21:29] <mlankhorst> ok revert uploaded, mesa should be back to 3.4 soon-ish
=== gusnan_ is now known as gusnan
=== salem_ is now known as _salem
[22:10] <jtaylor> someone have an upstream gcc without ubuntu patches handy?
=== arrrghhh is now known as arrrghhhAWAY
[22:50] <xnox> asac: no, we llvm-toolchain-snapshot should not migrate at the moment. llvm-toolchain-3.5 superseeds all packages build by llvm-toolchain-snapshot.
[22:50] <xnox> asac: once 3.6 snapshot is packaged, and synced it will migrate.
[22:53] <xnox> asac: i see 3.6 snapshot in proposed now, so it should migrate.
[22:55] <infinity> xnox: Backscroll contained all that info. ;)
[22:57] <xnox> infinity: heh, fair enough =)
[22:57] <xnox> infinity: just had enough time to read highlights alone...
[23:20] <asac> xnox: ack. thx