[00:06] <sistpoty> infinity: unless lp confuses me again, now would be a good time to give back happy alex on lpia ;)
[00:07] <Nafallo> happy alex?
[00:07] <sistpoty> Nafallo: see backlog
[00:07] <sistpoty> Nafallo: (iow, the joke was already made)
[00:08] <Nafallo> sistpoty: ah. I /lastlogged and couldn't see what you meant first. then I saw the "and" ;-)
[00:09] <sistpoty> or maybe lamont? (since infinity seems to be away)
[00:11] <TomJaeger> dpkg-buildpackage: source only upload: Debian-native package
[00:11] <TomJaeger> what did I do wrong?
[00:12] <sistpoty> TomJaeger: wrong name of orig.tar.gz, I assume (btw.: for such packing question I assume that #ubuntu-motu is more suited)
[00:12] <TomJaeger> okay, thanks
[00:42]  * slangasek blinks
[00:45] <ion_> slangasek: Well, be thankful the limit isn't what it used to be in IRCnet. :-)
[00:46] <slangasek> oh, no, I'm just blinking at the downtime
[01:16] <infinity> Okay, so this is the first time (since I got a shiny new laptop with decent 3D) that I've run compiz instead of immediately switching back to metacity...
[01:17] <infinity> Can anyone tell me if I can "fix" the fact that the fancy 3D Alt-Tab switcher doesn't understand Shift-Alt-Tab to cycle backwards?
[01:18] <sistpoty> infinity: I'd lie, if I say I could in case you'd give back alex and happy on lpia :P
[01:19] <infinity> sistpoty: I'd love to, if LP wasn't down.
[01:19] <sistpoty> infinity: it still is?
[01:19] <infinity> sistpoty: Oh, it's back. :)
[01:19] <sistpoty> :)
[01:20] <infinity> sistpoty: So, how do I fix the compiz task switcher? :P
[01:21] <james_w> infinity: there are various plugins that provide alt-tab like switching, so it may be that one of them can do it.
[01:21] <sistpoty> infinity: good question, I use KDE though, and I lied :P
[01:21] <james_w> although the one that I have doesn't understand it
[01:22] <infinity> james_w: Yeah, the default one seems to not know how to go backwards, which makes me grumpy.
[01:22] <infinity> james_w: Given that every window manager (heck, every OS) I've used in the last decade could do so. :P
[01:22] <james_w> infinity: run ccsm
[01:22] <james_w> infinity: you may have to install it first
[01:22] <infinity> simple-ccsm?
[01:22] <james_w> select "Application switcher"
[01:23] <james_w> you need the real thing I think
[01:23] <james_w> the advanced button in simple-ccsm spawns it
[01:23] <james_w> on the "Bindings" tab there is a "Prev window" setting, and it is unbound by default
[01:24] <infinity> Genius.
[01:24] <infinity> I've never looked at any of this before.
[01:25] <infinity> Of course, binding that should be the default, IMO, but I don't know how deeply I care about filing a bug to fix it this late.
[01:26]  * infinity squeals with glee.
[01:26] <infinity> james_w: You're my hero for the next 30 seconds.
[01:26] <infinity> james_w: If you ever needed a favor from me, ASK FAST.
[01:26] <james_w> umm, umm...
[01:28] <thom> too slow
[01:31] <ion_> james_w: You had a chance to ask infinity's hand in marriage, and you blew it?
[01:32] <james_w> dammit
[01:37] <james_w> asac: I've found the problem you were having, apt-get source only responds to a source package name without a version. I think I can work around it by picking the first binary package out of debian/control. I think it's unlikely that the first package will have been added in that revision.
[02:10] <nepbabu> what's the status of launchpad?
[02:10] <nepbabu> is it rebooted and done it's maintenance? thanks :)
[02:10] <james_w> nepbabu: there is a #launchpad
[02:11] <james_w> looks like it's all over though.
[02:11] <nepbabu> james_w: tia! but the SSL cert is invalid says ff
[02:12] <james_w> nepbabu: are you on firefox 3?
[02:12] <nepbabu> james_w: yes
[02:12] <nepbabu> ff3b4 james_w
[02:12] <james_w> I don't know then, it works here
[02:12] <nepbabu> hmm..
[02:13] <sistpoty> any buildd admin still around who could give back hscolour and haddock on lpia?
[02:18]  * sistpoty tries with highlighting the indirect members: elmo, Spads, lamont, Ng for the give-backs of hscolour and haddock on lpia :)
[02:43] <TomJaeger> Can somebody help me with bug #195953 ?
[02:43] <ubotu> Launchpad bug 195953 in wacom-tools "Tablet input resolution tied to display resolution" [Medium,Triaged] https://launchpad.net/bugs/195953
[02:45] <ion_> There's the same problem with plain mice. I've been saying it should be fixed. :-)
[02:53] <TomJaeger> I'm just trying to get a new upstream version uploaded.  How would I go about getting sponsorship for the new version and do I need a freeze exception?
[02:56] <protonchris> TomJaeger: take a look at https://wiki.ubuntu.com/SponsorshipProcess and https://wiki.ubuntu.com/FreezeExceptionProcess
[02:58] <TomJaeger> Wow, that sounds complicated
[02:58] <ScottK2> TomJaeger: What package?
[02:58] <TomJaeger> wacom-tools
[02:58] <ScottK2> Is it bug fixes or new features?
[02:58] <TomJaeger> I don't know why nobody feels responsible for this
[02:59] <TomJaeger> bug fixes
[02:59] <ScottK2> TomJaeger: 20,000 packages and ~100 developers.  You do the math.
[02:59] <andresj> Is this the right channel to ask for somebody to apply a fix for a bug? https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/208556
[02:59] <ubotu> Launchpad bug 208556 in qt4-x11 "qdbuscpp2xml uses moc-qt3 instead of moc-qt4" [Undecided,New]
[02:59] <Fujitsu> ScottK2: 100 developers, most of whom are inactive.
[03:00] <ScottK2> That too
[03:03] <ScottK2> TomJaeger: Since it's a Main package it's a rather simpler process.
[03:04] <ScottK2> TomJaeger: Is the release in Debian already?
[03:04] <TomJaeger> no
[03:04] <ScottK2> andresj: You will probably have more luck with that package on #kubuntu-devel
[03:06] <alex-weej> ScottK2: s
[03:06] <alex-weej> "it's maths, jeremy"
[03:06] <TomJaeger> The thing that bugs me is that all these procedures will take just a few minutes for someone who knows what they're doing, but will take me forever to figure out
[03:06] <alex-weej> TomJaeger: but once you've figured it out
[03:07] <ScottK2> TomJaeger: I can understand that, but the first thing it takes is motivation.
[03:07] <alex-weej> it's not like the people who can do it are sitting around scratching their backsides, they're busy on other things that they feel are more important
[03:07] <ScottK2> TomJaeger: I've got about a dozen things on my list to get done before release.  If I get to 4, I'll be lucky.
[03:08] <andresj> ok, ScottK2
[03:10] <TomJaeger> I'm more than happy doing things like tracking down bugs, providing patches and talking to upstream.  But trying to package that stupid package has been a complete nightmare so far.  I feel like my productivity there is close to zero.
[03:11] <ScottK2> OK.
[03:12] <ScottK2> I'd suggest focus on writing a bug that makes the case for why it's important and why it's safe.
[03:12] <TomJaeger> I've done that
[03:13] <ScottK2> TomJaeger: What bug?
[03:13] <TomJaeger> bug #195953
[03:13] <ubotu> Launchpad bug 195953 in wacom-tools "Tablet input resolution tied to display resolution" [Medium,Triaged] https://launchpad.net/bugs/195953
[03:14] <TomJaeger> If it doesn't get fixed, Tablet PCs are almost useless with hardy
[03:14] <ScottK2> Right.
[03:15] <ScottK2> slangasek: Would you please look at ^^^^ bug and give an opinion on if you'd accept a new wacom-tools version to fix it at this point?
[03:16] <TomJaeger> Do I know why the debdiff is so large? It's a complete mystery.  The diff between the two directories is 600k, and that's mainly autoconf stuff
[03:16] <ScottK2> TomJaeger: He's the Release Manager.
[03:23] <slangasek> ScottK2: I would potentially accept *a* new wacom-tools version, but to know whether I'd accept *this* wacom-tools version it would have to go through the FFe process; and I probably wouldn't be the one to sponsor it myself, I think it'd be better to have it done by someone with more direct knowledge of the issues
[03:23] <ScottK2> slangasek: I understand.  I'm just looking for a rough idea of if it's worth pursuing.  Who'd be the core-dev best equipped to look into this?
[03:25] <slangasek> ScottK2: bryce, maybe?
[03:25] <slangasek> i.e., Mr. Inkscape
[03:25] <ScottK2> Right.
[03:25] <ScottK2> slangasek: Thanks.
[03:26] <ScottK2> TomJaeger: Now you have an idea that this might be doable and who you want to discuss it with rather than worry overmuch about packaging it yourself.
[03:27] <TomJaeger> ScottK, thanks
[04:27] <bryce> hey slangasek I have something for you :-)
[04:27] <bryce> slangasek: http://people.ubuntu.com/~bryce/bisect/
[04:28] <bryce> slangasek: these are pre-git bisected -intel debs for testing.
[04:30] <bryce> (the page is still a work in progress)
[04:32] <james_w> bryce: how are you building them?
[04:32] <bryce> james_w: bunch of scripts
[04:33] <bryce> james_w: I'd gotten stuck down a rathole trying to get them to build in PPA, but PPA has turned out to be worthless for this
[04:33] <james_w> I was just wondering if you be able to basically run "git bisect run debuild"
[04:33] <bryce> james_w: well, ironically 'git bisect' never gets used
[04:34] <james_w> It obviously wouldn't work just like that, but it's an interesting idea.
[04:34] <james_w> bryce: :-)
[04:35] <bryce> yeah basically I pull a bunch of info out of git log, sort the commit id's, then do a bunch of git reset's and such to cycle through them, plunk in debian/ dirs, debuild, pbuilder, rsync, and generate the web page
[04:38] <ScottK2> bryce: TomJaeger was here earlier looking at bug #195953 and hoping for someone to champion getting it uploaded.  slangasek pointed vaguely in your direction.
[04:38] <ubotu> Launchpad bug 195953 in wacom-tools "Tablet input resolution tied to display resolution" [Medium,Triaged] https://launchpad.net/bugs/195953
[04:41] <bryce> ScottK2: whoa that's an insanely huge debdiff
[04:42] <bryce> rats, it crashed my ff3
[04:42] <ion_> :-D
[04:42] <TomJaeger> bryce, the debdiff b/w 0.7.7.7 and 0.7.9.3 is more than 5M
[04:42] <ion_> A nice little 3.5 MiB debdiff.
[04:45] <TomJaeger> I made a little mistake in the "original" tarball there.  the doc directory should be one level further down.  Not that it changes anything about the size of the debdiff.
[04:45] <bryce> hrm, well looks like it needs some additional packaging work before it can be put in
[04:45] <slangasek> TomJaeger: wait, why are you diffing 0.7.7.7 and 0.7.9.3 when hardy currently has 0.7.9.3?
[04:46] <slangasek> bryce: heh, my architecture is amd64, not i386...
[04:46] <TomJaeger> slangasek, just for comparison
[04:46] <slangasek> bryce: I think a git bisecting howto would've served me better :-)
[04:46] <bryce> slangasek: rats!!!
[04:46] <bryce> slangasek: back to the drawing board
[04:47] <slangasek> TomJaeger: erm, comparison of what, exactly? I don't see how 0.7.7.7 can be relevant here
[04:48] <ion_> git bisect is teh awesome. :-)
[04:48] <TomJaeger> slangasek, people are complaining about the size of the debdiff.  I'm just saying the last debdiff was even bigger.
[04:48] <slangasek> oh, I see
[04:48] <jdong> it's not the size of the debdiff that matters....
[04:48] <TomJaeger> the issue seems to be that there is prebuilt stuff in the original tarball
[04:48] <jdong> it's the color of the pill that makes the debdiff easier to work with.
[05:11] <ScottK2> bryce: Yeah.  The packaging needs some work by someone who knows what they are doing (e.g. not me).
[05:57] <calc> how long does it take for a bzr commit to show up in LP?
[05:57] <jdong> less than 30 minutes typically for the HTTP branch to be updated
[05:57] <calc> I did a commit 35m ago and it still isn't showing
[05:57] <calc> oh ok so it should be soon
[05:58] <jdong> the SFTP/SSH developer one is instant of course
[05:58] <calc> i did a ssh and its not showing up
[05:58] <jdong> yeah, typically for me it hasn't been more than 30 min
[05:58] <calc> hmm i'll check it out somewhere and verify the commit made it
[06:02] <calc> wow this is taking a very long time to checkout
[06:02] <Fujitsu> calc: bzr-lp is particularly slow now; they're working on it.
[06:03] <Fujitsu> It'll be like this for another couple eof days, thought.
[06:03] <calc> Fujitsu: ah ok
[06:03] <Fujitsu> If you use bzr+ssh, it should be quicker to update, but SFTP has to be checked to ensure you haven't uploaded evil stuff.
[06:04] <calc> yea i am using bzr+ssh
[06:04] <calc> ok the commit is there, it just haven't shown up on the webpage
[06:04] <jdong> Fujitsu: you mean it's *not* for my video collections?
[06:04] <Fujitsu> jdong: Devastating, I know.
[06:09] <TomJaeger> I think I figured out all the different ways the debian maintainer messed with the original tarball. Things look much better now and the debdiff's down to 600k.
[06:38] <warp10> Good morning
[09:42] <tjaalton> yep, we really need the newer wacom-tools, but I never figured out how to compile it and pushed it forward. For some reason the Debian maintainer hasn't updated it, even though he promised to do it two months ago
[11:08] <asac> james_w: ah, good to know. thanks!
[11:22] <pitti> tkamppeter_: shouldn't, but in the interest of not accidentally catching unrelated devices I'd transform the list as the existing script does
[11:23] <pitti> Chipzz: gnu tar switch> right, I see; would break compatibility
[11:24] <\sh> moins pitti :)
[11:25] <Chipzz> pitti: and probably in quite a visible and especially *unwanted* way :S
[11:28] <Chipzz> pitti: as an unrelated data-point, I did man tar on my OSX system, to see which options would be different. And apparently OSX doesn't even ship BSD tar, it ships GNU tar instead. Now if even a BSD based system ships the GNU version, I very much doubt we'll want to ship the BSD version... ;)
[11:31] <pitti> Chipzz: heh, indeed
[11:32] <\sh> oh wow...it's a sunny day...
[11:34] <Chipzz> pitti: also, doesn't dpkg use tar internally? I'd hate to see the breakage that would cause..
[11:45] <tjaalton> uh, so new upstream versions don't end up in quarantine
[11:46] <tjaalton> I uploaded a new wacom-tools and thought it would end up in the queue
[11:48] <StevenK> Because we aren't in a freeze
[11:49] <Hobbsee> tjaalton: no, it's a trust system.
[11:49] <Hobbsee> tjaalton: and you tend to get the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ coming in your directino if you violate it badly.
[11:49] <tjaalton> well, trust me, this was needed :)
[11:49] <tjaalton> the old wacom-tools was broken with xserver 1.4
[11:50] <zorglu_> q. before i found a channel with the ubuntu people which take care about all the server/mirror to store the .deb of ubuntu. i dont remember the name tho... anybody got suggestion?
[11:50] <tjaalton> and the new one didn't build until Tom Jaeger fixed the issues
[11:54] <\sh> asac: suddenly I see black holes with ff3 while browsing some pages...when I click on the pictures, they are display correctly...but embedded in the page they are black...
[12:04] <pochu> zorglu_: #ubuntu-mirrors
[12:05] <zorglu_> pochu: thanks
[12:11] <Chipzz> \sh: dunnow if it's related, but I've had FF beta4 do funny things for me on MacOSX too
[12:11] <Chipzz> like only loading some of the images on a page
[12:12] <Chipzz> I didn't quite get "black holes", but rather the image with the alt tag displayed though
[12:13] <Chipzz> asac: ^^^ as a data point -> most likely an upstream issue
[12:14] <Chipzz> \sh: only happened to me after several days of browsing, and was fixed by a browser restart though
[12:23] <asac> \sh: thats the zoom level
[12:23] <asac> we have to use in-source jpeg most likely
[12:23] <asac> (i know that its fixed that way, but i hoped to get the proper jpeg patch cherry-picked from firefox sources)
[12:24] <\sh> asac: so the bug is known...
[12:25] <asac> yes
[12:25] <asac> its a blocker
[12:25] <asac> we will revert to in-source jpeg if no solution is found
[12:26] <\sh> asac: thx :) I was wondering if something was wrong on my side :)
[12:26] <asac> \sh: are those jpegs?
[12:27] <\sh> asac: jepp
[12:27] <asac> ok then its known
[12:27] <\sh> btw..is there any tool for metacity to configure its own compositing thingy?
[12:45] <Hobbsee> azeem: ping?
[12:45] <Hobbsee> azeem: got a #debian-type question for you.
[12:50] <j1mc> hi all, could anyone tell me if kubuntu has a set of targeted milestone bugs set up like ubuntu does ( https://launchpad.net/ubuntu/+milestone/ubuntu-8.04 )?
[12:50] <j1mc> my guess would be no, but i wanted to check.
[12:50] <Hobbsee> j1mc: it doens't - that's the complete list for all flavours (assuming they're all using it)
[12:51] <j1mc> Hobbsee: thanks.
[12:51] <Hobbsee> j1mc: see specs assigned to Riddell for the planned kubuntu stuff, though
[12:52] <j1mc> Hobbsee: thanks again.  a question was asked about this in xubuntu-devel.  this is helpful information.
[12:53] <Hobbsee> j1mc: xubuntu is free to add to that list, and discuss things with slangasek and other members of the release team, too
[12:54] <j1mc> i will pass along that information. :)
[12:55] <Hobbsee> but please assign the bugs to some of your guys
[12:55] <Hobbsee> as you're responsible for them
[12:56] <j1mc> Hobbsee: understood.  thanks.
[12:56] <Hobbsee> at least, that's hte way this all worked in gutsy.  i'm unsure if slangasek has changed protocol, as i haven't seen many non-canonical people involved in any areas of RM this cycle.
[13:07] <azeem> Hobbsee: pong
[13:08] <Hobbsee> azeem: /query?
[13:08] <azeem> Hobbsee: sure, but I'm probably not around long :-/
[13:09] <Hobbsee> azeem: no problem, hopefully it won't take long
[14:50] <laga> slangasek: i tried today's mythbuntu alternate disk and the udeb wasn't installed, despite it being  Priority: standard
[14:53] <laga> slangasek: do you think you could take another look?
[14:58] <laga> slangasek: or.. wait. when is the menu entry in d-i supposed to show up? right at the beginning or is it added later, eg after the base system was debootstrapped?
[16:26] <lamont> why do my shift and control keys not wokr anymore/
[16:28]  * lamont applies the redmond solution
[16:29] <lamont> seb128: why doesn't my shift key love me anymore//  ditto for ctl...
[16:29] <seb128> hey lamont, dunno I'm not an xorg guy
[16:29] <lamont> heh
[16:29] <lamont> it's like gnome... ;-0
[16:30] <lamont> hrm... emoticons screw up too...  amazing how much one uses the shift key...
[16:30]  * lamont hits it with a rock
[16:31] <kagou> hey seb128
[16:33] <Chipzz> lamont: I read something about a fix for the "keys stuck" problem in X
[16:33] <Chipzz> lamont: there was a patch for that
[16:33] <lamont> Chipzz: ah, cool
[16:33] <Chipzz> lamont: not sure if it got uploaded though
[16:33] <Chipzz> lamont: maybe that could possibly have the side-effect you're seeing?
[16:34] <Chipzz> lamont: the fix would be in the xorg-core package, so try downgrading that (you would also need to restart your X-server obviously)
[16:34] <Chipzz> lamont: lemme see if I can find the url in the backlog ;)
[16:35] <wasabi> This "run this action now" dialog... may at least be putting power in my hands... but it's way too technical.
[16:36] <wasabi> Package authentication failure of some sort.
[16:36] <Chipzz> lamont: https://launchpad.net/bugs/194214
[16:36] <ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [Unknown,Confirmed]
[16:37] <Chipzz> lamont: hrrrm no mention of the patch being applied and uploaded yet; so that's probably not it
[16:38] <lamont> seb128: sometime, I should find out about the rising dominance of gnome-keyring-manager (or whatever the hell it is) and seahorse, and figure out what to add or remove from my sledgehammer-of-a-gnome-session
[16:39] <lamont> maybe it's finally usable out of the box??
[16:39]  * lamont wanders off for a while
[16:40] <seb128> lamont: the gnome-keyring new changes are cool ;-)
[18:46] <slangasek> laga: ok, trying to take a look; it's possible that I have to set the priority to 'Standard' in the archive overrides rather than relying on what the package thinks, for that change I should probably check with cjwatson and pitti first
[18:53] <slangasek> laga: right, it looks like the CD build takes the package priorities from the archive overrides, rather than looking inside the individual packages.  In that case, making it Priority: standard for the installer would require making it visible as Priority: standard for other install methods too, so that'll need more discussion; sorry for putting you to the effort
[19:33] <calc> Riddell: ping
[19:33] <calc> Riddell: does kde use shared-mime-data and associate programs via desktop files for mimetypes they claim to open?
[19:48] <slangasek> tjaalton: ugh, 195953 should have gone through an FFe...
[19:48] <slangasek> tjaalton: are you tracking this package then, to make sure there are no regressions?
[19:50] <warrend> hi
[19:50] <warrend> can someone look at this bug? https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/188764
[20:01] <laga> slangasek: so are you going to talk to cjwatson/pitti or should i bug them myself?
[20:04] <slangasek> laga: I'll talk to them (on Monday, I expect - I don't think either of them are around this weekend)
[20:04] <laga> slangasek: thanks, that's much appreciated
[20:46] <afflux> does the livecd environment currently warn the user when he doesn't seem to have enough ram?
[20:48] <afflux> hm, I'll  better ask in -installer
[20:49] <tjaalton> slangasek: yeah.. sorry about it :/
[20:50] <tjaalton> slangasek: I'll monitor any issues with it, and actually the upload was broken so I'll fix it asap
[20:52] <slangasek> tjaalton: ok :)
[20:55] <tjaalton> huh, this is strange.. it included wacom_drv.o, when it should have built .so
[20:55] <tjaalton> but building it locally generates only .so
[20:55] <slangasek> heh
[20:55] <tjaalton> maybe it's the default CFLAGS etc biting me again?
[20:56] <slangasek> that would be strange if so
[20:56] <slangasek> a strange misfeature of the upstream build rules
[20:56] <tjaalton> yep
[21:02] <tjaalton> found the bug.. now figuring out how to fix it
[21:03] <tjaalton> fails to find the module dir
[21:21] <tjaalton> hmmh, is 'elif -z "$FOO"' bashism? the wacom configure script seems to fail with '-z: command not found'
[21:24] <ion_> Probably missing 'test' or [ ].
[21:24] <tjaalton> yep, test should do it, since all the other tests have it
[21:25] <tjaalton> quality
[21:26] <slangasek> I don't think that's even a bashism, I think it's invalid shell
[21:26] <tjaalton> right, bash fails too
[21:26] <tjaalton> seems that no-one is using latest wacom :)
[21:27] <tjaalton> or at least not reporting these upstream
[21:31] <slangasek> well that's encouraging
[21:34] <tjaalton> hehe
[21:34] <tjaalton> anyway, a fix uploaded
[21:35] <tjaalton> the release is a month old, so the actual code should be quite solid :)
[21:36] <slangasek> how do we know that, if no one's actually managing to build it successfully?
[21:38] <tjaalton> slangasek: maybe they were built by hand?-) anyway, upstream is adamant about this being much better for xserver 1.4..
[21:38] <tjaalton> better release
[21:47] <\sh> keescook / bryce: are you pushing inkscape 0.46 to hardy? editing pdfs sounds awesome :)
[22:00] <YokoZar> I'm trying to track down a bug regarding Cyrillic input, but don't have a cyrillic keyboard...what's a good way to emulate that?
[22:01] <ion_> setxkbmap ru?
[22:01] <YokoZar> ion_: the trouble is I don't really know what buttons to push, heh
[22:02] <Fujitsu> The GNOME keyboard layout setting thing shows the mapping when you select it.
[22:05] <YokoZar> Fujitsu: ahh ok.  I should learn to look in obvious places, thanks.
[22:52] <sistpoty> Keybuk | Mithrandir | doko: please give back haddock and hscolour on lpia, thanks
[23:01] <doko> sistpoty: can't do that: it's MANUALDEPWAIT
[23:01] <sistpoty> doko: what does that mean?
[23:03] <Fujitsu> sistpoty: It'll automatically be retried when the dependency is available.
[23:03] <sistpoty> Fujitsu: ah, thanks
[23:04] <Fujitsu> MANUALDEPWAIT isn't manual at all. Isn't it great?
[23:05] <sistpoty> oh... haddock is already built... cool, but I don't see manualdepwait for hscolour on lpia?
[23:05] <ScottK2> Just for the record I'd like it noted that I'm self-censoring right now.
[23:07] <sistpoty> Fujitsu: any clues about hscolour, and where I could see it being manualdepwait?
[23:07] <Fujitsu> sistpoty: Looking.
[23:08] <sistpoty> thanks
[23:09] <Fujitsu> doko: hppa and lpia failed to build; they're not MANUALDEPWAIT.
[23:10] <sistpoty> doko: ok, then please give back hscolour on lpia (hppa is no use to give back, we don't have ghc6 there)
[23:10] <doko> Fujitsu: according to  https://edge.launchpad.net/ubuntu/+source/haddock/0.8-2 both are "Dependency wait"
[23:11] <Fujitsu> doko: Ah, I speak of hscolour.
[23:11] <sistpoty> doko: that's haddock, and it's for gutsy (which I misread in the first place as well *g*)
[23:11] <sistpoty> (and for hppa...)
[23:12] <doko> sistpoty: done
[23:12] <sistpoty> doko: thanks!
[23:22] <YokoZar> Is there a reason why /usr/share/X11/locale/locale.dir  lists ru_RU.UTF-8/XLC_LOCALE  ru_RU.UTF-8  rather than en_US.UTF-8/XLC_LOCALE  ru_RU.UTF-8 ?
[23:26] <slangasek> because of KOI8, according to the diff.
[23:28] <keescook> \sh: yawp, been done: inkscape | 0.46-0ubuntu1   | hardy/main
[23:28] <YokoZar> slangasek: Which package is that?  It may be causing a rather old bug in Wine ~ cyrillic input: https://bugs.edge.launchpad.net/wine/+bug/68594
[23:28] <ubotu> Launchpad bug 68594 in wine "No cyrillic input in apps under wine. " [Undecided,New]
[23:32] <slangasek> YokoZar: hrm? I'm talking about diff -u /usr/share/X11/locale/{en_US,ru_RU}.UTF-8/XLC_LOCALE
[23:33] <slangasek> I think you're unlikely to make a persuasive case that a wine bug should be fixed by *not* using the Russian KOI8 map
[23:34] <slangasek> and I'm not aware that XLC_LOCALE has anything to do with input anyway?
[23:35] <YokoZar> slangasek: I'm not sure why making the change fixed the problem earlier either.  Now, it looks like I can type Cyrillic characters in Wine's notepad (which is a UTF-8 app), but I don't have an ANSI app to test this on.  Wine's free fonts just started supporting Cyrillic letters too.
[23:37] <slangasek> if the problem was display of Cyrillic characters, then XLC_LOCALE would have some bearing
[23:38] <YokoZar> slangasek: that makes sense.  I'll close the bug