[00:00] <cjwatson> I don't mind, I can easily munge it to fix that. More interested in the question about the other shadow tools
[00:00] <NCommander> Looking at them now
[00:00] <NCommander> Don't see anything that jumps out at me, I just need to skim usermod before I say yes
[00:01] <cjwatson> well, put it this way, I know that some of them will suffer from the same kind of bug, but want to know whether we care :)
[00:01] <NCommander> cjwatson, usermod doesn't, userdel doesn't care
[00:02] <NCommander> passwd is the only other one
[00:02] <NCommander> It probably has the same issue
[00:02] <cjwatson> chpasswd?
[00:02] <cjwatson> we use that in the installer
[00:02] <NCommander> no, just regular password
[00:02] <NCommander> *passwd
[00:02] <NCommander> Oh
[00:02] <NCommander> ILet me check both
[00:02] <cjwatson> ./src/chpasswd.c:324:   long now = time ((long *) 0) / (24L * 3600L);
[00:02] <NCommander> Anything that will update the password field might be affected
[00:02] <cjwatson> and later on:
[00:02] <cjwatson>                         newsp.sp_lstchg = now;
[00:03] <NCommander> Yeah, that would do it
[00:03] <NCommander> Same with passwd.c
[00:03] <NCommander> Sorry, I had a brainfart and forgot to check the rest :-/
[00:03] <cjwatson> libmisc/pwd2spwd.c, src/newusers.c, and src/pwconv.c too
[00:04] <cjwatson> though I doubt that those would actually be used in practice
[00:04] <cjwatson> (in this kind of context)
[00:04] <NCommander> Does GDM gracefully handle password changes?
[00:04] <NCommander> Actually
[00:04] <cjwatson> well, not used in the installer, but of course somebody could call them by hand
[00:04] <cjwatson> no idea but it uses PAM
[00:04] <NCommander> if you change your passwd on 01-01-1970, it could be a problem
[00:05] <NCommander> Because it could get stuck always prompting you to change the password until the clock is changed
[00:05]  * NCommander would run into that problem on a Babbage board with a broken RTC
[00:05] <NCommander> Let me respin the patch
[00:06] <NCommander> This probably should go upstream
[00:06] <cjwatson> change your password> well, right, hence why passwd needs to be fixed
[00:06] <cjwatson> go upstream> yes, please do send it
[00:16] <NCommander> cjwatson, I've got passwd, and chpasswd fixed
[00:31] <slangasek> dendrobates: who's responsible for bug #347622?  marked critical, no assignee?
[00:34] <NCommander> cjwatson, here's my current debdiff http://paste.ubuntu.com/143165/
[00:35]  * NCommander is not sure how that bug meets the definition of an Ubuntu critical bug ...
[00:39] <cjwatson> NCommander: still has the tab damage
[00:40] <cjwatson> NCommander: and the duplicate patch file
[00:40] <slangasek> pitti: would it be reasonable/appropriate to work around bug #336055 by forcing an iwlist wlan0 in pm-utils resume.d?  (I've considered doing this locally, since it's what I end up typing at the commandline after each resume anyway :P)
[00:41] <NCommander> cjwatson, WTF? ...
[00:41] <NCommander> argh
[00:42] <NCommander> cjwatson, are we looking at the same patch?
[00:42] <NCommander> oh wait
[00:42] <NCommander> I'm a freaking idiot
[00:47] <NCommander> cjwatson, http://paste.ubuntu.com/143171/ - I apologize, I'm freaking fried. Tab damage properly fixed, testing now
[00:51] <cjwatson> NCommander: couple more bits of tab damage in passwd.c and newusers.c, but I can fix those - just in case you're sending upstream
[00:52] <NCommander> cjwatson, I'll get it. I thought I nailed all the tab damage. What are you using to see it? (I turned on the vi tab ... thingy which highlights the difference)
[00:52] <cjwatson> NCommander: rest looks fine
[00:53] <cjwatson> NCommander: I'm just looking at the URL you posted, you can see it by the alignment
[00:53] <NCommander> Its been too many hours in the day :-/
[00:54] <cjwatson> no worries
[00:54] <cjwatson> like I say, can fix it up at my end if your tests pass
[00:54] <NCommander> as a general rule of thumb, I perfer to fix it on my end.
[00:55]  * NCommander hates pushing work onto other's people plates
[00:55] <cjwatson> sure, I don't like making people respin for trivial whitespace changes either though :)
[00:55] <NCommander> cjwatson, where is upstream for shadow anyway?
[00:56] <cjwatson> NCommander: a list on alioth.d.o apparently; README has details
[00:56] <cjwatson> calc: can you explain to me the difference between myspell-en-us and hunspell-en-us?
[00:57]  * NCommander orders dinner while this builds
[00:58] <cjwatson> calc: bug 327821 appears to be because (a) myspell-en-us is installed as part of desktop, presumably due to a dependency from (lots of stuff) -> hunspell -> myspell-en-us | myspell-dictionary | hunspell-dictionary; (b) language-support-writing-en Depends: hunspell-en-us which Replaces: and Conflicts: myspell-en-us
[00:59] <NCommander> *sighs*
[00:59] <cjwatson> calc: the Replaces and Conflicts seems to suggest that hunspell-en-us is considered better in some way, but in that case I'm curious why it isn't hunspell's preferred alternative
[00:59] <NCommander> I'm really fried, I just put my name where the credit card number supposed to go ...
[01:02]  * NCommander found a bug ...
[01:04] <reduz> dudes! dudes! I've been trying out the latest version of ubuntu 9.04 beta, which i upgraded to some days ago.. and out of nowhere the mouse went crazy and started to move around all by itself clicking everywhere! it even copypasted text all around between windows!!
[01:05] <directhex> reduz, physical mouse, or laptop touchpad?
[01:05] <reduz> physical regular everyday mouse
[01:05] <reduz> the pointer, of course, i'm not drunk :)
[01:05] <reduz> killed X (exited session) and started again and now it's fine
[01:05] <NCommander> reduz, I think he meant was it a normal mouse or trackpad; I've had that issue with trackpads, but I haven't seen it with a normal mouse
[01:06] <cjwatson> I find that once in a blue moon a mouse button gets stuck, and I need to whack random buttons a few times to unstick it
[01:06] <reduz> ah yeah it's a regular standard $10 optical mouse
[01:06]  * NCommander does a rmmod psmouse && modprobe psmouse to get his laptop's trackpad going again
[01:06]  * TheMuso has had control/shift/alt buttons sticking, not physically, but in the computer's memory a fair bit, but thats often been a11y related./
[01:06] <reduz> but here it's like, the mouse cursor starts moving by itself pushing all buttons
[01:06] <reduz> only restarting X fixed it
[01:06] <NCommander> TheMuso, can't be as bad my old laptop
[01:06] <NCommander> TheMuso, having -8 memory errors is a bad thing :-)
[01:07] <TheMuso> NCommander: SOunds like it.
[01:07] <reduz> if it happens again, any idea what kind of info i can collect to pinpoint the problem?
[01:08] <NCommander> cjwatson, chpasswd works, but it spits out a warning each time it updates a user so I need to move the warning code; same with pwconv. Will ubiquity freak out if there is any strerr output?
[01:08] <cjwatson> NCommander: if ubiquity cares about the presence of stderr output in any way, it's a bug and I'll fix it
[01:08] <cjwatson> it shouldn't
[01:08] <NCommander> cjwatson, also, recommendations on how to better phrase the warning?
[01:08] <NCommander> (or print it?)
[01:08] <cjwatson> it seemed OK to me
[01:08] <NCommander> It comes out like:
[01:08] <NCommander> ystem clock set to Januar
[01:08] <NCommander> ield will be omitted from
[01:08] <NCommander> l be disabled on this acc
[01:08] <NCommander> ...
[01:09] <NCommander> copy and paste failure
[01:34] <nohup> Hey, is this the right channel to ask about packaging a certain open source program?
[01:36] <ScottK> nohup: #ubuntu-motu is better.
[01:40] <nohup> ScottK, what does motu mean?
[01:41] <ScottK-desktop> It means that's a better channel to ask about packaging a certain open source program.
[01:42] <Snova> nohup: Masters Of The Universe. :) Packagers, though I'm not certain exactly what they do.
[01:43] <nohup> haha, thanks Snova.
[01:45] <akgraner> nohup: https://wiki.ubuntu.com/MOTU
[01:47] <nohup> thanks akgraner
[01:48] <akgraner> nohup: your welcome..
[01:50]  * TheMuso likes Xubuntu's login artwork/layout change.
[02:40] <NCommander> TheMuso, your running Xubuntu?
[02:41] <NCommander> cjwatson, if your still awake, I posted a revised debdiff, tested to make sure it works as expected, and testbuilt in pbuilder. I also made sure the warning one printed once :-)
[02:48] <TheMuso> NCommander: just looking at a few things a11y wise.
[04:22] <calc> cjwatson: looking
[04:26] <calc> cjwatson: the only difference appears to be that myspell-en-us has iceape/icedove/iceweasel in the dictionary
[04:27] <calc> cjwatson: looks like we could drop hunspell-en-us afaict
[04:27] <calc> well there is also a file naming difference in /usr/share/myspell/infos/ooo/(blah)-en-us
[04:29] <calc> cjwatson:  4 files changed, 7 insertions(+), 1 deletion(-)
[04:29] <calc> cjwatson: that was after deleting the doc dir which had the debian changelog, etc
[04:30] <calc> cjwatson: i messaged rene to see if he knows why it still exists as a package, doesn't seem to have any real use
[04:30] <calc> one of the two probably should cease to exist, but i am not sure which one he would choose, heh
[05:31] <IsmailBhai> hi
[06:13] <pitti> Good morning
[06:13] <kees> pitti: any thoughts on 346846 ?  hal shows my esata luks partition, but I don't get prompted for it.  *scratch head*
[06:13] <pitti> kirkland: I'll get to it today
[06:14] <kees> pitti: oh!  I wasn't expecting you to be up yet!  :)
[06:14] <kees> good morning.  :)
[06:15] <pitti> slangasek: ah, I'm bitten by this as well; an iwlist is fairly harmless (as opposed to some ifdown/ifup hacks we did in the past), so I'm all for it
[06:15] <pitti> kees: good morning! early bird catches the worm :)
[06:15] <kees> pitti: indeed!  :)
[06:15] <pitti> and I still have a ton of stuff to do before I leave for the LF summit
[06:17] <pitti> kees: ah, you can reproduce it?
[06:17] <pitti> kees: is that only for esata, or also for USB disks?
[06:17] <kees> pitti: yes.  if I plug in this drive via USB, I am prompted.  via esata, I'm not.
[06:17] <pitti> kees: od you get an icon on the desktop/computer place?
[06:18] <pitti> kees: my gut feeling is that it is detected as an internal, non-removable disk
[06:18] <pitti> kees: look at the lshal stanza, .hotpluggable/.removable
[06:18] <kees> pitti: I don't get any icon for esata.  (lshal shows the raw luks partition, though)
[06:18] <ka6sox-work> kees, do you work on update-manager?
[06:19] <kees> ka6sox-work: nope, sorry.
[06:19] <kees> pitti: I don't see those two items.
[06:19] <bluefoxicy> so guys
[06:20] <bluefoxicy> I put elevator=as on my kernel command line in Jaunty
[06:20] <kees> pitti: I can't say if it worked in earlier alphas (as the original reporter says)
[06:20] <bluefoxicy> Jaunty now has ceased to behave like Windows Vista on a 486 with 32 megs of RAM
[06:20] <pitti> kees: these are on the device (sda), not on the partition (sda1)
[06:20] <bluefoxicy> i.e. it's actually usable and not lagging like hell
[06:20] <kees> pitti: if I try "gnome-mount" from the command line, it always fails.
[06:20] <pitti> kees: storage.hotpluggable and storage.removable
[06:20] <kees> pitti: ah! one sec
[06:20] <bluefoxicy> apparently CFQ is now total garbage.  Should I file this as a bug?
[06:21] <kees> pitti: har har:    storage.hotpluggable = false  (bool)
[06:21] <kees>   storage.removable = false  (bool)
[06:21] <kees>   storage.removable.media_available = true  (bool)
[06:21] <pitti> kees: that's it then
[06:21] <pitti> kees: can you please paste this to the bug?
[06:22] <kees> pitti: the sde stanza?
[06:22] <pitti> yes
[06:23] <pwnguin> bluefoxicy: you'd proably get more traction on kernel performance in #ubuntu-kernel, during whatever counts as business hours
[06:23] <pitti> kees: does gnome-mount -vbd /dev/sde1 work?
[06:23] <bluefoxicy> pwnguin: possibly
[06:23] <pitti> kees: (please paste the output to the bug, too)
[06:24] <kees> hm
[06:24] <kees> rg.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.crypto-setup-fixed auth_admin_keep_always <-- (action, result)
[06:28] <kees> pitti: oh, dur.  "sudo gnome-mount ..." worked
[06:30] <sbeattie> kees: are you watching bug 352779? Mind if I assign it to you for now?
[06:31] <pitti> kees: argh, DSL reconnect; did you say something after my "please attach hal debug output"?
[06:32] <kees> sbeattie: sure, no problem.
[06:32] <kees> pitti: yeah, I realized I needed to do "sudo gnome-mount ..." after seeing:  org.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.crypto-setup-fixed auth_admin_keep_always <-- (action, result)
[06:35] <pitti> kees: you shouldn't really
[06:35] <pitti> kees: it should ask you for admin password through policykit
[06:36] <kees> pitti: it doesn't seem to do that -- it just wanted the luks password
[06:38] <pitti> kees: it works with sudo?
[06:38] <kees> pitti: yup
[06:38] <pitti> kees: I'm interested in the hal output for both cases (sudo and user)
[06:38] <pitti> interesting
[06:39] <kees> pitti: hal output from what?
[06:39] <pitti> kees: the hal debugging output
[06:39] <pitti> didn't that come through any more?
[06:39] <kees> you mean the gnome-mount output?
 kees: can you please do this again with a hal debu
