=== Riddelll is now known as Riddell === duanedes1gn is now known as duanedesign === fader_ is now known as fader === yofel_ is now known as yofel === brendand_ is now known as brendand [15:30] hello! === nijaba_afk is now known as nijaba [16:00] hello again! [16:01] it's time for the weekly Ubuntu Friendly meeting! [16:01] let's get started [16:01] #startmeeting Ubuntu Friendly Meeting [16:01] Meeting started Mon Dec 12 16:01:37 2011 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:02] Hi all! Welcome to the Ubuntu Friendly meeting! [16:02] We only have a small topic on the Agenda today, but please remember, if there's anything at all you'd like to discuss, just let me know. [16:02] Our agenda for today includes: [16:02] Progress report on new Checkbox (System Testing client) user interface. [16:02] Any Other Business [16:03] Let's get started with our first topic! [16:03] [TOPIC] Progress report on new Checkbox (System Testing client) user interface. === 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: Progress report on new Checkbox (System Testing client) user interface. [16:03] So if you've run the Ubuntu Friendly tests, you're no doubt familiar with Checkbox. [16:03] Although good enough for most needs, the UI is lovably quirky and the way it is built limits the improvements we can easily make. [16:04] Since we were looking at a major overhaul, it was decided to create a new UI module for checkbox, to implement the new features we want and have room to improve it more easily. [16:04] There are both a new UI design in general, and a number of specific suggestions we received from the community during Ubuntu Friendly testing. [16:04] Ideally we'd like to incorporate these in the User Interface. Remember that we welcome ideas on specific pain points or interface quirks you'd like to see taken care of. [16:05] The UF mailing list is probably a good place for this, we like receiving stuff on the ML! [16:05] The one new thing about the UI is that, thanks to help from Ugo Riboni and Tiago Herrmann's expertise, there's already some progress in implementing a checkbox UI in Qt \o/ [16:05] For now work has gone into recreating the existing Checkbox UI in Qt, both for Tiago to get to know Checkbox and for us to get to know Qt :) [16:05] But in the near future (days, I expect), we'll refocus into creating the new Checkbox UI with what has been learned. [16:06] I'll check with Tiago to see if we can make a branch public for you all to see, although at this stage it's mostly an experiment. [16:06] Once we start actually implementing the new UI, we'll let you all know and follow along on the progress. [16:06] ... I guess that's it as far as progress on the UI goes! [16:07] Any comments or questions about this? :) [16:08] nothing? :) [16:09] o/ [16:09] jedimike: go ahead! [16:10] a new ui for checkbox is exciting, and I'd like to see a UI purely for ubunu friendly [16:10] it would consist of one button [16:10] that says "Run the ubuntu friendly tests" [16:10] to make sure we run everything we need [16:10] and still allow people to use the more detailed UI for running checkbox in the way they've been accustomed to [16:10] .. [16:11] o/ [16:11] jedimike, good suggestion! [16:11] cr3: you go [16:11] I might be inclined to agree with jedimike to have an Ubuntu Friendly specific client, but only if we can provide a link to Ubuntu Friendly at the end of the run [16:11] .. [16:12] o/ [16:12] noted, the "press this big button to do Ubuntu Friendly testing" approach sounds like the most intuitive way to tackle it [16:12] jedimike: heh, go ahead! [16:13] cr3: agreed, the UI for UF should be focussed on the friendly aspect, and shouldn't present anything more than is needed to run UF, and present UF info that the usual system testing checkbox ui doesn't [16:13] .. [16:14] oh so we're now talking about two UIs! [16:14] o/ [16:14] cr3, go [16:15] there seems to be much demand for slightly varying UIs: checkbox, friendly, certification, unity, etc. [16:15] o/ [16:15] I've been thinking of refactoring the checbox core: 1. to remove plugins; 2. to replace them with a job driven UI [16:16] so, the introduction screen should be specified as: plugin: interface; name introduction; description; welcome to Ubuntu Friendly... [16:16] .. [16:16] cr3: well in principle people can come up with their own Checkbox frontends, but that way it'd be easier for them to do. [16:16] jedimike: your turn! [16:16] just in case the outcome wasn't clear: a different UI would simply mean a different whitelist :) [16:17] it just seems to me like system testing would be for testing your system, the UF interface would be to participate in the ubuntu friendly program. While the testing backend is checkbox in both cases, the intentions and requirements are different, so a different, simpler UI for UF seems to be a good fit, from my view [16:17] ... [16:18] jedimike: yep agreed on that, and also the UI would probably share a lot of components. For this I liked the Gtk approach where you can come up with prefabricated "panels" or pieces and just bring them in as needed [16:18] jedimike: I guess Qt can do the same [16:19] OK so it's something to consider for when actual work starts on the new UI, which should really be within the next few days. [16:19] roadmr: I suspect the user_interface api should be sufficient for both intents and purposes, friendly and system testing [16:19] cr3: yep, it should be [16:20] we do need to come up with actual user stories and storyboards for the UI, something more detailed than the mockups we have [16:21] I'll keep everyone posted on this via the mailing list [16:21] anything else on this topic? :) [16:22] o/ [16:22] cr3: go ahead! [16:22] it sounds like this request for a UF interface is very similar to the one expressed by the Unity folks [16:23] the motivation being that changing the interface will result in more user testing [16:23] I would like to question that motivation and perhaps get some validation that the problem is really the interface [16:24] so, in addition to mockups, could we also do somekind of market research to justify that what we're doing will actually result in better numbers? [16:24] .. [16:24] cr3: quite a valid point. [16:25] cr3: to be fair, the UI work to be done for checkbox is in direct response to user feedback [16:25] cr3: but I agree that we should be sure about the "ROI" before committing a lot of resources to this [16:26] cr3: getting rid of annoyances like "closing the checkbox window ends the testing run, no questions asked" is one thing [16:26] roadmr: we should either get those numbers prior or at least plan to get them afterwards in the current case where we already committed to investing resources [16:26] cr3: but changing stuff without a real justification is probably not good [16:26] roadmr: that's a bug, not a preference :) [16:27] cr3: a preference is just a user-configurable bug :) [16:27] roadmr: actually, I misunderstood that as the checkbox window closing after each test. it might be a preference but I think it's been justified by plenty of user feedback [16:28] cr3: no, if you click on the "x" to close the checkbox window by mistake, it just closes, no "are you sure you want to abandon the test run?", no nothing [16:28] I know cuz I've done it :( [16:28] roadmr: right, I remember now, just read too fast the first time around :) [16:30] cr3: yep, it might be reasonable to depict feature requests as user stories, the "so I can..." thing is very good at distilling the intent behind a particular feature request [16:31] awesome feedback on this topic! [16:31] anything else for this? [16:32] OK let's move on then [16:32] roadmr: I see bugs like the one you mentionned as a cost center because it won't necessarily translate into more submissions, we may want to start thinking of improvements as profit centers that translate into more submissions [16:32] roadmr: ie, express the user stories you mentionned that way [16:33] cr3: sounds like a good idea! Though I can envision a submission being "lost" because a user lost its patience and decided not to restart the test run after mistakenly closing checkbox :( [16:33] cr3: if fixing the bug helps us "recover" those submissions, that may be worthwhile to fix [16:34] roadmr: sure, as long as it's expressed in such a way that leads to more submissions rather than just stories about people using checkbox in various ways without a purpose :) [16:34] cr3: agree 100%, sounds like a useful way to constrain the stories to make them more useful [16:35] ok then, let's move on! [16:35] roadmr: exactly, it might even help us priorities the stories [16:35] cr3: yes, highest submission value first :) [16:35] [TOPIC] 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: Any Other Business [16:36] Got anything you want to discuss? Anything Ubuntu Friendly related goes. [16:37] o/ [16:37] jedimike: go! [16:38] I'd like to get some feedback on the homepage. At the moment it's just listings, starting with the highest rated systems. I'd like to know what people would like to see, if they'd like something different, or if they like how it is. [16:38] ... [16:39] o/ [16:39] cr3: go ahead [16:39] jedimike: I think people could argue that when a listing becomes large enough, just showing a small subset on the home page is useless. [16:40] o/ [16:40] jedimike: the reason is probably because that list becomes stale at some point, always the same small subset is shown [16:40] o/ [16:40] jedimike: so, people tend to provide more active information, like "lastest hardware" or something like that [16:40] jedimike: perhaps we've reached enough hardware to make it worthwhile to consider other options at this point [16:41] . [16:41] . [16:41] roadmr, you go [16:41] thanks! heh, one problem I see is that the listing is somehow not turning up the way we expected it to [16:42] meaning that we see a lot of systems with very few ratings, rather than a large sample per-system [16:42] so yes, the ones that get 5 stars tend to always be the same [16:42] the "latest systems tested" section would be interesting to have [16:42] also, we could come up with a "spotlight" and rotate systems that have tested well, even though they may be a bit further down the list [16:43] finally, I saw some comments about how the home page just throws the listing into your face, assuming you know a priori what it is about [16:43] so maybe a short explanation blurb on the front page could help [16:44] "UF lists systems that are known to work well with ubuntu, yadda yadda, want to know more? click up there. Or just go straight into the listing" [16:44] that'd probably be easy enough to add and we could gauge how people feel about it. How to gauge? well I don't know yet :( [16:44] .. === Ursinha is now known as Ursinha-lunch [16:45] jedimike: go ahead :) [16:46] just wanted to say if anyone in the community had ideas, wanted to do some mockups, or anything like that, I'd welcome the input :) [16:46] .. [16:46] jedimike: I like this mockup: http://www.ubuntu.com/certification [16:47] jedimike: just kidding, except for the blurb, the rest of the page doesn't necessarily translate well to UF [16:48] OK! remember that the mailing list is open and probably a good place for that kind of feedback and suggestions [16:48] anything else? any other business? [16:49] nothing? :) Going once... [16:49] Going twice... [16:50] Well, looks like we're done, but please remember the mailing list is there if you ever want to discuss a topic, suggest an idea, or bring something to the Ubuntu Friendly Squad's attention. [16:50] I guess that's it for today then, thanks all for attending! And see you here next monday (December 19th) at the same time. [16:51] #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:51] Meeting ended Mon Dec 12 16:51:00 2011 UTC. [16:51] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-12-12-16.01.moin.txt [16:51] thanks everyone! === vanhoof_ is now known as vanhoof [18:01] hi! [18:02] hello! [18:02] hi [18:02] hey [18:03] let's get started [18:03] #startmeeting [18:03] Meeting started Mon Dec 12 18:03:29 2011 UTC. The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. [18:03] 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 [18:03] The meeting agenda can be found at: [18:03] [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting [18:03] [TOPIC] Weekly stand-up report === meetingology changed the topic of #ubuntu-meeting to: Weekly stand-up report [18:03] I'll go first [18:04] it'll be a short week for me this week [18:04] I have friday off. next week I'll have of thursday and friday [18:04] I'm in the triage role this week [18:05] I have some python updates I am working on, and an embargoed update [18:05] I have 1 more MIR audit left I think, as well as some archive admin work I couldn't get to last week [18:05] I'm also patch piloting today [18:06] I think that is it from me. sbeattie, you're up [18:06] I'm on community this week. [18:06] I'm in the middle of writing up my notes on cgroups; that should go out later today. [18:07] sbeattie: excellent! thanks :) [18:07] I'm also poking at jamespage's patch to add logging to upstart. [18:07] sbeattie: (james hunt :) [18:07] bah, jameshunt; one of the borg of the james [18:08] hehe [18:08] james page is the java borg :) [18:08] I also have some backburnered updates going on. [18:08] I think that's it for me; micahg? [18:09] I'm preparing the Firefox/Thunderbird 9 release later in the week as well as the Firefox Lucid/Maverick rapid release transition, with work on the webkit 1.6 transition as time permits [18:09] tyhicks: ? [18:10] I'm in the happy place this week [18:10] The acpid update last week took a bit longer than expected, so I've got some car [18:10] ry over from last week [18:10] I should get the bzip2 update out today [18:10] I'm almost done with the patch for bug 885744 (eCryptfs pathconf reporting) [18:10] Launchpad bug 885744 in eCryptfs "pathconf() does not reflect reality" [High,Triaged] https://launchpad.net/bugs/885744 [18:11] My math is just a little bit off in taking the max lower filename length and calculating the eCryptfs overhead, so I need to make a tweak or two to that [18:11] I've got the eCryptfs make test work item to do [18:11] and I'll move on to another update or two this week [18:12] jjohansen: you're up [18:12] There is the regular kernel USN work and the kernel team have asked for some help looking at a couple of CVEs. For apparmor I'll be poking at mount rules, and updated permissions, and domain transitions for stacking this week, along with putting a ppa together for testing the updated apparmor out. I am off next week [18:13] hrmm, that didn't paste so well ;/ [18:13] so that its from me [18:13] mdeslaur: ? or perhaps back to jdstrand [18:14] mdeslaur had a meeting conflict. I know he is working on several updates this week [18:14] mdeslaur: feel free to chime in if desired, but you should be covered [18:14] oh, he is also in the happy place this week [18:14] [TOPIC] Highlighted packages === meetingology changed the topic of #ubuntu-meeting to: Highlighted packages [18:14] The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so. [18:15] See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved. [18:15] http://people.canonical.com/~ubuntu-security/cve/pkg/krb5-appl.html [18:15] http://people.canonical.com/~ubuntu-security/cve/pkg/opendchub.html [18:15] http://people.canonical.com/~ubuntu-security/cve/pkg/vdr.html [18:15] http://people.canonical.com/~ubuntu-security/cve/pkg/kompozer.html [18:15] http://people.canonical.com/~ubuntu-security/cve/pkg/poco.html [18:15] [TOPIC] Miscellaneous and Questions === meetingology changed the topic of #ubuntu-meeting to: Miscellaneous and Questions [18:15] Does anyone have any other questions or items to discuss? [18:19] ok [18:19] sbeattie, micahg, tyhicks, jjohansen: thanks! [18:19] #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 [18:19] Meeting ended Mon Dec 12 18:19:26 2011 UTC. [18:19] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-12-12-18.03.moin.txt [18:19] thanks jdstrand [18:19] thanks jdstrand [18:21] thanks === mglidden_ is now known as mglidden === Ursinha-lunch is now known as Ursinha [20:54] cjwatson, kees, soren, stgraber: meeting reminder in 6 mins [20:55] pitti: already holding my breath [20:55] * kees waves [20:56] * soren makes waves [20:56] pitti: can you let me post through to the technical-board mailing list [20:56] hi [20:56] Riddell: I think cjwatson can moderate stuff in near real time. [20:58] ScottK overestimates me, but done anyway [20:58] That was pretty near. [20:58] Riddell: running listadmin [20:58] ah, thanks cjwatson [20:59] Riddell: You didn't happen to cc stuff to kubuntu-devel did you? [20:59] ScottK: no but it's just a pointer to https://wiki.kubuntu.org/Kubuntu/12.04/LTS-Proposal [20:59] OK. Thanks. [20:59] however FWIW I do think we need more than a few hours between a proposal to the list and voting on it [21:01] #startmeeting [21:01] Meeting started Mon Dec 12 21:01:00 2011 UTC. The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. [21: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 [21:01] * stgraber waves [21:01] welcome everyone to Ubuntu Late Night Tech Talk [21:01] *cough* Tech Board [21:01] #link https://wiki.ubuntu.com/TechnicalBoardAgenda [21:01] (just updated with another agenda item) [21:02] kees: here by chance? [21:02] ah, you waved, nvm [21:02] #topic action review === meetingology changed the topic of #ubuntu-meeting to: action review [21:02] sorry, I spectacularly failed with documenting the brainstorm review bits [21:03] will do first time tomorrow, promised (unless yet another thing blows up all over again :) ) [21:03] if you're going to fail, at least do it spectacularly. [21:03] * pitti has a huge paper note at his desk now [21:03] so, kees didn't start yet, so both carried [21:03] #topic edubuntu LTS application === meetingology changed the topic of #ubuntu-meeting to: edubuntu LTS application [21:03] stgraber: this is still blocked on Kubuntu LTS app, right? [21:04] or is there something else for this which we should talk about? [21:04] yeah, sorry :( [21:04] pitti: still blocked on Kubuntu and my inability to use germinate :) [21:05] Well, I see from the link earlier that Kubuntu now has a proposal on the way, so that's a good thing at least. [21:05] bit late due to my ill health alas [21:05] I updated the apps list of what we currently ship on https://wiki.ubuntu.com/Edubuntu/12.04/LTS-Proposal [21:05] what is the proper forum to repsond to the https://wiki.kubuntu.org/Kubuntu/12.04/LTS-Proposal application? [21:05] pitti: I have the full diff from Kubuntu+Ubuntu => Edubuntu which contains a lot of java stuff, so trying to re-generate the list without geogebra (that's pulling everything) but for some reason germinate doesn't seem to care about my local changes to the seed :) [21:05] highvoltage: ah, that list is very useful, thanks [21:05] jdstrand: technical-board list? [21:06] there's also a link to packages that's installed that's not on the Ubuntu/Kubuntu discs: http://paste.ubuntu.com/768132/ (thanks to stgraber) [21:06] ok [21:06] stgraber: and freemind, presumably? [21:06] stgraber: contact me about that outside the context of the meeting and I expect I can help [21:06] dia-gnome and calibre seem rather hard to support, but otherwise the list looks pretty tame [21:07] pitti: right, though apparently geogebra is the worst, I don't mind having a few java dependencies, having hundreds of them is a bit annoying though :) [21:07] stgraber: have you cross-referenced that against the server seed? seems like there's probably a fair amount of server stuff in there [21:07] err, java stuff [21:07] cjwatson: will do, that was my next step :) [21:07] stgraber: ok, so should we carry that until the next meeting until Kubuntu has been discussed? [21:08] broder: The output was diffing ubuntu.precise + kubuntu.precise to edubuntu.precise, I expect ubuntu-server to be part of ubuntu.precise (but should definitely check) [21:08] pitti: yep [21:08] BTW you might find it easier to use python-germinate now that it exists [21:08] save on parsing [21:09] ubuntu-server is in the ubuntu.precise seed collection, yes [21:09] oh right, forgot the new shiny stuff, will give it a try [21:09] #topic non-PAE kernel disposition === meetingology changed the topic of #ubuntu-meeting to: non-PAE kernel disposition [21:09] anyone from the kernel team here? [21:09] who is driving the discussion ? [21:09] tgardner, bjf? [21:09] yes [21:09] ah, hello! [21:10] * cjwatson sends a reminder to slangasek, since I know he wanted to weigh in here [21:10] ah yes, hi [21:10] it was already discussed quite a bit on the lists (@devel, IIRC) [21:10] we'd like to drop the non-pae kernel since we don't think its getting much use. [21:10] It only felt like devel-discuss. [21:11] wait, I'm sorry, "we don't think it's getting much use" ?! [21:11] so my first question would be how much actual effort it would be to keep the flavour; if it's more than the kernel team can spend, we wouldn't have much to decide anyway [21:11] plus, I think supporting it for another 5 years is a waste of resource. [21:11] from my outside POV it doesn't feel like a lot of extra maintenance, but IANAKD [21:11] pitti, its all incremental. [21:12] not getting much use is obviously no kind of sense at all because it's the default up to oneiric. [21:12] second question: given that it is currently our default kernel, do we have a proven rock-solid way of migration, or determining when a CPU does not support PAE and stopping the upgrade? [21:12] I have no memory of non-pae flavors ever causing ftbfs or other support problems. why not drop it in P+1 and then everyone is happy? [21:13] I'm certainly in favour of making the PAE one the default kernel in P as a first step [21:13] pitti: non-pae will not boot a pae kernel at all. [21:13] kees: right [21:13] yeah, me too [21:13] kees: I meant, what to do with upgrades? [21:13] pitti: ah, the "pae" flag in cpuinfo should be sufficient. [21:13] we can't just do the upgrade and then leave the user with an unbootable system [21:13] so we'd need an update-manager quirk there [21:13] pitti, I think the upgrade path is clear for those that have PAE capable CPUs. [21:13] which sounds rather easy to do [21:14] we will have to check that its capable. [21:14] my own concerns are twofold [21:14] It's only clear if you make the -generic kernel depend on -generic-pae, which makes it unclear for the rest [21:14] tgardner: the upgrade would be via switching linux-meta? [21:14] and keeping the non-PAE names as transitionals? [21:14] pitti, taht, and the upgrade manager would have to detect PAE support [21:14] - I don't understand why there's any measurable incremental cost to maintaining this flavor for the kernel team, and I don't get the impression this cost has actually been measured (I alluded to this in https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html, but perhaps should have asked the question more directly) [21:14] This is too important to rely on update-manager [21:15] failing linux/linux-meta preinsts would be the "last line of defence", but quite ugly, too [21:15] cjwatson, so how do you normally do this sort of thing when capabilities are being withdrawn ? [21:16] tgardner: I think we don't have much precedence here, we need to figure it out [21:16] It must go in packages themselves, not relying on update-manager [21:16] - since feedback to the question on ubuntu-devel overwhelmingly indicated that there are users who care about having a pae kernel for precise (which is exactly the kind of feedback you'd expect in such a thread), it's not at all clear what the threshold actually is for "getting enough use" to be worth keeping [21:16] It is simply not acceptable to cause upgraders with apt-get to end up with unbootable systems [21:17] (In any case, I think it's incumbent on those developers who are withdrawing support to deal with this kind of thing) [21:17] slangasek, nobody presented any hard facts. I expected a little howling anyways. [21:17] slangasek: do you mean "having a non-pae kernel for precise"? [21:18] cjwatson, I agree. but we have to solve this problem now or later. [21:18] Why? [21:18] tgardner: "I run a non-PAE machine that I care about running precise on" is certainly a hard fact; I'm not sure what you mean [21:18] slangasek: you meant "having a non-pae kernel for precise" ? [21:18] tgardner, kees: yes, I meant non-pae, sorry [21:18] Optimising the i386 architecture does not seem compelling to me. [21:19] I don't feel at all good about chopping off another percentage of users. Sooner or later salami tactics are going to bite. [21:19] slangasek, there a folks that ran sparc, ia64, and hppa. why did we drop those ? [21:19] Those had orders of magnitude fewer users and orders of magnitude greater difficulty in supporting them. [21:20] I don't thikn the maintenance burden of those flavours compares very well to the non-PAE one. [21:20] is there any way we can get some data on this, so we don't have to make as many assumptions? [21:20] e.g. can we actually try to estimate the proportion of our user base who would be affected by this? [21:20] We could start a thread on -devel and assume that the people who reply are unrepresentative [21:21] the one fact that I have is that non-PAE CPUs have not been in widespread production for 10 years. (I think tat was what Ben said on the list) [21:21] sorry [21:21] if I may chime in, in my dayjob we hava clients who use thin clients that weren't bought not too long ago (3-5 years ago) that uses via cpus that don't have pae support. we have one client that runs more then 5000 of these machines. upgrading them to stay on the latest lts right now would be quite costly [21:21] I think we have an excess of anecdotes and a dearth of data [21:21] (it's easier to say it's supported for now but in 5 years it will be dropped than it suddenly happening now) [21:22] (and sorry for adding another anectode :) ) [21:22] how about counting the proportion of non-pae CPUs in hardware profile submissions? [21:22] tgardner: I would also like to understand why this is a maintenance burden for the kernel team; since I can't see any reason it should be a measurable amount of work, if it actually *is*, I think that's a process bug that I'd like to see if I could help fix [21:22] bjf might be able to have a look at that. [21:22] (in its own right, and not just because of non-pae in particular) [21:22] mdz: wouldn't catch thin clients, but at least it's some data [21:22] this isn't about if the machines exist or not (they do) since no one is talking about eliminating non-pae. the question, as I saw it, was _how_ to move it to universe for precise. [21:23] FWIW, while I'm totally unpersuaded as to the need to drop i386/generic, I'm happy to switch the installer default [21:23] pitti, I suggest only that it would be more representative than our individual opinions :-) [21:23] cjwatson: right; I'm not really concerned about new installs/live system here, much more about upgrades [21:23] cjwatson, that only makes sense if we drop non-pae, right? otherwise it just won't boot [21:23] kees: the proposal from tgardner was to assist someone in uploading a separate source package for a non-pae flavor to universe; I think that's tantamount to killing it (or ought to be [21:23] mdz: yes, fully agreed :0 [21:23] kees: That has not been clear to me; I had been given to understand that this was the kernel team wanting to stop building i386/generic, which isn't -> universe, it's -> /dev/null [21:23] it sounds like the kernel team wants -generic out of main. I have no problem with that, the default kernel for ubuntu should have been PAE a long time ago, so I'd support that. [21:23] ) [21:24] I don't believe in a separate universe package [21:24] it'll essentially double the maintenance effort without any benefit [21:24] tgardner: Huh? It doesn't require the kernel packaging to drop the generic flavour at all. [21:24] making non-pae unavailable for this release (an LTS) seems like a serious mistake. I see no evidence at all that it would help anything. [21:24] or, if we don't double it, then people can't run it as it wouldn't get security updates, etc. [21:24] d-i s/generic/generic-pae/, base-installer (or preseeds or something) s/generic/generic-pae/, done [21:25] having a separate source package for non-pae might look good on paper from the kernel team's perspective, but with my archive admin hat on I think that would be a pretty broken thing to do, and I don't think anyone would actually step up to do it on those terms [21:25] I here 3 topics: making PAE the default kernel (we seem to all agree +1), moving non-pae to universe, dropping non-pae completely. [21:25] Personally I'm not happy with kernels in universe as it's a pain for archive admins to manage which are in universe and which in main; it's a lot simpler if they're all in main [21:25] But I suppose we could solve that if we had to [21:25] from the perspective of someone who hasn't kept up with ubuntu-devel recently, it's surprising to me how heated this discussion is [21:25] I'm completely against all-out dropping of non-pae. [21:25] can we try to dial it back a little? [21:26] mdz: sure. can we do 1 topic at a time, then? I think that may help. [21:26] slangasek, the maintenance burden is non-zero. its costs some amount of time to build it, there are config files to maintain, and so on. Its not a huge burden, but I'm trying to assess whether its worth while as all. time is money. [21:26] ah, you mean do build it from "linux", just have the binary in universe [21:26] above I meant that I don't believe in a separate source in universe [21:27] we tried that several times in the past, and it didn't work out [21:27] pitti: agreed [21:27] tgardner: I have a hard time believing that any maintenance costs to keep it in an LTS even approach the amount of time that's already been spent discussing ;) [21:27] While I understand that the kernel team specifically would probably save some small amount of time by dropping one i386 flavour, I question whether the net time benefit to the Ubuntu (development) community as a whole is positive [21:28] slangasek, it does when you consider the repetetive nature of the maintenance process. [21:28] Not to mention the net time cost to users of affected systems if we were to drop the flavour entirely [21:28] don't forget, I'm also looking forward to a number of ARM flavours, so I'm trying to shed some work. [21:29] is there any objection to moving to pae-by-default? [21:29] well, at some point we need an upgrade mechanism to deprecate flavours [21:29] I just don't think we have that worked out properly yet [21:29] I do not object, although I anticipate some trickle of requests to be able to install on older systems, which will come in as regressions [21:30] That will take some amount of my time to diagnose before I determine that they are non-PAE [21:30] okay, so, next is "drop non-pae entirely?" [21:30] my feeling is that we should switch to PAE by default first and have a few alphas/betas with that out for real field testing [21:30] I don't object, though it's easier to switch to the PAE kernel post-install rather than finding a way to get a non-PAE installer [21:30] But on the whole PAE-by-default is probably a better default, at least, for precise [21:30] tgardner: well, I still don't understand how you arrive at the conclusion that an extra flavor which is nearly identical to generic-pae in every way and should be maintainable in a scriptable fashion has a measurable impact, and I would like to understand that - but I don't necessarily want to take up the TB's time with that discussion [21:31] and can then drop non-PAE to universe in P+1 when we worked out an upgrade mechanism to safely stop upgrades for non-PAE systems [21:31] If we actually intend to keep it around in universe, but not be the default, the install instructions will be embarassing. "First, install Oneiric. Then, upgrade to Precise." and it gets even worse for P+1. [21:31] my guess is that having PAE the default for desktop is fine, alternate and server may be a bit trickier (and not having the same everywhere would be even worse) [21:31] Can we have one kernel in the installer and another as the default in the installed system? [21:31] we'll need the same mechanism for the gazillions of armel flavours that we have at some point, too [21:31] stgraber: If we have the same everywhere it's not especially challenging [21:31] Hm... I guess that'll be quite costly in ISO space. [21:31] soren: Yes, but it's a bad idea [21:32] soren: It means some people can boot the installer but not the installed system [21:32] cjwatson: WEll, the installer could detect the non-PAE-ness of the system and install the non-PAE kernel, but again: ISO space. [21:32] soren: If the non-PAE flavour is in universe, then by definition the installer won't consider it [21:32] (And yes, ISO space) [21:33] cjwatson: Ah, yes. [21:33] (But I think that's a secondary issue) [21:33] Someone would need to provide a special iso for non-pae. [21:33] netboot [21:33] soren: why? [21:33] Although we can't build debian-installer for non-PAE if the non-PAE kernel is in universe. [21:33] soren: yes, this is what already happens. the pae kernel is pulled from the network when pae+>3G RAM is seen. [21:33] kees: Oh, ok. [21:34] So in reality, non-PAE -> universe means that it's upgrade-only, no fresh installs [21:34] kees: not on CD installs right now [21:34] pitti: Why what? [21:34] cjwatson: I thought that was a feature of the alt installer? [21:34] I read the code for that... [21:34]