[03:07] <hallyn> if a package hasn't made it through -proposed on version $v, should the package be build with debuild -v$(v-1), or not?
[03:08] <hallyn> stgraber: ^
[03:15] <xnox> hallyn, yes, you should build with version from -release, when e.g. uploading into -proposed for devel.
[03:15] <xnox> hallyn, or e.g. -v$updates when uploading into -v$proposed SRU.
[03:15] <hallyn> xnox: thanks
[03:16] <xnox> and so on.
[03:17] <hallyn> finally got it to pass in adt-run so i'll assume i'm good.  finally
[03:27] <cjwatson> I don't think -v actually matters very much in practice for that situation.
[03:27] <cjwatson> It's a bit more important for SRUs because of how the tracking page works.
[03:28] <xnox> ... once we have dgit, it will do -v things automatically
[03:28] <cjwatson> I got dgit clone working against LP today
[03:28] <xnox> \o/
[03:29] <cjwatson> push will take quite a bit longer :)
[03:29] <xnox> i am happy to be a test monkey
[03:29]  * xnox will be happy with clone alone too, cause i have been abusing and finding all sorts of buts i've reported to ian over the years about it.
[03:29] <cjwatson> dgit clone is relatively boring, it's just making the right LP API calls and having all the config variables hooked up properly
[03:30] <Unit193> I presume you'll need access so it won't work like the MPs of the bzr branches?
[03:30] <cjwatson> push involves a bunch of thought about policy enforcement in turnip
[03:30] <xnox> cjwatson, well. still nice. given that bzr branch lp:ubuntu/foo doesn't work, I do pull-lp-source, git init, git add -A ., git commit -a -m 'init', then start working.....
[03:30] <cjwatson> Unit193: rough plan is that official dgit-maintained repositories will live in git.launchpad.net/ubuntu/+source/blah, personal branches will live in git.launchpad.net/~user/ubuntu/+source/blah
[03:31] <cjwatson> so anyone with an LP account can make branches and propose merges
[03:32] <Unit193> Awesome.  AFAIK currently it's only for DDs, so I've been ignoring it and just going with gbp.
[03:32] <xnox> well, dgit assumes that things will get stuck, or may get stuck in new-queue, get rejected, et.al. but all that history that dind't make it, is shared with all dgit users. So we can open all repos to all ~ubuntu-dev, even if they don't have upload rights. Cause then sponsoring will become: dgit pull, dgit push =) (from those that are at least ~ubuntu-dev)
[03:33] <cjwatson> not ~ubuntu-dev, but linked with upload permissions
[03:33] <cjwatson> which is not the same
[03:33] <cjwatson> (plus perhaps some thought about new packages)
[03:33] <Unit193> xnox: Yeah I only have a simple packageset, I need motu at some point (though I do like people reviewing my stuff, personally.)
[03:33] <xnox> Unit193, i think this has been progressing to be changed. cause e.g. there is a new dgit machine now, which does DD-privileges-less queries to dak as to how things should operate.
[03:33] <xnox> e.g. dgit clone, in debian, should be operation for non-DDs today.
[03:34] <cjwatson> it's a bit better, but alioth's structure does make it fundamentally hard.
[03:34] <xnox> not using alioth anymore as far as i understand, it's a separate machine now - or is it just vhost?!
[03:34] <cjwatson> once we get it going, LP is in some ways a better fit.
[03:35] <xnox> cool.
[03:35] <xnox> we are not gonna share debian's dgit repos though, right ?! aka things in dgit.debian.org.
[03:35] <xnox> well, i guess one is free to merge anything, cause it's dgit.
[03:35] <cjwatson> haven't thought through all the details there.
[03:36] <cjwatson> I was expecting to probably at least run an importer over everything accessible from every SPPH in LP.
[03:36] <cjwatson> well, in the primary archive anyway.
[03:36] <xnox> stand-alone will be good enough for now. cause we want our upload history and sequencing, and graft/force-merge debian if wanted or needed, or working on merge. But hey, this is git, it doesn't even need a merged history to merge things =)
[03:37] <xnox> cause it's good at smashing things.
[03:37]  * xnox aliases $ git smash, to git pull
[03:38] <cjwatson> sure, but better to have good history from the start IMO
[03:39] <cjwatson> it's on the list
[07:22] <pitti> Good morning
[07:48] <Bluefoxicy> man I am watching an update as it apt-get autoremove --purge on a machine with like 48 installed kernels.
[07:48] <Bluefoxicy> found [47 kernels], added to grub
[07:48] <Bluefoxicy> removing [kernel]
[07:48] <Bluefoxicy> rebuilding [kernel].initrd
[07:48] <Bluefoxicy> found [46 kernels], added to grub
[07:48] <Bluefoxicy> removing [kernel]
[07:48] <Bluefoxicy> rebuilding [kernel].initrd
[07:48] <nikow> auto-remove is removing kernels for u?
[07:48] <Bluefoxicy> yes
[07:49] <nikow> I always doing it manualy…
[07:49] <nikow> I was*
[07:49] <Bluefoxicy> more to the point, if you have multiple kernels installed, any updates will likely rebuild those kernels's initrds multiple times
[07:49] <Bluefoxicy> I'm really getting tired of watching initrds rebuild 4 times for the same kernel in one update
[07:50] <nikow> I can not have more than 3 kernels at the time.
[07:59] <Bluefoxicy> "You have to upgrade 400 packages.  The download will take about 31 seconds on your connection."
[08:19] <dholbach> good morning
[08:21] <ginggs> morning pitti, what can be done about autopkgtest for julia ? it normally fails, but somehow managed to pass the tests once http://autopkgtest.ubuntu.com/packages/j/julia/xenial/amd64/ - it passes the tests in debian  https://ci.debian.net/packages/j/julia/unstable/amd64/
[08:22] <pitti> ginggs: hm, "MemoryError" -- do you happen to know about this package?
[08:22] <pitti> i. e. would it help to give it a larger VM with more than 1.5 GB RAM?
[08:22] <ginggs> pitti, yeah i think so
[08:22] <pitti> ginggs: I can also just lobotomize the one passed result and then it'll be "always failed"
[08:22] <pitti> depending on how much you care
[08:23] <ginggs> if you could give it more ram, that would be great
[08:26] <pitti> ginggs: ok, updated the config and requested a re-run
[08:26] <Bluefoxicy> and apparently 14.10 -> 15.04 gets you a broken, non-booting system
[08:27]  * Bluefoxicy runs do-release-upgrade from the recovery console to get out of that mess.
[08:27] <ginggs> pitti, thanks!
[08:27] <pitti> ginggs: will take a bit though, the queues are moderately full (http://autopkgtest.ubuntu.com/running.shtml)
[09:08] <ginggs> pitti: need moar rams :(
[09:09] <pitti> --flavor autopkgtest
[09:09] <pitti> hm, no, that didn't work yet
[09:10] <pitti> should have been m1.large
[09:15] <pitti> ginggs: meh, my bad -- forgot to git pull before restarting the workers
[09:15] <pitti> done, and re-queued
[09:16] <seb128> mardy, hey
[09:16] <mardy> seb128: hi!
[09:16] <seb128> mardy, do you have hints to debug uoa/e-d-s no working in xenial?
[09:16] <seb128> if you add a google account the corresponding calendar/gmail are not available in evo
[09:17] <seb128> also if I add a google account it's immediatly flagged as desactivated in u-c-c
[09:17] <seb128> like I get a notify-osd about it and it has a red sign
[09:17] <seb128> need to click to reactivate it
[09:17] <mardy> seb128: not really, I'm not familiar with that code
[09:18] <mardy> seb128: but to debug the notification: please do "echo 'LoggingLevel=2' > ~/.config/signond.conf", then kill signond, try again, and you should get some info in the syslog
[09:19] <mardy> seb128: and to get even more info: kill signon-ui, and run this on a terminal: SSOUI_LOGGING_LEVEL=2 SSOUI_DAEMON_TIMEOUT=9999 signon-ui
[09:19] <mardy> seb128: if then you could share these logs with me, it could help (make sure to replace any tokens with XXXXX)
[09:20] <seb128> ok
[09:20] <didrocks> slangasek: in http://launchpadlibrarian.net/185122127/plymouth_0.9.0-0ubuntu3_0.9.0-0ubuntu4.diff.gz, you say that you replaced fonts-dejavu-core by ttf-ubuntu-font-family to avoid depending on both fonts in the changelog. However, the diff (and current packages) shows that we still depend on both, was it a typo and a missing | ?
[09:21] <pitti> more like forgot to actually drop the "fonts-dejavu-core" line?
[09:23] <didrocks> pitti: seems so, just want a confirmation (doing that on the merge for now)
[09:26] <ginggs> pitti: \o/ julia passed! - is this config change permanent now?
[09:27] <pitti> ginggs: yes, it is
[09:28] <pitti> --flavor m1.large
[09:28] <pitti> ginggs: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=d1aeff45 FYI
[09:30] <ginggs> pitti: nice, thanks
[09:54] <Laney> seb128: you doing that signon stuff?
[09:54]  * Laney can reproduce on an iso
[09:54] <seb128> Laney, yes, talking to mardy in a query
[09:54] <Laney> ok
[09:55]  * Laney keeps the logs in case
[09:55] <seb128> but it looks like an e-d-s issue, going to report to them
[09:55] <seb128> my log has " ubuntu_online_accounts_got_userinfo_cb: Failed to create ESource collection for AgAccount "
[09:55] <seb128> do you have that as well?
[09:56] <Laney> hang on
[09:56] <Laney> need to get it out of the vm
[09:56] <seb128> it's in syslog after doing the echo that mardy recommended before
[09:56] <Laney> yes I have that there
[09:56] <seb128> good
[09:56] <larsu> kirkland: why do you need that? gnome-terminal -e should do what you want, no?
[09:56] <zaytsev> laney: since you happened to help me out with my last trusty bugfix, maybe you could advise me on the new situation? so i have software that needs scons to build. i have discovered, however, that scons in trusty is broken with python 2.7 in a way that all sconf checks simply fail
[09:57] <zaytsev> laney: so i found the patch upstream that fixes this problem. it was included in scons 2.3.2
[09:57] <zaytsev> laney: trusty only ships scons 2.3.0 however
[09:57] <Laney> seb128: is that also why we have to re-confirm after adding it? or a separate issue?
[09:57] <seb128> separate issue
[09:57] <Laney> zaytsev: If the patch applies cleanly and fixes the problem then we could include it in a stable update
[09:58] <Laney> zaytsev: check that and then file a bug with the patch attached, subscribe "ubuntu-sponsors"
[09:58] <seb128> Laney, the re-confirm is not new and a sucking UI, apps need to allow access the first time they want to use the online account, and since e-d-s has no UI they decided to make you go through the settings to activate it
[09:59] <Laney> oh
[09:59] <zaytsev> laney: right, so that's the question: 2.3.2 was never shipped in ubuntu. willy ships 2.3.6 that has this bugfix and more, and xenial 2.4.1 which is the newer available with even more fixes. now the question is whether i should backport the patch as you suggest, or one can simply take the packae from the next version into backports?
[10:00] <zaytsev> laney: if the policy is such that backporting an isolated patch is preferred, then i'll go down this way. just need some direction.
[10:00] <Laney> backports isn't meant to sidestep fixing bugs in the release
[10:00] <Laney> fixing it a SRU would be preferred
[10:02] <zaytsev> laney: okay then i will invest some time in preparing a clean backport and makign the bug as last time, i'll try to follow the guidelines. many thanks for your help! it's very much appreciated
[10:04] <Laney> thanks zaytsev!
[10:04] <Laney> lemme know if you need any more help
[11:05] <Saviq> didrocks, hey, think you could have a look at https://code.launchpad.net/~saviq/unity8/in-train-pot-update/+merge/279100 please?
[11:07] <didrocks> Saviq: I guess that ./po/update-unity-pot is the scrope updating the pot file :)
[11:07] <didrocks> Saviq: so yeah, +1, even if I think that this feature should be in the train itself
[11:07] <Saviq> didrocks, bug #1359667 :)
[11:08] <didrocks> Saviq: hum, I would maybe rather override_dh_auto_clean
[11:08] <Saviq> didrocks, ah, right
[11:08]  * Saviq fixes
[11:09] <didrocks> Saviq: commented with this
[11:14] <Laney> didrocks: Saviq: is that going to work?
[11:14] <Laney> does train run debian/rules clean itself?
[11:14] <Saviq> Laney, it does
[11:15] <didrocks> Saviq: as in my comment, I would still readd a dh_auto_clean call then
[11:15]  * didrocks goes for a run, bbl
[11:16] <Saviq> didrocks, yeah, fixing
[11:16] <Saviq> but ssh broke in xenial, so delay
[11:16] <didrocks> Saviq: argh :p once done, just consider it a +1 for me
[11:18] <Laney> in that case why can't it run some random script for you instead of doing weird gymastics in debian/rules?
[11:18] <didrocks> Laney: see the referenced bug report above ^
[11:19] <didrocks> Laney: and my suggestion on that very channel as well :)
[11:19] <Laney> which part of it?
[11:19] <didrocks> https://launchpad.net/bugs/1359667
[11:25] <didrocks> (so yeah, we all agree here, but seems like CI Train maintainer doesn't agree)
[11:25] <Laney> going to comment
[11:25] <didrocks> please do, I've already done it once on IRC IIRC
[11:25] <Laney> done
[11:27] <Saviq> Mirv, hey, how's Qt 5.5 migration going?
[11:31] <Mirv> Saviq: hey, it's looking pretty good - http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src - I don't see currently anything that'd be broken "for real", and I was thinking if I could be at a point of poking pitti of glancing over it. the regressing non-overridden things to seem to have either passed occasionally after the landing or failing already be
[11:31] <Mirv> fore the landing.
[11:31] <Saviq> Mirv, ack, nice :)
[11:32] <pitti> Mirv: look at the bottom, a few failures are already overridden; but there are indeed a few new ones, like marble
[11:33] <Mirv> pitti: yeah, I checked those. marble has had a success yesterday on at least amd64 and i386 so seems flaky.
[11:33] <pitti> yeah, but it used to be very stable until yesterday
[11:34] <Mirv> others remaining are kdelibs4support amd64/ppc64el and kwayland ppc64el but those seem have been failing before
[11:34] <Mirv> pitti: right, it might the marble is the most deserving of attention, I'll try if I can figure anything out.
[11:39] <cjwatson> pitti: what normally creates things like /srv/ddebs.ubuntu.com/www/dists/xenial-updates/main/binary-s390x/Packages*?  I see that its siblings for other arches exist, empty, which I think is all that's required to shut up the cronspam
[11:39] <cjwatson> pitti: But it seems odd to create them by hand
[12:04] <mardy> Laney: hi! I've got someone complaining that the cdimage link from https://wiki.ubuntu.com/Unity8DesktopIso is no longer working
[12:04] <Laney> mardy: delete that wiki page, it's gone
[12:05] <mardy> Laney: do I understand correctly, that since wily+unit8 offers the same as that?
[12:05] <Laney> I think you're meant to use the -desktop-session packages
[12:09] <pitti> cjwatson: ah, that's a bit of a hack; as we don't have -updates during the devel series I usually hack the code temporarily to make it think that xenial-updates changed, and generate that
[12:09] <cjwatson> pitti: ok, if you're familiar with that could you do it for xenial-updates/s390x?
[12:09] <pitti> yep, doing
[12:09] <cjwatson> thanks
[12:10] <pitti> cjwatson: http://paste.ubuntu.com/13643501/ shoudl do, I'll check after the next run
[12:10] <cjwatson> pitti: cool, thanks
[12:14] <pitti> cjwatson: hm, but actually, it complains about the *input* archive, not the output archive
[12:14] <pitti> (it's correct to create empty xenial-updates ddeb indexes, though
[12:14] <pitti> http://ports.ubuntu.com/dists/xenial-updates/main/binary-s390x/Packages.gz exists, though
[12:15] <cjwatson> pitti: no, it must be complaining about the output archive because there's no suffix on the Packages files it lists
[12:15] <cjwatson> pitti: confusing warning message though!
[12:15] <cjwatson> pitti: it's from the second archive_map() call
[12:16] <pitti> oh right, it's building an archive map for the ddebs archive, with mirror pointing to itself
[12:16] <pitti> so, this run indeed should solve that
[12:46] <pitti> cjwatson: ok: http://ddebs.ubuntu.com/dists/xenial-updates/main/binary-s390x/
[12:46] <cjwatson> thanks
[13:06] <tjaalton> anyone else having issues with a sid schroot unable to run 'apt update' since a few days? it just gets stuck here, other schroots work fine..
[13:07] <Laney> there was a bug in apt 1.1, you need to manually upgrade it
[13:07] <tjaalton> ah
[13:08] <Laney> I suppose a re-create will work too
[13:08] <tsimonq2> I had that same issue with the apt PPA in Xenial
[13:08] <tsimonq2> it's easy to fix
[13:09] <tjaalton> yeah, upgrading apt fixed it
[13:09] <tjaalton> thanks
[13:56] <cpaelzer_> It might just be outdated - but I found something about packaging .debs and ldconfig here https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig
[13:56] <cpaelzer_> I wonder why I canÄt find any lib actually doing that ldconfig in maitainerscripts - is that these days automatically covered?
[13:56] <cpaelzer_> or do I just check bad examples when picking libs to see what they are doing?
[13:56] <cjwatson> $ grep ldconfig /var/lib/dpkg/info/libpipeline1\:amd64.postinst
[13:56] <cjwatson>         ldconfig
[13:57] <cjwatson> but as of relatively recently this is normally handled by triggers instead
[13:57] <cjwatson> which has (almost) the same effect as what policy says but not quite the same implementation
[13:57] <cjwatson> anyway, you should just let dh_makeshlibs handle this for you
[13:59] <cjwatson> policy should probably be updated for the ldconfig triggers work
[13:59] <cpaelzer_> cjwatson: thanks - I see that some even have it twice automatically added by dh_makeshlibs
[13:59] <cjwatson> there is no doubt the odd bug
[14:14] <pitti> Mirv: I'll hint kdelibs4support, that's been broken before
[14:14] <pitti> Mirv: kwin and marble do seem to relate to the new Qt, though
[14:17] <Mirv> pitti: I've been staring at marble. it's been failing (but not always) with 5.4 too in parsing the same Tour.kml Google maps file that fails with 5.5. the other 25 .kml files don't have issues  with either 5.4 or 5.5.
[14:19] <Mirv> pitti: kwin amd64 last 4 failing ones are 3 times 5.4.2 and 1 times 5.5.1
[14:20] <Mirv> (Qt version, kwin 5.4.3 always)
[14:25] <Mirv> pitti: ah I'm probably reading it wrong, just checking the first libqt5core5a installation mentioned
[14:29] <Mirv> I've adt-run done on marble but I'm none wise since I don't find how to output the whole parsed xml to find where there's a difference. but I guess the kwin might be the real deal.
[14:31] <Mirv> (sorry, yes marble is a real problem too)
[14:32] <pitti> Mirv: perhaps you can run it under gdb and break at the assertion?
[14:32] <pitti> (not sure how these look like)
[14:40] <kirkland> didrocks: http://bazaar.launchpad.net/~kirkland/byobu/trunk/revision/2450
[14:40] <kirkland> didrocks: in case that's useful to you with weechat
[14:41] <kirkland> didrocks: note the postinst, which links the right .desktop file
[15:06] <didrocks> kirkland: oh nice, so, you confirm that you forced to use a fqdn? (that was the issue yesterday?)
[15:09] <kirkland> didrocks: I had to work through a few things
[15:10] <kirkland> didrocks: it did seem like I needed to have a much more complex service name to work
[15:10] <kirkland> didrocks: I also had to remove the Terminal=true line
[15:11] <didrocks> yeah, I'm surprised about that one
[15:11] <didrocks> (the Terminal= to remove)
[15:18] <Mirv> pitti: ok, managed to add some qDebug finally (gdb break:ing didn't really work out). there's a rounding error of the read xml value with Qt 5.5.1, "4.2" becomes "4.2000000000000002"
[15:22] <pitti> Mirv: eek, does that test compare floats for equality? or is that a string comparison and it's formatted wrongly?
[15:25] <Mirv> pitti: no it compares XML data in eg https://github.com/KDE/marble/blob/master/tests/data/Tour.kml after having gone through some parsing in marble https://github.com/KDE/marble/blob/master/tests/TestGeoDataWriter.cpp
[15:25] <Mirv> pitti: the kwin issue is probably this without xrandr issue https://github.com/KDE/kwin/commit/eda4f6103707bc425dec884c3fe4dac1077b21a7 - probably could cherry-pick (kwin, as the Qt upstream commit not approved yet)
[15:30] <pitti> Mirv: ah, thanks for the research there!
[15:32] <Mirv> pitti: mgraesslin confirms that the kwin issue is probably exactly that
[15:40] <Mirv> pitti: ah, https://github.com/KDE/marble/commit/05df36b674db4b150835ceecc53021d61b51f27e - marble upstream has fixed it, although I'm not sure if it's a fix or workaround. but I could include that + the kwin fix.
[15:43] <Mirv> states it's a bad comparison of double values
[15:43] <pitti> Mirv: that looks more like a workaround
[15:44] <pitti> Mirv: well, "4" can be represented exactly in a float, 4.2 can't; but that just hides the fact of the bad equality comparison
[15:44] <pitti> Mirv: but anyway, this is way beyond what you should be doing there -- going with the upstream fix sounds fine
[15:46] <Mirv> pitti: ok, no-one told me this'd be beyond in any way but at least it has been informative :) I can upload both fixes.
[15:47] <pitti> Mirv: well, I meant "should" in the "can reasonably be expected from you position" side, not "wouldn't be welcome" of course
[15:47] <pitti> Mirv: great, so these two should turn green, the overrides should take care of others, then the large swath should promote
[15:54] <smb> doko, Not sure you saw already but that qemu merge does not seem to be really happy on many (if not all) the other arches
[15:55] <gQuigs> is there anything else I should be doing for SRU https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1505328 ?
[16:02] <rbasak> tdaitx, slangasek: how's that squid3 merge going?
[16:32] <tdaitx> rbasak, sorry, no updates so far, I was back from vacation yesterday. Anyway I do plan to get started at most on Monday
[16:33] <mvo> bdmurray: hi, sorry that it took forever. I followed up with patch  for bug #1267059
[16:33] <mvo> bdmurray: I also asked for a unattended-upgrades backport
[16:34] <bdmurray> mvo: Thanks! I'll have a look at the SRU today then.
[16:36] <mvo> bdmurray: cool, extra testing would be great, I poked at it in various way and I thnk its good but the diff was not trivial to extract unfortunately
[16:37] <bdmurray> mvo: I think there are plenty of people interested in testing it.
[16:42] <chiluk> mterry can I get an upload for coreutils trusty again https://launchpad.net/bugs/1432871
[16:42] <mterry> chiluk, yes... but not today from me anyway.  could do tomorrow
[16:42] <chiluk> ok I'll check elsewhere.
[16:43] <chiluk> cyphermox: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871
[16:51] <slangasek> didrocks: plymouth> your analysis seems plausible, it's likely to have been a typo - though I think I meant to drop the fonts-dejavu-core dependency entirely instead of |
[16:54] <cyphermox> chiluk: yeah, it's just a broken test
[16:54] <chiluk> cyphermox: kind of..
[16:55] <cyphermox> not just kind of
[16:55] <cyphermox> it expects the local fs that you run df on to not be nfs, which can't always be true
[16:55] <chiluk> our fix really should be to update the testcase.
[16:55] <cyphermox> the assumption is bad
[16:55] <chiluk> however... "df --local -t nfs --total '.'  "
[16:55] <chiluk> should never succeed.
[16:55] <cyphermox> why not?
[16:56] <chiluk> local and -t nfs should be mutually exclusive
[16:56] <cyphermox> heh
[16:56] <chiluk> and it does when run anywhere but on our buildds.
[16:57] <chiluk> however, upstream df still behaves this way.
[16:57] <cyphermox> well then we've found a bug in df or in the kernel
[16:57] <chiluk> right there is still an upstream bug in df.
[16:57] <chiluk> but it's not worth the effort to resolve..
[16:58] <cyphermox> did you report it?
[16:58] <chiluk> I'm just trying to give full disclosure here.
[16:58] <cyphermox> oh, I'm all fine with your fix, as long as we report the fact that --local fails to exclude nfs.
[16:58] <chiluk> basically part of the issue is that upstream  has determined that nfs can be a local filesystem on some OS's..
[16:59] <cyphermox> ok
[16:59] <chiluk> and that was the reason they changed the behavior of the testcase.
[16:59] <chiluk> because they also had to change the behavior of df.
[16:59] <cyphermox> fair enough
[17:00] <chiluk> it's definitely better than just skipping the testcases altogether... like was being done before *(because df was failing inside the buildds).
[17:00] <chiluk> it's definitely an improvement.
[17:02] <cyphermox> chiluk: uploaded.
[17:02] <chiluk> thanks cyphermox.. I'll start bribing arges... I think I have some hardware he wants.
[17:04] <chiluk> arges https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871
[17:17] <Odd_Bloke> doko: barry_: I've just discovered that https://bugs.launchpad.net/ubuntu/+source/python-virtualenv/+bug/1500768 is present in the vendored version of urllib3 in python-virtualenv, and hasn't been fixed.
[17:17] <Odd_Bloke> I've added it as an 'Also affects', but after I'd filed https://bugs.launchpad.net/ubuntu/+source/python-virtualenv/+bug/1522500.
[17:17] <Odd_Bloke> Shall I mark the latter as a duplicate of the former?
[17:21] <barry_> Odd_Bloke: yes, i think they're the same bug.  doko uploaded 1.7.1-1ubutu4 to trusty-updates. does that not fix the problem?
[17:34] <xnox> doko, smoser: can we simply move onto 2.5 rc? it's meant to go final on the 12th, and i would like new qemu due to things it will support.
[17:34] <xnox> and i guess we will target 2.5 or better in xenial.
[17:35] <doko> xnox, meh, I don't care, I only did the merge because I messed up the package
[17:35] <xnox> doko, ack. and what about the FTBFS?
[17:37] <cjwatson> doko: that FTBFS is just what I warned about before - control-in needs to be in sync with configure in terms of which arches support seccomp
[17:37] <cjwatson> why not revert all the seccomp-related changes back to just amd64/i386, on the grounds that the other path is clearly entirely untested?
[17:38] <doko> cjwatson, yes, have it fixed locally, will upload
[17:38]  * xnox was also going to mock with that package and make an -s390 package
[17:51] <Odd_Bloke> barry: So the problem is (I think) that virtualenv installs pip from /usr/share/python-virtualenv/pip-1.5debian1-py2.py3-none-any.whl which doesn't have the patch.
[17:53] <Odd_Bloke> barry: Yeah, and that has a _vendor/requests/packages/urllib3 in it.
[18:25] <hallyn> stgraber: infinity: gah!  bad push.  can you intercept a qemu for xenial push with ppa1 in the name?
[18:25] <hallyn> (otoh it might fix the xenial build :)  but shouldn't be there as is)
[18:26]  * hallyn goes to brew a pot of coffee.  this is turning out to be a week of ondays
[18:26] <stgraber> xenial uploads don't get held in the queue so there's not much we can do about it
[18:27] <stgraber> you can prevent it from moving out of proposed though, not that this would necessarily help, you'll still need to upload one with a non-ppa version that's higher than the one you just uploaded
[18:29] <hallyn> prevent it from moving out of proposed - how?
[18:29] <hallyn> yeah i'l upload a new version as soon as i get it to pass in ppa. it's nto a bad package, just bad changelog
[18:30] <stgraber> there's a bug tag you can use IIRC, trying to remember what it is
[18:31] <hallyn> oh nm i'll see if it passes :)  thx
[18:31] <stgraber> hallyn: you can file a bug against the source package and tag it with block-proposed
[18:32] <hallyn> ok thx
[18:32] <hallyn> and just drop that tag after i push the newer version?
[18:33] <stgraber> yeah or close that bug
[18:33] <hallyn> thx done
[19:03] <ben___> is there an easy way to mount /sys within a pbuilder chroot?
[21:20] <robert_ancell> bdmurray, can you get lightdm 1.14.4 out of vivid unapproved queue? It fixes bug 1516831 which was in the previous SRU
[21:24] <bdmurray> robert_ancell: yeah, I was gonna ask about that
[21:39] <knome> slangasek, hello, another ping about the xubuntu core -related merges; what's up? :)
[21:54] <tdaitx> doko, I would like to get your opinion on https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1518741
[22:39] <tmartins> hey guys, I'm experimenting Xenial already, just received libvirt-1.2.21 and it doesn't depends on libxen-4.5 anymore... Is this expected?
[22:39] <tmartins> I'm planning to use Xenial for my Xen project
[22:43] <xnox> arges, ^
[22:43] <xnox> barry, is this the right way to submit fixes? https://code.launchpad.net/~xnox/click/lp1522608/+merge/279521
[22:46] <barry> xnox: i guess that's a cjwatson question?  i don't touch click
[22:47] <xnox> well, i can in the end of the day, just do "ubuntu" community upload.
[22:48] <cjwatson> xnox: lp:click/devel as the merge target please
[22:48] <cjwatson> (and therefore rebranch from that too)
[22:49] <cjwatson> xnox: but you probably want mvo to actually shepherd it through; there are a few other worthwhile improvements in lp:click/devel that I'd like to be part of the next landing
[22:52] <xnox> cjwatson, should Vcs-Bzr nad Vcs-Browser point to the lp:click/devel then? cause that's where i looked.... or are those fields used for other magic elsewhere?!
[22:52] <cjwatson> xnox: very probably yes
[22:53] <xnox> currently points to stale https://code.launchpad.net/~ubuntu-managed-branches/click/click
[22:57] <cjwatson> it's not exactly stale, it just only updates on each landing
[22:57] <cjwatson> oh maybe it is
[22:57] <cjwatson> right, +branch/click is different
[22:58] <cjwatson> will fix when bored, or you can include it in your MP
[23:13] <arges> tmartins: yes
[23:14] <arges> libvirt 1.2.21 and libxen-4.6 are still in xenial-proposed
[23:20] <tmartins> Oh, cool! Thanks arges!
[23:22] <tmartins> arges, I have enabled proposed but, I received new libvirt-1.2.12 but no libxen-4.6
[23:22] <tmartins> will try again tomorrow
[23:26] <tmartins> sorry, new libvirt 1.2.21
[23:26] <tmartins> never mind, I have libxen-4.6  lol
[23:26] <tmartins> sorry about the buzz
[23:27] <tmartins> BTW, Xen adopted 6 months release cycle but, not close to Ubuntu cycle...   :-/
[23:27] <tmartins> Xen 4.7 will be ready two months after Xenial...


[02:45] <smoser> blackboxsw: do you have an mp coming?
[03:18] <blackboxsw> ahh yes, better late than never https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336582
[03:18] <blackboxsw> thx for landing it
[18:32] <smoser> blackboxsw: or rharper
[18:32] <smoser> pretty please
[18:32] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336498
[18:32] <blackboxsw> yeah smoser feature creep wishlist for me on the hotplug stuff
[18:32] <blackboxsw> looking
[19:01] <smoser> blackboxsw: rharper approved so i'm merging.
[19:01] <smoser> unless you object quick
[19:01] <smoser> ;)
[19:27] <blackboxsw> smoser: merging now
[19:27] <blackboxsw> well awaiting tox and it'll land
[19:35] <blackboxsw> landed
[19:36]  * blackboxsw needs to writeup a cool whoami ubuntu contributor page like rharper/powersj have to see if I can get per-pkg commit writes for cloud-init curtin
[19:36] <smoser> yes
[19:37] <powersj> feel free to use mine as a template
[19:37] <blackboxsw> cut-n-paste s/powersj/blackboxsw/g
[19:37] <blackboxsw> .... and done
[19:38]  * blackboxsw thinks claiming the work of others is frowned upon.
[19:38] <blackboxsw> but yeah will base it off what you guys have
[19:39] <powersj> :)
[22:13]  * blackboxsw dumped a couple of branches up for review: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336635 and https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336453
[22:13] <blackboxsw> the first one is just docs on CLI subcommands
[22:14] <blackboxsw> adding some cross-references to the pre-existing analyze stuff ryan added. But adding a bit of context on some of the cloud-init cmdline options as well.
[22:22] <blackboxsw> dojordan, just saw cloud-init updates with your changes made it into azure
[22:22] <blackboxsw> apt-cache policy cloud-init
[22:22] <blackboxsw> cloud-init:
[22:22] <blackboxsw>   Installed: 17.2-13-gf4b8fa6d-1~bddeb
[22:22] <blackboxsw>   Candidate: 17.2-25-gc03bdd3d-0ubuntu1
[22:22] <blackboxsw>   Version table:
[22:22] <blackboxsw>      17.2-25-gc03bdd3d-0ubuntu1 500
[22:22] <blackboxsw>         500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
[22:22] <blackboxsw>  *** 17.2-13-gf4b8fa6d-1~bddeb 100
[22:22] <blackboxsw>         100 /var/lib/dpkg/status
[22:22] <blackboxsw> root@b5:~#
[22:22] <blackboxsw> well into cloud image
[22:22] <blackboxsw> well into cloud images. I mean. deploying azure to check
[22:45] <blackboxsw> yep fresh azure instance is up with your changes... though I'm seeing a delta, like what I merged in from your branch was stale and didn't contain dojordan's last commit.
[22:45] <blackboxsw> it's a minor change, but I'll proposed a trivial now and we can discuss how best to merge, publish that change
[22:48] <blackboxsw> n/m I was on my own stale branch
[22:58] <blackboxsw> powersj: for shame lgtm.com doesn't scrub testing directories. /me was wondering how all your contributions only got logged as 300 lines
[22:58] <blackboxsw> https://lgtm.com/people/1801127304/project:1884170995/lang:python
[22:59] <powersj> blackboxsw: heh I wondered the same thing
[22:59] <powersj> I was like what happened to all my work?!
[23:00] <blackboxsw> yeah definitely "It's not fair" ™
[23:01] <powersj> haha
[23:02]  * blackboxsw sees if we can tweak settings as I'd like to have that review at least on cloud_tests directories
[23:02] <powersj> looks like you could create a lgtm.yaml with what dirs it tests
[23:10] <blackboxsw> https://lgtm.com/docs/lgtm/file-classification
[23:10] <blackboxsw> yeah
[23:16] <blackboxsw> yeah it'd probably be worth minimally a path_classifiers:\n test:\n  - exclude: tests/cloud_tests   lgtm.yaml
[23:17] <blackboxsw> I'll put up a sample cloud-init mirror to see if it blows up anything


