[00:00] -queuebot:#ubuntu-release- Unapproved: gnome-devel-docs (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra)
[00:02] <tsimonq2> sarnold: around? I'd like to get bug 1630700 fast-tracked through
[00:03] -queuebot:#ubuntu-release- Unapproved: ansible (xenial-proposed/universe) [<IP_ADDRESS>-2 => <IP_ADDRESS>-2ubuntu1] (no packageset)
[01:15] <infinity> wgrant: If a custom kernel will get us over the hump Right Now, let's do it.
[01:15] <infinity> wgrant: Agreed it's a terrible long-term solution, but not being able to build things we want on images today is also pretty ungood.
[01:17] <wgrant> infinity: Absolutely.
[01:17] <infinity> wgrant: Other than kernel build time, which I'm intimately familiar with, what kind of turnaround could we get on that?
[01:18] <wgrant> infinity: Soon™
[01:18] <infinity> (And said kernel could be neutered in debian/rules to exit 1 on DPKG_BUILD_ARCH != arm64, arm64 actually builds pretty fast compared to most)
[01:18] <infinity> Err, HOST_ARCH.
[01:18] <infinity> Though either would work in a non-cross env. :P
[01:20] <wgrant> infinity: We can get new images out in less than half an hour one the packages are available.
[01:20] <wgrant> Usually well less than half an hour, now that arm64 VMs aren't silly :)
[01:21] -queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (xenial-security/universe) [<IP_ADDRESS>0.22 => <IP_ADDRESS>0.22] (kernel) (sync)
[01:22] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (xenial-security) [<IP_ADDRESS>0.22]
[01:23] <infinity> wgrant: Need any help wrangling kernel packaging, or are you good there?
[01:23] <wgrant> infinity: I'm reasonably competent, particularly when not changing ABI :)
[01:23] -queuebot:#ubuntu-release- Unapproved: rejected linux-meta-snapdragon [sync] (xenial-security) [<IP_ADDRESS>0.22]
[01:23] <infinity> wgrant: Heh.  When not changing ABI, the best trick is to append to the current changelog entry and NOT MAKE A NEW ONE.
[01:23] <infinity> Then no ABI checker invoked, and magic.
[01:24] <wgrant> Precisely.
[01:24] <infinity> wgrant: Right, then I'll keep out of your hair.
[01:24] <wgrant> It took me a couple of years to work that hack out.
[01:24] <infinity> wgrant: Lemme know when you think it's ready for a spin, and I'll lob things at it.
[01:25] <infinity> I should be up for a Very Long While still.
[01:25] <infinity> In the process of reversing my clock.
[01:25] <infinity> Well, inverting, not reversing.
[01:25] <wgrant> infinity: It'll be a good while, currently in a couple of meetings.
[01:25] <wgrant> Though hopefully wrapping up now, then will get onto it properly.
[01:25] <infinity> wgrant: All good.  I intend to be awake all through London work day.
[01:25] <infinity> wgrant: TO set a trend for the rest of the week.
[01:26] <infinity> How I plan to do this, given that I woke up at 7am Calgary time, I'm not yet sure.
[01:26] <infinity> But I suspect caffeine might come into play.
[01:29] -queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu481 => 20101020ubuntu482] (core)
[01:30] <tsimonq2> infinity: Staying on UK time zones are fun, I did that over my summer vacation for a few weeks. :P
[01:30] <infinity> tsimonq2: I do it all the time, but it's always harder to shift one's clock on purpose rather than by accident. :P
[01:31] <tsimonq2> infinity: I can agree with that.
[01:31] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu482]
[01:31] -queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu2]
[01:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-devel-docs [source] (yakkety-proposed) [3.22.1-0ubuntu1]
[01:34] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (yakkety-proposed) [340.98-0ubuntu1]
[01:46] <cyphermox> infinity: logging off for some sleep. use ancient communication methods should you really need me for some reason.
[01:47] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161011)
[01:47] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161011)
[02:30] -queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Final] (20101020ubuntu482) has been added
[02:30] -queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Final] (20101020ubuntu482) has been added
[02:30] -queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Final] (20101020ubuntu482) has been added
[02:30] -queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Final] (20101020ubuntu482) has been added
[02:31] -queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Final] (20101020ubuntu482) has been added
[02:31] -queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Final] (20101020ubuntu482) has been added
[02:31] -queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Final] (20101020ubuntu482) has been added
[03:47] <apw> cjwatson, normally in 64bit all of physical memory is "direct mapped" so if the h/w is using a large physical space then we will chew a large chunk of KVA for the direct map
[03:50] <apw> still not clear as to why that is visible in userspace in any sense
[06:01] -queuebot:#ubuntu-release- New sync: openfoam (yakkety-proposed/primary) [4.0+dfsg1-3]
[06:12] -queuebot:#ubuntu-release- Unapproved: python3.6 (yakkety-proposed/universe) [3.6.0~b1-1ubuntu2 => 3.6.0~b2-1] (no packageset)
[06:13] -queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (yakkety-proposed) [3.6.0~b2-1]
[06:18] -queuebot:#ubuntu-release- New: accepted linbox [arm64] (yakkety-proposed) [1.4.2-1~build1]
[06:18] -queuebot:#ubuntu-release- New: accepted linbox [i386] (yakkety-proposed) [1.4.2-1~build1]
[06:19] -queuebot:#ubuntu-release- New: accepted linbox [armhf] (yakkety-proposed) [1.4.2-1~build1]
[06:19] -queuebot:#ubuntu-release- New: accepted linbox [ppc64el] (yakkety-proposed) [1.4.2-1~build1]
[08:19] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-304 (yakkety-proposed/restricted) [304.131-0ubuntu5 => 304.132-0ubuntu1] (ubuntu-desktop)
[09:15] <pitti> infinity, apw: I'm going to kill the currently running linux tests again, as they still keep breaking the testbed and are stuck in an eternal retry loop;  but I'll try to collect the console-log this time
[09:27] <pitti> apw: filed bug 1632252 with some logs/details
[09:27] <pitti> apw: sounds like sshd gets OOM-killed
[09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] has been updated (20161011)
[09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] has been updated (20161011)
[09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] has been updated (20161011)
[09:55] -queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core)
[09:56] <pitti> infinity, slangasek: ^ this drops the hard python3-launchpadlib dependency again (from http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz) and adds a graceful fallback
[09:56] <pitti> this should clean up most of http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
[10:03] <cjwatson> which will mean that the PPA changelog handling randomly doesn't work for users depending on whether they happen to have python3-launchpadlib installed?
[10:04] <cjwatson> I mean, I guess I see why you're doing it, but avoiding this was why I asked in review of that feature for it to be just made a dependency rather than conditional
[10:04] <pitti> cjwatson: I'd rather seed python3-launchpadlib on desktop then, TBH
[10:05] <pitti>  maybe the feature can also be reworked to do a single REST call via urllib, but I don't want to do this "under the gun"
[10:05] <cjwatson> pitti: seeding in desktop seems like a reasonable compromise, if people are OK with that
[10:05] <pitti> it doesn't do anything authenticated, so I guess getting a changelog with plain urllib should be fairly easy
[10:05] <cjwatson> maybe as a Recommends
[10:05] <pitti> *nod*
[10:06] <pitti> not sure who has the last word on that, but I'm happy to make the seed changes and update ubuntu-meta if we want to go ahead with this
[10:06] <cjwatson> It should be relatively easy to redo by-hand without lplib, indeed
[10:06] <cjwatson> One problem with seeding in desktop is, which desktops
[10:08] <pitti> hm -- how about we move the Depends: to update-manager?
[10:08] <pitti> (it previously was on python3-update-manager which is in standard)
[10:08] <pitti> update-manager is optional
[10:09] <pitti> then we don't need seed changes, and this conceptually sounds "more correct"
[10:09] <pitti> and to u-m-kde
[10:10]  * pitti self-rejects and reuploads, that's better than fiddling with seeds
[10:10] <cjwatson> Seems reasonable if you retain the optionality in the code
[10:11] <cjwatson> This is how to do what u-m does by hand:
[10:11] <cjwatson> $ curl -s 'https://api.launchpad.net/devel/archives?ws.op=getByReference&reference=%7Ecjwatson/ubuntu/ppa' | jq .self_link
[10:11] <cjwatson> "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa"
[10:11] <cjwatson> $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa?ws.op=getPublishedSources&source_name=ant&exact_match=true&version=1.9.7-3ppa1' | jq '.entries[0].self_link'
[10:11] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (yakkety-proposed) [1:16.10.7]
[10:11] <cjwatson> "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285"
[10:11] <cjwatson> $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285?ws.op=changelogUrl' | jq
[10:11] <cjwatson> "https://launchpad.net/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285/+files/changelog"
[10:11] <cjwatson> but you do have to make sure that all the quoting is correct
[10:12] <pitti> yeah, TBH that sounds more like a z thing
[10:12] <cjwatson> https://api.launchpad.net/devel/archives is a hardcoded base, and all of reference, source_name, and version are inputs that must be URL-escaped
[10:13] <cjwatson> Easy enough, but yeah, can be done in z
[10:14] <cjwatson> (Do we have a name yet?)
[10:15] <pitti> for the Zealous Zombie?
[10:16] <Odd_Bloke> Zenial Zebra.
[10:16] -queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core)
[10:17] <acheronuk> some have been guessing at Zazzy Zorilla
[10:17] <pitti> infinity, slangasek: ^ updated update-manager as per discussion with cjwatson; this is now self-contained (does not need seed changes)
[10:18] <pitti> I think we can drop xml-core's Depends: perl, to clean up that from "standard" as well (only using modules from perl-base); will confirm and then upload/file Debian bug
[10:19] <pitti> with these two, the remaining priority-mismatch items should be valid
[10:20] <cjwatson> acheronuk: Yeah, I'm ignoring guesses because they're ~never right
[10:21] <cjwatson> pitti: the changelog seems a bit wrong now?
[10:21] <cjwatson> pitti: wait, maybe I'm suffering from caching
[10:21] <pitti> cjwatson: ah, it should probably say "lower .. from python3-update-manager's Depends"?
[10:22] <pitti> cjwatson: http://launchpadlibrarian.net/289188605/update-manager_16.10.7_source.changes is the current version that I uploaded
[10:22] <cjwatson> no, I'm OK with it once I avoid looking at the old cached version
[10:22] <cjwatson> (but am no longer release team, so not accepting)
[10:24] <acheronuk> cjwatson: yep, my guess always seems wrong
[10:54] -queuebot:#ubuntu-release- Unapproved: xml-core (yakkety-proposed/main) [0.15 => 0.15ubuntu1] (core)
[10:55] <pitti> ^ will fix the perl priority-mismatches. This was a recent regression from https://anonscm.debian.org/git/debian-xml-sgml/xml-core.git/commit/?id=fed34e0
[10:56] <pitti> i. e. accidentally dropping the dh_perl -d option
[10:56] <pitti> (also filed as Debian bug 840410)
[10:56] <pitti> Laney: ^ as this is quite straightforward, mind reviewing/accepting this?
[10:57] <pitti> reviewing u-m is also appreciated of course, to clean up most of priority-mismatches so that we can get it release-ready
[11:06] <Laney> pitti: sure
[11:13] <tsimonq2> cjwatson: I'm still voting for Zealous Zebu :P
[11:13] <tsimonq2> s/voting/hoping/
[11:16] <acheronuk> tsimonq2: lol. you changed your mind AGAIN?
[11:17] <tsimonq2> acheronuk: no I only said Zazzy Zorilla because I thought Barry Warsaw leaked the codename, turns out he made it up... :P
[11:18] <acheronuk> tsimonq2: I swear there is a subtle disinformation plot by canonical each year to keep the real one under wraps
[11:19] -queuebot:#ubuntu-release- Unapproved: accepted xml-core [source] (yakkety-proposed) [0.15ubuntu1]
[11:19] <tsimonq2> acheronuk: cjwatson linked me to a graph yesterday...
[11:20]  * tsimonq2 finds it
[11:20] <tsimonq2> acheronuk: http://people.canonical.com/~cjwatson/tmp/release-name-notice.png
[11:22] <acheronuk> interesting
[11:32] <Laney> pitti: unorthodox syntax on Suggests there
[11:32]  * Laney built it to check it works (it does)
[11:33]  * rbasak believes he predicted Yakkety Yak before it was named
[11:33] <rbasak> Though in hindsight it was obvious I guess
[11:33] <Laney> and argh at all the trailing spaces in update-manager/d/control
[11:34] <Laney> (not new)
[11:35] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (yakkety-proposed) [1:16.10.7]
[11:44] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (yakkety-proposed/universe) [10.2.7-2 => 10.2.7-3] (no packageset) (sync)
[11:44] -queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (yakkety-proposed) [10.2.7-3]
[11:46] <pitti> Laney: you mean trailling commas?
[11:47] <pitti> Laney: trailing spaces> yeah, my vim loudly complains too, but minimal diff for review, etc.
[11:49] <Laney> pitti: It's like
[11:49] <Laney> Suggests:
[11:49] <Laney>           python3-...
[11:57] -queuebot:#ubuntu-release- Unapproved: congress (yakkety-proposed/universe) [4.0.0~rc1+dfsg1-1 => 4.0.0+dfsg1-2] (no packageset) (sync)
[11:57] -queuebot:#ubuntu-release- Unapproved: accepted congress [sync] (yakkety-proposed) [4.0.0+dfsg1-2]
[12:31] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu<IP_ADDRESS> => 2.0~rc3-0ubuntu<IP_ADDRESS>] (ubuntu-server)
[12:32] <cyphermox> good morning
[12:33] <pitti> Laney: oh, oops
[12:33] <pitti> Laney: fixed in bzr
[12:33] <pitti> hey cyphermox
[12:34] -queuebot:#ubuntu-release- Unapproved: designate-dashboard (yakkety-proposed/universe) [3.0.0~rc1-1 => 3.0.0-2] (no packageset) (sync)
[12:35] -queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [sync] (yakkety-proposed) [3.0.0-2]
[12:36] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu<IP_ADDRESS>]
[12:37] <pitti> apw: do you know about the fate of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux ?
[12:37] <pitti> I suppose we should release that RSN so that we can rebuild images?
[12:41] <apw> pitti as far as i can tell it is as good as the previous one, so i guess as those tests are not going to ever come in we'll need to hint it
[12:43] <pitti> apw: oh right -- I was blindly assuming they would use a tracking bug
[12:43] <pitti> apw: hinting
[12:45] <pitti> seb128, jbicha: do we want to let bug 1631955 into yakkety, or remain as an SRU?
[12:46] <pitti> (seb128, jbicha: we still have a kernel and two other packages to land before respinning images)
[12:46] <seb128> pitti, letting jbicha comment, I didn't look at this update
[12:46] <seb128> pitti, we don't plan respins after that?
[12:47] <pitti> seb128: I don't know; just saying that the current images can't possibly be final
[12:47] <seb128> pitti, it's a bit suboptimal that we have the current firefox blocked in proposed but I guess it is what it is now?
[12:47] <seb128> k
[12:47] <pitti> seb128: well, firefox is FTBFS, not much that we can do other than fixing it
[12:48] <pitti> but that's fine as an SRU
[12:48] <seb128> not optimal though
[12:49] <seb128> there might be some security issues in the previous verison
[12:49] <seb128> oh, also that's using an google api key that we revocated
[12:49] <seb128> the new key was added in https://launchpad.net/ubuntu/+source/firefox/49.0+build4-0ubuntu1
[12:49] <pitti> well, if we have a fix now/today, I'm sure everyone would be happy to get it in :)
[12:49] <seb128> chrisccoulson, ^
[12:50] <seb128> pitti, or we could declared firefox unsupported on ppc64el like it is on powerpc and s390x and delete the binaries like we did for those...
[12:51] <chrisccoulson> I don't think I'll be able to spend time investigating a ppc64el-specific startup crash in Firefox tbh
[12:51] <jbicha> pitti: I'm ok with letting e-d-s in now, it worked fine for me
[12:51] <chrisccoulson> (which is what the build failure is)
[12:51] <jbicha> the new e-d-s apparently doesn't actually fix the google authentication problem
[12:54] <jbicha> I guess we can point ppc users to epiphany? since chromium isn't supported there either
[12:58] -queuebot:#ubuntu-release- Unapproved: python-pycadf (yakkety-proposed/main) [2.2.0-2 => 2.4.0-1] (ubuntu-server) (sync)
[13:11] <chrisccoulson> seb128, have you used firefox in proposed btw?
[13:11] <seb128> chrisccoulson, not really, but I can give it a try if you want ... anything in particular?
[13:11] <seb128> chrisccoulson, did you see the ping from rico early on ubuntu-devel btw?
[13:12] <chrisccoulson> seb128, well, I just thought - the build in the release pocket is now so ancient that it was built with the old compiler
[13:12] <chrisccoulson> I didn't see a ping earlier, let me check
[13:13] <seb128> chrisccoulson, it was at 8:25 u.k
[13:13] <chrisccoulson> ahh
[13:13] <chrisccoulson> so, firefox has the same issue as https://bugs.chromium.org/p/v8/issues/detail?id=3782 which already affected chromium and oxide
[13:14] <chrisccoulson> Firefox really needs a maintainer that cares about it ;)
[13:17] <chrisccoulson> oh, apparently firefox doesn't have this problem, and the bug ricotz linked is thunderbird specific
[13:22] <jbicha> chrisccoulson: I've been using firefox from y/proposed for several days and it seems ok
[13:35] <apw> and the one from release is dire :/
[13:42] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.5 (yakkety-proposed/universe) [1:3.5.2-3ubuntu1 => 1:3.5.2-5] (no packageset) (sync)
[13:43] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.5 [sync] (yakkety-proposed) [1:3.5.2-5]
[14:02] <balloons> pitti, nothing is running in autopkgtest?
[14:07] -queuebot:#ubuntu-release- Unapproved: xfsprogs (yakkety-proposed/main) [4.3.0+nmu1ubuntu2 => 4.3.0+nmu1ubuntu3] (core)
[14:07] <apw> ^ fixes fallout from v4.8 kernel headers ...
[14:14] <davmor2> cyphermox: how are we looking for the new shim do you know anything yet?
[14:30] -queuebot:#ubuntu-release- Unapproved: openorienteering-mapper (yakkety-proposed/universe) [0.6.3-2build1 => 0.6.5-1] (no packageset) (sync)
[14:31] -queuebot:#ubuntu-release- Unapproved: accepted openorienteering-mapper [sync] (yakkety-proposed) [0.6.5-1]
[14:36] <pitti> balloons: no, we are in freeze :)
[14:37] <pitti> balloons: juju is, actually (i386 and amd64 failed already)
[14:37] -queuebot:#ubuntu-release- Unapproved: gdb (yakkety-proposed/main) [<IP_ADDRESS>61005-0ubuntu1 => 7.12-0ubuntu1] (core)
[14:37] <balloons> pitti, right it was of course what I was looking for. I saw amd64 failed, but I can't see the log proper until it finishes -- unless there's something I don't know
[14:38] -queuebot:#ubuntu-release- New: accepted openfoam [sync] (yakkety-proposed) [4.0+dfsg1-3]
[14:39] <cyphermox> davmor2: sorry, no news to be given
[14:40] <pitti> apw: xfsprogs> cheers! is that an upstream backport?
[14:41] -queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (yakkety-proposed) [4.3.0+nmu1ubuntu3]
[14:41] <apw> pitti, no that is allll me
[15:04] -queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.12-0ubuntu1]
[15:04] -queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1 => 1.9-3.2ubuntu<IP_ADDRESS>] (core)
[15:05] -queuebot:#ubuntu-release- Unapproved: vlan (precise-proposed/main) [1.9-3ubuntu6 => 1.9-3ubuntu6.1] (kubuntu, netbook, ubuntu-desktop, ubuntu-server, unr)
[15:05] -queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10 => 1.9-3ubuntu10.1] (core)
[15:16] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20160913.1-0ubuntu1 => 1:20161011.1-0ubuntu1] (no packageset)
[15:21] <pitti> chrisccoulson, seb128: removing current ppc64el firefox binaries seems reasonable to me; Laney, infinity, opinions?
[15:22] <chrisccoulson> pitti, I should point out, we don't block firefox security updates for build failures on those 3 architectures anyway
[15:22] <chrisccoulson> And the updates are never tested on those architectures in any case
[15:23] <seb128> pitti, +1 from me, it might require to delete/tweak a bit more due to rdepends, whoever handled the drop of powerpc earlier in the cycle should know the details of what is needed though
[15:23] <pitti>  firefox | 49.0+build4-0ubuntu<IP_ADDRESS>   | xenial-security  | source, amd64, arm64, armhf, i386, ppc64el
[15:24] <pitti>  chrisccoulson: I was wondering because it apparently did build for xenial still -- gcc 6, presumably?
[15:24] <chrisccoulson> pitti, I uploaded thunderbird with a build failure fix, but I've since been made aware of https://bugzilla.mozilla.org/show_bug.cgi?id=1251576, so it won't run anyway (it's a similar issue to https://bugs.chromium.org/p/v8/issues/detail?id=3782, which we already worked around in chromium and oxide)
[15:24] <chrisccoulson> pitti, yeah, most likely
[15:25] -queuebot:#ubuntu-release- Unapproved: libreoffice (yakkety-proposed/main) [1:5.2.2-0ubuntu1 => 1:5.2.2-0ubuntu2] (kubuntu, ubuntu-desktop)
[15:25] <Laney> pitti: We forced it last time
[15:26] <pitti> Laney: you mean with a britney hint, not removing packages?
[15:26] <Laney> yep
[15:26] <pitti> that seems a bit awkward
[15:26] <Laney> why?
[15:26] <pitti> Laney: hm, does that still turn up at NBS?
[15:27] <pitti> our report doesn't show that, AFAIK it only runs for amd64
[15:28] <jbicha> Firefox shows up at the bottom of /update_output.txt
[15:28] <pitti> List of old libraries in testing (2):
[15:28] <pitti>   firefox: s390x powerpc
[15:28] <pitti> oh, this?
[15:28] <pitti> well, we really should remove the old binaries properly
[15:29]  * pitti → meeting, bbl
[15:49] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92 => 0.92ubuntu1] (desktop-core, ubuntu-server)
[16:00] -queuebot:#ubuntu-release- Unapproved: python-tornado (yakkety-proposed/universe) [4.4.1-2ubuntu1 => 4.4.2-1ubuntu1] (ubuntu-desktop)
[16:01] <slangasek> pitti, balloons, stokachu: seems that juju-core is still failing autopkgtests, has this been analyzed?
[16:01] <pitti> slangasek: yes, balloons and I just debugged it
[16:01] <pitti> slangasek: ballons is preparing a new .dsc, I'll sponsor
[16:01] <balloons> slangasek, yes it's sorted. ^^
[16:01] -queuebot:#ubuntu-release- Unapproved: accepted python-pycadf [sync] (yakkety-proposed) [2.4.0-1]
[16:01] <pitti> building from bzr doesn't work (source and pristine-tar disagree), so I'll let him sort out the source build
[16:01] <balloons> and sorry pitti, re-setting up vpn to upload dsc
[16:02] <pitti> balloons: that or pastebin a debdiff if that's easier
[16:18] <lunaphyte> hi.  i'm trying to upgrade an eol install [15.04] to 15.10 [this is all just to upgrade to 16.04].  but if i'm not mistaken, the old-releases repo doesn't have packages/indexes for 15.10 published, so i'm stuck, it seems.
[16:18] <lunaphyte> however, us.archive.ubuntu.com still does.  so i'm a little confused as to how to go about upgrading.
[16:18] <wxl> lunaphyte: #ubuntu for support.
[16:19] <lunaphyte> [and, if this is the wrong channel, apologies]
[16:19] <lunaphyte> wxl: i actually came here from #ubuntu-server
[16:20] <wxl> lunaphyte: they suggested to come here? because that's strange. this channel exists to coordinate upcoming releases.
[16:20] <lunaphyte> it seems though that vivid package indexes aren't listed at old-releases, yet they should be, hence my question here
[16:20] <lunaphyte> wxl: no, they didn't suggest.  i spent time there troubleshooting, that's all.
[16:20] <wxl> lunaphyte: i'd personally advice you grab /home and maybe /etc and do a fresh install re-using those
[16:21] <lunaphyte> honestly, i'd just like to know who i can ask about 15.04 missing from old-releases
[16:24] <wxl> lunaphyte: vivid and wily are both at archive.ubuntu.com
[16:25] -queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.1.0~beta2+bzr5454-0ubuntu1]
[16:26] -queuebot:#ubuntu-release- Unapproved: networking-hyperv (yakkety-proposed/universe) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (no packageset)
[16:26] <lunaphyte> i thought since vivid is eol, it would be at old-releases.
[16:26] <wxl> it will get there eventually, i'm sure
[16:26] -queuebot:#ubuntu-release- Unapproved: accepted networking-hyperv [source] (yakkety-proposed) [3.0.0-0ubuntu1]
[16:27] <lunaphyte> inex retrieval at archive.ubuntu.com does work for vivid, yes, but upgrading fails, because it tries to upgrade to 16.04, but do-release-upgrade doesn't support it, of course.
[16:27] <wxl> so like i said, fresh install
[16:27] <lunaphyte> wxl: thanks, yeah, i guess that's my question, is what typically defines when that happens?
[16:28] <chrisccoulson> pitti, are you able to approve partner uploads?
[16:28] <lunaphyte> wxl: it's ok, i'll let the channel get back to the /topic
[16:28] <wxl> infinity: could you answer lunaphyte's question as to why vivid and wily are not in old-releases but are instead still on archive?
[16:29] <lunaphyte> hopefully my question isn't interpreted as "when will this be" - just would like to understand what the transition is based on
[16:30] <wxl> many activities in release require manual activity (for example, turning dailies on and off in response to milestone testing)
[16:30] <cjwatson> lunaphyte: Can't give you an accurate answer as to why it's not done yet (I suspect not-got-round-to-it for wily, and complicated stuff involving the Ubuntu phone codebase for vivid), but the process doc is https://wiki.ubuntu.com/EndOfLifeProcess
[16:30] <wxl> that said, sometimes they just get temporarily forgotten or put off
[16:31] <rbasak> There is no definite schedule. The EOL date is one bound.
[16:31] <wxl> tl;dr lesson learned: upgrade BEFORE EoL :)
[16:31] <lunaphyte> cjwatson: ah, thanks, that's informative
[16:31] <lunaphyte> wxl: yeah, for sure.  life sometimes has other plans, unfortunately. :)
[16:31] <lunaphyte> it's all good though.
[16:32] <apw> well before EOL of the release which follows :)
[16:32] <cjwatson> I'd probably just upgrade by frobbing sources.list and doing a dist-upgrade.
[16:32] <wxl> apw: hahahah indeed
[16:32] <cjwatson> Sure, do-release-upgrade helps, but it isn't mandatory.
[16:32] <lunaphyte> if the end result is that eventually it will make it's way to old-releases, and then the nominal eol upgrade path will work as expected, that's fine
[16:32] <rbasak> Somebody should figure out and document how to handle this better on the existing wiki page.
[16:33] <pitti> chrisccoulson: technically, yes; procedurally I have no idea what to do with them/what to check, etc.
[16:33] <lunaphyte> cjwatson: does frobbing sources.list mean switching from vivid to wily, in my case?
[16:33] <rbasak> https://help.ubuntu.com/community/EOLUpgrades
[16:36] <lunaphyte> i'm but a visitor here, but would a note somewhere there along the lines of "if you are doing an eol upgrade of a relatively recent release, it's possible that it may not work, until various transitions have fully occured - please try again later" be of any value?
[16:36] <chrisccoulson> pitti, ah. I need adobe-flashplugin approving (I've uploaded yakkety so far, I normally wait until that's approved before uploading the other releases)
[16:37] <chrisccoulson> pitti, the procedure is basically 1) approve, 2) I verify they're ok, 3) Copy to release pocket. Not sure if that helps you though :)
[16:38] -queuebot:#ubuntu-release- Unapproved: casper (xenial-proposed/main) [1.376.1 => 1.376.2] (desktop-core, ubuntu-server)
[16:38] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu<IP_ADDRESS> => 2.0~rc3-0ubuntu<IP_ADDRESS>] (ubuntu-server)
[16:39] <pitti> slangasek, balloons ^ now with 10% more testing love!
[16:39] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu<IP_ADDRESS>]
[16:41] -queuebot:#ubuntu-release- New binary: openfoam [s390x] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset)
[16:41] -queuebot:#ubuntu-release- Unapproved: indicator-network (yakkety-proposed/main) [0.8.0+16.10.20160930.5-0ubuntu1 => 0.8.0+16.10.20160930.5-0ubuntu2] (no packageset)
[16:41] <cjwatson> lunaphyte: Yeah
[16:41] <Laney> ^- fix for the live session
[16:45] -queuebot:#ubuntu-release- New binary: openfoam [ppc64el] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset)
[16:45] <pitti> chrisccoulson, Laney: I removed firefox ppc64el binaries; there are also some orphaned powerpc/s390x ones from 46.0.1+build1-0ubuntu1 and 47.0+build3-0ubuntu1, cleaning those too (this is why I don't like forcing without binary removal)
[16:46] <chrisccoulson> pitti, thanks
[16:48] <lunaphyte> cjwatson: thanks.  i suppose it's not necessarily kosher/supported, but your experience has been largely successful doing that?
[16:50] <rbasak> lunaphyte: please do edit https://help.ubuntu.com/community/EOLUpgrades to make it better.
[16:50] <rbasak> (you asked about adding a note?)
[16:51] <lunaphyte> rbasak: oh, ok, will do
[16:51] <rbasak> Looks like you have to ask to join the team, but contributors are welcome
[16:51] <rbasak> https://help.ubuntu.com/community/WikiGuide
[16:51] <rbasak> That's presumably to avoid spam.
[16:51] <lunaphyte> sure, understood
[16:52] <wxl> lunaphyte: or you could just become an ubuntu member and then you don't have to worry about that at all :)
[16:52] <lunaphyte> wxl: hah!  that sounds like more responsibility :)
[16:53] <wxl> lunaphyte: not necessarily. just need to sustain relevant contributions to the project
[16:53] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1]
[16:53] <rbasak> Fixing the doc sounds like a relevant but circular contribution :-)
[16:53] <wxl> !membership | lunaphyte
[16:53] <pitti> Laney: indicator-network> eek
[16:54] <lunaphyte> wxl: thanks
[16:54] <pitti> Laney: do any of the other unity8 upstart jobs now unexpectedly start in the unity7 session? it appears to me that this chagne needs to be replicated to all of those?
[16:54] <wxl> lunaphyte: i'm on the membership board if you have other questions about it
[16:54] -queuebot:#ubuntu-release- Unapproved: accepted indicator-network [source] (yakkety-proposed) [0.8.0+16.10.20160930.5-0ubuntu2]
[16:55] <cjwatson> lunaphyte: Yes, but I've been doing the general equivalent since well before Ubuntu existed so I'm not a good sample case.
[16:55] <pitti> Laney: I thought upstart had a less ugly way to do that, like start on starting DESKTOP_SESSION="unity8" or so?
[16:55] <pitti> unity-panel-service.conf:start on desktop-start DESKTOP_SESSION=ubuntu
[16:56] <pitti> Laney: ^ like this?
[16:56] <pitti> Laney: (accepted, as this is just bikeshedding, but I wonder if that affects other services too0
[16:56] <Laney> I copied it from the other job in the same source package which definitely works
[16:56] <pitti> unity-panel-service.conf:# start on started unity7
[16:56] <pitti> or even just that
[16:56] <lunaphyte> wxl: well, i really do appreciate all of the info, but if i'm honest, it's probably not in the cards for me these days.  hopefully that doesn't come across as dismissive!
[16:56] <Laney> I don't want to mess around at this point
[16:56] <lunaphyte> cjwatson: understood, thanks
[16:57] <wxl> lunaphyte: np. it will be there in the future.
[16:57] <lunaphyte> gracias
[16:57] <wxl> de nada
[16:57] <Laney> maybe you could do desktop-start DESKTOP_SESSION=... and indicator-services-start
[16:57] <Laney> Seems risky to me to experiment now
[16:58] <pitti> Laney: "start on started unity7" (like unity-panel-service.conf) seems like the equivalent of WantedBy=unity7-session.target
[16:58] <pitti> Laney: but yes, if it works, it's ok; as I said I mostly just wondered if that affects other unity8 services too
[16:59] <Laney> It's waiting for some event, not just that unity8 is started
[16:59] <Laney> and I don't know - at least I haven't heard that any of those actually crash like this one does ...
[17:00] -queuebot:#ubuntu-release- Unapproved: thunderbird (yakkety-proposed/main) [1:45.3.0+build1-0ubuntu2 => 1:45.3.0+build1-0ubuntu3] (mozilla, ubuntu-desktop)
[17:00] <Laney> I have something called indicator-transfer-service running, not sure if that's necessary or not
[17:06] <Laney> seb128 / tedg: do you know if indicator-transfer is used or useful on unity 7?
[17:06] <seb128> Laney, it's not used and probably not going to be useful
[17:06] <seb128> it's supposed to indicate ongoing downloads
[17:07] <seb128> but classic apps don't use the api to talk to it
[17:07] <seb128> so probably not that useful
[17:10] <Laney> thanks
[17:10] <Laney> I'll give it the same love, but this is lower priority
[17:14] <tumbleweed> I'm being arm twisted with beer, for some last minute universe FFes :)
[17:23] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (yakkety-proposed/main) [117 => 118] (kubuntu, ubuntu-desktop)
[17:25] -queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu3]
[17:26] -queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset)
[17:29] <slangasek> infinity, pitti: do we have a target time for the start of image respins, to guide evaluating the uploads in the queue?
[17:29] <Laney> pitti: ^- same fix - this one is "just" a waste of resources
[17:30] <slangasek> I'm a waste of resources ;(
[17:30] <Laney> urgh, there's a waste of resources in my changelog
[17:30] <infinity> slangasek: I was shooting for "very soon".  But will take another round of fixes if they don't need 4h to get through the sausage factory.
[17:31] <infinity> slangasek: I was personally waiting on the arm64 buildd kernel hack (done), and ubuntu-system-settings building successfully (in progress) and migrating.
[17:31] <infinity> I'm also curious to see what the fallout is from the firefox and thunderbird removals.
[17:32] <infinity> I bet component-mismatches explodes.
[17:32] <slangasek> infinity: what is "soon", realistically? we have maas which is currently publishing
[17:32] -queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset)
[17:32] <infinity> slangasek: After that maas, since it'll beat u-s-s to the release pocket.
[17:32] <slangasek> ok
[17:33] <infinity> slangasek: I dunno.  More than an hour, less than several.
[17:33] <infinity> I hope.
[17:34] <slangasek> infinity: it seems for some reason a gdb was accepted, which is seeded everywhere and needs 4 more hours to build on armhf
[17:34] <slangasek> (appx)
[17:34] -queuebot:#ubuntu-release- Unapproved: rejected indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2]
[17:34] <infinity> slangasek: Whee.
[17:34] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-304 [source] (yakkety-proposed) [304.132-0ubuntu1]
[17:34] <slangasek> so maybe someone wants to speak up and explain why that was accepted
[17:34] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (yakkety-proposed) [118]
[17:35] <slangasek> pitti: ?
[17:35] <slangasek> or Laney or apw or tumbleweed or stgraber ?
[17:36] <Laney> nope
[17:36] <slangasek> doko: or did you happen to accept this gdb yourself?
[17:36] <Laney> I accepted thunderbird though, which needs quite a while on armhf
[17:36] <Laney> Apparently the current one fails to start
[17:37] <slangasek> Laney: ah, well, thunderbird is seeded in only half the places that gdb is
[17:37] <infinity> Which is still many places. :P
[17:37] <Laney> block-all source time?
[17:37] <infinity> Not all.
[17:37] <slangasek> only ubuntu-mate, ubuntu desktop, ubuntukylin FWIW
[17:37] <infinity> But getting close to block all seeded.
[17:38] <slangasek> oh. but also ubuntustudio + xubuntu, so that's fine
[17:39] <slangasek> infinity, Laney: I suggest forcing thunderbird in before armhf is built, to unblock the image builds / tests on other archs and let armhf binaries catch up on their own time
[17:40] <infinity> We'll see how the other arches fare.
[17:40] <slangasek> (since I don't think any of those projects are building armhf images currently)
[17:40] <Laney> ubuntu2/armhf actually FTBFSed
[17:40] <Laney> So we'll see how this one does
[17:42] <Laney> It'll need some forcing or removals in any event since arm64/ppc64el have regressed
[17:42] <Laney> Might be one to punt
[17:42] <Laney> Dunno how crap 38 is
[17:42] <infinity> Has anyone looked into *why* they regressed?
[17:43] <infinity> They build fine in xenial with the same upstream version.
[17:45] <Laney> chrisccoulson: ^- (I'm guessing "no")
[17:45] <Laney> u-s-s worked
[17:47] <chrisccoulson> i didn't notice that ubuntu2 had been approved actually
[17:48] <chrisccoulson> the armhf is a race condition that we keep seeing in the build. It'll probably work fine if it's retried
[17:48] <chrisccoulson> the arm64 build failure is a crash when compiling the startup cache
[17:49] <chrisccoulson> it most likely builds fine on xenial because it's not using gcc6
[17:52]  * infinity notes that gcc-5 is still in yakkety.
[17:52] <infinity> Not that that fixes the bugs, but it would defer the issue.
[17:54] -queuebot:#ubuntu-release- Unapproved: gcr (yakkety-proposed/main) [3.20.0-2ubuntu1 => 3.20.0-2ubuntu2] (kubuntu, ubuntu-desktop)
[18:03] <infinity> pitti: Are you on top of this indicator-transfer thing?
[18:03]  * infinity eyes libreoffice suspiciously in the queue.
[18:03] -queuebot:#ubuntu-release- Unapproved: accepted gcr [source] (yakkety-proposed) [3.20.0-2ubuntu2]
[18:04] -queuebot:#ubuntu-release- Unapproved: accepted python-tornado [source] (yakkety-proposed) [4.4.2-1ubuntu1]
[18:06] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20161011.1-0ubuntu1]
[18:10] <chrisccoulson> oh, who just approved flash?
[18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20160913.1-0ubuntu<IP_ADDRESS> => 1:20161011.1-0ubuntu<IP_ADDRESS>] (no packageset)
[18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20160913.1-0ubuntu<IP_ADDRESS> => 1:20161011.1-0ubuntu<IP_ADDRESS>] (no packageset)
[18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20160913.1-0ubuntu<IP_ADDRESS> => 1:20161011.1-0ubuntu<IP_ADDRESS>] (no packageset)
[18:12] <infinity> chrisccoulson: Moi.
[18:12] <chrisccoulson> infinity, ah, thanks. I've just uploaded the rest of them now :)
[18:34] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (yakkety-proposed/main) [3.22.0-1ubuntu1 => 3.22.1-0ubuntu1] (ubuntu-desktop)
[18:35] <slangasek> jbicha: ^^ this impacts images across 4 flavors, for which image spins are supposed to start imminently; why is it uploaded now?
[18:36] <jbicha> slangasek: it can be an SRU right?
[18:37] <slangasek> jbicha: if it meets SRU requirements; ok I see the SRU template in the one bug, thanks
[18:38] <jbicha> it's not needed in the release images
[18:38] <slangasek> jbicha: I'm asking because it's hard to coordinate across all the release team working the queue in parallel, so it's important to have clarity about the target for these uploads
[18:38] <slangasek> ok
[19:00] <flexiondotorg> infinity, Is the release going to be delayed?
[19:01] <infinity> flexiondotorg: I shouldn't think so.
[19:01] <flexiondotorg> OK
[19:01] <flexiondotorg> The rumour mill is speculating. I'll pour water on that.
[19:01] <infinity> flexiondotorg: Rumour mills are special.
[19:02] <flexiondotorg> Indeed.
[19:03] <infinity> flexiondotorg: Perhaps the rumour mill should be harder at work on testing, reporting, and fixing. :P
[19:03] <flexiondotorg> That too.
[19:19] <lunaphyte> thanks everyone for entertaining my questions, etc.
[19:21] <slangasek> does a binary removal of an arch: all package on a specific arch DTRT? :P
[19:22] <infinity> slangasek: no.
[19:22] <slangasek> ok cool
[19:22] <slangasek> so how do we get juju in?
[19:22] <slangasek> I guess I can 'force' it
[19:23] <infinity> No.
[19:24] <slangasek> infinity: I hope you're planning on elaborating / presenting an alternative :)
[19:24] <infinity> I'm looking at the situation first.
[19:24] <slangasek> ok
[19:25] <slangasek> summary from my side: juju dropped 32-bit arch supports, with my sign-off; no transitional packages for this in yakkety because the drop is retroactive to xenial so for 16.10 we just want the packages gone; in the process that means juju is migrating from an (uninstallable) arch: all package to an arch: some package; and britney doesn't want to let it in
[19:25] <infinity> Check, and rmadison confirms.
[19:26] <slangasek> and I guess, from the output, that the arch: all-> arch: some change was made only in the latest release, since previous release was getting autopkgtest results
[19:26] <infinity> Okay, in that case, your propose arch-some removal might work.
[19:26] <slangasek> ok
[19:26] <infinity> The reason I said it doesn't is because all copies in LP are source-based, so binary removals always come back.
[19:26] <slangasek> did that, let's see what happens - thanks
[19:26] <infinity> And, thus, should be avoided.
[19:26] <infinity> (And definitely avoided for arch:all, which is just confusing)
[19:27] <infinity> But as a temp solution, it might DTRT.
[19:27] <infinity> If it doesn't, just remove juju from the release pocket entirely.
[19:27] <infinity> Still beats a force.
[19:32] <infinity> Okay, and juju's not in any metapackages, so don't need a refresh.
[19:32] <infinity> Though after the current things all settle, I'll do a world refresh of meta locally to see if any changes got missed.
[19:37] <pitti> slangasek: I didn't accept it; it seemed a bit dubious/too intrusive to me
[19:37] -queuebot:#ubuntu-release- Unapproved: wine-development (yakkety-proposed/universe) [1.9.19-1ubuntu1 => 1.9.20-1ubuntu1] (no packageset)
[19:37] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (yakkety-proposed) [1.9.20-1ubuntu1]
[19:38] <pitti> infinity: do you want everyone else to stay away from unapproved now?
[19:38] <pitti> or still want me to review the indicator-transfer thing?
[19:38] <pitti> (I have a hunch that's going to be needed for the ubuntu desktops at least, but not blocking all other flavors)
[19:39] <pitti> urgh, a LibO upload?
[19:39] <pitti> dear http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt, pretty please update
[19:39] <infinity> pitti: GO ahead and sort that, please.
[19:40] <pitti> Laney: running these shell scripts is a nice waste of resources too, but hopefully a bit less :)
[19:41] -queuebot:#ubuntu-release- Unapproved: accepted indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2]
[19:42] <pitti> jbicha: do you want that g-s-d on the images? diff looks sane enough to me, but at this point there's little margin for errors
[19:43] <pitti> jbicha: did you test this on real hw with a battery? screen saver works ok?
[19:43] <jbicha> pitti: did you see s_langasek's comment above about it ^
[19:43] <pitti> no, /me reads backscroll
[19:44] <pitti> meh, somehow my firefox/ppc64el removal didn't work?
[19:45] <jbicha> I'd rather g-s-d just be an SRU actually; the bug fixes in it are fairly minor
[19:45] <pitti> ack, they don't seem image-critical, unlike the indicator thing
[19:45] <pitti> (relevant for live image)
[19:46] <pitti> infinity: I guess you should put a propagation block in place now, so that we have more control over this?
[19:46] <infinity> pitti: Yeahp.  Doing that now.
[19:46] <pitti> infinity, slangasek: are you on top of the juju 32 bit removals so that this can land, or want me to?
[19:46] <infinity> pitti: Steve's on the juju case.
[19:46] <pitti> the transitional moved from arch: all to arch: [list]
[19:46] <pitti> ack
[19:47] <pitti> infinity: so I can deal with firefox; 46.x and 47.x are gone, but 48.x ppc binaries still exist
[19:47] <infinity> pitti: The easier way to do that is just to remove source package by version.
[19:47] <infinity> pitti: remove-package -e 48.blah firefox
[19:48] <infinity> pitti: Way simpler than trying to hunt down the mismatched bits.
[19:48] <pitti> infinity: that would entirely remove it from yakkety for a short blip of time, though?
[19:48] <infinity> pitti: Do you care?
[19:48] <pitti> I ran http://paste.ubuntu.com/23309737/ earlier, apparently that didn't work
[19:48] <infinity> If the goal is to get 49 in ASAP.
[19:48] <pitti> ok
[19:49] <pitti> infinity: done
[19:49] <infinity> pitti: I'm more worried about c-m exploding due to this.
[19:49] <pitti> seems a bit awkward to remove "good" binaries temporarily from the release, but indeed, better than screwing it up for another publisher
[19:50] <infinity> pitti: But maybe with archive-reorg, it won't.  The old "if we have no firefox, other browsers get yanked into main" thing *might* have been a build-dep issue.
[19:50] <infinity> Here's hoping.
[19:50] <infinity> I honestly don't recall if it was build-dep or runtime.
[19:50] <infinity> Though, at the very least, we'll need a meta refresh.
[19:51] <infinity> Which is on my TODO in a publisher cycle or three.
[19:51] <pitti> infinity: after it updates, http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt will still have some remaining bits -- e. g. libnuma1 on s390x only
[19:51] <infinity> I'll hold off on the britney block for another cycle or two as well.
[19:51] <pitti> oh wait, libnuma1 will then be in "optional" everywhere
[19:51] <infinity> I thought I had a hint for numa.
[19:51] <pitti> I was going to ask whether it's ok to have a different priority on a particular arch only
[19:52] <pitti> but seems it's the other way round -- it currently differs, this will now make it equal to other arches
[19:52] <infinity> You can't have mismatched priorities on arches, LP doesn't allow it.
[19:52] <infinity> Unless something goofs up.
[19:52] <infinity> Does architecture-mismatches show an issue?
[19:52] <pitti> ah no - libnuma1 is in standard for other arches
[19:53] <pitti> python* and perl* should be gone now -- I figure we need to promote this silly pinentry-curses now
[19:53] <pitti> infinity: wow, I was completely ignorant of http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt
[19:53] <infinity> I'll clean up the mismatches.
[19:53] <infinity> So we don't stomp on each other.
[19:54] <pitti> ack -- i. e. promote unity on arm64?
[19:54] <infinity> And priority stuff as well.
[19:54] <pitti> infinity: wait
[19:55] <pitti> infinity: can you predict what it's going to look like? or were you just going to promote pinentry-curses?
[19:56] <infinity> pitti: I'm fixing libnuma with a hint.  pinentry probably will want to promote.  But also waiting for the perl stuff to fall out.
[19:56] <pitti> libnettle6 might be a transient dep of pinentry
[19:56] <infinity> pitti: numa fix committed.
[19:57] <infinity> And unity8 fixed.
[19:58] <infinity> Finishing my lunch while I way for some archive settle.
[20:02] <tyhicks> Hi
[20:02] <tyhicks> we've just discovered that some confined programs are being denied access to the system bus due to the resolved changes in yakkety
[20:03] <tyhicks> at least tcpdump and ntpd are affected
[20:03] <pitti> that sounds SRUable?
[20:03] <tyhicks> nss seems to be falling back to do traditional name lookups whenever apparmor denies access to the bus but I don't know if that's acceptable
[20:03] <tyhicks> pitti: you would know best if the fallback is "safe" ^
[20:04] <pitti> tyhicks: NSS in general does work; you mean for apparmor profiles of programs where NSS doesn't work?
[20:04] <pitti> tyhicks: it's "safe" in yakkety as we disabled DNSSEC (and thus enforcement), so ATM falling back to "dns" is only a convenience/longer timeout/no caching issue
[20:05] <pitti> tyhicks: and desktops use dnsmasq anyway (again), not resolved
[20:05] <tyhicks> pitti: ok, so it sounds like we can fix this in an SRU
[20:05] <pitti> tyhicks: so you mean tcpdump/ntpd do lookups via NSS and are being denied D-Bus access?
[20:05] <tyhicks> pitti: correct
[20:05] <pitti> ok
[20:06] <sarnold> .. and everything else that aa-status reports as confined
[20:06] <pitti> tyhicks: i_nfinity installed a propagation block now, so we should actaully be able to start SRU uploads now
[20:07] <pitti> or rather, "soon" (block not yet active)
[20:07] <tyhicks> pitti: do I need to explicitly upload to yakkety-updates or will they be automatically routed to -updates?
[20:07] <pitti> tyhicks: no, *don't* upload to -updates, we need to reject this (and make sure we actually spot it)
[20:07] <pitti> tyhicks: continue to upload to yakkety or yakkety-proposed
[20:08] <tyhicks> thanks
[20:08] <pitti> tyhicks: -proposed is the same for devel and SRUs, just the propagation changes from -release to -updates
[20:08] <tyhicks> ack
[20:08] <pitti> so, uploading is fine at all times, but I can only review it after we get a release block
[20:11] <infinity> pitti: Yeah, the block will be in a couple of cycles, I don't want to block just to unblock everything in there right now.
[20:13]  * pitti waves good night
[20:15] -queuebot:#ubuntu-release- Unapproved: strongswan (trusty-proposed/main) [5.1.2-0ubuntu2.4 => 5.1.2-0ubuntu2.5] (no packageset)
[20:17] -queuebot:#ubuntu-release- Unapproved: multipath-tools (trusty-proposed/main) [0.4.9-3ubuntu7.14 => 0.4.9-3ubuntu7.15] (core)
[20:17] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90 => 0.90ubuntu0.1] (desktop-core, ubuntu-server)
[20:32] <brendand> who do i need to nudge to get cloud-init moving along from -proposed (in xenial)?
[20:32] -queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (yakkety-proposed/multiverse) [<IP_ADDRESS>5ubuntu1 => <IP_ADDRESS>7ubuntu1] (no packageset)
[20:34] -queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (yakkety-proposed) [<IP_ADDRESS>7ubuntu1]
[20:35] -queuebot:#ubuntu-release- Unapproved: icinga (xenial-proposed/universe) [1.13.3-2 => 1.13.3-2ubuntu0.1] (no packageset)
[20:35] <wxl> we having a respin at some point?
[20:36] <valorie> I heard "More than an hour, less than several"
[20:36] <wxl> jj
[20:36] <wxl> er
[20:36] <wxl> s/j/k/g
[20:36] <valorie> lol
[20:42] <brendand> infinity, any chance of nudging the cloud-init (xenial) sru along? bugs are verified, it's aged a week, and it's hurting us badly. understand if you're busy though
[20:47] <slangasek> valorie, wxl: right, and that was 3 hours ago
[20:47] <slangasek> infinity: what's the long pole now?
[20:48] <acheronuk> waiting until migration blocks are in place so I thought I read?
[20:52] <infinity> slangasek: Waiting on firefox migration, at least.
[20:53] <infinity> Less convinced about what to do with thunderbird.
[20:53] <infinity> Oh, but it looks like it's built/failed everywhere it's going to.
[20:53] <infinity> So maybe we can nudge that along too.
[20:55] <infinity> But yeah, probably time for the block and unblocks.
[20:55] <infinity> Doing that now.
[20:56]  * valorie sends a thousand {{{{{{{{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}}}}}}}}}}} to the release team
[20:56] <infinity> I only deal in pie.
[20:57]  * valorie adds pie
[20:57] <valorie> and beer
[20:58] <valorie> and whisky for those who want it
[20:58]  * wxl wants maté
[20:58] <valorie> some nice cider for those who don't
[20:58] <cjwatson> infinity: priorities> LP allows it, we just try to avoid it because it's a pain to keep track of.  Maybe you're thinking of dak.
[20:59] <infinity> cjwatson: Perhaps.
[20:59] <acheronuk> valorie: I suspect strong coffee is also required
[20:59] <infinity> cjwatson: The archive doesn't allow it, then. :P
[21:00] <valorie> I'm willing to bet the team has laid in stores of coffee AND tea
[21:09] <dannf> infinity: i'm not sure how to report this via the QA tracker (is that setup yet?), but arm64 ISOs need a fix - LP: #1632473
[21:14] <infinity> dannf: Is this already correct in the mini.iso?
[21:15] <infinity> dannf: Cause I see no mention of gzio in d-i...
[21:17] <dannf> infinity: checking
[21:17] <dannf> infinity: mini iso boots - seeing if i can figure out why - side-effect perhaps?
[21:18] <infinity> Side effect of what? :P
[21:18] <dannf> some other preloaded module perhaps
[21:21] <infinity> The grub.cfg on mini.iso is pretty sparse.
[21:21] <dannf> hrm.. w/ debug=all, i don't see gzio ever load.
[21:24] <dannf> infinity: ah - looks like the kernel on the iso is a gzip'd file w/ no UEFI stub
[21:24] <dannf> whereas on the mini.iso, it's a gzip's kernel w/ a UEFI stub prefix like it should be
[21:26] <infinity> *raise brow*
[21:27] <infinity> That seems suboptimal.
[21:28] <infinity> So, I get vmlinuz straight out of d-i.
[21:28] <infinity> Why are you giving me two different kernels? :P
[21:30] <dannf> indeed...
[21:34] <dannf> oh - i'm not. i was just apparently testing the wrong mini.iso! egg/face
[21:34] <infinity> Ahh, so d-i is also broken?  That's less confusing.
[21:35] <dannf> yes. fixing.
[21:35] <infinity> Right, do some test runs there to get something that works, and I can mirror it in debian-cd, if it's not just carried over in cd-info.tar.gz.
[21:36] <infinity> dannf: A little late for grub uploads now, but I'd suggest that, perhaps, if gzio is required for arm64 now, it should probably be built-in. :P
[21:37] <infinity> (I assume it is for x86?)
[21:37] <infinity> Oh, hrm.  Won't this also break the installed system on reboot?
[21:38] <infinity> Oh, no, looks like the installed grub.cfg has gzio just in case.
[21:59] <dannf> yeah - i've been booting compressed kernels for a while  on EFI systems w/ no problem
[22:15] <cyphermox> dannf: infinity: it's already builtin to the EFI images
[22:19] <dannf> infinity, cyphermox : https://code.launchpad.net/~dannf/debian-installer/lp1632473/+merge/308199
[22:20] <infinity> dannf: Please commit, tag, and upload.
[22:20] <dannf> infinity: ack
[22:29] -queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu482 => 20101020ubuntu483] (core)
[22:35] <flexiondotorg> infinity, Just trying to organise some final MATE testing.
[22:35] <flexiondotorg> Is a world respin planned?
[22:36] <wxl> supposedly incoming soon flexiondotorg
[22:36] <flexiondotorg> wxl For world?
[22:37] <sarnold> flexiondotorg: perhaps define what you mean by "world respin"
[22:37] <flexiondotorg> All the flavours.
[22:37] <flexiondotorg> Having images recreated.
[22:41] <slangasek> the world is constantly spinning, no "re" required
[22:41] <slangasek> yes, all flavors need an updated image
[22:41] <slangasek> stokachu, balloons, cyphermox: so, juju-core autopkgtest failure on ppc64el due to manual provider? expected?
[22:43] <cyphermox> I hear it's expected, but needs to be fixed?
[22:44] <cyphermox> slangasek: also, what do you mean, the world is spinning? isn't it constantly accelerating upwards at 9.8m/s^2?
[22:56] <slangasek> cyphermox: what does "needs to be fixed" mean here?  Should I expect a new fixed package before release?
[22:57] <cyphermox> slangasek: we discussed changes to this test this morning, but I don't know if you should be expecting a fixed package now
[22:57] <cyphermox> balloons: ^
[22:59] -queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.1 => 3.168.2] (ubuntu-desktop, ubuntu-server)
[23:22]  * tsimonq2 buys the release team a virtual cup of coffee and/or Red Bull for whoever wants it
[23:55] <cyphermox> tsimonq2: good plan. I took a short video games break ... and it ended in a game over :(, but now coffee seems in order
[23:55] <tsimonq2> cyphermox: cheers :)


