[16:49] <JoseeAntonioR> mhall119: ping
[17:02] <JoseeAntonioR> mhall119: ping
[17:03] <mhall119> JoseeAntonioR: pong again, sorry internet cut out
[17:04] <JoseeAntonioR> mhall119: no worries :) wanted to know if you wanna do an openweek session so we can get some contributors for the web team, to help develop the loco portal/summit/other projects
[17:15] <mhall119> a generic web development contribution session?
[17:16] <JoseeAntonioR> mhall119: yeah, like saying 'hey, we develop this this and this, this is how you can help us make it better'
[17:17] <mhall119> I could do that
[17:17] <mhall119> daker: cjohnston: ^^ want to make it a group thing and talk about all the various web projects the community is doing?
[17:18] <cjohnston> time is tight this week with whats going on at home
[17:18] <cjohnston> i might could be around depending on when, but i dont know that I have much prep time
[17:18] <mhall119> oh, is open week this week?
[17:18] <JoseeAntonioR> mhall119: erm, yep
[17:18] <mhall119> ph :/
[17:19] <mhall119> not a lot of time to prepare
[17:19] <mhall119> JoseeAntonioR: where's the schedule?
[17:19] <JoseeAntonioR> mhall119: https://wiki.ubuntu.com/UbuntuOpenWeek/raring/Timetable has got it
[17:19] <mhall119> oh geez, it starts tomorrow
[17:20] <mhall119> sorry JoseeAntonioR, I've got meetings already in the available slots
[17:21] <JoseeAntonioR> mhall119: no worries then, thanks anyways


[06:57] <mlankhorst> morning
[07:44] <bryceh> heya mlankhorst
[07:48] <mlankhorst> so judging from desktop chan, french is our official language for 12.10, better get learning :)
[07:52] <jcristau> there is no french cabal
[07:53] <mlankhorst> Perish the thought!
[07:54] <bryceh> heh
[09:11] <mlankhorst> well cleaned up my other patch parts of cross-device reservations too, now time to retest :>
[14:11] <psivaa> Just noticed an issue on mac mini with external display, bug 1066883. Did not appear to have seen it before


[06:47] <Admiral_Chicago> there is a 404 in the link to the Economist in UWN
[06:48] <Burgundavia> bugger
[06:49] <Burgundavia> got it
[06:51] <Admiral_Chicago> cool, i would have fixed it but got busy. thanks
[06:53] <boredandblogging> its fixed
[06:57] <Admiral_Chicago> thanks for fixing that, it was a great article
[04:00] <jenda> beuno: quick I need your birthday for the ticket :)
[04:01] <jenda> not quick enough.
[04:01] <jenda> I'll have to call them again :)
[04:02] <beuno> jenda: 29/09/1983
[04:03] <beuno> was distracted  :p
[04:03] <jenda> :)
[04:03] <jenda> thx
[04:06] <jenda> beuno: 765 CZK
[04:06] <jenda> but we won't sit next to each other unless we trade seats :/
[04:06] <jenda> the bastards told me there's plenty of time for that reservation :)
[04:07] <jenda> Oh well, we'll be way too sleepy to talk anyway :D
[04:09] <beuno> jenda: how long is the trip?
[04:09] <beuno> we can always annoy the person next to us enough by screaming to eachother until they feel like trading
[04:10] <elkbuntu> ooh, organising a trip? sounds fun
[04:10] <jenda> hahaha
[04:10] <jenda> beuno: just about 2 hours, maybe 2.5
[04:11] <jenda> elkbuntu: a tiny Ubuntu meetup in Dresden.
[04:11] <jenda> beuno, jul.iux, pitti and I
[04:11] <elkbuntu> cool
[04:11] <beuno> jenda: I'll have plenty of things to talk about, I got my first package uploaded to debian yesterday!
[04:12] <jenda> beuno: we'll have a day and an evening to talk about it in Prague and more in Dresden ;)
[04:12] <beuno> having Debien Developers all around you rocks  :D
[04:12] <jenda> beuno: since I don't expect juliux to come running to pick us up at 3 AM on the Dresden bus terminal :D
[04:12] <jenda> beuno: and, of course, we'll have until you leave after that
[04:13] <jenda> we'll be coming back even later in the night - 2:15-4:15 AM
[04:14] <beuno> jenda: sounds great, I'll make sure I get there rested
[04:14] <jenda> beuno: good :)
[04:14] <jenda> beuno: and sober, but well trained :D
[04:15] <jenda> nah - I don't think I'll get you too drunk. I'll need someone to carry my books on the way back from Dresden...
[04:16] <beuno> hahah
[04:16] <beuno> jenda: we can mail them back  :p
[04:16] <jenda> hahah :)
[04:16] <jenda> yeah, very economic :)
[04:17] <jenda> It would be about 5 times the price of the return ticket :D
[04:17] <elkbuntu> then you can carry jenda. I believe he is lighter than the books
[04:17] <jenda> elkbuntu: could be :)
[04:17] <beuno> jenda: then maybe we should buy the books a seat too  :p
[04:17] <beuno> hahaha
[04:17] <jenda> the books would have to be 6 kg each :)
[04:17] <beuno> we'll see...
[04:17] <jenda> elkbuntu: even if I was lighter... the books don't have legs, nor can they use them ;)
[04:17] <jenda> s/use mine/
[04:18] <elkbuntu> this was for the situation where the books were mailed
[04:18] <jenda> ah
[04:18] <beuno> right, I'm liking this trip already  :D
[04:18] <jenda> or, beuno can carry the books, and mail me instead.
[04:18] <beuno> hah!
[04:18] <beuno> we'll see what's cheaper  :D
[04:18] <jenda> it'll be cheaper - I'll cash in my ticket, too.
[04:19] <elkbuntu> i'd pay money to see jenda wrapped up with postage affixed
[04:19] <jenda> elkbuntu: how much? :)
[04:19] <beuno> lol, we might even finance some beer with this jenda!
[04:19] <jenda> beuno: :)
[04:20] <beuno> jenda: how much is a beer over there?
[04:20] <jenda> beuno: speaking of which, my backpack won't be empty on our way there either.
[04:20] <jenda> beuno: not much :)
[04:20] <beuno> here it's about 5   :(
[04:20] <jenda> 20 CZK is a downtown price
[04:20] <jenda> hahah
[04:20] <jenda> that's... 10 times as much :D
[04:20] <jenda> I usually get beers for 18
[04:21] <jenda> which is about 1 USD, or 0.7
[04:21] <jenda> right it's not 10 times as much - I thought you said 5
[04:21] <jenda> There are places you can get a beer for 0.5
[04:21] <beuno> jenda: you can count on getting drunk then  :p
[04:21] <jenda> and buying a bottled beer cost 0.3 anywhere
[04:22] <jenda> hehehe :)
[04:22] <jenda> I'm actually a fan of the bottled type - but most people prefer drawn.
[04:23] <beuno> jenda: depends on which kind of beer, but any is fine with me  :D
[04:23] <jenda> Weeell, I sometimes prefer it too - it's more of a social preference than one of taste - the bottled is for drinking at home, while drawn, obviously, in a pub.
[04:24] <jenda> Most Czech brands come both in bottles or in barrels, so it's really up to us ;)
[04:26] <beuno> jenda: great, I'm excited about the trip, start polishing your prague touring skills :D
[04:26] <jenda> beuno: I'll draft a schedule.
[04:27] <jenda> beuno: do you know what a Prague marathon is?
[04:27] <beuno> jenda: nope, last time I was there I was like 6 years old
[04:27] <jenda> it's when you go to a pub, have a beer, go to another pub, have a beer - and if you can make the entire tour as scheduled around Prague, which should be scheduled around 42 chosen pubs...
[04:27] <jenda> ...well, then you're the man ;)
[04:28] <jenda> We won't do that though. I want you alive.
[04:28] <jenda> :)
[04:28] <jenda> (I want me alive too)
[04:28] <beuno> hahaha
[04:28] <beuno> right, I like challenges, but not so much of a fan of alcoholic comas
[04:28] <beuno> al least not abroad
[04:31] <jenda> :)
[04:31] <jenda> Neither am I.
[04:31] <jenda> Home or abroad.
[04:31] <jenda> Actually, the only one I had was abroad :D
[04:32] <jenda> I haven't been able to drink hard alcohol since then.
[04:32] <jenda> it turns my stomach just smelling it - and that's a very good safety precaution :) it's hard getting drunk just on beer.
[04:34] <beuno> jenda: yeap yeap, the body has pretty cool defense mechanisms
[04:35] <jenda> indeed :)
[05:05] <tuxcrafter> hello guys does anybody here know how to create a brochure with the psutils
[09:24] <sits> did anyone see the Mark Shuttleworth interview on Click Online?
[09:26] <Burgundavia> sits: link us up
[09:26] <sits> link coming...
[09:26] <sits> Needs Real Player/Proper Windows Media Player:
[09:27] <sits> http://news.bbc.co.uk/1/hi/programmes/click_online/default.stm
[09:27] <sits> Then Watch Now
[09:27] <sits> Doh!
[09:28] <sits> is the latest UWN already out?
[09:29] <tsmithe> sits, i think "needs" is a bit of an exaggeration ;)
[09:31] <sits> tsmithe: ah well I couldn't use the URI directly
[09:31] <tsmithe> odd
[09:31] <sits> I had to hack up the blob that it pointed to and extract one of the two URIs from that
[09:31] <tsmithe> :s
[09:32] <sits> tsmithe: it worked out of the box for you?
[09:33] <jenda> sits: the latest UWN is always already out :)
[09:33] <tsmithe> well, i'm not sure, after a number of dist-upgrades. but i would expect easy-codec-installation to do it for you..
[09:35] <sits> tsmithe: I believe it's an issue with mrl
[09:35] <tsmithe> i'm not familiar with "mrl"
[09:35] <tsmithe> and i also have to go for a run around the farm
[09:35] <sits> I have the codecs etc. but it's the parsing of the "playlist" that is given that is breaking
[09:35] <tsmithe> so bye :)
[09:35] <tsmithe> sits, ahh ok
[09:35] <sits> jenda: ;)
[09:52] <sits> BTW I wouldn't mind seeing discussion of https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116996 / https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117447 /  https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-June/001059.html in the next UWN...
[09:54] <Burgundavia> sits: feel free to write it
[09:54] <sits> Burgundavia: well I effectively have in the lists.ubuntu.com link :)
[09:56] <sits> but it's been hard to get feedback so I don't know whether some of the stuff I've been posting is right
[09:57] <sits> e.g. the list of affected chipsets in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116996/comments/79
[09:58] <sits> Burgundavia: however if you outline what sort of content you're interested in then I may try and write something up after I finish eating


