[00:01] I'm looking at bug #113919 which applies to Hardy - and earlier. The suggested patch to fix is now in Intrepid. I asked on #u-bugs about backporting, but the wiki indicates that this is probably an SRU, rather than a backport. Any advice? [00:01] Launchpad bug 113919 in dosfstools "fsck crashes checking external FAT drive" [Medium,Confirmed] https://launchpad.net/bugs/113919 [00:12] slangasek: Sure, I'll sort it out [00:15] StevenK: ogra already did [00:15] That's what I get for living in an .au timezone :-) [00:16] shall I find another bug to put you to work on? ;) [00:16] * StevenK is poking at linux-lpia. [00:17] Want -lpia metapackages [00:18] What a useless arch [00:19] * StevenK silences cody-somerville with a glare [00:24] Anyone? [00:26] Not all at once :) [00:26] owh: "follow the SRU Procedure"? :) https://wiki.ubuntu.com/StableReleaseUpdates [00:27] slangasek: I read that, but I know that I don't have enough information to build that whole process. [00:28] Or are you telling me to just "jump in"? [00:28] Well, luckily you don't have to build the entire process - just the package. :p [00:28] yes!! :D [00:28] well, alternatively find someone who does and make them do it? [00:28] \o/ [00:28] * owh volunteers cody-somerville [00:28] :) [00:29] owh, wadaya want anyhow? : P [00:29] Seriously, I'm happy to jump in, but I thought I'd come and talk to someone before I did. [00:29] if the bug is fixed in intrepid, someone must have fixed it there, so they would have the necessary info? [00:29] slangasek: To me it appears as if Intrepid just synched the latest version. [00:29] No bug as such. [00:29] ah [00:30] well, there was still a bug, even if there wasn't a bug report [00:30] (or rather, there was this bug report, but it wasn't linked to the changelog) [00:30] I think I can get my head around that one... [00:31] evand: is usb-creator targeting main directly for intrepid? [00:31] cody-somerville: Well, to start with, some winning lotto numbers, then a neck massage, and an SRU for dosfstools, think you can handle it? [00:32] :P [00:32] * slangasek looks up last week's winning numbers, to help out [00:32] I hear StevenK is good with the neck massages (keybuck swears by them). [00:33] Yeah, but stevenk is on the other side of the country. [00:33] owh, and where do you think I am? Hint: not under your bed. [00:33] At least it's the same country :) [00:33] * owh hasn't checked of late :) [00:33] * cody-somerville is in Lexington, MA, USA atm fyi [00:34] "USA ATM FYI" FTW [00:34] Haha [00:34] * owh has stevenk in Sydney. [00:35] * StevenK might, or might not be in Sydney [00:35] Heh [00:36] owh, Can you file a bug re: your SRU request. [00:37] cody-somerville: I'm following the dot-points in the URL that slangasek indicated, I've just subscribed ubuntu-sru and I'm now updating the bug report description. [00:37] whats the bug #? [00:37] 113919 [00:38] owh: so you haven't extracted the patch to be included in the SRU yet/ [00:38] ? [00:38] lool: libmdns -> lib32mdns depends? are you on crack? [00:38] ;p [00:39] slangasek: Well, the patch file is already available via a debian link, but I'll include it. [00:39] I figured that it made more sense to use the current version of dosfstools, rather than a single diff. [00:39] Is that incorrect? [00:40] for an SRU, that's incorrect [00:40] Ok, I understand. [00:40] owh, congratulations, you're correct that you're incorrect [00:40] cody-somerville: :P [00:41] Hmm, the more I think about this, the more I think that this is going to go nowhere. [00:41] owh, You need to create a patch that specifically fixes the segfault and nothing else. [00:42] cody-somerville: That patch exists in Debian. [00:42] cody-somerville: Mind you, it also "fixes" an if-else into a switch-case. [00:43] * owh thinks I should stop going down the dots, remove ubuntu-sru for a bit and get some ducks lined up first. [00:44] The wiki dot order doesn't seem that correct. Nominate and subscribe before you do any work... [00:44] Is that intentional? [00:44] perhaps not [00:45] Or was the intent that you could start the process and run away for someone else to pick up? [00:46] we should probably switch 2 and 3 around in that list [00:47] Yeah, that's what I was thinking. [00:49] Done [00:53] Ahh the plot thickens, there is an actual bug that requested the sync. [00:53] Bug #244407 [00:53] Launchpad bug 244407 in dosfstools "Please sync dosfstools 2.11-5 (main) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/244407 [00:56] ScottK: ah, hmm; so in between the clamav sync FFe request and my acking thereof, you did an ubuntu1 upload? [00:57] owh: That fixes it for Intrepid, not Hardy [00:58] * StevenK kicks HAL for not mounting USB disks anymore [00:59] StevenK: The SRU process seems to assume that a bug for the development version needs to exist before you can SRU it. [01:01] owh: Or is fixed in the development release [01:02] StevenK: Right. It then goes on to say: "update the bug report" [for the bug that is marked "Fix released". === superm1|away is now known as superm1 [01:10] a.b.c.d - - [08/Sep/2008:19:09:01 -0500] "GET /brainstorm?idea=test HTTP/1.1" 200 55 "http://summit.netsplit.com/uds-jaunty/sponsorship" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1" [01:10] *sigh* [01:10] SOME people just can't leave things alone :p [01:10] "oh, look, a webapp; I know, I'll take it apart, read the javascript, and attempt to break holes in it" :p [01:14] Jackalope?! [01:14] Haha. I was waiting for that. [01:14] that's like so redneck :-) [01:14] Keybuk: "Never attribute to malice that which can be adequately explained by stupidity." [01:15] heh [01:15] yeah I just approved Mark's post [01:15] lol [01:16] I don't think I ever had one [01:16] but every gas station when I was growing up sure did [01:17] hilariously google managed to leak the code name [01:17] and I have absolutely no idea how [01:17] since it clearly indexed a page almost 30 minutes before it was linked from anywhere [01:19] Keybuk: Perhaps someone read some web-mail with it? [01:20] jackalope? I thought the theme was animals, not characters from bad early 90s shows on ABC [01:20] slangasek: you don't play the second and far more fun game? [01:20] hmm? [01:20] not guess what the codename will be, but guess what Mark will have been drinking/smoking/reading/watching when he comes up with it? [01:20] oh, I don't play either game. :) [01:21] kinky koala! [01:21] I refuse to upload to a release called "kinky" [01:23] jaunty is a bit interesting, I instantly think of jaundice [01:23] the idea of a jaundiced jackalope just isn't really sounding motivating ;-) [01:23] http://www.engadget.com/2008/03/21/ubuntu-hardy-heron-8-04-released-in-beta/ [01:23] that's... odd [01:24] Interesting, someone suggested it Mar 21st 2008 5:02AM [01:24] cody-somerville: it's a common suggestion actually, shows up in the forums [01:24] there aren't many animals or adjectives for j anyway [01:25] that thread shows a reasonable number of real animals as options. :) [01:25] * cody-somerville is off to party in Boston :P: [01:25] enjoy [01:25] Jumpy Jackrabbit [01:28] Jittery would have been fun [01:29] I was thinking that too but couldn't think of an animal :) [01:29] I could have gotten behind Jittery Jackalope === xxx__ is now known as _iron [01:49] PulseAudio 0.9.12 just released, and heading to my PPA shortly. [01:50] TheMuso: Cool. That makes it easier :) [01:50] RAOF: Yeah. I'll also pull latest alsa git and see if I can find any fixes relating to pulse there for your issue. [02:02] slangasek: Yes, but there was nothing in it that needed to be kept. Sorry I forgot to update the bug. The only thing it did was drop Recommends we didn't want in Main and Debian dropped them too. [02:03] ScottK: ok [02:21] * cjwatson wonders if this trend for getting some kind of MOTU points for taking a bug with a patch in it and appending a debdiff with that patch plus a changelog entry is really valuable [02:22] cjwatson: IMHO, no. [02:22] if you need sponsorship, the patch is going to need review anyway, so are you really adding anything? the work has one bit of informational content, namely "this patch needs to be reviewed" [02:23] I'm concerned that it seems to be ending up as a mechanical patch->debdiff transformation task, when the task of a reviewer should be to sanity-check the patch, argue with its author if necessary, and then upload it if it's good (not just put it through another stage of review) [02:24] cjwatson: and forward it upstream? [02:24] if applicable, of course [02:24] and all the rest of it, yes [02:25] (do not interpret exclusion from my list as anything other than "cjwatson forgot to mention it") [02:25] heh, ok [02:26] I have been given a patch that includes a merge of an if and a switch, which results in an indent change - which in turn obscures an actual code change within the same block. A diff -ruN shows the whole code-block, but a diff -bruN shows the actual code change. Is there a preference or policy which version I should add to a bug? [02:26] mostly I'm worried that there are some people who are wasting their time transforming patches into debdiffs when the developer on the other end would have been perfectly happy with a patch if given time to respond, and a debdiff is no better [02:27] owh: the former if you want the patch to be applyable mechanically; the latter if you want it to be understood by humans. Since it's often desirable to have both facilities, you might just want to attach both. [02:27] Excellent. [02:27] cjwatson: I think there is value in having debdiffs; namely that folk that want to test can do so with less knowledge of the package internals [02:28] cjwatson: because its a patch against the build system, not the code per se [02:28] lifeless: the target of bug reports is not typically testers [02:28] cjwatson: cause or effect :P [02:28] lifeless: let's take bug 267103 as an example [02:28] Launchpad bug 267103 in usb-creator "usb-creator FTBFS with "/bin/sh: python2.4: not found"" [High,Fix committed] https://launchpad.net/bugs/267103 [02:28] starts off with a suggested patch (incidentally in debdiff form), fair enough [02:29] cjwatson: ok, so a FTBFS can be autotested if there is a debdiff patch [02:29] cjwatson: whereas a human is required for a non-debdiff patch, with current facilities [02:30] Matt and I review, and I suggest an alternative formulation which is a one-liner and preparing a patch is a waste of time (it'll take the developer as long to download and apply the patch as it would to just change the one word); also I happen to know that the developer is currently working on the package anyway and so a patch is more useful than something that tromps over debian/changelog where they're going to have to ... [02:30] ... resolve the conflict [02:30] sure [02:30] the original submitter then reformulates this as a debdiff, whereas in fact this has negative utility [02:31] I guess I'm making a philosophical point [02:31] as for the debian/changelog conflict, that is surely programtically mergable [02:31] or bug 264471, where Evan submits a perfectly good patch, and somebody transforms it into a debdiff with no additional value [02:31] Launchpad bug 264471 in germinate "Typo in germinate.1" [Low,Fix committed] https://launchpad.net/bugs/264471 [02:31] lifeless: you are making a number of reasonable points, but none of the qualities you're striving for are ones I think are interesting for Ubuntu bug reports ... [02:32] a human being required to review a patch is a feature [02:32] we do not want to automatically merge patches [02:32] agreed; for inclusion to trunk [02:32] I'm totally behind that [02:32] I think what you're missing is that many of the cases at hand are utterly trivial [02:34] but because the policy is "prospective MOTUs shall get some changes sponsored, and in order to get a change sponsored there must be a debdiff", there is a deleterious social effect where prospective MOTUs redo other people's work in a different form (adding little value along the way) in the expectation that they'll get credit for it [02:34] oh, getting what you measure for [02:34] Because a debdiff gives a changelog with the all important their name in it [02:34] whereas, in fact, they have been misled because most developers reviewing their change will see the transformation and note that not much work was involved [02:35] particularly when they are transforming a patch that was already submitted by another developer [02:35] This is why I was arguing for a totally social peer-review metric for MOTU readiness back at MV, rather than strongly predefined criteria [02:35] StevenK: *exactly* [02:35] because I think its impossible to write good predefined criteria, but totally possible to say to sane folk "Is person X ready" [02:36] I didn't realise that that concept had degraded so far :( [02:36] I understand the need to have some mechanical assistance in assessing readiness, since there are a lot of people involved [02:37] I don't understand that yet, having followed NM for quite some time [02:37] I found it useful while on the community council to have mechanical metrics for how much people had done as a supplement to comments from their peers [02:38] hmm, in the asia membership board we look at what folk have done; I don't have a scale for it though [02:38] I'm not sure this is necessarily a problem with the existence of metrics, though; the problem is that we're suggesting that developers with zero experience should be reviewers [02:39] mainly 'lots' vs 'little' and 'trivial' vs 'ongoing' [02:39] whereas, in fact, what we should be doing is advising people to fix bugs all by themselves first, and after they have gained experience (i.e. >= already MOTU) they can help out with reviewing patches from contributors [02:39] thats definitely a problem, reviewing is something that takes practice, and knowing whats good vs bad [02:39] exactly [02:41] hmm. I should go back to bed, but thanks for refining my IRC rant :) I may turn that into a mailing list post or something [02:44] I'm looking at a patch and I think there is an error, but I'm not a C++ programmer, so I'm wondering if someone can have a look at this partial diff and tell me that I'm wrong. http://ubuntu.pastebin.com/m217fd2ab [02:46] cjwatson: my pleasure :) [02:51] cjwatson, I assume you've gone to bed? [02:52] * owh annotated the concerns http://ubuntu.pastebin.com/m32b6d894 [02:55] Does my concern make any sense to anyone, or am I just dribbling? [02:57] That pastebin is useless w/o context. [02:58] cody-somerville: What kind of context is needed for it to become useful? [02:58] owh, probably the entire sourcefile if not more :P [02:58] The actual diff came from here: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=dosfsck-lfn-3.diff;att=1;bug=152550 [03:00] cody-somerville: If I just look at it from an assignment perspective, then is the patch not using the old value for lfn->id ? [03:00] Maybe thats correct? [03:01] cody-somerville: Well, it changes the code where the only other patches in the code are checks to deal with 0 overflows. It's the only such change and I would expect an annotation. [03:01] But you raise an interesting point, which I had not considered. [03:02] So, I'll go ask the person who added it to Debian :) [03:05] owh, yea, I'd say it is intentional [03:05] cody-somerville: What makes you conclude that? [03:06] because all the if statements have been changed to compare against slot instead of lfn->id & LFN_ID_SLOTMASK [03:08] hm... cjwatson raised an interesting point. nonetheless, I believe there's some value in turning a patch into a debdiff, as it jumps the point between just patching and packaging. [03:08] the point not solved imho boils down to what which person did, and hence is technically knowing about s.th. [03:08] cody-somerville: Which is covered by the assignment at the top. [03:08] sistpoty: Just adding a changelog to a patch does not mean it's worth brownie points [03:09] cody-somerville: But it's the only place where the meaning changes. [03:09] StevenK: well, kind of with the brownie points. It means adding a meaningful changelog to me (as in what and moreover *why* s.th. was changed) [03:10] owh, The meaning isn't changing. [03:10] owh, the patch is correct [03:10] StevenK: nonetheless, I agree that it's only a small piece of a brownie [03:10] cody-somerville: The meaning *is* changing because lfn->id changes. [03:11] and funnily enough, back then when I was just a motu, the review of the dofsck (or whatever it's called, I just don't recall) by owh, is s.th. I consider more worthwhile than any patch in the first place [03:11] owh, I'm not going to argue with you. If you have any further questions about the patch, ask the author. [03:11] *dosfsck* [03:12] sistpoty: Huh? [03:13] cody-somerville: I will ask the author, but thanks for your eyeballs. [03:15] owh: that was quite some time ago... remember? the infamous bug was that dosfsck shouldn't check anything by default, which lead to two or more bugs uncovered within dosfsck (or was it someone else who finally kept me from proposing a patch that just wasn't wrong)? [03:15] Yup, that was me :) [03:15] heh [03:15] Ah, so that was a compliment :) [03:15] * owh blushes [03:15] owh: see, that was imho a great contribution, much better than turning a patch into a debdiff ;) [03:16] * owh is still partial to dosfsck and still at it :) [03:16] IIRC we both had out boot-prints all over that patch sistpoty :) [03:17] owh: yes, and it was great imho :) [03:17] It fixed stuff and people cheered - all good :) [03:18] sistpoty: I still haven't gotten to the bottom of codepages and dosfsck yet - so if you're bored :) [03:19] owh: sorry... I *do* have a copy of the MS manual about dosfs now (actually since some time)... but I haven't found time yet to go much further than downloading that *g* [03:21] sistpoty: I even got as far as someone giving me a filesystem with a different codepage on it, but I got buried in trying to figure out how to deal with multi-byte characters without my head exploding. Since then it seems to have gotten harder too, someone pointed out that you can change the codepage whenever you want - lovely :( [03:21] heh, sounds like fun :( [03:22] Hey, if I can fix one dosfstools bug per quarter, I'm doing more than most :) [03:26] How do I unsubscribe the ubuntu-sru from a bug? [03:26] You have to be in ubuntu-sru to do it. [03:29] So, I can subscribe them, but not unsubscribe them - joy :( [03:31] Yes. [03:31] owh: yep, long-standing LP bug. thought it was fixed (but must have mistaken it to be fixed anytime soon (whatever that means)) [03:31] Heh [03:32] It's good that one of the members of sru was right here encouraging me to "jump in", so I did - we then changed the SRU procedure around a little so we wouldn't subscribe U-sru before documenting the bug :) [04:00] kees: sorry about bug #249936, I wanted to follow up on this with the warning being present for ignoring short writes... sorry for the inconvenience! [04:00] Launchpad bug 249936 in glibc "fread declared with __wur (warn_unused_result)" [Low,Invalid] https://launchpad.net/bugs/249936 [04:00] (and I agree after having heard more on why the warning does make sense) [04:01] heck, short reads even *g* [05:01] How would one go about signing a ton of packages via a script w/o having to enter their password for their key a bunch of times? [05:02] With gpg-agent, I would assume. [05:04] RAOF, thanks :) [05:12] cjwatson, you around? [05:12] Does anyone know if backports are available on unoffical architectures? [05:12] its 6am there so probably not [05:13] and i dunno about the question [05:13] i only use amd64/i386, i have a m68k but its about as useful as a doorstop [05:14] calc, you do know I am a debian m68k porter ... [05:14] NCommander: oh, no offense, i have a quadra 840av it doesn't have dma disk support [05:14] NCommander: i can type faster than it can display when its doing disk io [05:14] calc, that's being worked on now int he 2.6 branch [05:14] and i can barely touch type ;-) [05:14] cool :) [05:15] i bought it about 8 years ago and maxed it out to 128mb ram but it was just way to slow to do anything with [05:15] calc, I plan to port Ubuntu to m68k ... [05:15] good luck :) [05:15] fluxbuntu might work ;-) [05:16] * calc somehow doubts getting gnome onto it will work [05:16] Xubuntu is likely [05:16] We did build KDE on m68k [05:27] NCommander: oh i'm sure it will all build, just not run fast enough to be usable ;-) [05:27] * calc used to watch the slow kde builds on debian since he maintained kde [05:32] calc, well, at the moment, have an interest of getting backports available for PowerPC and the other port architectures [05:38] NCommander: backports are built for all ports [05:39] cjwatson, I can't find lpia on us.archive.ubuntu.com or ports.ubuntu.com [05:40] oh wait [05:40] I'm an idiot :-) [05:40] cjwatson, your a kubuntu developer, right? [05:40] look harder ... http://ports.ubuntu.com/ubuntu-ports/dists/hardy-backports/main/binary-lpia/ [05:40] NCommander: no [05:41] ok :-/. I have a FTBFS for kdenetwork for hardy on lpia [05:41] ^fix [05:41] well, I am in the sense that I have upload privileges to all of Kubuntu, but I don't use it [05:43] cjwatson, heh, Ok, no problem, I'll just wait for ScottK to reappear [05:44] cjwatson, do chroot problems build features (marked as chroot problems) get auto-retried, or does someone need to do it? [05:48] NCommander: I don't think it's automatic, but often enough whoever fixes the chroots just gives everything back [05:51] ah [05:51] I feel like doing something productive :-/ [05:52] cjwatson, know any good todos? [05:52] chroot problems get done automatically, afaik. [05:52] i think, anyway [05:53] NCommander: I only just woke up, and it's before 6am ... not so much [05:54] cjwatson: you were meant to answer with all teh work you had to do :) [06:09] good morning === superm1 is now known as superm1|away [07:35] doko: Well I find the rationale for a libmdns -> lib32mdns depends more motivating than the one which pushed for a lib*mdns dep in jdk packages [08:00] Good morning [08:00] Morning pitti [08:02] Good morning pitti. It was suggested that you might know current practices for update-manager maintenance? The last update broke update-manager-hildon, and I'm unsure if it's better to fix it now in the source, or wait for a bzr branch to appear. [08:02] doko: (See my email) well I wasn't actually thinking of a depends dep, rather recommends; it's hard to express "if you have libmdns and ia32-libs" [08:04] persia: hm, I don't have particular knowledge about it; mvo is the maintainer, I think you should talk directly to him [08:04] pitti: Just hoping you might know as it's early yet :) Thanks. [08:42] mvo! Good morning. I've an update for update-manager, but it applies against bzr, and there's newer source in the archives. If uploading, what's the best way to proceed? [08:44] persia: update-manager in the archive and in bzr are not in sync ? [08:44] mvo: At least not lp:~ubuntu-core-dev/update-manager/main [08:44] * dholbach can feel mvo's blood pressure rising (and that although he lives 700km away from here) [08:45] persia: oh, that is bad, let me check how that happend [08:45] * mvo hugs dholbach [08:45] :-) [08:45] * persia looks for Riddell [08:45] * dholbach hugs mvo back [08:46] persia: I really don''t like it when the packages gets out of sync [08:47] mvo: I was thinking that I could pull the current archive source, commit, make my changes, commit, and request a merge. Would that model make sense to you, or do you seek the detail changes in the current upload? [08:47] persia: let me please first check what happend [08:49] mvo: OK. Let me know, and I'll push my changes. [08:49] Riddell: could you please push your update-manager changes into the lp:~ubuntu-core-dev/update-manager/main branch (you probably just forgot a bzr push) [08:49] persia: thanks, where is the branch that you want to be merged? (what location) [08:51] mvo: I haven't pushed yet, because of the confusion. I'll update the changelog and push now. [08:51] persia: ok, thanks === seb128__ is now known as seb128 [08:58] doko: wow, uploading gcc at 5:40 in the morning? :-) [08:58] hey seb128 [08:58] hello pitti === SWAT__ is now known as SWAT === tkamppeter_ is now known as tkamppeter [09:37] slangasek: yes, I plan to file a MIR in the morning. [09:55] jdstrand: I'd appreciate it if you could have a look at bug 262451 for your next ufw upload [09:55] Launchpad bug 262451 in dpkg "dpkg: ../../src/packages.c:221: process_queue: Assertion `dependtry <= 4' failed." [High,Confirmed] https://launchpad.net/bugs/262451 [09:57] so what do I have to do to get xserver 1.5.0 accepted? [09:59] tjaalton: file bug describing changes and asking for exception, subscribe ubuntu-release === fta_ is now known as fta [10:01] cjwatson: k, will do [10:16] cjwatson: I can upload it already so it's ready in the queue? [10:36] mvo: update-manager merged [10:37] Riddell: thanks [10:39] mvo: Upload it :-) [10:51] StevenK: I will, almost ready [10:55] tjaalton: if you upload it, it will go straight through without confirmation (unless it hits NEW for some reason). The archive is not frozen by any technical means [11:00] cjwatson: ok, in that case I won't upload [11:01] if any member of the release team would have a look at bug 268055, I'd appreciate it. all video drivers need to be rebuilt so I'd like to get on with it ;) [11:01] Launchpad bug 268055 in xorg-server "Please accept xorg-server 1.5.0-1ubuntu1" [Undecided,New] https://launchpad.net/bugs/268055 [11:32] soren: kvm still crashes when shutting down a VM (windows xp). 6 apport pop-ups come up before it actually shuts down. [11:33] Wow. :) [11:33] soren: bug #259336 [11:33] Launchpad bug 259336 in kvm "kvm crashed with SIGSEGV in __libc_start_main()" [Medium,New] https://launchpad.net/bugs/259336 [11:34] soren: anything I can do to help debug? === dholbach_ is now known as dholbach [11:35] so new kernel isn't changing things much for me [11:41] amitk: I forget... This is with kvm 72 userspace and kernel modules as well? [11:45] soren: Version: 1:72+dfsg-1ubuntu2 [11:45] amitk: And kernel? [11:45] soren: 2.6.27-2-generic [11:45] amitk: Could you try installing kvm-source? [11:46] It does the dkms thing to provide more up-to-date modules. [11:51] soren: nice! much better, with and withoug kvm-intel module. No crashes. [11:51] *without [11:52] amitk: Without the kvm-intel module? Then you're in qemu-mode => very, very slow. [11:55] soren: I know. I tried both ways - w/o modules and with update modules from kvm-source. And now there are no crashes. [12:02] tjaalton, pitti, is there a way I can debug issues relating to notebook keys for adjusting brightness etc and xorg input hotplug? I think the hotplug broke this for a couple of machines I have access to, and I'd like to track down the problem. [12:03] TheMuso: sounds like bug 267682, it has a few pieces of information [12:03] Launchpad bug 267682 in ubuntu "Hotkeys no longer working in Intrepid (evdev?)" [Critical,Triaged] https://launchpad.net/bugs/267682 [12:03] pitti: Thanks, will have a read. [12:08] dholbach: Any idea who handles bluetooth packaging currently? [12:09] pitti: Is this bug also related to not seeing volume/brightness indicators hon screen when pressing such keys? [12:09] TheMuso: ATM they don't do anything at all, right? [12:09] TheMuso: well, on some models they are hardwired [12:09] pitti: Well the volume/brightness gets changed, but no indicator is displayed. [12:10] so they will have an effect, but the GUI doesn't notice them [12:10] same bug in the end, yes [12:10] Yep. [12:10] Right, I don't know enough about those bits to be sure, thanks. [12:12] amitk: Lovely. That's very useful input. Thanks! [12:13] slytherin: #ubuntu-mobile I'd say [12:14] dholbach: waiting for StevenK there. :-) [12:16] pitti: didn't arrive yet in my time zone :-/ === ara_ is now known as ara === ogra_ is now known as ogra [12:28] mvo: update-manager wants nvidia-common!? [12:29] StevenK, lrm uses it iirc [12:30] nvidia-common is only on amd64 and i386 [12:31] mvo: There's no nvidia-common on lpia [12:32] why ? [12:32] there might be lpia devices with nvidia onboard cards at some point [12:32] Because it's Architecture: i386 amd64 [12:32] right, that needs fixing imho [12:32] though it might be tricky with binary drivers :) [12:33] nvidia-common itself is tiny [12:45] StevenK: it needs it just for the modinfo stuff [12:45] StevenK: ok, if lpia does not have nvidia anyway, then I need to patch that out [12:48] pitti: I'll modify hal bzr a bit, debian-setup-keyboard should use the same model as in console-setup and force rules to be evdev instead. that means updating xkb-data, x-x-i-evdev, g-s-d as well [12:48] this will fix the problems with ABNT2 & jp106 models [12:48] slangasek: let me know if you work out what caused the samba4 compile error, we have the same problem in kde4libs === LucidFox_ is now known as LucidFox [12:48] mvo: Well, ogra has a good point, but patch it out. [12:48] (once the evdev rules in xkb-data are updated) [12:48] tjaalton: sure, please go ahead; please use UNRELEASED, dch --release, and debcommit --release if you upload yourself [12:48] to date there are no such devices yet [12:49] so we might be able to ignore it for now [12:49] ogra: That's my plan [12:49] mvo: Ping me when you upload it [12:49] pitti: yes, I'm reading the "bzr packaging" session logs now to see how things are done :) [12:49] ogra: And I daresay fast 3D is not a first level requirement :-) [12:50] heh, yeah [12:50] tjaalton: I'm working on the gnome-control-center keyboard global keyboard setting right now, what is the plan for evdev and the console? I understand that the console will still use pc105 (or 104 etc)? [12:50] tjaalton: if you feel unsure, just commit your patch, and I'll do the upload for you, but don't be shy to upload yourself [12:50] mvo: this will let people to change the model again, and not force evdev [12:50] pitti: sure, thanks [12:51] tjaalton: aha, ok. is there work on gnome-control-center required for this too? [12:51] mvo: don't think so, g-s-d forces the model (or ignores it) so that patch should be dropped once hal/xkb-data are updated [12:52] seb128: Hi, was reading the gnome-session changelog to try and find the origin of the logout dialogs, and you noted it was from bugzilla. Mind pointing me to where? I need to see about fixing the dialogs so they are accessible to assistive technologies... [12:52] tjaalton: ok, thanks [12:52] TheMuso: http://bugzilla.gnome.org/show_bug.cgi?id=507101 [12:52] Gnome bug 507101 in general "New UI for logout/shutdown dialogs" [Minor,New] [12:52] seb128: Thanks. [12:53] TheMuso: but don't spend too much work on it, we have no decision yet on whether we will keep this one or if we want something similar to what hardy had [12:53] seb128: Ok, thanks for letting me know. [12:54] TheMuso: you can also talk to vuntz, he hangs on #ubuntu-desktop usually, he's working for novell and pushing those changes upstream now [12:54] let him know if there is any issue, he will probably be interested by those [12:54] seb128: Ok thanks. [13:07] cjwatson: @multiple active devices: do you see packet loss? or do you just assume that you loose packets? [13:08] NM folks say that there shouldnt be an issue with packet loss. if they are on different subnets NM will assign higher prio through metrics to the faster connection [13:08] if they are on the same subnet, kernel should use whatever was there first [13:09] if thats not the case NM folks want to fix metrics instead of allowing to deactivate connection or providing "old" mode that only allows one active connectoin [13:09] cjwatson: so if you have other arguments against "multiple active" devices other than packet loss, please let me know ;) [13:12] asac: does "active connection" translate to "multiple defaultroutes"? [13:13] pitti: yeah [13:14] pitti: hmm [13:14] pitti: strange. actually thats not the cas [13:14] * asac confused [13:14] i think i have to wait for the NM boss to shed a light on this [13:14] asac: hm, if not, how else do they work then? [13:15] pitti: I have package which builds locally but does not build in my PPA...is there any info on where to look for the problem? [13:16] kwwii: the build log should help, if you can send the URL [13:16] kwwii: I'm about to go to lunch, ok to deal with this in an hour? [13:16] asac: yes, I get packet loss [13:16] cjwatson: did you get multiple default routes with the same metric from nm then? [13:16] I think it's that the acks come back on the wrong route or something like that [13:18] pitti: sure, no worries [13:18] pitti: I don't recall, but can test when I get home [13:19] pitti: it seems to want intltool >= 0.37.1 but not get it [13:19] http://launchpadlibrarian.net/17439954/buildlog_ubuntu-hardy-i386.gtk2-engines-murrine_0.60-0ubuntu1%7Eppa2_FAILEDTOBUILD.txt.gz [13:20] kwwii: hm, hardy has 0.37.1-1ubuntu1 [13:21] checking for intltool >= 0.37.1... ./configure: line 11320: intltool-update: command not found [13:22]