[12:13] <cjwatson> tepsipakki: I don't think that would be too interesting in most cases; the merges that actually matter (IMO) are the new upstreams, in this case
[12:13] <cjwatson> exobuzz: that's not bash_completion, it's lesspipe
[12:13] <Chipzz> tepsipakki: no, with zsh you get the whole bakery :P
[12:13] <exobuzz> cjwatson: aah. ok.. good because ive hunting for where i can change this behaviour :-)
[12:13] <Chipzz> ie >20MB mem usage *per instance*
[12:15] <_ion> 5148..6472 KiB on my box
[12:16] <_ion> Oh, that was virtual. Resident: 2480..3128
[12:17] <exobuzz> cjwatson: ok thanks. now ive made my own filter override. im happy :)
[12:21] <ogra> tepsipakki, xscreensaver uploaded, thanks again
[12:22] <tepsipakki> ogra: no problem ;)
[12:24] <exobuzz> oh daniel stone is on the x.org board of directors
[12:24] <exobuzz> didnt realise that
[12:29] <cjwatson> it can't deal with something that's both a keyboard-type device *and* a mouse-type device
[12:30] <exobuzz> cjwatson: that's linux on your intel mac ?
[12:30] <exobuzz> cjwatson: via bootcamp, or efi ?
[12:30] <exobuzz> (elilo)
[12:31] <cjwatson> bootcamp
[12:31] <cjwatson> yes, Ubuntu
[12:31] <exobuzz> one problem with bootcamp..
[12:31] <exobuzz> unplug your monitor and try booting
[12:32] <cjwatson> I'll believe you
[12:32] <exobuzz> i configured my machine, posted it to the hosting company, and then they told me it wasnt booting.
[12:32] <exobuzz> turns out: "It is important to test that your Mac Mini will boot correctly without a screen. In particular, if you rely on the Apple "Boot Camp" firmware update (which provides a legacy BIOS, so that the machine can be booted like a conventional PC), then you may encounter trouble with this, because the VGA BIOS which the machine installs typically blocks trying to communicate with the monitor using DDC."
[12:32] <exobuzz> very annoying
[12:33] <tepsipakki> hmm, I diff'ed xorg-server upstream tarball and our orig.tar.gz, and it was like 800kB :I
[12:33] <exobuzz> in the end, i got them to switch it to efi/elilo.. actually the hosting guys have it netbooting, so if i make it unbootable they can netboot to a recovery kernel/disk which is handy
[12:33] <tepsipakki> the same version
[12:33] <exobuzz> tepsipakki: maybe its a big readme :)
[12:34] <tepsipakki> if only
[12:34] <cjwatson> unfortunately current versions of Linux can't drive the framebuffer properly if you boot via EFI
[12:34] <cjwatson> so II'm told, anyway
[12:35] <exobuzz> cjwatson: i had a framebuffer kenel patch. but would have though its in main kernel by now (this was 2.6.16 or something)
[12:35] <cjwatson> I think it worked for a while and then broke
[12:36] <exobuzz> oh :(
[12:36] <cjwatson> although honestly, I haven't tried it personally; I've been focusing on making the bootcamp case work well, since we need that for CD booting anyway
[12:36] <kylem> i suspect you need a modesetting intelfb driver.
[12:36] <exobuzz> i have 2 mac minis as hosting machines. they are cheap to run, where power is at a premium!
[12:36] <cjwatson> kylem: this is ATI r500, so that would surprise me
[12:37] <cjwatson> the only option right now is vesafb, crap though that looks
[12:37] <cjwatson> er, vesa
[12:37] <exobuzz> cjwatson: you can boot cd from efi, if it has a bootloader on it
[12:37] <cjwatson> exobuzz: not unless you can create an HFS+ filesystem from Linux
[12:38] <cjwatson> exobuzz: if it's a normal ISO9660 CD, you need BIOS compatibility to boot it
[12:38] <exobuzz> cjwatson: efi can also boot to fat32
[12:38] <cjwatson> exobuzz: I don't think it'd be terribly sane to make our CD images dual FAT32/ISO9660 ...
[12:38] <cjwatson> exobuzz: at least HFS (and HFS+, if anyone ever does it) you can overlay on ISO9660 with very little extra space requirements
[12:38] <tepsipakki> ok, so diffing 1.1.0 and 1.1.1 isn't wise
[12:39] <exobuzz> cjwatson: so, to create an hfs fs from linux you can use dd ;-)
[12:39] <exobuzz> "heres one i made earlier"
[12:40] <cjwatson> exobuzz: I'm talking about the official Ubuntu CD images here, which we need to be able to create automatically from scratch using only Linux
[12:40] <slomo> is a MIR also needed for a new package if it only contains code that already is in one or more other source packages in main?
[12:40] <cjwatson> I'm aware there are options available if you can do it by hand with Mac OS X to assist
[12:40] <exobuzz> you cant keep a empty partition image handy for making it ? i mean its once off right ?
[12:40] <cjwatson> exobuzz: no, of course it is not once off
[12:40] <kylem> cjwatson, ah, loss. maximum loss.
[12:40] <cjwatson> oh and I don't have root either
[12:41] <cjwatson> (on the box used to produce the CD image)
[12:41] <exobuzz> cjwatson: but a certain fixed size boot partition would be enough, and then you copy into it what you need ? what am i missing ?
[12:41] <exobuzz> cjwatson: of course, im not sure how to bless a hfs+ f/s from linux either..
[12:41] <cjwatson> exobuzz: the fact that the boot loader changes regularly? you can't write to HFS+ meaningfully without being able to mount it, which requires root
[12:42] <exobuzz> there is that
[12:42] <cjwatson> the userspace HFS+ utilities are read-only to all intents and purposes
[12:43] <mjg59> HFS+ support is basically uninteresting while the kernel doesn't deal with EFI terribly well
[12:43] <exobuzz> ok so.. use bootcamp, but you should include one tip for people who want to use their machines as servers without monitor: "If you need to use the "Boot Camp" firmware, you will need to prepare a simple terminator to convince the machine that a (non-DDC) monitor is attached. All that's needed is to connect a 75 resistor between pins 2 and 7 of the (analogue) VGA connector. The easiest way to do this is to buy a male DB15
[12:43] <exobuzz> connector (a "VGA plug") and appropriate resistor, and solder it between pins 2 and 7 on the connector. Fit a hood over the connector to prevent damage in handling. (You can get all of these parts from Maplin or any other electronics supplier. We can sometimes supply these terminators but we don't keep a stock.)" courtesy of www.mythic-beasts.com
[12:43] <mjg59> exobuzz: W?
[12:44] <exobuzz> mjg59: without that, bootcamp doesnt boot without monitor..
[12:44] <mjg59> Oh, sorry, got the context now
[12:44] <mjg59> Yes, that's unfortunate. It's also a tiny proportion of the userbase.
[12:44] <exobuzz> its a very useful tip.. 
[12:44] <mjg59> exobuzz: FWIW, I did a lot of the Intel Mac support for mythic beasts
[12:44] <exobuzz> but i was that tiny proportion at that point..
[12:45] <exobuzz> mjg59: yeh think they mentioned you to me..
[12:45] <exobuzz> mjg59: well i guess you are the person they mentioned anyway
[12:45] <exobuzz> mjg59: i think iwas their first intel mac customer :)
[12:45] <mjg59> Heh
[12:45] <mjg59> I had their first Intel Mac
[12:45] <tormod> tepsipakki: did you try to apply the old ubuntu diff to the new xorg tree?
[12:46] <mjg59> But seriously, EFI interacts very badly with IA32 and x86_64 right now
[12:46] <exobuzz> they sent it to you right ?
[12:46] <mjg59> No, I happened to be in the right cafe at the right time
[12:46] <exobuzz> mjg59: aah
[12:46] <mjg59> They're friends of friends
[12:46] <exobuzz> mjg59: how so ? about ia32 ?
[12:46] <tepsipakki> tormod: no, I'm just trying to figure out why the tarballs differed, but I had a wrong one
[12:46] <mjg59> 2.6.20 has only just got the calling convention for EFI right
[12:46] <exobuzz> mjg59: you know any of the oxlug lot then ?
[12:47] <exobuzz> im running 2.6.17 on intel mac.. what shouldnt work right ?
[12:47] <mjg59> There's still a certain degree of misery between EFI's memory map and IA32
[12:47] <exobuzz> via efi
[12:47] <mjg59> 2.6.17 is actually ok
[12:47] <mjg59> A certain amount of stuff breaks in 2.6.18
[12:47] <mjg59> Should be fixed by 2.6.19
[12:47] <mjg59> Anyway, I should have test hardware again by next week
[12:47] <tepsipakki> tormod: now that I got xorg-server-1.1.1 the checksums match ;)
[12:48] <mjg59> But a surprising amount of x86 Linux thinks that there's going to be a bios
[12:48] <exobuzz> so long as chris lightfoot knows that. since im running one of his built kernels 
[12:48] <exobuzz> :)
[12:48] <tormod> tepsipakki: I guess I wanted to ask: have you tried (not did you try) :)
[12:48] <mjg59> Yeah, Chris knows what he's doing
[12:48] <tepsipakki> tormod: no, I haven't yet.. need to figure out what is the correct order
[12:49] <exobuzz> so.. you have a lovely intel mac notebook.. it runs macos.. it runs windows.. and linux.. but.. ati's linux drivers still suck :(
[12:49] <exobuzz> shame
[12:50] <Viper550> Random little question, why does Ubuntu ship with vim-tiny instead of vim?
[12:50] <kylem> which is why you don't buy one with ati graphics...
[12:51] <LaserJock> Viper550: because it's tiny? :-)
[12:51] <Viper550> lawl
[12:51] <exobuzz> kylem: i had no idea about ati graphics until this pc, i had nvidia on my last laptop. iguess i assumed they would be as good as nvidia.. silly me...
[12:51] <Viper550> we're having a little discussion about text editors in -offtopic if you wanna join us
[12:51] <mjg59> exobuzz: ATI's drivers still needed legacy bios support, last time I checked
[12:51] <exobuzz> mjg59: yeh.. no ati with efi.
[12:51] <exobuzz> :)
[12:52] <tormod> tepsipakki: I am trying to merge/build the newest ati driver. I would be very interested if you get the xorg-xserver done.
[12:53] <elmo> they also suck, even with legacy BIOS
[12:53] <exobuzz> so with this not booting due to checking for monitor ddc.. do you think the old trick for infiniate lives on that c64 game would work. the one where you lick your finger and run it over the joystick port.. wrong sex on the video output though. unless you got it really moist.
[12:53] <exobuzz> :)
[12:53] <exobuzz> tormod: the newest x.org ati driver ?
[12:54] <tepsipakki> tormod: 6.6.3?
[12:54] <tormod> exobuzz: yes, 6.6.3 ++ git
[12:54] <exobuzz> tormod: ooh ;-) great
[12:54] <tepsipakki> tormod: that would be great, I've had problems with it + DRI
[12:55] <tepsipakki> seems that not that many xorg libraries have been updated
[12:55] <tormod> exobuzz: don't hold your breath :) needs a newer xserver-xorg also
[12:55] <cjwatson> we synced all the X libraries from Debian
[12:55] <tepsipakki> tormod: really?
[12:55] <cjwatson> except for libx11, which we merged
[12:55] <tepsipakki> cjwatson: thank goodness for modular xorg :)
[12:56] <tepsipakki> tormod: oh you mean the git-stuff?
[12:56] <tormod> tepsipakki: I am not sure. Do you think I can run 6.6.3 on the old xorg-server?
[12:57] <tepsipakki> tormod: well, debian has 6.6.3
[12:57] <tepsipakki> see merges.ubuntu.com
[12:57] <tormod> tepsipakki: I think I tried to install the debian 6.6.3
[12:58] <tormod> but there are many important fixes post 6.6.3
[12:58] <tormod> s/important/interesting
[12:59] <exobuzz> would this newer version solve the aiglx+compiz "GLX_EXT_ texture_ from_pixmap" missing problem ?
[12:59] <tepsipakki> yeah
[12:59] <tepsipakki> exobuzz: you've seen that too?
[01:00] <exobuzz> sure.. i cant run aiglx+compiz.
[01:00] <mjg59> Works fine here.
[01:00] <tepsipakki> me neither
[01:00] <mjg59> Well, has other bugs
[01:00] <exobuzz> maybe its owner certain cards
[01:00] <tormod> the debian 6.6.3 complains: xserver-xorg-dev (>= 2:1.1.1)
[01:00] <mjg59> But that one isn't one of htem
[01:00] <exobuzz> i have x700
[01:01] <tormod> exobuzz: I also have x700. my main target is bug #22985
[01:01] <Ubugtu> Malone bug 22985 in xserver-xorg-video-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005 | card detected, but driver fails to use right output port" [High,Confirmed]  https://launchpad.net/bugs/22985
[01:01] <tepsipakki> mjg59: with ati? I have a 8500 and it fails
[01:01] <mjg59> tepsipakki: No, i855. But this is all server side, so should be consistent.
[01:01] <mjg59> There was an upload yesterday. have you tested it?
[01:01] <tepsipakki> mjg59: oh, ok
[01:01] <sfllaw> ogra: Ping?
[01:01] <tepsipakki> mjg59: didn't have a chance, since my desktop is b0rked now :)
[01:02] <exobuzz> mjg59: oh that bug.. ive put up with that for ages. i just stick in the "MonitorLayout" bit.
[01:02] <exobuzz> mjg59: i thought it would never get fixed :)
[01:02] <exobuzz> sorry. i mean tormod. not mjg59 
[01:02] <exobuzz> i unfortunately bought an acer laptop too
[01:03] <tormod> exobuzz: I am not sure it ever will be :) But it is such a bad bug - newbie blocker deluxe
[01:03] <exobuzz> looks nice.. but essentially broken.. there is another nice bug, that if you press the lid button, you get about 10 acpi lid events per second, which fills the acpid logs
[01:03] <exobuzz> tormod: yes.. very hard with a black screen to do much
[01:03] <tormod> oh debian6.6.3 built fine once I removed the epic 2: from debian/control
[01:04] <tepsipakki> funny, the xorg mirrors have a hierarchy for 7.2, but not the main site
[01:04] <tepsipakki> have to get those from individual/*
[01:09] <exobuzz> tormod: i suppose installer could detect acer laptop, and ati card and add a MonitorLayout line to fix it if the bug is not fixed ?
[01:10] <tormod> exobuzz: I added that patch to the bug report ages ago (!)
[01:11] <exobuzz> tormod: and its included now ?
[01:11] <cjwatson> exobuzz: (for the record, the installer has nothing to do with that stuff; it's all in the xserver-xorg maintainer scripts)
[01:11] <tormod> exobuzz: no it's not. it's not important enough / patch is not elegant enough ?
[01:12] <exobuzz> cjwatson: yeh .. i was being generic. i dont know which x.org package makes the initial config :-)
[01:12] <tormod> it's in dexconf it can be done most easily
[01:12] <exobuzz> tormod: elegant? well. its important.. that should be enough
[01:12] <cjwatson> exobuzz: I care because I'm responsible for the installer but not for X configuration :-)
[01:13] <exobuzz> cjwatson: ok.. "listen up.  - its nothing to do with cjwatson." ;-)
[01:13] <tepsipakki> erm, for instance upstream libice would unpack to libICE-ver, but it should be changed so that the tarball md5sum is preserved.. how?-)
[01:13] <exobuzz> cjwatson: if it was down to you, i know it would already be fixed :D
[01:13] <cjwatson> oh, I wish
[01:14] <cjwatson> tepsipakki: the location the upstream tarball unpacks to hasn't mattered since some incomprehensibly ancient version of dpkg-source
[01:14] <exobuzz> tormod: i know this happens on all ferarri and travelmates with ati cards though right ? so we just use like dmidecode and check?
[01:14] <tepsipakki> cjwatson: oh..
[01:14] <exobuzz> tormod: i mean in addition to the gfx card check
[01:14] <mjg59> Gah, has that still not been fixed?
[01:15] <tormod> exobuzz: checking for that exact card should be enough. fixes 90% I guess, maybe breaks 3%, ok wild guessing.
[01:16] <exobuzz> tormod: the few that already work, are not harmed as they can go and edit their x.org and remove it, if they are sure.. but its harder to edit with a blank screen, so i agree it should go in.
[01:16] <mjg59> It's not a chipset thing
[01:16] <mjg59> It's very much an Acer thing
[01:16] <exobuzz> well i always hear the word acer with this problem
[01:16] <tormod> actually a few laptops with that card don't need the MonitorLayout line, but I guess they survive with it as well.
[01:17] <tormod> mjg59, interesting. is it just the bios?
[01:17] <exobuzz> my monitorlayout is "Option      "MonitorLayout" "LVDS,NONE""
[01:17] <mjg59> It's really something that should be fixed in the driver
[01:17] <tormod> mjg59, sure but until then? 4+ ubuntu releases useless for a lot of users?
[01:18] <mjg59> tormod: And the potential to break it for a load of others?
[01:18] <exobuzz> mjg59: cant we then fix it specifically for the laptops we know are broken ?
[01:18] <mjg59> Get me an affected laptop and I can try to fix it properly
[01:18] <mjg59> It's hard to debug remotely
[01:19] <mjg59> And I'm not enthusiastic about adding hacks for individual machines without an understanding of /why/ that's an issue
[01:19] <exobuzz> mjg59: where abouts do you live ?
[01:19] <tormod> mjg59, are there a load of others? of course I only hear about those who are already broken :)
[01:19] <mjg59> exobuzz: Xambridge
[01:19] <mjg59> tormod: There's plenty of X700 machines
[01:19] <tepsipakki> libice done :)
[01:19] <mjg59> exobuzz: Uh, Cambridge
[01:20] <exobuzz> mjg59: HAH.. cambridge. pah!
[01:20] <tormod> mjg59, I can give you ssh access if that would help.
[01:20] <ogra> sfllaw, pong (in a hurry)
[01:20] <mjg59> tormod: Possibly, but not necessarily all that much
[01:21] <exobuzz> mjg59: ok admitting its a hack, is it so bad to have a hack which only affects the few and fixes the problem, that have it broken for feisty ?
[01:21] <mjg59> exobuzz: It really depends on whether it hits other people as well
[01:21] <tormod> mjg59, I can set up a webcam on another computer, so you can see if there's light on the screen or not :)
[01:21] <mjg59> exobuzz: And whether there's a realistic chance of us managing to implement the hack in a correct manner without having test hardware
[01:21] <mjg59> It's really hard to get this right
[01:21] <exobuzz> mjg59: well at least fixing for some would be something. i have to adfmit, ive only seen it mentioned with acer laptops
[01:22] <mjg59> exobuzz: Right, from everything I've seen it's specific to Acers
[01:23] <tormod> the bug reports mentions Samsung
[01:24] <exobuzz> so lets fix the acers, and see if anyone else reports it ? ;-) the samsung bug is not related i think...
[01:24] <exobuzz> looks like they had a bad x config
[01:24] <exobuzz> on acer, X starts. only backlight is not switched on
[01:24] <exobuzz> if you look carefully you can see x running
[01:24] <exobuzz> almost :)
[01:26] <tormod> and presario 2100, hp compaq 9010, HP nw8240, Toshiba Satellite M70
[01:26] <exobuzz> really ?
[01:27] <exobuzz> shit.
[01:27] <tormod> exobuzz: I don't think so, I think the screen is totally off.
[01:27] <mjg59> nw8240 is an entirely different issue
[01:27] <exobuzz> tormod: on mine i can see it.. you have to look real hard..
[01:27] <tormod> nw8240 black screen, MonitorLayout fixes it.
[01:28] <tormod> yeah sorry that one started to work in Edgy
[01:29] <mjg59> tormod: Uh. All the information I had on nw8240 was that the screen was heavily corrupted, but visible.
[01:29] <tormod> well to help fix it properly I need to run latest git, and then I would need xorg 7.2 I guess
[01:29] <exobuzz> so maybe then we should do all x700 mobility.. monitorlayhout on a mobility card isnt going to break anything, as ive never seen a laptop that doesnt have its own screen
[01:29] <exobuzz> :-)
[01:30] <tormod> tepsipakki: you are not going to sleep before you have them all (xorg) done right? :)
[01:30] <math_b> Hi, I am typing this on a Toshiba Satellite M70, what bug are you talking about ?
[01:30] <tepsipakki> tormod: of course not
[01:30] <tepsipakki> it's just 02:30 here
[01:31] <tepsipakki> ha, debian had libx11 in experimental
[01:31] <tormod> tepsipakki: that's the spirit! kippis for that.
[01:32] <tepsipakki> I wonder how and where to put these for testing, _if_ I ever manage to get them ready
[01:32] <exobuzz> speaking about laptops: i want my wireless keys switched on.. https://launchpad.net/ubuntu/+source/hotkey-setup/+bug/57849
[01:32] <Ubugtu> Malone bug 57849 in hotkey-setup "Add keycodes for wireless button on Acer Travelmate 8100" [Low,Needs info]  
[01:32] <exobuzz> i added info... and patch...
[01:33] <exobuzz> actually 3 patches as i got it wrong twice. i was having a bad qa and testing day :)
[01:33] <tormod> tepsipakki, bit torrent :)
[01:34] <tepsipakki> nah, has to be apt-gettable
[01:34] <tepsipakki> time to worry about it tomorrow
[01:36] <exobuzz> tepsipakki: you dont have some person webspace to upload them ?
[01:36] <tepsipakki> I have yes
[01:37] <tepsipakki> don't know if the quota is sufficient
[01:38] <exobuzz> just go "its done" send them to someone here and they will go online somewhere ;-)
[01:38] <tepsipakki> heh
[01:41] <tormod> the debian ati 6.6.3 depends on xorg-server 1.1.1-1, I just have 1.1.1-0ubuntu12 but I'll try. wish me luck :)
[01:41] <tepsipakki> so it would need a merge
[01:42] <tepsipakki> or just relax the deps
[01:42] <tepsipakki> (don't know if that is generally a good idea, though)
[01:44] <tormod> ati 6.6.3 seems to work QED
[01:45] <tepsipakki> nice
[01:45] <tormod> now I'd like to merge any ubuntu patches left and a few git commits
[01:54] <tepsipakki> phew, libx11 done
[01:55] <tepsipakki> had to merge 1.0.3-4ubuntu1 and 1.1-2 with 1.1.1
[01:57] <tepsipakki> hmm, need to include 1.0.3-5 as well
[02:05] <tormod> if anyone wants to test, ati 6.6.3 i386 packages here: http://tormod.webhop.org/linux/ati/ 
[02:15] <exobuzz> ooh.
[02:15] <exobuzz> thakns
[02:26] <tepsipakki> too bad that xorg upstream has outdated Changelogs on many libraries
[02:26] <Burgwork> http://www.flickr.com/photos/christopherblizzard/377591178/ <-- they need LP to schedule for them
[02:29] <elmo> haha
[02:29] <elmo> that's how we did specifications at UDU
[02:30] <kylem> hehe
[02:31] <ajmitch> how appropriate, I'm just listening to 'the wall'
[02:43] <jdub> Burgwork: an unconference is quite different to specification fascification
[03:11] <Keybuk> elmo: Fedora like things that worked for Ubuntu
[03:12] <Keybuk> http://www.flickr.com/photos/christopherblizzard/378569571/
[03:12] <kylem> they also appear to like being tossers...
[03:13] <pkl_> kylem: still up...
[03:13] <Keybuk> yeah, it's not as if we'd have anything like "Better Fedora than Fedora" in our original governance plans, or anything
[03:14] <kylem> better fedora than fedora is pretty easy. it's called "delete yum and fire author into the sun"
[03:14] <kylem> worst. package. management. ever.
[03:14] <Keybuk> oh, I dunno, apt/dpkg are pretty bad
[03:14] <lifeless> 'bsd ports'
[03:14] <lifeless> 'gentoo'
[03:14] <kylem> Keybuk, it doesn't take 4 hours to upgrade a single package on a slow machine with apt.
[03:15] <lifeless> Keybuk: yum is special. 
[03:15] <Keybuk> ok, that's fair
[03:15] <lifeless> with a th
[03:15] <lifeless> and a capital S
[03:15] <pkl_> I've never had yum take 4 hours. 
[03:16] <kylem> i'm exaggerating, but not by much.
[03:16] <lifeless> I've had it take 4 hours
[03:16] <lifeless> embedded machine
[03:17] <pkl_> but you're asking for trouble using yum on an embedded machine.
[03:17] <kylem> i think this was a p 166mhz with 64M of ram or something.
[03:18] <pkl_> I've never used any package manager on an embedded machine.  They tend to have a specially constructed rootfs and that's it :-)
[03:19] <LaserJock> I've had yum completely not work (on FC1) which then lead my boss to by a mac :/
[03:21] <jdub> kylem: pot/kettle?
[03:21] <kylem> jdub, what?
[03:22] <jdub> Keybuk: more^Wbetter fedora than fedora ;)
[03:22] <jdub> i think firing people into the sun might count as "tosser" (in more ways than one)
[03:23] <pkl_> hey kyle isn't tossers a bit strong.  I think Fedora isn't a bad distribution, it's noticably improved in the last few years.  But, I hate playing politics.
[03:23] <kylem> feh.
[03:23] <kylem> it's pretty mild considering the filth that comes out of my mouth typically.
[03:26] <pkl_> kylem: heh, I believe you.
[03:46] <zul> kylem: thats an understatement :)
[04:02] <tepsipakki> xorg 7.2 libs updated.. all 27 of them, except libxscrnsaver which is a new one (don't know if it is needed)
[04:04] <tepsipakki> time for bed ->
[04:12] <infinity> Keybuk: Next rebuild happens right after feature freeze.
[04:24] <Keybuk> infinity: my INBOX was filling up with faileds :p
[04:24] <Keybuk> so I wondered
[04:26] <sladen> ooh, that was fun.  time for bed
[08:03] <pitti> Good morning
[08:03] <Hobbsee> heya pitti!
[08:03] <pitti> hey Hobbsee!
[08:04] <Hobbsee> :)
[08:52] <tormod> tepsipakki: (still up?) found a place for your packages?
[08:54] <ajmitch> morning pitti :)
[08:54] <tepsipakki> tormod: I did sleep for a few hours ;)
[08:54] <tepsipakki> now doing app/*
[08:54] <pitti> hey ajmitch 
[08:56] <dholbach> good morning
[08:56] <bluefoxicy> hi2u
[08:56] <tepsipakki> do ubuntu-devs have webspace in people.u.c?
[08:57] <dholbach> tepsipakki: only canonical employees
[08:57] <Hobbsee> tepsipakki: no, only canonical employees..
[08:57] <Hobbsee> gah.
[08:57] <tepsipakki> dholbach: ok
[08:57] <Hobbsee> tepsipakki: looking for webspace?
[08:58] <tepsipakki> hobbsee: yes.. doing xorg-7.2
[08:59] <tepsipakki> I do have some, but quota is only 100MB and it's full
[08:59] <tepsipakki> and I could put them on my own server, but uplink is only 0.5Mb/s :)
[08:59] <Hobbsee> tepsipakki: i'd ask imbrandon or TheMuso.  TheMuso might actually be around.
[08:59] <dholbach> tepsipakki: if it helps, you could store stuff in bzr on LP
[09:00] <Hobbsee> tepsipakki: as a general guide, any ubuntu person who has dreamhost hosting is probably a good bet :P
[09:00] <tepsipakki> alright, I'll see what to do when I'm ready
[09:00] <tepsipakki> it all depends if it builds :)
[09:00] <dholbach> tepsipakki: *crossing fingers*
[09:01] <tepsipakki> heh
[09:01] <pitti> dholbach: anything I can NEW for you for bughelper? :)
[09:01] <dholbach> I'd notify ubuntu-devel@ and ask for people to help out with
[09:01] <dholbach> pitti: :-D
[09:01] <tepsipakki> dholbach: ok, maybe it's time to do that
[09:01] <dholbach> pitti: it's in source NEW
[09:01] <dholbach> tepsipakki: then I'd definitely store stuff in bzr on LP
[09:03] <tepsipakki> dholbach: is there a HOWTO for a bzr-illiterate?
[09:03] <dholbach> https://wiki.ubuntu.com/BzrMaintainerHowto
[09:03] <dholbach> https://wiki.ubuntu.com/Bzr
[09:04] <dholbach> http://bazaar-vcs.org/Documentation
[09:04] <tepsipakki> ok, thanks!
[09:04] <Treenaks> c
[09:04] <hunger> Any estimation on when feisty will be fixed again? udev is completly borked here.
[09:05] <tepsipakki> hunger: run udev restart
[09:05] <hunger> tepsipakki: I did... which is why I am finally logged in:-)
[09:05] <tepsipakki> heh
[09:05] <tepsipakki> I'm sure it will be fixed soon
[09:06] <hunger> tepsipakki: I hope so, too...
[09:08] <tfheen> hunger: just mount it byhand?
[09:11] <hunger> tfheen: pam_mount keeps unmounting it, so it is really annoying... and I keep forgetting how to actually decrypt the key in the first place.
[09:12] <tfheen> cryptsetup luksOpen /dev/whatever blah ; sudo mount /dev/mapper/blah /home (or something like that), then don't log out.
[09:12] <tfheen> pam_mount doesn't unmount it unless you don't have any sessions running
[09:13] <Lure> tepsipakki: if you need free webspace and understand a bit of german: http://www.funpic.de
[09:13] <hunger> tfheen: The problem is the openssl command to decrypt the key with:-(
[09:13] <Treenaks> hunger: openssl x509 -in file.key -out file.key ?
[09:13] <hunger> tfheen: openssl enc -d -some-algorithm-I-keep-forgetting -in file -out file.out.
[09:14] <tfheen> hunger: that's what you get for having keys derived from file rather than from a passphrase, I guess.
[09:14] <hunger> Anyway: It is really annoying... especially as pam_mount keeps unmounting the whole thing all the time.
[09:15] <hunger> tfheen: Yeap... being paranoid is inconvinient at times;-)
[09:17] <Treenaks> hunger: but are you paranoid _enough_? :P
[09:19] <tfheen> hunger: why would a file on disk be more secure than something derived from a passphrase?
[09:22] <hunger> tfheen: Because a passphrase is shorter than a file on disk (and less random, too).
[09:23] <mdke> ajmitch: what's the "disabling scrollkeeper usage in debian/rules" in the latest f-spot upload? is it something to do with the manual?
[09:23] <hunger> tfheen: If you got a short passphrase, then you can turn hash that all you want, it is still a weak key.
[09:26] <seb128> morning
[09:26] <mdke> morning seb128 
[09:26] <seb128> weird, libx86 to /usr/lib totally broke my feisty desktop
[09:26] <seb128> no mouse
[09:27] <seb128> GNOME not starting and freezing the box completly
[09:27] <ajmitch> mdke: yeah, I was under the impression that it wasn't to be used - though I'll correct it if wrong
[09:27] <seb128> ajmitch: what?
[09:27] <hunger> seb128: Try restarting udev... helped here.
[09:27] <ajmitch> seb128: I wonder if that's the cause of some of the udev issues
[09:27] <ajmitch> seb128: I was talking to mdke about f-spot :)
[09:27] <seb128> ah ok
[09:27] <mdke> ajmitch: does the manual still work without it?
[09:27] <hunger> seb128: But the move is a bad idea... I get lots of warnings due to missing libx86 during bootup.
[09:28] <seb128> hunger: I copied libx86.so.1 to /lib, which fixed everything, I fail to understand why at the moment though
[09:28] <seb128> that's a new lib and is supposed to be used by usplash
[09:28] <hunger> seb128: /usr is not around when usplash is running... so storing it there is not a good idea.
[09:28] <seb128> it should not break the mouse and make the box freeze
[09:28] <hunger> seb128: That is udev I guess...
[09:29] <seb128> hunger: that I know, I still fail to understand why it's breaking the system
[09:29] <ajmitch> mdke: afaict it does
[09:29] <seb128> hunger: it should break usplash only
[09:29] <TheMuso> dholbach: The libgnome-speech3 binary does not need to depend on the espeak package. It depends on libespeak1, which is fine, but it doesn't use the espeak command at all.
[09:29] <tfheen> hunger: English has about 1.3 bits of randomness per letter, sha1 gives you a 128 bit hash, so a 98-letter passphrase will give the maximum security you can get using that hash.
[09:29] <hunger> seb128: Had that yesterday... all went fine after restarting udev.
[09:29] <seb128> hunger: you already said that ;)
[09:29] <tfheen> hunger: and it's trivial to have a passphrase with a higher randomness than english.
[09:29] <dholbach> TheMuso: ok, I'll change that - heno instructed me to do so
[09:29] <hunger> tfheen: Yeap... but who has a 98letter password (== passphrase in pam_mount)?
[09:29] <seb128> pitti: blocking the spec "implemented" for a menu item was slightly too much no?
[09:30] <TheMuso> dholbach: Right. All you needed was libespeak-dev, which you did.
[09:30] <mdke> ajmitch: ok, i'll give it a check later
[09:30] <seb128> pitti: I mean that's a trivial bug fixing
[09:30] <TheMuso> I confirmed that the /usr/bin/espeak command is not used by renaming it.
[09:30] <seb128> anyway, fixed
[09:30] <TheMuso> The gnome-speech driver interfaces directly with the shlib.
[09:30] <pitti> seb128: well, it was a missing thing from the spec *shrug*, but itz done now anyway
[09:30] <dholbach> TheMuso: done
[09:31] <tfheen> hunger: read again what I wrote.  You could have a passphrase where you replaced chars which would give you a fairly big boost.
[09:31] <tormod> tepsipakki: will you post to a ML once you have some packages out?
[09:31] <seb128> pitti: it'll likely change again, I don't like the 4 items in a row, we probably need a seperator or a different order or something
[09:31] <tepsipakki> tormod: I just sent to ubuntu-devel, but that's just a heads-up post
[09:31] <pitti> seb128: that's fine, now that everything is there in principle
[09:31] <TheMuso> dholbach: Ok.
[09:32] <tfheen> hunger: and if you have this on a file, it's still no more secure than how you keep that file.. and even if it's encrypted you still have a passphrase for it, so you can't strengthen your chain that way, only weaken it.
[09:32] <hunger> tfheen: how so? Even with a totally random password you can not expect more than 4bits of entroy per letter... so a 8char long password is 64bit of entropy.
[09:32] <hunger> tfheen: my HDDs passphrase is *LONG*, that is not the week point:
[09:33] <seb128> mjg59: https://launchpad.net/ubuntu/+source/libx86/+bug/83920
[09:33] <Ubugtu> Malone bug 83920 in libx86 "[feisty]  libx86.so.1 moved to /usr/lib -- and completely hosed my system" [Undecided,Unconfirmed]  
[09:33] <tfheen> hunger: if it's utterly random, with all printable chars you get way more than four bits per letter.
[09:33] <tfheen> six or seven bits, I suspect.
[09:33] <seb128> cjwatson: https://launchpad.net/ubuntu/+source/libx86/+bug/83920
[09:33] <seb128> that happens on my desktop as well, if you need any debug info let me know
[09:34] <hunger> tfheen: Nope... you can not enter all ascii chars in a password dialog.
[09:34] <hunger> tfheen: If you have 64 different chars you can use then you are lucky:-)
[09:35] <tfheen> hunger: upper and lower case A-Z gets you 52, numbers another 10, You'd easily find ten to twenty different punctation chars.
[09:35] <tfheen> which takes you into "6-7 bits per letter" land.
[09:36] <hunger> tfheen: Nope... in the 4-5 bits per letter land. With 4 being the safe bet;-)
[09:37] <tfheen> hunger: how on earth are you counting randomness?
[09:37] <pitti> tfheen: it's just that passphrases whose characters are really independent from each other are terribly hard to remember :) usually they will depend on each other (probability-wise)
[09:38] <hunger> pitti: Yeap... so 4bits of entropy is actually pretty much the upper limit... 3bits or maybe only 2 is a way safer bet.
[09:38] <tfheen> pitti: yes, that's obvious.
[09:38] <pitti> tfheen: so that drastically reduces entropy then
[09:39] <mdke> what is the status on the binary drivers spec? is it happening for feisty?
[09:39] <pitti> mdke: not by default, since we won't do compiz by default
[09:40] <mdke> pitti: and is it going to be made easier to install? We need to know for updating documentation
[09:40] <hunger> tfheen: Anyway... I do not expect more than max. 32bits of entropy from a standard unix password and that is a pretty optimistic guess already.
[09:40] <kwwii> anyone here have an amd-64 box that can verify something about the usplash for me?
[09:41] <tfheen> hunger: you're throwing numbers out without any reasoning for them.
[09:41] <hunger> tfheen: I prefer using those 32bits as an additional line of defense for my keys than having it as the only one:-)
[09:41] <tfheen> kwwii: sure.
[09:41] <kwwii> tfheen: does it show a progress bar?
[09:42] <kwwii> and if yes, is it a solid color?
[09:42] <tfheen> kwwii: let me reboot to take a look
[09:42] <mdke> pitti: it's confusing because the accelerated-x spec is marked as "Accepted for feisty"
[09:43] <kwwii> tfheen: thanks a lot, I wouldn't ask if it wasn't important ;-)
[09:43] <pitti> mdke: it was after the UDS, but then we didn't know how bad compiz actually was :)
[09:44] <mdke> pitti: so the spec is out of date?
[09:44] <pitti> mdke: it's not, we just defered its implementation
[09:44] <seb128> pitti: compiz is not that bad, composite doesn't work fine everywhere though
[09:44] <mdke> right, so it's out of date
[09:45] <pitti> mdke: the 'for feisty' bit is out of date, 'approved' isn't
[09:45] <mdke> yes, that's what I'm getting at
[09:46] <mdke> ok, so is the method for installing binary drivers going to be the same as it was for Edgy?
[09:46] <seb128> (gdb) bt
[09:46] <seb128> #0  0x08077eba in panel_make_unique_desktop_uri ()
[09:46] <seb128> Cannot access memory at address 0xbfe98e7c
[09:46] <seb128> grrrr
[09:46] <seb128> I want a working dup for that crash :/
[09:46] <seb128> that's 
[09:46] <pitti> seb128: BenC has (hopefully) fixed this locally
[09:46] <seb128> that's 3 crash dumps we get now and no one is useful
[09:46] <seb128> pitti: ah, good
[09:46] <pitti> this was a terrible timing, the new kernel went straight to herd-3 without prior testing :/
[09:47] <seb128> yeah
[09:48] <tfheen> herd 3 has been out for close to a week now, there's nothing stopping BenC from doing a new kernel upload, though
[09:48] <pitti> tfheen: right, sorry, that wasn't intended to be a blame
[09:49] <pitti> seb128: at the same time the new kernel will raise the core dump limit from 1 MB to 1 GB (as initially intended)
[09:49] <seb128> the limit is 1M atm?
[09:49] <pitti> yes, a bug
[09:56] <dholbach> hey mvo
[09:57] <mvo> hey dholbach! good morning glatzor
[09:57] <mdke> pitti: any idea?
[09:57] <tfheen> kwwii: it's nice-looking, but on shutdown it was solid, yes.
[09:57] <ajmitch> hi mvo 
[09:58] <pitti> mdke: I think so, unless cjwatson added something to the installer
[09:58] <tfheen> kwwii: as in, it was nice-looking on bootup again.
[09:58] <mdke> pitti: ok. I will mail the list to find out I guess
[09:58] <mvo> hey ajmitch!
[09:59] <glatzor> morning mvo!
[09:59] <glatzor> morning dholbach
[10:04] <glatzor> mvo: I improved the arch-build replacing the tar pipe by a bzr lightweight checkout 
[10:05] <mvo> glatzor: I tried that before and for me it was a step backward. it did not include not-yet-commited changes
[10:05] <dholbach> heya glatzor
[10:05] <dholbach> glatzor: how about getting python-distutils-extras into main?
[10:05] <mvo> glatzor: one of my main use-cases for arch-build is to test-build stuff
[10:05] <glatzor> mvo: ok
[10:06] <cjwatson> seb128: thanks, will fix
[10:06] <mvo> glatzor: and if I would have to commit everything before, that would be a bit anyoing :)
[10:06] <seb128> cjwatson: np, thank you
[10:06] <glatzor> does bzr inventory cover newly added and not yet comitted files?
[10:06] <mvo> glatzor: yes 
[10:07] <mvo> both
[10:07] <glatzor> mvo: I use arch-build to verify the consistency of the repo before pushing.
[10:08] <cjwatson> mjg59: hope you don't mind another libx86 NMU
[10:15] <sabdfl> hey guys, i have a question about the new dhclient.conf in feisty
[10:15] <sabdfl> it has a line like this:
[10:15] <sabdfl> send host-name "<hostname>";
[10:15] <sabdfl> is the <hostname> bit a "special value" which will be replaced with the results of `hostname`?
[10:15] <sabdfl> or is it just an example? in other words, should i leave my current config of 'send host-name "foo";' or switch to the new <hostname>?
[10:17] <tfheen> sabdfl: from my DHCP logs, it seems like it replaced it.
[10:17] <pitti> sabdfl: it's now a magic value
[10:18] <sabdfl> by "replaced" you mean that is s/<hostname>/`hostname`/? super, thanks tfheen
[10:18] <pitti> sabdfl: right
[10:18] <sabdfl> and thanks pitti!
[10:18] <pitti> sabdfl: that was a long-standing wishlist bug and seemed to have annoyed lots of people, so I threw that in right in time for FF :)
[10:18] <pitti> sabdfl: if 'foo' is the correct hostname on that system, either works
[10:19] <sabdfl> nice!
[10:19] <sabdfl> i've resolved conflicts on that file tons of times
[10:19] <cjwatson> pitti: thanks a lot for flush-syncs, BTW
[10:19] <sabdfl> now i can just go with the default behaviour
[10:19] <cjwatson> I created flush-backports along the same lines
[10:19] <pitti> cjwatson: nice
[10:19] <cjwatson> pitti: I meant to ask, any reason to use cp+rm rather than just mv?
[10:20] <cjwatson> the syncs and backports directories are group-writable so mv should work
[10:20] <pitti> cjwatson: just transactional behaviour, if anything went wrong, the set +e would have prevented the rm
[10:20] <cjwatson> true, fair enough
[10:20] <pitti> cjwatson: but I guess mv would do the same
[10:22] <cjwatson> pitti: so, does mouseemu make you scream in terror for main? :)
[10:23] <pitti> cjwatson: I didn't look at it yet :)
[10:23] <pitti> cjwatson: the good ol' sysctl doesn't work any more for macbooks, I figure?
[10:23] <cjwatson> correct, it's powerpc only and a good deal of work to make anything else
[10:24] <cjwatson> given that there's a userspace solution, I prefer that
[10:24] <tfheen> cjwatson: so, your usplash upload broke X for me.
[10:24] <cjwatson> tfheen: /usr on a separate partiion?
[10:24] <cjwatson> partition
[10:24] <tfheen> cjwatson: no
[10:24] <tfheen> (using the proprietary nvidia driver)
[10:24] <tepsipakki> tfheen: run udev restart
[10:24] <cjwatson> hmm, then I dunno, you're probably better-placed to debug than I
[10:25] <tfheen> tepsipakki: humm?  It works fine if I just remove "splash" from the kernel command line.  Why would this be related to udev?
[10:26] <tepsipakki> tfheen: oh, ok
[10:26] <cjwatson> tfheen: kyle reported success with nvidia, but I suspect he's using the free drivers
[10:26] <tfheen> cjwatson: yes, the splash displays fine.  It's X that falls over.
[10:27] <cjwatson> I think we're far enough before release that we should try to fix this and not back out the amd64 fix yet again
[10:27] <tfheen> cjwatson: sure; prodding here to see if somebody else has the same problem.
[10:27] <cjwatson> good to know that the splash works at least
[10:28] <tfheen> I need some food before I start debugging this
[10:28] <pitti> tfheen: a friend of mine mentioned the same to me yesterday
[10:28] <pitti> with nosplash X worked fine
[10:29] <torkel> tfheen: does it work if you disable gdm and run it manually from a root prompt afterwards?
[10:29] <tfheen> torkel: no
[10:29] <torkel> it=/etc/init.d/gdm start
[10:29] <tfheen> I'll try with various vbetool pokes, I think.
[10:30] <tepsipakki> this is going to be fun.. merging xorg-server and updating it to 1.2.0
[10:31] <tepsipakki> what a humungous diff
[10:37] <pitti> does anyone know how to update linux-meta for a new kernel ABI? this is kind of urgent
[10:38] <cjwatson> pitti: what release?
[10:38] <pitti> cjwatson: kyle uploaded one for edgy-security, but not for dapper-security (new kernel: 2.6.15-28.51)
[10:39] <cjwatson> ok, doesn't seem to have changed
[10:39] <cjwatson> pitti: change KERNEL_ABI in debian/rules
[10:39] <pitti> cjwatson: there's a new ABI
[10:39] <pitti> ah, ok
[10:39] <pitti> cjwatson: thanks
[10:40] <cjwatson> np
[10:42] <Lure> tfheen: hunger was asking about X starting before, not sure if he is on amd64 though
[10:48] <cjwatson> argh, STOP FILING BUGS ON HERD 2
[10:50] <\sh> what happend to my karma?
[10:50] <pitti> \sh: it overflowed and started at 0 again
[10:51] <cjwatson> all karma was reduced by a couple of orders of magnitude
[10:51] <pitti> 'go back to start. do not get K4000.'
[10:51] <Treenaks> pitti: ah.. using smallint? :P
[10:52] <\sh> pitti: largefile karma support not compiled into python? ,-)
[10:53] <hunger> Lure: I am not. X works again after doing a udev restart.
[10:53] <Lure> hunger: ok, just thought it may be related
[11:14] <tepsipakki> but first lunch
[11:14] <mjg59> cjwatson: Not at all
[11:17] <tfheen> so, if I strace X, it starts.
[11:18] <tfheen> like, if I connect to the X server after it has failed to start for ten minutes.
[11:22] <Keybuk> hmm, why does firefox (edgy) "freeze" when I open a new tab?
[11:25] <Keybuk> hmm, interesting
[11:25] <Keybuk> which would be very impressive
[11:25] <Treenaks> Keybuk: wow..
[11:25] <Keybuk> it's writing to a socket and timing out
[11:26] <Treenaks> Keybuk: what kind of socket?
[11:26] <ajmitch> probably an extension
[11:26] <Keybuk> firefox-b 8092 scott   52u  IPv4             215220             TCP quest.netsplit.com:48459->a212-135-93-135.deploy.akamaitechnologies.net:www (ESTABLISHED)
[11:26] <tfheen> Keybuk: sure it's not the phising stuff or something?
[11:27] <tfheen> or rather, anti-phising.
[11:27] <Keybuk> could be
[11:27] <Keybuk> if the server is down
[11:27] <Treenaks> could it be checking for updates on your extensions?
[11:27] <mjg59> Right, I wouldn't expect the average spyware company to be able to afford akamai
[11:28] <Keybuk> right
[11:28] <Keybuk> hmm, isn't the phishing stuff
[11:28] <Keybuk> it still freezes
[11:31] <Keybuk> *shrug*
[11:31] <Zdra> hi, can someone tell me how to use the new apport bug reports ? it attach tones of files now instead of a single .apport file
[11:32] <Keybuk> I wiped .mozilla
[11:32] <Keybuk> and it's fine
[11:32] <Zdra> how can I retrace a bt ?
[11:32] <pitti> Zdra: that's something I'm just working on
[11:32] <pitti> Zdra: I'll teach apport-retrace to take a bug number
[11:32] <Zdra> oh, goooooooddd !!!!
[11:32] <pitti> Zdra: for now you have to download the core dump and ProcMaps.txt manually and use apport-retrace's command line switches
[11:33] <pitti>   -r CORE, --core-file=CORE
[11:33] <pitti>                         Override report's CoreFile
[11:33] <pitti>   -x EXE, --executable=EXE
[11:33] <pitti>                         Override report's ExecutablePath
[11:33] <pitti>   -m MAPS, --procmaps=MAPS
[11:33] <pitti>                         Override report's ProcMaps
[11:33] <pitti> ^ these
[11:33] <Zdra> one thing I dislike with the new behavious is I receive tones of email when a new bug is reported
[11:34] <pitti> Zdra: not any more
[11:34] <Zdra> one email by new attachment
[11:34] <pitti> Zdra: this has been fixed for a few days
[11:34] <Zdra> oh
[11:34] <Zdra> ok :D
[11:38] <seb128> what is the right package for a bug concerning the fisrt CD boot screen (the one where you can pick the language to use, etc)?
[11:38] <Keybuk> pitti: was talking to kyle yesterday ... apport could do things like attach lspci -vvnn for kernel/udev reports, attach /var/log/boot for udev reports, etc.  right?
[11:38] <tfheen> seb128: gfxboot-theme-ubuntu, most likely
[11:38] <pitti> seb128: gfxboot
[11:38] <seb128> thank you
[11:39] <pitti> Keybuk: apport (0.48) feisty; urgency=low
[11:39] <pitti>   New feature: Infrastructure for reporting kernel Oopses:
[11:39] <tfheen> or gfxboot, depending on the problem.
[11:39] <pitti> Keybuk: ^ this does exactly that :)
[11:39] <seb128> tfheen: https://bugs.launchpad.net/ubuntu/+bug/82961
[11:39] <Ubugtu> Malone bug 82961 in Ubuntu "Slovenian boot options descriptions are too long" [Undecided,Unconfirmed]  
[11:39] <tfheen> g-t-u
[11:39] <Keybuk> pitti: right, but is there a way to have it automatic for set of packages
[11:39] <seb128> ok, thanks
[11:39] <Keybuk> e.g. report bug on firefox -> always lists extensions
[11:39] <pitti> Keybuk: and for udev, you can ship a per-package hook in /usr/share/apport/udev.py
[11:40] <pitti> Keybuk: right, listing extensions sounds like a good idea, too (firefox apport hook)
[11:41] <Keybuk> not that I'm trying to give you more work or anything :p
[11:41] <Keybuk> it's just So. Shiny.
[11:42] <Fujitsu> Do any other distros have a tool like apport?
[11:42] <pitti> Keybuk: the per-package hooks should be implemented by the package maintainers anyway, since they usually know best what info they want (I will help them, of course)
[11:42] <iwj> pitti: Would you care to cast an eye over my comments in https://wiki.ubuntu.com/MainInclusionReportCryptsetup ?
[11:42] <pitti> iwj: will do today
[11:42] <iwj> ogra complained about it up ^ there at 2157Z yesterday.
[11:43] <iwj> Maybe I'm just being overly fierce.
[11:43] <cjwatson> seb128: dupe of bug 81458, indeed :)
[11:43] <Ubugtu> Malone bug 81458 in gfxboot-theme-ubuntu "F-key row should wrap" [Wishlist,Confirmed]  https://launchpad.net/bugs/81458
[11:43] <pitti> it was indeed quite picky, but cryptsetup is a hard beast
[11:44] <seb128> cjwatson: right ;)
[11:44] <tfheen> iwj: oh, btw, your new udev packages fixed pam_mount for me.
[11:45] <iwj> tfheen: Oh, good.
[11:45] <cjwatson> BTW, anyone who fancies taking over gfxboot-theme-ubuntu is welcome
[11:45] <iwj> tfheen: That's better news than yesterday morning.
[11:45] <cjwatson> I'd been secretly planning to give it to iwj, but then he seems to have taken on enormous piles of other stuff :-)
[11:46] <iwj> cjwatson: *snort*
[11:46] <cjwatson> Familiarity with postfix-notation languages (esp. Forth) is a bonus
[11:47] <Keybuk> cjwatson: now there's a qualification of doom on a job description
[11:47] <cjwatson> I liked it
[11:47] <iwj> You liked gfxboot-theme-ubuntu ?  Or Forth ? :-)
[11:48] <cjwatson> the job description
[11:49] <Keybuk> if we combined the job with the PDP-11 Port Maintainer, we might find somoene :p
[11:50] <tfheen> Keybuk: if we combined it with that, I have a candidate in mind..
[11:50] <cjwatson> Keybuk: that sounds like a job for which you should be the hiring manager
[11:51] <tfheen> Keybuk: toresbe, who loves old computers.  The older, the better. :-P  (He was the kid at DC3 tinkering with the PDP10 in the library next to one of the hack rooms)
[11:53] <cjwatson> Keybuk: perhaps "PostScript" is a slightly less exotic example. I'm not sure which is more accurate
[11:54] <elmo> just for the record, any talk of PDP ports is a shoot offence, mmk?
[11:54] <cjwatson> elmo: don't we have room in the datacentre?
[11:54] <thom> elmo: come on, you know you want one in L3
[11:55] <thom> i can imagine the "hi, please reset the tape in our pdp-11 and reset it" calls at 4am to the "intelligent" monkey
[11:57] <Keybuk> cjwatson: I can categorically say that a PDP-11 port does not count as "New Developments", and is definitely "Maintenance and Upstream Work"
[11:58] <Keybuk> thom: imagine carrying one of *those* on the tube
[11:58] <thom> Keybuk: not so useful as an ipod, no
[12:11] <mneptok> does anyone have tho Hollereth cards for xserver-xorg? i need to do a stock run.
[12:18] <iwj> No-one else has a mode 600 /dev/null, I take it.
[12:18] <iwj> (apropos of bug 83878)
[12:18] <Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
[12:19] <iwj> Oh, I see various people do.
[12:20] <_ion> Yay, the recent postgresql security update in edgy broke postgresql. Error: "Table has type character varying, but query expects character varying."
[12:20] <pitti> _ion: should already be fixed 
[12:20] <pitti> _ion: http://www.ubuntu.com/usn/usn-417-2 -> still doesn't help?
[12:23] <hile> any good ideas for the passphrase query problem while I was away?
[12:23] <_ion> pitti: Oh, my bad, i assumed the 'apt-get update' the cron job did last night would be recent enough. I apt-get updated now and i see the new postgresql packages.
[12:23] <hile> cryptsetup initramfs, of course sorry
[12:24] <pitti> _ion: well, actually my bad, I released a broken version to -security :/
[12:24] <pitti> _ion: fortunately upstream was very quick to release a fix
[12:25] <hile> I think good short term solution would be to clean up all lvm and evms stuff from current cryptroot script, let it just block like  now for the cryptoroot device itself and forget udev
[12:26] <iwj> hile: Right, you probably don't have time now to do the proper fix.
[12:27] <iwj> In the longer run initramfs init should pass some environment variables through to udev so udev hooks can talk to the user.
[12:29] <hile> or could we have something like upstart in initramfs already? instead of ordered scripts, and let udev inform this process that a dependency is now ok, i.e. device is there, which would trigger the query
[12:30] <hile> similarly all current hooks could just be ordered with this
[12:30] <iwj> hile: Right, but in any case some daemon needs to make a UI query.
[12:30] <hile> yep
[12:31] <hile> well, I'll start the cleanup now, I'll send patches soon
[12:32] <ogra> iwj, i'm not concerned about you being picky (i think pickyness is a requirement for that job ;) ), but about switching established procedures without announce, it would be nice to coordinate with pitti and to announce if and how we need to write our MIRs differently :)
[12:32] <_ion> Upstart in initramfs, interesting.
[12:33] <iwj> ogra: Really it just seemed obvious to me that a MIR is supposed to be a report of some investigative activity and not just a cut-and-paste of a fixed text.
[12:33] <ogra> iwj, yes, but i see no reason to do copy paste jobs of lists that are linked already ...
[12:34] <iwj> But the list is a list of _things to check_ and after you've checked them you should have _results of your investigation_, surely ?
[12:34] <ogra> if i have to do additional stuff for the security review please give a hint what i should do etc
[12:34] <ogra> right
[12:34] <iwj> ogra: security> I'll discuss this with pitti but my very first google search found a vulnerability.
[12:34] <ogra> ok
[12:34] <iwj> And I think the proposer should do enough of a search that that doesn't happen.
[12:34] <hile> ion, my thought was that since the initramfs is moving to async mode, upstart would be better than strictly ordered scripts ;)
[12:35] <pitti> ah, there's a vuln that isn't CVEed?
[12:35] <ogra> i dont look at google at all for the security stuff but use the two secunia and CVE links
[12:35] <iwj> Maybe we can replace udev with upstart :-).
[12:35] <_ion> keybuk: Thoughts? 
[12:35] <ogra> haha
[12:35] <iwj> ogra: I don't mind what tool you use.
[12:35] <Keybuk> why would you?
[12:35] <ogra> iwj, well, but neither has that vuln.
[12:35] <iwj> I mind that I did a search myself and found something that wasn't mentioned in the report.
[12:36] <Keybuk> udev does what it does well enough (listening to uevents and dispatching them)
[12:36] <pitti> FWIW, neither 'cryptsetup vulnerability' nor 'cryptsetup security' gives a prominent google hit
[12:36] <_ion> keybuk: to133500 < hile> ion, my thought was that since the initramfs is moving to async mode, upstart would be better than strictly  ordered scripts ;)
[12:36] <Keybuk> if you need upstart functionality, it's easy -- just call initctl emit some-event from a udev rule and deal with it in an upstart job
[12:36] <Keybuk> using upstart in the initramfs is nothing new
[12:36] <ogra> iwj, well,for me as non security guy, i only follow the advised procedures ... which is to use the two search forms for the two sites ...
[12:36] <Keybuk> jbailey and I had that in mind from the beginning
[12:37] <iwj> ogra: The vulnerability I'm thinking of is in (at least) CVE.
[12:37] <hile> keybuk, cool, so now the only problem for cryptsetup is really controlling termnal input ;)
[12:37] <ogra> and i also think it makes your work easier if everyone uses the same template and you can see changes from the default on a first glance ...
[12:37] <pitti> iwj: so far it has been common practice that the reviewer (me so far) did a more exhaustive security analysis
[12:37] <iwj> pitti: Hmm.
[12:37] <pitti> iwj: from the reporters I mainly expect QA assessment/research, justification, and buildability proof
[12:38] <ogra> iwj, waht i say is not that i'm opposing to do more, but i want a hint for it in the rocedure documentation
[12:38] <ogra> you guys are the reviewers and need to tel me as developer what you need
[12:38] <pitti> iwj: but I think adding a google search for vulns could certainly be part of the template
[12:38] <ogra> i'm fine with providing any kind of info if required
[12:39] <Hobbsee> ogra: you really are supposed to be telepathic.
[12:39] <ogra> Hobbsee, now who do you think made you just grab that coffeecup ? ;)
[12:39] <iwj> pitti: Well, we have really two options for this process: the reviewer can do the security spadework, or they can check the proposer's.  The latter is somewhat more work overall but is less for the reviewers.
[12:40] <Hobbsee> ogra: :)
[12:40] <pitti> iwj: ideally the proposer would do the initial search, and the reviewer would verify it and do a shallow code review
[12:40] <Hobbsee> ogra: you forgot to preface with sudo.  sorry, cant do :P
[12:40] <ogra> haha
[12:40] <pitti> iwj: I don't really want proposers to do a code review
[12:40] <iwj> pitti: Right.  So what happened here is that I verified the search and came up with `failed'.
[12:41] <iwj> code review> Quite so.
[12:41] <iwj> I think we have a problem with the MainInclusionReportTemplate which is that people seem to think that the right thing is to cut-and-paste it.  Wiki Templates ought to be edited.
[12:41] <pitti> iwj: yup, fair enough in this case; however, the security review should just help us to decide whether we can cope with the package; we can't refuse all packages which ever had a single vuln
[12:42] <iwj> pitti: Well, indeed so.
[12:42] <ogra> iwj, i dont even cut and paste :)
[12:42] <iwj> So the report should say `these vulnerabilities [link]  [link] ' which are noncritical especially for us.
[12:42] <pitti> iwj: right, the recent reports have been a bit sloppy in that regard in many cases
[12:42] <iwj> or some such.
[12:43] <iwj> It might help to rewrite the template in the form of questions, or perhaps obviously false statements.
[12:44] <iwj> After all, things can be in main even if the sentences in the report template are false.
[12:44] <iwj> The right thing is then for the actual report to describe the actual situation and justify the inclusion.
[12:44] <iwj> Note above where our proposer is saying that it is somehow `easier' if the report is identical to the template even if perhaps not entirely accurate ...
[12:45] <ogra> well, i would find it easier as reviewer to have a quick overview on first sight ...
[12:46] <iwj> ??
[12:46] <iwj> ATM if I read one of these reports I have no idea whether any of it is even slightly true because the proposer (a) might have failed to check certain things and (b) evidently feels that it would be wrong to deviate from the template wording even when the template wording is not true !
[12:47] <ogra> well, if you look at: Standard debhelper/cdbs/dbs packaging, standard patch system.
[12:47] <ogra> i would only chaneg it if neither is true ...
[12:47] <ogra> *change
[12:48] <cjwatson> why would you not even remove the bits that don't apply?
[12:48] <ogra> if you know that, you can very quickly see if the packaging is fine from my POV
[12:48] <cjwatson> it should be read as "debhelper/cdbs/dbs (delete as applicable)"
[12:48] <iwj> ogra: I can tell that you think the package is fine because you put it into the queue!
[12:48] <cjwatson> it can't possibly be all of debhelper, cdbs, and dbs
[12:48] <ogra> right
[12:49] <cjwatson> ogra: the point of you filling out a template rather than the reviewer just doing it all is for you to communicate useful information to the reviewer
[12:49] <iwj> How about if I were to write at the top of the template something to say that the template should be vigorously edited when writing a report ?
[12:49] <ogra> it's not how i used it yet (and nobody complained about it yet), i'm fine with doing it differently
[12:49] <cjwatson> iwj: that would be excellent
[12:50] <ogra> iwj, sounds good
[12:50] <Kano> hi, whats wrong with the ubuntu kernel source? when i want to compile it with pbuilder/etch it comes to a point with
[12:50] <pitti> well, I grew the habit of reviewing the entire diff.gz anyway, thus I don't mind the packaging stuff so much
[12:50] <Kano> dpkg-gencontrol: error: package linux-image-2.6.20-kdump not in control info
[12:50] <Kano> make[2] : *** [debian/linux-image-2.6.20-kdump]  Error 255
[12:50] <Kano> and then all is over...
[12:51] <ogra> iwj, i just took a look over all the other MIRs in the queue and they are not much different to mine ... thats why i spoke up
[12:53] <ogra> so a template change would be a good start, but a documentation how to do a proper MIR would even be better ... i'm fine being a guineapig if you want one ...
[12:54] <Hobbsee> ogra: two words.
[12:54] <Hobbsee> ogra: ie, guinea pig
[12:54] <ogra> ah !
[12:54] <Hobbsee> iirc
[12:54] <Hobbsee> :)
[12:54] <iwj> ogra: Well, I thought that it was obvious that template pages should be edited rather than just used verbatim but I suppose I have seen similar `must follow the template exactly' elsewhere.
[12:54] <ogra> right ... it knows guinea pig
[12:56] <iwj> ogra: Can you take a look at what I've written in the top two paras of MainInclusionReportTemplate.  Does that explain more clearly what we're expecting ?
[12:59] <ogra> iwj, sounds good to me ... should probably be bold or something 
[01:04] <ogra> good idea
[01:06] <elkbuntu> ogra, please see PM
[01:07] <mjg59> pitti: Any idea why people are claiming vbetool is crashing on login?
[01:08] <mjg59> Is this just because the dump is being made at boot time, and then processed at login?
[01:08] <Ubugtu> Malone bug 83550 in gnome-power-manager "impossible to de-activate screensaver " [Undecided,Unconfirmed]  https://launchpad.net/bugs/83550
[01:08] <ogra> elkbuntu, can we d it after the distro meeting ?
[01:08] <ogra> *do
[01:08] <pitti> mjg59: I guess so
[01:08] <mjg59> pitti: Can we blacklist vbetool?
[01:08] <mjg59> It's expected to crash sometimes
[01:08] <elkbuntu> ogra, when does that end?
[01:09] <mjg59> ogra: Uh, most TFTs use a cathode tube for backlighting
[01:09] <ogra> elkbuntu, ~17:00 UTC
[01:09] <pitti> mjg59: hm, I wouldn't like to hardcode the package name into apport itself, how about adding /usr/share/apport/blacklist.d/ ?
[01:09] <ogra> mjg59, oh, really ? 
[01:09] <mjg59> pitti: Sure, that works
[01:09] <mjg59> ogra: Yes
[01:09] <pitti> mjg59: or even /etc
[01:09] <ogra> mjg59, i thought there is a dot matrix and just a backlight 
[01:09] <mjg59> ogra: The backlight is a cathode tube. Not a cathode *ray* tube.
[01:10] <ogra> ah, k
[01:10] <mjg59> Google cold cathode tube
[01:11] <ogra> mjg59, thanks :)
[01:11] <Keybuk> ogra: are you not planning to attend the meeting today?
[01:12] <ogra> Keybuk, i am, report will be there before
[01:12] <Keybuk> ogra: report needs to be there by the end of the day yesterday
[01:12] <Keybuk> otherwise it's missing from the agenda sent out in about 20 mins
[01:12] <ogra> meh
[01:12] <Keybuk> you were in the room when we discussed this :p
[01:12] <Keybuk> of course, you're not formally required to take part :)
[01:13] <ogra> but i want to :)
[01:13] <pitti> mjg59: added to TODO: - support /etc/apport/blacklist.d/ for check_ignored()
[01:13] <mjg59> pitti: Thanks!
[01:13] <Keybuk> right :p  end of day wednesday is the "send the weekly report" time
[01:13] <Keybuk> Colin and I write the agenda in the morning on thursday you see
[01:13] <pitti> mjg59: proposed format: file has one executable name per line
[01:13] <Keybuk> as that gives time for everybody to read it and propose new agenda items
[01:13] <mjg59> pitti: That works
[01:13] <elkbuntu> ogra, i'll be counting sheep then.. lets set an actual time?
[01:14] <Keybuk> people who don't get their reports in (Hi Tollef!) get the shame of running the meeting <g>
[01:14] <tfheen> hi Scott :-)
[01:14] <ogra> elkbuntu, when do you get up (in UTC time) ? 
[01:14] <Keybuk> tfheen: no, you don't need to run the meeting
[01:14] <ogra> do i ?
[01:14] <Keybuk> no :p
[01:14] <ogra> :)
[01:15] <tfheen> Keybuk: could we have the fridge calendar updated with the new meeting times?  It claims we should have had one this morning.
[01:16] <ogra> elkbuntu, i'm fine with every time after 17:00 UTC 
[01:16] <pitti> Keybuk: strictly, the requirement is to send activity reports to you and CC: distro-team; does it work for you to just send them to d-t?
[01:16] <Keybuk> pitti: yes
[01:16] <ogra> tfheen, for me it says 17:00 local time
[01:16] <Keybuk> tfheen: who runs the fridge calendar?
[01:16] <ogra> unless my evo missed to sync
[01:16] <pitti> tfheen: my evo import says 17:00 (CET)
[01:16] <elkbuntu> ogra, 21:00, but i'll be unavailable tomorrow until 04:00... how about the following UTC evening?
[01:17] <tfheen> Keybuk: fridge-devel@lists.u.c
[01:17] <tfheen> so I guess I could mail them myself when my mail server starts working.
[01:17] <cjwatson> Riddell: hey, if your enabling-additional-components changes are done, does that mean I can flip the installer switch?
[01:17] <ogra> elkbuntu, fine as well, unless i manage to make it by mail until then :)
[01:17] <elkbuntu> ogra, the chances dont seem good for that :
[01:18] <ogra> :)
[01:18] <tfheen> actually, it's the distro team calendar on google calendar which is broken.
[01:18] <tfheen> or wrong.
[01:18] <Keybuk> hmm?
[01:18] <Keybuk> distro team calendar is right
[01:18] <Riddell> cjwatson: yes please!
[01:18] <cjwatson> sfllaw: no update from you either, apparently
[01:18] <ogra> elkbuntu, really sorry, but pre feature freeze is a hard time for extra stuff
[01:18] <Keybuk> tfheen: says 1600UTC
[01:18] <pitti> Keybuk: but it's 1700 UTC, no?
[01:18] <elkbuntu> ogra, i know, which is why for most of the week i avoided harassing too much
[01:19] <ogra> thanks for that
[01:19] <pitti> Keybuk: (not that I would mind 1600)
[01:19] <Keybuk> no... it's 1600UTC
[01:19] <pitti> Riddell: https://code.launchpad.net/~mh21/+branch/apport/gui-qt4
[01:19] <Keybuk> "This week's team meeting is scheduled for 1600 UTC tomorrow, on #ubuntu-meeting as usual."
[01:19] <pitti> Keybuk: ah, ok
[01:20] <Riddell> pitti: goodness
[01:20] <Keybuk> the schedule is alternating 1600/2100 UTC
[01:20] <tfheen> Keybuk: grr, then evolution is just being silly here.
[01:20] <pitti> Riddell: I tried it out this morning and found a grave bug, should be fixed now; I'll try it again soon
[01:21] <ogra> tfheen, it pulls from the fridge ---> <Ubugtu> Schedule for Etc/UTC: 08 Feb 16:00: Ubuntu Development Team 
[01:23] <tfheen> ogra: yes, as I said, it's evolution which is being silly.
[01:23] <ogra> yep
[01:24] <tfheen> seb128: can I tell e-d-s to pull down a calendar again, since it's clearly confused here.
[01:29] <cjwatson> pitti/iwj: any chance of a migration-assistant MIR review today? I'm hoping to get the corresponding ubiquity branch merged for FF
[01:29] <pitti> yes, of course
[01:31] <ogra> pitti, iwj, the two sound related packages and python-ltsp would also be fine (both needed for specs)
[01:32] <cjwatson> pitti: thanks
[01:38] <Tonio_> seb128: ping ?
[01:39] <Tonio_> seb128: was just looking at the kubuntu-default-settings bug and saw that some gnome users complains that the defaults for kde apps on gnome are somehow nasty (cursor problems etc...)
[01:40] <Tonio_> seb128: I was wondering if making ubuntu-desktop depends on kubuntu-default-settings wouldn't make it easier for them.... although I know this is hard to figure out ;)
[01:41] <seb128> Tonio_: pong
[01:42] <seb128> Tonio_: no, ubuntu-desktop Depends on kubuntu-default-settings doesn't look a good idea
[01:43] <seb128> Tonio_: there is plenty of GNOME users who don't run a KDE app and no KDE app installed by ubuntu-desktop, so no reason to force kubuntu-default-settings
[01:43] <Tonio_> seb128: I knew this :) but it would be interesting if a gnome user installing a kde app gets invited somehow to install that package too
[01:43] <Tonio_> seb128: I agree with you on that point, but for the ones who do it there is no way for them to know how to get a proper config
[01:44] <seb128> make libkde Recommends kubuntu-default-settings
[01:44] <seb128> or libqt-x11 or whatever package make use of those settings
[01:44] <fabbione> mvo: ping?
[01:44] <Tonio_> seb128: hum, could make sense indeed, will discuss with riddell on that point
[01:44] <Tonio_> seb128: thanks
[01:44] <seb128> np
[01:45] <tkamppeter> pitti, ping
[01:45] <pitti> tkamppeter: pong
[01:46] <tkamppeter> pitti, I have uploaded a new foomatic-db which renames the PPD packages and directories to openprinting, see mail
[01:46] <tkamppeter> pitt, I have also updated the SpliX driver package from 1.0.1b2 to 1.0.1.
[01:49] <fabbione> Nafallo: ping?
[01:49] <Nafallo> fabbione: pong
[01:52] <pitti> yay for apport-retrace taking a LP bug number
[01:52] <pitti> Zdra, seb128: ^
[01:53] <seb128> excellent
[01:53] <pitti> seb128: you can only use -s or -g with it (no direct updating of the bug yet), but it should help already
[01:53] <seb128> yeah
[01:55] <pitti> seb128: oh, --output/-o works as well, of course
[01:56] <pitti> seb128: looks like this now: 'apport-retrace -o 83947-retraced.crash -c -d -C ~/.ddebs/ 83947' -> that's fine for you, or any idea for improvements?
[01:58] <seb128> pitti: looks cool, I'll let you know if I've some problems with when I'll have used it on some bugs etc
[01:58] <seb128> pitti: thank you ;)
[01:58] <pitti> you're welcome
[02:05] <givr1> infinity: ^^ did you get time to look at it ?
[02:38] <Chipzz> is there a bug-number or spec for the integration of encrypted / in the boot-process?
[02:40] <ogra> Chipzz, i think there was a spec, but the main inclusion report for cryptsetup was rejected yesterday ... needs some work nobody has time for atm
[02:40] <doko> tkamppeter: is the foomatic renaming really needed for feisty?
[02:41] <Chipzz> ogra: I was just talking to someone who attempted to do this himself, maybe I could direct him here to coordinate or sth?
[02:42] <ogra> Chipzz, it will need udev and upstart inetgration ...
[02:42] <ogra> and some smaller fixes in the package
[02:44] <fabbione> Nafallo: this mplayer bug is fishy.. turning -O4 to -O0 -ggdb make it works
[02:45] <tfheen> Nafallo: which bug is this?
[02:45] <fabbione> oh actually
[02:45] <fabbione> tfheen: i just noticed that latest mplayer crashes on ppc
[02:45] <exobuzz> sounds like gcc is fishy :-)
[02:45] <fabbione> and the package needs to be redone.. 
[02:46] <fabbione> exobuzz:no.. i did a bad test
[02:46] <fabbione> Nafallo: you really want to split that shared library out of mplayer package
[02:46] <ogra> fabbione, is your hwdb-client crash fixed with the latest package ? 
[02:47] <fabbione> exobuzz: the bug might be just in the shared lib or one of the codecs..
[02:47] <exobuzz> fabbione: oh..
[02:47] <fabbione> ogra: checking right away
[02:47] <fabbione> ogra: yeps.. it starts...
[02:47] <ogra> yay
[02:47] <fabbione> +it
[02:48] <ogra> somehow the #DEBHELPER# line was missing from the postinst ...
[02:48] <ogra> silly bug
[02:48] <fabbione> ogra: it's all good.. thanks a lot
[02:49] <ogra> thanks for testing :)
[02:50] <fabbione> do we have a tcl/tk guy?
[02:50] <fabbione> or with a bit of knowledge in that area?
[02:50] <exobuzz> tcl *shudder*
[02:50] <seb128> not me
[02:51] <fabbione> seb128: i *had* that feeling about you :P
[02:51] <seb128> ;)
[02:51] <fabbione> i am more looking for somebody to review a patch for SRU
[02:51] <ogra> not me then
[02:51] <fabbione> even if it's already included in feisty and upstream
[02:51] <seb128> fabbione: maybe give the bug number on the chan ;)
[02:52] <seb128> that would be a start
[02:52] <fabbione> seb128: there is no bug number yet. I got a patch from David Miller (the kernel guy) with the info. but there is no easy test case to prove the fix
[02:52] <fabbione> it's an endianess / allignment bug
[02:52] <exobuzz> what's the bug ? oh.
[02:53] <fabbione> and it's rarely triggered when scrolling some japanese text encoded in UTF-8 in a specific moment
[02:53] <seb128> do we want to backport that for edgy?
[02:53] <ogra> exobuzz, you can wear sunglasses ... its not *that* evil with them ...
[02:53] <fabbione> seb128: also in dapper...
[02:53] <seb128> that doesn't look like a high priority fix
[02:53] <exobuzz> ogra: :)
[02:53] <seb128> well, dapper I can understand
[02:53] <fabbione> seb128: no it's not a high priority, but it affects ppc too
[02:53] <seb128> edgy I've some doubt it's useful
[02:54] <fabbione> and we do support dapper/edgy.. so once you do one SRU, might as well do edgy in the same
[02:57] <fabbione> oh cool.. there is a 3 lines test case...
[02:57] <fabbione> yeah
[02:57] <exobuzz> there are more important bugs which could be fixed though surely? like the one where ethernet doesnt really work on a certain sis900 moterhboard (fixed in kernel for edgy) ;-)
[02:58] <exobuzz> i mean, if you are going to backport fixes to dapper.
[02:58] <fabbione> exobuzz: talk to the kernel team for that
[02:59] <exobuzz> well i mean, i dont care, since i upgraded .. but
[02:59] <exobuzz> noone else reported it so, i guess noone else with dapper has that motherboard (or triggers the bug)..
[03:00] <givre> ogra: do you have some time to look at a little correction in fuse package ?
[03:01] <givre> ogra: debdiff -> http://flomertens.keo.in/merge/debdiff_ubuntu1-ubuntu2
[03:02] <Kano> givre: btw. you NEED to update to fuse 2.6.3,because ntfs-3g does not run with it correctly.update ntfs-3g too...
[03:02] <givre> Kano: afaik it was the fuse module that cause problems
[03:03] <Kano> well i updated both for me
[03:03] <Kano> no big deal to go from 2.6.2 to 2.6.3, same debian dir works
[03:04] <Kano> similar for ntfs-3g
[03:04] <Kano> (when you update the experimental deb)
[03:06] <tkamppeter> doko, sorry, I have been at lunch. I have answered your e-mail now.
[03:06] <Kano> but i still have problems mounting ntfs-3g with uuids
[03:07] <Kano> ntfs works , UUID= only with patched mount, but the main thing is that mount -a works 
[03:07] <Kano> mount -a does not work correctly with ntfs-3g
[03:07] <Kano> when already mounted
[03:07] <givre> Kano: no big deal, but who is going to sponsors me on that ;) , i'm not even a motu
[03:07] <Kano> well i patch it for me ;)
[03:07] <givre> Kano: strange, works ok for me
[03:08] <pitti> ogra: do you need the pulse MIRs today? or is next week enough?
[03:09] <Kano> givre: of course the latest versions would be nice,because ntfs-3g got some needed patches
[03:10] <Kano> with older versions chkdsk may delete some new files
[03:10] <givre> Kano: i'd like to push it, but we don't have even have fuse 2.6.* in the archive
[03:11] <Kano> givre: which is really sad...
[03:11] <givre> Kano: we uploaded 2.6.2 last week but binary for i386 & amd64 get lost somewhere...
[03:11] <Kano> as it would fit perfectly to a 2.6.20 kernel
[03:11] <Kano> just to directly to 2.6.3...
[03:12] <pitti> cjwatson: m-a looks good, approved
[03:12] <evand> pitti: thanks!
[03:12] <Kano> and what about m-a in main?
[03:13] <Kano> a tool that i always install...
[03:13] <Kano> now i give a message to change sources.list
[03:13] <Kano> not that good...
[03:13] <pitti> evand: two little things: could you add the common-licenses pointer to debian/copyright and add a long description for the package?
[03:13] <evand> pitti: Sure thing.
[03:15] <fabbione> Nafallo: so it's definetely an optimization issue.. full code built with -O0 works
[03:15] <fabbione> Nafallo: now the fun part is going to find out where it break
[03:16] <tfheen> fabbione: try -fno-strict-aliasing
[03:16] <cjwatson> Kano: are you sure you're talking about the same m-a as we are? migration-assistant
[03:16] <cjwatson> pitti: thanks
[03:17] <Kano> no, m-a is the official short name for module-assistant
[03:17] <cjwatson> mvo: interesting, you marked enabling-additional-components Implemented before I made the installer change ...?
[03:17] <cjwatson> Kano: well, pitti and I knew what we were talking about.
[03:17] <fabbione> tfheen: ok.. in one of the next builds
[03:17] <Kano> /usr/bin/m-a is in the module-assistant package
[03:17] <cjwatson> *shrug*
[03:17] <cjwatson> please take it elsewhere, we were trying to coordinate development which is what this channel is for
[03:20] <tepsipakki> took awhile, but xorg-server-1.2.0 is now merged..
[03:20] <doko> tkamppeter: splix and foomatic-db uploaded
[03:22] <cjwatson> mvo_: but I've flicked the switch in the installer now
[03:24] <ogra> givre, i discovered yesterday as well, but i'm not sure we want 45-fuse.rules ... did you ask someone from the udev fraction ?
[03:25] <ogra> Keybuk, seems fuse in debian ships a differently numbered fuse rules file for udev, we have identical 45-fuse.rules and 80-fuse.rules now ... which one is the right one udev lies more ?
[03:25] <ogra> *likes
[03:26] <Keybuk> what does the file contain?
[03:27] <Keybuk> /etc/udev/rules.d/README ? :)
[03:27] <ogra> just the permissions for /dev/fuse
[03:27] <Keybuk> then it should be 45
[03:27] <ogra> ok
[03:27] <givre> ogra: no it was just a mistake : 80 is rules that run stuff, 40 are just rules that set permissions
[03:27] <ogra> ok, i tought they were identical
[03:27] <Keybuk> (our numbering is set up so that *user* rules can always just be 50-*.rules)
[03:28] <givre> ogra: in the first attempt, i set it to 80 because we run stuff
[03:28] <ogra> Keybuk, thanks a lot
[03:28] <Keybuk> if permissions are set in an 80-*.rules file, they'd override anything the user set
[03:28] <ogra> right
[03:28] <Keybuk> that's why if you do more than one thing (set the name, permissions, etc.) you should split it into multiple files
[03:28] <ogra> i'll read the README next time :)
[03:29] <givre> ogra: but now that all is done in /etc/modprobe.d, better to use 45
[03:29] <givre> which is the one also use in edgy 
[03:29] <ogra> pitti, as long as i get them to main i'm fine, thanks ... i just cant set the spec to implemented then but i'm fine doing that later
[03:30] <ogra> givre, yep, i'm fine with that patch ... will test and upload tonight ...
[03:30] <torkel> pitti: any idea when the new dapper kernels will hit the archive? linux-meta is available but not the actual kernels
[03:30] <tkamppeter> doko, thanks. Now only the new foomatic-db-hpijs needs to be uploaded, so that all new printers supported by HPLIP 1.7.1 will really appear in the printer setup tools. See mail.
[03:30] <pitti> torkel: it's due to bug 83976
[03:30] <Ubugtu> Malone bug 83976 in soyuz "-security vs. -updates/-proposed version comparison needs to be removed" [Critical,In progress]  https://launchpad.net/bugs/83976
[03:31] <givre> ogra: ok many thanks :)
[03:31] <doko> tkamppeter: ok
[03:31] <pitti> torkel: I was told that this bug should be fixed by tonight, so I can re-upload/re-publish tomorrow morning
[03:32] <torkel> pitti: ok
[03:32] <tkamppeter> doko, thanks.
[03:42] <pitti> doko: all these dict-* sources look a bit painful: they duplicate the munch/unmunch code and a complicated debian/rules; wouldn't it be easier to have a common source package for all of those?
[03:43] <Riddell> cjwatson: are you going to add commercial to the sources.list file too?
[03:44] <doko> pitti: they are updated separately; so we would get updates for all 20 binary packages.
[03:44] <bddebian> Heya
[03:44] <pitti> *shrug*, will they be updated that often?
[03:44] <doko> pitti: the "complicated" debian/rules is standard for building aspell dictionary packages
[03:45] <pitti> . o O { /usr/share/cdbs/1/rules/aspell.mk }
[03:47] <Keybuk> http://en.wikipedia.org/wiki/Ben_Collins_%28hacker%29
[03:47] <Keybuk> heh
[03:47] <Keybuk> now there's an article that needs some improvement
[03:47] <kylem> lol.
[03:48] <pitti> ogra: can you please see thin-client-manager to keep it in main?
[03:49] <pitti> ogra: s/see/seed/
[03:49] <cjwatson> Riddell: hadn't been planning to
[03:50] <mvo_> cjwatson: sorry for the enabling-additional-compents thing. that seemed to be a misunderstanding then
[03:51] <elmo> Keybuk: yeah, there's no mention of cows or mad bowling skillz
[03:51] <Keybuk> or being a poker shark
[03:51] <iwj> crw------- 1 root root 1, 3 2007-02-08 11:24 /dev/null
[03:51] <iwj> Yay!  It's doing it to me too now.
[03:51] <cjwatson> mvo_: never mind, done now
[03:51] <_ion> iwj: It's more secure now!
[03:52] <pitti> never loose important data again!
[03:52] <Keybuk> iwj: yeah, that means that the event got lost
[03:52] <iwj> Which event ?
[03:52] <Keybuk> check for "event queue overflow" and make sure null is listed in /var/log/udev
[03:52] <Keybuk> iwj: add /class/misc/null
[03:52] <Riddell> cjwatson: what's the reason not to?
[03:53] <cjwatson> Riddell: it just doesn't feel appropriate somehow
[03:54] <cjwatson> Riddell: I thought the graphical tools to install from there did it themselves anyway
[03:55] <Riddell> cjwatson: I think gnome-app-install does edit sources.list for you, but adept doesn't, hence my interest :)
[03:55] <Amaranth> fix adept :P
[03:56] <eriklo> congratulations
[03:56] <Amaranth> ?
[03:56] <Amaranth> wth was that?
[03:56] <Riddell> Amaranth: or software-properties
[03:56] <cjwatson> Riddell: it just feels too much like using undue influence
[03:57] <cjwatson> I think the commercial stuff should definitely be an explicit choice
[03:57] <seb128> BenC: any upload planned to fix apport? we keep getting crash bug with invalid coredump and no bt :/
[03:57] <pitti> seb128: bah, that's just like in the old times :/
[03:58] <BenC> seb128: I have an upload, but it's too soon to upload my apport fixes without some more testing
[03:58] <cjwatson> tfheen: changelog-closes-bugs doesn't seem to actually work ...
[03:58] <seb128> pitti: no, the worst we had since warty
[03:58] <seb128> pitti: new apport make easy to send bugs by a click, people use it
[03:58] <seb128> and for some reason bt are just "??" at the moment
[03:58] <pitti> BenC: if you have an amd64 kernel around, I'll be happy to test it
[03:58] <seb128> and the coredump are not valid
[03:58] <pitti> seb128: right
[03:58] <BenC> pitti: Ok, I'll get one built
[03:58] <cjwatson> tfheen: I get "dpkg-genchanges: warning: unknown information field `Launchpad-Bugs-Fixed' in input data in parsed version of changelog", but it doesn't appear in the .changes
[03:59] <BenC> pitti: Let me get this upload done, and we can do some testing, and another upload later tonight or tomorrow if things test ok
[03:59] <pitti> BenC: I can build it myself, too
[03:59] <seb128> pitti: I'm fine with rejecting all those bugs, it's just not easy to explain to people why we make them send megas over internet for nothing :/
[03:59] <pitti> BenC: sure, I have plenty of MIR/NEW stuff to do ATM for FF :)
[03:59] <BenC> pitti: By the time I can send you a patch that I am comfortable is working, I'll have a .deb too :)
[04:00] <pitti> BenC: heh
[04:00] <cjwatson> tfheen: I think dpkg-genchanges needs to be told about it, as well as the changelog parser
[04:01] <tfheen> cjwatson: yes, as I noted in my weekly report there's a bug there.
[04:02] <tfheen> cjwatson: I'll just fix it now.
[04:02] <ogra> pitti, seeds changed, it needs a -meta rebuild as well so may take some time still
[04:03] <ogra> mvo_, does python-apt have an equivalent to 'dpkg --print-architecture' ?
[04:04] <cjwatson> tfheen: ah, I missed that in your report
[04:04] <mvo_> ogra: apt_pkg.Config.Find("APT::Architecture")
[04:04] <ogra> ah, thanks
[04:05] <cjwatson> tfheen: ... wasn't in your report
[04:05] <tfheen> cjwatson: at least I intended to write it, I think I remembered too. :-)
[04:05] <tfheen> oh well
[04:05] <tfheen> cjwatson: it'll be fixed RSN
[04:05] <cjwatson> * changelog-closes-bugs: Distro side implemented, needs infrastructure
[04:05] <cjwatson>   in Soyuz and Malone.
[04:05] <cjwatson> thanks
[04:05] <tfheen> just doing a test build now
[04:18] <iwj> Keybuk: What arranges that the udevtrigger invoked by /etc/init.d/udev happens only after udev is properly started up and listening ?
[04:19] <Keybuk> udevd doesn't fork() until it's properly started up and listening
[04:20] <iwj> Ah.  Hmm, that means my reproduction of this mode 600 /dev/null is due to the way I tried to capture udev's debug output.
[04:24] <\sh> wow...I just read that linspire and ubuntu are now one ... congrats to linspire 
[04:24] <bddebian> Hah
[04:25] <bddebian> haha
[04:25] <\sh> dholbach: lwn :)
[04:26] <\sh> http://lwn.net/Articles/221217/ Linspire switches to ubuntu :)
[04:27] <dholbach> "are now one" stretches the truth a bit... don't you think? that's not even what LWN writes :)
[04:28] <jdub> just means linspire finally got the sense to use *all* of the ubuntu packages instead of snorting a few here and there ;)
[04:28] <\sh> dholbach: a bit exaggerated ,-)
[04:29] <dholbach> jdub: hehe
[04:29] <jdub> dude
[04:29] <jdub> have you seen the front cover of linux format from late last year?
[04:29] <dholbach> no?
[04:29] <jdub> i just got it
[04:29] <dholbach> oh... was that the black cover with HUGE ubuntu logo?
[04:29] <jdub> it's hilarious
[04:30] <jdub> nono, the fedora one
[04:30] <jdub> with me in it
[04:30] <dholbach> ah, no
[04:30] <jdub> "I was ready to walk out, because it sounded like the stupidest thing ever." - Jeff Waugh on Ubuntu's origins
[04:30] <jdub> right next to my mug
[04:30] <dholbach> ?
[04:30] <jdub> mug == face in empire lingo
[04:31] <dholbach> can you scan that in?
[04:31] <jdub> hrm, no
[04:31] <jdub> oh
[04:31] <jdub> but i have a cool camera now
[04:31] <jdub> i wonder if i can take a non-arse shot
[04:31] <dholbach> try! else I won't udnerstand what you're talking about ;-)
[04:32] <thom> jdub: your obsession with arses could get very disturbing mated to an SLR
[04:33] <Keybuk> jdub: it was a good article
[04:34] <Keybuk> http://www.linuxformat.co.uk/minicovers/87.jpg
[04:35] <jdub> taking photo now
[04:35] <jdub> i'll add it to the blog entry ;()
[04:35] <jdub> ;)
[04:35] <jdub> Keybuk: pretty good for my (almost) final act of evangelism ;)
[04:38] <jdub> dholbach: http://www.flickr.com/photos/jdubflickr/383758924/
[04:39] <dholbach> jdub: and what do they say on p48?
[04:40] <Keybuk> jdub: nice background!
[04:41] <jdub> dholbach: reload for link to complete interview (longer than in the magazine)
[04:41] <jdub> Keybuk: i got a new green book :)
[04:52] <cjwatson> jdub: interesting misspelling of mvo's name in there
[04:52] <cjwatson> "Michael Faulks"
[04:52] <jdub> yeah
[04:53] <jdub> kinda wang
[04:53] <jdub> at least that wasn't in the magazine
[04:53] <jdub> well
[04:53] <jdub> that whole section wasn't
[04:53] <jdub> which isn't necessarily better for mvo ;)
[04:54] <mvo> woah and I thought I have seen all crazy spelling already
[04:54] <jdub> looks like he guessed an anglo-ish name based on my pronounciation
[04:57] <cjwatson> great interview though
[05:01] <mdz> tkamppeter: meeting in #ubuntu-meeting now
[05:02] <thom> turning mako into "Mako-Hill" is pretty funny too
[05:05] <Zic_> hello, the last package of linux-image-generic is broken, it can't install the linux-image-2.6.17-11-generic package ...
[05:06] <Zic_> I think it's a problem with edgy-backport
[05:09] <pitti> Zic_: known problem, it's due to a bug in LP; we are working hard on it
[05:09] <Zic_> pitti: thanks :)
[05:10] <Zic_> pitti: the cause is edgy-backport isn't it ?
[05:10] <fabbione> Zic_: it's a bit more complicated than that
[05:10] <pitti> Zic_: no, it's not
[05:10] <Zic_> ok :) I'm waiting so :)
[05:25] <shawarma> I just filed a sync request (Bug 84017).. is that sufficient to be in time for UVF?
[05:25] <Ubugtu> Malone bug 84017 in rawstudio "Please sync 0.5-1 from Debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84017
[05:28] <tfheen> cjwatson: fixed dpkg uploading
[05:29] <cjwatson> thanks
[05:50] <cjwatson> Riddell:   * Import translations for Cancel, Back, Forward etc. buttons from gtk+2.0
[05:50] <cjwatson>     2.10.9-0ubuntu1 (LP: #43915).
[05:50] <Riddell> ooh, lovely, thanks
[05:50] <cjwatson> Riddell: FYI. It's hacky as hell but it works for GTK; I've done my best (without testing) to make it work for KDE
[05:51] <ogra> cjwatson, well, half done means that we need to support half done for 18 months 
[05:51] <ogra> and that we need working upgrades to a later full done variant etc
[05:51] <cjwatson> ogra: this is a bit like saying that if we only finish half the merges from Debian then we need to roll them all back
[05:52] <tfheen> X is modular, that's kinda the point.
[05:52] <cjwatson> ogra: the entire point of modular X is that (barring driver ABI issues, which are obvious and will just break hard) it CAN be loosely coupled
[05:52] <ogra> dont hook up on the rollback i mentioned ...
[05:52] <cjwatson> I'm not concerned about working upgrades. The X packaging is for the most part really, really simple.
[05:52] <ogra> mdz expressed what i meant, a proper commitment at least
[05:52] <cjwatson> you'd have to work hard to make upgrades difficult at this point
[05:52] <cjwatson> we've done all the hard bits
[05:54] <ogra> right, but still all 70 or so pkgs upgraded is better than only half of them ... and if someone starts to do it i'd ask for a commitment for all of them ...
[05:54] <tepsipakki> speaking of X, I have now a xorg-server package ready, building needs some newer libraries (libdrm-2.3 is where it failed)
[05:54] <tepsipakki> also the libs and apps are ready
[05:55] <pitti> tepsipakki: what about mesa? I heard that the merge would be pretty tricky
[05:55] <tepsipakki> pitti: yeah.. that's what I'm looking at now
[05:56] <tepsipakki> it was waaay back when they were merged
[05:56] <tepsipakki> last time
[05:56] <tepsipakki> and Debian has 6.5.2-2 in experimental
[05:56] <tepsipakki> but now I'm trying with 6.5.1-0.5
[05:57] <cjwatson> tepsipakki: have you been watching #ubuntu-meeting?
[05:57] <tepsipakki> nope, what's there?
[05:57] <cjwatson> tepsipakki: hmm, apparently not; would be worth reading the logs as we discussed X
[05:57] <tepsipakki> oh, ok
[05:57] <cjwatson> tepsipakki: I'll be posting stuff to -devel probably tomorrow now
[05:57] <tepsipakki> I'll do that
[05:57] <fabbione> tepsipakki: are you aware that you need to start from all the prototypes then libs then xserver and then drivers, right?
[05:58] <cjwatson> mesa needs to be merged first, I think; at least before the server
[05:58] <cjwatson> fabbione: we're not that far behind on prototypes and libraries; if the server builds at all I'd be happy
[05:58] <fabbione> cjwatson: be careful of that.. some features that are on now, might switch off if not done properly
[05:58] <tepsipakki> fabbione: it seems that proto hasn't changed much if at all
[05:59] <fabbione> cjwatson: specially if people are not reading carefully all the build logd
[05:59] <fabbione> logs even
[05:59] <cjwatson> fabbione: *shrug* I'm sure we'll build xorg-server again
[05:59] <iwj> tkamppeter: re bug 83924> Hmm.  I'm not sure it's "the same bug" but if we have it breaking on a system where the user is responsive we might be able to debug it.  Can you get the submitter to gather the info like I suggest in 83878 ?
[05:59] <Ubugtu> Malone bug 83924 in hplip "[apport] [feisty]  hpssd crashed with IOError in daemonize()" [Medium,Unconfirmed]  https://launchpad.net/bugs/83924
[05:59] <cjwatson> fabbione: I take your point but I think tepsipakki is taking account of some ordering anyway, from what I've seen
[05:59] <fabbione> cjwatson: oh yeah.. i know that.. it's a matter of properties propagation from prototype to lib to server to driver..
[06:00] <fabbione> paying a bit of extra care at the beginning will spare you tons of headacke later
[06:00] <fabbione> tepsipakki: ^^
[06:00] <tepsipakki> I started from the libs because they were easy and I something that could be done last night :)
[06:00] <tepsipakki> fabbione: yes
[06:00] <fabbione> tepsipakki: no you need to make sure to start from the prototypes
[06:00] <fabbione> libs come right after that
[06:00] <fabbione> also.. read carefully all the build logs
[06:00] <tepsipakki> ok, thanks for that
[06:00] <fabbione> at least once
[06:01] <tepsipakki> I haven't built anything yet ;)
[06:01] <fabbione> to make sure you get all the features enabled
[06:01] <tepsipakki> just source packages
[06:01] <cjwatson> tepsipakki: how much of this comes from Debian experimental?
[06:01] <tepsipakki> cjwatson: not much
[06:01] <cjwatson> tepsipakki: because we're in sync on all the prototypes and nearly all the libraries at the moment; is any of it *in* Debian experimental?
[06:01] <cjwatson> if we can sync from them, it would be preferable, given our manpower limitations
[06:01] <tepsipakki> actually, all the versions are from 7.2, nothing newer
[06:02] <tepsipakki> there isn't much.. I'm afraid
[06:02] <cjwatson> that's a great shame
[06:02] <cjwatson> perhaps we can work with debian-x on this
[06:02] <tepsipakki> perhaps
[06:03] <tepsipakki> maybe I should put xorg-server somewhere soon
[06:03] <tepsipakki> there were tons of patches, but luckily the tricky ones are already upstream
[06:03] <fabbione> tepsipakki: the server comes last.. please go in order or you will end up in a mess :/
[06:03] <tepsipakki> hehe
[06:04] <tepsipakki> I wanted to do it when I was awake :)
[06:04] <tepsipakki> it took maybe six hours
[06:04] <tepsipakki> or more.. but I'll check the prototypes now
[06:04] <pitti> tfheen: I guess from the meeting I have approval for packaging/adding apport-qt?
[06:04] <pitti> tfheen: (will do this evening)
[06:05] <tfheen> pitti: please.
[06:05] <tfheen> BenC: but if it's not shipped as part of the upstream kernel, it should be a separate package.
[06:06] <BenC> tfheen: We have a lot of stuff that is in our kernel that isn't shipped upstream :)
[06:06] <BenC> this package isn't even in Debian, so can't even sync it
[06:06] <tfheen> BenC: to me it sounded akin to putting some random source package in the kernel source.
[06:06] <tepsipakki> ooh, experimental has libdrm-2.3.0-1
[06:06] <BenC> NEW + MIR just for a small program to build a semi important kernel flavour is a lot of work
[06:07] <tfheen> if it's small, both NEW and MIR are small things.
[06:07] <BenC> the other problem is the name of the package
[06:08] <BenC> dtc is taken in Debian by some other package entirely
[06:08] <BenC> device-tree-compiler is sort of long, but probably best
[06:09] <tkamppeter> iwj, I have asked the original poster of the HPLIP bug for the information.
[06:09] <iwj> tkamppeter: Ta.
[06:10] <tfheen> BenC: coolie.  Prod me or another archive admin when it's in.
[06:10] <BenC> tfheen: Hopefully wont take long
[06:13] <ogra> cjwatson, sbalneav and jammcq poke me more often about the cipher=none thing ...
[06:14] <ogra> i thought i'd forward one for ten ... :)
[06:15] <TheBearded1_> can anybody tell me if bash in ubuntu feisty is compiled with --enable-net-redirections?
[06:17] <TheBearded1_> can anybody tell me if bash in ubuntu feisty is compiled with --enable-net-redirections?
[06:21] <tfheen> TheBearded1_: it's not.
[06:26] <gpocentek> tfheen: is there a way to modify the ubuntu live CD to use a custom xorg.conf, ie not reconfiguring the xserver-xorg package? It seems that only removing the casper script doesn't help...
[06:26] <ubuntugeek> not sure if this is right place.. but we got alot of users with issues with the latest kernel update. http://ubuntuforums.org/showthread.php?t=356408 if anyone wants to check it out
[06:27] <tfheen> gpocentek: removing the relevant bit of casper and putting an xorg.conf should work.
[06:28] <gpocentek> tfheen: I've replaced the xorg.conf and removed 20xconfig, but xorg.conf is still modified. Is there something else I should remove?
[06:29] <iwj> Keybuk: * Drop the "|| true"s from usplash_write calls, infinity says they're unnecessary' vs bug 83878
[06:29] <Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
[06:30] <Keybuk> iwj: ref?
[06:30] <iwj> udev changelog, 079-0ubuntu22 Thu, 23 Mar 2006 17:44:13 +0000
[06:30] <iwj> The problem is that usplash_write now links against libx86.
[06:30] <iwj> Which is in /usr.
[06:30] <tfheen> gpocentek: no, that should have been enough, I'd think.
[06:31] <gpocentek> hm...
[06:31] <Keybuk> right ... how does dropping the || true help?
[06:32] <iwj> Dropping the ||true makes it break.
[06:32] <iwj> Specifically, it means that if usplash_write fails, udev doesn't start.
[06:33] <iwj> So before reverting that change I thought I'd talk to you.
[06:34] <iwj> Also I think libx86 should perhaps be in /lib but I should talk to err Colin ?
[06:34] <stgraber> iwj: I have that /dev/null and /dev/zero permission problem on my laptop, do you need any other information about that bug ? (I posted a comment with the datas you requested)
[06:34] <iwj> stgraber: Ah, hi.  Do you have /usr on a separate partition ?
[06:34] <stgraber> yes
[06:35] <iwj> stgraber: Right, we know what the problem is and I'm working on it.
[06:35] <iwj> The primary bug for this is 83878.
[06:35] <gismo> hello all
[06:35] <iwj> Ah, you're the reporter of 83924.
[06:35] <stgraber> ok, good to hear :)
[06:35] <iwj> So you've just answered my question.
[06:35] <Keybuk> iwj: gimme 20 mins
[06:36] <iwj> Keybuk: Sure.
[06:37] <kylem> http://fedoraproject.org/wiki/Releases/FeatureCustomDistro?highlight=%28CategoryFedora7Features%29
[06:37] <kylem> heh.
[06:37] <gismo> little question: How can I get the list of installed files using python-apt ?
[06:39] <iwj> cjwatson: See discussion in bug 83878 re libx86.  If /usr is a separate partition then usplash_write fails and causes udev not to start.
[06:39] <Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
[06:40] <iwj> Should we move libx86 to /lib ?
[06:40] <mjg59> iwj: Yeah
[06:40] <iwj> mjg59: Yeah we should move it ?
[06:40] <mjg59> iwj: Yes
[06:40] <iwj> Right, willdo.
[06:40] <tepsipakki> iwj: thanks for working on that
[06:41] <iwj> Thank Timo Aaltonon who debugged it.
[06:41] <tepsipakki> ant of course Mathieu who provided the info
[06:41] <tepsipakki> nope, not me ;)
[06:41] <iwj> Sorry, yes, Matthieu I mean.
[06:41] <iwj> Looking at the wrong bug.
[06:45] <tepsipakki> fabbione: looks like all the x11proto-stuff is uptodate, although randr and input have newer versions but not for 7.2
[06:45] <tepsipakki> sorry, I forgot x11proto-core (7.0.7->7.0.10)
[06:53] <Keybuk> iwj: sorry, I can give you my full attention now
[06:53] <iwj> Sure.
[06:54] <iwj> I just wanted your permission to reinstate ||: after the call to usplash_write in /etc/init.d/udev.
[06:54] <Keybuk> the usplash_write thing; we used to || true those calls on general principle
[06:54] <Keybuk> but then usplash_write got fixed so we didn't need to
[06:54] <Keybuk> someone broke usplash_write again?
[06:54] <Keybuk> why does it link to libx86?
[06:54] <mjg59> usplash_write really shouldn't
[06:54] <Keybuk> I can understand usplash linking to that, not the IPC client for it
[06:54] <mjg59> Hm. Maybe Colin added libx86 to the wrong bit of the makefile?
[06:55] <Keybuk> (and if usplash links to it, it should be in /lib really)
[06:55] <iwj> mjg59: Aha.
[06:55] <mjg59> But it should be in /lib /anyway/
[06:55] <mjg59> Given that usplash is
[06:55] <iwj> Keybuk: I've just uploaded a libx86 with it in /lib so the users' problem is fixed now :-).
[06:55] <Keybuk> yeah, solution would be
[06:55] <Keybuk> 1) libx86 should be in /lib
[06:55] <Keybuk> 2) usplash_write should not link to libx86  (only usplash should)
[06:55] <Keybuk> then there's no need for the || true
[06:56] <BenC> tfheen: device-tree-compiler uploaded...so probably hit NEW queue in a few minutes
[06:56] <Keybuk> there's definitely a bunch of things, not just udev, that don't || true
[06:56] <iwj> But ||: is good practice in this case.  /etc/init.d/udev should not bomb out for these kinds of reasons.
[06:56] <Keybuk> tbh, I don't mind either way
[06:56] <iwj> It's part of the responsibility when you say set -e, to add ||: when appropriate.
[06:56] <Keybuk> I took it out because infinity nagged
[06:57] <iwj> Well, infinity isn't here so if we can't find a good reason I'll revert it :-).
[06:57] <Keybuk> revert that on the safe side as well
[06:57] <Keybuk> you're right, there's no reason udev should ever fail because of usplash
[06:57] <cjwatson> iwj: I already moved libx86
[06:58] <iwj> cjwatson: Oh, our uploads will clash then.
[06:58] <cjwatson> iwj: first thing this morning
[06:58] <cjwatson> iwj: no, yours will be rejected ;-)
[06:58] <iwj> That's a clash.
[06:58] <cjwatson> fair enough
[06:58] <cjwatson> my fix was -1.2
[06:58] <iwj> Ah.  Mine was -1ubuntu1.
[06:58] <iwj> So if it's 1.2 I don't need to worry about pushing the patch.  Good.
[06:59] <cjwatson> yes, mjg59 OKed an NMU
[06:59] <cjwatson> (-1ubuntu1 would have been wrong anyway, since the broken version was -1.1)
[07:00] <cjwatson> oh
[07:00] <cjwatson>   libx86-1 |     0.99-1 |        feisty | i386
[07:00] <cjwatson> I wonder why that failed to build
[07:00] <iwj> libx86 (0.99-1) unstable; urgency=low
[07:00] <cjwatson>     libx86 |   0.99-1.2 |        feisty | source
[07:00] <iwj> But evidently I've been working from an old mirror.
[07:01] <iwj> Still on average it's faster to risk spend 10 minutes duplicating some trivial change occasionally than it is to check in LP each time.
[07:01] <cjwatson> aha, it got wedged somewhere in Launchpad :-(
[07:01] <Keybuk> the publisher, etc. is on; right?
[07:01] <iwj> Ug.
[07:01] <cjwatson> I've resurrected it
[07:01] <mjg59> cjwatson: Did you NMU to Debian or Ubuntu?
[07:01] <cjwatson> mjg59: Debian, and synced
[07:01] <mjg59> (Just briefly confused)
[07:01] <mjg59> cjwatson: Cool
[07:01] <cjwatson> it's OK, I've rescued the build
[07:02] <Keybuk> build lost down the back of the sofa?
[07:02] <cjwatson> down the back of the /srv/launchpad.net/builddmaster, yes
[07:03] <cjwatson> mjg59: just usplash should link to it, yes? or libusplash.so as well?
[07:03] <mjg59> Oh
[07:03] <mjg59> Probably actually just libusplash
[07:04] <cjwatson> except oh god I'm horribly confused
[07:04] <cjwatson> perhaps it should go in usplash_BACKEND_LIBS since that's where svgalib is
[07:04] <mjg59> Yes
[07:05] <cjwatson> except that gets substituted into a make target list
[07:05] <cjwatson> I'm going to look at this tomorrow instead
[07:09] <iwj> cjwatson: Shall I assign that task of 83878 to you ?
[07:09] <BenC> tfheen, cjwatson: https://wiki.ubuntu.com/MainInclusionReportdevice-tree-compiler
[07:09] <cjwatson> iwj: yes please
[07:10] <BenC> cjwatson: Will you have time tomorrow morning (my morning) to go over testing casper changes?
[07:10] <cjwatson> Keybuk: yes, publisher is on - madison-lite works off publisher output
[07:10] <cjwatson> BenC: how about now?
[07:11] <BenC> cjwatson: Sure, but I'll just be cut-and-pasting while I'm doing this kernel upload :)
[07:11] <BenC> I need device-tree-compiler in before uploading the kernel
[07:12] <keescook> BenC: in all the flying bits this week, did you happen to add the 2 apparmor patches?
[07:13] <cjwatson> BenC: ok, tomorrow morning will be doable
[07:13] <BenC> keescook: I thought I had already...I'll get it in next upload
[07:14] <keescook> BenC: oh! I didn't check for it.  :)  did you happen to figure out what happened to ASLR in the -6?
[07:15] <BenC> keescook: I thought it might have something to do with vdso, but I haven't tested it
[07:15] <BenC> keescook: I thought it might be caused by paravirt being enabled, but that's x86 only...shouldn't bother amd64
[07:15] <BenC> So I'm at a loss
[07:15] <keescook> what are the vsdo issues?
[07:16] <kylem> sorry to jump into your conversation, do you have VDSO compat on?
[07:16] <BenC> vdso was disabled in -6 because the vmware VMI paravirt patches required it...in -7 that isn't true anymore, but aslr test program still fails
[07:16] <BenC> kylem: For now, yes
[07:16] <BenC> that's a topic for feisty+1 specs
[07:17] <keescook> vdso compat has been on prior to -6?
[07:17] <BenC> we may need to leave it until after next LTS, unless we find that dapper binaries work without vdso compat
[07:17] <BenC> vdso compat has been on since it's introduction
[07:17] <elmo> I thought vdso compat was for some insanely old copy of glibc
[07:17] <BenC> which predates dapper I think
[07:18] <keescook> okay, so that's not it either.  hmpf
[07:18] <BenC> elmo: pre 2.3.3
[07:18] <BenC> I haven't checked how old that is
[07:18] <keescook> that's pre-breezy
[07:18] <elmo> yeah, that's hoary and older
[07:19] <BenC> worried about third-party apps though...
[07:19] <BenC> who knows what they use
[07:19] <elmo> with their own libc?
[07:19] <elmo> they deserver to lose :-P
[07:19] <elmo> (granted, that's not actually a realistic attitude, but still)
[07:19] <BenC> or static bins :)
[07:20] <elmo> if they're static would the VDSO come into play?
[07:21] <BenC> good point, probably not
[07:24] <BenC> cjwatson, tfheen: Guess it helps if I save the wiki page for that MIR...done now
[07:57] <lucas_> I was wondering... what's the status of the debian-maintainer-field field ?
[08:00] <Burgwork> lucas_: in what sense?
[08:01] <lucas_> well, it was a spec for edgy, but it's still far from being implemented
[08:01] <tfheen> lucas_: as in, there are still packages without it, you mean?
[08:01] <lucas_> the topic was raised again on #debian-devel, and I think that it would really be ridiculous to release feisty without fixing this
[08:01] <lucas_> tfheen: yes, even for binary packages
[08:01] <BenC> tfheen: Did you catch my upload and MIR?
[08:02] <lucas_> src packages are even worse
[08:02] <tfheen> lucas_: We don't change the source packages in the usual case.
[08:03] <lucas_> tfheen: I meant for packages with ubuntuX
[08:04] <tkamppeter> pitti, corrected foomatic-db is ready for upload (biff)
[08:07] <pitti> tkamppeter: looking...
[08:09] <pitti> tkamppeter: uploaded
[08:11] <Mirv> people are wondering about broken amd64 kernel updates in both dapper and edgy
[08:11] <Mirv> not broken as such, but uninstallable
[08:12] <BenC> Mirv: uninstallable how?
[08:12] <tfheen> Mirv: we're working on fixing it.
[08:12] <BenC> Mirv: oh, you mean the linux-meta thing...known and being fixed
[08:12] <Mirv> BenC: in edgy, for me, there are ... okay :)
[08:13] <Mirv> btw, how did they pass testing?-)
[08:14] <BenC> it's not a matter of existing things not passing...it's a matter of the archive not being fully in sync
[08:15] <BenC> some packages are missing, and they are working on getting them installed into the -security archive so deps are satisfied
[08:16] <tkamppeter> pitti, thanks.
[08:19] <LaserJock> lucas_: binary packages are changed when rebuilt, source packages are being worked on
[08:43] <BenC> tfheen: Is there anything else I need to do for device-tree-compiler?
[08:51] <tfheen> BenC: no, I'll get it in, don't worry.
[08:52] <BenC> tfheen: Just want to make sure you aren't blocking on me...take your time and thanks
[08:53] <tfheen> BenC: I'm not, but it's 20:52 here now so I think I'm done for today. :-)
[08:53] <BenC> tfheen: Ok, kernel and lrm are uploaded, but I build-dep's ppc on that package, so it'll sit till it gets through, no problems
[09:01] <mdke> seb128: did the yelp upload have a problem? i didn't see it on -changes
[09:05] <tfheen> BenC: cheers.
[09:06] <BenC> tfheen: later
[09:09] <seb128> mdke: no, I just had enough to do without it since yesterday, I'll do it later
[09:11] <mdke> seb128: that's fine
[09:11] <seb128> mdke: do you have an updated patch?
[09:11] <seb128> mdke: let me know if you have idea for the system menu changes, the 4 items in a row are not ideal
[09:14] <mdke> seb128: No, I haven't done an updated patch yet (I'll do it via a debdiff when you've uploaded). I'll give it a think about the menu
[09:15] <seb128> mdke: ok, cool
[09:16] <sistpoty> kylem: got my reply regarding revu? (sent 2 minutes ago)
[09:17] <kylem> not yet
[09:21] <sistpoty> kylem: strange... I got a "[...]  host cabal.ca [134.117.69.58] : 554[...] " is this some graylisting?
[09:21] <kylem> probably
[09:21] <tfheen> 554 isn't greylisting, 55x is a permanent failure.
[09:22] <tfheen> 5xx, even
[09:22] <sistpoty> hm... strange, cause I didn't get a delivery failed yet
[09:22] <cjwatson> 554 is "transaction failed"
[09:23] <sistpoty> exim even says Relay access denied
[09:23] <cjwatson> if it's on opening the connection, it's "what, you expect me to speak SMTP? you fool" or words to that effect
[09:23] <kylem> what address did you send it to?
[09:23] <sistpoty> kylem: I just hit reply ;) 
[09:23] <cjwatson> can also be "no valid recipients"
[09:23] <kylem> oh.
[09:23] <kylem> arg.
[09:24] <kylem> can you bounce the reply to kyle@mcmartin.ca
[09:24] <sistpoty> kylem: anyway, you can login to revu with kylem@debian.org
[09:24] <kylem> i bet it's forgotten how to MX for my laptop
[09:24] <kylem> ok
[09:24] <sistpoty> kylem: and you can (hopefully) recover your pw if you don't enter any
[09:48] <Keybuk> http://www.snpp.com/guides/chalkboard.openings.html
[09:48] <Keybuk> oh, wow
[09:48] <Keybuk> if that's not an eternal source of release code names, I don't know what is!
[09:49] <_ion> :-)
[09:51] <_ion> It's interesting how ASCII has corrupted punctuation, one of the episodes had -- instead of  in the chalkboard text. :-)
[09:59] <Keybuk> You know that law which states programs are gases, they expand to fill the available space
[09:59] <Keybuk> someone shouldn't have told the evolution authors
[09:59] <lifeless> !!! hahaha
[09:59] <Keybuk> scott     8115  0.1  8.5 531300 176244 ?       Sl   Feb05   4:14 evolution --com
[10:00] <Keybuk> .5GB !L"KLWQKRQKORKOQIO)_)$"($)"!()$)"$(+")(
[10:00] <_ion> Hehe.
[10:00] <Keybuk> in second place is firefox, with 480MB
[10:00] <Keybuk> third place is rhythmbox with 250MB
[10:04] <ajmitch> how do you get them to be so small?
[10:04] <Treenaks> firefox only 480M!?
[10:05] <Treenaks> ajmitch: I run xmms because my playlist is too large for rhythmbox.. it's just too slow
[10:07] <seb128> Treenaks: how many songs do you have?
[10:07] <Keybuk> yikes. the maximum recommended spec for feisty+1 atm is something like AMD Athlon 64 3200+, GeForce 6150, 512MB ram, 250GB SATA, 16X DVD, etc.
[10:08] <Treenaks> seb128: about 20k
[10:08] <seb128> Treenaks: and it's slow with that? weird
[10:08] <seb128> slow to start you mean?
[10:08] <seb128> or to use?
[10:08] <Treenaks> seb128: slow to start
[10:08] <seb128> ah ok
[10:08] <Treenaks> and searching for artists/albums is slow
[10:08] <seb128> don't close it ;)
[10:10] <seb128> mdke: 
[10:10] <seb128> patching file data/scrollkeeper.xml
[10:10] <seb128> patching file data/toc.xml.in
[10:10] <seb128> patch: **** malformed patch at line 49: +    <_title>General Guides</_title>
[10:10] <seb128> with your yelp patch
[10:11] <mdke> seb128: is that without the previous ubuntu patch?
[10:13] <seb128> mdke: it's trying to apply "updated patch" to the package
[10:14] <mdke> seb128: did you drop the previous ubuntu patch as discussed on the bug?
[10:15] <seb128> mdke: I did apt-get source, cd dir, patch -p1 < patch
[10:16] <seb128> mdke: and it doesn't write that the patch doesn't apply
[10:16] <seb128> it writes that the patch is malformed
[10:16] <mdke> seb128: ok. AFAIK, from what DonS said on the patch, you have to drop the previous Ubuntu patch first
[10:16] <mdke> he did the patch on a vanilla Yelp I think
[10:16] <seb128> mdke: I didn't apply any patch
[10:17] <seb128> mdke: <seb128> mdke: I did apt-get source, cd dir, patch -p1 < patch
[10:17] <mdke> oh, I see
[10:17] <seb128> mdke: I tried to apply with -p1 to upstream non patched
[10:17] <mdke> hmm
[10:18] <mdke> seb128: can you try the "Update" patch? That was the one DonS sent before I edited it (although I don't think my edit is relevant to that error)
[10:18] <seb128> mdke: "Update" attachment works fine
[10:18] <seb128> "Updated patch" is malformed
[10:18] <mdke> ok phew
[10:18] <mdke> that's my fault then :(
[10:18] <mdke> sorry about that
[10:18] <seb128> k, do you have any change I should do over DonS' patch?
[10:18] <seb128> np
[10:19] <mdke> no, that's fine. I'll do the changes later using cdbs-edit-patch, surely even i can't make a mistake with that
[10:19] <seb128> ok
[10:24] <mdke> seb128: maybe a separator before About Gnome in the System menu?
[10:26] <seb128> yeah, a separator somewhere would be nice
[10:26] <seb128> or maybe moving the apport item before the existing one?
[10:26] <mdke> yeah, that would work for me too
[10:27] <seb128> mdke: I've uploaded yelp with the patch, the "Common Questions" links are broken and some people will probably bug about that, would be nice to fix that for next update ;)
[10:27] <mdke> oh yeah, that was in my edit
[10:28] <mdke> seb128: I'll fix it as soon as it hits the archive
[10:28] <seb128> ok, thank you
[10:28] <seb128> I'll upload an update tomorrow
[10:28] <seb128> no hurry
[10:30] <mdke> seb128: ok
[10:40] <mdke> seb128: can I get the source already from Launchpad do you know?
[10:40] <Keybuk> "The high intensity blue LED installed silent 110mm fan inside the heatsink maximizes cooling performance."
[10:40] <Keybuk> I so read that as the LED maximizes cooling performance
[10:41] <seb128> mdke: no need to wait, get the previous source, drop the patch 06 and copy the one from DonS to debian/patches, you can cdbs-edit-patch it then
[10:41] <lifeless> Keybuk: so did I
[10:41] <mdke> seb128: I'll probably break that. I'll try that though, ok.
[10:42] <Lure> Keybuk: lol
[10:42] <seb128> mdke: why? just download the patch to debian/patches and use cdbs-edit-patch
[10:43] <mdke> seb128: ok. I just copy don's patch over the existing 06 patch?
[10:43] <seb128> mdke: for example
[10:44] <mdke> ok, I'll give it a shot
[11:13] <shawarma> Any members of ubuntu-archive around? I've (before UVF) subscribed ubuntu-archive to a sync request, but it hasn't been done yet. Since we're in UVF, I should get an OK from motu-uvf first before ubuntu-archive should be subscribed, right? 
[11:13] <zul> tfheen: ping...mind pushing xen-meta though?
[11:23] <siretart> kylem: I've just seen your request for being a reviewer on revu. just checking the database, and I see you already being an admin?
[11:24] <sistpoty> siretart: sorry, I haven't sent reply-to-all
[11:24] <kylem> sistpoty added me
[11:27] <siretart> all right, no problem