=== _salem is now known as salem_
=== salem_ is now known as _salem
[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
=== stub` is now known as stub
=== nudtrobert1 is now known as nudtrobert
[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)
=== TheMuso` is now known as TheMuso
[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
=== nudtrobert1 is now known as nudtrobert
[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?
=== _salem is now known as salem_
[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:07] <ubottu> bug 1359667 in CI Train [cu2d] "There should be a hook mechanism available" [Undecided,Incomplete] https://launchpad.net/bugs/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:19] <ubottu> Launchpad bug 1359667 in CI Train [cu2d] "There should be a hook mechanism available" [Undecided,Incomplete]
[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
=== Ursinha_ is now known as Ursinha
[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)
=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
[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
=== pat_ is now known as Guest71267
=== Guest71267 is now known as pmcgowan
[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?
=== barry` is now known as barry_
[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 ?
[15:55] <ubottu> Launchpad bug 1505328 in cups (Ubuntu Trusty) "Cups SSL is vulernable to POODLE" [High,Triaged]
[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] <ubottu> bug 1267059 in unattended-upgrades (Ubuntu Trusty) ""Unattended-Upgrade::Remove-Unused-Dependencies" does not work " [High,Triaged] https://launchpad.net/bugs/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] <ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,Fix committed]
[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:04] <ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,Fix committed]
[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] <ubottu> Launchpad bug 1500768 in python-virtualenv (Ubuntu Trusty) "python3.4.3 SRU break requests" [Undecided,New]
[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] <ubottu> Launchpad bug 1522500 in python-virtualenv (Ubuntu) "pip in Python 3.4 virtualenvs cannot install using a proxy " [Undecided,New]
[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.
=== cpaelzer_ is now known as cpaelzer
[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:20] <ubottu> bug 1516831 in lightdm (Ubuntu Wily) "XDMCP Request packet with no addresses crashes LightDM" [Critical,Fix committed] https://launchpad.net/bugs/1516831
[21:24] <bdmurray> robert_ancell: yeah, I was gonna ask about that
=== salem_ is now known as _salem
[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
[21:54] <ubottu> Launchpad bug 1518741 in openjdk-7 (Ubuntu) "A pkg-config file is need for OpenJDK distributions" [Undecided,New]
=== _salem is now known as salem_
=== tsg_ is now known as tsg
[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!
=== salem_ is now known as _salem
[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...