[04:55] <pitti> Good morning
[04:57] <TripSec> pitti, Good morning
[04:57] <TripSec> sudo apt-get install git, how do I access the dl?
[04:58] <pitti> "dl"?
[05:24] <ming> I added a comment when I use "gpg --gen-key", so should I add the comment in the ~/.bashrc when I export the DEBFULLNAME  ? I always need to add the comment to the changelog when I ues "dch".
[05:25] <ming> by myself.
[05:49] <slangasek> ming: well, consider this article - maybe you want to add a UID to your keyring that doesn't have the comment: http://www.debian-administration.org/users/dkg/weblog/97
[06:30] <dholbach> good morning
[08:08] <doko> barry, given back and it did build
[08:32] <cjwatson> ming: Or you could add DEBSIGN_KEYID=<whatever your key ID is> to ~/.devscripts so that small mismatches don't matter, though the debian-administration.org post above is very sensible too
[08:37] <pitti> xnox, slangasek: is there some special sauce which gets poured over the install images on releases for EFI/secureboot?
[08:37] <pitti> xnox, slangasek: I tried to install my new x230 with saucy beta 1 and saucy daily, and they both are unbootable; /boot/efi/ is completely empty
[08:37] <pitti> xnox, slangasek: installing raring and dist-upgrade worked without a hitch, and I have a working /boot/efi/
[08:38] <xnox> pitti: it should just work, signed shim is uploaded in the archive and should be identical / present on all daily images.
[08:38] <pitti> is that a bug, or expected due to some "special sauce"?
[08:38] <xnox> pitti: i'd be expecting it to be a bug.
[08:38] <pitti> xnox: I don't think that shim was the problem actually; I disabled TPM/SecureBoot/CSM etc. in the setup and it still didn't work; empty EFI partition doesn't sound good, right?
[08:38] <xnox> pitti: good thing to test, is if booting saucy image, actually boots it in EFI mode.
[08:39] <pitti> xnox: it did
[08:39] <pitti> I set it up for "EFI only boot", got the grub-like start screen, and had /sys/firmware/efi, and dmesg babbled about EFI stuff
[08:39] <pitti> ubiquity created an efi partition, but it was empty
[08:40] <cjwatson> That suggests that the installation wasn't as successful as it thought it was.  There are probably errors somewhere in syslog
[08:40] <xnox> pitti: if in the logs (can you mount and check them?) grub-installer failed, you probably want cjwatson.
[08:41] <pitti> ok; I remembered too late to chroot in and save logs, will do that at a test reinstall
[08:42] <pitti> I guess I could make a backup of the EFI partition, dd it to zero, run the saucy installer, collect logs
[08:43] <pitti> I guess it's somehow possible to fix up the install manually, but the only recipes I found were rather complicated (and simple install-grub failed in chroot under live system with "cannot map BIOS drive" or so)
[08:50] <cjwatson> pitti: you should be able to retrieve the logs from a live CD or equivalent
[08:51] <pitti> *nod*
[08:51] <cjwatson> the partman log would be useful as well since it's possible it didn't create/mount an EFI partition
[08:51] <pitti> cjwatson: I meant after I did that it's certainly possible to manually create the EFI partition, so that I don't have to go back and install raring+upgrade
[08:51] <cjwatson> depends on the failure
[09:23] <mlankhorst> I hope mesa 9.2.1 gets accepted :) it fixes only updating the 1024x1024 topleft corner correctly in the tf2/hl2 games with nouveau drivers. \o/
[09:25] <seb128> xnox, hey, just checking fur that apturl/update-manager issue is still on your todolist right?
[09:25] <xnox> seb128: yes.
[09:25] <seb128> xnox, great
[09:37] <infinity> mlankhorst: Lemme have a look.
[09:52] <infinity> smartboyhw: Did you really mean to add ardour3 to ubuntustudio-audio and not remove ardour?
[09:54] <smartboyhw> infinity, yes we do
[09:54] <smartboyhw> Ardour 2 sessions can't be opened again in Ardour 2 if they are opened in Ardour 3 once.
[09:54] <smartboyhw> So, no.
[09:54] <smartboyhw> No removal of Ardour 2.
[09:54] <smartboyhw> (Until after 14.04, that is)
[09:56] <infinity> smartboyhw: Kay.  Just looks a bit weird to have both, but your call.
[10:27] <seb128> mardy, hey, did you receive any bug/are you aware of any issue with uoa/google account? mine keeps asking me to reauth (well, "keeps", I saw that basically once a day for a week, where it used to be weeks before I have to reauth again)
[10:27] <seb128> pitti, ^
[10:28] <mardy> seb128: are you using evolution?
[10:28] <pitti> mardy: for me it's worse now, asking every few hours
[10:28] <pitti> but I just installed a new computer yesterday, so it could be that my old gsettings or whatnot (I didn't move them to the new computer) kept the thing alive
[10:28] <seb128> mardy, no, but I've an e-d-s account configure for calendar
[10:29] <pitti> mardy: not using evo here (as in the application)
[10:29] <seb128> configured*
[10:29] <mardy> seb128: that's it :-(
[10:29] <pitti> but I enabled evo in the online accounts settings
[10:29] <seb128> mardy, that was not happening until recently, do you know what changed?
[10:29] <mardy> pitti: yep, so it's EDS
[10:31] <mardy> seb128: I didn't have a chance to investigate it yet, it's https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1210866
[10:31] <mardy> pitti: ^
[10:31] <pitti> mardy: ah, thanks! /me subscribes
[10:31] <mardy> seb128, pitti: it's due to an EDS upgrade
[10:32] <seb128> mardy, 3.6 to 3.8?
[10:32] <pitti> mardy: I'll try disabling the three EDS options for the google account in the account settings
[10:32] <seb128> well 3.6 didn't have uoa integration
[10:32] <mardy> seb128: most likely that
[10:33] <seb128> I wonder if we should turn off uoa in eds, for saucy, then
[10:33] <seb128> Laney, pitti, mardy: ^
[10:33] <mardy> seb128: what EDS version was there in raring?
[10:34] <seb128> 3.6.4
[10:34] <seb128> that didn't have uoa support yet
[10:34] <Laney> I've been avoiding using it because it was so flaky
[10:34] <Laney> with 2fa anyway, think it's ok without that
[10:35] <mardy> Laney: right, it's most likely due to 2fa
[10:35] <mardy> upstream has fixed the issue in 3.9.something, by switching to Oauth
[10:35] <Laney> yeah
[10:35] <Laney> so I'd be in favour of turning it off
[10:36] <seb128> shrug
[10:36] <seb128> mardy, we are not sure we are going to update to 3.9 for the LTS btw :/
[10:36] <seb128> is there any way to fix that issue on 3.8?
[10:36] <mardy> seb128: not even if we start testing it very early?
[10:37] <mardy> seb128: well, the immediate solution I think would be not installing evolution-data-server-uoa
[10:37] <seb128> mardy, well, I'm suggesting staying on 3.8 (still being discussed), it's likely the version the next RHEL is going to use and it would be nice to align with them, since that's liking going to get more fixes than other series
[10:39] <seb128> mardy, would you suggest installing the goa support then?
[10:39] <seb128> or none of those?
[10:39] <mardy> seb128: backporting the fix might be possible, but it will be a lot of code
[10:39] <mardy> seb128: I'd say none
[10:40] <seb128> mardy, ok, let's see next cycle, I need to look at how much changes in eds 3.10 and it depends on e.g gtk 3.10 (which we are not likely going to have)
[10:40] <Laney> Yeah, we could probably selectively take stuff if it's worth it
[10:41] <seb128> Laney, do you have some spare cycles today? Want to test building e-d-s without the depends on uoa/goa (or just force removal) and test if evolution works correctly/can add a calendar?
[10:42]  * seb128 already has a long todo for the day
[10:42] <Laney> mmm, ok
[10:42] <seb128> Laney, thanks
[10:43] <seb128> Laney, basically I think we agree on dropping uoa from the default install, I just wonder if we need to keep goa or not (it might be that some of the files in there are needed for calendaring, it already turned out that uoa was not working without the goa binary)
[10:43] <Laney> did we have g before?
[10:43] <seb128> yes
[10:44] <Laney> probably just go back to that situation
[10:44] <seb128> raring didn't have uoa yet (that got added to 3.8
[10:44] <seb128> so we were just building with goa and not splitting binaries
[10:44] <seb128> Laney, well, one of the things we wanted to avoid was to have goa-daemon running in Unity session
[11:46] <rbasak> pitti: I filed bug 1235189 the other day. I think your stdout/err pipe thing regressed all non-null drivers.
[12:02] <pitti> rbasak: ah, thanks; adding to my bug fix pipeline
[12:04] <pitti> I ought to write some test cases for at least the chroot runner
[12:07] <rbasak> I'm hoping to land adt-virt-lxc soon, and also adt-virt-kvm. With uvtool in Saucy now together with your pass-through of the cloud image, this should be much easier. Then I imagine a dep8 test for the kvm runner would be relatively straightforward to do (the lxc one will still have an external dependency on the lxc rootfs image)
[12:19] <mlankhorst> can someone kill the mesa-9.1.7-1ubuntu1 upload to raring-proposed? I forgot to open a sru bug for it :)
[12:23] <pitti> mlankhorst: it's not in https://launchpad.net/ubuntu/raring/+queue?queue_state=1&queue_text=
[12:23] <infinity> (I may have beaten you to it)
[12:23] <mlankhorst> ah ty
[12:39] <tvoss_> pitti, ping
[12:39] <pitti> hello tvoss_
[13:09] <mlankhorst> ok any sru admin can approve the new mesa I uploaded to raring then? :P
[13:24] <smoser> infinity, i did commit sane lp:software-properties and re-upload. re-review would be appreciated.
[13:24] <smoser> thanks.
[13:28] <cjwatson> roaksoax: Do you know what's happening with getting pacemaker rebuilt against current libraries?  (cf. http://people.canonical.com/~ubuntu-archive/nbs.html)
[13:28] <cjwatson> We're running out of time
[13:40] <roaksoax> cjwatson: ill take a look
[13:45] <roaksoax> cjwatson: you mean pacemaker-mgmt?
[13:47] <cjwatson> roaksoax: Yeah
[13:56] <Laney> what do I need to make the release upgrader happy to remove a package? ISTR that versioned C&R isn't enough to avoid partial upgrades
[13:56] <cjwatson> C+R is fine
[13:56] <cjwatson> see update-manager 1:0.184
[13:58] <Laney> ah, good
[13:58] <Laney> ta
[13:59] <arges> hallyn: hi
[13:59] <hallyn> arges: hi (mtg about to start)
[14:00] <arges> hallyn: ok real quick is there a wiki/pointer to some qemu tests I can run before i submit my sru to qemu-kvm ?
[14:00] <arges> or should i just use upstream tests
[14:01] <hallyn> arges: lp:qa-regression-testing  cd scripts; sudo python test-qemu.py
[14:01] <arges> hallyn: perfect! thanks
[15:06] <TJ-> According to bazaar importer system "usbutils" has failed to import since July 2012, which means the bzr branch is OUT-OF-DATE. What is the procedure for getting this fixed?
[15:21] <stokachu> is there a public repo for code used to create launchpad builders?
[15:21] <stokachu> i know sbuild mimics it but i thought launchpad has some special adjustments
[15:22] <smoser> stgraber, if i file a FFE for software-properties , can i have it re-evaluated please?
[15:23] <stgraber> smoser: once the FFe is accepted, sure, we can even accept it from the Rejected queue then
[15:23] <smoser> ok.
[15:25] <cjwatson> stokachu: lp:launchpad-buildd
[15:25] <smoser> stgraber, can i just turn bug 1233486 into a FFE bug ?
[15:25] <cjwatson> stokachu: I don't think it's worth trying to set up locally though - the cases where sbuild in the archive isn't close enough are very rare
[15:25] <stgraber> smoser: yep, add [FFe] to the title and subscribe ~ubuntu-release
[15:26] <cjwatson> (Unless you're actually hacking on the builders)
[15:26] <smoser> thank you
[15:27] <stgraber> cjwatson: that reminds me I need to publish my sbuild-launchpad-chroot script at some point (schroot hook that makes you use the Launchpad buildd chroots and keep them up to date as they change on the server side)
[15:27] <stokachu> cjwatson: ok cool, im trying to figure out why mysql fails to build due to unittests but builds in launchpad just fine
[15:27] <stokachu> me and another engineer ran into the same build issue locally
[15:28] <cjwatson> stokachu: The one case that bites people from time to time is that LP builders are blocked from accessing network resources other than ftpmaster.internal and archive-team.internal
[15:28] <cjwatson> (I don't know exactly how - that isn't in lp:launchpad-buildd)
[15:28] <stokachu> ah maybe thats it then
[15:29] <cjwatson> stokachu: So in the unusual case that a package tries to access something on the network and falls back to some other behaviour if it fails ... bit of a long shot though
[15:29] <cjwatson> stokachu: Is this PPAs or the primary archive?
[15:29] <smoser> stgraber, done. thanks.
[15:29] <stokachu> cjwatson: primary archive
[15:29] <stokachu> and its just a couple of unittests that fail causing the whole build to error
[15:29] <stokachu> the code builds fine
[15:30] <stokachu> chiluk: do you have a log of those unittests that failed locally still?
[15:30] <chiluk> let me check
[15:31] <cjwatson> stokachu: Different kernel version?  The primary archive builders will be on precise.
[15:31] <cjwatson> (The base system, that is.)
[15:31] <stokachu> the host was precise that i was on when it happened
[15:31] <stokachu> not sure about chiluk's environment
[15:31] <chiluk> mine is precise + 3.11 (eek)
[15:33] <cjwatson> The buildds are on 3.2
[15:34] <chiluk> I have two different logs, but they fail in two different spots.
[15:34] <cjwatson> If it's racy then maybe the buildds just got lucky.
[15:36] <chiluk> not sure..
[15:36] <chiluk> so the end of my logs say to look at /tmp/buildd/mysql-5.5-5.5.32/builddir/mysql-test/var/log/warnings
[15:37] <chiluk> but I failed at getting those out of pbuidler before it cleaned things up.
[15:39] <chiluk> http://paste.ubuntu.com/6205439/
[15:39] <chiluk> http://paste.ubuntu.com/6205443/
[15:40] <chiluk> cjwatson stokachu ^^ those are the output from my builds... Unfortunately they are not the error logs.
[15:40] <chiluk> infinity says he was able to build just fine though..
[15:40] <cjwatson> Don't use pbuilder to reproduce Launchpad failures
[15:40] <cjwatson> Use sbuild
[15:40] <cjwatson> You might as well at least *try* to be accurate :)
[15:40] <chiluk> cjwatson understood.
[15:40] <chiluk> you asked for logs
[15:40] <chiluk> and that's all I had..
[15:41] <chiluk> my sbuild env is a bit fubar..
[15:41] <chiluk> actually my whole system is a bit fubar at the moment.
[15:41] <rbasak> I do my builds and dev work on a cloud instance, with a script to set one up.
[15:41] <rbasak> Makes stuff reproduciable.
[15:41] <chiluk> I was planning on re-installing today, since so many things are wrong with it... *(too many broken cross dependencies between ppas)
[15:42] <chiluk> cjwatson, stokachu was using sbuild.
[15:42] <rbasak> I have had issues with mysql. I suspect it's a race.
[15:43] <chiluk> my machine must be winning that race!
[15:43] <rbasak> ISTR there being some recent commits to debian vcs to fix some stuff related to that.
[15:43] <cjwatson> That failure looks like a DNS argument
[15:43] <cjwatson> -mysqlcheck: Got error: 2005: Unknown MySQL server host 'not_existing_host' (errno) when trying to connect
[15:43] <cjwatson> +mysqlcheck: Got error: 2003: Can't connect to MySQL server on 'not_existing_host' (errno) when trying to connect
[15:43] <chiluk> the first one looks like that.
[15:43] <chiluk> the second one does not.
[15:44] <chiluk> I eventually just ended pushing it up to a launchpad ppa
[15:44] <cjwatson> ok, don't know enough about mysql to help further
[15:45] <roaksoax> cjwatson: bug #1236414
[15:55] <jodh> ogra_: to rule out gcc attribute issues, it would be helpful to run the nih tests on mako/maguro.
[15:55] <ogra_> what are the nih tests ?
[15:55] <jodh> ogra_: "make check" for the libnih package.
[16:12] <jodh> ogra_: I can now recreate the problem, so don't bother with that.
[16:12] <ogra_> oh !
[16:12] <ogra_> on grouper ? great !
[16:13] <ogra_> now that i trashed my beautiful image with all these build deps ...
[16:14] <ogra_> :)
[16:14] <jodh> ogra_: there are 2 problems - I can't recreate the udev kernel issue, but I can recreate the issue whereby the session init doesn't release memory.
[16:14] <ogra_> yay
[16:15] <ogra_> do you use Mir ?
[16:15] <ogra_> i would expect it to grab the vsync events too on nvidia
[16:17] <ogra_> jodh, touch /home/phablet/.display-mir ... and reboot ...  to switch it on
[16:18] <jodh> ogra_: I'll concentrate on the session init bug; the udev issue is not an upstart bug.
[16:19] <ogra_> jodh, btw, the test build i had started before you told me not to just failed three tests
[16:20] <jodh> ogra_: please raise a bug and one of the upstart devs will review :)
[16:20] <ogra_> jodh, well, i'm building on a writable made phone fs ... not sure how valid this actually is
[16:22] <jodh> ogra_: as long as /tmp is writeable and you aren't using overlayfs, should be valid.
[16:23] <ogra_> ok
[16:25] <slangasek> pitti: any luck figuring out that EFI install issue?
[16:25] <pitti> slangasek: no, not yet; that'll take a few hours as I'll have to trash/reinstall my machine, and I had a lot of post-holiday catch-up to do today
[16:27] <slangasek> pitti: ok
[16:38] <cjwatson> roaksoax: Thanks for the pacemaker-mgmt upload.  I'm a bit concerned that you've dropped all the changes from debian/changelog (and possibly the rest of debian/?) in favour of whatever was upstream.  Was that intentional?
[16:39] <cjwatson> roaksoax: "bzr di -c12 lp:ubuntu/saucy-proposed/pacemaker-mgmt" to see what I mean
[16:43] <cjwatson> roaksoax: In particular you have reintroduced python-central which is a regression
[16:43] <cjwatson> roaksoax: (But please don't just fix that on its own - the whole previous packaging should be restored and merged back in)
[16:44] <roaksoax> cjwatson: yeah so the changes to debian/changelog were unintentional
[16:44] <cjwatson> Looks like debian/copyright has been de-UTF-8-ed as well
[16:44] <roaksoax> cjwatson: yeah. I'll fix that
[16:44] <cjwatson> roaksoax: It looks like a symptom of unpacking the new upstream tarball and not restoring the previous packaging over the top of the debian/ directory it shipped
[16:45] <iraycd> Hi
[16:45] <iraycd> I'm new to development
[16:45] <roaksoax> cjwatson: so I did uupdate ../<pkg>.orig.tar.gz
[16:45] <iraycd> I'm a web developer
[16:45] <cjwatson> roaksoax: It's possible uupdate got very confused by the (anomalous) presence of an upstream debian/ directory
[16:45] <iraycd> Which is the best book to learn ubuntu development
[16:46] <iraycd> :)
[16:46] <iraycd> ??
[16:46] <roaksoax> cjwatson: that's probably what happened. I'll get that fixed
[16:46] <sarnold> JackYu: ah, thanks for the chinese-calendar explanation :)
[16:46] <cjwatson> roaksoax: Still, lots of tasty NBS removals
[16:46] <cjwatson> iraycd: Ubuntu development isn't really geared towards having books that are even slightly up to date.  It's probably better to start somewhere like https://wiki.ubuntu.com/UbuntuDevelopment
[16:48] <iraycd> cjwatson: I know that. But it's difficult for me to follow. Can you tell me few keywords that I need to be familiar
[16:49] <cjwatson> I don't do the web development end of things, so I probably can't give you much more specific advice
[16:51] <iraycd> cjwatson:  :-) . Nice answer. What version control do most of the ubuntu developers workon? where do I need to host the project?
[16:52] <iraycd> cjwatson: Can I use python for developing an app?
[16:53] <cjwatson> bzr, though git is also popular.  Wherever you like, though we offer launchpad.net for hosting (which supports bzr).  yes.
[16:53] <sarnold> iraycd: this seems popular for python-based web applications: http://en.wikipedia.org/wiki/Django_(web_framework)
[16:54] <iraycd> Django is a web framework. How can I use it in native application development?
[16:54] <sarnold> iraycd: ah, sorry, I thought you wanted to do web development stuff on ubuntu. :)
[16:54] <iraycd> :P
[16:55] <iraycd> I use ubuntu for web development. :P
[16:55] <iraycd> I want to develop native apps
[16:55] <iraycd> I want to make a music player
[16:56] <iraycd> I like clementine. But it isn't so user friendly
[16:56] <ogra_> iraycd, i bet you want to be in #ubuntu-appp-devel then ;)
[16:56] <ogra_> (as the channel topic here suggests)
[16:56] <dobey> -p
[16:56] <sarnold> how many 'p's in that?
[16:57] <ogra_> dunno, want some more ? i have a bag full :)
[16:57] <sarnold> hehe :)
[16:58] <iraycd> ogra_: Okay. Cool. This is IRC for Core OS development? :P
[16:58] <ogra_> yeah :)
[16:59] <iraycd> Cool
[16:59] <iraycd> I will get updated from you guys
[16:59] <iraycd> :)
[17:00] <iraycd> bedrocklinux.org
[17:00] <iraycd> I hope this is useful to you guys
[17:00] <iraycd> :)
[17:07] <stokachu> cjwatson: did vlan support ever make it into the debian installer?
[17:07] <stokachu> ive seen some references to vconfig but not actual configuring the vlan
[17:14] <cjwatson> stokachu: not AFAIK
[17:14] <stokachu> cjwatson: ok thanks
[17:19] <roaksoax> cjwatson: ok so this is the diff between the older debian/ and the fixed package: http://pastebin.ubuntu.com/6205805/
[17:21] <cjwatson> roaksoax: I expected to see the removed debian/changelog entries back
[17:21] <cjwatson> roaksoax: oh I misunderstood, sorry, disregard
[17:22] <cjwatson> roaksoax: yep, that looks much cleaner, thanks
[17:22] <roaksoax> cjwatson: and this is with what is currently in archive: http://paste.ubuntu.com/6205816/
[17:22] <roaksoax> cjwatson: np! sorry about that!
[17:22] <sarnold> seb128,pitti, the retracers look dead again
[17:58] <cjwatson> doko: Could you please merge libapache2-mod-perl2 from unstable (or tell me I can)?  All the changes look appropriate, and we need the -D APACHE24 change to get at least one other package to build (libapache2-authcookie-perl)
[18:07] <doko> cjwatson, ok, looking
[18:28] <doko> cjwatson, uploaded
[18:41] <zyga> slangasek: hey
[18:41] <zyga> slangasek: I'm on saucy mountall
[18:41] <slangasek> zyga: ok?
[18:41] <zyga> slangasek: I've added a comment with all the details
[18:41] <zyga> slangasek: not really, I'll do a few more reboot cycles
[18:41]  * sarnold read "I'm on a saucy meatball", which sounded pretty good..
[18:41] <zyga> slangasek: I'll test with static IP
[18:42] <slangasek> on top of spaghetti, all covered with cheese
[18:42] <zyga> slangasek: it all smells like UDP packets going to /dev/null to me + a timeout on top
[18:42] <zyga> slangasek: quick question:
[18:42] <slangasek> zyga: cute, ok
[18:42] <zyga> slangasek: should the 'S - skip M - manual' prompt show up all the time?
[18:42] <zyga> slangasek: when is it being displayed?
[18:42] <zyga> slangasek: is it time based or some event based?
[18:43] <slangasek> zyga: time based; if mountall waits for the mount for 3 seconds, it pops the prompt
[18:43] <zyga> ok
[18:43] <zyga> slangasek: after my network is working normally mount -a finishes in <1s
[18:44] <slangasek> zyga: so your mountall.log has two boot runs in it; in one, /home is 'remote', in the other it's 'nowait'.  Are these both from mountal 2.51, and did you change /etc/fstab in between?
[18:44] <zyga> slangasek: yes, no
[18:44] <slangasek> hmm
[18:44] <slangasek> *very* strange
[18:44] <zyga> slangasek: I didn't touch fstab all day
[18:44] <zyga> slangasek: all I did is reboot twice
[18:45] <zyga> slangasek: (now)
[18:45] <slangasek> so mountall parsed /etc/fstab differently each time(!)
[18:45] <zyga> slangasek: I rm -f the log file before doing that
[18:45] <zyga> slangasek: huh!!
[18:45] <zyga> slangasek: I'll reboot and make sure I was doing that
[18:45]  * zyga would like to rewrite mountall in python, with unit tests and such...
[18:46] <slangasek> would not be accepted in python
[18:46] <zyga> ok, brb
[18:46] <slangasek> unit tests welcome, though
[18:46] <zyga> yeah I know
[18:46] <zyga> in C that's crap though (writing tests)
[18:46] <zyga> slangasek: maybe rust? :D
[18:46] <zyga> anyway, brb - rebooting
[18:48] <zyga> reboot, stuck, I'll poke around
[18:51] <zyga> slangasek: ok, I'm in the recovery shell, all filesystems are mounted, mountall doesn't see that
[18:52] <zyga> slangasek: I take that back, /home/zyga/source isn't mounted
[18:52] <zyga> slangasek: another hint, the log file I'm looking at shows that /home/zyga/source waits for /home
[18:53] <zyga> slangasek: then /home gets mounted
[18:53] <zyga> slangasek: but /home/zyga/source is never mentioned again
[18:53] <slangasek> hmm
[18:53] <zyga> slangasek: does mountall support that scenario?
[18:53] <slangasek> it's certainly meant to :)
[18:53] <zyga> slangasek: yeah, try_mount: /home/zyga/source waiting for /home
[18:54] <zyga> slangasek: then I see stuff like: run_mount: /home: already mounted
[18:54] <zyga> slangasek: as if mountall tried to mount home again
[18:54] <slangasek> zyga: also, this is not the first time that I've seen evidence of NM declaring interfaces "up" before they're up.  Is there any chance you could try dumping ifconfig state to a log file at the point of /etc/network/if-up.d/upstart being run?
[18:55] <zyga> slangasek: absolutely!
[18:55]  * zyga mutters something about network manager being ready for servers 
[18:55] <slangasek> zyga: what's the context of these 'already mounted' messages?  You said you're in recovery shell; so is this from mountall running before you entered the recovery shell?
[18:56] <zyga> slangasek: I'm in tty6 that I've changed to show up early
[18:56] <zyga> slangasek: and I'm looking at mountall.log with less
[18:56] <slangasek> ok
[18:57] <zyga> slangasek: I didn't run the recovery shell this time, sorry for being inprecise
[18:57] <zyga> slangasek: so before net-device-up gets sent -- you want me to dump ifconfig, right?
[18:57] <slangasek> yes
[18:58] <zyga> slangasek: is /tmp mounted at that time?
[18:58] <zyga> slangasek: should be, right?
[18:58] <slangasek> zyga: not guaranteed; just write it out under /run
[18:58] <slangasek> (which is guaranteed)
[18:58] <zyga> slangasek: ok, thanks
[18:58] <zyga> slangasek: ok rebooting
[19:00] <zyga> slangasek: ok, looking at the new eth0.log -- it seems to be fine, I see my address and mask ok
[19:00] <zyga> slangasek: anything you want to look for in particular?
[19:00] <zyga> slangasek: if you want I can allow you to ssh into this box -- it's driving me nuts really :)
[19:01] <zyga> slangasek: http://pastebin.com/JT3FN8eY
[19:01] <zyga> slangasek: that's my mountall.log
[19:02] <zyga> slangasek: http://pastebin.com/XGEj7Zn0
[19:02] <zyga> slangasek: that's mount
[19:02] <slangasek> zyga: so address and mask are there, but nfs still didn't mount right on this boot?
[19:02] <zyga> slangasek: note that mountall says 3/8 remote while all remotes are mounted now
[19:02] <slangasek> hmm
[19:02] <zyga> slangasek: it's mounted after a moment
[19:02] <zyga> slangasek: not when I initially log in via tty6
[19:03] <zyga> slangasek: as my home is set to /
[19:03] <zyga> slangasek: I can patch/build mountall if you give me hints as to what we could try
[19:03] <zyga> slangasek: also please tell me if I should upgrade any of the packages that got affected by libc6 upgrade
[19:04] <zyga> slangasek: I'll add ping silverbox before that event gets sent
[19:05] <slangasek> replied on the bug, I think you probably want to rebuild mountall against precise to drop the deps (should build fine without changes)
[19:05] <zyga> ok
[19:05] <slangasek> currently reviewing this log to see if I an spot anything
[19:05] <slangasek> I do know we get duplicate 'mounting' events for network mounts that are in progress when another network device comes up, but that's just a nuisance that shouldn't have any impact in this case
[19:06] <zyga> ok
[19:06] <zyga> I'll reboot and rebuild mountall
[19:09] <zyga> slangasek: ping and ifconfig look ok, I'm sending one packet and it's working
[19:09] <zyga> slangasek: maybe name resolver fails? my fstab uses names, not IPs
[19:09] <slangasek> zyga: so what I don't understand (and can't reproduce here) is, why, when 'mount -tnfs' is called before the interface is up, does mount not fail immediately with an error?
[19:09] <slangasek> zyga: do you have your names in /etc/hosts?
[19:09] <zyga> slangasek: nope
[19:10] <slangasek> hmm
[19:10] <zyga> slangasek: my local DNS knows about those though
[19:10] <slangasek> how local is local?  loopback?
[19:10] <zyga> slangasek: well LAN, not local
[19:10] <slangasek> ok
[19:10] <zyga> slangasek: ah wait
[19:10] <zyga> slangasek: I have silverbox (the NFS server) in /etc/hosts
[19:10] <zyga> slangasek: so it's fully static, sorry, I forgot I did that
[19:10] <slangasek> right
[19:11] <slangasek> so I bet the difference between my config and yours is that mount.nfs behaves differently on a name resolution failure vs. server unavailable
[19:11] <stokachu> anyone familiar with gns3 and if I have to actually pay to get a IOS to emulate a network configuration?
[19:11] <zyga> slangasek: server unavailable is what? packet loss? NACK reply from the server?
[19:11] <stokachu> i just need to test some vlan functionality
[19:12] <slangasek> in fact, it's probably because mount itself handles network issues gracefully with an immediate error, whereas once we know the address and have passed it to the kernel, the kernel's nfs mounter code does something irritating
[19:12] <slangasek> zyga: "server unavailable" being "no response" or "no route to host"
[19:12] <zyga> a
[19:12] <zyga> ah
[19:12] <slangasek> in this case, it should actually be "no route to host"
[19:13] <slangasek> because the first time through, we're trying to mount your NFS shares before *any* network is up
[19:13] <zyga> slangasek: why is that (why do we try)? isn't that mountall-net.conf?
[19:14] <slangasek> zyga: well, in theory we could have network interfaces that are up before mountall, and which never trigger retries via mountall-net
[19:14] <slangasek> so we always try all the mounts immediately
[19:14] <zyga> slangasek: ah, I see
[19:14] <slangasek> but that runs us into problems when the mount helpers (or the kernel) misbehave, like this
[19:15] <zyga> slangasek: ok, just confirmed that before net-device-up eth0 I have working DNS and ifconfig
[19:15] <slangasek> zyga: anyway, workaround: drop silverbox from /etc/hosts, see if that doesn't fix it for you ;)
[19:15] <zyga> ok
[19:15] <zyga> slangasek: some hairy code I suspect!
[19:15] <zyga> slangasek: there's a lot of bugs on nfs and mounting on launchpad
[19:16]  * zyga reboots without any LAN entries in /etc/hosts
[19:16] <zyga> !!!
[19:16] <zyga> I think it worked, not sure yet :)
[19:16] <slangasek> expected behavior: you'll have errors in mountall.log that say 'mount.nfs: failed to resolve server silverbox: No address associated with hostname" // "mountall: mount /nas/foo [pid] terminated with status 32", but as soon as eth0 is up they'll mount correctly
[19:16] <zyga> slangasek: the S/M prompt showed up for split second then went away
[19:16] <slangasek> ok
[19:16] <zyga> slangasek: still looking at plymouth-text though
[19:17] <zyga> slangasek: ok it's stuck, looking at log files
[19:17] <slangasek> could be the /home/zyga/source again
[19:17] <slangasek> that sounds like a bug in mountall that I haven't heard about before
[19:17] <zyga> slangasek: oddly source is mounted now, still reading logs
[19:18] <zyga> slangasek: last line in mountall log is remote 3/8 again
[19:18] <zyga> slangasek: reading earlier to see what's up
[19:18] <slangasek> yuck
[19:18] <slangasek> I would like this log :)
[19:18] <zyga> slangasek: http://paste.ubuntu.com/6206297
[19:19] <zyga> slangasek: I'll rm and reboot to make sure I don't read stale stuff
[19:21] <zyga> slangasek: same situation, looking at logs again
[19:22] <zyga> slangasek: log from ONLY the last boot http://paste.ubuntu.com/6206309
[19:22] <zyga> slangasek: question -- why does mountall say we have 8 remote fs? -- mounta | grep silverbox
[19:22] <zyga> slangasek: question -- why does mountall say we have 8 remote fs? -- mounta | grep silverbox | wc -l prints 9
[19:23] <slangasek> zyga: because one of them wasn't marked bootwait
[19:23] <zyga> ah
[19:23] <slangasek> (/nas/archive)
[19:25] <zyga> slangasek: ok, I'll rebuild mountall now, unless you want me to do something else
[19:25] <slangasek> zyga: still reading logs, go ahead :)
[19:26] <slangasek> zyga: ok, done reading logs and grr. I'm going to have to think for a bit about how to catch this bug
[19:30]  * zyga downgraded all packages to precise
[19:32]  * zyga calls it a day
[19:32] <zyga> slangasek: I'll rebuild and test more in the morning, thanks for the help slangasek!
[19:34] <slangasek> zyga: sure thing
[19:35] <halfie> I was wondering how you guys invoke "libfaketime" during the build process? is there a package / script which is responsible for this?
[19:35] <slangasek> halfie: we don't
[19:35] <slangasek> however, if one were to do so, you'd use the 'faketime' wrapper command
[19:36] <halfie> slangasek, oh, weren't some of you guys working on doing Reproducible Builds thing?
[19:36] <slangasek> there certainly may be people working on that, but nothing is currently being done for the Ubuntu archive in that capacity
[19:37] <halfie> I see. thanks!
[19:46] <cjwatson> doko: thanks!
[19:46] <cjwatson> doko: um, don't see it though
[19:47] <cjwatson> halfie: work on that is mostly happening in Debian
[19:48] <halfie> cjwatson, oh, yes, they are the "upstream" in this case. but I don't have access to there devel channel ;(
[19:48] <cjwatson> halfie: eh, sure you do
[19:49] <cjwatson> halfie: it's on OFTC.  But you might be better off with mailing lists anyway ...
[19:49] <halfie> that is pretty weird. they seem to have #debian on freenode which is active.
[19:50] <halfie> will go to oftc one
[19:50] <cjwatson> I think that's to collect people who don't bother checking what network it's on :)
[19:50]  * halfie is guilty!
[19:50] <cjwatson> I mean, IRC channels exist as soon as somebody joins them
[19:51] <halfie> right, but you mean 1500 people are wrong at the same time :P ?
[19:52] <cjwatson> I wouldn't expect #debian to be a developer channel
[19:52] <cjwatson> it'll be way too noisy
[19:52] <cjwatson> and yes, I don't see how that's an implausible statement :)
[19:52] <cjwatson> https://wiki.debian.org/IRC
[19:53] <halfie> heh, will try my questions on oftc. I want to do my home-work before I start posting on the mailing list.
[19:54] <tarpman> halfie: spoiler: cjwatson is going to troll you by also being the person who answers you there :)
[19:54] <halfie> LOL
[19:55] <halfie> I am struggling with a hex diffing tool here ;( .. trying to figure out the differences in builds.
[20:05] <slangasek> zyga: hey, you don't have any custom jobs keying on 'mounted' events, do you?
[21:01] <cjwatson> doko: ah, sorry, I see it in unapproved now
[21:08] <smoser> someone able to just reject cloud-init https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=cloud-init
[21:08] <smoser> utlemming found an issue that we'll have to fix, so no need to waste resources on reviewing it.
[21:09] <cjwatson> smoser: done
[21:10] <smoser> thanks cjwatson
[21:22] <slangasek> cjwatson: so I'm seeing strange behavior with grub under SecureBoot on saucy; it seems 'recordfail' is being set somewhere, even though it's not in /boot/grub/grubenv (according to 'grub-editenv /boot/grub/grubenv list'), and I get the boot menu with no timeout for the first option
[21:22] <slangasek> ('set'/'echo $timeout' show no timeout value set)
[21:22] <slangasek> cjwatson: does this sound familiar at all
[21:22] <slangasek> ?
[21:24] <slangasek> cjwatson: also, I'm very confused by the usage of make_timeout() in /etc/grub.d/00_header... which seems to take two arguments, ignoring the first
[21:50] <bdmurray> doko: could you have a look at bug 1234218?
[21:54] <brainwash> which system application/daemon tells network-manager to change its state (awake/sleep) when suspending or resuming?
[21:54] <cjwatson> slangasek: you mean timeout is set to -1?
[21:55] <cjwatson> slangasek: make_timeout> I think that was to try to reduce the delta against upstream
[21:59] <slangasek> cjwatson: I mean 'echo $timeout' returns an empty string, and the grub menu behaves as if it's set to -1
[22:01] <cjwatson> That's not recordfail then
[22:01] <cjwatson> recordfail sets it to -1
[22:02] <slangasek> ok
[22:02] <cjwatson> pastebin /boot/grub/grub.cfg?  (though may not be able to look right now, getting late)
[22:02] <slangasek> any idea why recordfail itself is set?
[22:02] <slangasek> sure, one sec
[22:03] <slangasek> cjwatson: http://paste.ubuntu.com/6206949/
[22:05] <cjwatson> recordfail?  Depends when you're checking
[22:05] <cjwatson> It's *always* set on exit from GRUB
[22:05] <cjwatson> The point of it is that it's set on boot loader exit and cleared on successful boot
[22:06] <cjwatson> I can't see why timeout would be empty here; again, seems to depend when you're making your observations
[22:08] <cjwatson> Oh, are you making your observations from a command prompt accessed via 'c'?  The menu code has probably modified $timeout before you got to look at it, in that case
[22:08] <cjwatson> If recordfail is set in such a command prompt, then it must be being loaded from a grubenv file somewhere; you might like to check whether $prefix/grubenv is actually the one you checked earlier
[22:10] <slangasek> cjwatson: I was checking from within the grub shell, 'recordfail=1' showed up in 'set'
[22:11] <slangasek> and yeah, I just realized I have two disks in this machine... and /boot/efi/efi/ubuntu/grub.cfg is pointing to the wrong one
[22:12] <slangasek> I wonder how that could be
[22:14] <slangasek> hrm, no, it is the right disk
[22:15] <slangasek> or rather, it's a partition *on* the right disk, but not actually the one that's used as the rootfs or /boot or /boot/efi :P
[22:16] <cjwatson> can't remember how that works right now - maybe try sh -x'ing grub-mkconfig
[22:17] <slangasek> ack
[22:17] <cjwatson> (big hammer but it's what I usually do unless I know exactly what I'm looking for)
[22:17] <slangasek> anyway, seems like a tractable bug now, I just need to figure out where grub got the bright idea to look at a partition that's not mounted... and why that partition isn't in my fstab
[22:17] <slangasek> thanks for orienting me :)
[22:20] <slangasek> wow, this partition is special, tune2fs -l doesn't even list a creation date for the filesystem
[22:21] <cjwatson> maybe there are clashing uuids or something
[22:21] <slangasek> not that I see
[22:21] <slangasek> this uuid didn't show up anywhere except on this partition I didn't know I had
[22:22] <slangasek> what's crazy is that it has a full complement of kernels on it, that something must have copied over there
[22:24] <slangasek> stgraber: would you mind taking a look at bug #1234132 and let me know if you agree with the analysis there?
[22:27] <stgraber> slangasek: sounds right, dnsmasq itself is a universe package that IIRC doesn't even ship an upstart job. People installing that package usually get into a lot of weird issues which we sometimes try to accomodate (as was done in lxc, libvirt and NM) but it's not something we should be investing a lot of effort on (since we don't have any product shipping with that package)
[22:28] <slangasek> stgraber: right - do you agree that this is something the dnsmasq package should handle, though, by signalling mountall?
[22:29] <stgraber> slangasek: I'm not aware of how mountall works in that regard but if SIGUSR1 is the usual way of telling it network is ready, then I guess it'd be appropriate
[22:29] <slangasek> ok
[22:29] <slangasek> (yeah, it is)
[22:29] <slangasek> thanks :)
[22:30] <stgraber> assuming dnsmasq starts after the network is ready and can actually resolve stuff by that time (which I doubt it reliably is at the moment)
[22:31] <slangasek> dnsmasq always starts unconditionally *after* the network is up, since it's only started in runlevel 2
[22:31] <slangasek> so the network comes up, mountall very quickly tries to mount, and (in this config) gets a dns failure
[22:32] <stgraber> and doesn't retry?
[22:32] <slangasek> no, because mountall only retries when there's a network event telling it that it should
[22:32] <stgraber> ah right, and you'll get the network event once ifupdown is done but that'll be slightly before dnsmasq actually starts
[22:33] <slangasek> yes
[22:33] <stgraber> dnsmasq should actually be starting as early as it can and have an if-up.d hook to get it to reload whenever a new interface is brought up, that'd fix the problem in a sane way
[22:34] <slangasek> no, we can't start dnsmasq earlier, it'll just fall over for use cases where e.g. /var is a separate partition
[22:34] <stgraber> ah and since /var is not guaranteed to be a mountpoint it can't depend on that...
[22:35] <slangasek> the current configuration, which is 'start dnsmasq after the filesystem is up', is the only reasonable default behavior.  If someone then both wants to use dnsmasq as their only resolver, *and* has network mounts that will block the filesystem event, that's their problem to disambiguate locally :P
[22:37] <stgraber> well, or we could have dnsmasq start on local-filesystem and if dnsmasq depends on a network filesystem to work, then that's clearly their bad :)
[22:37] <slangasek> is it?  today, that works
[22:38] <slangasek> why should you be disallowed to run dnsmasq as a server with /var on nfs?
[22:38] <stgraber> didn't you just say it doesn't? dnsmasq when installed ensures its the only DNS server, so based on what you said above, that currently doesn't work
[22:39] <slangasek> "ensures it's the only DNS server" - that's only the case once dnsmasq has started though, I think?
[22:39] <stgraber> (if 127.0.0.1 is registered in resolvconf, everything else gets ignored)
[22:39] <slangasek> yes, but it's not registered in resolvconf until dnsmasq starts, right?
[22:39] <slangasek> so before dnsmasq starts, this all still works, using the DHCP-provided settings
[22:41] <stgraber> you're indeed correct about dnsmasq/resolvconf. It still won't quite work because the DHCP client also needs /var, so networked /var is bound to be a problem :)
[22:41] <stgraber> unless someone made dhclient less stupid lately and it now survives not being able to write its lease file
[22:42] <slangasek> stgraber: ok, so not DHCP; but /var on NFS, static interfaces in /e/n/i with dns server info, and dnsmasq installed -> works
[22:42] <stgraber> right, that should work
[22:43] <slangasek> right.  so to preserve that (admittedly marginal) use case while supporting Klaus's use case, we have to not move dnsmasq up in the boot order, but instead retrigger mountall once dnsmasq is available
[22:46] <slangasek> cjwatson: ok, looks like this is a problem with grub-install that's in some way specific to lvm.  This system was installed with ubuntu-server and custom LVM; under those conditions, grub-install skips all the load.cfg handling, but apparently doesn't clean up any existing /boot/grub/efi/EFI/ubuntu/grub.cfg (which I presume was there from a previous install attempt)
[22:46] <slangasek> oops, that path is not quite right
[22:52] <cjwatson> slangasek: OK, I can believe that
[23:01] <slangasek> cjwatson: bug #1236625 filed