[00:19] <syeh> Hi, does anyone here happen to know how ubuntu gnome resizes the wall paper upon a resolution change?  I'm running into a strange issue where going from 800x600 -> 1024x768, and the wall paper stays in 800x600 size.
[00:20] <nacc> syeh: you may want #ubuntu
[00:21] <syeh> Yeah, I tried that, but I thought maybe this channel is better suited for code development related questions
[00:22] <syeh> At first I thought the issue is with our graphics driver, but it's beginning to look like something inside of 16.10
[06:27] <cpaelzer> good morning
[09:15] <pitti> sergiusens: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html is the official doc
[09:15] <pitti> sergiusens: e. g. http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM
[11:13] <mardy> Laney: hi! Can you please update your signon-ui from https://bileto.ubuntu.com/#/ticket/2135 ?
[11:14] <mardy> Laney: please ping me once you're done, there is something else which you should do to activate logging
[11:14] <Laney> mardy: sure (haven't got the bug yet today, FWIW)
[11:14]  * Laney does now
[11:15] <Laney> done
[11:15] <mardy> Laney: do you have a file ~/.config/QtProject/qtlogging.ini?
[11:15] <Laney> mardy: nope
[11:17] <mardy> Laney: ok, then echo -e "[Rules]\nsignon.debug=true" > ~/.config/QtProject/qtlogging.ini
[11:17] <mardy> Laney: then kill signon-ui, if it's running
[11:18] <Laney> mardy: done
[11:18] <Laney> do I need to relaunch it?
[11:18] <mardy> Laney: no, you just need for the bug to appear :-)
[11:18] <Laney> ok, then stand by :)
[11:18] <Laney> if it happened 2 hours after I logged in then that's in 3 minutes :P
[11:19] <mardy> Laney: did you do something to trigger it? like checking the calendar for example?
[11:21] <Laney> mardy: IIRC I was in a terminal when it happened, so I don't think so
[11:34] <sil2100> Hey! My dbus package is blocked in -proposed due to LP: #1590956 - does anyone know if we can somehow ignore this autopkgtest failure for the time being?
[11:38] <pitti> rcj: hey! do you know what's blocking getting zesty-daily cloud images into simplestreams? that's blocking importing them into our clouds
[12:00] <sil2100> pitti: hey! I know you're sprinting so you probably don't have enough capacity for autopkgtest things, but I was wondering if I could request some failing autopkgtest exceptions to unblock things migrating? Regressions not caused by the actual packages trying to migrate but due to 'others'
[12:04] <pitti> sil2100: what ones are you looking for? I can add hints, but not enough time to walk throgh the huge -proposed (initial autosync swamp)
[12:06] <sil2100> pitti: so the first concrete candidate would be the plasma-framework s390x failure for the dbus package in -proposed (I also see the same plasma failure in openbox too)
[12:06] <sil2100> pitti: this one is caused by a known issue in LP: #1590956
[12:06] <sil2100> (unrelated to the packages trying to migrate)
[12:31] <xnox> marcustomlinson, hello
[12:32] <marcustomlinson> xnox: hi
[12:32] <xnox> marcustomlinson, i am looking at https://bileto.ubuntu.com/#/ticket/2130 and I see it's stuck on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2130/+build/11135918
[12:32] <xnox> why is there a build-dependency on less than boost 1.62?
[12:32] <xnox> also, that's not quite a good way to limit things; as boost-defaults have moved to 1.62 in zesty.
[12:33] <xnox> you can build-depend on: libboost-regex-dev (< 1.62~) | libboost-regex1.61-dev
[12:33] <marcustomlinson> xnox: right, that MP with that dependancy rule was nuked. I was trying to see if 1.61 would fix this: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1467173.html
[12:33] <xnox> that way it will work anywhere were the default is lower, or will pull in 1.61 in zesty, for now.
[12:34] <marcustomlinson> xnox: (issue with libboost-python1.62.0)
[12:34] <xnox> marcustomlinson, i see. so stuck behind boost-python misscompile.
[12:34] <xnox> marcustomlinson, i will prioritise trying to fix that then! =)
[12:34] <xnox> thanks for pointing out the underlying issue!
[12:35] <marcustomlinson> xnox: thanks! Yeah, wasn't really sure who to speak to about it. Was gonna watch the debian bug thread over the weekend I guess
[12:35]  * xnox started boost1.62 transitions in both ubuntu & debian..... :-(
[12:35] <marcustomlinson> xnox: so the thanks go to you!
[12:36] <pitti> sil2100: dbus hinted
[12:36] <sil2100> pitti: thanks! Still looking into the libnih issues, but this one I knew was b0rken
[12:37] <marcustomlinson> xnox: you can see the failures across the board on zesty here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2110/+packages
[12:37] <xnox> ack
[13:03] <rcj> pitti, which streams?  zesty is in the daily download stream.  it's been there for a week.
[13:03] <rcj> it's also in AWS daily streams
[13:04] <pitti> rcj: not according to IS (https://rt.admin.canonical.com/Ticket/Display.html?id=97105)
[13:04] <pitti> rcj: if it is, mind if I CC: you on the ticket and Jacek and you talk directly?
[13:05] <rcj> sure
[13:05] <rcj> I'll be back at my desk in 90m
[13:05] <rcj> pitti, ah, I see the index.json has dropped them.  I'll file a bug and get it going
[13:06] <pitti> rcj: he pointed at http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson but I don't see per-release images there at all
[13:06] <rcj> pitti, no, wait.  they're there.  They are looking in the wrong stream
[13:06] <pitti> rcj: daily vs. released?
[13:06] <rcj> You won't have images in 'releases' stream until zesty is released.
[13:06] <rcj> Use the daily stream during development
[13:06] <Laney> https://cloud-images.ubuntu.com/daily/streams/v1/index.sjson
[13:06] <Laney> that has it
[13:07] <pitti> Laney: nice, thanks!
[13:07] <rcj> okay, was worried that something had broken after we turned on zesty
[13:07] <pitti> rcj, Laney: cheers
[13:07] <rcj> np
[13:08] <Laney> cheers to you!
[13:08]  * Laney is watching the adt queues slowly drain
[13:13] <pitti> Laney: I hope on Monday they'll look better
[13:13] <Laney> pitti: I added some more workers (especially for armhf)
[13:14] <Laney> it's going downwards
[13:14] <Laney> graphs would be nice for times like this :-)
[13:14] <pitti> Laney: oh, nice! and that doesn't reduce the (relative) quota for ppc64el too much?
[13:15] <Laney> pitti: the bos01 quota is actually good
[13:16] <cjwatson> I'd hope that quotas for ARM and POWER are independent.
[13:17] <Laney> If they are it's not exposed in nova's output
[13:17] <Laney> Or at least not the command I'm using :)
[13:27] <pitti> they aren't, it's the quota for the bos01 cloud, not per-arch
[14:50] <rekoil> i'm having issues with libapache2-mod-wsgi-py3
[14:51] <rekoil> running python3 code with it seems to segfault
[14:51] <rekoil> this is on an up-to-date trusty installation
[14:52] <rekoil> anyone able to help me confirm this isn't just an issue on my end?
[14:52] <rekoil> libapache2-mod-wsgi works with python2 code
[14:52] <rekoil> but not libapache2-mod-wsgi-py3 with python3 code, all i get is segfaults trying to launch python3
[15:36] <nacc> rbasak: around?
[17:13] <nacc> smoser: had to implement an entirely new override model, but netty and pcre3 now import :)
[17:14] <smoser> nacc, nice.
[17:15] <nacc> smoser: the underlying issue was dsc/tarball shadowing in LP
[17:15] <nacc> smoser: so the same named file was being used by two different dsc files (and sometimes the same named dsc file) which then led hashes to mismatch or the wrong dsc to be used
[17:47] <doko> LocutusOfBorg: did you check all emacs25 rdeps in main?
[17:57] <LocutusOfBorg> doko, I don't know how to check
[17:58] <nacc> reverse-depends -c main src:emacs25
[17:58] <nacc> and maybe -b separately?
[18:03] <doko> nacc: we don't have any yet
[18:03] <doko> LocutusOfBorg: all packages which have emacs or emacs24 as b-d's in main
[18:04] <nacc> doko: oh i see transitioning emacs24 to emacs25, sorry
[18:09] <LocutusOfBorg> doko, webkitgtk is in universe
[18:09] <LocutusOfBorg> the only one that has such issue
[18:10] <tdaitx> is there a script out there that automates buildlog downloads? as in "download buildlogs for all archs for this package for a particular release"... I couldn't find anything
[18:10] <tdaitx> it would be great if it could handle private ppas as well
[18:11] <LocutusOfBorg> checking for WEBKIT... yes
[18:11] <LocutusOfBorg> not sure what does happen if we remove it
[18:19] <sarnold> tdaitx: fetch-buildlogs http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/files/head:/security-tools/
[19:08] <tdaitx> sarnold, nice! thanks for that ;-)
[20:32] <nacc> smoser: ping
[20:32] <smoser> hey
[20:32] <nacc> smoser: so i think there are 3 known cases where i can't make pristine-tar work, the cases i'm working with the launchpad folks to get alias tarballs for
[20:33] <nacc> smoser: *aliased
[20:33] <nacc> smoser: as the upstream is already tagged and we can't import it again
[20:33] <nacc> smoser: are you ok with that? it's historical, shouldn't happen again, but means there will be some versions that aren't buildable with pristine-tar (all long ago so far)
[20:33] <nacc> smoser: usd-build will be able to build them still, i think, once i update it to know about the aliasing
[20:35] <smoser> 3 known cases?
[20:35] <smoser> as in 3 ever ? or 3 types of things.
[20:35] <nacc> 3 publishes of src packages that are wrong
[20:35] <nacc> well, 'wrong', but yeah
[20:35] <nacc> 3 so far
[20:56] <smoser> nacc, i dont have strong feelings.
[20:56] <smoser> but wonder how you came up with 3
[20:56] <smoser> was that a db query on launchpad or a result of the things we've seen fail
[20:56] <smoser> as we've' only attempted a extremely small set of things (like 800)
[20:56] <smoser> of the probably 50000 things
[20:57] <nacc> 3 things you've filed bugs for
[20:57] <nacc> that are root caused to the same issue
[20:57] <nacc> smoser: there is no other workaround for this problem, though
[20:57] <nacc> it's a fatal flaw in pristine_tar :)
[20:57] <nacc> inasmuch as pristine-tar assumes (afaict) orig tarballs are unique by name
[20:58] <nacc> as does everythinge else, tbh
[21:47] <nacc> smoser: rbasak: does the dsc branch really need to be namespaced?
[21:51] <nacc> I didn't make a note as to why that should be necessary
[21:51] <nacc> similarly, i'm not sure i recally why namespacing the pristine-tar branch is necessary?
[21:51] <nacc> I mean, I can do it relatively trivially, but I'm not sure why we would
[21:53] <nacc> smoser: my fix also seems to be fixing ipvsadm
[21:53] <nacc> fyi
[23:42] <nacc> smoser: sweet, pristine-tar working, afaict -- needs some tooling assistance to rename importer/ubuntu/pristine-tar or importer/debian/pristine-tar to pristine-tar (as it assumes that branch name and can't use a symbolic-ref)
[23:47] <nacc> smoser: rbasak: i'm done for the week, will check in monday with what's left and maybe to clarify how we want to namespace stuff, everything i have is pushed up the git trre
[23:47] <nacc> the only thing i didn't get to is the `usd ...` subcommanding