[00:00] <wgrant> SpamapS: dogfood.launchpad.net is probably handy here.
[00:00] <wgrant> Although only LP devs can upload to it.
[00:01] <wgrant> It is where we do Soyuz QA.
[00:04] <SpamapS> ah
[00:05] <slangasek> hallyn: so qemu-linaro 2011.12 is based on qemu 1.0, which I'm told will break libvirt :)
[00:05] <slangasek> hallyn: (due to version number problems)
[00:05] <slangasek> hallyn: I guess this might be fixed in libvirt 0.9.8?  If you want to merge that from Debian unstable
[00:08] <hallyn> slangasek: fix is already in precise :)
[00:08] <hallyn> slangasek: (bc qemu-kvm 1.0 is in precise)
[00:08] <hallyn> slangasek: did you want to talk about the lvm initramfs/udev fix?
[00:20] <slangasek> hallyn: I do, but I keep not having time to do so :)
[00:21] <slangasek> hallyn: let me see if that doesn't make it back to the top of my queue next week
[00:21] <hallyn> slangasek: cool, thanks - ttyl
[00:34] <SpamapS> slangasek: I just opened up a MP against sysvinit.. I want to get your thoughts on the approach.. its quite untested.. but I'm having a hard time getting a precise VM setup on my laptop at the moment..
[00:34] <SpamapS> slangasek: https://code.launchpad.net/~clint-fewbar/ubuntu/precise/sysvinit/wait-for-long-shutdown-jobs/+merge/85208
[00:40] <slangasek> SpamapS: any reason not to handle stop/killed jobs the exact same way as those that are still start/ ?
[00:40] <slangasek> SpamapS: also, your wait seems to not have a break for the case where there are no jobs left running
[00:41] <slangasek> SpamapS: which means it *always* waits 300 seconds if there are any matches the first time around, even if the job we were waiting for was killed long ago
[00:47] <SpamapS> slangasek: oh right I forgot that break ;)
[00:48] <SpamapS> slangasek: on the why not handle them the same.. I find this easier to analyze.. separation of concerns. It may be more elegant to just omit those as well and increase the timeout from 10 to 300 seconds..
[00:50] <SpamapS> slangasek: also we don't want to wait *at all* for start/ 's .. they're being omitted.
[00:50] <slangasek> SpamapS: oh, wait vs ignore, right
[00:50] <slangasek> ok
[00:50] <SpamapS> my thinking is that stop/killed is a better clue than "just hanging around" so it gives us a good reason to wait longer than 10 seconds
[00:51] <slangasek> right
[00:51] <SpamapS> I think we may also need to add a note in init(5) about kill timeout only being respected up to 300 seconds.
[00:51] <slangasek> well, what about waiting indefinitely?
[00:51] <SpamapS> thought about that.. its an option
[00:52] <slangasek> except that has the problem that if an upstart job *never* shuts down, your ttys are gone and you have no way to usefully inspect
[00:52] <SpamapS> I figured we want a safety valve for the dork who does 999999999999
[00:52] <slangasek> what does that matter?  the process shouldn't actually take that long to die?
[00:52] <SpamapS> it might if it ignores signals
[00:53] <slangasek> yes
[00:53] <slangasek> otoh, 300 is an arbitrary cutoff
[00:53] <slangasek> and I hate those :)
[00:53] <SpamapS> I'm not married to this.. its just the more conservative approach.
[00:53] <slangasek> both options have downsides
[00:53] <SpamapS> it actually has some thought in it (mentioned in another bug about mysql) ...
[00:53] <slangasek> you can be conservative about not prematurely killing processes that are still shutting down
[00:53] <slangasek> or you can be conservative about ensuring the system doesn't hang on reboot
[00:53] <SpamapS> 300 seconds is a long time, but no longer than most battery backup systems will be available.
[00:54] <SpamapS> so for me, 300 is as long as I'm willing to wait for one service, before we start risking the whole system
[00:54] <slangasek> ok
[00:55] <slangasek> I can buy that
[00:55] <SpamapS> there's no actual research in that battery number.. just personal experience.
[00:55] <SpamapS> so I can totally be swayed on that
[00:56] <SpamapS> slangasek: also no need for a break, while [ -n "$(upstart_killed_jobs)" ] means it will exit the loop when there are no more jobs stop/killed
[00:56] <slangasek> well, I don't have a better magic number to offer, and you've convinced me that there are more advantages to not waiting indefinitely :)
[00:57] <slangasek> SpamapS: aha, I think I missed the while condition
[00:57] <SpamapS> ok, I'll try to get this tested in a VM next week
[00:57] <SpamapS> for now I need to hit the road ... Big Bear and 12-24 inches of man made snow await me. ;)
[00:57] <slangasek> SpamapS: :)
[00:57] <SpamapS> slangasek: thanks for the second pair of eyeballs!
[00:58]  * SpamapS disappears
[00:58] <slangasek> SpamapS: I do need to look at more of the diff context; I have a concern I can't currently articulate about making sure we're not delaying other parts of the shutdown waiting for these jobs
=== sagaci_ is now known as sagaci
[03:21] <psusi> TheMuso, so I've managed to overhaul the dmraid package; rebased it on a new upstream release and upgraded it to 3.0 (quilt) format... and tested it on debian.  Do you think you could review it and upload to debian, then sync it back to ubuntu?
=== mglidden_ is now known as mglidden
[08:33] <slangasek> SpamapS: right, so, I think the jobs that are in state stop/killed should *also* be excluded from the kill list because otherwise the process is being killed twice, which it seems to me can only lead to slowing down the graceful shutdown
[08:33] <slangasek> SpamapS: incidentally, I definitely see some weird behavior on shutdown here in precise; the killing of processes seems to take much longer than it seems it ought to
=== yofel_ is now known as yofel
=== sgnb` is now known as sgnb
[13:50] <arekm> hi, is your php dying on this, too? (can be run from cmdline): http://pastebin.com/xjCppEfS
=== fisted_ is now known as fisted
=== AbsintheSyringe2 is now known as AbsintheSyringe
[15:13] <bahr> Hi, I'm currently a .NET developer, and want to learn a new language, and thought contributing to ubuntu would be a nice way to do this. Which languages should I consider if I want to contribute? I would like to start on Python, but are there any projects using this or is it all C and C++?
[15:18] <penguin42> bahr: There is a lot of python, plenty of C and C++
[15:19] <sladen> bahr: Python is a good choice.  There is also some CLR/Mono/C# stuff, but it's not in the default install anymore
[15:19] <sladen> bahr: it's probably easiest if you have a particular goal in mind
[15:21] <bahr> sladen: hm well my main goal was actually just to learn a new programming language, and I though python would be a nice choice, as it is not statically typed compared to c#, and I like ubuntu, and this would give me some kind of motivating project to work on imeediately, and get practical experiences
=== bregma_ is now known as bregma
[15:26] <sladen> bahr: if you select a bug-report in a particular python-based program, you could perhaps work though and try to fix it by changing things
[15:26] <sladen> bahr: most of the Python syntax should be fairly familiar if you know other languages
[15:29]  * lamont struggles to understand why unity/firefox think that my non-fullscreen firefox window should always go full screen when I switch to that workspace
[15:30] <bahr> ok thanks. Does ubuntu have any specific python projects, cause I would like to contribute to it, as I love the operating system :)
[15:30] <bahr> or should I just find a bug on the launchpad thing and work on it?
[15:32] <penguin42> bahr: There is python itself, but I don't think packages that use python are tagged in any particular way
[15:33] <tumbleweed> packages that use python depend on python
[15:33] <bahr> ok
[16:32] <jtaylor> you could learn boo, its dynamic and static typed, similar syntax to python and runs with mono/cli :)
[18:04] <bluefoxicy> ok
[18:04] <bluefoxicy> apt-get install -f .
[18:04] <bluefoxicy> "install ALL the things"
[18:04] <bluefoxicy> .... apt apparently installs regexes.
[18:04] <Ampelbein> of course it does
[18:05] <bluefoxicy> I tried to install ./somefoo.deb :|
[18:05] <Ampelbein> From 'man apt-get': "If no package matches the given expression and the expression contains one of '.', '?' or '*' then it is assumed to be a POSIX regular expression"
[18:06] <Ampelbein> bluefoxicy: You are looking for 'sudo dpkg -i ./somefoo.deb'
[18:06] <bluefoxicy> Ampelbein:  with dependency resolution.
[18:07] <geser> sudo dpkg -i ... ; sudo apt-get -f install
[18:07] <Ampelbein> bluefoxicy: You can use 'sudo apt-get -f install' after the dpkg -i and it should install the deps
[18:07] <bluefoxicy> heh
[18:07] <geser> and check that apt doesn't propose to remove it again
[18:07] <bluefoxicy> interesting
[18:08] <geser> that's how I do it if I'm to lazy to create a repository for it (apt-ftparchive or dpkg-scanpackages)
[18:09] <broder> alternatively, there's gdebi
[19:08] <Frosty-nee> blist
[19:08] <Frosty-nee> whoops, wrong window
[19:08] <Frosty-nee> this isn't &bitlbee :P
=== lardman_ is now known as lardman
[21:13] <infinity> Riddell: opengtl seems incredibly unhappy on all 32-bit arches.
[21:14] <Riddell> infinity: yes I've been getting a bunch of error messages, it's on my todo
[21:14] <infinity> Riddell: Kay, just wanted to make sure it was somewhere on the list.  It's literally the only FTBFS in main for most arches right now, and it offends me. ;)
[21:15]  * infinity discounts the bizarre fact that gcc-4.5 is FTBFS everywhere except for the one arch I expected it to fail on...
[21:16] <infinity> doko: Any idea what's up with gcc-4.5?  Was it a build-dep that was broken and god fixed (ie: why did armhf succeed and everything else not?)
[21:16] <infinity> s/god/got/
[21:17] <infinity> doko: The logs almost make it look like the testsuite is deleting the build tree.  Which seems insane.
[21:18]  * infinity retries on amd64 for kicks.
[21:29] <doko> infinity, killed by intent. ICE's in the testsuite
[21:29] <doko> all with whopper
[21:30] <infinity> doko: Oh, kay.  They all seemed to die at around the same time, didn't realise it was intentional. :P
[21:31] <infinity> doko: So, the fact that the armhf build succeeded is a bad thing? :/
[21:32] <infinity> doko: You might want to do a -10ubuntu2 upload that's actually just reverting to -9ubuntu1.
[21:32] <infinity> doko: Cause accidental retries will land this in the archive.
[21:33] <infinity> doko: Oh, -9ubuntu3, rather.  But whatever.
[21:33] <infinity> doko: In fact, I might do that right now.  You okay with that?
[21:35] <doko> yeah, won't work on this for a while
[21:35] <infinity> Kay, I'll revert then.  Seems saner.
[21:35] <doko> ohh, and we should try to demote it
[21:35] <infinity> MySQL still builds with it. :/
[21:36] <doko> bad pitti
[21:38] <infinity> doko: Revert uploaded.
[21:38] <infinity> doko: I'll jam it through on armhf ASAP to replace the broken one that built.
[21:40] <infinity> And MySQL is SpamapS, not pitti.
[21:40] <infinity> But I believe it was due to an ICE or miscompilation or something?
[21:41] <doko> enoclue, lets get rid of it. you could recheck once -ubuntu1 is built
[21:43] <infinity> -- precise/main build deps on g++-4.5:
[21:43] <infinity> mysql-5.1
[21:43] <infinity> mysql-5.5
[21:43] <infinity> openjdk-6
[21:43] <infinity> -- precise/main build deps on gcc-4.5:
[21:43] <infinity> grub2
[21:43] <infinity> mysql-5.1
[21:43] <infinity> mysql-5.5
[21:43] <infinity> u-boot-linaro
[21:43] <infinity> grub2 is just a question of Colin confirming that bits don't grow too large for the boot sector when built with 4.6, I think that was on his TODO.
[21:43] <infinity> So, MySQL and u-boot.
[21:44] <doko> opendk-6? I think I did drop it
[21:45] <infinity> https://launchpadlibrarian.net/86468559/openjdk-6_6b24~pre1-1ubuntu3.dsc
[21:45] <infinity> 4.5 on arm*
[21:45] <infinity> Any idea why that was?
[21:46] <doko> ice, which is now fixed
[21:46] <doko> will fix with the next upload
[21:46] <infinity> Shiny.
[21:47] <infinity> I'll poke jcrigby about u-boot.
[21:48] <infinity> It may have similar "need to verify code generation" issues as grub.
[21:48] <infinity> Bootloaders are touchy.
[21:50] <infinity> doko: MySQL may take some extra fiddling.  I think SpamapS tried to switch to 4.6 while he was packaging 5.5 and ran into the same bug as before.  But it might be something we can workaround by dumping optimisation on a single file or something.
[21:51] <infinity> doko: Dumping optimisation on the entire build would probably be a Bad Thing for one of our two flagship SQL databases, though.  Worth keeping an old compiler around just for that, if we have no sane choice. :/
[21:52] <doko> well, find out the exact file, and only build that without optimization
[21:52] <infinity> If it was an optimisation issue.
[21:52] <infinity> Let me see if I can find the bug.
[21:54] <infinity> Grr, I know there was an upstream bug somewhere.
[21:56] <infinity> doko: http://bugs.mysql.com/bug.php?id=61509
[21:56] <infinity> doko: And patch attached a month ago!
[21:57] <infinity> doko: I'll test with that a bit later.
[21:57] <infinity> doko: Oh, wait.  That patch is supposedly backporting something from 5.5 to 5.1... And Clint says 5.5 still fails.  Hrm.
=== fisted_ is now known as fisted
[22:59] <infinity> doko: Running mysql-5.5/gcc-4.6 test builds on amd64, powerpc, and armhf here at home to see if I can figure out what the fuss is about.