[00:01] <owh> 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:12] <StevenK> slangasek: Sure, I'll sort it out
[00:15] <slangasek> StevenK: ogra already did
[00:15] <StevenK> That's what I get for living in an .au timezone :-)
[00:16] <slangasek> shall I find another bug to put you to work on? ;)
[00:16]  * StevenK is poking at linux-lpia.
[00:17] <StevenK> Want -lpia metapackages
[00:18] <cody-somerville> What a useless arch
[00:19]  * StevenK silences cody-somerville with a glare
[00:24] <owh> Anyone?
[00:26] <owh> Not all at once :)
[00:26] <slangasek> owh: "follow the SRU Procedure"? :) https://wiki.ubuntu.com/StableReleaseUpdates
[00:27] <owh> slangasek: I read that, but I know that I don't have enough information to build that whole process.
[00:28] <owh> Or are you telling me to just "jump in"?
[00:28] <cody-somerville> Well, luckily you don't have to build the entire process - just the package. :p
[00:28] <cody-somerville> yes!! :D
[00:28] <slangasek> well, alternatively find someone who does and make them do it?
[00:28] <cody-somerville> \o/
[00:28]  * owh volunteers cody-somerville
[00:28] <owh> :)
[00:29] <cody-somerville> owh, wadaya want anyhow? : P
[00:29] <owh> Seriously, I'm happy to jump in, but I thought I'd come and talk to someone before I did.
[00:29] <slangasek> if the bug is fixed in intrepid, someone must have fixed it there, so they would have the necessary info?
[00:29] <owh> slangasek: To me it appears as if Intrepid just synched the latest version.
[00:29] <owh> No bug as such.
[00:29] <slangasek> ah
[00:30] <slangasek> well, there was still a bug, even if there wasn't a bug report
[00:30] <slangasek> (or rather, there was this bug report, but it wasn't linked to the changelog)
[00:30] <owh> I think I can get my head around that one...
[00:31] <slangasek> evand: is usb-creator targeting main directly for intrepid?
[00:31] <owh> 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] <owh> :P
[00:32]  * slangasek looks up last week's winning numbers, to help out
[00:32] <cody-somerville> I hear StevenK is good with the neck massages (keybuck swears by them).
[00:33] <owh> Yeah, but stevenk is on the other side of the country.
[00:33] <cody-somerville> owh, and where do you think I am? Hint: not under your bed.
[00:33] <owh> 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] <slangasek> "USA ATM FYI" FTW
[00:34] <StevenK> Haha
[00:34]  * owh has stevenk in Sydney.
[00:35]  * StevenK might, or might not be in Sydney
[00:35] <owh> Heh
[00:36] <cody-somerville> owh, Can you file a bug re: your SRU request.
[00:37] <owh> 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] <cody-somerville> whats the bug #?
[00:37] <slangasek> 113919
[00:38] <slangasek> owh: so you haven't extracted the patch to be included in the SRU yet/
[00:38] <slangasek> ?
[00:38] <doko> lool: libmdns -> lib32mdns depends? are you on crack?
[00:38] <doko> ;p
[00:39] <owh> slangasek: Well, the patch file is already available via a debian link, but I'll include it.
[00:39] <owh> I figured that it made more sense to use the current version of dosfstools, rather than a single diff.
[00:39] <owh> Is that incorrect?
[00:40] <slangasek> for an SRU, that's incorrect
[00:40] <owh> Ok, I understand.
[00:40] <cody-somerville> owh, congratulations, you're correct that you're incorrect
[00:40] <owh> cody-somerville: :P
[00:41] <owh> Hmm, the more I think about this, the more I think that this is going to go nowhere.
[00:41] <cody-somerville> owh, You need to create a patch that specifically fixes the segfault and nothing else.
[00:42] <owh> cody-somerville: That patch exists in Debian.
[00:42] <owh> 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] <owh> The wiki dot order doesn't seem that correct. Nominate and subscribe before you do any work...
[00:44] <owh> Is that intentional?
[00:44] <slangasek> perhaps not
[00:45] <owh> Or was the intent that you could start the process and run away for someone else to pick up?
[00:46] <slangasek> we should probably switch 2 and 3 around in that list
[00:47] <owh> Yeah, that's what I was thinking.
[00:49] <owh> Done
[00:53] <owh> Ahh the plot thickens, there is an actual bug that requested the sync.
[00:53] <owh> Bug #244407
[00:56] <slangasek> ScottK: ah, hmm; so in between the clamav sync FFe request and my acking thereof, you did an ubuntu1 upload?
[00:57] <StevenK> owh: That fixes it for Intrepid, not Hardy
[00:58]  * StevenK kicks HAL for not mounting USB disks anymore
[00:59] <owh> StevenK: The SRU process seems to assume that a bug for the development version needs to exist before you can SRU it.
[01:01] <StevenK> owh: Or is fixed in the development release
[01:02] <owh> StevenK: Right. It then goes on to say: "update the bug report" [for the bug that is marked "Fix released".
[01:10] <Keybuk> 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] <Keybuk> *sigh*
[01:10] <Keybuk> SOME people just can't leave things alone :p
[01:10] <Keybuk> "oh, look, a webapp; I know, I'll take it apart, read the javascript, and attempt to break holes in it" :p
[01:14] <LaserJock> Jackalope?!
[01:14] <StevenK> Haha. I was waiting for that.
[01:14] <LaserJock> that's like so redneck :-)
[01:14] <owh> Keybuk: "Never attribute to malice that which can be adequately explained by stupidity."
[01:15] <Keybuk> heh
[01:15] <Keybuk> yeah I just approved Mark's post
[01:15] <cody-somerville> lol
[01:16] <LaserJock> I don't think I ever had one
[01:16] <LaserJock> but every gas station when I was growing up sure did
[01:17] <Keybuk> hilariously google managed to leak the code name
[01:17] <Keybuk> and I have absolutely no idea how
[01:17] <Keybuk> since it clearly indexed a page almost 30 minutes before it was linked from anywhere
[01:19] <owh> Keybuk: Perhaps someone read some web-mail with it?
[01:20] <slangasek> jackalope?  I thought the theme was animals, not characters from bad early 90s shows on ABC
[01:20] <Keybuk> slangasek: you don't play the second and far more fun game?
[01:20] <slangasek> hmm?
[01:20] <Keybuk> 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] <slangasek> oh, I don't play either game. :)
[01:21] <Keybuk> kinky koala!
[01:21] <StevenK> I refuse to upload to a release called "kinky"
[01:23] <LaserJock> jaunty is a bit interesting, I instantly think of jaundice
[01:23] <LaserJock> the idea of a jaundiced jackalope just isn't really sounding motivating ;-)
[01:23] <cody-somerville> http://www.engadget.com/2008/03/21/ubuntu-hardy-heron-8-04-released-in-beta/
[01:23] <slangasek> that's... odd
[01:24] <cody-somerville> Interesting, someone suggested it Mar 21st 2008 5:02AM
[01:24] <Keybuk> cody-somerville: it's a common suggestion actually, shows up in the forums
[01:24] <Keybuk> there aren't many animals or adjectives for j anyway
[01:25] <slangasek> that thread shows a reasonable number of real animals as options. :)
[01:25]  * cody-somerville is off to party in Boston :P:
[01:25] <Keybuk> enjoy
[01:25] <bddebian> Jumpy Jackrabbit
[01:28] <LaserJock> Jittery would have been fun
[01:29] <bddebian> I was thinking that too but couldn't think of an animal :)
[01:29] <LaserJock> I could have gotten behind Jittery Jackalope
[01:49] <TheMuso> PulseAudio 0.9.12 just released, and heading to my PPA shortly.
[01:50] <RAOF> TheMuso: Cool.  That makes it easier :)
[01:50] <TheMuso> 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] <ScottK> 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] <slangasek> 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] <StevenK> cjwatson: IMHO, no.
[02:22] <cjwatson> 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] <cjwatson> 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] <jelmer> cjwatson: and forward it upstream?
[02:24] <jelmer> if applicable, of course
[02:24] <cjwatson> and all the rest of it, yes
[02:25] <cjwatson> (do not interpret exclusion from my list as anything other than "cjwatson forgot to mention it")
[02:25] <jelmer> heh, ok
[02:26] <owh> 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] <cjwatson> 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] <cjwatson> 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] <owh> Excellent.
[02:27] <lifeless> 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] <lifeless> cjwatson: because its a patch against the build system, not the code per se
[02:28] <cjwatson> lifeless: the target of bug reports is not typically testers
[02:28] <lifeless> cjwatson: cause or effect :P
[02:28] <cjwatson> lifeless: let's take bug 267103 as an example
[02:28] <cjwatson> starts off with a suggested patch (incidentally in debdiff form), fair enough
[02:29] <lifeless> cjwatson: ok, so a FTBFS can be autotested if there is a debdiff patch
[02:29] <lifeless> cjwatson: whereas a human is required for a non-debdiff patch, with current facilities
[02:30] <cjwatson> 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] <cjwatson> ... resolve the conflict
[02:30] <lifeless> sure
[02:30] <cjwatson> the original submitter then reformulates this as a debdiff, whereas in fact this has negative utility
[02:31] <lifeless> I guess I'm making a philosophical point
[02:31] <lifeless> as for the debian/changelog conflict, that is surely programtically mergable
[02:31] <cjwatson> or bug 264471, where Evan submits a perfectly good patch, and somebody transforms it into a debdiff with no additional value
[02:31] <cjwatson> 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] <cjwatson> a human being required to review a patch is a feature
[02:32] <cjwatson> we do not want to automatically merge patches
[02:32] <lifeless> agreed; for inclusion to trunk
[02:32] <lifeless> I'm totally behind that
[02:32] <cjwatson> I think what you're missing is that many of the cases at hand are utterly trivial
[02:34] <cjwatson> 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] <lifeless> oh, getting what you measure for
[02:34] <StevenK> Because a debdiff gives a changelog with the all important their name in it
[02:34] <cjwatson> 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] <cjwatson> particularly when they are transforming a patch that was already submitted by another developer
[02:35] <lifeless> 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] <cjwatson> StevenK: *exactly*
[02:35] <lifeless> because I think its impossible to write good predefined criteria, but totally possible to say to sane folk "Is person X ready"
[02:36] <lifeless> I didn't realise that that concept had degraded so far :(
[02:36] <cjwatson> I understand the need to have some mechanical assistance in assessing readiness, since there are a lot of people involved
[02:37] <lifeless> I don't understand that yet, having followed NM for quite some time
[02:37] <cjwatson> 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] <lifeless> hmm, in the asia membership board we look at what folk have done; I don't have a scale for it though
[02:38] <cjwatson> 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] <lifeless> mainly 'lots' vs 'little' and 'trivial' vs 'ongoing'
[02:39] <cjwatson> 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] <lifeless> thats definitely a problem, reviewing is something that takes practice, and knowing whats good vs bad
[02:39] <cjwatson> exactly
[02:41] <cjwatson> 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] <owh> 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] <lifeless> cjwatson: my pleasure :)
[02:51] <NCommander> cjwatson, I assume you've gone to bed?
[02:52]  * owh annotated the concerns http://ubuntu.pastebin.com/m32b6d894
[02:55] <owh> Does my concern make any sense to anyone, or am I just dribbling?
[02:57] <cody-somerville> That pastebin is useless w/o context.
[02:58] <owh> cody-somerville: What kind of context is needed for it to become useful?
[02:58] <cody-somerville> owh, probably the entire sourcefile if not more :P
[02:58] <owh> 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] <owh> 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] <cody-somerville> Maybe thats correct?
[03:01] <owh> 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] <owh> But you raise an interesting point, which I had not considered.
[03:02] <owh> So, I'll go ask the person who added it to Debian :)
[03:05] <cody-somerville> owh, yea, I'd say it is intentional
[03:05] <owh> cody-somerville: What makes you conclude that?
[03:06] <cody-somerville> because all the if statements have been changed to compare against slot instead of lfn->id & LFN_ID_SLOTMASK
[03:08] <sistpoty> 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] <sistpoty> the point not solved imho boils down to what which person did, and hence is technically knowing about s.th.
[03:08] <owh> cody-somerville: Which is covered by the assignment at the top.
[03:08] <StevenK> sistpoty: Just adding a changelog to a patch does not mean it's worth brownie points
[03:09] <owh> cody-somerville: But it's the only place where the meaning changes.
[03:09] <sistpoty> 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] <cody-somerville> owh, The meaning isn't changing.
[03:10] <cody-somerville> owh, the patch is correct
[03:10] <sistpoty> StevenK: nonetheless, I agree that it's only a small piece of a brownie
[03:10] <owh> cody-somerville: The meaning *is* changing because lfn->id changes.
[03:11] <sistpoty> 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] <cody-somerville> owh, I'm not going to argue with you. If you have any further questions about the patch, ask the author.
[03:11] <sistpoty> *dosfsck*
[03:12] <owh> sistpoty: Huh?
[03:13] <owh> cody-somerville: I will ask the author, but thanks for your eyeballs.
[03:15] <sistpoty> 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] <owh> Yup, that was me :)
[03:15] <sistpoty> heh
[03:15] <owh> Ah, so that was a compliment :)
[03:15]  * owh blushes
[03:15] <sistpoty> 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] <owh> IIRC we both had out boot-prints all over that patch sistpoty :)
[03:17] <sistpoty> owh: yes, and it was great imho :)
[03:17] <owh> It fixed stuff and people cheered - all good :)
[03:18] <owh> sistpoty: I still haven't gotten to the bottom of codepages and dosfsck yet - so if you're bored :)
[03:19] <sistpoty> 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] <owh> 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] <sistpoty> heh, sounds like fun :(
[03:22] <owh> Hey, if I can fix one dosfstools bug per quarter, I'm doing more than most :)
[03:26] <owh> How do I unsubscribe the ubuntu-sru from a bug?
[03:26] <ScottK-laptop> You have to be in ubuntu-sru to do it.
[03:29] <owh> So, I can subscribe them, but not unsubscribe them - joy :(
[03:31] <ScottK-laptop> Yes.
[03:31] <sistpoty> 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] <owh> Heh
[03:32] <owh> 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] <sistpoty> 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] <sistpoty> (and I agree after having heard more on why the warning does make sense)
[04:01] <sistpoty> heck, short reads even *g*
[05:01] <cody-somerville> 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] <RAOF> With gpg-agent, I would assume.
[05:04] <cody-somerville> RAOF, thanks :)
[05:12] <NCommander> cjwatson, you around?
[05:12] <NCommander> Does anyone know if backports are available on unoffical architectures?
[05:12] <calc> its 6am there so probably not
[05:13] <calc> and i dunno about the question
[05:13] <calc> i only use amd64/i386, i have a m68k but its about as useful as a doorstop
[05:14] <NCommander> calc, you do know I am a debian m68k porter ...
[05:14] <calc> NCommander: oh, no offense, i have a quadra 840av it doesn't have dma disk support
[05:14] <calc> NCommander: i can type faster than it can display when its doing disk io
[05:14] <NCommander> calc, that's being worked on now int he 2.6 branch
[05:14] <calc> and i can barely touch type ;-)
[05:14] <calc> cool :)
[05:15] <calc> 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] <NCommander> calc, I plan to port Ubuntu to m68k ...
[05:15] <calc> good luck :)
[05:15] <calc> fluxbuntu might work ;-)
[05:16]  * calc somehow doubts getting gnome onto it will work
[05:16] <NCommander> Xubuntu is likely
[05:16] <NCommander> We did build KDE on m68k
[05:27] <calc> 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] <NCommander> calc, well, at the moment, have an interest of getting backports available for PowerPC and the other port architectures
[05:38] <cjwatson> NCommander: backports are built for all ports
[05:39] <NCommander> cjwatson, I can't find lpia on us.archive.ubuntu.com or ports.ubuntu.com
[05:40] <NCommander> oh wait
[05:40] <NCommander> I'm an idiot :-)
[05:40] <NCommander> cjwatson, your a kubuntu developer, right?
[05:40] <cjwatson> look harder ... http://ports.ubuntu.com/ubuntu-ports/dists/hardy-backports/main/binary-lpia/
[05:40] <cjwatson> NCommander: no
[05:41] <NCommander> ok :-/. I have a FTBFS for kdenetwork for hardy on lpia
[05:41] <NCommander> ^fix
[05:41] <cjwatson> well, I am in the sense that I have upload privileges to all of Kubuntu, but I don't use it
[05:43] <NCommander> cjwatson, heh, Ok, no problem, I'll just wait for ScottK to reappear
[05:44] <NCommander> cjwatson, do chroot problems build features (marked as chroot problems) get auto-retried, or does someone need to do it?
[05:48] <cjwatson> NCommander: I don't think it's automatic, but often enough whoever fixes the chroots just gives everything back
[05:51] <NCommander> ah
[05:51] <NCommander> I feel like doing something productive :-/
[05:52] <NCommander> cjwatson, know any good todos?
[05:52] <Hobbsee> chroot problems get done automatically, afaik.
[05:52] <Hobbsee> i think, anyway
[05:53] <cjwatson> NCommander: I only just woke up, and it's before 6am ... not so much
[05:54] <Hobbsee> cjwatson: you were meant to answer with all teh work you had to do :)
[06:09] <dholbach> good morning
[07:35] <lool> 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] <pitti> Good morning
[08:00] <StevenK> Morning pitti
[08:02] <persia> 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] <lool> 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] <pitti> persia: hm, I don't have particular knowledge about it; mvo is the maintainer, I think you should talk directly to him
[08:04] <persia> pitti: Just hoping you might know as it's early yet :)  Thanks.
[08:42] <persia> 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] <mvo> persia: update-manager in the archive and in bzr are not in sync ?
[08:44] <persia> 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] <mvo> persia: oh, that is bad, let me check how that happend
[08:45]  * mvo hugs dholbach
[08:45] <dholbach> :-)
[08:45]  * persia looks for Riddell
[08:45]  * dholbach hugs mvo back
[08:46] <mvo> persia: I really don''t like it when the packages gets out of sync
[08:47] <persia> 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] <mvo> persia: let me please first check what happend
[08:49] <persia> mvo: OK.  Let me know, and I'll push my changes.
[08:49] <mvo> 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] <mvo> persia: thanks, where is the branch that you want to be merged? (what location)
[08:51] <persia> mvo: I haven't pushed yet, because of the confusion.  I'll update the changelog and push now.
[08:51] <mvo> persia: ok, thanks
[08:58] <pitti> doko: wow, uploading gcc at 5:40 in the morning? :-)
[08:58] <pitti> hey seb128
[08:58] <seb128> hello pitti
[09:37] <evand> slangasek: yes, I plan to file a MIR in the morning.
[09:55] <cjwatson> jdstrand: I'd appreciate it if you could have a look at bug 262451 for your next ufw upload
[09:57] <tjaalton> so what do I have to do to get xserver 1.5.0 accepted?
[09:59] <cjwatson> tjaalton: file bug describing changes and asking for exception, subscribe ubuntu-release
[10:01] <tjaalton> cjwatson: k, will do
[10:16] <tjaalton> cjwatson: I can upload it already so it's ready in the queue?
[10:36] <Riddell> mvo: update-manager merged
[10:37] <mvo> Riddell: thanks
[10:39] <StevenK> mvo: Upload it :-)
[10:51] <mvo> StevenK: I will, almost ready
[10:55] <cjwatson> 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] <tjaalton> cjwatson: ok, in that case I won't upload
[11:01] <tjaalton> 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:32] <amitk> soren: kvm still crashes when shutting down a VM (windows xp). 6 apport pop-ups come up before it actually shuts down.
[11:33] <soren> Wow. :)
[11:33] <amitk> soren: bug #259336
[11:34] <amitk> soren: anything I can do to help debug?
[11:35] <amitk> so new kernel isn't changing things much for me
[11:41] <soren> amitk: I forget... This is with kvm 72 userspace and kernel modules as well?
[11:45] <amitk> soren: Version: 1:72+dfsg-1ubuntu2
[11:45] <soren> amitk: And kernel?
[11:45] <amitk> soren: 2.6.27-2-generic
[11:45] <soren> amitk: Could you try installing kvm-source?
[11:46] <soren> It does the dkms thing to provide more up-to-date modules.
[11:51] <amitk> soren: nice! much better, with and withoug kvm-intel module. No crashes.
[11:51] <amitk> *without
[11:52] <soren> amitk: Without the kvm-intel module? Then you're in qemu-mode => very, very slow.
[11:55] <amitk> 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] <TheMuso> 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] <pitti> TheMuso: sounds like bug 267682, it has a few pieces of information
[12:03] <TheMuso> pitti: Thanks, will have a read.
[12:08] <slytherin> dholbach: Any idea who handles bluetooth packaging currently?
[12:09] <TheMuso> pitti: Is this bug also related to not seeing volume/brightness indicators hon screen when pressing such keys?
[12:09] <pitti> TheMuso: ATM they don't do anything at all, right?
[12:09] <pitti> TheMuso: well, on some models they are hardwired
[12:09] <TheMuso> pitti: Well the volume/brightness gets changed, but no indicator is displayed.
[12:10] <pitti> so they will have an effect, but the GUI doesn't notice them
[12:10] <pitti> same bug in the end, yes
[12:10] <TheMuso> Yep.
[12:10] <TheMuso> Right, I don't know enough about those bits to be sure, thanks.
[12:12] <soren> amitk: Lovely. That's very useful input. Thanks!
[12:13] <dholbach> slytherin: #ubuntu-mobile I'd say
[12:14] <slytherin> dholbach: waiting for StevenK there. :-)
[12:16] <doko> pitti: didn't arrive yet in my time zone :-/
[12:28] <StevenK> mvo: update-manager wants nvidia-common!?
[12:29] <ogra> StevenK, lrm uses it iirc
[12:30] <StevenK> nvidia-common is only on amd64 and i386
[12:31] <StevenK> mvo: There's no nvidia-common on lpia
[12:32] <ogra> why ?
[12:32] <ogra> there might be lpia devices with nvidia onboard cards at some point
[12:32] <StevenK> Because it's Architecture: i386 amd64
[12:32] <ogra> right, that needs fixing imho
[12:32] <ogra> though it might be tricky with binary drivers :)
[12:33] <StevenK> nvidia-common itself is tiny
[12:45] <mvo> StevenK: it needs it just for the modinfo stuff
[12:45] <mvo> StevenK: ok, if lpia does not have nvidia anyway, then I need to patch that out
[12:48] <tjaalton> 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] <tjaalton> this will fix the problems with ABNT2 & jp106 models
[12:48] <Riddell> slangasek: let me know if you work out what caused the samba4 compile error, we have the same problem in kde4libs
[12:48] <StevenK> mvo: Well, ogra has a good point, but patch it out.
[12:48] <tjaalton> (once the evdev rules in xkb-data are updated)
[12:48] <pitti> tjaalton: sure, please go ahead; please use UNRELEASED, dch --release, and debcommit --release if you upload yourself
[12:48] <ogra> to date there are no such devices yet
[12:49] <ogra> so we might be able to ignore it for now
[12:49] <StevenK> ogra: That's my plan
[12:49] <StevenK> mvo: Ping me when you upload it
[12:49] <tjaalton> pitti: yes, I'm reading the "bzr packaging" session logs now to see how things are done :)
[12:49] <StevenK> ogra: And I daresay fast 3D is not a first level requirement :-)
[12:50] <ogra> heh, yeah
[12:50] <mvo> 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] <pitti> 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] <tjaalton> mvo: this will let people to change the model again, and not force evdev
[12:50] <tjaalton> pitti: sure, thanks
[12:51] <mvo> tjaalton: aha, ok. is there work on gnome-control-center required for this too?
[12:51] <tjaalton> 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] <TheMuso> 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] <mvo> tjaalton: ok, thanks
[12:52] <seb128> TheMuso: http://bugzilla.gnome.org/show_bug.cgi?id=507101
[12:52] <TheMuso> seb128: Thanks.
[12:53] <seb128> 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] <TheMuso> seb128: Ok, thanks for letting me know.
[12:54] <seb128> 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] <seb128> let him know if there is any issue, he will probably be interested by those
[12:54] <TheMuso> seb128: Ok thanks.
[13:07] <asac> cjwatson: @multiple active devices: do you see packet loss? or do you just assume that you loose packets?
[13:08] <asac> 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] <asac> if they are on the same subnet, kernel should use whatever was there first
[13:09] <asac> 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] <asac> cjwatson: so if you have other arguments against "multiple active" devices other than packet loss, please let me know ;)
[13:12] <pitti> asac: does "active connection" translate to "multiple defaultroutes"?
[13:13] <asac> pitti: yeah
[13:14] <asac> pitti: hmm
[13:14] <asac> pitti: strange. actually thats not the cas
[13:14]  * asac confused
[13:14] <asac> i think i have to wait for the NM boss to shed a light on this
[13:14] <pitti> asac: hm, if not, how else do they work then?
[13:15] <kwwii> 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] <pitti> kwwii: the build log should help, if you can send the URL
[13:16] <pitti> kwwii: I'm about to go to lunch, ok to deal with this in an hour?
[13:16] <cjwatson> asac: yes, I get packet loss
[13:16] <pitti> cjwatson: did you get multiple default routes with the same metric from nm then?
[13:16] <cjwatson> I think it's that the acks come back on the wrong route or something like that
[13:18] <kwwii> pitti: sure, no worries
[13:18] <cjwatson> pitti: I don't recall, but can test when I get home
[13:19] <kwwii> pitti: it seems to want intltool >= 0.37.1 but not get it
[13:19] <kwwii> http://launchpadlibrarian.net/17439954/buildlog_ubuntu-hardy-i386.gtk2-engines-murrine_0.60-0ubuntu1%7Eppa2_FAILEDTOBUILD.txt.gz
[13:20] <pitti> kwwii: hm, hardy has 0.37.1-1ubuntu1
[13:21] <pitti> checking for intltool >= 0.37.1... ./configure: line 11320: intltool-update: command not found
[13:22] <pitti> kwwii: I rather think that your package is missing an intltool build dependency altogether
[13:22] <kwwii> pitti: ahhh, that would be it...let me check
[13:22] <pitti> kwwii: it seems to pull in intltool-debian rather, whatever that is, and it is 0.35.something
[13:23] <pitti> bah, why does such a thing even exist? the patch should be in the main intltool package
[13:23] <kwwii> pitti: freaky, in the earlier svn snapshots that wasn't a problem
[13:23] <kwwii> I do not have it in my build depends, I assume I should add it there
[13:23] <pitti> kwwii: I guess they raised the required intltool version recently?
[13:24] <asac> cjwatson: ok so i understood correctly. could you attach the route table and the syslog taken after you reproduced this to bug 262152?
[13:24] <asac> thanks
[13:25] <cjwatson> asac: will do. FWIW they are on different subnets
[13:26] <pitti> mpt: just mailed you back wrt. the jockey UI (with screenshot)
[13:26] <asac> cjwatson: ah ok. then thats why i dont see multiple default routes here
[13:26] <pitti> lunch o'clock, bbl
[13:26] <mpt> ok
[13:59] <StevenK> mvo: Thank you for the quick 0.93.3 upload. *hugs*
[14:12] <zyga_> hello, are there any .mac/idisk like projects for ubuntu?
[14:26] <jdstrand> cjwatson: re ufw> sure
[14:37] <kirkland> cjwatson: hey
[14:37] <cjwatson> kirkland: yo
[14:38] <kirkland> cjwatson: I was hoping to find a server iso built overnight
[14:38] <kirkland> cjwatson: to test grub-installer from the ISO
[14:38] <kirkland> cjwatson: any idea why one didn't build?  or when the next one might?
[14:39] <pitti> mpt: thanks for your UI feedback; I'll fix the small things later, I first want to have something to present for a FF exception; do you think the general structure/design is ok now?
[14:40] <cjwatson> kirkland: did you check the build logs?
[14:40] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
[14:40] <kirkland> cjwatson: thanks, i'll check; didn't have that url
[14:41] <mpt> pitti, sure
[14:41] <cjwatson> should be ubuntu-server/intrepid/daily-*.log under that, or some such
[14:41] <kirkland> cjwatson: i'm on it ;-)
[14:42] <slytherin> kirkland: The last I checked no CD was built on 9th
[14:42] <cjwatson> sly	yes, he wants to know why
[14:43] <slytherin> right, I just wanted to say that it was not specific to server image
[14:45] <tseliot> pitti: are you going to include the support for x-kit in the FFE?
[14:46] <pitti> tseliot: it will be a separate request
[14:46] <dholbach> pitti: do you know anything new about seahorse-agent? :-)
[14:46] <tseliot> pitti: ok, if you need a hand just let me know
[14:46] <pitti> dholbach: just that it works wonderfully :)
[14:47] <dholbach> oh?
[14:47] <cjwatson> kirkland: looking at it myself, I can't say it's obvious
[14:47]  * dholbach installs seahorse-plugins
[14:47] <pitti> dholbach: apt-get install seahorse-plugins
[14:47] <kirkland> cjwatson: i'm not seeing anything either
[14:47] <pitti> dholbach: I discussed that with seb128, it will become a seahorse depends/recommends, but I think it isn't yet
[14:48] <seb128> pitti: yeah, forgot to change that yesterday, feel free to do so
[14:48] <cjwatson> looks like check-installable is falling over
[14:48] <dholbach> pitti, seb128: thanks for taking care of it
[14:48] <cjwatson> but why no error message, I'm not sure
[14:48] <pitti> seb128: sure, taking the 'lock' on it now
[14:48] <kirkland> cjwatson: yeah, just hangs there....
[14:49] <cjwatson> no evidence that it hangs, though, it just exits
[14:49] <tseliot> pitti: does Jockey (with guidance) touch the ServerLayout section in the xorg.conf?
[14:49] <cjwatson> though there are some old hung processes
[14:50] <tseliot> pitti: have a look at this bug report: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/261816
[14:52] <cjwatson> kirkland: trying a manual run to see what happens
[14:52] <kirkland> cjwatson: thanks a lot
[14:53] <pitti> dholbach: FYI, uploaded with the recommends
[14:54] <dholbach> pitti: rock on
[14:54] <pitti> tseliot: no, it doesn't
[14:55] <tseliot> pitti: ok, I just wanted to be sure
[14:56] <pitti> tseliot: indeed, no idea how it came there
[14:56] <cjwatson> kirkland: oh, it was hung actually. not sure why
[14:56] <cjwatson> unfortunately now that I've realised it was hung I've already destroyed the evidence; maybe it'll do it again
[14:57] <tseliot> pitti: I'll see if it has something to do with xorg autoconfiguration
[14:57] <cjwatson> slytherin: BTW the Ubuntu (non-server) dailies built fine today, so I'm not sure what you mean
[14:57] <cjwatson> slytherin: maybe you just looked too early in the day, before the cron jobs went off
[14:58] <cjwatson> kirkland: and there it goes, publishing fine now, no idea what was wrong :-(
[14:58] <kirkland> cjwatson: if by "evidence" you mean the build log, I still have it cached in my browser
[14:59] <cjwatson> I meant the state of the running processes. The build log is kept anyway
[14:59] <kirkland> ah
[14:59] <cjwatson> kirkland: anyhow, ISOs will appear under http://cdimage.ubuntu.com/ubuntu-server/daily/20080909.1/ shortly
[15:00] <doko> pitti: these rebuild tests are a pita ... for now I find unrelated problems, but none with the compiler.
[15:00] <doko> - pygtk ftbfs even with the existing hardy setup
[15:01] <doko> - perl fails due to a buildd misconfiguration, letting one test fail (don't know how this was built at all)
[15:04] <jdstrand> cjwatson: hi! I should have the fix for bug #262451, but wanted to make sure my test environment reflected that of the bug
[15:05] <jdstrand> cjwatson: it simply appeats that iptable_filter is not available, and that ufw is not enabled yet
[15:05] <cjwatson> my test environment is ... how can I put this, not as reduced as it might be
[15:05] <cjwatson> if ufw isn't enabled, why is it touching iptables-restore?
[15:05] <StevenK> My minimal chroot isn't any more.
[15:05] <jdstrand> cjwatson: that is indeed the bug
[15:05] <jdstrand> cjwatson: which was introduced in some cleverness in my application integration
[15:06] <StevenK> I had a plan to find stuff in the chroot that ubuntu-minimal didn't pull in and purge it. Not sure how yet.
[15:06] <jdstrand> (I forgot an _is_enabled() check)
[15:07] <cjwatson> jdstrand: ah, right
[15:08] <jdstrand> cjwatson: actually, just this little conversation is enough for me. thanks!
[15:08] <MacSlow> damn
[15:08] <cjwatson> jdstrand: I'm away from my normal environment, but I think doing a netboot install, selecting the desktop task, and putting pkgsel/include=openssh-server on the kernel command line should reproduce it
[15:08] <cjwatson> jdstrand: dpkg might not actually fail, as I think that part's more sensitive, but you should be able to spot the ufw trigger failure in the syslog
[15:09] <cjwatson> however I haven't had time to narrow it down yet - I only realised that that was the proximate cause at obscene o'clock this morning
[15:10] <jdstrand> cjwatson: I appreciate it, and sorry you had to deal with this bug at that time of the morning :(
[15:10] <cjwatson> jdstrand: meh, I wasn't up just to deal with that; I was preparing to catch a train and trying to wake up. (obscene being early not late)
[15:11] <mvo> StevenK: is update-manager on lpia fine now?
[15:11] <StevenK> mvo: Yes, thanks :-)
[15:11] <mvo> excellent!
[15:11] <MacSlow> evand, any bug know from the cd-image of 3rd of sep. regarding to the grub-installation on the harddisk?
[15:12] <MacSlow> evand, just wondering if it's something like that or just a hosed cd-r
[15:12] <jdstrand> cjwatson: it'll get uploaded today
[15:13] <cjwatson> jdstrand: great, thanks
[15:13] <cjwatson> MacSlow: what's the failure?
[15:14] <MacSlow> cjwatson, after the installation it just does not boot and grub reports an error ... I'll try another cd-r of a newer cd-image
[15:15] <cjwatson> which error? grub can report several
[15:15] <cjwatson> you never win by paraphrasing error messages :)
[15:15] <MacSlow> one sec
[15:15] <evand> heh
[15:15] <MacSlow> cjwatson, evand: it's "Error 15"
[15:16] <MacSlow> GRUB Loading stage1.5.
[15:16] <MacSlow> GRUB loading, please wait...
[15:16] <MacSlow> Error 15
[15:16] <MacSlow> and then it just sits there
[15:16] <cjwatson> error 15 translates to "file not found" from grub and often means that grub is being pointed to the wrong disk or partition
[15:17] <MacSlow> hm ok
[15:17] <cjwatson> do you have multiple disks in this machine, or a USB stick inserted?
[15:17] <MacSlow> cjwatson, no just one disc with several partitions
[15:18] <cjwatson> hm, not sure why that would happen with a single disk
[15:18] <MacSlow> cjwatson, I am in the middle of updating the hardy-installation to intrepid and wanted to use the new installer
[15:18] <dholbach> seb128, pitti: works nicely!
[15:18] <seb128> dholbach: excellent ;-)
[15:21] <evand> MacSlow: was this using the /home preservation functionality in the installer?  That is, did you go to the advanced partitioning page and uncheck the format boxes?
[15:22] <MacSlow> evand, yes
[15:23] <evand> hrm, yikes.
[15:23] <MacSlow> evand, did I miss something there?
[15:24] <evand> I'm wondering if that's connected to why grub is failing for you.
[15:25] <MacSlow> I just hope my /home partition is still intact
[15:25] <evand> Can you please file a bug and attach your logs from the install (/var/log/installer/*) as well as a listing of /boot?
[15:26] <MacSlow> evand, ok ... btw the integrity check of the CD returned no errors
[15:27] <evand> ok
[15:28] <didrocks> Hi everyone. I worked on a NBS (icedjava7-jre). Can someone remove it, please? http://people.ubuntu.com/~ubuntu-archive/NBS/icedtea-java7-jre
[15:29] <davmor2> Macslow: daft question but you did set the mount points didn't you?
[15:29] <mathiaz> cjwatson: what does () mean in the seeds ? ex: * (landscape-client)
[15:30] <MacSlow> davmor2, sure
[15:30] <StevenK> mathiaz: Recommends, I think.
[15:30] <davmor2> Macslow: thought you probably would of but it best to check the obvious hasn't been overlooked :)
[15:34] <cjwatson> mathiaz: StevenK is right. See the germinate(1) manual page
[15:35] <mathiaz> cjwatson: StevenK: thanks
[15:40] <pitti> tseliot: do you currently have a branch with only the 'recommended' addition? I'd like to review/merge them separately (x-kit branch comes next)
[15:40] <pitti> tseliot: or a patch, for that matter
[15:42] <MacSlow> evand, I cannot retrieve the contents of /var/log/installer/* only the listing of /boot
[15:43] <MacSlow> evand, I assume that's not enough for a useable bug-report
[15:43] <tseliot> pitti: no, I don't, however you can cherry pick  the commits from 362 to 366 and ignore commit 365: https://code.launchpad.net/~albertomilone/jockey/jockey-generic
[15:43] <evand> MacSlow: odd, is /var/log/installer missing?
[15:43] <pitti> tseliot: ok, thanks
[15:44] <pitti> StevenK: NBS packages cleaned up
[15:45] <MacSlow> evand, on none of hte partitions I can find /var (it used to be a separate partition)
[15:45] <evand> very yikes
[15:45] <MacSlow> evand, I've three partitions that only hold the lost+found directory
[15:46] <MacSlow> evand, well at least my /home partition was left untouched
[15:46] <evand> MacSlow: do me a favor and create a bug report anyway with the listing of /boot and `sudo parted /dev/sda print all`
[15:47] <MacSlow> evand, well at least my /home partition was left untouched
[15:47] <MacSlow> evand, ok
[15:47] <evand> glad to hear that, though sorry about the rest of your partitions
[15:48] <MacSlow> evand, well there's no data loss so it's not much of a problem
[15:49] <MacSlow> evand, against what package should I file it?
[15:50] <evand> hrm, partman-target would probably be best
[15:51] <cjwatson> MacSlow: might also be worth outlining what your partition scheme used to look like as best you can, to aid reproduction
[15:51] <seb128> asac: did you add this nspluginwrapper bugpattern yesterday?
[15:52] <MacSlow> cjwatson, of course
[15:59] <ogra> Riddell, mind o take a look at netbook-launcher in the queue ? http://revu.ubuntuwire.com/details.py?package=netbook-launcher has a revu review already, bug 263493 is the FFe exception (its an ubuntu-mobile pakcgae for which i approve FFe anyway)
[15:59] <ogra> s/o/to/
[16:02] <Riddell> ogra: aww, you spoilt my perfect empty New queue
[16:02] <ogra> sorry :/
[16:04] <asac> seb128: http://paste.ubuntu.com/44929/ ... i didnt find time to properly test it ... if you say that that looks fine i can just commit
[16:06] <Riddell> ogra: :)
[16:06] <Riddell> ogra: it includes a copy of another library, how come that isn't a separate package?
[16:08] <ogra> its a svn checkout that wont go in the normal upstream
[16:08] <asac> seb128: committed
[16:08] <ogra> at least thats how njpatel explained it
[16:08] <Riddell> ogra: seems ugly.  but accepted
[16:09] <ogra> thanks a lot :)
[16:09] <seb128> asac: looks correct to me too
[16:09]  * ogra adds the netbook packages to the seeds
[16:09] <asac> seb128: http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/revision/11
[16:09] <asac> seb128: do we want to upload that?
[16:10] <asac> or will this happen automagically?
[16:10] <tedg> Okay, so when I have an FFe that get accepted, but it needs a sponsor, do I subscribe main-sponsors to the FFe or create another bug?
[16:10] <pitti> tedg: just sub'ing u-m-s is sufficient
[16:10] <seb128> asac: I think it's using the only datas
[16:11] <seb128> s/only/online
[16:11] <asac> oh cool
[16:12] <Riddell> asac: knm issue.  knetworkmanager might get some work done on it in a couple of weeks so we can wait and hope that happens before beta, fix it ourselves (likely beyond my ability) or revert back to a nm daemon that we know works
[16:12] <asac> Riddell: yeah. NM finally stabilizes
[16:12] <tedg> pitti: Thanks.  Done.
[16:12] <asac> so there is hope that we dont need to run after it
[16:13] <Riddell> asac: mm hmm, but as it stands we have a version that doesn't work with knm
[16:13] <tkamppeter> pitti, hi
[16:13] <asac> Riddell: where is the knetworkmanager svn?
[16:14] <asac> Riddell: NM 0.7 finally has a final release date: 4 weeks from now. i guess knetworkmanager will be fixed for that.
[16:16] <Riddell> asac: http://websvn.kde.org/branches/work/knetworkmanager/
[16:16] <asac> Riddell: it is you who committed 4 hours ago?
[16:16] <asac> ;)
[16:16] <Riddell> yeah I added a compile fix
[16:16] <MacSlow> evand, there you go https://bugs.edge.launchpad.net/ubuntu/+source/partman-target/+bug/268186
[16:16] <Riddell> hschaa is the main developer but he's away for at least a couple of weeks
[16:17] <asac> Riddell: the changes NM did since it worked shouldnt be that intrusive
[16:17] <asac> Riddell: mostly some dbus API changes
[16:17] <asac> Riddell: which dont really add new features
[16:18] <asac> Riddell: is there an easy instruction on how to build that?
[16:18] <asac> Riddell: last time it was too tricky for me :(
[16:18] <asac> (as you might remember)
[16:18] <tkamppeter> pitti, it is about driver auto-download (https://blueprints.edge.launchpad.net/ubuntu/+spec/jockey-printer-driver-support)
[16:19] <pitti> tkamppeter: hi
[16:20] <tkamppeter> Yo write that s-c-p does not have the D-Bus interface yet. Did you talk with Tim Waugh about that?
[16:20] <zyga_> (again) are there any .mac/idisk like projects for ubuntu?
[16:20] <pitti> tkamppeter: s/have/use/; no, I didn't talk with him about it yet (not since our meeting in London)
[16:20] <pitti> tkamppeter: I want to get the 0.5 jockey release out (with that feature) first
[16:20] <pitti> tkamppeter: still working on some bits, and I want to stabilize the interface
[16:21] <Riddell> asac: svn co svn://anonsvn.kde.org/home/kde/branches/work/knetworkmanager/
[16:21] <evand> MacSlow: thanks
[16:21] <tkamppeter> Will the 0.5 Jockey go into Intrepid?
[16:21] <asac> Riddell: yeah. i got that  ;)
[16:21] <Riddell> asac: cd knetworkmanager; cp -r kdetoys/admin .
[16:21] <Riddell> asac: from your local copy of kdetoys that I'm sure you have
[16:21] <MacSlow> evand, I hope it's at least of some use to you
[16:21] <asac> Riddell: i am sure i dont have that ;)
[16:22] <asac> Riddell: have never heard of it before ;)
[16:22] <pitti> tseliot: btw, I just committed some robustifications for the jockey trunk test suite
[16:22] <pitti> tseliot: in your mail you mention that two tests fail; do they fail for you on trunk as well, or just after your modifications? in the former case, I'd like to find out and fix it
[16:22] <pitti> tseliot: well, in the latter case as well, of course, but then we need to look at some different place
[16:23] <Riddell> asac: well any copy of that admin directory, it's in svn somewhere of course but I can never remember where (I should find it and set the svn external really)
[16:23] <Riddell> asac: make -f Makefile.cvs; ./configure --prefix=/usr
[16:25] <asac_> Riddell: reconnect :/
[16:25] <MacSlow> evand, I'll grab a recent cd-image and try again
[16:25] <Riddell> asac: well any copy of that admin directory, it's in svn somewhere of course but I can never remember where (I should find it and set the svn external really)
[16:25] <Riddell> asac: make -f Makefile.cvs; ./configure --prefix=/usr
[16:25] <tseliot> pitti: I have modified the code in trunk and and in the ubuntu specific branch and in both cases the 2 tests fail only after my modifications
[16:26] <pitti> tseliot: ok, I should be able to reproduce that then, will have a look
[16:26] <tseliot> ok
[16:26] <asac_> Riddell: i think the admin directory was what bit me in london :/
[16:26] <pitti> tseliot: does the test suite in trunk run successfully for you now?
[16:26] <asac_> i dont feel confident that i can bootstrap that without much fiddling
[16:26] <asac_> Riddell: how are the packages built?
[16:27] <asac_> do they ship that admin dir?
[16:27] <tseliot> pitti: let me try again, just to be sure
[16:27] <Riddell> asac_: yes, I add it
[16:28] <Riddell> asac_: it's just like gnome-common or whatever it's called, but it should be set with an svn external
[16:28] <pitti> tseliot: ok, I reviewed the recommended branch, that looks fine
[16:28] <tseliot> pitti: great
[16:31] <tseliot> pitti: FAILED (failures=2, errors=3), however no test regarding the xorg.conf is involved
[16:31] <pitti> tseliot: ugh; let's take this to /msg
[16:31] <tseliot> ok
[16:32] <tkamppeter> pitti, Will the 0.5 Jockey go into Intrepid?
[16:32] <pitti> tkamppeter: most probably, yes
[16:33] <tkamppeter> pitti. is the DBUS API for s-c-p already defined or are you still working on it?
[16:37] <sbalneav> tkamppeter: Hey, some time ago I bumped into a bug in Cups, I've submitted a patch upstream: http://www.cups.org/str.php?L2831, patch fixed multi-tray printing for OpenOffice.org in hardy.  Would you be interested in me filing a LP bug so an SRU can go through?
[16:40] <Riddell> asac: yay, I worked out how to set the external so admin gets included with a checkout now (although it'll take 10 minutes to get into anonsvn)
[16:40] <pitti> tkamppeter: no, that's defined and works, just not documented properly yet
[16:41] <tkamppeter> pitti, what do you think about an SRU for cups about CUPS bug 2831 (as sbalneav asks for) and also for bug 218663?
[16:43] <tkamppeter> pitti, could you document the DBUS API quickly so that we can make a patch for s-c-p to trigger Jockey for driver download?This would enable especially network printers to make use of driver download.
[16:44] <pitti> tkamppeter: I'll respond later, need to finish something and have a phone call
[16:49] <asac> Riddell: ok. then its just the make line above?
[16:49] <Riddell> asac: yes
[16:50] <Riddell> asac: apt-get build-dep knetworkmanager first will help
[16:50] <asac> Riddell: yeah. thats clear
[17:02] <thom> doko: are you likely to look at LP:264808 before intrepid release?
[17:04] <samtb> i'm trying to create a bzr branch of mplayer so i can create personal packages that track the official releases but some of the launchpad branches don't seem to be setup and others give bzr: not a branch
[17:04] <samtb> could someone please explain what the setup is on launchpad?
[17:05] <tjaalton> pitti: so, I did the change in hal, now I should run bzr co, then dch --release, a new bzr co or?
[17:05] <doko> thom: hmm, was not yet on my radar ...
[17:08] <thom> doko: ok; i'll dig a bit and see if i can cook up a patch
[17:09] <samtb> e.g. ubuntu-hardy says "this branch has not been pushed yet" on the lp page - the next best option appears to be plain mplayer/ubuntu which gives "not a branch" with bzr
[17:10] <cjwatson> lp:~ubuntu-dev/mplayer/ubuntu looks right; I checked that out and made a change to it the other day
[17:10] <cjwatson> lp:mplayer is the upstream source; lp:~ubuntu-dev/mplayer/ubuntu is the current version in Ubuntu
[17:10] <samtb> that's what i thought - really i want hardy for the moment, but i don't mind getting more recent updates
[17:10] <doko> thom: there are two things: fixing ant, and maybe changing OpenJDK to generate byte code for1.5.
[17:10] <cjwatson> the other branches are things other people have created for one reason or another, and may or may not be sane
[17:10] <samtb> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ubuntu-dev/mplayer/ubuntu/.bzr/branch/".
[17:11] <cjwatson> samtb: what is your bzr command?
[17:11] <tjaalton> pitti: and I can't commit, "cannot lock Lockdir($url): transport operation not possible..."
[17:11] <samtb> bzr branch lp:~ubuntu-dev/mplayer/ubuntu dev
[17:11] <samtb> or co
[17:12] <samtb> note that it works for the trunk
[17:12] <samtb> or for nhandler's version
[17:12] <samtb> s/trunk/upstream
[17:12] <cjwatson> samtb: all I can say is that it works for me; you might need to use a newer version of bzr
[17:12] <cjwatson> http://bazaar-vcs.org/Download
[17:12] <slangasek> Riddell: hrm, is there a samba4 compile error that I'm meant to be looking at? :)
[17:13] <cjwatson> it's unusual for the version in hardy not to be good enough, but maybe that's the case here
[17:13] <samtb> bzr from latest hardy... should work surely?
[17:13] <cjwatson> I don't know why it wouldn't; that branch seems to be using a relatively old disk format
[17:13] <cjwatson> oh
[17:13] <cjwatson> samtb: have you done 'bzr launchpad-login YOUR_LP_USERNAME'?
[17:13] <cjwatson> if not, try that, and repeat ...
[17:14] <samtb> i'm using edge.... does that make a difference?
[17:14] <samtb> (no, i will try login
[17:14] <tjaalton> pitti: bah, I'll upload and commit later if I get it to work
[17:14] <cjwatson> samtb: so am I
[17:14] <\sh> isn't bzr launchpad_login only for using bzr+ssh ? when not bzr launchpad_logined it should default to http
[17:14] <cjwatson> samtb: it fails over http: for me too, but succeeds for bzr+ssh
[17:14] <cjwatson> \sh: see the comment I just made :)
[17:15] <\sh> cjwatson: that was missing, yes :)
[17:15] <Riddell> slangasek: maybe not, you're in the changelog but I see it's not your upload
[17:15] <james_w> tjaalton: you need to "bind" to a bzr+ssh:// version of the url
[17:15] <samtb> okay.... so i need to use the direct link replacing http with bzr+ssh?
[17:16] <cjwatson> samtb: this feels like something you should ask about on #launchpad or #bzr
[17:16] <james_w> tjaalton: as opposed to a http one, as that is not writeable.
[17:16] <cjwatson> samtb: lp: should work if you've done launchpad-login
[17:16] <cjwatson> but I think this is a bug somewhere ...
[17:16] <tjaalton> james_w: uh, of course
[17:16] <slangasek> Riddell: is it reproducible locally?
[17:17] <cjwatson> oddly, it works for other branches
[17:17] <cjwatson> $ bzr branch http://bazaar.launchpad.net/~ubuntu-core-dev/anna/ubuntu anna
[17:17] <cjwatson> Branched 412 revision(s).
[17:17] <samtb> with my email it says no such user, so i guessed what my username would be and it says no keys registered, which is untrue
[17:17] <Riddell> slangasek: I expect so if you have amd64, the kdelibs one is
[17:17] <cjwatson> samtb: do you have a Launchpad account? (most people who do know what the username is)
[17:17] <slangasek> Riddell: might be header breakage, wouldn't be the first time; but the compiler used to also tell you where the first definition was that's getting overridden, and it's not doing that here
[17:17] <slangasek> (in the samba4 case, that is)
[17:18] <cjwatson> samtb: if you guessed, how can you be certain that that LP account has your SSH keys registered?
[17:18] <samtb> i do have a launchpad account, i have registered ssh keys
[17:18] <samtb> i'm logged in now on edge
[17:18] <samtb> but i log in with email
[17:18] <samtb> and like you said, it works with other branches
[17:18] <cjwatson> samtb: hover over the link with your name in at the top right, just to the left of the "Log Out" button
[17:19] <cjwatson> it should link to https://edge.launchpad.net/~YOUR_USERNAME
[17:19] <samtb> sorry, i'm being dumb, yes i guessed it right
[17:19] <cjwatson> samtb: anyway, I think you do need help from #launchpad or #bzr (not sure which) for why that branch can't be pulled over HTTP
[17:20] <samtb> okay thanks will try over in launchpad
[17:24] <tjaalton> pitti: ok, pushed, although I forgot the debcommit --release -part :)
[17:28] <Bor_Ed> evening. is it too late to request device support for 8.10 intrepid this late on dev state?
[17:32] <thom> doko: argh, it's not just ant of course; there's a tonne of stuff which is 1.6 only now
[17:33] <thom> xalan, xerces are the two obvious ones
[17:33] <doko> yes, falling back to 1.4 or 1.5 is more work
[17:34] <avb> hey
[17:35] <avb> guys, there is a weird bug exists in intrepid for me and i cant decide against what should i place a bug
[17:36] <thom> it's more work but i think going to 1.6 only is gonna cause people a tonne of issues
[17:36] <avb> the problem is that gnome-screensaver locks up machine when its running on pc with intel videocard
[17:36] <avb> accourding to forum users have it only with i965 chipsets
[17:36] <avb> http://ubuntuforums.org/showthread.php?t=905459
[17:37] <avb> so, there is few things
[17:37] <avb> 1. bug goes away when u disable 'Unredirect Fullscreen windows'
[17:37] <avb> in compiz settings
[17:37] <avb> so, probably bug in compiz
[17:38] <avb> 2. $ glxinfo|grep render
[17:38] <avb> direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
[17:39] <avb> thats a second issue. why for now compiz for i965 starts with LIBGL_ALWAYS_INDIRECT and there is no DRI
[17:39] <avb> so probably a bug in mesa
[17:39] <avb> 3. probably a bug in intel driver
[17:40] <avb> so maybe one of maintainers is here?
[17:40] <avb> and we can find a sence of bug togeather?
[17:43] <cjwatson> Bor_Ed: #ubuntu-kernel's probably a better place, unless it's some particular application that's missing
[17:43] <cjwatson> Bor_Ed: it's not necessarily too late, though cutting it fine
[17:44] <Bor_Ed> cjwatson: thanks for answering... the prob is with v4l-dvb since the mantis driver kit seems to be only choice for most dvb-c and dvb-t cards here and builds without work on 9.10
[17:45] <avb> he
[17:45] <avb> mine second issue
[17:45] <avb> :)
[17:45] <Bor_Ed> cjwatson: just can't build the .deb myself and drop it to the maintainers
[17:48] <cjwatson> Bor_Ed: well, getting a binary .deb is rarely much use, but patches to the source code are welcome
[17:48] <Bor_Ed> cjwatson: no need for patches since the latest released tree builds just fine and work too
[17:48] <cjwatson> Bor_Ed: I can only give generic advice, though - don't know anything much about v4l-dvb myself
[17:51] <Bor_Ed> cjwatson: I have 2.6.27 from the install, build-essential etc and the source builds against them... though it's probably too much work for linux newbie still to locate source and build the stuff... and it's ~270 devices missing from the sys because of that
[17:52] <cjwatson> Bor_Ed: #ubuntu-kernel is a much better place for this
[17:52] <Bor_Ed> cjwatson: I'll try that, thanks
[17:53] <cjwatson> particularly if given very specific information about which hardware isn't working properly and which tree fixing it
[17:53] <cjwatson> fixes
[17:54] <Bor_Ed> gone... thanks again
[18:15] <nrg> does any know if genisoimage's "Directories too deep
[18:15] <nrg> issue is being worked on?
[18:50] <pitti> tjaalton: forgot debcommit --release> no problem, that should happen precisely when you actually upload, to maintain consistency
[18:51] <pitti> tjaalton: bzr co, dch --release, debcommit -r (that will automatically do bzr co)
[18:53] <pitti> tjaalton: just pulled; so, do 'debcommit -r' instead of the second 'bzr co', and all will be good (don't worry for now)
[18:53] <pitti> tjaalton: I retroactively added the 0.5.11-3~ubuntu8 tag
[18:56] <sbalneav>  /win 6
[19:06] <slangasek> bryce_: where do I file a bug about the fact that I can't keep my RWIN key mapped to Compose?
[19:07] <tjaalton> pitti: ok thanks, I need to use bzr more ;)
[19:08] <bryce_> slangasek: hmm
[19:09] <tjaalton> slangasek: I hope the uploads I did a while ago help with that
[19:09] <slangasek> tjaalton: how long ago is "a while ago"?
[19:09] <slangasek> and for which package?
[19:09] <tjaalton> 1-2h
[19:09] <slangasek> ah
[19:10] <tjaalton> now the model is forced as evdev, but with these uploads the evdev driver will use the evdev ruleset instead
[19:10] <slangasek> so I still need to wait for it to be published, then restart my session?
[19:10] <bryce_> slangasek: xkeyboard-config is an okay thing to file keyboard bugs against; often the real bug is somewhere else but we can move them from that
[19:10] <tjaalton> which is new
[19:10] <bryce_> slangasek: yeah
[19:10] <slangasek> what package should I be looking for?
[19:11] <tjaalton> hal/xkb-data/x-x-i-evdev/gnome-settings-daemon :)
[19:11] <tjaalton> all of them
[19:11] <slangasek> heh, ok
[19:12] <ogra> mind you it can take a small centuriy for them to build ...
[19:12] <slangasek> will this also coincidentally fix the fact that my media keys are no longer generating events over dbus, or do I need to file a separate bug on hal for that? :)
[19:12]  * ogra is still waiting for binaries of the packages slangasek approved 24h ago
[19:13] <ogra> the queue is still extremely long ...
[19:13] <slangasek> hmm, really?  I'm surprised it hasn't cleared yet
[19:13] <ogra> 849 for https://launchpad.net/ubuntu/intrepid/+builds?build_text=&build_state=pending
[19:14] <tjaalton> slangasek: xev doesn't show anything?
[19:15] <tjaalton> what about evtest?
[19:15] <jcristau> XKBOPTIONS=compose:rwin should work
[19:15]  * ogra wonders if we shouldnt use dbus-monitor nowadays
[19:15] <slangasek> tjaalton: for the media keys?  It /does/ show keypresses, but hal needs to pick those keys up and translate them into dbus events so that apps that don't have the focus can listen
[19:16] <tjaalton> if the settings are reset during the session, it's likely not a bug in xkeyboard-config but the server/evdev or desktop
[19:16] <tjaalton> slangasek: yeah, well I think what happens is that evdev has grabbed the device so that doesn't happen
[19:16] <slangasek> jcristau: well surely, the "Right Win-key is Compose" option in gnome-keyboard-properties should do that/
[19:17] <tjaalton> slangasek: see bug 267682 for my analysis on this (with the help of #xorg-devel)
[19:17] <jcristau> slangasek: no gnome here, i wouldn't know ;)
[19:18] <slangasek> tjaalton: ummm. ok, I just retested, and the media keys /don't/ show keypress events and /do/ generate the dbus events
[19:18] <slangasek> argh
[19:18] <tjaalton> hah
[19:18] <slangasek> and this, without restarting X since the last time I tested :P
[19:18] <slangasek> (compose is still broken though!)
[19:19] <slangasek> jcristau: "setxkbmap -option compose:rwin" - did the trick, but not very permanent...
[19:19] <slangasek> (and I don't want to have to set it in xorg.conf :)
[19:19] <jcristau> it can go in /etc/default/console-setup aiui
[19:20] <slangasek> hmm
[19:20] <tjaalton> yes
[19:20] <slangasek> I'm pretty sure I'm missing the point of getting rid of xorg.conf settings if we're just going to add the same settings to a different config file :)
[19:20] <tjaalton> well those are then shared with console too :)
[19:20] <ogra> they apply to both, console and X that way
[19:20] <slangasek> how do you list more than one XKBOPTIONS value?  space-separated?
[19:21] <jcristau> comma-separated
[19:21] <slangasek> k
[19:23]  * sebner wonders if upstart (ready since 12 august) will make it into intrepid or remaing for jaunty since mark wants "faster boot"!?
[19:24] <slangasek> sebner: what do you mean?  upstart has been the init system for a while now.
[19:25] <sebner> slangasek: sure but I'm speaking about the 0.5 release
[19:26] <slangasek> ah
[19:31] <davmor2> slangasek: I'd lose quick search from synaptic if I were you
[19:31] <slangasek> davmor2: I think you mean to address yourself to the desktop team
[19:33] <davmor2> type t into quick search and it instantly lowers your options to nvidia-glx-96 and nvidia-glx-177
[20:24] <dendrobates> doko: I want to remove zope3-sandbox from server-ship and I was told to run it by you.  Any objections?
[21:09] <dendrobates> pitti: what do you think about moving radeontools and vbetools to Suggests in pm-utils?
[21:10] <pitti> dendrobates: IIRC vbetool is actively used by pm-utils for implementing popular quirks; I don't know about radeontool
[21:10] <pitti> dendrobates: both together are a mere 20 KB, so I guess size is not the reason you want to get rid of them? :)
[21:11] <dendrobates> pitti: pm-utils is being pulled into server through recommends, and I am just looking to deal with possible complaints about bloat.
[21:12] <pitti> dendrobates: good point; I guess suspend/resume isn't really something you'd expect/install on servers
[21:13] <pitti> dendrobates: but these two recommends are fundamentally right IMHO; instead we should maybe look for throwing out pm-utils altogether on servers?
[21:13] <pitti> dendrobates: I'm ok with dropping the hal recommends on it, and instead pull it in through something else
[21:14] <dendrobates> pitti: thanks.
[21:14] <pitti> explicit seeding, or maybe gnome-power-manager
[21:14] <pitti> dendrobates: can you pleaes file an intrepid-beta milestoned bug and assign it to me?
[21:14] <pitti> dendrobates: can't do it right now, but ASAP
[21:14] <dendrobates> pitti: sure.  np
[21:14] <pitti> dendrobates: I just want to think a little more clearly how to pull it in
[21:14] <pitti> dendrobates: thanks
[21:37] <soren> I always forget this: What's the #define that tells me if I'm compiling on amd64 or i386?
[21:41] <geser> soren: are you looking for __x86_64__ and __i386__?
[21:42] <soren> geser: That sounds about right :)
[21:50] <soren> geser: Yes, fantastic. That did the the trick. Thanks very much!
[22:29] <brandon|work> what is the best way to install kde from svn?
[22:36] <Riddell> brandon|work: see techbase.kde.org
[22:36] <brandon|work> k
[22:36] <brandon|work> thanks
[22:36] <Riddell> or use kde-nightly
[22:38] <brandon|work> Riddell, project neon?
[22:39] <Riddell> brandon|work: yes
[22:39] <brandon|work> cool