| sarnold | xnox: is 1430569 supposed to be private security? | 00:41 |
|---|---|---|
| tyhicks | pitti: I published the ecryptfs-utils security updates to our stable releases and kirkland is going to cut a new release and upload it to vivid | 01:11 |
| pitti | hallyn_: user sesssion is still upstart, that didn't change; network config also didn't change, ifupdown and NM continue to work as they ever did | 05:33 |
| pitti | hallyn_: so apparently something failed on your system, can you please file a bug with "journalctl" output and some details? | 05:34 |
| pitti | hallyn_: note that you can also boot with upstart once or permanently, see https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems | 05:34 |
| Unit193 | pitti: Speaking of that, you tried systemd user sessions? Going to be easier to setup for WollyWombat? | 05:34 |
| pitti | hallyn_: bug report for the upgrade failure also highly appreciated | 05:34 |
| pitti | hallyn_: ah ok, do you still have the logs from the failed upgrade? | 05:35 |
| pitti | mdeslaur: cool, thanks for confirming! so it doesn't actually seem to be that hard, we mostly just need a .service for console-setup | 05:35 |
| pitti | Riddell: there's not much information in that bug, need to look myself; I'll respond there | 05:37 |
| pitti | Riddell: tagged for now, so that it stays on my radar | 05:37 |
| infinity | pitti: Riddell's bug may have to do with the bug I fixed in live-build today. Livefses were being created without /sbin/initctl | 05:38 |
| infinity | pitti: So, it might be magically fixed in the next daily. | 05:38 |
| infinity | Maybe. Then again, maybe unrelated. | 05:39 |
| hallyn_ | pitti: i probably do, but i'll look for them in the morning. screen just went blank during do-release-upgrade... | 05:40 |
| pitti | hallyn_: ah, you should still have logs in /var/log/dist-upgrade/ then | 05:41 |
| infinity | pitti: LP: #1430479 is disconcerting. I haven't had a change to reproduce or debug myself, but based on Timo's statement that the libc upgrade is starting systemd (despite it being an upgrade while booted with upstart), I'm assuming "telinit u" is starting systemd, despite the manpage clearly stating it should *re*exec, not start fresh even if systemd isn't PID1. | 05:41 |
| ubottu | Launchpad bug 1430479 in systemd (Ubuntu) "switching init systems together with a libc upgrade kills X and disrupts the upgrade" [Undecided,New] https://launchpad.net/bugs/1430479 | 05:41 |
| hallyn_ | pitti: yup, i see them | 05:41 |
| hallyn_ | oh hey that sounds lik ewhat may have happened to me | 05:42 |
| hallyn_ | except ctrl-alt-fN also didn't work, so wasn't just x | 05:42 |
| pitti | cjwatson: right, not a Launchpad bug, duped to bug 764414; it's essentially a "pick your poison" decision, we can't just make crash reports public by default | 05:42 |
| ubottu | bug 764414 in apport (Ubuntu) "private master bugs are confusing and lead to more duplicate filings" [Wishlist,Triaged] https://launchpad.net/bugs/764414 | 05:42 |
| pitti | cjwatson: it's apport (as the new master bug now) | 05:43 |
| infinity | hallyn_: Well, killing upstart would kill its children, including the gettys on tty[1-6]... It's a miracle any of the system survives when you forcefully replace pid1 at runtime. | 05:44 |
| infinity | (Assuming that's what's happening) | 05:44 |
| pitti | infinity: telinit u> right, I figure we need to teach it to check if upstart is currently running, and redirect the request to upstart; we already do that in "reboot" etc., so it should be relatively simple to fix | 05:45 |
| hallyn_ | infinity: guess so. (was just looking at the 'kills X' part of bug subject) | 05:45 |
| pitti | tjaalton, infinity: is there a bug report to track this? (sorry, I can't track IRC properly these days) | 05:45 |
| tjaalton | #1430479 | 05:45 |
| pitti | ericsnow: pong | 05:45 |
| infinity | pitti: Yeah, I saw the upstart_communicate patch in the systemd source, figured you'd have a good idea on how to make telinit behave too. | 05:45 |
| pitti | tjaalton: ah, thanks | 05:45 |
| tjaalton | pitti: you're subscribed to systemd bugs? | 05:45 |
| infinity | pitti: Bug report was pasted 10 lines up. :P | 05:46 |
| pitti | roaksoax: no, please use "service"; that works with any init system, we still need to support upstart too | 05:46 |
| pitti | tyhicks: ah thanks, then I'll upload the new ecryptfs on top of it today | 05:46 |
| pitti | Unit193: no, I didn't try user sessions at all yet; I mean, we do start systemd --user, but nothing uses that yet | 05:47 |
| tjaalton | pitti: I have another machine in a "pre-upgrade" state so I can test a proposed fix with it | 05:47 |
| pitti | Unit193: so in that sense that'll be an easier transition as you can have upstart and sytsemd run side by side; http://people.canonical.com/~jhunt/systemd/packages-to-convert/2015-03-11.txt is the TODO list for that | 05:47 |
| pitti | infinity: right, that's the patch | 05:48 |
| pitti | tjaalton: yes, I am | 05:48 |
| pitti | *phew*, that's what I call scrollback... and that was just the first channel | 05:48 |
| infinity | Heh. | 05:48 |
| infinity | pitti: Welcome to doing disruptive things? :P | 05:48 |
| pitti | infinity, tjaalton: so, obviously we can't really restart upstart | 05:48 |
| pitti | ah well, we can; upstart-bin ought to suffice | 05:48 |
| infinity | pitti: You could ask upstart to restart via its socket, I assume. | 05:48 |
| pitti | anyway, this sounds reasonably easy to reproduce in a VM | 05:49 |
| infinity | pitti: Which is all 'telinit u' does. | 05:49 |
| pitti | right, shouldn't be fundamentaly different from reboot and such | 05:49 |
| infinity | pitti: Not that it's my place to determine your priorities, but it would probably be good to get this nailed before it bites too many more people. | 05:49 |
| pitti | infinity: agreed | 05:50 |
| Unit193 | pitti: Great, thanks for the link. | 05:50 |
| infinity | Although, loving the segfaults and assertion bugs too. | 05:50 |
| infinity | Who thinks it's sane to *ever* put an assert() in a daemon whose failure mode is a kernel panic? | 05:51 |
| infinity | Oh, that's in systemctl, slightly less evil. | 05:52 |
| infinity | pitti: If my hunch is correct, you shouldn't need to fabricate a particularly complex test case. Just upgrading an upstart system to systemd and running "telinit u" should be enough. | 05:54 |
| pitti | infinity: right, installing systemd-sysv shoudl suffice | 05:55 |
| infinity | pitti: Probably hasn't bitten Debian people because people there have been upgrading by hand and, of course, the by-hand upgrade is "install systemd-sysv && reboot", so no chance for the complex "wait, what is something tried to reexec init?" case to happen. | 05:56 |
| infinity | s/is/if/ | 05:57 |
| pitti | infinity: upgrades to wheezy should now also upgrade to systemd-sysv, so this probably will hit them, too; but they weren't upgrading from upstart, perhaps telinit u behaves differently under sysvinit? | 06:11 |
| infinity | pitti: There's some fallback code in systemctl that seems like it wants to try to do the right thing, so maybe it gets "the right thing" right for sysvinit, but not upstart. Unsure. | 06:12 |
| infinity | pitti: Like I said, I only briefly looked at it, it was a busy day. :/ | 06:13 |
| pitti | tyhicks: hm, nothing new in https://launchpad.net/ubuntu/+source/ecryptfs-utils ? | 06:14 |
| pitti | tyhicks: I mean for vivid | 06:14 |
| infinity | pitti: Oh, nice, I also missed that we reached concensus on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779559 ... I'll whip up a patch for that after I get my late-to-the-party glibc upload done. | 06:16 |
| ubottu | Debian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Wishlist,Open] | 06:16 |
| pitti | infinity: yeah, I think it's looking nicely now | 06:16 |
| pitti | hm, so telinit u under upstart with systemd-sysv installed is a no-op | 06:19 |
| infinity | pitti: No start message in dmesg? | 06:19 |
| infinity | pitti: Then I really wonder what caused Timo's issue... | 06:20 |
| pitti | ah, upstart-{udev,file}-bridge restarts | 06:20 |
| pitti | strace shows that it connects to upstart's socket | 06:20 |
| infinity | pitti: But restaring upstart things is fine, he claims it showed systemd starting in dmesg. | 06:20 |
| * infinity scratches his head. | 06:20 | |
| pitti | I'll set up a trusty VM and check an upgrade from there | 06:21 |
| infinity | pitti: I'm heading to bed, please do post findings on that bug, since it technically appears to be my postinst causing the problem, and I want to get to the bottom of it. | 06:22 |
| pitti | yes, of course | 06:23 |
| pitti | sleep well! | 06:23 |
| infinity | pitti: If you can't find anything weird going on, I'll test myself later and see if I can force the failure. | 06:23 |
| pitti | infinity: do you still know what tjaalton was upgrading from? | 06:23 |
| pitti | earlier vivid/utopic/trusty? | 06:23 |
| infinity | pitti: vivid to vivid. But an old enough vivid that he got a new libc6 and systemd-sysv in the same run. | 06:23 |
| pitti | so somehow trying to connect to upstart failed | 06:25 |
| infinity | pitti: That's possible, yes. I'd still argue that "telinit u" (or systemctl reexec, really) should only *re*exec, and if it can't determine that systemd is PID1, it should not try starting a fresh one. | 06:27 |
| infinity | pitti: After it attempts fallbacks to sysvinit and upstart, etc. | 06:27 |
| pitti | agreed; we might need an additional check for "is systemd running" there | 06:28 |
| pitti | although daemon-reexec just immediately fails too | 06:29 |
| pitti | infinity: hm, when does the postinst actually run telinit? "sudo sh -ex /var/lib/dpkg/info/libc6:amd64.postinst configure 2.19-15ubuntu1" doesn't | 06:31 |
| pitti | oh, on pre-2.19? | 06:31 |
| infinity | pitti: On every upgrade. Unless you're running systemd, because the systemd maintainers claimed it's not needed (which I think is BS, but whatever). | 06:32 |
| pitti | with "2.18-1" it reconfigures locales and checks for things to restart, but doesn't do anything | 06:32 |
| infinity | pitti: Oh, also not in chroots. | 06:33 |
| pitti | hm, it doesn't even get near that code | 06:33 |
| pitti | http://paste.ubuntu.com/10578634/ | 06:33 |
| pitti | stops at debconf | 06:33 |
| pitti | oh, wait | 06:34 |
| * pitti adds a set -x, it reexecs itself | 06:34 | |
| pitti | right, I see it now | 06:34 |
| pitti | ok, off to utopic | 06:35 |
| pitti | hah! | 06:52 |
| pitti | infinity: ok, got it | 06:53 |
| pitti | smoser, utlemming, Odd_Bloke: can we drop the init= from cloud-images now? with it, installing "upstart" and uninstalling systemd-sysv doesn't actually work | 06:57 |
| tjaalton | pitti: yes, earlier vivid from ~2 weeks ago to current | 07:12 |
| pitti | tjaalton: good morning | 07:12 |
| tjaalton | hey | 07:12 |
| pitti | tjaalton: right, so curiously I can't reproduce this on current vivid, but I can now from utopic, see bug | 07:13 |
| pitti | tjaalton: thanks for the report, sorry for the trouble | 07:13 |
| tjaalton | pitti: no worries, it's easy to work around now that I know how :) | 07:14 |
| tjaalton | pitti: another thing.. looks like nfs mounts aren't getting mounted on boot on my systems :) | 07:22 |
| tjaalton | non-kerberized | 07:22 |
| pitti | tjaalton: are you using only NM, or ifupdown? | 07:22 |
| tjaalton | only nm | 07:23 |
| pitti | tjaalton: that's bug 1430280; it has instructions how to fix it locally | 07:23 |
| ubottu | bug 1430280 in network-manager (Ubuntu) "NetworkManager-wait-online.service not enabled after package installation" [Medium,Triaged] https://launchpad.net/bugs/1430280 | 07:23 |
| tjaalton | though on my main desktop/server it has a bridge set up in network/interfacese | 07:23 |
| tjaalton | -e | 07:23 |
| tjaalton | ok | 07:23 |
| pitti | tjaalton: I'm working on the telinit bug first, though | 07:23 |
| tjaalton | sure thing | 07:23 |
| tjaalton | mount -a -t nfs is easy | 07:23 |
| tjaalton | so there's another bug for static networks not getting set up? | 07:25 |
| pitti | tjaalton: I thought you were using NM? | 07:28 |
| pitti | tjaalton: oh, for your bridge? I tested that with a simple bridge and that worked; so I'll need another bug report with your particular configuration | 07:28 |
| tjaalton | pitti: yeah the bridge one | 07:30 |
| tjaalton | will file it | 07:30 |
| tjaalton | against..? | 07:30 |
| pitti | tjaalton: systemd is fine for now, I'll reassign it to ifupdown if appropriate | 07:30 |
| tjaalton | k | 07:31 |
| pitti | (most probably in ifupdown, but not that important) | 07:31 |
| pitti | tjaalton: would be nice if you could check if that reproduces in a VM | 07:31 |
| pitti | so that I can reproduce it | 07:31 |
| tjaalton | okay | 07:32 |
| tjaalton | I should have one ready.. | 07:32 |
| === kickinz1|afk is now known as kickinz1 | ||
| Mirv | pitti: I wonder if you'd be interested in looking at calibre FTBFS against Qt 5.4.1? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+sourcepub/4827668/+listing-archive-extra (calibre uses private symbols so it needs a rebuild) | 07:46 |
| Mirv | pitti: Debian experimental has all of 5.4.1 already | 07:47 |
| pitti | Mirv: in general yes, just this week is a really bad time | 07:48 |
| pitti | Mirv: oh, just a rebuild? that's very simple then | 07:48 |
| pitti | Mirv: at some point I should upload a newer upstraem version to Debian anyway and sync, that'll deal with it | 07:48 |
| Mirv | pitti: just a rebuild, but since it fails to rebuild against 5.4.1 I guess something else is needed too | 07:50 |
| Mirv | pitti: ok, regarding bad time. I can't publish 5.4.1 without the rebuild or it would be stuck in proposed, but I can forward with all the other testing since I suspect it'll take a couple of days before QA signs off 5.4.1 touch wise | 07:50 |
| pitti | oh, that needs some actual work then | 07:52 |
| Mirv | pitti: pyqt5 itself built fine and it's at 5.4.1 in Debian + that PPA (landing-012) | 07:52 |
| Mirv | probably so, "TypeError: getattr(): attribute name must be string" | 07:52 |
| pitti | Mirv: does debian and vivid have the same pyqt? | 07:52 |
| Mirv | pitti: debian experimental plus that landing PPA have the same pyqt5 - which was required to be updated for the new Qt | 07:52 |
| Mirv | no Ubuntu changes in pyqt5 | 07:53 |
| pitti | Mirv: ah, calibre isn't in debian experimental, so it will likely fail to build with that in Debian, too? | 07:53 |
| Mirv | pitti: I'd say it's likely | 07:54 |
| pitti | tjaalton, infinity: ok, I understand bug 1430479 now | 07:54 |
| ubottu | bug 1430479 in systemd (Ubuntu) ""telinit u" under upstart (upstart's Restart command) with systemd-sysv installed runs systemd" [Critical,In progress] https://launchpad.net/bugs/1430479 | 07:54 |
| Mirv | pitti: it's notable though that 2.19.0 rebuilt fine against Ubuntu's Qt 5.4.0, so it's probably something relatively small in pyqt5 5.4.0 -> pyqt5 5.4.1 | 07:55 |
| * pitti invokes jodh | 07:55 | |
| Mirv | pitti: last bit of calibre noise that there's now a bug #1430663 about it | 08:00 |
| ubottu | bug 1430663 in calibre (Ubuntu) "Fails to rebuild against Qt 5.4.1" [Undecided,New] https://launchpad.net/bugs/1430663 | 08:00 |
| pitti | Mirv: thanks (easier to track that way) | 08:03 |
| dholbach | good morning | 08:15 |
| infinity | pitti: Massive *headdesk* on the argv[0] find. | 08:42 |
| pitti | infinity: weren't you supposed to sleep? | 08:42 |
| infinity | pitti: As I said on the bug, we can't go back in time and fix that, so we'll need to just work around it. | 08:42 |
| infinity | pitti: Yes, I'm typing in my sleep. | 08:42 |
| pitti | infinity: well, it's not conceptually wrong as long as you don't take /sbin/init changes into account, but it indeed gets in the way | 08:42 |
| infinity | pitti: It's been conceptually wrong for as long as /sbin/init has been a symlink. | 08:43 |
| pitti | infinity: oh right, we'd need to fix that in trusty's/utopic's upstart too, so perhaps just work around it in systemd's telinit and not forward "u" to upstart at all? | 08:43 |
| infinity | pitti: But maybe the reexec code was written before that was true, and no one caught that it should have been fixed. | 08:43 |
| infinity | pitti: Anyhow, yeah, I think not forwarding the reexec request is probably about the best we're going to manage. I fear this could lead to unclean shutdowns post-upgrade, but I don't know if there's much we can do about that. | 08:44 |
| pitti | infinity: oh, we still need to forward reboot/shutdown etc, just not telinit | 08:45 |
| pitti | "u" | 08:45 |
| infinity | pitti: No, I mean unclean shutdowns because we didn't reexec, and we still have open deleted files and the world is confused and can't umount / sanely. | 08:45 |
| infinity | pitti: Which is one of the two reasons (the other being security updates) that we reexec init when its deps change. | 08:46 |
| pitti | ah, that | 08:46 |
| infinity | pitti: In practice, this probably isn't a big deal, and $deity knows that immediately after a long apt/dpkg run, we've sure run sync(2) a whole lot, so even if the remount-ro fails, the odds of catastrophic loss are are close to zero. | 08:47 |
| infinity | pitti: Anyhow, for now, I agree the quick bandaid is to not forward 'u' requests to upstart at all. | 08:49 |
| infinity | pitti: We can see if it appears to cause any legitimate upgrade/shutdown issues later, or have an idle think about if there's a better way, but this seems the lesser of two weavils. | 08:49 |
| infinity | weevils? weevils. I can't spell when I'm asleep. | 08:50 |
| === davidcalle_ is now known as davidcalle | ||
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| pitti | infinity, smoser: hm, wolfe-02 and wolfe-03 didn't come back from a reboot; do you have a serial console or something such to check what is going on? | 09:07 |
| pitti | rebooting the others will probably lead to the same error, so I'm trying not to | 09:07 |
| pitti | I tried to clean up after lxc-start hung forever and caused lots of woes | 09:07 |
| infinity | pitti: Lemme see if I remember how to get at wolfe. | 09:13 |
| pitti | infinity: ah, now I regret having pinged you as well.., addign to your sleep deprivation | 09:14 |
| infinity | pitti: wolfe-03 is running, I suspect it has no network. | 09:14 |
| infinity | Although, cloud-init claims it does... | 09:15 |
| pitti | infinity: before I rebooted wolfe-03, I installed upstart (just to see whether that was it) | 09:15 |
| infinity | ci-info: | eth0 | True | 10.245.66.195 | 255.255.248.0 | . | 52:54:00:00:42:c3 | | 09:15 |
| infinity | ci-info: | 0 | 0.0.0.0 | 10.245.64.1 | 0.0.0.0 | eth0 | UG | | 09:15 |
| infinity | pitti: Is that the right IP? | 09:15 |
| pitti | but I rebooted teh other wolfes with full vivid upgrade (kernel+systemd) yesterday, and that worked just fine | 09:15 |
| infinity | pitti: The NIC is up, it pings from batuan. | 09:16 |
| pitti | 10.245.66.195, yes | 09:16 |
| infinity | pitti: And I get an SSH banner on 22. | 09:16 |
| infinity | pitti: So, define "not up". | 09:16 |
| pitti | infinity: oh, so it is, sorry | 09:16 |
| pitti | apparently it just took very long | 09:16 |
| pitti | hah, and now wolfe-02 is back too | 09:16 |
| pitti | odd, I've waited like 5 mins | 09:16 |
| pitti | smoser, infinity: sorry for false alarm then! | 09:16 |
| infinity | pitti: In wolfe-02's console backscroll, I see a network up at ~4s, and a getty at ~5.5s | 09:18 |
| infinity | pitti: Unless it hung in grub for 5 minutes... | 09:18 |
| pitti | and now LXC works well again, too | 09:18 |
| pitti | ok, I'll reboot the other ones then and hope for the best :) | 09:19 |
| infinity | pitti: wolfe-02 was broken pre-reboot because of: | 09:19 |
| infinity | [14505.059372] INFO: rcu_sched self-detected stall on CPU { 0} (t=11314 jiffies g=61144 c=61143 q=1 | 09:19 |
| * infinity raises an eyebrow at: | 09:22 | |
| infinity | Mem: 65903680 65835456 68224 0 161408 25564032 | 09:22 |
| infinity | I wonder if smoser overcommitted this machine again... | 09:22 |
| infinity | Oh, I can't read, half of that is fs cache. | 09:23 |
| pitti | ok, all of them rebooted again | 09:23 |
| infinity | pitti: All good? | 09:24 |
| pitti | still waiting to come back, only wolfe-03 came back so far | 09:24 |
| pitti | but I'll be more patient this time and wait for 10 mins until I yell again :) | 09:24 |
| infinity | There does seem to be an unusually long grub timeout. | 09:24 |
| pitti | infinity: all back now | 09:25 |
| infinity | Also, are we ever going to fix this kmsg spam? | 09:25 |
| infinity | [ 9.707830] systemd-logind[1244]: Failed to start user service: Unknown unit: user@1001.service | 09:25 |
| infinity | Either that's expected behaviour and it should shut up, or we should fix the thing it's complaining about. | 09:25 |
| pitti | infinity: we have a workaround now, just not uploaded yet | 09:25 |
| pitti | $ sudo telinit u | 09:34 |
| pitti | Ignoring telinit u request, systemd is not running | 09:34 |
| pitti | ok, that's better | 09:34 |
| infinity | pitti: \o/ | 09:39 |
| Odd_Bloke | pitti: init= should be dropped in a daily build today. | 09:48 |
| pitti | Odd_Bloke: yay, thanks | 09:48 |
| pitti | tjaalton: bug 1430675> did you actually install bridge-utils into the VM? THe "not found" is odd | 10:09 |
| ubottu | bug 1430675 in systemd (Ubuntu) "fails to set up a bridged network interface" [Undecided,New] https://launchpad.net/bugs/1430675 | 10:09 |
| tjaalton | pitti: nope | 10:17 |
| tjaalton | ah, I'll try with that installed.. | 10:28 |
| tjaalton | hm, works fine on the vm | 10:30 |
| tjaalton | but I also see eth0 on ifconfig | 10:30 |
| tjaalton | and nm-applet says not managed, on my workstation eth0 is not shown and n-m applet somehow manages the connections (lxcbr0 and virbr0 too) | 10:31 |
| pitti | tjaalton: do you maybe have eth0 in /e/n/i on one but not the other? | 10:31 |
| darkxst | cjwatson, remember our discussion about webkit2gtk? its still struggly by the looks of it, https://launchpad.net/~darkxst/+archive/ubuntu/gnome315/+build/7050436/+files/buildlog_ubuntu-vivid-i386.webkit2gtk_2.7.91-0ubuntu1%7Evivid1_BUILDING.txt.gz | 10:32 |
| Laney | tjaalton: I reported something like this https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1422096 | 10:32 |
| ubottu | Launchpad bug 1422096 in network-manager (Ubuntu) "Occasionally no network on resume" [Undecided,New] | 10:32 |
| cjwatson | darkxst: not really ... | 10:33 |
| tjaalton | pitti: nope, neither of them has eth0 set up | 10:33 |
| tjaalton | in /e/n/i | 10:33 |
| darkxst | cjwatson, basically you said the new shiny ppa builders could handle it, yet those build failures look weird | 10:33 |
| darkxst | aka hitting resource limits I guess | 10:33 |
| cjwatson | well I think I probably said they ought to improve matters | 10:33 |
| tjaalton | Laney: I've seen something similar-ish on my laptop, it doesn't have any bridges though | 10:34 |
| Laney | same | 10:34 |
| cjwatson | they have 4GiB of RAM; you're not going to be able to map more than that in a single process on i386 anyway! | 10:34 |
| tjaalton | doesn't connect to wifi | 10:34 |
| tjaalton | *reconnect | 10:34 |
| pitti | Laney: probably a dupe of bug 1270257 ? | 10:34 |
| ubottu | bug 1270257 in network-manager (Ubuntu) "NetworkManager failed to function after suspend and resume" [Undecided,Confirmed] https://launchpad.net/bugs/1270257 | 10:34 |
| Laney | pitti: I think that's a different old one | 10:34 |
| Laney | the nm-applet state he describes there is different and I used to see that one from time to time too | 10:35 |
| pitti | Laney: your syslog looks exactly like in #1270257 | 10:35 |
| infinity | darkxst: Didn't we used to work around that with -Wl,--no-keep-memory ? | 10:36 |
| darkxst | cjwatson, mmap: failed to allocate 2291966196 bytes | 10:36 |
| pitti | Laney: i. e. NM thinking activated -> unmanaged (reason 'sleeping') after waking up | 10:36 |
| cjwatson | darkxst: can you even do that on i386? | 10:36 |
| infinity | darkxst: Also, ld.gold is probably more RAM-hungry than bfd (and also known to be error-prone on some arches), why is it using it? | 10:36 |
| darkxst | infinity, --no-keep-memory is still there I think | 10:37 |
| infinity | cjwatson: I think our i386 kernels are 1/3 splits, not 2/2, so you should be able to map (close to) 3ish... | 10:37 |
| cjwatson | well, this is an amd64 kernel, technically | 10:38 |
| infinity | --no-keep-memory | 10:38 |
| infinity | Use less memory and more disk I/O (included only for compatibility with GNU ld) | 10:38 |
| cjwatson | I don't know what happens in the compat layer | 10:38 |
| infinity | darkxst: ^-- I read that as "this is a no-op with gold". | 10:38 |
| Laney | pitti: I suppose maybe something else might have changed to cause the different output | 10:38 |
| infinity | darkxst: So, that would be the change. We used to use bfd with -Wl,--no-keep-memory, using gold is probably eating all our RAM for lunch. | 10:38 |
| Laney | I did only start seeing this very recently though, whereas that other bug is from 2014-01-17 | 10:39 |
| pitti | Laney: it's a race condition; switching init system certainly influences that, but we have reports from upstart too | 10:40 |
| pitti | this is much more logind/inhibitor territory, though | 10:40 |
| pitti | or changing timing because pm-utils isn't running in between | 10:40 |
| darkxst | infinity, right, I don't know why they are using ld.gold | 10:40 |
| Laney | There was also a n-m new upstream release around the correct time | 10:40 |
| infinity | darkxst: Because they hate !x86 people, and they prefer fast builds over correct builds. | 10:41 |
| infinity | darkxst: I think it's telling that, for instance, mozilla uses gold for quick iteration, but always uses bfd for release builds. | 10:41 |
| Laney | pitti: ah! I'm on upstart atm and I have still been seeing it, forgot about that. :) | 10:41 |
| infinity | (gold really is much faster) | 10:41 |
| * Laney comments | 10:41 | |
| pitti | Laney: well, it's still a bug :) | 10:42 |
| Laney | sure is | 10:42 |
| Laney | I'm basically trying to accuse n-m and not systemd though. :P | 10:42 |
| darkxst | infinity, maybe they are just trying to overcome the bloat factor, 3hrs to build on my dev machine | 10:42 |
| Laney | (of making it way more frequent, even if it did happen for others before) | 10:42 |
| infinity | darkxst: I'm sure their concern is speed, but ours shouldn't be. | 10:43 |
| infinity | darkxst: Slapping a -fuse-ld=bfd into CFLAGS will probably solve your issue. Probably. | 10:43 |
| darkxst | is there an easy way to switch back via packaging? | 10:43 |
| infinity | Or CXXFLAGS, or whatever. | 10:43 |
| darkxst | ok | 10:43 |
| infinity | Whatever webkit is. :P | 10:43 |
| infinity | darkxst: Alternately, find where it's setting -fuse-ld=gold and patch it out (or maybe it's influenced by a --with-not-stupid configure option) | 10:44 |
| darkxst | infinity, ok, easy enough, will give that try | 10:57 |
| pitti | tjaalton: replied to bug 1430675 | 11:11 |
| ubottu | bug 1430675 in systemd (Ubuntu) "fails to set up a bridged network interface" [Undecided,Incomplete] https://launchpad.net/bugs/1430675 | 11:11 |
| tjaalton | pitti: got it, I'll try to reboot this still today | 11:13 |
| pitti | tjaalton: is your bridge still broken, or did you ifup it manually? | 11:14 |
| pitti | tjaalton: if it's still down, seeing the info from these commands on your currently running system should be by and large the same | 11:14 |
| tjaalton | manual ifup | 11:14 |
| pitti | ok | 11:14 |
| pitti | tjaalton: so I guess you have a workaround for now, so this isn't uber-urgent now? | 11:15 |
| tjaalton | nah | 11:15 |
| tjaalton | do something else ;) | 11:15 |
| pitti | tjaalton: alright; at least we got the upgrade fix in -proposed now :) | 11:15 |
| tjaalton | yeah that's great | 11:15 |
| LocutusOfBorg1 | hi does anybody know how to contact Dave Morris? | 11:19 |
| Odd_Bloke | pitti: How are you testing the switch back to upstart? Just kvm on the local machine? | 11:27 |
| pitti | Odd_Bloke: I just take a VM (with -snapshot), apt-get install upstart, reboot, and check that upstart is running | 11:28 |
| pitti | installing upstart will remove systemd-sysv | 11:28 |
| pitti | but that doesn't work if you explicitly specify init= of course | 11:29 |
| Mirv | aha, someone disabled kishi arm builders and just when I was about to ask about it, I see they're back. thanks! :) | 11:41 |
| wgrant | Mirv: That buildd network needed a bit of hardware maintenance. Should all be back now. | 11:42 |
| matsubara | pitti, hey there. I just tried to create a new vivid testbed for adt with adt-buildvm-ubuntu-cloud and it gets stuck during the init scripts. Are you aware of bugs there? | 11:45 |
| pitti | matsubara: are you using -v? | 11:46 |
| matsubara | pitti, yes | 11:46 |
| pitti | matsubara: I noticed that it sometimes gets stuck with -v | 11:46 |
| matsubara | pitti, interesting. let me try without it | 11:46 |
| pitti | matsubara: dropping that seems to work; investigating this is on my TODO, but not at the very top right now | 11:46 |
| matsubara | pitti, fair enough. I'll file a bug if I gather further info. | 11:47 |
| pitti | matsubara: thanks | 11:47 |
| === doko_ is now known as doko | ||
| doko | mitya57, python-markdown autopkg test failure ... | 11:48 |
| darkxst | pitti, this retracer fail make any sense to you? http://pastebin.com/DCsS2UxY | 11:51 |
| pitti | tar: ./usr/share/doc/nettle-dbg: Cannot create symlink to 'libnettle4': File exists | 11:52 |
| pitti | darkxst: hm, I'm afraid not | 11:52 |
| pitti | I've never seen this | 11:52 |
| darkxst | I've seen it a few times now | 11:53 |
| darkxst | but I don't see how it could be caused by our ppa | 11:56 |
| pitti | smells like a corner case bug in dpkg | 11:56 |
| === kickinz1 is now known as kickinz1|afk | ||
| === Malsasa_ is now known as Malsasa | ||
| darkxst | pitti, probably, but kind of odd its such a low level package? | 12:09 |
| infinity | That doesn't look like a dpkg bug to me, it looks like two things are trying to ship the same symlink? | 12:09 |
| infinity | So, I'd blame whatever's creating the doc symlinks, and look at all the involved binaries closely. | 12:10 |
| === kickinz1|afk is now known as kickinz1 | ||
| darkxst | infinity, expect the only thing different my retracer does is add in the gnome3-team ppa's, in which case its odd the lp bot tracer hasnt hit this | 12:14 |
| darkxst | but I will check that | 12:14 |
| infinity | darkxst: Then I would suggest the broken packages are in your PPA. ;) | 12:16 |
| darkxst | infinity, there is nothing in our ppa that directly depends on libnettle afaik | 12:17 |
| === MacSlow is now known as MacSlow|lunch | ||
| infinity | darkxst: Oh, so nettle-dbg_2.7.1-5_amd64.deb is coming from the archive? | 12:17 |
| darkxst | yes | 12:17 |
| infinity | darkxst: Huh. Okay, in that case, I'm stumped. And also can't reproduce... | 12:20 |
| darkxst | infinity, yeh seems to only happen within apport-retrace | 12:24 |
| zyga | pitti: hey, where do I report bugs on adt-run? | 12:25 |
| pitti | zyga: against autopkgtest, please | 12:26 |
| zyga | on launchpad? | 12:26 |
| pitti | zyga: I read both Debian and LP bugs, so your pick (LP is magnitudes easier :) ) | 12:26 |
| zyga | hmmm, not set up for bugs | 12:26 |
| zyga | (on lp) | 12:26 |
| zyga | (I hate debian bugs) | 12:27 |
| zyga | pitti: http://pastebin.ubuntu.com/10579823/ | 12:27 |
| pitti | neither Launchpad nor Debian? | 12:27 |
| zyga | pitti: (while you set up https://bugs.launchpad.net/autopkgtest) | 12:27 |
| zyga | pitti: I'd rather eat dirt than report bugs in debian | 12:27 |
| cjwatson | what's wrong with https://bugs.launchpad.net/ubuntu/+source/autopkgtest? | 12:27 |
| zyga | oh, on the source package | 12:27 |
| cjwatson | and don't you think that's a bit childish? | 12:28 |
| pitti | zyga: please try a non-ancient version first | 12:28 |
| zyga | I rarely use those, not used to that concept | 12:29 |
| zyga | pitti: do you want a bug on the package then? | 12:29 |
| pitti | zyga: yes, that's what I meant; but please try with vivid's version first | 12:29 |
| zyga | pitti: well, this is utopic, vivid isn't out yet :) where can I get a better version | 12:29 |
| pitti | zyga: http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_3.11.1_all.deb | 12:29 |
| pitti | zyga: installs on >= precise | 12:29 |
| zyga | let's see | 12:29 |
| * zyga tries the build again | 12:30 | |
| zyga | pitti: crashes the same exact way | 12:31 |
| pitti | zyga: ack, can you please file a bug then? | 12:31 |
| zyga | pitti: that's what I'm here for, on the source package? | 12:31 |
| pitti | yes, as usual; "ubuntu-bug adt-run" will DTRT | 12:33 |
| pitti | err, ubuntu-bug autopkgtest | 12:33 |
| Bluefoxicy | why can I read acronyms I've never seen? | 12:35 |
| Bluefoxicy | Apparently my brain will DTRT too | 12:35 |
| zyga | pitti: nope, cannot do, I've updated the pacakge | 12:35 |
| * zyga goes to file the bug the old way | 12:35 | |
| zyga | pitti: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1430773 thanks! | 12:39 |
| ubottu | Launchpad bug 1430773 in autopkgtest (Ubuntu) "crash on unicode decode error" [Undecided,New] | 12:39 |
| zyga | pitti: I rely on adt a lot so if you need any extra bits to debug this or you want me to test a prototype branch, I'm glad to help | 12:42 |
| pitti | zyga: hm, do you run this under a non-UTF8 locale? | 12:45 |
| pitti | zyga: looks like "dpkg-deb --info -- twine*.deb control" would have some non-ascii characters (which is perfectly legit) | 12:46 |
| zyga | pitti: I'm using pl_PL.UTF-8 | 12:47 |
| zyga | pitti: hmm, I ran your command on ../build-area | 12:48 |
| zyga | pitti: and I see why it failed | 12:49 |
| pitti | non-UTF8 data? | 12:49 |
| pitti | zyga: either way, it's simple enough to fix | 12:49 |
| pitti | as long as the package name isn't something funky, we can ignore errors in the rest of it | 12:50 |
| pitti | + if (asprintf(&(c->device_id), "fd %d", c->fsck_fd) < 0) { | 12:50 |
| pitti | sorry, -ECHAN | 12:50 |
| zyga | pitti: http://pastebin.ubuntu.com/10579908/ | 12:51 |
| zyga | pitti: look at the last line | 12:51 |
| zyga | pitti: is the command I ran correct? | 12:51 |
| zyga | twine*.deb expands to more than one file in that place | 12:51 |
| zyga | pitti: if I just run it on the newest deb I get this http://pastebin.ubuntu.com/10579915/ | 12:51 |
| zyga | nothing non-ascii as far as I can see (though I didn't check this) | 12:51 |
| pitti | zyga: is that anything secret? if not, perhaps you could just attach the .debs to the bug (or give a pointer to them) | 12:52 |
| zyga | pitti: no, nothing secret at all, just work-in-progress | 12:53 |
| zyga | pitti: oh and that package doesn't have autopkgtests either, it's just a part of my standard .sbuildrc run | 12:53 |
| zyga | pitti: attached | 12:55 |
| smoser | infinity, i dont really know what you'd consider overcommit. wolfe has 9 vms, that probably are 90% idle . each as 4G memory, system has 64G memory. that doesn't sound terribly overcommitted. | 12:56 |
| infinity | smoser: It's not overcommitted, I can't read. | 12:56 |
| infinity | smoser: It's been a long day. :P | 12:57 |
| ricotz | doko, hi :), thanks for the gcc5 builds, jfyi, something seems wrong regarding libcc1-0 in "gcc-5 - 5-20150309-1ubuntu12" | 13:22 |
| doko | ricotz, why? | 13:28 |
| === MacSlow|lunch is now known as MacSlow | ||
| ricotz | doko, gcc-5 hard-version-depends on libcc1-0 which is not available | 13:35 |
| doko | ricotz, yeah, dumb packaging mistake | 13:57 |
| ricotz | doko, alright, thanks for confirming | 14:01 |
| rasmus_ | Hi! I submitted my app to Ubuntu about half a year ago and still have not heard anything. Does anyone know how long the pending process takes? | 14:05 |
| stgraber | bjf: Hi, so I've been talking with pitti. What you're hitting shouldn't be possible at this time as sysvinit has been fixed for that very issue a while back. | 14:07 |
| stgraber | so it may be some upgrade mis-ordering of some kind | 14:07 |
| pitti | well, it is possible | 14:07 |
| stgraber | how long had it been since you last upgraded that system? | 14:07 |
| pitti | if you run utopic with systemd and then try to install/upgrade LXC | 14:08 |
| pitti | utopic's invoke-rc.d didn't get get along with packages which didn't have an init.d script | 14:08 |
| bjf | stgraber, this is a fresh install of vivid on mare metal using a daily MAAS vivid image | 14:08 |
| bjf | stgraber, i can repo it on 5 systems | 14:09 |
| pitti | I just started utopic, installed lxc, then installed first systemd-sysv from vivid and then lxc | 14:09 |
| pitti | that worked now | 14:09 |
| pitti | bjf: ah, so this is not an upgrade? | 14:09 |
| bjf | pitti, no | 14:09 |
| bjf | pitti, it's in my testing lab ... and i've replicated it here at home as well | 14:10 |
| ericsnow | pitti: hey, I got everything sorted out yesterday, thanks | 14:10 |
| mdeslaur | doko: I am stealing your python-django merge | 14:25 |
| doko | mdeslaur, steal whatever you want, but don't give it back ;p | 14:27 |
| pitti | sticky thing, such a merge :) | 14:27 |
| mdeslaur | doko: don't worry, you usually get it all back when you upload your next toolchain :) | 14:27 |
| pitti | rbasak: I saw your question in bug 1409639, is that something that needs more discussion about anything? | 14:44 |
| ubottu | bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] https://launchpad.net/bugs/1409639 | 14:44 |
| pitti | rbasak: i. e. I don't think it's a pressing matter that the tests are failing -- they'll just remind us that something needs to be fixed | 14:45 |
| tyhicks | pitti: We'll need to check with kirkland on when he plans to cut the upstream ecryptfs-utils release and upload it to vivid | 14:45 |
| pitti | rbasak: i. e. either making it work with systemd, or installing upstart on the instances (and the test) | 14:45 |
| pitti | tyhicks: ah; would it hurt if I uploaded my fixes then? it causes a nasty 1.5 minute boot delay at the moment, many people will hard-boot before that | 14:46 |
| pitti | tyhicks: I thought you already had a vivid update prepared, and I wanted to avoid breaking that | 14:46 |
| ogra_ | Preparing to unpack .../base-passwd_3.5.37_armhf.deb ... | 14:48 |
| ogra_ | dpkg: symbol lookup error: dpkg: undefined symbol: setexecfilecon | 14:48 |
| ogra_ | dpkg: error processing archive /var/cache/apt/archives/base-passwd_3.5.37_armhf.deb (--install): | 14:48 |
| ogra_ | cjwatson, ^^^ do you have any idea what i can do there ? thats a debootstrap run of the initramfs-tools-ubuntu-touch package | 14:48 |
| ogra_ | (or anyone else familiar with debootstrap) | 14:49 |
| ogra_ | pitti, ? | 14:50 |
| pitti | erk, never saw that | 14:51 |
| ogra_ | i wonder if it could be anyhow related to systemd (on the buildd it is actually init that fails like this) | 14:51 |
| pitti | $ nm -D /usr/bin/dpkg|grep setexecfilecon | 14:51 |
| pitti | U setexecfilecon | 14:51 |
| pitti | so what provides that | 14:51 |
| pitti | /lib/x86_64-linux-gnu/libselinux.so.1. | 14:52 |
| ogra_ | oh | 14:52 |
| pitti | do we have that installed? | 14:52 |
| pitti | dpkg depends on it, so it would be strange not to | 14:53 |
| ogra_ | not from debootstrap i think | 14:53 |
| ogra_ | note that this is a fakechroot env | 14:53 |
| pitti | oh | 14:55 |
| pitti | ogra_: can you strace this and see whether it actually finds the lib? | 14:55 |
| pitti | fakechroot tends to fail a lot with newer libc versions | 14:56 |
| ogra_ | pitti, hard to do on the buildd ... and i'm not sure it is the same error | 14:56 |
| ogra_ | (i.e. what i see locally might be totally different) | 14:56 |
| ogra_ | let me re-upload the package with added verbosity :) | 14:57 |
| tyhicks | pitti: please sync with kirkland but I think it'd be fine if you uploaded | 14:59 |
| pitti | tyhicks: ack | 15:00 |
| pitti | kirkland: ^ would I step on your toes if I uploaded the ecryptfs swap fixes we talked about now? | 15:01 |
| pitti | kirkland: I see the two script fixes aren't upstream yet, but I can just add them as an Ubuntu patch for now; but I'd like to land the postinst fix for vivid users, as that's hurting quite a lot | 15:02 |
| kirkland | pitti: hiyea | 15:06 |
| cjwatson | ogra_: debootstrap's supposed to dpkg -x everything that's Priority: required before it tries to execute any code in the chroot, and it seems to be doing so there ... | 15:06 |
| kirkland | pitti: let me merge them | 15:06 |
| kirkland | pitti: and I'll release | 15:06 |
| kirkland | pitti: do you have a merge request to lp:ecryptfs? | 15:06 |
| pitti | kirkland: ah no, but I can do one (sorry for the misunderstanding, I thought you were just committing those) | 15:06 |
| kirkland | pitti: that's fine, I can do that | 15:07 |
| ogra_ | cjwatson, right, i uploaded a change that cats debootstrap.log now and did set the script to -x so we get more loggign | 15:07 |
| kirkland | pitti: I'm committing the tested changes I have to ecryptfs-setup-swap now | 15:07 |
| cjwatson | yeah, catting debootstrap.log on failure is smart | 15:07 |
| pitti | kirkland: as you wish; let me know if you like an MP | 15:07 |
| pitti | kirkland: that's the offset= and the updated cipher=? | 15:08 |
| kirkland | pitti: yeah, and one other fix to a grep/whitespace bug | 15:08 |
| kirkland | pitti: that would affect you too | 15:09 |
| kirkland | pitti: http://paste.ubuntu.com/10580515/ | 15:09 |
| pitti | kirkland: right, thanks | 15:10 |
| kirkland | pitti: tyhicks: I just want to track down all of the cryptfs swap bugs that might be affected/duped here | 15:13 |
| tyhicks | ack | 15:13 |
| seb128 | tyhicks, hey | 15:16 |
| seb128 | tyhicks, did you end up having slots to look at the schroot/ecryptfs issue? | 15:16 |
| tyhicks | seb128: hey - I was able to reproduce the rbind issue but I haven't yet figured out the cause | 15:16 |
| seb128 | tyhicks, k, I guess it's a good start to be able to confirm that there is an issue :-) | 15:17 |
| tyhicks | seb128: I need some more time today to look at it | 15:17 |
| seb128 | tyhicks, thanks for looking at it | 15:17 |
| seb128 | no hurry | 15:17 |
| tyhicks | np | 15:17 |
| === mvo__ is now known as mvo | ||
| bdmurray | pitti: have you seen bug 1430557? | 15:22 |
| ubottu | bug 1430557 in schroot (Ubuntu) "sbuild unmounted encrypted home directory" [Undecided,New] https://launchpad.net/bugs/1430557 | 15:22 |
| seb128 | bdmurray, pitti, I think it's the same issue I was discussing with tyhicks yesterday/now | 15:23 |
| seb128 | bdmurray, bug 1427264 / bug #769595 | 15:23 |
| ubottu | bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,New] https://launchpad.net/bugs/1427264 | 15:24 |
| ubottu | bug 769595 in schroot (Ubuntu) "Encrypted home not mountable under chroot" [High,Triaged] https://launchpad.net/bugs/769595 | 15:24 |
| seb128 | if it's like the click case, it tries to force unmount the bind mount and that leads to the ecryptfs userdir to be unmounted during the session | 15:24 |
| rbasak | pitti: so I've just caught up with sinzui in #juju, and believe I have a full understanding of the situation now. | 15:31 |
| ogra_ | cjwatson, pitti https://launchpadlibrarian.net/199937417/buildlog_ubuntu-vivid-armhf.initramfs-tools-ubuntu-touch_0.85_BUILDING.txt.gz | 15:32 |
| rbasak | It's a bit complicated because juju is both a client as well as something that deploys some release of Ubuntu. | 15:32 |
| ogra_ | so on the buildd it looks a lot worse than in my local build | 15:32 |
| rbasak | And finally, it has juju-local which deploys LXC or KVM to what it's already running on. | 15:32 |
| rbasak | But that's really just a special case of deploying some release of Ubuntu. | 15:32 |
| rbasak | So as a client, no issues. No dependency on init. | 15:32 |
| ogra_ | chfn: PAM: System error | 15:32 |
| ogra_ | adduser: `/usr/bin/chfn -f systemd Time Synchronization systemd-timesync' returned error code 1. Exiting. | 15:32 |
| ogra_ | grrr | 15:32 |
| ogra_ | i guess it is this one | 15:33 |
| rbasak | If the client deploys to something, then right now only upstart is supported. systemd support will only arrive in 1.23. | 15:33 |
| rbasak | 1.23 is scheduled for very close to the release of Vivid. | 15:33 |
| pitti | rbasak: as a clietn> well, it would still need at least an init.d script or a systemd unit to start the local client, right? | 15:33 |
| rbasak | No, the client isn't a daemon. | 15:33 |
| rbasak | It speaks to a daemon running on deployed instances | 15:33 |
| pitti | rbasak: oh, I was fairly sure it starts some juju service on boot | 15:33 |
| rbasak | If the client deploys something, then what it deploys runs a daemon, and that has to run the daemon via init on boot | 15:34 |
| rbasak | In the juju-local case, that's on localhost. | 15:34 |
| cjwatson | ogra_: + sed -i s/raring/saucy/ ./build/etc/apt/sources.list | 15:34 |
| rbasak | (I think that might be inside a container though, not on host itself) | 15:34 |
| cjwatson | probably wants cleaning up too :) | 15:34 |
| rbasak | So, Vivid is only half broken. | 15:35 |
| rbasak | juju-local is useless right now, and will be until 1.23. | 15:35 |
| rbasak | As a client (eg. to manage a production deployment), it's fine. | 15:35 |
| rbasak | To deploy Vivid, it's broken, and will be until 1.23. | 15:35 |
| ogra_ | cjwatson, yeah, but it fails earlier (just doesnt exit bcause i added an: "|| cat debootstrap.log" to the script) | 15:35 |
| rbasak | But in production use, most users will be deploying Trusty or even Precise, which is fine. | 15:35 |
| pitti | rbasak: ah, good; I was fairly sure that lxc-local under systemd wasn't working as it doesn't start that autogenerated "local manager something" job | 15:36 |
| cjwatson | rbasak: wgrant told me last night that juju-local was broken for him on vivid when deploying trusty, because it tries to write upstart jobs to the host and those never start | 15:36 |
| rbasak | Yeah I'd expect that to be broken. | 15:36 |
| pitti | rbasak: right, and landing that late seems fine; we basically land new juju releases to stables all the time anyway | 15:36 |
| rbasak | cjwatson: OK, that makes sense, thanks. | 15:36 |
| pitti | right, I mean those | 15:36 |
| rbasak | pitti: right. So I think we might as well ignore the failures for now, and it'll all get fixed when 1.23 is released and uploaded. | 15:36 |
| cjwatson | I don't know whether it works if you start those manually | 15:36 |
| kirkland | pitti: tyhicks: the big red button has been pushed :-) | 15:37 |
| rbasak | I could disable or remove juju-local somehow right now, but there seems to be little point if we're expecting to fix for Vivid's release. | 15:37 |
| rbasak | (with 1.23) | 15:37 |
| cjwatson | (I'm just sticking with upstart for now, I need juju-local and I have a bit too much state to reboot right now in any case) | 15:37 |
| rbasak | If 1.23 is delayed (it is very close to Vivid release), we could update in an SRU to fix it, as we have the exception anyway. | 15:37 |
| ogra_ | oh ! | 15:39 |
| * ogra_ thinks he found the issue | 15:39 | |
| rbasak | cjwatson: I'm told 1.23-beta1 will be out in the next week or two, and that'll have systemd support. So you could use that, though if you're pushed for time maybe you don't want to be a beta tester :) | 15:39 |
| pitti | rbasak: seems fine; we've traditionally developed upstream releases alongside with ubuntu releases (betas, rcs, etc.) | 15:42 |
| pitti | kirkland: cool, thanks! do you or tyhicks want to package that for vivid now, or should I do an upload with the postinst and offset= fix now, to take the pressure off for the new upstream release? (which might need a FFE) | 15:45 |
| kirkland | pitti: oh -- can you send me the postinst patch? | 15:45 |
| kirkland | pitti: I've already uploaded to vivid | 15:45 |
| kirkland | pitti: without the postinst patch (but with the offset one) | 15:46 |
| kirkland | pitti: we keep the debian/* dir in the upstream lp:ecryptfs | 15:46 |
| rbasak | pitti: I'll discuss with upstream tomorrow. Right now we're still in the position that upstream separately consider what they want to land in Ubuntu post-release. | 15:46 |
| kirkland | pitti: this shouldn't need an FFE | 15:46 |
| pitti | kirkland: ah nice, I'll handle the postinst then | 15:46 |
| kirkland | pitti: this is a clear bug fix | 15:46 |
| rbasak | I'd like them not to release if they're not happy that Ubuntu would take it, and they agree, but we're not quite there yet. | 15:46 |
| rbasak | Everyone is being very cautious about what they're prepared to push to Ubuntu (and eg. Trusty). Which is a good thing I figure. | 15:47 |
| pitti | kirkland: there was other bits that seemed more intrusive (like https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/839) | 15:47 |
| cjwatson | rbasak: Right, when it actually appears in a PPA somewhere I might | 15:47 |
| tyhicks | pitti: that was a security bug fix | 15:48 |
| kirkland | pitti: right, but that's a security critical fix; in fact, tyhicks is handling this as a security upload for precise, trusty, utopic | 15:48 |
| tyhicks | kirkland: the security uploads happened yesterday | 15:48 |
| pitti | kirkland: aaand failed tests :/ | 15:48 |
| cjwatson | rbasak: Though I do have fairly pressing work to do using it :) | 15:48 |
| pitti | kirkland: ah right, it was that one | 15:48 |
| zyga | did anyone running vivid observe that default network inteface, given ethernet and wifi, was wifi? | 15:49 |
| kirkland | pitti: where's the failed tests? | 15:49 |
| zyga | I just got that, (I only realized because my wifi is terrible) | 15:49 |
| rbasak | zyga: using network manager? I was under the impression that you end up with two default routes but with metrics that prefer the ethernet. Can you check your routing table? | 15:49 |
| zyga | rbasak: yep, looking | 15:49 |
| pitti | kirkland: I mean, it FTBFSed on failed "make check" | 15:50 |
| rbasak | It's not ideal though. Stuff bound to the old IP will continue using it. And I'd like to roam between wired and wifi with the same IP (due to a public IP shortage) and that triggers IPv6 DAD and breaks things. | 15:51 |
| kirkland | pitti: I'm looking into it | 15:51 |
| zyga | rbasak: I cannot reproduce it just by fiddling with connections now, I see eth0 has metric=1024 while wlan0 has metric=1000 (for 169.254.0.0), both have metric=0 for 0/8 | 15:51 |
| zyga | rbasak: I can reboot to see if this happens again | 15:52 |
| zyga | rbasak: what should the correct values be? | 15:52 |
| rbasak | zyga: OK. I'm not sure if I can help any more though, sorry. That's as far as I know. | 15:52 |
| zyga | rbasak: thanks! | 15:52 |
| rbasak | zyga: hmm. According to route(8), the metric is no longer used by recent kernels. So I have no idea how it makes a routing decision now. I wonder when it changed. | 15:53 |
| rbasak | The metric should be lower for wired though in order to prefer it. At least in the past. | 15:53 |
| zyga | rbasak: lower? oh then it is not lower for me here | 15:53 |
| * zyga reboots | 15:53 | |
| zyga | (in the background) | 15:53 |
| zyga | after reboot, eth0 has metric=1024 and is the default gateway | 15:55 |
| zyga | pinging google is unreliable though | 15:56 |
| ogra_ | pitti, cjwatson, so i think the bug i see lies within debootstrap ... systemd creates users and calls chfn, upstart didnt do that ... in the later used fakechroot-config in our build script we use we explicitly substitute chfn with /bin/true, but that doesnt help during chroot creation with debootstrap | 15:56 |
| zyga | is route just lying to me? | 15:56 |
| ogra_ | i suspect we need to do the same thing with chfn that --vartiant=fakechroot does with ldconfig there, if i read the code right | 15:57 |
| cjwatson | ogra_: please remove me from cc on this, I'm not going to have time at the moment | 15:57 |
| ogra_ | cjwatson, ok | 15:57 |
| cjwatson | ogra_: I would expect Debian to have the same issue with fakechroot, so perhaps reproduce there, and maybe then debian-boot@ can help you | 15:57 |
| ogra_ | well, i dont even have a debian install :) | 15:58 |
| cjwatson | oh come on you're using debootstrap | 15:58 |
| cjwatson | you can debootstrap debian | 15:58 |
| cjwatson | this is mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745082 | 15:58 |
| ubottu | Debian bug 745082 in debootstrap "fakechroot: chfn in a fakechroot environment" [Normal,Open] | 15:58 |
| ogra_ | i cant even reproduce the exact error on ubuntu :) | 15:58 |
| ogra_ | oh, thanks ! | 15:58 |
| zyga | cjwatson: truth be told I had issues with debootstrap on ubuntu, some defaults were wrong not long ago and it would misbehave or have some ubuntuisms inside | 15:59 |
| cjwatson | zyga: and you think that's related to this? note that Ubuntu's debootstrap is a literal copy of Debian's | 16:00 |
| cjwatson | anyway debootstrap is used by everything, so shrug | 16:00 |
| zyga | cjwatson: yes but it depends on some tools that are patched, from the top of my head archive signing keys were wrong and there were at least two other issues | 16:00 |
| cjwatson | this is so vague I'm going to ignore it, bye | 16:01 |
| zyga | cjwatson: I painfully found that trying to build a sid sbuild chroot for my debian work | 16:01 |
| cjwatson | file bugs | 16:01 |
| cjwatson | with actual details | 16:01 |
| zyga | cjwatson: that was last year, I think those bugs are gone now | 16:01 |
| zyga | cjwatson: my point was that there might be a weird difference hiding somewhere still | 16:01 |
| ogra_ | well, this particular issue simply never showed up with upstart, systemd introduced it ... cant really blame deboostrap | 16:02 |
| cjwatson | zyga: I don't think anything this hopelessly vague is going to help anything, sorry. | 16:02 |
| cjwatson | anyway I was trying to do entirely unrelated stuff, that's why I wanted people to stop talking to me about this :) | 16:02 |
| * rbasak is dealing with a bug that turns out to be an uninitalised value gcc warning in a random number generator | 16:05 | |
| pitti | rbasak: "oh no, not again"? :-) | 16:08 |
| pitti | "what can possibly go wrong" | 16:08 |
| rbasak | pitti: this ones a bit different, but I'm being very cautious :) | 16:09 |
| rbasak | https://bugs.launchpad.net/ubuntu/+source/percona-galera-3/+bug/1430874 if you're interested | 16:09 |
| ubottu | Launchpad bug 1430874 in percona-galera-3 (Ubuntu) "FTBFS on powerpc and armhf due to uninitialized struct" [High,Triaged] | 16:09 |
| pitti | rbasak: ah, not openssl then :) | 16:09 |
| rbasak | No :) | 16:10 |
| bdmurray | jodh: bug 1430374 is about chromium-browser just like bug 1300235 | 16:12 |
| jodh | bdmurray: wow, intriguing. What *is* chromium doing? :-) | 16:14 |
| === ubott2 is now known as ubottu | ||
| bjf | pitti, stgraber was anything decided about the lxc install issue i am seeing on vivid? | 16:15 |
| pitti | bjf: I don't see it on vivid installs or upgrades; I'm afraid I need detailled logs or a reproduction recipe | 16:16 |
| bjf | pitti, ok, i'll get that for you | 16:16 |
| pitti | bjf: cheers! | 16:16 |
| ogra_ | pitti, do you have any idea wrt the fakechroot thing ? this is realyl blocking us on the phone | 16:16 |
| ogra_ | the only idea i would have would be to hack up debootstrap | 16:16 |
| pitti | bjf: this morning it sounded like an upgrade failure, so I tested those; but apparently that was the wrong direction? | 16:17 |
| bjf | pitti, yes. it's a fresh install on bare metal | 16:17 |
| pitti | ogra_: sorry, confused: what's the issue with adduser and chfn? that doesn't work during deboostrap with fakechroot? | 16:18 |
| ogra_ | pitti, right | 16:18 |
| ogra_ | pitti, and our initramfs gets built inside a deboostrapped chroot that runs under fakechroot | 16:18 |
| ogra_ | upstart didnt create any users so we didnt hit that before ... | 16:19 |
| ogra_ | systemd wants to create a user for the timesyncd service it seems | 16:19 |
| stgraber | bjf: I just tried to install lxc on a clean vivid install here and it worked fine | 16:20 |
| pitti | yeah, I do that all the time, it's not that simple | 16:20 |
| stgraber | so it's not nearly as simple as installing it on current vivid | 16:20 |
| pitti | there must be something special in bjf's setup | 16:20 |
| pitti | ogra_: how do you invoke debootstrap with fakechroot? | 16:20 |
| bjf | stgraber, pitti, i'll get exact commands and a log together | 16:20 |
| pitti | ogra_: --variant=fakechroot? | 16:21 |
| ogra_ | pitti, http://paste.ubuntu.com/10580842/ | 16:21 |
| === roadmr is now known as roadmr_afk | ||
| ogra_ | thats the build script | 16:21 |
| ogra_ | pitti, the -c fakechroot-config is indeed moot ... i added that out of desparation ... | 16:22 |
| ogra_ | (the one in the debootstrap call) | 16:22 |
| ogra_ | FAKECHROOT_CMD_SUBST="$FAKECHROOT_CMD_SUBST:/usr/bin/chfn=/bin/true" | 16:22 |
| ogra_ | that is what we have in that config ... just for completion | 16:22 |
| * pitti runs $ fakeroot fakechroot debootstrap --variant=fakechroot vivid /tmp/vividfc http://archive.ubuntu.com/ubuntu/ | 16:23 | |
| ogra_ | pitti, i dont get the error at home ... i tried to run the whole package build ... note that this runs inside a buildd chroot usually | 16:24 |
| ogra_ | so you would have to run it inside a chroot i guess | 16:24 |
| pitti | chfn: PAM: System error | 16:24 |
| pitti | adduser: `/usr/bin/chfn -f systemd Time Synchronization systemd-timesync' returned error code 1. Exiting. | 16:24 |
| pitti | I get this | 16:24 |
| ogra_ | oh, nice | 16:24 |
| ogra_ | i didnt :P | 16:24 |
| ogra_ | pitti, colin pointed me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745082 | 16:25 |
| ubottu | Debian bug 745082 in debootstrap "fakechroot: chfn in a fakechroot environment" [Normal,Open] | 16:25 |
| ogra_ | someone there claims its a quoting issue ... but i slightly doubt that | 16:25 |
| pitti | ogra_: filed as bug 1430891 now | 16:28 |
| ubottu | bug 1430891 in fakechroot (Ubuntu) "debootstrapping vivid under fakechroot fails" [High,New] https://launchpad.net/bugs/1430891 | 16:28 |
| pitti | I'll look into it tomorrow morning; perhaps we can replace chfn, or use adduser instead of chfn | 16:28 |
| ogra_ | pitti, for this specific use case i wouldnt mind to just link chfn to /bin/ture ... | 16:29 |
| === seb128_ is now known as seb128 | ||
| pitti | ogra_: oh right, we don't really need that on the touch images | 16:29 |
| ogra_ | but i guess that would break for other cases | 16:29 |
| ogra_ | right, my prob is that it has to happen *inside* deboostrap | 16:30 |
| pitti | libfakechroot should be used by everything there too, unless it's suid/sgid? | 16:31 |
| ogra_ | i think chfn is suid | 16:32 |
| ogra_ | which is why we override it in the fhkechroot env for all subsequent calls in that script | 16:32 |
| ogra_ | but that override doesnt do anything durin the debootstrap run | 16:33 |
| bdmurray | mvo: with bug 1429041 - would the wrong packages also be suggested for removal? | 16:33 |
| ubottu | bug 1429041 in apt (Ubuntu Precise) "Autoremoval not working reliably" [Undecided,In progress] https://launchpad.net/bugs/1429041 | 16:33 |
| mitya57 | doko: looks like a bug in lava-server's testsuite (tries to compare unsorted arrays) | 16:35 |
| mitya57 | And also it's not a regression caused by python-markdown, it fails since March 4th | 16:36 |
| pitti | ogra_: oh, it probably calls chfn in the generated chroot, not from the host? | 16:36 |
| ogra_ | pitti, exactly | 16:36 |
| pitti | (was just running with -c and also tried a modified /etc/fakechroot/debootstrap.env | 16:37 |
| ogra_ | thats why i claim it has to be in debootstrap | 16:37 |
| pitti | ogra_: oh, wait | 16:37 |
| pitti | ogra_: I added it to /etc/fakechroot/debootstrap.env and that works | 16:37 |
| pitti | so apparenlty -c doesn't work somehow | 16:37 |
| ogra_ | . /etc/fakechroot/chroot.env | 16:37 |
| ogra_ | FAKECHROOT_CMD_SUBST="$FAKECHROOT_CMD_SUBST:/usr/bin/chfn=/bin/true" | 16:37 |
| mitya57 | pitti: why lava-server failure is considered a regression and blocks python-markdown migration? (sorry for disturbing you) | 16:37 |
| ogra_ | pitti, thats our .env in fackeshroot-confi | 16:37 |
| ogra_ | g | 16:37 |
| ogra_ | i wonder if i coudl somehow force that var on the actual command call | 16:38 |
| ogra_ | pitti, i have some doubt that infinity will be happy if i put files into /etc on the builder :) | 16:40 |
| pitti | ogra_: no, that was just to determine whether it works at all, or is just a problem with my -c | 16:40 |
| mvo | bdmurray: I don't think the wrong package would be suggested, just that some are missing. but I'm not 100% confident in this I need to think this through if there might be a case where the wrong one is selected | 16:40 |
| ogra_ | riht, it works in general ... | 16:40 |
| ogra_ | *right even | 16:40 |
| pitti | ogra_: ooh! | 16:41 |
| pitti | ogra_: not chroot.env, debootstrap.env | 16:41 |
| ogra_ | oh ? | 16:41 |
| ogra_ | oh, so we need a second file here ! | 16:41 |
| * ogra_ tries that ... version numbers are cheap :) | 16:41 | |
| pitti | I don't know if you need another one | 16:41 |
| pitti | ogra_: wait, still debootstrapping with that | 16:42 |
| ogra_ | well, we need the chroot.env for the actual chroot calls later | 16:42 |
| pitti | meh | 16:42 |
| ogra_ | didnt work ? | 16:42 |
| pitti | so why does it work in /etc/fakechroot/debootstrap.env but not in ~/fakechroot-touch/debootstrap.env | 16:42 |
| pitti | ah, it then doesn't read /etc/fakechroot/debootstrap.env any more | 16:43 |
| ogra_ | The configuration file name is type.env and is searched at $HOME/.fakechroot and /etc/fakechroot directories. | 16:43 |
| pitti | . o O { what would we do without strace } | 16:43 |
| ogra_ | says the manpage | 16:43 |
| ogra_ | oh, that was for -e | 16:43 |
| pitti | ok, next try | 16:43 |
| ogra_ | not -c | 16:43 |
| ogra_ | but let me try adding that deboostrap file to the package ... | 16:44 |
| pitti | \o/ | 16:44 |
| ogra_ | tell me :) | 16:44 |
| pitti | 5 Mark! :-) | 16:45 |
| ogra_ | lol | 16:45 |
| ogra_ | hier haste zehn :) | 16:45 |
| * ogra_ notes down for the sprint | 16:45 | |
| pitti | ogra_: added to bug fakeroot fakechroot -c ~/fakechroot-touch/ debootstrap --variant=fakechroot vivid /tmp/vividfc http://archive.ubuntu.com/ubuntu/ | 16:45 |
| pitti | no, my dear X paste buffer | 16:45 |
| pitti | bug 1430891 | 16:45 |
| ubottu | bug 1430891 in fakechroot (Ubuntu) "debootstrapping vivid under fakechroot fails" [Medium,New] https://launchpad.net/bugs/1430891 | 16:45 |
| pitti | ogra_: so apparently if you use -c, it *only* uses debootstrap.conf from that directory; it doesn't *also* read from /etc/fakechroot | 16:46 |
| pitti | so I just source the original file | 16:46 |
| pitti | ogra_: btw, I don't need another chroot.env, but probably because I don't run anything extra after that | 16:47 |
| ogra_ | right | 16:47 |
| ogra_ | we call chroot a few times later on | 16:47 |
| ogra_ | pitti, i'm wondering if we shouldnt add chfn to the file in etc though | 16:47 |
| ogra_ | seems valid | 16:48 |
| pitti | ogra_: not having proper long user names isn't the end of the world, yeah | 16:48 |
| ogra_ | well, it will fail everywhere now | 16:48 |
| ogra_ | with systemd | 16:49 |
| pitti | yeah, I didn't close the bug, it's just less urgent now | 16:49 |
| ogra_ | yep | 16:49 |
| pitti | and, 12 hours already, hungry, need dinner, then basketball and stuff | 16:50 |
| pitti | so I guess I'll call it a day before I get caught yet again :) | 16:50 |
| pitti | mitya57: will override | 16:50 |
| ogra_ | haha, sorry for that | 16:50 |
| pitti | ogra_: no, that's alright; image builds -> blocker -> super-urgent | 16:51 |
| * ogra_ uploads and crosses fingers | 16:51 | |
| * pitti hugs ogra | 16:52 | |
| * ogra_ hus pitti | 16:52 | |
| ogra_ | bah | 16:52 |
| ogra_ | i really need a new kbd | 16:52 |
| mitya57 | pitti: thanks | 16:52 |
| pitti | stop typing on your phone :) | 16:52 |
| * ogra_ puts some g's into the channel in advance | 16:52 | |
| ogra_ | gggg g g g g g g g | 16:53 |
| ogra_ | this keyboard isnt even a year old :/ | 16:53 |
| ogra_ | and wasnt cheap either | 16:53 |
| zul | is there a way to login to the autopkgtest after the failures? | 16:57 |
| dobey | zul: adt-run -s iirc | 16:58 |
| dobey | zul: ie, add -s to your adt-run clal that ran the tests; if you mean the ones in jenkins, the answer is no | 16:59 |
| zul | dobey: thanks | 16:59 |
| === roadmr_afk is now known as roadmr | ||
| patod | is anybody their to help me | 17:26 |
| patod | i am novice in open source | 17:26 |
| dobey | !ask | patod | 17:26 |
| patod | i want to contribute in open source | 17:26 |
| ubottu | patod: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience | 17:26 |
| === wendar_ is now known as wendar | ||
| patod | I am biginner in open source , how can i contribute here? | 17:40 |
| patod | can anybode suggest? | 17:41 |
| strikov | patod: https://wiki.ubuntu.com/ContributeToUbuntu | 17:45 |
| patod | Strikov:Thanks. | 17:46 |
| === tsimpson is now known as lubotu1 | ||
| === lubotu1 is now known as tsimpson | ||
| === udevbot_ is now known as udevbot | ||
| Riddell | who's our ubiquity fixer-uper these days? https://launchpadlibrarian.net/199954530/buildlog_ubuntu-vivid-amd64.ubiquity_2.21.14_BUILDING.txt.gz | 18:25 |
| seb128 | Riddell, we don't really have one afaik | 18:29 |
| infinity | Riddell: cyphermox | 18:29 |
| Riddell | of course it coule be a problem in the d-i component that's causing the failure | 18:30 |
| infinity | I suspect ubiquity needs some munging to deal with the new console-setup. | 18:31 |
| mlankhorst | infinity: we have fglrx now, can you ack 1424980 ? | 18:54 |
| infinity | mlankhorst: Yeahp, go for it. Please don't break the world. Kthx. | 18:59 |
| mlankhorst | sure np | 18:59 |
| kirkland | pitti: I'm going to do another release of ecryptfs that tyhicks has to fix the ftbfs | 19:16 |
| kirkland | pitti: can you send me your postinst changes? | 19:16 |
| kirkland | pitti: I'll test and merge and release those as part of this, if you like | 19:16 |
| kirkland | pitti: ah, I found https://launchpadlibrarian.net/199754367/fix-invalid-cryptswap.sh | 19:21 |
| cyphermox | Riddell: indeed, that file no longer exists, it's now named without the "My" | 19:23 |
| === kickinz1 is now known as kickinz1|afk | ||
| bjf | stgraber, it's looking like MAAS install of vivid was/is leaving me in a totally bizarro state. i'm continuing to investigate but for now i think the problem is not lxc | 19:37 |
| stgraber | bjf: ok | 19:45 |
| bjf | stgraber, when you tested, you didn't use MAAS to install on bare-metal did you? | 19:46 |
| Pwnna | does ubuntu keep a source tree of their kernels? | 19:49 |
| stgraber | bjf: indeed I didn't. I tried on an up to date vivid bare metal system and in a fresh lxc vivid lxc container. | 19:49 |
| bjf | stgraber, just checking. thanks | 19:50 |
| bjf | Pwnna, yes | 19:50 |
| Pwnna | where is it? | 19:51 |
| Pwnna | i'm looking at for builds such as http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.8-vivid/ | 19:51 |
| Pwnna | i think i found a regression | 19:51 |
| bjf | Pwnna, one sec ... that's not the kernel i was expecting you to ask about | 19:52 |
| Pwnna | alright thanks | 19:53 |
| Pwnna | yeah. i'm fairly certain that this is an issue.. | 19:53 |
| bjf | Pwnna, if you look in the SOURCES file: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.8-vivid/SOURCES you will see the git location | 19:53 |
| Pwnna | going from linux-headers-3.18.6-031806_3.18.6-031806.201502061036 => linux-image-3.18.8-031808-generic_3.18.8-031808.201502271935 disables the memory cgroup controller | 19:54 |
| Pwnna | bjf: does that include those patches? | 19:54 |
| bjf | Pwnna, don't know, i've never looked | 19:54 |
| smoser | hm.. stupid question. | 20:00 |
| smoser | my cloud-image has init=/lib/systemd/systemd | 20:00 |
| smoser | pitti, ^ thats a temporary thing, right ? | 20:00 |
| Pwnna | hasn't ubuntu switched over to systemd | 20:02 |
| infinity | Pwnna: Out of interest, why are you running the untested/unsupported mainline builds instead of the distro kernels? | 20:03 |
| Pwnna | features needed, i think | 20:04 |
| smoser | utlemming, is build process doing that ? ^ | 20:04 |
| infinity | Pwnna: That seems unlikely, as the distro kernels tend to have more features, not fewer. | 20:04 |
| infinity | Pwnna: Unless you mean you need newer versions on old releases, which is what the HWE kernels are for. | 20:05 |
| Pwnna | infinity: wait. but the trusty kernel is not 3.18.x | 20:05 |
| Pwnna | right? | 20:05 |
| infinity | Pwnna: No, but the linux-lts-utopic kernel in trusty is 3.16, and the linux-lts-vivid kernel will be 3.19 (and is in the kernel team's PPA). Both of those are much saner options than random mainline debugging builds. | 20:06 |
| Pwnna | so i'm not sure why we're running on mainline kernel | 20:07 |
| Pwnna | i think it may have something to do with some btrfs bug fixes | 20:07 |
| Pwnna | so the regression happened somewhere between .7 and .8 | 20:12 |
| Pwnna | now i just need a diff | 20:12 |
| Pwnna | where does ubuntu develop these patch sets? | 20:26 |
| smoser | xnox, are you going to fix bug 1424509 ? or have you done all you're planning there.. | 20:26 |
| ubottu | bug 1424509 in postgresql-common (Ubuntu) "lsclusters claims clusters are not running, when they are under systemd" [Undecided,New] https://launchpad.net/bugs/1424509 | 20:26 |
| Pwnna | doesn't look like an upstream bug | 20:51 |
| infinity | Pwnna: The mainline builds *are* upstream kernels, with the exception of the few tiny patches applied to make it build for Ubuntu. | 20:52 |
| Pwnna | yeah but those patches change | 20:52 |
| Pwnna | don't they? | 20:52 |
| infinity | Pwnna: We neither "develop" nor support them. | 20:52 |
| infinity | Pwnna: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.8-vivid/SOURCES shows you all the patches applied. It's all packaging stuff. | 20:53 |
| Pwnna | but the patches, 000*, are they changing? | 20:53 |
| Pwnna | it might be a configuration | 20:53 |
| infinity | Pwnna: The configs might change from time to time. All you need to do to see that is 'diff -u /boot/config-$(old_verision) /boot/config-$(new_version)' | 20:55 |
| Pwnna | yeah i'm tryin to do that now | 20:56 |
| Pwnna | infinity: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.7-vivid/ doesn't have the patches? | 20:58 |
| infinity | Pwnna: I tihnk that was before apw fixed how he published them. | 20:59 |
| rbasak | pitti: cloud-utils is stuck in vivid-proposed because of the juju-core dep8 failure. I don't understand why though. | 21:01 |
| rbasak | As in: why does cloud-utils require a juju-core dep8 pass? | 21:02 |
| rbasak | Oh | 21:02 |
| rbasak | It's backwards | 21:02 |
| rbasak | Of course | 21:02 |
| rbasak | pitti: in that case, would it be reasonable to have an exception for the juju-core failure, as we know it's broken but we don't want it to hold everything else up? | 21:03 |
| Pwnna | infinity: http://pastebin.ubuntu.com/10582239/ | 21:07 |
| Pwnna | do you know where i can find the reason why this is changed? | 21:07 |
| infinity | Pwnna: You could ask apw nicely. | 21:08 |
| Pwnna | thanks :) | 21:08 |
| Pwnna | apw: do you have any idea on why the memcg is disabled in 3.18.8 from the kernel options? | 21:09 |
| Pwnna | for ubuntu's mainline build | 21:09 |
| infinity | Pwnna: (Note that it's 9pm for him, I wouldn't expect a quick response) | 21:09 |
| Pwnna | alright | 21:09 |
| dobey | Pwnna: btw, you're aware of #ubuntu-kernel yes? :) | 21:10 |
| Pwnna | i am not :P | 21:10 |
| Pwnna | i need to signoff for the moment though. I'll be back | 21:10 |
| dobey | the kernel hackers hang in there | 21:10 |
| Pwnna | cool. thanks | 21:11 |
| dobey | might be a better place to ask kernel-specific questions | 21:11 |
| apw | Pwnna, if it is enabled for the common case, then it is because it was disabled at the time it was built | 21:40 |
| apw | Pwnna, though sometimes they change the names of configuration options so they are off by default, and we generate those electronically | 21:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!