[10:48] <smartboyhw> zequence, ping ping
[11:11] <zequence> smartboyhw: hi
[11:11] <zequence> just on my way out the door
[11:11] <smartboyhw> zequence, eh:(
[11:11] <zequence> sorry, today Ill be superbusy again
[11:11] <smartboyhw> zequence, :(
[11:11]  * smartboyhw would have asked zequence to promote the Beta 1 release-.-
[11:12] <zequence> I'll have a few free days between Sunday and Thursday
[11:12] <zequence> is there a need?
[11:12] <zequence> We just do testing for it
[11:12] <zequence> smartboyhw: I'll add you as admin to the social channels later, and let you do those announcements
[11:12] <zequence> ok?
[11:13] <zequence> sorry for the situation right now. I really don't have time. We won't suffer. 14.04 will be different in all possible aspects
[11:14] <zequence> bb tomorrow
[11:17] <smartboyhw> zequence, OK
[18:16] <cub> Hi OvenWerks, I messed around with the Brightness and Saturation for the desktop and you could do quite much with only those two. However, on the 13.10 wallpaper if I want to get the light parts darker, the darker parts is affected too. But a cool way to change colour on things. :)
[21:48] <OvenWerks> micahg: bug fixes for beta iso testing: is there anything special I need to do to get them uploaded?
[21:50] <OvenWerks> micahg: ubuntustudio-default-settings has a bugfix. But there is no hurry.


[01:44] <lenky> hihi
[01:44] <lenky> aron有空打包不？
[01:46] <lenky> happyaron,ping
[01:46] <lenky> 代码在这：https://github.com/lenky0401/fcitx-qimpanel/tree/ubuntukylin-13.10
[01:48] <lenky> 有哪里不对 或没有按照打包规范或社区规范写的 都可以改
[01:49] <FJKong> lenky: 在么
[01:50] <lenky> 哦哦
[01:54] <FJKong> 现在皮肤这块还需要改么
[01:54] <lenky> 不知道啊
[01:54] <lenky> 我按照我自己的想法实现的
[01:54] <lenky> 你看看代码 需不需要改
[01:57] <FJKong> 如果是默认皮肤的看这还可以但是我这边好像有点小bug
[01:58] <lenky> 现在功能都是实现在ubuntukylin分支里的 有很多地方可能不合规范 比如没有考虑统一安装路径 那个皮肤的实现也有些问题
[01:59] <lenky> 对四个默认皮肤可以支持 对于其他带很大logo的皮肤 支持还不好 会变形
[01:59] <FJKong> 打开输入法后上面有一个小黑条
[02:00] <lenky> 那是刚启动时吧 会有一个小窗口 但焦点移动一下就没了
[02:01] <lenky> 你在你的机器上跑一下 有问题看能否改咯
[02:01] <FJKong> 不是 我这边出来的情况是不管有没有打开输入法都有黑条
[02:02] <FJKong> 而且就在光标的下面
[02:02] <FJKong> 好的 好的
[02:04] <lenky> 不会吧 我让我同事们试试
[02:08] <FJKong> 我等会再换个桌面试试
[06:11] <happyaron> lenky: 好。
[06:19] <lenky> happyaron,刚commit了一个 修复皮肤右边哪个圈圈变形的问题 现在好一点了
[06:22] <lenky> http://img196.imageshack.us/img196/5417/06vh.png
[06:24] <lenky> 那些安装路径什么该怎么放或有什么问题 你改一下 或你给我说一下 我来改也可以 反正改起来应该也很快
[07:50] <JackYu> smartboyhw, hi
[07:50] <smartboyhw> JackYu, hello
[07:50] <JackYu> smartboyhw, did you get my email?
[07:51] <JackYu> about the testimonials:)
[07:51] <smartboyhw> JackYu, yes. I will write one later (and it seems many people are ping-ing me)
[07:51] <JackYu> smartboyhw, OK, thanks.
[08:05] <ypwong> smartboyhw,
[08:05] <ypwong> ping
[08:05] <smartboyhw> ypwong, OK
[08:05] <smartboyhw> What's the matter?
[08:08] <ypwong> smartboyhw, sorry nothing, unping
[08:08] <smartboyhw> ypwong, heh
[08:08]  * smartboyhw thinks ypwong should train ping-ing skills:p
[08:08] <ypwong> you left school so early
[08:08] <ypwong> yeah, i'm good at pong but not so good at ping :)
[08:09] <smartboyhw> ypwong, My home is close to school, and today we got a bit early leaving school
[08:09] <ypwong> nice
[10:59] <smartboyhw> Ouch, JackYu left, I was about to criticize his wiki page-.-
[11:07] <ypwong> smartboyhw, what's wrong
[11:08] <smartboyhw> ypwong, his wiki page, it isn't necessary to make testimonials from only Ubuntu Members.
[11:08] <smartboyhw> I think he mistaken it for Developer application -.-
[11:08] <ypwong> smartboyhw, well i think for testimonials they can come from any one
[11:09] <smartboyhw> ypwong, but JackYu specified in his wiki page that testimonials are to be from Ubuntu Members only, others can just leave a comment.
[11:09] <smartboyhw> Which, is for developers, but not for a general Ubuntu Member application.
[11:09] <ypwong> smartboyhw, probably he copied it from somewhere?
[11:10] <smartboyhw> ypwong, ah, I got it
[11:10] <ypwong> wow there's a picture
[11:10] <smartboyhw> But huh, that's weird
[11:11] <ypwong> heh
[11:12] <smartboyhw> ypwong, you left a testimonial for JackYu yet?
[11:12] <ypwong> smartboyhw, not yet :( I have to finish my work first
[11:12] <smartboyhw> ypwong, sure
[11:13] <smartboyhw> ypwong, his Membership application is on the 18th
[11:14] <ypwong> smartboyhw, shouldn't be a problem :)
[13:33] <JackYu> smartboyhw, hi, thanks for your testimonial:)
[13:34] <smartboyhw> JackYu, :)


