[00:02] slangasek, sorry, i ran off. yeah, the version check woudl make sense, although realistically, if the user deleted that file, it is an upgrade and they'd have /var/lib/cloud/data/cache/obj.pkl [00:02] but your way is better, i agree. [00:02] regarding /var/lib/cloud/data/cache/obj.pkl [00:02] cloud-init-cfg depends on that file being present (basically, that indicates that there is a cloud data source provided, which is not the case during our image builds) [00:12] * infinity goes to find dinner; back later if people need reviews and such. [00:42] * skaet back from dinner, seeing builds from daily cron start to emerge on the ISO tracker.... :) [02:18] infinity: Do you feel like updating all the archive admin scripts to use a new LP tree? [02:19] /srv/launchpad.net/production/launchpad instead of /srv/launchpad.net/codelines/current [03:18] ^ that'd be one of mine, universe package, not seeded, bugfix for non-x86 support, would appreciate if someone could let it through [03:44] stgraber: ^^ [03:45] thanks [03:47] You're welcome. [04:20] * skaet --> zzz [06:12] Good morning [06:15] * pitti starts to build langpacks for beta-2 [06:23] ^^ that's for the lucid-main upgrade bug, if someone wants to let it in [06:24] ! [06:24] I'll have a look, I soo want to see this fixed :) [06:32] ^ FTBFS/NBS fix, trivial; approving [06:33] wow, NBS almost clear [06:33] slangasek: ... I hate debian/patches/debian-changes [06:33] micahg: :) [06:34] slangasek: it seems it kept the patch, but changed the description to the current changelog; that makes no sense at all.. [06:34] pitti: heh, eew [06:34] sorry, I didn't look at the debdiff and assumed the source was generated correctly [06:34] slangasek: no worries, I was just ranting [06:35] so that covers the mono side, the bug also has a perl task; I guess we need that as well before the upgrade can work? [06:37] slangasek: oh, perl for the added Conflict:, I take it? [06:39] pitti: yes - so we should wait until mono is built everywhere before uploading the perl change [06:40] *nod* [06:44] wgrant: Uhh, what? [06:44] wgrant: Why gratuitously move the path it deploys to? [06:45] infinity: We need two separate trees on cocoplum, since poppy can't be upgraded without downtime. We also need to move cocoplum into line with the rest of the servers circa 2008, so the new nodowntime tree complies with the new naming scheme. [06:46] This will let us upgrade cocoplum several times a week, as we do with every other Launchpad server. [06:46] Sadly nasty people have shell access on cocoplum, so we have delayed doing this for a while :) [06:47] >:( [06:48] Anyhow, you'll want webops to carefully do the cronjob changes, but I can poke around at local scripts and .profiles and such. [06:48] Cronjobs are already changed. [06:48] Oh, I didn't log in and see that this was already done. [06:48] Thanks for the warning? ;) [06:50] The old tree still works for now, but for our deployment schedule to become more sensible we really need everything except poppy to run out of the new tree. [06:50] Sure. [07:37] infinity: do you know why so many buildds are on manual? [07:38] * pitti could use some i386 horsepower for the incoming langpack rebuild for b2 [07:41] pitti: Doing some lp-buildd upgrades. Can the langpack uploads hold off for a short bit? [07:41] pitti: Those upgrades should make the builds faster. [07:41] pitti: (I'm also refreshing the chroots, which should make things faster) [07:41] infinity: oh yes, they are still being generated; upload in an hour or 1.5 [07:41] no panic :) [07:42] chroot upgrades are appreciated indeed [07:42] infinity: thanks for the heads-up [08:10] ^ looks fine and fixes i18n, which I requested for this to be included, accepting [08:18] pitti: chroots are all freshened, webops are just finishing up with updating lp-buildd for me (though x86 should be all done, which is all you care about) [08:19] pitti: So, given that we never once actually used the "failed-to-uninstall-deps" return code from sbuild, I just removed the build-dep removal stage in lp-buildd. Should knock anything from a few seconds to upwards of 5 minutes off some builds. [08:19] skaet: folks, sorry for the release mail mess for Xubuntu, it's my first, so be gentle, please. :) [08:37] infinity: \o/ cheers [08:43] pitti: I assume you'll want to steal allspice for i386 before you start? [08:44] infinity: yes, probably two amd64 builders (as long as the queue is empty), and maybe molybdenium, too [08:46] pitti: Heh. [08:46] pitti: allspice is like 8 molybdenums anyway. [08:46] ah, generation of the package is complete; I give them a quick local test, and then upload [08:46] you can steal lpia for at least 3 hrs, maybe more [08:47] pitti: My bet is that with the fresh chroots and the new lp-buildd, you'd be happy doing langpacks on just allspice and roseapple. [08:47] Although, you're German, so I suppose you're never happy. *duck* [08:47] looking forward to seeing them in action :) [08:49] infinity: *smirk* [08:51] who is able to control the ubottu thing and tell it to STFU for the ~ 800 uploads and 800 approvals? [08:51] You mean the queuebot? [08:51] right [08:52] You may be out of luck, that version's running from stgraber's machine. [08:52] ah, ok; [08:52] stgraber: Awake, by any chance? ;) [08:52] so, brace for impact, upload coming :) [08:52] Well, if they all hit the queue at the same time, you might get queuebot K-lined. [08:52] Which would be entertaining. [08:52] couldn't you mute queuebot in this channel? [08:53] That would require someone who's an op. [08:53] pitti might be, pretty sure I'm not. [08:53] what's the magic incantation again to become op? [08:53] /msg chanserv help :P [08:53] I never remember. [08:54] Oh, go you. [08:54] powah [08:54] Can you add me to the list? ;) [08:54] * pitti <- IRC n00b; if you tell me how :) [08:55] /msg chanserv quiet #ubuntu-release ubottu [08:55] does that sound sensible? [08:55] that's what help quiet says [08:56] That should do/ [08:56] hah, "you are not authorized to perform this action" [08:56] I don't recall how to add people to op access lists. [08:56] Oh, lame. [08:56] * pitti starts the upload anyway [08:56] You could set the channel +v, and just upload. [08:57] infinity: I can't [08:57] Err, +m [08:57] /mode #ubuntu-release +m [08:57] /mode #ubuntu-release +m [08:57] whatever that just did then [08:58] That should have set the channel moderated, and only allowed +o and +v people to talk, but clearly not on Freenode. [08:58] jibel: uh, we should have set that for b1 already, thanks for pointing out [09:00] ok, commandeered allspice and crested to help out, I left a note in the description [09:01] let's see how quickly I can accept them before the bot catches them [09:01] ah, too late [09:02] pitti: feel free to steal the lpia builder until someone from the security team needs it [09:02] micahg: ok, thanks [09:03] 1:30 minutes for a -base pack on allspice, that's great! [09:04] pitti: So, for comparison, 21 seconds to build a KDE langpack on allspice, 2:20 on older hardware. [09:04] pitti: That's why I say allspice and roseapple are probably all you care about. :) [09:05] cool [09:05] hah, take that queuebot, I slip 2/3 of the packages through without you noticing [09:07] And there it goes. ;) [09:09] Okay, I'm pretty happy with the new lp-buildd. Seeing most of these builds clock at under a minute (which is now almost entirely the chroot tarball unpack) makes me happy. [09:10] (sbuild reporting builds that took "0:02" is fun) [09:12] wow, a build in 20 seconds is awesome [09:15] Yeah. I could (and should, to reduce PPA load) further optimise the Xen-virt case here. [09:15] But that's for the next time I feel silly enough to look at lp-buildd for more than 2 minutes. [09:16] not inclined to make it use a modern sbuild? [09:17] ajmitch: Other than people thinking that would be cool, I have yet to hear a valid reason. :P [09:17] ajmitch: The current one works. [09:17] backports build-depends on other backports? [09:17] What does that have to do with sbuild? [09:18] sbuild's internal dependancy resolver doesn't handle that [09:18] (well, the ancient one we have) [09:18] Oh, as in, because of the default pinning for backports? [09:18] yes [09:18] That's a 2-second fix in lp-buildd to just undo the pinning when building for backports. [09:18] Is there a bug about this? [09:19] bug #888665 [09:19] Launchpad bug 888665 in launchpad "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665 [09:19] Oh, one I commented on even. I wonder if I was asleep when I did. [09:19] if it's *that* simple... :) [09:20] Oh, I kinda mentioned the above, but I don't think my brain fully grasped how easy it would be until we just brought it up now. [09:22] Ahh, and I forgot the weird "we only want it to use backports for build-deps if required" requirement. [09:22] That makes it trickier. [09:23] Yeah, okay, maybe the sbuild switch is the better option, but that's not today. :P [09:26] ajmitch: Toggling the Automatic thing is almost literally a 2-minute fix (well, modulo the painful rollout process), but yeah, that has the side-effect of backports pulling in ALL of backports, which I think people don't want. [09:26] probably not ideal [09:26] ajmitch: Or, that's the impression I get here. [09:26] indeed, the NotAutomatic semantics are what we want [09:27] Fine. I'm convinced. New sbuild it is, at some point. [09:27] I could take wgrant's branch and hack in support for the bits he missed. [09:27] But. No idea when I can commit to that. [09:27] you would deserve many beers for that [09:27] (I do realise it'll also make home sbuild users feel warm and fuzzy that it's basically the same as the buildds, but that's less of a concern for me) [09:29] infinity: It's a bit of a challenge now. [09:30] wgrant: In what way? [09:30] infinity: Because, since my branch, distro sbuild has been refactored significantly into about a thousand pieces. [09:30] wgrant: Yeah, I've seen that. [09:30] wgrant: My plan is to remove sbuild from lp-buildd entirely. [09:30] wgrant: And fork the distro package for LP/IS. [09:30] That was my implementation, yes. [09:31] I looked maybe 6 months ago at reviving it. [09:31] But it was going to prove a challenge to use a post-Lucid sbuild. [09:31] You may have better luck. [09:31] pitti: any reason you haven't grabbed the lpia buildd yet? [09:31] wgrant: I'll poke it with a stick at some point. [09:32] https://code.launchpad.net/~wgrant/ubuntu/lucid/sbuild/extended-result and https://code.launchpad.net/~wgrant/launchpad/use-system-sbuild are relevant. [09:32] wgrant: I don't think it's as hard as all that, really. And I can probably get some of the patches into Ubuntu's sbuild (though not Debian's) as command-line options. [09:33] Note that the ddeb hack probably needs to be readded. [09:33] That's not difficult. [09:33] This was mostly my mess to start with, I'm somewhat familiar with it. [09:33] Not difficult, just ugly as hell :) [09:34] No argument here. [09:34] What's the blocker on ddebs-in-soyuz? [09:34] We already do it for PPAs now, right? [09:34] Do we just need a machine from IS provisioned to publish them? [09:35] They need different expiry policies, which means altering the copier to cope with sometimes having expired binaries. [09:35] Because otherwise cocoplum and acamar will melt. [09:36] And there's also the issue that we've decided the original constraint about forcing them into a separate archive is impractical and unnecessary. [09:36] It is? [09:36] This sort of assumes cocoplum gets a ton more space, then. [09:36] micahg: I think it won't make that much difference after all [09:36] It does, yes. [09:36] And when you say "separate archive", you do just mean on-disk, I hope? [09:37] Actually, wait. How is ddebs laid out? [09:37] infinity: Right, practically they have to be part of the same Soyuz archive. [09:37] I envisage that they will be split like ports is. [09:37] Err, we can't, [09:37] Not without changing the implementation everywhere. :/ [09:38] ddebs re-use archive namespace. [09:38] (ie: dists/precise/binary-amd64/Packages) [09:38] And we sure as heck aren't adding them to the primary Packages file. [09:38] Of course. [09:38] But we can work around that. [09:38] Like we do with d-i [09:38] Component of main/debug, for example. [09:38] Yes, by "changing the implementation everywhere", like i said. :P [09:39] That's roughly 10 lines of code. [09:39] You're not in a bubble here. [09:39] In LP. [09:39] ddebs has clients. [09:39] Moving files around breaks them. [09:39] could we keep transitional symlinks for the old packages.gz locations? [09:39] putting them in the same archive means mirrors have to carry them [09:39] tumbleweed: No [09:39] tumbleweed: Like ports, they can be split into a separate archive for mirroring. [09:39] tumbleweed: No, syncproxy takes care of that. [09:40] ah [09:40] pitti: I suppose syncproxy could re-create the old hierarcy and symlink to the new, but ew? [09:40] We could do something like the old -commercial hack [09:40] Or we could just update the few users' sources.lists... [09:40] infinity: if we could at least keep a symlink hierarchy for stables, and use the new layout from then on, it'll phase itself out [09:41] Right, that's how partner went. [09:41] We had a script around for years which mangled partner to dapper-commercial etc. [09:41] Yeah, I guess it's doable on syncproxy. [09:41] ln -s installer-i386 debug-i386, go. [09:42] Err. [09:42] Somewhere, I had an aneurysm. [09:42] But you know what I meant. [09:42] debug-i386 binary-i386 [09:42] Anyhow. [09:42] Needs Release mangling as well. [09:42] this still scares me a bit [09:43] But there's precedent for this. [09:43] wgrant: So, basically, this is waiting on cocoplum being hooked up to the mythical SAN with endless storage. [09:43] The SAN is no longer mythical :) [09:43] The librarian runs on it. [09:43] of course mirrors don't have to mirror them all, but they might not expect that change coming, so I guess many of them aren't configured to not mirror the debug- components? [09:43] pitti: The mirrors won't see them. [09:43] pitti: syncproxy. [09:43] It's just like ports. [09:43] aah [09:43] pitti: It'll split archive/ports/ddebs [09:44] yes, nevermind me [09:44] wgrant: And there's no need for release mangling. [09:44] wgrant: In fact, that would be *wrong*. [09:45] My implementation has been proven pretty robust by Linaro and another few PPAs, which is nice. [09:45] infinity: Huh? [09:45] wgrant: Note that http://archive.ubuntu.com/ubuntu/dists/precise/Release includes ports stanzas. :P [09:45] infinity: Yeah [09:45] Oh, but you mean mangling for s/debug/binary/ for old releases. [09:45] Ugh. [09:45] infinity: But if we symlink binary-i386 -> debug-i386, the hashes for binary-i386 will be wrong [09:45] Yeah [09:45] syncproxy doesn't sign things. [09:45] No [09:45] That's why commercial-compat.sh was on cocoplum. [09:45] pitti: can you please copy thunderbird 3.1.20 from ubuntu-mozilla-security for lucid-natty to -security please? [09:46] Part of LP [09:46] wgrant: What did that do? Do I want to know? :) [09:46] micahg: on it [09:47] micahg: confirming, !oneiric ? [09:47] pitti: correct, I should've deleted that one already [09:47] infinity: http://pastebin.ubuntu.com/896198/ [09:47] (I'm guessing we'd do something like mangle, write out, and sign a Release-ddebs, and then have syncproxy shuffle the files around as appropriate?) [09:47] pitti: I mean oneiric was already done :) [09:47] Although *-commercial was a different suite, so this just writes a full new Release file... [09:48] wgrant: Yeah. My above bit works, though. [09:48] Indeed. [09:48] wgrant: You just create a second release file, sign it, and have syncproxy sort the mess. [09:48] We could even sign with a different key if we want. [09:48] I guess. [09:48] (Which sucks, but) [09:48] No, same key. [09:48] It should be transparent to the user once moved around. [09:48] micahg: done [09:49] pitti: thanks [09:49] infinity: It's not the same key now. [09:49] The only cruft would be Release-foo.* on ftpmaster. [09:49] yes, but I don't think the current key is very valuable [09:49] it's only signed by me really [09:49] wgrant: It's not the same key because pitti can't use the archive key. :P [09:49] wgrant: That's not a feature. [09:49] this whole thing was never intended to last for 6 years :) [09:50] Heh [09:50] pitti: Ugh, has it been that long? [09:50] It was Edgy :/ [09:50] I feel old. [09:50] Anyway, if we take this approach, we just need to work out expiry policies and find an extra terabyte of disk for cocoplum :/ [09:51] wgrant: The disk thing is going to get punted to the SAN. But worth talking to IS about it again. [09:51] wgrant: Sorting the LP code sounds like not a lot of work? [09:51] does macquarie use the SAN? [09:51] wgrant: And then getting IS to sort syncproxy magic. [09:51] after all, it has all the ddebs right now [09:51] pitti: No, if it did, you wouldn't have to keep purging things you don't like. [09:52] well, we deleted a fair number of them for space reasons, but we can remove them there after theh migration [09:52] * infinity is annoyed that all those removed ddebs are just gone forever. [09:53] * pitti looks at NBS.. http://people.canonical.com/~ubuntu-archive/nbs.html --- c'mon, we can do that [09:54] pitti: I dunno. Removing one package sounds hard. [09:54] I'll have a go at toonloop (needs porting) [09:54] pitti: gnome-shell probably just needs a give-back, let me look. [09:54] infinity: nope [09:55] pitti: (I suspect it was fallout from clutter being broken) [09:55] I'll ask jbicha about it in the afternoon [09:55] no, already tried [09:55] infinity: LP can split the indices in about 10 lines of code. [09:55] infinity: And moving them back to the primary archive is a matter of deleting code. [09:55] Release file mangling is slightly harder, but a bit of awk never hurt anyone... [09:56] pitti: Oh, it might need some GL->EGL love of its own. [09:56] rsalveti: Do you love gnome-shell as much as you love clutter? ;) [09:57] pitti: Anyhow, removing libcogl5 on arm* (once toonloop is fixed) would be fine regardless. I suspect it's neither installable or runnable right now anyway. [09:58] (gnome-shell, that is) [09:58] yeah, presumably [09:58] but I would at least have a go at toonloop; there's a new upstream release which might help [09:58] or a trivial backport [09:59] It's universe, I'd rather sync than carry a diff, if no one's actively watching the package. [09:59] Which, if it's uninstallable/unbuildable, is probably the case. [09:59] we are newer than debian already [09:59] Oh. [09:59] Fun. [09:59] it it takes longer than 15 minutes, I'd probably just opt for removing it *shrug* [10:00] It must have a user. [10:00] ajmitch: did you get to looking at that haskell stuff? [10:00] Someone had a pretty cogent rant about willy-nilly removals in Debian a while ago. [10:00] "Just cause it's not worth your time, doesn't mean you aren't ruining someone else's day." [10:01] infinity: Ah [10:01] pitti: Also, can I pretend that libical's testsuite failure is your fault, since it's in the desktop seed? [10:02] 13:37 < wgrant> broder: Sadly precise's sbuild needs libdpkg-perl, which is new in maverick. And new dpkgs don't obviously backport to hardy, which is what most of the buildds run :/ [10:02] infinity: yes, you can [10:02] infinity, it's my fault in fact [10:02] I was hopping Debian would fix it [10:02] slackers [10:02] wgrant: That's a self-solving problem when the buildds move to precise. [10:02] infinity: Ha ha ha hah hahdada [10:02] wgrant: So, sometime in 2014. [10:03] infinity: Lucid supports ia64 and sparc [10:03] And Lucid doesn't die until 2015. [10:03] wgrant: Yes, and? [10:03] wgrant: I can keep the internal sbuild implementation for old buildds. [10:03] Does Lucid run on our ia64 and sparc buildds? [10:03] Ah [10:03] wgrant: We have the power to work magic here. :P [10:03] That works too, I guess. [10:03] I don't know that ia64 and sparc were also given LTS status.. [10:04] Daviey: We've never removed an arch post-release before. [10:04] Daviey: "official" lts status and reality aren't the same thing, don't confuse them. [10:04] Daviey: they're at least community supported for the duration [10:04] We didn't even have support for removing archs until I wrote it at the last minute for maverick. :/ [10:05] wgrant: heh.. well, i think it needs to be a consideration.. check if those arches were declared long term. [10:05] No, please dn't. [10:05] don't* [10:05] It's a headache. [10:05] Daviey: no, they weren't [10:05] infinity: How is it a headache? [10:06] Daviey: armel was supported but not LTS [10:06] Daviey: You're thinking of it in the "I want to kill ia64 nao" sense. But think of all the 5-year versus 18-month support statuses we have, and staggering dropping arches for no good reason? [10:06] It's insanity. [10:07] infinity: I really fail to see the headache.. we just don't ship non-lts point release iso's. [10:07] infinity: No.. hardy still has the pool of desktop open.. doesn't mean it's 'supported' [10:07] If someone uploads something to lucid, where PPC is no longer supported, do we still build it, but then employ black magic to publish it to old-releases? [10:07] Daviey: Uhm, ISOs are something we can much more easily just not build. [10:08] Daviey: And it's a disservice to anyone runinng lucid/ppc (hint: including IS) to just stop building new versions completely. [10:08] infinity: what if a sparc SRU ftbfs? it's the same as it never being built.. ie, not published. [10:08] Daviey: those ports were community ports from the beginning of Lucid, you can't just remove them [10:08] Daviey: If it FTBFS, someone might care and fix it, someone might not. [10:09] micahg: I'm not suggesting they are removed.. i'm saying, if they are not LTS, they are not LTS :) [10:09] Daviey: From the "every developer, even the ones Canonical pays, is a community member" perspective, I'd like to think that someone will be the uploader, but sometimes it won't be. [10:09] Daviey: that only means something as far as canonical support goes [10:09] Daviey: Err, you were suggesting they be removed. I was here. [10:09] micahg: No, that isn't true.. [10:10] micahg: To be fair, we've now had community discussions about what LTS means (hence community flavours using the term). [10:10] That said, the "whole community" doesn't agree to anything. [10:10] infinity: So.. if i want to SRU a fix for Hardy tomboy.. What will happen? [10:10] And if I upload one of my packages as an SRU, I expect it to build on every arch. [10:10] If it doesn't, I'll fix it. [10:10] And if I'm told I can't have it on an arch that released with that release because someone else doesn't want me to, well. I know a lot of four-letter words. [10:10] Daviey: that's a server/desktop split, quite different that selective archs [10:11] No.. not at all. [10:11] Daviey: What do you mean "what will happen"? [10:11] Daviey: You can SRU tomboy all you like. [10:11] Daviey: in one case you have no security support for your desktop, in the other case it's best effort [10:11] *IF* the arches mentioned were not declared LTS, it's *identical* to the Desktop / Server LTS length split. [10:11] "LTS is over" doesn't mean "can't upload SRUs anymore", it means that there's no longer a *commitment* to provide SRUs. [10:12] infinity: If there was a better distinction between pool for desktop and server, the hardy desktop pool wouldn't still be available [10:12] I doubt the SRU team would accept an SRU for hardy for a desktop package at this point [10:12] right! [10:12] Daviey: That's a blatant lie, but sure. [10:12] infinity: How is it a lie? [10:12] micahg: I would. Maybe I should re-join. [10:13] Daviey: Because it is. If we broke the packages out, we wouldn't stop publishing them. [10:13] Daviey: I explained the difference between the two [10:13] Daviey: Your assumption is an assumption, but you stated it as fact. [10:13] This isn't a Canonical/Ubuntu support split. As a project, we declare a shelf life for different parts of the project. When that life is expired, the project shouldn't work on expired things. [10:14] Daviey: Hahaha. [10:14] Note, that community flavours are pushing for LTS status.. It's irrelevant to Canonical. [10:14] Daviey: "As a project", the LTS thing came from Canonical. That's beginning to change a bit now, but that sure was true for hardy. [10:15] Either way. The distintion between "support commitment" and "actively blocking people from working on what they like" is one I'd rather not keep arguing about. [10:15] If the SRU team rejects an SRU in a still-open release bcause it's on the "wrong" packageset, that's wrong, IMO. [10:15] Daviey: arch specific retirement only makes sense in terms of active support since the uploads are still happening, it just switches from active commitment to best effort [10:15] infinity: well it happens :) [10:15] Daviey: Example? [10:16] pitti: Have an example of an SRU that was nack'd for being Desktop, for an expired LTS? [10:16] Daviey: And I don't mean rejecting a bug, I mean rejecting a fully-formed, I didn't have to do anything but accept it and mark is verification-needed, SRU. [10:16] s/is/it/ [10:16] infinity: it's giving people false hope, we shouldn't be updating one part of the desktop when the rest was left to the bandits [10:16] Daviey: I don't think it ever happened actually [10:16] micahg: It's not false hope. By that logic, we should never update a universe package, ever. [10:16] infinity: The cost in man hours for an SRU isn't cheap.. Creating a package and dput'ing is probably the cheapest part! [10:17] micahg: Cause it's "false hope" that the rest of universe will be fixed. [10:17] it depends on the nature of the change; if it's a truly critical data loss bug I might accept it [10:17] pitti: Really, i thought i saw it previously [10:17] but in general I wouldn't [10:17] infinity: with a universe package, there support for the main part of the system [10:17] I even reject most maverick SRUs these days [10:17] Good thing I accepted my own... [10:17] O_o [10:17] You are kidding me? [10:17] then again we actually do accept lucid universe SRUs [10:18] because lucid has a fairly large user base [10:18] pitti: So, the policy is somewhat inconsistent. :P [10:18] infinity: well, that's why we have a human SRU team and not automatic checks :) [10:18] pitti: So, if i upload a hardy SRU for tomboy, which fixes an issue where there might be loss of tomyboy notes, would you accept or reject it? [10:18] we become more and more strict in what we accept over time [10:18] pitti: re lucid SRUs> no reason not to at this point [10:19] Daviey: at this point the probability of this is very small [10:19] pitti: Okay, but when you say "reject an SRU", do you mean "tell the person to just use a newer release, because maverick is EOL soon, but let them argue why they need/want to do this fix" or "flat-out tell them that we don't do maverick SRUs"? [10:19] Daviey: and I really need to see the concrete bug [10:19] pitti: I'm really suprised you'd even consider it, considering desktop hardy is dead. [10:19]