[00:01] <xnox> infinity: my fault, please reject.
[00:01] <infinity> xnox: Already did.
[00:01] <xnox> infinity: i had no idea it's debian native, rather than debian-native-in-ubuntu. =)
[00:07] <infinity> stgraber: Are you sure it's right this time? :)
[00:08] <stgraber> I'm not sure, but I think it is :)
[00:08] <stgraber> my laptop still boots
[00:08] <stgraber> and so does a clean VM
[00:09] <infinity> Also, why does "[ ! -d ] && mkdir" annoy me, when "[ -d ] || mkdir" wouldn't?
[00:10] <infinity> stgraber: Do upstart pre-scripts run set -e?  That's probably why that construct annoys me, cause it breaks in set -e.
[00:10] <stgraber> hmm, yeah, you're right... please reject that one, I'll re-upload in a sec
[00:12] <cjwatson_> That construct isn't *meant* to break in set -e according to the rules, but I have a vague recollection that there are cases where it does anyway.
=== cjwatson_ is now known as cjwatson
[00:13] <cjwatson> Or maybe it just used to and this is a zombie rule we both remember.
[00:14] <cjwatson> Non-zero exit on the LHS of && or || (among other things) isn't supposed to be trapped by set -e.
[00:15] <stgraber> indeed, just confirmed that locally
[00:15] <infinity> cjwatson: Oh, right.  Still feels wrong somehow.
[00:16] <cjwatson> My personal style is still to use [ -d ] || mkdir though :-)
[00:16] <infinity> cjwatson: I guess it's just my inner logic solver saying "but, wait, what happens if it's false?"
[00:17] <infinity> Which then expands to adding || true to the end, which then collapses to [ -d ] || mkdir, yes.
[00:19] <infinity> cjwatson: Any idea if that left-hand evaluation rule is POSIX, or if our shells all just (currently) behave the same way?
[00:19] <cjwatson> POSIX
[00:19] <infinity> Kay.  Oh well.  Old habits die hard, and I prefer logic that reads as consistent.
[00:21] <cjwatson> Chapter and verse in http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03 under -e.
[00:21] <cjwatson> " -e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last."
[00:21] <cjwatson> s/^"/"The/
[00:22] <cjwatson> bash's set -o pipefail might modify this.  I haven't tested.
[00:25] <infinity> Anyhow, stgraber uploaded with our preferred syntax, so another brain successfully washed.
[01:20] <slangasek> infinity: [ ! -d ] && mkdir > you're thinking of the makefile case, which cares about the retval of the shell
[01:27] <infinity> slangasek: Or, like I said, it just offends the part of me that hates open-ended logic.
=== seelaman` is now known as seelaman
[01:27] <infinity> slangasek: "if true, do this thing, if false... If false... WHAT HAPPENS IF FALSE?!"
[01:28] <slangasek> if false, then... false!
[01:42] <cjwatson> makefile case> ah yes, I think that's what I'm thinking of
[02:22] <barry> xnox, infinity i'll ask mvo to push it to debian and we'll ffe a sync
[03:43] <cyphermox> ^ did someone accept those manually or did it happen automatically? I'm thinking thumbnailer probably should have gone through the same, but I see for it's not currently listed in the Touch FFE >.<
[03:45] <stgraber> things that are seeded only on touch or not seeded at all are auto-accepted
[03:46] <stgraber> there's also a short whitelist
[03:47] <stgraber> anything that's uploaded to the archive at this point which contains new features must have an FFe, either a generic one like touch or a specific one. People shouldn't upload new features without FFes in the hope that it gets stuck in the queue and then gets reviewed by the release team.
[03:49] <cyphermox> stgraber: ah
[03:50] <cyphermox> stgraber: that wasn't the intent no
[03:50] <stgraber> good
[03:51] <cyphermox> gah
[06:18] <Mirv> I'd ask you to consider letting thumbnailer go forward from unapproved queue, considering it only adds a Provides: line in debian/control and nothing else. it's part of a big unity8 landing.
[06:23] <infinity> Mirv: Looking.
[06:24] <RAOF> Oh! I didn't notice that libgdiplus is seeded in edubuntu!
[06:24] <infinity> Yay, useless diff is useless.
[06:24] <infinity> Mirv: Why was that built twice in the PPA? :/
[06:28] <Mirv> infinity: I don't know, probably a mistake. https://code.launchpad.net/~mhr3/thumbnailer/provide-virtual-pkg/+merge/213630
[06:29] <infinity> Mirv: Yeah, I already grabbed the sources manually and diffed (and accepted).
[06:30] <Mirv> thank you infinity, that should unblock the whole landing
=== jackson is now known as Guest51547
=== doko_ is now known as doko
[07:21] <didrocks> Laney: unity8 is blocked again today in proposed with the wrong item, maybe your fix from yesterday was reverted?
[07:22] <didrocks> (blocking on archs it never built on)
[07:25] <infinity> didrocks: It's not blocking on arches it never built on, it's blocking on arches it *did* build on.
=== psivaa is now known as psivaa-afk
[07:26] <didrocks> infinity: how so?
[07:26] <didrocks> out of date on arm64: unity8 (from 7.84+14.04.20140327.1-0ubuntu2)
[07:26] <didrocks> out of date on powerpc: unity8 (from 7.84+14.04.20140327.1-0ubuntu2)
[07:26] <didrocks> out of date on ppc64el: unity8 (from 7.84+14.04.20140327.1-0ubuntu2)
[07:26] <didrocks> https://launchpad.net/ubuntu/+source/unity8/7.84+14.04.20140327.1-0ubuntu2
[07:26] <didrocks> -> it build-deps-wait on arm64/powerpc/ppc64el
[07:27] <infinity> Err, wait.  What?
[07:27] <infinity> Did someone break britney's tiny brain?
[07:27] <didrocks> infinity: we had exactly the same issue yesterday, Laney did "something"
[07:27] <didrocks> (same case: unity8)
[07:27] <didrocks> let me find the pastebin
[07:28] <infinity> Uhm, unity8 is in fauxPackages.  But why?
[07:28] <didrocks> infinity: http://irclogs.ubuntu.com/2014/04/01/%23ubuntu-devel.html#t10:03
[07:28] <didrocks> yeah, it was a fauxPackages (not sure what it means) yesterday as well
[07:29] <infinity> "FauxPackages: temporarily add unity8 to arm64/powerpc/ppc64el to unstick a complicated touch porting chain"
[07:29]  * infinity scratches his head.
[07:29] <infinity> I guess I'll just bump it for now, ask why later.
[07:29] <didrocks> ok, thanks infinity :) should I poke Colin for tracking down this?
[07:30] <didrocks> (as I guess we'll have the same issue with the next release as well)
[07:30] <infinity> didrocks: Yeah, it was Colin who added it in the first place, and it really shouldn't be there long-term.
[07:30] <didrocks> ok, I'll check with him, thanks
[07:30] <infinity> didrocks: But I suspect only he knows why he added it, and if it's still necessary.
[07:30] <infinity> didrocks: I bumped the version for now, though, it should get through.
[07:30] <didrocks> yeah, no worry, as long as we can unblock that one, I'll check with him today
[07:31] <didrocks> Saviq: FYI (in case you wonder why unity8 wasn't in previous image ^)
=== psivaa-afk is now known as psivaa
[09:10] <sil2100> Hello! I'm investigating the strange case of a few of our packages being blocked in -proposed as Valid candidates (unity8, ubuntu-touch-session, lxc-android-config, qtubuntu)
[09:11] <sil2100> The update_output mentions * i386: ubuntu-touch
[09:11] <sil2100> But when enabling -proposed on my device and trying to upgrade those packages, everything upgrades cleanly
[09:11] <sil2100> Could anyone help me out in interpreting the situation and getting to the root cause?
[09:15] <xnox> sil2100: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[09:16] <xnox> trying: unity8
[09:16] <xnox> skipped: unity8 (3 <- 14)
[09:16] <xnox>     got: 27+0: i-27
[09:16] <xnox>     * i386: ubuntu-touch
[09:16] <xnox> sil2100: looks like you want/need meta packages refresh. I thought cyphermox was changing the seeds, or something.
[09:17] <xnox> unless it simply needs hinting together.
[09:17] <sil2100> hmmmm
[09:17] <sil2100> xnox: thanks, I wonder since I don't think the seeds needed updating for this landing
[09:18] <xnox> sil2100: yeah, ubuntu-touch seed looks all updated and in release pocket since 5h ago...
[09:18] <sil2100> didrocks mentioned that Britney might need some hints
[09:20] <sil2100> Can anyone with the power and knowledge help with that?
[09:21] <Laney> lemme see
[09:23] <Laney> Looks like it could be hinting
[09:23] <Laney> I'll add some, then we'll see what happens
[09:23] <xnox> Laney: yeah, i'm confused why britney does not autotry unity8 with qtubuntu together.
[09:25] <Laney> Needs to go with ubuntu-touch-session at least
[09:25] <didrocks> Laney: the whole transition is unity8+qtubuntu+u-t-s
[09:25] <didrocks> Laney: lxc-android-config as well
[09:26] <Laney> I see it
[09:28] <sil2100> Thanks guys o/
[09:37] <Laney> sil2100: looks like that worked
[09:39] <sil2100> Laney: thank you!
[09:39] <Laney> enjoy
[09:54] <brendand> this is a slightly unusual situation, but if we had a feature in a package and then had to drop it for while and now want to bring it back, will we need a feature freeze exception
[10:04] <Laney> brendand: Yes (you need to say why the reasons you had to drop it are now resolved)
[10:04] <brendand> ok
[10:04] <Laney> Also final freeze is in 9 days, so consider how essential it is as there isn't much time to fix issues.
[10:05] <brendand> there will be a ui change too, can that be encapsulated in the same bug?
[10:06] <Laney> I guess
[10:06] <cjwatson> infinity,didrocks: yeah, unity8 is a scary special case right now, I had to put that there because it was difficult to unwind stuff above it - I forget exactly which package, indicator-something I think
[10:08] <didrocks> cjwatson: so, for every unity8 updates, we'll need to ask the release team to bump this fauxpackage?
[10:09] <cjwatson> didrocks: unfortunately for the moment that's true.  I need to go sort out the root cause so that you don't
[10:10] <didrocks> cyphermox: robru: Mirv: sil2100: Saviq: FYI ^ (something to keep in mind)
[10:11] <cjwatson> I think it's indicator-network
[10:12] <sil2100> ACK
[10:12] <cjwatson> introduced in indicator-network r291
[10:19] <Riddell> shadeslayer: spammer :)
[10:20] <shadeslayer> :P
[10:20] <shadeslayer> its all queuebot's fault
[10:24] <shadeslayer> Riddell: all uploaded
[10:59] <cjwatson> shadeslayer: how does phonon-backend-gstreamer1.0 0.0~git20140324-0ubuntu2 in the queue fix bug 1300478?
[10:59] <ubot2> Launchpad bug 1300478 in phonon-backend-gstreamer1.0 (Ubuntu) "package does not have kubuntu-bugs team in global subscribers" [Critical,Triaged] https://launchpad.net/bugs/1300478
[11:00] <shadeslayer> cjwatson: uhm ... wrong bug
[11:01] <cjwatson> shadeslayer: ok, rejecting, please reupload
[11:01] <shadeslayer> well, I don't have upload rights for it :)
[11:01] <shadeslayer> 1300480 is what it's supposed to fix, partially
[11:02] <cjwatson> please get your sponsor to reupload then ...
[11:02] <cjwatson> (you were listed as the uploader in debian/changelog)
[11:04] <cjwatson> would be good if somebody could look at my parted upload - I know there's a big queue but it fixes a critical LVM handling bug
[11:05] <cjwatson> ah, I see somebody did, thanks
[11:11] <rbasak> Can https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1282630 be looked at please? There are just six fairly simple enumerated changes. It's not complex like juju itself. The added features are fairly trivial.
[11:11] <ubot2> Launchpad bug 1282630 in juju-quickstart (Ubuntu Trusty) "[FFe] Upgrade juju-quickstart to new upstream release 1.3.0" [High,New]
[11:13] <Laney> rbasak: what does comment #2 mean?
[11:13] <rbasak> Laney: AIUI, there was an upstream change that required a newer version of juju-core, so it could land until the newer juju-core landed.
[11:14] <rbasak> Laney: but the specific changes needed have landed now.
[11:14] <rbasak> Uh, *couldn't* land until the newer juju-core landed, but the specific changes needed have landed now.
[11:17] <Laney> rbasak: OK, done
[11:17] <rbasak> Laney: thank you!
[11:24] <seb128> if somebody wants to review gexiv in the queue, the changes are non trivial but mostly build system ones
[11:24] <seb128> upstream asked that we update with that comment
[11:24] <seb128> "The major changes in this release are (a) ported to autotools, (b) added some version-number methods for GIMP (Shotwell doesn't use them), and (c) a couple of small memory leaks fixed.  For the most part this release was about prepping it for GIMP.
[11:24] <seb128> Also, Shotwell 0.18 is not dependent on the latest release of gexiv2, but we always prefer if they're used in lockstep (i.e. latest with the latest)."
[11:24] <seb128> the lib has few rdepends so it shouldn't be a risky update
[11:47] <Laney> seb128: done
[11:47] <seb128> Laney, thanks
[11:47] <Laney> np
[11:55] <seb128> how did that python-smbc update went through when bug #1300857 is not approved?
[11:55] <ubot2> Launchpad bug 1300857 in python-smbc (Ubuntu) "FFE for python-smbc 1.0.14.1, integrating new samba features and python3 support" [Undecided,New] https://launchpad.net/bugs/1300857
[11:58] <Laney> It is, I just did them in the other order
[11:58] <seb128> k
[11:59] <Laney> Guess I'll look at samba after lunch...
[11:59] <seb128> great
[11:59] <Laney> ...someone else feel free though ;-)
[11:59] <seb128> enjoy lunch!
[12:24] <tjaalton> stgraber: heh, now I hit the sssd upstart job issue myself, on upgrade; the upgrade hung when it tried to stop the daemon, upstart thought it was running when it wasn't
[12:25] <tjaalton> stgraber: so, dropping -D from /etc/default/sssd and 'expect fork' from the job is what I'm testing now
[12:26] <tjaalton> hmm no doesn't work
[12:26] <tjaalton> stop leaves a process around
[12:27] <tjaalton> or not, just slow to stop
[12:39] <tjaalton> what's confusing is that sssd itself tries a few times if there are errors connecting the server, so the pid doesn't match what upstart thinks it is
[13:03] <Mirv> qtbase saw one patch to fix online accounts focus behavior, and I ran all AP:s on device + desktop smoke-testing to test for no regressions.
[13:03] <Mirv> (a backported patch from upstream stable branch)
[13:15] <Laney> Mirv: sure, no need to ping unless you think it's being delayed ;-)
[13:17] <zul> can someone tell me why samba was rejected?
[13:17] <Laney> the mail should have included a reason
[13:18] <zul> pl
[13:18] <zul> er...ok
[13:18] <zul> can someone accept glance as well plese?
[13:27] <JackYu> Hi release team, who could help us review the UIFe bug #1301130? Thanks a lot.
[13:27] <ubot2> Launchpad bug 1301130 in ubuntukylin-default-settings (Ubuntu) "[UIFe] Upgrade ubuntukylin-default-settings to 1.1.2" [Undecided,Confirmed] https://launchpad.net/bugs/1301130
[14:15] <xnox> stgraber: Laney: ScottK: infinity: Riddell: slangasek: ubuntu-meta, ubuntu-sso-client, ubiquity, ubiquity-slideshow-ubuntu - are all part of U1 shut down uploads. Please review =)
[14:15] <Riddell> xnox: is it announced?
[14:15] <Laney> if it wasn't then it is now :P
[14:16] <Laney> yes, it is
[14:16] <xnox> Laney++
[14:16] <xnox> Riddell: top of the http://blog.canonical.com/ =)
[14:16] <xnox> Riddell: also blog url referenced in the closed bug #.
[14:16] <xnox> it's also on http://voices.canonical.com/ubuntuone/2014/04/02/shutting-down-ubuntu-one-file-services/
[14:19] <Riddell> groovy
[14:45] <doko> shadeslayer, Riddell: could for the future prepare smore batched uploads? packages fail to build and have to be given back
[14:45] <shadeslayer> doko: which ones have failed? I was just about to look at them
[14:46] <doko> shadeslayer, the ones you uploaded, and which are red in http://qa.ubuntuwire.com/ftbfs/ ;p
[14:46] <shadeslayer> doko: ack, looking at those right now
[14:47] <doko> shadeslayer, but maybe update_excuses.html has these in a better order
[14:47] <shadeslayer> doko: it's probably going to get better next cycle with the decoupling of frameworks and workspaces
[14:48] <shadeslayer> then we'll only have 170 packages to deal at one time :P
[14:55] <stgraber> tjaalton: just had a quick look and it looks like sssd is now properly in main
[14:55] <sil2100> Hello release team! Could I ask someone to maybe look at some of our packages in the UNAPPROVED queue? From the smaller ones, there are unity, ubuntu-themes and unity-settings-daemon which would need moving out of the queue
[14:56] <sil2100> Would be most grateful - those are bugfixes only and I would appreciate those moving forward, as we need to clean out our CITrain queue as well :)
[14:56] <tjaalton> stgraber: yep it is
[14:58] <Laney> It's not very sustainable to have the landing team needing to ping the release team for expedited reviews all the time
[14:58] <Laney> We need to figure out a solution for this issue
[15:03] <seb128> Laney, I don't see lot of options, out of increasing the number of silos (but not sure IS is wanting to give even more ppas to that pool) or changing the workflow of CI train
[15:04] <cjwatson> seb128: the obvious option is to fix LP to avoid GCing packages when a package copy job refers to them, and then change ci train to merge and clean immediately rather than waiting for things to pass unapproved/proposed
[15:04] <cjwatson> or to permit m&cing immediately, anyway
[15:04] <seb128> cjwatson, well, that's "changing the workflow", the merge to trunk happens once the packages are in the release pocket by design
[15:04] <seb128> cjwatson, they don't want to merge back things that are blocked by britney/fail tests/...
[15:05] <seb128> that's also to force people to care about driving their landing all the way
[15:05] <seb128> rather than caring about uploads only
[15:06] <cjwatson> which is all very well but maybe the tradeoff with blocking other people isn't worth that
[15:07] <seb128> right, I tried to argue against the "wait to be in release to merge back" with asac by then before they changed the workflow but failed at it
[15:07] <cjwatson> it could be merged into a temporary branch perhaps
[15:07] <seb128> if other wants to try good luck ;-)
[15:08] <seb128> CI train already have temporary branches with what is in proposed
[15:08] <seb128> I think
[15:08] <seb128> didrocks did that to address feedback from distro users (stgrabers iirc?)
[15:09] <didrocks> xnox actually
[15:09] <didrocks> but yeah
[15:09] <seb128> but yeah, we have technical options, if they are wanting the change the design decision of "you need to drive your change all the way through before being able to merge back"
[15:09] <didrocks> it's pushing to another branch
[15:09] <didrocks> remember that the first idea that was was "in next image"
[15:09] <didrocks> and I tried to push that to a more reasonable "in the release pocket"
[15:10] <didrocks> (which convict upstream to take care until it's in)
[15:10] <seb128> I'm glad we didn't settle on the next image ;-)
[15:10] <Laney> There could be something like an optional separation of the merging and cleaning phases
[15:10] <Laney> So you can clean and go to a holding area while in unapproved/proposed/whatever
[15:10] <didrocks> Laney: well, then, you end up in the exact same situation "it's in trunk, I don't care"
[15:10] <Laney> No
[15:10] <xnox> didrocks: oh, the branches are public now?! Where abouts / which account?
[15:11] <Laney> Clean the silo, don't merge to trunk
[15:11] <shadeslayer> doko: fwiw http://qa.kubuntu.co.uk/buildstatus/kubuntu-buildstatus.html
[15:11] <didrocks> xnox: a long time ago, the day you asked for it
[15:11] <shadeslayer> doko: prettier page :)
[15:11] <xnox> didrocks: excellent =) but where can i find it?
[15:11] <didrocks> xnox: when you publish, it's written in the stdout
[15:11] <Laney> Keep the -proposed branch around, have the merging stage be done later on
[15:11] <xnox> i need one for unity atm =)
[15:11] <didrocks> xnox: basically ~ps-jenkins/<component>/<series>-proposed
[15:11] <xnox> cool!
[15:11] <doko> shadeslayer, hurting my eyes like every kde colour ;p
[15:12] <shadeslayer> hah
[15:12] <didrocks> Laney: if you need to have a followup fix to unblock from proposed, you need to reassign a silo and so on
[15:12] <Laney> Yep
[15:12] <xnox> doko: i'll make it pink, would that do?!
[15:12] <Laney> I don't think that's so bad though, or is it?
[15:12] <shadeslayer> doko: the orange from ubuntu.com makes my eyes bleed on this monitor
[15:12] <didrocks> Laney: it is more complicated and more delays for upstream
[15:12] <Laney> Usually it won't happen, and you optimise for that case by getting out of the way of others
[15:13] <stgraber> zul: hey, that samba upload doesn't seem to fix the bug I mentioned yesterday, could you re-upload with that fix in there so we don't need to rebuild the whole thing just for a single extra directory?
[15:14] <zul> stgraber: which bug?
[15:15] <stgraber> 15:45 < seb128> zul, I can try having a look at the merge if you want
[15:15] <stgraber> 15:45 < stgraber> zul: if you do that, can you please fix bug 1268180 at the same time, should be trivial
[15:15] <Laney> didrocks: If we strictly cannot introduce any more complexity then I do not know where to go
[15:15] <seb128> stgraber, zul: if somebody reupload, be aware that zul's upload was superseeded by one I did to re-add my changes from yesterday
[15:15] <ubot2> Launchpad bug 1268180 in samba (Ubuntu) "net join doesn't work by default since switch to 4.x" [High,Triaged] https://launchpad.net/bugs/1268180
[15:15] <stgraber> 15:45 < ubottu> bug 1268180 in samba (Ubuntu) "net join doesn't work by default since switch to 4.x" [High,Triaged] https://launchpad.net/bugs/1268180
[15:15] <zul> stgraber: well the samba upload i did yesterday got rejected because there is a newer ssamb upload
[15:15] <stgraber> 15:46 < zul> seb128: i thought it was merged already
[15:15] <zul> stgraber:  right
[15:15] <stgraber> 15:46 < zul> slangasek:  sure
[15:15] <didrocks> Laney: what about more complexity? We do that everyday
[15:15] <Laney> Maybe make the second step 'publish and clean' and free up the silo at that point
[15:15] <didrocks> Laney: which is a little bit too much for a 2 days temporary hack
[15:15] <didrocks> done as a favor, in theory
[15:16] <seb128> stgraber, isn't that addressed by my fix from yesterday/the version in the queue?
[15:16] <didrocks> and I don't think adding another step for upstream worthes it
[15:18] <Laney> Seems to me like it's moved past the realm of temporary hack
[15:18] <stgraber> seb128: I don't think so, I only reviewed the diff but didn't see /var/lib/samba/private being added to -common or something close to that which would fix that bug
[15:18] <Laney> I'm trying to come up with ideas to smooth the interactions between our teams here
[15:18] <didrocks> Laney: ask them management to give more people to maintain and deliver 300 components
[15:18] <didrocks> Laney: yeah, and I implemented quite a lot of them on release team feedback from day 1
[15:19] <Laney> But if it's not realistic to expect development then it's not worth it :)
[15:19] <stgraber> zul: so if you could upload yet another samba with that bugfix, then I'll reject seb128's upload and accept yours instead :)
[15:19] <didrocks> Laney: I would love to see the same effort on the other side as well
[15:19] <ScottK> I suppose test and release tarballs that are ready to be integrated into the distro and package them normally is out of the question.
[15:19] <seb128> stgraber, ok, your copy past was confusing to me ;-)
[15:19] <zul> stgraber:  sure ill do it this afternoon
[15:20] <stgraber> zul: thanks
[15:20] <didrocks> ScottK: 2.5 people full time for 300 packages, if you can solve that question with "normal packaging", I'm all hear :)
[15:21] <ScottK> didrocks: Is it really 300?
[15:21] <didrocks> ScottK: saucy + trusty, yeah (I diminished the number in saucy as the SRU isn't as big)
[15:22] <ScottK> For KDE we're doing ~100 and it's mostly run a script, upload to a PPA, test, and then upload to the archive.
[15:22] <Laney> Not sure what to say to that...
[15:22] <didrocks> ScottK: yeah, however, doesn't seem you are making between 15 to 30 uploads every day
[15:22] <ScottK> Seems to work.
[15:23] <ScottK> didrocks: Yes.  That's true and intentional.
[15:23] <ScottK> test, roll tarball, release implies a little bit of grouping things and testing them.
[15:23] <didrocks> ScottK: which is what we do in silos
[15:24] <didrocks> grouping and testing on a dynamic level
[15:24] <ScottK> And that's working how well?
[15:24] <stgraber> xnox: looks like you have undocumented changes in that ubiquity upload
[15:24] <Laney> what was wrong with samba?
[15:24] <didrocks> ScottK: isn't that working? We have a lot of changes flowing in everyday, don't we?
[15:25] <xnox> stgraber: really? Like what
[15:25]  * xnox downloads the diff
[15:25] <stgraber> xnox: extra tests
[15:25] <ScottK> didrocks: The last threat on -devel resulted in what I thought was a lot of people speaking up about being blocked.
[15:25] <xnox> stgraber: stuff under ./autopilot/ is not documented in debian/changelog as those tests are pulled direct from lp:ubiquity at testing.
[15:25] <ScottK> My impression, admittedly from a distance, is it's getting jammed up pretty frequently
[15:25] <xnox> stgraber: but otherwise they are not shipped etc.
[15:25] <didrocks> ScottK: I was off while that decision was taken, thanks for not involving me into that
[15:26] <xnox> stgraber: maybe we shouldn't ship them in the tarball....
[15:26] <stgraber> xnox: ok
[15:26] <stgraber> xnox: more tests are always good anyway :)
[15:26] <xnox> stgraber: yeah =) plus they are already running against all gtk-ubiquity images already =)
[15:33] <Laney> stgraber: ^^^ guessing you rejected samba - what for?
[15:34] <stgraber> Laney: considering how long it takes to build and the fact that zul will upload it again in a few hours, didn't seem worth it.
[15:34] <Laney> I see
[15:34] <Laney> I didn't know there was another upload planned
[15:34] <stgraber> 15:19 < zul> stgraber:  sure ill do it this afternoon
[15:34] <Laney> Missed / didn't pay attention to that
[15:34] <Laney> ta
[16:00] <xnox> stgraber: seb128: can you please remove _binary_ packages  ubiquity-plugin-ubuntuone &  deja-dup-backend-ubuntuone https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1301454
[16:00] <ubot2> Launchpad bug 1301454 in ubiquity (Ubuntu Trusty) "Remove dropped binary-only packages due to U1 shutdown" [High,Confirmed]
[16:01] <xnox> they are dropped from their respective source packages in -proposed, due to u1 shutdown.
[16:02] <xnox> wait, need to fix gnome seed first.
[16:04] <cjwatson> xnox: I imagine they'll show up in NBS
[16:04] <cjwatson> in which case they won't need special prodding
[16:04] <xnox> cjwatson: ah, good point.
[16:20] <asac> cjwatson: seb128: yes, we should publish temp branches with what is in the silo currently and what is currnetly in proposed etc.
[16:20] <asac> doesnt mean we should mege to trunk earlier
[16:34] <xnox> asac: i guess it's just a question of how soon one can start preparing the next silo, for the same project. ideally the (landing -1), would simply _always_ be the pre-depends. Such that if that one get's stuck, one can't do the next one, but if it's all good then your next landing is staggered quicker.
[16:40] <didrocks> asac: we do publish those temp branches FYI
[16:40] <didrocks> (since end of January, the day xnox suggested it)
[16:45] <seb128> asac, the issue discussed there is when to clean silos mostly
[16:46] <seb128> asac, that's currently done at the "merge back" time to allow iterating on ongoing changes without restarting the whole process
[16:46] <seb128> asac, but it leads to issues where we are running out of silos, especially at freeze times where things have an unapproved stop on the way
[16:56] <xnox> stgraber: maybe review ubuntu-gnome-meta ? it's the same refresh as was done for ubuntu-meta.
[17:08] <utlemming> question for a release person -- walinuxagent is showing in -proposed on launchpad with amd64 and i386 builds, but it is not in the archives....which means I can't verify the SRU
[17:08] <utlemming> what needs to happe to get the builds in -proposed?
[17:09] <utlemming> http://paste.ubuntu.com/7195099/
[17:09] <apw> utlemming, which is missing? .6?
[17:10] <utlemming> apw: yup, .6 for -proposed
[17:10] <Laney> utlemming: I see it
[17:10] <Laney> walinuxagent: Installed: (none) Candidate: 1.3.2-0ubuntu6
[17:10] <Laney> walinuxagent-data-saver: Installed: (none) Candidate: 1.3.2-0ubuntu6
[17:12] <apw> utlemming, so to confirm 1.3.2-0ubuntu4~12.04.6 for precise right?  that is showing as not yet published
[17:12] <apw> "Note: Some binary packages for this source are not yet published in the repository."
[17:12] <apw> so waiting on a publisher run
[17:12] <Laney> oh, precise
[17:12] <Laney> those are in NEW
[17:13] <utlemming> Laney: I think the problem is that walinuxagnet was a MIR/SRU after the release of Precise. So every time we SRU it gets screwy
[17:13] <Laney> Right, it wasn't in precise release
[17:13] <Laney> You'll need an archive admin to process it
[17:14] <utlemming> Laney: ack, thanks
[17:15] <utlemming> Is there an archive admin around that can prod walinuxagent along?
[17:54] <gaughen> any chance that someone can have a look at the MAAS FFe and help move it forward - https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1281881
[17:54] <ubot2> Launchpad bug 1281881 in maas (Ubuntu) "[FFe] FFe for 14.04 features" [Critical,New]
[17:54] <gaughen> infinity, slangasek --^
[17:54] <gaughen> pretty please!
[18:39] <infinity> Bah.  Who processed that walinuxagent SRU?
[18:42] <bschaefer> Hello, would anyone be able to take a look at this FFe: https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1295389
[18:42] <ubot2> Launchpad bug 1295389 in libsdl2 (Ubuntu) "[FFe] Enable Mir video support for 2.0.2" [Undecided,New]
[18:44] <slangasek> gaughen: looking at 1281881 now
=== jackson is now known as Guest78494
=== Guest78494 is now known as Noskcaj_
[19:25] <slangasek> stgraber: I see there's a new samba upload; is that something you're taking care of?
[19:26] <stgraber> slangasek: ah yeah, I'll take care of it
[20:08] <stgraber> that cgmanager upload is pretty urgent as without it, the cgmanager libs are in /usr/lib which since my systemd upload yesterday unfortunately breaks all machines that have /usr on a separate partition...
[20:08] <stgraber> and since I contributed to that upload (the adt bits), I can't review it myself
[20:10] <infinity> stgraber: Looking.
[20:11] <infinity> stgraber: Though, if you asked systemd upstream, they'd tell you that /usr is always on /, and any deviation from that is immoral and probably gives you cooties.
[20:12] <infinity> stgraber: Ugh.  No, that upload is wrong.
[20:12] <infinity> stgraber: Only the library should be in /lib, not the .so or the .pc or any of that.
[20:12] <infinity> stgraber: Also, why remove ${shlibs:Depends} from everything?
[20:13] <infinity> Oh, because none of those packages contain binaries, I guess.
[20:20] <stgraber> infinity: I'm busy with other things at the moment but hopefully hallyn will reappear soon to take care of those comments. Please reject.
[20:21] <stgraber> infinity: just using libdir would have been way too easy... guess we'll need to override the install target and manually move the right bits to /lib/<multiarch path>/
[20:22] <infinity> stgraber: Well, there's usually libdir and slibdir for this.
[20:22] <stgraber> infinity: dropping the .a (and indeed making it -shared, not static) was intentional, it caused a few problems and we really don't want anyone to static build libcgmanager at this point
[20:41] <slangasek> infinity: "usually libdir and slibdir" - it's not particularly usual
[20:43] <infinity> slangasek: It's totally usual for the only library that matters. ;)
[20:43] <infinity> (But it's not wildly uncommon either)
[20:43] <slangasek> I can only think of three packages that do that
[20:44] <stgraber> all 3 of them you patched to do that? :)
[20:44] <slangasek> no - eglibc, e2fsprogs, and util-linux
[20:45] <infinity> slangasek: So how does, say, PAM handle it?  Just prepending prefix (or not) as appropriate?
[20:46] <infinity> slangasek: Or is it all done at the packaging level?
[20:46] <infinity> Ahh, at the packaging level.
[20:46] <slangasek> yeah
[20:46] <infinity> That's unpretty.
[20:47] <slangasek> I was going to try to find a "good" example of this in packaging, and all I'm finding are bad ones
[20:48] <slangasek> (plymouth gets it wrong; libpng seems to have regressed rather awfully; pam is ok but not quite as automated as one might like)
[20:48] <slangasek> but of the three, pam is the best
[20:49] <stgraber> my plan there was to override autoinstall, mkdir /lib/${DEB_HOST_MULTIARCH} and mv /usr/lib/${DEB_HOST_MULTIARCH}/*.so.* to that, is there a better way of doing that?
[20:49] <slangasek> I know I used to have an example somewhere of one that would sensibly determine the symlink target in debian/rules and correctly remap
[20:49] <slangasek> stgraber: that breaks the .so symlinks
[20:49] <stgraber> oh yeah, the symlinks
[20:49] <infinity> stgraber: ... what vorlon said.
[20:49] <infinity> But you could recreate the symlink too, you only have one of them.
[20:50] <infinity> I suspect the reason libc6 has machinery upstream to do this is because there are so many libraries and links to deal with that it would make packagers cry.
[20:50] <stgraber> right, so you need an extra ln -sf to change the target of the .so, the others are relative anyway
[20:50] <infinity> (Or, indeed, probably did make packagers cry at some point until someone committed fixes)
[20:51] <slangasek> infinity: nah, it predates packaging ;)
[20:51] <infinity> slangasek: I'm pretty sure I never ran make install in a glibc source tree before I was running a packaged distro. ;)
[20:51] <infinity> So, no idea on the history there.
[20:56] <slangasek> stgraber, infinity: expat
[20:57] <slangasek> that one has the general form that doesn't require futzing with debian/rules when the soname changes
[20:58] <infinity> slangasek: Did you just grab the source for everything in /lib and hunt until you found rules that didn't suck? :P
[21:00] <infinity> Right, so that does pretty much what we discussed.  Move the lib and retarget the link.
[21:00] <slangasek> infinity: no, I gave up after the 4th miss and resorted to codesearch.debian.net ;)
[21:00] <infinity> But nice that it does it by reading the filenames so it doesn't need manual changing, yes.
[21:42] <stgraber> infinity: second try ^
[21:46] <infinity> stgraber: Looks gooder.
[22:34] <slangasek> bdmurray: W: lsvpd source: maintainer-script-lacks-debhelper-token debian/postinst
[22:34] <slangasek> bdmurray: (looks like you overtrimmed a little bit, oops)
[22:36] <slangasek> bdmurray: if you can s/exit 0/#DEBHELPER#/ and reupload, I'll accept
[22:38] <bdmurray> slangasek: okay
[23:19] <xnox> slangasek: infinity: could you please review/accept https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=ubuntu-gnome-meta ?
[23:25] <slangasek> checking
[23:26] <slangasek> xnox: acceptzored