[04:55] <poolie_> hi
[04:56] <poolie_> i'm thinking about buying an X61 or D430, any opinions on either of them?


[04:46] <pleia2> nhandler: do you have login access to the editor gmail account? I'm sharing the doc with people who care to be emailed each weekend when we're ready for summaries
[05:21] <alourie> hello
[05:21] <alourie> pleia2: I would also care to be emailed for that :-)
[05:21] <alourie> although I can do it only on Sundays...
[05:23] <pleia2> alourie: ok cool, what's your address?
[05:23] <pleia2> we'll also mention it in here 40 times :)
[05:26] <alourie> pleia2<EMAIL_ADDRESS>[05:26] <alourie> mention it as much as you like (just imagine I get a penny for every time you do :-) )
[05:27] <pleia2> hehe
[05:28] <pleia2> ok, you're added
[05:28] <alourie> cool
[08:32] <NRWlion> good morning folks!
[10:34] <NRWlion> hi there
[12:41] <NRWlion> hi
[14:48] <nhandler> pleia2: Yeah, I have the login info somewhere. Do you need it?
[16:09] <pleia2> nhandler: no, was just making sure you had access to the doc I shared with that account (but I shared it directly with you too)
[16:12] <nhandler> pleia2: Yeah, I got it. Thanks a lot for putting that together. Also, I am going to be on vacation from tomorrow morning until Tuesday night. Do we have someone to publish UWN monday?
[16:13] <pleia2> I can probably do it, will be an interesting test of whatever we're missing docs-wise
[16:14] <nhandler> pleia2: Thanks a lot. If you get a chance, take a quick look over the checklist and scripts, and let me know if you have any questions.
[16:15] <pleia2> will do
[18:31] <NRWlion> Evening from Germany
[21:34] <NRWlion> hey philipballew
[21:34] <philipballew> hey NRWlion
[21:35] <NRWlion> guess we havent had the pleasure yet, am I right?
[21:37] <philipballew> NRWlion, we have not.
[21:37] <philipballew> you are right
[21:39] <NRWlion> philipballew: well then ;) I am from germany (and thought i might be helpful but havent found the right place for myself in the team ;) )
[21:40] <philipballew> what are you looking to do?
[21:40] <NRWlion> philipballew: first of all getting much more knowledge about the tech side of ubuntu
[21:40] <NRWlion> as i am mostly running mint on my system
[21:41] <philipballew> why mint?
[21:41] <NRWlion> was the only system that worked on my 2001 hardware
[21:42] <philipballew> well I would think ubuntu would if mint did
[21:42] <philipballew> and probably puppy to
[21:42] <NRWlion> https://wiki.ubuntu.com/nrwlion-upgrade
[21:43] <philipballew> seemes intence
[21:43] <NRWlion> sorry?
[21:47] <philipballew> the install, seemes like it was having problems NRWlion
[21:48] <NRWlion> philipballew: it HAD ;)
[21:49] <NRWlion> so i was lucky to get mint running cause working on a 10 inch screen for nearly 18 hrs at the weekend wasnt nice :(
[21:49] <philipballew> so what brings you to the ubuntu-news? I am new to this channel for the past week
[21:51] <NRWlion> philipballew: i thought with my experience of nearly 8 years working on real life journalism i would be an asset but i was proofen wrong so i try to help where ever i could and absorb as much as intel as possible
[21:51] <philipballew> that never hurts. you did real life for what?
[21:53] <NRWlion> i did several years as reporter for icehockey in local papers and afterwards more than 3 years in local radio stations hosting a cinema show and other stuff
[21:55] <philipballew> nice! never seen a real hockey match
[21:55] <philipballew> probably hard to report on
[21:55] <NRWlion> ;)
[21:56] <NRWlion> not if you write your stuff afterwards or simply phone in the details after the match
[21:56] <NRWlion> but i godda go now
[21:56] <nhandler> pleia2: Think you are good for UWN?
[21:56] <NRWlion> night is over about 5 hrs
[21:56] <NRWlion> nhandler: i am not there on Sat this time
[21:56] <pleia2> nhandler: when I haven't been working today I've been at an Ubuntu Women meeting, no time to look so far :(
[21:57] <nhandler> NRWlion: Neither am I
[21:57] <nhandler> pleia2: Alright, no problem
[21:58] <NRWlion> ok folks. godda run for my pillows. gn8!
[21:58] <nhandler> Night NRWlion
[22:04] <philipballew> that NWRlion seemed nice


[06:16] <ducasse> good morning
[06:17] <lordievader> Good morning
[06:21] <mesaboogie> morning
[11:22] <lotuspsychje> https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-20.10-Restrict-dmesg
[15:08] <asdfgh> hello
[15:09] <asdfgh> are the softwares installed via the default software-tool of ubuntu 20.04 coming from SNAP?
[15:09] <lotuspsychje> asdfgh: its the users choice nowadays to install from apt or snaps
[15:09] <asdfgh> lotuspsychje, sure ok, but as i wrote i did not install it via snap
[15:09] <asdfgh> just via the default ubuntu software tool
[15:09] <asdfgh> are those packages coming from snap ?
[15:09] <lotuspsychje> asdfgh: before you install the software, you can check at bottom: snap-store
[15:10] <lotuspsychje> asdfgh: 20.04 uses the snap store by default, that does mean yes it holds also snaps by default too
[15:10] <asdfgh> lotuspsychje, at bootm where exactly?
[15:10] <asdfgh> i did not find snap-stopre
[15:11] <asdfgh> or really? i thought we were moving forward to Flatpak
[15:11] <asdfgh> so canonical is going to replace apt in the next relases?
[15:11] <lotuspsychje> asdfgh: source: snapcraft.io
[15:12] <asdfgh> interesting...yes but why this? i mean...we are moving to snap 100% in the next releases?
[15:12] <asdfgh> i heard about flatpak too, because snap is ubuntu-centric
[15:13] <asdfgh> no true?
[15:13] <lotuspsychje> asdfgh: no decision yet like that for the future
[15:13] <lotuspsychje> but the snaps are growing...
[15:13] <asdfgh> lotuspsychje, ok so where i can exactly select snap store from the software tool
[15:14] <lotuspsychje> asdfgh: ubuntu-software is the snap store on 20.04, it just colors orange like the old ubuntu software centre
[15:15] <asdfgh> ooh ok
[15:15] <lotuspsychje> asdfgh: df -h
[15:18] <lotuspsychje> asdfgh: you see snap-store? under /dev/loop ?
[15:19] <asdfgh> oh yes
[15:19] <asdfgh> lotuspsychje, yes
[15:30] <jnewsome> Hi, I'm working on a research project and am trying to compile the "glibc-source" package. Closest docs I could find are for compiling "source packages" but this seems to be a slightly different beast
[15:31] <Ussat> Personally, I rip snap* out of every server install
[15:31] <jnewsome> It's not a "source package" for glibc, but a regular package that happens to contain the glibc sources + patches
[15:32] <Ussat> IMHO snaps that decide when to update themselvs outside of my controll have no place in an enterprise server
[15:32] <jnewsome> it's not clear how to use the contents to configure + compile the glibc source in a way consistent with the system's glibc
[15:33] <Ussat> and TBH if that gets to the point whee I cant, I wont use Ubuntu
[15:33] <jnewsome> (I tried #ubuntu first; they suggested I try here)
[15:33] <daftykins> strange since it sounds like a support query
[15:50] <lotuspsychje> i suggested jnewsome he discuss here as we dont really support own compiles
[15:50] <lotuspsychje> but oh well, ioria is already helping
[15:52] <daftykins> oh i knew it was you ;)
[15:54] <lotuspsychje> lol
[15:54] <lotuspsychje> its a real user this time daftykins :p
[16:06] <lotuspsychje> Ussat: lxd was default snap on -server now right?


[06:05] <didrocks> good morning
[06:08] <oSoMoN> good morning desktoppers
[06:14] <didrocks> salut oSoMoN
[06:19] <oSoMoN> salut didrocks
[06:27] <seb128> gooood morning desktopers
[06:31] <didrocks> salut seb128
[06:35] <seb128> lut didrocks, en forme ?
[06:37] <oSoMoN> salut seb128
[06:39] <seb128> lut oSoMoN, en forme ?
[06:40] <didrocks> seb128: ça va, et toi ?
[06:40] <seb128> didrocks, ça va bien !
[06:44] <pieq> c'est la French connection tous les matins, ici :)
[06:45] <seb128> oui :-)
[06:50] <pieq> jamesh, hey, it's ePierre from the snapcraft forum :) Thanks for your answers regarding access to /var/lib, very much appreciated!
[06:51] <jamesh> pieq: hi
[06:51] <jamesh> no problem
[06:54] <jibel> hi all
[06:56] <duflu> Morning didrocks, oSoMoN and jibel
[06:56] <duflu> Afternoon jamesh
[06:57] <jamesh> hi duflu
[07:00] <pieq> didrocks, I opened an issue regarding the snap recipe for ubuntu-report: https://github.com/ubuntu/ubuntu-report/issues/28 ; jamesh has provided an answer that works for me, so if you ever decide to push the snap version instead of the deb, you may want to remember this :)
[07:00] <pieq> salut jibel
[07:02] <jibel> salut pieq
[07:02] <jibel> ça va?
[07:07] <oSoMoN> morning duflu
[07:07] <oSoMoN> hey jamesh
[07:07] <oSoMoN> salut jibel, pieq
[07:20] <didrocks> hey duflu
[07:21] <didrocks> pieq: oh nice, thx! Will have a look, as long as it supports completion and so on, that's great!
[07:21] <didrocks> pieq: do not hesitate to PR so that I can rereview it
[07:21] <pieq> jibel, oui ça va et toi ? It's been raining a lot in Taipei these last few days, which is bad (especially to walk the dog) but also good (the temperature is finally livable!)
[07:22] <pieq> didrocks, oh ok! I would have to find a way that works on both debian and snaps though. So far I've only tried jamesh 's trick on my own snap which uses --devmode (cause I'm lazy and all)
[07:23] <didrocks> yeah, reading that, this is why we couldn't snap it
[07:23] <didrocks> there was first an issue with core18, you couldn't build it against
[07:23] <didrocks> and then, confinement, classic isn't an option and there is no interface for this
[07:29] <pieq> didrocks, why isn't classic an option? is ubuntu-report supposed to work even on Ubuntu Core?
[07:31] <didrocks> pieq: I got some informal discussion with the snap team and the classic confinement would be nacked apparently, they prefer someone to take the time to develop proper interface
[07:34] <pieq> interesting!
[07:59] <willcooke> morning all
[07:59] <duflu> Morning willcooke
[08:00] <marcustomlinson> morning
[08:00] <duflu> Morning marcustomlinson
[08:00]  * marcustomlinson is feeling bleh this morning :/
[08:01] <duflu> :{
[08:01] <marcustomlinson> picking up some cold/flu thing since yesterday
[08:01] <willcooke> hi duflu
[08:01] <willcooke> bad luck marcustomlinson.  Don't solider on if you're ill
[08:01] <marcustomlinson> morning willcooke
[08:01] <marcustomlinson> I'll see how it goes
[08:02] <Laney> \o
[08:02] <Laney> o/
[08:02] <marcustomlinson> \o/
[08:02] <duflu> o/
[08:03] <marcustomlinson> could someone with upload rights please trigger this for me? could someone with upload rights trigger this for me pretty please: https://autopkgtest.ubuntu.com/request.cgi?release=eoan&arch=s390x&package=libreoffice&ppa=marcustomlinson/libreoffice&trigger=libreoffice/1:6.2.4-0ubuntu2~ppa1
[08:03] <marcustomlinson> whoops how did that happen ?? 🤔
[08:04] <marcustomlinson> message seemed to disappear so retyped it
[08:06] <oSoMoN> marcustomlinson, done
[08:06] <oSoMoN> and good morning!
[08:06] <willcooke> hi Laney. oSoMoN
[08:06] <marcustomlinson> thanks oSoMoN :) and good morning to you
[08:07] <oSoMoN> and good morning willcooke & Laney
[08:12] <seb128> hey again desktopers
[08:12] <willcooke> morning seb128
[08:12] <seb128> (laptop suspended/irc disconnected during morning erands)
[08:12] <seb128> hey willcooke, how are you?
[08:12] <willcooke> keeping dry :)
[08:12] <seb128> improvement!
[08:13] <Nafallo> o/
[08:13] <willcooke> hi Nafallo
[08:14] <oSoMoN> hey Nafallo
[08:14] <Laney> hi marcustomlinson duflu oSoMoN willcooke seb128
[08:15] <duflu> Morning seb128
[08:15] <marcustomlinson> mornign seb128 and Nafallo
[08:15] <duflu> and Nafallo
[08:17] <Laney> & Nafallo !
[08:17] <seb128> hey Laney duflu marcustomlinson
[08:18] <Nafallo> someone sitting on good documenation about creating udebs? ;-)
[08:22] <Nafallo> otherwise I'll just base it on flash-kernel and try to figure it out :-D
[08:22] <seb128> Nafallo, https://d-i.debian.org/doc/internals/ch03.html#idm459 ?
[08:26] <Nafallo> thanks seb128 :-D
[08:28] <Nafallo> that gives an additional primer indeed
[09:36] <duflu> seb128, if using the "June - Started" column, do we still use "In Review", or just keep it "Started"?
[09:36] <seb128> duflu, keep it "started" for now, we can adjust the workflow later if needed
[09:37] <seb128> duflu, if we move it out of the june columns we loose visiblity on the fact that it was targetted for this month
[09:37] <duflu> Yes
[09:37] <seb128> we could create a "june - in review" if needed, but I'm not sure the column is big enough that it's required so let's try without it this month
[09:38] <seb128> and do a round of feedback at the end of the month
[09:40] <duflu> seb128, should we rename "In Progress" to "Long Term - Started" ?
[09:41] <duflu> Otherwise people might think "In Progress" represents everything in progress
[09:41] <seb128> duflu, hum, good point. I renamed it to "non targetted work -  started"
[09:42] <duflu> Cool
[09:42] <seb128> duflu, are you the one moving proposed/backlog on the top left?
[09:43] <duflu> seb128, yeah just getting a feel for the ordering/appearance. I am done now so feel free to change it
[09:43] <seb128> k
[09:43] <seb128> let's keep the june one on the left for the month
[09:43] <seb128> I plan to do a round of feedback/comment after that iteration
[09:44] <seb128> but I think the ones on the left are the most visible ones, and what we want to see/focus on/be reminded of is the current priority work
[09:44] <seb128> not the endless list of backlog items that is sitting on the board
[09:44] <duflu> That makes sense. I was just wondering if it made more sense to order the columns chronologically
[09:46] <duflu> seb128, I suspect you will want to pick that vmwgfx regression bug out of proposed ;)
[09:48] <seb128> duflu, urg, indeed, SRU regressions in the LTS are not good :-/
[09:48] <seb128> Trevinho, ^ https://trello.com/c/gn0J5Qgb/169-bug1832138-login-screen-never-appears-on-vmwgfx-but-setting-waylandenablefalse-fixes-it-bionic-updates-regression
[10:29] <Trevinho> seb128: I'm actually affected by that in a VM I've and while looking at it since long time, I've never understood what's the problem, but indeed isn't a crash. But something in the very low level
[10:29] <Trevinho> mutter starts and everything, the problem seems to be more related to the drv
[10:36] <duflu> Trevinho, yes that's also the part of mutter I changed in the latest update
[10:37] <duflu> Also...
[10:37] <duflu> Good morning Trevinho
[10:37] <duflu> Good night all
[11:31] <seb128> Trevinho, hey. Duflu said that bug started happening following a SRU in bionic, that might tell us what change is triggering the issue and give more clues about the problem?
[11:53] <GunnarHj> Hi seb128, do you have time to sponsor the SRU-MP at bug #1831144? (Patch picked from upstream.)
[11:55] <seb128> GunnarHj, I add it to the backlog
[11:55] <GunnarHj> seb128: Ok.
[12:35] <Trevinho> seb128: mh, I can look at see if I can get to a point where I start from a bionic VM, dist-upgrade for each upgrade
[12:35] <Trevinho> but look a bit complicated to track this way
[12:36] <seb128> Trevinho, check with Daniel first tomorrow maybe? he perhaps started poking to find the commit?
[12:37] <Trevinho> mh ok
[12:37] <Trevinho> the annoying thing is that with vmplayer I can't either create snapshotts without copying the disk making such process a bit more annoying
[12:56] <jibel> boot the disk image with qemu?
[13:11] <oSoMoN> https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179
[13:24] <seb128> oSoMoN, great, which reminds me we said we wanted a discuss about disk space
[13:25] <oSoMoN> seb128, yes, I implemented a check that won't attempt to import an existing profile if there isn't enough space on disk
[13:26] <oSoMoN> seb128, https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=41c779916fcfda62080f346d118e6cc8acab436c
[13:26] <oSoMoN> happy to discuss further and to refine, of course
[13:28] <seb128> oSoMoN, oh, nice, well done :)
[13:33] <seb128> oSoMoN, "when running the snap for the first time, an existing chromium user profile in $HOME/.config/chromium will be imported"
[13:33] <seb128> oSoMoN, maybe add a "unless there is enough disk space available on disk"?
[13:33] <seb128> isn't*
[13:33] <seb128> -on disk
[13:45] <oSoMoN> seb128, done
[13:47] <tkamppeter> seb128, the n-m autopkgtest got solved, when I looked after it last week the fix was doine, probably by the person who uploaded the changed n-m in the first place.
[13:48] <seb128> oSoMoN, thx
[13:48] <seb128> tkamppeter, oh? can you give details?
[13:49] <Laney> http://autopkgtest.ubuntu.com/packages/n/network-manager/eoan/amd64
[13:49] <Laney> doesn't look solved to me
[13:58] <seb128> tkamppeter, ^ also there doesn't seem to have been an upload to port away from the missing bindings so unsure how it could have been resolved?
[13:58] <seb128> kenvandine, tkamppeter, that's probably sometime that we should deal with on higher priority, we have been sitting on that for over a week
[13:59] <kenvandine> agreed
[14:00] <kenvandine> tkamppeter: what was the fix?
[14:00] <Laney> cyphermox did some work, and then it was handed over to tkamppeter to finish because it wasn't finished
[14:01] <Laney> https://code.launchpad.net/~network-manager/network-manager/+git/ubuntu/+ref/gir-nm
[14:01] <Laney> possibly tkamppeter was confused and thought that cyphermox was saying it was done
[14:02] <seb128> kenvandine, tkamppeter, https://irclogs.ubuntu.com/2019/06/03/%23ubuntu-desktop.html has the ping/details
[14:05] <seb128> Laney, (thx for the summary / details)
[14:06] <Laney> np
[14:10] <cyphermox> ^ basically, I think the port hangs on the callbacks
[14:11] <cyphermox> not sure, but I haven't really done any meaningful glib in a long while, and much less in python
[14:12] <kenvandine> tkamppeter: look into that ASAP
[14:12] <kenvandine> we need to get this resolved
[17:18] <willcooke> night all.  See you all next week probably (depending on what I do on Friday)
[21:48] <robert_ancell> kenvandine, what migrates snap-store from candidate to stable? Manual?
[21:52] <robert_ancell> And how is the candidate revision (131) greater than the edge revision (122) !?
[21:59] <kenvandine> Edge is dead
[21:59] <kenvandine> robert_ancell: manually promote from candidate
[22:00] <kenvandine> robert_ancell: I have a version built in candidate now that I'll promote tomorrow after some testing
[22:00] <kenvandine> For a USN refresh
[22:01] <robert_ancell> kenvandine, Thanks. the candidate contains the use of the new media API (didn't notice that change was missing in snap-store) so it's the last thing that's blocking the removal of the old screenshot support in snapd (https://github.com/snapcore/snapd/pull/6582)


[02:13] <_mup_> juju/trunk r494 committed by<EMAIL_ADDRESS>[02:13] <_mup_> [trivial] remove setuptools dependencies, switch charm store back to domain, sans default-series use precise
[03:46] <_mup_> juju/relation-hook-context r496 committed by<EMAIL_ADDRESS>[03:46] <_mup_> Make relation id lookup robust
[12:29] <yolanda> hi, good afternoon, i'm trying to deploy a service in a local instance, and i have an error, can you help me'
[12:29] <yolanda> ?
[12:34] <jamespage> yolanda, sure - what are you seeing?
[12:34] <yolanda> i see that error every time
[12:34] <yolanda> LXCError: debootstrap is /usr/sbin/debootstrap
[12:34] <yolanda> mkdir: cannot create directory `/var/lock': File exists
[12:34] <yolanda> failed to execute template 'ubuntu'
[12:35] <yolanda> and then when i try to add a relation i see that error:
[12:35] <yolanda> No matching endpoints
[12:35] <yolanda> 2012-03-23 13:28:32,003 ERROR No matching endpoints
[12:35] <yolanda> jamespage ^
[12:35] <jamespage> yolanda, looks like to different errors
[12:35] <jamespage> what does juju status show you ATM?
[12:35] <jamespage> to/two
[12:36] <yolanda> machines:
[12:36] <yolanda>   0:
[12:36] <yolanda>     dns-name: localhost
[12:36] <yolanda>     instance-id: local
[12:36] <yolanda>     instance-state: running
[12:36] <yolanda>     state: running
[12:36] <yolanda> services:
[12:36] <yolanda>   openerp:
[12:36] <yolanda>     charm: local:oneiric/openerp-1
[12:36] <yolanda>     relations: {}
[12:36] <yolanda>     units:
[12:36] <yolanda>       openerp/0:
[12:36] <yolanda>         machine: 0
[12:36] <yolanda>         public-address: null
[12:36] <yolanda>         relations: {}
[12:36] <yolanda>         state: pending
[12:37] <yolanda>   postgresql:
[12:37] <yolanda>     charm: local:oneiric/postgresql-15
[12:37] <yolanda>     relations: {}
[12:37] <yolanda>     units:
[12:37] <yolanda>       postgresql/0:
[12:37] <yolanda>         machine: 0
[12:37] <yolanda>         public-address: null
[12:37] <yolanda>         relations: {}
[12:37] <yolanda>         state: pending
[12:37] <yolanda> 2012-03-23 13:36:14,209 INFO 'status' command finished successfully
[12:45] <yolanda> sorry, i got disconnected, jamespage
[12:45] <jamespage> yolanda, I realised (so kept quiet) :-)
[12:45] <yolanda> i pasted you the status of my machines, could you read it?
[12:46] <jamespage> yolanda, yep
[12:46] <yolanda> ok
[12:46]  * jamespage looks
[12:46] <yolanda> let me pastebin the full error
[12:46] <jamespage> yolanda, is that the official postgresql charm?
[12:46] <yolanda> jamespage, yes, i grabbed with charm getall
[12:47] <yolanda> the openerp is a new one i'm building
[12:47] <jamespage> yolanda, and can you pastebin the metadata.yaml file for openerp as well please
[12:48] <yolanda> that is the error: https://pastebin.canonical.com/62911/
[12:49] <yolanda> and that the metadata from openerp: https://pastebin.canonical.com/62912/
[12:50] <jamespage> yolanda, so the reason for the No matching endpoints message is that the interfaces have different names
[12:50] <jamespage> openerp - interface: postgresql
[12:50] <jamespage> postgresql - interface: pgsql
[12:51] <yolanda> oh
[12:51] <yolanda> first charm, so a newbie error :)
[12:51] <yolanda> and the /var/lock problem?
[12:51] <jamespage> yolanda, looking now - which version of ubuntu are you developing on?
[12:51] <yolanda> oneiric
[12:52] <yolanda> i used a local instance because openstack was giving error
[12:52] <yolanda> i would desired to use precise, but i can't at the moment
[12:54] <yolanda> also, i changed dependency to pgsql but still have the endpoints error
[13:06] <yolanda> jamespage ?
[13:07] <jamespage> yolanda, have you upgraded the charm in you local test deployment?
[13:07] <yolanda> jamespage, a just did a getall
[13:07] <yolanda> do i need to do something else?
[13:08] <yolanda> mm, i destroyed environment and created one new, sorry, didn't understand the question
[13:08] <jamespage> yolanda, yes but if you change metadata.yaml for openerp you need to upgrade the charm that juju is using
[13:08] <yolanda> so just destroyed and created new one, so data is fresh
[13:08] <jamespage> juju upgrade-charm --repository . local:openerp
[13:08] <jamespage> OK - so that should be OK
[13:11] <yolanda> i'm trying again
[13:11] <jamespage> yolanda, have you seen this charm thats being worked on - http://charms.kapilt.com/~patrick-hetu/oneiric/openerp-server
[13:13] <yolanda> jamespage, no , didn't see it
[13:13] <jamespage> quite new still - might be worth collaborating
[13:14] <yolanda> jamespage, the thing is that we use a package that we are building inside canonical
[13:14] <yolanda> i should ask for permission in the team
[13:14] <jamespage> yolanda, fair enough - that charm uses packages from a PPA for openerp
[13:15] <jamespage> its version 6 - is that up-to-date
[13:15] <yolanda> 6.1
[13:15]  * jamespage knows nothing about OpenERP
[13:15] <yolanda> it's our version
[13:15] <yolanda> mm, it's different
[13:15] <yolanda> 6.1 works very different than 6.0
[13:16] <yolanda> but i see the relation between openerp and postgres, with db and db-admin, i'll try like that
[13:18] <jamespage> yolanda, sorry - X died on me
[13:19] <yolanda> i was saying that 6.1 it's very different from 6.0
[13:19] <yolanda> no need for server and web, it comes together
[13:19] <yolanda> i'm checking his metadata however, because that is the same
[13:20] <yolanda> jamespage, the requires is the same, but i have this endpoint error, can something be wrong in my environment?
[13:23] <jamespage> yolanda, thinking
[13:24] <jamespage> might be worth checking the metadata.yaml in the postgresql charm you have locally
[13:24] <jamespage> it should provide db:
[13:24] <jamespage> interface: pgsql
[13:24] <yolanda> yes, i checked
[13:24] <jamespage> ack
[13:24] <yolanda> it is
[13:24] <yolanda> name: postgresql
[13:24] <yolanda> summary: "object-relational SQL database (supported version)"
[13:24] <yolanda> description: |
[13:24] <yolanda>   PostgreSQL is a fully featured object-relational database management
[13:24] <yolanda>   system.  It supports a large part of the SQL standard and is designed
[13:24] <yolanda>   to be extensible by users in many aspects.  Some of the features are:
[13:24] <yolanda>   ACID transactions, foreign keys, views, sequences, subqueries,
[13:24] <yolanda>   triggers, user-defined types and functions, outer joins, multiversion
[13:24] <yolanda>   concurrency control.  Graphical user interfaces and bindings for many
[13:24] <yolanda>   programming languages are available as well.
[13:24] <yolanda> provides:
[13:24] <yolanda>   db:
[13:24] <yolanda>     interface: pgsql
[13:24] <yolanda>   db-admin:
[13:25] <yolanda>     interface: pgsql
[13:33] <jamespage> yolanda, I need to just finish off some testing - can you put you openerp charm somewhere I can see it and I'll try to reproduce
[13:33] <yolanda> ok
[13:37] <yolanda> jamespage, do you have access here? https://code.launchpad.net/~yolanda.robla/charms/oneiric/openerp/trunk
[13:37] <jamespage> yolanda, yep - can see that
[13:38] <yolanda> i wanted to target precise platform, and the openerp package in the repo is for precise, can it be causing a problem? i don't have any precise machine to test
[13:41] <jcastro> m_3, SpamapS, marcoceppi: let's have a call late in the afternoon before I close the contest.
[14:20] <marcoceppi> jcastro: sounds good, it's going to be an easy day for me at work
[14:24] <marcoceppi> jcastro: I'll try to find a decent microphone
[14:24] <jcastro> I think Dr. Mims is travelling today
[14:25] <jcastro> so it'll just be us three, I figure close the contest around EOD and then we have all next week to review
[14:27] <jaaap> wondering how i commit my first juju charm… followed the instructions and failed to run bzr push lp:~4-ja-d/charms/oneiric/appflower/trunk and get bzr: ERROR: Invalid url supplied to transport: "lp:~4-ja-d/charms/oneiric/appflower/trunk": No such source package appflower.
[14:28] <jaaap> first time using bzr and launchpad
[14:46] <eb914> I'm trying to install juju with orchestra but it doesn't work...
[14:46] <eb914> error: Environments configuration error: /home/localadmin/.juju/environments.yaml: environments.orchestra.default-series: required value not found
[15:04] <jaaap> Got it.. committed my first charm. Thanks for the great work of making juju.. this will bring a bright future, i'm sure
[15:08] <yolanda> jamespage, did you see something strange in my charm?
[15:16] <SpamapS> eb914: that means what it says, you are missing default-series
[15:16] <SpamapS> eb914: are you following any specific documentation?
[15:29] <marrusl> jcastro++  o/
[15:29] <jcastro> SpamapS, hey, so marrusl and folks want an on the fly charm school. :)
[15:31] <jcastro> marrusl, he's usually dropping off his kid at school, but he should be around
[15:31] <jcastro> SpamapS, and he's left coast so I don't think 1:30 our time will be a problem
[15:31] <jcastro> ^^ that message meant for marrusl
[15:32] <marrusl> jcastro, hey.  makes sense.  good.  woo hoo, we got the A team!
[15:32] <jcastro> marrusl, I'll be at a doctor's appointment though, but I am confident Clint can hook this up.
[15:41] <_mup_> juju/relation-hook-context r497 committed by<EMAIL_ADDRESS>[15:41] <_mup_> Verify visibility of relation ids from a given hook context
[15:45] <jamespage> yolanda: think I know what the problem is - postgresql has two interfaces of type pgsql
[15:45] <jamespage> db and db-admin
[15:45] <jamespage> you prob need to be explicit
[15:45] <jamespage> juju add-relation openerp:db postgresql:db
[15:46] <jamespage> just testing now
[15:47] <jamespage> (sorry by other testing took a bit longer than expected)
[15:47] <yolanda> jamespage, np
[15:47] <yolanda> btw, i'm going out for a while no
[15:47] <yolanda> now
[15:52] <jamespage> yolanda, OK - so when you get back I think that is the issue - just tested locally
[16:03] <arosales> jcastro: m_3: you guys available for a quick chat with jamespage and I?
[16:06] <arosales> jcastro: m_3: jamespage: I'll reschedule for Monday
[16:14] <antono> hi all
[16:14] <antono> anyone have hudge desktop freezes when juju starts local linux containers?
[16:15] <antono> i cannot even move mouse
[16:17] <be> I'm trying juju, my error is: ERROR Cannot connect to machine MTMzMjUwNzQ3Mi42NTUzNzcyNi41MzQwMjI (perhaps still initializing): Invalid host for SSH forwarding: ssh: Could not resolve hostname oneiric01.ubuntu.lan: Name or service not known
[16:20] <SpamapS> antono: how much RAM do you have?
[16:20] <SpamapS> be: you're using orchestra then?
[16:21] <be> yes
[16:21] <SpamapS> be: you have to be able to resolve the hostnames of the machines from your client
[16:21] <antono> SpamapS: 8GB
[16:21] <SpamapS> antono: I've started 4 containers on a machine w/ 4GB of RAM, so thats not typical
[16:22] <antono> SpamapS: also i have SSD, can it affect lxc behavior?
[16:23] <SpamapS> antono: mine is also an SSD actually.. a 128G macbook air
[16:23] <be> what's the system to resolve it?
[16:23] <SpamapS> be: DNS
[16:24] <SpamapS> be: it should work to put that hostname in your /etc/hosts
[16:31] <be> Thank you I resolved it but now the error is ERROR Cannot connect to machine MTMzMjUwNzQ3Mi42NTUzNzcyNi41MzQwMjI (perhaps still initializing): Invalid SSH key
[16:33] <SpamapS> be: Can you explain to me what documentation you are following ? I have found that some of them miss the finer points
[16:50] <jcastro> SpamapS, the moodle charm needs an early review, he's having a hard time with the db-relation and is kind of stuck, so I just tagged it.
[16:50] <SpamapS> jcastro: mmk, will look at it first
[16:50] <jcastro> <3
[17:00] <be> https://help.ubuntu.com/community/UbuntuCloudInfrastructure
[17:02] <SpamapS> be: ok that one looks like the one I fixed recently
[17:03] <be> ?
[17:04] <SpamapS> be: so its possible that your installation did not go well, because your SSH key did not end up on the installed machine.
[17:05] <be> But I can connect with the client using ssh directly
[17:06] <SpamapS> be: thats odd
[17:07] <SpamapS> be: on the machine, are there juju agents running? (ps auxw | grep juju)
[17:07] <SpamapS> be: also, what version of juju do you have installed? (dpkg -l juju)
[17:09] <be> ps auxw | grep juju                                          ubuntu   15043  0.0  0.1   9252   908 pts/0    S+   18:08   0:00 grep --color=auto juju
[17:09] <SpamapS> be: ok, so most likely something failed when installing or starting up juju
[17:29] <SpamapS> be: so where are you at now?
[17:29] <SpamapS> be: stuck with an ssh key error?
[17:29] <be> juju status 2012-03-23 18:27:19,723 INFO Connecting to environment. 2012-03-23 18:27:20,233 ERROR Connection refused Unhandled error in Deferred: Unhandled Error Traceback (most recent call last): Failure: txzookeeper.client.ConnectionTimeoutException: could not connect before timeout Cannot connect to machine MTMzMjUwNzQ3Mi42NTUzNzcyNi41MzQwMjI (perhaps still initializing): could not connect before timeout after 2 retries 2012-03-23 18:27:4
[17:30] <SpamapS> be: something broke during the cloud-init phase I think. Can you pastebin /var/log/cloud-init-output.log (it might have sensitive information in it, so please make sure it doesn't)
[17:31] <SpamapS> be: there's a useful tool, btw, 'pastebinit', which you can use to just do 'pastebinit < /var/log/cloud-init-output.log'
[17:32] <hazmat> SpamapS, i fixed a problem last night that was causing breakage.. the setuptools stuff from rev 486 was broken. latest fixed build is 494
[17:33] <hazmat> er. good trunk rev
[17:33] <hazmat> i've gone ahead and yanked the setuptools stuff, it was to support osx, but it caused issues for deploying branches
[17:33] <hazmat> ppas/packages should have been okay though
[17:35] <be> sudo pastebinit < /var/log/cloud-init-output.log -bash: /var/log/cloud-init-output.log: No such file or directory
[17:38] <SpamapS> hazmat: right, waiting for the PPA build to succeed and then I will do another upload.
[17:38] <_mup_> Bug #963304 was filed: If bootstrap node is stopped or rebooted in EC2, its address changes and all agents lose track of it <ec2> <juju:New> < https://launchpad.net/bugs/963304 >
[17:51] <_mup_> juju/ftests r14 committed by<EMAIL_ADDRESS>[17:51] <_mup_> Fix after new environments.yaml option names.
[18:27] <_mup_> juju/ftests r15 committed by<EMAIL_ADDRESS>[18:27] <_mup_> Tentative test timeout logic.
[18:41] <_mup_> juju/ftests r16 committed by<EMAIL_ADDRESS>[18:41] <_mup_> Only move .ssh out of the way if not previously done by
[18:41] <_mup_> an interrupted test run.
[18:41] <_mup_> Also do replace ssh-keygen's input by /dev/null, so that
[18:41] <_mup_> it doesn't ask for input ever.
[18:49] <_mup_> Bug #963355 was filed: Agent lifecycle suport for subordinates <juju:In Progress by bcsaller> < https://launchpad.net/bugs/963355 >
[19:41] <_mup_> juju/relation-hook-context r498 committed by<EMAIL_ADDRESS>[19:41] <_mup_> Testing around child relation hook context flushes with parent, and crresponding bug fixes
[20:29] <bkerensa> jcastro: can I pm?
[20:30] <bkerensa> SpamapS: When you suggested "start-stop-daemon --start --oknodo --background --pidfile /run/subway.pid --startas /usr/bin/node -- subway"
[20:30] <bkerensa> which hook did you propose this go into?
[20:30] <bkerensa> the install or just in start?
[20:31] <bkerensa> or if I could do this upstart how would I do that?
[20:34] <bkerensa> or could someone point me to a charm that creates a upstart job so I can gank it
[20:46] <SpamapS> bkerensa: in the start hook.
[20:46] <SpamapS> bkerensa: I thought I recommended how to make an upstart job too
[20:48] <_mup_> juju/relation-hook-context r499 committed by<EMAIL_ADDRESS>[20:48] <_mup_> Verify child relation hook contexts are flushed
[20:50] <bkerensa> SpamapS: I see it now and have Bug #944246 set back for review again
[20:50] <_mup_> Bug #944246: Charm Needed: Subway IRC client/server <new-charm> <Juju Charms Collection:Fix Committed by bkerensa> < https://launchpad.net/bugs/944246 >
[20:51] <SpamapS> bkerensa: awesome, just getting ready to start another round of reviews
[20:51] <bkerensa> :D
[23:18] <SpamapS> bkerensa: subway looking good, just running a few tests. :)
[23:28] <_mup_> Bug #963560 was filed: Possible intermittent failure in juju.agents.tests.test_provision.FirewallManagerTest.test_watch_service_changes_is_called  <juju:New> < https://launchpad.net/bugs/963560 >
[23:40] <_mup_> juju/relation-ids-command r499 committed by<EMAIL_ADDRESS>[23:40] <_mup_> Initial commit
[23:40] <_mup_> juju/relation-ids-command r500 committed by<EMAIL_ADDRESS>[23:40] <_mup_> Merged upstream
[23:50] <SubwayawbuS> :-D
[23:50] <SubwayawbuS> SpamapS: you are the coolest person I've every known
[23:51] <SpamapS> SpamapS: begone, peon!
[23:59] <SpamapS> ring the bell! Subway promulgated


[08:19] <warp10> Hi all guys!
[08:19] <warp10> Is this picture available in higher resolution somehwere? --> http://www.ubuntu.com/sites/www.ubuntu.com/files/active/02_ubuntu/U_business/desktop-release-nov-2011.png


[16:02] <Oscailt> Hello. Anyone here?
[20:28] <czajkowski> cjohnston: ping
[20:39] <cjohnston> pong
[20:40] <czajkowski> cjohnston: have 5 mins for a quick pm ?
[20:41] <cjohnston> yup. no need to ask
[20:42] <czajkowski> sent


[00:18] <sectech> hggdh, Are you still around?
[00:19] <hggdh> I am here
[00:19] <sectech> hggdh,  Could you mark 231986 as triaged... I just got the last of the information required.
[00:20] <hggdh> bug 231986
[00:21] <hggdh> sectech, done.
[00:22] <sectech> hggdh,  Thank you :)
[00:22] <hggdh> welcome. Thanks for the help
[03:58] <nickellery> Can someone set an importance on Bug #232379 please?
[11:48] <Iulian> Hey
[11:48] <james_w> hi Iulian
[11:56] <Iulian> Hello james
[14:01] <pedro_> is kelvin gardiner around?
[15:48] <bddebian> Boo
[16:02] <marnanel> bddebian: Boo
[16:03] <bddebian> Heh, hello marnanel
[16:03] <jjesse> don't cry
[16:12] <Stroganoff> https://bugs.launchpad.net/ubuntu/+source/gst-plugins-ugly0.10/+bug/35112
[16:12] <Stroganoff> thats a nice one
[16:34] <saivann> warp10 : ping
[16:34] <warp10> saivann: pong
[16:35] <saivann> warp10 : Concerning your comment for conglomerate : https://bugs.edge.launchpad.net/ubuntu/+source/afflib/+bug/230350/comments/34
[16:36] <saivann> warp10 : conglomerate in ubuntu as the same debian version, no new upstream version is available in debian and conglomerate seems to build correctly, the patch that I provided was not ok?
[16:36] <saivann> s/as/has
[16:39] <saivann> warp10 : The debdiff is not attached to the bug anymore because you deleted it, but it was just about fixing Maintainer field and adding a new ubuntu version in changelog
[16:39] <warp10> saivann: there is a new debian version, indeed: 0.9.1-3.1. We are at 0.9.1-3ubuntu1 in Ubuntu, hence we can merge (or sync) it and we can fix the bug there.
[16:40] <saivann> warp10 : Oh.. right, I didn't see the ".1", thanks
[16:41] <warp10> saivann: np. If you are going to prepare a merge (or to request a sync, according to the needs), remember to add the tag to autoclose the Maintainer bug too, and I will be happy to upload it for you.
[16:43] <saivann> warp10 : Thank! I will first create a intrepid pbuilder environment and I will continue to work on that bug report. thanks for your work on this!
[16:44] <warp10> saivann: my pleasure ;)
[16:58] <saivann> warp10 : How did you get to have a intrepid pbuilder environment? When I login in my pbuilder with --save-after-login, I'm not able to do a dist-upgrade, debconf-i18n never install correctly.
[16:58] <saivann> dpkg: warning - old pre-removal script returned error exit status 134
[16:59] <saivann> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <=<PHONE_NUMBER>)' failed.
[17:00] <warp10> saivann: no need to login: just upgrade from hardy with a simple "sudo pbuilder update"
[17:03] <saivann> warp10 : pbuilder update only upgrade packages in hardy, but it does not install intrepid repositories. Should I change the /etc/apt/sources.list files before?
[17:04] <warp10> saivann: ops, sorry... I missed the important part :P The right one is: "sudo pbuilder update --distribution intrepid --override-config"
[17:05] <saivann> warp10 : Now that's interesting :)
[17:05] <saivann> Thanks
[17:05] <warp10> saivann: indeed :D
[17:06] <saivann> warp10 : Uh.. still the same problem with debconf-i18n.. That seems to be the postrm script of this package which is not replaced correctly.. I will try to fix this
[17:07] <saivann> warp10 : Is there a way to create a intrepid tgz without having to upgrade from hardy? In my case, pbuilder does not recognize "intrepid" as a distribution when I try to do so
[17:10] <warp10> saivann: you can try "sudo pbuilder create  --distribution intrepid". BTW, upgrade from Hardy worked fine for me
[17:10] <albert23> saivann: you can make a copy of gutsy and name it intrepid in /usr/share/debootstrap/scripts/ (or create a symlink intrepid pointing to gutsy)
[17:13] <saivann> warp10 & albert23 : Thanks, I think that I will be able to do it with these informations
[23:05] <smallfoot-> who has more bug, ubuntu or windows?