| smoser | 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 |
|---|---|---|
| smoser | but your way is better, i agree. | 00:02 |
| smoser | regarding /var/lib/cloud/data/cache/obj.pkl | 00:02 |
| smoser | 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:02 |
| * infinity goes to find dinner; back later if people need reviews and such. | 00:12 | |
| * skaet back from dinner, seeing builds from daily cron start to emerge on the ISO tracker.... :) | 00:42 | |
| wgrant | infinity: Do you feel like updating all the archive admin scripts to use a new LP tree? | 02:18 |
| wgrant | /srv/launchpad.net/production/launchpad instead of /srv/launchpad.net/codelines/current | 02:19 |
| stgraber | ^ that'd be one of mine, universe package, not seeded, bugfix for non-x86 support, would appreciate if someone could let it through | 03:18 |
| ScottK | stgraber: ^^ | 03:44 |
| stgraber | thanks | 03:45 |
| ScottK | You're welcome. | 03:47 |
| * skaet --> zzz | 04:20 | |
| pitti | Good morning | 06:12 |
| * pitti starts to build langpacks for beta-2 | 06:15 | |
| slangasek | ^^ that's for the lucid-main upgrade bug, if someone wants to let it in | 06:23 |
| pitti | ! | 06:24 |
| pitti | I'll have a look, I soo want to see this fixed :) | 06:24 |
| pitti | ^ FTBFS/NBS fix, trivial; approving | 06:32 |
| micahg | wow, NBS almost clear | 06:33 |
| pitti | slangasek: ... I hate debian/patches/debian-changes | 06:33 |
| pitti | micahg: :) | 06:33 |
| pitti | slangasek: it seems it kept the patch, but changed the description to the current changelog; that makes no sense at all.. | 06:34 |
| slangasek | pitti: heh, eew | 06:34 |
| slangasek | sorry, I didn't look at the debdiff and assumed the source was generated correctly | 06:34 |
| pitti | slangasek: no worries, I was just ranting | 06:34 |
| pitti | 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:35 |
| pitti | slangasek: oh, perl for the added Conflict:, I take it? | 06:37 |
| slangasek | pitti: yes - so we should wait until mono is built everywhere before uploading the perl change | 06:39 |
| pitti | *nod* | 06:40 |
| infinity | wgrant: Uhh, what? | 06:44 |
| infinity | wgrant: Why gratuitously move the path it deploys to? | 06:44 |
| wgrant | 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:45 |
| wgrant | This will let us upgrade cocoplum several times a week, as we do with every other Launchpad server. | 06:46 |
| wgrant | Sadly nasty people have shell access on cocoplum, so we have delayed doing this for a while :) | 06:46 |
| infinity | >:( | 06:47 |
| infinity | 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 |
| wgrant | Cronjobs are already changed. | 06:48 |
| infinity | Oh, I didn't log in and see that this was already done. | 06:48 |
| infinity | Thanks for the warning? ;) | 06:48 |
| wgrant | 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 |
| infinity | Sure. | 06:50 |
| pitti | infinity: do you know why so many buildds are on manual? | 07:37 |
| * pitti could use some i386 horsepower for the incoming langpack rebuild for b2 | 07:38 | |
| infinity | pitti: Doing some lp-buildd upgrades. Can the langpack uploads hold off for a short bit? | 07:41 |
| infinity | pitti: Those upgrades should make the builds faster. | 07:41 |
| infinity | pitti: (I'm also refreshing the chroots, which should make things faster) | 07:41 |
| pitti | infinity: oh yes, they are still being generated; upload in an hour or 1.5 | 07:41 |
| pitti | no panic :) | 07:41 |
| pitti | chroot upgrades are appreciated indeed | 07:42 |
| pitti | infinity: thanks for the heads-up | 07:42 |
| pitti | ^ looks fine and fixes i18n, which I requested for this to be included, accepting | 08:10 |
| infinity | 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:18 |
| infinity | 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 |
| astraljava | skaet: folks, sorry for the release mail mess for Xubuntu, it's my first, so be gentle, please. :) | 08:19 |
| pitti | infinity: \o/ cheers | 08:37 |
| infinity | pitti: I assume you'll want to steal allspice for i386 before you start? | 08:43 |
| pitti | infinity: yes, probably two amd64 builders (as long as the queue is empty), and maybe molybdenium, too | 08:44 |
| infinity | pitti: Heh. | 08:46 |
| infinity | pitti: allspice is like 8 molybdenums anyway. | 08:46 |
| pitti | ah, generation of the package is complete; I give them a quick local test, and then upload | 08:46 |
| micahg | you can steal lpia for at least 3 hrs, maybe more | 08:46 |
| infinity | 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 |
| infinity | Although, you're German, so I suppose you're never happy. *duck* | 08:47 |
| pitti | looking forward to seeing them in action :) | 08:47 |
| pitti | infinity: *smirk* | 08:49 |
| pitti | who is able to control the ubottu thing and tell it to STFU for the ~ 800 uploads and 800 approvals? | 08:51 |
| infinity | You mean the queuebot? | 08:51 |
| pitti | right | 08:51 |
| infinity | You may be out of luck, that version's running from stgraber's machine. | 08:52 |
| pitti | ah, ok; | 08:52 |
| infinity | stgraber: Awake, by any chance? ;) | 08:52 |
| pitti | so, brace for impact, upload coming :) | 08:52 |
| infinity | Well, if they all hit the queue at the same time, you might get queuebot K-lined. | 08:52 |
| infinity | Which would be entertaining. | 08:52 |
| micahg | couldn't you mute queuebot in this channel? | 08:52 |
| infinity | That would require someone who's an op. | 08:53 |
| infinity | pitti might be, pretty sure I'm not. | 08:53 |
| pitti | what's the magic incantation again to become op? | 08:53 |
| infinity | /msg chanserv help :P | 08:53 |
| infinity | I never remember. | 08:53 |
| infinity | Oh, go you. | 08:54 |
| pitti | powah | 08:54 |
| infinity | Can you add me to the list? ;) | 08:54 |
| * pitti <- IRC n00b; if you tell me how :) | 08:54 | |
| pitti | /msg chanserv quiet #ubuntu-release ubottu | 08:55 |
| pitti | does that sound sensible? | 08:55 |
| pitti | that's what help quiet says | 08:55 |
| infinity | That should do/ | 08:56 |
| pitti | hah, "you are not authorized to perform this action" | 08:56 |
| infinity | I don't recall how to add people to op access lists. | 08:56 |
| infinity | Oh, lame. | 08:56 |
| * pitti starts the upload anyway | 08:56 | |
| infinity | You could set the channel +v, and just upload. | 08:56 |
| pitti | infinity: I can't | 08:57 |
| infinity | Err, +m | 08:57 |
| infinity | /mode #ubuntu-release +m | 08:57 |
| pitti | /mode #ubuntu-release +m | 08:57 |
| pitti | whatever that just did then | 08:57 |
| infinity | That should have set the channel moderated, and only allowed +o and +v people to talk, but clearly not on Freenode. | 08:58 |
| pitti | jibel: uh, we should have set that for b1 already, thanks for pointing out | 08:58 |
| pitti | ok, commandeered allspice and crested to help out, I left a note in the description | 09:00 |
| pitti | let's see how quickly I can accept them before the bot catches them | 09:01 |
| pitti | ah, too late | 09:01 |
| micahg | pitti: feel free to steal the lpia builder until someone from the security team needs it | 09:02 |
| pitti | micahg: ok, thanks | 09:02 |
| pitti | 1:30 minutes for a -base pack on allspice, that's great! | 09:03 |
| infinity | pitti: So, for comparison, 21 seconds to build a KDE langpack on allspice, 2:20 on older hardware. | 09:04 |
| infinity | pitti: That's why I say allspice and roseapple are probably all you care about. :) | 09:04 |
| pitti | cool | 09:05 |
| pitti | hah, take that queuebot, I slip 2/3 of the packages through without you noticing | 09:05 |
| infinity | And there it goes. ;) | 09:07 |
| infinity | 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:09 |
| infinity | (sbuild reporting builds that took "0:02" is fun) | 09:10 |
| micahg | wow, a build in 20 seconds is awesome | 09:12 |
| infinity | Yeah. I could (and should, to reduce PPA load) further optimise the Xen-virt case here. | 09:15 |
| infinity | But that's for the next time I feel silly enough to look at lp-buildd for more than 2 minutes. | 09:15 |
| ajmitch | not inclined to make it use a modern sbuild? | 09:16 |
| infinity | ajmitch: Other than people thinking that would be cool, I have yet to hear a valid reason. :P | 09:17 |
| infinity | ajmitch: The current one works. | 09:17 |
| ajmitch | backports build-depends on other backports? | 09:17 |
| infinity | What does that have to do with sbuild? | 09:17 |
| tumbleweed | sbuild's internal dependancy resolver doesn't handle that | 09:18 |
| tumbleweed | (well, the ancient one we have) | 09:18 |
| infinity | Oh, as in, because of the default pinning for backports? | 09:18 |
| ajmitch | yes | 09:18 |
| infinity | That's a 2-second fix in lp-buildd to just undo the pinning when building for backports. | 09:18 |
| infinity | Is there a bug about this? | 09:18 |
| ajmitch | bug #888665 | 09:19 |
| ubot2` | Launchpad bug 888665 in launchpad "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665 | 09:19 |
| infinity | Oh, one I commented on even. I wonder if I was asleep when I did. | 09:19 |
| ajmitch | if it's *that* simple... :) | 09:19 |
| infinity | 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:20 |
| infinity | Ahh, and I forgot the weird "we only want it to use backports for build-deps if required" requirement. | 09:22 |
| infinity | That makes it trickier. | 09:22 |
| infinity | Yeah, okay, maybe the sbuild switch is the better option, but that's not today. :P | 09:23 |
| infinity | 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 |
| ajmitch | probably not ideal | 09:26 |
| infinity | ajmitch: Or, that's the impression I get here. | 09:26 |
| Laney | indeed, the NotAutomatic semantics are what we want | 09:26 |
| infinity | Fine. I'm convinced. New sbuild it is, at some point. | 09:27 |
| infinity | I could take wgrant's branch and hack in support for the bits he missed. | 09:27 |
| infinity | But. No idea when I can commit to that. | 09:27 |
| ajmitch | you would deserve many beers for that | 09:27 |
| infinity | (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:27 |
| wgrant | infinity: It's a bit of a challenge now. | 09:29 |
| infinity | wgrant: In what way? | 09:30 |
| wgrant | infinity: Because, since my branch, distro sbuild has been refactored significantly into about a thousand pieces. | 09:30 |
| infinity | wgrant: Yeah, I've seen that. | 09:30 |
| infinity | wgrant: My plan is to remove sbuild from lp-buildd entirely. | 09:30 |
| infinity | wgrant: And fork the distro package for LP/IS. | 09:30 |
| wgrant | That was my implementation, yes. | 09:30 |
| wgrant | I looked maybe 6 months ago at reviving it. | 09:31 |
| wgrant | But it was going to prove a challenge to use a post-Lucid sbuild. | 09:31 |
| wgrant | You may have better luck. | 09:31 |
| micahg | pitti: any reason you haven't grabbed the lpia buildd yet? | 09:31 |
| infinity | wgrant: I'll poke it with a stick at some point. | 09:31 |
| wgrant | https://code.launchpad.net/~wgrant/ubuntu/lucid/sbuild/extended-result and https://code.launchpad.net/~wgrant/launchpad/use-system-sbuild are relevant. | 09:32 |
| infinity | 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:32 |
| wgrant | Note that the ddeb hack probably needs to be readded. | 09:33 |
| infinity | That's not difficult. | 09:33 |
| infinity | This was mostly my mess to start with, I'm somewhat familiar with it. | 09:33 |
| wgrant | Not difficult, just ugly as hell :) | 09:33 |
| infinity | No argument here. | 09:34 |
| infinity | What's the blocker on ddebs-in-soyuz? | 09:34 |
| infinity | We already do it for PPAs now, right? | 09:34 |
| infinity | Do we just need a machine from IS provisioned to publish them? | 09:34 |
| wgrant | They need different expiry policies, which means altering the copier to cope with sometimes having expired binaries. | 09:35 |
| wgrant | Because otherwise cocoplum and acamar will melt. | 09:35 |
| wgrant | 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 |
| infinity | It is? | 09:36 |
| infinity | This sort of assumes cocoplum gets a ton more space, then. | 09:36 |
| pitti | micahg: I think it won't make that much difference after all | 09:36 |
| wgrant | It does, yes. | 09:36 |
| infinity | And when you say "separate archive", you do just mean on-disk, I hope? | 09:36 |
| infinity | Actually, wait. How is ddebs laid out? | 09:37 |
| wgrant | infinity: Right, practically they have to be part of the same Soyuz archive. | 09:37 |
| wgrant | I envisage that they will be split like ports is. | 09:37 |
| infinity | Err, we can't, | 09:37 |
| infinity | Not without changing the implementation everywhere. :/ | 09:37 |
| infinity | ddebs re-use archive namespace. | 09:38 |
| infinity | (ie: dists/precise/binary-amd64/Packages) | 09:38 |
| infinity | And we sure as heck aren't adding them to the primary Packages file. | 09:38 |
| wgrant | Of course. | 09:38 |
| wgrant | But we can work around that. | 09:38 |
| wgrant | Like we do with d-i | 09:38 |
| wgrant | Component of main/debug, for example. | 09:38 |
| infinity | Yes, by "changing the implementation everywhere", like i said. :P | 09:38 |
| wgrant | That's roughly 10 lines of code. | 09:39 |
| infinity | You're not in a bubble here. | 09:39 |
| wgrant | In LP. | 09:39 |
| infinity | ddebs has clients. | 09:39 |
| infinity | Moving files around breaks them. | 09:39 |
| pitti | could we keep transitional symlinks for the old packages.gz locations? | 09:39 |
| tumbleweed | putting them in the same archive means mirrors have to carry them | 09:39 |
| wgrant | tumbleweed: No | 09:39 |
| wgrant | tumbleweed: Like ports, they can be split into a separate archive for mirroring. | 09:39 |
| infinity | tumbleweed: No, syncproxy takes care of that. | 09:39 |
| tumbleweed | ah | 09:40 |
| infinity | pitti: I suppose syncproxy could re-create the old hierarcy and symlink to the new, but ew? | 09:40 |
| wgrant | We could do something like the old -commercial hack | 09:40 |
| wgrant | Or we could just update the few users' sources.lists... | 09:40 |
| pitti | 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:40 |
| wgrant | Right, that's how partner went. | 09:41 |
| wgrant | We had a script around for years which mangled partner to dapper-commercial etc. | 09:41 |
| infinity | Yeah, I guess it's doable on syncproxy. | 09:41 |
| infinity | ln -s installer-i386 debug-i386, go. | 09:41 |
| infinity | Err. | 09:42 |
| infinity | Somewhere, I had an aneurysm. | 09:42 |
| infinity | But you know what I meant. | 09:42 |
| infinity | debug-i386 binary-i386 | 09:42 |
| infinity | Anyhow. | 09:42 |
| wgrant | Needs Release mangling as well. | 09:42 |
| pitti | this still scares me a bit | 09:42 |
| wgrant | But there's precedent for this. | 09:43 |
| infinity | wgrant: So, basically, this is waiting on cocoplum being hooked up to the mythical SAN with endless storage. | 09:43 |
| wgrant | The SAN is no longer mythical :) | 09:43 |
| wgrant | The librarian runs on it. | 09:43 |
| pitti | 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 |
| wgrant | pitti: The mirrors won't see them. | 09:43 |
| infinity | pitti: syncproxy. | 09:43 |
| wgrant | It's just like ports. | 09:43 |
| pitti | aah | 09:43 |
| infinity | pitti: It'll split archive/ports/ddebs | 09:43 |
| pitti | yes, nevermind me | 09:44 |
| infinity | wgrant: And there's no need for release mangling. | 09:44 |
| infinity | wgrant: In fact, that would be *wrong*. | 09:44 |
| wgrant | My implementation has been proven pretty robust by Linaro and another few PPAs, which is nice. | 09:45 |
| wgrant | infinity: Huh? | 09:45 |
| infinity | wgrant: Note that http://archive.ubuntu.com/ubuntu/dists/precise/Release includes ports stanzas. :P | 09:45 |
| wgrant | infinity: Yeah | 09:45 |
| infinity | Oh, but you mean mangling for s/debug/binary/ for old releases. | 09:45 |
| infinity | Ugh. | 09:45 |
| wgrant | infinity: But if we symlink binary-i386 -> debug-i386, the hashes for binary-i386 will be wrong | 09:45 |
| wgrant | Yeah | 09:45 |
| infinity | syncproxy doesn't sign things. | 09:45 |
| wgrant | No | 09:45 |
| wgrant | That's why commercial-compat.sh was on cocoplum. | 09:45 |
| micahg | pitti: can you please copy thunderbird 3.1.20 from ubuntu-mozilla-security for lucid-natty to -security please? | 09:45 |
| wgrant | Part of LP | 09:46 |
| infinity | wgrant: What did that do? Do I want to know? :) | 09:46 |
| pitti | micahg: on it | 09:46 |
| pitti | micahg: confirming, !oneiric ? | 09:47 |
| micahg | pitti: correct, I should've deleted that one already | 09:47 |
| wgrant | infinity: http://pastebin.ubuntu.com/896198/ | 09:47 |
| infinity | (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 |
| micahg | pitti: I mean oneiric was already done :) | 09:47 |
| wgrant | Although *-commercial was a different suite, so this just writes a full new Release file... | 09:47 |
| infinity | wgrant: Yeah. My above bit works, though. | 09:48 |
| wgrant | Indeed. | 09:48 |
| infinity | wgrant: You just create a second release file, sign it, and have syncproxy sort the mess. | 09:48 |
| wgrant | We could even sign with a different key if we want. | 09:48 |
| wgrant | I guess. | 09:48 |
| infinity | (Which sucks, but) | 09:48 |
| infinity | No, same key. | 09:48 |
| infinity | It should be transparent to the user once moved around. | 09:48 |
| pitti | micahg: done | 09:48 |
| micahg | pitti: thanks | 09:49 |
| wgrant | infinity: It's not the same key now. | 09:49 |
| infinity | The only cruft would be Release-foo.* on ftpmaster. | 09:49 |
| pitti | yes, but I don't think the current key is very valuable | 09:49 |
| pitti | it's only signed by me really | 09:49 |
| infinity | wgrant: It's not the same key because pitti can't use the archive key. :P | 09:49 |
| infinity | wgrant: That's not a feature. | 09:49 |
| pitti | this whole thing was never intended to last for 6 years :) | 09:49 |
| wgrant | Heh | 09:50 |
| infinity | pitti: Ugh, has it been that long? | 09:50 |
| wgrant | It was Edgy :/ | 09:50 |
| infinity | I feel old. | 09:50 |
| wgrant | Anyway, if we take this approach, we just need to work out expiry policies and find an extra terabyte of disk for cocoplum :/ | 09:50 |
| infinity | wgrant: The disk thing is going to get punted to the SAN. But worth talking to IS about it again. | 09:51 |
| infinity | wgrant: Sorting the LP code sounds like not a lot of work? | 09:51 |
| pitti | does macquarie use the SAN? | 09:51 |
| infinity | wgrant: And then getting IS to sort syncproxy magic. | 09:51 |
| pitti | after all, it has all the ddebs right now | 09:51 |
| infinity | pitti: No, if it did, you wouldn't have to keep purging things you don't like. | 09:51 |
| pitti | 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:52 | |
| * pitti looks at NBS.. http://people.canonical.com/~ubuntu-archive/nbs.html --- c'mon, we can do that | 09:53 | |
| infinity | pitti: I dunno. Removing one package sounds hard. | 09:54 |
| pitti | I'll have a go at toonloop (needs porting) | 09:54 |
| infinity | pitti: gnome-shell probably just needs a give-back, let me look. | 09:54 |
| pitti | infinity: nope | 09:54 |
| infinity | pitti: (I suspect it was fallout from clutter being broken) | 09:55 |
| pitti | I'll ask jbicha about it in the afternoon | 09:55 |
| pitti | no, already tried | 09:55 |
| wgrant | infinity: LP can split the indices in about 10 lines of code. | 09:55 |
| wgrant | infinity: And moving them back to the primary archive is a matter of deleting code. | 09:55 |
| wgrant | Release file mangling is slightly harder, but a bit of awk never hurt anyone... | 09:55 |
| infinity | pitti: Oh, it might need some GL->EGL love of its own. | 09:56 |
| infinity | rsalveti: Do you love gnome-shell as much as you love clutter? ;) | 09:56 |
| infinity | 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:57 |
| infinity | (gnome-shell, that is) | 09:58 |
| pitti | yeah, presumably | 09:58 |
| pitti | but I would at least have a go at toonloop; there's a new upstream release which might help | 09:58 |
| pitti | or a trivial backport | 09:58 |
| infinity | It's universe, I'd rather sync than carry a diff, if no one's actively watching the package. | 09:59 |
| infinity | Which, if it's uninstallable/unbuildable, is probably the case. | 09:59 |
| pitti | we are newer than debian already | 09:59 |
| infinity | Oh. | 09:59 |
| infinity | Fun. | 09:59 |
| pitti | it it takes longer than 15 minutes, I'd probably just opt for removing it *shrug* | 09:59 |
| infinity | It must have a user. | 10:00 |
| Laney | ajmitch: did you get to looking at that haskell stuff? | 10:00 |
| infinity | Someone had a pretty cogent rant about willy-nilly removals in Debian a while ago. | 10:00 |
| infinity | "Just cause it's not worth your time, doesn't mean you aren't ruining someone else's day." | 10:00 |
| wgrant | infinity: Ah | 10:01 |
| infinity | pitti: Also, can I pretend that libical's testsuite failure is your fault, since it's in the desktop seed? | 10:01 |
| wgrant | 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 |
| pitti | infinity: yes, you can | 10:02 |
| seb128 | infinity, it's my fault in fact | 10:02 |
| seb128 | I was hopping Debian would fix it | 10:02 |
| seb128 | slackers | 10:02 |
| infinity | wgrant: That's a self-solving problem when the buildds move to precise. | 10:02 |
| wgrant | infinity: Ha ha ha hah hahdada | 10:02 |
| infinity | wgrant: So, sometime in 2014. | 10:02 |
| wgrant | infinity: Lucid supports ia64 and sparc | 10:03 |
| wgrant | And Lucid doesn't die until 2015. | 10:03 |
| infinity | wgrant: Yes, and? | 10:03 |
| infinity | wgrant: I can keep the internal sbuild implementation for old buildds. | 10:03 |
| wgrant | Does Lucid run on our ia64 and sparc buildds? | 10:03 |
| wgrant | Ah | 10:03 |
| infinity | wgrant: We have the power to work magic here. :P | 10:03 |
| wgrant | That works too, I guess. | 10:03 |
| Daviey | I don't know that ia64 and sparc were also given LTS status.. | 10:03 |
| wgrant | Daviey: We've never removed an arch post-release before. | 10:04 |
| infinity | Daviey: "official" lts status and reality aren't the same thing, don't confuse them. | 10:04 |
| micahg | Daviey: they're at least community supported for the duration | 10:04 |
| wgrant | We didn't even have support for removing archs until I wrote it at the last minute for maverick. :/ | 10:04 |
| Daviey | wgrant: heh.. well, i think it needs to be a consideration.. check if those arches were declared long term. | 10:05 |
| infinity | No, please dn't. | 10:05 |
| infinity | don't* | 10:05 |
| infinity | It's a headache. | 10:05 |
| micahg | Daviey: no, they weren't | 10:05 |
| Daviey | infinity: How is it a headache? | 10:05 |
| micahg | Daviey: armel was supported but not LTS | 10:06 |
| infinity | 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 |
| infinity | It's insanity. | 10:06 |
| Daviey | infinity: I really fail to see the headache.. we just don't ship non-lts point release iso's. | 10:07 |
| Daviey | infinity: No.. hardy still has the pool of desktop open.. doesn't mean it's 'supported' | 10:07 |
| infinity | 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 |
| infinity | Daviey: Uhm, ISOs are something we can much more easily just not build. | 10:07 |
| infinity | Daviey: And it's a disservice to anyone runinng lucid/ppc (hint: including IS) to just stop building new versions completely. | 10:08 |
| Daviey | infinity: what if a sparc SRU ftbfs? it's the same as it never being built.. ie, not published. | 10:08 |
| micahg | Daviey: those ports were community ports from the beginning of Lucid, you can't just remove them | 10:08 |
| infinity | Daviey: If it FTBFS, someone might care and fix it, someone might not. | 10:08 |
| Daviey | micahg: I'm not suggesting they are removed.. i'm saying, if they are not LTS, they are not LTS :) | 10:09 |
| infinity | 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 |
| micahg | Daviey: that only means something as far as canonical support goes | 10:09 |
| infinity | Daviey: Err, you were suggesting they be removed. I was here. | 10:09 |
| Daviey | micahg: No, that isn't true.. | 10:09 |
| infinity | micahg: To be fair, we've now had community discussions about what LTS means (hence community flavours using the term). | 10:10 |
| infinity | That said, the "whole community" doesn't agree to anything. | 10:10 |
| Daviey | infinity: So.. if i want to SRU a fix for Hardy tomboy.. What will happen? | 10:10 |
| infinity | And if I upload one of my packages as an SRU, I expect it to build on every arch. | 10:10 |
| infinity | If it doesn't, I'll fix it. | 10:10 |
| infinity | 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 |
| micahg | Daviey: that's a server/desktop split, quite different that selective archs | 10:10 |
| Daviey | No.. not at all. | 10:11 |
| infinity | Daviey: What do you mean "what will happen"? | 10:11 |
| infinity | Daviey: You can SRU tomboy all you like. | 10:11 |
| micahg | Daviey: in one case you have no security support for your desktop, in the other case it's best effort | 10:11 |
| Daviey | *IF* the arches mentioned were not declared LTS, it's *identical* to the Desktop / Server LTS length split. | 10:11 |
| infinity | "LTS is over" doesn't mean "can't upload SRUs anymore", it means that there's no longer a *commitment* to provide SRUs. | 10:11 |
| Daviey | infinity: If there was a better distinction between pool for desktop and server, the hardy desktop pool wouldn't still be available | 10:12 |
| micahg | I doubt the SRU team would accept an SRU for hardy for a desktop package at this point | 10:12 |
| Daviey | right! | 10:12 |
| infinity | Daviey: That's a blatant lie, but sure. | 10:12 |
| Daviey | infinity: How is it a lie? | 10:12 |
| infinity | micahg: I would. Maybe I should re-join. | 10:12 |
| infinity | Daviey: Because it is. If we broke the packages out, we wouldn't stop publishing them. | 10:13 |
| micahg | Daviey: I explained the difference between the two | 10:13 |
| infinity | Daviey: Your assumption is an assumption, but you stated it as fact. | 10:13 |
| Daviey | 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:13 |
| infinity | Daviey: Hahaha. | 10:14 |
| Daviey | Note, that community flavours are pushing for LTS status.. It's irrelevant to Canonical. | 10:14 |
| infinity | 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:14 |
| infinity | 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 |
| infinity | 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 |
| micahg | 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 |
| Daviey | infinity: well it happens :) | 10:15 |
| infinity | Daviey: Example? | 10:15 |
| Daviey | pitti: Have an example of an SRU that was nack'd for being Desktop, for an expired LTS? | 10:16 |
| infinity | 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 |
| infinity | s/is/it/ | 10:16 |
| micahg | 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 |
| pitti | Daviey: I don't think it ever happened actually | 10:16 |
| infinity | micahg: It's not false hope. By that logic, we should never update a universe package, ever. | 10:16 |
| Daviey | infinity: The cost in man hours for an SRU isn't cheap.. Creating a package and dput'ing is probably the cheapest part! | 10:16 |
| infinity | micahg: Cause it's "false hope" that the rest of universe will be fixed. | 10:17 |
| pitti | it depends on the nature of the change; if it's a truly critical data loss bug I might accept it | 10:17 |
| Daviey | pitti: Really, i thought i saw it previously | 10:17 |
| pitti | but in general I wouldn't | 10:17 |
| micahg | infinity: with a universe package, there support for the main part of the system | 10:17 |
| pitti | I even reject most maverick SRUs these days | 10:17 |
| infinity | Good thing I accepted my own... | 10:17 |
| Daviey | O_o | 10:17 |
| Daviey | You are kidding me? | 10:17 |
| pitti | then again we actually do accept lucid universe SRUs | 10:17 |
| pitti | because lucid has a fairly large user base | 10:18 |
| infinity | pitti: So, the policy is somewhat inconsistent. :P | 10:18 |
| pitti | infinity: well, that's why we have a human SRU team and not automatic checks :) | 10:18 |
| Daviey | 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 |
| pitti | we become more and more strict in what we accept over time | 10:18 |
| micahg | pitti: re lucid SRUs> no reason not to at this point | 10:18 |
| pitti | Daviey: at this point the probability of this is very small | 10:19 |
| infinity | 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 |
| pitti | Daviey: and I really need to see the concrete bug | 10:19 |
| Daviey | pitti: I'm really suprised you'd even consider it, considering desktop hardy is dead. | 10:19 |
| pitti | I just can't write down common sense, weighing risk/benefit and the effort/benefit ratios down in two lines | 10:19 |
| pitti | Daviey: that's what I'm saying; the bar is very very high, and because it is, I don't remember such a case where it even happened | 10:20 |
| infinity | Maybe the SRUs I do are weird cases, but the argument that it's more effort for the SRU team than the uploader is, in my case, very not true. | 10:20 |
| infinity | And I don't like the idea of going to the trouble of fixing something to be told "no". | 10:20 |
| pitti | infinity: in recent cases I didn't actually get any opposition; most people just said "I uploaded because I uploaded for lucid, too" | 10:20 |
| pitti | but maverick survived with these bugs for 17 months | 10:21 |
| Daviey | pitti: Right, but i mean - I was told that if the distinction betwee desktop and server was clearer, the pool for desktop of an expired LTS wouldn't still be published. | 10:21 |
| pitti | anyone using maverick for that long either has learned to live with the bug, or has abandoned it long ago | 10:21 |
| infinity | Daviey: Who told you that? | 10:21 |
| Daviey | infinity: Might have been the security team.. i'd have to grep lgos. | 10:22 |
| Daviey | logs | 10:22 |
| infinity | Turns out that no one small team gets to make those decisions. Thankfully. | 10:22 |
| pitti | Daviey: right; I wish we could move it to old-releases, but that's not techincally possible AFAICS | 10:22 |
| infinity | Or we'd have a mostly empty archive. | 10:22 |
| infinity | In fact, if we had my way, we'd just ship enough for me to run mutt, irssi, and a compiler. | 10:22 |
| Daviey | infinity: mutt or mutt-patched? | 10:23 |
| pitti | but even if we had another openssl incident, we still wouldn't fix it in feisty or gutsy any more, even though there are still installations out there | 10:23 |
| pitti | somewhere you have to draw the line | 10:23 |
| infinity | Daviey: Sidebars are for the weak. | 10:23 |
| Daviey | infinity: yeah, i only use them on the weekend. | 10:23 |
| infinity | pitti: feisty and gutsy are completely EOL and no longer published. That's a bit different. | 10:24 |
| pitti | infinity: not really from the POV of an installed machine | 10:24 |
| pitti | hardy kernel is still being updated, sure | 10:24 |
| Daviey | pitti: well it is, because archive.ubuntu.com will not work for them :) | 10:24 |
| pitti | but we still don't fix desktop-ish bugs any more | 10:24 |
| infinity | pitti: And I think that while listing the support we *commit* to is important, it's silly to say "we shouldn't publish or ever update anything not listed as supported" or, as I say, we should just drop most of universe the day after release. | 10:25 |
| pitti | infinity: yes, I agree | 10:25 |
| pitti | but in practice it doesn't happen | 10:25 |
| pitti | (which is good) | 10:25 |
| Daviey | infinity: that is a silly example.. and not what i was suggesting at all | 10:25 |
| infinity | Daviey: It's not silly at all. | 10:25 |
| pitti | because any hardy desktop SRU that you do is an incredibly high effort for near-zero benefit | 10:25 |
| micahg | infinity: that's not the point, the point is that the main env isn't supported anymore | 10:26 |
| pitti | same for maverick | 10:26 |
| infinity | Daviey: You're suggesting that once an 18-month package set in a 5-year release is EOL, it should be dropped (if it were technically feasible). | 10:26 |
| Daviey | infinity: you are implying that i what i was suggesting is akin to dropping universe after release? | 10:26 |
| Daviey | infinity: Yes! That *is* what i am suggesting. | 10:26 |
| infinity | Daviey: I'm suggesting that, by that logic, universe (except for the packagesets owned by derivatives who commited to support) should be dropped. | 10:26 |
| micahg | infinity: well, at least my point :) | 10:26 |
| Daviey | As a project, we declare the lifetime of a release, with given parameters.. after that date, having *any* updates, is nonsense. | 10:27 |
| * micahg is beginning to see where infinity is going with this :) | 10:27 | |
| infinity | Daviey: We delcare exactly zero post-release support for universe, outside of derivative packagesets. | 10:27 |
| pitti | well, I don't go as far as "nonsense" | 10:27 |
| Daviey | infinity: You are being too accurate.. as a Supported server *will* include universe packages. | 10:28 |
| pitti | but we need a damn good reason for doing them | 10:28 |
| Daviey | But *willnot* include gnome. :) | 10:28 |
| infinity | Daviey: I'm not being too accurate, you're being too focused on your own perceived problem and applying it too broadly. | 10:28 |
| pitti | but really, where's the problem | 10:28 |
| infinity | Daviey: At the end of the day, the status quo is fine. | 10:28 |
| pitti | we are not exactly rejecting 10 hardy SRUs every day | 10:28 |
| pitti | we hardly get any at all | 10:28 |
| micahg | Daviey: yes, those groupings are desktop and server (who does what when is an implementation detail) | 10:28 |
| infinity | Daviey: And the fact that we still build LTS updates for non-LTS arches is, also, fine. | 10:28 |
| Daviey | pitti: You think it's a good use of the SRU team, and those validating to even consider an SRU for something we declared at the release point, will not be supported by either the project or Canonical? | 10:28 |
| ogra_ | and luckily that "problem" will be gone with 12.04 where desktop and server have the same lifetime | 10:29 |
| infinity | ogra_: Nah, cause some desktops are only going 3 years. | 10:29 |
| pitti | Daviey: as I said, if we actually had the problem of reviewing and rejecting hardy SRUs, I'd also stir some trouble; but we don't | 10:29 |
| micahg | ogra_: yes, that's the one good thing about the synergy | 10:29 |
| Daviey | infinity: this discussion started, as we were discussing dropping of two arches which we are not convinced were delcared LTS. Sparc and ia64 | 10:29 |
| pitti | in general, developer's interest in old releasese diminishes fast enough for that problem to fix itself just nicely | 10:29 |
| infinity | ogra_: And unsupported arches are only 18 months. And, and. This is where Daviey gets his knickers in a twist. | 10:29 |
| micahg | infinity: yes, but the archive as a whole is 5yr | 10:29 |
| infinity | micahg: That's patently untrue. | 10:30 |
| micahg | infinity: again who does what when is an implementation detail | 10:30 |
| pitti | Daviey: but assuming that it was the case, then no, it's not a good use of the SRU team's time | 10:30 |
| ogra_ | infinity, but you still cant say "desktop isnt LTS anymore" ... there will likely be a few packages for derivatives that arent LTS, but still | 10:30 |
| micahg | infinity: I mean as in community supported to the extent you can say anything is | 10:30 |
| infinity | micahg: Sure, but that's true of the things Daviey thinks should be dropped too. That was kinda my point. | 10:30 |
| ogra_ | and wrt arches ... if it builds it builds ... i doubt anyone will remove an arm binary from the archive just because | 10:31 |
| infinity | micahg: We either drop all !packageset universe, or we let people SRU it if they want. Architectures are the same. | 10:31 |
| micahg | infinity: yes, which is why I said I see where you're going and stopped arguing with you for the most part :) | 10:31 |
| ogra_ | (and if it doesnt build and is actually still used the community will scream and likely also help) | 10:31 |
| micahg | infinity: I still thing the server/desktop distinction makes sense pre-precise | 10:31 |
| infinity | Daviey: Anyhow. Things are fine. This argument was pointless. Go have a smoke and calm down. | 10:31 |
| infinity | micahg: From a "support expectation" (and commitment) perspective, lots of these distinctions make sense. | 10:32 |
| infinity | micahg: I think enforcing it at the archive level (and actively preventing people from scratching their own itch) is lunacy. | 10:32 |
| infinity | And, I'll note, I SRU into older releases when I feel the urge and no one tells me no. But maybe I'm a unique snowflake. I dunno. | 10:32 |
| micahg | infinity: scratching one's own itch makes sense where there's a base supported system | 10:32 |
| Daviey | infinity: Oh i'm good.. I'd just rather pitti find out why the heck my right click doesn't work in precise, than work on expired releases :) | 10:33 |
| infinity | micahg: There's a "base supported system" right up until we close the release to uploads. | 10:33 |
| infinity | Daviey: You need a new mouse. | 10:33 |
| pitti | Daviey: WFM :) | 10:33 |
| infinity | Daviey: Works here. | 10:33 |
| Daviey | infinity: You don't really accept your own SRU's do you? | 10:33 |
| micahg | infinity: for servers, yes, but not for desktops, and I mean security support really :) | 10:33 |
| infinity | Daviey: Oh, only one specific package, which has a disturbing policy exception. | 10:34 |
| Daviey | pitti: I have a shiney silver laptop, with a fruit on the lid.. which seems less than happy :) | 10:34 |
| infinity | Daviey: (But I did have other people test it) | 10:34 |
| pitti | Daviey: oh, I thought these wouldn't have right mouse buttons in the first place :) | 10:34 |
| infinity | Daviey: Oh, your problem is that you onle have one mouse button. | 10:34 |
| Daviey | gah | 10:34 |
| infinity | Damn, pitti beat me to it. | 10:34 |
| infinity | s/onle/only/ | 10:34 |
| * ogra_ right clicks on Daviey on his arm netbook ... | 10:35 | |
| infinity | http://img.chan4chan.com/img/2009-02-08/1234107430946.jpg | 10:35 |
| ogra_ | Daviey, works here, get better hardware ;) | 10:35 |
| Daviey | heh | 10:35 |
| Daviey | running this every hour or so, seems to work :) | 10:36 |
| Daviey | $ grep -i rightclick ~/.bashrc | 10:36 |
| Daviey | alias rightclick="xinput --set-prop 12 259 0" | 10:36 |
| ogra_ | wow, you make your rightclik work by running grep ? thats cool | 10:37 |
| * ogra_ didnt know grep was that powerful | 10:37 | |
| Daviey | ogra_: it has architecture specific build options, and it's disabled for arm - as it can't handle it. :) | 10:38 |
| ogra_ | haha | 10:39 |
| * infinity decides he needs a nap. | 10:41 | |
| pitti | I'm uploading a new ubuntu-defaults-builder | 10:45 |
| infinity | pitti: Need it reviewed? | 10:45 |
| pitti | our Italian friends want this for beta-2 to build their Italian Edition without oversizing | 10:45 |
| pitti | the potential worst-case impact is breaking the Chinese Edition | 10:46 |
| infinity | stgraber: When you wake up, we might need queuebot back. pitti flooded it off the server. ;) | 10:46 |
| pitti | oh, did it? | 10:46 |
| infinity | 03:07 -!- queuebot [~queuebot@dakara.stgraber.org] has quit [Excess Flood] | 10:46 |
| pitti | it only actually saw maybe 10% of the uploads | 10:46 |
| infinity | pitti: Want to pastebin me a debdiff, and I'll review now before I go to sleep, and you can self-accept. | 10:49 |
| pitti | infinity: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-defaults-builder/precise/revision/135 | 10:49 |
| * infinity doesn't feel like waiting for LP. | 10:49 | |
| infinity | pitti: I prefer debdiffs to be sure they're clean, but I'll take your word for it that you know how to build source packages and compare them. ;) | 10:50 |
| * infinity looks at the bzr diff. | 10:50 | |
| pitti | infinity: the only other commit is http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-defaults-builder/precise/revision/136 | 10:50 |
| pitti | infinity: sure: http://paste.ubuntu.com/896271/ | 10:51 |
| infinity | pitti: That's an odd way to write that. | 10:53 |
| infinity | pitti: Why not filter components first, and then construct the list in a loop? | 10:53 |
| pitti | infinity: indeed, a --delete-apt-components woudl have been easier | 10:53 |
| pitti | infinity: that would be even more code; but I'm open to clever ideas | 10:53 |
| pitti | negating sets in posix shell isn't exactly elegant | 10:53 |
| infinity | It's just a for/case loop to drop things out of the set, and then a for loop to construct the removal list with the remaining bits. | 10:54 |
| infinity | echo | grep -v just feels icky. | 10:54 |
| pitti | infinity: how do you drop things out of a set without echo | grep -v? | 10:56 |
| Daviey | ev: Does server-ship *really* need whoopsie? | 10:56 |
| pitti | infinity: I guess you can use join | 10:56 |
| pitti | phone, bbl | 10:57 |
| Daviey | elmo: Are you going to be unhappy if zsh isn't shipped on the server on-cd-archive? | 10:57 |
| ev | Daviey: it would be nice if we had crash reporting across all Ubuntu products | 10:58 |
| ev | Daviey: but I'm happy to fight you to the death if you disagree | 10:59 |
| Daviey | ev: No, it's currently just in the on-cd-archive.. not installed.. | 10:59 |
| ev | oh, whoops | 11:00 |
| * ev digs | 11:00 | |
| Daviey | ev: I also want the same, but trying to shave space off the cd for thigns that might be required at install time | 11:00 |
| Daviey | oh no, you put it in server-ship and server | 11:00 |
| Daviey | ev: forget i said anything :) | 11:02 |
| ev | Daviey: always ;) | 11:02 |
| didrocks | pitti: ok, so, FYI | 11:10 |
| didrocks | pitti: we got some issues from yesterday | 11:10 |
| didrocks | with some hangs on some hardware (~8 machines on more than 30 testers) | 11:10 |
| didrocks | we workarounded it it | 11:11 |
| didrocks | the hang is fixed on 7 machines on the 8 | 11:11 |
| didrocks | but, 1 of them (and the other getting the hang) sees graphical issues | 11:11 |
| didrocks | not quite sure yet | 11:11 |
| didrocks | but seems sandybridge on amd64 related | 11:11 |
| didrocks | with distro build flags | 11:11 |
| didrocks | some track is that it can be related to i915.i915_enable_rc6=1 | 11:11 |
| didrocks | on the kernel | 11:12 |
| didrocks | but at the end, we have some machines with eventually graphical corruptions | 11:12 |
| didrocks | seems to be a really few of them (not all sandybridge have that issue) | 11:12 |
| didrocks | so, my proposal is still to release | 11:12 |
| didrocks | opening a critical bug about that issue | 11:13 |
| didrocks | put it on the release note | 11:13 |
| didrocks | and ensuring the guys work on that at the top priority | 11:13 |
| didrocks | (the graphical issue is triggered by compiz, we tried new compiz + old unity rebuild to confirm) | 11:14 |
| tseliot | can anybody approve fglrx-installer and fglrx-installer-updates in precise, please? They are not on the cd image | 11:18 |
| stgraber | infinity: fixed ;) | 11:36 |
| stgraber | I should make the bot detect these and just show "150 language-packs" instead of showing every one of them | 11:39 |
| ogra_ | ++ | 11:39 |
| ogra_ | doesnt the ML have such a function already ? | 11:39 |
| ogra_ | (-changes that is) | 11:39 |
| infinity | ogra_: LP just special-cases launguage-pack* and doesn't send the announce to -changes. | 11:41 |
| infinity | stgraber: queuebot not announcing at all would be perfectly fine and in line with that. | 11:41 |
| ogra_ | now that was a short nap ! | 11:41 |
| infinity | I had a shower first. | 11:41 |
| infinity | Nap now. | 11:42 |
| infinity | Bye. :P | 11:42 |
| ogra_ | sleep well | 11:42 |
| stgraber | infinity: done | 11:46 |
| ev | ^ would someone be so kind as to let that through | 12:01 |
| pitti | didrocks: oh, I thought we disabled rc6 on sandybridge again? | 12:10 |
| pitti | didrocks: I agree, it seems better to test the new versino on a bigger scale | 12:10 |
| didrocks | pitti: not that, more experience showed it's not this case though | 12:11 |
| didrocks | so it's ruled out | 12:11 |
| didrocks | pitti: ok, I'm making the release now | 12:11 |
| didrocks | pitti: do you want me to push things in on shot? | 12:11 |
| pitti | on shot? | 12:11 |
| didrocks | pitti: or wait that one is built before the other | 12:11 |
| pitti | didrocks: just go ahead and upload to -proposed, I'll feed it through the queue | 12:11 |
| pitti | didrocks: ah | 12:12 |
| pitti | didrocks: they are build-dep'ing on each other, right? | 12:12 |
| didrocks | right | 12:12 |
| pitti | didrocks: so, just dump them all in and let depwait sort it out | 12:12 |
| didrocks | so arch: matching issue | 12:12 |
| pitti | it's -proposed, it won't break anyone's install | 12:12 |
| didrocks | pitti: yeah, but we have the "… is not installable" | 12:12 |
| didrocks | and have to retry ;) | 12:12 |
| pitti | ah | 12:12 |
| didrocks | because of arch mistmatching | 12:12 |
| pitti | didrocks: well, as you wish; whatever is easier/better for you | 12:13 |
| didrocks | not sure how to keep the overhead low | 12:13 |
| didrocks | pitti: ok, I'll push and poke you about what to accept | 12:13 |
| pitti | didrocks: thanks | 12:13 |
| didrocks | fixing some upstream files not disted in the tarball first | 12:14 |
| pitti | crested and allspice returned to normal amd64 dity | 12:15 |
| pitti | duty | 12:15 |
| pitti | that was darn fast for a full langpack build | 12:15 |
| pitti | tseliot: done | 12:17 |
| cjwatson | wgrant,infinity: I fixed bin/* and .bashrc for the codelines/current -> production/launchpad change | 12:20 |
| * cjwatson restarts all his screened lp_archive shells to get an updated $PATH | 12:21 | |
| wgrant | cjwatson: Thanks. | 12:27 |
| didrocks | pitti: compiz is here ^ | 12:36 |
| pitti | yup, already looking at changelog :) | 12:36 |
| pitti | didrocks: does it change anything in the packaging? | 12:37 |
| pitti | aah, /me gets a debdiff on cocoplum | 12:37 |
| didrocks | pitti: not that I can remember (apart some more distro-patch) | 12:37 |
| pitti | right, not even a soname bump or so | 12:38 |
| didrocks | no, there is an ABI break, but there is no soname to bump | 12:38 |
| didrocks | it's the file mentionning the abi version | 12:38 |
| didrocks | picked and creating a virtual package | 12:38 |
| didrocks | (and packages that dep on compiz will dep on this virtual package as well) | 12:39 |
| pitti | accepted | 12:39 |
| * pitti hands didrocks the prize for the first-ever precise-proposed upload | 12:39 | |
| didrocks | \o/ | 12:39 |
| didrocks | thanks pitti ;) | 12:39 |
| didrocks | uploaded libcompizconfig now, but we may want to wait for compiz to be built to avoid build to relauncher because of unsynced arch | 12:40 |
| didrocks | pitti: there is a version bump here because sil2100 released an intermediate version in a testing ppa without ~ppa1 so it's for those transitions :) | 12:44 |
| didrocks | pushing c-p-m now, need to wait on compiz and libcompizconfig (which is included inside compiz) to be built | 12:45 |
| === greyback is now known as greyback|lunch | ||
| didrocks | compiz-plugins-extra incoming (build-dep on latest compiz and compiz-plugins-main) | 13:04 |
| tseliot | pitti: thanks a lot! | 13:08 |
| cjwatson | ev: done | 13:31 |
| skaet | good morning | 13:33 |
| stgraber | skaet: good morning | 13:34 |
| * skaet sees that precise-proposed is now being used... :) | 13:36 | |
| cjwatson | still only possible during freeze though | 13:38 |
| cjwatson | didrocks: oh, damn, I'm really sorry, I missed what you said above | 13:39 |
| didrocks | pitti: bamf and libunity can be accepted straight away | 13:39 |
| cjwatson | compiz hasn't been published on armel/armhf yet :-/ | 13:40 |
| didrocks | cjwatson: no worry ;) will just need to ask for rebuilding on those arch :) | 13:40 |
| cjwatson | I might be able to rescue this by scoring those builds through the floor | 13:40 |
| didrocks | it's just to avoid having too many FTBFS | 13:40 |
| cjwatson | too late, they've already started | 13:40 |
| didrocks | and have to respawn the build | 13:40 |
| didrocks | waow, that's fast | 13:41 |
| cjwatson | so sorry, you'll have to reupload libcompizconfig - feel free to blame me | 13:41 |
| didrocks | cjwatson: hum, why reupload? | 13:41 |
| didrocks | cjwatson: the build-dep is correct | 13:41 |
| cjwatson | oh, they have a build-dep, don't they | 13:41 |
| didrocks | right | 13:41 |
| cjwatson | ok, great | 13:41 |
| didrocks | it's just that it will FTBFS | 13:41 |
| didrocks | as -dev is published | 13:41 |
| didrocks | but can't install the rest | 13:41 |
| cjwatson | which is not a problem. ok | 13:41 |
| cjwatson | no, -dev is arch-dependent too | 13:41 |
| cjwatson | compiz-dev | 1:0.9.7.2-0ubuntu1 | precise-proposed | amd64, i386, powerpc | 13:41 |
| didrocks | cjwatson: oh that's fine then ;) | 13:42 |
| didrocks | I remember they are some cases when I got FTBFS because of arch skew | 13:42 |
| didrocks | it's just to avoid the amount of retry to have to be done, I always ensure the build-dep are correct | 13:43 |
| didrocks | that* | 13:43 |
| cjwatson | yep, they're going into dep-wait now | 13:43 |
| didrocks | great :) | 13:43 |
| didrocks | nux is safe to accept right away ^ | 13:50 |
| ev | cjwatson: cheers | 13:52 |
| pitti | looking into bamf, nux, libunity | 13:52 |
| didrocks | ok, just uploaded unity. It can be built once compiz-dev libcompizconfig0-dev and nux are built (libnux-2.0-dev is arch:any) | 13:58 |
| didrocks | don't freak out on the inline patch, it's bzr merge ../upstream | 13:58 |
| pitti | https://launchpad.net/ubuntu/+source/libcompizconfig/0.9.7.0~bzr428-0ubuntu6 is properly depwaiting, seems alright | 14:01 |
| pitti | didrocks: ^ | 14:01 |
| didrocks | pitti: yeah, the isses comes on c-p-m IIRC if you install both, as then compiz-dev is pulling libcompizconfig0-dev back | 14:02 |
| pitti | didrocks: does c-p-extra need compiz only, or also compizconfig? | 14:02 |
| didrocks | circular dep on compiz | 14:02 |
| didrocks | c-p-extra needs compiz, compizconfig and c-p-m | 14:02 |
| pitti | didrocks: ah, good | 14:03 |
| didrocks | so basically, libcompizconfig0-dev is dep on itself (because compiz-dev pulls it) to build | 14:03 |
| didrocks | and then it's an nightmare for all plugins | 14:03 |
| didrocks | I know that upstream wants to merge compiz and compizconfig at some point | 14:03 |
| === greyback|lunch is now known as greyback | ||
| didrocks | dee and file lens are fine to accept whenever you want | 14:13 |
| pitti | done | 14:17 |
| ev | ^ hello again. I think this fixes the memory corruption bug in whoopsie. | 14:21 |
| ev | And I would greatly appreciate an approval | 14:21 |
| cjwatson | ev: personally I would have done the close (fd) in src/utils.c after the fd < 0 test, but it doesn't cause a real problem. Otherwise seems fair enough - approved, thanks | 14:25 |
| ev | cjwatson: for aesthetic reasons? | 14:26 |
| ev | and cheers | 14:26 |
| cjwatson | ev: saves a syscall that's going to fail anyway | 14:27 |
| cjwatson | and saves your future self looking at strace and wondering what that EBADF is doing there :) | 14:27 |
| ev | so something like http://paste.ubuntu.com/896490/ then? | 14:30 |
| didrocks | so unity-lens-music and unity-lens-applications uploaded | 14:30 |
| didrocks | u-l-m build-dep on latest dee FYI | 14:30 |
| didrocks | thanks pitti ;) | 14:30 |
| ev | oops, that upload was busted | 14:32 |
| ev | I'll actually run it through pbuilder this time | 14:32 |
| cjwatson | ev: yes | 14:35 |
| cjwatson | s/pbuilder/sbuild/ :-P | 14:36 |
| cjwatson | (doesn't bore you to death unpacking tarballs) | 14:36 |
| pitti | didrocks: ah, libcompizconfig built on arms | 14:36 |
| didrocks | nice ;) | 14:37 |
| didrocks | you can start c-p-m and eventually unity if nux is built | 14:38 |
| pitti | still needs publishing | 14:39 |
| ev | cjwatson: hmm, I'll have to give that a try | 14:42 |
| cjwatson | it's a bit more setup (not much more complex than pbuilder really, but you have to do it all over again); but mk-sbuild really helps and it's much more efficient thereafter with overlayfs | 14:43 |
| ev | is the overlayfs stuff documented somewhere? | 14:43 |
| ev | oh, mk-sbuild | 14:45 |
| ev | gotcha | 14:45 |
| ev | ^ :) | 14:46 |
| ev | fixes the FTBFS | 14:46 |
| cjwatson | ev: mk-sbuild does it out of the box; the configuration variable it uses is documented in schroot.conf(5) | 14:46 |
| ev | cheers | 14:46 |
| didrocks | ^ I expose in g-c-c the new options related to latest unity mutimonitor behavior, that's why I pushed it in -proposed as well (makes more sense to avoid "this option doesn't work" feedback ;)) | 14:46 |
| ogra_ | skaet, how did bug 856988 end up assigned to ubuntu-arm (or why) | 15:01 |
| ubot2` | Launchpad bug 856988 in gstreamer0.10 "totem cannot play quicktime file after upgrade to oneiric" [High,Confirmed] https://launchpad.net/bugs/856988 | 15:01 |
| ogra_ | seesm to cleartly be an amd64 desktop bug | 15:01 |
| skaet | ogra_ will look at after the meeting. | 15:02 |
| ogra_ | great, thanks ! | 15:02 |
| ogra_ | oh, /me totally missed the meeting is running, sorry for disrupting... | 15:02 |
| pitti | seb128: did yo hear anything about a new wallpaper by chance? | 15:06 |
| seb128 | pitti, no I didn't, I assume there is none? | 15:06 |
| pitti | right, that's sorta my question; I guess I'll ask the design guys | 15:07 |
| seb128 | yeah, good diea | 15:07 |
| seb128 | idea | 15:07 |
| pitti | ah, Cimi seems to be on it, nevermind | 15:07 |
| pitti | kenvandine: Riddell says you should talk to shadeslayer about telepathy-qt4 | 15:08 |
| Riddell | cos there's a new version out and he wants it in | 15:08 |
| Riddell | and the new version is out because of the farsight change | 15:08 |
| kenvandine | Riddell, there isn't a new tarball yet | 15:09 |
| kenvandine | i pinged upstream to get an eta on that | 15:09 |
| Riddell | kenvandine: aah | 15:09 |
| kenvandine | i saw the farstream port was merged in git though | 15:09 |
| kenvandine | so i assume it is coming soon | 15:09 |
| Riddell | kenvandine: http://lists.freedesktop.org/archives/telepathy/2012-March/006022.html | 15:09 |
| Riddell | which I haven't read | 15:09 |
| kenvandine | oh | 15:10 |
| kenvandine | it is out | 15:10 |
| pitti | didrocks: oh, he's back! | 15:10 |
| didrocks | yeah, just pushed unity-2d, which is the last of the family :) | 15:10 |
| kenvandine | Riddell, oh.. the moved the releases url, damn | 15:10 |
| pitti | erk, sorry, I realize this is -release; I meant to speak on #-desktop | 15:11 |
| didrocks | build-dep on latest nux and libunity-core (unity) | 15:11 |
| pitti | I reordered my IRC columns for the meeting | 15:11 |
| didrocks | :) | 15:11 |
| kenvandine | shadeslayer, do you want me to do the telepathy-qt update to 0.9.1 or are you doing it? | 15:11 |
| pitti | didrocks: anyway, back on release topic | 15:11 |
| === bladernr_ is now known as bladernr_afk | ||
| pitti | didrocks: libcompizconfig built, nux publishing | 15:11 |
| pitti | didrocks: I can do c-p-main now, right? | 15:11 |
| didrocks | right! | 15:11 |
| pitti | err, s/built/published/ | 15:11 |
| didrocks | once nux is there, you can go ahead with unity | 15:12 |
| didrocks | (didn't see if g-c-c was accepted yet btw) | 15:12 |
| pitti | didrocks: and the lenses should be fine now, too? | 15:12 |
| didrocks | yeah, just the -music ones dep on latest dee | 15:12 |
| didrocks | one* | 15:12 |
| shadeslayer | kenvandine: feel free to do it | 15:13 |
| shadeslayer | kenvandine: It was on my todo for tomorrow | 15:13 |
| kenvandine | shadeslayer, ok | 15:13 |
| shadeslayer | kind of on a coding kick right now :P | 15:14 |
| kenvandine | shadeslayer, ok, i'm on it | 15:14 |
| shadeslayer | awesome | 15:14 |
| pitti | didrocks: ^ that doesn't depend on any nux & friends, right? | 15:16 |
| didrocks | pitti: unity-2d? | 15:16 |
| didrocks | 16:11:07 didrocks | build-dep on latest nux and libunity-core (unity) | 15:17 |
| pitti | ah, ok | 15:17 |
| didrocks | pitti: see why I regularly complain about ABI break and chain dependency? :-) | 15:17 |
| didrocks | compiz -> libcompizconfig -> unity -> unity-2d is the longest chain | 15:18 |
| didrocks | (but you can have libunity| nux -> unity -> (nux|) unity-2d) | 15:18 |
| ogra_ | juts merge all of it into one big package (like kde in the past) ;) | 15:18 |
| didrocks | (and you can replace libunity by bamf as well in the schema, adding bamf-qt… :p) | 15:18 |
| didrocks | or dee and add the lenses ;) | 15:19 |
| didrocks | ogra_: all staticly linked? ;) | 15:19 |
| didrocks | and then rewrite on go! | 15:19 |
| ogra_ | yay | 15:19 |
| ogra_ | thats the future ! | 15:19 |
| didrocks | do not forget the gconf backend fix as well (just pushed) ;) | 15:35 |
| didrocks | compiz gconf backend | 15:35 |
| pitti | didrocks: nux is published; triggering unity | 15:36 |
| didrocks | great ;) | 15:37 |
| * cjwatson giggles at http://raphaelhertzog.com/2012/03/23/people-behind-debian-joerg-jaspert/ - "I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject)" | 15:51 | |
| cjwatson | I should do that | 15:51 |
| stgraber | :) | 15:54 |
| Laney | first word: "NACK" | 15:55 |
| skaet | ogra_, re: 856988, was a mistake on my part, was late, sorry. | 16:01 |
| ogra_ | skaet, great, thought so | 16:01 |
| slangasek | ^^ that perl is the other half of bug #948848. | 16:01 |
| ubot2` | Launchpad bug 948848 in mono "cil packages fail to uninstall on lucid->precise upgrade due to prerm script use of perl-modules via /usr/share/cli-common/gac-package-remove -> /usr/share/cli-common/runtimes.d/mono (Can't locate File/Basename.pm in @INC)" [High,Fix released] https://launchpad.net/bugs/948848 | 16:01 |
| slangasek | jibel will be happy to have it in, I think :) | 16:01 |
| slangasek | oh, and I think the mono build on armel took out the buildd | 16:02 |
| slangasek | who can stab that for me? | 16:02 |
| slangasek | (I've spot-checked the build log twice now over a span of an hour and a half, and it doesn't look like it's progressed) | 16:03 |
| slangasek | lamont: ^^ ? | 16:03 |
| jibel | slangasek, I am happy \o/ thanks | 16:06 |
| skaet | :) | 16:08 |
| slangasek | jibel: then we'll be able to see the NEXT upgrade failure bug in the stack ;) | 16:13 |
| brendand | skaet, ping | 16:18 |
| skaet | hiya brendand | 16:18 |
| brendand | skaet, we verified https://launchpad.net/bugs/888219 is fixed | 16:18 |
| ubot2` | Launchpad bug 888219 in linux "[ThinkPad E420] Wifi is always soft blocked" [High,Confirmed] | 16:18 |
| brendand | eh, wrong one. haha | 16:18 |
| brendand | this one: https://launchpad.net/bugs/882253 | 16:19 |
| ubot2` | Launchpad bug 882253 in linux "[Thinkpad E520] SDHC card unable to be mounted" [High,Incomplete] | 16:19 |
| brendand | skaet, the other one we are verifying now | 16:19 |
| skaet | brendand, good news. :) | 16:19 |
| skaet | apw, ^ | 16:19 |
| skaet | Thank you. :) | 16:19 |
| apw | skaet, brendand, great, have marked 882253 as Fix Release in P | 16:20 |
| brendand | skaet, apw - i'll ping you over the status of the E420 wifi bug if i get it by the end of the day | 16:21 |
| skaet | thanks brendand | 16:22 |
| cjwatson | pitti: ^- maybe you could look at localechooser, since we'd discussed that; that's the first half of the change, there's a corresponding change to ubiquity once that's in | 16:36 |
| cjwatson | (also an FTBFS fix in ubiquity) | 16:37 |
| pitti | cjwatson: sure, thank you | 16:37 |
| cjwatson | pitti: any luck? | 16:51 |
| cjwatson | sorry, just want to get ubiquity sorted | 16:51 |
| pitti | sorry, waited a bit for diff, looking now | 16:51 |
| cjwatson | ah, ok | 16:51 |
| pitti | that looks spot-on, thanks | 16:52 |
| slangasek | pitti, cjwatson: could either of you review the perl upload? | 16:52 |
| pitti | cjwatson: so LOCALE_TRANSLATIONS is the language, and $LOCALE the region bit, right? | 16:52 |
| pitti | slangasek: yep, can do; that was for the new conflicts:, I suppose | 16:53 |
| cjwatson | pitti: right | 16:53 |
| slangasek | pitti: exactly | 16:53 |
| pitti | cjwatson: accepted | 16:53 |
| pitti | slangasek: let's hope that apt's resolver groks that :) | 16:53 |
| brendand | skaet, apw - yep, bug 888219 fixed too! | 16:53 |
| cjwatson | great. I'll prepare a new ubiquity the cheating way (I have the source package locally, no need to wait for it ...) | 16:53 |
| ubot2` | Launchpad bug 888219 in linux "[ThinkPad E420] Wifi is always soft blocked" [High,Confirmed] https://launchpad.net/bugs/888219 | 16:53 |
| slangasek | pitti: if it doesn't, we can roll back and do the SRU that cjwatson didn't want | 16:54 |
| pitti | mono-gac has a large dependency chain | 16:54 |
| apw | skaet, i've closed 888219 off as Fix Released too | 16:54 |
| mdeslaur | skaet, slangasek: can I upload a fix for bug #962378 | 16:54 |
| ubot2` | Launchpad bug 962378 in ca-certificates-java "multiarch broke circular dependency workaround" [High,Confirmed] https://launchpad.net/bugs/962378 | 16:54 |
| pitti | slangasek: anyway, it can't break installs, so I'm fine with accepting this now | 16:54 |
| slangasek | pitti: also, can you do something about the broken armel build of mono? It's stalled out | 16:54 |
| cjwatson | it wasn't that large | 16:54 |
| cjwatson | and it was mostly mono libraries, rather than anything involving perl | 16:54 |
| pitti | slangasek: sorry, I can't; that's IS matter | 16:54 |
| slangasek | mdeslaur: yes please | 16:55 |
| slangasek | pitti: you can't kill the build and let it get picked up on another builder? | 16:55 |
| pitti | that reminds me that I was to remind infinity to eventually implement the Cancel button for distro builders :) | 16:55 |
| slangasek | ok | 16:55 |
| pitti | slangasek: no, only for PPAs | 16:55 |
| slangasek | infinity: wake up :P | 16:55 |
| pitti | I can reassign builders | 16:55 |
| mdeslaur | slangasek: thanks, done. | 16:55 |
| pitti | and give back/prioritize, etc. | 16:55 |
| pitti | or tell an amd64 builders to build i386 instead, or something | 16:55 |
| pitti | but Cancel isn't implemented in the web UI | 16:55 |
| pitti | slangasek: actually vanguard in #is should be able to | 16:56 |
| skaet | mdeslaur, what slangasek says. :) thanks | 16:56 |
| mdeslaur | skaet: thanks | 16:56 |
| slangasek | pitti: wow, did you notice that my conflicts version comparison was wrong for 2 of 3 packages in that perl upload? :/ | 16:59 |
| slangasek | (I just noticed it now because I was going to edit the diff for submission to Debian) | 16:59 |
| pitti | slangasek: argh Friday evening/hectic blindness :/ | 16:59 |
| slangasek | pitti: it shouldn't matter in practice since the only version the check is wrong for will soon be unavailable in the Ubuntu archive | 16:59 |
| pitti | right | 17:00 |
| pitti | *phew* | 17:00 |
| pitti | missing ubuntu1 | 17:00 |
| pitti | ^ if someone coudl review this, didrocks will pay him a beer | 17:03 |
| pitti | seb128: ugh @ indicator-appmenu "rewrite half of the code" | 17:03 |
| pitti | seb128: how much testing did that get? | 17:03 |
| didrocks | pitti: I'll pay you one as well! | 17:03 |
| pitti | didrocks: c-p-main published | 17:04 |
| didrocks | great ;) | 17:04 |
| pitti | didrocks: accepting c-p-extra | 17:04 |
| didrocks | yeah | 17:05 |
| didrocks | thanks! | 17:05 |
| pitti | still waiting for unity/armel for unity-2d | 17:05 |
| pitti | didrocks: I need to leave in about 20 minutes, so someone else would need to do that then | 17:05 |
| didrocks | and makes the pocket copy? | 17:05 |
| pitti | that, too | 17:05 |
| pitti | didrocks: you can also do it yourself | 17:05 |
| pitti | didrocks: sru-release precise compiz unity whatnot... | 17:06 |
| pitti | from lp:ubuntu-archive-tools | 17:06 |
| didrocks | pitti: from cocoplum? | 17:06 |
| didrocks | or my machine? | 17:06 |
| pitti | didrocks: no, from your box | 17:06 |
| pitti | lplib | 17:06 |
| didrocks | ok, that will close the bugs as well, isn't it? | 17:06 |
| pitti | didrocks: if you are uncomfortable with that, just tell someone here the list of packages | 17:06 |
| pitti | they should all be copied in one go | 17:06 |
| pitti | didrocks: yes | 17:06 |
| didrocks | ok, and appearing on the ML I guess | 17:07 |
| pitti | didrocks: they will appear twice | 17:07 |
| pitti | didrocks: they appeared for -proposed already | 17:07 |
| pitti | and they will appear again when copying, under the name of whoever runs the script | 17:07 |
| didrocks | ok ;) I won't freak out then | 17:07 |
| pitti | so do it yourself, otherwise you won't get all the bug count :) | 17:07 |
| * didrocks rushes ;) | 17:07 | |
| didrocks | let's wait for unity armel to be fine | 17:07 |
| didrocks | to start pocking for 2d :) | 17:08 |
| pitti | that said, let me do it! that'll give me a nice jump in front of seb | 17:08 |
| pitti | seb128: ah, saw your ping in -desktop | 17:08 |
| didrocks | pitti: depends on how much beer you will pay me then! :) | 17:08 |
| lamont | slangasek: anyone in webops is the new target for machine smackery | 17:10 |
| slangasek | ok | 17:11 |
| infinity | slangasek: Don't wanna. | 17:17 |
| slangasek | oh, well all right then | 17:17 |
| slangasek | also, #is is on it | 17:18 |
| infinity | Oh, dang. I just caught the tail end of that. | 17:20 |
| infinity | Would have liked to see ps output from that machine before people started killing willy-nilly. | 17:20 |
| didrocks | pitti: launchpad is seeing armel being built, can you poke unity-2d? | 17:21 |
| pitti | unity | 5.8.0-0ubuntu1 | precise-proposed | source, amd64, armel, armhf, i386, powerpc | 17:23 |
| pitti | didrocks: accepted | 17:23 |
| didrocks | thanks pitti :) | 17:23 |
| didrocks | will wait for it to build/publish on every arch | 17:23 |
| didrocks | and then do the publishing, I have the list here | 17:24 |
| pitti | so, need to leave now, sorry | 17:24 |
| pitti | didrocks: FYI, if you run sru-release, they will appear in https://launchpad.net/ubuntu/precise/+queue?queue_state=1 | 17:24 |
| pitti | didrocks: you will have to accept them from there to really get them copied | 17:25 |
| pitti | didrocks: they will appear as syncs | 17:25 |
| didrocks | pitti: ah ok, will do! :) | 17:25 |
| pitti | good night everyone, have a nice weekend! | 17:25 |
| pitti | didrocks: it tells you so, and the link, don't worry | 17:25 |
| didrocks | have a good night and good week-end pitti, thanks again ;) | 17:25 |
| didrocks | ok ;) | 17:25 |
| seb128 | re | 17:28 |
| skaet | good night pitti. | 17:28 |
| seb128 | pitti, hey, it's not "half the code", it's an hundred line and pretty much easy code ;-) | 17:28 |
| seb128 | pitti, 'nighty | 17:28 |
| micahg | pitti: cancel button in the archive UI is a bad idea unless they fix the you can't retry a canceled build issue | 18:08 |
| infinity | micahg: There are two different "cancels", one of which kills builds, the other completely blacklists it. | 18:12 |
| infinity | micahg: I don't really know who thought implementing the latter was a good idea. :P | 18:12 |
| infinity | micahg: (The latter could have uses for a build that is known to break machines, or something, but it should be pretty clearly marked as dangerous, and available to a limited set of pepole) | 18:13 |
| infinity | micahg: Anyhow, hooking up proper build abort semantics would be the softer version. :P | 18:14 |
| didrocks | cjwatson: hum, I need to look at the sru-release script, it wants to copy to -updates | 18:26 |
| didrocks | pitti: ^ | 18:26 |
| rsalveti | infinity: haha, not that much, but I can check | 18:27 |
| rsalveti | infinity: what is the issue with gnome-shell? | 18:27 |
| cjwatson | didrocks: mm, yeah. you could cowboy http://paste.ubuntu.com/896797/ for now. | 18:28 |
| infinity | rsalveti: Looks like more GL versus EGL hatred. | 18:28 |
| rsalveti | infinity: ok, will take a look | 18:28 |
| didrocks | cjwatson: right, hwat I just did :) | 18:28 |
| didrocks | cjwatson: I'll have a cleaner version for later :) | 18:28 |
| * cjwatson nods | 18:28 | |
| didrocks | cjwatson: thanks for confirming | 18:28 |
| didrocks | ok, the queue didn't seem to yell, let me copy the other before syncing everyone in a row | 18:31 |
| didrocks | ok, time to copy that to the Release pocket :) | 18:34 |
| cjwatson | looks plausible enough to me | 18:35 |
| cjwatson | all the binaries built in -proposed? | 18:35 |
| didrocks | cjwatson: right, all were built (was waiting on unity-2d) | 18:36 |
| didrocks | seems to have worked | 18:36 |
| didrocks | just need a publisher round I guess? | 18:36 |
| skaet | cjwatson, is that bulk of removeds the copy over from -proposed to -release? | 18:37 |
| cjwatson | skaet: yes | 18:39 |
| cjwatson | didrocks: yes | 18:39 |
| didrocks | ok, I'll stay around and have a look to ensure all is fine/published :) | 18:39 |
| slangasek | is this related to the most recent upgrade autotest failure involving compiz-core-abiversion-20120228, by chance? | 18:39 |
| cjwatson | not sure why gnome-control-center and nux aren't listed as removed, but I'm going to assume that's a bot glitch since they're gone from the queue itself | 18:39 |
| didrocks | slangasek: hum, I didn't see that one. We didn't get any unsync from what I know? | 18:40 |
| didrocks | cjwatson: I guess so | 18:40 |
| didrocks | slangasek: if people are using third party packages (like the wallit…smothing package) from a ppa, there can have some ABI mismatch | 18:41 |
| didrocks | if it's the automated upgrade tests, we have an issue, yeah :) | 18:41 |
| slangasek | didrocks: this is the autotester | 18:41 |
| slangasek | https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/63/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all-amd64/apt.log | 18:41 |
| didrocks | slangasek: wasn't aware about it, let me look | 18:41 |
| slangasek | Installing unity-common as Depends of unity | 18:41 |
| slangasek | unity:amd64 Depends on compiz-core-abiversion-20120228 [ amd64 ] < none > ( none ) can't be satisfied! | 18:41 |
| slangasek | Broken unity:amd64 Depends on compiz-core-abiversion-20120228 [ amd64 ] < none > ( none ) | 18:42 |
| slangasek | Considering compiz-core:amd64 20 as a solution to unity:amd64 12 | 18:43 |
| slangasek | Holding Back unity:amd64 rather than change compiz-core-abiversion-20120228:amd64 | 18:43 |
| slangasek | the same error didn't happen with the previous test from 5 hours earlier | 18:43 |
| * cjwatson wonders whether to put this linux-firmware upload on hold, given that it needs an associated linux upload to be effective | 18:43 | |
| didrocks | slangasek: apt-cache show unity=5.6.0-0ubuntu4 … Depends: … compiz-core-abiversion-20120228, | 18:43 |
| cjwatson | and would need a d-i upload afterwards too | 18:44 |
| didrocks | so the virtual package that unity picks is coherent with what is in the distro | 18:44 |
| slangasek | didrocks: yes, but somehow apt thinks it shouldn't install it, whereas it had no problem doing so 5 hours earlier... assuming it's not the perl/mono change, I wonder what else has changed that caused this? | 18:44 |
| didrocks | slangasek: yeah, it's really puzzling… compiz-plugins-main-default was installed and dep on the same virtual package | 18:45 |
| cjwatson | is telepathy-farstream urgent? new upstream release, no bugs mentioned | 18:45 |
| didrocks | slangasek: and the dep is compiz, compiz-core-abiversion-20120228, to ensure it tries to build one compiz first | 18:46 |
| didrocks | s/build/install | 18:46 |
| cjwatson | I'd appreciate somebody reviewing ubiquity - fixes build failure and a rls-p-tracking bug | 18:46 |
| didrocks | slangasek: that process didn't change since natty | 18:46 |
| infinity | cjwatson: I'll look at ubiquity. | 18:47 |
| infinity | cjwatson: No opinions about the kernel thing, but if it's just a time concern, I can make sure i386 lands on roseapple (i386 is usually the bottleneck), which gets all arches in < 4h. | 18:48 |
| cjwatson | I'm confused by that autotest log too | 18:48 |
| cjwatson | infinity: I just figure that if we're not having another kernel upload for beta2 (an assumption), then there's no point | 18:48 |
| didrocks | slangasek: I'll try to talk to mvo on Monday about it | 18:49 |
| infinity | cjwatson: Why would it need a new kernel upload to take advantage of adding firmware? | 18:49 |
| cjwatson | see the bug - the kernel module isn't in scsi-modules either | 18:49 |
| infinity | Oh. Check. | 18:50 |
| cjwatson | bug 963306 | 18:50 |
| ubot2` | Launchpad bug 963306 in linux-firmware "Intel(R) C600 SAS Controller Driver is boot essential" [Undecided,Fix committed] https://launchpad.net/bugs/963306 | 18:50 |
| infinity | cjwatson: Yea, looked. | 18:50 |
| slangasek | didrocks: well, I was hoping to have validation today that the mono+perl change is good :( | 18:50 |
| didrocks | slangasek: yeah, I really have no clue why you get that suddenly | 18:50 |
| didrocks | slangasek: the new release has a new ABI, but we are in the same state, with unity dep on the new abi and new vitual package | 18:51 |
| didrocks | virtual* | 18:51 |
| infinity | cjwatson: From my experience with tp-qt4, my guess is that the farstream sync is required for the tp-qt4 upload to be happy. | 18:51 |
| cjwatson | if you know it, feel free to review :) | 18:51 |
| infinity | cjwatson: (The tp-qt guys don't really understand backward compat as well as the tp-glib folks) | 18:52 |
| cjwatson | maybe the autotester was operating on a half-complete proposed stage? | 18:52 |
| didrocks | cjwatson: that can be an explanation | 18:52 |
| didrocks | as there is a new ABI | 18:52 |
| cjwatson | at the time it ran, it wouldn't have been all the way there | 18:53 |
| didrocks | but the autotester has -proposed enabled? | 18:53 |
| infinity | cjwatson: Yeah, sure, I'll take the two telepathy bits for review. | 18:53 |
| cjwatson | it does | 18:53 |
| didrocks | ah :) | 18:53 |
| didrocks | slangasek: so you have your explanation ^ | 18:53 |
| cjwatson | I think largely as an accidental result of having lucid-proposed enabled in order to get upgrade code from there | 18:53 |
| slangasek | oh | 18:53 |
| slangasek | heh, ok | 18:53 |
| cjwatson | you can see it in https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/63/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all-amd64/main.log | 18:53 |
| slangasek | right, cool - so a re-test should show something useful | 18:54 |
| cjwatson | and it makes some sense that if you have lucid-proposed then you want precise-proposed | 18:54 |
| cjwatson | right | 18:54 |
| didrocks | the new compiz provides compiz-core-abiversion-20120305 as a virtual package | 18:54 |
| slangasek | jibel: can you manually re-try the precise-upgrade-lucid-main on both archs? The daily test failed because unity was temporarily uninstallable in precise-proposed | 18:54 |
| didrocks | slangasek: yeah, new run should be safe now | 18:54 |
| didrocks | phew, after a crazy week, finally nothing scarying at the end of it ;) | 18:55 |
| infinity | cjwatson: This is basically just mirroring the localechoose change locally in localechooser-apply? Trying to visually diff those two hurts. ;) | 18:55 |
| didrocks | thanks cjwatson for finding the issue ;) | 18:56 |
| cjwatson | infinity: yeah. curse oem-config anyway. | 18:56 |
| cjwatson | (it has to have a cloned version because it isn't operating on /target. one day I should turn it into automatic seddery.) | 18:57 |
| infinity | cjwatson: We really need to just do a better job of exporting target=/ all over the place. | 18:57 |
| infinity | cjwatson: And accepted. | 18:57 |
| cjwatson | ta | 18:58 |
| cjwatson | yeah, some bits of d-i code support that, some don't | 18:58 |
| cjwatson | needs some reunification by somebody really anal. | 18:58 |
| infinity | I have a rectum. | 18:58 |
| infinity | I'm not sure if I *really* have one. | 18:58 |
| cjwatson | I thought you were a robot. | 18:59 |
| infinity | I'm a poorly-designed robot. | 18:59 |
| astraljava | At least you're considerably more intelligent than ubot2`, though. | 19:10 |
| infinity | cjwatson: tp-farstream looks good, accepting that. | 19:11 |
| infinity | cjwatson: I'll do tp-qt4 a bit later, when my brain's not being bent by p11-kit, or when I want another "break". | 19:11 |
| * cjwatson nods | 19:15 | |
| slangasek | cjwatson: we're avoiding :any deps because of lucid->precise upgrades, right? | 19:22 |
| cjwatson | yes | 19:23 |
| * slangasek nods | 19:23 | |
| cjwatson | wine-gecko1.4 has "Recommends: wine1.4:any", I notice | 19:23 |
| cjwatson | I forget exactly how fatal the parser error is ... | 19:23 |
| slangasek | bug #962854 | 19:24 |
| ubot2` | Launchpad bug 962854 in gconf "Upgrade 11.10 to 12.04 failed on gconf2" [High,Confirmed] https://launchpad.net/bugs/962854 | 19:24 |
| slangasek | the gconf-service package provides both arch-dependent and arch-independent interfaces | 19:24 |
| slangasek | and this is /after/ Np237 did extensive package splitting for multiarch :/ | 19:24 |
| cjwatson | does an approach like the one I suggested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641614#25 work here? | 19:24 |
| ubot2` | Debian bug 641614 in libidl "please convert to multiarch" [Normal,Open] | 19:24 |
| slangasek | it should, though adding Yet Another Binary will make me sad | 19:25 |
| cjwatson | an intermediate package which is Architecture: all and Multi-Arch: foreign, and whose sole purpose is to contain the dep that would otherwise be :any | 19:25 |
| cjwatson | yeah :-/ | 19:26 |
| slangasek | you don't think the release upgrader apt mitigates this adequately? | 19:26 |
| cjwatson | I don't think we can rely on that, and in any case germinate also doesn't understand :any at this point | 19:26 |
| slangasek | I guess that would rather conclusively break 'apt-get' upgrades of the lucid desktop though | 19:26 |
| slangasek | ah, ok | 19:26 |
| cjwatson | (not that I expect the latter to be persuasive to Np237, but) | 19:26 |
| slangasek | alright, we'll do it the ugly way | 19:27 |
| cjwatson | I forget what its failure mode is; I was going to do something about it since we'll need it eventually, but I think I shelved it since all such deps had to be purged for precise anyway | 19:27 |
| cjwatson | I think it just omits following those deps | 19:27 |
| cjwatson | slangasek: wait, am I following your analysis correctly? you're saying that the plugin has to be of the same arch as the rev-dep; wouldn't that imply gconf-service Multi-Arch: allowed, gconf2 Depends: gconf-service, not gconf-service:any? | 19:30 |
| cjwatson | :any seems counterproductive | 19:31 |
| slangasek | cjwatson: sorry, I said it the wrong way around - I mean that the /other/ revdeps would need to use gconf-service:any | 19:31 |
| cjwatson | ah | 19:31 |
| cjwatson | right, so you'd end up with a gconf-service-any binary or something as the intermediate | 19:31 |
| slangasek | (basically, all other revdeps aside from gconf2 itself) | 19:31 |
| rsalveti | infinity: lovely, there's one plugin using opengl directly by hand | 19:31 |
| cjwatson | ok, so lots more packages to change, too | 19:31 |
| rsalveti | infinity: that's specifically why they are using cogl and clutter, to avoid forcing one single opengl interface | 19:32 |
| infinity | rsalveti: :( | 19:32 |
| cjwatson | $ grep-aptavail -FPre-Depends,Depends gconf-service -nsPackage | wc -l | 19:32 |
| cjwatson | 62 | 19:32 |
| cjwatson | eek | 19:32 |
| rsalveti | but sometimes they break the rule, and break everyone not using gl | 19:32 |
| cjwatson | ok, sort -u reduces to 31, still | 19:32 |
| rsalveti | infinity: will check with linaro folks to see if we can port this plugin | 19:32 |
| infinity | rsalveti: Sure. Is it a plugin we can just conditionally disable on ARM for the time being, or is it something painfully central and useful? | 19:33 |
| rsalveti | infinity: it's the shell-screen-grabber, maybe we can disable | 19:33 |
| rsalveti | I'll take a look | 19:33 |
| cjwatson | slangasek: I can't think of an analogous hack in the other direction, that would allow you to force same-arch for a dependency on an otherwise M-A: foreign package. Can you? That would allow confining the hack to a single package | 19:33 |
| cjwatson | (in any case, squeeze's apt has the same problem, doesn't it? and Debian doesn't have release-upgrader-apt) | 19:35 |
| slangasek | nope, can't think of a way to do it the other way around | 19:36 |
| cjwatson | I think there may just be a limit on how much it's possible to do in a single stable release cycle ... | 19:37 |
| infinity | To be fair, M-A upgrades are generally fine if you don't enable a second arch on upgrade. | 19:43 |
| infinity | It's our attempt to violently do so (because we wanted to be rid of ia32-libs) that makes it rough. | 19:43 |
| slangasek | they wouldn't be if we started using dependencies that the old apt doesn't understand | 19:43 |
| infinity | s/generally/always/ | 19:43 |
| slangasek | (not merely "can't satisfy", but *doesn't understand*...) | 19:43 |
| infinity | slangasek: Well, there's that. | 19:44 |
| infinity | I hadn't realised we'd gone down that path. I missed reading scrollback here. | 19:44 |
| infinity | What happened to the old Debian rule of not using new dpkg/apt features until stable+1? :P | 19:44 |
| rsalveti | infinity: great, seems upstream has the fixes at the wayland branch, to actually be able to use opengles | 19:45 |
| rsalveti | infinity: I'll try them and let you know how it goes | 19:45 |
| infinity | rsalveti: Oh, shiny. | 19:45 |
| cjwatson | infinity: we haven't (mostly) | 19:45 |
| infinity | cjwatson: "mostly". ;) | 19:45 |
| cjwatson | one exception which I think Scott Ritchie had promised to get rid of | 19:45 |
| cjwatson | hmm, he's closed the bug, but it's still there | 19:46 |
| infinity | rsalveti: If only every bug I was working on had an "oh look, upstream's already done the hard work for me" branch. :) | 19:46 |
| slangasek | infinity: right, that's basically why I'm whining, because the new feature makes this clean(ish) and avoiding it is ugly | 19:46 |
| slangasek | anyway, the path forward is clear from here | 19:46 |
| infinity | slangasek: Well, we have (in the distant past) provided static dpkg/apt for Debian stable upgrades. Though with no lovely frontend to inform users of that fact, just release notes that no one reads. | 19:47 |
| infinity | I do remember them being by-hand jammed into the archive though. | 19:47 |
| slangasek | yep | 19:48 |
| rsalveti | infinity: haha, yeah, but still need to test and validate ;-) | 19:54 |
| rsalveti | it can't be that easy | 19:55 |
| infinity | rsalveti: Pessimist. ;) | 19:55 |
| slangasek | skaet: what would you like to do with bug #876298? | 20:47 |
| ubot2` | Launchpad bug 876298 in update-notifier "[FFe] [MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [Critical,Triaged] https://launchpad.net/bugs/876298 | 20:47 |
| * skaet looking | 20:47 | |
| skaet | slangasek, is there any way the behavior will be worse than what happens now when failure happens (code not 100%). Ideally I'd like to pull this into beta 2, so it can bake as long as possible, but it might be best just after beta 2. How ready is it? | 20:53 |
| * skaet thinks getting this in before release is a good idea, just timing. | 20:54 | |
| slangasek | well, it's possible the behavior could be "worse" in the sense that we manage to fail to ever download flashplugin for the user and so flash doesn't work without the user knowing why | 20:55 |
| slangasek | I don't think I want to push the code to the archive today - I'd like to iterate a bit more with mvo. | 20:55 |
| skaet | slangasek, ok, lets aim for just after Beta 2 then, I'll mark it approved. | 20:59 |
| slangasek | skaet: ok, thanks | 20:59 |
| micahg | skaet: will you take an upload for bug 958385 during the freeze (breaks on screen keyboard for xubuntu) | 21:07 |
| ubot2` | Launchpad bug 958385 in onboard "Encoding mismatch when mousetweaks is missing" [Undecided,Fix committed] https://launchpad.net/bugs/958385 | 21:07 |
| skaet | micahg, yes, bug fixes are still welcome during the freeze, esp. early on. | 21:08 |
| micahg | skaet: I won't get to this until the weekend | 21:08 |
| skaet | micahg, is it Xubuntu specific, or wider? | 21:09 |
| * skaet thinks it looks wider... | 21:09 | |
| micahg | the bug is, the package is seeded in ubuntu and edubuntu as well | 21:09 |
| micahg | skaet: ^^ | 21:10 |
| skaet | yes, if we can be sure it won't cause regression on either of those, I'm fine with pulling it on monday (or earlier). | 21:10 |
| micahg | hmm, ok, will look for the fix over the weekend and see if it's likely to break stuff | 21:11 |
| skaet | thanks micahg! :) | 21:11 |
| jibel | slangasek, lucid main is running. I disabled -proposed too since release-upgrader-apt is in -updates now. | 21:20 |
| slangasek | jibel: ok, cheers :) | 21:21 |
| jbicha | rsalveti: thanks for working on the gnome-shell ARM build problem | 21:31 |
| rsalveti | jbicha: np | 21:32 |
| slangasek | ^^ addressing upgrade bug #962854 | 21:52 |
| ubot2` | Launchpad bug 962854 in gconf "Upgrade 11.10 to 12.04 failed on gconf2" [High,In progress] https://launchpad.net/bugs/962854 | 21:52 |
| slangasek | infinity: ^^ if you can look at the above at some point, would be appreciated; needs unapproved and binary new processing | 21:55 |
| infinity | New packages? Oh my. | 21:56 |
| infinity | slangasek: I'll poke it when LP gets around to giving me a diff. | 21:57 |
| infinity | I'll go find lunch while I wait. :P | 21:57 |
| slangasek | okie | 21:57 |
| infinity | Hrm, did someone review and approve the telepathy-qt4 that was on my TODO? | 22:20 |
| infinity | Guess so. | 22:20 |
| infinity | jdstrand: I have to know, what does hamster-indicator indicate? | 22:33 |
| infinity | jdstrand: (And the part where the short description doesn't give me any clues might be a bug) :P | 22:35 |
| slangasek | does syncpackage respect the freeze queue? | 22:41 |
| cjwatson | yes | 22:41 |
| slangasek | good-o | 22:41 |
| cjwatson | there've been several syncs in the queue at various points just this freeze | 22:42 |
| * cjwatson is perplexed by bug 961046 and agrees it's not terribly pretty - but I don't understand what criteria were used to tag it rls-mgr-p-tracking | 22:44 | |
| ubot2` | Launchpad bug 961046 in ubiquity "oem-config: Content of the slideshow shifted to the bottom right" [Medium,Triaged] https://launchpad.net/bugs/961046 | 22:44 |
| infinity | cjwatson: I dunno, that kind of user experience is pretty important to people. | 22:45 |
| slangasek | rls-mgr-p-tracking is more of an incoming queue than anything else | 22:45 |
| infinity | (Also, WTF? How did that happen?) | 22:45 |
| infinity | slangasek: gconf is through NEW. | 22:48 |
| slangasek | infinity: cheers | 22:48 |
| skaet | slangasek, yes, its an incoming/consider queue. Most are there if high/critical and targetted against the release, found in the iso testing, etc. | 23:01 |
| micahg | anyone opposed to a no change rebuild to change the suggests from cpio on libarchive1? | 23:22 |
| micahg | nevermind, I"ll just wait until after beta freeze | 23:23 |
| cjwatson | skaet: is there a set of rough criteria somewhere for removing that tag? | 23:35 |
| cjwatson | infinity: I agree it's important, I just don't see it as RC in any sense | 23:36 |
| skaet | cjwatson, for that one, I've gone in and removed it, since it isn't judged high. | 23:36 |
| * skaet needs a tag for those considered, but not making the rls-p-tracking list. | 23:36 | |
| * cjwatson nods | 23:36 | |
| cjwatson | at some point there are going to be some bugs we forget about though :) | 23:37 |
| infinity | cjwatson: Well, given that it's still the oneiric slideshow anyway, I assume the artsy-fatsy folks will raise this again if it's an issue when they do precise stuff. | 23:37 |
| cjwatson | not saying this is one of them, but | 23:37 |
| infinity | artsy-fartsy, too. | 23:37 |
| infinity | Oh, wait. No, maybe that's a Pangolin. | 23:37 |
| infinity | My brain's not all here. | 23:37 |
| cjwatson | It was updated for 12.04 last week | 23:38 |
| infinity | Yeah. | 23:38 |
| infinity | Ignore me. | 23:38 |
| infinity | Spending two hours looking at code to type end up typing a 1-line, 10-character fix has driven me off the deep end. | 23:38 |
| infinity | s/type // | 23:38 |
| slangasek | accepting p11-kit | 23:39 |
| infinity | slangasek: \o/ | 23:39 |
| slangasek | infinity: thanks :) | 23:39 |
| skaet | cjwatson, aiming for launchpad release high+critical = ( incoming U p-tracking U p-someoneelse ) then the searches that work can help me figure out gaps. | 23:40 |
| cjwatson | p-tracking => rls-mgr-p-tracking or rls-p-tracking? | 23:41 |
| skaet | p-incoming (rls-mgr-p-tracking) p-tracking is rls-p-tracking. maybe p-nottracking, for other? | 23:41 |
| cjwatson | Maybe we could just use the literal tag names rather than ambiguous abbreviations? :-) | 23:43 |
| * cjwatson <- very confused now | 23:43 | |
| skaet | cjwatson, yeah, the names this release were an evolutionary mistake | 23:43 |
| skaet | and we missed a new tag. | 23:43 |
| skaet | maybe for next release rls-q-incoming, rls-q-tracking, rls-q-nottracking - clearer? | 23:44 |
| cjwatson | Only if the set of bugs it's worth applying rls-q-nottracking to is very strictly limited. It would be pretty bad to have to tag a few hundred thousand bugs just to make sure nobody worries about them. | 23:46 |
| skaet | cjwatson, agreed, its just the state it goes in once one of the development teams or release team members have looked at the rls-q-incoming, and decided its not a priority for this release. | 23:47 |
| cjwatson | Sounds like we might as well just remove the tag. | 23:48 |
| skaet | am finding cases in the last search where folks have removed the rls-mgr-p-tracking tag, put on a rls-p-tracking tag, and then removed both.... which leaves me the fun of rediscovering it all over again. :P | 23:48 |
| cjwatson | It's in the bug history. | 23:48 |
| cjwatson | It's not like it vanishes. | 23:48 |
| skaet | yeah, and requires manual checking each time though. | 23:48 |
| cjwatson | It's not searchable in bulk, but the entire point of rls-q-nottracking is that you don't search for it. | 23:49 |
| cjwatson | It'd be pretty easy to lplib | 23:49 |
| cjwatson | Although personally I'd find Ctrl-F in the browser easier ... | 23:49 |
| cjwatson | I just don't really see the point of rls-q-nottracking unless it's in some category of bug that you'd be looking at as a source of rls-q-incoming bugs; in which case it might be worth spelling out those categories | 23:50 |
| cjwatson | If possible | 23:51 |
| cjwatson | Because maybe we should be removing the bugs from those as well if they aren't that important | 23:51 |
| skaet | In LP advanced searches, I can specify high & critical , and then remove all with tags rls-q-tracking, rls-q-nottracking, rls-q-incoming, and just find out those that haven't sorted, without writing a script. | 23:51 |
| cjwatson | So you're saying that "the set of bugs it's worth applying rls-q-nottracking to" (as I asked for above) is Priority high/critical? | 23:52 |
| cjwatson | (or Importance or whatever it is) | 23:52 |
| skaet | yes, assuming they made it on the list q-incoming at some point. | 23:53 |
| cjwatson | I guess I can run with that, although maybe if they don't matter they should be downgraded | 23:53 |
| cjwatson | (Though, OK, package-specific priority != project priority) | 23:53 |
| * skaet nods | 23:53 | |
| cjwatson | I think you're going to spend a lot of time trawling through large numbers of bugs if you do that though ... | 23:53 |
| skaet | cjwatson, by having these lists, the quality of my life has significantly improved this release, compared to past ones. | 23:54 |
| skaet | :) | 23:54 |
| cjwatson | mkay | 23:54 |
| * skaet spent way, way,way too much time screen scraping and putting things in a spreadsheet and manually tracking to get the same type of info. | 23:55 | |
| === Riddelll is now known as Riddell | ||
| === rsalveti` is now known as rsalveti | ||
| * ScottK hurrumphs that if it's worthwhile it should be hard .... | 23:58 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
