[02:19] <asac> cyphermox_: how can i mount nexus 4 storage properly?
[02:19] <asac> cyphermox_: like not the face nautilus stuff so i can use cd etc.
[02:20] <asac> cyphermox_: guess first i have to prevent nautilus to not deal with this?
[02:20] <asac> guess on -touch better
[06:13] <dholbach> good morning
[06:14] <Tribaal> hi dholbach
[06:14] <dholbach> hi Tribaal
[07:08] <doko_> jtaylor, matplotlib tests start failing: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-matplotlib/lastBuild
[08:02] <Tribaal> hi all - I need my package to create a /var/log/mypackage directory - what's the recommended way to do it? postinst?
[08:04] <Tribaal> I feel there should certainly be a "better" way to do it since it seems like such a common thing to do...
[08:06] <Tribaal> or should I use a debian/mypackage.dirs file?
[08:06]  * Tribaal is confused
[08:06] <seb128> Tribaal, that works yes
[08:06] <Tribaal> seb128: what's the recommended way to do it then?
[08:07] <seb128> Tribaal, not sure there is only "one recommended" way
[08:07] <seb128> you could make the make install from your software create it, create it from the rules, from a .dirs, etc
[08:07] <Tribaal> seb128: so either is fine? Nice. I'll go for the mypackage.dirs option then, seems easy enough
[08:07] <Tribaal> ok
[08:07] <Tribaal> less work = win
[09:43] <jtaylor> doko_: seems wxversion is 3.0 but it the rest 2.8
[09:49] <jtaylor> which I do not understand, there is no wxversion 3.0
[09:49] <jtaylor> has it been removed from proposed?
[10:14] <doko_> jtaylor, no, there is a new version in proposed
[10:15] <jtaylor> not of 3.0
[11:10] <jtaylor> oh its from another source pacakge
[11:11] <jtaylor> ScottK: what are your plans with the wxpy 3 transition now that you changed wxversion to 3.0?=
[11:11] <jtaylor> rebuild everything against 3.0?
[11:20] <Mirv> anyone else noticing PPA uploads going to /dev/null and no e-mail about acceptance/rejection?
[11:24] <Mirv> from some other uploads it's just me, hmm hmm
[11:24] <Mirv> unless that I'm uploading for trusty series instead of utopic matters
[11:31] <sveinse> Hi. There is no more firmware-libertas in trusty and I cannot find the firmware binary files in any other package either. Anyone can recollect why this has happened?
[11:34]  * Mirv found the reason, finally. using a wrong GPG key apparently results in silence.
[11:35] <Mirv> sveinse: maybe they were collected to the linux-firmware package? dpkg -L linux-firmware | grep libertas lists a lot for me
[11:37] <sveinse> Mirv, I am looking for sd8686.bin, but unless this has been renamed to something else, it is not found in the linux-firmware package IFAICS
[11:38] <Mirv> sveinse: I see sd8686_v9.bin and v8 at least (although I'm on 14.10)
[11:40] <directhex> i see sd8688.bin
[11:40] <directhex> sd8686_v8.bin and sd8686_v9.bin too
[11:51] <sveinse> Mirv, directhex: ah, there it is. Thanks
[11:52] <rbasak> xnox: bug 1355992 claims the last samba merge inadvertently dropped an upstream cherry-pick. Please could you take a look?
[12:13] <ScottK> jtaylor: I don't have a plan, I just fixed an FTBFS.
[12:14] <ScottK> Mirv: I can confirm using the wrong GPG key gets silence.  I've done it before.
[12:17] <infinity> jodh: You around?
[12:18] <infinity> jodh: LP: #901038 is a much nastier bug than the severity implies.
[12:18] <infinity> jodh: Pretty much anything that does a 'telinit u' on upgrade just explodes very unintuitively, and it takes a Very Long Time to get back to a sane enough state that retrying the upgrade fixes it.
[12:19] <infinity> jodh: Like, well over a minute on the machines I'm doing this on right now.
[12:20] <infinity> jodh: So, I think having 'telinit u' block until completion is correct, but it would also be good to sort out WHY this takes so long.  I'd expect it to be seconds (or less than a second), not minutes.
[12:43] <infinity> Riddell: Ahh, good ol' ppc54el. :P
[12:44] <Riddell> by the ubuntu7 upload my typing is showing my frustration!
[12:44] <infinity> :)
[12:46] <asac> however, i tested multiple times yesterday and dont know why, but i never 99had the big time lag in the indicator/infographics screen
[12:47] <asac> but sure its still there
[12:47] <asac> oops
[12:47] <asac> :)
[12:48] <doko> asac, Mirv, whoever: unity-scope-click autopkg tests fail. is this being worked on? blocks gcc-4.9
[12:48] <doko> tvoss, ^^^
[12:52] <ogra_> doko, talk to the lander (marked on the landing spreadsheet)
[12:53] <infinity> ogra_: "The lander" is a pretty opaque thing to people working on the distro.
[12:53] <asac> truish
[12:53] <ogra_> infinity, well, it is the name that is in the column named "lander"
[12:53] <ogra_> :P
[12:53] <asac> hehe
[12:53] <asac> ogra_: where is the landing log again?
[12:54] <ogra_> you mean the spreadsheet URL ?
[12:54] <infinity> ogra_: Yeah, I'll reiterate the above.  That column doesn't exist to someone working on the distro. :P
[12:54] <ogra_> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&pli=1#gid=0
[12:54] <ogra_> now it does :P
[12:54] <infinity> ogra_: And encouraging people to look things up on a spreadsheet at a magic URL won't help it go away or get fixed properly.
[12:54]  * infinity shrugs.
[12:55] <infinity> Anyhow, this one has nothing to do with "the lander", it looks like a dep of unity-scope-click stopped linking pthread, and it needs to explicitly link it itself.
[12:55] <infinity> So, anyone upstream would do.
[12:55] <ogra_> infinity, so who else would you expect to look up the name of the person you want to talk to ?
[12:56] <infinity> ogra_: I'd expect the uploader recorded in LP to not be a bot, but I've beaten this horse a few thousand times.
[12:56] <ogra_> ther is a person that is responsible for getting this package into the archive ... the name of that person is noted down in the spreadsheet
[12:56] <asac> changelog suggests Michal Hruby
[12:56] <asac> Alejandro J. Cura (alecu)
[12:57] <dobey> hrmm?
[12:58] <infinity> dobey: Is your perking up you volunteering to take ownership of unity-scope-click sucking at linking? :)
[12:58] <dobey> infinity: it's a "what is the problem exactly?" :)
[12:58] <infinity> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/artifact/results/log
[12:58] <asac> ogra_: where? i dont see the list of component owners in there anymore
[12:58] <infinity> dobey: Missing a -pthread or -lpthread
[12:59] <infinity> dobey: Which it was likely always missing, but a transitive dep probably pulled it in and recently stopped doing so.
[12:59] <ogra_> asac, the first column ?
[12:59] <dobey> weird
[13:00] <asac> ogra_: well, that requires you to be lucky and find a landing of this component
[13:00] <ogra_> asac, so you want package names ?
[13:00] <asac> ogra_: searching unity-click yields nothing on pending nor archive for me :)
[13:00] <ogra_> ask sil2100 :)
[13:01] <infinity> ogra_: No, more info on the spreadsheet isn't helpful, we need to fix this so we can actually track from LP/changes.
[13:01] <asac> infinity: doko: check with your teammate... we also have a landing commitlog that has the info: http://people.canonical.com/~lzemczak/landing-team/
[13:01] <infinity> Having a spreadsheet that grows infinitely so I can do an upload blame for a package from 8 months ago isn't sane.
[13:02] <ogra_> asac, thats post landing
[13:02] <asac> think having a concatenated log that has all landings would be nice for these things until better solution arises
[13:02] <infinity> ogra_: This is all post-landing.
[13:02] <asac> ah in proposed its still in pending?
[13:02] <ogra_> the package in question hangs before entering the archive
[13:02] <infinity> ogra_: The package is in the archive.
[13:02] <ogra_> wint show up in that changelog
[13:02] <dobey> infinity: hmm, what triggered this autopkgtest?
[13:02] <infinity> dobey: gcc-4.9 upload.
[13:02] <lullis> Hello, all. I have a few questions regarding (I think) lightdm. I am looking for a way to allow users to authenticate remotely, but first of all they need to get a connection to a OpenVPN Server.
[13:02] <ogra_> infinity, yu mean it is in the release pocketalready ?
[13:03] <doko> but the test doesn't compile anything afaics
[13:03] <infinity> ogra_: Yes.
[13:03] <ogra_> oh, i thought it is stuck in autopkgtests
[13:03] <infinity> doko: It... Compiles lots of things?
[13:03] <dobey> infinity: weird
[13:03] <lullis> I was looking at the docs for lightdm, but it does not provide anything related to network connections, so my guess is that any of current greeters won't be able to have a "network applet". Is that correct?
[13:03] <infinity> ogra_: No, it's an autopkgtest regression, probably due to dep churn.
[13:03] <dobey> infinity: the same package passed under the glibc upload.
[13:04] <infinity> dobey: The glibc upload that's older than the package?
[13:04] <dobey> according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html anyway
[13:04] <ogra_> infinity, ok
[13:04] <dobey> 2.19-4ubuntu2
[13:05] <infinity> dobey: Yeah, I'm not sure what you're driving at.
[13:05] <infinity> dobey: That glibc upload was in July.
[13:05] <infinity> dobey: This new autopkgtest triggered today.
[13:06] <doko> yep, but once it fails, and once it suceeds. it references the very same autpkg run
[13:06] <dobey> infinity: i mean, the only thing i see that changed is gcc-4.9. i'd like to understand why it had the -pthread before and now it doesn't
[13:06] <infinity> doko: The reference is just bad UI.
[13:06] <infinity> doko: It succeeded when it ran in July, the link just links to the latest.
[13:06] <infinity> (so it becomes a stale lie)
[13:06] <doko> dobey, ahh, that's a fix. where do you see this?
[13:07] <infinity> It never had -pthread...
[13:07] <infinity> It may have been pulling it in silently via a dep.
[13:07] <doko> dobey, where do you see the problem?
[13:08] <infinity> doko: In the test log?
[13:08] <infinity> doko: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/artifact/results/log
[13:08] <dobey> doko: in the test log
[13:08] <dobey> infinity: and why wouldn't it still be doing that though, if the dep hasn't changed as well?
[13:08] <infinity> doko: It's clearly missing a -pthread, but the latest build in the archive also doesn't have one there, so...
[13:09] <infinity> doko: So, your assertion is that in the last 4 days, none of the 293 build deps changed?
[13:10] <dobey> infinity: well, if the build-deps of unity-scope-click had changed, it would have caused an autopkgtest run, and it would have failed then, no?
[13:10] <doko> infinity, dobey: so the change is that when using thread from libstdc++ it now always emits a reference to pthread_create, which it didn't before. meaning that problems are now catched at link time, and not at run time
[13:11] <dobey> doko: ok, so libstdc++ change is the cause? that's what i wanted to know
[13:11] <infinity> doko: Ahh, so this is an intentional change in g++/libstdc++ ... Kay.
[13:12] <doko> dobey, not ok if you use this information to blame me ;-P  do you see where things are missing the -pthread?
[13:12] <infinity> doko: That seems like something we might want to comb a rebuild test for once this is in.
[13:12] <dobey> doko: i'm not blaming you. i'm just trying to understand why it worked before, and now it doesn't
[13:14] <doko> infinity, https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01366.html
[13:14] <doko> dumb bot
[13:14] <infinity> doko: And maybe a short note to -devel telling people that they might start seeing "undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'" in their C++ projects, and what that means.
[13:15] <lullis> No one? Maybe someone could point me where to go to ask lightdm-specific questions?
[13:15] <dholbach> lullis, you could try #ubuntu-desktop
[13:15] <infinity> doko: The upstream change looks entirely sane and reasonable to me, just a bit unintuitive (as the last 5 minutes demonstrate), so a heads-up to -devel and a grep of the next rebuild test would both be good, IMO.
[13:16] <infinity> dobey: Are you going to own hunting down which component actually needs the -pthread (unity-scope-click, or one of its deps, or both), and getting it fixed?
[13:16] <infinity> dobey: Or delegate same to someone else. ;)
[13:17] <lullis> dholbach, I imagine there it would be about dealing with configuration of existing greeters. What I am looking is to possibly understand how I would go around writing my own (adding an openvpn connection setup applet)
[13:17] <lullis> I will try, though.
[13:17] <dobey> infinity: i don't have much choice really. damn national holidays in europe and south america :)
[13:17] <dholbach> lullis, the folks who wrote lightdm should be hanging out there
[13:18] <doko> infinity, wanted to wait with the test rebuild until you had a chance to address https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1352836  afaiu this is pending upstream, I have the gcc backport done
[13:22] <doko> jtaylor, ScottK: did you come to any conclusion about the missing wx.py?
[13:22] <jtaylor> doko: I filed an RC bug in debian
[13:22] <jtaylor> lets see what debian does
[13:23] <jtaylor> debian bug 758209
[13:24] <jtaylor> can we force numpy into utopic? the matplotlib failure has nothing to do with it
[13:25] <dobey> doko, infinity: https://code.launchpad.net/~dobey/unity-scope-click/explicit-pthread/+merge/230973 looks correct?
[13:26] <infinity> dobey: Except for the unnecessary whitespace change, sure.
[13:26] <infinity> dobey: Assuming it works.
[13:26] <doko> dobey, well, usually you build with -pthread in both CFLAGS and LDFLAGS
[13:27] <infinity> -lpthread should work fine.
[13:27] <doko> sure
[13:27] <infinity> And it's used other places in the same codebase.
[13:27] <infinity> So, meh.
[13:29] <infinity> dobey: Might be prettier with some CMakey macro.
[13:30] <doko> jtaylor, we can blame dholbach for sponsoring these packages ;-P
[13:31] <infinity> dobey: The tests use "${CMAKE_THREAD_LIBS_INIT}", not sure how that expands, or what exactly it does.
[13:31] <dobey> oh
[13:31] <infinity> dobey: But the tests do seem to be built with -lpthread, while the failing bit isn't.
[13:31] <infinity> dobey: So, that might be the "right" CMakey way to do it.  I dunno.
[13:33] <dobey> changed it to that
[13:34] <jtaylor> I guess we could change matplotlib to wx 3.0
[13:35] <jtaylor> though I would prefer todo that for all packages at once to avoid tcl/tk like issues
[13:36] <infinity> dobey: I'd still nitpick the whitespace change, but otherwise looks alright.  Going to test build to make sure.
[13:37] <doko> jtaylor, it even fails when pyhton-wxgtk3.0 is installed
[13:38] <jtaylor> oh I didn't try that
[13:39] <dobey> infinity: well, i was tempted to fix all the other weird whitespace in that file too, but only did this since i was changing the target_link_libraries call :)
[13:40] <jtaylor> doko: hm in unstable the import works
[13:41] <infinity> dobey: Sure, I'm just from the anal-retentive world where whitespace fixes and bugfixes shouldn't be the same commit.
[13:41] <jtaylor> maybe one has to do a --reinstall python-wxversion you had to do these things when having 2.6 and 2.8 installed
[13:41] <infinity> (So, ie: it's obvious that the 1-liner that fixed the bug is just one line)
[13:42] <dobey> infinity: so am i, but more lenient for very small changes.
[13:42] <pete-woods> jdstrand: hi. are you able to get the easyprof release you made yesterday into RTM?
[13:46] <jodh> infinity: As the bug shhows, we can't actually have telinit block - would have to poll indefinitely attempting to reconnect (ugh).
[13:47] <jodh> infinity: I don't understand why you are seeing stateful re-exec take so long - even on a system with hundreds of running jobs it should be almost instantaneous.
[13:47] <infinity> jodh: arm64, though I can't see why that should make a difference.
[13:47] <infinity> jodh: Nothing running except a few idle daemons.
[13:47] <jodh> infinity: if you can recreate (I can't - tried a few times), can you add some further details to the bug?
[13:48] <infinity> jodh: I can reproduce on a whim, yeah.  What details are you looking for?
[13:48] <infinity> jodh: and what do you mean we can't have telinit block?  That's the only sensible thing for it to do.
[13:49] <jodh> infinity: can you try running http://people.canonical.com/~jhunt/upstart/scripts/get_state.sh and seeing how long that takes to run?
[13:50] <jodh> infinity: telinit connects to upstart via dbus and asks it to re-exec. On re-exec, upstart severs all dbus clients connections (of which telinit is one :-)
[13:50] <jodh> infinity: it's all on the bug dude
[13:51] <jodh> infinity: I wonder if for some reason the performance of libjson on arm64 is poor?
[13:51] <infinity> jodh: The bug implies what I'm asking for, though.
[13:51] <infinity> "a better solution to modifying initctl would probably be to modify telinit such that it runs fully synchronous when a restart is requested"
[13:51] <doko> jtaylor, I don't understand that alternatives business, because: $ cat /usr/lib/python2.7/dist-packages/wx.pth
[13:51] <doko> wx-3.0-gtk2
[13:52] <doko> this is hard coded in python-wxversion
[13:52] <jtaylor> I never understood it either, I was very happy when 2.6 disappeared and the problem was gone
[13:52] <jtaylor> now its back :(
[13:52] <jodh> infinity: yes, well the telinit command would certainly block whilst we poll, waiting for the re-exec to finish.
[13:53] <infinity> jodh: Right, which is what we want.
[13:53] <jodh> infinity: Yes, it's not ideal, but until dbus allows a connection to be serialised I think it's the best we can do (tm)
[13:54] <jodh> infinity: I'm tempted to throw in a magic variable that if set disables the blocking op as a 'get out of jail card'
[13:54] <infinity> Oh, FFS, now 'telinit u' works instantly.
[13:54] <infinity> I bet it's because I rebooted all these machines after the upgrades. :(
[13:54] <jodh> infinity: I've tried 4 upgrades and all worked flawlessly. sorry :)
[13:54] <jodh> infinity: upstart just hates you
[13:55] <infinity> Ah-ha, I left one of them not rebooted.
[13:55] <infinity> It still has the slow re-exec.
[13:55] <infinity> We win.
[13:56] <infinity> jodh: So, this could point to a leak or something, if a fresh boot is happy, but an older system isn't.
[13:56] <jodh> infinity: ah - a thought occurs. Do any of the jobs use the 'debug' stanza?
[13:57] <infinity> jodh: Not that I see.
[13:58] <infinity> dobey: That still fails the same way, FWIW.  So, maybe that Cmake thing doesn't do what we thought, and the explicit link would work better?
[13:58] <doko> great packaging ...
[13:58] <doko> cd thirdparty; tar xzf desktop-0.4.2.tar.gz --strip-components=1 -C ../taskcoachlib/thirdparty desktop-0.4.2/desktop
[13:58] <doko> cp /usr/share/pyshared/lockfile.py taskcoachlib/thirdparty
[13:58] <doko> cp: cannot stat '/usr/share/pyshared/lockfile.py': No such file or directory
[13:58] <doko> Makefile:181: recipe for target 'thirdpartymodules' failed
[13:58] <doko> make[3]: *** [thirdpartymodules] Error 1
[13:58] <dobey> infinity: weird
[13:59] <dobey> infinity: so the tests aren't getting -pthread/-lpthread either?
[13:59] <infinity> jodh: Oh dear, get_state is a lot of vomit. :P
[13:59] <infinity> dobey: No, the tests do...
[13:59] <infinity> dobey: As the build logs show.
[13:59] <jodh> infinity: get_state.sh | json_pp > /tmp/upstart.state
[14:00] <jodh> infinity: if you can send me that file along with a get_state.sh run for an amd64 system unaffected that would be useful.
[14:00] <infinity> jodh: Adding json_pp to that pipe makes it take a lot longer, could definitely back up your arm64 json performance assertion.
[14:01] <dobey> wtf
[14:03] <dobey> infinity: ah, needs the find_package() in there too
[14:04] <jodh> infinity: I'll send you a json test prog to check performance...
[14:04] <infinity> jodh: Getting you your outputs.
[14:04] <jodh> infinity: ta
[14:05] <infinity> The filesize differences are shocking. :P
[14:06] <dobey> infinity: so i just pushed the addition of the find_package(), so it should work now
[14:06] <infinity> jodh: http://lucifer.0c3.net/~adconrad/upstart/
[14:06] <infinity> jodh: good returns in under a second, bad takes well over a minute.
[14:06] <jodh> infinity: wow. thanks.
[14:07] <tedg> jodh, I'm kinda curious if bug 1357252 is the same cgroup error Chipaca was talking about yesterday.
[14:07] <infinity> jodh: Both hosts run exactly the same things, the only difference is that one was just rebooted, the other's been up 53 days and lived through some re-execs.
[14:07] <tedg> jodh, When do you expect the better error reporting there to land?
[14:07] <hallyn> hm, what does
[14:07] <hallyn> W: qemu source: virtual-package-depends-without-real-package-depends build-depends: gnutls-dev
[14:08] <hallyn> mean.   apt-cache seems to disaree
[14:08] <infinity> dobey: Testing that.
[14:08] <jodh> infinity: hmm - I don't think it's the performance of the json parser per se - look at the file size difference!
[14:08] <infinity> jodh: Right, it's huge.
[14:08] <infinity> jodh: And all 5 of these hosts were in, I presume, the same state, until 4 were rebooted.
[14:09] <infinity> (The fifth is 14h into a webkit build, hence why I didn't reboot yet)
[14:09] <jodh> infinity: running json_pp on upstart_vomit.bad is taking almost an entire cpu on my system (been running for 20 odd seconds so far)...
[14:12] <hallyn> 'sudo apt-get install gnutls-dev' does do th right thing...  so i guess i can ignore that
[14:12] <infinity> jodh: Anyhow, clearly two very unrelated bugs here, but this highlights why telinit blocking needs to happen.
[14:13] <infinity> jodh: But it would also be smashing to sort out why my state grew so large and make that not happen again. :P
[14:13] <infinity> jodh: Being buildds (constantly tearing down and setting up chroots) might relate, though I'd have assumed my last-minute --disable-sessions default swap would have made that a non-issue.
[14:15] <jodh> infinity: ack. looking at the bad file, you seem to have 591,355 lines of job definition whereas my system has ~1000 lines :)
[14:15]  * jodh goes to get a strong cup of tea...
[14:17] <infinity> jodh: Would it be helpful if I keep the sad system in its sad state, in case you need more info, or can I reboot it at my leisure?
[14:18] <infinity> dobey: That fixes it.
[14:18] <infinity> dobey: Commented on the MP.
[14:19] <dobey> thanks
[14:19] <rbasak> slangasek: please could you review bug 1357003 wearing your ~ubuntu-sru hat? This would be a violation of the micro-release exception, so upstream have asked in advance and I've filed at as a regular SRU-type bug. Upstream would like to know Ubuntu's position to help make a decision.
[14:19] <dobey> now to get it landed
[14:25] <jdstrand> pete-woods: I'll see what I can do (/me needs to review the procedures still)
[14:25] <pete-woods> jdstrand: thanks :)
[14:30] <jodh> infinity: would be useful if you could keep it for a while if not too inconvenient.
[14:30] <jodh> infinity: how many chroots have you got on the bad system?
[14:31] <rbasak> I'm ready to land mysql-5.6 in Utopic, to replace mysql-5.5 completely. This involves switching some binary packages over from being built from 5.5 to being built from the 5.6 source package.
[14:31] <rbasak> The upgrade path works easiest when the mysql-5.5 packages all disappear at the same time as 5.6 appears. Otherwise apt-get seems to want to remove the mysql-server metapackage.
[14:31] <rbasak> (rather than remove mysql-server-5.5).
[14:32] <rbasak> So, please could I have a hand from an archive admin so that we can maybe remove mysql-5.5 binaries in the same publisher run that 5.6 appears?
[14:32] <rbasak> Or should I handle this in some other way?
[14:50] <dobey> infinity: it's building in a silo now
[14:57] <tedg> jodh, any ideas on bug 1357252
[14:58] <jodh> tedg: just updated the bug - we need more debug :)
[15:00] <rbasak> stgraber: around? I'm still waiting on https://lists.ubuntu.com/archives/devel-permissions/2014-August/000711.html. Seems like an unnecessary addition to the sponsorship queue.
[15:00] <tedg> jodh, Were you able to try locally? It might be easier to reproduce there.
[15:02] <slangasek> rbasak: replied on the bug (+1 from me)
[15:03] <rbasak> slangasek: thank you!
[15:03] <jodh> tedg: can you give me an example cmdline to trigger the prob?
[15:04] <tedg> jodh, Let me find it, I'm pretty sure there's a wiki page with info.
[15:05] <tedg> jodh, https://wiki.ubuntu.com/Touch/Testing/ phablet-test-run -p ubuntu-ui-toolkit-autopilot ubuntuuitoolkit
[15:06] <jodh> tedg: thanks
[15:08] <stgraber> rbasak: this is an auto-generated packageset, we don't do manual additions to it.
[15:08] <stgraber> Laney: can you run the script see if that adds what rbasak needs? ^
[15:08] <rbasak> stgraber: yes you do. There have been many instances in the past.
[15:08] <Laney> rbasak: I just ran the script right now
[15:09] <stgraber> rbasak: we did in the past because the script was broken for like a year :)
[15:09] <Laney> you need to add an exception for this if you want to
[15:09] <stgraber> rbasak: now any manual change I do will get reverted when we run the script. We have a list of exceptions in the script itself, though that shouldn't be needed for seeded packages since that's precisely what the script is meant to base the packageset on :)
[15:10] <Laney> or seed it somewhere
[15:10] <Laney> like platform/supported-server
[15:10] <rbasak> Hmm, OK. I still can't upload, but I'll see if I can in a few minutes.
[15:11] <Laney> It didn't get added
[15:11] <rbasak> It's seeded in http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.utopic/supported under "Extra server bits"
[15:12] <stgraber> ok, that's not a server seed so that explains why it's not pulled into your set
[15:12] <stgraber> Laney: can you add an exception for nginx?
[15:12] <Laney> why not platform/supported-misc-servers?
[15:13] <Laney> then it should get into https://bazaar.launchpad.net/~developer-membership-board/+junk/packageset/view/head:/packageset-report#L59
[15:13] <stgraber> that'd actually sort of make sense
[15:13] <rbasak> Laney: I'm not sure I understand the distinction
[15:13] <rbasak> (between "Extra server bits" and supported-misc-servers)
[15:13] <rbasak> Apart from reporting and this script, of course.
[15:14] <rbasak> Why does "Extra server bits" exist in the first place?
[15:14] <stgraber> rbasak: one is a server seed, the other one isn't
[15:14] <stgraber> no idea, possibly someone who didn't know to look into the platform.* seeds too :)
[15:14] <stgraber> and then people just keeping adding stuff there :)
[15:15] <rbasak> I have never understood the difference between platform.* and ubuntu.*. Is this documented anywhere?
[15:15] <stgraber> supported seeds are pretty much used for 3 things, get suff in main, include things in the support declaration, package sets
[15:16] <stgraber> so the main distinction I can think of in the past for ubuntu.*/supported vs platform.*/server-supported was that the former was supported for 3 years during LTS and the latter for 5 years during LTS, but none of that matters now since we don't do the different support length stuff anymore
[15:17] <rbasak> infinity: ^^ you seeded nginx, I think, in bug 1262710? Do we want this in ubuntu.utopic/supported or in platform.utopic/supported-misc-servers?
[15:17] <rbasak> Or shall we just move everything in that section across to platform.utopic/supported-misc-servers now that we have an actual reason to want it there?
[15:18] <rbasak> stgraber: ah, that makes sense, thanks
[15:18] <rbasak> So are we moving the seed or putting an exception in the script?
[15:19] <dobey> infinity: so unity-scope-click is built in the silo now, and marked as tests passing, so will hopefully be published very soon.
[15:19] <dobey> and i'm off to lunch
[15:19] <stgraber> I'd prefer we move that chunk to the right seed
[15:19] <rbasak> stgraber: would you mind committing that change, please? I can't.
[15:19] <stgraber> that way further additions will likely be done at the right place too and we won't have to add even more exceptions to the script :)
[15:19] <rbasak> Sounds good to me :)
[15:22] <stgraber> done
[15:22] <rbasak> Thank you!
[15:23] <rbasak> Does that need the script re-running now?
[15:23] <stgraber> yeah
[15:23] <stgraber> Laney: can you re-run the script?
[15:26] <Laney> Maybe, if --bzr works
[15:26] <Laney> Otherwise it needs to wait for LP
[15:26] <stgraber> Laney: oh, we're only using the tasks for that?
[15:27] <Laney> germinate looks at people.c.c
[15:27] <stgraber> ah, I can refresh people.c.c
[15:27] <Laney> oh wait, already did
[15:27] <Laney> nice
[15:30] <stgraber> Laney: gah, "more than 25 entries", I need to get queuebot to pastebin the output in those cases :)
[15:30] <stgraber> rbasak: can you try again now?
[15:31] <rbasak> stgraber: "ubuntu-upload-permission" still says no.
[15:32] <Laney> that was a previous run
[15:32] <Laney> call it an amusing coincidence
[15:32] <stgraber> yeah, interesting timing :)
[15:36] <infinity> jodh: Only ever one chroot at a time, but they're constantly unpacked, set up, torn down, and deleted.  For every build.
[15:36] <Laney>  actually I was trying to address that request
[15:36] <Laney> you beat me to it by minutes :)
[15:37] <jodh> infinity: could you do another get_state.sh run after a chroot has been spun up and down again? Also, does 'ls -al /proc/1/fd' look sane?
[15:38] <infinity> jodh: It's 16h into a build, there won't be any new chroots until that's done.
[15:39] <jodh> infinity: ok.
[15:39] <infinity> jodh: Your ls shows the usual stdin/stdout/etc, and about 100ish inotify.
[15:39] <infinity> jodh: I'm not sure what qualifies as sane. :)
[15:40] <jodh> infinity: can you pb it?
[15:40] <infinity> jodh: http://paste.ubuntu.com/8054640/
[15:43] <jodh> infinity: confirmed - that's most definitely not sane :)
[15:43] <jodh> infinity: my theory is that you'll get 2 more anon_inode:inotify post chroot tear-down.
[15:44] <infinity> jodh: That machine's done far more than 50 builds since the last reboot.
[15:45] <jodh> infinity: ok. can you 'telinit u' at your leisure and see if that bumps the anon_inode:inotify count by 2?
[15:45] <infinity> jodh: Sure.
[15:46]  * infinity waits a few minutes for that to take.
[15:55] <Laney> rbasak: there
[15:57] <infinity> jodh: Stayed at 125 before and after a telinit u
[15:58] <rbasak> Laney: ubuntu-upload-permission agrees. Thank you, and to stgraber.
[15:59] <infinity> jodh: How many should there generally be?  My laptop has two, one of these recently-rebooted machines has 4.
[15:59] <Laney> yw - enjoy
[16:31] <jodh> infinity: you should only ever have 2.
[16:39] <jodh> infinity: having paused for thought, I've realised that what you're seeing is bug 1338637. This is fixed in 1.13, so I'm afraid you'll have to suffer the slow re-exec's to get to that version :)
[16:48] <infinity> jodh: And when will it get fixed in trusty?
[16:48] <infinity> jodh: We're not upgrading production machines to utopic. :P
[16:49] <infinity> jodh: I think both the telinit-should-block bug and this one should be fixed in trusty before too many more people suffer my pain.
[17:10] <dobey> doko, infinity: ok, fixed unity-scope-click is in archive now
[17:15] <doko> slangasek, ping
[17:19] <infinity> dobey: Thanks.
[17:53] <jodh> infinity: It's a cherry-pick. I'll take a look at this early next week unless another upstart dev wants to jump in.
[18:02] <hallyn> hm, has it always been the case that launchpad told me "newer version available" for a package when newer version was only available in -proposed?
[18:02] <infinity> hallyn: If it didn't, it was a bug, the current behavious is correct.
[18:02] <infinity> hallyn: I assume you mean when a PPA lists a newer version in the distro, yes?
[18:03] <hallyn> right
[18:04] <hallyn> ok, thanks.  just checking.
[20:15] <xnox> rbasak: =( ok.
[20:16] <roadmr> hello folks! I found a couple of problems with the 12.04.5 images, what's a good place to report them/file bugs? (place as in, launchpad project or package)
[20:16] <xnox> roadmr: depends what type of problems.
[20:17] <roadmr> first, if booted on a VM (tested on kvm and virtualbox), I don't get a console
[20:17] <xnox> roadmr: can you describe in short them?
[20:17] <roadmr> no way to access any of the vttys with ctrl+Fx, I have to reset the VM and use recovery mode to get a root prompt
[20:17] <xnox> roadmr: boot what specifically? desktop iso / live cd; server iso / d-i installer; installed system?
[20:18] <roadmr> xnox: right :) sorry, this is 12.04.5 server amd64 image. The install completes correctly, but when trying to use the installed system I get that issue and another one...
[20:18] <xnox> roadmr: I'd say $ ubuntu-bug console-setup - from installed system itself, if you can.
[20:18] <roadmr> xnox: the second issue is that the apt lists seem somehow corrupted: if on this freshly installed system I try apt-get update, I get a lot of checksum mismatch errors and apt-get exits with errors
[20:19] <roadmr> xnox: sure, I can do that (console-setup). I don't mean to give detailed descriptions here, I can provide good steps to reproduce but wanted to know where to file them
[20:19] <xnox> roadmr: that can happen naturally, if e.g. network connection / dns setup is wrong. Can you confirm by changing all sources to use just "archive.ubuntu.com" (no coutry prefix) and see if errors persist?
[20:20] <roadmr> xnox: also, the install/no-console problem was verified by someone else on qemu/kvm, and the apt-get problem verified by the same person on a bare metal installation
[20:20] <xnox> roadmr: if mirror bug -> file against ubuntu-mirrors project. If other checksum error -> file against $ ubuntu-bug apt; and it would be inspected / reassigned from there.
[20:20] <roadmr> xnox: they have no country prefix now :D just archive.ubuntu.com (I told it I was in the US)
[20:21] <roadmr> xnox: ok, I'll start with apt. FWIW, I've reproduced this from Canada, the UK and US west coast, and at different times (yesterday + today) so it doesn't seem like a network issue
[20:21] <roadmr> xnox: thanks for your help (as usual, much appreciated), I'll file them now
[20:35] <arayaq> Hi! I'm getting an error trying to compile the template project for a QML Extension library with a tabbed UI (CMake) on 14.04
[20:37] <arayaq> Nvm, the problem is that you can't have a dash in your project name
[20:37] <arayaq> No idea if it is a bug
[20:45] <dobey> anyone know why the symbols checker would complain about 2 symbols not being in the .symbols file, even though i added them?
[20:46] <infinity> dobey: build log?
[20:46] <infinity> dobey: And symbols file.
[20:46] <infinity> dobey: My guess is the answer is "it wouldn't", but...
[20:48] <dobey> infinity: http://pastebin.ubuntu.com/8057237/
[20:49] <dobey> ironically, in the diff from gensymbols you can see 2 lines above the + that the ::updated() is already there...
[21:24] <xnox> wgrant_: ./copy-package -s utopic --from ubuntu --to ~xnox/ubuntu/scratch hello is very nice.
[21:24] <xnox> wgrant_: apart from having to quote "~xnox/ubuntu/scratch" as otherwise it ends up with error message - AssertionError: No such archive: /home/xnox/ubuntu/scratch
[22:03] <geofft> is anyone working on updating gnome-settings-daemon to a newer upstream version in Utopic?
[22:04] <geofft> slash, is that wanted or is there something that requires it being held at 3.8.x?
[23:23] <Bluefoxicy> bah
[23:23] <Bluefoxicy> lightdm and gdm should have a setting to add priority to the DE
[23:25] <Bluefoxicy> that way X11 can run at -2, lightdm at 0, Gnome-Shell or Unity or XFCE at 1.  Then the DE should have a configuration to spawn all user applications at additional priority i.e. +2 or +5.
[23:25] <Bluefoxicy> then maybe stuff will work when chrome misbehaves
[23:26] <Bluefoxicy> and if not, I can just ^+F1 and log in on a priority-0 terminal, running at higher priority than Chromium at 3.