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