[00:00] <xnox> or some such.
[00:00] <cjwatson> ish.  there isn't really a global build collection, it's rather a cheat
[00:00] <ari-tczew> xnox: No, I didn't try with cmake from Debian.
[00:00] <xnox> ari-tczew, or kdelibs5-dev from debian =)
[00:01] <xnox> ari-tczew, then how do you know we should spend time merging cmake? =) for soemthing in your ppa, rather than in the archive too ;-)
[00:01] <xnox> i mean getting newer cmake is always good, but takes time reverse-building things.
[00:02] <ari-tczew> xnox: I didn't say "you should merge cmake", I just asked about my problem and I've got answer from you, that's all.
[00:03] <xnox> ari-tczew, i shall note that "is there any plan to grab latest cmake soon?" == "can anybody please see what's weird going on with this cmake buildlog?" =))))))))))))))))
[00:04]  * xnox is being a bit mean. i'm sorry =)
[00:04] <xnox> it does look like a werid build failure.
[00:10] <ari-tczew> xnox: Well, maybe my 1st question was not appropriate. I'm trying to catch some merges, but they're failing. So, I'd figure out where is the problem. I guess that you think, you waste time for such question like mine.
[00:10] <xnox> ari-tczew, no i don't waste time. i try to help.
[00:11] <xnox> ari-tczew, it's just build-log indicates a miscompat between in-tree cmakefile of the package being built, and cmake module from kdelibs5-dev. as my first guess, i'd assume incompatability of the two (e.g. one is too old / too new for the other)
[00:12] <xnox> rather than cmake core changes. Sure the error is generated by cmake, but it simply says cannot have two conflicting targets doing diffrent stuff =/
[00:14] <ari-tczew> xnox: Sorry that my first target was cmake. I don't know everything, that's the reason why I ask more skilled people.
[00:15] <ari-tczew> You said it's not cmake related, rather kdelibs5-dev, then I'll forward the question to the #kubuntu-devel
[05:54] <ancaemanuel> jdstrand: ping
[05:57] <ancaemanuel> what are you doing more important than this https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 ?
[06:44] <pitti> Good morning
[08:59] <LocutusOfBorg> pretty please, can anybody retry libquazip/marble autopkgtest?
[08:59] <LocutusOfBorg> I uploaded marble, and the test was successful, I don't understand why it hasn't been automatically retried the one from libquazip too
[09:00] <pitti> LocutusOfBorg: done
[09:01] <LocutusOfBorg> thanks :)
[09:05] <Laney> @pilot in
[10:46] <xnox> Laney, may the force be with you
[11:09] <cyphermox> good morning!
[11:32] <juliank> Why are there no xenial branches on https://code.launchpad.net/ubuntu/+source/software-properties - and why does checking out the xenial branch give me 0.96.16, while 0.96.17 is in the archive?
[11:33] <rbasak> juliank: UDD is generally broken. Use pull-lp-source.
[11:34] <juliank> Ugly
[11:34]  * juliank has to merge the latest Ubuntu releases into Debian
[11:34] <rbasak> juliank: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html
[11:35] <juliank> Mkay
[11:36] <juliank> Not sure what I'll do then
[11:36] <rbasak> Right now I import using pull-lp-source downloads into git using a dsc-committing-tool. Would that help?
[11:37] <rbasak> It's effectively what UDD did for bzr, but for git, but manually.
[11:37] <rbasak> Until Launchpad has a new git importer ready.
[11:38] <juliank> It's just ... work
[11:39] <juliank> But it seems like the most sensible option of some sort
[11:47] <LocutusOfBorg> pitti, I see the libquazip marble autopkgtest
[11:48] <LocutusOfBorg> but why did it take the old one?
[11:48] <LocutusOfBorg> 4:15.08.2-0ubuntu3  libquazip 0.7.1-1
[11:48] <LocutusOfBorg> there is an ubuntu4 right now
[11:48] <LocutusOfBorg> Laney, pretty please if you can look at llvm-* on wily queue :) many people suffers from problems about not being able to build some graphic drivers, because clang is not available there and I fixed the build failure
[11:49] <pitti> LocutusOfBorg: we do that with all -proposed packages -- we test them in isolation as much as possible
[11:49] <pitti> LocutusOfBorg: i. e. for verifying if the new libquazip is good, we take its proposed version and run tests against the released versions of rdepends, unless dependencies force the version in -proposed
[11:49] <LocutusOfBorg> ah ok fine
[11:50] <LocutusOfBorg> but the -release is broken :)
[11:50] <LocutusOfBorg> thanks for the explanation
[11:50] <Laney> LocutusOfBorg: I'm sorry but I'm not in the sru team :(
[11:50] <pitti> LocutusOfBorg: apparently that fails here, so I'll re-run it against -proposed
[11:50] <LocutusOfBorg> thanks pitti I wasn't aware of this, otherwise I would have specified it
[11:50] <LocutusOfBorg> good to know
[11:50] <LocutusOfBorg> Laney, no problem :)
[11:52] <Laney> LocutusOfBorg: these people are your friends https://launchpad.net/~ubuntu-sru/+members
[11:52] <LocutusOfBorg> Laney, I'm doing a libgksu merge, do you want to have a look? you are the last uploader :)
[11:52] <Laney> You should ask the last uploader before doing the work
[11:52] <Laney> but in this case it was just a rebuild so I would have said to go ahead
[11:53] <LocutusOfBorg> oh I'm not going to upload anything :)
[11:53] <LocutusOfBorg> I'm going to open a bug
[11:53] <LocutusOfBorg> with a patch
[11:53] <LocutusOfBorg> just I don't know if robert is on irc
[11:53] <pitti> WTF just happened to prodstack
[11:53] <pitti> LocutusOfBorg: ok, I will re-run it as soon as the infra comes back to live
[11:54] <LocutusOfBorg> thanks a lot!
[11:54] <LocutusOfBorg> it is the first transition I try to make it finish :)
[11:54] <LocutusOfBorg> the first ubuntu transition ;)
[12:28] <mdeslaur> @pilot in
[13:25] <doko> tumbleweed, given back three times ... https://launchpad.net/ubuntu/+source/pyzmq/15.1.0-1build1
[13:47] <Mirv> thank you mdeslaur
[13:52] <mdeslaur> Mirv: np! thanks for spotting that
[14:00] <Laney> zyga: hey, could you maybe subscibe the checkbox-dev team to pyotherside bugs?
[14:01] <Laney> zyga: MIR team usually likes to see someone subscribed to main package bugs and that seems to be the team for checkbox itself
[14:01] <Laney> seems this MIR is blocking builds of Ubuntu desktop images atm
[14:29] <spineau> Laney: hello (I'm the one who filed the pyotherside MIR bug)
[14:29] <spineau> Laney: I subscribed https://launchpad.net/~checkbox-bugs for this package
[14:31] <spineau> Laney: All checkbox related packages use this ML (e.g https://launchpad.net/ubuntu/+source/plainbox)
[14:57] <zyga> Laney: I'll look into it
[14:59] <zyga> Laney: done
[15:02] <Laney> hi spineau, thanks!
[15:02] <Laney> hopefully someone will come and look quite soon
[15:03] <spineau> Laney: I hope so too
[15:33] <Laney> @pilot out
[15:54] <yofel> Hi, could someone from the DMB add extra-cmake-modules back to the kubuntu packageset please? It's part of kde frameworks that's mostly maintained by us.
[15:55] <yofel> and is there an easy way to list the reverse-*build*-dependencies of something? e-c-m is used by some qt5 packages so I would like to testbuild those just to be safe
[15:58] <cjwatson> reverse-depends -b
[15:58] <yofel> thanks
[16:46] <mdeslaur> @pilot out
[16:47]  * dholbach hugs mdeslaur
[16:47]  * mdeslaur hugs dholbach
[16:47] <dholbach> :)
[16:54] <smoser> hey.
[16:54] <smoser> is ureadahead still relevant ?
[16:54] <pitti> smoser: not at all on SSD, but still on spinning rust, and ogra says it helps on MMC too
[16:54] <smoser> i had in my head that upstart made use of it and with a systemd system i'd guess its not used.
[16:55] <pitti> smoser: it actually is, I fixed it to work under systemd because phone
[16:55] <pitti> but it still uses an ancient ubuntu kernel patch, so it won't work with upstream kernels
[16:55] <smoser> pitti, oh. ok. that was my query. i just didn't know if it could be dropped from seeds
[16:55] <pitti> there's been a replacement for years, but ureadahead needs to be ported to that
[16:55] <pitti> smoser: oh, do drop it from clouds
[16:56] <pitti> it makes zero sense on virtual machines
[16:56] <smoser> its way down
[16:56] <pitti> kees, stgraber, slangasek, infinity: TB meeting in 4 mins, reminder
[16:56] <smoser> The following packages will be REMOVED:
[16:56] <smoser>   ubuntu-minimal* ureadahead*
[16:57] <pitti> smoser: I suppose we should unseed it from minimal and seed it into standard or even desktop+touch
[16:57] <smoser> well, if it does in fact help on spinning disks, then ...
[16:58] <smoser> you'd be actively hurting server installs to spinning disks by removing it
[16:58] <smoser> hey. other random question
[16:58] <pitti> smoser: does server not install ubuntu-standard?
[16:59] <slangasek> not true that ureadahead is only useful for spinning disks; I forget the details, but it did have relevance for SSD
[16:59] <smoser> (i thought that too at least at one point, slangasek).
[16:59] <slangasek> this may /no longer/ be the case, but Keybuk had benchmarked it
[16:59] <smoser> pitti, one way or another, d-i and maas installs are going to get ubuntu-minimal
[17:00] <smoser> other qustion, was https://wiki.ubuntu.com/Releases shows 15.04 EOL is Feb 4.
[17:00] <smoser> but distro-info-data says 01-23
[17:00] <smoser> is that a designed difference ?
[17:02] <mdeslaur> smoser: it's feb 4th because the eol notice was sent out late
[17:03] <smoser> ok. so readers of distro-info-data just get an early kick in the pants. that is fine.
[17:08] <pitti> smoser: Jan 23 is "end of love", feb 4 is "end of life" :)
[17:09] <pitti> although I guess with $phone it'll actually stay alive for much longer
[18:07] <tumbleweed> doko: let's keep trying :(
[18:29] <tumbleweed> doko: next retry worked :)
[19:02] <pitti> doko: debhelper merge uploaded
[19:03] <smoser> apt is much less GET'y lately.
[19:04] <smoser> previously apt-get update would do something like 58 GETs and now it does only 6.
[19:04] <smoser> https://gist.github.com/smoser/5586288
[19:04] <smoser> horay!
[19:05] <pitti> smoser: wow, that's apt 1.1, or the new 1.2?
[19:06] <pitti> I wonder if it does that, http2 and some bundling or so? AFAIK the structure on archive.u.c. didn't change
[19:10] <cjwatson> pitti: InRelease is recent-ish, although wouldn't account for all of that.  But Julian has been doing a lot of optimisation work
[19:18] <pitti> cjwatson: I see how that would cut down the GETs by a few (not downloading the Release.gpg), but I don't think that explains 58 → 6?
[19:18] <cjwatson> Indeed
[19:18] <pitti> cjwatson: anyway, thanks for pointing that out, I wasn't aware of InRelease yet
[19:20] <cjwatson> Maybe this was David - I see a bunch of vaguely-relevant-looking stuff in e.g. 1.1~exp9
[19:20] <juliank> pitti: smoser: Mostly the work of mvo and DonKult in 1.1, as APT now only fetches files listed in the (In)Release files, instead of trying everything it might need.
[19:20] <juliank> cjwatson: ^
[19:20] <cjwatson> Ah, cool
[19:22] <smoser> juliank, \o/ thank you!
[19:22] <smoser> oh. and DonKult and mvo.
[19:22] <juliank> The Ubuntu archive really should start shipping pdiffs though, then there would be more GETs, but things would be *much* faster
[19:23] <smoser> GETs are heavy
[19:23] <infinity> I've never noticed pdiffs made my life better.
[19:23] <infinity> I turn them off on Debian hosts.
[19:23] <juliank> smoser: Fetching a few 100 kb compared to a few MB/s is a huge difference
[19:23] <pitti> infinity: really?
[19:23] <pitti> they absolutely rock
[19:23] <juliank> infinity: They only really do since recently.
[19:23] <pitti> apt-get update on Debian is a non-issue
[19:23] <pitti> like, lightning fast
[19:23] <infinity> I dunno, I have a lot of bandwidth and slow CPUs.
[19:24] <pitti> on Ubuntu it's a serious task
[19:24] <infinity> Maybe things improved recently, but the tradeoff used to absolutely not be worth it.
[19:24] <smoser> pitti, on xenial its dramatically improved.
[19:24] <pitti> wow, I have a completely different experience
[19:24] <juliank> infinity: They improved *a lot*
[19:24] <pitti> well, even on squeeze
[19:24] <pitti> even apt-get with 20 pdiffs is still much faster than on ubuntu
[19:24] <smoser> by-hash: https://bugs.launchpad.net/launchpad/+bug/1430011
[19:24] <smoser> then super!
[19:24] <infinity> Getting there.
[19:25] <juliank> An update takes 10 seconds here for unstable+experimental with Packages, Sources, Contents files for amd64 and i386
[19:25] <cjwatson> Yeah, by-hash is on my list, but I wanted to finish xz support first, and that's still blocked on some infrastructure deployments to avoid e.g. incorrect squid caching of .xz files
[19:25] <Unit193> pdiffs are so slow, that's why I as well turned them off in Debian.
[19:25] <juliank> Unit193: *were*
[19:25] <cjwatson> The problem with pdiffs in Ubuntu has historically been that we cycle our archive a LOT more often than Debian, so could end up keeping an awful lot of the things around
[19:26] <juliank> Since 1.1.7 it's really fast
[19:26] <cjwatson> But I would like to do it at some point now that the client implementation is sensible
[19:26] <infinity> juliank: It would have to be super fast, given that 24h of pdiffs in Ubuntu could be 48 (or more) diffs.
[19:27] <Unit193> Not sure if I've noticed a huge change in Debian chroots, I suppose I'll have to try it (or wait for infinity to. >_> )
[19:27] <juliank> infinity: The amount of pdiffs does not make a difference, just the total size, given that they're pipelined and merged before being applied
[19:27] <infinity> juliank: Curious.  Yeah, that definitely sounds better than before.
[19:28] <juliank> The bottleneck we had was because reads were unbuffered, so we were doing read(..., 1, ..)
[19:29] <juliank> Well, that was the most important bottleneck
[19:30] <rbasak> juliank: it seems that pipelining doesn't work when behind a traditional (non-pipelining-supporting) squid proxy though? pdiffs are slow for me, I think because of the round trip time.
[19:31] <juliank> rbasak: Right, it requires HTTP/1.1, older squids only do 1.0
[19:33] <juliank> If you want extreme performance, you might want 1.2, that also runs the rred processes in parallel
[19:33] <juliank> But that's only really useful for Contents files
[19:35] <smoser> 'rr'ed ?
[19:35] <nacc> round robin'd?
[19:35] <nacc> dunno :)
[19:36] <juliank> smoser: It's the thing applying the pdiffs
[19:36] <smoser> if thats parallel hits on the same mirror, thats great (what https://github.com/ilikenwf/apt-fast does).
[19:36] <smoser> oh.
[19:36] <juliank> smoser: No, that would not be great
[19:36] <smoser> well, then... since this is like Christmas here for apt... what about ^
[19:37] <juliank> It's one line to enable that, but we're not going to do it
[19:37] <smoser> why ?
[19:37] <juliank> Because it's unfair.
[19:37] <smoser> hm..
[19:37] <juliank> and if your mirror is fast enough, it would be slower
[19:37] <juliank> due to additional overhead
[19:38] <smoser> well, having it configurable would be wonderful. on a per-mirror basis possibly ?
[19:38] <juliank> If your mirror is limiting you because it does not have enough bandwidth, you are stealing bandwidth from other users.
[19:38] <smoser> it is a *massive* improvement on S3 mirrors.
[19:38] <Unit193> juliank: This is not horribly slow, thanks for shouting.
[19:39] <smoser> on s3 mirrors a connection takes a long time to "bring up". the pipe is virtually limitless.
[19:39] <smoser> but doign serial connections kills you.
[19:39] <smoser> on other scale-out style solutions, i'd think behavior might be similar.
[19:40] <juliank> smoser: Shouldn't pipelining take care of that?
[19:40] <juliank> Or is it the connection from the front to the back end
[19:40] <juliank> on the server?
[19:40] <smoser> well, they had a bug in pipelining , which was later fixed, but even then it was not significantly improved.
[19:40] <juliank> hmm
[19:40] <smoser> yeah.. i think the server side took a while to determine you were allowed access to the file or somethign.
[19:41] <smoser> but amazon's suggestion was "our object store is designed to scale out... throw as many connections as you want at us"
[19:41] <smoser> and test validated that.
[19:42] <smoser> using apt-fast we could saturate the link that was provided to the instance.
[19:42] <smoser> but without it, not a chance.
[19:42] <smoser> ie, 4-5M/s -> 40M/s
[19:42] <smoser> (in an 'apt-get --download-only ubuntu-desktop')
[19:43] <smoser> i respect your decision to have clients play nice with servers... but some servers are perfectly fine with parallel connections.
[19:43] <juliank> I can talk to the rest of the team about that use case
[19:44] <juliank> But we do have a limit of min(CPU count *  2, 10)
[19:44] <juliank> Well, no
[19:45] <juliank> You could set 10 to a higher value
[19:46] <juliank> But the number of processes we spawn needs to be controlled in some sort, and we basically append random() % (CPU_COUNT * 2) to the queue name to limit the amount of queues
[19:46] <gQuigs> any suggestions on what to investigate next for https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1515446 ?  It works in debian testing (even though it still gives the nameserver error)
[19:47] <gQuigs> seems to be caused by network-manager/systemd, but I tried installing network-manager from debian and doesn't work any better...
[19:48] <gQuigs> guessing there is a mounting difference between Ubuntu and debian that makes debian retry?
[20:12] <pitti> gQuigs: the main difference in that regard is that ubuntu ships nfs-utils systemd units while debian uses the init.d script
[20:21] <gQuigs> pitti: interesting.. I think that is likely the issue..  guess I can try adding a "Network-manager wait for online" to one of those services?
[20:39] <gQuigs> I guess I should report a bug to debian on it, because likely the NetworkManager difference (not having anything depend on NetworkManager-wait-online.service) will end up affecting debian as well..
[20:49] <pitti> gQuigs: sorry, just here with half an ear (doing a sprint)
[20:49] <pitti> gQuigs: nothign is suppposed to directly wait for NM-waitonline; only to network-online.target
[20:49] <pitti> gQuigs: and NM-waitonline is an "implementation" of network-online (another one is to wait for ifupdown interfaces)
[20:50] <pitti> gQuigs: so waiting on network-online.target is right for NFS
[20:51] <gQuigs> pitti: np, in Fedora it works by having NetworkManager-wait-online.service as a wants on to network-online.target.
[20:51] <pitti> [Install]
[20:51] <pitti> WantedBy=network-online.target
[20:51] <gQuigs> pitti: that was removed in Debian's network-manager, and now NFS mounts fail because nameservers aren't up yet
[20:51] <pitti> gQuigs: yes, same thing
[20:54] <rharper> xnox: hi, wanted to mention that I'm looking at the strongswan merge;  once I have something working after merging, I'll send a note to ubuntu-devel with the changes for discussion, as there is quite a delta (specifically in the packaging of plugins)
[20:56] <gQuigs> so is it a Debian bug? or should our network-online.target be changed (I know how to do this), or our NFS utils?
[20:56] <barry> apw: are you still around?  had some questions about LP: #1519894
[21:05] <pitti> gQuigs: what is actually wrong about our network-online.target? it has Before=network-online.target, so it ought to be fine?
[21:06] <pitti> gQuigs: err, I mean, our NetworkManager-wait-online.service has that Before=
[21:06] <smoser> does anyone know how i would "Blacklist python2.7 and libpython2.7 from cloud and server: " ?
[21:06] <smoser> https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
[21:08] <smoser> i believe next cloud image builds (with cloud-utils at 0.27-0ubuntu21 will drop euca2ools (and thus python2.7)
[21:08] <smoser> and if that is in fact true, i want to make it stay that way
[21:08] <cjwatson> man germinate   /blacklist
[21:08] <pitti> smoser: indeed, I've been purging python2 from my autopkgtest xenial cloud images for a long time
[21:09] <smoser> cjwatson, thank you.
[21:09] <smoser> pitti, well, we had made it in wily
[21:09] <smoser> but then 1 week before release, we got python2 back
[21:13] <gQuigs> pitti: it's not actually blocking network-online.target and I don't know if it actually ever runs
[21:14] <gQuigs> sudo systemctl status NetworkManager-wait-online.service shows no log data at all...
[21:15] <gQuigs> pitti: if you do ' sudo systemctl add-wants network-online.target NetworkManager-wait-online.service ' and reboot it actually shows log data and shows it exited green
[21:15] <pitti> gQuigs: ah, so you mean that we don't actually enable NetworkManager-wait-online.service
[21:15] <pitti> gQuigs: sorry, I didn't think of that; I remember that there was some discussion at some point, about whether we should do that by default
[21:16] <pitti> bug 1430280
[21:16] <pitti> (firefox awesome bar to the rescue!)
[21:16] <pitti> gQuigs: it ran on my system, but maybe I configured it manually at some point
[21:17] <pitti> gQuigs: but the intention was that it got enabled automatically since vivid
[21:18] <juliank> Shouldn't devel-* point to xenial and not to wily?
[21:18] <pitti> err, for sure
[21:19] <juliank> Hmm, on de.archive it points to xenial, but on archive.ubuntu.com it points to wily
[21:19] <gQuigs> pitti: awesome, I'll see about making a debdiff for that then.  thanks!
[21:20] <pitti> gQuigs: ah, was that accidentally dropped later in a merge or so?
[21:25] <gQuigs> pitti: looks like it, it doesn't run by default
[21:25] <gQuigs> and I had no idea that sudo systemctl enable NetworkManager-wait-online.service == the add-wants given the before line
[21:25] <gQuigs> makes sense though
[21:33] <pitti> gQuigs: no, enable doesn't look at the Before= line, it creates the symlinks for the [Install] section, i. e. the WantedBy
[23:44] <doko> pitti, still awake?
[23:46] <Unit193> It's a pitti if he isn't.
[23:46] <sarnold> considering he's often starting his day in four or five hours, it's probabl best if he's still sleeping :)