=== salem_ is now known as _salem
[01:59] <Bluefoxicy> pissing off everyone on ubuntu-devel-discuss in 3, 2, 1...
[03:22] <mwhudson> heh heh i ran "EB_BUILD_OPTIONS=nocheck sbuild -d yakkety"
=== King_InuYasha is now known as Son_Goku
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Sir_Gallantmon
=== Sir_Gallantmon is now known as Son_Goku
=== vigo is now known as vigo|afk
[06:17] <sakrecoer> jbicha: from upstream, https://github.com/numixproject/numix-gtk-theme/issues/508 :) we just grep'ed all the colors from red to blue :)
[06:19] <jbicha> sakrecoer: oh
[06:22] <pitti> Good morning
[06:25] <sakrecoer> morning! :)
[06:47] <pitti> bdmurray: http://autopkgtest.ubuntu.com/packages/ubuntu-release-upgrader passed again except on armhf
[07:17] <jamespage> doko_, great - thankyou!
[08:12] <LocutusOfBorg> hi, sigh  cp: error writing 'debian/insighttoolkit4-python/usr/lib/python2.7/dist-packages/itk/itkCenteredTransformInitializerPython.py': No space left on device
[08:12] <LocutusOfBorg> ppc64el
[08:13] <LocutusOfBorg> do you think we have machines with more free space?
[08:27] <mwhudson> pitti: autopkgtests are confusing me again, http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#docker.io says "in progress" but it's lying
[08:28] <mwhudson> or at least inconsistent with http://autopkgtest.ubuntu.com/running
[08:32] <pitti> mwhudson: looking
[08:40] <pitti> ERROR:root:http://10.24.0.175:8080/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20160907_055947@/result.tar is damaged, ignoring: "filename 'testpkg-version' not found"
[08:40] <pitti> mwhudson: ah, that's it -- https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20160907_055947@/log.gz
[08:40] <pitti> mwhudson: autopkgtest seems to have trouble with unpacking the source, I'll have a look
[08:41] <mwhudson> pitti: special
[09:02] <pitti> mwhudson: hmm, can't reproduce locally or on infra, and a retry worked; sun rays/temp network failure/fingers in ear/lalala etc.
[09:11] <mwhudson> pitti: ok, so it's run on the real infrastructure now?
[09:16] <pitti> mwhudson: yes, and http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/amd64 has the actual result now
[09:17] <mwhudson> huh lxd does not depend on lxd-client
[09:17] <mwhudson> TIL!
[09:20] <pitti> mwhudson: Restrictions: needs-recommends, or add it explicitly
[09:20] <pitti> mwhudson: indeed, you can have a box which is only a remote lxd server
[09:20] <mwhudson> pitti: yeah, added it explicitly
[09:32] <pitti> PSA: autopkgtest infra will go down for a bit for redeployment; I'll mop up any missed britney tests afterwards
=== hikiko is now known as hikiko|ln
[10:22] <Laney> doko_: do you know if anyone is aware of/looking at the mir ftbfs in yakkety-proposed?
[10:23] <Laney> found https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1619616
[10:23] <ubottu> Launchpad bug 1619616 in protobuf (Ubuntu) "Mir test fails with protobuf3: Protobuf-can-be-reloaded (SEGFAULT)" [High,In progress]
[10:27] <cjwatson> LocutusOfBorg: all builders have identical disk allocation and are started from a fresh image between builds
=== hikiko|ln is now known as hikiko
[10:37] <tseliot> pitti: hi, can you help with LP: #1619306 , please? nvidia is in NEW
[10:37] <ubottu> Launchpad bug 1619306 in ubuntu-drivers-common (Ubuntu) "SRU request: Include the 367 driver in Ubuntu 16.04" [High,In progress] https://launchpad.net/bugs/1619306
[10:40] <pitti> tseliot: not right now (I don't want to stop redeploying our test infra), maybe later
[10:43] <tseliot> pitti: ok, thanks
[10:57] <LocutusOfBorg> cjwatson, it makes no sense then :)
[10:58] <LocutusOfBorg> the previous upload was successful
[10:58] <LocutusOfBorg> and changes are not worth a size change
[10:59] <cjwatson> LocutusOfBorg: ok, can't help with that, but I thought you might find it helpful to know that any exploration of the form "clean up builder" or "use a different builder with more space" is a red herring
[10:59] <LocutusOfBorg> yes, and thanks for that :)
[10:59] <cjwatson> your build may have slightly nondeterministic size
[11:00] <LocutusOfBorg> the question hidden was something like "did anybody reduce the size of the ppc64el builders in the last 10 days"?
[11:01] <LocutusOfBorg> but the answer should be "nobody" and the size is increased from time to time, not reduced
[11:01] <LocutusOfBorg> so, exploring other possibilities
[11:04] <cjwatson> LocutusOfBorg: basically the only way that could happen is if the inter-build reset was quite a while before the build started so that the launchpad-buildd log had grown larger - but that's really quite a negligible amount of space
[11:05] <cjwatson> there are things we could do like running apt-get clean after installing build-deps, but even then the amount of space involved should not be *that* large
[11:05] <cjwatson> there's no cruft build-up over time
[11:05] <LocutusOfBorg> Build needed 08:42:50, 2391164k disc space
[11:05] <LocutusOfBorg> this is from the old build
[11:06] <LocutusOfBorg> I can also remove the debian/tmp after dh_install :)
[11:06] <LocutusOfBorg> 	rm -rf BUILD debian/tmp
[11:06] <LocutusOfBorg> already done :(
[11:09] <LocutusOfBorg> Laney, pretty please can you look at merging gnome-pkg-tools? your "X-AppStream-Ignore=true" can't be merged
[11:11] <Laney> LocutusOfBorg: We dropped that whole script there, so just copy it from the Ubuntu package when merging.
[11:19] <LocutusOfBorg> ok thanks
[11:25] <LocutusOfBorg> so, can I merge Laney? :)
[11:25] <Laney> Sure
[11:26] <LocutusOfBorg> -         python3,
[11:27] <LocutusOfBorg> -         python3-gi,
[11:27] <LocutusOfBorg> -         gir1.2-glib-2.0
[11:27] <LocutusOfBorg> they have been removed from runtime-deps
[11:27] <LocutusOfBorg> readding
[11:28] <Laney> Yes
[11:28] <LocutusOfBorg> according to svn, they are dropped with the pkg-gnome-compat-desktop-file removal
[11:28] <Laney> Basically revert that commit
[11:29] <LocutusOfBorg> yep
=== freyes__ is now known as freyes
[13:08] <pitti> Laney: FYI: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=d1ac20f3c5 and https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure?action=diff&rev2=66&rev1=65
[13:08] <pitti> Laney: this should also reduce worker failure spam now
[13:09] <pitti> Laney: i. e. only the 6-hour maintenance cron job will show the logs of permanently failed workers, not the ones any more which recover quickly (nobody pays attention to them anyway)
[13:12] <semiosis> anyone know whats up with the daily builds of xenial on cloud-images?  latest one is a week old (aug 30)
[13:12] <semiosis> Odd_Bloke: ?
[13:16] <Odd_Bloke> semiosis: I'll ensure that the livecd-rootfs change has been picked up in our build PPA, then kick one off. :)
[13:17] <semiosis> Odd_Bloke: sweet!  thank you
[13:17] <Odd_Bloke> semiosis: (It triggers automatically on changes to packages _in_ the image, which doesn't apply to livecd-rootfs :)
[13:18] <semiosis> Odd_Bloke: that makes sense
[13:55] <Laney> pitti: nice; what else changed with moving to xenial?
[14:07] <pitti> Laney: mostly the upstart → systemd move and moving teh notification mails from the worker upstart job into the maintenance cron script
[14:07] <pitti> Laney: the rest is just gory small details
[14:08] <Laney> nod
[14:08] <Laney> well, good work!
[14:08] <pitti> Laney: but this got rid of this wget | dpkg -i thing and the backport PPA, the workers are easier to stop now (cgroup units et al), and it can now be ported to py3
[14:09]  * Laney is re-jujuing for appstream-generator as well
[14:09] <Laney> tried to look at Mojo again
[14:09] <Laney> *cough*
[14:09] <Laney> also juju 2.0 appears to be fairly different to 1.x
[14:17] <pitti> Laney: yeah, I keep trying 2.0, but earlier it got stuck on deploying, and now this silly 2.1 versioning bug
[14:17] <pitti> Laney: 2.0 appears much nicer locally (it doesn't pull in all that crap on the host, but everything into lxd containers)
[14:21] <Laney> pitti: oh, does it? I didn't get that far due to lxd bug and I wasn't sure if I could use it on wendigo anyway
[14:21] <Laney> like if the charms are going to be compatible
[14:21] <pitti> Laney: charm format hasn't changed much AFAICS
[14:21] <pitti> Laney: but no juju 2.0 on wendigo indeed
[14:21] <pitti> I was just hoping for a nicer "local" experience
[14:21] <Laney> ya
[14:21] <Laney> I'd probably end up using a 2.0 feature by accident
[14:22] <pitti> old juju-local clutters the host and fails with ecryptfs (units need to be manually started after login, etc.)
[14:22] <Laney> might try "juju-deployer" though if I can figure it out
[14:22] <Laney> hopefully make the nagios/bootwhatsitcalled/turku setup easier
[14:23] <Laney> basenode
[14:39] <pitti> Laney: hm, I downgraded to 2.0.4 (that took some time), and now it fails due to
[14:39] <pitti> ERROR failed to bootstrap model: cannot start bootstrap instance: unable to get LXD image for ubuntu-xenial: The requested image couldn't be found.
[14:39] <pitti> Laney: that doesn't ring a bell with you by any chance?
[14:43] <pitti> ah, nevermind -- installed https://launchpad.net/ubuntu/+source/juju-core/2.0~beta17-0ubuntu1.16.10.1/+build/10695313 and that works with lxd 2.1 and also downloads the image
[14:43] <pitti> (that's just stuck due to FTBFS)
[14:45] <Laney> nie
[14:45] <Laney> nice*
[14:45] <Laney> I didn't get that far :)
[14:49] <pitti> Laney: nice, with that "juju bootstrap lxd-test localhost; juju deploy rabbitmq-server" Just Works™
[14:58] <Laney> pitti: Maybe I'll try it again tomorrow or so then
[14:58] <Laney> iterating on canonistack isn't that fun
[15:05] <seb128> Saviq, cyphermox, was there anything else needed on bug #1613678? the hardening was enabled and the buglist seems short enough?
[15:05] <ubottu> bug 1613678 in unity-notifications (Ubuntu) "[MIR] unity-notifications" [Undecided,New] https://launchpad.net/bugs/1613678
[15:08] <Saviq> seb128, not that I know of, wasn't sure how to change the status to get it back in business
[15:41] <cyphermox> seb128: I'd like to re-review to say
[15:42] <seb128> cyphermox, can you do that this week?
[15:43] <cyphermox> I will do that today
[15:44] <seb128> thanks
[15:56] <pitti> Laney: so, nice -- that's the first time juju-2.0 ever worked for me, and now it works without a hitch
[15:56] <pitti> ... except for tab completion which is broken
[15:57] <Laney> pitti: So you're going to use this to develop charms which you'll deploy on 1.25?
[15:58] <pitti> Laney: not sure yet, but I at least wanted to play around with it
[15:58] <pitti> Laney: I need to charm up the langpack-o-matic stuff, I think I'll use it for that
[15:59] <pitti> Laney: and I at least want to make the autopkgtest charms compatible with juju-2.0, as that's the default juju on 16.04 now
[15:59] <pitti> Laney: so I'm more worried about compatibility in that "upward" direction
[15:59] <Laney> pitti: Are there problems in that way?
[15:59] <Laney> too early to tell? :)
[16:00] <pitti> Laney: I hope not -- as I said, I've never gotten j-2 to work until now :)
[16:00]  * pitti → dinner
=== shuduo is now known as shuduo-afk
[16:19] <octoquad> hi, can anybody tell me how I can create a branch for the software-center based off the latest revision for trusty. I don't see any obvious branches to fork from.
[16:21] <rbasak> octoquad: bzr-based UDD is deprecated. Use "pull-lp-source software-center trusty" to grab the latest source (without VCS).
[16:21] <octoquad> rbasak, thanks, it's been a while since I contributed!
[16:23] <octoquad> ls
[16:23] <nacc> rbasak: re: LP: #1579480 and similar bugs, is there a best practice for dealing with 'manually' installed packages that no longer exist in the new release?
[16:23] <ubottu> Launchpad bug 1579480 in php-defaults (Ubuntu) "PHP7-ubuntu sessionclean searches for "php5" named binary" [High,Invalid] https://launchpad.net/bugs/1579480
[16:25] <nacc> rbasak: e.g., LP: #1617397 might be related to the same idea (php5 packages sticking around)
[16:25] <ubottu> Launchpad bug 1617397 in php5 (Ubuntu) "Some php5 packages not upgraded to php7 from 14.04 to 16.04" [Wishlist,Triaged] https://launchpad.net/bugs/1617397
[16:26] <rbasak> nacc: if the new php-common should cause php5-common to be removed on upgrade, then maybe a Conflicts/Replaces? I'm not sure.
[16:26]  * rbasak consults https://wiki.debian.org/PackageTransition
[16:26] <rbasak> Maybe #11?
[16:27] <rbasak> I'm interested in ondrej's opinion. We should probably do what he says here (and not diverge).
[16:28] <nacc> rbasak: ack, i asked him in the second bug
[16:37] <nacc> rbasak: also just took a look at debian sid and it seems to match what we currently have, afaict. Interesting, php-common breaks (versioned) php5.6-common which doesn't exist in debian, and not php5-common at all.
=== alexisb is now known as alexisb-afk
=== sexy-guy changed the topic of #ubuntu-devel to: Why won't pretty girls talk to me?
[17:56] <sexy-guy> Why won't pretty girls talk to me?
[17:56] <Unit193> dax.
[17:56] <sexy-guy> Unit193: Why won't pretty girls talk to me?
[17:57] <sexy-guy> dax: Why won't pretty girls talk to me?
[17:57] <dax> Unit193: danke
[17:57] <Unit193> dax: Thank you.
=== dax changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[17:57] <dax> Unit193: reminder about pondering changing this channel's ACL
=== alexisb-afk is now known as alexisb
[21:28] <nacc> smb: around?
[21:51] <mwhudson> pitti: is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834367 going to be fixed in xenial?
[21:51] <ubottu> Debian bug 834367 in systemd "systemctl daemon-reexec (as run on systemd upgrade) causes all keystrokes to go to text console in addition to X (including passwords)" [Critical,Fixed]
[22:03] <nacc> just to confirm, an SRU to a package with version currently 7.0.5+dfsg-4build1 should result in 7.0.5+dfsg-4ubuntu0.1?
[22:04] <sarnold> nacc: yes, that's what we've got in our version-number-table https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[22:05] <nacc> sarnold: yep, just my first upload, so didn't want to mess up :)
[22:06] <nacc> sarnold: thanks!
[22:17] <nacc> sarnold: for dput to xenial-proposed, it would be `dput ubuntu:xenial-proposed <changes file>`, correct?
[22:18] <sarnold> nacc: that's what my notes say, but I've never done uploads outside of -security
[22:22] <jbicha> you might even be able to do 7.0.5+dfsg-4ubuntu1 if that version doesn't and won't exist in any later Ubuntu release
[22:24] <nacc> sarnold: ack, thanks -- many of the documents i'm finding just keep referring to 'when you do an upload', without specifying exactly what to do :)
[22:24] <nacc> jbicha: true, i figured i was best off being consistent with the security team's documentation
[22:24] <cjwatson> you don't specifically need to dput to ubuntu:xenial-proposed
[22:25] <cjwatson> what matters is what's in the Distribution field in the .changes, which is generated from the first line of debian/changelog
[22:25] <cjwatson> and "xenial" will do fine there, that's mapped to xenial-proposed automatically
[22:25] <cjwatson> assuming that's correct then you can just dput to ubuntu
[22:25] <nacc> cjwatson: ah ok, good to konw
[22:25] <nacc> *know
[22:25] <nacc> maybe that's why it's not easy to find that detail :)
[22:26] <cjwatson> what matters> well, if you specify a particular dput target then that will override
[22:26] <cjwatson> but most people don't
[22:27] <nacc> right
[22:27] <nacc> cjwatson: thanks again!
[22:27] <sarnold> ah thanks :)
[22:28] <Unit193> 'devel' is even more fun. >_>