=== ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 02 Sep 15:00: Server Team | 27 Aug 17:00: QA Team | 27 Aug 22:00: Platform Team | 28 Aug 12:00: Ubuntu Mobile Team | 28 Aug 13:00: Desktop Team | 01 Sep 04:00: Arizona LoCo IRC === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 02 Sep 15:00: Server Team | 27 Aug 17:00: QA Team | 01 Sep 04:00: Arizona LoCo IRC | 28 Aug 12:00: Ubuntu Mobile Team | 28 Aug 13:00: Desktop Team | 28 Aug 14:00: Ubuntu Java Team === fenris_ is now known as e-jat === C3333877 is now known as chalcedony === emma_ is now known as emma === dholbach_ is now known as dholbach === jsg123 is now known as jsgotangco === asac_ is now known as asac === jsg123 is now known as greeneggsnospam === jsg123 is now known as greeneggsnospam === nand_ is now known as nand [15:38] @now [15:39] Current time in Etc/UTC: August 27 2008, 14:39:00 - Next meeting: Server Team in 6 days [16:10] Erm. That's just not right. [16:10] Anybody from the news team around? Could you populate the calendar a bit? I *know* there's lots of meetings during the next 30 hours or so. === lamont` is now known as lamont [17:57] Hey everyone [17:57] * pedro_ waves [17:57] 'alo [17:57] hi heno_ [17:57] I may have to run in a few minutes [17:57] hey LaserJock [17:58] greetings [17:58] pedro_: could you chair the meeting? - in case I need to dash off [17:58] heno_: yes no problem [17:58] pedro_: I think we need to send the meeting emails earlier [17:59] it'd be nice if we had the agenda set by Monday and the email sent out Tuesday I think [17:59] to allow people who don't normally come but may be interested in specific agenda items [17:59] should we schedule meetings when there are no suggested agenda items? [17:59] LaserJock: indeed, but we didn't have an agenda till today morning, that's why i didn't send it yesterday [18:00] heno_: well, I would propose that unless we have a full agenda a "spec status" roll call would be good to do each meeting [18:00] we may have some standing items of course like, indeed [18:00] it's often good if we don't have big agenda items :-) [18:00] hey === ubottu changed the topic of #ubuntu-meeting to: Current meeting: QA Team Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 01 Sep 04:00: Arizona LoCo IRC | 28 Aug 12:00: Ubuntu Mobile Team | 28 Aug 13:00: Desktop Team | 28 Aug 14:00: Ubuntu Java Team [18:00] Or a round table [18:00] also looking toward testing of the next milestone and SRU status [18:01] but it's also good to get everybody together, talk about the week [18:01] hello [18:01] yay, let's do a round table! [18:01] yeah [18:01] ok everybody is here, let's start [18:01] #startmeeting [18:01] I think it's especially nice to find out about blockers :-) [18:01] * pedro_ kicks the bot [18:02] I'll go first since I may have to run [18:02] hello [18:02] Welcome to the Ubuntu QA Meeting the Agenda for today is at https://wiki.ubuntu.com/QATeam/Meetings [18:02] I was at a Canonical distro team leads sprint all last week [18:03] we discussed the usual admin stuff but also some Ubuntu QA stuff [18:03] hey [18:03] There is broad agreement that we will ramp up the focus on quality in the releases to come [18:03] I can write more when I get the notes [18:04] that's always a good thing? :-) [18:04] s/?/!/ [18:04] of course! [18:04] oh, not '?' [18:04] heh [18:04] * LaserJock plays "punctuation jumble" today [18:04] on monday I was at an LP team sprint as well [18:05] the numbers that we discussed for the LP bugs priorities were presented [18:05] it looks like they have a good process for taking that forward [18:05] cool :) [18:06] they will decide on actual priorities this week [18:06] excellent [18:06] yay [18:06] ok, that's it from me! [18:06] thanks [18:06] ok the next point i see is [18:06] Ubuntu Developer Week preparations [18:07] the Ubuntu Developer Week starts next week [18:07] That's just pointing out https://wiki.ubuntu.com/UbuntuDeveloperWeek [18:07] and there's a few talks from the members of the team [18:08] anyone wants to give a brief overview about their talk? [18:08] I was pleasantly surprised to see Ara scheduled [18:08] and it looks like there are no more open slots [18:08] bdmurray, ara ? [18:08] go ara go! ;-) [18:08] pedro_: ok, I'll go [18:09] rock [18:09] I will be presenting the automated testing library that we've been working on [18:09] what is exactly, how to use it, etc. [18:10] i will be completing the docuementation at https://wiki.ubuntu.com/Testing/Automation/LDTP/HowToUseTestingLibrary === persia_ is now known as persia [18:10] before the session, so people will be able to have some reading after it [18:11] what I would like to achieve from the session is making people more involved in testing and more specifically in automated testing [18:11] only some very basic python knowledge is required [18:11] ara: very nice [18:12] nice! looking forward to it [18:12] bdmurray: may you tell us a bit about the launchpad hacks session? [18:12] ara: so are you going to be able to go through how people can contribute test scripts? [18:13] LaserJock: yes, how to contribute with new scripts that use the library; but not how to extend the library [18:13] LaserJock: if I get people willing to contribute also to extend the library, it will be great [18:14] pedro_: I plan on talking about recent features added to bughelper / python-launchpad-bugs. Additionally, I want to talk about all the scripts in the launchpad-gm-scripts project and how they might help you use launchpad. [18:15] next time we should get a QA Team overview session [18:15] cool! [18:15] should we continue the round table? [18:16] If so there's one thing I wanted to mention... [18:18] I've written a script that checks needs-packaging bugs to see if they are already packged in debian or ubuntu and checks to see if there is a request to have them packaged in debian [18:18] I plan on running this on qa.ubuntu.com soon and announcing it [18:19] However, one way we can help is ensuring the needs-packaging bugs follow a specific format for the title [18:19] for example: [needs-packaging] softwarename .... [18:19] how does it find the package in the archive? [18:19] So if you happen to see any that don't follow that convention please modify the title. [18:19] bdmurray: why do you want to use the title? [18:20] heno_: rmadison [18:20] bdmurray: one thing that is unclear from the documentation is that instead of "naming [needs-packaging]" the document reads "tagging [needs-packaging]" [18:20] bdmurray: rather than a tag, that is [18:20] intellectronica: so it is distinguishable in a list of bugs - both are done [18:20] ara: okay, I'll update the documentation [18:21] Ideally they'll be tagged needs-packaging and have that prepended to the title [18:21] hmm, but how reliable would the title be? [18:22] LaserJock: I've modified ~134 needs-packaging bugs which is >10% [18:22] So I think it has been pretty successful [18:22] bdmurray: you've modified the title of 134? [18:23] what I meant was that by definition we don't have a package name for needs-packaging bugs [18:23] LaserJock: no, I've linked to upstream bug watches, marked as duplicate or Fix Released 134 bugs [18:23] so how do you go from a bug title to finding if it's in the archive? [18:23] * heno_ is afk [18:24] I assume the 2nd word in the title is the name of the software needing packaging [18:25] And that's where help would be useful - ensuring the bug titles follow that convention [18:25] bdmurray: right but quite often that's not a great mapping to package name [18:25] but consistency is usually a good thing :-) [18:26] I'm just worried that if we take a scripted list we'll could have a significant amount of false positives [18:26] so then we'd be triaging anyway [18:27] bdmurray: so bug title Intrepid: xapian doesn't work and intrepid: bunnys have big ears is cool for you? [18:28] where bunnys needs packaging sorry [18:29] davmor2: heh [18:29] LaserJock, this is one reason why we would still need the tag -- titles may not work always [18:30] hggdh: that's the whole reason why I made the tag in the first place ;-) [18:30] and this is another reason why we need more tags ;-) [18:30] and if a particular ubuntu bug has too many results just skip it or modify the title and it'll get processed in the next run of the script [18:30] bdmurray: sorry talking at cross purposes missed the first bit just played catch up [18:31] bdmurray: ok, so what does your script output? [18:31] the bugs where the software exists in Debian/Ubuntu? [18:31] The output of rmadison or links and titles of debian bugs [18:32] hmm, that just seems so error prone [18:34] Any other issues? [18:35] well, the Testing Day thing is still up in the air [18:35] it'd be nice to get something nailed down for that [18:37] Yes, LaserJock can you send a reminder about it to the ubuntu-qa list ? [18:37] k [18:37] also before I need to dash off the bugs I've come across whilst smoke testing I've collated here https://wiki.ubuntu.com/Testing/DailySmoke/bugs I won't be around next week so if someone can quickly blitz through them and see if there fixed early next week that would be great [18:37] thanks you [18:40] alright, thanks davmor2 [18:40] ok it seems we don't have anything else [18:40] just a quick one [18:40] intellectronica: go ahead [18:41] has there been any progress on preparation for that bug status migration? [18:41] intellectronica: i haven't had the time yet to prepare the wiki page, but ill need to do it soon [18:42] cool. let me know if you need any help [18:42] yup , thanks [18:42] ok , let's wrap then [18:42] thanks everybody [18:43] thanks, pedro_ [18:43] thanks [18:43] thanks [18:44] thanks everyone === emma_ is now known as emma === emgent` is now known as emgent === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 01 Sep 04:00: Arizona LoCo IRC | 28 Aug 12:00: Ubuntu Mobile Team | 02 Sep 15:00: Server Team | 28 Aug 13:00: Desktop Team | 28 Aug 14:00: Ubuntu Java Team | 29 Aug 15:00: Ubuntu Release [19:42] @schedule detroit [19:42] Schedule for America/Detroit: 01 Sep 00:00: Arizona LoCo IRC | 28 Aug 08:00: Ubuntu Mobile Team | 02 Sep 11:00: Server Team | 28 Aug 09:00: Desktop Team | 28 Aug 10:00: Ubuntu Java Team | 29 Aug 11:00: Ubuntu Release === riot_le1 is now known as riot_le === Czessi_ is now known as Czessi === stefanlsd_ is now known as stefanlsd [22:56] * asac first [22:56] hi [22:56] hi [22:56] hi [22:56] hi all [22:57] morning [22:57] hi [22:57] evening [22:58] * ogra waves [22:59] * slangasek waves [23:01] bryce: ping? [23:03] guess not; let's move on without him for now [23:03] hi [23:03] aha [23:03] ok, so feature freeze is at some time I'm not entirely certain of, but at any rate within the next day [23:04] so now's a good time to look over our team's progress and see what needs to be deferred and what might want exceptions from the release team [23:04] * ogra hopes late [23:04] 5 minutes ago I thought [23:04] 0000 UTC [23:04] which by my clock leaves us all with 2h :) [23:04] I heard COB Wednesday, though personally I'd been shooting for COB Thursday; but I shouldn't imagine a few hours will make a whole lot of difference either way [23:05] slangasek, eeek [23:05] ah, I fail at timezones yet again [23:05] so, I asked for a one-line summary of each of your feature goals (something of the form "name of goal: where it's at" would be fine) [23:06] how about we go in reverse order, since ogra was expressing concern [23:06] ogra: [23:06] (cjwatson: there was apparently a precedent in the wiki that freezes start at 0000UTC on the given day; we diverged from this for hardy, reinstated now for intrepid, sorry to catch people flat-footed) [23:06] well, still busy getting the latest ltsp upstream changes in [23:06] According to my clock, FF is in 114 minutes [23:07] slangasek: there were older precedents yet that were different again, of course ;-) [23:07] heh [23:07] we've gone through various interpretations [23:07] my only left goal for intrepid was compcache: implemented and running fine [23:07] (just getting it into ltsp) [23:07] that was certainly the only major item [23:08] I'm very pleased with how memory use has come out so far on the desktop CD, and I gather there's more room for tweakage [23:08] yeh, definately [23:08] * ogra is hoping for 24M ltsp client support [23:08] ogra: edubuntu-menus-completion and local-content-filter deferred, I take it? [23:08] yeah [23:08] I thought that was likely [23:09] and though i'm likely moving teams now, i'D still like to go after the content filter stuff [23:09] (trying to get to that since the sydney UDS where i had to take edubuntu to actually get the spec :P ) [23:10] heh :) [23:10] ogra: on that note, remind me to give you a ring tomorrow [23:10] oki [23:10] doko is on holiday [23:11] of his feature goals, OpenJDK seems pretty happy at this point barring a few glitches the server team would like to be cleared up [23:11] Python 3 was only ever preparation for the future [23:11] TheMuso: [23:11] dmraid: Complete bar no event monitoring due to broken code and incomplete upstream tarballs. [23:11] desktop a11y review: Deferred, dmraid took more time than expected. [23:11] Hola [23:12] doko: oh, hiya [23:12] audio: due to the kernel fuss nothing has been uploaded yet, although things are almost ready on my end, just need to test check and upload alsa pieces. [23:12] pulseaudio I'd rather PPA test, and if people really want it, we FF for it. [23:12] TheMuso: though dmraid not yet promoted to main - I'll get to that before the deadline [23:12] cjwatson: Ok no problem. [23:13] right, for those who haven't noticed, the kernel team is pretty set on trying out 2.6.27, but acknowledges the regression risk so we're going to be pretty careful about it [23:13] I doubt I can get all of alsa done before FF, but I'll see... [23:13] https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan is the plan and timeline [23:13] TheMuso: can we at least get a fix for the also through pulseaudio by default thing? [23:13] we're going to have to switch up to .27 in intrepid in order to get certification testing done, but that's not necessarily final [23:13] TheMuso: otherwise we will end up with flash blocking sound device [23:14] TheMuso: i know that the current fix isnt kde compatible. [23:14] asac: Yes, I need to reread up on everything to work out what exactly has to be done but yes, that is regardless of pulse version [23:14] but maybe that should be solved on a package base somehow (if we cannot find a real solution) [23:14] TheMuso: ok. as long as you keep in line tha tthis is really a big show stopper and we need a solution i am happy ;) [23:15] s/in line/in mind/ [23:15] TheMuso: do you have some skeleton disk images that people could use in a vm to do basic dmraid testing? [23:15] cjwatson: Yes, but thats not really useful. [23:15] something of the form "create zero-filled images, and run this dd command" [23:15] Other than testing whether everything fits together. [23:15] I would find it very useful to be able to try out the installer and suggest possible improvements [23:15] but yes, I do have images. [23:16] 23:10 doko is on holiday [23:16] 23:11 of his feature goals, OpenJDK seems pretty happy at this point barring a few glitches the server team would like to be cleared up [23:16] 23:11 Python 3 was only ever preparation for the future [23:16] TheMuso: thanks [23:16] doko: anything you want to add? just a very quick run-down [23:16] cjwatson: I'm going to blog/post to devel about dmraid anyway, so I will put the images up somewhere for people to download. [23:16] TheMuso: great, thanks [23:17] cjwatson: I will upload python3 next week, including with a few modules how python3 modules sould be packaged. [23:17] I didn't see any critical reports about OpenJDK [23:18] the server team wanted to get bugs 261847 and 249178 cleared up [23:18] Launchpad bug 261847 in openjdk-6 "Installing openjdk-6-jre-headless pulls in dbus/avahi" [Undecided,New] https://launchpad.net/bugs/261847 [23:18] Launchpad bug 249178 in ecj "libecj-java shouldn't recommend java2-runtime" [Low,Confirmed] https://launchpad.net/bugs/249178 [23:18] python3 should go to main however, because we want to build modules from one source package [23:18] that's going to bloat the size of all the python module packages again? [23:18] 261847 seems to be controversial [23:19] I don't see how that can be justified as a post-FF change [23:19] slangasek: no, not the binary ones, we'll have python3-XXX binaries [23:19] hmm, breaking the python policy instead, ok... :) [23:19] you can't have the same source used by both python 2 and 3, to a good first approximation [23:20] 249178 should be uploaded [23:20] so this is really something the python policy failed to predict :) [23:20] well, ouch [23:20] not breaking, but changing. [23:21] doko: 249178 is a two-parter, I understand: one using -headless, and one being a recommends change that I understand is disputed [23:21] they seem quite upset about all the X libraries being pulled in [23:22] I didn't want to overrule you in your absence; in any case this all seems to be under the bug-fix heading [23:22] well, yes, maybe we could drop this recommend, now that we have java-gcj-compat and java-gcj-compat-hl. I'll do this next week [23:22] I mean: dropping the recomend of libgcj9-0-awt in libgcj9-0 [23:23] doko: thanks for the update; we'd best move on, as time is pressing [23:23] liw: [23:23] CleanupCruft: package almost ready, gui sucks but works, need to find how to do root from gui [23:23] DebianPolicyInDocbook: ignored [23:23] FastLsbRelease: ignored [23:23] GetRidOfPythonCentralAndSupport: not ready, lots of work needed [23:23] GobbyServerPersistentState: my patch works, upstream now maintains package and has corresponding patch (which I should review) [23:23] LintianHarness. ignored [23:23] NoFsckAtBoot: deemed semi-impossible, but ubuntu-devel(-discuss) has had similar discussions [23:23] PythonProfilingTool: playing with Heapy (it does work!), but no concrete results [23:23] SuperPiuparts: deferred [23:24] perhaps somebody could help liw out with the last bits needed for cleanup-cruft [23:24] what is needed? [23:24] policykit? [23:25] should I run gksu (what update-manager seems to do currently) or go straight for policykit? [23:25] ah ... root from gui ;) [23:25] AIUI we're well on the path for transitioning to policykit, so better if new stuff uses that? [23:25] liw: policykit, though it may require architecture changes [23:26] and may require frustration [23:26] ok, policykit it is (unless it looks too difficult, in which case I'll go for gksu, call it a bug, and fix it to use policykit later...) [23:26] Policykit please, for accessibility reasons. [23:26] gksu is not an option. :p [23:27] I know pitti recently converted to policykit, so he may be able to help, and I have a basic knowledge, so I'll help if I can [23:27] pitti is on holiday at the moment [23:27] james_w, thanks, that'll be helpful [23:27] as is, I gather, most of the desktop team :P [23:28] liw: thanks, better to get system-cleaner into the archive while a bit suboptimal than to leave it until it's too late; we still have time for bug-fixing and polishing provided the basic functionality works [23:28] cjwatson, ack [23:28] james_w: it's been a while since we talked about UDD. What's the good word? [23:29] I've got bzr-builddeb 2.0 in bzr since about an hour, that has the features I think we need for Intrepid. [23:29] I'd love a sponsor (perhaps for Debian as well, but that's less important) [23:30] if not I can get an FFe and have my usual sponsor upload [23:30] I don't see it on https://code.edge.launchpad.net/bzr-builddeb ? [23:30] the rest is not bound by feature freeze, and hasn't moved in the last couple of weeks [23:30] bzr http mirror syncs are broken i think [23:31] hmm, worked for me earlier today [23:31] strange. then thats just affecting the mozillateam branches ;) [23:31] cjwatson: I also tried to upgrade the alioth branch that it mirrors from at the same time, so there may be a delay [23:31] (but havent checked today) [23:31] http://bzr.debian.org/pkg-bazaar/bzr-builddeb/trunk if anyone is interested [23:32] interested, but otherwise occupied at the moment [23:32] james_w: I'll be up for a little while after the meeting, and can sponsor [23:32] cjwatson: great, thanks [23:32] bzr: ERROR: No repository present: "http://bzr.debian.org/pkg-bazaar/bzr-builddeb/trunk/" [23:32] EHOSEDBRANCH [23:32] cjwatson: just fixed that, there's a bug in bzr I'll report [23:33] not EHOSEDHOSTING? [23:33] (I can't seem to get http transport to work for bzr.debian.org for my stuff, maybe I'm doing it wrong) [23:33] slangasek: I shall withhold my comments on the delays involved in getting new branches created on bzr.d.o [23:33] slangasek: try nosmart+http:// [23:33] slangasek: *another* bzr bug, fixed in 1.6 [23:34] which leads me to [23:34] james_w: hum, ok :/ [23:34] bzr* updates: all lined up as sponsored sync requests, thanks to LaserJock and jelmer. Probably bugs to fix in 1.6, but we definitely want its features. We shou [23:34] ld evaluate 1.7 in 3 weeks. [23:34] slangasek: assuming it's the bug I think it is. [23:34] james_w: I don't suppose we'll get 1.6 into lenny...? [23:34] (I imagine not) [23:34] just about every problem I've run into in the last couple of weeks has been "fixed in 1.6" [23:34] slangasek: it's in experimental, but no-ones pushing for it [23:34] (including the ones that had nothing to do with bzr) [23:35] cjwatson: fwiw, I haven't had problems with getting bzr setups done for bzr.d.o [23:35] slangasek: I should investigate backporting the fix. [23:35] 1.6 was a real pain of a release, I think it may have reached 4 months. [23:35] pretty bad for a monthly release project [23:37] the rest of my list: [23:37] font-selector: nowhere, sorry. [23:37] lvm .39: done, thanks to TheMuso. [23:37] mono-tools: still needs MIR for webkit-sharp, though could be sponsored as-is I [23:37] believe. [23:39] james_w: ok, thanks [23:39] evand: [23:39] * usb-installer-images: Mostly finished. I just need to figure out [23:39] why an io_watch isn't promptly firing, polish the code and UI, and [23:39] pick a name (suggestions welcome). This will be done in time for the [23:39] feature freeze cutoff Thursday. [23:39] (written before the above conversation) [23:39] * dvd-performance-hacks: Mostly done. Just need to merge in my [23:40] ubiquity changes and triggerize packages. [23:40] * ubiquity-visual-refresh: The partition bar work has been committed [23:40] to ubiquity trunk. I did not manage to coordinate the slideshow work [23:40] in time and will have to defer that (though I'll continue working with [23:40] the art and documentation team to obtain the required media for it [23:40] during the remainder of the 8.10 cycle). I am going to apply for a [23:40] feature freeze for the timezone map changes for over the weekend as [23:40] I'm having some difficulty with rsvg and locating the mouse within a [23:40] particular time zone. If the work fails to produce effective results, [23:40] slangasek: the usb installer stuff is largely (afaik) a new package, so I think the regression risk is pretty low; can we manage the one-day slip there? [23:40] I will work to fix the remaining usability bugs in the previous [23:40] timezone map. [23:41] cjwatson: yes [23:41] thanks [23:41] evand: if you could push the ubiquity branch for dvd-performance-hacks somewhere, I can have a look at it for you [23:41] Speaking of slips, I can get alsa uploaded today, but it won't all be before FF. Is this ok? [23:42] /msg evand name suggestion for the usb thing: gloffod (glorious freedom from optical disks) [23:42] cjwatson: will do [23:42] james_w: pitti and I will clean up MIRs next week [23:42] TheMuso: what part is going to be past FF? [23:42] doko: great, I'll try and get it written before then [23:42] thanks liw, any other suggestions? [23:42] slangasek: Getting lib/utils/plugins in. [23:43] evand: I'm looking forward to having a look at the partition bar work; you should blog about it :) [23:43] (can be mailed so we don't eat up time here) [23:43] TheMuso: hmm, you said it won't /all/ be before FF... will /any/ of it be before FF? :) [23:43] cjwatson: blog? I don't think I've done that since Summer of Code ;) [23:43] yes, I know ;-) [23:43] slangasek: i think he ment that this upload will take a few more hours [23:43] (but thats just what i read from it) [23:43] slangasek: lib likely will be yes. [23:43] oh ok ;) [23:44] TheMuso: ok. yes, that'll be alright. [23:47] on my own bits: [23:47] recommends-by-default: germinate updated and all seems to be working, although some people have requested the ability to exempt certain recommendations from CD building. We may be able to do something about tha [23:48] t. [23:48] splitting server and mobile into separate branches and metapackages: not done, will probably wait for archive-reorganisation. [23:48] archive-reorganisation: call tomorrow morning with Mark to iron out some details. I think we have high-level agreement though and it's on the LP 3.0 plan. [23:48] policy-and-standards: initial version of Ubuntu policy uploaded; need to reinstate pristine debian-policy and repackage but that's no big deal. [23:48] recommends-by-default, any idea what to do with the lilo dep of linux-image-* ? [23:48] also been helping out the server team with some installer bits, but I think my end is done and any FFEs they need are their business :) [23:49] ogra: I think that's wrong under the definition of Recommends and should be dropped? [23:49] 5~/c [23:49] slangasek, well, lilo seems to be still wanted ... [23:49] you can also use --no-install-recommends as a stopgap measure [23:49] it's not appropriate as the first alternative [23:49] yeah, thats what i switched ltsp to now [23:49] oh, it's linux-image-* that was Recommending lilo? [23:49] yes [23:49] since my chroots just explode with recommends ... [23:49] yeah, shouldn't be the first one, anyway [23:50] right and lilo in a chroot isnt really fun :) [23:50] for minimal chroots I think --no-install-recommends is entirely appropriate [23:50] they aren't the usual case [23:50] i was fearing i miss anyhing .. [23:50] but it seems to stil work fine [23:51] wont be the caes if we start to rely on recommends [23:51] *case [23:51] if we follow the definitions properly, it should be fine [23:51] right; for a minimal chroot, --no-install-recommends is precisely how one finds out if a recommends should've been a depends instead :) [23:52] heh [23:52] calc: [23:52] ok [23:52] OOo 3.0 rc1 is delayed again until sept 1 [23:53] i am working on OOo 3.0 packaging split and hope to have some debs in PPA by the end of the week (maybe not all packages though) [23:53] potentially having OOo 3.0 split packages parallel installable [23:53] parallel alongside what? [23:53] slangasek: the regular debs, if the 3.0 release slips much more we may have 3.0 split debs for test and 2.4.1 debs for the main install [23:53] calc: is this the mmeks split? [23:54] my suggestion was, by way of having some concrete progress on OOo this cycle, to produce openoffice.org3-* modularised packages [23:54] doko: yes [23:54] ah :/ [23:54] right, that's better than getting stuck with prerelease 3.0 packages at release time [23:54] slangasek: yea [23:54] and to use those as a guideline for the observable quality of 3.0 [23:55] slangasek: they still have sept 16 listed as release date, but that looks awfully optimistic [23:55] realistically we aren't going to get much feedback until there's something in the archive, but it seems like they're slipping too much for us to commit to 3.0 [23:55] that's my take on it, anyway ... [23:56] yes [23:56] * slangasek nods [23:56]