[00:01] Hm, that was interesting, experimentally forcing signon-ui so that I could see which uninstallables it created said no new uninstallables and let it in [00:01] I suspect partial-NBS doesn't behave the way I think it does [00:22] cjwatson: testing-ports seems to pick it up. [00:23] cjwatson: although, wait, all those problems exist for primary arches too. [00:23] (p11-kit promoted, BTW, don't bother doing it again) [00:25] ack [00:25] * cjwatson fixes a few more blockages in proposed-migration [00:28] gvfs (1.17.1-0ubuntu1 to 1.17.2-0ubuntu1) [00:28] Maintainer: Ubuntu Developers [00:28] autopkgtest for gvfs 1.17.2-0ubuntu1: FAIL [00:28] Not considered [00:28] woo, progress [00:28] cjwatson: Speaking of partial NBS, we don't actually have a useful report for that, do we? [00:29] (Other than britney blocking migration, potentially) [00:30] I think http://people.canonical.com/~ubuntu-archive/testing/saucy_outdate_all.txt should cover it [00:30] Oh, fair point. [00:30] Along with other stuff [00:31] Just lacks the mind-numbing autopilot of the NBS report. [00:31] DON'T MAKE ME ACTUALLY THINK WHILE READING REPORTS! [00:31] But cantor there looks like partial NBS to me [00:31] (Then again, I didn't even know about the NBS report for ages, and used to always work from outdate) === salem_ is now known as _salem [00:32] Yeahp, that backend does indeed look gone from ppc/arm [00:33] Though, with no changelog mention of same... [00:34] control agrees, though. [00:34] * infinity knocks it out. === RAOF_ is now known as RAOF [01:40] xnox: I think your autopackagetest for python-qt4 is pretty pointless. The more usual problem is sip4 has been updated and python-qt4 hasn't. autopackagetest on python-qt4 doesn't really help. One for sip4 that notices it's got a different API version would be useful. [01:40] xnox: You'll also probably want to merge the new python-qt4 from Debian since it's needed for PyQt5, which I think is wanted in Debian. [01:40] Debian/Ubuntu [01:48] Also, it needs rebuild against the new sip4 again since the API version wasn't set right on the first one. === jono is now known as Guest14995 === Logan_ is now known as Guest48721 === Guest128 is now known as Logan_ === Logan_ is now known as Guest15447 [02:52] Laney, yeah i can reproduce it too with nautilus 3.8 [02:52] not sure about nautilus trunk === Logan__ is now known as Logan_ === 92AAAUIMO is now known as RAOF [04:57] Good morning [06:35] good morning === smb` is now known as smb [07:25] didrocks: ping. as you requested me to file a bug for zeitgeist sponsorship for saucy https://code.launchpad.net/~zeitgeist/zeitgeist/saucy-packaging-0-9-14/+merge/170244 [07:25] here is the full MP (thanks to ricotz) [07:26] hi, are there any plans to turn on "-fstack-protector-strong" in Ubuntu ? [07:26] m4n1sh: excellent! it should appear on the sponsoring list, people getting their patch pilot shift should sponsor it! [07:26] thanks :) [07:26] halfie: happened like 4 years ago [07:26] oh, -strong; not sure [07:26] mdeslaur_: ^ [07:27] pitti, heh ;) [07:27] didrocks: that is great [07:32] mdeslaur_: please could you consider bug 1192367? Seems valid to me - don't we support Lucid on server for another couple of years? puppet was in main then. Although it's a really old version - perhaps it's not vulnerable? [07:32] bug 1192367 in puppet (Ubuntu) "No security release provided in Lucid for CVE-2013-3567" [Undecided,New] https://launchpad.net/bugs/1192367 [08:09] tyhicks: ping [08:12] ScottK,xnox: An autopkgtest in pykde4 would be run whenever sip4 changes (or should, anyway), so it could be used to effectively enforce constraints on sip4's behaviour from the point of view of pykde4 [08:13] ScottK: (I'm still finishing putting the pieces of the proposed-migration work together ... planning to announce it shortly) [08:21] didrocks: So, signon-ui landed, but now we have unbuildable images because qtwebkit-opensource-src is in universe and there's no MIR [08:22] didrocks: Given webkit there is no way I'm going to move that without signoff from security :) [08:22] cjwatson: right, I understand. Is it an new dependency? (or we didn't transition to Qt5 before?) [08:23] the publication was manual if there was any packaging change, not sure why ken acked it without the MIR [08:24] didrocks: AFAIK it's a new dependency [08:24] I know that ken already talked with the security team about qtwebkit, but I'm not on top of latest outcomes [08:25] https://launchpad.net/bugs/1157732 is the MIR bug for other chunks but I don't really see an unambiguous statement there that qtwebkit-opensource-src is OK, and there's no bug task for it [08:25] Launchpad bug 1157732 in ubuntu-ui-toolkit (Ubuntu) "[MIR] circle of friends" [Undecided,Fix committed] [08:26] didrocks: Indeed, signon-ui 0.14-0ubuntu2 was on Qt4 [08:26] Which was the version in the saucy release pocket until last night [08:27] urg :/ [08:27] cjwatson: yeah, it has been acked manually when we were using the next ppa [08:27] I have no good clue of what we can do apart if a revert is possible for now [08:27] and check with ken/jdstrand when they are online [08:27] I think the security team didn't like much having another webkit in main when that was discussed before raring, dunno if that changed since though [08:28] If you're considering a (partial?) revert then please keep a note on https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog [08:28] right, but then PS started to use that as their supported html5 stories, when I told yesterday to them to ensure things can be MIRed before starting dep on it [08:29] cjwatson: do you mind waiting on kenvandine? he would know more if we can revert safely or not [08:30] I don't mind, it just means you owe me a few hours of patience the next time you have a problem that you want me to fix ;-) [08:30] cjwatson: ken owes you if you want to make the count rights :p [08:31] Next time you have a problem *that I didn't cause* that you want me to fix anyway ;-) [08:31] heh, right :-) (well, I'm not sure I rang the bell alarm too much on you for stuff to be fixed right away IIRC) [08:31] I just prefer to ensure that the revert will not create more issues that we didn't know of [08:32] Quite so [08:32] Especially since we did other things to prepare for moving forward [08:32] cjwatson: or can we upload it to -proposed and block it? [08:32] I entirely appreciate it's not a simple revert [08:32] so that it's quicker to take a decision once ken is back [08:33] I think just having the packages ready would be fine [08:33] ok, let me prepare it, just in case [08:33] cjwatson, sorry about the extra work created there, I didn't think to check the new build-depends/depends and the MIR state when Ken pinged about it :/ [08:33] Nor did I in fairness [08:34] we'll figure it out :) still quite stressed about all this extra load on qtwebkit and the push there is in PS to use that as our main html story… [08:35] mardy: hey, you are around! do you know if we revert to the previous signon-ui (0.14) using Qt4, we'll get any issue? ^ [08:36] didrocks, the reason Ken wanted the new version out of proposed is that the old version was broken on the touch image, but I don't know the specific of the breakage [08:36] didrocks, you can't use online account on touch with 0.14, it works with 0.15 though [08:36] seb128: ok, we can still mitigate that with the "armhf" double builds if upstream supports that [08:36] hum, no we can't, ignore me [08:37] (as it's a build-dep, even if we set the armhf binary in universe) [08:37] cjwatson: do you know if it's possible/desirable to have britney making this sanity check as well? [08:41] possible, arguably desirable, but very difficult [08:42] it'd be very significant reengineering of a bit of the code I really don't understand [08:43] ok, let's hope we don't have that much "humman review errors" and let's put that on the count of all the drastic changes we have under way to try paying more attention to it :) [08:44] pitti: Can we have a talk about logind and VTs and such? [08:45] pitti: Or, rather more specifically, do you have any free cycles to do the finangling? [08:48] cjwatson: seb128: ok, at least, old signon-ui still builds, and the g-c-c interface is working after some tests. So, the package is ready once ken is up [08:50] didrocks: So, I'm trying to tear out the remaining bits related to signon on powerpc, but I want to make sure that any binaries I remove won't just come back (uninstallable) on the next build [08:51] cjwatson: they will come back I'm afraid with Qt4 and arch: any, should I list the archs to prevent that? [08:51] This is at higher levels, not in signon-ui [08:52] ah ok, so this won't impact it [08:53] didrocks: hi! can you brief me on the reasons? [08:53] didrocks: ... actually, never mind, in gathering more data for the question I was going to ask you I realised it was moot :-) [08:53] I think, anyway [08:54] didrocks: the latest version should be buildable on Qt4 just fine, anyway [08:54] cjwatson: ok, if you have this list of packages you are removing to put me into the context (I wasn't close to that topic, ken was handling it), FYI signon is building on powerpc: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3315384/+listing-archive-extra [08:54] didrocks: Yeah, I was just looking at that [08:55] didrocks: I think maybe an arch restriction in signon would make sense? [08:55] cjwatson: I think so, I'm digging in why https://launchpad.net/~ubuntu-unity/+archive/daily-build/+files/libsignon-qt5-1_8.52daily13.06.19-0ubuntu1_powerpc.deb is even possible as there is no powerpc Qt5… [08:56] ah maybe that part doesn't use qtscripts [08:56] There is a powerpc Qt5, just not the v8-dependent stuff [08:56] cjwatson: why should we restrict it then? [08:56] Maybe we shouldn't, that's why I'm asking :) [08:56] mardy: ok, I'll try that as well, the issue is that you are depending on qtwebkit and it's in universe, not in main [08:57] I'm trying to work out how to neatly tear out the stuff that depends (recursively) on signon-ui [08:57] mardy: so we can't get it on the iso by default (and as we don't have the old version, we can't even build the iso) [08:57] isn't the other way around? signon-ui dep on signon? /me checks [08:57] And I get to gnome-control-center-signon which depends on libaccount-plugin-generic-oauth and libaccount-plugin-google which depend on signon-plugin-oauth2 which depends on signon-plugin-oauth2 [08:58] ... which depends on signon-ui, I mean [08:58] But there are no build-dependency relationships there so I can't remove those binaries without them coming back on the next build [08:58] didrocks: I'd vote for dual builds, and generate signon-ui-qt4 and signon-ui-qt5, both providing signon-ui (virtual) [08:58] didrocks: but I'm no expert in this stuff, so feel free to ignore me :-) [08:58] (ah, it's a recommends for signond -> signonui) [08:58] RAOF: sorry, in between some appointments, today is a bit crazy [08:59] mardy: won't work, it's a build-dep anyway, so the source would need to be in main [08:59] Right, the Recommends isn't enough to justify removing signond [08:59] RAOF: so the bottom line is, logind needs to grant ACLs to processes which have a $DISPLAY, but don't have a controlling terminal [09:00] RAOF: is that XMir process in a session cgroup at least? [09:00] RAOF: i. e. /proc/pid/cgroup/ has it in a session? if not, it's going to be difficult [09:00] cjwatson: so, we should "just" ensure that gnome-control-center-signon, libaccount-plugin-generic-oauth and libaccount-plugin-google, signon-plugin-oauth2 doesn't build on powerpc? [09:00] RAOF: at any rate, would you mind filing a bug about it with the summary? [09:00] RAOF: I can have a look at it this afternoon in the train [09:01] didrocks: Possibly webaccounts-browser-extension as well [09:12] pitti: Will do. [09:13] roaksoax, kirkland: would you guys mind lurking in #ubuntu-quality so it's easier for smartboyhw and i to talk to you. [09:15] RAOF: can you please include the loginctl output, /proc/pid/{status,cgroup} bits? [09:15] Will do. [09:15] RAOF: or some pointer how to install xmir to test it end to end :) [09:15] RAOF: thanks [09:15] I'll do both :) [09:15] cjwatson: do you think that captures everything? [09:15] https://code.launchpad.net/~didrocks/gnome-control-center-signon/dont-build-powerpc/+merge/170273 [09:15] https://code.launchpad.net/~didrocks/account-plugins/dont-build-powerpc/+merge/170274 [09:15] https://code.launchpad.net/~didrocks/webaccounts-browser-extension/dont-build-powerpc/+merge/170276 [09:20] didrocks: I think so. Consider pre-emptively adding arm64 too [09:20] (On the perhaps optimistic assumption that v8 will work there, I guess ...) [09:20] cjwatson: ok, let's be optimistic, pushing those :) [09:24] cjwatson: ok, done, IIRC, I've handled the case of archs not existing in ubuntu but listed in daily release (at least, the unit test pass ;)), I'll see with next dailies [09:24] mardy: mind having a look and approving those 3 MP? ^ === ckpringle_ is now known as ckpringle === doko_ is now known as doko [09:47] cjwatson: HUD under publish, finally (tests pass and components build)! no more julius* recommends, phew… [09:49] oh, yay [11:03] ScottK: cjwatson: i thought that python-qt4 autopkgtest would be triggered by sip4 uploads, due to sip-api-9.2 dependency. or did I get that wrong? [11:12] pitti: Sorry, everything's being terrible here. I'll get the info and file that logind bug tomorrow. === MacSlow is now known as MacSlow|lunch [11:41] rbasak: puppet isn't on the list of packages we still support for lucid: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/lucid-supported.txt [11:41] mdeslaur_: I understand that, but I think there may be a problem with that list. [11:41] rbasak: even if it were, it's so old, that it's pretty much impossible to fix the few latest security issues, as upstream has rewritten a whole lot of the code [11:43] mdeslaur_: I understand that it may not be possible, or may be hard. But that specific issue aside, I'm confused as to our support policy for Lucid on Server. AIUI, it's supported, and puppet was seeded, so should be on your list. So the bug reporter seems to have a valid point. Have I got that part wrong? Why does puppet not appear on your list? [11:43] rbasak: I suggest using the package upstream provides [11:43] rbasak: I does't appear on our list because it was deemed one of the packages that we couldn't possibly support for 5 years [11:44] Was that decision published anywhere that I can point the bug reporter to? [11:44] xnox: It should do. [11:44] xnox: But that's all very new and unannounced and I can forgive developers for not being aware of it :-) [11:45] ok. [11:46] mdeslaur_: so the policy is that it is supported, but puppet is an exception? Are the exceptions documented anywhere, and are there any more? [11:48] rbasak: that list is the authoritative source, as used by the security team. Whatever is not on the list is no longer supported. [11:49] mdeslaur_: OK, thanks. It sounds like there's a disconnect between the security team's authoritative source and what we communicate with the outside world. I think that's probably more of an issue on the Server side, so I'll take that up there. Thanks for explaining this to me. [11:51] rbasak: is there a place where this is communicated? [11:51] rbasak: well, there are plenty of corner cases like that. hence the push/desire to have archive-reorganisation and flexibly define what's supported, security-support only, and in main only due to build-depends. [11:51] xnox: +1 [11:51] mdeslaur_: everywhere. We say that Server has 5 year LTS for Lucid. [11:51] rbasak: I'll see if I can add a link to wiki.ubuntu.com to clarify where the authoritative list is [11:52] rbasak: yes, the list contains server packages [11:52] mdeslaur_: I appreciate that technically we need to work from an authoritative list. But what we communicate is that it has 5 year support, period. And that doesn't hold true if we have exceptions. [11:53] rbasak: As I said, I'll add the list to the wiki [11:53] rbasak: even if I added puppet back to the list, it's unfixable [11:54] thankfully we won't have this problem with precise, as it's 5 years across the board [11:55] mdeslaur_: I feel that 1) in every single place we claim 5 year support, we should make it clear that some "server" packages aren't included, and list them (so a diff against the seed, rather than a list of what is supported), and 2) for where something is unfixable but not in that published list, that this can happen of course, but we should declare and justify this in the security announcement. [11:56] rbasak: ok, it's wiki, feel free to modify as you see fit [11:59] xnox: Could be. Sip-api-10.0 is in saucy-proposed now, so if it was going to be, it would have. [12:00] ScottK: i don't see python-qt4 adt job in jenkins at all.... either it's not been picked up yet or i added it wrong. [12:09] Hmm [12:09] jibel: doesn't look like the reverse-dep handling is working? [12:09] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sip4 should at least mention a pykde4 job === greyback is now known as greyback|lunch [12:11] cjwatson, looking [12:12] could some sru move mesa from raring-proposed to -updates? [12:12] jibel: ah, I wonder if it doesn't deal with virtual packages? [12:13] jibel: the dep in pykde4 is on sip-api-9.2 [12:13] mlankhorst: I'd normally wait for it to age 7 days, so tomorrow according to http://people.canonical.com/~ubuntu-archive/pending-sru.html [12:14] cjwatson: yeah but it's also been in saucy for a while [12:14] sure, but that's the baseline state for SRUs [12:14] or at least is supposed to be [12:15] so, put another way, I can do it but you'll need to explain why I need to waive the waiting period :) [12:16] I want to upload a fix for https://bugs.launchpad.net/ubuntu/+source/mesa-lts-raring/+bug/1175533 [12:16] Launchpad bug 1175533 in linux (Ubuntu Quantal) "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Critical,New] === bigon_ is now known as bigon [12:20] cjwatson: pykde4 doesn't have autopkgtest?! but python-qt4 does. https://launchpadlibrarian.net/142758139/python-qt4_4.10.1-1ubuntu2.dsc unless I misspelled it somehow. But yeah the dep is on a virtual package. Could check reverse build-deps as well, since that has "real" package. [12:21] jibel: tells me that britney should have had requested test result for python-qt4, back when it was initially uploaded with added autopkgtest. but that didn't happen? [12:23] halfie: we're considering it, but need to evaluate it properly. We're pretty busy with app confinement at the moment, so it definitely won't be soon. [12:26] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur_ [12:26] xnox, it might be a problem with handling of virtual packages in rdep resolution, that's what i'm verifying [12:28] xnox: Oh, well, OK. Either way. [12:34] mdeslaur_, cool, what exactly is this app confinement thing? is it related to selinux and mac stuff? [12:36] halfie: it's related to confining apps with apparmor: https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement [12:43] mdeslaur_, ah I see, is apparmor ubuntu only or have other distributions adopted it. (I know Fedora doesn't use it?). [12:44] halfie: suse uses it, and it's available in a whole bunch of other distros, including debian, gentoo, arch, etc. [12:44] mdeslaur_, cool, I am working on doing some benchmarking on this new strong stack protector patch. [12:45] halfie: care to join #ubuntu-hardened if you want to talk about security? [12:45] mdeslaur_, sure === MacSlow|lunch is now known as MacSlow === dholbach_ is now known as dholbach === _salem is now known as salem_ === wedgwood_away is now known as wedgwood [12:57] cjwatson, is there a log of the requests submitted by britney? I generated a request file on lillypilly and see this line: [12:58] "python-qt4 4.10.1-1ubuntu2 NEW python-qt4 4.10.1-1ubuntu2" which means that python-qt4 will be tested because 4.10.1-1ubuntu2 has been uploaded, but I do not see any request on jenkins side, hence no job. [13:06] is there someone who can point me towards a project / team that would teach me some stuff of linux software development? [13:10] jibel: It should spit out a line with the substring "Requested autopkgtest" in its own log (~/proposed-migration/log/$date/$time.log) [13:10] But apparently isn't doing so ... [13:10] I mean not for this one at least [13:10] ok, that's the location I checked [13:10] doko: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-android-builds-revisited ... the two work items for 13.05 in there are done? [13:11] I didn't make it log all packages it was requesting because there was a lot of verbosity there [13:11] Since it basically re-requests all packages that are valid candidates and lets adt-britney sort it out [13:12] asac, yes, but afaik ogra_ doesn't use these yet, so we don't have any feedback, if these actually work [13:12] doko: what did you do for validating? [13:12] doko, xnox took over the android packaging [13:12] doko: asac: Ogra and I are in progress of verifying that the said toolchain produces binaries that do run. [13:12] please set your work items to done and add work items for ogra to test and ack that they work :) [13:12] right [13:12] if you want him to do something [13:12] (at least that feels like the obvious way to go) [13:13] asac, i'm fully out of that spec apart from lending a hand [13:13] ogra_: you are the owner [13:13] jibel: I'll attack it with pdb, I guess [13:13] so you are responsible that this happens [13:13] (well, i might keep the "schedule a discussion for 14.04) [13:13] through talking and escalation etc. in case you dont do engineering work :) [13:13] and helping [13:14] ogra_: doko: asac: updated workitems. [13:14] cool [13:14] asac, right ... no need for me to kick any butts atm ... it all goes smoothly forward [13:14] xnox: thanks a bunch [13:14] ogra_: the work items were not properly cleared up at end of 13.05 :) [13:14] and xnox didnt know about the blueprint until a few mins ago [13:14] so yes, you just need to kick your own butt :) [13:14] lol [13:15] ascteh WIs arent done yet [13:15] what? [13:16] never seen ascteh :) [13:16] there is no bionic in the archive yet [13:16] yeah, my tab key messed it up apparently :) [13:16] are there any devs that can mentor me into learning how to develop for the ubuntu project? === mmrazik is now known as mmrazik|afk [13:17] ogra_: ok, but bionic is on track? [13:17] it is in a PPA [13:17] i think xnox is on getting it into the archive once we know it produces usable binaries [13:17] (which we are in the middle of) [13:17] mlankhorst: mesa/raring released now [13:18] thanks [13:18] pianogmx: Probably best to read through https://wiki.ubuntu.com/ContributeToUbuntu, chase links for things you're interested in, and then ask questions about specific things that confuse you [13:18] (one of those links is https://wiki.ubuntu.com/UbuntuDevelopment which may be more specifically relevant) === greyback|lunch is now known as greyback [13:35] jibel: The file given to adt-britney request includes the line "sip4 4.14.7-2" (in full: http://paste.ubuntu.com/5780463/). The output contains only headers. [13:35] jibel: The logging output includes "2013-06-19 13:34:18,563 WARNING "The cache has no package named 'sip-api-9.2'"", which seems possibly relevant [13:38] hey folks! A code reorganization in my project (checkbox) means that the debian directory is not in the top level of the source branch (it's under checkbox-legacy). Can this be uploaded to lp:ubuntu/checkbox? are specifications for source branches documented somewhere? FWIW I can generate and upload the source packages from that subdir just fine === mmrazik|afk is now known as mmrazik [13:46] roadmr: I don't know if it's documented but that would very definitely violate my expectations of lp:ubuntu/foo. If you're doing that then I think you should use some other branch outside the lp:ubuntu/ namespace, and consign lp:ubuntu/checkbox to the auto-importer. [13:47] Part of the point of lp:ubuntu/foo was for it to be roughly the same shape for every package. [13:47] If you tried to push that to lp:ubuntu/foo I would expect the importer to blow up in interesting ways and/or overwrite your branch. === ckpringle_ is now known as ckpringle [14:01] cjwatson: ok, that makes sense, but I wanted to check first === salem_ is now known as _salem [14:33] cjwatson, there are 2 issues in adt-britney 1) virtual packages are not considered, 2) a logical error when matching the list dependencies in the request file to the list of packages with tests. I'm on a fix for both [14:33] Righto, sounds good, thanks [14:33] (1 causes the warning in the log) === tkamppeter_ is now known as tkamppeter === ckpringle_ is now known as ckpringle [14:38] xnox: Would you please figure out if we should keep your python-qt4 autopackagetest or not as we need to do a merge from Debian. [14:39] ScottK: i'll keep it for now, and will deal with merging python-qt4 in a moment. [14:39] xnox: Thanks. [14:41] What does TIL actually stand for? [14:44] rbasak: "Touched It Last" [14:45] as in "Sucker! You TIL!!!!" [14:54] barry, just to mention it here ... cross-building the base system was a goal for raring and is a goal for saucy. please don't drop any cross-build support when merging things from debian [14:56] doko: i'm not going to drop it, but i just want to express caution. until debian supports it, we will fall increasingly behind unless we have enough manpower to do more manual syncs. i guess we'll see if that's a real problem or not [14:57] Debian's been taking quite a few cross-building patches [14:57] IME [14:57] In fact we're getting near the point where in some cases I'd consider NMUing for them [14:59] I might go on a delayed-NMU spree this weekend :) [15:02] cjwatson: this came up with me wanting to sync zope.interface. the delta we carry is that we b-d on python{,3}-all-{dev,dbg}:any. if we do more of these, and can't get those changes back into debian, then we may find ourselves getting increasingly behind debian, which i really want to avoid. autosyncs ftw! [15:04] barry, that's life. being able to cross-build is needed for us [15:05] cjwatson: if/when we *can* get those changes into debian, then i will be happy again [15:05] Oh, yeah, the :any bit is a bit unfortunate; I was hoping to talk with buildd maintainers at or before debconf about that [15:05] It will be sorted out eventually [15:06] cjwatson: cool, thanks. [15:06] btw, where does debian policy state that shared libs have to be installed without x permission? [15:07] doko: 8.1 [15:08] It's a "should not", and the rationale is because it usually doesn't work; I think it would be reasonable to make exceptions for cases where the library authors have gone to special lengths to make it work (e.g. ld.so) [15:09] cjwatson, ok. that was the thing that did break lto in 4.8 [15:09] searching only for files with the x bit set [15:09] you certainly mustn't expect *all* shared libraries to be installed executable - that would be an unreasonable amount of work to change, if nothing else [15:10] didrocks: I jump out now for practice, I'll be back later when I'm back - I'll chase down robru then ;) [15:10] if something thinks all shared libraries should be executable then it's just wrong :) [15:10] sil2100: ok, thanks! === dholbach_ is now known as dholbach [15:30] didrocks: Any decision on the signon-ui vs. qtwebkit-opensource-src deathmatch? [15:31] cjwatson, it's being worked, kenvandine opened a MIR bug and jdstrand will comment soon [15:31] cjwatson: from what I heard kenvandine and jdstrand agreed on promoting qtwebkit for now [15:31] so basically, no revert [15:31] This is qtwebkit for Qt5? [15:31] cjwatson, https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567 [15:31] OK, I didn't see the MIR bug on component-mismatches so I guess it's recent [15:31] Launchpad bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New] [15:31] ScottK: yeah [15:32] Oh, the MIR team isn't subscribed [15:32] the MIR is going to be temporary most likely [15:32] * jdstrand will be commenting in the bug soon [15:32] cjwatson, jdstrand said he wanted to comment and talk the MIR team when he was done with meetings [15:32] kenvandine: You have to subscribe ubuntu-mir to MIR bugs or else they aren't visible in component-mismatches [15:32] FWIW [15:32] * ScottK isn't sure how QtWebKit for Qt5 will work in the long run with needing to support both upstream and Ubuntu APIs in the archive, but that's, at least, not an immediate problem. [15:33] I found it encouraging that the intent expressed in the bug was to have it in sync with Debian [15:35] cjwatson, whoops, was focused on security and forgot that [15:36] cjwatson, that was the plan for the whole qt5 stack [15:50] tyhicks: ping [15:50] hey mardy [15:50] tyhicks: hi, I wanted to ask you about the apparmor-dbus stuff [15:50] (for online accounts) [15:50] sure [15:50] tyhicks: I see that the apparmor team has a dbus-dev PPA [15:50] yes [15:51] tyhicks: should I use that? [15:51] mardy: Yeah, you could use it. [15:52] mardy: I had hoped that all of the changes would be in the archive by now, but we've got a few more things to wrap up [15:52] tyhicks: np === davidcalle_ is now known as davidcalle [15:53] tyhicks: what method should I call to check if the peer has certain permissions? [15:53] mardy: I'm trying to remember what exactly you need for online accounts [15:53] (or to find out the security context of the peer) [15:53] right, I was thinking that you only needed the label of the peer [15:54] tyhicks: basically, the one which creates the account sets the ACL, and then I have to check against it when someone wants to authenticate [15:54] yeah [15:55] mardy: So you would just call org.freedesktop.DBus.GetConnectionAppArmorSecurityContext [15:55] mardy: it takes a string which is the peer connection name and returns a string which is the label of the process [15:58] cjwatson: hey [15:58] mdeslaur_: aha. Thanks :) [15:58] cjwatson: I have a question about what ubuntu branches are for, for example, lp:ubuntu/checkbox [15:59] they are created from the uploaded source packages [15:59] ogra_: so we never have to touch them? [15:59] They're supposed to be a uniform representation of source package history in bzr [15:59] ogra_: or can the reverse also happen? [16:00] You *can* commit to them directly, but if you prefer to manage your package VCS some other incompatible way, you can do so, just don't put it in that namespace [16:00] cjwatson: okay [16:00] cjwatson: so as a packager [16:00] For example, you could use lp:checkbox for upstream development and keep that separate [16:00] cjwatson: I just keep uploading my source packages [16:00] cjwatson: and everything ends up being added to lp:ubuntu/$package [16:01] cjwatson: but I don't care about that and it's not helping me in any way, just people that might need to repackage it for example? [16:01] Yeah, I mean, once you go into auto-import lp:ubuntu/checkbox will probably become rather less useful because it won't be mergeable [16:01] But you can just ignore it if it doesn't fit your workflow [16:01] cjwatson: I wonder how it could help us though [16:01] * ogra_ uses these trees just to pull from usually ... [16:01] cjwatson: so I'm trying to understand the concept [16:01] The goal was to make it work for everyone, but there's only limited attention for it at the moment so I think you should not stress about it [16:01] cjwatson: how do we 'go into auto-import'? [16:01] I certainly have a number of packages where I ignore it [16:02] zyga: Upload something that doesn't match the latest tag on the branch [16:02] cjwatson: I see [16:02] cjwatson: (something == source package), right [16:02] That's the only thing you can upload (to the archive) [16:02] right, just double checking I understand correctly [16:03] tyhicks: thanks! does it return the same string that would be returned by the aa_getcon() family? [16:03] cjwatson: if we wanted to use the feature directly, could we stop uploading source packages? [16:03] mardy: yes [16:04] tyhicks: we have the long-term plan of migrating to a dbus p2p connection, so it may be that at some point we'll switch to getting the context from the fd of the peer [16:04] tyhicks: great, then there won't be any problems [16:05] mardy: That's where the context is coming from [16:06] mardy: When a DBus connection is made, I do a aa_getpeercon() call on the socket fd and then store that on the DBus connection [16:06] zyga: No [16:06] cjwatson: ok [16:06] zyga: The project never got that far [16:07] cjwatson: so I guess that's all I need for now, many thanks, that does clear stuff up for us === mmrazik is now known as mmrazik|afk [16:18] hmm lintian is giving me postrm-does-not-call-updaterc.d-for-init.d-script [16:18] evilissimo: did you use dh_installinit ? [16:18] yeah [16:18] actually it's automatically used [16:18] debian/packagename.upstart is present [16:19] Known when dh_installinit is running in Ubuntu mode; ignore it [16:19] ah, ok. [16:19] cjwatson: so I should just ignore this one? [16:19] Yes [16:20] k [16:21] $ lintian openssh-server_6.2p2-4_amd64.deb [16:21] E: openssh-server: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/ssh [16:21] ^- you're in reasonable company [16:21] of course check that your package is actually starting the upstart job correctly [16:24] Perhaps the Ubuntu-patched dh_installinit should also install an override? [16:37] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === _salem is now known as salem_ [16:42] cjwatson: hey, sorry to keep pestering with this. So for checkbox, all I would need is to dput a source package, if that doesn't match a tag in lp:ubuntu then the auto-importer takes over? and I don't have to do or upload anything else? [16:42] (just want to triple-check so I don't mess things up) [16:47] cjwatson: I've sent you an updated bundle for parted including the fix you uploaded the other day, and two more I've added === ryanakca_ is now known as ryanakca [17:01] roadmr: To repeat: if your VCS layout no longer matches that of lp:ubuntu/checkbox, then just push it somewhere else, forget about lp:ubuntu/checkbox, and upload source packages [17:01] psusi: Thanks, sorry for being slow about this - I'll try to get to it this weekend [17:01] cjwatson: ok, gotcha. Thanks so much! === LordOfTime is now known as LordOfTime|EC2 [18:46] Are ddebs enabled for ports.ubuntu.com? === dpm is now known as dpm-afk [18:52] mterry: Yes. [18:52] mterry: ddebs.ubuntu.com hosts all arches. [18:54] infinity, oh, I looked in the wrong place then, thanks [18:57] infinity, http://ddebs.ubuntu.com/dists/saucy/main/ seems short [19:01] mterry: Indeed it does. [19:01] pitti_: No ports indices on ddebs? Que pasa? [19:03] mterry: Most of the right files should be there (other than things pitti purged when he was low on disk space :/ ), but indeed, he doesn't seem to be generating indices... [19:11] I'm writing a program and I was thinking of licensing it under the WTFPL just because that sort of reflects my style (I'm not trying to be Stallman here). However, in the future if I'm looking for a programming job I'd like to be able to point to it and the rest of my projects as examples. Would having the WTFPL in there be a strike against my "professional image" in the eyes of potential... [19:11] ...employers or would they not care? [19:23] infinity: say, back in quantal I had asked you to carry some eglibc patch... but I can't find any record of a bug or anything for it. === kees_ is now known as kees [19:24] kees: Was it the patch(es) you uploaded for? [19:24] I'm trying to find it... [19:25] 2.15-0ubuntu15 [19:25] yeah, that's the one [19:25] but that patch is missing now? [19:25] https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu15 [19:25] Is it? [19:25] Oh! it's in the ubuntu/ directory, not the any/ directory [19:25]