[06:39] <pitti> gging output (https://wiki.ubuntu.com/DebuggingHal#How%20to%20file) and attach i
[06:39] <pitti> t?
[06:39] <kees> oh! I never saw that.
[06:40] <pitti> kees: tomorrow I have to get up at 4:30 am, good time to reset my dsl router to have the reconnect in the middle of the night henceforth :)
[06:41] <pitti> kees: I just tried mounting an unencrypted internal partition as user, and it worked (through PK), so it seems the issue is only with luks encrypted ones
[06:41] <pitti> that sounds tractable to fix
[06:41] <kees> cool.
[06:41] <pitti> kees: so, please submit the hal debugging output, for both non-sudo and sudo gnome-mount
[06:42] <pitti> kees: and also supply the output of "gnome-mount -vbud /dev/sde1" (-u -> unmount), which should work as normal user; if not, try again with root
[06:42] <kees> okay -- is it sane to restart hal several times while I have Xorg running?
[06:42] <pitti> kees: yes, you can restart hal without problems
[06:42] <pitti> kees: but once in debugging mode you can just leave it running
[06:42] <pitti> no need to restart between above attempts
[06:42] <pitti> kees: just don't touch dbus
[06:42] <kees> okay, let me collect that stuff.
[06:42] <kees> heh
[06:45] <showers> hello?
[06:46] <showers> Even as we speak, ubuntu is downloading (utorrent, pretty good speed) and I may need just a little assistance
[06:46] <dholbach> good morning
[06:46] <showers> To set up the dual boot
[06:47] <showers> Basically, there are two hard drives - one win xp and the other empty except for my data backup files
[06:48] <showers> i partitioned the almost empty drive into the data backup (5 gigs) and the unused space
[06:48] <showers> it would be nice if ubuntu would install into the unused part of the backup disk
[06:48] <showers> will there be any problems?
[06:49] <showers> Because it is going into only part of a drive it will probably be a 'manual install.'
[06:50] <showers> from my previous experience with linux it needs three partitions. Still True?
[06:50] <dholbach> showers: did you try asking in #ubuntu?
[06:51] <showers> will have to do the iso burn thing first, and all that. The only thing which gave me trouble ... eh? asking in ubuntu, you say? Well, to be sure.
[06:52] <showers> join/#ubuntu
[06:52] <showers> join #ubuntu
[06:53] <showers> #ubuntu
[06:53] <dholbach>  /join #ubuntu
[06:53] <showers> of course. thanks
[06:54] <kees> pitti: okay, everything attached.
[06:57] <dholbach> bryce, tjaalton: will you guys take care of 352335 and bug 326050?
[06:57] <dholbach> bug
[06:57] <dholbach> bug 352335
[07:01] <bryce> dholbach: timo has been afk due to ill children
[07:01] <tjaalton> dholbach: sure
[07:01] <tjaalton> hehe
[07:01] <tjaalton> back :)
[07:01] <bryce> wb :-)
[07:01] <Amaranth> ill children will almost certainly end up with an ill timo
[07:02]  * dholbach hugs the dynamic duo :)
[07:02] <tjaalton> Amaranth: maybe after the incubation time is over ;)
[07:09] <dholbach> bryce, tjaalton: and bug 317127 too :)
[07:10] <dholbach> ivoks: do you know who usually takes care of ebox stuff?
[07:10] <dholbach> ivoks: it seems the upstream maintainer is looking for a sponsor: bug 345150 and bug 350452
[07:10] <dholbach> ivoks: he seems to be a good guy, knowing his way around
[07:11] <bryce> dholbach: why these bugs in particular?
[07:11] <dholbach> bryce: they're all on the sponsors list
[07:12] <tjaalton> bryce: I guess because they have patches
[07:12] <bryce> ahh
[07:12] <ivoks> dholbach: hm...
[07:12] <tjaalton> the FTBFS' should be synced, although they need a FFe
[07:12] <dholbach> ivoks: sorry, the first one should have been bug 354150
[07:12] <bryce> hum, weird, I *just* went through harvest yesterday top to bottom sponsoring patches, odd I didn't run across those
[07:12] <dholbach> hiya ttx
[07:13] <ttx> hey dholbach !
[07:13] <dholbach> ttx: do you know anything about bug 345562 and the progress there?
[07:14] <ttx> dholbach: no, but I can have a look.
[07:14] <dholbach> super
[07:14] <ivoks> dholbach: server team does it, there's no one particulary responsible for it, iirc
[07:14] <dholbach> ah ok
[07:15] <bryce> tjaalton: you doing evtouch and vmmouse both, or should I take one or the other?
[07:15] <tjaalton> bryce: I can take care of them
[07:15] <bryce> thanks
[07:17] <ivoks> dholbach: javier is upstream, so i would trust his patches :)
[07:17] <dholbach> ivoks: yeah, I noticed - so will you sponsor them? :)
[07:17] <ivoks> dholbach: sure
[07:18] <dholbach> I'm trying to get  http://people.ubuntu.com/~dholbach/sponsoring/  down to 0 :)
[07:18] <dholbach> we're doing quite good actually
[07:18] <ttx> dholbach: re:netbeans at first glance it looks relatively harmless but I don't know anything about netbeans... I know persia does
[07:18] <dholbach> ttx: I think he's travelling atm
[07:18] <ttx> dholbach: ok. i'll put that on my TODO.
[07:19] <slangasek> pitti: ok; if rtg & pgraner don't have a better idea how to fix it for release, then let's do that
[07:19]  * ttx is just back from a 3-day presence at the Paris SolutionsLinux expo
[07:19] <ttx> dholbach: so I have a large backlog.
[07:19] <pitti> slangasek: do you have time to work on that? I'm on the LF summit next week, and still have a ton to get done today
[07:19]  * dholbach hugs ttx
[07:19] <slangasek> pitti: I can probably poke at it over the weekend; as I said, I was already pondering hacking it together for myself :)
[07:20] <pitti> ah, splendid
[07:21] <dholbach> superm1: does bug 352572 make sense?
[08:04] <slytheri1> cjwatson: not sure if you have noticed already, but grub-pc package is not on alternate CD images. Let me know if I should file a bug for this.
[08:16] <slangasek> slytheri1: it's intentional to only include in on the DVD; does this cause a problem?
[08:38] <RAOF> lifeless: Do you remember when I was complaining about evolution thrashing the disc for 30 minutes at a time, and you said (a) that there was a bug filed upstream and (b) that it was fixed in trunk?  I can't seem to find the bug, and it's not fixed in Ubuntu :)
[08:40] <Unggnu> hi all
[08:40] <Unggnu> pitti: You there?
[08:40] <pitti> hi Unggnu
[08:40] <Unggnu> hi
[08:40] <Unggnu> Is it possible that apport doesn't mark the whole bug report private but only the private relevant parts like backtraces?
[08:41] <Unggnu> The problem is that often your bug report is marked as a duplicate but you can't see the original report because of the private tag
[08:41] <Unggnu> So it is still possible to add information for the duplicate reporter.
[08:43] <slytheri1> slangasek: I haven't yet tried installation yet. But since grub-installer is supposed to give an option to install grub2 in advanced mode, I thought it will cause problem if it is not included on CD.
[08:44] <Unggnu> pitti: What do you think? Should I add a feature request/bug report?
[08:44] <pitti> Unggnu: that would be nice, but unfortunately isn't possible with LP
[08:44] <pitti> you can't make attachments private at all
[08:44] <Unggnu> pitti: atm?
[08:44] <pitti> if you know their URL, you can read them
[08:44] <Unggnu> So a bug against launchpad?
[08:44] <pitti> Unggnu: right
[08:45] <Unggnu> ok, thx
[08:45] <pitti> if we had private attachments, we could redesign this to be much more friendly
[08:47] <pitti> tseliot: bug 320632> seems you did it, great job! Can you please connect with bryce to get this sponsored?
[08:47] <tseliot> pitti: sure, I'll talk to him
[08:49] <mvo> just FYI I disabled upgrades to jaunty temporarely because of bug #354228
[08:51] <RAOF> TheMuso: You might be happy to learn that pulseaudio from the test PPA is no longer totally crazily crap.  It seems to work fine, and not even make HDA Intel a world of crackling underruns.
[08:51] <slangasek> slytherin: it /should/ automatically download from the network to install it
[08:51] <slangasek> slytherin: if you don't have a network, then the DVD is the only way to get grub2 currently
[08:52] <Unggnu> pitti: https://bugs.launchpad.net/bugs/354345
[08:52] <slytherin> slangasek: hmm. I can understand, considering that only advanced users will install grub2. Are we targetting for grub2 to be default for karmic?
[08:53] <bryce> pitti, tseliot: done
[08:53] <pitti> bryce: awesome
[08:53] <tseliot> bryce: thanks. I didn't think you were still awake ;)
[08:53] <slangasek> slytherin: we don't currently have such a target, no; grub2 will need more attention yet before we'll be able to make it default, and no one's committed yet to making that happen
[08:53] <bryce> tseliot: pshaw it's barely 1am
[08:53] <tseliot> hehe
[08:54] <slytherin> slangasek: ok.
[08:54] <pitti> bryce: sounds like a good time to go to bed :)
[08:54]  * pitti hugs bryce
[08:55] <lool> slangasek: Please do change texlive-bin, thanks for looking into it
[08:55] <slangasek> lool: ok - done ;)
[08:55] <bryce> ooh, slangasek's up too, and he's my same timezone
[08:55] <lool> ISTR Matthias had done some changes to texlive though
[08:55] <lool> Oh no, it was djvulibre
[08:55] <slangasek> bryce: yes, and I have to be up in 6 hours for a release meeting; I'm a masochistic idiot, what's your excuse? :)
[08:56] <bryce> same
[08:56] <lool> I have to be up in 6 hours for a release meeting as well!!
[08:56] <lool> :-P
[08:56] <slangasek> lool: you'd better get to bed soon then
[08:58] <bryce> lool:  done today just for you...
[08:58] <bryce>    def append_comment(self, message):
[08:58] <bryce>         for m in self.bug.messages:
[08:58] <bryce>             if m.content == message:
[08:58] <bryce>                 return
[08:58] <bryce>         self.bug.newMessage(subject = "Re: "+self.title, content = message)
[08:58] <bryce>         return True
[08:58] <mvo> lool: what TZ are you in currently :) ?
[09:01] <lool> bryce: \o/
[09:01]  * lool hugs bryce 
[09:02] <lool> bryce: TBH I've been a bit annoyed by the rate at which the scripts were asking for useless stuff; I'm sure they'll improve and that'll eventually be history
[09:03] <lool> mvo: I'm in Disneyland/Mickey + 2
[09:03] <pitti> bryce, tjaalton: did you happen to see bug 349127?
[09:04] <tjaalton> pitti: yes, I've got mesa 7.4 in my ppa
[09:04] <pitti> I mean the backported patches
[09:04] <mvo> lool: heh :)
[09:04] <pitti> tjaalton: I don't suppose 7.4 is targetted at jaunty?
[09:04] <tjaalton> pitti: it is
[09:04] <lool> Uh
[09:04] <pitti> oh
[09:04] <tjaalton> I'd rather get it instead
[09:04] <mvo> lool: I'm in GreenTeaLang/Sencha
[09:04] <tjaalton> it's a bugfix release
[09:05] <pitti> tjaalton: this sounds like a high regression potential?
[09:05] <lool> mvo: Sweet, received your order? :)
[09:05] <tjaalton> no it doesnt'
[09:05] <pitti> I was just looking at the backported patch
[09:05] <bryce> lool: yes, getting them tuned perfectly will take some time but I plan to keep at it
[09:05] <mvo> lool: yes - you too?
[09:05] <tjaalton> did I not send an email to the list about it?
[09:06] <lool> mvo: No, and it's looking bad; order was refused and they don't pick up the phone so I couldn't switch credit card in time, it's going to expire today   :-/
[09:06] <lool> tjaalton: I didn't see it
[09:06] <pitti> tjaalton: I haven't seen it, but I might have missed it (I'm not on ubuntu-x@)
[09:06] <bryce> tjaalton: don't think so
[09:06] <tjaalton> damn
[09:06] <lool> I'm not on -x either
[09:06] <pitti> so, the backported patch looks reasonable to me
[09:06] <bryce> hehe
[09:06] <pitti> and it is confirmed to fix elisa
[09:06] <bryce> I think maybe I'm on -x by myself, that would explain the lack of replies to some of my emails ;-)
[09:06] <tjaalton> I mean to send it to u-d
[09:07] <bryce> here I've just been assuming everyone must be agreed ;-)
[09:07] <tjaalton> meanT
[09:07] <pitti> tjaalton: when is that scheduled to land? can we have it ASAP theN?
[09:07] <bryce> pitti: I also reviewed mesa 7.4 and agree it is worth a FFe on
[09:07] <pitti> also, that means I shouldn't bother to apply/test the backported patch then?
[09:07] <pitti> bryce: FF? I thought it was bug fix only?
[09:07] <tjaalton> pitti: sure, it's basically ready, I've just been adding some backported commits that have been verified to fix some bugs
[09:08] <pitti> ah, great
[09:08] <tjaalton> well, new upstream version
[09:08] <pitti> tjaalton: mind if you close the bug above in the changelog?
[09:08] <mvo> lool: oh :(
[09:08] <tjaalton> pitti: sure
[09:08] <pitti> great, thanks
[09:08] <pitti> tjaalton: new upstream versions by themselves don't need an ack; new features do
[09:08] <bryce> pitti: yes bug fix only; but whatever paperwork is required for a new version of a package, I +1 it for mesa 7.4 ;-)
[09:08] <slangasek> does 7.4 also close the mythbuntu bug?
[09:08] <pitti> I don't think so
[09:09] <pitti> 7.4 from ppa was said not to fix that one
[09:09] <tjaalton> which bug was that?
[09:09] <slangasek> (who's upstream for mesa these days? someone who knows what "bugfix only" means?)
[09:09] <pitti> tjaalton: bug 341898
[09:09] <tjaalton> slangasek: brian paul @ vmware, they are pretty strict ;)
[09:09] <slangasek> ok
[09:10] <slangasek> still, taking a new upstream release that only manages to fix one of two release-critical bugs on the package, vs. just cherry-picking the fix we know and care about?
[09:10] <tjaalton> I proposed a patch that bumps the texture size on i965 and it was rejected from 7.4
[09:11] <tseliot>  tjaalton: can I see that patch?
[09:12] <tjaalton> tseliot: it's in the ppa version
[09:12] <davmor2> bryce: should a built in nvidia 6100 gfx card have a higher res than 800x600 using the nv driver or is it likely to be using the vesa mode? 00:0d.0 VGA compatible controller [0300]: nVidia Corporation GeForce 6100 nForce 405 [10de:03d1] (rev a2) id from lspci -vvnn
[09:12] <pitti> admittedly I'm still nervous about getting large changes in now, even if they are declared bug fix only
[09:13] <wgrant> doko: Should python2.6's distutils really be inserting local/ even when it's nowhere near /usr?
[09:13] <tjaalton> pitti: I'll open a new tracker bug for it with all the confirmed fixes, diffstat and shortlog etc
[09:13] <bryce> slangasek: shipping ubuntu with a version number on mesa that is a stable version number will give people more warm fuzzies than if we shipped with an unstable version number + patches.  For whatever warm fuzzies are worth, there's that ;-)
[09:14] <tjaalton> yeah, like um, hardy?-)
[09:14] <pitti> tjaalton: thanks
[09:14] <tseliot> tjaalton: ok, thanks
[09:14] <bryce> davmor2: check your Xorg.0.log to see what driver is loaded
[09:15] <bryce> davmor2: in general if you're stuck at 800x600 it usually means either you booted vesa, or your monitor's EDID was invalid for some reason
[09:15] <lool> tjaalton: Weird, that max texture size bump didn't seem too risky; it was even tested
[09:15] <davmor2> bryce: where was the nv device list too I can check if it is listed in there too
[09:15] <tjaalton> davmor2: nv is fail, try nouveau
[09:15] <lool> I was actually about to ask whether we'd get that fix
[09:15] <slangasek> bryce: oh, 7.3 reads as an unstable version number in the case of mesa?
[09:15] <lool> (Cause currently you can't have a big screen on the side of your laptop and use compiz)
[09:15] <bryce> davmor2: /usr/share/xserver-xorg/pci/
[09:16] <bryce> slangasek: yes
[09:16] <lool> slangasek: yes
[09:16] <tjaalton> lool: it might get in 7.4.1, but idr said it should need another commit which broke r300
[09:16] <slangasek> ah, well, in that case.. :)
[09:16] <davmor2> bryce: ta I'll look at both of those
[09:17] <bryce> tjaalton is right that nouveau is a good option, however we're not officially supporting it yet, so it's still sort of buyer beware for now
[09:17] <tjaalton> RAOF does support it though :)
[09:17] <directhex> crazy boy that he is
[09:23] <davmor2> bryce: Meh xorg.log and xorg.log.old both list nvidia and glx however the card id isn't listed in nv.  Should I try adding it and do sudo dpkg-reconfigure -phigh xserver-xorg
[09:25] <tseliot> davmor2: isn't it something similar to what I reported here (albeit with a different card)? http://www.mail-archive.com/xorg@lists.freedesktop.org/msg04430.html
[09:25] <tseliot> davmor2: have a look at Aaron's reply
[09:25] <tjaalton> oh, 6100 doesn't work
[09:26] <tjaalton> sorry
[09:26] <tjaalton> wrong model :)
[09:27] <RAOF> tjaalton: 6100 doesn't work with nouveau?  There are some kernel fixes there I'm considering pulling in.
[09:28] <tjaalton> RAOF: no, I meant -nv
[09:28] <davmor2> tseliot: Ah makes sense
[09:28] <tjaalton> I filed a bug about GF7050 not being supported by -nv, but failed to remember the model
[09:28] <RAOF> davmor2: Really, try nouveau.  It's faster and more featureful than the binary nvidia driver.
[09:28] <RAOF> davmor2: Well, barring 3d, of course :)
[09:29] <lifeless> RAOF: uhm
[09:32] <lifeless> RAOF: http://bugzilla.gnome.org/show_bug.cgi?id=564339 was one
[09:32] <lifeless> which I patched
[09:35] <tjaalton> pitti: so, there's bug 347171 already, I've updated it
[09:35] <tjaalton> slangasek: ^^
[09:36] <lifeless> RAOF: but I can't right now find the other; it was linked from the lp bug I filed on evolution though, if you care to search for it
[09:37] <RAOF> lifeless: Looks like your patch should be in Jaunty's package.
[09:39] <tjaalton> pitti, slangasek: oh and it seems to fix my problems on resume :) (bug 347871)
[09:47] <cjwatson> calc: ok, thanks; I was more wondering about dictionary compatibility than about the contents, I think
[10:12] <directhex> tracker's "about to index" notification message seems inappropriate
[10:12] <directhex> saying "you can pause it by clicking here" doesn't help much given the contextless nature of the new notifications
[10:12] <directhex> and unclickability too
[10:30] <tkamppeter> Any USB/kernel expert around? Can you have a look at bug 348316? Seems to be a low-level USB problem.
[10:34] <mnemo> tkamppeter: try #ubuntu-kernel as well
[10:44] <james_w> I need to do a split() with and re in perl, but also retain the text that was split on, is there a way to do this?
[10:44] <james_w> i.e. split on "[ \t]+" and get back the exact spacing that was used as well as the bits either side
[10:46] <cjwatson> james_w: put parens around the thing you're splitting on
[10:46] <cjwatson>                If the PATTERN contains parentheses, additional list elements
[10:46] <cjwatson>                are created from each matching substring in the delimiter.
[10:46] <james_w> ah, wonderful, thanks
[10:58] <tkamppeter> mnemo: Thanks, but it seems that there is currently no traffic on #ubuntu-kernel.
[10:58] <mnemo> :(
[10:59] <ogra> tkamppeter, the kernel team is at a sprint at the US eastcoast ... they will be up later
[11:00] <tkamppeter> ogra, thanks, did not know that they are having a sprint now.
[11:19] <juanje> hi, anyone here maintain the grub package? I've added a branch to a bug 347790 to fix it last week. I've been testing it and it's working, but I don't know if it's the best approach. It is a problem with the UUID device name and splashimage path
[11:22] <mnemo> juanje: use "aptitude changlog grub" to see how usually uploads it and contact one of those guys
[11:22] <juanje> mnemo: thanks
[11:24] <jpds> juanje: You could subscribe the ubuntu-main-sponsors to the bug too.
[11:25] <juanje> jpds: Thank, good idea. I will
[11:29] <juanje> mnemo: actually I now the people who touch the package, the problem is nobody said nothing in more than a week and the bug is confirmed and make the splashimage feature fails, so for me it's quite important.
[11:30] <cjwatson> juanje: I'll look at it, thanks
[11:30] <juanje> cjwatson: Thanks to you :-)
[11:31] <cjwatson> juanje: please don't modify existing already-released changelog entries
[11:31] <cjwatson> -grub (0.97-29ubuntu51) jaunty; urgency=low
[11:31] <cjwatson> +grub (0.97-29ubuntu51guada1) jaunty; urgency=low
[11:31] <cjwatson> very confusing
[11:32] <juanje> cjwatson: sorry, this was for our ppa so we could use in the main time. I didn't mean to change for the patch :-/ Sorry
[11:33] <cjwatson> this all seems quite wrong though. There'll be all sorts of problems caused by putting a root command in there.
[11:33] <juanje> cjwatson: yes, I was looking for that problem (I'm still doing it) but i didn't find yet the place
[11:34] <cjwatson> juanje: oh, also, never use a file in debian/patches/ to patch files in debian/
[11:34] <cjwatson> just change the file directly
[11:34] <juanje> ummm
[11:36] <juanje> cjwatson: ok, it was just because it was a script which will be installed on /usr/sbin/ not a debian file
[11:36] <cjwatson> (ubuntu_update_grub.diff does this, I know; that's a bug and not one to be imitated)
[11:36] <cjwatson> juanje: that doesn't matter, the fact is that it's in debian/ and not in the .orig.tar.gz
[11:36] <juanje> cjwatson: yes, that was the one I looked to make mine..
[11:37] <juanje> ok
[11:37] <juanje> I undertand
[11:37] <cjwatson> ubuntu_update_grub isn't actually applied, it's apparently just kept there for future reference or something
[11:37] <juanje> yes, I saw it
[11:37] <cjwatson> I'll remove it since it's preserved in revision control
[11:38] <juanje> cjwatson: I guess that is better to avoid confusions like mine
[11:40] <lifeless> RAOF: my fix is in yes
[11:40] <lifeless> RAOF: there are other issues, and thats where I got bored
[11:40] <cjwatson> (done)
[11:40] <lifeless> I'll get annoyed enough some day to come back to it
[11:40] <RAOF> lifeless: I'd be happy enough with a workaround such as a recommendation for a better mail client :)
[11:41] <lifeless> RAOF: I hear tinymail works
[11:42] <juanje> cjwatson: I was trying another approach in another branch. Doing it by fixing the real bug (splashimage should allow UUID paths), but I'm still looking in the code... :-/
[11:43] <cjwatson> juanje: the syntax would be a bit tricky. What did you use?
[11:43] <juanje> cjwatson: syntax? what syntax?
[11:44] <juanje> for the path?
[11:44] <juanje> I didn't put any. The updated-grub did
[11:45] <cjwatson> juanje: in order to allow for opening images by UUID and path, the syntax of the splashimage command would need to be extended, would it not?
[11:45] <juanje> I just put the file in the right place (/boot/grub/splash.xpm.gz) and the update-grub did the work
[11:46] <juanje> ummm
[11:47] <cjwatson> and there is a fundamental problem with that because grub_open supports no syntax which allows UUIDs
[11:48] <juanje> cjwatson: yes, I saw it. But other files are opened with that with success. I think because they open first the device (or set the root device) and the open the file
[11:49] <juanje> cjwatson: well, I think... I'm not totally sure...
[11:50] <cjwatson> I'm talking about the syntax "(hd0,0)/foo/bar/baz"
[11:50] <cjwatson> if you mean the kernel and the initrd, then yes, they do so by first setting the uuid, and then opening a file relative to that
[11:50] <cjwatson> it would probably make sense to use 'uuid foo\nsplashimage /relative/path'
[11:51] <cjwatson> assuming that that actually works, mind :)
[11:52] <juanje> cjwatson:  what I did in the branch was setting the root to the uuid device before (but in the menu.lst) and then putting just the relative path for the splashimage. And in that way works
[11:53] <cjwatson> juanje: there's a separate command for setting root by uuid
[11:53] <cjwatson> juanje: you should use that, not the 'root' command
[11:53] <juanje> cjwatson: I guess the thing is doing something similar, but in the code. Just before the grub_open, setting the uuid root
[11:53] <cjwatson> juanje: well, no, it wouldn't be necessary to do that in grub_open if it were done properly in update-grub
[11:54] <cjwatson> not strictly necessary anyway
[11:54] <juanje> cjwatson: yes, I know
[11:54] <juanje> ummm
[11:54] <cjwatson> but using the 'root' command in update-grub as a workaround is right out
[11:54] <cjwatson> you need to use the 'uuid' command
[11:54] <cjwatson> at least, if $grub_root_device is a UUID
[11:54] <juanje> cjwatson: well the documentation says it's almost the same command
[11:55] <RAOF> lifeless: Hm.  Tinymail (or, at least, the 'modest' client built on it) is certainly fast; it just doesn't actually work, though :)
[11:55] <juanje> and if you are not using uuid it will working anyway
[11:55] <cjwatson> "almost the same" is not "the same"
[11:55] <juanje> cjwatson: hehe, ok
[11:55] <cjwatson> juanje: the whole *point* of the exercise is to fix things for people using UUIDs
[11:55] <cjwatson> so saying "it'll work if you aren't using UUIDs" is a bit fatuous
[11:56] <cjwatson> it works right now with no changes if you aren't using UUIDs :)
[11:56] <juanje> cjwatson: yes, probably, no one uses non uuid path, but if what if this happen?
[11:56] <juanje> ok
[11:56] <cjwatson> you use the 'root' command for such cases
[11:57] <cjwatson> look at lines 799-806 of update-grub
[11:57] <lifeless> RAOF: :)
[11:57] <lifeless> or should I say :(
[11:58] <juanje> cjwatson: yes, know those lines, I used them
[11:59] <cjwatson> juanje: not properly, though
[11:59] <pitti> Keybuk: I'd like your opinion on bug 347370 (last comment)
[11:59] <juanje> ummm
[11:59] <cjwatson> juanje: your version of it never emitted a 'uuid' command
[11:59] <juanje> cjwatson: the case didn't work well for me
[11:59] <cjwatson> juanje: that needs to be made to work
[12:00] <juanje> you mean to change the "root" command there for the "uuid" one?
[12:02] <cjwatson> juanje: if the root device is (hdX,Y), it should produce a 'root' command. If it is a UUID, it should produce a 'uuid' command - just as in the lines I referred to above
[12:02] <juanje> cjwatson: I thought about it, but I didn't because what I told you before. but I guess you're right, it must be uuid because with other paths wont get into the case
[12:02] <juanje> yes
[12:02] <juanje> you are right
[12:02] <cjwatson> actually, if the root device is (hdX,Y), there is no need to produce a 'root' command, because the 'splashimage' command's syntax can already cope with that
[12:03] <juanje> that's why i didn't in that cases
[12:03] <juanje> actually, putting root comand was an error....
[12:03] <cjwatson> in other words, if the root device is (hdX,Y), emit 'splashimage=(hdX,Y)/relative/path'; if the root device is a UUID, emit 'uuid foo-bar-baz' and 'splashimage /relative/path'
[12:03] <cjwatson> or splashimage=/relative/path I guess. I don't think it matters
[12:04] <juanje> so, the patch could be the same, but changing the root command for the uuid one, couldn't it?
[12:04] <cjwatson> yes, probably
[12:04] <juanje> ok
[12:05] <juanje> and changing directly in the update-grub, instead of using the debian/patches
[12:05] <cjwatson> yes
[12:06] <juanje> do you like i change the branch and readed? or you like to change it yourself?
[12:11] <Keybuk> pitti: if you want unmangled, use ID_FS_LABEL_ENC
[12:11] <cjwatson> juanje: I'd appreciate it if you could do it - I'm not going to have time to test changes and I have a depressing number of RC bugs of my own :/
[12:12] <juanje> cjwatson: I've just attached patch for the current main branch
[12:13] <juanje> cjwatson: I'll testing again with this code and I'll write update on the bug
[12:14] <juanje> cjwatson: thank you so much for your time. I really appreciate. I know you're quite busy...
[12:20] <Keybuk> just for _once_, I'd like usb-creator to work
[12:23] <Keybuk> "invalid compressed format (err=2)" ?
[12:24] <cjwatson> I don't think that's from usb-creator itself. gzip or something?
[12:25] <Keybuk> cjwatson: it's from trying to boot the USB keys it's making today
[12:25] <Keybuk> (of 9.04 beta)
[12:25] <cjwatson> oh, right, that's the kernel
[12:29] <Keybuk> using trunk seems to have solved it
[12:31] <Keybuk> ooh, today London has moved to the North coast of France \o/
[12:31] <cjwatson> let me see if I can do an upload
[12:31] <cjwatson> it has? it was in the right place for me
[12:32] <cjwatson> sassenfrassenmapprojections
[12:32] <Keybuk> hmm
[12:32] <Keybuk> stuck in a "The installer has detected that the following disks have mounted partitions: /dev/sdb" loop
[12:33] <cjwatson> err, is this beta or a daily?
[12:33] <cjwatson> Keybuk: there's nothing in usb-creator trunk that isn't in the beta
[12:33] <Keybuk> beta
[12:33] <cjwatson> could you try a daily please?
[12:34] <cjwatson> I want to make sure that both of those bugs are dead and gone
[12:34] <Keybuk> I'm using beta deliberately for the testing I need to do
[12:34] <Keybuk> I'm not sure whether I'll have time to play with a daily
[12:34] <Keybuk> heading to SF over the weekend
[12:34] <cjwatson> then I'd appreciate if you didn't scare me by talking about installer bugs we've already fixed?
[12:34] <Keybuk> sure, but I did *start* this by saying 9.04 beta ;)
[12:35] <Keybuk> ?! "Input/output error" now
[12:35] <cjwatson> I'm still confused about you talking about usb-creator beta vs. trunk, which AFAICS are identical
[12:35] <Keybuk> usb-creator in current jaunty didn't work for me
[12:36] <Keybuk> hmm
[12:36] <Keybuk> this is failing again due to squashfs errors
[12:36] <cjwatson> lp:~usb-creator-hackers/usb-creator/trunk is 0.1.15
[12:36] <Keybuk> weird
[12:36] <Keybuk> why aren't these images working?
[12:37] <cjwatson> are you using some different trunk? I think Evan has moved it a couple of times
[12:37] <Keybuk> no, definitely the one you say
[12:40] <Riddell> ArneGoetje: how come language-pack-kde-fr contains translation files?  shouldn't they all be in language-pack-kde-fr-base?
[12:40] <superm1> dholbach, added a comment, that's for raising that
[12:41] <dholbach> superm1: rock on!
[12:42] <cjwatson> Riddell: language-pack-kde-fr's purpose is to contain deltas on top of language-pack-kde-fr-base, to save us the expensive -base respin all the time
[12:43] <Riddell> cjwatson: and isn't that post-release only?
[12:44] <cjwatson> Riddell: sometimes during a development release too, since the full export is expensive (days of runtime, IIRC) at any time. They'll be back down to size for final
[13:21] <doko> wgrant: where does it to this?
[13:26] <wgrant> doko: I'm trying to get virtualenv working, but it's proving non-trivial becauuse python2.6 insists on sticking local/ after Python's prefix even when it's not in /usr.
[13:27] <doko> wgrant: do you use python2.6_2.6.1-1ubuntu8?
[13:27] <wgrant> doko: Yes.
[13:28] <pitti> Keybuk: is there a standard function for decoding that by any chance?
[13:28] <juanje> cjwatson: tested and updated the bug. Thanks for the help and the time :-)
[13:29] <Keybuk> pitti: it's just standard escaping no?
[13:29] <Keybuk> \x<hex>
[13:30] <pitti> Keybuk: right, I just wondered if there's some existing function to decode that, or whether I need to write it
[13:30] <Keybuk> unsure
[13:30] <doko> wgrant: please update and rehcheck. this should address the problems. Had a discussion with Larry Hastings at PyCon, who emailed about these on the distutils-sig
[13:31] <wgrant> doko: Update to what? 2.6.1-1ubuntu8 is the latest.
[13:34] <doko> wgrant: hmm, I misread. do you use the package, or the virtualenv upstream directly. in any case please file a bug report.
[13:48] <Riddell> mdeslaur: would you have an opinion on updating the lcms package to 1.18?
[13:50] <mdeslaur> Riddell: I guess we should
[13:50] <mdeslaur> Riddell: for jaunty
[13:51] <Riddell> mdeslaur: trouble is I can't see a changelog
[13:52] <Riddell> mdeslaur: oh here's a sort of one http://www.littlecms.com/whatsnew.htm
[13:52] <mdeslaur> Riddell: heh...great changelog
[13:52] <mdeslaur> Riddell: when I looked at 1.17 to 1.18beta2, it was mostly the security fixes, along with a few other things
[13:53] <superm1> mdke, thanks for that hack.sh in the interim re bug 353981. i'll just integrate that for now in new import target in my Makefile until rosetta is fixed
[14:01] <smagoun> slangasek kees: Hey guys, would you take another look at bug 316756 when you get a chance? It's a conffile prompt for login.defs on upgrade to Jaunty; I figured out how to reproduce it.
[14:05] <m4v> Riddell: bug 354493
[14:07] <ahasenack> hi guys, I prepared an FFe request for smartpm (it's in main), it's here: https://bugs.launchpad.net/ubuntu/+source/smart/+bug/349866 I think it's complete. Who can I ping to take a look at it?
[14:08] <pitti> Keybuk: oh, if it's really just \x00 style, then of course there is a decoding function --- printf() :)
[14:08]  * pitti RTFS udev
[14:09] <Keybuk> pitti: heh
[14:09] <james_w> ahasenack: the release team are subscribed, so they'll get to it soon
[14:10] <ahasenack> james_w: ok, thanks
[14:10] <Keybuk> pitti: does printf really decode those?
[14:10] <pitti> $ printf 'Pitti\x20USB'
[14:10] <pitti> Pitti USB
[14:10] <pitti> I'm checking volume_id_encode_string()
[14:11] <cjwatson> pitti: I'd be worried about %s in the string
[14:12] <Keybuk> that's the shell printf surely?
[14:12] <pitti> cjwatson: hm, true that
[14:12] <pitti> meh, why can't I just get the label as it is..
[14:13] <Keybuk> cjwatson: well, if you trust udev, you know there's no % in there
[14:13] <cjwatson> and yeah, what Keybuk said, in C \x is decoded by the compiler's lexer
[14:13] <cjwatson> or lexical analysis pass or whatever the proper name is :)
[14:13] <Keybuk> pitti: because labels can include \0, and C strings (and therefore udev's db) can't :p
[14:14] <Keybuk> hmm
[14:14] <Keybuk> actually those don't come from udev, they come from vol_id (blkid soon)
[14:14] <Keybuk> and anyone can overwrite them with a udev rule
[14:14] <pitti> ./extras/volume_id/lib/libvolume_id.c, yes
[14:15] <Keybuk> pitti: the ones you get from volume_id are *not* escaped or encoded
[14:15] <Keybuk> they're raw
[14:15] <Keybuk> you only get an escaped or encoded copy if you use udevadm
[14:15] <pitti> Keybuk: hal braindeadly calls udevadm info -e instead of just calling the volume_id_() functions for those
[14:16] <Keybuk> see, you're running a program intended to output for humans ;)
[14:16] <Keybuk> so it has to escape characters that can't be output
[14:16] <Keybuk> actually, it's pretty paranoid and just escapes everything
[14:17] <Keybuk> E:ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
[14:17] <Keybuk> there really is random crap in these strings ;)
[14:17] <Riddell> mdeslaur, m4v: bug 354493 updated with FFe request
[14:21] <mdeslaur> Riddell: I don't think we were affected by that bug, I didn't use that "untrusted" patch, I pulled the patch out of 1.18beta1
[14:21] <mdeslaur> m4v: did you get affected by the lcms update?
[14:22] <pitti> Keybuk: I'm writing a decode_escape() function now; can't be more than 10 lines anyway
[14:22] <m4v> mdeslaur: yes, as soon as it was updated
[14:22] <m4v> Riddell: great, I will try to update from your ppa
[14:23] <mdeslaur> m4v: do you have steps I can use to reproduce the issue?
[14:26] <m4v> mdeslaur: only if you have koffice2 compiled from kde's svn, basically Krita asserted when opening any .kra file
[14:27]  * Riddell notes that koffice2 is in jaunty
[14:27] <Keybuk> pitti: that should go in libudev I reckon
[14:27] <Keybuk> alongside the encode one
[14:27] <pitti> would be handy
[14:27] <pitti> OTOH
[14:27] <pitti> Keybuk: if you are using libudev, you can just use the non-encoding functions in the first place
[14:28] <m4v> ah, i didn't know, that should work, just open krita, paint something, save as kra, and try to open it again, I'll try it mysql
[14:28] <Keybuk> pitti: things like the labels don't come from udev though
[14:28] <m4v> myself*
[14:28] <Keybuk> udev *gets* them encoded from blkid
[14:28] <Keybuk> and never decodes them itself
[14:28] <Keybuk> so a decode function would be useful
[14:28] <pitti> ah, I see
[14:30] <Keybuk> err, vol_id in this case
[14:30] <Keybuk> but the same holds true in the future
[14:36] <mdeslaur> m4v: work for me with the version in jaunty. Do you have color profiles configured in it?
[14:37] <ttx> pitti: remember when joining a domain with likewise-open would break desktop things by aggressively restarting DBUS ? we fixed it by reloading instead...
[14:37] <ttx> pitti: but likewise-open5 *requires* (according to upstream) DBUS restart to pick up nsswitch changes
[14:38] <pitti> ttx: I don't, I haven't looked into likewise-open at all
[14:38] <Riddell> mdeslaur, m4v: I confirm krita crashes using current lcms and doesn't with 1.18
[14:38] <pitti> ttx: why woudl dbus be affected by an nsswitch change?
[14:38] <Riddell> when opening a .kra file
[14:39] <Riddell> mdeslaur: are you using krita-kde4  ?
[14:39] <m4v> Riddell: yep, I get it too, if you open krita from a console, you should see an assert
[14:39] <mdeslaur> Riddell: oh, no, sorry
[14:39] <ttx> pitti: good question. Not restarting DBUS results in "Failed to initialize HAL" when logging in as a domain user
[14:39] <ttx> pitti: upstream says it's required for glibc to pick up the nsswitch change
[14:40] <ttx> http://lobugs.likewise.com/show_bug.cgi?id=17
[14:40] <ttx> "DBUS is not able to resolve the user's id"
[14:40] <pitti> oh, for enforcing the policies
[14:40] <m4v> mdeslaur: not that i know of, i use the sRGB built-in (lcms internal) if that's what you mean. and I delete krita stuff in ~/.kde regulary
[14:41] <pitti> ttx: that's just an one-time problem after installation, no?
[14:41] <pitti> ttx: perhaps you should just trigger the 'reboot requried' notification in likewise's postinst then?
[14:41] <ttx> yes. And Windows requires to reboot as well.
[14:41] <ttx> pitti: I suppose yes. What is the proper way of doing that ?
[14:41] <ttx> hhhmm no.
[14:42] <ttx> pitti: it's a one-time thing after domain join, not package install.
[14:43] <ttx> pitti: but I have a script run (the one mentionned on http://lobugs.likewise.com/show_bug.cgi?id=17) on which I can execute things rather than restarting/breaking DBUS
[14:44] <ttx> pitti: so perhaps I could trigger the reboot required notification from there ?
[14:44] <pitti> ttx: sure
[14:44] <pitti> ttx: just call /usr/share/update-notifier/notify-reboot-required
[14:44] <ttx> pitti: sounds simple enough :)
[14:45] <facundobatista> Hello all
[14:45] <facundobatista> tkamppeter, ping
[14:45] <ttx> pitti: many thanks :)
[14:46] <pitti> facundobatista: I think you should probably just followup on bug 348316; Till reads it, and he needs some tests (especialy with older kernels)
[14:47] <mdeslaur> m4v: oh, yeah, I see the problem
[14:47] <mdeslaur> Riddell: I was fixed between beta1 and beta2, I can either fix the patch, or we can go to 1.18
[14:48] <m4v> w00t, both my build and krita-kde4 works with Riddell's lcms
[14:49] <facundobatista> pitti, ok, thanks
[14:57] <m4v> mdeslaur: probably up to 1.18 is better, it seems is going be a requirement for koffice2
[14:58] <ttx> pitti: won't notify-reboot-required only notify you if update-manager is running ? I need to ask for a reboot after the domain is joined (triggered by domainjoin-cli or domainjoin-gui) so update-manager is not running at that time. Anything I should/could plug into ? notify-send ?
[14:58] <pitti> ttx: update-notifier, not manager
[14:58] <mdeslaur> m4v: ok, great
[14:58] <pitti> ttx: if you aren't logged into GNOME, you won't get it, right
[14:59] <m4v> mdeslaur: from koffice maillist, http://lists.kde.org/?l=koffice-devel&m=123874884601650&w=2
[14:59] <ttx> pitti: I'll test some more, it doesn't seem to trigger on my test rig.
[15:02] <mdeslaur> m4v: ok, let's go to 1.18
[15:02] <ttx> pitti: the /var/run stuff is created but update-notifier doesn't trigger anything. Maybe it still sleeps.
[15:05] <pitti> mvo: ^ hmm
[15:06] <ttx> pitti: yep, running an apt-get afterwards triggers the notification.
[15:07] <ttx> so it's not really usable in my case
[15:08] <mvo> ttx: it needs a touch to /var/lib/update-notifier/dpkg-was-run too
[15:09] <mvo> ttx: its designed to be part of the upgrade process and that file is touched when the upgrade is finished
[15:09] <ttx> mvo: testing that, thx
[15:29] <calc> cjwatson: i think they should be compatible in this case since they appear to be the same files in two different packages
[15:29] <pitti> Keybuk: would you mind eyeballing this? http://paste.ubuntu.com/143509/
[15:29] <pitti> works well for me
[15:29] <cjwatson> calc: ok, thanks - can you take responsibility for changing hunspell based on the discussion?
[15:30] <calc> cjwatson: hmm rene wants me to look at it again
[15:30] <cjwatson> (once you've agreed it etc.)
[15:30] <calc> cjwatson: and he thinks that myspell-en-us should be the one going away
[15:31] <cjwatson> calc: right, if that's the case, hunspell's dependencies should change to list hunspell-en-us as the first alternative
[15:32] <calc> ok
[15:34] <tkamppeter> facundobatista: Hi
[15:36] <facundobatista> tkamppeter, hi, I was just about to offer you my PC to test the printer issue in #348316, but then I found that I need to try some of what you wrote there
[15:49] <pitti> Keybuk: I fixed a thinko in the UTF-8 validation, it's http://cgit.freedesktop.org/hal/commit/?id=97b023f94f1d79a19bc0489c0d167bdaebb765fd now
[15:51] <NCommander> cjwatson, Good afternoon
[15:52] <cjwatson> NCommander: it's open in my browser :) looks fine, I just want to do a couple of final checks and then I'll upload it
[15:53]  * NCommander wonders when cjwatson installed telepathy and thus read my mind
[16:00] <calc> cjwatson: do you remember that bug number? i need to add a few packages to it
[16:02] <siretart> mvo: are update-manager's dist-upgrades to jaunty re-enabled yet?
[16:03] <cjwatson> calc: bug 327821
[16:04] <calc> cjwatson: ok thanks
[16:05] <pitti> seb128: wow, the retracer caught up and didn't crash \o/ *phew*
[16:06] <calc> cjwatson: ok this seems to only affect hunspell and thunderbird, and thunderbird is not of the cd so isn't critical to fix before release
[16:06] <calc> cjwatson: i'll fix up hunspell
[16:07] <cjwatson> thanks
[16:07] <cjwatson> plenty of time to fix tb still :)
[16:07] <calc> yea
[16:08] <UsamaAkkad> hello, I've something needs a bit intention
[16:08] <UsamaAkkad> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
[16:08] <UsamaAkkad> lets say I don't have internet and I want to update my system
[16:09] <UsamaAkkad> the synaptic generate download script worked for me fine when I had Dial-up connection
[16:09] <UsamaAkkad> but what if someone has no connection at all
[16:09] <UsamaAkkad> any one interested ?
[16:12] <seb128> pitti: excellent ;-)
[16:15] <calc> cjwatson: done
[16:22] <Riddell> mdeslaur: I'll upload lcms 1.18 then
[16:23] <mdeslaur> Riddell: thanks
[16:26] <facundobatista> tkamppeter, ok, I tried everything on the mentioned bug (#348316 in lp), and now I can't even see my printer (see the bug for full details)
[16:26] <facundobatista> tkamppeter, just let me know anything you want to test
[16:39] <kees> smagoun_: oh good!  I can't tell you how many upgrade I've run trying to find that one.
[16:39] <tkamppeter> facundobatista: Have you done "sudo aa-conplain cupsd"?
[16:41] <tkamppeter> facundobatista: Did you unload the usblp kernel module and did you blacklist it?
[16:41] <james_w> kees: thanks for looking at it. I have an idea for a patch to system-tools-backends to stop it doing that. I fear I may not want to show it to you though
[16:41] <facundobatista> tkamppeter, yes to both
[16:42] <facundobatista> tkamppeter, in the other order, though (modified the blacklist file first, then unloaded the moldule)
[16:43] <tkamppeter> facundobatista: That is all OK.
[16:43] <tkamppeter> Did the module actually unload ("lsmod | grep usb")?
[16:44] <tkamppeter> facundobatista: What is the output of /usr/lib/cups/backend/usb
[16:44] <facundobatista> tkamppeter, modules loaded: there's a usbhid, and the rest are all modules for usb sound
[16:45] <facundobatista> tkamppeter, but no usblp
[16:45] <tkamppeter> facundobatista: Yes, then the module got correctly unloaded.
[16:45] <tkamppeter> Can you run /usr/lib/cups/backend/usb now?
[16:45] <facundobatista> yes:
[16:46] <facundobatista> DEBUG: list_devices
[16:46] <facundobatista> DEBUG: usb_find_busses=2
[16:46] <facundobatista> DEBUG: usb_find_devices=5
[16:46] <facundobatista> and then it gives me a "symbol lookup error"
[16:46] <facundobatista> undefined symbol: _ppdGet1284Values
[16:47] <kees> james_w: haha, I'm curious to see it, regardless.  I figure I'll have to patch shadow to do a preinst change on the file itself.
[16:47] <tkamppeter> Did you install all binary packages of the CUPS from my PPA? Especially also the new libcups package is needed.
[16:47] <james_w> kees: well the patch is sensible I think, it's what it implies about the existing code that worries me
[16:48] <facundobatista> tkamppeter, mmm... let me see... I just installed the .deb you mentioned
[16:48] <slangasek> calc: I swear we had a conversation about when the next OOo upload was going to be, and now I can't find it in my logs at all... :)  did that conversation happen, and what was the answer? :)
[16:49] <facundobatista> tkamppeter, oh, I didn't install any libcups...
[16:49] <tkamppeter> facundobatista: Install also the new libcups2 package.
[16:49] <kees> james_w: well, you already know my opinion of that code-base.  :)
[16:50] <james_w> yeah
[16:50] <james_w> it's not as bad as the other issue thankfully
[16:50] <facundobatista> tkamppeter, what about libcupsimage2, and libcupsys2?
[16:50] <james_w> kees: bug 354378 is quite a fun one I found today
[16:50] <facundobatista> tkamppeter, cups-client? cups-common?
[16:51] <james_w> 'cos I'm sure you haven't got much to do and can spend time looking at random bugs :-)
[16:51] <tkamppeter> They are not needed. All *cupsys* are even only transitional package which do not contain any files or maintainer scripts.
[16:51] <kees> james_w: oooh, owchy.
[16:52] <kees> heh, nah, I like knowing the reality of a situation.  :)
[16:52] <facundobatista> tkamppeter, ok
[16:53] <james_w> kees: I also noticed that while the policykit design is pretty sane generally it does actually pass an unencrypted password over a file descriptor at one point
[16:53] <james_w> as you can see, the user in that bug had to redact it from the strace
[16:53] <james_w> is that a concern? It seems like it doesn't open too much of a hole.
[16:53] <slangasek> well, as opposed to doing what with it?
[16:54] <kees> james_w: well, a fd's not totally crazy.
[16:54] <UsamaAkkad> any one can tell me who should I ask about this ?
[16:54] <UsamaAkkad> #251378
[16:54] <slangasek> unless policykit is running as root, it has to pass it over a pipe to unix_chkpwd
[16:54] <UsamaAkkad> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
[16:54] <slangasek> for unix auth
[16:54] <kees> james_w: I mean, passwords float through the tty fds, so it's not much different
[16:54] <james_w> slangasek: yeah, I'm not sure there's an alternative, I thought it was worth asking
[16:55] <james_w> slangasek: in this case it passes it to a process running as root which can communicate with pam, so it's equivalent
[16:55] <tkamppeter> facundobatista: Does CUPS now detect your printer?
[16:55] <slangasek> james_w: hrm, that's... odd. :)
[16:55] <slangasek> second-guessing PAM?
[16:56] <slangasek> well; you have to do that if your process is non-root and not running as the user you want to auth
[16:56] <james_w> yeah
[16:56] <james_w> often it is, but not always
[16:57] <james_w> and it needs to add an entry to polkit's auth db anyway, which needs to be root controlled for obvious reasons
[16:57] <facundobatista> tkamppeter, yes! wee...
[16:57] <facundobatista> tkamppeter, let me see how it goes
[16:57] <facundobatista> ...searching for controllers...
[16:57] <facundobatista> selecting "Foomatic/foo2xqx"
[16:58] <facundobatista> sending test page print
[16:58] <facundobatista> printer state: "processing"... and nothing happens
[16:59] <facundobatista> it just stays there...
[17:00] <facundobatista> tkamppeter, and one process, from "lp" user, is taking 100% of one processor
[17:03] <tkamppeter> facundobatista: what is the name/command line of the process ("ps auxwww | grep '^lp '")?
[17:04] <facundobatista> tkamppeter, that is strange... the command, or at least what appears in the ps or top is:
[17:04] <tkamppeter> facundobatista: Looks like that thgis backend principally works but does not fix the bug. So it is really as I assumed, the backend is not the culprit.
[17:04] <facundobatista> "usb://HP/HP%20Laserjet.... 152 facundo Test Page 1 job-...
[17:05] <tkamppeter> facundobatista: That is the USB backend, it tries to feed the data into the appropriate port of the kernel but the kernel does not let the data in.
[17:05] <facundobatista> tkamppeter, damn
[17:06] <facundobatista> tkamppeter, do you want me to comment something in the bug?
[17:06] <tkamppeter> facundobatista: So your next step is to try running Jaunty wityyh the kernel of Intrepid.
[17:06] <tkamppeter> facundobatista: Comment these results in the bug. So people who are not here on IRC in the moment (kernel developers perhaps) know what happened.
[17:07] <tkamppeter> facundobatista: Did you update from Intrepid to Jaunty?
[17:07] <facundobatista> tkamppeter, question... when I boot, GRUB offers me two kernels: 2.6.28-11, and 2.6.27-11, but both as "Jaunty"
[17:07] <facundobatista> tkamppeter, yes I did
[17:08] <tkamppeter> facundobatista: Then you did a fresh Jaunty installation and not an upgrade from Intrepid, or you played around with strange tools like computer-janitor.
[17:08] <facundobatista> tkamppeter, I upgraded, and didn't run the janitor
[17:10] <tkamppeter> Strange that all the old kernels go away when you upgrade.
[17:11] <facundobatista> tkamppeter, don't remember what happened when upgraded from hardy to intrepid...
[17:13] <tkamppeter> facundobatista: Perhaps you could do the following: Find the kernel package of intrepid on Launchpad and install it onyour system. It should not have dependencies or only dependencies on kernel components. All what you need to install should be packages with version numbers in their names, so nothing of Jaunty should get overwritten. If you reboot then, the old kernel should appear in the boot menu.
[17:14] <facundobatista> tkamppeter, ok, I'll try that
[17:16] <cjwatson> slangasek: http://paste.ubuntu.com/143572/ look OK to you? there's only one difference in its output, and it's a bug in ruby's gettext parser :-)
[17:16] <facundobatista> tkamppeter, (but later)
[17:16] <slangasek> cjwatson: <laugh>
[17:16] <cjwatson> slangasek: (it misparses \\r in the middle of multibyte strings as \ \r rather than \\ r)
[17:16] <m4v> Riddell: mdeslaur: when lcms 1.18 will be available in jaunty repos?
[17:17] <slangasek> cjwatson: looks good to me!
[17:17] <slangasek> (and way better than the ruby looked :P)
[17:17] <cjwatson> slangasek: oh, the only difference is that it needs to be run on .mo rather than .po
[17:17] <cjwatson> ok, I'll upload it
[17:18] <slangasek> cjwatson: ...which saves us a step, so. :)
[17:19] <mdeslaur> m4v: Riddell uploaded it, so it should be on it's way once it's built...in the next hour or two maybe?
[17:19] <slangasek> cjwatson: does python's gettext module automatically give you utf8, or does it just happen to not be an issue?
[17:20] <m4v> mdeslaur: ah, thanks! :D
[17:20] <amgarching> does it make sense trying to install gcc-snapshot (20090327-0ubuntu1) from Jaunty repos onto Intrepid?
[17:26] <cjwatson> slangasek: the ugettext method gives you a Unicode string
[17:26] <slangasek> cjwatson: spiff
[17:27] <cjwatson> there are a few charset=EUC-JP .po files in there
[17:27]  * slangasek nods
[17:39] <alex-weej> any Qt maintainers/experts here? got a bug in Jaunty wrt font settings
[17:40] <jpds> alex-weej: Maybe #kubuntu-devel might be able to help.
[17:40] <alex-weej> jpds: ta
[17:58] <calc> slangasek: hopefully later today or by end of weekend at latest
[17:59] <slangasek> ok
[17:59] <calc> slangasek: i was holding off on the upload until after lp 2.2.3 came out wed night
[17:59] <slangasek> ah, right
[18:00]  * calc wishes bugs were harder to file, keep getting duplicate bug reports, argh
[18:01] <ScottK> calc: How about LP had a better U/I for moving people to accepting something is a dupe?
[18:01] <calc> ScottK: that might help too... though the percentage of non apport bugs suggests they would still try to file bad bugs :\
[18:02] <ScottK> I think the current 'would you like to subscribe to one of these' approach is not an appealing alternative to filing a new bug.
[18:04] <maxb> Didn't update-manager used to keep its progress window open if you'd expanded the embedded terminal view?
[18:04] <maxb> It seems to have stopped doing that for me.
[18:33] <maco> Jaunty has version 2.4.12 of Openswan, but the current 2.4.x (which has security fixes) is 2.4.14.  Aside from that there's a 2.6.21.  Would it make more sense to grab last week's security patch and apply it to what we've got or to update to the latest release of the 2.4.x line?
[18:34] <ScottK> maco: If it's bugfixes only, probably just update.
[18:38] <maco> yep, memory leaks and security bugs
[18:48] <rolianne> hi.. why is my newly installed 8.10 cant connect to the internet? what should I do?
[18:49] <rolianne> err
[18:49] <rolianne> bye
[18:55] <phaidros> hi, I have seen in launchpad as well in package names that there is a hardy version 8.04.3 and 8.04.4 .. all my uptodate machines are 8.04.2
[18:55] <phaidros> is .3 and .4 planned? or virtual?
[18:57] <LaserJock> phaidros: have a look at the bottom of https://wiki.ubuntu.com/HardyReleaseSchedule
[18:57] <phaidros> ah ic, thanks LaserJock
[19:13] <NCommander> cjwatson, how'd your testing w/ my shadow patch go?
[19:40] <BUGabundo> hi guys
[19:40] <BUGabundo> where would I redirect bug 354682 ?
[19:40] <BUGabundo> maybe evan?
 Hi <gon>: I have some problems connecting to wireless network in some place <gon>: In 8.10 works fine, but in jaunty can't connect
