[02:26] Hi guys, a tester for Mixxx found another semi-bad-ish bug in Ubuntu 10.10 - https://bugs.launchpad.net/mixxx/+bug/642606 [02:26] Launchpad bug 642606 in Mixxx "Mixxx 1.8.0 > background color in library " [Undecided,Confirmed] [02:27] The background color in our library isn't being styled properly by the Qt 4.7 RC that's in 10.10. (It works fine in Qt 4.4/4.5/4.6.) [02:27] We're also about 1 or 2 days away from dropping a Mixxx 1.8.0 final tarball which contains more bugfixes compared to the 1.8.0 RC that's in Universe right now. [02:28] What's the best course of action here? [02:28] TheMuso: I might call your attention to this too [02:29] asantoni_: Ok, getting a new upstream release in this late may be difficult, but its up to the release team to make that decision, given all the necessary information presented. [02:30] TheMuso: How can I get in touch with the Release Team? [02:31] asantoni_: Easiest way is to file a bug requesting a feature freeze exception, as documented on https://wiki.ubuntu.com/FreezeExceptionProcess. [02:31] TheMuso: Excellent, thank you very much [02:31] np [02:36] asantoni_: Feel free to ping me once you have the bug filed to review it (I'm on the release team). [02:36] thanks ScottK [03:25] hey guys, we've traced this Mixxx-ugly-white-colours bug down in the Qt bug tracker, and apparently the fix is targeted for Qt 4.7.1 :S [03:25] see: http://bugreports.qt.nokia.com/browse/QTBUG-13125 [03:26] and a possible work-around that we're going to play with: http://bugreports.qt.nokia.com/browse/QTBUG-13471 [03:28] asantoni_, I think we'll need the workaround for maverick, as we're exceedingly unlikely to get an updated Qt. [03:30] I don't think Qt has even been patched upstream yet [03:30] doesn't look like it, at least [03:36] yeah, bummer :S [03:37] I posted a menacing screenshot in the Qt bug tracker to try to illustrate how ugly the bug is for us === JanC_ is now known as JanC [03:41] We'll be lucky to get 4.7.0 final in before release. [04:21] persia> They closed the Opinion status bug as Won't Fix. [04:21] Ah the irony. [04:24] Actually, I appreciated that. Setting it to "Opinion" would have been frustrating :) [04:25] I'll admit though that I'm surprised you didn't reference it in your recent post that included a discussion of "Opinion" [04:25] I'd still like to hear some rationale for the decision: none of the points I raised seem to have been addressed. [04:25] which bug # was this? [04:25] 642637 [04:26] aha [04:26] If folks comment, please restrict yourself to reasoned argument: I'd hate to see that bug get noisy. [04:27] the only comment I'd have about it was given in the first reply to you, that it was already intended as a final state [04:28] to be less harsh wording than "won't fix", but effectively the same [04:28] Indeed. I really didn't expect it to get anything other than Won'tFix, and only submitted the patch because it was dead-easy, and someone suggested it would get faster consideration that way. [04:28] It's the "effectively the same" bit that bothers me, as noted in comment #3. [04:30] right, I'm trying to find where I read the justifications for this originally [04:30] deryk wrote it up in a blog posting. [04:49] persia> Well, the "Opinion" status wasn't really the point of my recent post, it was just a minor side-rant :) [04:49] heh. [04:54] * lucidfox pokes YokoZar again [04:54] hi [04:55] There is a patch applied to wine1.2 in the vivnet repository that stubs a kernel32 function without which the WoW Cataclysm and 4.0.1 launchers crash [04:55] think we could apply it to the Ubuntu version? [04:56] I'm investigating the crash now [04:57] And I don't mean the crash of WoW itself with the Ubuntu kernel - that's a different bug [04:57] oh [04:57] you mean the launcher thingy [04:57] lucidfox: is that kernel issue fixed? [04:57] ajmitch: it is upstream, I'm not sure if it's fixed in Ubuntu because we also have the ptrace changes causing a crash at the same point [04:58] * ajmitch hasn't tried wow on maverick yet [04:58] Last I checked (that was 2.6.35.21, IIRC), it was still occurring with all the Ubuntu kernels, but not with the mainline ones [04:58] ajmitch: I'm working on a wrapper for Wine to give it cap_sys_ptrace as a workaround [04:58] I've been running WoW with mainline kernels ever since I installed Maverick [04:58] lucidfox: Ubuntu kernels also enable ptrace protection that mainline doesn't iirc [04:58] no WoW means that maverick should be delayed, right? [04:58] LOL [04:59] there are more WoW users on Ubuntu than music store buyers I'm pretty sure [04:59] YokoZar: you're probably quite right [04:59] * YokoZar stews over not having his sponsorship accepted [05:00] * ajmitch happens to have the background downloader running at the moment :) [05:00] YokoZar: don't worry, you're not alone, though you've done a lot more than many of us have :) [05:01] lucidfox: is that patch in wine1.3? [05:01] moment [05:02] ajmitch: Is it still -Part-2? [05:02] YokoZar, Don't let that stop you from coming to UDS. [05:02] StevenK: sure, I'monly about 400MB into it too [05:03] persia: as you can probably imagine, flights cost a bit from this part of the world :) [05:03] ajmitch: I've got both -Stage-{1,2}, if there was a -Stage-3, I was going to fire it off [05:03] YokoZar> Here's the patch for the Cataclysm/4.0.1 launcher: http://paste.ubuntu.com/497460/ [05:04] ajmitch, For you, sure, for YokoZar, I thought it was less problematic. When we have UDS in NZ, I expect you there regardless of whether you get sponsored :p [05:04] persia: it's a matter of cash. I just decided to book my flight for wineconf and I'm not sure if I can afford both [05:04] persia: somehow I doubt it'll be anywhere that I can get to in less than 12 hours travel time anytime soon :) [05:04] But doctormo is organising some lodging that costs something like 15-30% of the official rate. [05:04] YokoZar> It's also applied in Wine 1.3.3 [05:05] YokoZar, Understood. I'll wish you luck planning, and hope to see you. [05:05] lucidfox: ok that makes me much ahppier about backporting it [05:05] Where do you people get money for all these flights :( [05:05] * StevenK has a job [05:05] Well, it was a rhetorical question :p [05:05] lucidfox: we don't, that's why we don't attend :P [05:05] * YokoZar thinks StevenK saw "WoW" in chat and instantly had his attention [05:05] it just... sounds like a waste to me, personally... [05:05] Hush [05:06] UDS in person is way more productive than UDS remotely [05:06] lucidfox: depends on how much you really need to be there to push some ideas through & get some support & hopefully interested people [05:06] I'm not prepared to blow such large sums just for the privilege of meeting with the Ubuntu community [05:06] persia: I have an aunt who lives about an hour away from the conference too [05:07] ah, good to see some 'feedback' on the post-release apps process on planet ubuntu/omgubuntu :) [05:07] Well, given that I'm basically Ubuntu's grumpy bear, I doubt anything I say would change anything about how Ubuntu development works, in the slightest [05:07] YokoZar, Then it's just flights. Good luck with your budgeting. [05:07] lucidfox, Don't underestimate yourself. [05:07] lucidfox: you're hardly grumpy [05:08] lucidfox: Then ask for sponsorship, then you don't have to? [05:08] lucidfox: Or, don't go and grumble about it :-) [05:09] I do too little to deserve sponsorship, really [05:09] You could always contract with some group to manage their software in Ubuntu, for small regular monies + large travel budget :) [05:09] * StevenK hasn't done anything for Ubuntu for the entire cycle and is still going to UDS. [05:09] * persia knows a couple people who do that and regularly get to UDS [05:10] persia: what would be nice is to have some sort of marketplace for that, but that's a *whole* lot of trouble right there :) [05:10] StevenK, Yes, but we want you there so we can complain at you about the tools we use :) [05:10] StevenK: but you're spethial :P [05:10] Well, I don't know [05:10] ajmitch, Why trouble? [05:10] I don't know how you're still remotely sane after hacking on soyuz [05:10] on one hand, I don't care enough about UDS to blow my own money on such expensive trips [05:10] on the other hand, I still can't help but feel sad [05:10] ajmitch: I'm not? [05:10] persia: the usual trust issues, trying to setup payments, etc [05:10] StevenK: true [05:12] ajmitch, Oh, I guess. I thought you just meant a place for folks to post RFQs. Actually managing everything is trouble indeed. [05:12] ajmitch: He can't still be sane. [05:12] It's been several months now. [05:12] wgrant: we know that you're long beyond hope :) [05:13] * StevenK even has a special jacket for wgrant to wear. [05:13] persia: just a vague idea that I had, no reason why it'd have to be done that way I guess :) [05:13] It has long arms for extra warmth ... [05:13] ...and grommets for improved security [05:14] you wouldn't want it to fall off somehow [05:14] Hey, I am recovering my sanity after not hacking Soyuz too much lately. [05:14] * StevenK deals wgrant a penalty card for 'Lying' [05:14] ajmitch, Nearly anything would be better than now, when it's mostly just random bits in the wider bespoke software/free software contracting realm. [05:15] wgrant, Hacking Malone does not give you a break from the sanity point loss inherent in hacking Soyuz [05:15] Heh. [05:16] Doing uni work also has an inherent sanity point loss [05:16] Which changes, depending on which unit you're doing work on at the time [05:16] persia: it could be a useful addition in terms of having some non-canonical involvement [05:16] wgrant: so when will blueprints die? [05:17] ajmitch, I'd argue it would be useful addition in terms of increasing the visibility of that involvement. I'm not sure the actual numbers would change that much. [05:17] persia: it could provide additional motivation for some people [05:18] Sure. I think it would also encourage folk who don't now to do things like ask for a time-spent-on-distro-maintenance rider on their sysadmin contracts or additional-cost-for-continued-distro-support for bespoke development contracts, etc. [05:20] I know of only a few people who've done some one-off projects, I think that having a available pool of willing developers can be useful in terms of companies wanting to offer some ubuntu support [05:22] Indeed. Needs a website, etc. Also probably needs approval from the trademark team. [05:23] might be worth writing up some ideas at least [05:23] I don't think we're allowed to sell "Ubuntu", but I do believe we're allowed to sell certain Ubuntu-related services. [05:23] just hang it off the ubuntuwire website :) [05:24] There are several cases where I'd have found it useful to redirect certain people to such a resource to find someone to do stuff. [05:24] Please don't conflate that with ubuntuwire. Ubuntuwire doesn't have many sponsors (and is sadly in need of a fundraiser drive), but some of them might not be happy hosting such a thing, as they are otherwise commercially active with Ubuntu. [05:25] I know, it was just a joke :P [05:25] * persia needs to find some repo from which one can apt-get install humour [05:25] IRC doesn't transmit it very well [05:26] wgrant: is ubuntuwire high bandwidth? [05:28] we do have the resources to host REVU no another ubuntuwire machine instead of the sparc host, but it just takes time to setup & none of us have sat down & done it [05:28] micahg: Not really, no. [05:28] We must move REVU at some point. [05:28] Since poor sparc is a little unloved. [05:28] wgrant: where is it currently hosted? [05:29] wgrant: you're probably more familar than I am with setting up a new kvm guest, I could probably look at migrating the rest as I find time [07:44] Hello again! The qtjambi team has been down in the cellar since last time I was here and remade the build system so that it's now possible to build qtjambi against system Qt. We most dearly want to add qtjambi as an official package in the ubuntu repos. How do we proceed? Have a look at http://qtjambi.sf.net for details. [07:45] borealis: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [07:46] Thanks, micahg, that seems to be the right place to start. [08:10] Concerning qtjambi, do we have to go through the whole application process, or is it possible for us to pick up on the work that was done previously? http://packages.ubuntu.com/search?keywords=jambi&searchon=names&suite=all§ion=all [08:11] borealis: sorry, you just need to update [08:11] Since last time qtjambi was represented in Ubuntu, there is a totally new team in place due to the fact that the Trolls left development. [08:11] borealis: but you'll need an FFe [08:11] !ffe | borealis [08:11] borealis: Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process. === ldunn_ is now known as ldunn [14:08] would it be unreasonable of me to blog that it's better to work with motu to get your packages in universe rather than use the new app-review stuff? [14:08] the way I see it, in universe you at least have the option of stable release updates, and your packages will at least be able to get into the archives and back into debian [14:08] as where with the app store stuff, when the app is somewhere in /opt it will never be able to make it into the archives anyway [14:09] highvoltage, I think it's worth wider discussion first. At UDS there were some various threads of conversation that suggested it might make sense to have the app-review program be an input system into the following release. [14:10] So one would create an app, and it would be reviewed, and it would be pushed to natty and maverick-extras, as an example. [14:10] And one would be told to continue working with the Ubuntu Developers to keep it in shape. [14:11] Mind you, I've not been following the program closely: these plans may have changed, but if they haven't, I'm not sure it's better one way or the other. [14:11] persia: are there any benefits to using the app-review program over using revu/universe? [14:11] A dedicated council of people responsible for making sure progress happens? [14:11] highvoltage: revu is badly backlogged? (plus you can get into the current stable release) [14:12] Oh, and one gets a free-pass-automatic-backport for install on end-user systems. [14:12] So, if REVU worked well, I don't think we'd need this. [14:12] also, if packages that came in via REVU didn't die of bitrot [14:12] tumbleweed: maybe some things on http://www.omgubuntu.co.uk/2010/09/ubuntu-application-review-process-announced-restrictive-rules-galore/ are wrong or misguided then [14:12] Also, if a couple annoying (but exceedingly hard) bugs were fixed, we'd be using backports for this. [14:13] tumbleweed, Not all die of bitrot. Lots gets through REVU, just nothing like the volume submitted. [14:13] persia: I mean once they are in, many rot [14:13] highvoltage, I believe that review to be fairly misguided. I'm not sure it's technically wrong, so much as from the wrong viewpoint. [14:13] (not that Debian doesn't have that happen too) [14:14] tumbleweed, Oh, you mean once they get into the archives? Depends on the motivation. I think we see less of that now that we're not telling people to learn to help by packaging something. [14:15] But, obviously, we could do some signficant work in documenting how to care for packages, and not closely documenting how to create packages (pointing folks at Debian or the ubuntu-app-devel folks) [14:17] highvoltage: I wouldn't hesitate. [14:17] ScottK: But you wouldn't. [14:18] StevenK: beat me to it :) [14:18] persia: I think it's reasonably obvious from the complete lack of action based on the feedback to the call for app review board candidates that there isn't much point in discussion. Canonical is going to do what they will do and the rest of us should too. [14:18] ScottK: hmm? [14:18] ScottK: you mean about the blog post? [14:19] highvoltage: Yes. [14:19] persia: yeah (although I'll admit I only got into deb/ubu dev when I had something I needed to package) [14:19] ScottK: ok, I'll do so tonight. I just have to do it tactfully, I don't want to appear to be anti-canonical or something [14:19] * bilalakhtar joins the discussion [14:19] highvoltage: Don't be anti-Canonical. Be anti-idiot. It's up to readers to tell the difference. [14:20] So by this we mean that packages in the new app-review thing will get sponsored faster since fewer integrity checks will be performed? [14:20] highvoltage: yes, I did find that OMGubuntu post rather misguided, the whole point of this excercise is to make it easier to get things into ubuntu after its released. (Some commenters addressed that) [14:20] The OMG! post i misleading [14:20] *is [14:20] even jono said that [14:20] The facts were accurate. [14:21] The call for members required folks to be core-dev or MOTU. If that's true, I don't know why it's bad. [14:21] persia: It didn't. [14:21] It said it would be good to be that, but didn't require it. [14:21] http://fridge.ubuntu.com/node/2095 says it did [14:21] Oh, "as a bonus" :( [14:21] Not all members are core-dev or MOTU. [14:21] Who isn't? [14:21] fagan [14:22] bilalakhtar: What was in the post that was factually incorrect? [14:22] ScottK: The attitude was incorrect [14:22] bilalakhtar: He's not allowed to have an attitude? [14:22] ScottK: There's nothing wrong in taking one's time to express oneself tactfully. [14:22] Ugh. There's lots of folk on that board who aren't. [14:22] It gave a feeling that this process was way too simple to get apps into Ubuntu [14:22] soren: There are also times when it's not particularly useful. [14:23] bilalakhtar, Why? [14:23] And by 'Way too simple', ben meant that it would be like 'Ask for review today and your app is in tomorrow!' [14:23] ScottK: Really? [14:23] persia: ^^ [14:24] bilalakhtar, I don't have any issue with that, given the right set of reviewers. I'm not confident of half the current reviewers. [14:24] soren: Witness the recent flap over the default configuration of evolution. The thing that got it reverted was OMG telling people to go spam the bug. [14:24] ScottK: factually incorrect: "a oneoff with no updates" - surely it'll allow security / bugfix updates, just not using this scheme to update packages already in the repo (i.e. bypassing SRU) [14:25] tumbleweed: That's what the process says, IIRC. [14:25] BTW, what is extras.ubuntu.com for? [14:25] That's where these apps will go after they are approved. [14:25] Will it be a separate repo handling these packages? [14:25] Yes. [14:25] ScottK: that's my problem with the OMG post, I'd like it to reference these sources [14:25] But it will be enabled by default. [14:25] So we have a repo that can be disabled :( [14:25] ScottK: where exactly does it say that absolutely no updates will be allowed? [14:25] ScottK: "Security bugs and problems are expected to be resolved by the application author" - that implies update uploads [14:25] Who all will have upload rights there? [14:26] https://launchpad.net/~app-review-board/+members (kinda) [14:26] There was a humongous thread on ubuntu-devel (or maybe devel-discuss) on this relatively recently. [14:26] persia: probably they are only for the review, but I think you are right [14:26] Technically it's not part of the Ubuntu distribution (like Partner is also not part of Ubuntu), so it's not really related to Ubuntu development. [14:27] ScottK: So can this be SRUed? [14:27] I mean [14:27] bilalakhtar: No idea. It's up to Canonical. [14:28] bilalakhtar: you'd probably have to submit updates to the review board or something, I doubt it would follow any standard kind of sru process as we know it [14:28] ScottK, Is it so firmly something from Canonical, rather than something that can be recovered? The little I've heard about it seemed not unpromising, but from what you say now, I worry. [14:29] persia: My assessment if the long ML thread is that there was lots of constructive feedback from the community and yet the plans have moved forward. [14:30] There were some minor changes like installing in /opt, but the bulk of the concerns were (as at UDS) not addressed. [14:30] well, every now and then people are being told to get new packages into Debian and not Ubuntu, and now this thing has come [14:30] Ah, so in fact this can't replace our current broken processes, and we need to revive them anyway. Oh well. [14:31] * persia was hoping for a get-out-of-revu-free-card [14:31] persia: It's not our process that's broken, it's the lack of resources to execute it. This will only aggravate it. [14:31] persia: some explenation of some of the rationale behind some of the decisions would be nice. for example, why insist on non-standard packaging? it kind of irks me that they encourage people to take the time to make packages from free software that won't ever be able to be pushed back into ubuntu or debian [14:31] bilalakhtar: I'd say they should still get their apps into Debian in the long run [14:32] ScottK, Our process is broken because, as designed, it's not something we can execute. How it gets fixed (throwing people at it, closer coordination with Debian, more automation, brainstorm voting, etc.) is a topic for discussion. [14:33] persia: OK, but we have a fundamental resource shortfall that no amount of process will fix. [14:33] highvoltage: there was some discussion on on the mailing lists (as mentioned), the rationale for /opt (and no maintainer scripts) is to reduce the damage that these packages can cause. Hopefully in the future, moving towards some sandboxing protection [14:33] highvoltage, I suspect it was to avoid the implication that it was really part of Ubuntu, somehow, in compliance with the FHS. I'm not sure this was ultimately useful, but I haven't thought about it much. [14:34] No maintainer scripts? What? [14:34] ScottK, Well, maybe. We could do better at making folk want to participate in our processes. If people are packaging random stuff for PPAs, what makes that seem preferable than packaging random stuff in collaboration with us? I don't disagree with you, so much as think there are probably things we could do differently to make the shortfalls less painful. [14:35] Possibly. [14:35] I don't really like the extras.ubuntu.com name. [14:35] So this is going to come in the between of the familiar REVU process and the other normal ubuntu development processes [14:35] It makes it sound like it's part of Ubuntu. [14:35] Or at least run by Ubuntu. [14:35] Although I think the current situation is moving towards the logical result of easy access to PPAs. [14:35] And, the huge one [14:35] What will happen to the package once the next release comes? [14:35] bilalakhtar: It's unrelated to normal Ubuntu development. [14:36] ScottK: But it has to be, in some way I guess [14:36] No. It doesn't. [14:36] To explain my point, I take up the case of the current cycle [14:36] It's a separate repository controlled by a separate team with separate processes. [14:36] If X wants to get package Y into Lucid, what will happen to Y in maverick? [14:36] I think if you has said "To make any sense, it would be ..." I'd agree, but it doesn't. [14:37] bilalakhtar: You mean into the Lucid part of extras.ubuntu.com? [14:37] And if X gets Y accepted in Debian, then would Y be removed from extras.ubuntu.com? [14:37] wgrant: I am just explaining my point with release names [14:38] bilalakhtar: No. It's a completely separate system. [14:38] hmm [14:38] fine [14:38] The processes have clearly not been well though-through. [14:39] I wish more discussion had been had before everything was set in stone. [14:39] As there are many unresolved issues, and attempts to resolve them have been rejected. [14:39] But this is not the ultimate solution, since if it so happens that a so-called 'standalone executable' package needs to be depended upon by another package, for example, a program that wraps around it and provides a GUI for it, for example [14:40] and if the upstream developer of the second package wants things to follow the normal process and not this separate one, then? dependency problems... [14:40] sorry if my point wasn't clear [14:41] bilalakhtar, In cases like that, it would then need to be repackaged to fit in the repos. [14:41] (where extras.ubuntu.com doesn't count) [14:41] hmm [14:42] bilalakhtar: it will only work for leaf packages (I assume). And I'd guess that dependancies that aren't in Ubuntu will get bundled in with the app [14:42] Anyway, pointless to discuss at length here. With luck ajmitch, stgraber, and statik will impose some sanity, and mvo will be able to make sure it works to match that. [14:43] I wish they had chosen to spend the effort actually working on improving Ubuntu. [14:46] I'm not yet convinced that they aren't: to me there exists a possibility that the initial deployment will result in sufficient thought that something else can happen. [14:46] And since I trust half the gatekeepers (they already have root on all my systems), I'm hoping that this won't cause too much of a headache. [14:47] I first thought of applying for joining that board, but then now it appears it will only waste my time [14:47] Not having some gatekeepers I trust could end up as painful as early days of getdeb. [14:47] I can spend doing things better apart from that [14:49] bilalakhtar: meh. so do :) [14:50] highvoltage: already doing :) just upgrading a GNOME package from upstream [14:50] bilalakhtar, You have a freeze exception already? Otherwise, probably better to chase crashers, fail-to-run, fail-to-install, and fail-to-build. [14:51] persia: GNOME packages don't need FFe [14:51] * bilalakhtar has said that a million times by now :) [14:51] The output of `apt-cache unmet -i` is hug today. [14:51] bilalakhtar, They do during FinalFreeze (although they aren't as tightly controlled as other packages). [14:52] persia: What about a GNOME universe package? [14:52] If it's unseeded, we aren't in final freeze for it yet. [14:52] seeded or unseeded? (main/universe doesn't matter) [14:52] persia: unseeded [14:53] That doesn't automatically translate into it's a good idea to update it. [14:53] You should consider risk versus benifit. [14:53] I think unseeded gets frozen sometime in the next 15-20 hours. Still, take a look at the output of `apt-cache unmet -i`. 60% of those are easy to fix. [14:53] RCbugs needs love also. [14:53] since it just finished building, I am also testing it right onw [14:53] *now [14:54] bilalakhtar, Be aware that unseeded GNOME doesn't usually get the free pass on freezes that seeded GNOME gets. [14:58] persia: No, we'll keep it unfrozen for some time yet. There's a mail stuck in u-d-a moderation since last Friday on it. [14:59] Ah. I thought freeze was just awaiting moderation. [14:59] No. [15:00] Oh, good. More time to play :) [15:00] persia: Play? Archive is not playing stuff :) lol [15:00] Why not? I play responsibly. [15:01] And if I didn't enjoy it, I should spend my time doing something else. [15:01] * bilalakhtar uploads to the arcive very carefully [15:02] Indeed. One has to take care, or one breaks ones toys (and more importantly, when playing with shared toys, annoys everyone else). [15:02] Yay! Package is working well! [15:02] persia: All of Main/Restricted is now frozen, seeded or not - changing build-deps can cause subtle problems. [15:03] The math problem for unseeded Universe/Multiverse is something like this: [15:03] I thought "seeded" implied everything in the seeds and everything in their recursive {build-,}{depends,recommends} [15:03] persia: does that make karma a high score then? :P [15:04] release -36 hours for the final, final upload to the archive (that's time for fixing a last minute OMGWTFBBQ problem and mirror sync) and then 3 days prior to that for final freeze where all uploads are reviewed (IIRC, I wrote the mail on Friday). [15:04] persia: ^^^ math problem for U/M final freeze. [15:05] sistpoty|work, I don't like to keep score :p [15:05] heh [15:05] ScottK, Only 3 days for unseeded FinalFreeze? I'd like to have seen a week, but I can understand you don't want to review them all :) === sikon is now known as lucidfox [15:06] Also we're counting that from the actual release day, 10/10, not the process release day of 10/7. [15:07] u-d-a mail should be out now. [15:09] Right. process release day -> actual release day is the OMGWTFBBQ 3 days, right? [15:10] Oh, no, only half. [15:18] Hello [15:18] dholbach still in vacation ? [15:24] Probably. He's not been saying "good morning" [15:25] ScottK: I blogged about it, I kept it very, very friendly though. [15:25] AnAnt: "I’ll be back on 29th September." from dholbach's blog post about his vacation [15:25] aha [15:33] AnAnt: dholbach's visa mentions him as Daniel Holbakh, not ch [15:34] see the arabic part :) [15:37] bilalakhtar: as far as I know, in Deutsch language "ch" is equivalent to "خ" in arabic [15:38] bilalakhtar: indeed, that's how we pronounce the name of their classical musician "Bach" [15:38] AnAnt: Its good to see people visiting the middle east while others consider this region as inferior [15:39] It's like the sound at the end of (bad transliteration) sabakh [15:39] Well, in some areas. In other parts of germany it's more like the sound in the second part of "good mornig" (after the al-), but I'm not even going to attempt to transliterate that. [15:40] persia: Hows it like attending DMB meetings when you're living in Japan? MIght have to wake up extra, I suppose [15:40] persia: ah, you mean "sabah" (ie. morning) ? [15:40] Sabah Al-Khair [15:40] -> Good morning [15:41] AnAnt, Like I said, bad transliteration. Depending on regional accent anywhere from English "sh" to Arabic "Kh" (from your transliteration) [15:41] * persia tends to pronounce bare "h" without any friction, whereas "sabah" was learned with light friction [15:48] highvoltage: You have at least one comment awaiting moderation. [15:50] ScottK: approved [15:50] (and thanks) [15:51] highvoltage: Feel free to ask me something like "Gee. That sounds lake a great way to do this, how come it wasn't discussed at UDS?" [15:52] ScottK: I can't! I'm afraid of what the answer will be! [15:52] The answer is, of course, that it was. [15:53] ScottK: my guess would be that they felt that backports was too complicated? [15:53] That's the official explanation, although technically it would have been less complicated to implement. [15:53] My view is they arrived with their plan and weren't very open to feedback. [15:54] Which is pretty consistent with the way the more recent ML discussion went. [15:55] ScottK: imho the effort of creating a package of sufficient quality of being in a backport isn't that much more than doing a simpler package that would pass the app review package [15:55] (if that doesn't make sense, then sorry. my english really seems to suck today :p) [15:56] highvoltage: I'd put it differently. If the package isn't good enough to be in Ubuntu (for the next release or backports) why is it good enough to be immediately provided to all Ubuntu users via this new repository. [15:57] ScottK: *nod* === ivoks-afk is now known as ivoks [18:35] ScottK: Officially they are not a part of Ubuntu, and so users won't blame the distribution if the quality suffers. [18:35] Yeah, right. [18:43] Laney, everything is ubuntu;s fault [19:08] directhex: +1 [19:08] ;) [20:48] bdrung_: so I'm spamming your inbox? :) [20:57] uhm how can I tell pbuilder that I care a ·$% about keyrings so it'll give me a Maverick pbuilder on Debian? [20:58] what does that mean? [20:58] .$% [20:58] RainCT: you mean --debootstrapopts --keyring=foo ? [20:59] Laney: whatever nice word you want ;) [21:00] oh, "lot" [21:00] ;) [21:00] tumbleweed: yes, except that I don't want it to use any keyring since I don't feel like hunting it down [21:01] RainCT: just --recv-keys and use your own keyring (that's how I do it) [21:01] I just installed the ubuntu-archive-keyring on Debian [21:01] :( [21:05] Laney: Yup, just did the same. Couldn't they have implemented this by adding a --i-am-paranoid option? ^^ [21:15] RainCT: no, you are not. if you fix 42 bugs in ubuntu-dev-tools, i might count that as spamming. ;) [21:28] nxvl, you and your team are waited in ubuntu-meeting [21:28] :) [21:37] bdrung_: okay, then I'll do 42 commits to fix a single bug ;) [21:38] RainCT: no, commits don't count. only linked branches === ivoks is now known as ivoks-afk [22:01] bdrung_: there you go, sponsor-patch has a manpage. Happy with it? [22:01] tumbleweed: lemme see [22:07] tumbleweed: "to an Ubuntu bug bug," [22:10] tumbleweed: "Should any checks (or the build fail), the user has an option to edit the patched source and try building it again." seems to belong to point 4., but it shouldn't, should it? [22:11] grr@nroff :) [22:11] tumbleweed: besides that, it's good. thanks. [22:13] tumbleweed: one more thing: it's not only for sponsoring, it's for the ubuntu-review team too. it can pull patches (not debdiffs). the use case for ubuntu-review would be to pull the patch, apply it, upload to a PPA [22:13] bdrung_: what do you have against bugs in bugs? :( [22:13] tumbleweed: maybe it would be useful to have example usages explained [22:14] bdrung_: yeah, I tried to not rule out the ubuntu-review workflow in any wording, but it doesn't exactly say it can do it either. Examples are probably good. [22:14] tumbleweed: one could be "sponsor-patch -s " [22:17] tumbleweed: another could be "sponsor-patch -u ppa:/

" [22:17] tumbleweed: "bugs in bugs?" the word _bugs_ twice sounds weird [22:18] bdrung_: review-bug probably needs -e [22:18] bdrung_: "bugs in bugs" ? [22:18] tumbleweed: not necessarily [22:19] I mean so that the changelog entry can be generated (assuming th ereview bug is a straight patch) [22:19] tumbleweed: sorry. RainCT "bugs in bugs" confused me. ignore that. [22:20] * RainCT was just joking, haven't looked at the manpage at all [22:20] tumbleweed: sponsor-patch should generate a changelog entry stating that the patch is applied [22:21] RainCT: i thought your reply was a reply from tumbleweed [22:22] tumbleweed: btw, sponsor-patch updates the timestamp in debian/changelog [22:23] bdrung_: yeah, I just saw that now. I can't see anything about changelog entry generation, though [22:24] tumbleweed: SPONSOR_PATCH_WORKDIR should be mentioned in the man page [22:25] tumbleweed: i forgot the changelog generation. it's in my brain's TODO list. here. can you see it? ;) [22:26] :P [22:27] tumbleweed: i need to add a --workdir, -w for overriding SPONSOR_PATCH_WORKDIR [22:28] yeah sounds good [22:32]