[00:00] or some such. [00:00] ish. there isn't really a global build collection, it's rather a cheat [00:00] xnox: No, I didn't try with cmake from Debian. [00:00] ari-tczew, or kdelibs5-dev from debian =) [00:01] 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] i mean getting newer cmake is always good, but takes time reverse-building things. [00:02] 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] 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] it does look like a werid build failure. [00:10] 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] ari-tczew, no i don't waste time. i try to help. [00:11] 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] 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] 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] You said it's not cmake related, rather kdelibs5-dev, then I'll forward the question to the #kubuntu-devel === MerryChristmas is now known as benonsftware === benonsftware is now known as benonsoftware [05:54] jdstrand: ping [05:57] what are you doing more important than this https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 ? [05:57] Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New] [06:44] Good morning === mwhudson is now known as Guest92985 === Guest92985 is now known as mwhudson [08:59] pretty please, can anybody retry libquazip/marble autopkgtest? [08:59] 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] LocutusOfBorg: done [09:01] thanks :) [09:05] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney === vrruiz_ is now known as rvr [10:46] Laney, may the force be with you [11:09] good morning! === jincreator is now known as jincreator_ === _salem is now known as salem_ [11:32] 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? === cpaelzer is now known as cpaelzer_afk [11:33] juliank: UDD is generally broken. Use pull-lp-source. [11:34] Ugly [11:34] * juliank has to merge the latest Ubuntu releases into Debian [11:34] juliank: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html [11:35] Mkay [11:36] Not sure what I'll do then [11:36] Right now I import using pull-lp-source downloads into git using a dsc-committing-tool. Would that help? [11:37] It's effectively what UDD did for bzr, but for git, but manually. [11:37] Until Launchpad has a new git importer ready. [11:38] It's just ... work [11:39] But it seems like the most sensible option of some sort [11:47] pitti, I see the libquazip marble autopkgtest [11:48] but why did it take the old one? [11:48] 4:15.08.2-0ubuntu3 libquazip 0.7.1-1 [11:48] there is an ubuntu4 right now [11:48] 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] LocutusOfBorg: we do that with all -proposed packages -- we test them in isolation as much as possible [11:49] 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] ah ok fine [11:50] but the -release is broken :) [11:50] thanks for the explanation [11:50] LocutusOfBorg: I'm sorry but I'm not in the sru team :( [11:50] LocutusOfBorg: apparently that fails here, so I'll re-run it against -proposed [11:50] thanks pitti I wasn't aware of this, otherwise I would have specified it [11:50] good to know [11:50] Laney, no problem :) [11:52] LocutusOfBorg: these people are your friends https://launchpad.net/~ubuntu-sru/+members [11:52] Laney, I'm doing a libgksu merge, do you want to have a look? you are the last uploader :) [11:52] You should ask the last uploader before doing the work [11:52] but in this case it was just a rebuild so I would have said to go ahead [11:53] oh I'm not going to upload anything :) [11:53] I'm going to open a bug [11:53] with a patch [11:53] just I don't know if robert is on irc [11:53] WTF just happened to prodstack [11:53] LocutusOfBorg: ok, I will re-run it as soon as the infra comes back to live [11:54] thanks a lot! [11:54] it is the first transition I try to make it finish :) [11:54] the first ubuntu transition ;) === cpaelzer_afk is now known as cpaelzer === locutus_ is now known as LocutusOfBorg [12:28] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur, Laney [13:25] tumbleweed, given back three times ... https://launchpad.net/ubuntu/+source/pyzmq/15.1.0-1build1 [13:47] thank you mdeslaur [13:52] Mirv: np! thanks for spotting that [14:00] zyga: hey, could you maybe subscibe the checkbox-dev team to pyotherside bugs? [14:01] 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] seems this MIR is blocking builds of Ubuntu desktop images atm [14:29] Laney: hello (I'm the one who filed the pyotherside MIR bug) [14:29] Laney: I subscribed https://launchpad.net/~checkbox-bugs for this package [14:31] Laney: All checkbox related packages use this ML (e.g https://launchpad.net/ubuntu/+source/plainbox) [14:57] Laney: I'll look into it [14:59] Laney: done [15:02] hi spineau, thanks! [15:02] hopefully someone will come and look quite soon [15:03] Laney: I hope so too [15:33] @pilot out === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur [15:54] 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] 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] reverse-depends -b [15:58] thanks [16:46] @pilot out === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [16:47] * dholbach hugs mdeslaur [16:47] * mdeslaur hugs dholbach [16:47] :) [16:54] hey. [16:54] is ureadahead still relevant ? [16:54] smoser: not at all on SSD, but still on spinning rust, and ogra says it helps on MMC too [16:54] i had in my head that upstart made use of it and with a systemd system i'd guess its not used. [16:55] smoser: it actually is, I fixed it to work under systemd because phone [16:55] but it still uses an ancient ubuntu kernel patch, so it won't work with upstream kernels [16:55] pitti, oh. ok. that was my query. i just didn't know if it could be dropped from seeds [16:55] there's been a replacement for years, but ureadahead needs to be ported to that [16:55] smoser: oh, do drop it from clouds [16:56] it makes zero sense on virtual machines [16:56] its way down [16:56] kees, stgraber, slangasek, infinity: TB meeting in 4 mins, reminder [16:56] The following packages will be REMOVED: [16:56] ubuntu-minimal* ureadahead* [16:57] smoser: I suppose we should unseed it from minimal and seed it into standard or even desktop+touch [16:57] well, if it does in fact help on spinning disks, then ... [16:58] you'd be actively hurting server installs to spinning disks by removing it [16:58] hey. other random question [16:58] smoser: does server not install ubuntu-standard? [16:59] not true that ureadahead is only useful for spinning disks; I forget the details, but it did have relevance for SSD [16:59] (i thought that too at least at one point, slangasek). [16:59] this may /no longer/ be the case, but Keybuk had benchmarked it [16:59] pitti, one way or another, d-i and maas installs are going to get ubuntu-minimal [17:00] other qustion, was https://wiki.ubuntu.com/Releases shows 15.04 EOL is Feb 4. [17:00] but distro-info-data says 01-23 [17:00] is that a designed difference ? [17:02] smoser: it's feb 4th because the eol notice was sent out late [17:03] ok. so readers of distro-info-data just get an early kick in the pants. that is fine. [17:08] smoser: Jan 23 is "end of love", feb 4 is "end of life" :) [17:09] although I guess with $phone it'll actually stay alive for much longer === ben_ is now known as ben___ [18:07] doko: let's keep trying :( === essembe is now known as sbeattie === cpaelzer is now known as cpaelzer_afk [18:29] doko: next retry worked :) [19:02] doko: debhelper merge uploaded [19:03] apt is much less GET'y lately. [19:04] previously apt-get update would do something like 58 GETs and now it does only 6. [19:04] https://gist.github.com/smoser/5586288 [19:04] horay! [19:05] smoser: wow, that's apt 1.1, or the new 1.2? [19:06] I wonder if it does that, http2 and some bundling or so? AFAIK the structure on archive.u.c. didn't change [19:10] 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] 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] Indeed [19:18] cjwatson: anyway, thanks for pointing that out, I wasn't aware of InRelease yet [19:20] Maybe this was David - I see a bunch of vaguely-relevant-looking stuff in e.g. 1.1~exp9 [19:20] 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] cjwatson: ^ [19:20] Ah, cool [19:22] juliank, \o/ thank you! [19:22] oh. and DonKult and mvo. [19:22] The Ubuntu archive really should start shipping pdiffs though, then there would be more GETs, but things would be *much* faster [19:23] GETs are heavy [19:23] I've never noticed pdiffs made my life better. [19:23] I turn them off on Debian hosts. [19:23] smoser: Fetching a few 100 kb compared to a few MB/s is a huge difference [19:23] infinity: really? [19:23] they absolutely rock [19:23] infinity: They only really do since recently. [19:23] apt-get update on Debian is a non-issue [19:23] like, lightning fast [19:23] I dunno, I have a lot of bandwidth and slow CPUs. [19:24] on Ubuntu it's a serious task [19:24] Maybe things improved recently, but the tradeoff used to absolutely not be worth it. [19:24] pitti, on xenial its dramatically improved. [19:24] wow, I have a completely different experience [19:24] infinity: They improved *a lot* [19:24] well, even on squeeze [19:24] even apt-get with 20 pdiffs is still much faster than on ubuntu [19:24] by-hash: https://bugs.launchpad.net/launchpad/+bug/1430011 [19:24] Launchpad bug 1430011 in Launchpad itself "support apt by-hash mirrors" [High,Triaged] [19:24] then super! [19:24] Getting there. [19:25] An update takes 10 seconds here for unstable+experimental with Packages, Sources, Contents files for amd64 and i386 [19:25] 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] pdiffs are so slow, that's why I as well turned them off in Debian. [19:25] Unit193: *were* [19:25] 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] Since 1.1.7 it's really fast [19:26] But I would like to do it at some point now that the client implementation is sensible [19:26] juliank: It would have to be super fast, given that 24h of pdiffs in Ubuntu could be 48 (or more) diffs. [19:27] 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] 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] juliank: Curious. Yeah, that definitely sounds better than before. [19:28] The bottleneck we had was because reads were unbuffered, so we were doing read(..., 1, ..) [19:29] Well, that was the most important bottleneck [19:30] 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] rbasak: Right, it requires HTTP/1.1, older squids only do 1.0 === ChrisTownsend1 is now known as ChrisTownsend [19:33] If you want extreme performance, you might want 1.2, that also runs the rred processes in parallel [19:33] But that's only really useful for Contents files [19:35] 'rr'ed ? [19:35] round robin'd? [19:35] dunno :) [19:36] smoser: It's the thing applying the pdiffs [19:36] if thats parallel hits on the same mirror, thats great (what https://github.com/ilikenwf/apt-fast does). [19:36] oh. [19:36] smoser: No, that would not be great [19:36] well, then... since this is like Christmas here for apt... what about ^ [19:37] It's one line to enable that, but we're not going to do it [19:37] why ? [19:37] Because it's unfair. [19:37] hm.. [19:37] and if your mirror is fast enough, it would be slower [19:37] due to additional overhead [19:38] well, having it configurable would be wonderful. on a per-mirror basis possibly ? [19:38] If your mirror is limiting you because it does not have enough bandwidth, you are stealing bandwidth from other users. [19:38] it is a *massive* improvement on S3 mirrors. [19:38] juliank: This is not horribly slow, thanks for shouting. [19:39] on s3 mirrors a connection takes a long time to "bring up". the pipe is virtually limitless. [19:39] but doign serial connections kills you. [19:39] on other scale-out style solutions, i'd think behavior might be similar. [19:40] smoser: Shouldn't pipelining take care of that? [19:40] Or is it the connection from the front to the back end [19:40] on the server? [19:40] well, they had a bug in pipelining , which was later fixed, but even then it was not significantly improved. [19:40] hmm [19:40] yeah.. i think the server side took a while to determine you were allowed access to the file or somethign. [19:41] but amazon's suggestion was "our object store is designed to scale out... throw as many connections as you want at us" [19:41] and test validated that. [19:42] using apt-fast we could saturate the link that was provided to the instance. [19:42] but without it, not a chance. [19:42] ie, 4-5M/s -> 40M/s [19:42] (in an 'apt-get --download-only ubuntu-desktop') [19:43] i respect your decision to have clients play nice with servers... but some servers are perfectly fine with parallel connections. [19:43] I can talk to the rest of the team about that use case [19:44] But we do have a limit of min(CPU count * 2, 10) [19:44] Well, no [19:45] You could set 10 to a higher value [19:46] 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] 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:46] Launchpad bug 1515446 in systemd (Ubuntu) "NFS shares in FSTAB no longer mount at boot" [Medium,Confirmed] [19:47] seems to be caused by network-manager/systemd, but I tried installing network-manager from debian and doesn't work any better... [19:48] guessing there is a mounting difference between Ubuntu and debian that makes debian retry? === cpaelzer_afk is now known as cpaelzer [20:12] gQuigs: the main difference in that regard is that ubuntu ships nfs-utils systemd units while debian uses the init.d script === salem_ is now known as _salem [20:21] 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] 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] gQuigs: sorry, just here with half an ear (doing a sprint) [20:49] gQuigs: nothign is suppposed to directly wait for NM-waitonline; only to network-online.target [20:49] gQuigs: and NM-waitonline is an "implementation" of network-online (another one is to wait for ifupdown interfaces) [20:50] gQuigs: so waiting on network-online.target is right for NFS [20:51] pitti: np, in Fedora it works by having NetworkManager-wait-online.service as a wants on to network-online.target. [20:51] [Install] [20:51] WantedBy=network-online.target [20:51] pitti: that was removed in Debian's network-manager, and now NFS mounts fail because nameservers aren't up yet [20:51] gQuigs: yes, same thing [20:54] 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] 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] apw: are you still around? had some questions about LP: #1519894 [20:57] Launchpad bug 1519894 in Auto Package Testing "add JSON output for queued and running tests" [Wishlist,In progress] https://launchpad.net/bugs/1519894 [21:05] gQuigs: what is actually wrong about our network-online.target? it has Before=network-online.target, so it ought to be fine? [21:06] gQuigs: err, I mean, our NetworkManager-wait-online.service has that Before= [21:06] does anyone know how i would "Blacklist python2.7 and libpython2.7 from cloud and server: " ? [21:06] https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only [21:08] i believe next cloud image builds (with cloud-utils at 0.27-0ubuntu21 will drop euca2ools (and thus python2.7) [21:08] and if that is in fact true, i want to make it stay that way [21:08] man germinate /blacklist [21:08] smoser: indeed, I've been purging python2 from my autopkgtest xenial cloud images for a long time [21:09] cjwatson, thank you. [21:09] pitti, well, we had made it in wily [21:09] but then 1 week before release, we got python2 back [21:13] pitti: it's not actually blocking network-online.target and I don't know if it actually ever runs [21:14] sudo systemctl status NetworkManager-wait-online.service shows no log data at all... [21:15] 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] gQuigs: ah, so you mean that we don't actually enable NetworkManager-wait-online.service [21:15] 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] bug 1430280 [21:16] bug 1430280 in NetworkManager "NetworkManager-wait-online.service not enabled after package installation" [Medium,Confirmed] https://launchpad.net/bugs/1430280 [21:16] (firefox awesome bar to the rescue!) [21:16] gQuigs: it ran on my system, but maybe I configured it manually at some point [21:17] gQuigs: but the intention was that it got enabled automatically since vivid [21:18] Shouldn't devel-* point to xenial and not to wily? [21:18] err, for sure [21:19] Hmm, on de.archive it points to xenial, but on archive.ubuntu.com it points to wily [21:19] pitti: awesome, I'll see about making a debdiff for that then. thanks! [21:20] gQuigs: ah, was that accidentally dropped later in a merge or so? [21:25] pitti: looks like it, it doesn't run by default [21:25] and I had no idea that sudo systemctl enable NetworkManager-wait-online.service == the add-wants given the before line [21:25] makes sense though [21:33] gQuigs: no, enable doesn't look at the Before= line, it creates the symlinks for the [Install] section, i. e. the WantedBy === nobuto_ is now known as nobuto [23:44] pitti, still awake? [23:46] It's a pitti if he isn't. [23:46] considering he's often starting his day in four or five hours, it's probabl best if he's still sleeping :)