[19:42] <hyperair> gon: wrong place to ask. head to #ubuntu.
[19:42] <hyperair> i mean #ubuntu+1
[19:44] <gon> !
[19:45] <BUGabundo> hyperair: we won't be able to help him much there either
[19:45] <hyperair> BUGabundo: really?
[19:45] <BUGabundo> lets see
[19:45] <hyperair> BUGabundo: what be up anyway
[19:46] <BUGabundo> if it is user stuff we can
[19:46] <BUGabundo> if it is packages stuff, most of us in there won't be able to help much
[19:46] <BUGabundo> which seem to be the case
[19:46] <hyperair> does it really?
[19:47] <hyperair> what seems to be the issue then
[19:47] <BUGabundo> humm
[19:47] <BUGabundo> he is using knetworkmanager
[19:47] <BUGabundo> which is broken badddddd
[19:47]  * hyperair quickly backs away.
[19:47]  * hyperair hides in the corner
[19:48]  * hyperair waves a flag saying "network-manager-gnome banzai!"
[19:48] <BUGabundo> eheh
[19:48] <BUGabundo> pop up on +1
[19:48] <BUGabundo> all help is appreciated
[19:48] <hyperair> but i've never even used kde before
[19:48] <hyperair> well i ahve, but not more than a week.
[19:48] <hyperair> never got past configuring it.
[19:49] <LaserJock> BUGabundo: what do you mean by "when booting with casper"?
[19:49] <BUGabundo> I don't use it either
[19:49] <BUGabundo> but I do help on anything users trow at me
[19:49] <BUGabundo> LaserJock: humm the boot from CD/USB
[19:49] <hyperair> BUGabundo: i would help, if my accounts exam isn't in 10 days ;)
[19:49] <BUGabundo> isn't that casper?
[19:49] <hyperair> casper's a friendly ghost
[19:49] <LaserJock> BUGabundo: from the Desktop CD, yes
[19:49]  * BUGabundo makes some voodoo and gets hyperair exams reschedule
[19:50] <hyperair> BUGabundo: if only that worked =(
[19:50] <BUGabundo> LaserJock: then that's what I'm trying to say
[19:50] <LaserJock> BUGabundo: what specifically does the F6 menu say?
[19:50] <BUGabundo> Show extra options
[19:50] <BUGabundo> like acpi off, etc
[19:50] <LaserJock> right
[19:51] <BUGabundo> go buntu
[19:51] <LaserJock> and there is one that says "Edubuntu"?
[19:51] <BUGabundo> one of them is for Edubuntu
[19:51] <BUGabundo> but its badly worded
[19:51] <BUGabundo> just says edu=on
[19:51] <LaserJock> how odd
[19:51] <BUGabundo> no oned guess what that is
[19:51] <BUGabundo> I ask on the bug to re-write it with
[19:51] <BUGabundo> just Edububuntu
[19:52] <BUGabundo> and then the Flag enabled by the user
[19:52] <BUGabundo> LaserJock: does it makes any sense to you ?
[19:52] <LaserJock> not yet, no
[19:53] <BUGabundo> if it is an option, just saying what it is, should be enough
[19:53] <BUGabundo> no need for "edd=on"
[19:54] <LaserJock> is it edd or edu?
[19:55] <BUGabundo> no sure now
[19:55] <BUGabundo> you got me confused
[19:55] <BUGabundo> eheh
[20:01] <BUGabundo> bbl
[20:16] <pjwaffle> hi
[20:28] <mnemo> thiebaude: what intel chipset is it you're having problems with btw? (you can tell using "lspci -nn | grep VGA")
[20:30] <thiebaude> 00:02.0 VGA compatible controller [0300]: Intel Corporation 82815 Chipset Graphics Controller (CGC) [8086:1132] (rev 04
[20:30] <thiebaude> i can log into gnome only using 2.6.24-24 generic kernel
[20:31] <thiebaude> ubuntu 9.04 works, but only with the older kernel
[20:31] <mnemo> hmm, so its some sort of regression then :(
[20:32] <thiebaude> yea, i've had no problems with alpa's and beta's and i've been using ubuntu since 6.06
[20:32] <thiebaude> i've had this 81815 since 6.06
[20:32] <mnemo> thiebaude: can you please open a bug in LP explaining this?
[20:32] <mnemo> use the command "ubuntu-bug xorg" to file it
[20:33] <mnemo> then it will attach lots of interesting data automatically
[20:33] <thiebaude> ubuntu web site says bug 304871
[20:33] <thiebaude> ok
[20:35] <mdke> superm1: no worries :)
[20:46] <pjwaffle> hey how do you base a distribution off of another distribution eg. ubuntu
[20:46] <pjwaffle> I would like to use the init scripts and maybe apt-get to create a rolling release distro
[20:50] <pjwaffle> IMHO ubuntu needs a rolling release distro to test really early development packages eg. kernel 2.6.29
[20:50] <pjwaffle> like debian's sid
[20:50] <BUGabundo> pjwaffle: go try fedora
[20:50] <mnemo> fedora is not rolling release
[20:50] <BUGabundo> we need some time to stablize
[20:50] <mnemo> try rawhide
[20:50] <pjwaffle> I know they have rawhide but I use apt-get and debian packages
[20:50] <BUGabundo> and then the next cycle begins again
[20:50] <BUGabundo> for cutting edge use bzr or PPAs
[20:50] <pjwaffle> and sid is not so driver-friendly
[20:50] <mnemo> pjwaffle: ubuntu offers the ability to test mainline kernels and latest xorg bits though
[20:52] <pjwaffle> well you know my question is how do you base off another distro?
[20:52] <pjwaffle> I would consider myself an intermediate/early-experienced user
[20:52] <BUGabundo> either use what is available to you or package your own newer versions
[20:53] <pjwaffle> I mean do you just use cp and copy the init scripts to your chroot or what? isn't there a version control for the entire ubuntu distro?
[20:53] <savvas> any main sponsors here? I would like your opinion on bug #315679 - should I try to merge the new version of libmtp from Debian?
[20:54] <pjwaffle> well ok fine what is the ubuntu repo for the initscripts on bazaar
[20:56] <BUGabundo> LaserJock: ping
[20:56] <LaserJock> BUGabundo: yeah?
[20:56] <BUGabundo> how can I make the bug clear?
[20:56] <cjwatson> pjwaffle: unfortunately not everything is in revision control (yet)
[20:56] <BUGabundo> you seemed to have some questions about it?
[20:56] <cjwatson> BUGabundo: that casper bug? it's invalid.
[20:57] <pjwaffle> oh :(
[20:57] <cjwatson> edd has nothing to do with edubuntu
[20:57] <BUGabundo> cjwatson: :(
[20:57] <LaserJock> that's what I was trying to figure out
[20:57] <BUGabundo> ok that makes it clear
[20:57] <BUGabundo> what is it then?
[20:57] <LaserJock> I couldn't see why there would be anything Edubuntu in the menu
[20:57] <cjwatson> I replied to your bug
[20:57]  * BUGabundo looks
[20:57] <cjwatson> pjwaffle: we hope that this will be rectified over the next release cycle or two, though
[20:58] <BUGabundo> BIOS Enhanced Disk Drive Services 3.0 (EDD)
[20:58] <BUGabundo> got it
[20:58] <BUGabundo> still its bad wording, no?
[20:58] <cjwatson> pjwaffle: merges.ubuntu.com helps us to deal with the six-monthly merge from Debian
[20:58] <BUGabundo> no need to have the ON there!
[20:58] <cjwatson> BUGabundo: it's advanced options. I don't care.
[20:58] <cjwatson> BUGabundo: the kernel option is literally "edd=on"
[20:58] <BUGabundo> ok ok
[20:58] <BUGabundo> then never mind
[20:58] <BUGabundo> sorry for the noise
[21:13] <cjwatson> NCommander: uploaded
[21:13] <cjwatson> sorry for the delay
[21:14] <NCommander> cjwatson, no problem
[21:58] <mvo> kirkland: I updated #352307
[21:58] <kirkland> bug #352307
[22:00] <mvo> kirkland: you probably cover the server use case already with update-motd? I'm not sure if kde supports this feature of update-notifier though
[22:01] <kirkland> mvo: i don't ...  we don't have per user messages in update-motd ...  i'll need to think about this
[22:01]  * mvo nods
[22:01] <mvo> update-notifier-text
[22:05] <kirkland> mvo: actually, for intrepid, we handled it in the alternate/server case in the installer
[22:05] <kirkland> mvo: there was a page that popped up, and showed the user their password, and told them to record it
[22:06] <kirkland> mvo: for some reason, that page isn't getting displayed in Jaunty
[22:06] <mvo> right, I remember this page I think
[22:06] <kirkland> mvo: i've ping cjwatson about turning that back on
[22:06]  * mvo nods
[22:09] <kees> james_w: is there actually a bug open for the g-s-t UID_MIN rewriting?
[22:09] <james_w> kees: nope
[22:09] <Amaranth> mvo: Do you think the nvidia workaround should be on by default?
[22:10] <james_w> kees: do you think a task on the existing bug would be appropriate, or a new bug?
[22:10] <Amaranth> Although I don't think the workaround is included in the packages right now...
[22:10] <kees> james_w: probably a task, keeps it all in one place
[22:10] <kees> james_w: which src pkg should I open it against?
[22:10] <james_w> system-tools-backends
[22:11] <mvo> Amaranth: which one?
[22:11] <kees> james_w: okay, cool.  assign it to you?
[22:11] <Amaranth> mvo: bug 269904
[22:11] <james_w> kees: sure
[22:11] <Amaranth> mvo: It's a pretty simple patch but it causes a small performance loss
[22:12] <Amaranth> mvo: http://launchpadlibrarian.net/23889138/compiz-fusion-plugins-main_0.8.2-0ubuntu2.debdiff is the relevant bit
[22:13] <mvo> Amaranth: I remember seeing the commit in git, but that does make everything pretty slow dosn't it. or is the nvidia HW fast enough to deal with this kind of syncs?
[22:13] <Amaranth> mvo: nvidia hardware is plenty fast to handle it, not sure how other systems will
[22:14] <Amaranth> mvo: I don't think there is that much of a slowdown but the only people that have tested it are nvidia users
[22:14] <Amaranth> I don't really have time to play with it until tomorrow but I can try it on intel then
[22:14] <mvo> I'm pretty sure we have the half-fix from aaron, this workaround a bit scary. also having it sounds fine
[22:14] <Amaranth> Just wanted to make sure you saw it
[22:15] <mvo> enable-by-default hmmmmm
[22:15] <mvo> Amaranth: please try
[22:15] <mvo> Amaranth: we could add more magic to compiz-manager to enable it only for peole with -180
[22:16] <mvo> Amaranth: my intel system had a mainboard meltdown, I can test this at monday afternoon (then I should get a replacement)
[22:17] <gouki> Anyone has a jaunty debootstrap script?
[22:17] <mvo> Amaranth: thanks a lot for raising it!
[22:17] <kees> gouki: I also just use mk-sbuild-lv, but that's pretty LVM/sbuild-specific
[22:17] <Amaranth> mvo: true, we already detect nvidia in there
[22:17] <Amaranth> mvo: I guess I've got a couple minutes, let me get it built
[22:18] <mvo> Amaranth: I apply the diff, having it is certainly good and will not do any harm
[22:18] <gouki> kees, I wanted to create a jaunty file system for user-mode linux.
[22:19] <kees> gouki: hrm, in that case, I'd just use debootstrap directly
[22:20] <Amaranth> mvo: I've got it enabled now on X3100, seems fine
[22:21] <Amaranth> mvo: seems to make Xorg CPU usage go up a couple percent though
[22:21] <gouki> kees, but I still need the specific options for jaunty present on the /usr/share/debootstrap/scripts, right?
[22:22] <kees> gouki: nah, just symlink intrepid to jaunty
[22:22] <kees> they're mostly already symlinks.  :)
[22:22] <Amaranth> mvo: should probably put out a call for testing after a package with the fix is uploaded, see if anyone notices problems with various hardware after a couple days use
[22:23] <mvo> Amaranth: right, I will just upload the fix with the enables "false" default for now so that people can at least enable it
[22:23] <mvo> Amaranth: and ponder about it some more later
[22:24] <gouki> kees, but there isn't even a hardy (nor intrepid, for that matter) script on the debootstrap package. :S
[22:25] <jpds> gouki: There are, they all link to hardy's.
[22:25] <maxb> gutsy's, actually
[22:26] <kees> yeah, link to gutsy.
[22:26] <kees> $ dpkg -L debootstrap | grep hardy
[22:26] <kees> /usr/share/debootstrap/scripts/hardy
[22:26] <maxb> gouki: Are you using a really out of date debootstrap?
[22:26] <kees> $ ls -la /usr/share/debootstrap/scripts/hardy
[22:26] <kees> lrwxrwxrwx 1 root root 5 2009-03-19 17:17 /usr/share/debootstrap/scripts/hardy -> gutsy
[22:27] <gouki> maxb, I was under the impression I tested with debootstrap from jaunty, but that clearly isn't the case.
[22:27] <gouki> Well, thank you all very much for the help. :)
[22:27] <kees> np
[22:28] <gouki> It's there indeed :) My bad.
[22:34] <picklesworth> Hey folks! What's the status on appending notifications for Pidgin? Any way I can help that along?
[22:35] <YokoZar> picklesworth: what kind of notifications
[22:35] <YokoZar> you mean like more than one at once?
[22:36] <picklesworth> ( Speaking of Pidgin, it's being hopelessly unstable today :/ )
[23:15] <maxb> mvo_: I think update-manager used to not auto-close its progress window if you display the embedded terminal - was this a deliberate feature? It seems to have broken.
[23:15] <mvo_> maxb: there is a checkbox for this that should remember its state
[23:16] <mvo_> maxb: assuming you mean normal update and not release upgrades ?
[23:16] <maxb> yes, normal updates. Where is this checkbox? I've not seen it! :-)
[23:16] <maxb> (ever!)
[23:16] <mvo_> maxb: did you every switched it when running synaptic normally?
[23:17] <mvo_> maxb: give me a sec, i check the name
[23:18] <mvo_> maxb: /root/.synaptic/synaptic.conf - there is a option called "closeZvt" - what values does that have?
[23:18] <maxb> Not present in the file
[23:19] <maxb> on one of my machines, that is. Set to "false" on the other, but it still closed.
[23:22] <mvo_> maxb: hm, odd. let me try to reproduce
[23:25] <mvo_> maxb: heh :) turns out this was changed back in intrepid, the key to control it is /apps/update-manager/autoclose_install-window
[23:25]  * mvo_ has faulty memory
[23:25]  * maxb fires up gconf-editor
[23:26] <maxb> It's on... but not in my per-user gconf
[23:27] <maxb> Also, IIRC it didn't always close or always not-close - it depended on whether you expanded the Details terminal or not
[23:27] <mvo_> oh, I see now what you mean. I don't think it was that clever, but actually that would be a good feature
[23:27]  * mvo_ is a bit tired already
[23:28] <maxb> How puzzling. Surely I can't have hallucinated this feature? :-)
[23:28]  * maxb boots intrepid for some comparative testing
[23:34] <mvo_> maxb: let me know, but I will have to crash soonish. just poke me when I'm online again
[23:36] <maxb> Huh. It doesn't work on Intrepid either, which suggests I may have somehow managed to totally confuse myself
[23:36] <maxb> I will grab a colleague who's still running Hardy on Monday for further experimentation.