[01:29] <sarnold> smoser: lintian throws some warnings and errors on simplestreams, e.g. http://paste.ubuntu.com/6126373/
[01:31] <smoser> sarnold, do do you have any idea what would do that ?
[01:32] <smoser> i udnestand the man pages.
[01:32] <smoser> but dont understand how 'python3:any' got in there.
[01:33] <sarnold> smoser: not a clue on bad-provided-package-name python3:any -- is that ":any" supposed to be there?
[01:33] <smoser> $ grep any debian/control || echo no
[01:33] <smoser> no
[01:33] <smoser> ?
[01:33] <smoser> i'm sure its something 'ive done stupid. but i dont have a clue.
[01:33] <sarnold> haha
[01:33] <smoser> (which is probably why i'm 'so sure it was something that i've done stupid)
[01:35] <sarnold> man, I just hoped you'd know right off the top of your head a typo somewhere, but .. that's really confusing.
[01:50] <jbicha> python3:any is new but it's ok http://lists.debian.org/debian-python/2013/09/msg00044.html
[01:50] <jbicha> I guess you need to report a lintian bug then
[02:19] <xnox> dobey: rbasak if the python3 converted code leaked into the python2 package that indeed is bad (or vice versa)
[02:20] <xnox> dobey: rbasak: i'll double check it. But if you say it broke u1, surely it should have been stuck in -proposed because of u1's auto-package-tests, right?!
[06:19] <Noskcaj> Can someone hit "rebuild" for language-pack-as and mesa? one failed in chroot the other failed to upload
[06:24] <infinity> Noskcaj: Done.
[06:24] <Noskcaj> thanks
[06:56] <dholbach> good morning
[08:22] <smartboyhw> dholbach, many, many, thanks!!!!!!!!!!!!!
[08:33] <rbasak> nnnnnnnnnn/sb end
[08:33] <Noskcaj> smartboyhw, That was a bit over-the-top, can you explain
[08:34] <smartboyhw> Noskcaj, for sponsoring ubuntustudio-look :)
[08:34] <smartboyhw> Noskcaj, and I'm not saying it to you:P
[08:34] <Noskcaj> smartboyhw, I'm allow to be interested. It looks like studio will have a good release for 13.10
[08:56] <Noskcaj> Does anyone have a good pbuilderrc file for pbuilder-dist i can copy? it needs at least debian sid and ubuntu saucy support
[10:11] <cjwatson> Grr, I'd hoped I'd never have to use a hardy chroot again
[12:14] <bluesabre> dholbach: thanks for sponsoring several of xubuntu's pending packages
[12:15] <bluesabre> would it be possible for you to take a look at https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1227402 as well?
[12:15] <bluesabre> it updates each of our themes to their latest version which fixes some minor buglets and addresses some transitionary items
[12:16] <dholbach> bluesabre, I had a very brief look at it but couldn't quite figure out what to do with the debdiff or the branch
[12:16] <bluesabre> ochosi, our artwork lead, would have additional details to the changes involved
[12:16] <bluesabre> ah
[12:16] <dholbach> in either case I couldn't produce a source package out of it
[12:16] <bluesabre> I see
[12:17] <dholbach> let me add a comment to the bug so whoever takes care of it can leave some pointers for either myself or another sponsor
[12:17] <bluesabre> thanks a lot
[12:17] <bluesabre> normally we'd have one of our devs with upload rights take care of it, but both are currently away and are likely to miss the UIF
[12:19] <ochosi> dholbach: thanks for your uploads so far, it's really great for us because (what bluesabre just said)
[12:21] <dholbach> ochosi, bluesabre: https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1227402
[12:22] <bluesabre> thanks dholbach
[12:22] <dholbach> I know I could just sign the source package which is in the branch (why?), but I wanted to understand a bit better what I'm uploading there :-)
[12:24] <bluesabre> fair enough.  We have one developer who has been the sole maintainer of that package.  We basically drop the latest git-tags of each theme into there and run debuild -S to produce the latest
[12:24] <dholbach> ah no, hang on
[12:24] <bluesabre> as to what he usually does then, its beyond me, but since he has direct upload, its probably known only to him
[12:28] <dholbach> bluesabre, ochosi: I still don't know how it's put together, but I could rebuild the source package and can upload it - I just took the liberty of adding (LP: #1227402) to the changelog entry so the bug gets closed automatically
[12:28] <dholbach> bluesabre, ochosi: maybe you can suggest adding a debian/README which describes how it's put together
[12:29] <ochosi> dholbach: thanks a *lot* ! i can tell you this was a lot of work to put together (i mean the artwork stuff, but maybe also the complicated packaging, who knows ;)) and I'm happy to see it land before UIF
[12:29] <bluesabre> dholbach: yes, we've already requested the usual developer to do so when he's around next
[12:30] <dholbach> bluesabre, ochosi: uploaded
[12:31] <ochosi>  \o/
[12:31] <dholbach> rock on!
[12:31] <bluesabre> dude, you rock!
[12:31] <ochosi> +1
[12:31] <dholbach> keep up the good work!
[12:32] <ochosi> dholbach: a big thank-you from the xubuntu dev-community!
[12:32] <davmor2> bluesabre: no dholbach doesn't rock, more trance/techno/dance/dubstep
[12:33] <bluesabre> haha
[12:33] <dholbach> I think what's happening here is that davmor2 is trying to sneak his own music wishlist in :-P
[12:33] <bluesabre> probably makes the loco meetings more fun
[12:34] <doko> glatzor online?
[12:35] <pitti> Good morning
[12:35] <davmor2> dholbach: No, just going for accuracy, I've heard you DJ it definitely isn't rock, it does however fall nicely into the other categories :D
[12:36] <dholbach> I'm not quite sure about the categories, but yeah, Rock doesn't happen that often ;-)
[12:39] <doko> pitti, apport-noui wants to demote. expected?
[12:39] <pitti> doko: yes, we don't need that on the phone any more
[12:39] <pitti> doko: and server guys certainly want to continue with -cli
[12:40] <pitti> it was a bit of an evolutionary dead end; I should discuss with ev whether we'll still need it at all
[12:40] <doko> ok, demoted
[12:48] <doko> jamespage, your libunwind merge ftbfs on every architecture
[12:49] <jamespage> doko, yeah - I know
[12:49] <doko> good =)
[12:49] <jamespage> doko, something odd about linking for the mini-debug-info stuff
[12:49] <doko> urgh
[12:50] <doko> anything more specific?
[12:50] <jamespage> doko, I need to refresh my memory
[12:50] <jamespage> that happened > 2 weeks ago
[12:51] <jamespage> doko, the lzma linking was failing for one of the test binaries
[12:52] <jamespage> I think I see that someone fixed upstream - I'll take another look
[13:07] <doko> xnox, can I assign this one to you? bug #1227639
[13:14] <jamespage> doko, this is the build failure I see on i386
[13:14] <jamespage> http://paste.ubuntu.com/6128253/
[13:14] <jamespage> amd64 works OK
[13:14] <doko> jamespage, looks like libunwind-coredump.so isn't linked with lzma
[13:18] <doko> fails on the buildd on amd64 too
[13:19] <jamespage> doko, oh - does it?
[13:19] <dobey> xnox: paste doesn't work under python 3 either. the patches to make it "work" with 3 as well as 2 are broken. u1db dosen't have an autopkgtest yet, because i wasn't able to make it work right when i was trying to get it working, so i had to leave it out. i've recently discovered another way to do the tests for it though that might work, so i can try to get that in, but the package will of course be held in -proposed because pa
[13:19] <jamespage> doko, ignore the failure for the one currently in proposed
[13:19] <jamespage> the test failure is me not reading my own README.source
[13:19] <doko> ahh, good =)
[13:27] <speakman> Hi folks. I'm trying to build a package using pbuilder-dist, but it insists on running tests and since it's an x11 program it won't pass. How can I disable testing during pbuilder-dist build?
[13:40] <JackYu> dholbash, hi
[13:42] <rbasak> speakman: I don't know about pbuilder specifically, but in general you need to set or get it to set DEB_BUILD_OPTIONS=nocheck when running debian/rules. With sbuild you can just set the environment variable and it passes through.
[13:43] <rbasak> (this assumes the packaging supports this standard)
[13:45] <Laney> is there a trick to make debmirror download Contents?
[13:46] <cjwatson> --getcontents
[13:46] <Laney> I got that
[13:46] <cjwatson> Not sure then
[13:46] <speakman> rsajdok: thanks, but I can't find a way to pass the DEB_BUILD_OPTIONS envvar to the "pbuilder" environment. I'll just try to set it in the running environment and hope for it to come along.
[13:47] <speakman> Looks like it worked! :)
[13:54] <smoser> hey. i was looknig at germinate output, basically auditing build process of cloud images.
[13:54] <smoser> https://bugs.launchpad.net/ubuntu/+bug/1224504
[13:54] <smoser> the build process installs 'ubuntu-minimal' explicitly.
[13:54] <pitti> jibel: do you know why the new python3.3 wasn't held back by the failing apport test?
[13:55] <smoser> is there any reason why we would do that? and if so, is there a reason I should'nt just add it to a seed ?  And if so, why would it not be part of all seeds ?
[13:55] <pitti> jibel: someting changed in MIMEText which breaks the handling of encoding (I'm not yet sure whether apport did things wrong all the years or it's a bug in py3.3), but I thought such things were supposed to be kept in -proposed
[13:55] <speakman> Where do I fetch the final .deb when pbuilder is done? It looks disappeard currently.
[13:56] <jamespage> doko, OK - fix uploaded for libunwind
[13:56] <cjwatson> smoser: Most of the packages you list there are installed conditionally and mustn't be seeded
[13:57] <cjwatson> smoser: and if you try to add ubuntu-minimal to any other seed you will blow things up
[13:57] <cjwatson> smoser: is any of this actually important? :-)
[13:57] <cjwatson> smoser: You absolutely must not seed grub-pc.
[13:58] <cjwatson> smoser: (because that's hardware-dependent)
[13:58] <ogra> it might put some pressure up to get the armhf port ready :)
[13:59] <cjwatson> ogra: I mean even within a single architecture.
[13:59] <ogra> yeah
[13:59] <smoser> cjwatson, i wont seed grub-pc. but couldn't i ?
[13:59] <jibel> cjwatson, has python3-defaults been forced to -release ? The test result is "apport 2.12.2-0ubuntu1 FAIL apport 2.12.2-0ubuntu1 python3-defaults 3.3.2-14ubuntu1" but it wasn't held back
[13:59] <cjwatson> smoser: efi, sure
[13:59] <cjwatson> ly
[13:59] <bjsnider> dobey, i reported a bug to debian yesterday on that apt issue and they argued themselves out of it being apt-s fault and closed it
[13:59] <cjwatson> smoser: It's generally a fundamental mistake to assume that the BIOS variant is the only one
[13:59] <smoser> none of it is really important, no. but i was just trying to understand why we would install 'ubuntu-minimal' and 'ubuntu-cloudimg^'
[14:00] <cjwatson> jibel: No, I sorted out some associated bugs but I didn't force it
[14:00] <cjwatson> smoser: It's usually a good idea to have the metapackages installed to aid upgrades
[14:00] <cjwatson> smoser: You've kind of misunderstood seed structure inheritance though
[14:01] <cjwatson> smoser: The cloud-image seed inherits from standard, yes, which means that germinate computes its expansion starting from the assumption that everything in standard and below is already installed
[14:01] <pitti> jibel, cjwatson: oh, I guess it's because apport depends on python3, not on python3.3 directly
[14:01] <cjwatson> smoser: But that doesn't translate into package dependencies
[14:01] <pitti> jibel, cjwatson: so it's again a transitive dependency, which we don't yet do unfortunately
[14:01] <speakman> How do I get the resulting .deb package after pbuilder is finished?
[14:02] <speakman> I can't even find the resulting name anywhere on my disk.
[14:02] <pitti> (especially because changes in python-defaults are much less prone to break other python stuff than changes in the actual python interpreters)
[14:02] <cjwatson> smoser: We deliberately omit those dependencies because if we include them then somebody who wants to vary a single choice we've made in, say, ubuntu-minimal, then has to remove ubuntu-standard and ubuntu-desktop as well
[14:02] <cjwatson> (or whatever)
[14:02] <cjwatson> smoser: So you need to track the seed inheritance structure when installing the metapackages/tasks in images
[14:03] <cjwatson> smoser: IOW you can't assume that installing a task higher in the structure will automatically pull in ubuntu-minimal - it won't
[14:03] <pitti> jibel: ok, nevermind then; I guess we just need to switch to transitive checks at some point
[14:03] <cjwatson> smoser: does that help?
[14:03] <smoser> maybe. but now i'm more confused.
[14:03] <smoser> so the change i made to structure
[14:03] <speakman> ping cjwatson and rbasak, any ideas how to reach the created .deb package from pbuilder?
[14:04] <cjwatson> speakman: I don't use pbuilder
[14:04] <smoser> that does not indicate that cloud image is a strict superset of server ?
[14:04] <speakman> cjwatson: ok :/
[14:05] <cjwatson> smoser: Sure, but it doesn't translate into dependencies from any metapackage you generate from cloud-image
[14:05] <cjwatson> smoser: Nor does it mean that, e.g., the server task implicitly includes standard
[14:05] <cjwatson> it doesn't
[14:06] <cjwatson> smoser: now, ubuntu-minimal is probably unnecessary for a different reason: it's included by debootstrap
[14:06] <cjwatson> speakman: IIRC it's in something like /var/cache/pbuilder/result/ though
[14:06] <cjwatson> speakman: sbuild is more helpful: puts results in the current directory
[14:07] <smoser> i dont understand. what you mean by "the server task implicitly includes standard".
[14:07] <doko> jibel, is there something wrong?
[14:07] <smoser> my understanding was that it *explicitly* in STRUCTURE includes standard.
[14:07] <JackYu> robert_ancell, hi
[14:07] <cjwatson> smoser: That only affects how germinate expands the dependencies
[14:07] <cjwatson> smoser: It intentionally doesn't translate into the Task fields in the archive
[14:08] <robert_ancell> JackYu, hello
[14:08] <cjwatson> smoser: If nothing else, I have no interest in bloating the Packages file with a gazillion Task fields for everything in minimal ...
[14:09] <JackYu> robert_ancell, would you help to upload the fcitx-qimpanel at bug #1226492?
[14:09] <smoser> cjwatson, so we *should* be explicitly installing server^ in the build process ?
[14:09] <smoser> if in fact we want to say "its server + stuff"
[14:09] <cjwatson> smoser: Yes
[14:09] <robert_ancell> JackYu, that has nothing to do with me
[14:10] <cjwatson> smoser: compare live-build/auto/config in livecd-rootfs
[14:10] <JackYu> robert_ancell, oh, sorry. I saw you are the Pilot today:)
[14:10] <cjwatson>         xubuntu)
[14:10] <cjwatson>                 add_task install minimal standard xubuntu-desktop
[14:11] <robert_ancell> JackYu, sorry, not available at the moment
[14:11] <smoser> that seems repetitive. but OK.
[14:11] <cjwatson> smoser: a bit, yes.  IIRC I tried the alternatives and they were worse.
[14:12] <cjwatson> (for other reasons)
[14:12] <smoser> ok then. do you have feelings on if i should put STRUCTURE back ?
[14:13] <cjwatson> smoser: That depends on whether you want cloud-image to be dependency-expanded with respect to server
[14:13] <cjwatson> I don't think my feelings come into it :)
[14:13] <JackYu> robert_ancell, That's all right. Would you introduce someone available?
[14:13] <cjwatson> smoser: That said, cloud-image looks substantively duplicated from server
[14:13] <cjwatson> smoser: So it does look as though that STRUCTURE change might be a mistake
[14:13] <cjwatson> smoser: Either that, or there's a load of stuff in cloud-image that should now be deleted because it's already in server
[14:14] <cjwatson> smoser: Either way, you should indeed make the image build process line up with the seed structure
[14:14] <speakman> cjwatson: sbuild..?
[14:14] <cjwatson> smoser: And consider the future question of whether you might ever want something in the default server install but *not* in cloud images
[14:14] <cjwatson> speakman: apt-cache show
[14:14] <robert_ancell> JackYu, according to the bug you need an archive administrator which is someone from https://launchpad.net/~ubuntu-archive/+members#active
[14:15] <smoser> alright. i'm gong to revert that change for now.
[14:15] <robert_ancell> JackYu, like cjwatson :)
[14:15] <cjwatson> speakman: and https://wiki.ubuntu.com/SimpleSbuild
[14:15] <cjwatson> robert_ancell: he still needs a sponsor to upload it ...
[14:15] <JackYu> robert_ancell, thank:)
[14:15] <cjwatson> not like me
[14:16] <cjwatson> I have a million things to do today
[14:16] <speakman> cjwatson: thanks
[14:16] <JackYu> cjwatson, robert_ancell, yes, I'm looking for a sponsor...
[14:16] <robert_ancell> Laney, why does bug 1226492 need an archive admin?
[14:17] <speakman> cjwatson: A quick one; can I build i386 binaries on an x86_64 platform with sbuild? That's why I'm using pbuilder atm.
[14:17] <JackYu> I know cjwatson is very busy:)
[14:17] <cjwatson> speakman: Yes, I do it all the time, you just need an i386 chroot
[14:17] <cjwatson> xnox: Would you have time to run an update of app-install-data-ubuntu in preparation for final beta?  I notice you did some in raring
[14:17] <xnox> cjwatson: correct. Yeap, I can do that now.
[14:18] <speakman> cjwatson: thanks! :)
[14:20] <pitti> doko: seems last py3.3 is missing a Replaces: ? http://paste.ubuntu.com/6128496/
[14:20] <cjwatson> speakman: (and rest per that wiki page)
[14:21] <pitti> doko: want a bug report for that?
[14:21] <doko> pitti, hmm, it should have one ...
[14:22] <pitti> doko: not for libpython3.3-stdlib, only for pyton3.3 and python3.3-minimal
[14:23] <doko> pitti, ok :-/ are the autopkg tests succeeding?
[14:23] <pitti> doko: for py3.3? yes, they got fixed; thanks!
[14:24] <pitti> we don't test upgrades in britney, though, so above upgrade bug wasn't detected
[14:27] <JackYu> pitti, hi, would please help to review the FFE  request at bug #1226492?
[14:27] <pitti> JackYu: I'm not in the release team
[14:28] <JackYu> pitti: you  are an archive administrator?
[14:28] <pitti> JackYu: yes
[14:29] <JackYu> pitti: Laney said this FFE needs an archive administrator agree:)
[14:29] <pitti> for NEW review, I guess; can do next week, I'm at a conference this week
[14:29] <doko> pitti, uploaded
[14:30] <pitti> doko: danke sehr
[14:30] <JackYu> pitti, this package would be installed in UbuntuKylin. we need upload this package first before upgrade our default-settings package:).
[14:37] <speakman> sbuild doesn't like --jobs=13. At least it doesn't pass it to dpkg-buildpackage
[14:38] <cjwatson> speakman: Are you sure?  Remember that packages have to take explicit care to honour that.
[14:38] <speakman> cjwatson: I did work using pbuild and it's the same package.
[14:38] <cjwatson>                        "j|jobs=i" => sub {
[14:38] <cjwatson>                            push(@{$self->get_conf('DPKG_BUILDPACKAGE_USER_OPTIONS')},
[14:38] <cjwatson>                                 '-j'.$_[1])
[14:38] <cjwatson>                        },
[14:38] <cjwatson> seems fairly straightforward, in sbuild
[14:40] <cjwatson> speakman: What pbuilder invocation were you using to do this?
[14:40] <cjwatson> Because AFAICS parallel-build support isn't built into pbuilder ...
[14:41] <speakman> cjwatson: --debbuildopts
[14:42] <cjwatson> Perhaps use "ps aux" while sbuild is running to see what the dpkg-buildpackage command line actually is
[14:43] <speakman> /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc -mDaniel Nyström <daniel@nystrom.st> -b -rfakeroot -j13
[14:44] <speakman> HM...
[14:44] <Riddell> ogra: do you know if the ubuntu desktop "Texas Instruments OMAP4 (Hard-Float) desktop image" images are working currently? I can't get today's daily to do anything
[14:44] <ogra> Riddell, i have no clue
[14:45]  * ogra hasnt touched a panda in ages
[14:45] <speakman> cjwatson: http://pastebin.com/Cxpm42Ea
[14:45] <speakman> cjwatson: that's my sbuildrc
[14:45] <ogra> and i dont knw who is up to test them or something
[14:45] <Riddell> ogra: do you know if anyone is looking out for it as part of beta 2?
[14:45] <cjwatson> speakman: sbuild is fine based on that command
[14:45] <ogra> nope
[14:45] <Riddell> ogra: what hardware are the cool kids running these days?
[14:45] <ogra> Riddell, either desktop or QA i would imagine
[14:45] <speakman> cjwatson: I also have to make sure it doesn't run any tests (nocheck in DEB_BUILD_OPTIONS), how do I pass that to sbuild? Just setting the env var?
[14:45] <cjwatson> since it's manifestly passing it through
[14:46] <cjwatson> speakman: yep
[14:46] <ogra> Riddell, ubuntu touch on nexus devices :)
[14:47] <cjwatson> speakman: sbuild sanitises the environment but DEB_BUILD_OPTIONS is one of the ones it lets through
[14:47] <speakman> cjwatson: Great!
[14:53] <Maple__> fasf
[14:53] <Maple__> you know
[14:53] <Maple__> this needs +t
[14:55] <cjwatson> Maple__: it's deliberate since in practice it's not much of a problem
[14:56] <Maple__> ...if you say so.
[14:56] <cjwatson> Maple__: And you don't seem to have actually changed anything from my point of view, just set it to the previous value
[14:56] <cjwatson> I do say so
[14:56] <cjwatson> If it becomes a practical problem we'll revisit
[14:56] <cjwatson> (If kicking offenders isn't sufficient)
[14:58] <speakman> cjwatson: and finally - after one day of trying to "cross" compile for i386 I did get one .i386.deb five minutes before "deadline". :D
[14:58] <speakman> cjwatson: thanks a lot for helping!
[14:59] <cjwatson> you're welcome
[14:59] <cjwatson> I still do almost all my Debian uploads as i386 despite my host system being amd64, so it's a familiar process
[15:07]  * xnox started to do _multi and merge amd64&i386 uploads for some of my builds.
[15:24] <pitti> xnox: is "_multi" something sbuild-ish, or just means "you build for multiple architectures and merge the .changes?
[15:26] <cjwatson> pitti: Not sbuildish, just convention - dak doesn't actually care what the bit between _ and .changes is
[15:26] <xnox> pitti: build for multiple architectures, then use mergechanges -f foo*.changes.
[15:27] <cjwatson> pitti: mergechanges(1) produces _multi though
[15:27] <pitti> cjwatson: oh, as in "part of the .changes filename", thanks
[15:27] <xnox> pitti: mergechanges, defaults to _multi.changes suffix to not clobber up the rest (source, $arch) . changes.
[15:27] <pitti> nice, I didn't know about mergechanges
[15:28] <xnox> pitti: on #ubuntu-release  & in-person there were requests about langpacks refresh. Not sure if it's time to do them again yet, or not.
[15:28] <pitti> xnox: we missed doing fresh -base ones for beta
[15:28] <xnox> cause e.g. archive rebuild is in progress.
[15:28] <xnox> pitti: =( ok.
[15:29] <pitti> xnox: I guess the next sensible -bsae refresh one would be before final beta, and/or final
[15:29] <pitti> xnox: but that's mostly about reducing image size
[15:29] <xnox> ack.
[15:29] <pitti> xnox: updates from LP are auto-uploaded twice a week
[16:45] <dobey> xnox: still around?
[16:47] <pitti> doko: "Jenkins Fixed - saucy-adt-python2.7" \o/ thanks!
[17:13] <dholbach> doko, barry: who could take a look at https://code.launchpad.net/~mitya57/ubuntu/saucy/python-defaults/2.7.5-5ubuntu1/+merge/185620?
[17:14]  * dobey wonders what to do about paste
[17:15] <xnox> dobey: yeah, here.
[17:15] <xnox> dobey: i think i fixed lint.py in debian now, what packages / where was paste failing for you?
[17:15] <xnox> dobey: so waiting on lp mirror to pick it up to merge it.
[17:15] <dobey> xnox: fixed it how?
[17:15] <xnox> it did unbreak convoy at least.
[17:15] <dobey> xnox: did you fix the package to run the unit tests at build time as well?
[17:16] <dholbach> happyaron, is https://bugs.launchpad.net/ubuntu/+source/libchewing/+bug/1220224 something we still want to get into saucy?
[17:16] <xnox> dobey: which one? paste's? that's failing from before i started to touch it, so no, i didn't enable it.
[17:16] <dobey> xnox: it breaks u1db
[17:16] <dobey> xnox: yes paste. there seem to be a lot more issues than simply the StringType issue
[17:17] <xnox> dobey: let me test it know, just debuild would do? or do I need to run it?
[17:17] <happyaron> dholbach: I think it's nice to have.
[17:17] <dobey> xnox: debuild should be enough, it runs the tests during the build
[17:17] <dholbach> happyaron, ok, it's still sitting in the sponsoring queue
[17:17] <happyaron> good
[17:17] <xnox> dobey: doing test-build against the updated paste now.
[17:18] <dobey> xnox: can you link to the fix you applied to paste?
[17:18] <xnox> dobey: build succesful.
[17:18] <xnox> dobey: well it's in the debian svn / upload. I can link to it once launchpad imports the debian upload.....
[17:19] <dobey> hmm
[17:21] <dobey> xnox: ok, please ping me when it gets merged into saucy
[17:21] <mterry> zul, can you subscribe the server team to blinker bugs?  (it needs to be in main for flask)
[17:21] <zul> blinker bugs?
[17:22] <zul> mterry:  doh...done :)
[17:23] <xnox> dobey: ack.
[17:23] <mterry> zul, thanks.  I already patched it to run tests.  Seems fine besides
[17:23] <mterry> zul, bug 1227623 if you're curious
[17:23] <zul> mterry:  coold thanks
[17:36] <barry> dholbach: i will look
[17:36] <dholbach> thanks
[18:00] <barry> @pilot in
[18:25] <pitti> so what magic needs to happen to make the PS auto-uploader actually upload ubuntu-themes in the next 2 hours or so to meet the UIF?
[18:28] <xnox> ev: fginther: ^
[18:31] <fginther> pitti, are the necessary changes in trunk?
[18:32] <xnox> fginther: yes.
[18:32] <fginther> robru, can help then ^^
[18:33] <robru> pitti, hi. i will kick off a release build of misc stack for you (this includes ubuntu-themes)
[18:34] <fginther> robru, thanks
[18:40] <robru> fginther, pitti: ok, it is done. you should see ubuntu-theme package upload soon.
[18:42] <robru> pitti, although, I disagree with your changes to the version number... like all daily_release packages, it's built in split mode, which means orig.tar.gz is created by deleting debian/ dir.
[18:46] <robru> pitti, so with daily_release'd stuff, you only have control over the part of the version number to the left of the '+' sign... the rest is automatically added by jenkins in order to identify when it was released.
[18:55] <pitti> robru: oh, I see; well, I can back that out
[18:56] <pitti> robru: but I was worried as there is no obvious way to build an orig for myself, nor any real "upstream"
[18:56] <pitti> robru: but can we at least drop the 13.04+13.10 stuff?
[18:56] <robru> pitti, I already fixed the changelog in trunk.
[18:56] <pitti> robru: ok, thanks
[18:56] <robru> pitti, the 13.10 bit has to stay, but if you want to change the '13.04' part to something else, go right ahead.
[18:57] <robru> pitti, and if you 'bzr bd' in the branch, it will make orig.tar.gz for you
[18:57] <pitti> robru: yes, basically just drop the 13.04+; that seems useless?
[18:57] <pitti> robru: but oh well, it's already uploaded now according to the changelog, so nevermind
[18:57] <robru> pitti, I agree, but there needs to be something there for jenkins to build off of. we should discuss with didrocks what makes a good version number.
[18:57] <pitti> robru: thanks for getting it into the archive!
[18:58] <pitti> robru: actually, no -- https://launchpad.net/ubuntu/+source/ubuntu-themes/13.04+13.10.20130919.2-0ubuntu1 doesn't seem to contain my changes?
[18:58] <robru> pitti, hmmm, let me check
[18:58] <pitti> ah no, that can't be that upload
[18:58] <pitti> robru: that said the upload was from 4 hours ago
[18:59] <pitti> so we need another one with xnox's and my changes
[18:59] <robru> pitti, hmm, that's strange. it looks like it missed your commits. I'll try it again
[18:59] <pitti> robru: no, xnox' and my commits presumably haven't even been there 4 hours ago
[19:00] <robru> pitti, i think that timestamp is wrong, because the version number matches what just got uploaded
[19:02] <robru> pitti, yeah, that's definitely the build I just kicked off, see here: http://10.97.0.1:8080/job/cu2d-misc-saucy-3.0publish/16/console most recent build in the system, and the version number matches. not sure why it says 4hrs ago, maybe one server has a bad clock somewhere/
[19:02] <robru> also not sure why it didn't get your commit, but will try again
[19:03] <pitti> robru: ah, so it hasn't actually been uploaded to saucy yet?
[19:03] <pitti> robru: as https://launchpad.net/ubuntu/+source/ubuntu-themes/13.04+13.10.20130919.2-0ubuntu1 definitively doesn't have the latest changes
[19:03] <robru> pitti, it made an upload but for some reason it didn't include your commit.
[19:03] <pitti> robru: or the tree from xnox
[19:03] <robru> pitti, this is an issue that has bit me a couple times recently, it's like the jenkins job is caching launchpad branches so it doesn't see new commits sometimes
[19:05] <robru> pitti, hmmm, jenkins claims to have released revision 315, which would include xnox's work. are you sure it's missing?
[19:05] <pitti> robru: the upload timestamp says "Thu, 19 Sep 2013 14:05:04 +0000" which roughly coincides with "4 hours ago", though
[19:05] <pitti> robru: perhaps that was an auotmatic one?
[19:06] <robru> pitti, no, automatic uploads are disabled, things are kind of a mess right now.
[19:06] <pitti> robru: ah yes, so 315 has xnox' merges, but mine was 316
[19:06] <pitti> latest one is 318
[19:06] <robru> yeah, ok I'll run it again and hope for the best
[19:06] <pitti> robru: thanks
[19:08] <robru> pitti, you're welcome
[19:10] <robru> pitti, hmmm, still doesn't seem to have found it. last time this happened to me it took ~12 hours before jenkins saw the latest commit
[19:12] <robru> pitti, you might want to file your UIFe now, if necessary.
[19:14] <infinity> smoser: Weren't you going to seed ubuntu-cloudimage-keyring somewhere to keep it in main?
[19:14] <infinity> smoser: (Or have something depend on it)
[19:16] <smoser> infinity, maas will depende on it.
[19:16] <smoser> can i recommends it?
[19:16] <infinity> smoser: Recommend would be fine.  Also, cloud-utils wants to move to universe too, is that meant to be?
[19:16] <alberts> Hi! Can patch pilot look at this fix for raring - https://code.launchpad.net/~albertsmuktupavels/ubuntu-themes/restore-space-between-applications-and-places-in-gnome-panel-raring
[19:17] <smoser> infinity, cloud-utils is in cloud-image seed.
[19:17] <infinity> smoser: Is not.
[19:17] <infinity> smoser: cloud-init and cloud-guest-utils are, but not cloud-utils.
[19:18] <smoser> cloud-guest-utils is binary from cloud-utils.
[19:18] <smoser> is that not enough?
[19:18] <smoser> cloud-utils is now metapackage.
[19:18] <infinity> smoser: Sure, it's a metapackage that depends on cloud-guest-utils and cloud-image-utils.  Is all of that supposed to be in main, or just cloud-guest-utils?
[19:19] <infinity> smoser: If it should all be in main, you should seed the metapackage somewhere.
[19:19] <infinity> smoser: Especially if this is required for smooth upgrades from precise.
[19:20] <infinity> smoser: So, you seed cloud-guest-utils to cloud-image, I'd suggest that you might want cloud-utils in supported.
[19:20] <smoser> cloud-guest-utils and cloud-image-utils should be in main.
[19:21] <smoser> yeah. i'll add it in supported.
[19:21] <infinity> Thanks.
[19:22] <smoser> and maas will have the dependency on cloudimage-keyring sometime soon
[19:23] <smoser> roaksoax, ^ can you add that ?
[19:23] <smoser> for your next upload
[19:23] <smoser> Depends: ubuntu-cloudimage-keyring
[19:32] <roaksoax> smoser: for maas?
[19:32] <smoser> yes
[19:33] <roaksoax> smoser: what is that for?
[19:33] <roaksoax> smoser: i mean, what tool?
[19:33] <roaksoax> region/cluster?
[19:36] <smoser> whatever downloads ephemeral images.
[19:56] <alberts> barry: do you have time?
[20:07] <barry> alberts: hi, what's up?
[20:08] <alberts> barry: hi! I see you are patch pilot. can you look at this - https://code.launchpad.net/~albertsmuktupavels/ubuntu-themes/restore-space-between-applications-and-places-in-gnome-panel-raring/+merge/178242
[20:08] <alberts> barry: and at this - https://code.launchpad.net/~albertsmuktupavels/indicator-applet/fix-for-1215337/+merge/185623
[20:11] <pitti> robru: ouch; is it using the http:// addresses by any chance? they usually lag behind a few minutes
[20:14] <barry> alberts: i'll take a look
[20:15] <pitti> robru: I modified bug 1079639 for an UIFe
[20:40] <robru> pitti, some empirical study has shown that the lag between when a commit lands in trunk, and when jenkins is able to push a release, is more than 4hrs, but less than 7hrs (assuming it's consistent; i haven't tested enough to be able to see if it's random or not)
[20:41] <robru> pitti, it looks like your commit is 2hrs old, so I expect I'll be able to get a release out within 5hrs
[20:48] <infinity> smoser: Did you want me to just do that supported seed change for you?
[20:48] <infinity> smoser: (I'm trying to get some noise out of component-mismatches while I clean it up)
[20:48] <barry> alberts: i must confess that i am not really qualified to review these branches :/
[20:48] <smoser> i did it.
[20:49] <smoser> didn't i?
[20:49] <smoser> gah.
[20:50] <smoser> now i did it.
[20:50] <alberts> barry: who can do it?
[20:50] <barry> alberts: someone from the desktop team would probably be better
[20:51] <alberts> barry: ok. thanks!
[20:51] <barry> alberts: not sure who's still online though ;) mterry perhaps?
[20:51] <mterry> barry, hi
[20:51] <mterry> barry, I'm on unity8 team these days  :)
[20:52] <mterry> of course I can still help
[20:52] <barry> mterry: ah.  i just looked at ~ubuntu-desktop ;)
[20:52] <mterry> barry, what am I helping with?
[20:52] <barry> mterry: alberts has some branches ^^ that need review.  i'll be happy to sponsor them if you can review and approve them
[20:52] <barry> mterry: https://code.launchpad.net/~albertsmuktupavels/ubuntu-themes/restore-space-between-applications-and-places-in-gnome-panel-raring/+merge/178242
[20:53] <barry> mterry: https://code.launchpad.net/~albertsmuktupavels/indicator-applet/fix-for-1215337/+merge/185623
[20:56] <infinity> smoser: Thanks.
[21:03] <mterry> barry, alberts: looking, commented on first one
[21:30] <Noskcaj> how do i run debuild through pbuilder-dist?
[21:31] <barry> @pilotout
[21:31] <udevbot> Error: "pilotout" is not a valid command.
[21:31] <barry> @pilot out
[21:46] <alberts> mterry: replied on first one
[22:06] <alberts> mterry: replied to second too
[22:07] <mterry> barry, first MR you linked to is approved
[22:07] <mterry> barry, second just needs some testing, but code seems fine
[22:11] <pitti> robru: wow, that seems like a weird delay, given our 4 hour landing cycle :)
[22:11] <pitti> robru: thanks
[22:15] <jtaylor> can one opt out of this phased updates thing? i.e. get everything immediately?
[22:16] <robru> pitti, yes, this delay only started in the last couple weeks. also, 4-hour landing cycle has been disabled for several weeks
[22:16] <robru> because everything is broken and horrible
[22:17] <cjwatson> jtaylor: http://www.murraytwins.com/blog/?p=127
[22:17] <jtaylor> thx
[22:17] <cjwatson> jtaylor: referenced from https://lists.ubuntu.com/archives/ubuntu-devel/2013-August/037563.html
[22:18] <jtaylor> do you know since when support for it is in update-manager?
[22:20] <cjwatson> I added it in January
[22:20] <cjwatson> I think it got SRUed back, not sure
[22:20] <cjwatson> of course you can use apt-get and that always ignores phasing
[22:20] <jtaylor> hm k, I'm asking because my update manager seems to behave differently since a few weeks
[22:21] <jtaylor> on 13.04, it pops up multiple times each time giving me a small chunk of updates
[22:21] <cjwatson> hopefully bdmurray can investigate, he's the king of phased updates :)
[22:21] <jtaylor> but I'm not sure if I may be imaging it, as I usually update via apt-get, so I'll first check if opting out changes anything
[22:24] <infinity> tjaalton: You need an MIR for glamor-egl, it looks like.
[22:25] <tjaalton> infinity: yes
[22:26] <infinity> tjaalton: Please file one? :)
[22:26] <tjaalton> on it :)
[22:26] <infinity> tjaalton: Is this all new code, or something split from mesa or some such?
[22:26] <tjaalton> infinity: it's a new library
[22:27] <bdmurray> jtaylor: could you elaborate on pops up multiple times each time?
[22:27] <jtaylor> it pops up offers me a couple updates, I apply, close update manager
[22:27] <jtaylor> it pops up right again with more
[22:28] <bdmurray> Your /var/log/apt/history.log file might be helpful.
[22:31] <jtaylor> bdmurray: I had this today: http://paste.ubuntu.com/6130220/
[22:31] <jtaylor> though it seems to be one regular and one security updates
[22:31] <jtaylor> is it intentional they are split in two?
[22:32] <bdmurray> apt and curl are undergoing phasing at the moment
[22:33] <bdmurray> so its possible the first time you weren't selected to install them and later you were
[22:34] <jtaylor> I had this two split several times in the last few weeks
[22:34] <bdmurray> oh, and I guess that would make more sense if they were further apart
[22:34] <jtaylor> really close to each other
[22:35] <robru> pitti, so a build from r318 has been dispatched, but it seems to be going very slowly. I see it in the PPA but it doesn't look like it's made it into distro yet.
[22:35] <bdmurray> okay, I'll have a look thanks
[22:35] <robru> pitti, https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=ubuntu-themes&field.status_filter=published&field.series_filter= keep and eye on that i guess
[22:35] <jtaylor> this time there were 10 minutes because it was waiting on an ack of listchanges
[22:35] <jtaylor> yesterday I had itpop up ~ minute after it was done with the first set
[22:35] <jtaylor> (on a different machine)
[22:36] <jtaylor> I'll check the logs tomorrow, but I think it might have also been security and regular updates
[22:36] <infinity> robru: "Very slowly?"  It took 13 minutes to build, so there's only another 11 minutes of delay there so far.
[22:37] <pitti> robru: très bien, merci
[22:37] <robru> infinity, well, usually the misc stack runs quite quickly i thought, just a few minutes? seems like it's been running for 30 minutes now, i'm not sure that that's normal
[22:37] <pitti> robru: I think it'll get held in -proposed due to the freeze that cjwatson announced, but I sent that UIFe about it
[22:37] <robru> yeah
[22:38] <infinity> robru: PPA publication times vary a bit.  But still, I wouldn't call this "very slow" was all I was driving at.  It was only uploaded 24m ago.
[22:38] <robru> infinity, I was referring to this: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/All/job/cu2d-misc-saucy/ which started 35 minutes ago, seems uncharacteristically slow to me
[22:44] <tjaalton> infinity: btw, if you still want to meet and talk about the backport stack implementation & future, me and mlankhorst are both at lpc
[22:44] <infinity> Hrm.  Shame Andy isn't.
[22:45] <infinity> But still might be nice to have a chat.
[22:45] <infinity> I'm pretty convinced that what we're doing isn't the best we can do, by a long stretch, but sorting out what would be better could take some beer and a large whiteboard.
[22:46] <tjaalton> the lobby bar has napkins ;)
[22:46] <infinity> Heh.
[22:58] <robru> pitti, ok. it looks like it is done and I'm just publishing it now.
[22:58] <robru> should be in -proposed shortly (before it was just in that PPA)
[22:59] <tjaalton> infinity: mir filed as bug 1227919
[23:00] <infinity> tjaalton: Thanks.
[23:00] <infinity> mterry: If you've got a tiny bit of time, could you have a look at the above?
[23:01] <mterry> infinity, is it time sensitive?  I can do now, but would slightly prefer to do tomorrow
[23:01] <infinity> mterry: Seems to be a new rdep of xorg-ati, but I'm sure it can wait a day, just not a month. ;)
[23:01] <mterry> infinity, done  :)
[23:01] <infinity> mterry: Might need a light security audit too.
[23:01] <infinity> mdeslaur: ^
[23:02] <mterry> infinity, ick, yeah, will assign to security now then, that can take a bit sometimes
[23:02] <mdeslaur> infinity: thanks
[23:02] <mdeslaur> sarnold: ^ one more for your list
[23:03]  * mterry hugs sarnold for his audits
[23:03]  * sarnold <3  :D
[23:28] <infinity> sarnold: Doesn't look like it'll be a long audit, but I figure a library that will be linked into an X driver and running ring 0 might need a look-see.
[23:28] <sarnold> infinity: oh, nice, drivers can go one of two directions.. :)