[06:09] <pitti> Noskcaj_: merge flashplugin-nonfree-extrasound> am I touched-it-last? sure, please do
[06:10] <Noskcaj_> pitti, You were the last to look at it. oneric i think
[06:25] <pitti> apachelogger, ScottK: do you mind if I upload kde-workspace to put back the init.d script? (needed for insserv compatibility, it won't actually ever run on Ubuntu)
[06:25] <pitti> for bug 1323274, blocking https://code.launchpad.net/~ubuntu-core-dev/ubuntu/utopic/sysvinit/unreviewed/+merge/219999
[06:39] <dholbach> good morning
[06:39] <pitti> apachelogger, ScottK: well, I'll just do and take the bullets (it's just reverting that particular delta to Debian)
[06:56] <TheMuso> greyback: happy to meet up with you out where the coffee break is held.
[06:57] <greyback> TheMuso: ok, see you there
[07:21] <dholbach> @pilot in
[07:21] <apachelogger> pitti: I'll only mind if you break something, that's my job :P
[07:22] <pitti> apachelogger: hehe; yes, of course
[07:22] <pitti> apachelogger: if it ever finishes building :)
[07:33] <mterry> jjohansen1, is there a bug for those lxc test failures?
[07:36] <jjohansen1> mterry: 1323528
[07:40] <ogra_> xnox, where are you hiding ?
[07:41] <jjohansen1> mterry: btw I am testing and will submit the fix for it soon
[07:41] <mterry> jjohansen1, cool, thanks
[07:42] <Shock> pitti: can you take a look at bug #1247584 and tell me if there's anything else I need to do or I can consider it done?
[07:42] <pitti> Shock: hey! yes, I saw your response yesterday
[07:42] <pitti> Shock: thanks for your patch!
[07:42] <Shock> pitti: sure
[07:42] <pitti> Shock: I probably won't get around it this week (sprint), but it's on my TODO list now
[07:43] <pitti> Shock: so from your POV it's "done"
[07:43] <Shock> pitti: cool, thanks
[07:43] <xnox> ogra_: studio 8 at the moment
[07:43] <xnox> (on the sunset strip)
[07:44] <xnox> wgrant: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.utopic/touch.sources ~ 226 source packages
[07:45] <ogra_> xnox, we need to talk if you are not in a meeting anymore
[07:45] <wgrant> xnox: Plus core, I suppose?
[07:45] <xnox> wgrant: yeah.
[07:46] <wgrant> Right, vaguely manageable.
[07:46] <xnox> wgrant: yeah, i would have thought some of kde ppas are bigger.
[07:47] <wgrant> They're a bit of a problem, but yeah.
[07:51] <cjwatson> doko: Would you mind having a look at the wxwidgets3.0/arm64 build failure?  ICE, I'm seeing something that looks similar in redeclipse/arm64, but am in meetings and haven't had a chance to investigate properly yet
[07:52] <cjwatson> xnox,wgrant: touch inherits from sdk-libs, so I think you need to count that too
[07:53] <pitti> xnox: could you put a quick look at http://paste.ubuntu.com/7527535/ ?
[07:53] <cjwatson> little things like qtbase there
[07:53] <pitti> xnox: in particular, for the "shim" nfs-common upstart job I supposed I should add a "stop on" for maybe runlevels 0 and 6?
[07:54] <cjwatson> So more like ~600 ...
[07:54] <pitti> xnox: stop on runlevel [016] ?
[07:58] <xnox> pitti: no, no stop on needed.
[07:58] <xnox> pitti: let me double check.
[08:00] <xnox> pitti: actually it should be "stop on (stopped idmapd and stopped gssd and stopped statd)" no?
[08:01] <wgrant> cjwatson: That'll be in the top 10, and might end up kicking me into making NMAF suck slightly less, but shouldn't be fatal. Thanks for the details.
[08:01] <pitti> xnox: ah, I think an "or" in that case
[08:01] <pitti> xnox: stop on (stopped idmapd or stopped gssd or stopped statd)
[08:01] <cjwatson> wgrant: ok, sorry to accidentally blindside you
[08:02] <pitti> xnox: cause if either is down, nfs-common is not "fully" running any more
[08:02] <xnox> pitti: ack.
[08:02] <cjwatson> wgrant: I think I tacitly assumed "will probably fit within default quota => not a problem"
[08:02] <wgrant> It's number of packages rather than size of packages.
[08:02] <wgrant> NMAF index generation is unbelievably terrible.
[08:03] <xnox> pitti: i'm ok with that, and that's a good state approximation.
[08:03] <pitti> xnox: ack, thanks; testing now
[08:05] <cjwatson> wgrant: yeah, that's obvious now you say it
[08:05] <cjwatson> hmm.  struggling to think of an alternative, all the same
[08:06] <wgrant> Nah, it's easy to make it not suck.
[08:06] <cjwatson> derived distros obviously wouldn't work, and I don't think we should be creating extra distroseries for vendor-specific RTM projects
[08:06] <wgrant> But if you were looking at more than a couple of thousand packages I would have died :)
[08:06] <cjwatson> yeah, I think it will be impractical to make the PPA build entirely standalone for that reason
[08:06] <zyga> ara: my desktop died
[08:06] <wgrant> Imight get bored on the plane and fix it.
[08:06] <evfool> does anyone know about docs on how to do ubuntu online accounts integration?
[08:06] <cjwatson> (i.e. full germinate-speak depends+build-depends closure)
[08:07] <zyga> ara: I managed to log in to see a stream of kernel errors related to NMI and USB
[08:07] <zyga> ara: I need to have a look at it, maybe the fan is stuck or something
[08:07] <cjwatson> wgrant: benefit of living in .au, lots of plane time to get bored in?
[08:07] <wgrant> I attempted it back in '09, but that was before anybody cared about performance, so it was never acceptable to people who could land it.
[08:07] <wgrant> Indeed.
[08:08] <seb128> evfool, try asking mardy maybe, he can probably point you to the right direction
[08:09] <evfool> thanks seb128, I'll ask mardy
[08:09] <mardy> evfool: hi! There aren't many docs at the moment, but I can hopefully help you :-)
[08:10] <pitti> slangasek: do you have a minute to review http://paste.ubuntu.com/7527609/ ? that's a nontrivial (but not too complicated either) diff for nfs-utils
[08:10] <mardy> evfool: do you want to add support for a new service, or are you developing an application?
[08:10] <evfool> mardy: I have found an html5 tutorial
[08:10] <pitti> slangasek: I tested it in a VM (upgrade, various start/stop), and it works fine here
[08:10] <evfool> mady: would like to add uoa integration for an existing app
[08:10] <evfool> mardy^
[08:13] <mardy> evfool: OK. What application is it? Is it a HTML5 one?
[08:14] <evfool> mardy: that would be straightforward based on the HTML5 tutorial, it's Vala, but C code would also help me
[08:18] <evfool> mardy: just found your signong-glib-google-demo, trying to decipher it :)
[08:19] <mardy> evfool: there's a patch for shotwell (it's written in Vala) to add support for Online Accounts
[08:19] <mardy> evfool: you could do "apt-get source shotwell" to get it
[08:21] <evfool> mardy: found it on launchpad already, in the deb folder, I assume 06_uoa.patch is the thing to look at ;)
[08:21] <mardy> evfool: yep :-)
[08:27] <evfool> mardy: thanks, I'll try some stuff, and will ping you if I get into trouble
[08:36] <doko> cjwatson, arm64 recently has issues with precompiled headers, not reliably reproducible.  as a workaround build without pch. would like to wait until 4.9 is the default and see if this persists
[08:43] <darkxst> dholbach, infinity while your piloting would be nice if you could look at the mega cleanup of g-s-d! seems no one else wants to!
[08:43] <darkxst> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539
[08:46] <zyga> 4~/exit
[08:50] <dholbach> darkxst, I'll have a look, but I could imagine that I won't know enough about it to make a good decision
[08:52] <pete-woods> mardy: hi, I'm trying to add a SSO provider for vimeo
[08:52] <pete-woods> but the process doesn't quite complete
[08:53] <pete-woods> I have logging output from the signon-ui: https://pastebin.canonical.com/110741/
[08:53] <pete-woods> it seems to get most of the way through the process
[08:54] <pete-woods> but the https://wiki.ubuntu.com/?=&code=4ee3705aabf48607fb237a925f9fd68b4a0f2d7a URL looks a bit weird to me
[08:54] <pete-woods> I can provide the provider / service files if that will help
[08:55] <jamesh> jdstrand: hi.  Would you know how to debug why dbus on my laptop doesn't seem to be handling apparmor?
[08:55] <mardy> pete-woods: hi! It's not clear from the logs what's happening; do you get to enter your username and password?
[08:55] <mardy> pete-woods: yes please, so I can try here
[08:55] <pete-woods> mardy: yes, I enter the credentials on the first page, it then does the usual "would you like to authorise this app" stuff
[08:56] <pete-woods> mardy: but then when I click accept it dumps me out with no error
[08:56] <mardy> pete-woods: it actually seems that the process completed successfully, I can see an authentication token in line 89
[08:56] <jamesh> mardy: I passed on your debug tips to pete-woods.  It is handling the authorize workflow, but never converting the access code into a token
[09:00] <cjwatson> doko: this one seems pretty reliable, FWIW ...
[09:00] <doko> cjwatson, ok, will try a local build
[09:01] <cjwatson> doko: I don't see a gcc option to disable precompiled headers - am I missing it?
[09:04] <pitti> cjwatson: would you happen to know why this isn't in -proposed yet? it got uploaded yesterday: https://launchpad.net/ubuntu/+source/autopilot-gtk/1.4+14.10.20140526-0ubuntu1
[09:04] <thomi> pitti: the langing hasn't completed yet
[09:04] <pitti> it seems LP doesn't want to publish it?
[09:04] <thomi> *landing
[09:05] <pitti> thomi: oh wow, you can upload something to Ubuntu and then kind of hold it back in limbo somehow?
[09:05] <thomi> pitti: check silo 19 on the SS
[09:05] <thomi> pitti: it didn't get uploaded to ubuntu
[09:05] <thomi> yet
[09:05] <pitti> ah, so that LP page is just utterly confusing then
[09:06] <thomi> hmmm, yeah, it's odd that LP shows it has been uploaded
[09:06] <cjwatson> pitti: The build was 22 hours old, but it was only very recently copied to -proposed
[09:06] <thomi> surely that doesn't include PPAs?
[09:06] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/autopilot-gtk/+publishinghistory makes it clearer
[09:06] <cjwatson> thomi: Sure it does :)
[09:06] <thomi> oh, ok, cool
[09:06] <cjwatson> The buildd still has to upload builds for PPAs
[09:06] <pitti> cjwatson: aah, that makes much more sense now; thanks!
[09:07] <cjwatson> And indeed in this case it was uploaded by the jenkins bot
[09:07] <mardy> jamesh, pete-woods: the token is there, but somehow after receiving it, the authentication plugin gets an error serverReply : "{"error":"application/vnd.vimeo.auth"}"
[09:07] <cjwatson> You have to get the source into LP somehow at some point
[09:07] <jdstrand> jamesh: I am going to point you at tyhicks
[09:07] <cjwatson> Though you can then copy it around as much as you like later
[09:08] <pitti> cjwatson: yeah, I was confused by "uploaded by ps-jenkins bot 22 hours ago"
[09:08] <cjwatson> Right, that was the original source upload to the PPA
[09:08] <cjwatson> But yeah, I tend to reach for +publishinghistory pretty quickly
[09:08] <cjwatson> Since that's comprehensible :)
[09:08] <jdstrand> jamesh: though, I'm curious what you mean by 'handling apparmor'
[09:09] <jamesh> jdstrand: I'm getting errors when trying to execute org.freedesktop.DBus.GetConnectionAppArmorSecurityContext
[09:09] <jdstrand> jamesh: is this on utopic or trusty?
[09:09] <jamesh> e.g. "dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionAppArmorSecurityContext string::1.1" returns an error
[09:10] <jamesh> jdstrand: utopic.
[09:10] <jdstrand> jamesh: and you said on desktop?
[09:10] <jamesh> that command returns "unconfined" on my phone hardware, and an error on desktop
[09:10] <jdstrand> actually, I don't think tyhicks is needed after all
[09:11] <sarnold> how up-to-date is your utopic desktop? apparmor hasn't been adapted to the changes in the new 3.15.x kernel yet
[09:11] <jdstrand> jamesh: the utopic desktop kernel does not yet have all the apparmor patches (it has what is upstream, not the additional stuff we are in the process of upstreaming)
[09:11] <jamesh> ahh.
[09:11] <jamesh> and the phone has a completely different kernel
[09:11] <jdstrand> jamesh: that coming. if you boot a trusty kernel, that should unblock you
[09:11] <jdstrand> jamesh: yes
[09:12] <jdstrand> s/that/that is/
[09:12] <jamesh> thank you.
[09:13] <jamesh> jdstrand: fyi: we should have the mediascanner QML bindings going through D-Bus shortly.  I'm now working on adding the apparmor hooks to it
[09:13] <jamesh> the next step is to get every client of the mediascanner going through d-bus
[09:15] <jdstrand> jamesh: nice! that sounds great :)
[09:16] <jamesh> jdstrand: I'm a little concerned about encoding security policy directly into the daemon though (in particular, making decisions for particular security context labels)
[09:16] <jdstrand> jamesh: that is a workaround until there is trusted session support
[09:16] <jamesh> okay
[09:17] <jdstrand> jamesh: in mir. that isn't intended to be there forever. we don't now have a way to prompt the user if the access is ok (ie, you can't use trust-store) and we don't want to break the music-app, so we just do this
[09:17] <jdstrand> it is icky, but temporary
[09:18] <doko> cjwatson, it should be in the packaging. configure.in: bk_use_pch=no
[09:18] <doko> but I'll try to reproduce it first
[09:19] <jamesh> jdstrand: I was thinking more about the way media-hub encodes knowledge that an app has access to ~/.local/share/$package and ~/.cache/$package
[09:19] <jamesh> which presumably wouldn't invoke a trust-store dialog
[09:19] <jdstrand> let me look at the code real quick
[09:20] <slangasek> pitti: hmm, so, nfs-utils is a mess.  Are you readding the nfs-common init script because something depends on it?
[09:20] <pitti> slangasek: yes
[09:20] <xnox> slangasek: yeah.
[09:20] <slangasek> pitti: because we need to split this init script for proper systemd integration too, so I'd greatly prefer to move the other direction
[09:20] <slangasek> ah, what depends on it?
[09:21]  * pitti tries to find the pastebin again, hang on
[09:21] <xnox> slangasek: but pitti only created a dummy upstart job (ala mountall.sh)
[09:21] <slangasek> right
[09:21] <slangasek> but IIRC, idmapd may not always start?
[09:21] <slangasek> ditto statd
[09:21] <xnox> slangasek: should it be just or'ed ?
[09:21] <pitti> utopic/etc/init.d/umountnfs.sh:# Should-Stop:       $network $portmap nfs-common
[09:21] <pitti> utopic/etc/init.d/nfs-kernel-server:# Required-Start:    $remote_fs nfs-common $portmap $time
[09:21] <pitti> utopic/etc/init.d/nfs-kernel-server:# Required-Stop:     $remote_fs nfs-common $portmap $time
[09:21] <pitti> slangasek: ^
[09:22] <slangasek> ah, nfs-kernel-server, hah
[09:22] <xnox> slangasek: (sure the dependnecy will fire earlier then.....)
[09:22] <slangasek> so we at least could fix that in one place ;)
[09:22] <pitti> slangasek: so, not that much, but these could still creep in with syncs/merges from other packages, so I thought it'd be cleaner to keep Debian's and shadow it
[09:22] <cjwatson> doko: oh, you meant turn off pch in the gcc build, I thought you meant turn it off in the wxwidgets3.0 build
[09:22] <slangasek> pitti: right, but as nfs-utils comaintainer ;P, I'm planning to move this in the other direction in Debian
[09:22] <jdstrand> jamesh: ok, right. the point of media-hub and mediascanner is that they are trusted helpers. they are purposefully there to enforce access controls beyond the static apparmor policy. since media-hub and mediascanner2 allow access to other files, they need to be careful about how they do so
[09:23] <pitti> slangasek: other direction sounds even better, of course
[09:23] <jamesh> jdstrand: http://bazaar.launchpad.net/~phablet-team/media-hub/trunk/view/head:/src/core/media/player_skeleton.cpp#L153 <- that's the code
[09:23] <pitti> slangasek: do you plan to do that "soon", or can/should we use this to unblock the insserv transition (it
[09:24] <pitti> 's the last affected package)
[09:24] <slangasek> pitti: I was certainly planning on doing it "soon", and think it would be easier if we didn't then have to unpick another Ubuntu-specific upstart job in the process
[09:24] <jamesh> jdstrand: It just seems a bit weird to be repeating these parts of the security policy in each daemon (determining package names based on apparmor contexts, what files those contexts automatically have access to, etc)
[09:24] <jdstrand> jamesh: every trusted helper will be a little different. some, like location service, won't need to have more logic because they don't give out more access
[09:24] <jamesh> because if we change details of the policy, we'd need to go through each of these services and update it
[09:26] <jdstrand> jamesh: most trusted helpers don't have to do this
[09:26] <jamesh> okay
[09:26] <jdstrand> jamesh: and we don't expect the paths to change, cause the specification is using standard XDG directories
[09:26] <pitti> slangasek: so the other option which wouldn't introduce blocking right now is to drop that shim upstart job and just drop the dependency in nfs-kernel-server?
[09:27] <slangasek> pitti, xnox: anyway, I'm not exactly sure which of the components of nfs-common is a prereq for nfs-kernel-server, but each of these is possibly not going to start on boot and could block
[09:27] <slangasek> pitti: I wouldn't want to just drop the dep either
[09:29] <pitti> slangasek: ATM we only have an init.d for nfs-kernel-server and upstart jobs for nfs-"common"; how is that dependency being enforced right now?
[09:31] <doko> cjwatson, no, turn it off in the wxwidgets build
[09:32] <slangasek> pitti: because the nfs-kernel-server init script starts in runlevel 2 and the upstart jobs 'start on local-filesystems'.  If you have both nfs mounts and nfs-kernel-server there's guaranteed ordering, if you don't have nfs mounts there's a race but nfs-common has a head start
[09:32] <pitti> slangasek: ah, ok; so isn't that the same with changing nfs-kernel-server to either drop the nfs-common dep or drop it to should-start?
[09:33] <pitti> slangasek: (to avoid having to clean up nfs-common.conf later on after you do the split)
[09:33] <cjwatson> doko: oh, ok.  let me know if you want me to upload that then
[09:34] <cjwatson> (--disable-precomp-headers apparently)
[09:34] <slangasek> pitti: as long as you're on upstart, yes; will do the wrong thing on systemd, but that's a deeper problem which I suppose we can deal with a little bit later
[09:34] <pitti> slangasek: *nod*
[09:34] <slangasek> hmm, so did you already upload this?
[09:35] <pitti> slangasek: yes, but with block-proposed, so easy to change
[09:35] <slangasek> mmk
[09:37] <pitti> slangasek: so the total delta to what's currently in utopic would just be th drop the LSB header dep of kernel-server
[09:37] <pitti> s/th/to/
[09:37] <pitti> thomi: "Jenkins Fixed - utopic-adt-autopilot-gtk 13" \o/
[09:38] <slangasek> pitti: makes sense
[09:38] <thomi> pitti: virtual high-five!   o/
[09:38] <pitti> slangasek: ack
[09:38] <pitti> thomi: ^5s
[09:38] <thomi> :-/
[09:40] <pitti> thomi: I think that warrants a :-)
[09:40] <thomi> ...
[09:53] <mterry__> ogra_, any objections if I make /var/lib/lightdm (the greeter user's HOME dir) persistent?
[09:53] <mterry__> ogra_, in touch
[09:54] <ogra_> is there much stuff in it ... ?
[09:57] <ogra_> mterry__, (also do we need to wipe it for factory reset ? if so, please tell sergiusens )
[09:57] <mterry__> ogra_, just some typical cruft from being a user (some junk in .cache/.config)
[09:58] <mterry__> ogra_, for factory reset...  hmm  I guess -- I had assumed we just wipe disk and reinstall base system image?
[10:00] <xnox> stgraber: how does system image update
[10:01] <xnox> stgraber: does shutdown?
[10:01] <xnox> (reboot)
[10:04] <doko> cjwatson, please do. is not reproducible, and segfaults on a different file each time
[10:20] <GunnarHj> Hi pitti
[10:20] <pitti> hey GunnarHj
[10:20] <GunnarHj> pitti: Did you see this:
[10:20] <brendand> anyone come across this error before? dpkg-source: error: cannot represent change to trunk/.bzr/repository/packs/9245e3e3055bac62bf0c407a72389cbc.pack: binary file contents changed
[10:20] <GunnarHj> https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html
[10:20] <brendand> why does debuild care about what's in .bzr?
[10:21] <cjwatson> use the exclude option
[10:21] <cjwatson> debuild -S -i -I
[10:21] <stgraber> or call bzr bd if it's that kind of branch
[10:21] <cjwatson> $ grep BUILDPACKAGE .devscripts
[10:21] <cjwatson> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -uc -us"
[10:21] <cjwatson> or that yeah
[10:26] <Wellark> doko: which room are you in?
[10:27] <Wellark> there is something weird going on with gcc -dbg package dependencies
[10:29] <jamesh> jdstrand: thanks for your help.  I've got an MP for mediascanner here: https://code.launchpad.net/~jamesh/mediascanner2/dbus-apparmor/+merge/221058
[11:36] <dholbach> hey seb128 - I'm sure you're busy sprinting, but do you think somebody could take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539? attente seems to have ACKed it already, but I personally can't judge if it should be uploaded or not
[11:36] <seb128> dholbach, go for it
[11:36] <seb128> dholbach, it's basically up to the GNOME remix team and it has been acked by attente
[11:36] <infinity> @pilot out
[11:37] <seb128> +1 on the principle from me, but I didn't do a detailed review
[11:38] <dholbach> @pilot out
[11:38] <dholbach> seb128, we could probably take a look and see what still depends on gnome-settings-daemon
[11:39] <dholbach> seb128, I had to "dpkg -P gnome-settings-daemon gnome-packagekit-session gnome-session ubuntu-system-settings gnome-control-center gnome-packagekit ubuntu-system-settings-online-accounts  account-plugin-ubuntuone  unity-scope-click" - I probably still had it installed from some older installation
[12:08] <ScottK> pitti: That's fine, the only thing is to please commit the changes to our bzr repo.
[12:08] <ScottK> (didn't check if you did already)
[12:09] <mterry__>  sergiusens, talk to me about factory reset when you get a chance
[12:09] <mterry__> sergiusens, on the phone
[12:10] <sergiusens> mterry__: sure, just come by 2c... I have only one meeting today; everything else is adhoc
[12:11] <seb128> dholbach, sorry, I got disconnected, not sure you got my reply (guess so from your upload)
[12:12] <pitti> ScottK: ah, will do
[12:12] <ScottK> pitti: Thanks.
[12:19] <xnox> slangasek: nexus 5 works
[12:19] <xnox> slangasek: bregma is not online =)
[12:30] <pitti> infinity: argh, I just noticed that I didn't bump the copy limits of eglibc, which explains the timeouts
[12:31] <infinity> pitti: Meh, it'll be "fixed" after I merge from Debian anyway.
[12:31] <pitti> infinity: while I'm at it, if I give the VM 4 CPUs, does the build make use of that?
[12:31] <infinity> pitti: Yeahp, the build will happily eat more cored.
[12:31] <infinity> pitti: cores, too.
[12:32] <pitti> infinity: ack, config pushed (with 4 cores)
[12:32] <pitti> infinity: current build cancelled and restarted, I think/hope it'll succeed now
[12:33] <pitti> argh, I thought we already had an override; for that it held up surprisingly well..
[12:39] <pitti> ... or I would if jenkins wouldn't be nasty again
[12:47] <mardy> pete-woods: hi! According to https://developer.vimeo.com/api/authentication, it should be possible to find the authorization header on the application webpage
[12:47] <mardy> pete-woods: could you please tell me the code? I'm generating it according to the instructions, but vimeo stills gives me an error, so maybe I'm doing it wrong
[12:54] <Mirv> hmm, I'm getting chroot error on amd64, i386 and ppc64el builders: https://launchpadlibrarian.net/176409150/buildlog_ubuntu-utopic-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu1~utopic1~test1_CHROOTWAIT.txt.gz
[12:57] <jamesh> jdstrand: the d-bus AppArmor stuff doesn't seem to work in Jenkins builds.  Do you have any suggestions on how to handle that?
[12:58] <jamesh> jdstrand: allowing everything when the AA check fails would work, but sounds like something that could be used in an exploit.
[13:02] <sarnold> jamesh: are they perhaps using the 3.15-ish kernels?
[13:03] <jamesh> sarnold: I don't know.
[13:04] <jamesh> IIRC, it runs the tests in a chroot so I don't know what the host system is
[13:06] <shadeslayer> pitti: re autopkgtests , what happens if a autopkgtest fails? Does it block package migration from proposed to release?
[13:10] <tyhicks> jamesh: can you give me more detail on why you think dbus mediation isn't working with jenkins?
[13:11] <pitti> shadeslayer: if it ever succeeded, i. e. it's a regression, then yes
[13:11] <shadeslayer> aha
[13:11] <pitti> shadeslayer: if it always failed, we consider the test broken and ignore it
[13:12] <shadeslayer> cool, thanks
[13:12] <GunnarHj> pitti: Did you forget about the link I posted?
[13:12] <shadeslayer> pitti: and just so I understand correctly, autopkg tests are run separately from the actual build on launchpad correct?
[13:12] <pitti> shadeslayer: yes
[13:12] <shadeslayer> ack, thanks
[13:12] <pitti> GunnarHj: sorry, probably drowned (sprint/discussions here)
[13:13] <GunnarHj> pitti: https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html
[13:13] <pitti> GunnarHj: yep, got your mail, just didn't find time to respond yet
[13:13] <GunnarHj> pitti: Ok.
[13:14] <GunnarHj> pitti: One thing I wonder about is who is supposed to initiate translation updates. I haven't found any schedule for when things are copied to -proposed for testing.
[13:15] <jamesh> tyhicks: https://jenkins.qa.ubuntu.com/job/mediascanner2-utopic-amd64-ci/19/consoleFull <- right at the bottom one of the erros is "Error getting apparmor context: org.freedesktop.DBus.Error.AppArmorSecurityContextUnknown: Could not determine security context for ':1.1'"
[13:15] <pitti> GunnarHj: there's nobody right now; it used to be dpm, but he works on other stuff now
[13:15] <GunnarHj> pitti: Just as I feared, then.
[13:15] <jamesh> tyhicks: which is the error I was getting locally with the Utopic kernel (I reverted locally to the trusty kernel at jdstrand's suggestion)
[13:29] <infinity> xnox: Where are you?
[13:29] <shadeslayer> looks like something went kaput https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4
[13:29] <infinity> xnox: Making everything in the archive have a versioned upstart dependency seems like exactly the opposite of what we want.
[13:30] <shadeslayer> seems like what I'm facing ^^
[13:30] <infinity> shadeslayer: Oh, fun.
[13:34] <stgraber> xnox: thanks for breaking the archive
[13:46] <tyhicks> jamesh: I suspect that securityfs is not mounted (or bind mounted) in the chroot
[13:47] <tyhicks> jamesh: the apparmor dbus mediation sees that and can't determine if it should enforce rules so, by default, it disables the apparmor checks
[13:48] <tyhicks> (there is an option in the bus config file to not fall open like that, but that's not the issue here...)
[13:48] <tyhicks> jamesh: the only issue is when you're asking for the apparmor confinement context of a given connection
[13:49] <tyhicks> jamesh: IMO, it is currently doing the right thing by returning a DBUS_ERROR_APPARMOR_SECURITY_CONTEXT_UNKNOWN error
[13:50] <tyhicks> jamesh: I think the best fix here would be to get securityfs mounted in the chroot
[13:53] <xnox> infinity: sorry........... =)
[13:59] <tyhicks> jamesh: but... it is completely possible that the jenkins kernel is the 3.15 utopic kernel that doesn't have the necessary apparmor patches
[13:59] <tyhicks> jamesh: I just don't know enough about that environment or how to find more info on it
[14:01] <jamesh> tyhicks: okay, I'll try following up there.  Thanks for the help.
[14:01] <jjohansen1> tyhicks, jamesh: the 3.15 utopic kernel is missing the necessary patches, that will be fixed soon
[14:05] <pitti> xnox: oh, you still want to block sysvinit? kde-workspace went in
[14:06] <dpm> GunnarHj, pitti, exactly. A community member used to help creating the schedule in later times, but he got busy with other stuff too. Here's an example of the release schedule we set up for releases a while ago: https://wiki.ubuntu.com/Translations/NattyLanguagePackReleaseSchedule
[14:08] <GunnarHj> dpm, pitti: Thanks, that's exactly what I had in mind. Would you recommend that we basically copy it for trusty?
[14:11] <pitti> infinity: https://launchpad.net/ubuntu/utopic/+source/systemd/204-10ubuntu5 -> "Broke the world from the new upstart dependency" ?
[14:12] <pitti> infinity: do you have some details on that? I've run this for 2 days now
[14:13] <pitti> or did that interact badly with the dh_installinit upload or something?
[14:16] <infinity> pitti: See the build log for https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4 for instance.
[14:16] <rbasak> What do people use to get the source package name of a binary package? chdist bin2src is crashing on me.
[14:16] <infinity> pitti: Dep loop that triggered an apt bug.
[14:16] <infinity> pitti: But, apt bug notwithstanding, having everything with an upstart job have a dep on upstart is just plain wrong.
[14:17] <infinity> pitti: So, we're moving that lsb init snippet to lsb-base, and moving the dep there instead.
[14:17] <pitti> infinity: ah, perhaps we could turn this into a Breaks: upstart (<<)
[14:17] <infinity> pitti: And rebuilding everything with the upstart dep.
[14:17] <infinity> pitti: We thought about a breaks, but can't quite sort out WHAT would break upstart.
[14:17] <pitti> infinity: ah, even better
[14:18] <pitti> infinity: with breaks: we'd need sourceful changes, so depends: indeed would be better
[14:18] <pitti> infinity: are xnox and you already at it? anything I should do now?
[14:18] <infinity> pitti: stgraber and I are on it.
[14:20] <infinity> pitti: How did you notice the systemd deletion, BTW? :P
[14:20] <infinity> pitti: Oh, I guess you nogticed me copying in the old one.
[14:20] <pitti> infinity: I got a "released to utopic" mail for ubuntu4, and wondered where ubuntu5 went to
[14:23] <diwic> hmm, I thought we were all going to ditch upstart for systemd but now it seems things are going the other way around...
[14:23] <pitti> diwic: how so?
[14:23] <pitti> diwic: it's just a rather long dependency chain
[14:24] <diwic> pitti, you were adding empty upstart scripts and infinity talks about systemd deletion? :-)
[14:24] <pitti> diwic: fixing our packages to comply to Debian init.d/upstart/systemd policy → moving from legacy init.d ordering to insserv → merging sysvinit → adding systemd equivalents to upstart jobs
[14:24] <pitti> diwic: ah, I didn't see the implied :)
[14:25] <pitti> it's kind of weird that we have to fix sysvinit first, but overall that's the path of least resistance/work/delta to Debian
[14:25] <pitti> (in fact it's mostly "remove some Ubuntu delta")
[14:26] <diwic> pitti, okay, looks like you have it all under control then ;-)
[14:27] <pitti> kind of, except for details like breaking all builds (thanks infinity for quick action!)
[14:27] <pitti> diwic: so, let's say we know the path now :)
[14:27] <diwic> pitti, all right then :)
[14:29] <pitti> infinity: I suppose we can retry https://launchpad.net/ubuntu/+source/debhelper/9.20140228ubuntu3/+build/6045112 now :)
[14:30] <shadeslayer> so is the brokenness fixed now?
[14:30] <pitti> shadeslayer: AFAICS, yes
[14:30] <pitti> udev | 204-10ubuntu4   | utopic          | amd64, arm64, armhf, i386, powerpc, ppc64el
[14:30] <pitti> and nothing in -proposed
[14:30] <shadeslayer> hm
[14:30] <pitti> i. e. the apt dependency loop should be gone
[14:31] <pitti> and debhelper is happily installing its build deps now
[14:31] <shadeslayer> rebuilding kdelibs, lets see
[14:31] <shadeslayer> because it doesn't work locally
[14:31] <pitti> shadeslayer: wait
[14:31] <shadeslayer> oh
[14:31] <pitti> https://launchpadlibrarian.net/176413792/buildlog_ubuntu-utopic-i386.debhelper_9.20140228ubuntu3_CHROOTWAIT.txt.gz still failed, hmm
[14:32] <shadeslayer> pitti: http://paste.ubuntu.com/7529745/
[14:32] <dpm> GunnarHj, sorry for the delay. I'd say yes, but let me find you a more recent template than the one for natty
[14:32] <pitti> Unpacking udev (204-10ubuntu5) over (204-10ubuntu1) ...
[14:33] <pitti> shadeslayer: ^ your build log still has the ubuntu5 version which infinity removed
[14:33] <shadeslayer> pitti: yeah, trying to figure out why
[14:33] <pitti> shadeslayer: probably just mirror lag; the LP buildds use ftpmaster.internal
[14:33] <shadeslayer> yeah
[14:33] <shadeslayer> pitti: https://launchpadlibrarian.net/176413830/buildlog_ubuntu-utopic-amd64.kde4libs_4%3A4.13.0-0ubuntu4_CHROOTWAIT.txt.gz  < plymouth issue
[14:33] <pitti> yes, same as debhelper
[14:34] <shadeslayer> yep
[14:34] <dpm> GunnarHj, here's the raring one: https://wiki.ubuntu.com/Translations/RaringRingtail/ReleaseSchedule
[14:35] <GunnarHj> dpm: It says raring in the URL, but it's actually precise. ;)
[14:36] <pitti> probably this:
[14:36] <pitti>  initscripts depends on upstart (>= 1.12.1-0ubuntu6); however:
[14:36] <pitti>   Package upstart is not configured yet.
[14:36] <dpm> GunnarHj, I guess it was copied from Precise and we never actually used that one :)
[14:36] <pitti> thus we need to rebuild the latest sysvinit upload against the reverted debhelper, and need the rebuilt sysvinit to build debhelper; yay loops
[14:37] <GunnarHj> dpm: I see. So there hasn't been any systematic translation updates since 12.04?
[14:40] <dpm> GunnarHj, most probably no. I know we've done some updates, but as you're saying, not systematically
[14:40] <GunnarHj> dpm: Ok. Anyway, thanks for the link. I'll make a proposal for trusty based on it.
[14:41] <dpm> GunnarHj, sounds great, thanks!
[14:42] <shadeslayer> pitti: hah :D
[14:43] <xnox> pitti: sysvinit must depend on new upstart though....
[14:43] <xnox> pitti: if that's bad, we'd need to move the hook elsewhere.
[14:43] <xnox> pitti: sysvinit is currently blocked from migrating.
[14:43] <pitti> xnox: the hook is being moved to lsb-base AFAIUI
[14:43] <pitti> xnox: hm, it did migrate already
[14:43] <pitti> I can't reproduce the upgrade failure in a schroot
[14:44] <Elv1313> I got this while accessing errors.ubuntu.com for a little while http://pastebin.com/2s4ud5rk as an error message, it look as a hack, might not be the brightest idea ever
[14:44] <xnox> pitti: ok, i hread that mentioned, but it was not definitive at the time, i don't think.
[14:44] <xnox> slangasek: infinity: stgraber: what's the current plan for unbreaking & steps that we need to do to land insserv?
[14:45] <xnox> pitti: cause e.g. adding in sysv-rc breaks upstart << (version with hook) was also offered.
[14:45] <xnox> which shouldn't have any side-effects if upstart is not installed to begin with, and triggers the update otherwise.
[14:46] <pitti> infinity, stgraber, xnox: so I'm trying to understand the current failure, did you already reproduce this somehow?
[14:46] <pitti> [-upstart,-] {+upstart (>= 1.12.1-0ubuntu6),+}
[14:46] <pitti> I figure it's somehow related to this change initscripts, but I don't understand why
[14:46] <xnox> pitti: that's manual change in the debdiff.
[14:46] <infinity> pitti: It's actually probably the sysv-rc/initscripts loop, I'm doing some reversions.
[14:47] <infinity> xnox: stgraber and I are sorting this out.
[14:47] <xnox> infinity: ok. thanks.
[14:47] <xnox> pitti: let's wait for inifinity & stgraber to unwind this =)
[14:49] <mdeslaur> infinity, pitti, stgraber, slangasek: are we still having a tech board meeting in an hour?
[14:50] <pitti> mdeslaur: yes, I think so; we can have it IRL, maybe at the nice patio in front of the coffee area?
[14:50] <mdeslaur> pitti: sounds good to me
[14:50] <Laney> is the whole tb here?
[14:51] <pitti> infinity: wow, I didn't know we could do this now (revert ubuntu13 to ubuntu12 in the release)
[14:51] <pitti> Laney: yes
[14:51] <pitti> mdeslaur: and I expect today's meeting to be < 15 mins :)
[14:53] <infinity> pitti: We can't.  You didn't see anything.
[14:54] <pitti> infinity: /me performs self-lobotomy
[14:54] <infinity> pitti: Good job.
[14:54] <infinity> xnox: Was there a reason you decided sysv-rc needed a dep on initscripts?
[14:54] <infinity> xnox: Before I tear that right out again? :P
[14:56] <xnox> infinity: yes, cause insserv in sysv-rc may not be enabled without the update initscripts.
[14:57] <xnox> infinity: initsctipts & sysv-rc can instead both break "upstart (<< magic-version number)" (the version that first introduced the hook)
[14:57] <infinity> xnox: Well, that introduces a dep loop, so won't do what you wanted even if it worked.
[14:57] <xnox> infinity: would the two breaks do what I want?
[14:58] <infinity> xnox: initscripts will depend on the lsb-base where we moved the hook.
[14:58] <xnox> infinity: ok, that works fine then.
[14:58] <infinity> xnox: But what does sysv-rc have to do with it?
[14:58] <xnox> infinity: that mean that initscripts can be upgraded independant of sysv-rc.
[14:59] <pitti> so breaks: then?
[14:59] <infinity> xnox: Right, so sysv-rc breaks initscripts << foo.
[14:59] <infinity> I'll give that a spin.
[14:59] <xnox> infinity: yes.
[15:00] <xnox> (which should result in the same desired final outcome)
[15:01] <xnox> cyphermox: can you take this patch into urfkill http://paste.ubuntu.com/7529928/ ? to potentially remove two races.
[15:03] <cyphermox> xnox: sure
[15:03] <cyphermox> xnox: where did you see these issues?
[15:08] <xnox> cyphermox: this is by inspection, not from real problem.
[15:09] <cyphermox> ok
[15:09] <xnox> cyphermox: awe_ and I were inspecting things trying to find a race, and these are two minor but potential issues.
[15:09] <cyphermox> well, I have them applied here, will include in the next upload
[15:09] <xnox> cyphermox: tah.
[15:09] <zbenjamin> sarnold: any luck yet? :)
[15:09] <cyphermox> I'm testing some other fixes that could correct races
[15:10] <cyphermox> xnox: awe_ should know, I have a package ready to test in my PPA
[15:13] <sarnold> zbenjamin: no, sorry :)
[15:13] <zbenjamin> sarnold: ok thx
[15:14] <zbenjamin> sarnold: would it be different if i would ship gdbserver inside the click package? Or would the ptrace still fail?
[15:16] <zbenjamin> sarnold: not that i want to do that because with fat packages it would be a mess. But would be interesting to know
[15:16] <sarnold> zbenjamin: the ptrace operations should still fail, yeah
[15:17] <sarnold> zbenjamin: probably the 'right' approach would be to create a new child profile for gdb or gdbserver. it might be worth going down that road a little bit to see what's required inside the child profile.
[15:18] <sarnold> zbenjamin: http://wiki.apparmor.net/index.php/QuickProfileLanguage#Child_profiles
[15:19] <zbenjamin> sarnold: that means gdbserver would run unconfined but the click app would not?
[15:20] <sarnold> zbenjamin: well, I got to thinking that perhaps the gdbserver Ux, might actually run the whole thing unconfined.
[15:20] <zbenjamin> ok that would make the whole effort pointless
[15:20] <sarnold> yeah
[15:21] <sarnold> zbenjamin: creating a child profile for gdbserver would let us keep it in a profile and keep the 'main' profile clean -- if we added the needed privileges right to the profile, the program may not behave the same when the debug group is added
[15:22] <zbenjamin> sarnold: true, that sounds good to me.
[15:32] <rbasak> What do people use to get the source package name of a binary package? chdist bin2src is crashing on me.
[15:33] <rbasak> (before I go and write my own grep-dctrl wrapper...)
[15:33] <xnox> rbasak: is it crashing because source has been removed.... ?!
[15:34] <rbasak> xnox: I just filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749504
[15:35] <xnox> rbasak: such package does not exist in debian?! $ rmadison -S apache2-bin -u debian
[15:36] <xnox> rbasak: however, it exists in at least saucy, trusty and utopic.
[15:37] <sarnold> rbasak: I've got an 'lpsrc' shell function: apt-cache showsrc "$*" | grep --color=auto '^Binary: ' | sed -e 's/Binary: //' -e 's/ //g' -e 's/,/\n/g' | sort -u
[15:37] <sarnold> rbasak: it's far from perfect but I can usually spot the source pcakage I need with it..
[15:37] <infinity> xnox: Eh?  It's a binary package.
[15:37] <infinity> xnox: You might be rmadisoning incorrectly. :P
[15:40] <xnox> infinity: oh, rmadisoning against ubuntu and debian is different. =)))) on ubuntu -S is like a modifier (iff source, also print all binaries). Cause against ubuntu "rmadison libc6" & "rmadison -S libc6" for example return the same thing.
[15:40] <infinity> xnox: That would be a bug in the Ubuntu madison.cgi
[15:41] <xnox> infinity: =(
[16:00] <pitti> slangasek, infinity, kees, mdeslaur, stgraber: reminder that TB meeting is in #ubuntu-meeting-2 (collision with server meeting in #u-m)
[16:00] <stgraber> pitti: oh, is that going to be happening every week? we probably should have considered that when doing the doodle :)
[16:01] <pitti> stgraber: well, we already had few enough options without considering meeting channel colissions :)
[16:02] <sarnold> pitti: mdeslaur may have taken the physical meeting suuggestion literally :)
[16:02] <ogra_> slangasek, bug 1323732 for you
[16:02] <sarnold> mdeslaur: #ubuntu-meeting-2
[16:03] <mdeslaur> sarnold: thanks!
[16:04] <jdstrand> jamesh: hey, so I got the MR, I'll look at it when I have a moment
[16:05] <jamesh> jdstrand: thanks.
[16:05] <jdstrand> jamesh: I did want to mention that I was thinking about your question about the policy in the trusted helper, and I remembered that we are introducing the apparmor query interface
[16:05] <jamesh> jdstrand: in case I have more questions, which room are you in this week?
[16:06] <jdstrand> jamesh: we have a bit of it now, but when it is done, we will have libapparmor api such that you can ask 'hey can this process running under this profile access this file?"
[16:06] <jdstrand> jamesh: once we have that, we can clean up mediascanner and media-hub. however, that isn't going to be fixed super soon
[16:06] <jdstrand> jamesh: just fyi
[16:06] <jdstrand> jamesh: I am in 2C when I am not in meeting
[16:06] <jamesh> jdstrand: sounds good.
[16:06] <jdstrand> meetings
[16:07] <tyhicks> jamesh: fyi, I'm in 2C this week, too
[16:08] <mhall119> slangasek: ping
[16:10] <ogra_> hallyn, we see a new cgmanager crash during image tests ... http://ci.ubuntu.com/smokeng/utopic/touch/mako/50:20140527:20140523/8241/click_image_tests/ (scroll to the bottom)
[16:10] <hallyn> "pass rate 100%"  /me doens't know how to interpret that
[16:10] <slangasek> mhall119: hi
[16:11] <hallyn> oh that one
[16:11] <ogra_> hallyn, well, the test itself passes but alongside that .crash file appears
[16:11] <mhall119> slangasek: hey, every track but Platform Dev has at lest one non-Canonical track lead, do you have any recommendations for who in the community (Ubuntu's or Debian's) would be a good candidate for that?
[16:12] <mhall119> I'd very much like to get more community participation in the call for and scheduling of sessions
[16:13] <hallyn> ogra_: there is a new version in utopic-proposed.  i'm hoping that''ll fix that (though no guaarentees)
[16:13] <hallyn> it looks like genuine stack corruption...  hm
[16:13] <hallyn> ogra_: can you run a set of tests with the -proposed version?
[16:13] <slangasek> mhall119: what's "platform dev"?
[16:13] <hallyn> (I assume this is not 100% reliably failing, so it wouldnt guarantee anything, but...)
[16:14] <ogra_> hallyn, well, we'll just wait til it lands then
[16:14] <slangasek> mhall119: has the core track been renamed, or is this something else?
[16:14] <ogra_> hallyn, our nightly automated image build will pick it up anyway
[16:14] <hallyn> ogra_: ok, thanks  (i also need ot sru that to trusty today, though it'll be a tough one to write a testcase for :)
[16:14] <ogra_> :)
[16:15] <ogra_> hallyn, oh, does that also include the fix for mterry__ ?
[16:15] <mhall119> slangasek: it's a combination of foundations, client and server tracks
[16:15] <hallyn> ogra_: yeah that's his in fact
[16:15] <ogra_> yay, thats grat
[16:15] <ogra_> *great too :)
[16:15] <mhall119> slangasek: so basically everything from past vUDS except community and appdev is now "Platform Development"
[16:16] <hallyn> i have a feeling there's another bug which may be responsible for yours - i'm guessing similar to the one mterry__ fixed
[16:16] <hallyn> i.e. due to my mis-use of nih
[16:16] <ogra_> heh, k ... we'll see
[16:16] <slangasek> mhall119: hmm. and where can I see a list of the other tracks (to understand who from the community might relevantly fit under this umbrella, vs. being on a different track)?
[16:17] <mhall119> slangasek: http://summit.ubuntu.com/uos-1406/tracks
[16:17] <mterry__> hallyn, we need lxc/kernel fixes to unblock cgmanager  :(
[16:18] <mhall119> slangasek: anything that's historically  been considered "Ubuntu development" would fall under this track
[16:18] <hallyn> mterry__: hm?
[16:18] <hallyn> why would cgmanager be blocked on lxc?
[16:18] <mterry__> hallyn, cgmanager has been in the proposed queue for days
[16:18] <slangasek> mhall119: ok; off the top of my head, maybe ScottK?
[16:18] <hallyn> mterry__: exactly waht is it blocked on?
[16:18] <mterry__> hallyn, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[16:18] <mterry__> hallyn, lxc's autopkgtest fails
[16:18] <mterry__> hallyn, due to some kernel issues
[16:19] <mhall119> ScottK: would you be interested in being a track lead for Platform Development in the next UDS? It'll be June 10-12, but your main responsibility would be in asking people to propose sessions and getting them approved & scheduled
[16:19] <hallyn> hm there's an open bug for that right?  i guess that should move to the top of my queue then
[16:19] <ogra_> ++
[16:20] <mterry__> hallyn, ogra_, bug 1323528
[16:20] <mterry__> hallyn, ogra_, additionally there was a needed lxc update (but that's sitting in proposed too)
[16:21] <hallyn> mterry__: d'oh.  ok i can't do anything about that one
[16:21] <mterry__> hallyn, yeah  :(  me neither
[16:21] <hallyn> back to packaging netcf then - thanks, ttyl
[16:24] <ogra_> mterry__, you actually can ... pay beers to the kernel team till they agree on fixing it asap
[16:24] <ogra_> beer always works
[16:24] <ogra_> at least on them
[16:25] <mterry__> :)
[16:40] <brendand> ogra_, just remember to do it during happy hour :)
[20:43] <ScottK> mhall119: Sorry. No time in the near term for something like that.
[20:44] <mhall119> ScottK: even just recruiting sessions and approving them?
[20:44] <mhall119> ScottK: anybody else from the Kubuntu devs you think would be good for me to ask?
[20:46] <ScottK> Kubuntu has already had its planning session for the cycle.
[20:47] <ScottK> I think the only thing we really care about is getting moving on Qt5 5.3.
[20:48] <ScottK> mhall119: Even that. I expect to be offline more than on between now and then.
[20:51] <mhall119> ScottK: how about presentation-style sessions like how to get involved
[20:52] <ScottK> Ask Riddell.


[13:30] <bandali> ricotz, hey, ack
[13:37] <bandali> lissyx, for the xdg-desktop-portal side, my colleague James did a bunch more work on it and addressed some feedback from mozilla, and afaik he thinks it's in overall good shape
[13:37] <bandali> for the firefox side, i seem to recall there weren't any code changes requested, but i think some docs work still needs doing
[13:40] <bandali> getting the patches landed is one of my objectives for this new cycle