[01:06] <YokoZar> Can anyone shed a bit of light on https://bugs.launchpad.net/ubuntu/+source/wine/+bug/460596  ?
[01:08] <YokoZar> wine.postinst has this line that I suspect is erroring: service procps start
[02:13]  * ccheney thinks something is broken with his mac address on his new pc, its 00:00:00:00:00:30 
[02:14] <hyperair> lol
[02:14]  * ccheney probably should contact tech support for his board to see what is going on
[05:14] <superm1> pitti, can you determine why the retracer hasn't ran on https://bugs.edge.launchpad.net/mythbuntu/+bug/452508/+index ?
[05:14] <superm1> pitti, it's about 10 days old
[05:14] <superm1> it's a PPA build, but we (attempt to) build them with debug symbols
[06:05] <YokoZar> kees: ping
[06:08] <YokoZar> kees: Am I committing a horrible sin if I invoke `sysctl -p /etc/sysctl.d/30-wine.conf` directly in a maintainer script rather than reloading the entire configuration?  The problem is that using `start procps` can fail at package install time.  https://bugs.launchpad.net/bugs/447197
[06:12] <al-maisan> Good morning
[06:18] <virtuald> YokoZar: That would wipe my later sysctl rule. Look at what the upstart or init script tries to do
[06:19] <YokoZar> virtuald: Yeah that was my thought.  I can't figure out why procps doesn't support a restart command though (for reloading all the config files)
[06:21] <virtuald> I haven't looked at it much should probably get out of bed first :)
[06:26] <YokoZar> virtuald: the entirety of procps is in /etc/init.d/procps.conf and is basically:     cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -p -
[06:28] <YokoZar> but it contains no restart instructions (not too familiar with upstart syntax at the moment)
[06:29] <YokoZar> I suppose I could just put `cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -p -` into the maintainer script but that's an ugly thing to do.
[06:39] <pitti> Good morning
[06:43] <YokoZar> Good morning pitti :)
[06:43] <pitti> apw: oh, kerneloops catches those?
[06:43] <maco> hi folks
[06:58] <pitti> hey YokoZar, how are you?
[06:59] <YokoZar> pitti: surprisingly busy with last minute fixes (aside from the final polish to app-install-data I'm hammering out, there's the procps stuff I ran into above ;) )
[07:10] <dholbach> good morning
[07:11] <pitti> superm1: 452508> it's not an ubuntu bug, but an upstream one; retracers can only deal with ubuntu packages
[08:44] <tkamppeter> pitti, hi
[08:44] <pitti> hey tkamppeter
[08:45] <tkamppeter> I have done a one-byte fix in the cpdftops filter as there is a bug preventing setting printers to single-sided when duplex is set by default. This affects all PostScript printers. I have committed it to the CUPS BZR.
[08:45] <tkamppeter> Should we take it into Karmic?
[08:46] <pitti> tkamppeter: should be done as SRU now, if it's important enough
[08:46] <tkamppeter> OK, so I leave it alone until SRU can be posted.
[09:04] <ion> keybuk: O hai. I just sent you an email.
[09:04] <Keybuk> ion: what was your e-mail?
[09:05] <apw> hey pitti is apport going to be enabled following release this time?
[09:05] <ion> keybuk: The content of the message? Or do you mean my address?
[09:05] <pitti> apw: no, already disabled (right after RC)
[09:06] <Keybuk> ion: the content of the message
[09:06] <apw> pitti, thanks ... so we don't really need to worry about this kerneloops issue then as such
[09:06] <Keybuk> oh, yes
[09:06] <Keybuk> I saw that this morning
[09:07] <pitti> apw: well, disabling apport won't disable kerneloops, so I guess it'll still write kerneloops reports; they just won't be displayed through apport any more
[09:07] <ion> keybuk: An RFC-ish patch i don’t expect to make it into mountall as-is at least. :-P
[09:08] <slangasek> Keybuk: hi, mountall / usplash still not uploaded?
[09:08] <Keybuk> ion: I just figured that the overflow would not be "that bad"
[09:08] <ion> True
[09:08] <Keybuk> slangasek: in PPA and being tested
[09:08] <apw> pitti, but it is the processing in apport which pushes them to kerneloops from what i saw so they won't get reported either ... not that it shouldn't be fixed just trying to work out if we have any impact doing so
[09:09] <pitti> apw: right, it doesn't seem release critical to me
[09:09] <apw> pitti, ack and thanks
[09:09] <slangasek> Keybuk: please get it in the queue so the release team review can happen in parallel, that's critical path for starting ISO testing today
[09:09] <Keybuk> slangasek: as soon as I've done a reboot test myself
[09:09] <slangasek> ok, thanks
[09:10] <Keybuk> which I would be doing, if you weren't bugging me about it ;)
[09:56] <asac> mdke: there?
[09:56] <mdke> asac: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[09:56] <asac> mdke: bot?
[09:57] <asac> mdke: check out 460225 ... the index.html is not in ubuntu-docs anymore?
[09:58] <slangasek> YokoZar: I don't see the point in re-adding fltk1.1 to ia32-libs; I proposed that as a solution because the use case for it is minimal, not just because fltk1.1 was broken
[09:59] <YokoZar> slangasek: You're right that the use case for adding it was minimal, but there may be other apps that use it since it was added and removing it would be a regression
 not a regression I think we should care about, it's ia32-libs
