=== 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
pittiGood morning06:23
pittipopey: how is dropbox involved in a caja <-> apport crash?06:24
pittielbrus: no, it magically started working, apparently some dependency got uploaded/synced06:25
pittislangasek: 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 apt06:27
pittislangasek, 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 tests06:27
Mirv@pilot in07:03
=== 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
dholbachgood morning08:09
bipulGood morning :)08:24
popeypitti, dropbox has shell integration, I'm speculating, but it locks up every time I touch dropbox folders in caja08:34
popeypitti, by "shell integration" I mean hooks into the file manager08:35
=== mthaddon` is now known as mthaddon
pittiapw: 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:16
apwpitti, looking09:17
* pitti will look at the "crash" regression, that's infrastructure related09:18
apwpitti, END ERROR ubuntu_qrt_kernel_aslr_collisions.test-kernel-aslr-collisions.py09:18
apwpitti, we've got a whine out to #security about that one failing _a_lot_09:18
pittiapw: want me to push the retry knob?09:18
apwpitti, let me check if it always fails09:19
pittiapw: I retried it once more, the previous failures were due to util-linux09:19
pittilet's see09:19
pittiit passed on 4.2.0-17.2109:19
apwok thanks09:20
pittiapw: and it passed on i386 too09:20
pittiotherwise I'll hint it to unblock binutils09:20
apwthen its likely random when it fails, i have someone looking to see if we can make it work better and quicker09:20
apwbut yes, if its blocking something in -proposed it is known and very likely not real09:20
pittiapw: I fixed the "apt get source" case of "Temporary failure resolving" btw, the other is still on my list09:20
pittiapw: thanks for checking; I had a hard time spotting the error in the log09:21
apwand cirtianly the kind of error which means "we are less secure against attacks" than "functionally broken"09:21
apwpitti, yeah they are all autotest under the hood so "END\ " is your search term09:21
pittigood to know09:21
LocutusOfBorg1good morning09:27
bipulHi, i have question. Do you mind if i discussed here.09:28
=== lionel_ is now known as lionel
bipulI 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:29
tvosspitti, do you happen to know the launchpad project powering geoip.ubuntu.com09:31
apwpitti, i have asked for the "END"s to be summarised at the end of the run before exiting, much as adt run does09:34
seb128tvoss, there are https://launchpad.net/ubuntu-geonames and https://launchpad.net/ubuntu-geoip but unsure that includes the geoip server side09:47
tvossseb128, ack09:48
seb128ted or evan probably know better09:48
highvoltage4~/win last10:04
popeymorphis, 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:24
morphispopey: that depends, generally everything should be the same as before10:26
morphispopey: but should be a lot easier to add new ones now10:27
morphispopey: joypad, never heard of it before, it is a special gamepad?10:27
popeymorphis, no, just another word for the same thing10:28
popeypretty sure "joypad" is what bluetooth calls them10:28
s1adenmmm, joypad10:29
morphispopey: which bt profiles does it support?10:30
s1adenpresumably it's just a HID device10:30
popeyit is10:30
pittiutlemming: would it be possible to manually publish a more up to date xenial cloud image?10:30
popeywith lots of buttons and other interesting things10:30
morphispopey: good, than this maybe just need a small adjustment in the settings app10:33
popeymorphis, would be good for a demo I wanted to make for the converged phone, playing a game with a bluetooth controller.10:41
morphispopey: when do you want to do the demo?10:42
popeyNot any time soon.10:43
popeyPost OTA-9 for example10:44
morphispopey: good10:55
morphispopey: we're going to land bluez5 support in a bit10:55
morphispopey: I can push up a MP after that for you to test10:56
popeymorphis, great, thanks.10:57
nobutopitti: 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
nobutosuch as bug #151226211:21
ubottubug 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/151226211:21
nobutoand bug #151140511:21
ubottubug 1511405 in language-pack-ja (Ubuntu) "Cannot install package language-pack-ja" [Undecided,Confirmed] https://launchpad.net/bugs/151140511:21
=== bigon_ is now known as bigon
pittinobuto: done, sorry about that11:36
nobutopitti: brilliant! no problem.11:36
=== s1aden is now known as sladen
pitticjwatson: hah, now LXC has started acting up for me as well, I can't start wily or xenial containers12:25
pittiFailed to create root cgroup hierarchy: Permission denied12:25
pittiFailed to allocate manager object: Permission denied12:25
pitticjwatson: sorry, can't remember any more -- was that what you were seeing?12:26
cjwatsonpitti: no, I was seeing http://paste.ubuntu.com/13247579/12:26
pittiah right, ns/mnt12:27
rbasakmariadb-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:48
cjwatsonrbasak: It takes the newest in release or proposed.12:51
cjwatsonrbasak: So subsequent uploads should auto-sync, yes.12:51
cjwatsonrbasak: (The code is auto-sync in lp:ubuntu-archive-tools)12:51
rbasakcjwatson: OK, thanks!12:52
cpaelzerhi everybody, we have a bug and ask ourself what the right approach is #LP 151654313:08
ubottuLaunchpad bug 1516543 in dpdk (Ubuntu) "dpdk-init depends on executables in /usr/bin" [Undecided,New] https://launchpad.net/bugs/151654313:08
cpaelzerEventually we could: a) just add a path to /usr/bin/ b) fix the script to not rely oon /usr/bin (more complex)13:08
cpaelzeris there anything against a) in terms of usual policy or best practise?13:08
rbasakcpaelzer: is it an init.d script or something else?13:09
rbasakcpaelzer: it seems pretty common for init.d scripts to set their own PATH at the top.13:09
cpaelzeryes, it is an init script13:09
rbasakDebian policy doesn't seem to say much about it.13:09
cpaelzerrbasak that sounds good as it indicates it is somewhat common13:09
rbasakI only know of https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html which is about maintainer scripts and says:13:09
rbasak"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 pathn13:09
rbasakame. 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:09
rbasakBut maintainer scripts are called from a better defined environment (dpkg).13:10
rbasakinit.d scripts can't rely on much, so perhaps deviating from that and setting PATH manually is fine.13:10
cjwatsonOne 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
cpaelzerrbasak, yeah I took a loog and you are right a lot of PATH= in /etc/init.d13:10
cjwatsone.g. http://git.savannah.gnu.org/cgit/binfmt-support.git/tree/init13:11
cjwatsonI'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
cjwatsonAt least if the executable is within your own package.13:12
cjwatsonAh, but this bug implies that maybe we're talking about standard utilities in /usr/bin/ that aren't part of dpdk.13:13
cpaelzercjwatson - right13:13
cpaelzerhead and cut13:13
cpaelzerfor some text processing13:13
cjwatsonIn 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:14
cpaelzersmb, is dpdk be late enough in terms of dependencies to assume mounts are ok atthe time?13:15
rbasakcpaelzer: so in this bug, systemd is calling the init.d script and not giving it a sane path? That's a shame.13:15
rbasakI presume it's intentional if it is, but I don't like it :-(13:15
cpaelzerrbasak, well I trust jamespages initial check that it only provides /bin and /sbin13:15
cpaelzernever checked that detail of systemd13:15
smbcpaelzer, Not really sure... the intention was to be relatively early to take away the nics as soon as possible13:16
cpaelzerrbasak, smb - well then for simplicity lets consider dropping head&cut - any votes for the tool of choice?13:17
cpaelzersed ?13:17
cjwatsonsystemd.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
cjwatsonsed is usually pretty good for this kind of thing.13:18
* smb wonders whether cloud-images differ there... 13:18
cpaelzercjwatson - hmm, interesting find on systemd.exec13:19
cpaelzerjamespage, are you around to share what you have seen in detail?13:19
smbcjwatson, I think that should be possible and would combine two callouts into one13:19
rbasakcjwatson: would that apply for ExecStart?13:19
rbasakI didn't realise before but that's how this script is being called - not init.d13:19
jamespagecpaelzer, 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 releases13:20
rbasakAh, no systemd.13:20
smbrbasak, I tried to provide both ways13:20
jamespagecpaelzer, that said this was not as startup - it was just calling the init script with 'start'13:20
rbasakAh, that makes more sense.13:20
rbasakAnd there's the culprit13:20
jamespageI set that to include /usr/bin and everything sprang to life13:21
rbasakIn debian/dpdk.init which ends up as /etc/init.d/dpdk13:21
rbasakSorry, I had completely misunderstood the problem.13:21
cjwatsonThere we go.  But if it's early, using sed is still (overall) simpler.13:21
cpaelzerrbasak, you still solved it faster than we did :-)13:21
margaHi, 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:21
cpaelzerlet me try create an sed to make sure we would work on the conditions of not yet mounted /usr as cjwatson suggested13:22
cjwatsoninfinity,apw: ^- fancy doing a trusty d-i update?13:22
cpaelzerbut I'd still suggest we add that to the path in dpkg.init to not search for the issue again13:22
smbcpaelzer, Ok, so this sounds like another item on my list13:22
cpaelzersmb, let me give it a try13:22
rbasakRelated to me mariadb question earlier. We autosync from sid always nowadays, right? Even for LTses?13:22
cpaelzerI'm done with paperwork13:23
cjwatsonrbasak: Yes.13:23
rbasakOK, thanks for confirming.13:23
cjwatsonrbasak: Auto-syncing from testing turned out to be more trouble than it was worth.13:23
cpaelzersmb, and that simple test probably needs a full day and would be bad to start now13:23
cpaelzersmb, how would you prefer the patch ?13:23
cpaelzersmb, it is not part of your git - hmm - merge proposal to lp:ubuntu/wily/dpdk then ?13:24
cpaelzeron that bug?13:24
smbcpaelzer, well this and probably the other things would be updates to the wily version as well... I can live with a simple diff13:24
cpaelzerok I'll post something in the bug later on and assign it to you then13:25
cpaelzersmb, ok ?13:25
smbcpaelzer, ok, wfm13:25
cpaelzerrbasak, sorry but I can't set it to triaged, could you ?13:26
smbcpaelzer, looks like I could too...13:27
smbcpaelzer, done13:27
smbcpaelzer, well only the dpdk part... lets ignore the cloud-archive half... :-P13:28
cpaelzersmb, I agree13:28
rbasaksmb, cpaelzer: maybe an idea to throw the dpdk packaging into git and maintain it from there now?13:29
rbasak(if we weren't already)13:29
cpaelzerrbasak, smb, I'd love that13:30
smbrbasak, well it is13:30
smbrbasak, lp git... actually13:30
cpaelzersmb, is https://git.launchpad.net/~ubuntu-server/dpdk what you work on ?13:30
smbcpaelzer, yep... there is a wily branch and we could add a xenial one13:30
rbasaksmb: we should have upstream branches and tags that match the Ubuntu uploads.13:31
smbcpaelzer, master I would use as upstream13:31
rbasakAlso ~ubuntu-server is available for everyone to force push to, including potentially vandals.13:31
rbasakI'm not sure of a good solution to that issue, since you won't be able to push to ~ubuntu-server-dev.13:31
rbasakWe could have a separate ~dpdk-dev launchpad group I guess, but that seems overkill.13:31
cpaelzerrbasak, let keep it there in SMBs hope to get rid of it one day anyway13:32
apwcjwatson, thanks for hte heads up13:32
cpaelzerand then move it to ~ubuntu-server-dev13:32
smbcpaelzer, rbasak, I put it there on rbasak's request, but yeah maybe some group that is a bit more closed13:33
rbasakThe problem is that ~ubuntu-server-dev is a DMB-managed group and cpaelzer and smb won't be able to push there.13:33
rbasakOTOH you could submit merge proposals and acceptance would effectively be an endorsement for upload of those changes.13:34
rbasaksmb, cpaelzer: I'm happy for you to decide what workflow you prefer between yourselves, and I'll support that ;)13:35
smbrbasak, I guess there is one thing how to do it for now but maybe another thing how to properly do it for the future13:36
rbasakIn the future Launchpad will do something dgit-like and it'll all be like a bed of roses :)13:37
cpaelzerrbasak, thorny roses?13:39
=== Spads_ is now known as Spads
rbasakNo, nice-smelling ones :)13:39
smbwith thorns13:39
smbcpaelzer, btw I just pushed tags and current upstream to lp13:40
rbasaksmb: it would be useful to have packaging tags that correspond to Ubuntu uploads. Eg. ubuntu/2.0.0-0ubuntu113:44
smbrbasak, yeah now that there is an actual upload that makes sense13:45
=== lool- is now known as lool
cjwatsonOdd_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 images14:34
cjwatsonOdd_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:34
cjwatsonOdd_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" plan14:35
=== tyhicks` is now known as tyhicks
=== elopio_ is now known as elopio
=== balloons_ is now known as balloons
smoserslangasek, or infinity, do you plan on addressing my comment in https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1508759 ?15:19
ubottuLaunchpad bug 1508759 in distro-info-data (Ubuntu Wily) "Update to include xenial" [Medium,Fix released]15:19
smoseri'm guessing you just didn't see it. but we really should fix that completely.15:19
=== JanC_ is now known as JanC
slangaseksmoser: if you want to upload, I'm happy to process the SRUs15:22
smoserslangasek, uploaded.15:32
Odd_Blokecjwatson: I'm sprinting this week, would you mind filing a cpc-core bug and assigning it to me?15:38
Odd_Blokecjwatson: (I should be able to get to it, but I'll lose track of it amongst all the other stuff happening otherwise)15:39
infinitymarga: The installer doesn't need to be revved with every kernel bump.15:53
slangaseksmoser: I only see an upload in wily; was that the only one that was missing the full name?15:56
margainfinity, 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:56
infinitymarga: 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
smoserslangasek, correct.15:57
smosereverything else was right.15:57
smoserwily went in before xerus was released as a name.15:57
infinitymarga: 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
smoserthen the srus got the real name15:58
margainfinity, yeah, a custom preseed that pulls in additional packages (in this case it's nvidia-dkms).  I guess the bug might be in update-initramfs15:58
marga(the package isn't called nvidia-dkms, I meant to write nvidia's dkms package)15:58
infinitymarga: Err, yes, update-initramfs.  Do you have a log of the issue?15:58
margaYes, sec15:59
infinitymarga: 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
infinitymarga: Can you file a bug in initramfs-tools and point me at it?15:59
margayeah, if you are sure that's it16:00
margaI'll give you paste of the error in a sec16:00
margainfinity, http://paste.debian.net/333067/16:01
margaShould I go ahead and open the bug?16:02
infinitymarga: 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:02
margaok, thanks16:03
=== wendar_ is now known as wendar
tsgScottK: 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 to16:30
ubottubug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/151571016:30
ubottubug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/151625916:30
mterrychiluk_, that trusty update of coreutils is ftbfs16:44
=== chiluk_ is now known as chiluk
=== henrix_ is now known as henrix
chilukI know I ran build tests, because I'm running the package on my desktop as we speak16:46
chilukmterry are you building with pbuilder again?16:46
mterrychiluk, I mean it's ftbfs in the buildd servers, when it hit trusty-proposed16:47
chilukhuh... but it builds for you locally right?16:47
chilukyeah mterry, just verified, I definitely built that debdiff locally... coreutils is such a pita.16:49
margainfinity, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/151670516:49
ubottuLaunchpad bug 1516705 in initramfs-tools (Ubuntu) "update-initramfs fails during debian-installer if running kernel doesn't match installed kernel" [Undecided,New]16:49
margaSorry for the delay, got caught up in other things16:50
mterrychiluk, 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 it16:50
chilukyeah pbuilder does something weird with it..16:51
chilukE: Build failure (dpkg-buildpackage died)... well that's weird16:52
chilukmterry 1 of 423 tests failed16:53
infinitymarga: S'ok, won't be as bad as the delay for me investigating/fixing. :P16:53
infinitymarga: Thanks for filing, though, I'll look when I have a bit of time to context switch out of mainframe land.16:53
margainfinity, that's fine16:53
chilukmterry FAIL: tests/df/total-unprocessed.sh16:53
margaYou got me thinking with the non-lts thing16:54
margaThis 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:54
chilukmterry .. I'm rebuilding again now... just to sanity check..16:55
infinitymarga: 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
ckingpitti, 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
ubottuLaunchpad bug 1491729 in dkms (Ubuntu Wily) "dkms: add module build ordering for ZFS on Linux" [Undecided,New]16:55
chilukmterry  PASS: tests/df/total-unprocessed.sh16:55
chilukworked for me.16:55
chilukvery confusing.16:55
mterrychiluk, I suspect it will work for you locally again.  I think this is a difference between buildd and local sbuild.  yeah16:55
margainfinity, 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
chilukI'll take a closer look at the test.16:56
infinitymarga: 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.16:57
chilukhmm 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
chilukmterry give me a sec to see if I can figure out if I did that or if we can change that somehow.17:07
chilukmterry yeah it has something to do with the smart quotes being printed by df..17:10
chilukwhich is super odd.17:10
chilukI'm not seeing that out of sbuild, but am seeing it when I run the test manually17:10
chilukwhich is also nuts.17:10
mterrychiluk, well...  good that you can reproduce?17:10
chilukyeah give me a sec to see if I can fix it so we don't have to disable the tests.17:11
cjwatsonThat'll probably be LANG=C vs. LANG=C.UTF-817:13
cjwatsonor similar17:13
cjwatsonthough launchpad-buildd currently uses LANG=C, so the symptoms seem backwards17:13
cjwatsonunless I'm misunderstanding17:14
cjwatsonOdd_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 supervisor17:15
ubottuError: launchpad bug 1516715 not found17:15
chilukthanks cjwatson.. I think you are on the right track.. I'll try setting the LANG explicitly in the test case, and hopefully that will help17:24
cjwatsonchiluk: Yep, sounds sensible17:26
chilukcjwatson, I think it's a new test, but setting LANG=C in the test itself seems to resolve the issue.17:28
chilukmterry .. do I need to create a new bug to fix the FTBS?17:29
chilukcjwatson: what's the process for fixing ftbs17:31
chilukwhen it's failing in -proposed?  open a new bug, increment source version reupload?17:32
cjwatsonchiluk: I'm sure I'm out of date, but I can't see why a new bug is needed17:33
chilukcjwatson, mterry, so what's required here?17:34
cjwatsonchiluk: just upload a fix?17:35
chilukI'm not coredev yet..17:35
cjwatsonwell, get a sponsor to do so17:35
chilukbut I'll upload a new debdiff..17:35
chilukdoes the debdiff have to be versioned newer than the ftbs?17:36
cjwatsonyou can't reuse the same version, indeed17:36
chilukok.. I wasn't sure if that was required..17:36
cjwatsonuse 8.21-1ubuntu5.317:36
chilukthat's newer..17:36
cjwatsonthe 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 verification17:36
cjwatsonchiluk: err ... yes it is17:37
cjwatsonI meant it to be17:37
cjwatsonyour debdiff should be on top of 8.21-1ubuntu5.2, and should result in a new package versioned 8.21-1ubuntu5.317:37
chilukOk.. that's what I thought.17:38
cjwatsonbecause you cannot reuse 8.21-1ubuntu5.2, and there's certainly no reason to pretend it never existed17:38
chilukmterry arges ...fix for ftbfs uploaded https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/143287117:54
ubottuLaunchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,Fix committed]17:54
chilukit seems to resolve it when run outside of a chroot on my local machine where the lang is set to  en_US.UTF-817:55
chilukdo you want me to run a test build on the buildd's first?  I really don't think that should be necessary17:55
apwpitti, i added that [!ppc64el] test dependancy to fix the ppc64el linux package install failures, but it seems it is not valid17:59
apwpitti, if i am reading this dep_re correctly it only supports positive [arch] lists17:59
cjwatsondep_re where?18:00
apwautopkgtest lib/testdesc.py18:01
apwwhich isn't a big deal i guess we don't change the list very often18:02
mterrychiluk, I can try uploading in a bit18:02
mterrychiluk, sorry was afk for a quick errand18:02
chilukno worries mterry we all have life to deal with.18:02
chilukmterry I uploaded it to my ppa in case you want to wait a sec to see if it builds.18:03
chilukmterry should be almost done18:03
mterrychiluk, oh nice18:03
chilukmterry coreutils has been such a pita..18:04
mterrychiluk, :)  every package is its own sweet little pile of pain18:04
chilukmterry still FTBFS.18:05
chilukmaybe I forgot to add it to 00list18:05
mterrychiluk, I'm so glad Debian got behind quilt instead of dpatch or others  :)18:05
mterryStill can forget to add to series, but just much harder to mess up18:06
chilukyep that was my problem.. working too fast.18:06
chilukwell crap mterry still failing...18:41
=== elbrus_ is now known as elbrus
chilukmterry 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
chilukso that's not good.18:55
mterrychiluk, hrm18:55
chilukthat should probably be remedied.18:56
mterrychiluk, so yay for tests  :)18:56
chilukyeah.. so the the testcase is incorrectly failing as far as I can tell.18:56
chilukthere's definitely something going odd.18:56
mterrychiluk, oh sorry I thought you said there was a real regression18:56
chilukyeah there is a real regression18:56
chilukthe testcase didn't really find it.18:57
mterrychiluk, ah  :)18:57
chilukbut I found it while playing around with the commands the testcase is testing.18:57
mterrychiluk, so yay for busted tests!  :)18:58
chilukyeah something like that18:58
mterrychiluk, this regression is trusty-specific?18:58
chilukit's all in similar logic.18:58
chilukhaven't figured that out yet.. but I'll definitely check upstreams.18:58
chilukbasically df -t nfs isn't finding nfs shares.18:59
chilukso that's odd.18:59
chilukbut the test case somehow finds a - mount.18:59
chilukwhich is beyond me.18:59
chilukanyhow I'll need a few to get this squared away.18:59
chilukmterry looks like wily's affected as well.19:03
chilukI guess it's better for us to discover it than someone else ..19:04
chilukit might even be an upstream issue.19:04
=== Guest29831 is now known as mfisch
=== mfisch is now known as Guest80875
Odd_Blokecjwatson: Thanks for that; looks like utlemming has picked it up. :)19:05
=== alai888 is now known as alai
=== dpm is now known as dpm-afk
jibelbdmurray, hi, about bug 1494442, could you count the crashes for ubuntu-touch/rc-proposed/* instead of ubuntu-touch/devel?21:09
ubottubug 1494442 in Canonical System Image "Turn crash generation off by default for phone on stable channel" [High,Fix released] https://launchpad.net/bugs/149444221:09
bdmurrayjibel: where * = ubuntu or something else?21:10
jibelbdmurray, I'd be interested in ubuntu, bq-aquaris.en and meizu.en21:11
bdmurrayjibel: updated21:13
jibelbdmurray, thanks21:13
bdmurrayno problem21:14
chilukmterry so I just compiled upstream coreutils, and df has the same issue with remote filesystems..22:18
ScottKtsg: you might check with micahg.22:25
tsgthanks ScottK22:26
tsgmicahg: 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
ubottubug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/151571022:27
ubottubug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/151625922:27
chilukmterry, so after stepping through the code, it looks like the move to /proc/mountinfo has had some odd side effects.22:44
chilukthis is because the filesystem type is now more accurate.. for example it's no longer just nfs , it's nfs4.22:45
chilukso I don't think this is a regression.. more of a change in behavior.22:46
chilukbut one that's necessary.22:46
mterrychiluk, ok22:46
mterrychiluk, so we don't do anything?22:46
chilukmterry do you know the correct way to disable a test?22:46
mterrychiluk, we can't fix the test?22:47
chilukI'm still trying to figure out why it's failing.22:47
chilukI'm basically not getting the same output ..22:47
mterrychiluk, 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 problem22:49
chilukyeah.. I'll look a little closer.. but setting the LANG=C in the test directly didn't seem to help22:50
mterrychiluk, odd22:52
mterrychiluk, dumb question , but did you forget to maybe export it, instead of just set it?22:52
chilukwell 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
chilukwhere the error is expected.22:53
chilukit might be a cgroups related failure.22:54
chilukmterry http://pastebin.ubuntu.com/13303587/  that's the part that's causing the failure.22:54
mterrychiluk, so is that just because it's using nfs instead of nfs4?22:55
chilukit almost makes me wonder if the filesystem being mounted to / in the buildd is somehow local and nfs.22:55
chilukcjwatson, are the buildd's run under kvm or cgroups?22:56
chilukdf shouldn't have any outpu on that test.22:56
chilukbut something is weird enough about the buildds that it gets confused22:56
mterrychiluk, I'm going eod, good luck :-/22:57
chilukthanks for all the help mterry.22:58
=== mfisch is now known as Guest73509
sarnoldchiluk: 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 workstations22:59
chilukyeah.. that's the weird thing.. sbuild succeeds locally for me.23:00
chiluksarnold: it's something particular to the buildds23:00
chiluksarnold:  see http://pastebin.ubuntu.com/13303587/23:00
chiluksarnold basically the testcase is expecting df to fail.23:01
chilukbut for some odd reason it's working fine at least on trusty23:01
chilukthat didn't get hit on wily or vivid23:01
chilukwhich is also strange23:01
sarnoldchiluk: i'm quite surprised that --local -t nfs doesn't throw a fit23:01
chilukyeah it's supposed to.23:02
chilukand it does for me locally23:02
chilukbut not on the buildds23:02
chilukwhich is why it's so odd.23:02
sarnoldchiluk: 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:03
chiluksarnold it's just going to be processing /proc/mountinfo23:04
chilukI know this code fairly well at this point.23:04
sarnoldchiluk: ltrace then?23:04
sarnoldchiluk: heh, sorry to hear that :)23:04
chilukhah yeah.. me too.23:04
chiluksarnold: df doesn't really make any library calls.. it statically includes gnulib.23:06
=== cjwatson_ is now known as cjwatson
cjwatsonchiluk: 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
cjwatsonThe point of gnulib isn't to statically link libc into everything that uses it :-)23:10
chilukcjwatson, I said df statically links with gnulib not libc23:11
cjwatsonchiluk: Yes, but the bits of gnulib that might substitute for library calls that df would otherwise make are basically libc.23:12
chilukI'll check to see if it's making libc calls, but I don't think there's any code for an equivalent to mountlist23:12
cjwatsondf certainly does make library calls.23:12
chilukyes it does..23:12
chilukI"m not arguing that.23:12
cjwatsonBut sure, mountlist is linked in directly.23:12
chilukI just don't think those library calls are affecting this build.23:12
chilukthen again I wont' know till I know.23:13
cjwatsonsarnold: The sbuild in use is nowadays extremely close to that in the archive.  You can find it in ppa:~canonical-is-sa/ubuntu/buildd23:13
chilukcjwatson can you take a look at http://pastebin.ubuntu.com/13303587/ , and tell me why the rootfs comes up as - ?\23:13
cjwatsonsarnold: We're currently in a state where for upcoming xenial-based builders it will be identical.23:14
sarnoldcjwatson: cool, thanks!23:14
=== Guest73509 is now known as Guest80875
cjwatsonchiluk: Not sure just from looking, or from looking at the source - definitely a case where it will be quicker to slap ltrace -S on the front than to try to guess23:17
chilukalrighty will do.23:17
cjwatsonchiluk: The buildd's FS is certainly not NFS.23:18
chilukyeah it's super f-ed up... My locally built version succeeds on that test.. so there's something strange still going on.23:19
cjwatsonchiluk: Each x86 builder instance is an OpenStack instance, so kvm will be involved in there, and then as sarnold says there's sbuild under that (though using sudo chroot rather than schroot for mainly historical reasons).23:19
cjwatsonchiluk: However, if you're seeing this on all architectures in a build for the Ubuntu primary archive, some of them are still just bare metal.23:20
tsimonq2wxl: where?23:20
tsimonq2aw crap, sorry23:20
chilukalright I'll pick this up tomorrow .. I have to meet a friend for dinner.23:21
cjwatsonchiluk: While there isn't an equivalent of mountlist, I believe that mountlist uses various libc functions such as getmntent23:21
chilukcjwatson: yes it used to23:22
chilukbut with the move to /proc/mountinfo and /proc/self/mounts it processes those directly now23:22
chilukwhich may be part of the problem.23:23
cjwatsonWell, I was looking at the version you uploaded, but maybe not very closely.23:23
cjwatsonAnyway, bed.23:23
chilukyeah have fun cjwatson thanks.23:23
chiluki really appreciated it..23:23
chilukcjwatson: afaik all the getmntent calls get ifdefed out.  i will verify that though.23:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!