=== jasox is now known as jasox_afk === jasox_afk is now known as jasox === AlanChicken is now known as AlanBell === jdstrand1 is now known as jdstrand === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ [16:00] hey! [16:00] hello! [16:00] o/ [16:00] ok, let's get this show on the road! [16:01] #startmeeting Ubuntu Friendly meeting [16:01] Meeting started Mon Jan 9 16:01:02 2012 UTC. The chair is roadmr. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. [16:01] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Friendly meeting Meeting | Current topic: [16:01] Hi everyone, welcome to the Ubuntu Friendly meeting! [16:01] First meeting of the year! [16:01] I hope you had a great end-of-year and that this year is awesome for you. [16:01] We're already hard at work on improving Ubuntu Friendly! Today we have the following topics to talk about: [16:02] * Checkbox (Ubuntu Friendly, System Testing) -proposed version status - [16:02] roadmr [16:02] * Fixing papercuts in the test suite - brendand [16:02] * Any Other Business [16:02] As usual, you're welcome to participate, indicate you want to speak by raising your hand (o/). Don't forget to also signal when you're done using .. [16:03] Let's get started with the agenda! [16:03] [TOPIC] Checkbox (Ubuntu Friendly, System Testing) -proposed version status - roadmr === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Friendly meeting Meeting | Current topic: Checkbox (Ubuntu Friendly, System Testing) -proposed version status - roadmr [16:03] hey that's me heheh [16:03] As you know, last year (sounds like a long time ago) we submitted a few bug fixes for checkbox, to be made available as an SRU for Ubuntu 11.10. [16:04] Unfortunately two of those bugs failed verification. We updated our update (so to speak) and I resubmitted the SRU request which should be OK this time around. [16:05] o/ [16:05] Right now we're awaiting a re-updated checkbox in -proposed. Once it's available I'll notify the mailing list and I'd appreciate, once again, your valuable help in verifying that the bugs are fixed as advertised. [16:05] o/ [16:06] all bugs should verify just as they did the last time, except for: [16:06] bug 862322 (this failed the last time around, but should pass in the new SRU) [16:06] Launchpad bug 862322 in checkbox (Ubuntu Oneiric) "bluetooth/detect shouldn't run on a system with no Bluetooth device" [Undecided,Fix committed] https://launchpad.net/bugs/862322 [16:06] bug 877752 (this failed the last time around, and will NOT be included in the new SRU, so can be just ignored this time) [16:06] Launchpad bug 877752 in checkbox (Ubuntu Oneiric) "connect_wireless can unintentionally choose a non-wireless connection to connect to" [Undecided,Fix committed] https://launchpad.net/bugs/877752 [16:07] so that's it for the SRU, I'll let everyone know once the update is in -proposed awaiting testing. Thanks! [16:07] ara, hey! go ahead! [16:07] cr3 was first :D [16:07] why did those bugs fail verification? any lesson to be learned for next time? [16:07] .. [16:07] and I had the same question :D [16:08] cr3: yes, the lesson is to be more careful :P the first failed because I neglected to actually include the fixing code, which happened because I omnibus'd the changelog, and then I forgot to include the actual code fixes [16:09] lesson 1: preferrably merge each change and its changelog together, rather than omnibusing the changelog [16:09] roadmr: backporting across different branch roots using patch is error prone indeed. I blame bzr, not you :) [16:09] the second failed because the fix introduced *another* bug which we didn't catch (just as we didn't catch the original problem ourselves) because the problem doesn't happen in our lab setup [16:09] I blame it on the boogie [16:10] so since the original bug is still in development, we can't SRU those changes- so I had to revert them altogether [16:10] the lesson here is to be very careful in trying to replicate the failing environment to make 100% sure that the fix works - this one looked good at first glance but there was a subtlety in field ordering that caused things to fail [16:10] ara: don't blame it on the sunshine :) [16:10] there :) [16:10] .. [16:11] nice explanation! [16:11] o/ [16:11] bladernr_: go ahead! [16:12] Just thought I'd point out that the second item seems to be a good case for why we need/love community testing... [16:12] that's all... [16:12] :) [16:12] .. [16:12] bladernr_: yep! I'm not entirely sure the community person who reported the bug did verify it, I think he didn't - so we just assumed it worked because the code looked fine [16:13] bladernr_: ideally we'd wait until all the original reporters verify the bugs [16:13] roadmr: that's a common problem with drive-by bug reporting where the community disappears when comes time to reproduce [16:13] bladernr_: but it's not always possible, so once a reasonable time has elapsed, we are somewhat forced to verify ourselves to move things forward [16:13] roadmr: I think this is too common to block bug fixes on being able to reach the community [16:13] right [16:14] which is why we have to be extra diligent in replicating the error conditions [16:14] cr3: yep, well in this case it was bad to "gate" 6 fixes on a 7th one that wasn't getting any attention [16:15] so we just need to be more careful when we don't have community verification (unlike the 0.9.2 SRU where we had a lot of help from Chad Davis) [16:16] anything else on this topic? :) [16:16] OK let's move on then [16:17] [TOPIC] Fixing papercuts in the test suite - brendand === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Friendly meeting Meeting | Current topic: Fixing papercuts in the test suite - brendand [16:17] brendand, you have the stage [16:17] hi [16:18] we'd like to hear from people about problems they have with the ubuntu friendly tests. anything from test failing to changes that would make a test easier to understand are welcome [16:18] you can put your comments on this spreadsheet next to the test name: https://docs.google.com/spreadsheet/ccc?key=0ApQ2JshzVOLydF8waXotcXZueGc3MlB1am1jUEgwTHc [16:19] o/ [16:19] note that the spreadsheet contains a lot of tests not run in ubuntu-friendly [16:19] o/ [16:20] ideally, base your comments on what you see in the precise version of Checkbox, since many changes have been made from Oneiric [16:20] ... [16:21] ara, you're first this time! [16:21] :) [16:21] I was wondering how do we know which items from that list are already being taken care by someone else [16:21] or which ones have been already fixed [16:21] .. [16:22] ara - i guess it might be good to add a column for 'status' [16:23] ... [16:24] * brendand adds one [16:24] my turn.. [16:24] is the spreadsheet open to the public at-large? [16:24] I think so [16:25] well. you need to use the link i just pasted, which i will also send to the mailing list i guess [16:25] if not, would it be wortwhile doing so? perhaps not as directly as just sharing the document with the world, but creating a "public" version that people can comment on via, say, google docs forms (that way we reduce the chance of people messing up the spreadsheet) [16:25] .. [16:25] "anyone who has the link can edit" [16:25] so, you have to attend this meeting to get the link :) [16:26] ok great :) [16:26] anyone else on the test papercuts topic? [16:27] nope? :) let's move on then [16:27] to everyone's favorite topic! [16:27] [TOPIC] AOB - Any other business === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Friendly meeting Meeting | Current topic: AOB - Any other business [16:27] Now's your chance to discuss anything you didn't have time to add to the agenda! any takers? [16:28] o/ [16:28] mlegris: go ahead [16:28] At the end of a testing run, does the button still say next rather then exit? [16:28] I find that rather odd if it is [16:28] .. [16:29] good point, though it doesn't "exit" as such, so something else may be better - "see results" ? [16:29] nm, its say finished :P [16:29] oh ok :) [16:29] that's wrong, it should say "I like turtles" [16:29] or boogie, to be able to blame it on it [16:29] that's more of a l10n concern I think [16:30] export LANGUAGE=cr3 [16:30] heh [16:31] anything else? :) [16:32] "speak now or forever (until next monday) hold your peace" :P [16:32] going once... [16:32] going twice... [16:32] roadmr: trust me, you don't want me to speak... only nonsense comes out :( [16:32] and it's all publicly logged :) [16:33] going thrice... [16:33] gone! [16:33] Well I guess this wraps things up for today. Thanks for attending! please remember to help with the Checkbox verification if you can. And remember the mailing list is open to all your UF-related comments and inquiries. [16:33] thanks roadmr! [16:33] Thanks all! have a good day! [16:33] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [16:33] Meeting ended Mon Jan 9 16:33:47 2012 UTC. [16:33] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-09-16.01.moin.txt [16:34] roadmr: you roxor! === jasox is now known as jasox_study === vibhav_ is now known as vibhav === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ === Quintasan_ is now known as Quintasan === jasox_study is now known as jasox === bladernr_ is now known as bladernr_afk [20:58] #startmeeting Technical Board [20:58] Meeting started Mon Jan 9 20:58:26 2012 UTC. The chair is mdz. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. [20:58] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: [20:58] * stgraber waves [20:58] o/ [20:59] here [20:59] #topic Action review === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: Action review [20:59] * pitti: document brainstorm review activity → carried over [20:59] * kees: perform brainstorm review → carried [20:59] documentation is done [21:00] \o [21:00] o/ [21:00] yeah, holiday distracted me about the brainstorm review :( [21:00] #action kees to perform brainstorm review [21:00] ACTION: kees to perform brainstorm review [21:00] #topic Xubuntu LTS Application (knome) === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: Xubuntu LTS Application (knome) [21:01] knome doesn't seem to be around [21:01] he sent a mail today [21:02] hey [21:02] that would need a list of supported packages, I think [21:02] oh, hello knome! [21:02] https://lists.ubuntu.com/archives/technical-board/2012-January/001160.html [21:02] #link https://lists.ubuntu.com/archives/technical-board/2012-January/001160.html [21:02] mdz: re-added Edubuntu after Kubuntu to the agenda. We haven't voted on it yet as Edubuntu's LTS status depends on Kubuntu's [21:02] as Xubuntu is built out of universe, it's not immediately clear which packages in it are security sensitive [21:03] pasting here since it's short: [21:03] the Xubuntu team has put together an LTS plan proposal for the TB to [21:03] review, and it is as follows: [21:03] * 3-year LTS cycles [21:03] * Milestone image testing i386/amd64 (including point release updates [21:03] post release) [21:03] * Best effort High/Critical bug fixes [21:03] * Best effort security fixes for Xfce related packages [21:03] knome, is there a list of 'Xfce related packages'? [21:04] no, not yet at least afaik [21:04] xubuntu has a packageset: http://people.canonical.com/~stgraber/package_sets/precise/xubuntu [21:04] most desktop-ish packages are probably fairly harmless, but I wonder if there are some libraries which touch/parse HTML or other network data [21:04] tbh, micahg will know about this 10 better than me :) [21:04] What web browser does Xubuntu use by default? [21:05] firefox at the moment [21:05] and thunderbird as mail client [21:05] #link http://people.canonical.com/~stgraber/package_sets/precise/xubuntu [21:05] That would certainly help with security support. [21:05] yeah, and micahg is active in both communities ;) [21:05] (does #link not work, or is it just silent?) [21:05] pidgin stands out as a security-heavy package [21:05] mdz, it's silent :) [21:05] I'm not sure if it's feasible to commit to the entire packageset though [21:05] pidgin is supported by the security team as it's in main [21:06] http://paste.ubuntu.com/798657/ [21:06] that's the list of source packages in Xubuntu that aren't supported in Ubuntu [21:06] (based on germinate output) [21:06] hm, I don't think that's really intended; sounds like we forgot to unseed it since we switched to empathy [21:06] stgraber: that should be the xubuntu packageset :) [21:07] if these packages are going to receive bug fixes and security updates, is it appropriate to move them into main? [21:07] oh, but it's not... [21:07] that would make things simpler [21:07] mdz: no, it wouldn't [21:07] micahg: hehe, yeah, that doesn't always work ;) [21:08] telepathy-haze -> b-deps libpurple-dev [21:08] i suppose "xfce related packages" mostly are meant to mean xfce4-* and thunar-*, maybe tumbler, ristretto, leafpad, gtk2-engines-xfce, garcon <- micahg, am i right? [21:08] parole [21:08] orage [21:08] libxfce* [21:08] https://wiki.ubuntu.com/RecognizedDerivatives doesn't require moving everything to main, so I'm a bit wary of setting that precedent since I know the review process entails a fair amount of work [21:08] gigolo [21:09] how about a Supported: header in Packages? [21:09] that's not too hard [21:09] yeah, I checked the xfce specific packages and they had pretty few CVEs, I'm not sure about the rest, I guess I'd want to check before committing to those packages [21:09] harder than it ought to be, but not desperately bad [21:10] so is the question whether or not it's OK to label Xubuntu an LTS given this level of maintenance? [21:10] (http://bazaar.launchpad.net/+branch/launchpad/files/head:/cronscripts/publishing/maintenance-check.py I think; can't check as it's timing out ...) [21:11] mdz: we have had these for a long time already? [21:11] pitti, I mean for the Xubuntu packages [21:11] so that it's clear to end users what's what [21:11] Any TB decision regarding flavour support lifetime should be accompanied by an LP branch publishing that change in LP [21:11] or followed by, anyway [21:12] knome: How many active developers do you currently have? [21:12] cjwatson, that depends on how you count it, but i'd say 1-3... [21:13] cjwatson, but 1 is how we've maintained xubuntu for the past i can't remember how many releases [21:13] My main concern with any flavour is essentially whether they'll actually be able to sustain the support lifetime in question [21:13] 2 active with upload rights AFAIK, myself and mr_pouit [21:13] Supporting stable releases takes a fair amount of time over and above supporting ongoing development; depending on how much turnover you have in your software stack it doesn't necessarily parallelise well [21:13] cjwatson, the plan has been discussed in the community and we decided/come to the conclusion this is what we can do [21:14] I would add that Xubuntu has supported both 8.04 and 10.04 as LTS releases, with three year lifetimes [21:14] cjwatson, I don't know what assurance we can ask for other than that they solemnly swear it :-) [21:14] Right, but the TB is supposed to do *some* kind of check :) [21:14] What kind of SRU throughput do you have at the moment? [21:15] is it a good argument/assurance if we've did it with less resources for two releases already? :) [21:15] micahg is the one to answer that ^ [21:15] mdz: I realise it's hard to predict the future; I just want to make sure we don't end up in a situation where we advertise n-year support for lots of flavours in a fit of enthusiasm and then don't make it [21:15] charlie-tca: What do you mean by that? Do you mean that you (plural) were continuing to publish SRUs for three years from date of release? [21:15] LTS support in practice mostly means "security updates" and perhaps a point release, right? Or do you actually plan to backport hardware support, etc? [21:15] cjwatson, do we need to differentiate somehow between Canonical-backed LTS and community-backed LTS? [21:16] cjwatson: yes [21:16] mr_pouit has done 5 SRUs since oneiric's release [21:16] mdz: On the whole I would prefer not to as a matter of principle, although there's the elephant in the room of security support === JanC_ is now known as JanC [21:17] the reason why we think it's feasible as Xfce generally only has a handful of CVEs every couple of years [21:17] s/as/is/ [21:18] I don't think we would be doing hardware backports, but security updates, SRU's, and point releases [21:18] * pitti checks abiword history -- doesn't have too many past CVEs [21:18] I don't think there's been much research lately on abiword -- most efforts moved to OOo [21:18] I'm not sure about the rest of the packages in the packageset, I would have to check on those [21:19] damn, I need a way to count SRUs by package set :-) [21:19] cjwatson, I think there's a qualitative difference between the two. an organizational commitment generally stands even if the individuals involved were to disappear [21:19] cjwatson: I just did it by name :)_ [21:19] but I don't feel that strongly about it [21:19] mdz: OTOH individuals often retain enthusiasm when companies decide for political reasons to move on, so it's swings and roundabouts I think [21:20] cjwatson, that would be interesting data - SRUs by package set [21:20] do we have enough information on the table to make a decision about Xubuntu now? [21:21] Just one thing: [21:21] Maybe it's been answered already, but: What's the motivation? [21:22] to keep xubuntu supported for 3 years? [21:22] Has there been a lot of demand for it from the user community? [21:22] Yes. === yofel_ is now known as yofel [21:22] so, for me the packages that stand out are pidgin, abiword, xchat; nontrivial, but on the whole seems manageable; but I still wonder if there is a lot of actual demand for it? [21:22] Or is it simply to be a serious alternative to the "bigger" flavours? [21:22] I think I am reasonably convinced that Xubuntu has a credible history of being a responsible part of the development community and caring about updates as much as many others, at least from my own impressions and the extremely unscientific data samplings I've been able to do [21:22] ...or something entirely different? [21:22] Not having a need for users to download and install 300-500 updates two years down the road because as non-LTS designated, you do not get a point release [21:23] charlie-tca: Is that the key factor or just one in many? [21:23] one [21:23] Ok. [21:24] but a serious one, since users are sometimes downloading as much in updates as the original cd [21:24] that too, and tbh, the non-lts releases have been stable too, so it's not a huge push to go for a longer supported lts too, and we really want to do that [21:24] It probably won't change my vote or anything, I'm just curious what the motivation is. [21:24] Ok. [21:24] That's cool. [21:24] Xubuntu hasn't generally been one for going in for horrifically unstable wobbly software stacks either IME [21:25] it's just logical to go that way really, as we've always done it and it haven't been a problem [21:25] we have other topics to get to: ready to vote? [21:25] which should help ... [21:25] I'm ready to vote. [21:25] aol [21:25] I'm ready too [21:25] yeah, it was worse when it was still using hal a year or so ago, now it should be relatively robust [21:25] pitti, not all things in the world can we fix ;) [21:26] #voters cjwatson pitti stgraber mdz kees soren [21:26] Current voters: cjwatson kees mdz pitti soren stgraber [21:26] #vote Xubuntu LTS 3-year designation [21:26] Please vote on: Xubuntu LTS 3-year designation [21:26] Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) [21:26] mdz: Cool, I didn't know about that feature. [21:26] +1 [21:26] +1 received from soren [21:26] +1 [21:26] +1 received from mdz [21:26] +0 [21:26] +0 received from pitti [21:26] +0 [21:26] +0 received from stgraber [21:26] +1 - it sounds feasible and I think I'm convinced of the Xubuntu team's ability to deliver [21:26] +1 - it sounds feasible and I think I'm convinced of the Xubuntu team's ability to deliver received from cjwatson [21:27] * mdz prods kees [21:27] (And there's been a lot of buzz about Xubuntu lately, especially from people who dislike Unity; I'd like to encourage them to stay within the fold ...) [21:28] for the record, the +0 was because of the somewhat limited set of people dealing with uploads when supporting a different desktop. I'd really love to see more people contributing to packaging and SRUs for Xubuntu [21:28] stgraber: so would I :) [21:28] stgraber, we love you so much as you're willing to help us [21:28] I'm going to assume kees got disconnected or something [21:28] #endvote [21:28] Voting ended on: Xubuntu LTS 3-year designation [21:28] Votes for:3 Votes against:0 Abstentions:2 [21:28] Motion carried [21:29] #topic ARB: Allow for files outside of /opt/extras.ubuntu.com// as long as they are prefixed by "extras-_". This is mostly to fix Unity lenses, the ARB will still require any data and binary to be in /opt/extras.ubuntu.com//. An example would be (for package abc): /usr/share/unity/lenses/music/extras-abc_abcmusicstore.scope (stgraber) === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: ARB: Allow for files outside of /opt/extras.ubuntu.com// as long as they are prefixed by "extras-_". This is mostly to fix Unity le [21:29] thanks! [21:29] #topic ARB: Allow for files outside of /opt/extras.ubuntu.com// as long as they are prefixed by "extras-_". === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: ARB: Allow for files outside of /opt/extras.ubuntu.com// as long as they are prefixed by "extras-_". [21:29] oh, my topic :) [21:29] stgraber, yep :-) [21:29] great :) [21:30] so basically, the ARB has received some Unity lenses to review [21:30] these like desktop apps need some kind of reference outside of /opt [21:30] in order to provide a generic way for the ARB to provide these, I'm proposing that extras-_ prefix so we avoid potential path conflicts [21:30] This kind of reminds me of the various things in the LSB (I think) that have namespaced files in various places for when it isn't practical to have a separate hierarchy [21:30] what do they need specifically? [21:31] as much as possible would remain in /opt/extras.u.c/ [21:31] is it not practical for unity to look for lenses in /opt? [21:31] I think the principle is reasonable but I think it should be up to the Unity people to define the namespace of the files in their directory [21:31] And not to the ARB to pick one [21:31] no, because you'd need gobbing for /opt/extras.ubuntu.com/*/usr/share/unity/*/ [21:31] in general, prefixing files with extra__ looks like a reasonable way to me to limit the chance of file collisions [21:32] and we'd need to SRU that change to supported release (at least 11.10) which could still be considered a new feature [21:32] And then it would be fine to say something like "packages under the purview of the ARB can have files outside /opt where specific policy allows for namespacing to avoid collisions" [21:32] IMHO [21:32] the globbing shouldn't actually be that expensive, though [21:32] cjwatson, +1 [21:32] That is a particularly irritating type of thing to have to glob ... [21:33] cjwatson: I'd be fine with that, sure [21:33] but I'm even inclined to say that we shold modify the existing policy to prefix *.desktop files in /usr, too [21:33] I mean if you look at the syscalls involved [21:33] pitti: agreed [21:33] I'm fine with prefixing the lens descriptions, though (I guess the actual code would live in /opt) [21:33] cjwatson, it doesn't sound too bad to me, but namespacing outside of opt is certainly simpler [21:34] yes, only the lense file would be in /usr, everything else would be in /opt. We just need to confirm with the DX guys what's the easiest, a prefix or a sub-directory (if they scan sub-directories), ... [21:35] mdz: I'm thinking of this as something that might apply to things other than lenses, and trying to keep down the number of moderately expensive lookups across the system - I agree it probably wouldn't have a huge impact in just one case but this feels like a precedent [21:36] stgraber, sounds like a consensus [21:36] good enough? [21:36] yep [21:36] right, and prefixing with extras_src_ seems like a general enough principle for this, unless of course the file name is user visible [21:36] #topic Kubuntu LTS Application (ScottK) === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: Kubuntu LTS Application (ScottK) [21:36] how much patching of packages do you think this'd introduce? [21:37] oh, sorry ajmitch [21:37] e. g. we wouldn't name LibO document templates like that [21:37] Hello. [21:37] This should really be Riddell. [21:38] waiting for previous to finish [21:38] #link https://wiki.kubuntu.org/Kubuntu/12.04/LTS-Proposal [21:38] that's the proposal, we'd like to suggest Kubuntu is an LTS for 5 years [21:38] ajmitch, I imagine not much, only where the program in question can't accommodate the namespacing (restrictions on filenames eg) [21:38] I've got a question about Qtwebkit [21:38] the initial motivation for this was Unity lenses, so for these I'll talk to DX to see how we want to do it, for other similar cases, the ARB will deal with it case by case and if something weird shows up and we aren't sure how to deal with, we'll come back to the TB [21:38] we're a supported product of canonical, have a strong comminity and it's in a good place for upstreams [21:39] * Riddell waits [21:39] stgraber: sounds good [21:39] * ajmitch thinks we're done with the ARB topic now, sorry :) [21:39] stgraber: dbus activation *.service ? (related to lenses) [21:40] pitti: right, these will need to use that exception too, though we'll be extremely careful with anything touching dbus because of potential path conflict on the dbus path [21:41] Riddell, what is upstream's plan for ongoing maintenance of Qt and KDE during this time? [21:41] it seems to me that, similar to firefox, webkit would need a µrelease exception, and corresponding Qtwebkit updates [21:41] you mentioned both are going to see major new versions; does that mean that support for the current versions might be discontinued during the 5-year term? [21:42] pitti: that's true, but we have a problem in that qtwebkit usually only supports the last 2 QT stable releases (or maybe even 1) [21:42] do we have experience with API stability for those? i. e. can we build a three year old KDE browser against a current {,qt}webkit? [21:42] mdz: formal support from upstreams is the same as always [21:42] KDE is does patches for the master and last two releases and Qt does much the same [21:43] of course qt is in ubuntu desktop so it's already 5 years supported [21:43] which is fine for most of the desktop, IMHO [21:43] (GNOME does even less) [21:43] Riddell, cool, thanks [21:43] mdz: bleh, yeah, network back now. +1 from me, fwiw. [21:43] but we do need to find a solution for webkit for 5 years [21:43] pitti: Qt has a policy of not changing API for the Qt 4 series [21:44] Riddell: ah, so while the webkit API might change, qtwebkit would "adapt" it to a stable API? [21:44] webkit is of course used by other (non-KDE) bits as well, so that will introduce some extra porting challenge (as we don't want to break other software in main using webkit) [21:45] pitti: yes, it'll use Qt 4.8 in 12.04 and the API and ABI don't change [21:46] Qt has a copy of webkit in its sources [21:46] qtwebkit and webkitgtk are 2 separate sources [21:46] e. g. software-center, rhythmbox, and ubiquity use webkit as well, so we might need to adapt them to new webkits (i. e. backport ports from the devel release) [21:46] and webkit is embedded in qtwebkit? [21:47] pitti: no, the plan with those is to stay on webkit 1.8 for the life of precise (we can discuss that later) [21:47] *webkitgtk [21:47] micahg: ah, we can? does it get supported for that long? [21:47] same script as before gives me the following for kubuntu: http://paste.ubuntu.com/798698/ === bladernr_afk is now known as bladernr_ [21:48] which interestingly doesn't list qtwebkit [21:48] pitti: I'll be trying to build a conglomerate of people to support it [21:48] note ubuntu one is going to be ported to pyqt I head so that means qtwebkit will be 5 years supported by virtue of ubuntu desktop anyway [21:48] which would indicate something in Ubuntu brings something which brings qtwebkit into Ubuntu [21:48] stgraber: no ubuntu desktop uses qt [21:49] http://paste.ubuntu.com/798698/ looks very incomplete [21:49] stgraber: depends whether you're using the output of something that follows build-depends, which would almost certainly pull in qtwebkit [21:49] you can't build Ubuntu desktop from scratch (e.g. new port) without building qtwebkit along the way [21:49] which is of course not the same as supporting it for users [21:49] Riddell: right, and webkit itself is, too (the qt binding around it is probably less of a security problem) [21:50] the same reason may account for other apparent incompleteness too [21:50] 10 minute warning [21:50] no other questions from me [21:50] Edubuntu is still up next [21:51] I think it's also worth mentioning that we've had very good experiences with KDE updates post-release. We've updated all of KDE twice for oneiric and I'm about to upload the third and last full release to oneiric-proposed. [21:51] It seems like they're doing a good job on preventing regressions as they fix bugs. [21:51] pitti: afaik qtwebkit doesn't plan to release a new version for Qt 4 with an updated webkit [21:51] #vote https://wiki.kubuntu.org/Kubuntu/12.04/LTS-Proposal [21:51] Please vote on: https://wiki.kubuntu.org/Kubuntu/12.04/LTS-Proposal [21:51] Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) [21:51] +1 [21:51] +1 received from pitti [21:51] +1 sounds workable to me [21:51] +1 sounds workable to me received from mdz [21:51] +1 [21:51] +1 received from kees [21:51] cjwatson: that was using all+extra.sources, diffing ubuntu and kubuntu [21:51] +1 [21:51] +1 received from stgraber [21:51] +1 [21:51] +1 received from cjwatson [21:52] stgraber: right, so as I said [21:52] (Oh boy. mvo overhauled maintenance-check but it still needs non-trivial work to support different LTS lifetimes for different flavours.) [21:52] Fortunately he's got a use case to work with then ... [21:52] soren, still here? [21:52] ScottK: I was just going to do it now(ish) [21:52] ;-) [21:52] Sorry, yes. [21:52] +1 [21:52] +1 received from soren [21:53] * micahg still has no idea who's supporting qtwebkit [21:53] Real world, unmaskable interrupt :) [21:53]