| micahg | infinity: when you can a chance, can you release thunderbird, lightning-extension, and enigmail? | 00:28 |
|---|---|---|
| cjwatson | stgraber et al: I've changed the precise daily image builds to use -proposed, to make it possible to verify installer/cdimage-type changes | 08:39 |
| cjwatson | been meaning to do that for a while | 08:40 |
| quadrispro | bdmurray, | 09:10 |
| quadrispro | libmtp's been reuploaded to precise-proposed | 09:10 |
| ogra_ | nice, the arm live images work astonishingly well | 11:49 |
| xnox | ogra_: did manage to boot, while you were having lunch? =)))))) | 11:58 |
| ogra_ | heh, kind of, it boots into the installer and does the install ... though the copying process takes ages ... i'm massively spoiled by preinstalled images | 11:59 |
| * ogra_ is curious if the bootloader bit will work | 11:59 | |
| xnox | I was planning migrating my laptop to UEFI boot, but I'm not sure weather to reinstall or migrate the installation from the backup | 12:00 |
| ogra_ | hmm, the partitioner isnt able to read the MBR of my USB disk, weird | 12:03 |
| ogra_ | bah, and indeed it chrashed at the bootloader install stage | 12:14 |
| === tkamppeter__ is now known as tkamppeter | ||
| tumbleweed | infinity: I (and my IRC logs) can't remember. Did we increase the build timeouts for pypy? 1.9 has been building very happily in Ubuntu but timing out everywhere in Debian (and in quite a few of my PPA builds on Ubuntu) | 12:16 |
| stgraber | cjwatson: thanks, that'll be quite useful | 13:14 |
| stgraber | ogra_: yep, thanks for that work! I built an Edubuntu omap4 live image yesterday afternoon and it worked great (haven't tried installing though, just been checking the live environment) | 13:15 |
| infinity | tumbleweed: I don't think we did any sbuild timeout magic. And even if we had, PPAs use the same configs. | 15:11 |
| * tumbleweed wonders why on earth it isn't timing out, then | 15:12 | |
| tumbleweed | compare https://buildd.debian.org/status/package.php?p=pypy&suite=experimental with https://launchpad.net/ubuntu/+source/pypy/1.9+dfsg-1 | 15:12 |
| infinity | tumbleweed: Our timeouts might be slightly less agressive, I don't recall off the top of my head. | 15:25 |
| infinity | tumbleweed: Our systems might also suck less. | 15:25 |
| tumbleweed | heh | 15:26 |
| tumbleweed | infinity: if you wouldn't mind increasing the timeouts for the benefit of PPA builds, I'd appreciate it. And it looks like I need to request this in Debian too | 15:30 |
| Laney | skaet: So are we going to send a "response from the release team" to this discussion? | 16:31 |
| ogra_ | infinity, would you mind doing the changes to /etc/default-arches ? i know i will break it again if i touch it ... | 16:31 |
| Laney | That's what I was after from it :P | 16:31 |
| infinity | ogra_: You do seem to be good at breaking it. | 16:31 |
| ogra_ | infinity, omap, omap4 and mx5 desktop need to be added to the normal live ... ac100 needs to stay preinstalled from quantal on | 16:31 |
| ogra_ | no crontab changes needed i think | 16:31 |
| infinity | ogra_: Can do. This is going to annoy the heck out of people doing live builds. ;) | 16:32 |
| ogra_ | oh, indeed, they now take longer | 16:32 |
| infinity | Oh, how I can't wait for more ARM hardware. | 16:32 |
| infinity | ogra_: A lot longer. Times 3. | 16:32 |
| ogra_ | we should probaly move back to ARCHES in crontab for that | 16:32 |
| ogra_ | to keep this build separate | 16:32 |
| infinity | crontab isn't the issue, it's manual builds. | 16:32 |
| skaet | Laney, rather than add to the mess that that thread is, I'll start off a new one on the goals, and see if we can get some planning structure in place to pull in the input from all the stakeholders in an effective manner. | 16:33 |
| ogra_ | and not make the change in default-arches | 16:33 |
| infinity | No one cares (or, they shouldn't) how long the cron entry takes. | 16:33 |
| ogra_ | it will also be the manual build you run on nusakan | 16:33 |
| ogra_ | (during milestones when doing rebuilds) | 16:33 |
| Laney | skaet: OK. I think it's important to emphasis that the RT doesn't want to change anything for Q but that we are cautiously supportive of the goals. | 16:34 |
| skaet | Laney, agreed. | 16:34 |
| * Laney looks at the wind/rain and thinks twice about cycling home | 16:34 | |
| stgraber | ogra_: we should probably also check that the cronjob timing will still be good after that change. | 16:35 |
| * skaet looks at the outside thermometer and wishes for wind and rain.... summer is now in Austin. | 16:35 | |
| ogra_ | stgraber, thats why i think using ARCHES for this might be better | 16:35 |
| infinity | stgraber: It won't be. | 16:35 |
| cjwatson | I hate to say this, but I'll revert changes that put ARCHES in crontab | 16:35 |
| infinity | Really, I need the army of new Pandas I was promised to materialise. | 16:35 |
| cjwatson | I put a lot of work into getting rid of that | 16:35 |
| ogra_ | cjwatson, hmm, but do you really want a live build to take hours ? | 16:36 |
| cjwatson | I don't especially care | 16:36 |
| cjwatson | At least not for cronned builds | 16:36 |
| infinity | ogra_: Like I said, I don't care for cron jobs. And no one should. | 16:36 |
| ogra_ | no, but for manual ones | 16:36 |
| cjwatson | Those don't follow the crontab anyway | 16:36 |
| infinity | ogra_: It's by-hand stuff that's more annoying to people. And that has nothing to do with crontab. | 16:36 |
| ogra_ | cjwatson, they follow default-arches | 16:37 |
| infinity | ogra_: THey don't have to. :P | 16:37 |
| cjwatson | Not mandatorily | 16:37 |
| ogra_ | and are only as fast as the slowest build | 16:37 |
| infinity | ogra_: And they haven't always. | 16:37 |
| ogra_ | yes, i know they havent always | 16:37 |
| cjwatson | The pad-based "big sequence of stuff to build" often has manual ARCHES overrides. | 16:37 |
| ogra_ | ok | 16:37 |
| cjwatson | That much is fine. It's just not OK in the crontab. | 16:37 |
| ogra_ | if the pad is enough to handle it thats fine | 16:38 |
| cjwatson | (Well, not fine, but tolerable.) | 16:38 |
| infinity | Well, the pad is meant to turn into something better. | 16:38 |
| cjwatson | Yes. | 16:38 |
| infinity | It's on my list of stuff and things. | 16:38 |
| ogra_ | i just dont want the wrath of all team on me just because the build suddenly goes 4h longer since i added arm to the build | 16:38 |
| ogra_ | *teams | 16:38 |
| cjwatson | The correct answer (at least based on the current world order) is to have enough extra builders to have the new cron builds parallelised. | 16:38 |
| infinity | cjwatson: Yes, and I was promised a MandaBox in the DC to solve this issue. | 16:39 |
| infinity | cjwatson: I need to chase that up. I bet it's there and collecting dust. | 16:39 |
| ogra_ | a month ago, wasnt it ? | 16:39 |
| * skaet --> lunch | 16:39 | |
| * ogra_ packs his bags and wanders off to watch greece kick germanys butt ;) | 16:41 | |
| infinity | ogra_: That's some real national pride you have there. | 16:42 |
| ogra_ | heh | 16:42 |
| infinity | ogra_: But, really, Greece is pretty much just a German province at this point. | 16:42 |
| ogra_ | well i do my duty at least ... going to the beergarden to watch the game that is :) | 16:42 |
| infinity | ogra_: Or, they soon will be. | 16:42 |
| infinity | ogra_: So, you're essentially kicking your own butts! | 16:42 |
| ogra_ | yeah, i'm already watching out for an island :) | 16:42 |
| xnox | infinity: it's always fun to watch minions play | 16:42 |
| * cjwatson has his ninth (or so) go at fixing LP copying of custom uploads | 16:43 | |
| infinity | cjwatson: Ninth time's the charm. That's what they always say when trying to off cats. | 16:43 |
| infinity | * Note: I do not condone the offing of cats. | 16:44 |
| skaet | ogra_, have fun. :) | 16:44 |
| cjwatson | I think the nearest approximation to a right answer is that, when you copy a package containing a custom upload, LP should synthesise uploads to the target series/pocket containing only the custom files | 16:45 |
| === skaet is now known as skaet_afk | ||
| === skaet_afk is now known as skaet_ | ||
| cjwatson | That's how it works for copying custom uploads across to new series; it's a bit weird but it works, and absent some equivalent of BinaryPackagePublishingHistory that's useful for custom files, it's about the best we can do | 16:45 |
| infinity | cjwatson: Will that also buy us auto-rotation/expiry of custom published bits, or do we still need to mangle that by hand? | 16:46 |
| cjwatson | Should do, because it'll go through the normal custom upload publication code at that popint. | 16:46 |
| cjwatson | *point | 16:46 |
| infinity | \o/ | 16:46 |
| infinity | That'll be a massive win for the one AA task that no one ever remembers to perform until someone points out it's been broken for six months. | 16:47 |
| cjwatson | Yeah. (Though sru-release started nagging about it, which I think has helped.) | 16:47 |
| cjwatson | But I've been trying on and off for months to make this work, so maybe best not hold your breath :-) | 16:48 |
| cjwatson | As usual writing the tests is the incredibly difficult bit | 16:48 |
| ScottK | infinity: Isn't that true for most of Europe now? | 16:49 |
| infinity | ScottK: Perhaps. It turns out that being rich was a far better strategy than wearing grey outfits and killing everyone. | 16:53 |
| ScottK | Yes. Absolutely. | 16:53 |
| ScottK | From a US policy POV this is a case of be careful what you ask for, you may get it. | 16:54 |
| === rsalveti` is now known as rsalveti | ||
| infinity | cjwatson: Also, vaguely related, after watching the publisher grind for 28m last night on a single libreoffice.translation.tar.gz, I'm wondering why ftpmaster is doing that job at all. I assume we don't hard-crash the publisher is a translation tarball import fails (I hope?), so can't we just fire and forget that at some appserver somewhere, and take it from 28m to a second or two? | 17:01 |
| infinity | s/is a/if a/ | 17:01 |
| cjwatson | I'm not sure how that stuff works | 17:03 |
| infinity | Me neither. It's a black box to me. | 17:03 |
| infinity | I think it is to almost everyone, which could explain why it's never been optimised. | 17:03 |
| cjwatson | Let me have a look at the logs and see if I can hazard a guess | 17:04 |
| cjwatson | 2012-06-22 01:03:16 DEBUG Publishing custom libreoffice, libreoffice_3.5.4-0ubuntu1_amd64_translations.tar.gz to ubuntu/precise | 17:04 |
| cjwatson | 2012-06-22 01:29:02 DEBUG Successfully processed queue item 4298271 | 17:04 |
| cjwatson | That bit, I take it | 17:04 |
| infinity | cjwatson: That bit, yeah. | 17:04 |
| infinity | cjwatson: THe 28m is a bit unfair, as it was fighting for I/O with bug 1013583, but even if that weren't the case, it would be maybe 14m, which seems crazy. | 17:05 |
| ubot2 | Launchpad bug 1013583 in apt "contents-generation could be 2x faster by not regenerating Packages/Sources" [Medium,New] https://launchpad.net/bugs/1013583 | 17:05 |
| infinity | cjwatson: And a minute or two for smaller translation tarballs. | 17:05 |
| cjwatson | Hm, right | 17:05 |
| cjwatson | So this is PackageUploadCustom.publishRosettaTranslations | 17:05 |
| cjwatson | Which calls SPR.attachTranslationFiles | 17:05 |
| cjwatson | Which indeed is dealing with inserting files into the translation queue | 17:06 |
| cjwatson | I think in the modern world it should be creating a job for that | 17:06 |
| infinity | Seems out of scope for the publisher to do, yeah. | 17:06 |
| infinity | Hence the fire-and-forget suggestion. | 17:06 |
| infinity | You know, when you finally admit you're a Launchpad developer and so this stuff full time. | 17:07 |
| * infinity ducks. | 17:07 | |
| cjwatson | That's a fairly standard mechanism for pushing off long-running things to script servers | 17:07 |
| cjwatson | Never happening :-P | 17:07 |
| infinity | s/so/do/ | 17:07 |
| * cjwatson is not StevenK | 17:07 | |
| infinity | No, you don't bring Vegemite to conferences. | 17:07 |
| infinity | For which I'm grateful. | 17:07 |
| cjwatson | If you want an example of stuff causing jobs to be created, look at Archive.copyPackage -> PackageCopyJob | 17:08 |
| cjwatson | I'm a little surprised there isn't a job class for this already, actually. | 17:09 |
| infinity | cjwatson: Oh, would you say from the lack of response on mirrors (other than the one dude who seemed to argue that they were useless but he wanted something else), that we can probably remove ls-lR.gz. Unless you really wanted to talk to iwj about him being the only use-case. :P | 17:09 |
| cjwatson | I dunno, I'm uncomfortable with it because I do actually know more than one user of that mirroring software :) | 17:10 |
| infinity | You're not one of them, are you? *suspicious look* | 17:11 |
| cjwatson | I'd kind of prefer to pursue the "blat it out of the ftparchive cache" approach | 17:11 |
| cjwatson | No, I use debmirror | 17:11 |
| stgraber | ls-lR.gz is usually the file I'm using to test download speed from mirrors ;) | 17:11 |
| infinity | Yeah, and I just use rsync. (well, Debian's fancy rsync wrapper mirror script) | 17:11 |
| infinity | All our "real mirrors" would never use ls-lR.gz for anything, so it's all about small home users using Ian's tool. Surely, it can be rejiggered to not require it. | 17:12 |
| infinity | Or just make it a debmirror wrapper. :P | 17:12 |
| cjwatson | I dunno. I guess I can ask. I don't like dropping features if it's avoidable though. | 17:12 |
| cjwatson | lp.soyuz.scripts.tests.test_copypackage.TestDoDirectCopy.test_copy_custom_upload_files | 17:12 |
| cjwatson | Ran 1 tests with 0 failures and 0 errors in 4.522 seconds. | 17:13 |
| cjwatson | Ooh | 17:13 |
| infinity | Yay? | 17:13 |
| infinity | And sure, if we can make a-f do it with a significant performance increase over the current coreutils implementation, that seems reasonable. | 17:13 |
| cjwatson | I think there may be a degree of cautious yay | 17:13 |
| === skaet_ is now known as skaet | ||
| cjwatson | https://code.launchpad.net/~cjwatson/launchpad/copy-custom-uploads/+merge/111653 *pant* | 18:04 |
| cjwatson | We won't be entirely able to get rid of the manual copy process until I also fix bug 827941, but that's a really easy follow-up branch at this point. | 18:05 |
| ubot2 | Launchpad bug 827941 in launchpad "Copy ddtp-translations uploads to new distroseries" [High,Triaged] https://launchpad.net/bugs/827941 | 18:05 |
| cjwatson | (In fact, it can be done independently.) | 18:07 |
| cjwatson | There we go, branch pushed for that too. I'll file an MP for it later. | 18:26 |
| xnox | I would love someone to accept autofs, this is a package rename autofs5 -> autofs, following merge from debian | 19:44 |
| === yofel_ is now known as yofel | ||
| === Ursinha` is now known as Ursinha | ||
| === Ursinha is now known as Guest72428 | ||
| === Guest72428 is now known as Ursula | ||
| === Ursula is now known as Ursinha | ||
| xnox | thank you! | 22:56 |
| infinity | Did someone remove autofs5 and its binaries before that landed or something? | 23:03 |
| infinity | Cause most of the binaries the queue thinks are NEW shouldn't be. :/ | 23:03 |
| xnox | infinity: autofs ships transitional packages with old names | 23:03 |
| xnox | of autofs5 | 23:03 |
| xnox | which are arch all | 23:04 |
| infinity | xnox: No, I'm looking at the queue, and almost everything it's marking as NEW isn't. | 23:04 |
| infinity | xnox: Hence the "did someone remove the old binaries?" bit. | 23:04 |
| * infinity shrugs and will sort it out. | 23:04 | |
| xnox | but it just got accepted! | 23:04 |
| infinity | ... | 23:04 |
| infinity | Binaries. | 23:04 |
| xnox | infinity: I'm off to read about ArchiveAdministration as I don't understand launchpad's new queue administration. Nor debian's for that matter. | 23:06 |
| xnox | Deleted 8 minutes ago by Jamie Strandboge | 23:06 |
| xnox | renamed to autofs | 23:06 |
| xnox | Published on 2012-04-26 | 23:06 |
| xnox | Copied from ubuntu precise in Primary Archive for Ubuntu | 23:06 |
| xnox | infinity: ask jdstrand =)))) | 23:07 |
| infinity | jdstrand: You made life more difficult by removing the autofs5 package. | 23:07 |
| infinity | jdstrand: You should have waited for autofs to take over all the binaries. | 23:07 |
| jdstrand | infinity: hrm. I was unaware of that. why? | 23:08 |
| xnox | and wait for autofs5 to end up in the NBS.... | 23:08 |
| infinity | jdstrand: Because now all the binaries are NEW again. So, I have to go carefully re-ovveride them all. | 23:08 |
| infinity | jdstrand: (When, in fact, none of these binaries were new at all) | 23:08 |
| jdstrand | infinity: well, you could leave that to me-- it is my archive day after all :) | 23:08 |
| xnox | jdstrand: and we have no autfs in the archive now =) | 23:08 |
| infinity | jdstrand: Okay, so you'd better carefully re-override them all to match. Either way. :P | 23:08 |
| jdstrand | xnox: I used -S | 23:09 |
| jdstrand | the binaries are still there | 23:09 |
| xnox | jdstrand: oh, ok. | 23:09 |
| infinity | jdstrand: Not in a way that the queue knows about, evidently. :P | 23:09 |
| jdstrand | infinity: I was responding to 'no autofs in the archive now' | 23:09 |
| infinity | jdstrand: Heh, yeah. | 23:09 |
| infinity | jdstrand: Anyhow. I'll leave the overriding to you. It's just irksome with main/universe split packages to have to re-do it when you didn't have to. :) | 23:10 |
| jdstrand | well, I'll remember for next time | 23:10 |
| * jdstrand has to do it the hard way | 23:10 | |
| * xnox jdstrand see sign ^^^^^^ "be prepared to apologise to the release team | we accept payment in cash, check or birdseed" | 23:11 | |
| xnox | =) | 23:11 |
| jdstrand | I figure my apology is doing the work :) | 23:12 |
| * xnox likes birdseeds =) | 23:12 | |
| infinity | jdstrand: Well, it was a chastisement when I was going to do the work. With you doing the work, it's more pointing out that you could have been more efficient. ;) | 23:13 |
| jdstrand | heh | 23:14 |
| * cjwatson <- obviously glutton for punishment. I'm trying to track down all the various places where LP fails to honour P-a-s ... | 23:25 | |
| jdstrand | I'll do the remaining source NEWs over the weekend | 23:28 |
| infinity | cjwatson: The saner thing would be just phasing out P-a-s, probably. | 23:30 |
| infinity | cjwatson: I thought I heard rumors that Debian was wanting to do away with it, now that Arch lines are significantly more expressive. | 23:30 |
| cjwatson | They're only doing so really gradually, AFAICS. | 23:31 |
| infinity | Fair point. | 23:31 |
| xnox | what's P-a-s ? | 23:31 |
| cjwatson | I'm pretty sure I can fix all three known classes of failures to handle P-a-s, and one unreported one, in about 10/20 lines, maybe plus a bit more for tests. | 23:31 |
| infinity | xnox: Packages-arch-specific. | 23:32 |
| cjwatson | Packages-arch-specific - a central override file allowing us to prevent some packages being attempted for build on some architectures | 23:32 |
| xnox | ah, ok. | 23:32 |
| infinity | It has more uses in Debian, like that wanna-build used to REALLY suck at sorting out source:binary relationships on arches that didn't build every binary a source has in debian/control, so P-a-s was used to denote arch-specific binaries. | 23:33 |
| infinity | This allowed wanna-build to be more accurate about if a source was out-of-date and needed building. | 23:33 |
| infinity | We don't use any of that functionality, we just use the source->arch blacklisting. | 23:33 |
| cjwatson | Anyway, it was one of the two things I could see that would break when killing off delayed copies. | 23:35 |
| cjwatson | (Which is a consequence/benefit of making Archive.copyPackage work for copying things out of private archives, i.e. for the security team.) | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!