[00:08] hi [00:08] what compiler is suggested for java [00:08] gcj or something else? [00:08] if its gcj why is it so damn slow [00:09] i understand it is being used as the default java interpreter [00:15] starek, openjdk's javac, i think [00:15] starek, there's some kind of default compiler metapackage [00:15] yeah [00:15] thats gcj [00:15] why is it so slow [00:15] 2ghz, 2gb ram laptop [00:15] damn thing drags [00:16] Depends: default-jre (= 1.6-30ubuntu5), openjdk-6-jdk (>= 6b11) [00:17] looks like openjdk to me [00:17] ok but any idea why this is so slow [00:17] ive switched to javac actually [00:23] thanks directhex [00:36] Is there an article on the wiki that tells me how to write a new blueprint? [00:36] * twb looks... === asac_ is now known as asac [02:19] #launchpad tells me there's no such article. [06:56] Good morning [06:56] bigon: ah, thanks; and, yay for it catching regressions already :) [07:55] good morning [08:03] Morning === dholbach_ is now known as dholbach [08:57] pitti: about the check for gupnp-igd? I've already told upstream the checks doesn't pass [08:57] bigon: right; they do pass with the karmic version [08:57] thanks [08:58] good morning [08:58] i've just updated my ubuntu box @work [08:59] and now i can't click the task panel applications with my first left click anymore [08:59] i first have to right click an application, then i can left click again [08:59] file a bug? [08:59] any ideas how to fix it? [08:59] i thought it is maybe already known [09:00] as it's the second box i've updated and it happened on both of them [09:00] http://bugs.launchpad.net/ubuntu/+bugs [09:00] youch [09:01] mattn_, where did you upgrade from? cirtainly not seen that behavior [09:02] apw, update manager [09:02] i mean which release did you upgrade from [09:03] and do you mean that you have to always click right then left works, or just one right in the bar is enough to sort it out [09:03] and was this a normal update or a one release to the next upgrade? [09:04] and do you have -proposed enabled? [09:04] 9.04 => 9.10 [09:05] no, proposed is not activated [09:05] maco, one release to the next [09:06] apw, before the left clicks are working again, i have to right click the app (in the panel) [09:06] alt+tab works fine [09:06] and is this laptop with touchpad, or are you using a normal mouse? [09:06] just switching via mouse isn't working [09:06] normal mouse [09:06] on both of the affected machines [09:06] and both were an update from 9.04 to 9.10 [09:07] i didn't play with any "low-level" gconf stuff [09:07] mattn_, so i hear you saying that each and every left click in the panel you need to do a right click [09:07] if that matters ;) [09:07] no, not everyone - sometimes it works (but not very often) [09:08] mattn_, are you also finding that left click works everywhere else? [09:08] no, some other gtk components are not working via mouse, too [09:08] mattn_: file a bug, it's something that I've seen on 1 karmic install as well [09:08] some buttons in some applications only listen to an activating via space or enter [09:09] e.g. on my work machine it's eclipse that isn't working as expected for some buttons [09:09] and now it worked 5 times ok, then it stopped working again - really strange [09:10] nothing i can nail it down to [09:10] already tried to reboot and so on [09:10] i'm not even sure how i should create a reasonable bugreport for this [09:11] you can really only describe it as clearly as possible. "left clicks not always functional" or something, but do clearly state is multiple applications and that its intermittent and what you can do to make it start working again [09:12] it would be worth doing an xev and recording its output [09:12] mattn_: ajmitch just said he's seen it before. he may have some insight [09:12] and then do a series of left clicks there [09:12] maco: I wish I did, I haven't had a chance to look into it [09:12] also check dmesg, to see if there is any mouse errors, sometimes we lose sync with mice [09:13] as its all applications which are affected i'd probabally file it against the kernel with ubuntu-bug linux, and then 'we'll' ask for the dmesg and xev tests which hopefully can tell us if its kernel or not [09:13] if not we'll pass it to X for further diagnosis [09:14] * ajmitch has only noticed it on gtk+ apps, mostly the panel [09:15] I don't think it'll be a kernel issue [09:39] I note messages during upgrade like this: "Package foo should be rebuild with new debhelper to get trigger support" it seems to relate with install-info. however, debhelper seems up-to-date [09:40] any ideas what package needs merging/fixing? [09:43] siretart`: could be that those packages have "old maintainer scripts" and thus need a rebuild with the new debhelper? [09:45] dholbach: I don't think so. I'm seeing this with my last emacs22 upload a few hours ago to lucid [09:45] ah ok [09:45] * dholbach shrugs then [09:46] siretart`: Does it use dh_installinfo, or does it add install-info calls "manually" to postinst? [09:46] That error message comes from install-info. [09:47] If it gets called from a maintainer script, it will echo that warning, because since debhelper 7.2.17, dh_installinfo does not add a call to install-info, but relies on a trigger to handle that. [09:48] siretart`: I just checked. It does call install-info manually. [09:48] but it also ships with a dh_installinfo -a call in debian/rules [09:48] so it seems to do both [09:51] siretart`: Yeah, I don't know how it's supposed to work when you want to pass extra options to install-info. [09:51] hm. let's see if this happens in debian as well [09:51] siretart`: I'm quite sure it will. See changelog entry for 7.2.17 in debhelper. [09:53] hm [09:53] why didn't this hit us in karmic as well, but just in lucid? [09:55] siretart`: The texinfo change happened rather late, apparantly. [09:56] Tue, 20 Oct 2009 18:28:40 +0100 [09:56] so the "bug" is already in karmic, but we just didn't notice [09:56] Yes. [09:56] Oh. [09:56] Tue, 20 Oct 2009 18:28:40 +0100 was time of upload.. [09:56] Build: # Finished on 2009-10-27 (took 3 minutes, 6.7 seconds) [09:56] (for amd64) [09:57] About the same for i386. [09:57] siretart`: yes, just stop using install-info in the maintainer scripts [09:57] cody-somerville: I've promoted diffutils to main, which should fix that particular debootstrap breakage [09:57] If you need to pass special options to install-info, you seem to have to use ginstall-info. [09:57] siretart`: ^ [09:58] ok. made a mental note [09:58] cjwatson: Unless you know of another way to do so after this change? [10:07] soren: I thought in most situations it was possible to put the necessary information in the info file header to be more trigger-friendly [10:07] we definitely don't want to encourage lots of packages calling [g]install-info directly, AFAIK [10:11] cjwatson: Alright, thanks. [10:19] Keybuk: Are you planning on a UDS session about network configuration in the brave new world of upstart? [10:27] does anyone know how to get nvidia drivers to work with ubuntu when using Sun Virtual box? [10:30] soren: no? [10:40] Keybuk: Hm. Ok. [10:41] did anything change with networking ? [10:41] i mean from a users perspective [10:42] users use network manager [10:42] so no ;) [10:42] Some users do. [10:42] ogra: Yes. [10:43] that seems like quite a random arb question :) [10:43] well, NM is used as well as /e/n/i ... [10:43] ogra: Like, for instance, bonding used to work most of the time. [10:43] i dont see where upstart comes into play [10:43] and it doesnt anymore ? [10:44] ogra: Due to lots of stuff being upstartified in Karmic, the order in which certain things happens has changed. [10:44] soren: but bonding still works [10:44] Keybuk: I'm not going to discuss this again. [10:44] right, but if something is broken due to that, thats a bug [10:44] soren: but you started the discussion [10:44] Keybuk: I'm stating facts. [10:44] Keybuk: Not theory. [10:44] no, you asked if there was going to be a discussion [10:44] Yes, it's racy now, and it was before. [10:45] which, if you're not going to discuss it, is a bit ... contrary [10:45] Keybuk: At UDS. [10:45] soren: so put a blueprint on the server track? I would try to attend, certainly [10:46] Keybuk: I'm not going to discuss it /here/, just with you, again. [10:47] At UDS, certainly. [10:47] I don't think this is a topic that requires a lot of discussion from a lot of people; it really just needs one bugfix [10:47] if you want a session on server boot-time network config, add it to the server track? [10:48] slangasek: Oh, really? What might that fix be? [10:48] soren: "make it not racy" [10:48] the obvious fix for me is that ifup eth0 should bring up any bonded interfaces attached to eth0 [10:48] (provided the other bits are up) [10:49] is ifup reentrant? [10:49] no idea [10:49] it's written in LaTeX, so that's probably "Chapter 4" :) [10:50] slangasek: Well, if you guys know how to "make it not racy", there's no point in my driving a discussion about it. [10:51] at a high level, yes, I know how to make it not racy - the bonding interfaces need to be event-driven in the same way other interfaces are. Keybuk's suggestion is one possible solution, if it works [10:52] if you think it needs to be discussed, I'm happy to discuss it [10:53] IIRC I've used ifup in a post-up hook in the past [10:53] ok [10:54] I think I've tried that, and it didn't work. [10:54] I think it logs /var/run/network/ifstate or whatever it's called. [10:54] Err.. /locks/ [10:54] it locks it briefly when updating it, but from a cursory glance through the source it does not appear to lock it for the duration of ifup's execution [10:55] ICBW of course [10:55] cjwatson: I think it used to, and I fixed that [10:55] Ah. [10:55] I kind of thought it was on purpose. [10:56] soren: what might make a good UDS topic (IMHO) is "what are the things that upstartification breaks on the server?" - that way we can get out on the table all the issues anyone has run into, and we can make sure they *all* get dealt with for lucid [10:58] slangasek: I would love to get this all solved. I just don't want to have the same type of discussion we had two weeks ago. [10:58] "The only winning move is not to play" [11:23] pitti: how can I turn off the apport "serious kernel problem" thing? [11:24] Keybuk: it should already be turned off in kerneloops-daemon 0.12+git20090217-1ubuntu4.1 [11:24] https://lp-oops.canonical.com/oops.py/?oopsid=daemon [11:24] Keybuk: i. e. in karmic-updates [11:25] ah ok [11:25] * slangasek points and laughs at ubottu's clumsy attempt [11:25] I'm sick of being told that my BIOS has ECC disabled by default ;-) [11:26] that's yet another bug which should be addressed in current karmic-proposed linux [11:56] Do XID collision kill you or what does it else? [11:56] GDK seems to be frightened by such error messages [12:02] slangasek: it looks like universe has finished [12:02] urgh [12:02] ValueError: process failed 9: dpkg-source -x quilt_0.48-2.dsc [12:02] +/srv/patches.ubuntu.com/unpacked/q/quilt/0.48-2 [12:03] Format: 3.0 (quilt) [12:03] slangasek: looks like the first v3 source packages have hit testing === Keybuk changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM up to date as of Monday 4am, but now stalled | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [12:12] james_w: is there a way to ask merge-package for different merge strategies (like --lca)? I tried it on "shadow" and got a suboptimal merge [12:26] mvo: merge-package does not support that option yet but could be be made to do so. [12:32] al-maisan: ok, thanks [12:34] dpm: can I pester you about nightly bzr exports of the ddtp translations project via launchpad? sianis is very keen on getting it to implement "nightmonkey" to make the whole translation experience for package descriptions easier [12:39] al-maisan: another very nice option would be to have bzr-buildpackage somehow figure out that it was a merge and add the right -vlast-ubuntu-version [12:41] dpm: along the same lines, bug #374765 is also problematic for nightmonkey [12:42] Launchpad bug 374765 in rosetta "Wrong string order in po file after export" [Medium,Triaged] https://launchpad.net/bugs/374765 [12:51] al-maisan: I get a lot of "Conflict adding files to po. Moved to root. errors - do you a suggestion what is causing this? [12:52] mvo: sorry, I am busy with diagnosing a package set problem. Can I get back to you later? [12:53] al-maisan: sure, no urgent at all [12:53] al-maisan: I can also talk to james_w when is is around [12:53] yes, that's right. === evand_ is now known as evand [13:40] hi mvo, sorry for not replying earlier. First of all, regarding the bug, yeah, I'll ping danilo and the other guys to have a look at it. Or perhaps a better idea would be to mentor sianis to fix it himself, now that LP is opensource. [13:54] mvo re: the nightly bzr exports of the ddtp translations project, bzr exports for source packages are not yet implemented in LP, only for projects [13:54] what is he trying to implement which would need the exports? [13:54] Perhaps there is a better way using some of the existing features [13:58] dpm: its a export of a project he needs, but its currently not working because of the amount of strings in the ddtp project [14:01] pitti: The powerpc, ia64, and sparc uploads for the kdebase-workspace SRU (Karmic) that you accepted earlier today failed to upload. LP has no upload log. This is somewhat concerning since it was fine the last pre-release upload. Suggestions on who I should talk to about this? === marjomercado is now known as marjo [14:01] mvo, ah, I see, yes, it's https://translations.edge.launchpad.net/ddtp-ubuntu. This should be filed as a support request (https://answers.edge.launchpad.net/rosetta/+addquestion) if it's not working, so that the LP devs can look at it in detail. sianis, do you think you could do that? [14:02] ScottK: I'd start with al-maisan or bigjools on #launchpad [14:02] Thanks. [14:02] ScottK: (I'm afraid my powers don't reach into the inner workings of soyuz :( ) [14:03] james_w: I guess we still can't use lp:ubuntu/karmic/PACKAGE for our own packaging branches? [14:03] pitti: Right. I thought it was something I ought to at least make you aware of. [14:03] thanks; I didn't hear about this before indeed [14:03] ScottK: know problem, bigjools is working it (it also affects normal and PPA builds) [14:03] geser: Is there a bug? [14:03] dpm: I think so [14:05] ScottK: I don't know of one [14:06] geser: Thanks. [14:06] dpm: Have a moment? [14:10] ScottK, sure, go ahead [14:11] dpm: I noticed with the kdebase-workspace upload to karmic-propsed that I was just discussing I got the usual flood of translation import messages. [14:11] dpm: https://answers.edge.launchpad.net/rosetta/+question/89334 - is it enough? [14:11] Keybuk, seems there is another mountall race in bug 435228 [14:11] Launchpad bug 435228 in ltsp "ltsp doesn't boot due to mount errors in initrd" [Undecided,Fix released] https://launchpad.net/bugs/435228 [14:11] dpm: Since -proposed is an area for testing, sometimes packages fail testing and never make it into the archive. [14:11] ogra: "in initrd" => NOT MOUNTALL! [14:12] dpm: It seems to me that -proposed ought not be used for translation imports since that may leave them out of sync with what is finally delivered to end users. [14:13] Keybuk, http://launchpadlibrarian.net/32307916/ltsp_2.png [14:13] sianis, that's good, thanks [14:13] lamont: seems that crested fell into the digest mismatch problem again; can you please nudge it back to work? [14:14] ogra: fun, got a patch? :) [14:14] Keybuk, nope, no idea whats going on there yet [14:15] i'll try to find out though ... there are some reports on the ltsp mailing list that it's not reliable reproducable ... does apparently only happen one out of ten boots or so [14:17] ScottK, hmm, that's a good point, but there are two other points that come to mind here: in principle uploads to -proposed shouldn't be changing strings (or unless not without notifying translators), and sometimes uploads to -proposed are indeed fixes to strings (in which case we do want the new strings in LP) [14:17] dpm: True. Except what if you change the string and then the update gets rejected for other reasons? [14:18] It would seem to me you'd want to know it was going in the archive. [14:19] ARGH! My coffee machine stopped working after I upgraded my laptop to karmic! [14:19] CANCEL THE RELEASE! [14:19] * Keybuk finishes catching up with ubuntu-devel-discuss [14:20] geser: Looks like it's fixed now. [14:20] ScottK, I don't have a definitive solution for this other than letting the translations team know: if an upload to -proposed modified strings in a template and was later rejected, those rejecting it should notify the translations team, who can then manually upload the old template back without requiring a package upload [14:21] dpm: I think any solution that relies on developers remembering to tell translators about unusual things is doomed to fail. [14:22] ScottK, yes, I agree :) I'm also for automatic solutions [14:23] but I thought uploads to proposed [14:23] might be something that gets more review before getting uploaded [14:24] so any string changes are accepted/rejected before the upload [14:25] dpm: We upload to proposed for testing and even with all the review before hand, it doesn't always go well. [14:25] ScottK, but I agree that it makes sense to discuss it [14:25] dpm: while it's true that they get review, I'm not sure how to glue that together with translation workflow [14:26] cjwatson, I was not implying that they do not get review, sorry if it came across that way [14:26] I know you weren't [14:26] ok [14:27] dpm: In any case, I think it's something to look into. I'd wait for it to hit updates, but I don't pretend to understand all the translation stuff. [14:28] geser: Looks like it's fixed. [14:28] ScottK, cjwatson there are guidelines on freezes, which mention what to do on string changes. I'm wondering, are there similar guidelines for reviewing uploads to -proposed, in which we could add a note on translations? I know it wouldn't be the definitive solution, but I'm up for anything that raises the awareness on translations [14:29] ScottK, in any case it might make a good topic for a discussion at UDS [14:29] dpm: OK. You should talk to the translation guy about scheduling it. ;-) [14:29] yeah, I wonder who that is ;) [14:34] dpm: StableReleaseUpdates [14:35] ah, thanks. I'll make some notes on translations and send them to the ubuntu-sru team for review [14:36] sianis, mvo re bug 374765, danilo tells me that it is due to another underlying bug, which is somewhat critical and he'll be working on this asap. If fixing the underlying bug does not work, he'll then look into the other one. [14:36] Launchpad bug 374765 in rosetta "Wrong string order in po file after export" [High,Triaged] https://launchpad.net/bugs/374765 [14:37] If you want to keep track of it, it is bug 401618 (note that it doesn't have a milestone yet, since they only assign them when they actually start working on a bug) [14:37] Launchpad bug 401618 in rosetta "Remove [I]POTMsgSet.sequence" [High,Triaged] https://launchpad.net/bugs/401618 [14:47] apw: so my request for more debugging in bug 429257 spawned off two new bug reports which are completely unrelated; I'm afraid I need you to run the procedure as well [14:47] Launchpad bug 429257 in gvfs "MMC cards no longer auto mount" [Undecided,Incomplete] https://launchpad.net/bugs/429257 [14:50] dpm: thanks! [14:50] pitti, so you want me to file a new bug yes? [14:50] apw: well, ubuntu-bug does it that way [14:50] mvo, np :) danilo also tells me that he'll get in touch with you re: ddtp exports [14:51] apw: alternatively you can do udevadm monitor -e --udev and devkit-disks --monitor-detail manually and attach the logs [14:51] hrm ... just worked for me [14:51] apw: (the symptom does that for you) [14:51] symptom apport script, I mean [14:51] hi [14:51] anyone familiar with CBQ / HTB [14:51] cjwatson: if I do something like "ls /boot/" in a package script (e.g. postinst) and the package is installed in a buildd I would get the content of the boot directory in the chroot, right? (just to be sure) [14:51] iwas wondering if there are any front ends to configure them [14:52] tseliot: yes [14:52] cjwatson: ok, thanks [14:53] pitti, ok both sd and sdhc cards are being mounted just fine as of 'now' [14:53] any ideas [14:53] apw: nice [14:54] apw: perhaps it was yet another instance of the "break the world" bug 463347.. [14:54] Launchpad bug 463347 in udev "devices not detected -- too many open files" [High,Fix released] https://launchpad.net/bugs/463347 [14:55] * apw looks [14:55] ive been googling for a bit [14:55] and kinda out of luck [15:00] pitti: how do I make bug #479207 get retraced? [15:00] Launchpad bug 479207 in dbus "dbus-daemon assert failure: *** glibc detected *** /bin/dbus-daemon: free(): invalid next size (fast): 0x01606ed0 ***" [Medium,Confirmed] https://launchpad.net/bugs/479207 [15:01] run apport-retrace? [15:02] hyperair: that involves downloading loads of stuff === robbiew_ is now known as robbiew [15:03] we have an automatic retracer, no? [15:03] oh yeah the apport retracing service or something of that sort [15:03] i think if you wait it runs automatically, though i could be wrong. [15:03] Keybuk: the reporter apparently uploaded a "reduced" report without a core dump, so it can't be retraced [15:03] how do they do that? [15:04] -> invalid then ;) [15:04] there is some logic which tries to judge whether the user-generated stack trace is "good enough" [15:04] which apparently spectacularly failed here [15:04] if there are enough known functions in the trace, it offers this in the details dialog [15:05] Keybuk: yeah, invalid sounds correct [15:07] anyone pls reply [15:07] :/ [15:13] pitti: Now that the upload failure in Soyuz is fixed, I went through and retried all the packages that failed because of it. [15:15] ScottK: wow, that was fast; they cherrypicked a fix? [15:16] pitti: " well, cowboyed pending a proper fix" [15:31] Recently something regarding suspend_text() was fixed, probably in -proposed. Does anyone know what it was again? [15:50] asac: ping [16:43] james_w: around? [16:43] hi LaserJock [16:43] james_w: is there a channel for distributed devel? [16:43] you could jump in #ubuntu-bzr [16:45] james_w: I'm there (all by my lonesome) [16:46] LaserJock: are you sure? [16:46] james_w: in #ubuntu-bzr [16:47] bah [16:47] * LaserJock stabs empathy [16:48] #ubuntu-bzr doesn't seem to be a registered channel [16:52] Riddell: hi [16:53] Riddell: firefox kde spec? [16:53] asac: that was the question [16:53] asac: worth scheduling one? [16:54] Riddell: i think its definitly worth scheduling one [16:54] ok will do [16:55] Riddell: will you add a spec? maybe also refer to the other spec we had once ... so we can check if the suse patches have everything we thought abuot that that point [16:56] asac: yes [17:02] Hi. Could someone help with PPA builds? The problem is that the build-bot installs the wrong version of software (I have the needed version in my ppa already built, but it installs ubuntu version instead) and package building fails because of that. Build log -> http://launchpadlibrarian.net/35424976/buildlog_ubuntu-karmic-lpia.audacious-plugins_1.5.1-2ubuntu3~ppa1_FAILEDTOBUILD.txt.gz Package list -> https://launchpad.net/~sandshrew/ [17:02] +archive/ppa/+packages [17:07] slangasek: bug 426027 [17:07] Launchpad bug 426027 in util-linux "/dev/disk/by-uuid doesn't exist in karmic kernels" [High,Triaged] https://launchpad.net/bugs/426027 [17:07] you say "Given that upstream has a fix for this, we should certainly apply this to karmic via SRU." [17:07] unfortunately the "fix" is after a near-rewrite of blkid ;) [17:16] Keybuk: is it something that can be detected prior to upgrading? [17:16] I mean detected and fixed [17:16] Ng: fixing involves dd over partitions [17:16] * Keybuk gets scared [17:17] not fixing involves an inability to boot, which is also kinda scary [17:18] and at least pre-upgrade the thing is in a known-good state [17:18] even just saying "sorry, you can't upgrade" would be better than the current situation [17:19] imho :) [17:33] doko: ping re gdb 7.0/6.8 === asac_ is now known as asac === dendro-a` is now known as dendro-afk [17:55] whee [17:55] 2,400 unread mails now read [17:56] Keybuk: hey, indicates you are a social being with many friends and fans. congratulations! ;D [17:59] Keybuk, you mean you've redirected 2,400 mails into /dev/null? [18:00] sebner: no, just someone who gets subscribed to logs of bugs [18:00] Keybuk: you are mean, look at the brigth side :D [18:01] hoi jono =) [18:01] hey sebner :) [18:04] james_w: can you import samba please? thanks! === asac_ is now known as asac === quadrispro_ is now known as quadrispro [18:24] smb: for the lols: crossgrading to amd64 fixes karmic for 445456 [18:24] apparmor.d/libvirt/libvirt-54b68396-8493-97f7-c78a-ac9a74684ddb <-- wtf? [18:25] lamont, the last thing maybe jjohansen knows [18:25] those are 2 totally unrelated comments, fwiw [18:25] lamont: give me a sec [18:26] anyway, somewhere in karmic, the jaunty regression that the CVE fix uncovered got fixed. Meanwhile, karmic/i386 hates booting windoze differently [18:26] lamont: jdstrand added per vm apparmor profile generation to libvirt. [18:26] karmic/amd64 was on the plate for a while, so I spent a couple hours yesterday doing the crossgrade [18:26] sbeattie: ok, just per-vm, not per-invocation.. much better [18:27] lamont: jdstrand has add some AppArmor libvirt wrappers [18:27] mdeslaur: most of postfix should be confinable - just local and it's friends should have issues, no? [18:27] lamont: that's my understanding, but at the moment, my knowledge of libvirt is doing there is theoretical only [18:27] sbeattie: heh [18:28] smb: so short answer is that I'm less interested in the bug now, since I haz working windoze again [18:28] lamont: I haven't looked at the issue, I'm just quoting the fedora page [18:28] lamont, The other thing not surprisingly because the problem seems to be related to setting 64bit flags on 32bit [18:28] mdeslaur: we can spend some time in dallas staring at it [18:28] lamont, Would you still be able to run test kernels for me? [18:28] most of the postfix daemons should be very constrainable [18:28] smb: yeah [18:29] lamont, Great. I have something built (but not tested and uploaded) Maybe a bit later [18:29] smb: the biggest challenge is that the early karmic kernels don't work with jaunty or karmic userspace very well... that was when I gave up on bisecting karmic and through some total entropy into the problem by booting the amd64 livecd [18:29] lamont: with libcap-ng? or are you talking about apparmor? [18:29] apparmor [18:29] haven't looked at libcap-ng [18:31] mdeslaur: or were you talking about libcap-ng? [18:32] most of the postfix daemons have very specific things that they do, and files/directories that they should touch. local is the glaring exception of the tip of my head [18:32] (mixed metaphors are just so much fun...) [18:32] lamont: yeah, we were talking about libcap-ng: http://fedoraproject.org/wiki/Features/LowerProcessCapabilities [18:33] ah, more reading. kthx [18:43] smb: will be afk most of the day, starting in about 5 min [18:43] or less === maco_ is now known as maco [18:44] lamont, As it seems less urgent for you, it can be tomorrow too [18:45] slangasek: I learned debhelper %: dh $@ thingy [18:45] slangasek: I was disappointed that it doesn't help take care of the whole CFLAGS/--build/--host thing in *any way* :-( [18:45] which is by far the largest and ugliest bit of debian/rules [18:45] haha [18:45] yeah - it's a non-issue for me now. at some point, I'll migrate the i386 karmic boot tree to not be where it is today, and then things will be simpler. [18:48] Keybuk: it really should; dh_auto_configure takes care of --build/--host [18:48] cjwatson: yeah, but dh_auto_configure has joey's idiotically wrong idea of flags to pass to configure [18:48] so it'll fail on any up to date package due to the unknown options [18:48] really? which ones? I haven't run into any problems [18:49] oh, apart from the one that he took from cdbs, which was wrong [18:49] it unconditionally passes --disable-maintainer-mode and --disable-dependency-tracking iirc [18:49] #541458 [18:49] which don't even exist [18:49] doesn't configure just ignore those? [18:49] no, not anymore [18:49] autoconf stopped ignoring unknown options a while back [18:49] ew [18:49] hm, well dh_auto_configure doesn't break on any autoconf-up-to-date package for me [18:50] but YMobviouslyV :) [18:50] have you filed a bug already, or shall I? [18:50] cjwatson: if you could [18:50] looks like he took those two from cdbs as well [18:50] /usr/share/cdbs/1/class/autotools-vars.mk has the exact same thing [18:51] ok, will do so in a bit [18:51] I was also vaquely wondering whether --localstatedir=/var shouldn't be --localstatedir=/var/lib [18:51] but I can't remember which was right [18:51] if you have any references to send me it wouldn't hurt [18:51] localstatedir's default is ${prefix}/var [18:51] but of course that's for the /usr/local layout [18:52] info Autoconf => Site Configuration => Option Checking [18:53]