=== jamesh_ is now known as jamesh === ValicekB_ is now known as ValicekB === nudtrobert1 is now known as nudtrobert === nudtrobert1 is now known as nudtrobert === balloons is now known as Guest45465 === Guest45465 is now known as balloons_ === nudtrobert1 is now known as nudtrobert === nudtrobert1 is now known as nudtrobert [06:23] Good morning [06:24] popey: how is dropbox involved in a caja <-> apport crash? [06:25] elbrus: no, it magically started working, apparently some dependency got uploaded/synced [06:27] slangasek: I saw the kernel autopkgtest install failure on Friday, on my radar for today; if autopkgtest itself installs test deps it falls back to removing the pin, but that doesn't work if tests themselves call apt [06:27] slangasek, infinity: yeah, I mentioned that in the announcement -- right now we dist-upgrade to -proposed as we have a lot of packages in the base image without any tests [07:03] @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: Mirv === ahoneybun_ is now known as ahoneybun === asac` is now known as asac [08:09] good morning [08:24] Good morning :) [08:34] pitti, dropbox has shell integration, I'm speculating, but it locks up every time I touch dropbox folders in caja [08:35] pitti, by "shell integration" I mean hooks into the file manager === mthaddon` is now known as mthaddon [09:04] Hi. [09:16] apw: can you see what's wrong in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux/20151116_071523@/log.gz ? [09:17] pitti, looking [09:18] * pitti will look at the "crash" regression, that's infrastructure related [09:18] pitti, END ERROR ubuntu_qrt_kernel_aslr_collisions.test-kernel-aslr-collisions.py [09:18] pitti, we've got a whine out to #security about that one failing _a_lot_ [09:18] apw: want me to push the retry knob? [09:19] pitti, let me check if it always fails [09:19] apw: I retried it once more, the previous failures were due to util-linux [09:19] let's see [09:19] it passed on 4.2.0-17.21 [09:20] ok thanks [09:20] apw: and it passed on i386 too [09:20] otherwise I'll hint it to unblock binutils [09:20] then its likely random when it fails, i have someone looking to see if we can make it work better and quicker [09:20] but yes, if its blocking something in -proposed it is known and very likely not real [09:20] apw: I fixed the "apt get source" case of "Temporary failure resolving" btw, the other is still on my list [09:21] apw: thanks for checking; I had a hard time spotting the error in the log [09:21] and cirtianly the kind of error which means "we are less secure against attacks" than "functionally broken" [09:21] pitti, yeah they are all autotest under the hood so "END\ " is your search term [09:21] good to know [09:27] good morning [09:28] Hi, i have question. Do you mind if i discussed here. === lionel_ is now known as lionel [09:29] I don't know what's wrong with my gnome-terminal. It is getting vanished all of sudden (gnome-terminal). when ever i am trying to open it. [09:31] pitti, do you happen to know the launchpad project powering geoip.ubuntu.com [09:31] ? [09:34] pitti, i have asked for the "END"s to be summarised at the end of the run before exiting, much as adt run does [09:47] tvoss, there are https://launchpad.net/ubuntu-geonames and https://launchpad.net/ubuntu-geoip but unsure that includes the geoip server side [09:48] seb128, ack [09:48] ted or evan probably know better [10:04] 4~/win last [10:24] morphis, in the bluez5 transition (specifically on touch) do we plan to add support for other device types? I'd like to have joypad support in if possible? [10:26] popey: that depends, generally everything should be the same as before [10:27] popey: but should be a lot easier to add new ones now [10:27] popey: joypad, never heard of it before, it is a special gamepad? [10:28] morphis, no, just another word for the same thing [10:28] pretty sure "joypad" is what bluetooth calls them [10:29] mmm, joypad [10:30] popey: which bt profiles does it support? [10:30] presumably it's just a HID device [10:30] it is [10:30] utlemming: would it be possible to manually publish a more up to date xenial cloud image? [10:30] with lots of buttons and other interesting things [10:33] popey: good, than this maybe just need a small adjustment in the settings app [10:41] morphis, would be good for a demo I wanted to make for the converged phone, playing a game with a bluetooth controller. [10:42] popey: when do you want to do the demo? [10:43] Not any time soon. [10:44] Post OTA-9 for example [10:55] popey: good [10:55] popey: we're going to land bluez5 support in a bit [10:56] popey: I can push up a MP after that for you to test [10:57] morphis, great, thanks. [11:21] pitti: hi, can you please move language-pack-ja-base and language-pack-gnome-ja-base from trusty-proposed to trusty-updates? we received such unmet dependency bug reports recently. [11:21] such as bug #1512262 [11:21] bug 1512262 in language-pack-gnome-ja-base (Ubuntu) "language-pack-gnome-ja-base 1:14.04+20150804 not published in trusty-updates, cause language-pack-gnome-ja installation error" [Undecided,Confirmed] https://launchpad.net/bugs/1512262 [11:21] and bug #1511405 [11:21] bug 1511405 in language-pack-ja (Ubuntu) "Cannot install package language-pack-ja" [Undecided,Confirmed] https://launchpad.net/bugs/1511405 === bigon_ is now known as bigon [11:36] nobuto: done, sorry about that [11:36] pitti: brilliant! no problem. === s1aden is now known as sladen [12:25] cjwatson: hah, now LXC has started acting up for me as well, I can't start wily or xenial containers [12:25] Failed to create root cgroup hierarchy: Permission denied [12:25] Failed to allocate manager object: Permission denied [12:26] cjwatson: sorry, can't remember any more -- was that what you were seeing? [12:26] pitti: no, I was seeing http://paste.ubuntu.com/13247579/ [12:27] ah right, ns/mnt [12:48] mariadb-10.0 is on 10.0.22-0ubuntu1 in xenial's release pocket and 10.0.22-1 in xenial-proposed which FTBFS on some architectures so isn't migrating. The Debian maintainer will work on it in Debian. Will subsequent uploads to sid autosync? That is: does the autosync avoid stepping on merges by examining the release pocket or the proposed pocket? [12:51] rbasak: It takes the newest in release or proposed. [12:51] rbasak: So subsequent uploads should auto-sync, yes. [12:51] rbasak: (The code is auto-sync in lp:ubuntu-archive-tools) [12:52] cjwatson: OK, thanks! [13:08] hi everybody, we have a bug and ask ourself what the right approach is #LP 1516543 [13:08] Launchpad bug 1516543 in dpdk (Ubuntu) "dpdk-init depends on executables in /usr/bin" [Undecided,New] https://launchpad.net/bugs/1516543 [13:08] Eventually we could: a) just add a path to /usr/bin/ b) fix the script to not rely oon /usr/bin (more complex) [13:08] is there anything against a) in terms of usual policy or best practise? [13:09] cpaelzer: is it an init.d script or something else? [13:09] cpaelzer: it seems pretty common for init.d scripts to set their own PATH at the top. [13:09] yes, it is an init script [13:09] Debian policy doesn't seem to say much about it. [13:09] rbasak that sounds good as it indicates it is somewhat common [13:09] I only know of https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html which is about maintainer scripts and says: [13:09] "Programs called from maintainer scripts should not normally have a path prepended to them. Before installation is started, the package management system checks to see if the programs ldconfig, start-stop-daemon, and update-rc.d can be found via the PATH environment variable. Those programs, and any other program that one would expect to be in the PATH, should thus be invoked without an absolute pathn [13:09] ame. Maintainer scripts should also not reset the PATH, though they might choose to modify it by prepending or appending package-specific directories. These considerations really apply to all shell scripts." [13:10] But maintainer scripts are called from a better defined environment (dpkg). [13:10] init.d scripts can't rely on much, so perhaps deviating from that and setting PATH manually is fine. [13:10] One thing to bear in mind is that systemd units don't do any path expansion, so you end up having to execute specific paths for that anyway. My solution for things I'm upstream for is to generate all the init files and substitute @bindir@. [13:10] rbasak, yeah I took a loog and you are right a lot of PATH= in /etc/init.d [13:11] e.g. http://git.savannah.gnu.org/cgit/binfmt-support.git/tree/init [13:12] I'm not really wild about hardcoding that way, but that ship has sailed regarding systemd so we might as well be consistent, and it's fairly tolerable if the substitution is automatic. [13:12] At least if the executable is within your own package. [13:13] Ah, but this bug implies that maybe we're talking about standard utilities in /usr/bin/ that aren't part of dpdk. [13:13] cjwatson - right [13:13] head and cut [13:13] for some text processing [13:14] In that case, yeah, I'd tend to agree that ensuring that the directories you need are on PATH is OK, provided that you can guarantee that even if /usr is a separate mount it's always available by the time your init script runs. [13:15] smb, is dpdk be late enough in terms of dependencies to assume mounts are ok atthe time? [13:15] cpaelzer: so in this bug, systemd is calling the init.d script and not giving it a sane path? That's a shame. [13:15] I presume it's intentional if it is, but I don't like it :-( [13:15] rbasak, well I trust jamespages initial check that it only provides /bin and /sbin [13:15] never checked that detail of systemd [13:16] cpaelzer, Not really sure... the intention was to be relatively early to take away the nics as soon as possible [13:17] rbasak, smb - well then for simplicity lets consider dropping head&cut - any votes for the tool of choice? [13:17] sed ? [13:18] systemd.exec(5) claims that systemd uses a fixed PATH of "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", which would be OK here. [13:18] sed is usually pretty good for this kind of thing. [13:18] * smb wonders whether cloud-images differ there... [13:19] cjwatson - hmm, interesting find on systemd.exec [13:19] jamespage, are you around to share what you have seen in detail? [13:19] cjwatson, I think that should be possible and would combine two callouts into one [13:19] cjwatson: would that apply for ExecStart? [13:19] I didn't realise before but that's how this script is being called - not init.d [13:20] cpaelzer, I hit that error in a backport of dpdk to 14.04 - I need to reconfirm it on 15.10/16.04 as its possible that its working in later releases [13:20] Ah, no systemd. [13:20] rbasak, I tried to provide both ways [13:20] cpaelzer, that said this was not as startup - it was just calling the init script with 'start' [13:20] Ah, that makes more sense. [13:20] And there's the culprit [13:20] PATH="/sbin:/bin" [13:21] I set that to include /usr/bin and everything sprang to life [13:21] In debian/dpdk.init which ends up as /etc/init.d/dpdk [13:21] Sorry, I had completely misunderstood the problem. [13:21] There we go. But if it's early, using sed is still (overall) simpler. [13:21] rbasak, you still solved it faster than we did :-) [13:21] Hi, the files in http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/ are from Nov 4th. The kernel there is 3.13.0-67-generic, but the latest kernel is already -68 since Nov 10th. Any reason why the installer was not regenerated? [13:22] let me try create an sed to make sure we would work on the conditions of not yet mounted /usr as cjwatson suggested [13:22] infinity,apw: ^- fancy doing a trusty d-i update? [13:22] but I'd still suggest we add that to the path in dpkg.init to not search for the issue again [13:22] cpaelzer, Ok, so this sounds like another item on my list [13:22] smb, let me give it a try [13:22] Related to me mariadb question earlier. We autosync from sid always nowadays, right? Even for LTses? [13:23] I'm done with paperwork [13:23] rbasak: Yes. [13:23] OK, thanks for confirming. [13:23] rbasak: Auto-syncing from testing turned out to be more trouble than it was worth. [13:23] smb, and that simple test probably needs a full day and would be bad to start now [13:23] smb, how would you prefer the patch ? [13:24] smb, it is not part of your git - hmm - merge proposal to lp:ubuntu/wily/dpdk then ? [13:24] on that bug? [13:24] cpaelzer, well this and probably the other things would be updates to the wily version as well... I can live with a simple diff [13:25] ok I'll post something in the bug later on and assign it to you then [13:25] smb, ok ? [13:25] cpaelzer, ok, wfm [13:26] rbasak, sorry but I can't set it to triaged, could you ? [13:27] cpaelzer, looks like I could too... [13:27] cpaelzer, done [13:28] cpaelzer, well only the dpdk part... lets ignore the cloud-archive half... :-P [13:28] smb, I agree [13:29] smb, cpaelzer: maybe an idea to throw the dpdk packaging into git and maintain it from there now? [13:29] (if we weren't already) [13:30] rbasak, smb, I'd love that [13:30] rbasak, well it is [13:30] rbasak, lp git... actually [13:30] smb, is https://git.launchpad.net/~ubuntu-server/dpdk what you work on ? [13:30] cpaelzer, yep... there is a wily branch and we could add a xenial one [13:31] smb: we should have upstream branches and tags that match the Ubuntu uploads. [13:31] cpaelzer, master I would use as upstream [13:31] Also ~ubuntu-server is available for everyone to force push to, including potentially vandals. [13:31] I'm not sure of a good solution to that issue, since you won't be able to push to ~ubuntu-server-dev. [13:31] We could have a separate ~dpdk-dev launchpad group I guess, but that seems overkill. [13:32] rbasak, let keep it there in SMBs hope to get rid of it one day anyway [13:32] cjwatson, thanks for hte heads up [13:32] and then move it to ~ubuntu-server-dev [13:33] cpaelzer, rbasak, I put it there on rbasak's request, but yeah maybe some group that is a bit more closed [13:33] The problem is that ~ubuntu-server-dev is a DMB-managed group and cpaelzer and smb won't be able to push there. [13:34] OTOH you could submit merge proposals and acceptance would effectively be an endorsement for upload of those changes. [13:35] smb, cpaelzer: I'm happy for you to decide what workflow you prefer between yourselves, and I'll support that ;) [13:36] rbasak, I guess there is one thing how to do it for now but maybe another thing how to properly do it for the future [13:37] In the future Launchpad will do something dgit-like and it'll all be like a bed of roses :) [13:39] rbasak, thorny roses? === Spads_ is now known as Spads [13:39] No, nice-smelling ones :) [13:39] with thorns [13:40] :) [13:40] cpaelzer, btw I just pushed tags and current upstream to lp [13:44] smb: it would be useful to have packaging tags that correspond to Ubuntu uploads. Eg. ubuntu/2.0.0-0ubuntu1 [13:45] rbasak, yeah now that there is an actual upload that makes sense === lool- is now known as lool [14:34] Odd_Bloke: I don't know if you remember, but there's a missing --rename in the dpkg-divert handling for grub-probe in the cloud images [14:34] Odd_Bloke: It's fixed in the patch set that landed in livecd-rootfs in the archive, but do you know if it might be possible to produce at least fixed wily/arm64 cloud images without having to wait for the full migration to LP to finish? [14:35] Odd_Bloke: I ask because it's currently blocking upgrading arm64 scalingstack guests to wily, which we'd like to do as part of the "flail desperately until we find something that makes them more stable" plan === tyhicks` is now known as tyhicks === elopio_ is now known as elopio === balloons_ is now known as balloons [15:19] slangasek, or infinity, do you plan on addressing my comment in https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1508759 ? [15:19] Launchpad bug 1508759 in distro-info-data (Ubuntu Wily) "Update to include xenial" [Medium,Fix released] [15:19] i'm guessing you just didn't see it. but we really should fix that completely. === JanC_ is now known as JanC [15:22] smoser: if you want to upload, I'm happy to process the SRUs [15:24] k. [15:32] slangasek, uploaded. [15:38] cjwatson: I'm sprinting this week, would you mind filing a cpc-core bug and assigning it to me? [15:39] cjwatson: (I should be able to get to it, but I'll lose track of it amongst all the other stuff happening otherwise) [15:53] marga: The installer doesn't need to be revved with every kernel bump. [15:56] smoser: I only see an upload in wily; was that the only one that was missing the full name? [15:56] infinity, uhm, but if you don't then errors like the one I mentioned in #u-kernel happen (i.e. update-initramfs triggered by dkms at the end of the installer fails, due to the running kernel not being installed in the chroot) [15:57] marga: Guessing you're using a custom preseed with dkms? I would consider that a dkms bug we should look at, if it tries to generate for a kernel that's not installed. [15:57] slangasek, correct. [15:57] everything else was right. [15:57] wily went in before xerus was released as a name. [15:58] marga: Anyhow, there will be a new d-i sometime this week for other reasons, but we don't rev stable d-i builds every single kernel. [15:58] then the srus got the real name [15:58] infinity, yeah, a custom preseed that pulls in additional packages (in this case it's nvidia-dkms). I guess the bug might be in update-initramfs [15:58] (the package isn't called nvidia-dkms, I meant to write nvidia's dkms package) [15:58] marga: Err, yes, update-initramfs. Do you have a log of the issue? [15:59] Yes, sec [15:59] marga: FWIW, while we do update trusty's d-i ona fairly regular basis because we build dailies from it, we almost never update d-i in non-LTS stables (vivid, wily, etc), so this is a bug that should be filed and fixed. [15:59] marga: Can you file a bug in initramfs-tools and point me at it? [16:00] yeah, if you are sure that's it [16:00] I'll give you paste of the error in a sec [16:01] infinity, http://paste.debian.net/333067/ [16:02] Should I go ahead and open the bug? [16:02] marga: Well, that'll either be a bug in initramfs-tools or in dkms for calling it incorrectly, but do file the bug on one of them and give me the #, I can figure it out when I have some time. [16:03] ok, thanks === wendar_ is now known as wendar [16:30] ScottK: wanted to check with you on backports - bug 1515710 and bug 1516259 - critical for openstack swift. If there is additional validation I can provide, I will be happy to [16:30] bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/1515710 [16:30] bug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/1516259 [16:44] chiluk_, that trusty update of coreutils is ftbfs [16:45] really? === chiluk_ is now known as chiluk === henrix_ is now known as henrix [16:46] I know I ran build tests, because I'm running the package on my desktop as we speak [16:46] mterry are you building with pbuilder again? [16:47] chiluk, I mean it's ftbfs in the buildd servers, when it hit trusty-proposed [16:47] huh... but it builds for you locally right? [16:49] yeah mterry, just verified, I definitely built that debdiff locally... coreutils is such a pita. [16:49] infinity, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1516705 [16:49] Launchpad bug 1516705 in initramfs-tools (Ubuntu) "update-initramfs fails during debian-installer if running kernel doesn't match installed kernel" [Undecided,New] [16:50] Sorry for the delay, got caught up in other things [16:50] chiluk, it doesn't build for me locally in pbuilder, as we discussed. I never did the sbuild setup, since I figured that was a PITA for me if you had already done it [16:51] yeah pbuilder does something weird with it.. [16:52] E: Build failure (dpkg-buildpackage died)... well that's weird [16:53] mterry 1 of 423 tests failed [16:53] marga: S'ok, won't be as bad as the delay for me investigating/fixing. :P [16:53] marga: Thanks for filing, though, I'll look when I have a bit of time to context switch out of mainframe land. [16:53] infinity, that's fine [16:53] mterry FAIL: tests/df/total-unprocessed.sh [16:54] You got me thinking with the non-lts thing [16:54] This issue used to happen for us A LOT when we were using the hardware enablement installers for precise. But we are still using trusty's installer for trusty and it hasn't happened in over a year or so, I guess this is why. [16:55] mterry .. I'm rebuilding again now... just to sanity check.. [16:55] marga: Without looking, I suspect the bug is that dkms triggers an initramfs build for all kernels, not just the one it built modules successfully for, but I'll have to investigate a bit to see what's really happening. [16:55] pitti, who can we asked to get https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1491729/ moving a bit further on the SRU process? [16:55] Launchpad bug 1491729 in dkms (Ubuntu Wily) "dkms: add module build ordering for ZFS on Linux" [Undecided,New] [16:55] mterry PASS: tests/df/total-unprocessed.sh [16:55] worked for me. [16:55] very confusing. [16:55] chiluk, I suspect it will work for you locally again. I think this is a difference between buildd and local sbuild. yeah [16:56] yeap [16:56] infinity, dkms actually realizes that it's in this weird situation and does the right thing with regards to module building, so I think the fault lies at update-initramfs for not realizing. [16:56] I'll take a closer look at the test. [16:57] marga: Well, no. If dkms knows what kernels it built for, it should only be triggering update-initramfs for those kernels, IMO. But I could be off, and it could be using a generic trigger that just sucks at its job. We'll see when I dig. [17:07] hmm mterry it appears as if the only difference is df is printing directional ticks and compare on the buildds isn't liking that. [17:07] mterry give me a sec to see if I can figure out if I did that or if we can change that somehow. [17:10] mterry yeah it has something to do with the smart quotes being printed by df.. [17:10] which is super odd. [17:10] I'm not seeing that out of sbuild, but am seeing it when I run the test manually [17:10] which is also nuts. [17:10] chiluk, well... good that you can reproduce? [17:11] yeah give me a sec to see if I can fix it so we don't have to disable the tests. [17:13] That'll probably be LANG=C vs. LANG=C.UTF-8 [17:13] or similar [17:13] though launchpad-buildd currently uses LANG=C, so the symptoms seem backwards [17:14] unless I'm misunderstanding [17:15] Odd_Bloke: OK, sure - filed https://bugs.launchpad.net/cpc-core/+bug/1516715 but I can't assign it to you because I'm not a cpc-core bug supervisor [17:15] Error: launchpad bug 1516715 not found [17:24] thanks cjwatson.. I think you are on the right track.. I'll try setting the LANG explicitly in the test case, and hopefully that will help [17:26] chiluk: Yep, sounds sensible [17:28] cjwatson, I think it's a new test, but setting LANG=C in the test itself seems to resolve the issue. [17:29] mterry .. do I need to create a new bug to fix the FTBS? [17:31] cjwatson: what's the process for fixing ftbs [17:32] when it's failing in -proposed? open a new bug, increment source version reupload? [17:33] chiluk: I'm sure I'm out of date, but I can't see why a new bug is needed [17:34] cjwatson, mterry, so what's required here? [17:35] chiluk: just upload a fix? [17:35] I'm not coredev yet.. [17:35] well, get a sponsor to do so [17:35] but I'll upload a new debdiff.. [17:36] does the debdiff have to be versioned newer than the ftbs? [17:36] you can't reuse the same version, indeed [17:36] ok.. I wasn't sure if that was required.. [17:36] use 8.21-1ubuntu5.3 [17:36] that's newer.. [17:36] the reason it shouldn't need a new bug is that the bug is principally required for tracking verification, and a build failure fix to something that's already on its way through -proposed for a different reason doesn't need separate verification [17:37] chiluk: err ... yes it is [17:37] I meant it to be [17:37] your debdiff should be on top of 8.21-1ubuntu5.2, and should result in a new package versioned 8.21-1ubuntu5.3 [17:38] Ok.. that's what I thought. [17:38] thanks. [17:38] because you cannot reuse 8.21-1ubuntu5.2, and there's certainly no reason to pretend it never existed [17:38] right.. [17:54] mterry arges ...fix for ftbfs uploaded https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871 [17:54] Launchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,Fix committed] [17:55] it seems to resolve it when run outside of a chroot on my local machine where the lang is set to en_US.UTF-8 [17:55] do you want me to run a test build on the buildd's first? I really don't think that should be necessary [17:59] pitti, i added that [!ppc64el] test dependancy to fix the ppc64el linux package install failures, but it seems it is not valid [17:59] pitti, if i am reading this dep_re correctly it only supports positive [arch] lists [18:00] dep_re where? [18:01] autopkgtest lib/testdesc.py [18:02] which isn't a big deal i guess we don't change the list very often [18:02] chiluk, I can try uploading in a bit [18:02] chiluk, sorry was afk for a quick errand [18:02] no worries mterry we all have life to deal with. [18:03] mterry I uploaded it to my ppa in case you want to wait a sec to see if it builds. [18:03] mterry should be almost done [18:03] chiluk, oh nice [18:04] mterry coreutils has been such a pita.. [18:04] chiluk, :) every package is its own sweet little pile of pain [18:05] mterry still FTBFS. [18:05] maybe I forgot to add it to 00list [18:05] chiluk, I'm so glad Debian got behind quilt instead of dpatch or others :) [18:06] Still can forget to add to series, but just much harder to mess up [18:06] yep that was my problem.. working too fast. [18:41] well crap mterry still failing... === elbrus_ is now known as elbrus [18:55] mterry it looks like the testcase is failing, but after playing around a bit it looks like there's a similar regression somewhere.. where df -t nfs isn't reporting filesystems. [18:55] so that's not good. [18:55] chiluk, hrm [18:56] that should probably be remedied. [18:56] chiluk, so yay for tests :) [18:56] yeah.. so the the testcase is incorrectly failing as far as I can tell. [18:56] there's definitely something going odd. [18:56] chiluk, oh sorry I thought you said there was a real regression [18:56] yeah there is a real regression [18:57] the testcase didn't really find it. [18:57] chiluk, ah :) [18:57] but I found it while playing around with the commands the testcase is testing. [18:58] chiluk, so yay for busted tests! :) [18:58] yeah something like that [18:58] chiluk, this regression is trusty-specific? [18:58] it's all in similar logic. [18:58] haven't figured that out yet.. but I'll definitely check upstreams. [18:59] basically df -t nfs isn't finding nfs shares. [18:59] so that's odd. [18:59] hm [18:59] but the test case somehow finds a - mount. [18:59] which is beyond me. [18:59] anyhow I'll need a few to get this squared away. [19:03] mterry looks like wily's affected as well. [19:04] I guess it's better for us to discover it than someone else .. [19:04] it might even be an upstream issue. === Guest29831 is now known as mfisch === mfisch is now known as Guest80875 [19:05] cjwatson: Thanks for that; looks like utlemming has picked it up. :) === alai888 is now known as alai === dpm is now known as dpm-afk [21:09] bdmurray, hi, about bug 1494442, could you count the crashes for ubuntu-touch/rc-proposed/* instead of ubuntu-touch/devel? [21:09] bug 1494442 in Canonical System Image "Turn crash generation off by default for phone on stable channel" [High,Fix released] https://launchpad.net/bugs/1494442 [21:10] jibel: where * = ubuntu or something else? [21:11] bdmurray, I'd be interested in ubuntu, bq-aquaris.en and meizu.en [21:13] jibel: updated [21:13] bdmurray, thanks [21:14] no problem [22:18] mterry so I just compiled upstream coreutils, and df has the same issue with remote filesystems.. [22:25] tsg: you might check with micahg. [22:26] thanks ScottK [22:27] micahg: I was wondering about bug 1515710 and bug 1516259. This is a fairly simple backport and I can provide any validation needed (already have validated the wily pkgs work on trusty and precise) [22:27] bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/1515710 [22:27] bug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/1516259 [22:44] mterry, so after stepping through the code, it looks like the move to /proc/mountinfo has had some odd side effects. [22:45] this is because the filesystem type is now more accurate.. for example it's no longer just nfs , it's nfs4. [22:46] so I don't think this is a regression.. more of a change in behavior. [22:46] but one that's necessary. [22:46] chiluk, ok [22:46] chiluk, so we don't do anything? [22:46] mterry do you know the correct way to disable a test? [22:47] chiluk, we can't fix the test? [22:47] I'm still trying to figure out why it's failing. [22:47] I'm basically not getting the same output .. [22:49] chiluk, well there's no standard way to disable a test, because there are so many frameworks. Often a patch to comment it out. Or a debian/rules adjustment to skip it if possible. But skipping tests is obviously the least preferable way to solve the problem [22:50] yeah.. I'll look a little closer.. but setting the LANG=C in the test directly didn't seem to help [22:52] chiluk, odd [22:52] chiluk, dumb question , but did you forget to maybe export it, instead of just set it? [22:53] well looking at the build log.. it seems that we are actually getting output from "df --local -t nfs --total ." from within the buildd. [22:53] where the error is expected. [22:54] it might be a cgroups related failure. [22:54] mterry http://pastebin.ubuntu.com/13303587/ that's the part that's causing the failure. [22:55] chiluk, so is that just because it's using nfs instead of nfs4? [22:55] it almost makes me wonder if the filesystem being mounted to / in the buildd is somehow local and nfs. [22:56] cjwatson, are the buildd's run under kvm or cgroups? [22:56] df shouldn't have any outpu on that test. [22:56] but something is weird enough about the buildds that it gets confused [22:57] chiluk, I'm going eod, good luck :-/ [22:58] thanks for all the help mterry. === mfisch is now known as Guest73509 [22:59] chiluk: check the build logs, there's some hints about what it does; iirc all the builders are virtualized these days, but within those VMs, they also use chroots, managed by an sbuild that may or may not be similar to the sbuild that we use on our dev workstations [23:00] yeah.. that's the weird thing.. sbuild succeeds locally for me. [23:00] sarnold: it's something particular to the buildds [23:00] sarnold: see http://pastebin.ubuntu.com/13303587/ [23:01] sarnold basically the testcase is expecting df to fail. [23:01] but for some odd reason it's working fine at least on trusty [23:01] that didn't get hit on wily or vivid [23:01] which is also strange [23:01] chiluk: i'm quite surprised that --local -t nfs doesn't throw a fit [23:02] yeah it's supposed to. [23:02] and it does for me locally [23:02] but not on the buildds [23:02] which is why it's so odd. [23:03] chiluk: that -is- odd :) that's a good one, hehe; can you plop a 'strace' in front of that thing and try to figure out the series of systemcalls it's working with? [23:04] sarnold it's just going to be processing /proc/mountinfo [23:04] I know this code fairly well at this point. [23:04] chiluk: ltrace then? [23:04] chiluk: heh, sorry to hear that :) [23:04] hah yeah.. me too. [23:06] sarnold: df doesn't really make any library calls.. it statically includes gnulib. === cjwatson_ is now known as cjwatson [23:10] chiluk: Speaking as a heavy gnulib user, gnulib serves two purposes: it provides replacement functions if autoconf says that something's missing from the system, and it provides various utility functions of its own. For functions in the former category, seeing a function in included gnulib source does *not* imply that df won't prefer the version from libc if it works properly. [23:10] The point of gnulib isn't to statically link libc into everything that uses it :-) [23:11] cjwatson, I said df statically links with gnulib not libc [23:12] chiluk: Yes, but the bits of gnulib that might substitute for library calls that df would otherwise make are basically libc. [23:12]