=== stalcup is now known as vorian [03:20] do FTBFS qualify for SRU by themselves, or do you need another bug to upload it with? [03:21] micahg: That's generally sufficient. [03:21] ScottK: does that include something that if rebuilt at the moment, it won't build, but not on the FTBFS list? === vorian is now known as oldschool === oldschool is now known as obama === obama is now known as heHATEme === heHATEme is now known as TheMaster === TheMaster is now known as master [03:27] master: identity crisis? [03:27] micahg: always [03:27] :P [03:39] micahg: If the package is not out of date (e.g. the binary in the archive is built from the current source), then I don't think it's SRU worthy. it would be documenting in a bug how to get it to build if a package update were needed for other reasons. [03:41] ScottK: well, the issue is gnome-chemistry-utils, an update to libgdk-pixbuf makes it so the current source cannot build anymore so if an update was needed, that would need to be fixed [03:42] Right, but since an update isn't otherwise need it, I think it's sufficient to document what needs changing. [03:42] (for maverick) [03:42] Fix it in Natty after it opens, of course [03:43] ScottK: k, will keep in mind, thanks [03:44] micahg: Also I'm not on ubuntu-sru, so that's just my opinion. === master is now known as vorian === zooko is now known as storageclient === storageclient is now known as zooko [06:45] is it possible to do syncs from Debian to -proposed (Just a new Debian revision, not upstream)? [07:10] do I need SRU even for a theme update ? [07:12] AnAnt: what do you mean? [07:12] micahg: I wanted to update plymouth-theme-sabily package, does that require an SRU ? [07:13] AnAnt: at this point, yes [07:13] AnAnt: that or a backport [07:22] ScottK: Hello [08:39] hyperair: would you be willing to comment on my MOTU app? [08:40] i could try later, but not now. i'm preparing for a barcamp talk [08:40] hyperair: k, no rush, I'm not applying for 2 weeks [09:01] Will there php 5.3.3 backport for lucid LTS? [09:01] chalet16: not in the archive [09:02] mean that there is no plan for offical backport? [09:07] ttx: there's no possibility of officially backporting PHP, right? [09:07] micahg: I'd say no... but you can ask the question to zul for a definite answer [09:08] I thought I asked once, but I can't seem to find a record of it [09:09] chalet16: normally security updates and high priority fixes are provided, but not new versions for PHP, looking at the history of the last 5 releases [09:09] for backports too? [09:13] chalet16: well, it hasn't been backported in the past, you could ask the server team what it would take to have it backported, #ubuntu-server or ubuntu-server@lists.ubuntu.com [09:14] ok [09:14] thanks [09:14] chalet16: mailing list might be better since it's the weekend [09:14] ok === JPM is now known as JPM[Stellenbosch === JPM[Stellenbosch is now known as JPM[STB-CPT-ZA] === JPM[STB-CPT-ZA] is now known as CapeTownParty[st [10:49] Are there troubles with the launchpad debbugs connection? It doesn't seem to update the bug status at all since a pretty long time now, keeping Debian bugs still listed as New :/ === CapeTownParty[st is now known as CapeTownParty [10:57] Rhonda: I think it used the public bts mirror which was on merkel [10:58] That's part of it. [10:58] And it's the main problem now. [10:58] But it's not the original issue. [10:59] ajmitch: Hmm, then I think that might have changed, there were a fair amount of parts going on with merkel. [10:59] Right, it's gone. [10:59] Without a replacement :( [11:00] Did anyone ask don about it? Or was it just accepted that it's gone? [11:00] The email about it said it probably wasn't going to be replaced. [11:01] that could have been because there wasn't any public outcry about it [11:01] * ajmitch only asked in #debian-qa, didn't ask on a mailing list === persia changed the topic of #ubuntu-motu to: Maverick is released. Lots of SRUs to be done. | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/ | latest rebuild failures: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi [11:20] good to see another release [12:13] geek farming [12:13] Hrm? === bilalakhtar_ is now known as bilalakhtar [16:11] didrocks: so you want us to carry the eclipse patch in debian until a better solution is found? [16:11] bdrung: if you are willing to, I think that's the best option [16:11] bdrung: sorry, I wasn't clear enough? [16:12] didrocks: it wasn't very clear. i'll take care of it. just let us know once it should be changed. [16:13] bdrung: sure, I'll (hoping that we can export the menu through dbus for those apps in natty) [16:43] Oh. Ah. I think it's time for another packages.ubuntu begging-for-applying-changes round. [16:44] * Rhonda . o O ( No, haven't commited yet ) [16:44] Has natty got created yet? [16:45] Nope. Be a few days, at least. [16:45] There's usually a mail to u-d-a when the new archive is really open (post-toolchain-fussiness) [16:45] Then I guess I don't have to rush the commit. Is any release EOLed now? [16:46] Rhonda: jaunty won't be EOL for another 13 days [16:46] But dapper is gone? [16:46] Nope. That lasts until sometime in June 2011 [16:47] Rhonda: not on server for another 8 months [16:47] http://wiki.ubuntu.com/#Releases doesn't mention it anymore? [16:47] (although it's hoped most of the remaining dapper users will have been able to update to lucid in the next 3-4 months) [16:48] * persia edits [16:48] micahg: Hmm, I guess I'll remove jaunty right ahead from the packages code, I have very little hope that the changes will get applied within the next 2 weeks. Or 2 months, FWIW. [17:03] debian-www: rhonda ubuntu-master * r8838986 packages/ (3 files in 3 dirs): Add maverick, remove jaunty [17:05] http://git.debian.org/?p=webwml/packages.git;a=commitdiff;h=8838 - yet again the changes to config.sh.in needs to get applied to the config.sh file on the server after the git pull. [19:42] Does anyone haves any suggestions for packaging training sessions that they would like to see or does anyone want to volunteer to give one? [19:51] nhandler, https://wiki.ubuntu.com/MOTU/School/Requests is full of ideas [19:51] Some of them are pointlessly obsolete at this point. [19:52] persia: Yeah, and many of them have been done as well (we had copied them to Packaging/Training at some point) [19:52] Might be worth decommissioning that page then :) [19:52] I still should do my git talk me thinks at some point. [19:53] With a new cycle starting, it might be worth having one about UEHS: new upstream, bug fixes, bug forwarding, etc. [19:56] persia: True. We had a few on bug forwarding in conjunction with Project Cleansweep. And I'll look through the MOTU/School pages to see if there is anything valuable that hasn't been merged into other pages yet and get rid of the page if not [19:56] nhandler, Please keep w.u.c/MOTU/School as a page, but maybe rewrite to talk about history, and move all the real content over to Packaging/Training. [19:57] All the subpages can probably go at this point: Packaging/Training has long taken over, and we'd do better to not be confusing. [19:57] * nhandler nods === hannesw_ is now known as hannesw === andreas__ is now known as anoteng [22:26] does anyone have an information how many merges were available when lucid/maverick started? [22:28] I think MoM has some historical statistics, used for the charting. [22:29] They have minor inaccuracies for complex reasons, but it ought be correct to within less than a percentage point. [22:29] Note that Natty will open with fewer pending Debian changes than usual: one of the best ways we can ensure Natty has new and updated software is to help Debian release Squeeze. [22:33] persia: look @ https://merges.ubuntu.com/main-trend.png [22:34] it looks like history, but the number is strange - 4000? [22:34] Right. Those would be the historical statistics from MoM [22:34] Might be a count of packages in main. Might be a count of all packages that were ever in main. Check the code. [22:35] persia: good point, red color is interesing for me. [22:35] but in this case is not good readable [22:36] No, it isn't. [22:36] You might look at the MoM code to see how they are generated: it may be that you can get something closer to what you seek from that. [22:37] persia: but from universe trend we can compare 2 points - red line with lucid release and with maverick release [22:37] the conclusion is following: we've reduced a lot of merges during maverick cycle [22:37] Anyway, the current MoM information is very likely to be of limited use, as either squeeze will release before DIF, meaning everything needs to be remerged, or it won't meaning we'll have a huge swath of DIFes to process, which probably requires coordination or something. [22:38] Sure, but that doesn't reflect on us: it's also that Debian has been frozen for most of the Maverick cycle, so there's less to be merged. [22:38] also, the number of to-merge packages are smaller in universe than to-merge in main! [22:38] it's nice achievement [22:38] This is not uncommon. Stuff in main tends to get tweaked more, and historically there has been weaker coordination with Debian. [22:40] If you're willing to track history further, you might notice that for the 5.04 cycle, there were *zero* pending merges in universe. [22:40] persia: I trust, but number of packages is growing up always [22:40] :) [22:41] No, I think we got a reduction in total packages for feisty->gutsy by clearing out a bundle of stuff. [22:41] But there are usually more, indeed :) [22:41] persia: so working on Debian RC bugs in Debian at this point is like working on Ubuntu? [22:41] micahg, Yes, in two ways. [22:41] persia: cool, will keep in mind [22:42] Firstly, by solving the Debian RC bugs, we get to apply those fixes in Ubuntu, to issues that are likely RC (and probably ought be SRUs) [22:42] Secondly, by helping Debian release squeeze, we allow the hundreds of Debian Developers to easily upload the newest upstream stuff, and we can autosync it. [22:43] So, it's fixing 200 bugs that we need to fix anyway to get ~1000 extra developers helping us get new software. Seems more than a fair tradeoff to me. [22:43] yep [22:44] persia: I would believe that sync package which fixes RC bug is enough. [22:47] ari-tczew, sync from where? The RC bugs need to be fixed *in Debian* [22:48] persia: so what about column Fixed Version ? [22:49] http://qa.ubuntuwire.org/bugs/rcbugs/ [22:49] ari-tczew, Those are RC bugs that have already been fixed in Debian but aren't yet fixed in Ubuntu. We need to review them, and if they are critical for Maverick, SRU them. [22:50] ari-tczew: I think persia means we need to fix the RC bugs not on the list yet in Debian, so they can be sync'd to Ubuntu [22:50] http://bts.turmzimmer.net/ is a reasonable place to look for RC bugs that need to be fixed in Debian [22:51] micahg, Actually, at this point in the Ubuntu cycle, I think it's more important to get squeeze released than to worry about syncs (especially as we're supposed to cherry-pick for SRUs) [22:52] persia: right, I meant after squeeze was released [22:52] these days: there's also http://udd.debian.org/bugs.cgi [22:53] UDD is making all my carefully memorised URLs obsolete [22:54] heh [22:55] persia: yeah I never remembered turmzimmer [23:50] persia: do you remember today case about plymouth bug? [23:50] Yes. [23:50] persia: I found resolution (note: work-around) for this problem. [23:51] Excellent! [23:51] So you have a graphic logo now? [23:51] but I didn't use this, because I want have system to fix the patch, not work-around script. [23:51] I can suggest people affected by this bug to use workaround [23:53] persia: http://techblogparade.blogspot.com/2010/09/fix-ugly-plymouth-screen-on-ubuntu-1010.html [23:56] Oh, too bad. I was hoping for something sharable. [23:56] At least it makes your device pretty :) [23:57] Maybe it's worth talking to the #ubuntu-x folks about considering something like that for postinsts or something. [23:57] * persia isn't sure that would really work for everyone, but it works around the limited kernel support from the binary drivers, and confirms that it isn't a bug in plymouth [23:58] Detecting BIOS-settable resolutions is somewhat of a black art. [23:59] RAOF, Do we not have EDID info when we use those drivers? [23:59] The EDID isn't what we're after. [23:59] What do we need beyond resolution and bit depth?