[00:59] <killown> help me understand why flash was updated for 10.2 on official ubuntu repositories? it's very very bug, alot annoying bugs
[01:03] <persia> killown, we only ship an installer, not flash directly.  That said, the answer is in the changelog: looks like a security update fixing all sorts of outstanding CVEs.
[01:06] <killown> any browser is crashing easily with 10.2
[01:06] <micahg> killown: it's been working fine for me
[01:34] <blackmoon-105> i've create a new project on launchpad
[01:34] <blackmoon-105> the source is already in the universe repo of ubuntu
[01:35] <blackmoon-105> i've set the series in my project
[01:35] <blackmoon-105> but now i don't know how set it
[01:37] <blackmoon-105> no one?
[01:38] <RAOF> Set what?
[01:43] <blackmoon-105> RAOF: Code for this series
[01:44] <blackmoon-105> a message say that i haven't yet told Launchpad where your source code is
[01:45] <RAOF> Hm.  I'm not sure; I've never tried doing that.
[01:45] <RAOF> So it's not *terribly* important if you don't, either :)
[01:47] <persia> You might ask in #launchpad: they tend to be a bit better about advice on using LP for projects
[01:47] <blackmoon-105> persia: ok, thank you
[02:35] <broder> what are the practical implications of the beta 2 vs. rc swap? is it just that we'll be rolling a thing-that-looks-like-a-pre-release a week sooner?
[02:38] <persia> broder, Also, because we'll be in beta2 soft-freeze from probably Tuesday before Final Freeze (hard), it reduces the time available for the last-minute fix that isn't OMG-kittens by a couple days.
[07:15] <poolie> asac, hi?
[07:36] <didrocks> good morning
[07:38] <dholbach> good morning
[08:07] <pitti> Good morning
[08:08] <poolie> hi pitti
[08:46] <al-maisan> Hello, upgraded to the 2.6.38-3.30 kernel this morning and laptop (thinkpad t410) froze twice on resume from suspend (nothing in /var/log/syslog) .. is this a known issue?
[08:47] <al-maisan> FWIW the 2.6.38-2.29 kernel does not exhibit this problem
[08:53] <bryceh> al-maisan, probably you should be on #ubuntu-kernel...
[08:53] <al-maisan> bryceh: thanks for the pointer
[08:53]  * al-maisan relocates
[08:55] <pitti> ara: so the plan is to roll the (supposedly) final 10.04.2 CDs today, right?
[08:55] <pitti> cjwatson: ^
[08:56] <pitti> ara: dpm and I are currently testing some more langpacks, then I'll move the tested ones to lucid-updates, and we'll do the final rebuild, so that they will be available in ~ 4 hours; does that sound ok?
[08:57] <pitti> cjwatson: FTR, disabling lucid cron jobs now
[08:59] <dpm> pitti, ack. Let me see if I can test the Spanish one as well, as discussed
[09:02] <pitti> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[09:02] <pitti> o_O
[09:02] <pitti> is that just me?
[09:03] <pitti> ah, LP maintenance
[09:03] <didrocks> yeah, not only you pitti :)
[09:09] <ara> pitti, we are still testing the latest laptops, but so far it goes well. I guess we will need to respin in case we find anything in the latest laptops, but even the ones that are not 100% done, we have already run some tests on them, so I would be surprise to find anything
[09:10] <pitti> ara: yeah, I don't expect any breakages either
[09:10] <pitti> ara: but in last meeting we said that we should have finals on Friday
[09:10] <pitti> so I wanted to coordinate with you whether "in ~ 4 hours" is enough
[09:11] <ara> pitti, sure thing
[09:15] <poolie> pitti, didrocks, sorry
[09:15] <poolie> this time for sure
[09:15] <poolie> http://blog.launchpad.net/general/launchpad-read-only-09-00-utc-11th-february-2011
[09:20] <asac> poolie: ?
[09:23] <janimo> mvo, hi I have a question related to package availability notifications, maybe you know what the best choice is. For arm images we want to notify the user when a new bootloader package is available. Can this be done using currently available components withoiut having that package previously installed?
[09:24] <janimo> mvo, as we do not currently install the bootloader packages in the image, they are only on a separate boot partition written at image creation
[09:27] <mvo> janimo: hello, could you have a meta-package that points to the right package that you then upgrade? like linux-image -> linux-image-$version ?
[09:28] <mvo> janimo: or a empty "bootloader" package that you can later (if needed) can fill with life
[09:28] <janimo> mvo, we have about 8 binary packages, (2 sources * 4 arm falvours)
[09:29] <janimo> mvo, do we need to have soemthing installed to be able to check ?
[09:30] <janimo> I guess that is what we need to do, maybe have all these preinsatlled
[09:30] <janimo> and be notified when they are new
[09:30] <mvo> janimo: it seems like the best choice to make it a package (even if initially empty) as it will seamlessly integrate with all our tools
[09:30] <janimo> I was told jockey could help with this situation but no further details
[09:31] <janimo> mvo, I'll check how linux image does it if that is a solution
[09:31] <mvo> janimo: right, I guess that would work, but I don't really see the benefits
[09:32] <janimo> mvo,  I cannot judge either way. The use case is, when we have a new bootloader ready, niotify the user so they can install if they want to. So optional
[09:32] <janimo> An otion is have all these packages preinstalle,d and when they update have a dpkg hok notify the user that it can flash it if they want
[09:33] <mvo> janimo: what is the benefit for the user (just out of curiosity)
[09:33] <mvo> janimo: but yeah, my feeling is it should just be a package
[09:34] <janimo> mvo, the whole use case you mean? Sometime the bootloader has a bug which prevents some hw feature being enabled
[09:34] <janimo> so sometimes they can be instructed to flash a new one if they really want that feature - usually nothing serious but nice to have
[09:35] <janimo> I don;t know any examples as I wasn;t around in 10.10 but something like not setting up some voltage, and the kernel not being able to set it by itsel
[09:36] <janimo> mvo, if it is a package, how does a post-install  hook notify the user (either in the notification area, or especially in headless at the next login)?
[09:38] <mvo> janimo: not sure I understand, why would the user need to be notified post-upgrade? is there something he/she needs to do?
[09:39] <janimo> mvo, yes, these flashings of bootloader would be optional. apt only installs the files on the filesystem, but in order for them to be used at boot they need to be specifically put by another tool into a boot partiotion which is usually not mounted
[09:39] <janimo> so the files formthe package are only needed to have the blobs ready for the flashing tool
[09:39] <janimo> and being a potentialy risky operation it was decided it should not happen automatically
[09:40] <janimo> but the user would use a command line tool to do it
[09:40] <mvo> janimo: aha, now I get the full picture
[09:40] <janimo> so on login the user would see, new version of U-boot available, you may want to flash it to the boot partition using tool-xxx
[09:41] <janimo> mvo, sorry for not explkaining it better in the first place
[09:41] <janimo> mvo https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
[09:41] <janimo> here's a rationale
[09:42] <mvo> janimo: check https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging#Interactive%20upgrade%20hooks
[09:42] <mvo> janimo: or https://wiki.ubuntu.com/InteractiveUpgradeHooks
[09:42] <janimo> mvo, thank you for the links and the advice
[09:43] <mvo> janimo: the UI is not that great, the longer term goal is to make this much more plugable and flexible, but that relies on some of the cool new upstart session support
[09:43] <janimo> mvo, if it notifies and works in console mode it is fine for us too
[09:44] <mvo> oh, console mode?
[09:45] <janimo> mvo, we wil have headless images as well
[09:45] <janimo> I was told the kernel install hooks at least print out some message on first login if some action is required
[09:45] <janimo> but I had not seen that in action yet
[09:47] <mvo> janimo: in this case its probably best to hook into update-motd
[09:48] <janimo> mvo, I am looking at that now, it says it is superceded by pam-motd, I'll ask in the server team maybe they have such scenarios more often
[09:48] <janimo> thanks for the pointers
[09:56] <mvo> yw
[10:03] <gerth> I experienced several problems with mawk 1.3.3 in Ubuntu 10.10
[10:04] <gerth> I found a site with a new maintained version: http://invisible-island.net/mawk/
[10:04] <gerth> This version solves all problems I had with mawk
[10:05] <gerth> gawk and mawk now to the same
[10:06] <hyperair> gerth: please report the bugs on bugs.launchpad.net/ubuntu/+source/mawk
[10:06] <gerth> OK
[10:08] <hyperair> thanks
[10:13] <persia> janimo, Do be careful: changing the bootloader is the easiest way to brick a device: if the old bootloader is configurable, and you can load a new kernel, this is almost certainly safer.  This is all the more true for devices that do not have a separate preboot environment from bootloader.
[10:17] <cjwatson> pitti: right, that's what I was expecting ... do you want me to take care of builds?
[10:18] <pitti> cjwatson: if you want to, sure; but I need to copy the langpacks to -updates first and get them published
[10:18] <pitti> LP is back up now, doing that now
[10:21] <pitti> oh noes
[10:21] <pitti> 2011-02-11 10:21:18 ERROR   Unhandled exception
[10:21] <pitti>  -> http://launchpadlibrarian.net/64023385/3fXOMNPsLdTZdUGxZ1qA5uyCv1P.txt (FATAL:  Ident authentication failed for user "archivepublisher"
[10:21] <pitti> FATAL:  Ident authentication failed for user "archivepublisher"
[10:22] <pitti> looks like some problem with postgresql?
[10:22] <pitti> StevenK, lifeless: ^ do you know who we can ask about this?
[10:22] <pitti> (copy-package.py failure)
[10:23] <StevenK> Awesome. That's fallout from the rollout.
[10:23] <StevenK> lifeless, wgrant: Pls fix, I'm on holidays
[10:23] <lifeless> pitti: see internal IRC
[10:23] <lifeless> for less zomg things, contact any dev in #launchpad
[10:23] <lifeless> pitti: see francis email about the reorg for full details
[10:41] <gerth> bug report mawk: https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/716920
[10:44] <persia> #ubuntu-bugs is likely a better place to coordinate bug reports
[10:44] <pitti> cjwatson: cocoplum is happy again, and I copied the tested lucid langpack updates now
[10:52] <cjwatson> Riddell: kubuntu-mobile: you need to propose a Launchpad change to cronscripts/publishing/cron.germinate that adds kubuntu-mobile to the 'for distro in' list
[10:52] <cjwatson> since the task doesn't exist
[10:54] <cjwatson> pitti: OK, so we should be good to start builds after the next publisher run?
[10:55] <pitti> cjwatson: yes, from my side
[10:55] <janimo> persia, I try to be as careful as I can given that the goal _is_ to change the bootloader :)
[10:55] <pitti> cjwatson: but let's verify madison after that, just be sure (after the recent db trouble)
[10:55] <persia> janimo, well, depends.  Make sure the user is already running a packaged bootloader beforehand.  If the user is running the vendor bootloader, they may prefer it that way.
[10:56] <janimo> persia, the update is not automatic, so the user will run the update if they think it is wise
[10:57] <persia> That seems safer.  I just worry: it's akin to a BIOS update, which many folk happily never do for the lifetime of their device.
[10:57] <janimo> persia, sure, I hope they won't have to do it too often on our images as well.
[10:58] <janimo> persia, honestly I think this spec is a bit silly and contrived, but I was not at the UDS so I may misjudge how useful it is overall
[10:58] <persia> Why would they have to do it ever?  I can imagine wanting to do it, but I don't see when it would be a must, once the kernel is loaded.  It's not like there's data stores used (e.g. dmidecode)
[10:58] <Riddell> cjwatson: ok, how do I do that, bug on soyuz?
[10:58] <janimo> persia, there were bugs during maverick which only an x-loader update could cure
[10:59] <janimo> the kernel not being up to the task
[10:59] <janimo> low level twiddling probably
[10:59] <persia> Sure, but that was for a pre-retail device.  Anyway, if it's a spec, worth implementing.  Just be careful.
[11:00] <janimo> persia, there are going to be other pre retails devices further down I guess, so having the possibility is useful.
[11:01] <persia> janimo, Absolutely.  I just worry about the post-retail case: I don't want you to brick my handheld just because it needs some special tweak in the bootloader :)
[11:02] <janimo> persia, I hope we'll be wise enough not to put new updates via SRU unless absolutely useful. And this only targets SD card/OMAP, so it is a very soft kind of bricking
[11:02] <janimo> nothing that someone who uses this cmdline tool cannot fix with a littel IRC help
[11:02] <persia> janimo, Except if I use a blaze, which uses a hardwired (non-removable) eMMC, rather than SD.
[11:02] <janimo> not actual firmware update like x86 BIOSes
[11:03] <cjwatson> Riddell: bug on launchpad, and it's probably quickest if you attach a branch
[11:03] <persia> Anyway -> -arm
[11:03] <cjwatson> Riddell: I'm updating tasksel
[11:03] <janimo> persia, right now I put beagle,igep and panda in the handled list. We'll see if others will be added, but it is explicit
[11:04] <persia> Ah, that's being careful :)
[11:11] <Riddell> cjwatson: a branch of what?  soyuz?
[11:12] <cjwatson> Riddell: launchpad, it's all one piece
[11:13] <cjwatson> Riddell: oh, if you don't already know how, I'll do it
[11:13] <Riddell> cjwatson: I'd be interested to learn though
[12:18] <cjwatson> pitti: so which packages should we verify?  language-pack-de is at 1:10.04+20110204
[12:19] <pitti> correct, and language-pack-fi at 1:10.04+20110204.1 (manual update)
[12:19] <pitti> cjwatson: so, all green from my side
[12:21] <cjwatson> ok, I'll just do a manual sync to check that antimony's mirror will pull the right things
[13:03] <cjwatson> pitti: building
[13:08] <ScottK> barry: Nice job on the numpy doc fix.
[13:23] <soren> Is it just me, or does mountall not handle SIGPIPE *at all*?
[13:24] <cjwatson> yow
[13:24] <cjwatson> Riddell: is it known that you can't do a Kubuntu install with 512MB of RAM at the moment
[13:25] <cjwatson> ?
[13:25] <cjwatson> well, at least not in debug mode ...
[13:25] <cjwatson> maybe it'll work better if I use the debug-ubiquity boot parameter rather than starting a desktop first
[13:27] <cjwatson> oh, sod it, I'll just bump the memory for now
[13:28] <Riddell> cjwatson: I don't think I've tried
[13:29] <cjwatson> I switched to -m 768, I just habitually use -m 512
[13:44] <Riddell> cjwatson: does bug 716311 seem like it would be caused by bug 680328 ?  if so should I backport the three patches to packagekit?
[13:47] <cjwatson> Riddell: um - the fixes were ported *from* packagekit to qapt
[13:47] <cjwatson> Riddell: oh, do you mean to older releases?
[13:48] <cjwatson> Riddell: yes, I think we probably ought to backport those to packagekit, qapt, and possibly aptdaemon (though I think it's different there)
[13:50] <Riddell> cjwatson: ok I'll take a look at that
[13:52] <cjwatson> great, thanks
[14:13] <soren> cjwatson: You've touched mountall before. I can't seem to find a bzr branch for it? Any hints?
[14:14] <cjwatson> lp:ubuntu/mountall
[14:14] <soren> Ah.
[14:14] <soren> cjwatson: Ta.
[14:55] <soren> cjwatson: Would you mind reviewing a mountall patch for me? It's not very big.
[14:56] <soren> https://code.launchpad.net/~soren/ubuntu/natty/mountall/sigpipe-handler
[15:00] <cjwatson> soren: a bit deep in yak-shaving at the moment - could you mark me as the reviewer on a MP?
[15:00] <soren> cjwatson: Will do. I wasn
[15:00] <soren> t sure who would be the reviewer by default.
[15:02] <bdrung> tumbleweed: u-d-t build failure: http://launchpadlibrarian.net/64035083/buildlog_ubuntu-natty-i386.ubuntu-dev-tools_0.116~daily%2Bbzr1012~natty1_FAILEDTOBUILD.txt.gz
[15:03] <soren> cjwatson: MP filed with you as the reviewer. Thanks. If you don't get to it today, I might bug someone else to review it.
[15:05] <tumbleweed> bdrung: I can look at fixing that in the morning
[15:09] <kirkland> @pilot in
[15:09] <kirkland> hold on to your butts, ladies and gentlemen...today's patch pilot has arrived  :-)
[15:15]  * pitti closes his seat belt
[15:15] <pitti> go, Dustin, go!
[15:41] <ogra> cjwatson, any idea why http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/ubuntu-netbook/ doesnt get updates anymore ? i see current/, latest/ and 20101119/ (?!?) having a fresh timestamp but no logs
[15:44] <cjwatson> ogra: isn't that just for the i386 netbook image, which is no longer being built?
[15:44] <ogra> oh, might be
[15:50] <GunnarHj> cjwatson: Hi Colin, considering your comments at https://launchpad.net/bugs/666565, it would be great if you could spare a minute or two to act on the comment I posted on Feb 3.
[15:59] <cjwatson> GunnarHj: I've replied briefly
[16:03] <cjwatson> RAOF: did I ask you for some debugging information on the GRUB problem with corrupted video on Thinkpads?  I'm sure I remember doing so, but I can't find the mail
[16:12] <GunnarHj> cjwatson: Thanks! Then, how about just replacing .utf8 with .UTF-8 to start with, and introduce parsing of .../SUPPORTED later on, if the simplistic solution proves to not suffice?
[16:16] <cjwatson> GunnarHj: it would likely be an improvement, at least
[16:18] <kirkland> cjwatson: I'm on patch pilot duty, and I willing to sponsor SpamapS' ssh fix at https://code.launchpad.net/~clint-fewbar/ubuntu/natty/openssh/init.d-chroot-aware/+merge/48070
[16:18] <kirkland> cjwatson: unless you'd prefer I left it to you...
[16:18] <cjwatson> oh, actually I'd sort of like to read through that so that I know what's going on later
[16:18] <cjwatson> can you leave it to me?  I promise to get it done today
[16:18] <kirkland> cjwatson: fair enough, i'll bypass
[16:18] <kirkland> cjwatson: sure thing, no worries
[16:21] <janimo> hyperair, hi, is banshee 1.9.3 planned to be updated?
[16:22] <GunnarHj> cjwatson: Ok, then I include .utf8 => .UTF-8 in a couple of MPs, so we get it confirmed that it's an improvement, to start with.
[16:52] <dholbach> can somebody have a look at the u-d-a moderation queue?
[16:53] <hyperair> janimo: yes.
[16:55] <sebner> bryceh: is there currently some b0rken font rendering known bug? Using nvidia but only installed the normal xorg updates (so no dist-upgrade)
[16:58] <cjwatson> dholbach: done
[16:59] <dholbach> thanks cjwatson
[17:21] <bryceh> sebner, there's been a few font rendering issues reported on natty.  However they've ended up all being unrelated problems, so you should probably report your issue separately.
[17:23] <sebner> bryceh: well, I'm seeing this issue since yesterday. Have you got some links for me (or can tell me against which packages they were filed) so I can check before filing a new bug
[17:24] <bryceh> sebner, just do ubuntu-bug xorg and we'll sort it out.  Include a photo of the corruption
[17:25] <bryceh> if you can, file the bug after you've reproduced the corruption, and outline the steps you take to reproduce the bug
[17:27] <sebner> bryceh: reproduce = start system ^^, well my backgroundimage looks a little bit broken (the black part) but if I make a screenshot of the b0rken font it looks normal on the screenshot :\
[17:31] <alexbligh> I'm sure this is really obvious, but is there any way to skip the "make" stage of building a package (I'm typing "debuild -us -uc" and I know all I have changed is the install stuff)
[17:31] <cjwatson> you can often do  fakeroot debian/rules binary
[17:31] <james_w> alexbligh, try ./debian/rules binary
[17:31] <james_w> ah fakeroot, yeah
[17:31] <bryceh> sebner, yeah you need a photo
[17:32] <alexbligh> cjwatson, james_w, thanks
[17:32] <sebner> bryceh: will try, why does a screenshot on the broken backgroundimage/game works though?
[17:39] <alexbligh> OK, one more. If I am overriding dh_auto_configure in debian/rules, do I need to pass ALL the parameters, or just the additional ones I need? Specifically, do I need to pass --prefix and --sysconfdir, and should they be set to /usr and /etc/foo or to `pwd`/debian/tmp/usr (etc.)
[17:40] <cousteau> is there any channel about help relating packages on repositories?
[17:41] <pitti> zul, kirkland: do you now who is working on eucalyptus in the server team these days?
[17:42] <zul> that would be daviey
[17:42] <cousteau> (particularly, I'm wondering why Flash was updated to 10.2)
[17:42] <pitti> Daviey: we have a question wrt. xulrunner in main; eucalyptus build dep gwt build-dep swt-gtk build-dep xulrunner
[17:42] <pitti> Daviey: do you think this chain could be broken anywhere?
[17:43] <chrisccoulson> Daviey, we're trying to drop xulrunner out of main
[17:43] <pitti> (if we could drop swt-gtk, so much the better -- it's only in main for this one reason)
[17:44] <cjwatson> alexbligh: just the extra ones you need; and they should be set to the real destination locations, not the temporary ones in the build tree
[17:44] <cjwatson> (with reasonably conventional build systems, anyway)
[17:44] <smoser> anyone know about peristent net rules ? i'm wanting to add to the 'globally_administered_whitelist' in /lib/udev/rules.d/75-persistent-net-generator.rules
[17:44] <smoser> i wanted to do so without editing the file
[17:44] <smoser> is that possible in /etc/udev/rules.d ? or is that too late.
[17:45] <pitti> smoser: locally, or should that go upstream?
[17:45] <smoser> well, locally for now.
[17:45] <smoser> its arguable if it should go upstream
[17:45] <smoser> eucalyptus uses 'd0:0d' as a prefix (ie "dude")
[17:46] <alexbligh> cjwatson, thanks. I am not using dh_auto_install or whatever anyway (as I am overriding it) so that makes sense. I am trying to make a dhcpd package that is, um, less baroque than the current one...
[17:46] <pitti> smoser: I'm afraid you can't just specify a single rule in /etc; you'd need to copy the entire file to /etc and edit it
[17:46] <pitti> smoser: as the checks and actions are all in just one file, there's nothing "in between"
[17:46] <alexbligh> smoser, Eucalyptus should have paid their $3000 for a MAC range allocation I think..
[17:46] <pitti> smoser: if that is an officially registered prefix, I see nothing wrong with committing it upstream
[17:46] <smoser> alexbligh, that is not arguable, you are correct.
[17:47] <smoser> pitti, they didn't happen to be assigned "dude".
[17:47] <smoser> :)
[17:47] <alexbligh> smoser, if you are doing what I think you are doing (where all interfaces are virtual), why don't you just disable ALL interface persistence. That's what we do
[17:47] <alexbligh> we just remove the file
[17:47] <smoser> ah.
[17:47] <alexbligh> (i.e. the file to build it)
[17:47] <smoser> that makes sense for my local hack
[17:48] <smoser> you'r saying just rm /lib/udev/rules.d/75-persistent-net-generator.rules
[17:48] <pitti> http://www.coffer.com/mac_find/?string=d00d
[17:48] <pitti> nothing official :/
[17:48] <alexbligh> smoser, yes. It causes a huge amount of problems and counterintuitive behaviour. I'd vote for removing it from UEC images
[17:48] <pitti> smoser: so yeah, local hack for now, I'm afraid
[17:48] <alexbligh> (or having some /etc/default type thing to disable it)
[17:48] <pitti> smoser: or we patch it in the Ubuntu package
[17:49] <smoser> pitti, i might open a bug for ubuntu local mod
[17:50] <pitti> so, good night everyone, have a nice weekend!
[17:50] <alexbligh> smoser, there is also (just so you know) a bug with Xen where the PV driver MAC address and the non-PV driver MAC address are the same (as it's the same interface). One is ignored by udev, one isn't, which causes all sorts of random renaming and failure to reboot.
[17:50] <alexbligh> which is the other reason we remove the file...
[17:52] <cjwatson> alexbligh: uh, isn't isc-dhcp in natty reasonably current already?
[17:52] <Daviey> pitti, Hmm...  TBH... i'd need to do a trial build.
[17:52] <alexbligh> cjwatson, we have local patches (see http://blog.alex.org.uk/2010/12/02/adding-sql-support-to-dhcpd-part-2/)
[17:52] <Daviey> pitti, But as it stands euca is still FTBFS'ing in Natty.. which is making me cry.
[17:53] <alexbligh> cjwatson, , and no, it's 4.1 not 4.2
[18:02] <kirkland> pitti: yeah, like zul said, it's Daviey
[18:10] <kirkland> slangasek: howdy
[18:11] <kirkland> slangasek: we're running into some contention building/uploading qemu-kvm
[18:11] <kirkland> slangasek: qemu-linaro and qemu-kvm are producing some of the same binary package names
[18:11] <slangasek> kirkland: oh?
[18:11] <kirkland> slangasek: https://launchpad.net/ubuntu/+source/qemu-linaro
[18:11] <slangasek> kirkland: qemu-kvm is supposed to drop those packages
[18:12] <slangasek> Serge took the action to clean that up on the qemu-kvm side - do you need me to knock them out?
[18:12] <kirkland> slangasek: qemu-keymaps?
[18:12] <kirkland> slangasek: qemu-system
[18:12] <kirkland> slangasek: i can probably handle it;  i just want to make sure i get it right
[18:12] <kirkland> hallyn: you around?
[18:13] <slangasek> kirkland: hum? those packages were never part of qemu-kvm before
[18:14] <kirkland> slangasek: okay, it looks like it's just [qemu-kvm-extras, qemu-kvm-extras-static]
[18:14] <slangasek> kirkland: yes
[18:14] <kirkland> slangasek: right, sorry about that noise
[18:14] <slangasek> n/p :)
[18:14] <kirkland> slangasek: okay, so i just need to drop those from our build
[18:14] <kirkland> hallyn: do you have a branch with that already?
[18:17] <slangasek> kirkland: it also means you should update the build to only build for the targets that get packaged in qemu-kvm itself... that will substantially reduce the build time
[18:18] <slangasek> janimo: did you land the CFLAGS workaround for qemu-kvm on armel?
[18:18] <janimo> slacker_nl, no, it was serge hallyn
[18:18] <slangasek> janimo: ok, but it's done now - great :)
[18:18] <janimo> yes, I just filed the bug
[18:19] <janimo> slangasek, any news on the porting queue project?
[18:19] <slangasek> janimo: I'll be doing some initial population of the queue today, with plans for our first jam session next Wednesday
[18:20] <Keybuk> slangasek: I saw a video on YouTube yesterday and thought of you ... ;-)
[18:20] <slangasek> Keybuk: uhoh? :)
[18:20] <Keybuk> slangasek: http://www.youtube.com/watch?v=AVmq9dq6Nsg
[18:21] <kirkland> slangasek: right, debian/control, and debian/rules
[18:21] <slangasek> Keybuk: putabirdonit.com
[18:22] <slangasek> :)
[18:22] <slangasek> kirkland: yep; the target selection is a bit non-obvious, but I guess you may be familiar with how it goes :)
[18:22] <kirkland> slangasek: shall i drop armel from the build entirely?
[18:23] <Keybuk> slangasek: ;-)
[18:23] <slangasek> kirkland: you should only be building those targets that are going to be packaged in the qemu-kvm binary... so x86*/powerpc?
[18:24] <slangasek> kirkland: looks like qemu-i386, qemu-x86_64, and qemu-system-"" are the only bits that we build from here, so those are the only targets that should be selected
[18:24] <slangasek> (and the 'user' build phase should be dropped entirely)
[18:24] <kirkland> slangasek: k;  i'm hacking on it;  will pastebin a diff to settle upon before uploading
[18:25] <slangasek> kirkland: pastebin? pff, push a branch! :)
[18:25] <nigelb> heh
[18:25] <kirkland> slangasek: i spent my morning working in the customer lounge of the VW service department;  bzr sucks over a slow link;  apt-get source + pastebin was my friend
[18:26] <Keybuk> slangasek: the discovery of this show is nearly as awesome as when ev introduced me to Canadian Trailer Park Boys (the story of cody-somerville's life)
[18:26] <hallyn> kirkland: oh, no, i haven't done a branch without qemu-kvm-extras yet
[18:26] <kirkland> slangasek: alas, i'm back home now, on a good up/down link; so sure, a branch
[18:26] <hallyn> is that just a matter of removing that from the control file?
[18:26] <slangasek> kirkland: is that because bzr sucks over a slow link, or because you had a local apt source repo?
[18:26] <kirkland> hallyn: okay, i'm trying to sort it out now
[18:26] <alexbligh> cjwatson, hmm "fakeroot debian/rules binary" just produces the output "dh  binary" and does nothign else
[18:26] <slangasek> Keybuk: <snort>
[18:26] <hallyn> kirkland: cool, thanks
[18:26] <kirkland> hallyn: it's a bit more of a mess in debian/rules
[18:26] <hallyn> kirkland: fwiw, natty boots fine with -std vga in qemu :)
[18:26] <kirkland> hallyn: the debian/control part is easy
[18:27] <kirkland> slangasek: i had no local apt source
[18:27] <slangasek> alexbligh: that means it's been run before; dh aggressively caches the results
[18:27] <slangasek> kirkland: interesting
[18:27] <slangasek> alexbligh: you would need to run 'debian/rules clean' first
[18:28] <alexbligh> slangasek, I am attempting to avoid recompiling (i.e. doing the make). Won't debian/rules clean clean the make?
[18:28] <hallyn> kirkland: and simply rm debian/qemu-kvm-extras* ? :)  feels reckless
[18:28] <kirkland> hallyn: yeah, that too
[18:29] <slangasek> alexbligh: yes, it will.  You could try running 'dh_prep', it's possible that this is smart enough to roll back the debhelper.log files under debian/ also
[18:29] <kirkland> hallyn: it's the debian/rules stuff that looks complicated to me
[18:29] <alexbligh> slangasek, no difference.
[18:30] <slangasek> hallyn: my suggestion to kirkland was that if you're no longer shipping any of the dozen or so binaries emulating other architectures, you should also not waste buildd time building them :)
[18:30] <hallyn> slangasek: yup
[18:31] <slangasek> alexbligh: so, deleting the debian/*debhelper.log files will tell dh to start from the beginning
[18:31] <slangasek> alexbligh: no guarantee that this won't also require rebuilding the upstream source - it depends how good the upstream target definitions are
[18:32] <alexbligh> slangasek, I am using the default dh version 7 rules file. It's (essentially) my package.
[18:32] <alexbligh> slangasek, so not dh_clean?
[18:33] <slangasek> alexbligh: you could try it, I'm not sure what that will give you either
[18:33] <kirkland> slangasek: i suppose i should drop sparc from here too
[18:33] <alexbligh> slangasek, it gave me a huge rebuild :-(
[18:34] <slangasek> kirkland: just to make sure there's no understanding - you're going to continue to build the x86 targets *on* all archs, right?
[18:35] <slangasek> (this should greatly simplify the rules for all architectures)
[18:35] <slangasek> the only special case will be x86 now, because of the binfmt handling
[18:35] <slangasek> alexbligh: sorry to hear it.  If you're lucky, at least some of it is cached
[18:36] <kirkland> slangasek: hmm, is that how you'd like to handle this?
[18:37] <slangasek> kirkland: that's what was agreed at the rally :)  qemu-linaro is *not* building x86 emulators for any arch, with the reasoning that qemu-kvm is going to have the best x86 emulation generally - so please continue to build those for everyone
[18:38] <kirkland> slangasek: okay, sorry;  i think hallyn was a party to that discussion and i was not
[18:38] <slangasek> kirkland: I think you begged off :-)
[18:38] <kirkland> hallyn: we should probably work together on this ;-)
[18:38] <alexbligh> slangasek, nope, it essentially did a make clean. I think it removed build.stamp. There must surely be a simple way to rebuild only the package (not the binary) for an autoconf style package.
[18:39] <slangasek> alexbligh: removing debian/*.debhelper.log is as close as I know to come, in the dh model
[18:42] <alexbligh> slangasek, thanks - I'll test that in a bit. In the mean time, the obvious consequence of playing with dhcpd on a remote machine without kvm access has happened. I should really use a VM for this :-/
[18:42] <hallyn> kirkland: wouldn't that just be the default?  (to keep building qemu-system-amd64 and qemu-system-i386 on all architectures) ?
[18:45] <kirkland> slangasek: lp:~kirkland/ubuntu/natty/qemu-kvm/fix-build
[18:46] <kirkland> hallyn: right
[18:46] <kirkland> hallyn: lp:~kirkland/ubuntu/natty/qemu-kvm/fix-build
[18:46] <kirkland> slangasek: hallyn: that's a first draft
[18:48] <hallyn> (fetching)
[18:49] <hallyn> (slowly - i'm getting 7mbs down, but something like 7kps from launchpad.net)
[18:49] <hallyn> actually i guess that's just ppa.l.n - bzr is fetching 10x as fast
[18:51] <slangasek> kirkland: FYI, there were un-uploaded changes committed to the UDD branch for qemu-kvm; those should get merged in also
[18:51] <kirkland> slangasek: i'm pretty sure i did
[18:51] <kirkland> slangasek: i saw your manpage change
[18:51] <kirkland> slangasek: i had a cve/security fix
[18:52] <kirkland> slangasek: plus an arm build fix from hallyn
[18:52] <hallyn> kirkland: looks good so far
[18:52] <slangasek> kirkland: ah - the changelog entry didn't make it into the upload
[18:52] <kirkland> slangasek: ?
[18:52] <kirkland> slangasek: see ubuntu13, ubuntu14, ubuntu15
[18:53] <slangasek> kirkland: the package that was uploaded (0ubuntu14) doesn't show the manpage change
[18:53] <slangasek> I haven't looked at your branch yet, downloading it now (having just figured out that the UDD branch no longer matches the archive)
[18:56] <kirkland> slangasek: right, that one didn't make it into 0ubuntu14
[18:56] <kirkland> slangasek: i'll move your changelog entry up to 0ubuntu15
[18:56] <kirkland> slangasek: as it will be included in this upload
[18:56] <jam> slangasek: there are only 14.5k jobs pending...
[18:56] <kirkland> slangasek: now that I have decent networking and can work from the bzr branch :-)
[18:57] <jam> downtime is shockingly painful
[18:57] <slangasek> kirkland: ok; let me know when that's done, I'll need to do some minor surgery on the branch afterwards to make everything match up again
[18:57] <slangasek> jam: not that - I mean there's a desync between what was uploaded and what was committed :)
[18:57] <jam> plus a wheezy release
[18:57] <jam> slangasek: so the foo-x.y.deb doesn't match the tag x.y?
[18:58] <kirkland> slangasek: okay, i'm pushing to lp:ubuntu/qemu-kvm;  can you take it from here?
[18:58] <slangasek> jam: the 0.13.0+noroms-0ubuntu12 deb matches the tag; then there were further commits to the branch, and further uploads to the archive
[18:59] <slangasek> kirkland: i.e., you want me to upload?
[18:59] <kirkland> slangasek: sure
[18:59] <slangasek> ok
[18:59] <kirkland> slangasek: pushed to lp:ubuntu/qemu-kvm
[19:00] <slangasek> kirkland: NB I'm also in the midst of uploading 5 armel kernel source packages, so it'll be a bit before I can make any headway :)
[19:00] <kirkland> slangasek: okay, well, i can upload to;  you just said you wanted to do some surgery
[19:00] <slangasek> kirkland: the surgery can happen on the branch once the upload is in the archive
[19:00] <slangasek> it's specifically branch surgery not package surgery
[19:01] <kirkland> slangasek: i'm building now locally
[19:01] <kirkland> slacker_nl: ah
[19:01] <kirkland> slangasek: ah
[19:01] <kirkland> slangasek: cool, i'll get this built/tested/uploaded then
[19:01] <kirkland> slangasek: i have a bunch of other stuff to do, but this has my attention right now ;-)
[19:01] <slangasek> k :)
[19:15] <kees> stgraber: will you take care of uploading the natty italc updates? just wanted to make sure that got fully taken care of now that the others are public. thanks again for all the dediffs on that. :)
[19:15] <kirkland> hallyn: is there a bug open for all this qemu-kvm build futzing?
[19:25] <ohsix> hrm, can timidity be made to play well with pulse, it lords over the hw from a single instance
[19:28] <ohsix> false alarm, java6 is ugly
[19:29] <hallyn> kirkland: with linaro you mean?  no
[19:40] <sbeattie> jdstrand: do you have any idea why byacc got demoted to universe?
[19:40] <jdstrand> sbeattie: doesn't ring a bell otoh
[19:41] <jdstrand> sbeattie: are there any bugs on it?
[19:42] <jdstrand> no, doesn't seem so...
[19:42] <sbeattie> jdstrand: not that I can see. It's a build dependency of krb5 at least, and I'd suspect of many others in main.
[19:43] <jdstrand> sbeattie: the version that came in was an autosync from Debian...
[19:44] <jdstrand> sbeattie: I can only say it happened on 2011-01-14
[19:44] <sbeattie> jdstrand: right, which came in during maverick, but then (according to https://launchpad.net/ubuntu/+source/byacc) it got republished in natty/universe
[19:44] <jdstrand> yeah, clearly that was a mistake
[19:45] <jdstrand> sbeattie: I'll fix
[19:45] <jdstrand> sbeattie: it is only krb5 and gob2 that have a build dep on it btw
[19:46] <kirkland> slangasek: i just moved all of the qemu-system-arm* bugs over from qemu-kvm to qemu-linaro
[19:46] <slangasek> kirkland: sounds reasonable, thanks
[19:46] <kirkland> slangasek: some might need to grow a qemu-kvm task too (if the fix necessitates an SRU against qemu-kvm, in Lucid, say)
[19:47] <kirkland> slangasek: i think we'll follow your lead on that
[19:47] <jdstrand> sbeattie: actually, krb5 has a byacc | bison in the build depends
[19:47] <jdstrand> sbeattie: and bison is in main
[19:48] <jdstrand> sbeattie: so I don't think I will make the change
[19:48] <sbeattie> jdstrand: hunh. odd. sbuild/maverick is failing to build krb5 because it can't install byacc.
[19:49] <jdstrand> sbeattie: that might be a ust thing
[19:49] <sbeattie> jdstrand: okay. I'll dig into it.
[19:59] <kirkland> slangasek: hmm, i'm looking for a better way to do this ...
[19:59] <hallyn> cjwatson: i'm chasing down a bug (not yet filed, guess i should) that lucid (and probably maverick) does not boot in qemu with '-vga std', while natty does.  A bleeding edge kernel doesn't help, so at this point I think I have to blame grub.  Was wondering whether you had any ideas.  It bombs just hangs after complaining about 'out of range pointer 0x80220000'
[20:00] <kirkland> slangasek: after my test build, i realized that all of those binaries previously moved to qemu-extras just landed in qemu-kvm now
[20:00] <kirkland> slangasek: i can:
[20:00] <kirkland>         # Remove the binaries provided by qemu-linaro
[20:00] <kirkland>         for i in alpha arm armeb cris m68k microblaze mips mipsel sh4 sh4eb sparc sparc32plus sparc64 system-arm system-cris system-m68k system-microblaze system-mips system-mips64 system-mips64el system-mipsel system-sh4 system-sh4eb system-sparc system-sparc64; do \
[20:00] <kirkland>                 rm -f debian/qemu-kvm/usr/bin/qemu-$$i
[20:00] <kirkland>         done
[20:00] <kirkland> slangasek: easily enough;  but it's kind of a waste to bother building them
[20:00] <kirkland> slangasek: i'm looking for a --configure option to just not build/install them
[20:01] <kirkland> slangasek: hmm, maybe --target-list
[20:01] <slangasek> kirkland, hallyn: huh, looks like maybe I misunderstood the state of play of the qemu-kvm packages on armel.  I assumed qemu-kvm was being built for all archs and would contain the qemu-*-x86* emulators, but it seems this package doesn't exist at all and we're not providing an x86 emulator for arm *anywhere*?  Should qemu-kvm provide this (as the branch w/ better x86 emulation), or should qemu-linaro provide this?
[20:01] <slangasek> kirkland: right, --target-list is the key
[20:02] <slangasek> kirkland: the Debian qemu source package makes use of --target-list, if you need an example
[20:02] <slangasek> kirkland: no it doesn't, I'm lying
[20:02] <slangasek> the qemu-maemo package had that example, only I've superseded that source and deleted it from the ppa, ho-hum :)
[20:03] <slangasek> anyway, yes - use --target-list to only build the objects you care about
[20:03] <kirkland> slangasek: okay, thanks
[20:09] <slangasek> kirkland: I'm just about done with the branch surgery; I recommend holding off a few minutes before making any further changes to bzr, I'll push my cleanup and you can pull it back with bzr pull --overwrite
[20:12] <hallyn> packages for natty are not auto-syncing now right?
[20:12] <slangasek> kirkland: branch pushed; please do a fresh checkout or a bzr pull --overwrite to get back in sync
[20:12] <geser> hallyn: no, we are after DIF, if you need something you need to "requestsync" it
[20:13] <stgraber> kees: natty has been fixed "cleanly", as in, ubiquity re-generate the keys at install time. I uploaded this one on Monday.
[20:15] <soren> slangasek: Do you think you could review this instead of cjwatson: https://code.launchpad.net/~soren/ubuntu/natty/mountall/sigpipe-handler/+merge/49401 ?
[20:15] <slangasek> soren: sigpipe> far better to have cjwatson review it
[20:15] <slangasek> he has deep understanding of sigpipe; I run screaming
[20:16] <soren> slangasek: Alrighty.
[20:22] <hallyn> geser: thx
[20:25] <kees> stgraber: ah, okay.
[20:25] <kees> stgraber: still might be a good idea to fix it in the natty italc-client, in case someone upgrades from maverick live DVDt to natty without first installing -security updates...
[20:32] <kirkland> slangasek: okay, the manifest of qemu-kvm_0.13.0+noroms-0ubuntu15_amd64.deb is at: http://paste.ubuntu.com/566040/
[20:42] <slangasek> kirkland: shouldn't the user targets be in here, in addition to the system targets?
[20:42] <slangasek> kirkland: i.e., qemu-i386, qemu-x86_64
[20:43] <kirkland> slangasek: yeah, i'm just trying to figure out how to state those in             --target-list="x86_64-softmmu i386-softmmu" \
[20:44] <slangasek> kirkland: qemu-linaro does separate passes for system vs. user
[20:44] <slangasek> one is --disable-system, the other is --disable-linux-user
[20:44] <slangasek> not sure to what extent that's required
[20:45] <hallyn> --enable-user?
[20:45] <kirkland> hallyn: yeah;  just added that;  what about --enable-linux-user ?
[20:45] <slangasek> kirkland: ah, it's i386-linux-user and x86_64-linux-user for the targets
[20:45] <hallyn> kirkland: actually yes, i think you want
[20:46] <hallyn> --enable-linux-user,
[20:46] <slangasek> I guess --target-list may override --en/disable-linux-user
[20:46] <hallyn> and the way i read configure, it seems to say that enable-user == ! enable-linux-user
[20:46] <slangasek> or vice-versa
[20:46] <kirkland> slangasek: hmm, okay, i'm testing now
[20:46] <hallyn> weird
[20:46] <kirkland> slangasek: it was VERY nice to get our build back down to ~2 minutes (from 45+ minutes before)
[20:46] <slangasek> :-)
[20:47] <slangasek> kirkland: now, can I switch this package to use dh :)
[20:47] <kirkland> slangasek: dh7 you imply?
[20:47] <slangasek> yah
[20:47] <slangasek> I'm not really going to do it right now though
[20:47] <kirkland> slangasek: would you like to?
[20:48] <slangasek> eventualy
[20:48] <kirkland> slangasek: you're *welcome* to do so
[20:48] <kirkland> slangasek: don't do it yet, as I need to merge my changes in on top of yours
[20:48] <kirkland> slangasek: ask i'm still tweaking the build correctly
[20:48] <slangasek> yep
[20:48] <kirkland> slangasek: but yeah, dh7 would be nice here
[20:49] <slangasek> qemu-linaro is dh7.  It doesn't look all that much nicer ;)
[20:50] <kirkland> slangasek: :-P
[20:50] <killown> when ubuntu will upgrade to gtk3?
[20:54] <kirkland> slangasek: perfect!
[20:54] <kirkland> slangasek: i think we have a winner
[20:55] <kirkland> hallyn: I have not added ppc64 to the target list yet;  let's do that when we get the patches from our friends
[20:56] <hallyn> kirkland: i woudln't be surprised if we hear a bug report overnight from one of the two people who quietly are using it
[20:56] <kirkland> hallyn: that would be kinda cool, actually :-)
[20:56] <kirkland> hallyn: snuff 'em out!
[20:58] <hallyn> yeah but they're not gonna be nice about it :)
[20:58] <kirkland> hallyn: what are the ppc64 targets then?
[20:58] <kirkland> ppc64-softmmu and ppc64-linux-user ?
[21:01] <hallyn> looks like
[21:06] <kirkland> hallyn: ack, got it
[21:10] <kirkland> hallyn: slangasek: okay, built, tested, committed, uploaded
[21:11] <kirkland> hallyn: slangasek: give 'er a test sometime later today or tomorrow
[21:15] <hallyn> i'll update right now, see if it puts a stop to my current ongoing tests :)
[21:19] <LinuxPhreak1> I don't know if this is the correct channel to ask this question in. But I'm working on program to help users transition from Windows to Ubuntu. I wanted to know if it is possible to build deb package inside of Windows
[21:21] <slangasek> LinuxPhreak1: inside a VM, maybe; otherwise you need a chroot and I don't recall Windows having that feature
[21:22] <slangasek> actually, even in a chroot you'd be tainted by cygwin
[21:22] <LinuxPhreak1> what about chroot compiled with cygwin? Has chroot been compiled with cygwin
[21:22] <slangasek> it's not about /compiling/ it, it's about having the underlying system facilities that /implement/ chroot
[21:22] <broder> LinuxPhreak1: what do you mean by "transition from Windows to Ubuntu"? what's wrong with Wubi or Ubuntu Light?
[21:24] <slangasek> so in theory you could have a cygwin environment with a Windows->Linux cross-compiler
[21:24] <slangasek> but I don't see the point
[21:25] <LinuxPhreak1> This program is not geared towards installing Ubuntu with Windows. It is simply going to copy users data such as pictures and videos. Place them into a .deb file. Then the user will be able to have the files in locations on Ubuntu such as Pictures directory.
[21:25] <slangasek> a .deb is a package format for system software; it's not a reasonable format for transferring data between Windows and Ubuntu
[21:27] <LinuxPhreak1> Okay so maybe something like archiving the files and generating a bash script to extract the files into certain locations
[21:27] <broder> LinuxPhreak1: i think that ev is already working on that for ubiquity on natty
[21:28] <LinuxPhreak1> Cool. I'll fetch the source and check it out. This program is not just geared for ubuntu but for several Linux OSes
[21:37] <bryceh> rickspencer3, you about?  I sent you an essay on your intel freeze bug
[21:38] <bryceh> rickspencer3, but basically, I think you might be seeing a freeze we already know about, but there's not enough info to say one way or the other.  if you want to gather the info I sent directions, but if you want to just assume it's covered by one of the other bugs and wait 'til they get resolved, that's cool too.
[21:39] <rickspencer3> bryceh, I added a note to the bug
[21:39] <rickspencer3> let me know if you need more info, happy to help, but closing it is fine too
[21:39] <bryceh> ah great
[21:40] <cjwatson> hallyn: I don't have an answer for you off the top of my head, but basically that message is equivalent to malloc arena corruption, or freeing a non-malloced pointer, or similar, and can be similarly hard to debug (no valgrind either).  if you can give me a rough recipe for reproducing it in a bug report, I may be able to work something out; even better if you can produce a cut-down version with grub-mkrescue or something ...
[21:40] <cjwatson> ... like that
[21:40] <cjwatson> hallyn: I'd probably start by executing menu commands one by one to see where it breaks
[21:41] <hallyn> cjwatson: i figured i would try compiling natty's grub for lucid, but that failed
[21:41] <cjwatson> no xorriso would be awkward
[21:42] <slangasek> kirkland: any further thoughts about where we should be putting i386 emulation for non-kvm-supporting archs?
[21:42] <cjwatson> I don't remember a specific fix that might correspond to that, but it could have been in the course of general code cleanup or anything
[21:43] <kirkland> slangasek: on a call, will get back with you after
[21:43] <slangasek> kirkland: okie
[22:06] <hallyn> cjwatson: replacing grub2 with grub it boots fine.  at least now i know waht to file the bug against :)
[22:11] <soren> cjwatson: Do you think there's any chance you'll get to reviewing that patch of mine today? If not, that's perfectly fine, then I just need to flick a switch somewhere.
[22:13] <Laney> oijoijoijoijoijoijoijhhoihoih
[22:17] <kirkland> slangasek: back now
[22:18] <kirkland> slangasek: okay, i propose this: qemu-kvm builds the binaries for and on those that support KVM acceleration
[22:18] <kirkland> slangasek: qemu-linaro builds everything else
[22:18] <kirkland> slangasek: ie, qemu-kvm really is for "KVM", and qemu-linaro is more for "QEMU" (non-kvm)
[22:18] <kirkland> slangasek: does that sound reasonable?
[22:24] <kirkland> @pilot out
[22:42] <slangasek> kirkland: is that an exclusive or inclusive and?
[22:42] <slangasek> kirkland: i.e., does build for those that support KVM mean building qemu-i386 on armel, or not?
[22:43] <kirkland> slangasek: i'm ambivalent on that;  though I think it a precious waste of armel cpu time to waste running qemu-i386 emulation :-)
[22:44] <kirkland> slangasek: ie, is there sensible reason to do that, that I'm missing?
[22:45] <slangasek> kirkland: well, no one seems to have minded that it wasn't building before now <grin>, but I have some evil designs for it that involve multiarch
[22:45] <kirkland> slangasek: neat :-)
[22:46]  * kirkland has long awaited this magical multiarch
[22:46] <slangasek> and it's at least as useful as, y'know, qemu-sparc on armel
[22:46] <slangasek> which we /are/ building
[22:47] <slangasek> kirkland: so at the root, my question is - will using the kvm branch of qemu give any advantage in terms of x86 system emulation on non-kvm archs?
[22:48] <slangasek> if not, I'm happy to build from qemu-linaro (it's already building, we're just throwing it away at the end)
[22:48] <kirkland> slangasek: nope, none that i know of
[22:48] <slangasek> if so, I'd like us to get those benefits and have it built from qemu-kvm
[22:48] <kirkland> hopefully hallyn can keep me honest there ^
[22:48] <kirkland> slangasek: currently, qemu-kvm only positively effects i386-on-i386, i386-on-amd64, and amd64-on-amd64
[22:49] <hallyn> my understanding is the same
[22:50] <slangasek> ok, so even amd64-on-i386 isn't helped, the differences are entirely in the code that leverages the proc for native execution?
[22:54] <soren> Yeah. amd64-on-i386 could actually work (I've learned this recently), but kvm doesn't do it at the moment.
[22:55] <slangasek> so thinking about it, the other issue is that qemu-kvm already has all the x86 bioses sorted already
[22:55] <slangasek> if I build qemu-system-i386 from qemu-linaro and it wants a different version of seabios or vgabios, I'm in trouble
[22:57] <alexbligh1> What does the file [packagename].templates do in the debian directory? It seems to be translation related. If it's not there, bad things happen. If it's there, I get (on dpkg -i) "Template parse error near `# These templates have been reviewed by the debian-l10n-english', in stanza #1 of /var/lib/dpkg/info/extility-dhcpd.templates"
[22:58] <alexbligh1> I have copied the file from the Natty dhcpd package so I don't see why it causes a parse error (particularly on a comment)
[22:58] <slangasek> alexbligh1: .templates are the source of the questions asked by a package via the debconf interface at install time
[22:58] <hallyn> slangasek: yes, tracking the bioses is a bit of extra work...
[22:59] <slangasek> hallyn: not just tracking them but making sure we don't have mutually exclusive requirements for bios versions due to upstream version skew
[22:59] <kirkland> slangasek: hmm, yeah, the bios problem is a bitch
[22:59] <alexbligh1> slangasek, ok, any idea why it chokes on a line begining with a #?
[23:00] <slangasek> kirkland: I think the easiest way to avoid the bios problem is to use qemu-kvm to build all x86 emulation, even on non-kvm archs - do you think that's reasonable under the circumstances?
[23:01] <slangasek> alexbligh1: I'm guessing there's some difference in the post-processing of the templates when copying into the binary package
[23:01] <slangasek> alexbligh1: I'm having a look now at the dhcp3 source package
[23:03] <alexbligh1> slangasek, it's actually the templates file from https://launchpad.net/ubuntu/natty/amd64/isc-dhcp-server/4.1.1-P1-15ubuntu2 I used
[23:03] <persia> slangasek, So, some of the cross-arch build stuff we have floating around expects that a single package will handle all cross-arch needs.  Is the expectation that we'd have ${src}-extras-static and ${src}-x86-static and need to generally pull both to ensure full cross-arch support?
[23:03] <slangasek> persia: -static is a special case; qemu-user-static does it all
[23:04] <slangasek> alexbligh1: are you using 'dh_installdebconf' to install the templates into the package?  Are you building on natty?
[23:05] <alexbligh1> I'm building on Lucid. I'm just using the stnadard dh7 rules file with a couple of overrides.
[23:05] <persia> slangasek, Ah, so your suggestion is only that qemu-system-foo be generated separately.  by qemu-kvm for x86, and by qemu-linaro for ARM+powerpc?
[23:05] <slangasek> alexbligh1: it's possible that the behavior of either debconf or dh_installdebconf has changed between lucid and natty.  I haven't run into this before though
[23:05] <alexbligh1> slangasek, Does that not do dh_installdebconf?
[23:06] <slangasek> persia: yep - they're already being generated separately, we just have a gap wrt i386-on-other
[23:06] <slangasek> er, x86-on-other
[23:06] <kirkland> slangasek: yes, that seems fine
[23:06] <slangasek> kirkland: ok, I'll wire it up and push to bzr, thanks
[23:07] <persia> Ah, OK.  And if it's just qemu-system, and not qemu-user, it won't affect any of the scripts I care about.  Sorry for the noise.
[23:07] <alexbligh1> slangasek, the annoying thing is I don't actually need debconf but the .init file does weird things I don't understand that seem to rely on it
[23:08] <slangasek> persia: oh, sorry - it would also affect qemu-user but not qemu-user-static; does that make a difference?  (non-static qemu-user is never used for binfmt-misc...)
[23:09] <persia> Not to me.  My uses of qemu are either related to binfmt-misc, or (when I have time) about powerpc-on-powerpc with qemu-system, which I need to rearrange some services locally to test with qemu-linaro (in my queue)
[23:09] <slangasek> persia: ok
[23:10] <kirkland> slangasek: ack, thanks
[23:15] <slangasek> alexbligh1: unwinding debconf integration from a package is somewhat non-trivial, I'm afraid I don't have time to help you with this at the moment; you could see if anyone around on #ubuntu-motu can lend a hand
[23:16] <persia> This channel is also fine for such things: there's no difference in the on-topicness of questions in one place or the other.
[23:16] <alexbligh1> slangasek, no problem. I will try and learn about debconf.
[23:17] <alexbligh1> After all, it would be better if it worked, and dhcp with a DBI back end might just be useful to someone else
[23:17] <slangasek> persia: not meaning to suggest it's off-topic, merely that #ubuntu-motu is usually a good place to find people able to pitch in; is that no longer the case (de jure or de facto)?
[23:18] <persia> slangasek, de jure from about a year back: with the breakdown of developers into lots of different types, we seek to encourage teaching and mentoring in all development channels.
[23:18] <slangasek> okie
[23:18] <persia> the MOTU are still happy to help with stuff, as before, but other people are also supposed to be happy to help :)
[23:22] <persia> alexbligh, To be clear: feel free to ask in -motu if you like, but odds are that most folk who understand debconf templates well are also here.
[23:34] <alexbligh1> persia, thanks. I am sure I have missed something dumb. I think I shoudl look at it when i am less tired...
[23:41] <alexbligh1> well, the issue is db_get extility-dhcpd/interfaces is returning "RET=10 extility-dhcpd/interfaces doesn't exist". Presumably the key should be defaulted somewhere, but I don't know where.
[23:43] <soren> Keybuk: Oh, maybe you could review my mountall patch?
[23:43] <soren> Keybuk: https://code.launchpad.net/~soren/ubuntu/natty/mountall/sigpipe-handler/+merge/49401
[23:44] <slangasek> alexbligh1: "doesn't exist" means the question isn't registered with debconf; for that you need a working .templates
[23:45] <Keybuk> soren: not without context, no
[23:46] <Keybuk> soren: why can't you add MSG_NOSIGNAL to the culprit send/write call?
[23:46] <soren> Keybuk: Because I'm not sure which of the many send/write calls in Plymouth's client code is at fault.
[23:47] <Keybuk> well, that's where to start then ;-)
[23:47] <Keybuk> given it's EASY to tell which syscall causes a signal
[23:47] <soren> Keybuk: Well, I can't really.
[23:47] <soren> Keybuk: it could be any one of them.
[23:47] <Keybuk> and it's pretty easy to add the flag to all of the calls
[23:47] <alexbligh1> slangasek, thanks
[23:47] <soren> Keybuk: Plymouth has gone the way of the segfault. The next thing that tries to talk to it blows up.
[23:47] <soren> Keybuk: One time around it could be one write() call, next time around it could be another.
[23:48] <Keybuk> right, so add the flag to them ;-)
[23:48] <Keybuk> it's the right fix
[23:48] <soren> Keybuk: I'm not sure which effect that would have, really.
[23:48] <Keybuk> we did it to D-Bus for example
[23:48] <Keybuk> you get SIGPIPE when you issue a write()/send() etc. on a disconnected socket
[23:48] <soren> Right.
[23:48] <Keybuk> adding the MSG_NOSIGNAL flag means you get an error back instead via usual errno
[23:49] <walters> i'd be nice if the kernel had a system call to the kernel to opt out of all the broken stuff from unix
[23:49] <walters> like, all signals
[23:50] <Keybuk> walters: it'd be *really* nice if that flag opted out of filesystem authors citing broken stuff from posix as justification for their crazy filesystem behaviour <g>
[23:50] <walters> heh
[23:50] <Keybuk> soren: also, really close plymouth?!
[23:50] <walters> welcome your new sprinkle-userspace-with-fdatasync() overlords
[23:50] <Keybuk> soren: why not just SIG_IGN?
[23:50] <Keybuk> walters: oh, it got much worse
[23:50] <Keybuk> did you not see the dpkg thread?
[23:50] <soren> Keybuk: Because if I close it, we automatically attempt to reconnect.
[23:51] <maco> link plz?
[23:51] <walters> Keybuk: nope
[23:51] <Keybuk> soren: won't the -EPIPE from write() cause that anyway
[23:51] <walters> i should really be working but, i'll read the link =)
[23:51] <soren> Keybuk: Good question.
[23:51] <Keybuk> soren: if you ignore the signal, it behaves
[23:52] <soren> Keybuk: Would that be an acceptable change to mountall, then?
[23:52] <soren> Keybuk: Or where would you stick it?
[23:53] <Keybuk> soren: since I get to play upstream, I think the acceptable change is to fix libplymouth
[23:53] <Keybuk> so then everyone benefits
[23:53] <Keybuk> and you don't hit this bug next week somewhere else
[23:54] <Keybuk> maco, walters: I can't find the link
[23:54] <Keybuk> but it got insane
[23:54] <Keybuk> oh
[23:54] <slangasek> Keybuk: you're proposing to change the caller's signal handling from within libplymouth?
[23:54] <Keybuk> now I have
[23:55] <Keybuk> slangasek: no, I'm proposing that libplymouth guards its write() calls to not result in a signal to the caller
[23:55] <soren> Keybuk: Silly question, but what's the write() equivalent of MSG_NOSIGNAL?
[23:55] <Keybuk> maco, walters: http://lists.debian.org/debian-dpkg/2010/11/msg00075.html
[23:55] <slangasek> did it get insane before or after tytso and Olaf van der Spek started emulating one of joeyh's thread batterns?
[23:55] <Keybuk> that has a quote of Ted's suggestion
[23:56] <slangasek> Keybuk: guards> ok
[23:56] <maco> oh so i was on the right thread. i found ted's suggestion here https://bugzilla.sourcefire.com/show_bug.cgi?id=83924
[23:56] <maco> erm no
[23:56] <maco> http://us.generation-nt.com/answer/bug-605009-serious-performance-regression-ext4-help-201204702.html?page=8
[23:56] <maco> THERE
[23:56] <maco> (two paste buffers...)
[23:58] <maco> :( ted doesnt wrap at 80 char
[23:59] <Keybuk> nor do I...
[23:59] <walters> Keybuk: the only bug i see here is dpkg isn't threaded; it's like all the unix calls, to make them sane you have to wrap them in a thread worker library