[00:19] <Unit193> jbicha: Since you've been doing stuff with webkitgtk, what do you think about sponsoring https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/6849400/+listing-archive-extra ?
[00:20] <Unit193> (Fedora also builds with this switch, btw.)
[00:22] <jbicha> Unit193: could you file a bug for it and subscribe ~ubuntu-sponsors when ready?
[00:24] <Unit193> Meh, perhaps.
[00:28] <jbicha> Unit193: actually webkitgtk is in sync with Debian so why don't you submit it there instead? and what are you using that's not webkit2gtk yet?
[00:31] <Unit193> jbicha: Well, it's not in sync and yeah was considering checking in with Debian on it too.
[00:31] <jbicha> it's in sync with Debian git since the one change we needed I forwarded there :)
[00:32] <Unit193> Nice. \o/
[00:33] <jbicha> I wonder if this commit can/should be backported from webkit2gtk to webkitgtk: https://trac.webkit.org/changeset/204250
[00:36] <Unit193> No idea, all I knew was that just opening the thing would kill it.  Had to poke around webkitgtk to figure out what was up (And lovely 18 hour build times..)
[00:38] <jbicha> opening what thing?
[00:38] <Unit193> The browser I was using, that point being unimportant.
[00:39] <jbicha> I don't build webkit locally; last time I tried the computer I was using couldn't handle it
[00:40] <Unit193> I used LP to build it, aye.
=== King_InuYasha is now known as Son_Goku
=== salem_ is now known as _salem
[05:21] <Mirv> xnox: hmm, it is suppposed to be "working" set of dependencies for emulator use. maybe it got broken in yakkety at some point then, let's see.
[05:22] <Mirv> (at least it is working on vivid where the emulator is used with the gles code path)
[05:26] <Mirv> mitya57: thanks a lot! I think a rebuild should be fine in this case.
[05:37] <pitti> Good morning
[06:07] <Mirv> xnox: it should (be possible to) work because that qml-module-ubuntu-components-gles Provides: qml-module-ubuntu-components. and at least on my yakkety it seems to do that right thing http://pastebin.ubuntu.com/23123088/ (ubuntu-sdk-libs already installed). but it could easily be too much for apt depending on the config.
[06:08] <Mirv> creating emulator images from clean slate of course is easier than switching the whole system from Qt desktop opengl to opengl es
[06:14] <Mirv> ah I see the bug report, well it's a good thing to do regardless
=== racism changed the topic of #ubuntu-devel to: Welcome to the official IRC channel of the Ku Klux Klan | /msg alis list * -min 200 -mode -t   and you get a list of large channels on which any user can change /topic!
[06:27] <pitti> !op | racism
[06:27] <ubottu> racism: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
[06:27] <pitti> Unit193: ^
[06:28] <pitti> well, this <!>op list is fairly useless
[06:30] <racism> !op | penis
[06:30] <ubottu> penis: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
[06:30] <racism> !op | penis
[06:30] <racism> pitti you dont need a fucking op
[06:30] <pitti> racism: and you need a life..
[06:30] <racism> as I am making blatantly obvious anyone can change the topic
[06:31] <racism> if you care so fucking much YOU can change it too!
[06:33] <pitti> racism: I need an op to ban you, not to change the topic back
[06:33] <racism> LOL
[06:33] <racism> what good does it do to ban me?
[06:34] <racism> My poiny has been made, I'm not going to engage in a revert war with the topic if you reset it
[06:34] <pitti> you did yesterday
[06:34] <racism> lol that was because I was stupid yesterday
[06:34] <racism> but now I'm smart
[06:34] <racism> and less of a smartass
[06:35] <racism> and not even a dumbass
[06:43] <racism> ara: observe the /topic
=== ogra_ is now known as ogra
[06:47] <racism> ogra: hi
[06:49] <racism> ogra here too!
[06:49] <racism> ogra sucks nigger dicks
[06:49] <racism> for the lulz
=== racism changed the topic of #ubuntu-devel to: Welcome to the official IRC channel of the Ku Klux Klan | /msg alis list * -min 200 -mode -t   and you get a list of large channels on which any user can change /topic!
[06:54] <racism> dholbach: hi
[06:54] <racism> like the /topic?
[06:57] <dholbach> !ops
[06:57] <ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
[06:57] <dholbach> ^ can you take care of "racism" above?
[06:57] <pitti> dholbach: already done, Unit193 isn't here today, and cjwatson will still sleep a bit
[06:57] <pitti> dholbach: those two are the only two active ops I know
=== racism changed the topic of #ubuntu-devel to: Welcome to the official IRC channel of the Ku Klux Klan | /msg alis list * -min 200 -mode -t   and you get a list of large channels on which any user can change /topic!
[06:58] <racism> lol
[06:58] <racism> cunt cunt cunt cunt cunt
[06:59] <grumble> dholbach: can you tell me what the original topic was?
[06:59] <dholbach> Topic for #ubuntu-devel is: 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:
[06:59] <pitti> grumble: we can, but don't bother changing it back until that guy who doesn't have a life gets kickbanned
=== grumble 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:
[07:00] <pitti> grumble: oh, you have ops? thanks
[07:00] <racism> oh fuck
[07:00] <racism> pitti: grumble is network staff
[07:00] <racism> but very new at being staff
[07:00] <pitti> grumble: but +t is impractical here -- a lot of developers regularly need to change the topic
[07:00] <pitti> (which is the reason why it's free to change)
[07:00] <dholbach> it's something we should raise with the irc council
[07:01] <grumble> pitti: it's temporary :)
[07:01] <racism> hence the delay while grumble sat helplessly trying to google what command to type
[07:01] <racism> grumble, lol
[07:01] <k1l> freenode really should rethink blocking open proxy trolls like racism
[07:01] <pitti> grumble: can you please kickban the guy here? we banned him from other ubuntu channels
[07:01] <racism> uhm  not all the proxy users are bad
[07:01] <dholbach> and all that for a bit of attention
[07:01] <ogra> you surely are
[07:02] <racism> some of them just need them to anonymize their porn
[07:02] <k1l> racism: uhm, then stop abusing it.
[07:02] <racism> lol
[07:02] <pitti> DFTT
[07:17] <pitti> dax: thanks
[07:18] <dax> oh. i assume y'all want -t too?
[07:18] <pitti> dax: yes, please
[07:20] <dax> if most devs have ubuntu/* or canonical/* or something, we could add those cloaks to the ops list and set +t, i guess
[07:20] <dax> but that'd be an IRCC thing, indeed
[07:20] <pitti> dax: that souds like a good compromise indeed
[07:21] <pitti> dax: i. e. only authenticated users can change the topic
[07:21] <pitti> that's what I woudl expect anyway
[07:21] <dax> Unit193, elky: ^ please consider pondering
[07:22] <dax> theoretically could give chanserv flag +t instead of +o, but that'd require re-learning commands
[07:22] <dax> anyways, afk
[07:36] <pitti> xnox: initial statistics: http://autopkgtest.ubuntu.com/browse.cgi/statistics
[07:59] <Unit193> pitti: FWIW, I'm not on that ping list because I'm not an OP here.  If you do go for giving +t to ubuntu/member/ and canonical/, they'd either have to  /cs topic #ubuntu-devel TOPIC HERE  or op up first.
[09:23] <Trevinho> ahoneybun: what you mean, isn't the calculator showing there?
[09:43] <LocutusOfBorg> pitti, hi
[09:43] <LocutusOfBorg> autpkgtest failed
[09:43] <LocutusOfBorg>  cannot copy extracted data for './usr/lib/gcc/powerpc64le-linux-gnu/6/cc1plus' to '/usr/lib/gcc/powerpc64le-linux-gnu/6/cc1plus.dpkg-new': failed to write (No space left on device)
[09:43] <Laney> LocutusOfBorg: known, will be retried
[09:44] <LocutusOfBorg> I already retried ocrmypdf
[09:44] <LocutusOfBorg> I was wondering if you were aware of it :)
[09:44] <LocutusOfBorg> ok, I'll leave to you
[09:44] <Laney> thanks for pointing it out anyway :)
[09:44] <LocutusOfBorg> thanks to you for caring and fixing
[09:58] <pitti> doko, seb128, Laney, LocutusOfBorg: image rebuilds done, mass retry started
[10:00] <LocutusOfBorg> <3
=== hikiko is now known as hikiko|ln
[11:05] <xnox> pitti, nice stats =)
[11:06] <xnox> ah, wanted to ask about releasing a few packages, but it can wait for mass-retry to get them.
=== hikiko|ln is now known as hikiko
[11:36] <pitti> xnox: I'm sure we want more stats over time, we can add them on demand
[11:37] <xnox> pitti, yeah. I imported the dump into postgresql and created the views that I want in pgadmin =)
[11:37] <xnox> failing amd64 test; failing s390x test; and things that fail on s390x but not on amd64 as a personal hit list =)
[11:50] <mitya57> Mirv, in my test (local Qt build) the global menu worked fine, I will test the build in your PPA a bit later and see what's wrong here.
[11:51] <mitya57> (Later today or tomorrow; will reply on the bug after that)
[11:58] <Mirv> thank you so much mitya57
[12:40] <rbasak> libnl-3-200 is "Multi-Arch: same" but both i386 and amd64 ship /etc/libnl-3/classid. Is this a bug?
[12:41] <rbasak> I'm triaging bug 1619481 but it seems to happily co-install in Xenial, which confuses me. I'll try Trusty.
[12:41] <ubottu> bug 1619481 in libnl3 (Ubuntu) "package libnl-3-200 (not installed) failed to install/upgrade: pokus o prepísanie zdieľaného súboru „/etc/libnl-3/classid“, ktorý sa líši od iných inštancií balíka libnl-3-200:i386" [Undecided,New] https://launchpad.net/bugs/1619481
[12:43] <rbasak> Ah, https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent_files_in_multiarch_packages
[12:43]  * rbasak reads more
=== zyga_ is now known as zyga
[12:47] <rbasak> So it looks like it should be fine. No idea why that user hit a bug. Local corruption maybe?
[12:58] <xnox> pitti, refreshing http://autopkgtest.ubuntu.com/running -> s390x/ppc64el columns disappear from time to time, and reappear on a refresh
=== _salem is now known as salem_
[13:06] <smoser> hm.
[13:06] <smoser> late last night i looked at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[13:06] <smoser> and cloud-utils was held due to some failures in lxd and juju
[13:06] <smoser> now it is not held..
[13:06] <smoser> how do i
[13:07] <smoser> a.) see those failures
[13:07] <smoser> b.) know how it got through .
[13:07] <smoser> i suspect someone let it thorugh but i want to know why it failed.
[13:12] <smoser> rbasak, do you now ?
[13:12] <smoser> i dont want to just hit this same thing again next time i upload
[13:14] <rbasak> smoser: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-01/23:38:49.log suggests a lxc/s390x failure maybe?
[13:14] <rbasak> Looks like that always failed though: http://autopkgtest.ubuntu.com/packages/lxc/yakkety/s390x
[13:15] <smoser> iknow when i saw it yesterday it said 'regression' on lxc and on juju
[13:15] <smoser> like ceilometer has now
[13:16] <rbasak> I: [Thu Sep  1 23:41:39 2016] - Checking for new results for failed juju-core-1/amd64 for trigger cloud-utils/0.29-0ubuntu3
[13:16] <rbasak> That one seems more likely. And http://autopkgtest.ubuntu.com/packages/juju-core-1/yakkety/amd64 suggests that it's still failing.
[13:16] <rbasak> Did someone let it through despite that failure?
[13:16] <smoser> thats what i'm asking
[13:17] <smoser> rbasak, well, they might have
[13:17] <smoser> that log https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/j/juju-core-1/20160901_221159@/log.gz
[13:17] <smoser> (no space left on device)
[13:18] <smoser> is almost certain the isue that this fixed.
[13:18] <rbasak> smoser: here you are: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/1894
[13:18] <smoser> but juju ran in a cloud image that didn't have the fix to resize and thus it ran out of space
[13:19] <smoser> is that permenantly disabling ?
[13:19] <rbasak> AIUI, it's just that version (or perhaps <=version, not sure)
[13:20] <smoser> rbasak, where did you learn of all these links ?
[13:20] <smoser> the autopkgtest.ubuntu.com pages are new to me. as is hints-ubuntu
[13:21] <rbasak> Good question. I don't really know!
[13:21] <rbasak> IRC I guess.
[13:21] <smoser> yeah.
[13:21] <smoser> ok.
[13:22] <rbasak> pitti did announce the updated autopkgtest.ubuntu.com the other day.
[13:23] <_hc> hey all, its time again for a request sync of the android-tools packages :-)  its about 10 packages that should all be set to the same upstream version, so I thought it would be less work for all to avoid filing bug reports.  yakkety currently has a mix of upstream versions for these packages (e.g. android-platform-* source packages).  They should all be set to 6.0.1+r55 from Debian/sid.  Or you can wait for them to hit testing if you want.
[13:23] <_hc> here's one examplle https://launchpad.net/ubuntu/+source/android-platform-build
[13:23] <_hc> that needs to be synced
[13:23] <_hc> this one is on the correct upstream version https://launchpad.net/ubuntu/+source/android-platform-system-core
[13:24] <_hc> they all need to be at the same version, otherwise odd bugs will ensue
[13:24] <rbasak> _hc: how does that fit with feature freeze? If you don't get it done soon, filing a single bug with a description and adding that to the sponsorship queue might be a good idea.
[13:25] <jbicha> _hc: yes, I'd been syncing android-tools stuff so that they're on the same version but android-platform-build was broken for the past week (looks like it's fixed today)
[13:25] <_hc> rbasak: since those packages are all part of yakkety, I can't see any reason to not have them synced.  We did this same process with 16.04.
[13:25] <_hc> yeah, I was just uploading
[13:26] <_hc> I'm the main Debian devloper uploading those, feel free to ping me with questions or ask in #debian-android-tools on oftc
[13:27]  * rbasak leaves it to jbicha 
[13:49] <xnox> pitti, in adt can i somehow use archive binaries, but run my tests from my source package which i've just written?
[13:49]  * xnox tries built-tree option
[13:52] <dobey> xnox: that's how it normally works. built-tree doesn't sound like what you want there (it builds new binaries, but i don't recall which get installed after the build)
[13:53] <xnox> unbuilt-tree builds new binaries
[13:53] <xnox> =)
[13:53] <jbicha> pitti: https://autopkgtest.ubuntu.com/running.shtml (from my browser history) doesn't redirect properly
[13:53] <xnox> looks like it's using my tests, against archive packages
[13:54] <dobey> xnox: huh? how can it build new binaries if you aren't specifying to build the tree?
[13:54] <xnox> ... i don't want new binaries. I'm happy with the binaries in the archive. I just adding new adt tests.
[13:55] <Laney> sounds like autopkgtest --no-built-binaries might do the right thing too
[13:55] <xnox> it doesn't build any binaries, nor requires locally built ones, it takes them from the archive. but doesn't take source package from the archive, and instead uses my `pwd`./debian/tests
[13:56] <dobey> i'm confused
[14:05] <mterry> sarnold: so regarding Go packages in main...  Now that we don't need Build-Depends in main, we wouldn't normally need the golang-*-dev packages in main.  But is there a special exception for Go, since their code is bundled in?  (tho not sure how we'd enforce it except by maybe a package regex...)
[14:07] <xnox> mterry, false
[14:07] <xnox> mterry, Built-Using must be correct, and Built-Using must be in main
[14:07] <mterry> xnox: ah... built-using triggers the main check?  Perfect
[14:07] <xnox> mterry, or use go shared libraries, in which case Depends will be generated and result in main inclusion.
[14:08] <mterry> yeah
[14:08] <mterry> xnox: is that supported yet in Ubuntu?
[14:08] <xnox> we went from: build-depends[-indep|-arch], depends, recommends = main
[14:08] <xnox> to: built-using, depends, recommends = main
[14:09] <xnox> oh and Pre-Depends too.
[14:09] <mterry> makes sense yeah
[14:09] <xnox> mterry, i believe mwhudson_ was working on it and i think it was something like works in yakkety, and he was unwinding all the deps to make it worthwhile.
[14:09] <mterry> cool
[14:10] <mterry> xnox: thanks!
[14:10] <xnox> e.g. one needs at least 2 users of the same lib to make this effort give benefits.
[14:10] <xnox> goal was to "sharify" juju/snapd/docker or some such.
[14:10] <xnox> but that may have changed since
[14:10] <mterry> hm
[14:38] <mapreri> why isn't stuff like this dealt by ubuntu's debhelper?  https://patches.ubuntu.com/i/inkscape/inkscape_0.91-9ubuntu1.patch
[14:40] <mapreri> pitti: ↑  (as you're the one taking care of debhelper in ubuntu, apparently)
[14:45] <xnox> mapreri, because it cannot know if the package is meant to be in main and translation packs, or not.
[14:47] <jbicha> mapreri: pkgs that use gnome-pkg-tools (dh --with gnome) pick up dh-translations automatically
=== grumble is now known as spybot
[14:54] <mapreri> jbicha: thanks.  Now, I'm peaking at the sources (and at the manpages), but I can't see where it is doing it :|
[14:56] <mapreri> there is only some translation-related things (but not calling dh_translations) in the cdbs part
=== spybot is now known as grumble
=== dax_ is now known as dax
[15:26] <brendand> getting this error when deploying a yakkety testbed - http://paste.ubuntu.com/23124368/
[15:27] <seb128> brendand, report a bug on launchpad?
[15:30] <seb128> looks like juliank removed the replaces in some recent upload
[15:30] <juliank> Back soon
[15:30] <juliank> the replaces
[15:30] <seb128> brendand, ^
[15:31] <seb128> juliank, thanks
[15:31] <brendand> juliank, ah. we were about to break our way out with a hammer, but if soon is very soon...
[15:32] <juliank> I'd say tomorrow with a sync from a Debian upload today, but I can also prioritize this and do a direct ubuntu upload now
[15:32] <juliank> git cherry-pick commit && gbp dch && ./prepare-release pre-export && debcommit -r -a && gbp buildpackage -S && dput
[15:33] <brendand> don't rush it on my behalf. we'd just need to regenerate our base image and we should probably do that anyway
[15:34] <juliank> There are also some other nice undefined behavior / segfault fixes and staged pipelines for updates, so we now fetch files in a more defined order
[15:34] <juliank> (1) All Release + .diff/Index files, (2) all .pdiff files, (3) the rest
[15:36] <juliank> Here, (2) is basically irrelevant, but it still fixes progress reporting a lot. Progress reporting only starts once we fetched all stage 1 files, and previously you might have already started fetching large files; and thus see 0% all the time
=== mpt_ is now known as mpt
[16:10] <smoser> can anyone sverify that grub-reboot works ?
[16:12] <smoser> http://paste.ubuntu.com/23124599/
[16:13] <smoser> paste fail
[16:13] <smoser> http://paste.ubuntu.com/23124602/
=== sabdfl__ is now known as sabdfl
=== Hakase_ is now known as Tester2009
[19:03] <sarnold> mterry: it'd probably be best to discuss with jdstrand when he returns next week (us holiday and all) -- I only ever took a small "is this package sane" view of things
[19:04] <mterry> sarnold: I figured it out -- Go packages are correctly caught as needing to be in main due to our tools checking the value of Built-Using
[19:04] <mterry> sarnold: thanks though
[19:05] <sarnold> mterry: ah :) hooray
=== salem_ is now known as _salem
=== _salem is now known as salem_
[20:46] <juliank> brendand: Fixed apt uploaded. I accidentally forgot to fix the autopkgtest test suite upstream for non-amd64, so I had to merge it, which means I could directly upload it :)
[20:47] <juliank> Luckily I just noticed that and did not try syncing it tomorrow...
[21:07] <Unit193> jbicha: Right then, now will you sync it?
[21:17] <jbicha> Unit193: webkitgtk you mean? sure, once LP picks it up (there's a delay of several hours after Debian upload before syncpackage works)
[21:17] <Unit193> Yep, I know.  And great.  Another package in sync. \o/
=== salem_ is now known as _salem