[11:19]  * cjwatson switches proposed-migration's no-break-architecture-all architecture over to amd64.  Hopefully a non-event ...
[11:20] <cjwatson> It'll cause amd64 to show up first in architecture lists, though
[11:22] <cjwatson> seems to have behaved roughly as expected
[11:23] <infinity> cjwatson: Not like anyone knows what the arch list means anyway, with 3 As. :P
[11:24] <cjwatson> It does have an "Arch order is:" line up top :)
[11:25] <infinity> cjwatson: We just need to rename i386, ppc, and ppc64el to something starting with R, G, and H.
[14:55] <xnox> can I do sftp uploads to ubuntu archive?
[14:55] <xnox> or is there a dput that has proxy support?
[14:55] <cjwatson> You can upload over SFTP
[14:55] <cjwatson> [ubuntu-sftp]
[14:55] <cjwatson> fqdn                    = upload.ubuntu.com
[14:55] <cjwatson> method                  = sftp
[14:55] <cjwatson> incoming                = ubuntu
[14:55] <xnox> cool thanks.
[14:56]  * xnox notes to upload dput with that extra stanza
[14:56] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/dput/+bug/632041
[14:56] <ubot2> Launchpad bug 632041 in dput (Ubuntu) "Provide commented-out method of using SFTP to upload to Ubuntu + PPAs" [Undecided,Confirmed]
[14:57] <cjwatson> different name is probably better than commented-out
[14:57] <cjwatson> oh, there's the awkward thing with the login stanza if you don't have local user == LP user or .ssh/config configuration
[14:58] <xnox> cjwatson: yeah, noticed. and .ssh/config username didn't get accepted either. meh, fixed it with ~/.dput.cf
[14:58] <xnox> anyway at least i can upload packages from work now.
[14:59] <xnox> cjwatson: would you like to review https://code.launchpad.net/~xnox/launchpadlib/proxy/+merge/241176 such that all ubuntu-dev-tools gain proxy support when talking to launchpad?
[15:00] <xnox> (including like add-apt-repository)
[15:01] <cjwatson> xnox: hm, right, possibly not right away but queued up
[15:02] <cjwatson> currently cleaning up after a proposed-migration mistake I made earlier today :-/
[15:02] <xnox> once that is reviewed, i'm thinking to cut the launchpadlib point release and upload it to experimental & vivid. It will have python3 support and proxy support.
[15:02] <xnox> cjwatson: hehe, those are fun =)
[15:03] <cjwatson> xnox: thanks for dealing with ubiquity vte
[15:03] <xnox> no problem.
[15:03] <xnox> it needed a vivid opening upload anyway.
[15:05] <Laney> oh cool, yes, thanks xnox :-)
[15:08] <infinity> cjwatson: proposed-migration mistake> would this relate to my seeing glibc copied to the release pocket twice?
[15:22] <cjwatson> infinity: I shouldn't have thought so
[15:23] <infinity> cjwatson: Okay, so that was just a random oddity, no big deal.
[15:24] <cjwatson> This was me trying to fix a bug with miscalculation of when it's OK for things to become arch: all, and accidentally ending up ignoring several out-of-date build excuses as a result
[15:24] <cjwatson> Nothing terribly important but I need to clean up
[15:25] <infinity> cjwatson: Oh, like blobby...
[15:27] <cjwatson> Right
[15:27] <cjwatson> Well, that was a secondary mistake, I removed the wrong architecture and had to re-copy :P
[15:32] <infinity> cjwatson: Still looks wrong to me...
[15:33] <cjwatson> How so?
[15:33] <infinity> cjwatson: Wrong version in the release pocket.
[15:33] <infinity> cjwatson: 1.0-1 should never have migrated.
[15:33] <cjwatson> infinity: I didn't try to undo that
[15:34] <infinity> Ick.
[15:34] <infinity> How many more arch regressions migrated?
[15:34] <cjwatson> It has no reverse-dependencies, and it's like a silly game or something, I reckoned it was OK to just drop the binary
[15:35] <cjwatson> Somewhere between 15 and 20 total.  I'm working my way through them
[15:35] <infinity> The blobby thing is probably an -O3 failure anyway, easily fixable.
[15:35] <cjwatson> current list I haven't checked: aces3 aspectc++ asymptote dsc-statistics eclipse eclipse-cdt gamera luminance-hdr nauty qgis
[15:35] <infinity> Maybe I'll look after I sleep.
[15:36] <cjwatson> But I'm really not going to put lots of effort into the cases where they're non-trivial and unimportant
[15:36] <infinity> Hrm, or not, fails with -O2 in Debian.
[15:37] <cjwatson> I think that vector bool thing is a deeper problem somewhere.
[15:37] <cjwatson> We ran into it in several Haskell packages
[15:37] <infinity> Though bool being in play could be a hint.  Maybe an endian or signedness oops.
[15:37] <cjwatson> No, I think it relates to altivec
[15:37] <cjwatson> Pretty sure I've failed to work it out before :)
[15:37] <cjwatson> In Haskell we passed -Ubool and suchlike in a few places to work around it
[15:38] <infinity> Oh, that's sounding sort of familiar.
[15:38] <infinity> Yeah, interest piqued enough for me to look later.
[15:38] <infinity> Just cause.
[15:40] <infinity> So, the big change between rc3 and final was *drum roll* -std=c++11
[15:40] <infinity> That's now sounding very familiar.
[15:41] <infinity> I vaguely recall a header defining bool-related things goofily on PPC depending on std.
[15:57] <cjwatson> infinity: How's your TeX?  The asymptote/powerpc failure is perplexing, and it built fine in Debian last time round.
[15:57] <cjwatson> 22 days ago, so I suppose it could be some underlying change ...
[15:58] <infinity> cjwatson: Haven't touched LaTeX (or any free variant) since high school.
[15:58] <infinity> cjwatson: So, about that good.
[15:58] <cjwatson> Yeah, mine dates from university.
[15:58] <cjwatson> And was a bit copy-paste even then.
[15:59] <cjwatson> It does have one reverse build-dep which has built in the past, unfortunately ("music").
[16:03]  * infinity goes to bed.
[17:17] <lool> stgraber, slangasek: Heads up: I've changed devel and ubuntu-touch/devel aliases to point to vivid instead of utopic: pub.change_channel_alias('devel', 'ubuntu-touch/vivid') and pub.change_channel_alias('ubuntu-touch/devel', 'ubuntu-touch/vivid') in si-shell
[17:18] <ogra_> lool, erm
[17:18] <ogra_> lool, you cant point devel to vivid until there is some image in the channel
[17:18] <ogra_> or did you promote an image
[17:20] <stgraber> lool: you just did something very very wrong :) don't ever change the /devel alias, it's not an actual alias but a redirect to ubuntu-touch/devel...
[17:22] <lool> ogra_: good point; can we copy the last utopic image there?
[17:22] <lool> stgraber: is there some doc about it? could we prevent this from the API?
[17:23] <ogra_> lool, did that get QA signoff ?
[17:23] <stgraber> lool: why would you copy the last utopic image into the vivid channel?
[17:23] <lool> ogra_: I dont see why it needs QA signoff; the images in utopic already did?
[17:23] <stgraber> lool: just keep devel pointing to utopic until we have something in vivid, THEN change the alias
[17:23] <lool> stgraber: to have one there
[17:24] <stgraber> there's no point forcing everyone to do a full update now and then again once we actually have a vivid image
[17:24]  * stgraber reverts the alias change
[17:24] <ogra_> lool, dunno, thats our general rule for promotion ... testing on all arches before signoff ... not sure we need to keep that for vivid though
[17:25] <stgraber> changes reverted
[17:25] <lool> well here's my issue: "devel" is used by people for development, but doens't reflect the right contents
[17:25] <ogra_> lool, then we need someone to check the promotion readiness or change the current rules
[17:25] <cjwatson> Messing about with the pointers without actually doing a vivid promotion doesn't do anything to change that, though
[17:25] <stgraber> well, the problem is that we don't have a vivid image, let's fix that, then change the alias :)
[17:25] <lool> cjwatson: it does not; I assumed we had images there
[17:26] <ogra_> i dont really mind either way
[17:26] <stgraber> right, it actually makes things worse because people will think they're running vivid when really, they're not
[17:26] <lool> stgraber: question stands on redirects
[17:26] <cjwatson> I think it would be a good idea to check carefully *before* making this kind of change, in future
[17:26] <cjwatson> I triple-checked before making the custom tarball changes a while back ...
[17:26] <stgraber> lool: yeah, I'm checking whether I did mention that stuff in the doc, but the wiki is freakishly slow
[17:28] <stgraber> lool: https://wiki.ubuntu.com/ImageBasedUpgrades/ServerOperation does explain the difference between aliases and redirects
[17:28] <stgraber> but yeah, the code fails to notice that what you're doing is wrong because the redirect target is an alias channel
[17:28] <lool> stgraber: it does, but I cant list redirects
[17:28] <stgraber> I'll add a test for that in the code
[17:31] <stgraber> >>> pub.change_channel_alias("devel", "ubuntu-touch/vivid")
[17:31] <stgraber> Traceback (most recent call last):
[17:31] <stgraber>   File "<console>", line 1, in <module>
[17:31] <stgraber>   File "/srv/system-image.ubuntu.com/bin/../lib/systemimage/tree.py", line 225, in change_channel_alias
[17:31] <stgraber>     raise KeyError("Channel is a redirect: %s" % channel_name)
[17:31] <stgraber> KeyError: 'Channel is a redirect: devel'
[17:31] <stgraber> lool: ^
[17:32] <lool> stgraber: I didn't get this though
[17:32] <stgraber> no, that's because I just added it now so you can't possibly do the same mistake again :)
[17:32] <lool> stgraber: so I take it you've just added that
[17:32] <lool> stgraber: me or anyone else, but thanks
[19:30] <brainwash> arges: please move thunar from utopic-proposed to -updates
[19:30] <brainwash> bug 1382977
[19:30] <ubot2> bug 1382977 in thunar (Ubuntu Utopic) "[SRU] Thunar open default not respecting mimetype" [Undecided,Fix committed] https://launchpad.net/bugs/1382977
[19:31] <arges> brainwash: ok looks good releasing
[19:37] <brainwash> arges: thank you :)