=== Ursinhal is now known as Ursinha
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[03:32] <micahg> I would prefer if there were only one version of mozjs in the archive, truthfully, it doesn't matter since it's not supportable in any event
[03:33] <darkxst> micahg, that is basically impossible
[03:33] <micahg> darkxst: what is impossible?
[03:33] <darkxst> well only having the new mozjs
[03:34] <micahg> is stuff still not ported 8 months after release?
[03:34] <darkxst> couchdb uses invalided syntax as a core feature, so they can't port to mozjs17 without breaking every user extension ever written
[03:34] <micahg> as I said, in truth, it doesn't matter, since it's not supportable from a security standpoint
[03:35] <darkxst> I am not aware of any othere projects that have ported, but so far Fedora and the crazy rolling distros are the only ones to have packaged mozjs
[03:35] <darkxst> ^mozjs17
[03:36]  * micahg wonders if this should move somewhere else, -motu?
[03:37] <darkxst> micahg, ok
[06:19] <chrisccoulson> infinity, i don't. like firefox, it's something i have very little time for these days :/
[07:48]  * slangasek moves gdbserver to main
[09:23] <jibel> when i386 and amd64 images are being smoketested, checksums in http://cdimage.ubuntu.com/daily-live/current/ doesn't correspond to the images available in this directory
[09:23] <jibel> checksums are from the 29th but i386 and amd64 images are from the 28th
[09:23] <jibel> which makes checksum validation possible only if pending and current are in sync
[09:32] <xnox> jibel: but smoketesting should be done on /pending/ images where checksums do match, no?!
[09:32] <jibel> xnox, right, but during that time images in current are "invalid"
[09:33] <jibel> xnox, and pending is mainly for smoketesting, current for any other test on "known good" images
[09:34] <xnox> jibel: yes. /current/ can be a mix of images, but there is only one checksums file at the moment. I guess we do need per image checksums and/or signatures....
[09:34] <infinity> We have per-image checksums, in said file.
[09:35] <infinity> It's just a bug if it's not being generated correctly, not something that needs reengineering.
[09:36] <jibel> I guess checksums files in current are a copy from pending, not regenerated from the actual content of current
[09:36] <xnox> jibel: the checksums under http://cdimages.ubuntu.com/daily-live/20130728/ and http://cdimages.ubuntu.com/daily-live/20130729/ are correct.
[09:37] <xnox> jibel: so one can lookup build timestamp, then go to full url to fetch static checksum file and verify against it.
[09:37] <jibel> xnox, but http://cdimage.ubuntu.com/daily-live/current/ are not
[09:37] <cjwatson> jibel: They're supposed to be regenerated ...
[09:37] <infinity> jibel: Indeed, that appears to be the case.
[09:37] <cjwatson> xnox: You don't need to be a support firewall here :)
[09:37] <infinity> cjwatson:
[09:37] <xnox> cjwatson: =) ack.
[09:37] <cjwatson> If it's broken, we should fix it
[09:37] <infinity> cdimage@nusakan:~/cdimage/www/full/daily-live/current$ md5sum -c MD5SUMS
[09:37] <infinity> saucy-desktop-amd64+mac.iso: OK
[09:37] <infinity> saucy-desktop-amd64.iso: FAILED
[09:37] <infinity> saucy-desktop-armhf+omap4.img: OK
[09:37] <infinity> saucy-desktop-i386.iso: FAILED
[09:37] <infinity> saucy-desktop-powerpc.iso: OK
[09:37] <infinity> md5sum: WARNING: 2 computed checksums did NOT match
[09:37] <cjwatson> infinity: Right, I'll have a look
[09:37] <jibel> thank you
[09:41] <cjwatson> Perplexing.  This is absolutely meant to work.
[09:42] <cjwatson> However I have children screaming in the background so you'll have to wait a bit until my concentration isn't shredded. :-/
[09:47] <cjwatson> slangasek: Back when you disabled zh_CN images in favour of UbuntuKylin (cdimage r1274), did you intentionally disable them for precise too?  That seems odd since UbuntuKylin postdates precise.
[09:53] <slangasek> cjwatson: I don't recall this being intentional
[09:55] <cjwatson> slangasek: OK, putting them back then, thanks
=== jdstrand_ is now known as jdstrand
=== sil2100_ is now known as sil2100
[12:28] <infinity> Hrm, uploading glibc only triggered 19 tests.  I wonder if our rdep handling is incorrect, or if our test coverage of C/C++ projects is really that abysmal.
[13:04] <ScottK> If a package in Debian moves from main to non-free and is autosync'ed, does that move get tracked and it goes to multiverse?
[13:05] <ScottK> ibm-3270 is the package that has me thinking the answer is "no".
[13:09] <cjwatson> ScottK: Sadly not.
[13:14] <ScottK> OK.  In this particular case, I think it's OK as Debian was being overly pedantic.
[13:23] <xnox> infinity: sorry for being so out of date =)
[13:24] <cjwatson> jibel: I *think* I have fixed this.  Not completely sure as it's a pain to test.  Tomorrow's attempt should tell us
[13:32] <jibel> cjwatson, thanks, I'll tell you if it is still occurring tomorrow.
[13:33] <infinity> xnox: S'ok, it reminded me to poke the current binutils transition with some additional uploads. :)
[13:33] <infinity> (It should be good to go now, once those two build)
[13:35] <infinity> This whole (near)instant upload queue business is making me feel all velocitized.
[13:35] <infinity> Funny how we can write gobs of code for fancy features, but the ones that impact us the most seem to be really simple.
[13:40]  * infinity is going to find some lunch and, when he gets back, wrangle the linux/d-i/seeds/germinate mess into submission so he never has to edit for ABI bumps EVAR AGAIN.
=== barry` is now known as barry_
=== barry_ is now known as barry
=== doko_ is now known as doko
[16:05] <Ursinha> slangasek, cjwatson, release team call?
[17:39] <cjwatson> infinity: https://code.launchpad.net/~cjwatson/launchpad-buildd/fix-abort/+merge/177003 should be worth another look; I tweaked upgrade-config.
[17:41] <infinity> cjwatson: Hah.  Way to complicate the code to serve your anal-retension. ;)
[17:41] <cjwatson> I contemplated writing a general parser
[17:42] <cjwatson> Briefly
[17:42] <infinity> Well, it's a standard ini syntax, there are a bazillion parsers out there.  But adding a dep just for the postinst is silly.
[17:42] <cjwatson> Parser/order-preserving-reserialiser, I mean
[17:42] <infinity> The postinst is generally silly to start with.
[17:43] <cjwatson> It's probably possible with just the Python stdlib, I just couldn't be bothered :)
[17:48] <infinity> Reading it didn't do much for my sanity, but it seems to work as advertised.
[17:50] <infinity> Ahh, and thank you for r61
[18:01] <infinity> cjwatson: And thanks for the subtle hint in there that buildd-slave-example.conf is wildly out of date.  I brought it up to date in trunk now.
[18:01] <infinity> cjwatson: Maybe that should just be autogenerated by a Makefile from template.conf
[18:30] <infinity> cjwatson: And, of course, I went and committed things before I took your MP, cause I'm SMRT.
[18:31] <infinity> cjwatson: Want to rebase to trunk, and then I'll pull your MP in?  It looks as good as I can tell from reviewing without running (and I saw it running).
=== NCommand` is now known as NCommander
=== NCommander is now known as Guest48731
[20:01] <stokachu> im in the process of getting package sosreport included into main, however, when i attempt to add it to a seed file (cloud-image) it gives me a readonly transport error during the commit. is this a permissions thing for my account?
[20:01] <stokachu> bzr: ERROR: Cannot lock LockDir(chroot-94282704:///~ubuntu-core-dev/ubuntu-seeds/ubuntu.saucy/.bzr/branch/lock): Transport operation not possible: readonly transport
[20:17] <jbicha> stokachu: you need to be a member of that team to push to the team's branches
[20:18] <stokachu> jbicha: i was trying to push it under my account is that not possible this way?
[20:18] <stokachu> and then open an MP to have it reviewed
[20:18] <jbicha> what command were you using to push?
[20:19] <stokachu> i tried variations but the one i thought was right is: bzr push lp:~adam-stokes/ubuntu-core-dev/ubuntu-seeds/ubuntu.saucy
[20:19] <stokachu> similar to how i alter packages
[20:20] <stokachu> im trying to do #5 on this list : https://wiki.ubuntu.com/MainInclusionProcess
[20:23] <jbicha> stokachu: I think you need to leave out the "ubuntu-core-dev" part
[20:24] <stokachu> jbicha: ok that allowed me to push to my account
[20:24] <stgraber> stokachu: bzr push lp:~adam-stokes/ubuntu-seeds/ubuntu.saucy should work (~<username>/<project>/<branch name>)
[20:24] <stokachu> now that its pushed how do i tell bzr commit i want to update the commit for that branch
[20:24] <stokachu> i tried bzr commit :parent
[20:25] <stgraber> ah yeah, just do a push with --remember
[20:26] <stokachu> ok lemme try that
[20:26] <stgraber> then after that, any "bzr push" should just use the right location automatically
[20:27] <stokachu> so that allows me to push automatically but the bzr commit still fails for some reason
[20:27] <stgraber> ah, is that a bound branch?
[20:27] <stokachu> yea i did a bzr checkout
[20:28] <stokachu> i got that from the changing the seeds document
[20:28] <stokachu> https://wiki.ubuntu.com/SeedManagement#Changing_the_Seeds
[20:28] <stokachu> should i do a bzr branch instead?
[20:31] <stgraber> you can just bzr bind :push
[20:31] <stgraber> that should change the source/target of the bind
[20:31] <stgraber> or just bzr unbind if you want to turn the branch into a standard unbound branch
[20:32] <stokachu> stgraber: sweet! that works
[22:49] <cjwatson> infinity: Thanks.  I should probably leave it until the preliminary master side (buildstatus-aborted) is reviewed, though, because landing this without that preparatory work would be bad.
[22:52] <infinity> cjwatson: Well, landing it is fine, as long as we don't request a rollout to -cat prematurely. :P
[22:53] <infinity> cjwatson: That's entirely up to us, IS doesn't pull without a request.
[22:53] <infinity> cjwatson: And I'd rather have it landed than sitting in a topic branch forever.  But up to you.
[23:13] <barry> oops. i made a typo in a changelog i didn't catch until i uploaded.
[23:14] <infinity> barry: I guess you get to fix it retroactively in the next upload.
[23:14] <infinity> barry: Unless it was an SRU, then I can reject it.
[23:14] <cjwatson> infinity: Hopefully won't be long.  I just wanted to avoid confusing anyone with a -buildd branch that doesn't work with LP devel.
[23:14] <cjwatson> (Not least myself.)
[23:14] <barry> infinity: i caught it before i uploaded the sru one!  it may be a while before i upload a new version in saucy ;)
[23:15] <barry> (it's one character s/2/3/ ;)
[23:15] <barry> i guess i could just do a +1 upload to overwrite it
[23:15] <infinity> Why bother?
[23:16] <barry> only that it would be misleading/confusing for someone reading the changelog (the entry implies it fixes things in a python2 env, really it fixes things in a python3 env)
[23:17] <infinity> barry: Not world-ending.  Which package was this?
[23:17] <barry> infinity: command-not-found
[23:17] <infinity> Yeah.  Meh.
[23:17] <barry> infinity: it's easy enough to ignore ;)
[23:18] <infinity> I'm already ignoring it.
[23:18] <infinity> Watch me ignore.
[23:18] <infinity> LA LA LA.
[23:18] <barry> ignoring what?
[23:18] <infinity> Who said that?
[23:18] <barry> is this mic on?
[23:18] <infinity> (Thanks folks, we're here all week.  Try the fish.)
[23:19] <barry> tip your waiters, waitresses, and mindless ubuntu developers
[23:20] <barry> well, at least i got it right in the sur
[23:20] <barry> *sru