=== yofel_ is now known as yofel === james_w` is now known as james_w [01:06] Can anyone shed a bit of light on https://bugs.launchpad.net/ubuntu/+source/wine/+bug/460596 ? [01:06] Launchpad bug 460596 in wine "package wine 1.0.1-0ubuntu7 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] [01:08] wine.postinst has this line that I suspect is erroring: service procps start === porthose is now known as porthose|afk [02:13] * ccheney thinks something is broken with his mac address on his new pc, its 00:00:00:00:00:30 [02:14] lol [02:14] * ccheney probably should contact tech support for his board to see what is going on === bjf is now known as bjf-afk [05:14] pitti, can you determine why the retracer hasn't ran on https://bugs.edge.launchpad.net/mythbuntu/+bug/452508/+index ? [05:14] Error: This bug is private [05:14] pitti, it's about 10 days old [05:14] it's a PPA build, but we (attempt to) build them with debug symbols === YDdraigGoch is now known as Guest72665 [06:05] kees: ping [06:08] 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:08] Launchpad bug 447197 in wine1.2 "package wine 1.0.1-0ubuntu6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,In progress] [06:12] Good morning [06:18] YokoZar: That would wipe my later sysctl rule. Look at what the upstart or init script tries to do [06:19] 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] I haven't looked at it much should probably get out of bed first :) [06:26] 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] but it contains no restart instructions (not too familiar with upstart syntax at the moment) [06:29] 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] Good morning [06:43] Good morning pitti :) [06:43] apw: oh, kerneloops catches those? [06:43] hi folks [06:58] hey YokoZar, how are you? [06:59] 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] good morning [07:11] superm1: 452508> it's not an ubuntu bug, but an upstream one; retracers can only deal with ubuntu packages === Whoopie_ is now known as Whoopie === dholbach_ is now known as dholbach === highvolt2ge is now known as highvoltage === tkamppeter_ is now known as tkamppeter === Guest72665 is now known as YDdraigGoch [08:44] pitti, hi [08:44] hey tkamppeter [08:45] 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] Should we take it into Karmic? [08:46] tkamppeter: should be done as SRU now, if it's important enough [08:46] OK, so I leave it alone until SRU can be posted. [09:04] keybuk: O hai. I just sent you an email. [09:04] ion: what was your e-mail? [09:05] hey pitti is apport going to be enabled following release this time? [09:05] keybuk: The content of the message? Or do you mean my address? [09:05] apw: no, already disabled (right after RC) [09:06] ion: the content of the message [09:06] pitti, thanks ... so we don't really need to worry about this kerneloops issue then as such [09:06] oh, yes [09:06] I saw that this morning [09:07] 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] keybuk: An RFC-ish patch i don’t expect to make it into mountall as-is at least. :-P [09:08] Keybuk: hi, mountall / usplash still not uploaded? [09:08] ion: I just figured that the overflow would not be "that bad" [09:08] True [09:08] slangasek: in PPA and being tested [09:08] 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] apw: right, it doesn't seem release critical to me [09:09] pitti, ack and thanks [09:09] 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] slangasek: as soon as I've done a reboot test myself [09:09] ok, thanks [09:10] which I would be doing, if you weren't bugging me about it ;) [09:56] mdke: there? [09:56] 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] mdke: bot? [09:57] mdke: check out 460225 ... the index.html is not in ubuntu-docs anymore? [09:58] 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] 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 [09:59] not a regression I think we should care about, it's ia32-libs [10:00] hmm ... still ia32libs wrestline [10:01] * TheMuso is just glad he doesn't have to touch it that often. [10:01] whatever helps to get ia32libs updated is much better than a fltk regression [10:01] s/just// [10:02] YokoZar: ^^ [10:02] asac: hrm? ia32-libs was /already/ updated; are you saying you care about 32-bit fltk? [10:02] no [10:02] slangasek: i just thought it wasnt updated and this was still discussion about something blocking it ;) [10:02] slangasek: a few packages other than fltk were freshened in the latest update, btw [10:03] I don't see the harm it does by including it, so why not [10:03] 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] plague [10:03] including libs that no one needs makes it harder to maintain [10:04] i am more scared bout bug 460225 that says that we have no /usr/share/ubuntu-artwork/home/index.html on CD :/ [10:04] Launchpad bug 460225 in ubufox "Firefox v 3.5.3 Home Page Error" [High,Triaged] https://launchpad.net/bugs/460225 [10:04] asked on -testing to get someone verify it [10:05] slangasek: I thought the goal was to get rid of all of them next release using the magic of multiarch or something [10:06] 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] 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] 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] Yes, a security issue in fltk would force an ia32-libs update. [10:08] but it's already forcing that update onto jaunty and intrepid and hardy because they have fltk too [10:08] pitti: the apport assert catching stuff appears to be working nicely for upstart - I'm getting bugs \o/ [10:08] (in ia32-libs that is) [10:08] slangasek: hrm ok, I'll see if I can reproduce, it could be transient. [10:08] (from the code that spawns services sadly, not init itself yet) [10:09] 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] because it's a grotesque CD-size source package [10:10] 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] It's at that point where updating it is basically "leave it on overnight" though [10:10] 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. === Tonio__ is now known as Tonio_ [10:11] 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] YokoZar: Ouch. [10:20] Keybuk: did you build-test this mountall upload? Makefile.in has vanished [10:20] slangasek: I test built the code [10:20] who knows what bzr-builddeb did [10:20] can you reject them both (usplash probably had the same issue) [10:20] bzr-builddeb exported the package as it existed in the bzr repo [10:20] oh, how silly [10:20] yes, will reject [10:21] was the usplash one ok? [10:22] can I upload again now? [10:23] Keybuk: yes, you can reupload [10:23] haven't looked at usplash yet, checking now [10:24] lool: bug #456523 looks like gtk-doc-tools need a depenency on emacsen-common ? (see comment 5 in the bug) [10:24] Launchpad bug 456523 in gtk-doc "Distribution Upgrade to karmic freezes on gtk-doc-tools" [Undecided,Confirmed] https://launchpad.net/bugs/456523 [10:25] usplash looks ok, looks like it just dropped the .bzr [10:25] the mountall bzr tree is a bit "odd" [10:26] usplash looks ok> confirmed [10:26] I should repackage mountall like upstart [10:27] where the "upstream" repo has the code [10:27] but the "ubuntu" repo is buildable (with libnih merged in, etc.) [10:27] or just make the ubuntu repo buildable [10:27] have a chat with james_w, see what went wrong [10:27] nothing went wrong :) [10:28] no reason to expect bzr bd to run ./autogen.sh for you [10:28] heh [10:28] slangasek: yeah, it's the whole "you don't put Makefile.in in bzr" thing [10:28] Keybuk: I suppose I should reject the older mountall upload? [10:31] 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] lifeless: have you fixed the bzr bug yet where it screws up timestamps? [10:31] slangasek: yeah, though it's an interesting case that --native *might* need autoreconf running [10:32] it's almost a would-be-nice that if there's configure.ac but not configure, run autoreconf [10:32] could put it in debian/rules [10:32] not make bd guess [10:32] sure, but then you'd need a build-depend [10:32] configure should be in the tar.gz [10:32] could do if [ ! -e ./configure ] in debian/rules :) [10:33] slangasek: doesn't remove the build-depend need [10:33] bzr bugs notwithstanding, it should be ok to put autofoo stuff in the bzr repo now [10:33] it works for upstart [10:33] and libnih needs to be in mountall too ;) [10:33] sure it does, if the code path is never hit during a normal package build [10:33] (bzr still has the bug where it doesn't apply the same timestamp to all files touched during a checkout/update) [10:34] I build-dep on autoconf as a matter of course [10:35] Keybuk: we should make that a higher priorty bug with the new focus [10:35] I make packages build-dep on autoconf when they use scons [10:35] slangasek: evil :) [10:35] heh [10:40] Keybuk: month's worth of libnih updates - bah [10:40] month's worth? [10:40] innit? [10:40] I was going by timestamps in the debdiff [10:40] are there actual code changes there? [10:40] lots [10:41] really? [10:41] bzr diff said it was the same [10:42] let me check myself [10:42] mdebdiff -s karmic *.dsc | filterdiff -i '**/nih**/**'|wc -l [10:42] 2605 [10:43] huh, I honestly don't know why those changes *aren't* in 0.2.5 [10:43] but most of them aren't even in bits that mountall touches [10:44] how safe are the ones that are? :) [10:44] oh, utterly safe [10:44] they're all bug fixes [10:44] valgrind errors [10:44] this is the same code as upstart is using [10:44] * slangasek nods [10:44] (you're sure of that part, right? :) [10:44] very sure [10:45] because the patch includes the glibc __abort_msg thing [10:45] that means apport catches nih_assert() [10:45] and I've definitely been getting those from Upstart [10:45] * slangasek nods [10:46] and the patch includes the cross-compiling support [10:46] which cjwatson *really* wants ;) [10:48] I need to fix the mountall repo clearly [10:48] let me do that now [10:50] * Keybuk tries to remember what bzr dark magic he did to make the upstart tree [10:53] Keybuk: please share that wisdom about the dark magic with me [10:54] mvo: I found a way to join the history of the two repositories together [10:54] so that "bzr merge lp:upstart" *and* "bzr merge lp:libnih" worked [10:54] with the resulting repo containing files from both [10:55] Keybuk: bzr merge-into [10:55] its aplugin [10:55] lifeless: which didn't work [10:55] neither did join [10:55] merge-into should have [10:55] your other option is merge -r 0..-1 [10:55] nice, is there a way to track a merge-into branch (maybe even automatically?) [10:56] lifeless: right, I think I did the latter, then fixed up some renames and removed some files [10:56] merge-into just automates the management of the root dir rather than getting conflicts on NEWS etc [10:56] lifeless: that's the bit it screwed up on! :) [10:57] :( [10:57] did you file a bug? [10:57] probably, yes [10:57] I usually do [10:58] or I might have msg'd the guy [11:01] slangasek: ok, the mountall repo is now directly buildable ;-) [11:05] * asac hugs kees (459199) [11:07] asac: Debian policy is not broken and will not be changed; Debian policy is older than your 10 year UID. :) [11:08] slangasek: really? [11:08] kees said it was an ancient debian UID [11:08] 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] Launchpad bug 460225 in ubufox "Firefox v 3.5.3 Home Page Error" [High,Invalid] https://launchpad.net/bugs/460225 [11:08] asac: he's mistaken [11:08] slangasek: i thought my uid was also created using debian [11:08] but i could be wrong [11:09] well [11:09] slangasek: the policy claim was more or less a joke ;) [11:09] i think it should be done by checking whether an account is a valid log-in account [11:09] 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] slangasek: correct [11:10] asac: I agree with you that gdm/ck-history shouldn't hard-code the uid policy, though :) [11:11] too long ago for me to tell for sure ... [11:11] it was considered OK in the sense that we were happy to accept such UIDs, though [11:11] just not create them [11:11] * slangasek nods [11:11] this is at least in part because Ian had UID 100 hanging around from a previous installation [11:11] * slangasek grins [11:11] haha [11:11] i think 100 is solaris [11:11] yeah, my colo server is happily running with a dozen users with UIDs numbered from 500 [11:11] at least that what i got when googling for random UID bounds [11:11] and it's not Red Hat ;) [11:11] not in this case, but sure [11:14] TheMuso: rejecting this brasero upload, SRU please [11:19] slangasek: Ok will pass that onto Robert. [11:19] mvo: Looking [11:23] mvo: This is odd [11:23] 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] mvo: It seems to me the dh_installemacsen snippet should also check whether emacsen-common is configured rather than for mere availability [11:25] mvo: There are a bunch of other packages with that snippet even in the default install [11:26] mvo: Hmm no, not that many sorry, too large grep [11:27] mvo: However I have packages "global" and "lbdb" on my system which have the same snippet and no dep [11:28] 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] zul: bug #451314> in what sense is this making zlib "shared"? the package already depends on zlib1g [11:34] Launchpad bug 451314 in php5 "PHP 5.2.10 zlib bug remains for 32bit" [Medium,Confirmed] https://launchpad.net/bugs/451314 [11:40] mvo: Happy if you can test emacsen-common_1.4.19ubuntu1~dooz1 in my PPA [11:41] slangasek: in the sense that zlib.so is not statically built into php itself [11:43] zul: oh. why does that cause this bug? [11:44] 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] slangasek: also things like pear looked like it wasnt able to unpack any packages it was downloading [11:45] 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] slangasek: it shouldnt regress anything [11:45] (whine, all the bad memories) [11:46] zul: explain, please [11:47] slangasek: when it was not shared we were having problems like 432291 and 439407] [11:47] bug 439407] [11:47] bug 439407 [11:47] Launchpad bug 439407 in php5 "Abort class-pclzip.php : Missing zlib extensions (dup-of: 451405)" [Undecided,Confirmed] https://launchpad.net/bugs/439407 [11:47] Launchpad bug 451405 in php5 "zlib extension missing in php5 karmic " [Undecided,Confirmed] https://launchpad.net/bugs/451405 [11:48] bug 432291 [11:48] Launchpad bug 432291 in php5 ""Fatal error: Call to undefined function gzopen()" on php5 5.2.10.dfsg.1-2ubuntu3 (dup-of: 451405)" [Undecided,Won't fix] https://launchpad.net/bugs/432291 [11:50] slangasek: if you want you could reject the upload and I could write a better changelog entry for it [11:51] zul: it's faster to come to a conclusion here [11:52] anyway, the above doesn't prove it won't regress in exactly the way I've described === lamont`` is now known as lamont [11:57] 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] zul: I see nothing in the php5 packaging that would ensure zlib module autoloading [11:58] 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] slangasek: Hmm, I just bisected upstream and observed they had a fix which does actually work :-/ [11:59] Also, the triggering 'multibyte sequence' is in fact a tab character [11:59] zul: (gzopen() is still broken, yes - but that doesn't mean we should regress other code that doesn't need gzopen()) [11:59] maxb: yep - but the patch makes no sense; if it fixes anything, it appears to do so as a side effect? [11:59] (unless something is passing &cur_len later... let's see) [12:00] oh - indeed something is [12:00] ok, that makes sense now [12:00] 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] cjwatson: https://bugs.launchpad.net/lupin/+bug/460740 [12:01] Launchpad bug 460740 in lupin "ext4 not supported for loopback" [Undecided,New] [12:01] slangasek: php does the loading for you not the packaging [12:02] zul: when and how? How does it know you want the zlib.so loaded? [12:03] 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] slangasek: its done through the php.ini file or loaded dynamically [12:04] in zlib's case i believe its done dynamically [12:06] Really? When did it start doing this? [12:06] (loading extensions dynamically, that is) [12:06] soren: when its built as shared [12:07] 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] 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] maxb: if not, looks good for an immediate SRU [12:08] fair enough [12:08] 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] zul: You don't need to look up when it started doing it. I'm just surprised, but if you're sure... [12:08] soren: its done it for a while now [12:08] slangasek: ok then [12:09] zul: so if Till's var_dump() test works with the package you uploaded, I'm convinced [12:09] 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] slangasek: sure Ill add it to the bug report [12:10] Kano: committed, thanks [12:11] good [12:11] just tested a new grub yesterday and it did not want to boot from ext4 [12:12] grub2 is really cool as it supports loopback [12:13] now $var works, not only ${var} [12:14] zul: ok, thanks [12:14] http://paste.debian.net/49971/ [12:14] example [12:24] 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:24] Launchpad bug 410234 in ubuntu-translations "Xsane menu entry is not translatable" [High,In progress] https://launchpad.net/bugs/410234 [12:24] Launchpad bug 457632 in ubuntu-translations "Desktop entry needs the X-Ubuntu-Gettext-Domain key" [High,In progress] https://launchpad.net/bugs/457632 [12:37] cjwatson: if you feel like a C-related challenge, could you read through bug 436758 (esp. my most recent comment) [12:37] Launchpad bug 436758 in ubuntu-release-notes "upstart doesn't boot on sparc" [Undecided,Fix released] https://launchpad.net/bugs/436758 [12:37] (when my most recent comment shows up) [12:39] njpatel: was reviewing this netbook-launcher change; isn't this solution racy, assuming that waiting 2 seconds is sufficient? [12:39] lool: ^^ let's discuss here === kenvandif is now known as kenvandine [12:42] I'm trying to debug a suspend issue on my laptop. Can anybody point me to the best channel for expertise on this? === rmcbride_ is now known as rmcbride === mtrudel_ is now known as cyphermox [12:45] 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] hgomersall: #ubuntu or #ubuntu+1 , depending on what version of Ubuntu you're running [12:47] Keybuk: should I add a check sparc into u-m and warn/error on upgrade ? or do expect a fix very soon? [12:48] Pici: its karmic, is that +1? [12:50] mvo: it's in the release notes [12:50] "sparc is fail" [12:51] hgomersall: yes [12:51] Pici: thanks! [12:56] 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] 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] long long> there are archs that require alignment greater than the word size? === MacSlow is now known as MacSlow|lunch [12:57] hi, sparc [12:58] according to some random document I found on sun.com, yes [12:58] heh [12:58] Just checked svn log. t@h had close to realtime rendering since 03-2007 at least... [12:58] oops, sorry [12:58] http://docs.sun.com/app/docs/doc/819-3196/6n5ed4hm7?a=view [12:58] cjwatson: not sure [12:58] let me check [12:59] Keybuk: that would be my interpretation, and it explains why aligning on 24 rather than 20 would fix things [12:59] (I don't think -m64 matters, don't we build sparc32 userspace?) [12:59] cjwatson: because 24/8 is 3 [13:00] * Keybuk wonders what he uses that includes a long long [13:00] I don't have a full list of alignment requirements; long long may not be the only such [13:00] so if you have a structure that contains a 8-byte alignment word [13:01] would that, itself, be 8-byte alignment? [13:01] it must be aligned such that the 8-byte alignment member is aligned appropriately [13:02] but alignof for a struct with a long long doesn't work ;) [13:02] it says 4 [13:02] it may well be done with padding [13:03] oh, padding wouldn't work [13:03] can't be reliably done with padding unless the alignment of the struct itself is enforced [13:03] yeah [13:03] oh, sorry, I'm a numpty [13:03] how can I get quilt to apply a patch only on a specific architecture? [13:04] Riddell: dynamically construct your series file via debian/rules [13:04] right, if you have something 8-byte aligned at the front of the structure [13:04] Riddell: with "series" you can't AFAIK; call quitl in debian/rules or use dpatch :) [13:04] or sometimes in the structure (if it can't be solved with padding between elements) [13:04] then yes, the alignof does return 8 [13:04] so this would only affect certain structs [13:05] hmm, ok, I'll work out another way [13:05] the C spec suggests that double is guaranteed to be the largest alignment [13:06] (from a footnote to the definition of malloc) [13:06] ooh [13:06] Riddell: what about applying it all the time and use #if defined(__sparc__) or so? [13:07] cjwatson: always guaranteed? [13:07] pitti: it's a cmake file, not sure how to get cmake to do that [13:07] 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] actually sorry it's a footnote to sizeof [13:08] oh, bah, I'm misreading! [13:08] so __alignof__ (double) * ((sizeof (NihAllocCtx) - 1) / __alignof__ (double) + 1) [13:08] ? [13:08] no, I missed a bit in the example [13:08] oh [13:08] * cjwatson reads some more [13:09] but yeah, I see that it must be aligned to the largest possible alignment [13:09] because what follows it must be aligned [13:09] so the problem is finding the largest possible alignment [13:10] glibc's malloc just does 2*sizeof(size_t) [13:11] 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] I'd assume long double would be the largest possible alignment of the standard types [13:11] so you probably want to use the latter [13:11] cjwatson: yeah was just reading that exact code [13:12] I'm going to guess (possibly unwisely) that there isn't a better way or glibc would be using it :) [13:12] 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] cjwatson: we could burn Sun to the ground [13:12] njpatel: Shall we count them in a log message and use that approach if it's only called once? [13:12] lool: the concern I have is not with delay, it's with 2 sec not being long /enough/ [13:13] slangasek: I kind of agree with you as I have seen the interface load really slowly in virtualbox [13:13] 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] 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] lool: I can create some debs in a few minutes and ask jamie to test [13:16] njpatel: I don't think I understand what you mean about skipping handlers [13:17] 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] that would get rid of the g_timeout_8 [13:18] g_timeout_add_seconds* [13:20] njpatel: ah, ok [13:26] 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] cr3: I checked updated installation of Karmic. Checkbox strings are translated all but those with / [13:30] 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] cr3: That's nice. so are you going to ask for a ffe? or you mean after the release. [13:32] primes2h: ffe [13:32] can anyone explain me why ubuntu uses 1500 as default mtu? most websites does not allow mtu up to 1492 :( [13:33] cr3: Great. Thank you very much. Tell me if you need some feedback. :) [13:34] caio: I don't believe we do; we accept the MTU set by your DHCP server [13:34] caio: so, if you run the DHCP server, reconfigure it; otherwise, complain to your ISP [13:36] What triggers configuration of the loopback device? [13:38] soren: /etc/init/networking.conf [13:38] slangasek: Really? It used to be brought up by S40networking? [13:38] That late? [13:38] cjwatson: only strange, because a laptop with windows wasn't affected with this mtu problem [13:39] soren: late? When else would it have been brought up (and why)? [13:39] maybe windows already configured with 1492 instead of automatic mtu? [13:39] slangasek: rc2.d/S40 just seems late for something like that. [13:39] cjwatson: slangasek: mdz: I'm here now; do we still need assistance with the iscsi-on-root issue? [13:39] soren: it wasn't in rc2 [13:40] Oh. Oh, right. [13:40] * soren facepalms [13:40] my bad. [13:40] kirkland: I believe you know everything I do about the current status [13:41] slangasek: i was afraid of that... okay, i'll go reproduce the issue [13:44] 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] and thus triggers runlevel 2. [13:44] But networking might still be waiting for udevtrigger to finish, right? [13:45] Does udevtrigger block at all? [13:45] I forget. [13:46] soren: udevtrigger does what it says on the box^W^W^W in /etc/init/udevtrigger.conf [13:46] bryce__: hi there, let me know when you have a moment to follow up on bug #427932 [13:46] Launchpad bug 427932 in checkbox "[MASTER] Karmic alpha: Checkbox cannot switch display modes in display test" [High,Confirmed] https://launchpad.net/bugs/427932 [13:47] soren: and local-filesystems is emitted when there are no more local filesystems to mount, not when it's "done" [13:47]