[01:00] <peitschie> yay! finished!
[01:00] <peitschie> that only took uhh... 18hrs to do a single checkin :/
[01:16] <Darxus> Heh, lp:spamassassin import still going, 16 hours.
[01:18] <poolie> jeez
[01:24] <peitschie> poolie: good news is that while the next checkin was then slow again, all ones after that appear to be reaaaasonably speedy
[01:37] <peitschie> poolie: do you have any concepts what kind of size the bzr-svn bridge was designed for?  My sqlite db is like 240Mb... >_>
[02:25] <Darxus> When building lp:spamassassin, which is synced via svn, it generates a .orig.tar.gz to satisfy quilt.  How can I do something like that when building from the command line?  How do I generate the .orig.tar.gz?
[02:27] <Kamping_Kaiser> -sa
[02:31] <Darxus> Kamping_Kaiser: Nice, thanks.  That's listed in the dpkg-buildpackage man page with no documentation?
[02:33] <Kamping_Kaiser> Darxus: dpkg-buildpackage, but i think its man page refers to dpkg-source for details
[02:34] <Kamping_Kaiser> (its man page)
[02:35] <Kamping_Kaiser> dpkg-buildpackage has some options around this too, dpending on what you are working with. --split and --export-upstream=ARG
[08:09] <mgz> morning all
[08:11] <vila> hey mgz and al !
[08:11] <vila> jml, james_w : out of curiosity, how did you test your paths shuffling proposal ?
[08:17] <mgz> vila: did you see the note about the jenkins openid plugin?
[08:17] <vila> mgz: yup, thanks
[08:17] <vila> but the description is a bit sparse, I don't really know if babune is at risk,
[08:18] <vila> at worst, AIUI, some can start jobs or modify stuff
[08:19] <vila> in the former case, the fans are close enough to me that I will notice their noise, in the later case, every relevant file is version controlled so I can revert any malicious change
[08:23] <mgz> I'm not sure that's all that could be done, but agree the risk in general is pretty low
[08:25] <vila> mgz: if nothing else, the unusual port I use will hopefully help staying below the radar ;)
[08:26] <mgz> :)
[10:58] <nigelb> Will bzr let me merge one revision from one branch into another?
[10:58] <nigelb> Or skip the last revision but grab the one right before.
[10:59] <nigelb> nevermind, found it :)
[11:08] <mgz> vila: any idea how best to test the fix proposed for bug 882541?
[11:09] <mgz> if there was a working-tree-open hook, could assert that the tree isn't opened unless clean is in the template, but only branch gets an open hook, not tree or repo
[11:09] <mgz> anyway, I need to nip out now will be back a little later
[11:53] <odin_> bzr: ERROR: Permission denied: "Cannot create 'ubuntu'.  Only Bazaar branches are allowed."
[11:54] <odin_> with: bzr push --create-prefix lp:~project-group-account/foobar/snapshot/ubuntu/natty/
[13:04] <indigo> does bazaar have a feature that allows me to emded checkouts of other branches in a branch? If so, what's it called?
[13:06] <indigo> what i'm trying to accomplish is to create a puppet package that deploys an application from a bzr branch. I could make puppet rules that have the target host check out the code itself, but getting authentication right in that case is hard. So, I thought I'd embed a checkout of the code inside the puppet package (which is also stored in a branch)
[14:15] <mgz> indigo, there are a couple of plugins for managing branches within branches, but it sounds like you should just get your deploy right, rather than versioning the dependency
[14:17] <mgz> see bzr-externals and scmproj
[14:29] <jam> mgz: vila: I'm off to pack, see you guys in about 48 hours or so :)
[14:29] <jam> (I leave tomorrow way-to-frickin-early)
[14:29] <jam> s/to/too/
[17:09] <smoser> i think someone has helped me with this before, but I dont recall how to ignore this.
[17:10] <smoser> http://paste.ubuntu.com/721725/
[17:11] <smoser> bzr has a different view on reality than i do.  i'd like for it to not show me entire deletes and replaces of the same file contents
[17:11] <smoser> i think there is some way to do that
[17:27] <mgz> smoser: that's generally a sign of a bad merge
[17:28] <smoser> well you, either I or the launchpad importer are to blame for that.
[17:28] <smoser> but the output is not really useful.
[17:28] <mgz> if you've inadvertantly told bzr that you've got a new file (by id) that happens to replace an existing file with the same contents, you want to Not Do That
[17:29] <mgz> the output is bad, but the problem is worse if it continues becase it leads to bad history
[17:29] <mgz> ^where 'you' could well be 'the importer'
[17:32] <smoser> i dont know if i did it or not. it is quite possible i did.
[17:32] <smoser> but realistically, its a bug in the tool to consider a file 100% different to itself.
[17:33] <smoser> is there a way to either fix it  or tell it "from now on, consider those files the same"
[17:34] <mgz> sure but that's likely just a symptom
[17:34] <mgz> redoing the merge, taking the original files, should do it.
[17:35] <mgz> there may also be a cleverer way
[17:36] <mgz> filing a bug with the exact problem revisions (and ideally how you got them) would help, or posting the details to the list
[17:38] <mgz> right, I need to pack and things
[17:53] <smoser> mgz is gone now.
[17:53] <smoser> bug 883207 is filed with info.
[17:54] <wgz> I'm still here in essence, just less corporally
[17:55] <wgz> bug looks useful, thanks.
[21:34] <hikiko> hello, I would like to install the launchpad plugin on mac osx but I can't find it
[21:34] <hikiko> (only in launchpad)
[21:34] <hikiko> how can i get it?
[22:40] <indigo> is there some command i can run to know if the working tree of a lightweight checkout is out of date? ie, if 'bzr update' will change anything?
[23:19] <fullermd> indigo: status will tell you, I think.
[23:20] <fullermd> You could also compare 'revno' (branch) vs 'revno --tree'.  Though of course it's possible for them to match and be different.  Unlikely with most workflows I'd think.
[23:50] <sproaty> hi, if I have a directory that's basically the same code my bazaar repo, but the dir is not 'connected' to bzr...is there a way I can do that and make this a working branch?
[23:54] <Noldorin_> hi jelmer