[10:00] <asac> hmm ... still ia32libs wrestline
[10:01]  * TheMuso is just glad he doesn't have to touch it that often.
[10:01] <asac> whatever helps to get ia32libs updated is much better than a fltk regression
[10:01] <TheMuso> s/just//
[10:02] <asac> YokoZar: ^^
[10:02] <slangasek> asac: hrm?  ia32-libs was /already/ updated; are you saying you care about 32-bit fltk?
[10:02] <asac> no
[10:02] <asac> slangasek: i just thought it wasnt updated and this was still discussion about something blocking it ;)
[10:02] <YokoZar> slangasek: a few packages other than fltk were freshened in the latest update, btw
[10:03] <YokoZar> I don't see the harm it does by including it, so why not
[10:03] <slangasek> the harm it does is that ia32-libs could as well be named ia32-everything-and-the-kitchen-sink-avoid-like-the-plauge
[10:03] <slangasek> plague
[10:03] <slangasek> including libs that no one needs makes it harder to maintain
[10:04] <asac> i am more scared bout bug 460225 that says that we have no /usr/share/ubuntu-artwork/home/index.html on CD :/
[10:04] <asac> asked on -testing to get someone verify it
[10:05] <YokoZar> slangasek: I thought the goal was to get rid of all of them next release using the magic of multiarch or something
[10:06] <TheMuso> slangasek: Been playing with livecd-rootfs locally here, and have found an uninstallability issue with libgd2 and libgd2-xpm. Thought I'd let you know so time wasn't lost building, and finding the failure in teh livefs for ubuntu, and uploading a fix. Not sure how to fix atm, haven't dug into it.
[10:06] <slangasek> YokoZar: yes; but you're still increasing the maintenance burden for karmic-updates in the event of security issues, and it's not 100% certain we'll be rid of ia32-libs for lucid either (though I'm going to try really hard to see it happen)
[10:07]  * TheMuso updates his mirror to see if the error was transient.
[10:07] <slangasek> TheMuso: what uninstallability issue?  libgd2-xpm and libgd2-noxpm are not coinstallable; we've carefully forced everything to use libgd2-xpm by preference, so we don't have to worry about this
[10:07] <YokoZar> Yes, a security issue in fltk would force an ia32-libs update.
[10:08] <YokoZar> but it's already forcing that update onto jaunty and intrepid and hardy because they have fltk too
[10:08] <Keybuk> pitti: the apport assert catching stuff appears to be working nicely for upstart - I'm getting bugs \o/
[10:08] <YokoZar> (in ia32-libs that is)
[10:08] <TheMuso> slangasek: hrm ok, I'll see if I can reproduce, it could be transient.
[10:08] <Keybuk> (from the code that spawns services sadly, not init itself yet)
[10:09] <slangasek> YokoZar: no, I mean that adding random crap to that package makes it more time consuming to update it for *any* security update
[10:09] <slangasek> because it's a grotesque CD-size source package
[10:10] <YokoZar> slangasek: Yeah, as someone who's had to borrow his girlfriend's internet to update this package about 10 times now (since it dies on my home internet due to hugeness), I'm quite aware of this.
[10:10] <YokoZar> It's at that point where updating it is basically "leave it on overnight" though
[10:10] <TheMuso> YokoZar: Yes, I've had to do that, or during the day when nobody is on the net. I have come back to it a couple of times and its died mid upload.
[10:11] <YokoZar> TheMuso: the worst is how it'll stall with 1k left (I've seen this behavior and it seems to be ISP-dependent)
[10:11] <TheMuso> YokoZar: Ouch.
[10:20] <slangasek> Keybuk: did you build-test this mountall upload?  Makefile.in has vanished
[10:20] <Keybuk> slangasek: I test built the code
[10:20] <Keybuk> who knows what bzr-builddeb did
[10:20] <Keybuk> can you reject them both (usplash probably had the same issue)
[10:20] <slangasek> bzr-builddeb exported the package as it existed in the bzr repo
[10:20] <Keybuk> oh, how silly
[10:20] <slangasek> yes, will reject
[10:21] <Keybuk> was the usplash one ok?
[10:22] <Keybuk> can I upload again now?
[10:23] <slangasek> Keybuk: yes, you can reupload
[10:23] <slangasek> haven't looked at usplash yet, checking now
[10:24] <mvo> lool: bug #456523 looks like gtk-doc-tools need a depenency on emacsen-common ? (see comment 5 in the bug)
[10:25] <Keybuk> usplash looks ok, looks like it just dropped the .bzr
[10:25] <Keybuk> the mountall bzr tree is a bit "odd"
[10:26] <slangasek> usplash looks ok> confirmed
[10:26] <Keybuk> I should repackage mountall like upstart
[10:27] <Keybuk> where the "upstream" repo has the code
[10:27] <Keybuk> but the "ubuntu" repo is buildable (with libnih merged in, etc.)
[10:27] <Keybuk> or just make the ubuntu repo buildable
[10:27] <lifeless> have a chat with james_w, see what went wrong
[10:27] <slangasek> nothing went wrong :)
[10:28] <slangasek> no reason to expect bzr bd to run ./autogen.sh for you
[10:28] <lifeless> heh
[10:28] <Keybuk> slangasek: yeah, it's the whole "you don't put Makefile.in in bzr" thing
[10:28] <pitti> Keybuk: I suppose I should reject the older mountall upload?
[10:31] <slangasek> Keybuk: absolutely; for most packages this works fine because it's expected that something other than bzr bd has done this as part of the tarball generation :)
[10:31] <Keybuk> lifeless: have you fixed the bzr bug yet where it screws up timestamps?
[10:31] <Keybuk> slangasek: yeah, though it's an interesting case that --native *might* need autoreconf running
[10:32] <Keybuk> it's almost a would-be-nice that if there's configure.ac but not configure, run autoreconf
[10:32] <slangasek> could put it in debian/rules
[10:32] <slangasek> not make bd guess
[10:32] <Keybuk> sure, but then you'd need a build-depend
[10:32] <Keybuk> configure should be in the tar.gz
[10:32] <slangasek> could do if [ ! -e ./configure ] in debian/rules :)
[10:33] <Keybuk> slangasek: doesn't remove the build-depend need
[10:33] <Keybuk> bzr bugs notwithstanding, it should be ok to put autofoo stuff in the bzr repo now
[10:33] <Keybuk> it works for upstart
[10:33] <Keybuk> and libnih needs to be in mountall too ;)
[10:33] <slangasek> sure it does, if the code path is never hit during a normal package build
[10:33] <Keybuk> (bzr still has the bug where it doesn't apply the same timestamp to all files touched during a checkout/update)
[10:34] <lifeless> I build-dep on autoconf as a matter of course
[10:35] <lifeless> Keybuk: we should make that a higher priorty bug with the new focus
[10:35] <slangasek> I make packages build-dep on autoconf when they use scons
[10:35] <lifeless> slangasek: evil :)
[10:35] <TheMuso> heh
[10:40] <slangasek> Keybuk: month's worth of libnih updates - bah
[10:40] <Keybuk> month's worth?
[10:40] <slangasek> innit?
[10:40] <slangasek> I was going by timestamps in the debdiff
[10:40] <Keybuk> are there actual code changes there?
[10:40] <slangasek> lots
[10:41] <Keybuk> really?
[10:41] <Keybuk> bzr diff said it was the same
[10:42] <Keybuk> let me check myself
[10:42] <slangasek>  mdebdiff -s karmic *.dsc | filterdiff -i '**/nih**/**'|wc -l
[10:42] <slangasek> 2605
[10:43] <Keybuk> huh, I honestly don't know why those changes *aren't* in 0.2.5
[10:43] <Keybuk> but most of them aren't even in bits that mountall touches
[10:44] <slangasek> how safe are the ones that are? :)
[10:44] <Keybuk> oh, utterly safe
[10:44] <Keybuk> they're all bug fixes
[10:44] <Keybuk> valgrind errors
[10:44] <Keybuk> this is the same code as upstart is using
[10:44]  * slangasek nods
[10:44] <slangasek> (you're sure of that part, right? :)
[10:44] <Keybuk> very sure
[10:45] <Keybuk> because the patch includes the glibc __abort_msg thing
[10:45] <Keybuk> that means apport catches nih_assert()
[10:45] <Keybuk> and I've definitely been getting those from Upstart
[10:45]  * slangasek nods
[10:46] <Keybuk> and the patch includes the cross-compiling support
[10:46] <Keybuk> which cjwatson *really* wants ;)
[10:48] <Keybuk> I need to fix the mountall repo clearly
[10:48] <Keybuk> let me do that now
[10:50]  * Keybuk tries to remember what bzr dark magic he did to make the upstart tree
[10:53] <mvo> Keybuk: please share that wisdom about the dark magic with me
[10:54] <Keybuk> mvo: I found a way to join the history of the two repositories together
[10:54] <Keybuk> so that "bzr merge lp:upstart" *and* "bzr merge lp:libnih" worked
[10:54] <Keybuk> with the resulting repo containing files from both
[10:55] <lifeless> Keybuk: bzr merge-into
[10:55] <lifeless> its aplugin
[10:55] <Keybuk> lifeless: which didn't work
[10:55] <Keybuk> neither did join
[10:55] <lifeless> merge-into should have
[10:55] <lifeless> your other option is merge -r 0..-1
[10:55] <mvo> nice, is there a way to track a merge-into branch (maybe even automatically?)
[10:56] <Keybuk> lifeless: right, I think I did the latter, then fixed up some renames and removed some files
[10:56] <lifeless> merge-into just automates the management of the root dir rather than getting conflicts on NEWS etc
[10:56] <Keybuk> lifeless: that's the bit it screwed up on! :)
[10:57] <lifeless> :(
[10:57] <lifeless> did you file a bug?
[10:57] <Keybuk> probably, yes
[10:57] <Keybuk> I usually do
[10:58] <Keybuk> or I might have msg'd the guy
[11:01] <Keybuk> slangasek: ok, the mountall repo is now directly buildable ;-)
[11:05]  * asac hugs kees (459199)
[11:07] <slangasek> asac: Debian policy is not broken and will not be changed; Debian policy is older than your 10 year UID. :)
[11:08] <asac> slangasek: really?
[11:08] <asac> kees said it was an ancient debian UID
[11:08] <Riddell> asac, mdke: bug 460225 has nothing to do with kubuntu, we don't use firefox in kubuntu, please don't assign bugs to kubuntu for software that has nothing to do with us
[11:08] <slangasek> asac: he's mistaken
[11:08] <asac> slangasek: i thought my uid was also created using debian
[11:08] <asac> but i could be wrong
[11:09] <slangasek> well
[11:09] <asac> slangasek: the policy claim was more or less a joke ;)
[11:09] <asac> i think it should be done by checking whether an account is a valid log-in account
[11:09] <slangasek> perhaps I should double-check the history; /I/ don't remember UID 501 ever being considered ok on Debian, I believe that was /Red Hat's/ UID policy
[11:10] <cjwatson> slangasek: correct
[11:10] <slangasek> asac: I agree with you that gdm/ck-history shouldn't hard-code the uid policy, though :)
[11:11] <asac> too long ago for me to tell for sure ...
[11:11] <cjwatson> it was considered OK in the sense that we were happy to accept such UIDs, though
[11:11] <cjwatson> just not create them
[11:11]  * slangasek nods
[11:11] <cjwatson> this is at least in part because Ian had UID 100 hanging around from a previous installation
[11:11]  * slangasek grins
[11:11] <asac> haha
[11:11] <asac> i think 100 is solaris
[11:11] <slangasek> yeah, my colo server is happily running with a dozen users with UIDs numbered from 500
[11:11] <asac> at least that what i got when googling for random UID bounds
[11:11] <slangasek> and it's not Red Hat ;)
[11:11] <cjwatson> not in this case, but sure
[11:14] <slangasek> TheMuso: rejecting this brasero upload, SRU please
[11:19] <TheMuso> slangasek: Ok will pass that onto Robert.
[11:19] <lool> mvo: Looking
[11:23] <lool> mvo: This is odd
[11:23] <lool> mvo: gtk-doc-tools only uses the dh_installemacsen snippet; dh_installemacsen doesn't add a dependency and I dont have /usr/lib/emacsen-common/emacs-package-install so it seems perfectly fine not to install emacsen-common
[11:24] <lool> mvo: It seems to me the dh_installemacsen snippet should also check whether emacsen-common is configured rather than for mere availability
[11:25] <lool> mvo: There are a bunch of other packages with that snippet even in the default install
[11:26] <lool> mvo: Hmm no, not that many sorry, too large grep
[11:27] <lool> mvo: However I have packages "global" and "lbdb" on my system which have the same snippet and no dep
[11:28] <lool> mvo: it's probably too late to fix this at this point though; perhaps we could fix emacsen-common to just not do anything if packages try to use the hook before configuration, but not raise an error?
[11:34] <slangasek> zul: bug #451314> in what sense is this making zlib "shared"? the package already depends on zlib1g
[11:40] <lool> mvo: Happy if you can test emacsen-common_1.4.19ubuntu1~dooz1 in my PPA
[11:41] <zul> slangasek: in the sense that zlib.so is not statically built into php itself
[11:43] <slangasek> zul: oh. why does that cause this bug?
[11:44] <zul> slangasek: i think its something they changed in newer versions of php, we had multiple bug reports that the zlib functions werent working, i thought it was something that broke in 5.2.10 that they fixed in 5.2.11 but it was not, and poking around other distros load it as shared now
[11:45] <zul> slangasek: also things like pear looked like it wasnt able to unpack any packages it was downloading
[11:45] <slangasek> zul: well, this is going to regress any code that expects the functions to be there without having to configure it for loading, no?  or is the installed php.ini set up to already load it?
[11:45] <zul> slangasek: it shouldnt regress anything
[11:45] <slangasek> (whine, all the bad memories)
[11:46] <slangasek> zul: explain, please
[11:47] <zul> slangasek: when it was not shared we were having problems like 432291 and  439407]
[11:47] <zul> bug  439407]
[11:47] <zul> bug  439407
[11:48] <zul> bug 432291
[11:50] <zul> slangasek: if you want you could reject the upload and I could write a better changelog entry for it
[11:51] <slangasek> zul: it's faster to come to a conclusion here
[11:52] <slangasek> anyway, the above doesn't prove it won't regress in exactly the way I've described
[11:57] <slangasek> maxb: I don't buy this texinfo fix - why is mb_len() overflowing an int on amd64, but not on i386, when using the same manpage?  Why should the multibyte sequence *ever* exceed 2^32 bytes in length?
[11:57] <slangasek> zul: I see nothing in the php5 packaging that would ensure zlib module autoloading
[11:58] <slangasek> zul: so unless I've overlooked something, there is a regression here: currently gzfile() works without having to load the module, after the change something has to load it
[11:58] <maxb> slangasek: Hmm, I just bisected upstream and observed they had a fix which does actually work :-/
[11:59] <maxb> Also, the triggering 'multibyte sequence' is in fact a tab character
[11:59] <slangasek> zul: (gzopen() is still broken, yes - but that doesn't mean we should regress other code that doesn't need gzopen())
[11:59] <slangasek> maxb: yep - but the patch makes no sense; if it fixes anything, it appears to do so as a side effect?
[11:59] <slangasek> (unless something is passing &cur_len later... let's see)
[12:00] <slangasek> oh - indeed something is
[12:00] <slangasek> ok, that makes sense now
[12:00] <maxb> I guess so. I'll try to look into it if you don't. I admit my thought processes didn't advance much beyond, "oh good, upstream have fixed it"
[12:01] <Kano> cjwatson: https://bugs.launchpad.net/lupin/+bug/460740
[12:01] <zul> slangasek: php does the loading for you not the packaging
[12:02] <slangasek> zul: when and how?  How does it know you want the zlib.so loaded?
[12:03] <mvo> lool: the diff looks good, I don't ahve a way to reproduce the issue myself, but I think the fix is good
[12:04] <zul> slangasek: its done through the php.ini file or loaded dynamically
[12:04] <zul> in zlib's case i believe its done dynamically
[12:06] <soren> Really? When did it start doing this?
[12:06] <soren> (loading extensions dynamically, that is)
[12:06] <zul> soren: when its built as shared
[12:07] <slangasek> maxb: ok - the fix looks good, but the change isn't critical, so it'll go into release only if we have to respin for something else
[12:07] <soren> zul: No, I mean when did php start doing stuff like this? Back when I cared about php at all, it had no mechanism for automatically loading extensions. I always had to add them to the php.ini.
[12:07] <slangasek> maxb: if not, looks good for an immediate SRU
[12:08] <maxb> fair enough
[12:08] <slangasek> zul: I'm going to require empirical proof that this is the case, not "I believe"; especially since /I/ believe php upstream isn't that clever
[12:08] <soren> zul: You don't need to look up when it started doing it. I'm just surprised, but if you're sure...
[12:08] <zul> soren: its done it for a while now
[12:08] <zul> slangasek: ok then
[12:09] <slangasek> zul: so if Till's var_dump() test works with the package you uploaded, I'm convinced
[12:09] <slangasek> otherwise, I think what's really happening is that the code you're testing has provisions to load the module, thus hiding the regression
[12:09] <zul> slangasek: sure Ill add it to the bug report
[12:10] <cjwatson> Kano: committed, thanks
[12:11] <Kano> good
[12:11] <Kano> just tested a new grub yesterday and it did not want to boot from ext4
[12:12] <Kano> grub2 is really cool as it supports loopback
[12:13] <Kano> now $var works, not only ${var}
[12:14] <slangasek> zul: ok, thanks
[12:14] <Kano> http://paste.debian.net/49971/
[12:14] <Kano> example
[12:24] <dpm> hi slangasek, pitti. I would like to point you to bug 410234 and bug 457632 to be considered for a post RC update - if it's not too late and if you consider it appropriate
[12:37] <Keybuk> cjwatson: if you feel like a C-related challenge, could you read through bug 436758 (esp. my most recent comment)
[12:37] <Keybuk> (when my most recent comment shows up)
[12:39] <slangasek> njpatel: was reviewing this netbook-launcher change; isn't this solution racy, assuming that waiting 2 seconds is sufficient?
[12:39] <slangasek> lool: ^^ let's discuss here
[12:42] <hgomersall> I'm trying to debug a suspend issue on my laptop. Can anybody point me to the best channel for expertise on this?
[12:45] <lool> njpatel, slangasek: 13:42 < lool> njpatel|lunch: Perhaps a way to address slangasek's concerns is  to use a static var near the toggle desktop thing in  netbook-launcher which would fire a g_idle with no delay the  first time toggle desktop is hit
[12:46] <Pici> hgomersall: #ubuntu or #ubuntu+1 , depending on what version of Ubuntu you're running
[12:47] <mvo> Keybuk: should I add a check sparc into u-m and warn/error on upgrade ? or do expect a fix very soon?
[12:48] <hgomersall> Pici: its karmic, is that +1?
[12:50] <Keybuk> mvo: it's in the release notes
[12:50] <Keybuk> "sparc is fail"
[12:51] <Pici> hgomersall: yes
[12:51] <hgomersall> Pici: thanks!
[12:56] <cjwatson> Keybuk: while sizeof does include padding for the size of the object in question, it doesn't necessarily include padding for every conceivable type of object that might fall after it. I don't think you're correct that pointers are the largest possible alignment; long long needs to be 8-byte-aligned, AFAIK
[12:56] <cjwatson> Keybuk: so if there's an odd number of NihAllocCtx structures followed by (e.g.) something including a long long, won't the long long be misaligned?
[12:57] <slangasek> long long> there are archs that require alignment greater than the word size?
[12:57] <cjwatson> hi, sparc
[12:58] <cjwatson> according to some random document I found on sun.com, yes
[12:58] <slangasek> heh
[12:58] <spaetz> Just checked svn log. t@h had close to realtime rendering since 03-2007 at least...
[12:58] <spaetz> oops, sorry
[12:58] <cjwatson> http://docs.sun.com/app/docs/doc/819-3196/6n5ed4hm7?a=view
[12:58] <Keybuk> cjwatson: not sure
[12:58] <Keybuk> let me check
[12:59] <cjwatson> Keybuk: that would be my interpretation, and it explains why aligning on 24 rather than 20 would fix things
[12:59] <cjwatson> (I don't think -m64 matters, don't we build sparc32 userspace?)
[12:59] <Keybuk> cjwatson: because 24/8 is 3
[13:00]  * Keybuk wonders what he uses that includes a long long
[13:00] <cjwatson> I don't have a full list of alignment requirements; long long may not be the only such
[13:00] <Keybuk> so if you have a structure that contains a 8-byte alignment word
[13:01] <Keybuk> would that, itself, be 8-byte alignment?
[13:01] <cjwatson> it must be aligned such that the 8-byte alignment member is aligned appropriately
[13:02] <Keybuk> but alignof for a struct with a long long doesn't work ;)
[13:02] <Keybuk> it says 4
[13:02] <cjwatson> it may well be done with padding
[13:03] <cjwatson> oh, padding wouldn't work
[13:03] <slangasek> can't be reliably done with padding unless the alignment of the struct itself is enforced
[13:03] <cjwatson> yeah
[13:03] <Keybuk> oh, sorry, I'm a numpty
[13:03] <Riddell> how can I get quilt to apply a patch only on a specific architecture?
[13:04] <slangasek> Riddell: <cough> dynamically construct your series file via debian/rules
[13:04] <Keybuk> right, if you have something 8-byte aligned at the front of the structure
[13:04] <pitti> Riddell: with "series" you can't AFAIK; call quitl in debian/rules or use dpatch :)
[13:04] <Keybuk> or sometimes in the structure (if it can't be solved with padding between elements)
[13:04] <Keybuk> then yes, the alignof does return 8
[13:04] <Keybuk> so this would only affect certain structs
[13:05] <Riddell> hmm, ok, I'll work out another way
[13:05] <cjwatson> the C spec suggests that double is guaranteed to be the largest alignment
[13:06] <cjwatson> (from a footnote to the definition of malloc)
[13:06] <Keybuk> ooh
[13:06] <pitti> Riddell: what about applying it all the time and use #if defined(__sparc__) or so?
[13:07] <Keybuk> cjwatson: always guaranteed?
[13:07] <Riddell> pitti: it's a cmake file, not sure how to get cmake to do that
[13:07] <Keybuk> so the problem isn't the alignment of the struct, the problem is that the pointer returned (following the struct) must be absolutely neutrally aligned
[13:08] <cjwatson> actually sorry it's a footnote to sizeof
[13:08] <cjwatson> oh, bah, I'm misreading!
[13:08] <Keybuk> so __alignof__ (double) * ((sizeof (NihAllocCtx) - 1) / __alignof__ (double) + 1)
[13:08] <Keybuk> ?
[13:08] <cjwatson> no, I missed a bit in the example
[13:08] <Keybuk> oh
[13:08]  * cjwatson reads some more
[13:09] <Keybuk> but yeah, I see that it must be aligned to the largest possible alignment
[13:09] <Keybuk> because what follows it must be aligned
[13:09] <Keybuk> so the problem is finding the largest possible alignment
[13:10] <cjwatson> glibc's malloc just does 2*sizeof(size_t)
[13:11] <cjwatson> with a comment that the only problem is -mlong-double-128 on powerpc, and that a better definition would be max(2 * sizeof(size_t), __alignof__(long double)) but that it can't use this due to compatibility problems
[13:11] <liw> I'd assume long double would be the largest possible alignment of the standard types
[13:11] <cjwatson> so you probably want to use the latter
[13:11] <Keybuk> cjwatson: yeah was just reading that exact code
[13:12] <cjwatson> I'm going to guess (possibly unwisely) that there isn't a better way or glibc would be using it :)
[13:12] <lool> slangasek: 14:05 < njpatel|lunch> lool: I don't think 2sec delay is that bad. We don't  know how many times toggle desktop is hit during start  up, so we can't be sure that it will work on the first  one
[13:12] <Keybuk> cjwatson: we could burn Sun to the ground
[13:12] <lool> njpatel: Shall we count them in a log message and use that approach if it's only called once?
[13:12] <slangasek> lool: the concern I have is not with delay, it's with 2 sec not being long /enough/
[13:13] <lool> slangasek: I kind of agree with you as I have seen the interface load really slowly in virtualbox
[13:13] <njpatel> slangasek: the delay is to skip the idle handlers that were registered by wnck and to receive x events. I believe it's more than long enough, I can't see where you wouldn't get those events and not have bigger issues to worry about.
[13:14] <njpatel> slangasek: lool: I can re-do with an g_idle_add instead, and I'm pretty sure it would still work, if that is easier to digest
[13:15] <njpatel> lool: I can create some debs in a few minutes and ask jamie to test
[13:16] <slangasek> njpatel: I don't think I understand what you mean about skipping handlers
[13:17] <njpatel> slangasek: we need to let the launcher receive events from X and wnck. the timeout can probably be replaced by a g_idle_add, which would have the same effect. I'm rebuilding some debs with the patch so lool/david/jamie can test.
[13:18] <njpatel> that would get rid of the g_timeout_8
[13:18] <njpatel> g_timeout_add_seconds*
[13:20] <slangasek> njpatel: ah, ok
[13:26] <njpatel> http://people.canonical.com/~njpatel/netbook-launcher_2.1.12-0ubuntu1_i386.deb has the updated fix. Jamie is going to try it out in a bit. I'll update here when we get some results.
[13:30] <primes2h> cr3: I checked updated installation of Karmic. Checkbox strings are translated all but those with /
[13:30] <cr3> primes2h: I've encountered a couple serious bugs this weekend, so I might be able to push an update into karmic. thanks for the heads up
[13:32] <primes2h> cr3: That's nice. so are you going to ask for a ffe? or you mean after the release.
[13:32] <cr3> primes2h: ffe
[13:32] <caio> can anyone explain me why ubuntu uses 1500 as default mtu? most websites does not allow mtu up to 1492 :(
[13:33] <primes2h> cr3: Great. Thank you very much. Tell me if you  need some feedback. :)
[13:34] <cjwatson> caio: I don't believe we do; we accept the MTU set by your DHCP server
[13:34] <cjwatson> caio: so, if you run the DHCP server, reconfigure it; otherwise, complain to your ISP
[13:36] <soren> What triggers configuration of the loopback device?
[13:38] <slangasek> soren: /etc/init/networking.conf
[13:38] <soren> slangasek: Really? It used to be brought up by S40networking?
[13:38] <soren> That late?
[13:38] <caio> cjwatson: only strange, because a laptop with windows wasn't affected with this mtu problem
[13:39] <slangasek> soren: late?  When else would it have been brought up (and why)?
[13:39] <caio> maybe windows already configured with 1492 instead of automatic mtu?
[13:39] <soren> slangasek: rc2.d/S40 just seems late for something like that.
[13:39] <kirkland> cjwatson: slangasek: mdz: I'm here now; do we still need assistance with the iscsi-on-root issue?
[13:39] <slangasek> soren: it wasn't in rc2
[13:40] <soren> Oh. Oh, right.
[13:40]  * soren facepalms
[13:40] <soren> my bad.
[13:40] <slangasek> kirkland: I believe you know everything I do about the current status
[13:41] <kirkland> slangasek: i was afraid of that...  okay, i'll go reproduce the issue
[13:44] <soren> Ok, I need help working this upstart stuff out.. networking runs once something has emitted local-filesystems and udevtrigger has stopped). rc-sysvinit sets runlevel and runs when "filesystems" is emitted... So once mountall is done, it emits "local-filesystems" as well as "filesystems"...
[13:44] <soren> and thus triggers runlevel 2.
[13:44] <soren> But networking might still be waiting for udevtrigger to finish, right?
[13:45] <soren> Does udevtrigger block at all?
[13:45] <soren> I forget.
[13:46] <slangasek> soren: udevtrigger does what it says on the box^W^W^W in /etc/init/udevtrigger.conf
[13:46] <cr3> bryce__: hi there, let me know when you have a moment to follow up on bug #427932
[13:47] <slangasek> soren: and local-filesystems is emitted when there are no more local filesystems to mount, not when it's "done"
[13:47] <soren> slangasek: Are they not functionally equivalent?
[13:47] <slangasek> no
[13:47] <slangasek> soren: so is this about the iscsi stuff?
[13:48] <soren> slangasek: Not at all.
[13:48] <slangasek> ok, n/m then
[13:48] <slangasek> local-filesystems is specifically emitted when all the *local* filesystems are mounted
[13:48] <soren> So when an upstart job description says "emits foo", what does that mean?
[13:48] <slangasek> you don't want networking to block waiting for remote filesystems to be mounted first
[13:49] <slangasek> soren: it's documentation only
[13:49] <soren> slangasek: upstart doesn't even look at it?
[13:49] <slangasek> nope
[13:49] <soren> I see.
[13:49] <soren> That explains a lot.
[13:49] <soren> A whole lot, actually.
[13:49] <slangasek> (cf. init(5))
[13:49] <soren> Ah, /that/'s the man page to look for!
[13:50] <soren> And mountall (the binary, not the job) emits those events?
[13:50] <soren> ttx: ^^ You may want to follow this :)
[13:51] <slangasek> correct
[13:51] <soren> Interesting.
[13:51]  * ttx looks
[13:51] <slangasek> emitting is done by the equivalent of '/sbin/initctl emit <foo>'
[13:51] <soren> Right.
[13:53] <soren> Ok, so now that we've cleared that up.. I'm still not sure how I can be sure that networking is run before we start processing rc2.d init scripts.
[13:53] <soren> couldn't networking still be waiting for udevtrigger?
[13:53] <soren> Or will mountall perhaps not finish (thus emitting filesystems) until udevtrigger finishes?
[13:54] <soren> That would sort of make sense, but I don't see that logic anywhere.
[13:54] <slangasek> "waiting" meaning "hanging", or "waiting" meaning "waiting"?
[13:54] <soren> Yes?
[13:54] <slangasek> udevtrigger calls 'udevadm trigger' && 'udevadm settle'
[13:54] <soren> waiting, I think.
[13:54] <soren> Yes.
[13:54] <slangasek> this shouldn't hang
[13:55] <soren> udevadm setting in post-stop, though.
[13:55] <soren> I thought udevadm settle blocked until it's done processing events?
[13:55] <slangasek> until it's done processing all events currently in the queue
[13:55] <soren> Right.
[13:55] <slangasek> which in no case should result in a /hang/
[13:55] <slangasek> what is it you're actually trying to do?
[13:56] <soren> I'm just trying to understand if (and if so, how) we know that the loopback device is available once we start going through rc2.d/S* scripts.
[13:56] <njpatel> slangasek: we may have a waaaay saner fix
[13:57] <soren> ..since that used to be the case (given that networking ran at rcS.d/S40)
[13:57] <njpatel> slangasek: just testing then will ping lool with patch
[13:57] <ttx> ..and some server software kinda expects at least loopback to be up when started.
[13:58] <ttx> for example, rc2.d/S15dnsmasq
[13:58] <slangasek> soren: we don't; it's racy; file a bug on upstart
[14:00] <soren> slangasek: You agree that having lo availab in runlevel to is a reasonable expectation?
[14:00] <soren> What the?
[14:01] <soren> That did not come out the way I thought I typed it. :)
[14:01] <slangasek> soren: yes, everything that rcS did for us before should still be guaranteed
[14:01] <soren> slangasek: You agree that having lo available in runlevel two is a reasonable expectation?
[14:01] <soren> slangasek: Lovely, thank you.
[14:01] <soren> ttx: Can you turn this into a bug report yourself? :)
[14:01] <slangasek> unfortunately, switching /half/ of our init system has introduced a few race conditions
[14:01] <ttx> soren: last time I filed a bug in upstart it didn't turn out so well :)
[14:02] <soren> ttx: I woudl quote relevant parts of this IRC discussion. In particular slangasek's last three comments :)
[14:05] <mterry> ScottK: following up about that report of a no-longer-have-a-syslogger after jaunty-to-karmic?  I never saw a bug go through.  There is an existing Incomplete report for similar issue.  Could your user add details to it or file new one?  bug 440914
[14:05] <ScottK> mterry: The guy that had the report was gone off IRC before I could get him to report it.
[14:06] <ScottK> mterry: If I see him again, I'll point him at that bug.
[14:07] <mterry> ScottK: ah, cool.  np
[14:07] <sgallagh> Does ubuntu have a graphical tool for configuring directory services (such as LDAP, NSS, etc,) and authentication services (such as Kerberos)?
[14:10] <slangasek> sgallagh: configuring the services, or selecting which ones to use?
[14:10] <sgallagh> slangasek: More the former than the latter.
[14:11] <slangasek> then I don't believe so
[14:11] <sgallagh> slangasek: What is the other?
[14:12] <slangasek> sgallagh: pam-auth-update lets you configure which authentication services to use
[14:12] <sgallagh> I'm trying to figure out who to speak to about getting the SSSDConfig API integrated in ubuntu
[14:12] <njpatel> davidbarth: lool: slangasek: http://paste.ubuntu.com/302075/ this will fix it properly. We were activating the launcher window for no reason.
[14:12] <slangasek> though it's not integrated anywhere /from/ the gui, you have to run it from the commandline (or let it be launched during package configuration)
[14:12] <slangasek> effectively, you shouldn't have to run it at all to configure anything, just install the packages you want
[14:16] <sgallagh> slangasek: How is one expected to configure LDAP for user information or kerberos for authentication?
[14:17] <slangasek> sgallagh: using the usual methods for those services
[14:17] <sgallagh> slangasek: Hacking on a config file, in other words.
[14:18] <mathiaz> sgallagh: another non-gui package is auth-client-config
[14:18] <mathiaz> sgallagh: jdstrand wrote that package ^^
[14:19] <slangasek> sgallagh: erm, you said "configure kerberos for authentication", not "configure your machine to use Kerberos for authentication"
[14:19] <sgallagh> mathiaz: Where I'm going with this is that the SSSD as of 0.7.0 now has an API for managing our config files, and I was hoping that I could talk to someone about implementing this to make life easier
[14:19] <slangasek> you don't configure kerberos for authentication by editing config files
[14:19] <slangasek> and you don't need to edit any config files on your local system in order to point it at Kerberos
[14:20] <sgallagh> slangasek: what about /etc/pam.conf (or /etc/pam.d/system-auth)
[14:20] <lool> njpatel: thanks; so that's replacing the previous patch?
[14:21] <sgallagh> slangasek: and of course /etc/krb5.conf to set up the realm properly...
[14:21] <slangasek> sgallagh: I just told you about pam-auth-update
[14:21] <mathiaz> sgallagh: right - I saw that. I'll probably schedule a session at the next UDS to talk about that
[14:21] <simon-o> ScottK: The IRC log from bug 459164 you attached to the MP, where did that take place?
[14:21] <ScottK> simon-o: #ubuntu-motu
[14:21] <slangasek> sgallagh: run "apt-get install libpam-krb5" and see if this doesn't do everything for you
[14:21] <sgallagh> slangasek: Where I'm going with this is that SSSD (and its config API) should make it really easy to set this stuff up.
[14:21] <sgallagh> I'm campaigning, here ;-)
[14:22] <sgallagh> mathiaz: OK, do you want me to be present to answer questions?
[14:22] <simon-o> ScottK: Ok, thanks. I'll take a look at it. Next time please ping me, then I can participate in the discussion :)
[14:22] <mathiaz> sgallagh: present - virtually or physically?
[14:23] <ScottK> simon-o: I didn't know you were on IRC.  Please ping me on #ubuntu-motu when you have an update.
[14:23] <mathiaz> sgallagh: anyway - the sessions should streamed online
[14:23] <sgallagh> mathiaz: WHere are USDs held?
[14:23] <simon-o> ScottK: Sure, I'll do
[14:23] <simon-o> thanks again
[14:23] <sgallagh> err UDSs
[14:23] <YokoZar> What's Scott James Remnant's IRC nick?  Not on his launchpad/wiki page :(
[14:23] <mathiaz> sgallagh: in Dallas - https://wiki.ubuntu.com/UDS-L
[14:23] <azeem> Keybuk
[14:24] <sgallagh> mathiaz: Virtually, then
[14:24] <mathiaz> sgallagh: anyway there are streamed online
[14:24] <YokoZar> oh nevermind it is on launchpad I can't see anything
[14:24] <mathiaz> sgallagh: once the schedule is published I'll let you know if there is a specific session about sssd and its integration with the API
[14:24] <YokoZar> Anyway Keybuk did you see Mephisto's comment on 447197  (it came seconds before you closed it)
[14:24] <sgallagh> mathiaz: Thanks
[14:24] <njpatel> lool: yes, replaces previous patch. Tested by Jamie
[14:24] <mathiaz> sgallagh: I may have time to poke at 0.7.0 before and look at the new config API.
[14:25] <sgallagh> mathiaz: We're also aiming to have a 1.0 Release Candidate around Nov. 18th, with a final release of 1.0 occurring sometime in December.
[14:25] <Keybuk> YokoZar: it wasn't relevant to the procps task
[14:25] <mathiaz> sgallagh: that sounds like a great timing from our perspective!
[14:26] <Keybuk> (that I could see
[14:26] <sgallagh> mathiaz: Well, what I'm getting at is that if there's anything you guys want to see in SSSD 1.0, the window is closing rapidly :)
[14:27] <YokoZar> Keybuk: is there a problem with sysctl though?  It seems like making a package install script fail due to something that should just be ignored in /etc/sysctl.d is a bad thing
[14:27] <pitti> dpm: these need to become SRUs
[14:27] <Keybuk> YokoZar: I don't think there's a problem in sysctl?
[14:27] <mathiaz> sgallagh: understood.
[14:27] <pitti> Riddell: cmake> how is that relevant for patching the code?
[14:28] <YokoZar> Keybuk: so is it supposed to exit status 1 on an unknown key then?
[14:29] <sgallagh> mathiaz: Nov. 18th is intended to be feature-complete, with only bugfixing after that. We'll see if this is actually achievable when we get there, of course.
[14:29] <Keybuk> YokoZar: no idea, the manpage doesn't document its exit codes
[14:30] <liw> have any packages been updated in the archive since the RC image?
[14:30] <zul> slangasek: ah it looks like a patch got dropped when we updated php
[14:30] <Keybuk> unknown key could be a security issue, etc. so seems reasonable
[14:30] <cjwatson> liw: yep
[14:30] <liw> cjwatson, thanks
[14:33] <YokoZar> Keybuk: shouldn't it complain at boot rather than package install time?  having wine install break is the first they're being made aware of the bad keys
[14:34] <Riddell> pitti: the patch edits cmake to stop it compiling the nepomuk code
[14:34] <Keybuk> YokoZar: well, wine should clearly deal with things in its postinst properly
[14:34] <Keybuk> that's why i closed out the sysctl task
[14:34] <pitti> Riddell: ah, I see
[14:34] <Keybuk> there may be a separate bug to improve the upstart job separately, but it's not related just resultant
[14:35] <YokoZar> Keybuk: you mean ignore error exit status 1 when calling start procps  ?
[14:36] <YokoZar> Keybuk: we should at least update /etc/sysctl.d/README to reflect the change from invoke-rc.d to start
[14:36] <Keybuk> YokoZar: only if exit status 1 *only* means that, etc.
[14:37] <Keybuk> sure
[14:37] <superm1> pitti, oh shame.  is that something that can be improved upon?
[14:39] <pitti> superm1: hm, you'd need to set up a retracer for a particular upstreamish PPA, and check the package origin somehow
[14:40] <pitti> not trivially, I'm afraid
[14:40] <pitti> and PPAs don't have ddebs either
[14:40] <superm1> pitti, well if it's only for apport reported bugs, remember an apport conf has to come in the package to set the project that the bugs get filed to
[14:41] <pitti> right
[14:41] <superm1> so debugging symbols aren't stripped from the packages though, so they should be remaining in the deb itself shouldn't they?
[14:41] <pitti> superm1: you build your PPA packages without stripping?
[14:41] <pitti> well, in this case you wouldn't even need a retracer?
[14:42] <superm1> pitti, well I had thought there is something in soyuz that prevents stripping from happening on PPA builds
[14:42] <superm1> i recall looking at a build log and seeing a reference to it
[14:42] <cjwatson> if so, where do the symbols go ...
[14:44] <pitti> superm1: no, I don't think so; that logic is built into dh_strip and upstream build systems (for the CFLAGS="-g -O2" bits)
[14:44] <pitti> superm1: perhaps you are mixing it up with stripping translations?
[14:44] <superm1> pitti, well what i was seeing was "dh_strip debug symbol extraction: disabling for PPA build", which I suppose I was mis-assuming as the symbols still end up in the binaries
[14:45] <pitti> ah; that just means that it won't build .ddebs
[14:45] <superm1> ah, but the stripping still happens..
[14:45] <lool> slangasek: New patch from njpatel above was tested successfully by JamieBennett but davidbarth is not confortable with it because it is hard to test
[14:46] <slangasek> lool: should we stick with the current solution, then?
[14:46] <lool> slangasek: (I had already pushed to the queue when we discussed it)
[14:47] <slangasek> zul: what patch was dropped from php?
[14:47] <zul> slangasek: hold on
[14:48] <njpatel> lool: slangasek: There are four main things to test: 1. Open a window and click on the desktop, make sure the launcher comes into focus. 2. Open a window and press Ctrl+Alt+D, make sure the launcher focuses 3. Open a window and press the go-home-applet, make sure the launcher comes into focus 4. Add the 'show-desktop' applet, open a window and click on the applet, make sure the launcher comes into focus.
[14:48] <lool> slangasek: It's pretty much the only thing we care fixing for release; I dont mind either way, but the xsession-errors which Jamie saw with the first patch worried me a bit; I kind of agree with davidbarth's argument about testability though, so if he wants to play safe I understand
[14:48] <zul> slangasek: 019-z_off_t_as_long.patch
[14:48] <davidbarth> slangasek: for a fix to integrate /right now/ i'm more comfortable with the one from this morning
[14:48] <lool> njpatel: That sounds like you have a relatively good idea of the possible code pathes and puts me into more confidence that we can fix it
[14:49] <lool> s/fix it/test it
[14:49] <njpatel> lool: Yep, although I'm asking Jamie to also test these. It shouldnt' take longer than a couple of minutes
[14:49] <superm1> pitti, well ideally during UDS can you try to help work out a solution for such scenarios with myself and some of the people normally doing our bug triaging that will be there?  we'd really like to make these PPAs useful to upstream since they're building tip regularly, and it's looking like this is the missing link then
[14:50] <davidbarth> slangasek: if you have an upload window for tomorrow morning, i think we can let the new one being tested a bit more (because the 4 code paths need to be exercised)
[14:50] <slangasek> davidbarth: no, we should get this settled today
[14:51] <pitti> superm1: I'm happy to explain how the current setup works, and then we can discuss how to extend it to PPAs without much ongoing maintenance cost
[14:51] <lool> slangasek: How about we test for 45 minutes and report on at least 4 successful tests?
[14:51] <davidbarth> slangasek: i can have that new one tested properly but will need around 1h
[14:51] <superm1> pitti, Ok, great thanks :)
[14:51] <njpatel> davidbarth: lool: (14:50:51) JamieBennett: njpatel: All work for me.
[14:52] <lool> njpatel: 1
[14:52] <davidbarth> njpatel: meaning, the 4 code paths
[14:52] <njpatel> yep
[14:52] <slangasek> lool, davidbarth: that would work; you're testing locally, and I should accept the package in the queue only once confirmed ok?
[14:52] <lool> Yup
[14:52] <davidbarth> slangasek: ok, let's do that
[14:53] <lool> Back to you at 3:30 UTC
[14:54]  * mvo_ grumbles - his laptop just shut itself down because of critical temperature 
[14:55] <soren> On fire, eh?
[14:55]  * mvo_ looks for smoke
[14:55] <ccheney> anytime the initrd is regenerated it suggests you reboot?
[14:55] <ccheney> even for just a usplash update, heh
[14:55] <mvo_> not quite it seems, but almost ~100°C
[14:56] <ccheney> mvo_: wow thats hot
[14:56] <ScottK> Perfect for making tea.
[14:56] <mvo_> tea!
[14:56]  * mvo_ will do exactly that
[14:56] <ccheney> mvo_: did the fan die?
[14:56] <mvo_> ccheney, I don't think so, but I guess I will have to open the case to see if the fan collected too much dust or something
[14:57] <ccheney> mvo_: hopefully linux didn't decide to just turn the fan off, heh
[14:58]  * ScottK had one of those bugs in Gutsy.
[15:00] <ccheney> suspend/resume seems much more buggy in karmic than previous releases at least for my laptop (thinkpad x200)
[15:00] <ogra> mvo_, the reboot notification comes up for me while u-m is still operating, do you have a bug about that open ?
[15:00] <ccheney> i went to file a bug but saw large numbers of reports already
[15:00] <mvo_> ogra, during a partial upgrade?
[15:01] <zul> slangasek: i have uploaded it to my ppa and ask people for testing
[15:01] <ogra> mvo_, just when running u-m from my menu
[15:01] <ogra> some package triggers a reboot request and the window pops up
[15:01] <mvo_> ogra, could you give me the output of ps afx please?
[15:02] <slangasek> zul: ok
[15:02] <ogra> mvo_, not really, that was two days ago (and i was travelling)
[15:02] <ogra> but i think u-m should suppress the notification until it's done
[15:03] <mvo_> ogra, hm, it should, however there is a bug that during a partial upgrade that sometimes does not work
[15:04] <ogra> mvo_, partial is the one where i get the extra popup in u-m ?
[15:04] <mvo_> ogra, yes
[15:05]  * ogra thinks he should really run at least one fully english desktop for the proper wording :P
[15:05] <ogra> yes, then i had a partial upgrade and hit the same bug
[15:06] <mvo_> ogra, thanks
[15:09] <kees> asac: hehe you too, eh?
[15:09] <kees> $ id kees
[15:09] <kees> uid=501(kees) gid=501(kees) groups=501(kees)
[15:09] <kees> 501!  :)
[15:10] <ogra> 501 ? reserved for thpethial users ? :)
[15:11] <kees> ogra: it's from really old installs.  I probably did it because I use an NFS home directory, and created my "kees" account in 1995 or something on RH 5 (?)
[15:11] <ogra> heh
[15:13] <lool> slangasek: krafty teted and passed the tests with no regression
[15:14] <slangasek> lool: does that mean everyone's satisfied with this solution?
[15:15] <lool> slangasek: Sorry just one report
[15:15] <lool> slangasek: Waiting for davidbarth's testing report
[15:15] <slangasek> ok
[15:25] <jimpop> hi all.  i have an autoconf question wrt to a some Ubuntu code... is that applicable here?
[15:25] <jimpop> i want to modify a source pkg so that ./configure sets up Makefile to use a different include path
[15:25] <jimpop> i realize i can do EXTRA_CFLAGS -I...., but i want to have autoconf support this
[15:26] <jimpop> additionally, due to kernel header changes, I need to define __KERNEL__ now to gcc.... so that too needs to be added to config.in.h ? or where?
[15:27] <cjwatson> defining __KERNEL__ in userspace code is a very bad idea, so unless you're writing a kernel module I'd strongly recommend against it - if necessary, copy the definitions you need instead (and maybe ask the kernel guys if they can expose it in future)
[15:27] <cjwatson> configure.ac can typically just add -I options to CFLAGS
[15:27] <jimpop> cjwatson, this is a video driver...
[15:27] <cjwatson> video as in an X driver?
[15:27] <jimpop> yes
[15:28] <jimpop> which, to me, is both userspace and module'ar
[15:28] <cjwatson> I believe that still counts as userspace
[15:28] <jimpop> cjwatson, k
[15:28] <cjwatson> X drivers aren't kernel modules. Sometimes there's a separate component that lives in the kernel
[15:29] <jimpop> cjwatson, that is the case with this (psb) there is a kernel module and a xorg module
[15:30] <dpm> pitti, (re: the translation fixes needing to be SRU), np, I'll prepare the SRUs, then. Thanks for looking into that.
[15:33] <lool> slangasek: Ok; we have enough reports now (I tested on davidbarth's netbook, I tested in virtualbox, I tested with krafty on his dell mini 10v, JamieBennett tested and marjo gave a quick smoke test as well)
[15:33] <slangasek> lool, davidbarth: so I should take this new netbook-launcher fix?
[15:34] <cjwatson> jimpop: so define __KERNEL__ at the top of some file(s) used only by the kernel module code
[15:34] <cjwatson> definitely not config.h.in
[15:34] <jimpop> no -D__KERNEL__  ?
[15:37] <lool> slangasek: Yes
[15:37] <lool> slangasek: davidbarth is in phone meetings rest of day apparently
[15:37] <slangasek> lool: ok; accepted
[15:37] <lool> Thanks
[15:37] <lool> njpatel: ^ it's in
[15:37] <njpatel> lool: Awesome!
[15:38] <lool> We should retest the resulting binaries quickly when they popup
[15:39] <cjwatson> jimpop: you can do that if you like, although it usually belongs in the Makefile.am or whatever not in autoconf bits. Seems like more hassle to me than putting it in a .h or .c file, but up to you
[15:40] <lool> mvo_: Are you happy with the emacsen-common fix?  Do you have a way to test the upgrade scenario which lead to the bug?
[15:40] <jimpop> cjwatson, ok, i'll give it a go using  a #define, and if not then investigate Makefile.am.  Thanks!
[15:42] <mvo_> lool, I though I replied to that, but maybe it got eaten by a disconnect. I'm happy with the fix but I have no way to reproduce it (other than the bugreport I got)
[15:43] <davidbarth> slangasek: test reports positive, i recommend taking it (if not already the case ;)
[15:44] <slangasek> davidbarth: right, done already - thanks. :)
[15:45] <cjwatson> jimpop: (if there isn't a Makefile.am, try Makefile.in or Makefile in turn; this varies)
[15:45] <lool> mvo_: Ok; I didn't get the reply; thanks
[15:45] <jimpop> cjwatson, i see that. ;-)
[15:45] <lool> mvo_: Hmm actually I did, sorry
[15:45] <lool> 13:03 < mvo> lool: the diff looks good, I don't ahve a way to reproduce the  issue myself, but I think the fix is good
[15:45] <mvo_> lool, no problem :)
[15:45]  * lool sucks
[15:45] <mvo_> lool, thanks for the super-quick fix
[15:46] <dmart> Does anyone know where I can get a vmlinux image for use with oprofile?
[15:46] <dmart> Specifically, I'm trying to do profiling on karmic armel
[15:46] <ccheney> hmm whatever was done to the default Ubuntu 9.10 theme now vmware can't even leave checkboxes checked they go away immediately
[15:48] <lool> dmart: I did read someone did it a while back in jaunty on an imx51 kernel
[15:48] <lool> dmart: Back then one had still to patch this support in, but perhaps the upstream kernel support for it is good enough now; no idea
[15:49] <lool> dmart: In fact I have some notes that I could perhaps pass you around if you're really interested -- I'd have to check whether I can release the info
[16:31] <LaserJock> slangasek: do you have any respins of Edubuntu planned at this point?
[16:31] <slangasek> LaserJock: it's in my queue currently
[16:31] <LaserJock> slangasek: ok, great, thanks
[16:35] <JontheEchidna> pitti: ping
[16:39] <zooko> Folks: I have a lead on what might be a regression between g++-4.4.1-3ubuntu3 and g++-4.4.1-4ubuntu8.
[16:39] <zooko> I'm still narrowing it down and reproducing it, but I wondered if someone else wanted to try this easy experiment:
[16:39] <zooko> rebuild libcrypto++8.
[16:39] <zooko> On my machine, that fails with the current karmic g++ (4.4.1-4ubuntu8).
[16:41] <kees> zooko: I'm starting a local build now.
[16:50] <zooko> kees: great.
[16:50] <zooko> What I observe is that the self-test hangs on the SHA validation.
[16:50] <zooko> Also I get segfaults when I link to the resulting lib from pycryptopp.
[16:51] <zooko> You could also try rebuilding python-pycryptopp and runnings its self-tests if you want.
[16:53] <kees> zooko: yup, hangs after:
[16:53] <kees> passed   34aa973cd4c4daa4f61eeb2bdbad27316534016f   "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" repeated 15625 times
[16:54] <zooko> kees: so, what I'm doing right now is trying to set up a pbuilder chroot with g++ 4.4.1-3ubuntu3.
[16:54] <zooko> Because that's the version of g++ that was used to build the version of libcrypto++8 that is currently in karmic.
[16:54] <blackxored> where I can find someone to file an FFE for azureus-4.2.0.8-3 ??
[16:54] <zooko> I'm not expert at this pbuilder stuff, though, so it is taking me a while to get g++-4.4.1-3ubuntu3 and all its many dependencies installed into my chroot.
[16:58] <zooko> http://codepad.org/3whfme67
[16:58] <zooko> ^-- my failure to install cpp in my pbuilder chroot.
[16:58] <zooko> ^-- mysteriously it says it requires "libcloog-ppl0 (>= 0.15~git20081008)", which is a non-existent package that it just made up in order to tease me.
[16:59] <kees> cloog-ppl | 0.15.7-1                  | karmic/main
[17:02] <cjwatson> zooko: libcloog-ppl0 exists fine here
[17:05] <ScottK> blackxored: Come talk to me in #ubuntu-motu about why we want it.
[17:05] <blackxored> ScottK, thanks
[17:14] <zooko> cjwatson: thanks.  must have beenspelling it wrong
[17:15] <zooko> cjwatson, kees: do you know any technique for installing "the version of cloog that matches g++-4.4.1-3ubuntu3" ?
[17:15] <zooko> I guess I can manually inspect publication history and download and dpkg -i and then recurse for all deps, but that will take a while.
[17:16] <cjwatson> can't apt-get do it for you?
[17:16] <cjwatson> oh, you're using an older version
[17:17] <cjwatson> well, the current version of libcloog-ppl0 in the archive satisfies that dependency
[17:17] <cjwatson> you can 'apt-get -f install' and it should try to fix the current system ...
[17:17] <zooko> cjwatson: thanks.
[17:17] <zooko> I'll try that.
[17:18] <zooko> Whoops it upgraded my g++ to 4.4.1-4ubuntu8.
[17:18] <cjwatson> if you said 'apt-get -f install' without further arguments, that must mean that it couldn't satisfy the dependencies given what's in the archive
[17:19] <cjwatson> so my approach would be to find out which dependency caused g++ to be upgraded, download and install an older version of that by hand, and iterate
[17:20] <zooko> Phewf, how do I do that first step?
[17:20] <zooko> Figuring out which dep caused g++ to be upgraded?
[17:21] <cjwatson> there are few enough dependencies that I'd just walk them by hand
[17:21] <cjwatson> BTW you do know that g++ is just a dependency package don't you? g++-4.4 is the actual substantive package name
[17:23] <zooko> Sigh.  Let me back up a step.  We know that the current g++-4.4 (4.4.1-4ubuntu8) miscompiles libcrypto++8.
[17:24] <zooko> I guess it *must* be the case that g++-4.4 4.4.1-3ubuntu3 must have compiled it correctly, or at least well enough that libcrypto++8 passed its own self-test and got uploaded into karmic.
[17:24] <zooko> Which it does not do with the current g++.
[17:24] <zooko> So all this above was me attempting to reproduce the build with the older, working g++,
[17:24] <zooko> hopefully in order to further isolate the problem.
[17:25] <zooko> But, maybe that's not helpful.  What can I do to help?  I'm concerned about this regression in g++ in karmic, because it breaks one of my libraries:
[17:25] <zooko> http://allmydata.org/buildbot-pycryptopp/waterfall
[17:25] <zooko> See the red one?
[17:25] <zooko> (Not the failed upload, the "failed test".)
[17:25] <zooko> That shows that my application, when built on Karmic, gets segfaults.
[17:26] <zooko> That also means it might have an exploitable bug, for all I know -- I haven't understood it yet.
[17:26] <zooko> We're pretty sure that this is due to the karmic g++ miscompiling Crypto++.
[17:28] <zooko> Because kees reproduced the problem by attempting to rebuild libcrypto++8  with the current g++ and it fails for him/her, too.
[17:29] <zooko> I assume that a generates-wrong-code bug in g++ might be of concern to ubuntu devs for other reasons, too.
[17:29] <zooko> By the way, that buildbot runs it under valgrind too if that helps: http://allmydata.org/buildbot-pycryptopp/builders/linux-amd64-ubuntu-karmic-yukyuk/builds/11/steps/test/logs/valgrind
[17:31] <pitti> JontheEchidna: hi
[17:32] <JontheEchidna> pitti: Hi there! We were wondering if it would be possible to get a manual langpack upload to fix bug 460984
[17:32] <JontheEchidna> (https://translations.edge.launchpad.net/ubuntu/karmic/+source/kdepim/+pots/kmail/nl/+translate?batch=10&show=all&search=gmail)
[17:32] <zooko> Okay, while awaiting an Ubuntu dev to tell me how I can help with this (apparent) generates-wrong-code g++ regression
[17:33] <zooko> I'll try reproducing the build with g++ 4.4.1-3ubuntu3.
[17:34] <kees> pitti: do you happen to know what triggers the notifier for installing updates?
[17:35] <zooko> Okay I've installed g++ 4.4.1-3ubuntu3 in my pbuilder chroot.
[17:35] <pitti> kees: hm, not sure; inotify watch on /var/lib/apt/ perhaps? mvo would know
[17:36] <zooko> Ah, but when I exit that pbuilder --login and relogin it has reverted to its previous state.
[17:36] <zooko> How do I save the state of my pbuilder chroot after I've changed it?
[17:36] <pitti> JontheEchidna: a manual upload will be mercilessly overwritten by the next daily PPA/-proposed upload, though
[17:36] <ScottK> zooko: Yes.  pbuilder --login --save-after-login
[17:37] <zooko> Thanks!
[17:37] <JontheEchidna> pitti: but since the fix is already committed, wouldn't it be included in the next PPA/-proposed upload?
[17:37] <pitti> JontheEchidna: IMHO it's least intrusive to first fix it in Rosetta, and then put the updated .po into the update langpack, to avoid two uploads
[17:37] <pitti> JontheEchidna: right, it would
[17:39] <JontheEchidna> so what are our options at this point?
[17:39] <JontheEchidna> as it stands I'm pretty sure the correct string is now in Rosetta, correct me if I'm wrong
[17:40] <ScottK> JontheEchidna: At this point it might also be in the way of the CD/DVD build process to update it.
[17:40] <JontheEchidna> meh
[17:44] <dpm> JontheEchidna, also, related to that bug, have you found out what caused it? Looking at who did the translation, it seems he cannot have done it through Launchpad, as he doesn't seem to use it.
[17:44] <dpm> https://edge.launchpad.net/~f-de-kruijf-gmail
[17:45] <JontheEchidna> honestly I have no clue. It seemed a bit weird that it showed up as "packaged"
[17:45] <dpm> I'm just wondering if the rest of the Dutch translation might have problems
[17:47] <zooko> Folks: how can I figure out what package(s) are requiring newer versions of g++ to be installed?
[17:48] <JontheEchidna> dpm: the translator does appear to be from upstream. Maybe an import mishap?
[17:48] <cjwatson> apt-get -o Debug::pkgProblemResolver=true may help
[17:48] <dpm> JontheEchidna, that's what I'm looking at now, downloading kde-l10n-nl
[17:48] <cjwatson> in a verbose kind of way
[17:49] <zooko> Ah I think I found it.
[17:49] <zooko> cjwatson: thanks
[17:49] <cjwatson> alternatively, get the older g++-4.4 (NOT g++) into an apt repository (apt-ftparchive), point sources.list at it temporarily, apt-get install it, and see what problems it reports
[17:49] <pitti> JontheEchidna: as I said, we could do a manual upload of language-pack-kde-nl, put that single po file into it, and upload to -proposed, so that it'll be fixed right after install
[17:49] <cjwatson> i.e. "what would go wrong if I tried to downgrade this"
[17:50] <JontheEchidna> pitti: ah, ok. just a bit confused there for a moment :)
[17:50] <pitti> JontheEchidna: we can't get it into final any more, sorry (images already building)
[17:50]  * JontheEchidna nods
[17:50] <sabdfl> evand: the slideshow on install is very cool
[17:51] <evand> sabdfl: thanks!  Quite a few people made that happen, most notably Picklesworth.
[17:52] <sabdfl> please pass on the compliment then
[17:52] <sabdfl> very cool indeed
[17:53] <evand> will do
[17:54] <sabdfl> evand: what's the "skip" button do when i get to configuring apt?
[17:55] <cjwatson> that's a slow download, and sometimes it sticks for people, so it's basically the equivalent of ctrl-c-ing apt-get update; you'll just get what's on the cd
[17:55] <dpm> JontheEchidna, it seems that the imported upstream PO file had the error (from kde-l10n-nl-4.3.2/messages/kdepim/kmail.po) -> http://ubuntu.pastebin.com/d3fa327cd
[17:55] <JontheEchidna> I see
[17:56] <sabdfl> i see, thanks cjwatson
[17:56] <davmor2> sabdfl: Same applies to Xubuntu it used to go online to get the lang packs so you could skip that,  mind you that used to take ages
[17:56] <sabdfl> we could be clearer about that
[17:56] <sabdfl> "loking for online updates... [skip]"
[17:57] <dpm> JontheEchidna, and this seems to confirm it -> http://websvn.kde.org/tags/KDE/4.3.2/kde-l10n/nl/messages/kdepim/kmail.po?revision=HEAD&view=markup
[17:57] <cjwatson> yeah, I tend to agree - could you file a bug about that?
[17:57] <dpm> (first string)
[17:57] <sabdfl> will do
[17:57] <cjwatson> thanks
[18:04] <zooko> https://bugs.launchpad.net/ubuntu/+bug/461303
[18:05] <zooko> Okay, so I'm still hoping one of the grown-ups around here will take over and tell me how to further diagnose this and/or fix it for Karmic.
[18:05] <zooko> But in the meanwhile, I'm going to start bisecting the g++ versions and figure out exactly what change went from passing to failing.
[18:05] <ScottK> zooko: No chance of it getting fixed before release for Karmic, but it can go into a post-release update.
[18:05]  * zooko nods.
[18:05] <ScottK> I'd call it important, so please keep going.
[18:05] <zooko> Any advice for me?
[18:06] <zooko> Okay. :-)
[18:06] <ScottK> No, sorry, up to my eyeballs in other pre-release stuff.
[18:07] <sabdfl> evand: so, with the update download in place, does that mean we can close https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/346682 ?
[18:08] <sabdfl> and cjwatson, do you think https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/55505 is elegantly doable?
[18:10] <cjwatson> sabdfl: grave concerns about the feasibility of 55505, even finding out whether an update is available could easily take a very noticeable period of time; it would have to be a background thread that times out after the installer has got a certain amount through, and I expect a lot of people blast through the early stages of the installer pretty quickly
[18:10] <cjwatson> (there's no point in 55505 unless it's done right at the start, really)
[18:10] <cjwatson> that said, having an explicit "Check for updates" button would be elegantly doable, I think
[18:11] <zooko> Oh-ho.
[18:11] <zooko> pbuilder with g++-4.4 4.4.1-3ubuntu3 also hangs in the SHA validation test.
[18:11] <zooko> kees: can you reproduce that?
[18:12] <mvo> kees: update-notifier watches some dirs (like apt lists dir, /var/lib/update-notifier/dpkg-run-stamp etc) - why ?
[18:13] <kees> zooko: I use sbuild.
[18:13] <kees> mvo: can you check in with bdmurray, he's not seeing the update notifier on current karmic.
[18:14] <sabdfl> cjwatson: we would have to bypass normal package db update, and just do a special-url-check
[18:14] <sabdfl> is it possible to tell apt to download a package that it doesn't know about?
[18:14] <mvo> kees: could well be  that he does not sees it because the design team decided to now show the notification anymore but instead auto-open only every 7 days
[18:14] <cjwatson> sabdfl: if it were an explicit check, I think that'd be a lot more feasible, much less hacky, and with many fewer difficult corner cases
[18:15] <mvo> kees: that confused/is confusing a lot of people
[18:15] <cjwatson> sabdfl: I'd be happy to try to resurrect the sample code mvo did for that ages ago to that end for lucid
[18:15] <sabdfl> cjwatson: is it worth putting on the UDS discussion list, or is Ubiquity already wedged for Lucid?
[18:15] <evand> sabdfl: we deferred 346682 (https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-install-updates-when-installing)
[18:15] <kees> mvo: oh, right, the 7 day delay.  bdmurray: ping
[18:15] <sabdfl> i'm trying to get a feel for how much you have queued up and planned for it
[18:16] <cjwatson> sabdfl: I'll be syncing up with Robbie on this tomorrow
[18:16] <sabdfl> evand: so, it does a package update, but not the update-install bit?
[18:16] <mvo> bdmurray, kees: given how much confusion it causes i think we should at least re-discuss it again at uds
[18:16] <sabdfl> ok, thanks cjwatson, if you could consider it for UDS that would be great, as I do think there's value to us i having the ability to correct installer issues without a full point release for an LTS
[18:16] <zooko> kees, cjwatson: I updated this bug report to indicate that libcrypto++8 when built with g++ 4.4.1-3ubuntu3 fails its self-tests (by hanging indefinitely with high CPU load) and to ask:
[18:17] <cjwatson> sabdfl: in the meantime, I've put it in my file of "things to consider for UDS" notes
[18:17] <zooko> So, how did libcrypto++8 as built by g++ 4.4.1-3ubuntu3 pass its self tests? Or *did* it pass its self-tests before it went into Karmic?
[18:17] <sabdfl> ok thanks
[18:17] <kees> zooko: so, it's not a compiler regression?
[18:18] <kees> zooko: check in https://edge.launchpad.net/ubuntu/+source/libcrypto++/5.6.0-3/+build/1249032/+files/buildlog_ubuntu-karmic-i386.libcrypto++_5.6.0-3_FULLYBUILT.txt.gz
[18:18] <kees> zooko: (from https://edge.launchpad.net/ubuntu/+source/libcrypto++/5.6.0-3/+build/1249032)
[18:18]  * cjwatson grins at mvo's old branch for this
[18:18] <cjwatson> +        open(MAGIC_MARKER,"w").write("1")
[18:18] <mvo> heh :)
[18:18]  * mvo played nethack at that time
[18:19] <cjwatson> I did wonder :)
[18:19] <zooko> kees: look!  It passes the SHA validation test!  Wah.
[18:19] <zooko> kees: does the fact that you use sbuild make it easy or hard for you to reproduce the experiment of building with g++ 4.4.1-3ubuntu3?
[18:20] <cjwatson> zooko: did you also downgrade gcc-4.4, and the rest of the compiler suite?
[18:20] <cjwatson> zooko: I'm not sure that just downgrading g++-4.4 alone will be sufficient
[18:20] <zooko> cjwatson: so the current situation is -4ubuntu8 fails for me and for keys, -3ubuntu3 fails for me, but apparently -3ubuntu3 worked in that buildlog that kees just posted.
[18:20] <zooko> cjwatson: yes.
[18:20] <cjwatson> also worth looking at binutils
[18:20]  * zooko looks at binutils.
[18:21] <dpm> JontheEchidna, I've commented on the bug. pitti, as is there anything else to be done to move your suggested fix forward, i.e. open a separate bug, subscribe you on the original bug?
[18:22] <dpm> pitti, (re: kmail)
[18:22] <evand> sabdfl: it currently installs language support, but it doesn't do an apt-get update; apt-get --download-only upgrade
[18:22] <mvo> i
[18:22] <pitti> dpm: someone needs to prepare the package, check that it really works, and upload it to -proposed
[18:22] <pitti> that's pretty much it
[18:22] <zooko> How do I view tghe full history of builds and uploads of packages again?
[18:22] <doko_> cjwatson: any specific arch?
[18:22] <pitti> dpm: i. e. take a new po, put it into data/, build/test/upload
[18:23] <cjwatson> doko_: -> zooko
[18:23] <zooko> To figure out what version of binutils was used to build libcrypto++8 5.6.0-3
[18:24] <doko_> zooko: the build logs should include gcc and binutils versions
[18:24] <dpm> JontheEchidna, do you think you or someone from Kubuntu could do that ^?
[18:24] <JontheEchidna> That could be arranged, yes
[18:24] <cjwatson> zooko: https://launchpad.net/ubuntu/+source/libcrypto++ (that's indexed by source package name), "See full publishing history", pick version, click on appropriate architecture in builds column, follow "buildlog" link
[18:25] <zooko> doko: thanks
[18:25] <zooko> cjwatson: thanks
[18:31] <kees> zooko: hard to reproduce with sbuild (also, busy with other stuff at the moment)
[18:32] <zooko> kees: okay thanks!
[18:39]  * ccheney hates the kernel, heavy disk io still brings desktops down to being completely unusable
[18:39] <ccheney> every few seconds all my windows grey out for a while then start working again for a short time, cycle indefinite
[18:39] <Tm_T> ccheney: hmm, different scheduler helps or not?
[18:40] <ccheney> Tm_T: maybe, i hear the new con scheduler is supposed to help but i don't think that is in the karmic kernel (or is it?)
[18:40] <jdong> ccheney: that's not an IO scheduler :)
[18:40] <jdong> ccheney: deadline will prevent the greyout grinding
[18:40] <ccheney> jdong: ah, well then yea i need a useful io scheduler :)
[18:40] <jdong> but will cause more disk thrashing
[18:40] <jdong> ccheney: if ext3/4, mounting with data=writeback helps too
[18:40] <ccheney> jdong: ok
[18:40] <jdong> though it MAY lead to stale zombie data after a crash.
[18:40] <ccheney> heh
[18:41] <ccheney> so no real solutions to fixing it properly yet i suppose? :)
[18:41] <jdong> if you want to cast it in such dim light, sure! :)
[18:41] <ccheney> eg some sort of roundrobin disk io thing
[18:41] <jdong> that's what CFS is supposed to be.
[18:41] <jdong> it's just that your robin isn't as important as the non-gray robins ;-)
[18:41] <ccheney> the slices must be too large, heh
[18:42] <ccheney> there is some way to lower io priority for a particular process too right?
[18:42] <jdong> ccheney: I think the problem is when the previous slice triggers an expensive disk operation that must finish.
[18:42] <jdong> ccheney: i.e. hitting a journal barrier that forces 32MB of disk cache to be flushed before any further operations
[18:42] <ccheney> oh
[18:43] <jdong> ccheney: if you notice, it's usually *writes* that cause death
[18:43] <jdong> ccheney: there's also limitations such that fsync of a single file may cause a sync of the entire disk to take place.
[18:46] <mathiaz> cr3: checkbox 0.8.5 uploaded to karmic
[18:47] <mathiaz> cr3: can you mark the merge request as approved? https://code.edge.launchpad.net/~cr3/ubuntu/karmic/checkbox/0.8.5/+merge/13965
[19:39] <ccheney> grr iwlagn decided to eat 100% cpu on my box :-\
[19:40] <jdong> yay!
[19:40] <jdong> the last time I flipped the hw rfkill switch on my iwl3945 I had a similar experience
[19:40] <jdong> and lost the 4 virtualized servers too. whoops!
[19:41] <ccheney> i was just using my system as normal when it decided to do it to me
[19:41] <ccheney> i'm in the process of compressing a vm for reuse later and its now heating up my system a lot
[19:41]  * ccheney wouldn't be surprised if he saw the 100C like mvo after this crap
[19:42] <ccheney> i'm not sure how to get it to show me the temperature though
[19:43] <ccheney> oh i found it, 88C thats pretty bad
[19:44] <jdong> eep :)
[19:44] <ScottK> I've had to run my laptop sitting on a bag of ice before.
[19:44] <ScottK> You can't leave it on indefinitely though because of condensation.
[19:44] <hyperair> didn't condensation form?
[19:44] <hyperair> ahah
[19:44] <zooko> I want a hermetically sealed computer.
[19:44] <ScottK> You take it off and then the heat causes it to evaporate
[19:44] <hyperair> ccheney: the newer kernels don't get the iwlagn-100% issue.
[19:45] <hyperair> at least, not the one i'm running
[19:45] <hyperair> which is .32
[19:45] <hyperair> and my computer auto-poweroffs at somewhere around 80
[19:45] <ccheney> hyperair: newer than 2.6.31-14.48 ?
[19:45] <jdong> can of dust-off
[19:45] <jdong> spray it upside down
[19:45] <hyperair> ccheney: 2.6.32-rc5.
[19:46] <jdong> I've had success cooling dangerously overheated motors that way too
[19:46] <ccheney> hyperair: ah well i'm getting 100% iwlagn on the version i mentioned above
[19:46] <hyperair> ccheney: i compile my own kernels, since i need the PHC patch or my notebook will blow up when i compile things.
[19:46] <jdong> it sprays on solidified-subliming propellant which is much colder than ice
[19:46] <ccheney> crap its up to 89C now
[19:46] <hyperair> ccheney: rmmod iwlagn
[19:46] <jdong> hyperair: watch that panic.
[19:46] <hyperair> jdong: what what panic?
[19:46] <jdong> hyperair: rmmodding a misbehaving module
[19:46] <jdong> :)
[19:46] <hyperair> jdong: no, i've done it before.
[19:46] <hyperair> it works very well
[19:47] <hyperair> rmmod iwlagn and all associated modules..
[19:47] <ccheney> hmm that seems to magically have worked, but i am surprised since it was giving lots of backtraces
[19:47] <hyperair> iwlagn, iwlcore, {mac,cfg}80211
[19:47] <jdong> I'm surprised too
[19:47] <hyperair> yeah i was surprised too =\
[19:47] <ccheney> hyperair: thanks
[19:47] <jdong> typically when a ko is misbehaving, rmmodding it is a suicide attempt :)
[19:47] <hyperair> but the solution worked flawlessly every time
[19:47] <ccheney> already down to 80C :)
[19:47] <jdong> nice
[19:47] <jdong> good to know, hyperair
[19:47] <hyperair> jdong: seriously? i haven't seen a rmmod panic me =\
[19:47] <jdong> hyperair: wow
[19:47] <jdong> you are one lucky guy!
[19:48] <ccheney> hyperair: i have but i don't have problems often enough to have had it happen in a few years
[19:48] <ccheney> i just remember it crashing often years ago so didn't even try
[19:48] <hyperair> jdong: heh call me inexperienced ;-)
[19:48]  * hyperair gets tonnes of backtraces in dmesg
[19:49] <hyperair> acpi stuff and the like
[19:49] <hyperair> heh
[19:49] <hyperair> but i go on hibernating/resuming (using tuxonice) without any issue =p
[19:51]  * jdong has an amusing amount of apparmor chatter in dmesg
[19:51] <jdong> and should probably invest in an auditd.
[19:51] <hyperair> auditd eh
[19:51] <hyperair> i should look into that sometime
[19:54]  * ajmitch is glad it's just a website that's causing 100% CPU usage, and not a kernel module
[19:55] <hyperair>  lol
[19:55]  * hyperair has a laggy bluetooth mouse
[19:55] <hyperair> under load anyway
[19:56] <ajmitch> I should have tested wireless on my laptop before kernel freeze, since it had problems with hard lockups in jaunty
[19:56] <hyperair> meh
[19:56] <hyperair> why didn't you?
[19:56] <ajmitch> because I never use it
[19:56] <hyperair> .__.
[19:56] <ajmitch> it's yet another intel driver :)
[19:56] <hyperair> lol
[19:57] <hyperair> for some reason, eventhough we always go around advocating intel graphics and intel wifi, it ends up backfiring on us =.=
[19:57] <ajmitch> yes, I just checked & it's the iwlagn driver ccheney was talking about
[19:58] <hyperair> hah
[19:58] <hyperair> i remember intrepid having issues
[19:58] <hyperair> but it was fixed
[19:58]  * hyperair thinks intrepid was the most rock solid release ever
[20:02] <jdstrand> ttx, soren: does bug #460271 factor into euca in any way? I can fix this and upload today or do an SRU along with bug #453335 after the kernel gets updated
[20:02] <jdstrand> ttx, soren: perhaps a better question is-- do you want me to upload a fix asap, or is an SRU ok?
[20:03] <ttx> jdstrand: at this point I'd say SRU
[20:03] <jdstrand> ttx: that is what I was thinking. it's a regression but not a common use case afaict
[20:03] <jdstrand> ttx: though definitely SRU worthy
[20:04] <ttx> jdstrand: you can target to 9.10-updates so that we track it
[20:06] <ScottK> ttx: karmic-proposed is open for uploads now.
[20:07] <ttx> ScottK: even better :)
[20:07] <jdstrand> ttx: already done
[20:07] <ScottK> We've already got one in the queue.
[20:40] <zooko> Isolated the regression in binutils https://bugs.launchpad.net/ubuntu/+bug/461303
[20:41] <jonathan__> anyone aware of a way around the password prompt I get every time I startup and click my RAID array?
[20:42] <ScottK> jonathan__: This isn't a support channel.  #ubuntu or #ubuntu+1 for support
[20:42] <ScottK> doko_: ^^^
[20:42] <ScottK> (the binutils)
[20:43] <kees> zooko: if you have the .dsc files for 2.19.91.20091006-0ubuntu1 and 2.19.91.20091014-0ubuntu1 you can use "debdiff" to see the differences in the code
[20:43] <kees> (and diff.gz and orig.tar.gz)
[20:43] <zooko> kees: thx
[20:43] <zooko> holding 9 day old baby atm
[20:43] <kees> woo! early computer induction.  :)
[20:44] <jdstrand> excellent getting the baby to learn debian packaging at such a young age
[20:45] <cjwatson> zooko: I put a link to the diff in the bug
[20:45] <cjwatson> LP automatically generates diffs between successive versions of packages
[20:48] <zooko> that's a big diff
[20:50] <zooko> i'm out of my depth looking at this diff
[21:01] <zooko> examined the diff with minimal comprehension and came up wit three possibly relevant patches:
[21:01] <zooko> https://bugs.launchpad.net/ubuntu/+bug/461303
[21:03] <kees> zooko: if you want to isolate it further, you can build current binutils with each of those chunks reverted to see which causes it.
[21:03] <kees> zooko: also, it'd be cool if a more minimal test-case could be found besides "build libcrypto++"  :)
[21:03] <kees> zooko: however, this is not an area I'm familiar with.  doko may know more, but he's asleep
[21:04] <zooko> i could work on that smaller test case.
[21:04] <zooko> after a nap...
[21:04] <kees> zooko: does it hang on i386 too?
[21:15] <ion> keybuk: It seems the ‘waiting for mounts’ notification has disappeared.
[21:38] <zooko> kees: no idea
[21:38] <zooko> I know that there is different ASM in Crypto++ for x86 vs amd64.
[22:09] <simon-o> Hi, could anybody take a look at bug 414057 and tell me what to do next? I guess it's already too late for karmic...
[22:15] <cyphermox> simon-o, maybe i'm wrong but i do not think there is anything more you need to do, since ubuntu-main-sponsors is subscribed; other than bug someone to sponsor the fix :)
[22:16] <TheMuso> Its probably too late for karmic final, it will have to be an SRU I'd say.
[22:16] <doko_> zooko, kees: I'm back, knowing the exact chunk would be nice. to speed up the build, use DEB_BUILD_OPTIONS="nostat nomult nogold parallel=4" ...
[22:17] <simon-o> cyphermox, TheMuso: ok, thanks. I don't know if it's "worth" an SRU because it build fine on the "official" build machines
[22:17] <cyphermox> simon-o, i was about to point that out
[22:17] <simon-o> the problem is, when people try to build it with debuild
[22:18] <simon-o> cyphermox: I'll just try it again with lucid, because I think this should be fixed somehow
[22:18] <zooko> doko: I just now was asked to help my 5 year old carve a pumpkin.
[22:18] <TheMuso> But if its built fine on the build machines, why would they want to rebuild it? Sure it needs fixing, but for the final release of karmic, the latest package revision is available, which is good enough.
[22:19] <simon-o> TheMuso: That's exactly what I thought
[22:22] <cyphermox> simon-o, pbuilder / sbuild shouldn't complain if someone tries to rebuild graphviz
[22:23] <simon-o> cyphermox: no they don't. sorry if I was unclear here. This is just for people like the one who reported the bug who do a apt-get source and then try it with debuild. If you have tcl8.4 this will fail, which is a bad experience.
[22:23] <simon-o> pbuilder and sbuilder are fine
[22:25] <TheMuso> Straight out debuild is likely not to work purely because the user doesn't have the build dependencies installed.
[22:25] <simon-o> TheMuso: ok, then the do a apt-get build-deps first ;)
[22:25] <TheMuso> Yes I know.
[22:28] <cyphermox> simon-o, it's a nice fix though
[22:28] <cyphermox> simon-o, i saw you made fixes to a couple of FTBFS bugs today, it was very interesting to look at it helps me understand this stuff :)
[22:29] <simon-o> cyphermox: thanks. Yes I did fix some FTBFS today, but there are many more open :(
[22:30] <cyphermox> simon-o, I'm not the best at C, but perhaps I can help -- where do you get your list?
[22:31] <simon-o> cyphermox: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html but this list is fairy old
[22:32] <simon-o> Stefan Potyra sent out a list to ubuntu-devel explaining some of the failures
[22:32] <simon-o> cyphermox: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-October/000626.html
[22:37] <simon-o> cyphermox: If you get stuck, just ping me here on IRC or vial Email (http://launchpad.net/~simono)
[22:38] <cyphermox> simon-o, sure.
[22:44] <soren> kees: Err.. https://bugs.launchpad.net/bugs/460906   I'm usually pretty imaginative, but I'm completely at a loss with this one.. I cannot come up with a single use case where I'd want the snapshot linked from /dev/disk/by-uuid/. :) what gives?
[22:49] <spstarr> erm, is grub2 broken ?
[22:49] <spstarr> i put a custom kernel, and now it says 'could not read file' press any key to continue
[22:49] <spstarr> yet the vmlinuz and initramfs are fine?
[22:52] <spstarr> hmm
[22:52] <spstarr> 'mountall' changed again
[22:54] <kees> soren: there is only one origin, but multiple snapshots possible.  therefore, the uuid should always point to the "real" partition.
[22:56] <soren> kees: Exactly!
[22:56] <soren> kees: but it doesn't, and Scott says that's the way you want it.
[22:57] <soren> kees: the symlink point to *the snapshot*.
[22:58] <kees> oh, er
[22:58] <kees> well, I just argued your point, then.  ;)
[22:58] <kees> let me think...
[23:00] <kees> soren: ^^
[23:02] <soren> kees: I can think of at least one good reason why it should point to the origin, at least. Some of us use UUID based mounting for everything, including lv's. If I make a snapshot of, say, /var and reboot, I'm sure I will be a quite unhappy camper with a read-only /var. I've never hit this, because my snapshots are usually quite short-lived (the time it takes to make a backup).
[23:02] <kees> you can mount snapshot origins while they have snapshots open, I thought?
[23:03] <kees> (yes, you can)
[23:04] <soren> Sure.
[23:05] <soren> kees: I'm not sure where you're going with that, though?
[23:05] <kees> soren: what did you mean by the "read-only" bit?
[23:05] <soren> kees: snapshots are read-only.
[23:05] <kees> no they're not.
[23:05] <soren> kees: If my fstab references the uuid, I will mount the snapshot of /var, instead of the origin.
[23:05] <soren> They're not? Hmm... I'm not sure if that makes it better or worse, really :)
[23:06] <soren> Oh, right.
[23:06] <soren> Of course they're not.
[23:06]  * soren .oO{ sbuild }
[23:06] <kees> :P
[23:06] <kees> so, opposing logic would be "snapshots are more interesting than origins" so they should get the UUID.
[23:07] <soren> kees: Anyhow, if I create a snapshot for some reason, I still want my the origin mounted if I reboot.
[23:07] <kees> but I need to dig up my reason for this...
[23:07] <soren> Right. And I've had a hard time...
[23:07] <soren> right, exactly.
[23:11] <soren> kees: Either way, can you update that bug, please?
[23:11] <kees> soren: I did, yes.
[23:11] <wild_oscar1> hey slangasek, there?
[23:11] <soren> kees: Apparantly, you're authoritative, but if my vote counts at all, I'd like for the symlink to point to the origin.
[23:11] <wild_oscar1> I tried editing /etc/init/mountall.conf again, but it gives me the "unknown stanza" on the line that says "pre-exec script"
[23:13] <kees> soren: so, I introduced the links due to bug 117225, which I'm re-reading now
[23:13] <cjwatson> well, 'pre-exec script' *should* be unknown, that's an error
[23:13] <cjwatson> perhaps that was meant to be pre-start or pre-stop?
[23:13] <wild_oscar1> cjwatson: I don't know
[23:13] <wild_oscar1> I was being guided by slangasek
[23:13] <wild_oscar1> regarding this bug https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/455045
[23:14] <wild_oscar1> he suggested attaching the /var/log/syslog
[23:14] <wild_oscar1> after editing mountall.conf with
[23:14]  * soren calls it a day (again)
[23:14] <wild_oscar1> pre-exec script initctl log-priority debug end script
[23:14] <wild_oscar1> (3 lines)
[23:14] <cjwatson> wild_oscar1: I guess some of that was in a private conversation, not in the bug
[23:14] <slacker_nl> ion: you there, think we spoke a couple of days ago about usplash?
[23:15] <cjwatson> wild_oscar1: but I think that's almost certainly a typo for 'pre-start script'
[23:15] <wild_oscar1> cjwatson: yes, here on irc
[23:15] <cjwatson> (or possibly for 'pre-start exec initctl log-priority debug' on a single line; either would work)
[23:16] <ion> slacker_nl: Yeah
[23:17] <slacker_nl> ion: i still get the messages
[23:18] <kees> soren: ah-ha, my original bug was about /dev/mapper/* entries, not by-uuid symlinks.
[23:18] <slacker_nl> only two, but still see them
[23:19] <ion> slacker_nl: They should disappear when the mount is successful. Do they not?
[23:19] <wild_oscar1> cjwatson: I shall try with pre-start
[23:20] <slacker_nl> ion: i don't see them in the splash, but I do see them before that
[23:20] <slacker_nl> ion: but not as many as before
[23:20] <wild_oscar1> cjwatson: does it influence where the line is put in the file?
[23:21] <wild_oscar1> ie, in the beggining, in the end
[23:21] <cjwatson> no
[23:21] <cjwatson> well, don't put it in the middle of a script stanza :)
[23:21] <cjwatson> I'd put it before the line with just 'script' on it
[23:24] <slangasek> cjwatson: <smack> right, sigh
[23:27] <ion> slacker_nl: What do you mean by “before that”?
[23:28] <slacker_nl> ion: before the splash (the kubuntu logo) I get the messages
[23:30] <wild_oscar1> cjwatson: thanks, will try 'pre-start exec initctl log-priority debug' in the end of the file
[23:30] <slacker_nl> ion: i'll make some pictures of it tomorrow - going to bed now
[23:39] <wild_oscar1> well, I do have the syslog attached to https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/455045
[23:40] <wild_oscar1> if someone has any clue why installing nfs-kernel-server breaks a lot of init scripts (dovecot, postfix don't startup, nor is portmap started)