[04:17] <pitti> GOod morning
[04:22] <roaksoax> pitti: howdy!
[04:22] <roaksoax> pitti: quick question, any ideas? http://pastebin.ubuntu.com/12778124/
[04:23] <roaksoax> pitti: running vivid's adt in trusty, against a vivid qemu image
[04:26] <pitti> roaksoax: if "runlevel" says "unknown" this means that the VM hasn't done early boot yet, presumably some service is failing?
[04:26] <pitti> roaksoax: you can run "--- qemu --show-boot ..." to watch the VM booting, perhaps you see an error there?
[04:27] <roaksoax> pitti: systemd seems to bring everything up just fine
[04:28] <roaksoax> pitti: the only thing:
[04:28] <roaksoax> [    1.037526] systemd[1]: Set hostname to <ubuntu>.
[04:28] <roaksoax> [    1.185590] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[04:30] <pitti> that should be fine
[04:31] <pitti> roaksoax: so that smells like a bug in autopkgtest then, apparently there's sometimes still stuff going on after login is ready
[04:31] <roaksoax> pitti: right, so I'll try to create a new image and see what happens
[04:31] <pitti> roaksoax: if you boot the VM manually in QEMU, log in, and run "runlevel", what exit code and output do you get?
[04:31] <pitti> roaksoax: i. e. does it ever flip to exit 0/output "2", or stay in "unknown" forever?
[04:32] <pitti> roaksoax: i. e. does this just need to become a waiting loop, or is something genuinely broken there?
[04:32] <pitti> roaksoax: err sorry, should go to "5", but any number will do :)
[04:32] <roaksoax> pitti: i'll give that a try
[05:06] <roaksoax> pitti: created a new image, and now see this:
[05:06] <roaksoax> [FAILED] Failed to start Seed the pseudo random number generator on first boot.
[05:06] <roaksoax> See "systemctl status pollinate.service" for details.
[05:06] <pitti> roaksoax: ah, so I suppose "systemctl status" is "degraded", not "running"?
[05:06] <pitti> roaksoax: what does "runlevel" say then?
[05:07] <roaksoax> sae:
[05:07] <roaksoax> adt-virt-qemu: DBG: runlevel: exit 1, out "unknown
[05:07] <roaksoax> ", err "None"
[05:07] <roaksoax> haven't run it manually yet
[05:10] <roaksoax> pitti: weird, it works fine with wily with the same error
[06:24] <dholbach> good morning
[06:44] <clobrano> good morning all
[07:52] <pitti> sarnold: do you need any further security info in bug 1488341?
[08:52] <ginggs> good morning all
[08:54] <ginggs> doko: i don't think that fpc 3.0.0 rc1 sitting in proposed is ready for production ( https://launchpad.net/ubuntu/+source/fpc ), is it possible to have it removed?
[09:55] <flexiondotorg> I've just tried an upgrade from 15.04 to 15.10 which fails because Thunderbird in 15.04 is newer than the one on 15.10.
[10:09] <ricotz> chrisccoulson, ^
[10:19]  * xnox got removed from all my channels, *sigh*
[10:31] <seb128> pitti, are ddebs still relying on the old importer script or did we got them in launchpad now? and if we got them in launchpad when did that landed? (doing a bunch of rebuilds for missing ddebs and I wonder if that's the still supposed ot be an issue)
[10:32] <pitti> seb128: we switched to Launchpad at the start of wily, so we don't need any rebuilds any more
[10:32] <pitti> seb128: if they are missing on ddebs, we can fish them out of LP
[10:32] <seb128> oh ok
[10:32] <seb128> are the retracers doing that
[10:32] <pitti> seb128: apport also falls back to direct LP download if it's not on ddebs.u.c. these days
[10:32] <seb128> I was looking at e.g https://errors.ubuntu.com/problem/11fc82b90619044eaa80c8acd806e58b47cace21
[10:33] <seb128> that started on september 25
[10:33] <seb128> and it seems to not find the ddebs on launchpad
[10:33] <seb128> those listed indeed miss amd64 ddebds on ddebs.u.c
[10:34] <seb128> e.g atk1.0 clutter-1.0 harfbuzz
[10:36] <pitti> seb128: right, apport's direct LP download fallback was added on Sep 30, i. e. after that
[10:38] <seb128> pitti, hum, ok, do you know if retracers can be nudged to fix those retraces?
[10:38] <seb128> or are the new tries going to success and be batched in a different bucket?
[10:39] <pitti> seb128: new tries ought to succeed now, yes; but I don't know for sure whether they'll become a new bucket
[10:39] <seb128> pitti, k, thanks
[10:39] <pitti> I thought once there was a known address signature already it won't actually retrace
[10:42] <seb128> k
[10:46] <seb128> pitti, do you know exactly when ddebs started being in launchpad/how to check if one is there?
[10:46] <seb128> like libsignon-glib was uploaded on 2015-05-13 unsure it needs a rebuild
[10:47] <pitti> seb128: you see it as normal build output in LP, e. g. https://launchpad.net/ubuntu/+source/atk1.0/2.16.0-2build1/+build/8115852
[10:47] <pitti> seb128: and the previous atk was already built with ddebs too: https://launchpad.net/ubuntu/+source/atk1.0/2.16.0-2/+build/7428094
[10:47] <pitti> seb128: not that it even matters for atk1.0 as that has a -dbg and thus the ddebs are empty
[10:48] <seb128> pitti, https://launchpadlibrarian.net/203832013/buildlog_ubuntu-vivid-amd64.libsignon-glib_1.12%2B15.04.20150420.1-0ubuntu1_BUILDING.txt.gz doesn't
[10:48] <seb128> so I guess that needs a rebuild?
[10:49] <pitti> seb128: start of May somewhere, I can't pinpoint it exactly (cjwatson might); but it's easy enough to check on a per-package basis
[10:49] <pitti> seb128: correct, 20 April was before enabling that
[10:49] <pitti> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/7343240 has no ddebs
[10:52] <seb128> pitti, danke
[10:56] <cjwatson> seb128,pitti: Mysterious lack of logs of exactly when, but it was between 2015-04-30 and 2015-05-05
[10:57] <cjwatson> (With a brief period earlier when they were enabled but then backed out as we fixed a problem that arose)
[10:57] <seb128> cjwatson, pitti, k, I think that's enough information to see what needs a rebuild or not, thanks
[10:57] <cjwatson> seb128: Right, not much was built in the ambiguous period since it was before wily opened.
[11:44] <sil2100> barry: hey! Once you're around, I would need sponsoring/review for LP: #1505632 and a sync for LP: #1506007
[11:44] <sil2100> barry: thanks! :)
[13:32] <doko> didrocks, LP: #1440549 your comment and the "solution" don't make sense.
[13:32] <doko> if you want to use python3 use it.
[13:34] <dobey> doko: hi. do you have any idea how to get gccgo-4.9 to be usable as /usr/bin/go on vivid? gccgo-5 isn't usable because it requires g++5, so all the binary compatibility issues make it untenable on vivid.
[13:36] <doko> dobey, why? gccgo-5 doesn't depend on g++-5
[13:36] <dobey> doko: not directly, but it tries to execute it, which fails
[13:37] <doko> dobey, ahh, you mean when you have embedded c++ code?
[13:37] <dobey> yes
[13:38] <doko> that's somehing we probably can't fix. does the go driver allow to call another CXX?
[13:38] <dobey> i have no idea.
[13:40] <dobey> doko: btw, re: that python3 bug above, dh-python does rewrite shebangs, but only /usr/bin/python ones, not /usr/bin/env (because that'e executing env, not python), iirc
[13:41] <barry> sil2100: cool will look
[13:41] <doko> dobey, could you try setting CXX=g++-4.9 in the env?
[13:43] <dobey> doko: seems to work, but now i get /usr/bin/ld.gold: error: cannot find -lstdc++
[13:43] <seb128> doko, what if you want to use "the default python version"?
[13:43] <doko> seb128, we don't have a "default python version"
[13:44] <seb128> we should :-)
[13:44] <doko> we're not ArchLinux ;p
[13:45] <dobey> seb128: then you want to use python 2.x. it's what the PEP says, and what we do :)
[13:45] <doko> dobey, -L$(dirname $(g++-4.9 --print-file-name libstdc++.so))
[13:45] <seb128> then that "env python" and the depends on python are fine?
[13:46] <doko> what does the PEP have to do with removing python2 from the images?
[13:46] <dobey> seb128: as long as gconf2 isn't part of the default install, i guess so. otherwise they conflict with the goal of removing python2 from the images
[13:46] <dobey> doko: nothing with that, but the PEP has to do with /usr/bin/python vs /usr/bin/python3
[13:47] <doko> right
[13:48] <didrocks> doko: so, we hardcode /usr/bin/python3?
[13:48]  * didrocks backlogs
[13:48] <doko> didrocks, this, or maybe use env python3 if you like
[13:48] <dobey> didrocks: or /usr/bin/env python3 if you prefer
[13:48] <doko> violent agreement
[13:49] <didrocks> ok, I thought that mutliple time, we required to use env instead of anything
[13:49] <dobey> and change build-deps and any binary deps, to be python3 things
[13:49] <didrocks> dobey: if you looked at the package, that's already done for long
[13:49] <didrocks> so only changing to python3, will do in next upload
[13:50] <dobey> didrocks: then the package is broken since the script runs against things the package doesn't depend on :)
[13:50] <dobey> but yeah, just change the shebang then
[13:52] <dobey> doko: so how do i get that -L passed to gccgo? setting LDFLAGS didn't seem to do it
[13:52] <doko> dobey, hmm, on second thought, just use $(g++-4.9 --print-file-name libstdc++.so), so that other files are taken from the default gcc lib dir
[13:52] <doko> no idea
[13:53] <doko>         cppflags = stringList(envList("CGO_CPPFLAGS", ""), p.CgoCPPFLAGS)
[13:53] <doko>         cflags = stringList(envList("CGO_CFLAGS", defaults), p.CgoCFLAGS)
[13:53] <doko>         cxxflags = stringList(envList("CGO_CXXFLAGS", defaults), p.CgoCXXFLAGS)
[13:53] <doko>         ldflags = stringList(envList("CGO_LDFLAGS", defaults), p.CgoLDFLAGS)
[13:53] <doko>  
[13:53] <doko> from go/cmd/go/build.go
[14:02] <dobey> gccgo-5: error: /usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.so\: No such file or directory
[14:02] <dobey> hrmm
[14:02] <dobey> wtf cmake/gccgo
[14:06] <ogra_> cyphermox, did you see bug 1446689 ?
[14:07] <doko> didrocks, dobey looks like you have to use dh_python3 --shebang=/usr/bin/python3 explicitly
[14:07] <ogra_> (and the corresponding ubuntu-devel-discuss thread)
[14:07] <cyphermox> ogra_: yes, I saw
[14:07] <doko> dobey, the extraneous : ?
[14:08] <ogra_> cyphermox, i wonder if we can do something about that ... seems rp-pppoe is in universe now for whatever reason
[14:10] <dobey> doko: for some reason a "\" is being added to the filename soemwhere
[14:10] <dobey> but afaict it's not cmake doing it, but gccgo
[14:10] <cyphermox> ogra_: we'll just have to promote it again, if it was ever in main
[14:10] <ogra_> yeah, well, if it was, that is most likely quite a while ago
[14:11] <doko> dobey, or -L$(dirname $(gcc-5 --print-file-name libgcc_s.so)) -L$(dirname $(g++-4.9 --print-file-name libstdc++.so))
[14:11] <dobey> oh maybe it is cmake
[14:11] <dobey> hmm
[14:12] <cyphermox> ogra_: ah, I think I see.
[14:12] <dobey> no idea why that's happening though :(
[14:13] <didrocks> doko: interesting, that's for the pointer! I'll bundle that in next upload
[14:14] <ogra_> cyphermox, oh ... the "--with-pppoe=/usr/sbin/pppd" sounds like an interesting workaround :)
[14:14] <ogra_> probably works without seeding rp-pppoe
[14:17] <cyphermox> ogra_: right, plus part of that code changed at some point
[14:17] <ogra_> ah
[14:19] <ginggs> cyphermox, ogra_ : hi, i'm familiar with that bug
[14:19] <cyphermox> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6fdfb03107138e96e641d12a7c4df5ecfacb5406
[14:19] <ogra_> yeah, i see your comment :)
[14:21] <rbasak> hallyn: it looks like your netcf FTBFS fix in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795328 also came up on the rebuild test and affects 1:0.2.6-1 in Debian experimental which is synced to Wily. I can cherry-pick it but do you want to upload a fix to Debian experimental and sync that instead?
[14:21] <cyphermox> I'll cherry-pick the fix to wily and prepare a SRU for vivid.
[14:21] <ogra_> yay
[14:21] <ogra_> now that was quick ... :)
[14:22] <cyphermox> ^^ commit is upstream already, it's just a matter of identifying which
[14:23] <cyphermox> so once I looked at git and saw that the pppoe_binary bits weren't there, and we have them in what's currently in wily, then it's obvious there is some patch to apply
[14:23] <cyphermox> or
[14:23] <cyphermox> ogra_: wanna do it?
[14:23] <cyphermox> or morphis
[14:23] <ogra_> very busy this week ... sorry
[14:24]  * ogra_ only saw the mail and wanted it handled if possible :) 
[14:24] <cyphermox> does that affect you?
[14:24] <cyphermox> ginggs: me guesses you're directly affected by this, so you could test the SRU?
[14:24] <ogra_> nope, i dont use NM on my router
[14:25] <ogra_> (headles ufw/pppoe setup)
[14:25] <bdmurray> pitti: Where is your retracer code? https://bugs.launchpad.net/ubuntu/+bug/1320700/comments/2 That could use some improvement.
[14:25] <ginggs> cyphermox: sure i can test an SRU
[14:25] <cyphermox> yeah
[14:25] <ogra_> malone !
[14:25] <dobey> doko: i managed to get it a bit further along, but now it's weirdly complaining about use of undefined name in some of the go code
[14:25] <ogra_> now i feel old
[14:25] <ogra_> (remembering what malone is/was)
[14:26] <bdmurray> ogra_: I hate to tell you this but you are
[14:26] <ogra_> lol
[14:26] <ogra_> so true
[14:26] <pitti> bdmurray: it's not in bzr, these are just some custom scripts that we run every now and then to clean up the unretraceableones
[14:26] <bdmurray> pitti: ah, okay
[14:28] <doko> dobey, paste?
[14:29] <dobey> ../../service-ng/src/github.com/ziutek/glib/value.go:71:3: error: reference to undefined name ‘_Cfunc_g_value_set_double’
[14:29] <dobey> lot sof stuff like that
[14:38] <dobey> i wonder if we can get golang 1.5 backported to the vivid phone overlay PPA instead of trying to make gccgo work
[14:41] <doko> dobey, wasn't the server team already doing that?
[14:42] <jrwren> dobey: copy it from ppa:~ubuntu-lxc/lxd-stable ?
[14:42] <dobey> doko: why would the server team care about go on the phone?
[14:42] <jrwren> how is go on the phone different from an armhf build of go?
[14:42] <dobey> or they are backporting as an sru for vivid?
[14:43] <thebwt> Howdy folks, is there a document out there that details packaging destination directory best practices?  like when to use /sbin vs /usr/sbin ?
[14:43] <doko> welcome to the wonderful world of inter team communication
[14:43] <thebwt> (asked in the packaging, but it's been a ghost town for the last week)
[14:43] <dobey> jrwren: well, armhf isn't the problem. it's arm64 and ppc
[14:44] <chiluk> infinity, arges, do either of you have a chance to review the debdiff for https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871 with me?
[14:44] <jrwren> dobey: for phone? oh right, arm64
[14:44] <doko> dobey, but maybe mwhudson knows about the cfunc stuff ...
[14:44] <jrwren> dobey: there is a go with builds for all those platforms in that ppa
[14:44] <arges> chiluk: i can take a look
[14:44] <dobey> jrwren: well, for phone there is an overlay PPA and QA requirements and such, so for me to use new go on vivid, we need to get new go approved to go in that PPA
[14:45] <arges> chiluk: oh i remember this one : )
[14:45] <jrwren> dobey: ah, sorry. I see what you mean.
[14:45] <chiluk> arges it's a fairly large change... but debdiff is a collection of clean-ish cherry-picks from upstream.
[14:45] <arges> yea this will require more coffee
[14:45] <chiluk> lol..
[14:46] <chiluk> I think I did a good job documenting what I did in the case, and in the patch.
[14:50] <sil2100> doko, slangasek: hey! So, regarding the mir build-failure from bug LP: #1506045 - could anyone of you guys copy-package the mir version I mentioned there from the overlay PPA to the archive? It has the fix for the build failure
[14:51] <Laney> sil2100: seb128 has been pinging the team about it
[14:51] <Laney> maybe find out what they said first
[14:51] <seb128> I asked them yesterday
[14:51] <seb128> they said they needed QA verification first
[14:52] <seb128> kgunn said they would copy over once it's done
[14:52] <seb128> 0.17
[14:52] <kgunn> seb128: yep, it just now got QA approval
[14:52] <kgunn> so needs to at least migrate to overlay first
[14:52] <seb128> great
[14:52] <sil2100> QA verification?
[14:52] <seb128> it's a dual landing
[14:53] <seb128> you know QA team, touch, phone etc
[14:53] <sil2100> But it's landed already
[14:53] <seb128> 0.17?
[14:53] <sil2100> No, 0.16.1+15.10.20150930.1
[14:53] <seb128> they want to land 0.17
[14:53] <sil2100> This is enough to get wily mir building
[14:53] <seb128> right
[14:53] <seb128> but 0.17 is ready and has more fixes
[14:53] <seb128> they wanted to land that directly
[14:54] <sil2100> Ok, well, I just want to resolve the build failure before the release
[14:54] <sil2100> Anyway, as long as 0.17 builds on wily as well then sure ;)
[14:54] <seb128> right and it's being handled
[14:54] <seb128> don't worry about it
[15:16] <Saviq> bbl
[15:21] <ginggs> cyphermox: shouldn't you remove '--with-pppoe=/usr/sbin/pppoe' from debian/rules as well?
[15:22] <cyphermox> ginggs: yes, you're right, it will need to be changed to /usr/sbin/pppd or the right path for pppd
[15:22] <ginggs> cyphermox: no i think it should just go
[15:25] <cyphermox> oh, you're right
[15:30] <ginggs> doko: it would be great if those FTBFS pages (e.g. http://qa.ubuntuwire.com/ftbfs/ ) had an editable comment field like the merge-o-matic pages (e.g. https://merges.ubuntu.com/universe.html )
[15:43] <doko> wgrant, ^^^
[15:43] <doko> ginggs, yeah, but there is not much space on these lines
[15:47] <doko> mvo, just updated https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/823254
[15:47] <doko> what is this issue about gmenu?
[15:58] <mvo> doko: I don't know about a gmenu issue sorry
[15:58] <doko> mvo, well, you wrote about it in the past?
[16:00] <mvo> doko: aha, this can be removed, current trunk is using gobject-introspection already for gmenu
[16:01] <mvo> doko: and python3-dbus exists also, let me update the bug
[16:02] <doko> mvo, ta
[16:02] <mvo> yw
[16:20] <mterry> @pilot in
[16:32] <seb128> happyaron, cking, do you have a ffe for zfs-linux? https://wiki.ubuntu.com/FeatureFreeze states that's needed for new packages (and those should stop after beta freeze)
[16:32] <cking> seb128, https://bugs.launchpad.net/zfs/+bug/1505716
[16:32] <seb128> thanks
[17:02] <seb128> cking, happyaron, sorry but the zfs news review is not going to be for today from me, we have team dinner tonight and I need to go
[17:02] <seb128> maybe somebody in the U.S tz can pick that up
[17:02] <seb128> otherwise I'm going to try to have a look tomorrow if things are not too crazy at the sprint
[17:03] <cking> seb128, tomorrow is fine, thanks
[17:03] <seb128> yw!
[17:10] <mterry> chiluk, I'm looking at bug 1432871
[17:10] <mterry> chiluk, and I see you also patched gnulib
[17:10] <mterry> chiluk, but don't have a wily patch for it?
[17:12] <chiluk> mterry are you looking for https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/comments/9
[17:13] <chiluk> or has the wily version changed in the last few weeks.
[17:13] <mterry> chiluk, that's a patch for the coreutils package
[17:13] <mterry> chiluk, does the gnulib package not also need a patch?  You link to upstream gnulib changes
[17:13] <chiluk> mterry I guess you are correct..
[17:14] <chiluk> the weird thing is that we package coreutils with a gnulib already sitting in lib
[17:14] <mterry> chiluk, are they separate changes?  It looks like you mention coreutils needing support in gnulib?
[17:14] <chiluk> unless I'm missing something.
[17:14] <chiluk> I didn't notice that we had a separate gnulib package..
[17:15] <chiluk> I'll work on a debdiff for gnulib this afternoon.
[17:15]  * mterry looks at code...
[17:16] <mterry> chiluk, I see what you mean.  It does seem to include its own copy of the code
[17:17] <chiluk> it's definitely not dynamically linked to gnulib sources.. it's really a very odd project like that.
[17:18] <chiluk> mterry I think you are right though, if we are going to fix coreutils we should probably have the requisite changes in gnulib as well.
[17:18] <mterry> chiluk, I think maybe it's OK to ignore gnulib for now...
[17:18] <mterry> chiluk, it doesn't seem as important -- we can wait for upstream there
[17:18] <chiluk> alrighty..
[17:19] <chiluk> mterry if you want to do the initial upload I'll get arges to do the SRU when I meet up with him this afternoon.
[17:20] <mterry> chiluk, uploaded (with a bugfix merge from Debian included too)
[17:20] <chiluk> awesome thank you mterry
[17:20] <mterry> chiluk, thanks for the fix!  :)
[17:20] <chiluk> yeah.. it was a royal pita.
[18:18] <mterry> chiluk, whoops.  I was careless.  I uploaded the coreutils change, but it is ftbfs
[18:18] <mterry> chiluk, have you tested it on wily?
[18:42] <mterry> chiluk, specifically, the tests/misc/chroot-fail.sh dies on everything from chroot / sh... down
[18:42] <chiluk> mterry, yeah this is weird.. I know I built it last week....
[18:42] <chiluk> mterry give me a sec.. I'll get it squared away.
[18:44] <chiluk> yeah the .m4 changes shouldn't have been in there.
[18:44] <chiluk> the patches that got included add them, then remove them.
[18:44] <chiluk> that's where it's failing.
[18:45] <chiluk> mterry I think I may have just uploaded the wrong debdiff.. this bug has been going on for so long.
[18:45] <mterry> hah
[18:51] <chiluk> mterry, no that's the correct patch... I even have the debs that I built with it.
[18:51] <chiluk> mterry I'm attempting another sbuild now.. mterry .. I know I had issues getting coreutils to build using pbuilder ... are you using pbuilder by chance?
[18:52] <mterry> chiluk, I am, but I saw the same error that the buildd did when using it (and an extra error when building locally, but I didn't worry about that one)
[18:55] <mterry> chiluk, I've combined your patch with another change from Debian when uploading... maybe that is screwing something up?
[18:56] <mterry> chiluk, it was a chroot related change in debian...
[18:56] <mterry> chiluk, but Debian's package builds fine for me
[18:56] <arges> chiluk: https://launchpad.net/ubuntu/+source/coreutils/8.23-4ubuntu1/+build/8129763
[18:56] <chiluk> mterry .. it's ok .. I'll take a closer look at it.
[18:57] <chiluk> mterry looks like a test failure..
[18:57] <mterry> chiluk, yup
[18:58] <chiluk> mterry FAIL: tests/misc/chroot-fail .... my changes should be touching that.
[19:02] <chiluk> mterry PASS: tests/misc/chroot-fail.sh  ... builds fine with just my patch.
[19:02] <chiluk> I'll grab the sources and see what's going on.
[19:02] <mterry> chiluk, sorry  :(  I didn't consider Debian's patch blowing yours up
[19:03] <chiluk> mterry ... I'll help figure this out.. perhaps we should push my patch back into debian..
[19:04] <chiluk> I think It's mostly ready for submittal there, but they don't have a related bug open yet.
[19:04] <Noskcaj> Would someone  be able to sponsor a merge of redshift for me? it's currently non-funtional in wily, and it would be great to fix it
[19:06] <mterry> Noskcaj, got a bug number?
[19:06] <arges> chiluk: http://launchpadlibrarian.net/221228821/coreutils_8.23-4ubuntu1.dsc
[19:06] <Noskcaj> bug 1485153
[19:07] <Noskcaj> probably a few dupes too. I'm just merging it now, i've been away for a few months
[19:07] <mterry> :)
[19:20] <arges> @pilot in
[19:20] <arges> mterry: oh its your patch pilot day too : )
[19:20] <mterry> arges, :)
[19:21] <mterry> arges, I'm currently working on "baloo_file_extractor crashed with SIGSEGV in memcpy"
[19:21] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/wily/redshift/merge2/+merge/274448
[19:21] <mterry> Just to avoid overlap
[19:21] <mterry> arges, and Noskcaj's merge ^
[19:21] <arges> mterry: ok
[19:22] <chiluk> mterry so I just removed my patch from your upload of coreutils, and chroot-fail.sh still fails.... so it's like the debian patchset that's breaking somethin.
[19:22] <mterry> chiluk, huh... I had tried that...
[19:22]  * chiluk is happy it wasn't his fault for once...
[19:22] <mterry> chiluk, will try again to confirm
[19:23] <chiluk> I just commented my patch out of 00list.. with a #... not sure if that would do it..
[19:23] <mterry> chiluk, I think so?  As long as it was not applied at the time
[19:23] <mterry> I don't believe your patch was anything but a debian/patches patch
[19:26]  * arges looks at 1314887
[19:27] <chiluk> mterry that is correct...
[19:33] <mterry> chiluk, ah.. I know why my test of debian's change worked.  They don't run tests, but the fact that we do wasn't clear from our changelog delta.  OK.  I'll patch out the test due to it being Debian
[19:34] <chiluk> mterry it looks like you removed -33_chroot_always  .. that's probably the source of the build failure.
[19:34] <chiluk> mterry give me one sec to check.
[19:36] <mterry> chiluk, no?  That was added by Debian
[19:37] <chiluk> yeah but they aren't running tests.
[19:37] <chiluk> just give me a sec to understand what's going on and what's being tested here.
[19:38] <mterry> chiluk, right.  But I'm saying I didn't remove 33_chroot_always, I added it.  I think the fix is just patching out the tests in chroot-fail.sh that assume Debian didn't patch out the "chroot /" optimization
[19:39] <chiluk> yeah I think you may be correct.
[19:41] <mterry> chiluk, alright will go ahead with that then
[19:51] <chiluk> mterry  the 33_chroot patch is definitely the source of the test failure.
[19:51] <mterry> chiluk, cool.  I'm testing a build of coreutils with the tests patched out.  I presume it will work and I'll upload
[19:51] <mterry> chiluk, sorry to alarm ya
[19:52] <chiluk> mterry are you patching out all the tests or just the chroot-fail test?
[19:53] <mterry> chiluk, just the chroot-fail ones that actually fail
[19:53] <chiluk> mterry ... no worries... just support me when I submit for core dev eventually..
[19:53] <mterry> chiluk, hah, the standard fee for that is measured in beers  :)
[19:56] <chiluk> mterry... I'm not above bribery ...
[20:08] <tyhicks> pitti: hello - is the libmicrohttpd MIR something that can happen towards the start of the 16.04 devel cycle or do you need it in main for 15.10?
[20:18] <arges> @pilot out
[20:19] <chiluk> mterry are you going to be doing a copy of the wily sources to vivid as well?
[20:20] <mterry> chiluk, wasn't planning to
[20:20] <mterry> chiluk, didn't want to include the Debian stuff there
[20:20] <chiluk> mterry they were at the same version.
[20:20] <chiluk> mterry can I get up to upload my patch for vivid as well then?
[20:21] <chiluk> I kind of want it to bake a bit in vivid/wily before proceeding with trusty
[20:21] <mterry> chiluk, I can upload for vivid too sure
[20:21] <chiluk> thanks.
[20:21] <mterry> chiluk, that was my thinking for letting it bake in wily.  But sure on vivid
[20:21] <chiluk> oh ok.
[20:21] <chiluk> we can wait a few weeks then with wily.
[20:25] <mterry> chiluk, no I'm fine.  it's just vivid  :)
[20:25] <chiluk> yeah ... it should be safe... I just figured we'd get more thorough testing there.
[20:26] <mterry> chiluk, but first let it land in wily
[20:26] <chiluk> yeah.
[20:26] <mterry> still hasn't
[20:32] <doko> slangasek, I think you are wrong writing "will cause the behavior of programs to be inconsistent"
[20:44] <mterry> @pilot out
[21:15] <mwhudson> dobey: are you still here?
[21:16] <dobey> hi
[21:17] <pitti> tyhicks: libmicrohttpd can certainly wait for 16.04; we are deep in FF anyway, I just stumbled across it today and wondered if it was blocked on information or just manpower
[21:18] <tyhicks> pitti: that's great to hear!
[21:19] <dobey> mwhudson: i think the best solution is to just try and get golang 1.5 into our phone overlay ppa at this point, to solve the issues we're hitting
[21:19] <tyhicks> pitti: it is a man power issue - we had several high priority MIRs that trumped many others this cycle
[21:19] <mwhudson> dobey: ah ok
[21:19] <pitti> tyhicks: that's ok, thanks
[21:20] <mwhudson> dobey: let me know if you want me to try to figure out what's going on, but if it's 1.4 or earlier i might not be much help
[21:22] <dobey> mwhudson: yeah, the problem is vivid has 1.3, and on arm64 and powerpc doesn't use golang-go, but rather uses gccgo, and that isn't working with cgo very nicely
[21:22] <mwhudson> dobey: aah
[21:23] <mwhudson> yeah sounds plausible
[21:23] <mwhudson> fwiw, golang-go on ppc64el is still pretty bad at cgo
[21:24] <dobey> i'm more worried about arm64 than ppc really at this point
[21:24] <dobey> aren't many ppc phones on the market :)
[21:28] <sergio-br2> hi
[21:28] <sergio-br2> just a quick question: ubuntu packages are synced from sid or testing?
[21:30] <pitti> sergio-br2: the autosync is from sid usually, but we don't run it right now; manual syncs can happen from anywhere
[21:31] <sergio-br2> even universe packages are from sid?
[21:31] <sergio-br2> and main
[21:31] <pitti> yes
[21:32] <pitti> we have our own britney instance to keep out the brokenness
[21:32] <sergio-br2> ok, found something http://askubuntu.com/questions/104287/how-is-ubuntu-more-updated-than-debian
[21:32] <sergio-br2> so the LTS packages comes from testing
[21:32] <cjwatson> not any more
[21:32] <cjwatson> that was true at one point but it proved to be more trouble than it was worth, especially once we introduced our own equivalent of testing migration
[21:33] <cjwatson> note the date on that answer
[21:33] <sergio-br2> february 2015
[21:33] <cjwatson> no
[21:33] <sergio-br2> nope, it's 2012 right?
[21:33] <cjwatson> it's a silly American date
[21:33] <cjwatson> 2012-02-15 in sensible formatting
[21:34] <sergio-br2> so 14.04 came from sid more or less?
[21:36] <cjwatson> sergio-br2: yes
[21:38] <cjwatson> sergio-br2: 12.04 was testing if I'm remembering/reading the history correctly
[21:38] <sergio-br2> it explain lot's of stuff
[21:40] <cjwatson> auto-syncing from testing meant that it took longer for regressions to get fixed due to the standard migration delay in Debian, and we ended up frequently spending time chasing down regressions that turned out to be already fixed in unstable
[21:41] <cjwatson> (and obviously it had some benefits, but our own testing migration provided the bulk of the same benefits)
[21:51] <sergio-br2> thanks for the explanation
[22:56] <sergio-br2> another question: why the kernel number is not bumped to 4.2.0 --> 4.2.1 --> 4.2.2 and so ?