[12:07] <icecrash> are there so much md5 problems on the different mirrors?
[12:08] <icecrash> working with the same debmirror setup, parts fail on the first mirror, parts fail on the next
[12:08] <icecrash> ???
[12:15] <Chipzz> hrrrrm
[12:15] <Chipzz> chipzz    5299  0.0  0.0   4476   732 ?        Ss   Aug02   0:00 /usr/bin/ssh-agent /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
[12:16] <mjg59> Kamion: I want a configuration file with two values in it. What's the sanest format to parse?
[12:20] <Kamion> mjg59: from C?
[12:21] <mjg59> Kamion: Yeah
[12:21] <mjg59> Kamion: I want to put x and y values for usplash resolution in initramfs
[12:21] <Kamion> mjg59: avoid foo=bar, people will think it's shell syntax (see pam_env)
[12:21] <mjg59> Indeed
[12:21] <Kamion> mjg59: I'd go for 'xresolution FOO\nyresolution BAR\n' personally
[12:21] <mjg59> Ok
[12:22] <Kamion> and # at start of lines to introduce comments
[12:22] <mjg59> This isn't going to be doable in four lines, is it?
[12:22] <Kamion> probably not
[12:22] <Kamion> should be doable in a couple of dozen though
[12:22] <mjg59> The alternative would be to use read to grab the values and then pass them to usplash on the command line
[12:23] <Kamion> if you're doing that in shell, you could
[12:23] <Kamion> just use a sourced file
[12:23] <Kamion> (ignore spurious newline there)
[12:23] <mjg59> Oh, true
[12:23] <mjg59> Yeah, I'll do that
[12:24] <mjg59> So
[12:24] <mjg59> I want to populate the config file with information from the X autoconfiguration stuff
[12:24] <mjg59> Which ought to be in debconf
[12:24] <Kamion> please don't read debconf for that - reading xorg.conf is preferable
[12:24] <Kamion> I know it's a bit harder, but
[12:24] <mjg59> Seriously?
[12:24] <mjg59> Ouch
[12:25] <Kamion> the information in debconf isn't canonical - people are entitled to modify xorg.conf by hand
[12:26] <mjg59> Actually, I don't believe that it's possible to do that
[12:26] <mjg59> The default resolution in xorg.conf might be outside the limits of the hardware
[12:26] <mjg59> That is, after user modification
[12:26] <Kamion> won't X break too then?
[12:26] <mjg59> But it should be in limits at the point where X is autoconfigured
[12:26] <mjg59> No
[12:27] <mjg59> X will drop modes it doesn't think it can display and fall back
[12:27] <Kamion> what will X do?
[12:27] <Kamion> can usplash do the same?
[12:27] <mjg59> No
[12:27] <Kamion> X's autoconfiguration does get it annoyingly wrong sometimes
[12:27] <Kamion> also, usplash needs to not fuck up if the debconf database disappears
[12:27] <mjg59> Ngh.
[12:27] <Kamion> or if the debconf db is on /var which isn't mounted yet, for example
[12:27] <mjg59> Yes.
[12:28] <mjg59> I was planning on using the debconf data to write the default config file
[12:28] <Kamion> I suppose you could fetch it from debconf iff you did it in usplash.postinst
[12:28] <Kamion> yeah
[12:28] <mjg59> Which would then be user modifiable
[12:28] <Kamion> that would be less bad, provided you had a fallback in case X isn't tere
[12:28] <Kamion> there
[12:28] <Kamion> or in case those debconf questions have disappeared
[12:28] <Kamion> usplash can be installed without X, so ...
[12:29] <mjg59> Yeah
[12:29] <mjg59> In that case, just fall back to 640x480
[12:35] <Kamion> mjg59: or 640x400 maybe?
[12:36] <icecrash> Kamion: one questions if it's ok
[12:36] <icecrash> how much space is necessary to rebuild a complete set of cds?
[12:36] <mjg59> Kamion: Not a vesa mode
[12:37] <icecrash> as the cdimage runs a complete rsync, more than 150 seems to be clear
[12:37] <Kamion> mjg59: ah, plain VGA support is gone?
[12:37] <Kamion> icecrash: mirror size plus about 2GB for amd64/i386/powerpc alternate install CD
[12:37] <Kamion> oh, no
[12:38] <Kamion> sorry, more like 4GB
[12:38] <Kamion> unpacked ISO size plus packed ISO size
[12:38] <Kamion> I can't easily give mirror figures for just one release
[12:39] <icecrash> 150gb  is the size that the mirrors print out as ubuntu repos size
[12:39] <mjg59> Kamion: For now - we'll see if it's needed for a fallback
[12:39] <Kamion> a full main+restricted mirror is 69GB at present
[12:39] <icecrash> and universe is not delivered :)
[12:40] <icecrash> perfect
[12:41] <Kamion> the entire archive is about 200GB
[12:42] <icecrash> if there are any plans to move over to a python implementation of cdimage, after my session, I offer help :)
[12:43] <icecrash> its a really huge process
[02:21] <nictuku> hi, just FYI, /usr/share/fonts/X11/misc does not have "fonts.dir". mkfontdir is enough to fix it
[02:32] <desrt> heh. cute usplash screen.
[02:32] <dabear> has it changed again?
[02:33] <desrt> it looks like a test pattern
[02:33] <dabear> could you take a screenie w/ a camera or something?
[02:47] <icecrash> good night
[02:49] <desrt> dabear; http://desrt.mcmaster.ca/random/test-pattern.jpeg
[02:49] <desrt> looks like we have some nice high-res usplash business
[02:50] <jdub> looks like the old one; is it in the centre of your screen without stretching (now that it's using svgalib)?
[02:51] <desrt> i expect so
[02:51] <desrt> let me reboot again and take a better look
[02:51] <desrt> i only get it at the very end of the shutdown, though
[02:51] <desrt> not at startup and not during the initial part of the shutdown
[02:52] <desrt> the 1:1 square seems square....
[02:52] <tseng> hi desrt
[02:52] <tseng> I am fixing muine now
[02:52] <desrt> tseng; upstream?
[02:52] <tseng> no, your upload failed to build
[02:52] <tseng> missing build-dep, not your fault
[02:52] <desrt> seriously?
[02:52] <desrt> ah.
[02:53] <desrt> i wonder how we got away with that in dapper
[02:54] <tseng> because dapper has cli-common
[02:54] <tseng> edgy has cli-common, cli-common-dev
[02:54] <tseng> split.
[02:54] <desrt> make: dh_makeclilibs: Command not found
[02:54] <tseng> you got it.
[02:54] <desrt> tsk tsk tsk
[02:54] <desrt> oh my.  looks like it will rain tonight
[02:55] <desrt> edgy's grub works with macbook
[02:55] <desrt> love.
[02:56] <desrt> somehow lilo takes about 10x (seriously) as long to load the kernel off the disk as grub does
[02:57] <desrt> jdub; is that normal or should i be concerned?
[02:57] <tseng> desrt: neat.
[02:58] <jdub> desrt: you probably don't have 'compact' in your lilo config
[02:58] <desrt> jdub; actually, i did
[02:58] <tseng> desrt: word, thunderstorm
[02:58] <tseng> just hit me
[02:59] <desrt> :)
[02:59] <desrt> it's windy as all hell here
[02:59] <tseng> we are going between 100 degree heat and thunderstorms
[02:59] <desrt> jdub; i mean the usplash thing... is it normal for it to only show for a few seconds just before reboot and not any other time
[03:00] <sladen> desrt: no, it should show on bootup and on shutdown
[03:00] <desrt> yay.  something else to look into :D
[03:03] <jdub> desrt: oh; no, but it is a pretty new version (multiple uploads, finally built) and it has been a bit rough in edgy already, so...
[03:03] <desrt> yay.  something less to look into :D
[03:08] <desrt> *** stack smashing detected ***: /usr/bin/whiptail terminated
[03:08] <tseng> send that bug to pitti, i think
[03:09] <desrt> more like a whiptail bug, i think
[03:09] <tseng> well, its a whiptail bug discovered by ssp most likely
[03:09] <tseng> muine uploaded
[03:09] <desrt> definitely.
[03:09] <tseng> I got sidetracked
[03:09] <desrt> cool
[03:09] <tseng> it should build now
[03:21] <bddebian> Howdy
[03:23] <tseng> hello
[03:24] <bddebian> Heya tseng
[03:26] <Kamion> BenC: any luck on the dapper kernel upload?
[03:31] <Kamion> ogra: please try to avoid deleting old dapper-updates changelog entries in future (gnome-screensaver 2.14.3-0ubuntu1 lost the changelog from gnome-screensaver 2.14.2-0ubuntu1)
[03:35] <bddebian> Kamion: Hush up and get syncing.. ;-P
[03:37] <jdub>    * Make svgalib shut up
[03:37] <jdub>    * Create necessary device nodes in initramfs startup
[03:37] <jdub>    * Autoconfigure the resolution where possible
[03:37] <jdub> ^ usplash upload from mjg59
[03:37] <jdub> AUTOCONFIGURE THE RESOLUTION WHERE POSSIBLE
[03:38] <tseng> woo
[03:38] <mjg59> It might even work
[03:39] <mjg59> (does here)
[03:39] <Kamion> bddebian: it's 2:30 am, sod off :P
[03:39] <Amaranth> i guess i don't get to enjoy the new bootup bling :/
[03:39] <bddebian> Ah, it's early then
[03:39] <Amaranth> ah well, i don't restart that much
[03:40] <mjg59> Amaranth: Mm?
[03:40] <Amaranth> mjg59: i get no usplash love
[03:41] <mjg59> Amaranth: Why not?
[03:41] <Amaranth> mjg59: I dunno, I get a blinking underscore then text boot
[03:43] <jdub> $ pbuilder build --basetgz /var/cache/pbuilder/dapper.tgz mugshot_1.1.13-0ubuntu1.dsc
[03:43] <jdub> E: File /var/cache/pbuilder/hoary.tgz does not exist
[03:43] <jdub> ^ ?!
[03:43] <LaserJock> hehe
[03:44] <crimsun> pass --configfile foo to it
[03:44] <crimsun> (presuming you used one)
[03:44] <ajmitch> hoary? that's awhile ago now
[03:44] <LaserJock> last time jdub build a package, apparently ;-)
[03:44] <LaserJock> *built
[03:44] <jdub> no, i've been trying to fix pbuilder on my machine
[03:44] <jdub> so i killed everything
[03:44] <crimsun> too bad, I miss the "naked people."
[03:44] <jdub> and built a dapper pbuilder basetgz
[03:45] <jdub> which was called hoary.tgz for some reason
[03:45] <jdub> i renamed it
[03:45] <jdub> and now it's b0rk
[03:45] <BenC> Kamion: uploading in about 10 minutes
[03:45] <jdub> no pbuilder config file refers to hoary
[03:46] <crimsun> jdub: gotta use --override-config, then
[03:46] <jdub> no config refers to hoary
[03:46] <jdub> and it fails in the same way if i hadd that
[03:46] <jdub> s/hadd/add/
[03:47] <jdub> $ grep -rl hoary /etc/pbuilder* | wc -l
[03:47] <jdub> 0
[03:47] <crimsun> well, the hacky way is to change BASETGZ in /etc/pbuilderrc
[03:47] <jdub> BASETGZ=/var/cache/pbuilder/base.tgz
[03:47] <jdub> doesn't even refer to that :)
[03:48] <jdub> (also now there's an /etc/pbuilder/pbuilderrc too)
[03:48] <jdub> oh
[03:48] <jdub> which is just a link
[03:48] <desrt> bah.  usplash makes sleep/wake unstable
[03:48] <desrt> lame.
[03:48] <jdub> even changing that doesn't work
[03:49] <jdub> oh
[03:49] <jdub> ha ha ha
[03:49] <jdub> ~/bin/pbuilder -> GAR!
[03:49] <Kamion> BenC: thanks
[03:49] <Kamion> BenC: I'll stay up then :)
[03:49] <crimsun> heh, my next question.
[04:08] <BenC> grr...this box is so stupid
[04:08] <BenC> it crashes if I don't have a head on it, and boots perfect if I do
[04:09] <BenC> how the hell am I supposed to see how it's crashing if it does that
[04:09] <BenC> it boots even if I connect a serial console
[04:11] <desrt> BenC; do you know of any other bugs in the kernel where it can't properly calculate the number of bogomips?  i'm sort of stuck on where to go next on this bug i'm hunting
[04:11] <BenC> do you really need bogomips to me accurate, considering it's not really accurate by nature?
[04:11] <BenC> s/to me/to be/
[04:11] <desrt> yes
[04:11] <desrt> bogomips is used to calibrate delay loops
[04:12] <desrt> which are used by usleep() msleep() etc
[04:12] <BenC> bogomips changes whether you run 2.2, 2.4 or 2.6 kernels and even sometimes changes in between
[04:12] <desrt> and at bootup the kernel does a test to make sure the timer IRQ is working
[04:12] <desrt> it msleep()s for a bit and makes sure the right number of timer IRQs were delivered
[04:12] <desrt> if your bogomips count is wrong then the kernel panics because it assumes your timer hardware is borked
[04:12] <BenC> what does that have to do with bogomips though?
[04:12] <desrt> it does something like this:
[04:13] <BenC> haven't heard anything regarding that
[04:13] <desrt> c = jiffies;
[04:13] <desrt> msleep(a while);
[04:13] <desrt> c = c - jiffies;
[04:13] <desrt> or jiffies -c, even.
[04:13] <desrt> then makes sure c is within the expected range
[04:13] <desrt> so if msleep is inaccurate the kernel gets very unhappy
[04:14] <desrt> see https://launchpad.net/bugs/54621
[04:14] <Ubugtu> Malone bug 54621 in linux-source-2.6.17 "Kernel panic - not syncing: IO-APIC + timer doesn't work!" [Untriaged,Unconfirmed]
[04:14] <BenC> Kamion: kernel upload away
[04:14] <BenC> sounds like it isn't related to bogomips
[04:14] <BenC> I've seen a similar bug and it's related to something else
[04:14] <desrt> it's definitely related to bogomips
[04:14] <BenC> desrt: brb
[04:14] <desrt> giving lpj= on the commandline fixes it
[04:15] <desrt> (loops per jiffy -- manual delay loop calibration, ie: you tell it how many BogoMIPS you have because it can't detect it for itself)
[04:18] <desrt> tseng; rain starting here just now
[04:19] <bddebian> tseng: Warm enough for ya today? ;-P
[04:21] <desrt> well... liberal use of printk brought me this far :)
[04:21] <bddebian> Ah :-)
[04:21] <bddebian> No wonder I'm not cool enough for core-devs :-)
[04:23] <mjg59> desrt: Code change around 2.6.17 changed the default timer
[04:23] <desrt> mjg59; this happened both before and after
[04:23] <mjg59> desrt: Ok
[04:23] <BenC> desrt: is your system using calibrate_delay_direct() or the manual way to calibrate lpj?
[04:23] <mjg59> desrt: Also, it says "Boot with apic=debug" and then you say "acpi=debug gives no extra output"
[04:23] <mjg59> apic != acpi
[04:23] <desrt> BenC; it's using the manual for now.... when it uses the calibrate_delay_loop() it sometimes fails
[04:23] <mjg59> Typo?
[04:23] <desrt> mjg59; ya..... :)
[04:24] <desrt> mjg59; definitely typo
[04:24] <BenC> desrt: so manual works?
[04:24] <desrt> mjg59; i just don't know if i made the typo into lilo or not :)
[04:24] <desrt> BenC; ya.  i add the lpj= commandline option and all is well
[04:24] <mjg59> So it's the "8254 timer not connected to apic" bit that's exploding
[04:24] <desrt> ya.... it uses a bogomips-calibrated delay loop to wait for some timer IRQs to come in
[04:25] <desrt> and if the wrong number comes in it assumes the timer IRQ is miswired
[04:25] <mjg59> Right
[04:25] <desrt> of course, if the delay loop is miscalibrated this will also cause the wrong number
[04:25] <mjg59> Yes
[04:26] <mjg59> I think this is an lkml job
[04:26] <BenC> desrt: by manual I mean the part in calibrate_delay(), the last if
[04:27] <mjg59> desrt: I wonder why other people don't seem to be getting bitten by this...
[04:27] <BenC> desrt: if you hardcode the calibrate_delay_loop() bit to be skipped, and let it fall through, does it work?
[04:27] <mjg59> desrt: It's always possible that your hardware is fucked in some bizarre subtle way
[04:27] <desrt> mjg59; some #gnome-hackers guy is
[04:27] <BenC> that's what I was thinking
[04:27] <desrt> mjg59; a fellow macbook owner
[04:27] <mjg59> Oh, fun
[04:27] <BenC> macbook
[04:27] <mjg59> Ok
[04:27] <desrt> mjg59; in fact, he gets bitten by it more frequently than i do
[04:27] <BenC> that's what I was thinking
[04:27] <mjg59> Maybe a run of bad ones :p
[04:27] <BenC> desrt: is this dapper or edgy?
[04:28] <desrt> both
[04:28] <mjg59> desrt: Have you tried booting with different timer= values?
[04:28] <desrt> no...
[04:28] <desrt> like, instead of HPET?
[04:28] <mjg59> Yeah
[04:28] <mjg59> Try tsc or pmtimer
[04:28] <desrt> i never understood why tsc wasn't used more often....
[04:28] <BenC> desrt: test one of these: http://people.ubuntu.com/~bcollins/kernels/mvo-dazuko/
[04:28] <mjg59> There's something weird about HPET and Linux in the DSDT
[04:28] <BenC> there's a timer fix in there for macbook
[04:29] <desrt> The requested URL /~bcollins/kernels/mvo-dazuko was not found on this server.
[04:29] <mjg59> desrt: Because it's a bastard to keep in sync on multiple-CPU machines
[04:29] <zul> hey
[04:29] <BenC> drop one subdir and see what's in kernels/
[04:29] <desrt> -test
[04:29] <mjg59> BenC: Have you got the patch somewhere?
[04:29] <desrt> oh.  i no longer have dapper on the box.
[04:29] <desrt> but it happened in dapper too
[04:29] <BenC> desrt: you'll have to wait for an edgy kernel with that fix
[04:30] <BenC> try the dapper one, it should still boot fine
[04:30] <BenC> atleast tell you if things work correctly
[04:30] <BenC> http://people.ubuntu.com/~bcollins/kernels/mvo-dazuko-test/
[04:30] <desrt> k.
[04:30] <BenC> that's exactly the kernel I just uploaded to dapper-security
[04:31] <desrt> lemme take it for a spin :)
[04:31] <Kamion> BenC: oh, dapper-security - it'll need pitti to publish it then
[04:31] <Kamion> drat, that's slower :)
[04:31] <Kamion> oh well, will nudge him tomorrow morning
[04:31] <desrt> failing that, i'll try mjg59's ideas
[04:32] <mdz> mjg59: should we switch to using the ondemand governor instead of powernowd?
[04:33] <desrt> YES YES YES
[04:33] <mjg59> mdz: On machines where it works, yes
[04:33] <BenC> mjg59: it was cherry picked from upstream
[04:33] <mdz> mjg59: what's hardware-specific about it?
[04:33] <mjg59> mdz: It needs to know latancy figures
[04:33] <mjg59> Not all cpufreq modules provide that
[04:36] <mjg59> I'm heading to bed - any feedback on usplash would be good
[04:36] <mjg59> It works here now, anyway
[04:36] <desrt> mjg59; it doesn't work for me
[04:36] <mjg59> desrt: 0.4-5
[04:36] <desrt> how new is this?
[04:37] <mjg59> Uploaded, not built yet
[04:37] <desrt> gotcha.
[04:37] <desrt> fwiw, fbcon prevents sleep from working properly here
[04:37] <mjg59> Which fbcon?
[04:37] <mjg59> Just any framebuffer at all?
[04:37] <desrt> intel?
[04:37] <desrt> it's my dumb macbook acting out again :)
[04:38] <mjg59> Oh
[04:38] <mjg59> We don't use that by default, right?
[04:38] <desrt> oh.  btw
[04:38] <desrt> vbestate and acpid are still inverted in rc2.d
[04:38] <desrt> plz fix
[04:38] <mjg59> Oh, bleah, yes.
[04:38] <mjg59> It's only a problem because laptop-detect doesn't work for you
[04:39] <desrt> BenC; no love
[04:39] <desrt> BenC; booted fine a couple of times and then on the 3rd try failed
[04:39] <BenC> desrt: was the bogo's the same each time?
[04:39] <BenC> desrt: how far off is the value it's giving you?
[04:39] <desrt> BenC; uhm...
[04:39] <desrt> 4519.06 is the sum
[04:40] <BenC> what are you passing?
[04:40] <desrt> and CPU1 is always detected correctly at 3994.7
[04:40] <desrt> so it just detected 524 bogomips
[04:40] <mjg59> desrt: Can you give the other timer options a go?
[04:40] <desrt> mjg59; sure will
[04:40] <mjg59> Rock
[04:40] <BenC> yeah, sounds like it's just not using the right timer source or something
[04:41] <desrt> i  have decided that edgy will run perfectly on the macbook
[04:42] <BenC> desrt: so when it boots ok, is the bogo's right, or it just happens not to affect it?
[04:42] <desrt> BenFrom a successful boot:
[04:42] <desrt> [17179570.588000]  Total of 2 processors activated (6485.23 BogoMIPS).
[04:43] <desrt> this should be more like 7[something]
[04:43] <desrt> so no... they're not perfect
[04:43] <desrt> just close enough that it's not enough to cause the timer-irq code to break
[04:43] <BenC> desrt: it's odd that the bogo's are different from boot-to-boot on the same kernel
[04:43] <desrt> BenC; it's because of the "calibrate_delay_direct() failed to get a good estimate for loops_per_jiffy.  Probably due to long platform interrupts."
[04:44] <desrt> the kernel knows that it got a bad bogomips count
[04:44] <BenC> ah, so it falls through to the crappy estimate code
[04:44] <desrt> i guess?
[04:44] <BenC> you're the one with the printk's :)
[04:45] <desrt> i didn't printk that part :)
[04:45] <BenC> for shame :)
[04:45] <desrt> lemme try mjg59's ideas
[04:46] <desrt> you know that bit about "seeing if WP bit is honoured in supervisor mode"
[04:46] <desrt> the HPET stuff comes just after that
[04:47] <desrt> and sometimes (seems unrelated to if bogomips is accurate or not, actually) it pauses for a _very_ long time there
[04:47] <desrt> like 5-10 seconds
[04:48] <desrt> eep.  using tsc is no help.
[04:56] <bluefoxicy> https://wiki.ubuntu.com/QuietenGrub disturbs me; the idea behind it seems to be, "The user may be curious about a message that appears for all of 1 second and means nothing just as the computer turns on; so we should hide this"
[04:57] <bluefoxicy> the machine displays a lot of words and numbers when it's first turned on; worrying that the user may get confused by the few Grub and the Linux kernel spit out seems silly.
[04:57] <BenC> bluefoxicy: it's about a polished look
[04:57] <bluefoxicy> The only way the user is going to get confused is if they suddenly decide that they care what's going on, even though it's blatantly obvious that it's of no concern to them.
[04:58] <BenC> for the same reason we default the kernel to "quiet"
[04:58] <desrt> the grub quiet stuff is _really_ dumb
[04:58] <zul> i think it looks cool
[04:58] <bluefoxicy> It doesn't seem to matter from my point of view
[04:58] <desrt> it replaces "Uncompressing Linux... OK, booting the kernel." with "Booting the operating system now."
[04:58] <zul> uh...it does more than that
[04:58] <desrt> and it hardcodes that "Booting" message into grub
[04:59] <desrt> (can't be turned off)
[04:59] <bluefoxicy> the user is either going to go "OK words are appearing on the screen it's loading" or go get a can of soda
[04:59] <desrt> if you want to get rid of messages then get rid of them... by all means
[05:00] <bluefoxicy> I don't see an actual problem, aside from the user getting nervous that the screen is blank for 5 seconds and thinking "huh the system just sits doing nothing for 5 seconds, I wonder why they never fixed that" (since during that time the hard drive is accessed all of twice)
[05:00] <bluefoxicy> besides that it just seems like a waste of developer time
[05:01] <bddebian> So is your bloviating :-)
[05:01] <bluefoxicy> bloviating, that's a new one for me.
[05:02] <Burgundavia> 'ello Hobbsee
[05:02] <zul> bluefoxicy: it was not that hard to implement in the first place
[05:02] <Hobbsee> hi all, hi Burgundavia :)
[05:02] <Hobbsee> hi zul
[05:02] <zul> hey hobssee
[05:02] <bluefoxicy> zul:  shrug
[05:03] <bddebian> Heya Hobbsee
[05:03] <Hobbsee> hi bddebian
[05:04] <bluefoxicy> particularly when the Linux kernel used to barf half a screen of text, then sit quiet for about 20 seconds on hardware it wasn't quite sure what to do with yet; then finish booting :P
[05:04] <desrt> anyway.  i have work to be doing :)
[05:04] <bluefoxicy> Remember, the text on the bootsplash screen is mainly meaningless too.  EVMS?  Mounting disks?  Whassat?  :>
[05:05] <desrt> about that.... why is evms/raid/lvm/etc/etc initialised on desktops?
[05:05] <Kamion> desrt: it isn't on fresh edgy installs
[05:05] <desrt> oh.  sweet.
[05:05] <desrt> +1
[05:06] <bluefoxicy> no, it was removed.  Although it's going to cause a problem for upgrades if someone doesn't fix a certain bug.
[05:06] <Kamion> that'll get fixed, I'm quite certain
[05:06] <bddebian> Kamion: Damn man, you still haven't gone to sleep?
[05:07] <Kamion> still beating against the big ubiquity wall, though fading fast
[05:07] <bluefoxicy> Kamion likes his work :)
[05:07] <Hobbsee> Kamion is very good at what he does.
[05:08] <Hobbsee> the explosives are to aid you in blowing up the big ubitquity wall, not for any other purpose!
[05:08] <bluefoxicy> Kamion is very good at complaining about needing sleep every night and staying up for hours longer working :)
[05:09] <Hobbsee> bluefoxicy: arent we all?
[05:09] <bddebian> Hobbsee: Darn, and here I thought it was for blowing up bluefoxicy ;-)
[05:09] <zul> not me...i got to bed at a sensible time when i can
[05:10] <bluefoxicy> zul:  heathen!
[05:10] <Hobbsee> bddebian: hah.  well....
[05:10] <Hobbsee> bddebian: now that you mention it...
[05:10] <zul> bluefoxicy: then i can be crabby in the morning..
[05:11] <Hobbsee> zul: and very asleep in meetings, yes.
[05:12] <bluefoxicy> haha, poor Hobbsee :)
[05:12] <Hobbsee> bluefoxicy: you dont want to know how asleep i was in yesterday's meeting.  and they're asking me complicated questions
[05:12] <Hobbsee> and i'm thinking "hey now, i could answer you when i'm awake...but while i'm still waking up?  not a chance"
[05:13] <bluefoxicy> Hobbsee:  Unless a job is at stake I tend to just spurt crap back when that happens
[05:13] <Hobbsee> bluefoxicy: not a good idea to do to the TB.
[05:13] <bluefoxicy> if you catch me when I'm asleep I'll be like, "..... wut?  I dunno, go ask stiffler's mom or something there's a crash in the dog processor chupathingy..."
[05:14] <bluefoxicy> just because I figure if I say something you'll go away
[05:14] <TheMuso> c
[05:14] <bluefoxicy> Hobbsee:  I actually can think when my body is out of it; my mind never really sleeps.
[05:15] <bluefoxicy> now, whether I want to put the energy into controlling my jaw is another story.
[05:15] <Hobbsee> heh
[05:15] <Keybuk> Kamion: uh, dude, get out of my time zone ;)
[05:16] <jsgotangco> thou shalt not malloc another byte
[05:16] <jsgotangco> lol
[05:16] <jsgotangco> :D
[05:16] <Hobbsee> hi Keybuk.  i've got a question about your MoM at some point.
[05:16] <bluefoxicy> .................... wtf does that stand for
[05:17] <bddebian> Keybuk!!!
[05:17] <jsgotangco> bluefoxicy: i was just quoting Keybuk from his email heh
[05:17] <bluefoxicy> jsgotangco: no I meant Hobbsee asking about urMoM
[05:17] <jsgotangco> ahhh sorry
[05:17] <Keybuk> Hobbsee: shoot
[05:17] <Hobbsee> bluefoxicy: MoM is the merge-o-matic.  see merges.ubuntu.com and then do some of them
[05:17] <jsgotangco> Merge-o-Matic
[05:17] <bluefoxicy> ah
[05:18] <Hobbsee> Keybuk: the merge-buildpackage script - why are we not running that with -rfakeroot anyway?  you either need to do that, or run it as root
[05:18] <Keybuk> (totally-not-funny-story ... the reason it's called "mom" is because it's a very very very CPU & I/O-using process and I didn't tell elmo about it ...
[05:18] <Keybuk> so it's argv[0]  was "hi mom!"
[05:19] <Keybuk> and I backronymed that into "hoary intelligent merge-o-matic"
[05:19] <Keybuk> for obvious reasons, when breezy was released, it was shortened)
[05:19] <Keybuk> Hobbsee: you can merge-buildpackage -rfakeroot
[05:19] <Hobbsee> heh
[05:19] <Hobbsee> Keybuk: that's what i do.  i'm wondering why it isnt set to do that by default though
[05:20] <Keybuk> Hobbsee: for the same reason it's not the default for dpkg-buildpackage either ... not everyone uses fakeroot
[05:20] <Keybuk> I test merges in a chroot, where I'm root, for example
[05:20] <Hobbsee> Keybuk: true.  wonder what happens if you put it in anyway, while running as root.  i keep forgetting the rotten thing.
[05:20] <Keybuk> Hobbsee: not much
[05:21] <Keybuk> still works
[05:21] <Hobbsee> Keybuk: right.
[05:21] <Keybuk> some people use -rsudo
[05:23] <Keybuk> Hobbsee: which mailing list is that on?
[05:23] <Hobbsee> Keybuk: looks to be MOTU
[05:24] <ajmitch> which quickly went onto what new packages we should accept into universe, if any
[05:24] <Hobbsee> ajmitch: true, i'm getting to that.
[05:25] <bddebian> Heh
[05:29] <Hobbsee> yay.  Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/edgy/universe/binary-i386/Packages.gz  MD5Sum mismatch
[05:29] <desrt> Hobbsee; give it 12 seconds and try again :)
[05:30] <Hobbsee> desrt: heh.  i did.  this uni connection is a bit slow
[05:56] <sid> From the home page... "Ubuntu is a complete Linux-based operating system, freely available with both community and professional support." Why doesn't it say GNU+Linux or GNU/Linux.
[05:58] <jdub> sid: we tend to avoid that turf war
[05:59] <Kamion> in this case we haven't managed to avoid it though, we've picked one side ;)
[05:59] <Kamion> as jdub said we historically tried to avoid saying either Linux or GNU/Linux
[05:59] <Kamion> (unless necessary/pertinent)
[05:59] <Kamion> it's kind of slipped in places though
[06:01] <bluefoxicy> unlike Gentoo which has Gentoo/Darwin Gentoo/Linux Gentoo/FreeBSD etc etc etc
[06:03] <jdub> Kamion: hrm, i guess; though this is more a statement of fact than a branding issue ;-)
[06:04] <sid> eh, Seems important to mention GNU. This project and Debian could be dead by companies like SCO, if it weren't for things like the GPL which has been the MVP in stopping SCO. Someone(*cough*) had to foresight in 1991 to structure the license in a certain way that helps us all.
[06:04] <sid> Plus we all know how evil the DMCA / Software idea patents are. Seems silly not to mention GNU
[06:05] <desrt> sid; is this a troll?  why are you using tor?
[06:05] <sid> I'm not a troll.
[06:05] <sid> MSG nickserv info sid; my nickserv account wouldn't be this old if I was a troll.
[06:06] <crimsun> I'm thinking this pedantry is increasingly off-topic.
[06:06] <sid> I'm just trying to figure out the reasoning for not mentioning GNU. I feel it's important. I thought this is where the web master would be.
[06:08] <desrt> sid; it's probably not as important as not confusing new users is.  "linux-based", for 98% of the population (who know what linux, gnu/linux or whatever you prefer is at all), means exactly what that page is trying to convey.
[06:09] <desrt> there is a very large group of people (ubuntu's intended target audience, basically) who grok "linux-based" but would "eh?" at "gnu/linux based"
[06:10] <Lathiat> ah but rms will hunt you down
[06:10] <desrt> it may be unfair that "linux" means what it means in the public consciousness... but that's what it means.  in any case, by any definition of the world "linux", it's no lie to say that ubuntu is linux-based.
[06:10] <desrt> *word
[06:10] <Burgundavia> Lathiat: smoothered by that beard of his
[06:10] <Lathiat> ;)
[06:14] <sid> Well there reference to it in all the install docs --> http://doc.ubuntu.com/ubuntu/install/i386/ch01s03.html
[06:14] <sid> But a large portion of people never read those. Some one a new user becomes intermediate with Ubuntu. They never learn what GNU is, or the idea of free software.
[06:14] <sid> s/Some one/So Once/
[06:15] <bddebian> sid: Well asking RMS wouldn't get you to Debian or Ubuntu either since they allow the evil non-free software
[06:15] <sid> right
[06:16] <desrt> sid; ubuntu isn't about lecturing users; by overt means or otherwise.
[06:16] <sid> Well he would say something like "I use Debian GNU/Linux, but I can't recommend it to others because they have non-free software on their servers"
[06:16] <sid> heh
[06:16] <desrt> ya.  it's called BIOS. :p
[06:16] <sid> desrt: I don't want Ubuntu to be able lecturing users.
[06:16] <sid> I just wish there was an issues page, that could help users understand better.
[06:17] <desrt> sounds like a lecture to me :)
[06:17] <bluefoxicy> Stallman is weird
[06:17] <desrt> i <3 stallman
[06:17] <sid> ie, why ffmpeg isn't in Ubuntu. Because there are so many patents surrounding it. And why they can't play drm'd music from their iPod etc.
[06:17] <bluefoxicy> rather than allow people to control stuff they created; he wants to allow people to control things others create.
[06:17] <desrt> we want him to come talk at cusec
[06:18] <desrt> ffmpeg _is_ in ubuntu and i _can_ play drm'd music from my (hypothetical non-existant) ipod :)
[06:18] <bluefoxicy> If you picked up a copy of gedit and wrote in a modification; then the GNOME team is now able to claim your modification must be released under their licensing terms, or else you are not allowed to distribute it.
[06:18] <bluefoxicy> Stallman says to not get yourself "trapped" by proprietary software that wants to "take away your rights" and "control you"
[06:19] <bluefoxicy> It's ironic that the GPL is a trap that aims to take away your rights and control you.
[06:19] <bluefoxicy> and that's all I'll say on that.
[06:19] <desrt> nobody ever said that it's public domain.  copyleft is just as evil as copyright
[06:19] <desrt> it just points in the opposite direction :)
[06:20] <bluefoxicy> yeah.  Copyright == you controlling your work; copyleft == you controlling others' work.  :)
[06:20] <sid> desrt: You can play music downloaded from the itunes store that was on your ipod?
[06:20] <sid> With Ubuntu
[06:20] <desrt> bluefoxicy; with traditional copyrighted software you wouldn't even be able to modify gedit in the first place
[06:20] <desrt> sid; ya
[06:20] <sid> desrt: how?
[06:20] <desrt> sid; there's some program called harmony or something
[06:21] <sid> desrt: That would violate the DMCA. And it would be illegal if you're an American.
[06:21] <desrt> it's broken a few times and they've fixed it again
[06:21] <desrt> i'm not an american
[06:21] <desrt> what's the DMCA?
[06:21] <bluefoxicy> desrt: this is true; but it's not evil of the creator of said software to do that
[06:21] <sid> Just like playing a DVD in GNU / Linux with libdvdcss is illegal in America.
[06:21] <desrt> well god bless america.  good thing i don't live there.
[06:21] <Burgundavia> we are straying off topic for -devel here
[06:22] <desrt> Burgundavia; very strongly.
[06:22] <sid> desrt: If there wasn an issues page you would know. ;)
[06:22] <Burgundavia> then I suggest we take it elsewhere
[06:22] <sid> Digital Millennium Copyright Act
[06:22] <Burgundavia> bluefoxicy: as for what you believe about the gpl, this is not the appropriate place to raise them
[06:22] <desrt> sid; i know.  i don't care.
[06:22] <sid> It's a act that makes it illegal to circumvent copyright protections schemes. ie DRM
[06:23] <Burgundavia> sid: thanks for your inquiry as to the gnu/linux vs linux debate. If you want to talk about the DMCA, please take it elsewhere
[06:24] <bluefoxicy> on closer examination, I simply don't have the "albany" font and OOo is substituting arial
[06:24] <bluefoxicy> this is a default font in an OOo template
[06:24] <bluefoxicy> desrt:  the devs come back to see wtf we're talking about and waste time reading the screen.
[06:24] <desrt> fair
[06:25] <bluefoxicy> desrt:  in non-dev channels, yes, it's completely retarded :)
[06:26] <bluefoxicy> at any rate why don't I have Albany and how do I rectify; and more importantly, should fonts that OOo expects to have around be installed by default?
[06:29] <bddebian> Gnight folks
[06:29] <tritium> night, bddebian
[06:29] <bddebian> Night tritium
[06:32] <Kaleo> hello girls and boys
[06:32] <desrt> good eve
[06:33] <bluefoxicy> hi pitti
[06:33] <desrt> pitti; stacksmashing detected in whiptail.  do you want to hear about it?
[06:33] <pitti> Good morning
[06:34] <bluefoxicy> desrt:  do you know what function?
[06:34] <desrt> nope.  i was hoping for some help, if anything
[06:34] <bluefoxicy> meh.  ProPolice used to blurt out the vulnerable function name, RHAT removed that when they pushed it into gcc mainline
[06:35] <bluefoxicy> (this is why pitti's crash reporter is going to be awesome)
[06:36] <jdub> elmo, Znarl, Spads: ping
[06:37] <jdub> oh man, i can't log into any of the machines now
[06:37] <jdub> heh
[06:38] <jdub> the canonical kthxbye ;)
[06:38] <jdub> if ever there was one
[06:39] <pitti> desrt: sure, if you can find out anything about it
[06:39] <desrt> jdub; what was your last day?
[06:40] <pitti> desrt: too bad that apport currently cannot extract stack traces :(
[06:40] <desrt> pitti; do you know of some switch i can throw to get some more info?
[06:40] <jdub> friday
[06:40] <dholbach> good morning
[06:40] <jdub> i'm just going to mail rt
[06:40] <desrt> dholbach; word.
[06:40] <pitti> hey dholbach
[06:40] <dholbach> hey desrt, hey pitti
[06:40] <dholbach> jdub: heya - how's genius looking? :)
[06:40] <desrt> you germans wake up early
[06:41] <jdub> dholbach: genius is looking like i can't upload it to my usual spot :)
[06:41] <dholbach> jdub: hu? where?
[06:41] <jdub> dholbach: people.ubuntu.com; no access atm ;)
[06:41] <dholbach> upload it to the archive!
[06:41] <dholbach>  !!!
[06:41] <jdub> well, there is that
[06:42] <jdub> can i pass it to your or ogra for ongoing maintenance?
[06:42] <dholbach> yeah
[06:42] <dholbach> i'm answering for ogra here ;)
[06:42] <jdub> haha
[06:42] <jdub> building it in pbuilder atm, will upload after that
[06:42] <dholbach> rock and roll
[06:43] <ajmitch> lucky ogra inherits another package
[06:43] <dholbach> he'll be delighted to add some more good educational software to his CDs
[06:43] <bluefoxicy> by the way, Tuesday is 8/08/6
[06:44] <jdub> dholbach: i'm glad you picked up on it for edubuntu, it didn't even occur to me that it would be useul there
[06:44] <desrt> pitti; newtCheckboxTreeAddItem() calls __stack_chk_fail()
[06:45] <dholbach> i'd need to play with it a bit, but to me it totally looked like being at the right place :)
[06:45] <bluefoxicy> desrt:   :)  Bingo.
[06:45] <bluefoxicy> desrt:  reproduced?
[06:46] <desrt> bluefoxicy; 100%
[06:46] <desrt> i get it when running module-assistant on vmware-player
[06:48] <bluefoxicy> desrt:  now the fun part, screw with it in gdb or elfsh and see if you can find a way to feed it a file and get it to give you a shell ;)
[06:49] <desrt> or i could just fix the bug
[06:49] <bluefoxicy> or that yes.  :)
[06:58] <bluefoxicy> pitti:  do you have a place for automated problem reports to go?
[06:58] <desrt> found the problem
[06:58] <pitti> bluefoxicy: right now, it's a manual user decision/task to create a bug  and attach the report
[06:58] <desrt> if you feed whiptail a string starting with a negative number then that number gets cast to unsigned
[06:58] <desrt> and becomes very very very large
[06:59] <bluefoxicy> pitti:  If you want to let the user set it to automatically send reports, you should probably com up with a separate back-end instead of creating a Launchpad bug
[06:59] <bluefoxicy> pitti:  I would suspect that such a thing would create a MASSIVE influx of bug reports (and duplicates-- every time something breaks), and it would be bad to dilute the bug tracker that way.
[07:00] <pitti> bluefoxicy: right, we need a separate db for automatic reports
[07:00] <pitti> bluefoxicy: that's something for edgy+n, though
[07:00] <Hobbsee> has anyone tried the new usplash yet?  says /dev/svgasomething not found.
[07:00] <pitti> bluefoxicy: the intent of the current system is to make the communication easier for people who already send us bugs about crashes
[07:00] <pitti> Hobbsee: I'm up to date and get the same old 640 by 400 as always
[07:01] <pitti> bluefoxicy: right, later we need to automatically find duplicates and such
[07:01] <Hobbsee> pitti: hmmm...okay
[07:01] <bluefoxicy> pitti:  Yes; I'd think a new Launchpad module would be best, which would indeed be a lot of work and not ready by Edgy.  I have some ides for that, which I've been working on for a while; I'm currently writing up a slide show presentation on that.
[07:01] <bluefoxicy> pitti:   Yes, duplicates and such are not easy; but I've come up with a technique that I believe will help a lot if you can't fully-auto it.
[07:05] <Hobbsee> pitti: ah, they released a new version between when i updated an hour and a half ago, to now
[07:09] <Hobbsee> pitti: from what to what?
[07:12] <pitti> Hobbsee: to latest edgy
[07:13] <Hobbsee> pitti: ahh :)
[07:13] <Hobbsee> 30.7kB/s download speed.  yay.
[07:14] <imbrandon> 30kB hehe i would cry
[07:14] <imbrandon> ;)
[07:14] <pitti> 355kB/s - hehe :)
[07:14] <imbrandon> pitti: yea thats about what i get from archive.u.c , 350 to 400
[07:14] <imbrandon> ;)
[07:14] <Hobbsee> pitti: it's the uni connection, i cant complain too much.
[07:15] <desrt> does someone have a few minutes to review and possibly upload a package for me?
[07:20] <Hobbsee> desrt: which package?
[07:20] <desrt> newt
[07:21] <desrt> do you have upload to main?
[07:21] <bluefoxicy> desrt:  if you just fixed a security hole make sure it gets back to upstream.
[07:22] <desrt> bluefoxicy; this isn't a security problem
[07:22] <desrt> just a plain old crashes
[07:22] <desrt> *crasher
[07:22] <Hobbsee> desrt: no.  according to my apt-cache, it isnt in ubuntu at all yet
[07:23] <desrt> Hobbsee; newt is the source package name
[07:23] <desrt> binary packages include libnewt0.52 and whiptail
[07:23] <Hobbsee> desrt: ahh.  i thought apt-cache search found source packages too, for some reason.
[07:23] <bluefoxicy> desrt:  What triggered the overflow; how far did it overflow; and where did the data come from?
[07:23] <desrt> ya.  so did i.  i just found out that that's not true :)
[07:23] <Hobbsee> i think my brain is being dulled by vaguelly listening to the current prac in here.
[07:24] <desrt> bluefoxicy; you pass an int to a function.  it then puts that many (constant) characters into a fixed-size buffer
[07:24] <desrt> bluefoxicy; that int can be very very large in some cases
[07:25] <bluefoxicy> desrt: hole was in libnewt; could any programs using libnewt possibly pass a string they got from a file or such?  i.e. in theory could someone trick a user into loading a file that would write some data from it into that buffer and go off the edge
[07:26] <desrt> the problem only happens when you ask a gauge to draw a negative percentage
[07:26] <desrt> if someone is calling that function they ought to verify that the value they pass it is sane
[07:26] <desrt> even still, i fixed the crash in two places to be extra safe
[07:26] <bluefoxicy> mm.
[07:27] <bluefoxicy> whatever. :p
[07:28] <bluefoxicy> I don't feel like arguing theory and gorey non-existent details.  It's fixed, it's fixed.
[07:30] <bluefoxicy> (come to think of it, I didn't ask the source of the characters; if they're internal to libnewt then yeah not a vulnerability for sure)
[07:34] <desrt> arf
[07:35] <bluefoxicy> narf ^o.o^
[07:35] <Lathiat> .look. at bugs.?
[07:36] <Hobbsee> Lathiat: no.  looking at bugs is illegal.  actually fixing bugs is a criminal offense.
[07:36] <Lathiat> thats why everyone does it right? RIGHT!?
[07:36] <Lathiat> its illegal must be fun woooooooooooo ;)
[07:36] <Hobbsee> Lathiat: what gives you the idea that people fix bugs?  :P
[07:37] <Lathiat> good intentions? ;p
[07:37] <desrt> https://launchpad.net/distros/ubuntu/+source/newt/+bug/55017
[07:37] <Ubugtu> Malone bug 55017 in newt "whiptail --gauge crashes when given negative numbers" [Untriaged,Unconfirmed]
[07:37] <desrt> if anyone cares to look :p
[07:38] <Lathiat> desrt: easy fix
[07:38] <Lathiat> desrt: dont give it negative numbers ;)
[07:38] <desrt> Lathiat; the problem is taht programs pipe their output to it
[07:38] <bluefoxicy> Hobbsee: "But when a long Train of Abuses and Usurpations, pursuing invariably the same Object, evinces a Design to reduce them under absolute Despotism, it is their Right, it is their Duty, to throw off such Government, and to provide new Guards for their future Security."
[07:38] <Lathiat> see im fixing bugs already :)
[07:38] <Lathiat> desrt: ;p
[07:38] <bluefoxicy> Hobbsee:  ^^^ Why people fix bugs
[07:38] <desrt> and one of the outputs was a big line that ended with a kernel version
[07:38] <desrt> and the -686 wrapped to the next line
[07:39] <Lathiat> heh
[07:39] <Hobbsee> Lathiat: haha
[07:39] <Lathiat> awesome
[07:39] <Hobbsee> bluefoxicy: scary.
[07:39] <bluefoxicy> Hobbsee:  US declaration of independence
[07:40] <bluefoxicy> it means that people who have the power to correct a wrongful situation also have the responsibility to correct said wrongful situation
[07:40] <Hobbsee> bluefoxicy: ah, right.
[07:40] <Hobbsee> hi dholbach!
[07:40] <desrt> dholbach could upload for me!
[07:40] <dholbach> hey Hobbsee
[07:40] <Hobbsee> hehe
[07:40] <desrt> hi dholbach :)
[07:40] <dholbach> desrt: what is it? :)
[07:41] <desrt> https://launchpad.net/distros/ubuntu/+source/newt/+bug/55017
[07:41] <TheMuso> Hobbsee: Neither do I.
[07:41] <Ubugtu> Malone bug 55017 in newt "whiptail --gauge crashes when given negative numbers" [Untriaged,Unconfirmed]
[07:41] <dholbach> desrt: i don't upload no kernel :)
[07:41] <bluefoxicy> your diff scares me
[07:41] <bluefoxicy> it has ++ lines
[07:41] <bluefoxicy> like a diff of a diff
[07:41] <desrt> it's a debdiff
[07:41] <desrt> and it contains a patch
[07:41] <bluefoxicy> ah
[07:41] <bluefoxicy> oh right.  that confuses me.
[07:42] <Hobbsee> bluefoxicy: debdiff's are good.
[07:42] <Hobbsee> bluefoxicy: learn to like them
[07:42] <desrt> bluefoxicy; they're the de facto way to get someone to do an upload for you
[07:42] <Hobbsee> desrt: better than source.
[07:42] <bluefoxicy> yes I fed one to mdz and pitti
[07:42] <desrt> source is so big :)
[07:43] <desrt> man.  le tigre.
[07:43] <desrt> who took the bomp?
[07:44] <StevenK> The only thing I dislike over debdiffs is the diff of a diff.
[07:44] <desrt> StevenK; imagine, then, diffing the two .diff.gz files
[07:44] <StevenK> Done that.
[07:44] <desrt> +++
[07:44] <ajmitch> desrt: interdiff is a great tool, really
[07:44] <desrt> it's enough to make your modem hang up
[07:45] <desrt> ajmitch; first time i tried to use debdiff i didn't have interdiff installed.  that was lame :)
[07:45] <Hobbsee> hehe
[07:45] <StevenK> desrt: Only if its a crappy one that doesn't understand escapes sequences.
[07:45] <desrt> StevenK; joke, k plz thx
[07:46] <StevenK> desrt: I have seen some that will see '+++' in an input stream and disconnect.
[07:46] <desrt> my friend has the modern-day equivalent problem with his ISP-provided router
[07:46] <desrt> if you /msg him a DCC SEND someverylongstringlikethis on irc he disconnects
[07:46] <StevenK> Heh
[07:46] <dholbach> hahahaha, I didn't have  dbs  installed - my machine was sane :)
[07:47] <Hobbsee> desrt: gah.  dont joke about that.
[07:47] <HrdwrBoB> desrt: you don't have to msg it
[07:47] <HrdwrBoB> you just say it
[07:47] <desrt> well, at the start of a line
[07:47] <desrt> that's still a privmsg
[07:48] <tritium> desrt: ask ubotu about dcc
[07:48] <Hobbsee> desrt: actually, i'm suprised you didnt disconnect anyone doing that.
[07:48] <desrt> dholbach; eh?
[07:48] <desrt> Hobbsee; fairly sure it has to be at the start of the line
[07:48] <dholbach> desrt: the dbs package
[07:48] <desrt> Hobbsee; i don't think that's necessary
[07:48] <StevenK> Muahaha
[07:49] <Hobbsee> desrt: could be interesting.  /me tests in -ops
[07:49] <desrt> asshat :p
[07:49] <Hobbsee> [15:49]  <Hobbsee> desrt: they're just clones - they got redirected here from #ubuntu the last time someone ran the exploit
[07:49] <Hobbsee> heh
[07:49] <desrt> ah
[07:50] <Hobbsee> okay, that works anywhere in the line.
[07:50] <desrt> didn't work for me, tho
[07:50] <TheMuso> Hobbsee: What was the result?
[07:50] <Hobbsee> desrt: means there's no people with the dodgy router brands then
[07:50] <Hobbsee> TheMuso: see -bugs
[07:51] <Hobbsee> desrt: in here, anyway
[07:51] <desrt> nice
[07:51] <desrt> my router is vuln to that bug, but i don't use it as a router
[07:51] <desrt> wifi access point only
[07:55] <dholbach> desrt: uploaded - do you care enough to send it upstream?
[07:56] <desrt> dholbach; it looks vaguely orphaned in debian
[07:56] <desrt> dholbach; but i'll drop a mail to the guy who did the last NMU
[07:56] <desrt> dholbach; thanks
[07:56] <dholbach> oh, i was more referring to fedora (seems to be a project of them) - but to send it to debian is a good thing too
[07:56] <desrt> :)
[08:00] <desrt> dholbach; will you close the bug or should i?
[08:01] <dholbach> desrt: go ahead :)
[08:02] <desrt> crikey thunder!
[08:05] <desrt> bah.  the email address of the redhat guy bounces
[08:05] <desrt> bed time.  cheers.
[08:06] <dholbach> good night desrt and thanks for the fix
[08:06] <desrt> thanks for the rapid upload :)
[08:06] <dholbach> anytime - if i hear any complaints, i'll wake you up ;)
[08:06] <desrt> unlikely.
[08:06] <dholbach> :)
[08:06] <desrt> in any case i'll be awake again in almost exactly 8 hours :)
[08:07] <dholbach> enjoy
[08:07] <desrt> cha.
[08:38] <dholbach> ogra*: jdub will upload genius soonish and asked us to take over maintenance
[08:40] <ogra> yup, saw it in my backlog :) thanks ! :)
[08:56] <ogra> /var/lib/dpkg/info/usplash.postinst: line 40: /dev/fd/62: No such file or directory
[08:56] <ogra> Keybuk, whats supposed to create that fd ?
[08:57] <dholbach> ogra: i think mjg59's newest upload takes care of that
[08:57] <dholbach> ogra: cf edgy-changes
[08:57] <ogra> ah, k so my udev isnt missing something, thanks :)
[09:00] <Keybuk> ogra: /dev/fd should be a symlink to /proc/self/fd
[09:01] <ogra> Keybuk, there is no proc in a non booted ltsp chroot
[09:01] <Keybuk> ogra: then lots of things will be broken
[09:01] <ogra> its mounted on boot on the client
[09:01] <Keybuk> right, but you need /proc to upgrade it
[09:02] <ogra> and temporary during chroot creation
[09:02] <ogra> hmm ... cant it have just some error catching ?
[09:02] <ogra> i dont think its needed by the package during package install time ... only at runtime, no ?
[09:03] <ogra> mjg59, ^^ ?
[09:03] <Keybuk> ogra: I doubt that's the only thing that will break because /proc isn't mounted
[09:03] <Keybuk> little things stop working
[09:03] <Keybuk> like ps, pidof, shells, etc.
[09:03] <ogra> Keybuk, th ethin client mounts proc
[09:04] <Keybuk> yes, but package postinsts are entirely permitted to need /proc, because they expect a POSIX system
[09:04] <ogra> but if i upgrade the client chroot there is no proc ....
[09:04] <Keybuk> then that's a bug, you need to mount /proc while you upgrade the client chroot
[09:04] <ogra> hmm ... then i need a wrapper :/
[09:04] <Keybuk> /proc/$PID (and thus /dev/fd -> /proc/self/fd) is used in a few places
[09:04] <Keybuk> and many things use pidof/ps
[09:07] <ogra> yes, i know why we use it in the build script ... i just havent had probs yet when upgrading
[09:07] <ogra> its the first package i see requirig it
[09:08] <Keybuk> openssh-server does
[09:08] <ogra> i dont use the server in th echroot :)
[09:09] <bluefoxicy> hmm.  I wonder if my presentation needs polish.  Probably.
[09:10] <bluefoxicy> Not that it matters, I'm not nutty enough to try to sneak into the next developer's summit; and there's no friggin' way I'd ever actually present.  You know.  In front of a group of like, real, live people.
[09:11] <sivang> morning
[09:12] <bluefoxicy> hi... Mr. *
[09:21] <Hobbsee> hi all
[09:25] <pitti> desrt: thanks for the newt patch
[09:25] <pitti> desrt: was this an upstream or Debian-inherited bug?
[09:28] <caleb-> seb128: About edgy bug #54956. Most GTK immodules can not be fixed by rebuild only. Default installation is /usr/lib/gtk-2.0/immodules/, but debian packages used to change to /usr/lib/gtk-2.0/2.4.0/immodules/. So every GTK immodule package will need a new *.diff.gz for the 2.4.0 -> 2.10.0 transition.
[09:28] <Ubugtu> Malone bug 54956 in gtk+2.0 "Wrong path name 2.10.0, should be 2.4.0 for back-compatibility" [Untriaged,Rejected]  http://launchpad.net/bugs/54956
[09:28] <seb128> caleb-: and?
[09:28] <pitti> Kamion: ok, so we need to get off 6 MB from powerpc and 3 from amd64/i386; that'll kill pt and ru for powerpc (pt is a bit unfortunate, but we can't help it)
[09:28] <Kamion> de and ja are further down the list for powerpc
[09:28] <bluefoxicy> I'm gonna sleep, night all.
[09:28] <caleb-> seb128: and maintainer have to do more work for backporting.
[09:29] <pitti> Kamion: but they aren't in the current seeds
[09:29] <Kamion> seems like they should be first to go ...
[09:29] <pitti> Kamion: right, but powerpc has zh es bn hi ar xh pt ru ATM
[09:29] <pitti> Kamion: did you already took some away since yesterday?
[09:29] <pitti> s/took/take/
[09:29] <seb128> caleb-: I don't get your issue, I fixed those packages when updating them, no?
[09:29] <Kamion> I'm updating to check
[09:29] <seb128> caleb-: I've you looked at the uploads or that's just random comment?
[09:30] <Kamion> pitti: read the live seed again
[09:30] <pitti> Kamion: argh, my bad
[09:30] <Kamion> there's a stanza which affects only some architectures, which I think you missed
[09:30] <pitti> Kamion: right, that'll give us exactly 6 MB; I hope it'll be just enough
[09:31] <caleb-> seb128: OK. I recheck them again.
[09:31] <bluefoxicy> hobbsee@hobbsee:~$ ./exploit pitti --steal-brain
[09:31] <pitti> !
[09:31] <Hobbsee> hehe
[09:31] <Kamion> pitti: ok, thans
[09:31] <Kamion> +k
[09:32] <pitti> Kamion: if this will still overflow by a few KB, would it hurt much to do yet another image?
[09:32] <Kamion> pitti: not a problem
[09:32] <Kamion> pitti: have you approved the new kernel already?
[09:32] <pitti> Kamion: I hoped to get hoary and breezy, too
[09:32] <pitti> Kamion: but if we need it now, I'll split the USN
[09:33] <Kamion> well, it's either now or it's not in the point release
[09:33] <Kamion> I don't actually mind which
[09:33] <pitti> ok, then let's do it now
[09:34] <pitti> Kamion: what do you think about cups 1.2.2? something for the CD, or rather not? (it's in the dapper queue, mdz approved the upload)
[09:35] <Kamion> printing has been a major bugbear with dapper.0; if this stands a chance of fixing several high-profile issues then I'm all for it
[09:36] <pitti> yes, it does
[09:36] <Kamion> need to make sure it's tested before release though
[09:36] <caleb-> seb128: They will work well in edgy, but will fail when backporting to dapper.
[09:36] <pitti> Kamion: well, we only tested it in edgy so far
[09:36] <caleb-> seb128: dapper can not recognize those GTK immodules in 2.10.0
[09:36] <pitti> Kamion: (well, of course I tested it in dapper, too, but only me)
[09:41] <seb128> caleb-: those are edgy uploads, so everything is fine
[09:41] <seb128> caleb-: no need to backport that on dapper
[09:42] <seb128> caleb-: packages are made for current versions, if backport doesn't work that's something for the backport-team
[09:43] <pitti> Kamion: dapper live seed updated
[09:44] <pitti> Kamion: with a potentially new OOo it'll be a moving target anyway
[09:44] <ogra> you change the daper seeds ????
[09:44] <ogra> *dapper
[09:44] <pitti> ogra: removed langpacks to fix overflow
[09:44] <caleb-> seb128: OK, I wll discuss with backport-team. Thank you. :-)
[09:44] <ogra> you know that could make edubuntu explode ?
[09:44] <seb128> caleb-: np
[09:45] <pitti> ogra: sure, we might have to remove some langpacks from edubutun, too
[09:45] <ogra> erm
[09:45] <ogra> the install CD only has en
[09:45] <ogra> if that grew we're screwed
[09:45] <pitti> ogra: ubuntu installs are okay
[09:45] <pitti> ogra: they didn't seem to have grown significantly
[09:45] <ogra> i'm talking abour edubuntu with 699MB
[09:45] <ogra> *about
[09:46] <Kamion> ogra: stop panicking, Edubuntu dapper still has different seeds from Ubuntu dapper
[09:46] <Kamion> pitti changing Ubuntu dapper seeds (which is FINE, stop PANICKING :-)) doesn't affect Edubuntu
[09:46] <ogra> Kamion, but the same package contents ...
[09:46] <Kamion> yes, Edubuntu dapper may have to be changed somehow
[09:46] <ogra> if the packages grew it will explode
[09:46] <Kamion> it had very few language packs though
[09:46] <ogra> exactly
[09:46] <Kamion> and it's mostly language packs that have grown
[09:47] <Kamion> ogra: welcome to life
[09:47] <pitti> Kamion: you have both gnome and KDE -en, right?
[09:47] <Hobbsee> Kamion: if you're dealing with removing packages from the archive/cds/whatever, feel free to remove kdelibs-bin and amarok-arts from the repositories.
[09:47] <ogra> heh, we never had a pointrelease before :)
[09:47] <Kamion> Hobbsee: please file a bug with ubuntu-archive subscribed if there isn't one already
[09:47] <pitti> ogra: gnome+kde+rest -en grew by 2085918 bytes
[09:47] <Hobbsee> Kamion: right.  one bug for two packages, or one bug for each package?
[09:48] <ogra> pitti, might aready be to much ... i'll ave to check
[09:48] <Kamion> pitti: edubuntu? yes
[09:48] <Kamion> pitti: only en on alternate, but loads on desktop
[09:48] <pitti> Kamion: sorry, that question should have gone to ogra
[09:48] <Kamion> edubuntu desktop will be dead easy to shrink
[09:49] <ogra> yes ...
[09:49] <ogra> but install will get tricky
[09:49] <ogra> i wouldnt want to drop any app in a pointrelease
[09:49] <Kamion> it seems to me that language-pack-kde-en could be removed without much badness
[09:49] <ogra> contents shouldnt differ etc ...
[09:50] <Kamion> it's not affecting the desktop, only a few apps; we're probably carrying a lot of KDE desktop translations in there that aren't used in Edubuntu
[09:50] <ogra> i'm not sure kdeedu will like that
[09:50] <pitti> ^ this would buy you 3 MB
[09:50] <Kamion> it's -en for goodness' sake!
[09:50] <Kamion> surely it will just fall back to C and all will be well ...
[09:50] <ogra> we can try ...
[09:50] <Riddell> it will yes
[09:51] <Kamion> and even if a few translations are a bit wonky, that seems ok if it's just kdeedu
[09:51] <Kamion> pitti: freaks translating to en_EVERYTHING I guess :-/
[09:51] <pitti> C -> en_US translation should be 95% identical, and those few en_GB strings shouln't be so big...
[09:51] <Kamion> losing en_GB from kdeedu on edubuntu is not a big deal
[09:52] <jdub> pitti: en_ZA is pretty big, with all that "off" -> "orf" and so on.
[09:52] <Kamion> mvo: how does language-selector decide which sets of language packs to install?
[09:52] <pitti> jdub: right, and 'Welcome' -> 'Yo dude!'
[09:53] <pitti> ^ for en_AU
[09:53] <pitti> hey kagou
[09:53] <kagou> hey pitti !
[09:54] <kagou> pitti: what's up ?
[09:54] <mvo> Kamion: you mean if it should install "-kde", "-gnome"- packs? that is detected via the installed packages
[09:55] <Kamion> mvo: so if language-pack-kde-en isn't installed on Edubuntu any more, then it won't know to install any language-pack-kde-*?
[09:55] <nags> G0SUB, as part of Google SoC - Prashanth Mohan has done these two work...Evolution calendar automation - http://people.freedesktop.org/~prashmohan/evolution-calendar-low.avi and http://people.freedesktop.org/~prashmohan/jhbuild-screencast-low.avi - Jhbuild / Tinderbox - LDTP integration
[09:56] <pitti> mvo: it should detect that it's missing and offer to complete language support, right?
[09:56] <Kamion> pitti: wouldn't want to offer to install language-pack-kde-* on Ubuntu
[09:56] <Kamion> or -gnome-* on Kubuntu
[09:56] <pitti> well, if you have the 'other' apps installed, it will AFAIK
[09:56] <mvo> Kamion: it will detect missing langpacks by checking if key-dependencies are installed and offer to install them
[09:57] <Riddell> presumably it test for kdelibs/some gnome lib being installed, mvo?
[09:57] <Kamion> mvo: aha, I should go look at the source then
[09:57] <mvo> Riddell: yes
[09:57] <ogra> then its fine
[09:57] <mvo> Kamion: it stopped working for you?
[09:57] <Kamion> mvo: no, just checking that the change discussed above won't make language-selector go wonky
[09:57] <ogra> mvo, no, but i'll likely hve to drop the kde-en packs from edubuntu
[09:58] <mvo> ogra: that should be fine, on the next start of language-selector it should come up with a dialog offering to install them
[09:58] <ogra> (in the dapper pointrelease)
[09:58] <mvo> we did that with firefox locales too
[09:58] <ogra> fine :)
[09:58] <mvo> but obviously it should be tested :)
[09:58] <mvo> but I'm pretty confident
[09:58] <Kamion> mvo: apart from the minor detail that kdelibs4c2 does not exist in dapper
[09:58] <Kamion> which appears to be your key package for language-pack-kde-*
[09:58] <mvo> *gar*
[09:58] <Hobbsee> Kamion: use kdelibs4c2a instead
[09:59] <Kamion> can we use a binary package whose name won't change as often?
[09:59] <Kamion> kdelibs-bin?
[09:59] <ogra> cant we put a wildcard in ?
[09:59] <ogra> kdelibs*
[09:59] <Kamion> oh, no, not kdelibs-bin
[09:59] <Hobbsee> Kamion: kdelibs-bin is going to die.
[10:00] <Kamion> ogra: smallest change possible for -updates, can be fixed better for edgy
[10:00] <Hobbsee> Kamion: dont depend anything on it, or i'll have to change it again.
[10:00] <ogra> yep
[10:00] <pitti> kdelibs-data ?
[10:00] <Kamion> kdelibs-data looks good
[10:00] <Hobbsee> oh, wait, not sure on dapper.
[10:00] <pitti> ^ dependency of kdelibs4c*
[10:00] <mvo> pitti: sounds good
[10:00] <Kamion> Hobbsee: yeah, was just reading the package list a bit too quickly
[10:00] <pitti> Hobbsee: in dapper, too
[10:01] <Hobbsee> pitti: my statement was more i wasnt sure if we were killing off kdelibs-bin in dapper too - we certainly did in edgy.
[10:01] <Kamion> Hobbsee: we're not killing off any packages in dapper
[10:01] <Kamion> short of being sued
[10:01] <Hobbsee> Kamion: heh
[10:01] <pitti> Hobbsee: ah, right; indeed in dapper kdelibs4c2a depens on -bin
[10:01] <pitti> but let's use -data for edgy/dapper consistency
[10:02] <Hobbsee> pitti: yeah.  it's dying. lovely circular dependancy. i just havent filed a bug report getting it out of the archive yet :P
[10:03] <mvo> Kamion: I will do a upload with that fix to dapper-updates now
[10:04] <Hobbsee> pitti: the circular dependancy is still in dapper.  guess we'd better keep it in then
[10:04] <Kamion> mvo: while you're at it, in edgy s/libgnome2-0/libgnome2-common/g would be good too, for similar reasons
[10:05] <Kamion> don't need to change that in dapper though
[10:06] <mvo> Kamion: ok
[10:10] <pitti> zul: ping
[10:15] <Kamion> then I can turn edgy builds back on
[10:17] <Kamion> mvo: don't you need to change LanguageSelector/gtk/GtkLanguageSelector.py too?
[10:17] <Kamion> ./LanguageSelector/LangCache.py:        ("kdelibs-data", "language-pack-kde-"),
[10:17] <Kamion> ./LanguageSelector/gtk/GtkLanguageSelector.py:        ("kdelibs4c2", "language-pack-kde-"),
[10:21] <Hobbsee> Kamion: filed those two removal bugs.  thanks :)
[10:22] <Kamion> mdz: -DISTRIB_DESCRIPTION="Ubuntu 6.06 LTS"
[10:22] <Kamion> +DISTRIB_DESCRIPTION="Ubuntu 6.06.1 LTS"
[10:22] <Kamion> mdz: this is ok, right?
[10:22] <mvo> Kamion: *cry* right
[10:22] <mvo> Kamion: please reject the last upload
[10:22] <mdz> Kamion: yes
[10:23] <mdz> Kamion: do you need anything from me before I sleep?
[10:24] <Hobbsee> mdz: fixes for all the bugs in the archive.  :P have a good sleep :)
[10:24] <Kamion> mdz: no, I don't think so - sleep well
[10:24] <Kamion> mvo: done
[10:24] <Kamion> I did wonder about that one :)
[10:26] <mvo> Kamion: it was a left-over from the late addition of the Qt frontend and not properly cleaned up
[10:31] <caleb-> seb128: tamil-gtk2im also needs rebuild for 2.4.0 -> 2.10.0. Those rebuilded immodules all work fine in edgy. Thank you. :-)
[10:32] <seb128> caleb-: I've updated it yesterday but it had a build issue, it's on my "to fix" list
[10:32] <seb128> caleb-: np ;)
[10:40] <nags> heno, http://people.freedesktop.org/~prashmohan/evolution-calendar-low.avi
[10:41] <nags> heno, http://people.freedesktop.org/~prashmohan/jhbuild-screencast-low.avi
[10:41] <nags> heno,  Aspart of Google SoC - Evolution calendar automation and Jhbuild / Tinderbox - LDTP integration
[10:41] <nags> heno, will ping you on Monday, going out of town...
[10:42] <heno> nags: ok, I'll look at those in the meantime, thanks
[10:42] <nags> heno, sure :)
[10:44] <mvo> Kamion: uploaded again, this time (hopefully) correct
[11:03] <mdke> pitti:
[11:04] <mdke> RicardoPerez has reported a problem with langpacks
[11:04] <mdke> 9:58:22 < RicardoPerez> mdke: I think the langpacks generation procedure is using obsolete Rosetta's templates
[11:04] <mdke> can you help with that?
[11:04] <RicardoPerez> mdke: thanks a lot. I didn't ask him yet because he appears away ;)
[11:05] <mdke> oh yeah, my bad
[11:14] <pitti> mdz: hm, that rather sounds like problem for carlos
[11:15] <pitti> erm, mdz: ^ please ignore
[11:15] <pitti> RicardoPerez, mdz: hm, that rather sounds like problem for carlos
[11:15] <pitti> RicardoPerez: so Rosetta doesn't use dapper's current template?
[11:15] <pitti> +s
[11:15] <RicardoPerez> pitti: hi, I don't know if the problem is in the Rosetta or in the langpack generation...
[11:16] <RicardoPerez> pitti: ok, that's right
[11:16] <pitti> RicardoPerez: Rosetta does the msgmerge between .po data and pot files
[11:16] <RicardoPerez> pitti: mmmm, better said, the langpack generation isn't use the latest Rosetta's templates
[11:17] <RicardoPerez> pitti: for example, the gnome-panel-2.0 template is empty in Rosetta, but has full of translated strings in the .mo file installed in my system
[11:17] <pitti> RicardoPerez: but you are sure you looked at dapper's templates, not at edgy's?
[11:17] <RicardoPerez> pitti: absolutely. I'm looking at the dapper's templates
[11:17] <pitti> hm, let's wait until carlos arrives
[11:17] <RicardoPerez> pitti: https://launchpad.net/distros/ubuntu/dapper/+source/gnome-panel/+pots/gnome-panel-2.0/es_ES/+translate
[11:18] <RicardoPerez> pitti: I'm writing now a post for ubuntu-translators with all the details
[11:20] <RicardoPerez> pitti: The post is in the mailing list now: https://lists.ubuntu.com/archives/ubuntu-translators/2006-August/000745.html
[11:20] <pitti> thanks
[11:20] <RicardoPerez> pitti: thanks to you, hope this helps
[11:20] <pitti> so, the very latest (yesterday's) dapper langpacks are wrong?
[11:21] <RicardoPerez> pitti: exactly. the problem appears with the lastest langpack updates
[11:21] <RicardoPerez> pitti: until yesterday, there was no problem
[11:23] <seb128_> pitti: carlos in on VAC this week
[11:23] <Kamion> try danilos
[11:25] <RicardoPerez> pitti: can you rebuild the es_* langpacks again to ensure that you are using the latest templates from Rosetta?
[11:28] <pitti> RicardoPerez: can you please check out today's daily langpacks from my people.u.c. page, around 1300 UTC?
[11:28] <RicardoPerez> pitti: ok, sure... are your daily langpacks working now? I remember there was an issue with that...
[11:29] <pitti> RicardoPerez: yes, the apt-ftparchive bug has been worked around
[11:29] <pitti> RicardoPerez: and I just re-enabled dapper langpack building
[11:29] <pitti> RicardoPerez: (I stopped dapper until we got the rebased packages into the archive)
[11:29] <RicardoPerez> pitti: ok, superb. is this the correct apt line? deb http://people.ubuntu.com/~pitti/langpacks/daily/dapper-updates ./
[11:30] <pitti> yep
[11:30] <RicardoPerez> pitti: ok, I'll wait the updates, I'll try it at 1300 UTC and I'll tell you
[11:30] <RicardoPerez> pitti: thanks a lot
[11:30] <hanswerner> Hey there :)  Is there a way to get fonts working in Edgy-X?
[11:33] <hanswerner> I just updated because I needed a new QT4 for developing - Fonts a screwed but I think it's a known problem. Can I help fixing it or is there a way to get `em running again?
[11:39] <hanswerner> no way?
[11:42] <mvo> infinity: can you kick the python-apt build once the new apt (0.6.45ubuntu1) has build please?
[11:43] <thom> is anyone else having problems connecting to security. or is it just me?
[11:44] <pitti> thom: hm, doesn't seem to work for me either
[11:44] <tepsipakki> thom: it's been sluggish for a couple of days..
[11:44] <elmo> security's currently running into bandwidth limits, it'll be slow, but should work
[11:45] <doko> Kamion: OOo ping
[11:45] <Kamion> doko: hi
[11:46] <Kamion> doko: have you got much in the way of test reports from your dapper-proposed binaries?
[11:46] <doko> Kamion: no feedback yet
[11:46] <Kamion> that's awkward
[11:46] <Kamion> how about I build alternate install CDs with -proposed for a bit?
[11:46] <Kamion> can't fudge desktop CDs so easily, but that would get us some testing at least
[11:47] <doko> Kamion: that would be very nice
[11:47] <doko> is there a way to determine the delta in size for the new CD's? before building them?
[11:49] <Kamion> there is, but it's probably less effort just to build the alternate install CD and find out
[11:49] <Kamion> which I'm doing now
[11:50] <Kamion> I mean you can sum all the Size fields by hand and do arithmetic
[11:50] <doko> hmm, ok, I'll wait :)
[11:51] <Kamion> in fact, not necessarily too evil to do in shell ...
[11:51] <pitti> doko: I have such a script for the language packs, should be trivial to adapt for other packages
[11:51] <doko> ohh, nice, please email
[11:52] <pitti> doko: http://people.ubuntu.com/~pitti/bzr/langpack-o-matic/langpacksize
[11:55] <Kamion> well, the difference in the total size of all the packages in dapper-proposed versus their corresponding packages in dapper-updates/dapper is < 2MB
[11:56] <Kamion> we'll see in a moment what that maps to in terms of CD size
[11:56] <doko> which is acceptable?
[11:56] <Kamion> we'll see ...
[11:56] <Kamion> depends where the bulk of the size increase is, really
[11:56] <Kamion> 2MB would be a bit much
[11:56] <Kamion> (for edubuntu)
[11:56] <doko> pitti: well, I'd need to compare the latest of dapper{,-security,-updates} with -proposed
[11:57] <pitti> doko: you can specify a Packages.gz file
[11:57] <pitti> doko: still, the script is very langpack specific
[11:58] <doko> pitti: yes, but OOo is in -security, ia32-* are in -security and -updates, so I have to know where to look.
[11:58] <doko> not everything is as easy as language packs ;-)
[11:58] <Kamion> oh, meh, I was running the wrong image build
[11:58] <Kamion> you'll have to wait a bit longer :-/
[12:11] <Kamion> anyone know of a quick tool to deduplicate a Packages file (i.e. take only the highest version of each)
[12:13] <mjg59> Hm.
[12:13] <mjg59> Systems /should/ have a /dev/fd, right?
[12:14] <StevenK> mjg59: Its a symlink to /proc/self/fd here at least.
[12:14] <Nafallo> looks like it. atleast my systems has.
[12:17] <mjg59> But some people seem to be lacking it
[12:17] <ogra> mjg59, i'm lacking it in the ltsp chroots on upgrades ...
[12:18] <ogra> there is no proc mounted at that point
[12:18] <Nafallo> mv ogre some\ people
[12:18] <Nafallo> ;-)
[12:19] <Nafallo> baah, ogra even. ogre is my server.
[12:19] <ogra> is it really needed in the postinst ?
[12:19] <ogra> Nafallo, ltsp has plenty of users
[12:24] <Kamion> yes, /proc is needed in postinsts, in general
[12:24] <Kamion> as Scott explained earlier
[12:24] <Kamion> you might have been lucky before, but now you have to deal. :-)
[12:30] <ogra> thats very sad ... because it takes the ease of "sudo chroot /opt/ltsp/i386/ apt-get dist-upgrade" away ... :/
[12:30] <pitti> ogra: I have /proc mounted in all my chroots automatically (in fstab)
[12:30] <pitti> that works pretty well
[12:31] <ogra> pitti, its not needed, /proc will be mounted during the client boot
[12:31] <pitti> ogra: yeah, but I don't boot my chroots :)
[12:31] <ogra> and its mounted/unmounted by the script that creates it ...
[12:32] <ogra> my prob is that i will have to write a ltsp-update script, which has to be documented and which users need to be aware of ...
[12:32] <heno> doko: there were some reports of serious accessibility problems with the OOo in edgy: https://lists.ubuntu.com/archives/ubuntu-accessibility/2006-July/000667.html but that could be a more general Gnome problem. We are trying to work that out
[12:32] <ogra> the last two releases this worked with just apt-get
[12:34] <doko> heno: I didn't look at accessability problems yet. is this i386?
[12:35] <heno> doko: yes
[12:35] <heno> and bleeding edge edgy
[12:36] <heno> OOo in dapper seems less bad (though I personally get crashes when AT-SPI is on)
[12:36] <doko> heno: dapper, or dapper + dapper-proposed?
[12:37] <Kamion> doko: preliminary figures suggest that amd64 shrinks by 1.7MB, i386 grows by 250KB, and powerpc grows by 1.9MB on adding dapper-proposed
[12:37] <heno> doko: haven't tested -proposed
[12:37] <Kamion> doko: I suspect there's some noise in those figures though
[12:38] <Kamion> definitely noise, various packages seem to have randomly gone missing from the .list
[12:38] <doko> amd64 shrinks? strange
[12:39] <mjg59> ogra: Ngh.
[12:39] <mjg59> ogra: Yes, it's needed.
[12:39] <mjg59> Bits of shell just don't work unless it's there.
[12:39] <Kamion> doko: I suspect it's got more to do with:
[12:39] <Kamion> -/pool/main/s/samba/samba_3.0.22-1ubuntu3.1_amd64.deb
[12:39] <Kamion> and stuff like that
[12:40] <Kamion> ah, there's oversizing, damn
[12:41] <heno> doko: was the 2.0.2 that was in Edgy until recently the same as that in dapper or did it have lots of patches from 2.0.3?
[12:42] <doko> heno: we had no 2.0.2 uploads in edgy
[12:43] <heno> doko: I could have sworn the 'About OOo' screen said 2.0.2 a few days ago, but I could be wrong :)
[12:43] <ogra> mjg59, ok, then  cant do anything ...
[12:43] <Kamion> heno: dapper package carried over
[12:43] <mjg59> ogra: Mm?
[12:44] <heno> Kamion: right, that's what I figured
[12:44] <ogra> mjg59, if its needed by the postinst i cant do anything against it ... i just wondered why ... i'd expect the fd to be used at runtime but not at installation time
[12:44] <mjg59> ogra: The postinst uses subshells
[12:45] <ogra> ah, k
[12:46] <mjg59> Ok
[12:47] <heno> So that points to some AT-SPI problems in Gnome 2.15 because that dapper OOo packages works fine on dapper, while both the old and new fail on edgy
[12:48] <Kamion> pitti: ok, turns out the alternate install CDs are rather oversized too. I'm turning off debian-cd's own oversizing protection in order that we can easily se by how much
[12:48] <Kamion> see
[12:48] <doko> heno: did you check 2.0.3 from dapper-proposed as well?
[12:48] <pitti> Kamion: the report doesn't help for that? (CD 2 will only be filled with n bytes)
[12:49] <Kamion> pitti: it does, but it's tedious
[12:49] <heno> doko: no, do I just add -proposed to the sources list? are there any instruction on-line?
[12:49] <Kamion> much easier to see the results from a single number in one place
[12:49] <pitti> right
[12:49] <heno> sorry, I've been away ...
[12:52] <doko> heno: see my recent mail to -users, and -devel: that will work: deb http://archive.ubuntu.com/ubuntu dapper-proposed main
[12:52] <heno> thx
[01:17] <heno> doko: the -proposed version speaks loud and clear :)
[01:17] <doko> so it looks like a at-spi problem
[01:18] <heno> yep
[01:18] <heno> any advice on how to dig further in that?
[01:18] <heno> I can poke around with at-poke for a start I guess
[01:30] <gnomefreak> what did i miss :( i thought usplash was gonna read Xorg.conf?
[01:30] <mjg59> No
[01:30] <gnomefreak> how do i change it so i can boot?
[01:31] <gnomefreak> its telling me wrong res. black screen with flashing monitor thing
[01:31] <gnomefreak> after usplash is finished
[01:32] <mjg59> Does usplash itself work fine?
[01:32] <gnomefreak> mjg59: yes right at the end where it would give me login it dies
[01:32] <mjg59> Right
[01:32] <mjg59> What drivers are you using for X?
[01:33] <gnomefreak> nv
[01:33] <mjg59> Not nvidia?
[01:33] <gnomefreak> cant this card wont use any of the nvidia drivers :(
[01:33] <mjg59> Right
[01:34] <mjg59> For now, you can just remove the "splash" argument from the kernel command line
[01:34] <mjg59> Please file a bug
[01:34] <gnomefreak> you got it
[01:37] <Zdra> gnomefreak: I've the same problem here. I use the free nv X driver
[01:37] <gnomefreak> yep
[01:38] <gnomefreak> i will report a bug in a few im looking for something atm
[01:41] <ogra> BenC, ping
[01:45] <pitti> seb128: wow, gtk has a cupsys backend now?
[01:45] <seb128> pitti: yep
[01:45] <seb128> pitti: since 2.10.1
[01:46] <pitti> seb128: I still miss gtk-mail-server :)
[01:46] <seb128> "* The printing framework now supports a subset
[01:46] <seb128>   of the Cups 1.2 custom PPD option spec"
[01:46] <pitti> ^ cool
[01:47] <seb128> gtk-mail-server? a MTA backend for GTK? :p
[01:47] <pitti> sure, and gtk-kitchen-sink
[01:47] <seb128> :)
[01:47] <seb128> gtk-make-coffee
[01:47] <pitti> and -clean-my-room
[01:48] <seb128> patches are welcome :p
[01:48] <Nafallo> s/om/oms/ :-)
[01:51] <gnomefreak> Zdra: comment on bug 55048 about usplash
[01:51] <Ubugtu> Malone bug 55048 in usplash "usplash ends and doesnt boot (edgy)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55048
[01:52] <Zdra> gnomefreak: I'll comment when I'm back at home to attach logs ;-) thanks
[01:52] <gnomefreak> ok
[01:54] <seb128> pitti: I'm not sure I like everything about the new apport-gtk
[01:54] <seb128> pitti: like the default being the bug discarded
[01:55] <pitti> seb128: as opposed to just being kept in /var/crash/?
[01:55] <seb128> and having the browser being spawned like that is sort of weird
[01:55] <seb128> pitti: as opposed to send the bug by default :)
[01:55] <pitti> we have to use the browser for edgy, we don't have a bug reporting tool yet :(
[01:55] <seb128> right
[01:55] <pitti> seb128: ah, you mean the default button?
[01:55] <seb128> yep
[01:56] <pitti> let's ask mpt again, but that's certainly negotiable
[01:56] <pitti> -> #u-desktop?
[01:56] <seb128> pitti: sure
[02:10] <hs_125> I installed ntop when i tried to run it says **ERROR** RRD: Disabled - unable to create base directory
[02:10] <hs_125> and gets freezes
[02:10] <hs_125> any idea ?
[02:18] <pygi> sivang, poke :)
[02:33] <Kamion> doko: ok, these figures look better - growth of 1.5-2MB across the board
[02:35] <doko> Kamion: hmm, that looks like it's too much
[02:35] <doko> Kamion: can I get these oversized CD's nevertheless?
[02:36] <Kamion> doko: the only differences are openoffice.org; also python-uno no longer seems to be on the CD
[02:36] <Kamion> doko: which is because openoffice.org-writer no longer depends on it in -proposed
[02:36] <pitti> Kamion: total CD growth, or OO.o growth?
[02:36] <Kamion> doko: http://cdimage.ubuntu.com/dapper/daily/
[02:37] <Kamion> pitti: total CD growth due to adding -proposed, entirely composed of OO.o changes
[02:37] <pitti> so we need to reduce powerpc, the rest should be fine?
[02:39] <Kamion> pitti: yes, powerpc alternate needs to drop by at least half a megabyte
[02:39] <Kamion> doko: if you can see low-hanging fruit to reduce the size, go for it, but otherwise I'm inclined to say "good try, but not this time"
[02:39] <Riddell> el: ping
[02:40] <doko> Kamion: I'll have a look
[02:40] <pitti> Kamion: hm, not two, to make them burnable for all people again?
[02:40] <Riddell> Kamion: should I be testing kubuntu/dapper/daily/20060803/ ?
[02:48] <Kamion> pitti: half a megabyte from 20060803.4 brings it under 700MB
[02:48] <Kamion> pitti: 20060803.5 was the one built against -proposed
[02:49] <Kamion> Riddell: hmm
[02:49] <Kamion> Riddell: yes, I guess so, although it was relatively early this morning
[02:49] <Kamion> ogra: could you have a look at http://cdimage.ubuntu.com/edubuntu/dapper/daily/current/ ?
[02:50] <Kamion> doko: doing one desktop CD build with -proposed, for your comfort and convenience :)
[02:51] <doko> Kamion: is openoffice.org-gcj on the CD? I didn't look yet at the package list
[02:51] <ogra> Kamion, looks good on first sight :)
[02:52] <gnomefreak> Hobbsee: thank you for fixing the depedns on that app so fast
[02:52] <Kamion> doko: no
[02:52] <Hobbsee> gnomefreak: which one?  oh, the yada one?  *grumble grumble mutter mutter*
[02:52] <gnomefreak> the mascma one
[02:52] <gnomefreak> (sp)
[02:53] <gnomefreak> mascyma
[02:54] <mjg59> gnomefreak: If you boot without splash, then log in, switch to a text console, do sudo usplash and then press ctrl+alt+f7, does it work or do you get corrupted graphics?
[02:54] <gnomefreak> didnt try ill try now
[02:55] <Hobbsee> gnomefreak: yeah.  uses yada.  ought to be shot.
[02:55] <Hobbsee> gnomefreak: actually, the upstream maintainers ought to be shot.  and their corpses burned.
[02:55] <gnomefreak> lol ;)
[02:55] <StevenK> Hobbsee: And drawn, quartered and then *really* hurt.
[02:56] <Hobbsee> StevenK: yeah, that's the one.
[02:56] <Hobbsee> and then taugth about using decent build system.s
[02:56] <gnomefreak> ok sudo usplash showed it now should i change my boot back to with splash?
[02:57] <gnomefreak> mjg59: ^^
[02:57] <mjg59> gnomefreak: No
[02:57] <gnomefreak> ok brb reboot
[02:57] <mjg59> gnomefreak: ?
[02:58] <gnomefreak> oh nvm you didnt need me to reboot
[02:58] <mjg59> gnomefreak: Nope
[02:58] <gnomefreak> k
[02:58] <mjg59> gnomefreak: So it works if you switch from usplash to X?
[02:59] <gnomefreak> mjg59: it worked in usplash X came right back to this
[02:59] <gnomefreak> tty
[02:59] <mjg59> gnomefreak: Ok
[02:59] <mjg59> gnomefreak: Then it's probably the fact that vga16fb gets loaded
[02:59] <mjg59> I'll look into it
[02:59] <gnomefreak> shoo
[02:59] <gnomefreak> mjg59: i went back into tty2 and it has that flashing error
[03:00] <mjg59> Oh
[03:00] <mjg59> Interesting
[03:00] <gnomefreak> mjg59: i went back again it dropped me into tty2 again
[03:01] <gnomefreak> mjg59: ok sudo usplash runs the usplash for a few secs maybe 30 than drops me back to the black screen with the monitor error
[03:03] <gnomefreak> i tried getting a screenshot of it but cant
[03:03] <mjg59> Right
[03:03] <mjg59> I'll look into it
[03:09] <jdub> hrm, is security.u.c down / inaccessible?
[03:09] <Kamion> slow
[03:09] <jdub> ah
[03:09] <jdub> thanks
[03:10] <mjg59> jdub: Tried the new usplash?
[03:11] <jdub> mjg59: not yet
[03:11] <jdub> mjg59: i'll have to reboot when pipka's not using my laptop :)
[03:11] <Hobbsee> mjg59: what did you want to know about it?
[03:11] <doko> Kamion: found the first 100k to save :)
[03:12] <mjg59> Whether it works
[03:12] <mjg59> In terms of appearing at a higher resolution than the old one
[03:12] <gnomefreak> Hobbsee: yes it was updated lastnght
[03:12] <mjg59> And if X still works afterwards
[03:13] <gnomefreak> maybe 10 hours ago or so
[03:13] <Hobbsee> mjg59: ah.  right.  X seems to start much more slowly, and it's at a slower resolution (680x400 or whatever the standard one is) instead of 800x600/1024x768/whatever mine usually is
[03:14] <mjg59> That's nothing to do with usplash
[03:14] <mjg59> So not sure what's going on there
[03:14] <Hobbsee> mjg59: sorry - the usplash is at the lesser resolution
[03:14] <mjg59> I don't really understand
[03:14] <Hobbsee> my bad.  i was unclear.
[03:15] <mjg59> usplash has never usually been at anything other than 640x400 in dapper
[03:15] <mjg59> Do you have a /etc/usplash.conf ?
[03:15] <Hobbsee> # Usplash configuration file
[03:15] <Hobbsee> xres=1024
[03:15] <Hobbsee> yres=768
[03:15] <Hobbsee> mjg59: yes.  ^
[03:15] <mjg59> Ok
[03:16] <mjg59> And you've rebooted since that was written?
[03:16] <Hobbsee> i've rebooted since i got the last update for usplash, so yes.
[03:16] <mjg59> Assuming your initramfs was regenerated, it's impossible for usplash to run at any resolution other than 1024x768 in that case
[03:17] <mjg59> The picture will still be 640x400, but it'll be centred in the screen
[03:17] <Hobbsee> mjg59: that's true.
[03:18] <mjg59> ?
[03:18] <gnomefreak> yep here too
[03:19] <Hobbsee> mjg59: sorry, that's true @ the 640x400, but centred in the screen.
[03:19] <mjg59> Oh
[03:19] <mjg59> So it works?
[03:19] <Hobbsee> well, yes.  but it's gotten a lot smaller!
[03:19] <mjg59> Given that the artwork is only 640x400, that's sort of inevitable...
[03:20] <gnomefreak> ok brb i have to boot kde
[03:31] <mdke> elmo: possibly you've been bugged about this already, but have you been poked about the forums being v slow? are you the right person to poke?
[03:33] <elmo> mdke: we don't run the forums software - if they're down entirely, sure, poke us, but performance isn't something we really deal with, you need to speak to ubuntugeek.  but he's aware, and wer're discussing ways of potentially speeding them up
[03:35] <mdke> elmo: ah, I see. Thanks, I wondered if it was related to the bandwidth thing you mentioned earlier wrt security.u.c, cheers for explaining
[03:36] <elmo> mdke: the bandwidth limitations are specific to security.u.c, shouldn't affect ubuntuforums right now
[03:36] <mdz> mjg59: will it be possible to know at update-initramfs time what mode will be used, so that we can select appropriate artwork in advance?
[03:37] <mdke> elmo: gotcha.
[03:37] <ogra_thin> but then ldm will also depend on lsb?relese
[03:37] <ogra_thin> argh
[03:37] <ogra_thin> lsb-release
[03:38] <ogra_thin> damned, i need an lts.conf with the right keymap
[03:38] <doko> Kamion: plus another 1.8MB
[03:38] <ogra_thin> whoops, ECHAN
[03:38] <Kamion> doko: ooh, where did that come from?
[03:39] <doko> Kamion: .wav files in /usr/lib/openoffice/share/gallery/sounds -> sound doesn't work anyway
[03:39] <doko> (at least in 2.0.3)
[03:42] <bddebian> Heya
[03:43] <Kamion> doko: that should be basically all the size increase clawed back, then, which is great
[03:45] <Kamion> mdz: do we want to update stuff like the firefox home page for 6.06.1?
[03:45] <Kamion> if I can get away with just leaving them alone, that would be a bonus :-)
[03:45] <mdz> Kamion: I don't think it's necessary
[03:45] <doko> Kamion: there seems to be much more (i.e. if we move the default icon themes for -gome and -kde) out of -common into some -common-kde and -common-gnome packages, but I would like to delay that, seems to have some impact
[03:46] <Kamion> doko: sounds like something to do for edgy
[03:46] <Kamion> although if it's *lots* more then we might want it for the next point release, if there is one
[03:46] <Kamion> I'm a bit reluctant to require dist-upgrade within a stable release though
[03:46] <doko> 4 icon themes with 4.5MB zip files each
[03:47] <Kamion> whew
[03:47] <Kamion> -rw-r--r-- root/root   4622082 2006-08-02 00:41:36 ./usr/lib/openoffice/share/config/images_hicontrast.zip
[03:47] <Kamion> -rw-r--r-- root/root   5458441 2006-08-02 00:41:30 ./usr/lib/openoffice/share/config/images_industrial.zip
[03:47] <Kamion> -rw-r--r-- root/root   5870914 2006-08-02 00:41:33 ./usr/lib/openoffice/share/config/images_crystal.zip
[03:47] <Kamion> -rw-r--r-- root/root   4901170 2006-08-02 00:41:28 ./usr/lib/openoffice/share/config/images.zip
[03:47] <Kamion> which of those are needed for GNOME and which for KDE?
[03:48] <Riddell> crystal kde, industrial gnome I guess, hicolontrast accessibility, images non-themed?
[03:48] <QuestionMarkCoun> Hello *
[03:48] <Kamion> doko: if we wanted to do that for dapper, I'd suggest moving them to openoffice.org-{gnome,kde}; I know those are architecture-dependent but the bloat there is probably better than a new package in dapper
[03:49] <QuestionMarkCoun> Kamion: I'm working with cdimage and I have a problem with the Makefile in debian-cd
[03:50] <Kamion> QuestionMarkCoun: oh?
[03:50] <sabdfl> mjg59: ping
[03:51] <doko> Kamion: ok, but not now. the missing python-uno is a mistake. adds +250k; so now we have saving of unused bitmaps: 110k + 1.8mb .wav files - 250k python-uno. -> total savings 1.65mb on all archs
[03:51] <QuestionMarkCoun> Kamion: The part after "Generating the source CD labels and their volume ids ..."
[03:53] <QuestionMarkCoun> Kamion: in the logfile I find "ls: /tmp/scratch/ubuntu-server/daily/tmp/dapper-src/??.sources: No such file or directory"
[03:53] <Kamion> doko: that makes it +/- 200-300KB; I'm happy enough with that
[03:53] <Kamion> doko: thanks for that
[03:53] <Kamion> QuestionMarkCoun: that's normal
[03:54] <doko> Kamion: ok, needs another upload, which will likely be built tomorrow morning
[03:54] <el> Riddell, late pong
[03:54] <Hobbsee> hah.  late pong.
[03:54] <QuestionMarkCoun> Kamion: ok... thank u
[03:54] <Kamion> QuestionMarkCoun: it's just because there's some dodgy shell that looks for ?.sources and ??.sources in order to cope with more than 9 CDs in a set
[03:55] <Riddell> el: could you change the assignee in kubuntu-system-settings-usability to simon-simonzone
[03:55] <Riddell> el: https://launchpad.net/distros/ubuntu/+spec/kubuntu-system-settings-usability/+people
[03:55] <Kamion> QuestionMarkCoun: personally I'd advise not trying to track down every warning - track down ones that seem to be associated with build problems, but don't go looking for trouble in debian-cd, because you'll find it ;)
[03:55] <Kamion> QuestionMarkCoun: you could compare against our build logs in http://people.ubuntu.com/~cjwatson/cd-build-logs/ if you like
[03:56] <el> Riddell, done
[03:56] <Kamion> doko: will you upload that to dapper-updates? you'll need to also upload stuff like libwpd then
[03:56] <doko> Kamion: can't that be mapped?
[03:56] <QuestionMarkCoun> Kamion: ok... but somehow, I have to find out, what is important and what is not ;)
[03:57] <Kamion> doko: not sure, I can ask the Soyuz team
[03:57] <Riddell> el: thanks, I'll let you know when I have some pacakges of simon's changes
[03:57] <Kamion> QuestionMarkCoun: comparing against our logs can be good for that
[03:57] <el> Riddell, great, thanks
[03:57] <doko> Kamion: that way, we could easily fall back to the packages from -security / -updates
[03:57] <Kamion> doko: actually, I know the answer - if we want to copy prebuilt binaries over, we need manual SQL munging at present
[03:57] <Kamion> ?
[03:58] <Kamion> ok, step back, what do you mean by "mapped"?
[03:59] <doko> Kamion: add the packages to -updates without uploading again? (or building the CD's from -proposed, if OOo is the only thing uploaded there)
[03:59] <mjg59> sabdfl: Hi
[03:59] <Kamion> doko: adding the packages to -updates is irreversible - once we do that, we can't/won't "easily fall back to the [old]  packages"
[03:59] <Kamion> doko: we can build from -proposed though
[04:00] <Kamion> doko: the plan is to create a dapper.0 suite which is a copy of dapper, and then sync all sources/binaries from dapper-{security,updates,proposed?} into it
[04:00] <Kamion> doko: I'd like to do that right at the end, though, as it needs malcc to sit down with ten pints of coke and a DB pickaxe
[04:01] <Kamion> infinity then wants to rebuild CDs and livefses from the new dapper just as a sanity-check
[04:04] <doko> -proposed currently just has the OOo related uploads. do what you think is less work for you. if users install 2.0.3, they can't go back that easily anyway. for me, it's not a big deal to upload to -proposed now and to -updates this weekend
[04:05] <Kamion> an upload this weekend cannot get into the point release, because as of Monday I'm on holiday for two weeks
[04:05] <Kamion> so I'd say just upload to -proposed now
[04:06] <Kamion> as you say, there's just OOo in there so it's easy enough to build from it
[04:07] <doko> ok
[04:09] <Kamion> right, that's it, I hereby declare that going back to gparted/qtparted in ubiquity will forget any mountpoints you've set. The alternative is too complicated to actually get right.
[04:31] <seb128> doko: do you know about gdb? like is that you I should ping if gdb segfault? :p
[04:32] <doko> seb128: it starts with g*, iz a gtk bug
[04:32] <doko> no, no problem reported yet
[04:33] <Nafallo> lol
[04:33] <Nafallo> doko: http://www.magicalforest.se/~nafallo/update-manager_crash.txt :-)
[04:34] <doko> Nafallo: please install python-dbg and try again
[04:35] <Nafallo> oh, it segfaults because of that? odd.
[04:36] <doko> Nafallo: I don't know ...
[04:36] <desrt> pitti
[04:36] <desrt> mer
[04:37] <seb128> doko: no, gdb is crashing, http://paste.ubuntu-nl.org/19599
[04:37] <seb128> doko: I'm building a debug gdb atm
[04:37] <Nafallo> yea, still crashing...
[04:37] <Spads> zul: ping
[04:37] <Nafallo> hehe, debug debugger :-)
[04:37] <desrt> a self-hosting trace?  cool.
[04:38] <doko> seb128: or build it with -fno-stack-protector
[04:38] <seb128> doko: what does it do?
[04:38] <doko> seb128: disabling pitti's pet
[04:38] <doko> (ssp)
[04:38] <seb128> ah
[04:38] <seb128> will try that
[04:39] <doko> if that doesn't work, I'll need to look at it tomorrow ...
[04:39] <seb128> doko: adding -fno-stack-protector to the CFLAGS should work?
[04:40] <doko> seb128: yes
[04:40] <seb128> doko: ok, thank you
[04:49] <zul> Spads: pong
[04:53] <Spads> zul: oh hey
[04:56] <QuestionMarkCoun> Kamion: I made some progress... now mkisofs crashes: /usr/bin/mkisofs: Argument list too long. cannot parse MD5 file '$CDIMAGE_ROOT/scratch/ubuntu-server/daily/tmp/dapper-src/md5-check'
[04:57] <Kamion> $CDIMAGE_ROOT shouldn't be in there unexpanded; investigate that
[04:58] <QuestionMarkCoun> Kamion: sry... log entry has the real path... I shortened it...
[04:59] <Kamion> so what mkisofs command is it running? it should have logged that
[05:02] <QuestionMarkCoun> Kamion: Is a special mkisofs version needed? I just use the standard one...
[05:03] <Kamion> the one in Ubuntu dapper should work fine
[05:03] <Kamion> don't use the upstream version - it doesn't have the jigdo patches
[05:04] <QuestionMarkCoun> man mkisofs knows something about jido... so I think this is ok
[05:05] <mhb> hey everyone
[05:05] <icecrash> hi
[05:05] <Hobbsee> heya
[05:06] <mhb> here am I lobbying again :o) Does anyone know if there are plans for internationalization of the basic console? (/dev/tty1,2...)
[05:07] <QuestionMarkCoun> + /usr/bin/mkisofs -r -V 'Ubuntu 6.06 Src-1' -o /tmp/independent/scratch/ubuntu-server/daily/debian-cd/src/dapper-src-1.raw -jigdo-jigdo /tmp/independent/scratch/ubuntu-server/daily/debian-cd/src/dapper-src-1.jigdo -jigdo-template /tmp/independent/scratch/ubuntu-server/daily/debian-cd/src/dapper-src-1.template -jigdo-map Debian=/tmp/independent/ftp/ -md5-list /tmp/independent/scratch/ubuntu-server/daily/tmp/dapper-src/md5-check -jigdo-min-fi
[05:07] <QuestionMarkCoun> le-size 0 -jigdo-exclude 'README*' -jigdo-exclude /doc/ -jigdo-exclude /md5sum.txt -jigdo-exclude /.disk/ -jigdo-exclude /pics/ -jigdo-exclude 'Release*' -jigdo-exclude 'Packages*' -jigdo-exclude 'Sources*' -jigdo-exclude 'Contents*' -jigdo-force-md5 /pool/ -J -joliet-long CD1
[05:08] <mhb> I find it a bit silly that I have my local keyboard in X but when I switch with CTRL+ALT+F1 to the consoles, I have english keyboard and no support for local characters ... :o(
[05:08] <mhb> I think it should be configured at install time
[05:08] <Kamion> mhb: it is, for most people
[05:09] <Kamion> please file a bug on debian-installer with full information about your setup
[05:09] <Kamion> (or ubiquity, depending on which you used) and attach /var/log/installer/syslog
[05:09] <mhb> Kamion: dapper or edgy?
[05:10] <Kamion> mhb: it's supposed to have worked since forever, but there's always the possibility of bugs with regard to certain keymaps
[05:11] <Kamion> QuestionMarkCoun: looks ok to me, so I'm afraid I don't know
[05:12] <Kamion> QuestionMarkCoun: FWIW the string "list too long" doesn't appear anywhere in the mkisofs source I have here - I'd suggest double-checking your installation
[05:13] <QuestionMarkCoun> Kamion: is ok to just drop md5 things here... for testing...
[05:13] <Kamion> QuestionMarkCoun: I suppose it could be that "Argument list too long" is a red herring and it
[05:13] <Kamion> just doesn't like the md5-check file
[05:13] <Kamion> QuestionMarkCoun: up to you
[05:13] <mhb> Kamion: so I should do a clean install and then report the /var/log/installer/syslog, right?
[05:13] <Kamion> mhb: feel free to report from your current installationn
[05:14] <Kamion> QuestionMarkCoun: things that come to mind are to make sure that your setting of MIRROR is correct and to make sure that you've mirrored dists/$DIST/main/installer-$ARCHES
[05:15] <QuestionMarkCoun> my mkisofs is 4:2.01+01a01-4ubuntu6
[05:16] <mhb> Kamion: well, I'll do some more research ... I have to find out if both ubiquity and the Kubuntu installer fails to set the console font+keymap
[05:17] <Kamion> they do it using different code at present (sane-installer-keyboard aims to fix that, in part), so it's possible that one fails but not the other
[05:18] <mhb> Kamion: I'll do some more research and then I'll report the bug
[05:18] <Kaleo> Hello
[05:18] <mhb> Kamion: thanks for the pointers :o)
[05:18] <QuestionMarkCoun> Kamion: we are syncing against de.archive.ubuntu.com with SECTIONS="main,restricted,universe,main/debian-installer"
[05:19] <QuestionMarkCoun> and dists are: dapper,dapper-updates,dapper-security
[05:19] <Kamion> QuestionMarkCoun: debmirror doesn't pull down the installer-* trees itself - you have to do that by hand with rsync or whatever
[05:20] <QuestionMarkCoun> ok... thank you so far... I will rsync it and try again
[05:20] <Kamion> no problem, good luck
[05:22] <seb128> doko: crash with gdb built with -fno-stack-protector too
[05:24] <Kamion> oops! let's pretend that ubiquity actually works in dapper-updates shall we *cough*
[05:24] <mhb> Kamion: Any chance you might know if (or when) we (the translators) will be able to translate the .deb package information (details about the package) ?
[05:25] <mhb> some of my debian translator friends informed me they are starting to translate their own, so I thought it will soon be possible in Ubuntu, too.
[05:25] <Kaleo> Kamion: sorry to annoy you again but did you get my private messages or would it be better to send you an e-mail ?
[05:25] <Kamion> Kaleo: yes, I got them, and I'm familiar with the bug
[05:26] <Kamion> thank you for the patch, I'll review it when I have time
[05:26] <Kamion> I could not respond to your private messages because every time I saw them you were offline
[05:26] <Hobbsee> Kamion: /msg memoserv help :P
[05:27] <Hobbsee> although whether people actually read their memos is a good question
[05:27] <Kaleo> Kamion: that's right (56k modem), thank you for your time
[05:28] <Kamion> Hobbsee: I tend to think that people who aren't connected most of the time should use e-mail or memos themselves rather than sending /msgs to which it's hard to respond
[05:28] <Kamion> I tend not to remember about memoserv when replying to people
[05:28] <Hobbsee> Kamion: that is true.  i'm more telling you another way you could use :)
[05:28] <Hobbsee> heh
[05:29] <Kamion> Kaleo: also, AFAIK the problem only affects users on systems that drop traffic they don't want rather than properly rejecting it
[05:29] <Kaleo> thanks to screen+irssi Ill be online now :)
[05:30] <Kamion> s/on systems/behind firewalls/
[05:30] <Kamion> if your firewall actually says "no" rather than "la la la I can't hear you", then apt will give up in a reasonable time rather than waiting ages to timeout
[05:30] <Kamion> I'm also not really sure that just checking the http_proxy environment variable (while useful) is something that most people affected by this would discover
[05:32] <Kaleo> Kamion: I understand
[05:32] <Kaleo> in the Uni here everybody is behind that kind of firewall
[05:33] <Kaleo> and there is no way to complete the installation right now
[05:33] <Kamion> I'll throw in your workaround for the moment, but it doesn't really close the bug
[05:34] <Kaleo> I agree
[05:34] <Kaleo> actually what I would like is something like
[05:34] <Kaleo> do you want to use your internet connection or not
[05:34] <Kamion> hang on, doesn't apt honour http_proxy?
[05:35] <Kamion> yes, it does
[05:35] <Kamion> so I don't understand why your suggested change is necessary
[05:35] <Kaleo> give me a minute to remind me the circumstances
[05:35] <Kamion> if http_proxy is set in the environment, apt will prefer it over Acquire::http::Proxy anyway
[05:36] <Kaleo> because in my experience setting up the http_proxy variable did not solve the bug
[05:36] <Kaleo> I have now to remember why
[05:36] <Kamion> ok, sorry but I want to know why before installing workarounds
[05:37] <Kaleo> no problem
[05:37] <Kaleo> oh I think I remember
[05:37] <Kaleo> because of gksu
[05:37] <Kaleo> if I remember correctly ubiquity is launched by gksu
[05:38] <Kamion> gksu is outside apt-setup (the code you patched); if apt doesn't see http_proxy due to gksu, then apt-setup won't see it either
[05:38] <Kaleo> "This is thanks to the correction of bug #13661 where gksu has been given the ability to set $http_proxy according to System/Preferences/Proxies."
[05:38] <Ubugtu> Malone bug 13661 in synaptic "get proxy via gconf" [Medium,Fix released]  http://launchpad.net/bugs/13661
[05:38] <Kaleo> that's why it works
[05:39] <Kamion> but gksu -> ubiquity -> (apt-setup, apt_)
[05:39] <Kamion> anything in gksu will affect apt-setup and apt equally
[05:39] <Kamion> making apt-setup look at http_proxy should be pointless because apt already does it
[05:39] <Kaleo> I see
[05:41] <Kamion> I'm running through an installation with a configured proxy now
[05:41] <Kaleo> ok
[05:42] <Kaleo> I have to look at the code to be able to remember the process
[05:43] <Kamion> it's possible that something's clobbering the environment; if so, that's the bit to fix
[05:44] <Kamion> and yes, ubiquity's launched via gksudo
[05:49] <Kaleo> from what I understand of my patch apt-setup was not honouring $http_proxy
[05:51] <Kamion> apt-setup doesn't need to
[05:51] <Kamion> it doesn't download anything itself - it calls out to things that do honour http_proxy
[05:51] <Kaleo> well
[05:51] <Kamion> i.e. apt-get and wget
[05:52] <Kaleo> I guess than apt-get or wget was not honouring it
[05:52] <Kaleo> -than+that
[05:52] <Kamion> honestly, I don't believe that
[05:52] <Kaleo> that seems weird
[05:53] <Kaleo> must be something else then
[05:55] <Kaleo> how is going your installation ?
[05:55] <Kamion> I've confirmed that http_proxy is definitely being passed through to apt
[05:55] <Kaleo> ok
[05:55] <Kamion> it's being pretty slow, but that's because archive.ubuntu.com is being pretty slow
[05:55] <Kaleo> yes
[05:55] <Kamion> the environment is definitely correct though
[05:55] <Kaleo> how did you set up the proxy ?
[05:55] <Kamion> system -> preferences -> network proxy
[05:55] <Kaleo> directly the $http_proxy ?
[05:55] <Kaleo> ok
[05:56] <Kaleo> are you sure that its going through it ?
[05:56] <Kaleo> does your firewall prevent the direct connection ?
[05:57] <Kamion> I'm stracing squid, I can see stuff going through it
[05:57] <Kamion> read(14, "GET http://gb.archive.ubuntu.com"..., 4095) = 211
[05:57] <Kamion> is pretty conclusive
[05:58] <Toadstool> hi here
[05:58] <Toadstool> doko: around?
[06:01] <Kamion> netstat on the client also says that it's talking to the proxy
[06:03] <Toadstool> doko: anyway, got to go, that was about bug 55047, python-mysqldb just need a rebuilt and as you're listed as the last uploader, I thought I should talk to you first
[06:03] <Ubugtu> Malone bug 55047 in python-mysqldb "python-mysqldb doesn't actually install any python" [Medium,Confirmed]  http://launchpad.net/bugs/55047
[06:04] <Kaleo> Kamion: pretty strange but the facts are as you say conclusive
[06:06] <Kamion> Kaleo: my feeling is that a good approach would be to make apt-setup chatter more to debconf about what it's doing
[06:06] <Kamion> Kaleo: it probably wouldn't be too difficult to pass through the apt progress bar, now that we have stuff like debconf-apt-progress
[06:07] <Kamion> I suspect many experiences of "hangs" with a configured proxy are in fact just slowness and lack of progress reporting
[06:07] <Kaleo> hmmm
[06:08] <heno> seb128: do you know why gnome grabs focus when you press Alt? Does it need to do that?
[06:08] <heno> It complicates things like the on-screen keyboard
[06:10] <Kaleo> Kamion: I will try again from the same place to see if the problem vanished
[06:10] <Kamion> Kaleo: check with netstat to see what hosts processes are talking to
[06:10] <Kaleo> yes
[06:12] <Kaleo> question: would it not be better to ask the user if he wants his connection to be used or if he thinks that it's correctly configured ?
[06:12] <Kamion> sure, just more work that's all
[06:13] <Kamion> I have no fundamental objection to it, but I doubt I'll have time to do it before Edgy because I'm also trying to rewrite the partitioner, which is more urgent
[06:13] <Kaleo> Kamion: okay
[06:13] <Kaleo> I agree
[06:13] <Kaleo> I would like to try
[06:13] <Kamion> care would need to be taken to ensure that it's not on the critical path for installation
[06:13] <Kamion> i.e. that it's off in a "Connection Settings..." box
[06:14] <Kaleo> what do you mean ?
[06:14] <Kamion> it is important not to make the installation longer by adding extra pages full of questions that the user has to read
[06:14] <Kaleo> yes
[06:15] <Kamion> at this point, most extra questions should be in places where the user isn't obliged to acknowledge them, and can just bypass them to use the defaults
[06:15] <Kaleo> like an extra option in a page with a sensitive default option ?
[06:16] <Kamion> I was thinking of a button on some appropriate page that popped up some extra stuff when pressed
[06:16] <Kamion> but whatever
[06:16] <Kaleo> I see
[06:16] <Kamion> I'm no UI design genius
[06:16] <Kaleo> me neither
[06:18] <Kamion> well, that was the work of a number of people
[06:18] <gnomefreak> ah i thought that was you only :)
[06:19] <Kamion> hell no
[06:20] <Kamion> I spent at least 20 hours of face-to-face time with other people to thrash out the ubiquity UI
[06:20] <gnomefreak> ah
[06:24] <Kaleo> Kamion: do you think that the question is important enough to be visible in one ubiquity's screen ?
[06:25] <Kamion> Kaleo: I think it should be easy to see how to get to it, but I'm not convinced the question itself should be visible
[06:26] <seb128> heno: no idea, what do you mean by "grab focus when you press Alt"? like window going to first plan?
[06:26] <Kamion> seems like a reasonable case for just having the title/heading be visible
[06:30] <heno> seb128: when you press and hold the Alt key the mouse clicks are diverted to metacity it seems
[06:30] <heno> seb128: so you cannot click on anything else until it is released
[06:31] <heno> that makes Alt+key combinations difficult on the virtual keyboard
[06:31] <mdke> it's used for dragging windows
[06:31] <Kaleo> Kamion: I cannot see any screen in ubiquity relevant to the network
[06:31] <heno> mdke: ah, thanks. Is there a gconf key to turn it off?
[06:31] <Kamion> Kaleo: indeed, there isn't one
[06:32] <Kamion> Kaleo: the timezone screen is closest, I suppose, since it deals with where you are
[06:32] <Kaleo> Kamion: yes
[06:32] <Kamion> although it's a little crowded at present
[06:32] <Kaleo> I agree
[06:32] <Kaleo> indeed
[06:32] <Kaleo> it brings me another question
[06:33] <mdke> heno: I can't see one. seb128 will know
[06:33] <Kamion> Riddell: I'd appreciate testing of ubiquity 1.0.15 on Kubuntu when it builds; suggested test is to create some partitions in qtparted, go forward to the mountpoints screen, go back, delete those partitions and create some other ones, go forward to the mountpoint screen, see if it behaves sensibly
[06:33] <Kaleo> we have three possibilities : 1) internet connection set up properly, 2) no network interfaces configured, 3) interface configured but no access to internet
[06:33] <Kaleo> in case 1) everything is fine
[06:34] <Riddell> Kamion: sure
[06:34] <Kamion> Riddell: prior to 1.0.15/1.1.7 it would fail to offer some of the partitions (especially if you create more partitions the second time round than you did the first time round), probably get the sizes wrong, and if you selected a partition that you didn't create in the first time round then it would crash
[06:35] <Kamion> I solved this by just deciding not to bother trying to preserve mountpoint selections if you go back
[06:36] <Kamion> Kaleo: the other obvious option is to put stuff on the final summary screen
[06:36] <Kaleo> in case 2) the installation goes ok I think but you have to configure manually the mirrors if you planned to use an internet connection
[06:36] <Kamion> Kaleo: so it says "Network: use existing Internet connection" and there's a button beside it letting you change it, or something
[06:36] <Kaleo> Kamion: absolutely the best place at the moment, I agree
[06:36] <Kaleo> Kamion: yep
[06:36] <Kamion> that would go for bootloader configuration as well
[06:37] <Kaleo> Kamion: really interesting the bootloader option but maybe a bit too technical ?
[06:37] <Kamion> I have a horde of osnews people baying for my blood that ubiquity doesn't let you configure where grub is installed
[06:38] <Kamion> again, it absolutely shouldn't be asked by default, but if the final summary said "GRUB: installed in Master Boot Record of /dev/sda" or whatever and there was a button to change it, that wouldn't be too scary
[06:38] <Kaleo> oh I see, the same summary but with small buttons for options
[06:39] <Kamion> right. now at the moment there are some technical problems with asking much in the way of questions on the final summary page (because the partitioner is still running in the background and monopolising debconf), but I'm sure there are ways around that
[06:39] <Kamion> anyway, I have to go for the evening - see you
[06:39] <Kaleo> ok Kamion , see you later
[06:39] <Kaleo> thanks for the chat
[06:41] <Kamion> np
[06:55] <bluefoxicy> Ubugtu: bug 6761
[06:55] <Ubugtu> Malone bug 6761 in openssl "openssl: Expired certificates and recertification" [Unknown,Confirmed]  http://launchpad.net/bugs/6761
[06:55] <bluefoxicy> ok /bugs/ *starts poking through bugs*
[06:55] <bluefoxicy> (launchpad is such a pain)
[06:56] <doko> Toadstool: on my list
[06:56] <bddebian> Wow you are actually going to do something instead of bitch and moan?
[06:57] <bluefoxicy> bddebian:  Nah, I'm trying to graph the rate of bug submissions for a presentation
[06:57] <bddebian> Ah yes of course
[07:04] <Riddell> el: rocking new system settings http://kubuntu.org/~jriddell/tmp/kde-systemsettings_0.0svn20060803-0ubuntu1_i386.deb
[07:06] <Nafallo> what's up with a.u.c? it's /real/ slow now.
[07:07] <bluefoxicy> bddebian:  you don't know of a way to get per-day or per-month counts on launchpad besides counting each bug do you?
[07:07] <bluefoxicy> (using the bug numbers doesn't seem to help; or the reporter is not reporting most of the bugs to me)
[07:08] <Nafallo> bluefoxicy: ask the launchpad-devs to integrate that somewhere? :-)
[07:08] <bddebian> bluefoxicy: no clue,sorry
[07:18] <seb128> heno: gnome-window-properties, on the bottom of the dialog
[07:19] <heno> seb128: thanks, that helps a bit. No option for 'none' unfortunately
[07:20] <seb128> heno: people usually want to be able to move their window :p
[07:21] <seb128> heno: the gconf key is /apps/metacity/general/mouse_button_modifier you can try to set it to nothing maybe, dunno if that's supported
[07:21] <heno> seb128: right, but for people who cannot use a mouse it may be more important to be able to access the file menu with Alt-F
[07:21] <heno> thanks
[07:21] <heno> The Meta options should help
[07:21] <seb128> heno: right, but do they need the win key by example?
[07:21] <heno> no not really
[07:22] <heno> that's good enough for now I think
[07:22] <seb128> k
[07:22] <seb128> other way it's probably easy to change the metacity code for understand no value for it if it doesn't at the moment
[07:24] <heno> actually it's not a problem with the Win key ATM either, because we don't treat it as a sticky key, so it can still be used for single presses
[07:25] <heno> though I guess it is used as a modifier in some cases
[07:44] <dos000> anyone can suggest a good ide/debugger in ubuntu ?
[07:44] <dos000> for c/c++
[07:44] <bddebian> gdb?
[07:44] <pygi> sivang, poke
[07:44] <dos000> bddebian, anything that has integrated editors .. like gvim
[07:45] <pygi> dos000, #ubuntu pls :)
[07:45] <pygi> your mind is best debugger :)
[07:45] <dos000> pygi, most people in #uybuntu are not necessarily developpers ... i also already asked there
[07:46] <dos000> i am donloading kdevelop3 now. i am on breezy
[07:56] <lfittl> madduck: ping
[07:58] <bddebian> lfittl!!  I just sent you an e-mail
[07:58] <lfittl> bddebian: saw it, and already replied ;)
[07:59] <bddebian> lfittl: Aye, just got that, sorry
[08:00] <bddebian> lfittl: Have you talked to Raphael at all?
[08:01] <lfittl> bddebian: no, didn't thought of it in february, but will do now before taking over his package
[08:02] <bddebian> lfittl: Well he has been fairly unresponsive for me :-(
[08:03] <madduck> lfittl: yes?
[08:03] <lfittl> bddebian: hmm, will see, worst case if I can't take it over in debian I just upload it to ubuntu..
[08:03] <bddebian> lfittl: Aye
[08:07] <pygi> doko, bleh, why not upgrade to dapper?
[08:16] <bluefoxicy> Nafallo:  will do
[08:18] <jdub> (holy crap, an imlib upload...!)
[08:20] <Gloubiboulga> jdub, is this that bad?
[08:21] <bddebian> Didn't I ask for a sync of imlib?
[08:21] <Gloubiboulga> bddebian, you did? I just merged it
[08:21] <bddebian> I saw that :-)
[08:22] <Gloubiboulga> ah yes, there's a sync request
[08:22] <zul> jdub: any problems with xen so far?
[08:22] <bddebian> Gloubiboulga: Can you reject that for me while you are in there?
[08:22] <Gloubiboulga> bddebian, sure
[08:22] <msw> jdub: like, good 'ole imlib?
[08:22] <msw> jdub: not imlib2?
[08:23] <jdub> msw: seriously.
[08:23] <jdub> Gloubiboulga: that anything depends on or requires updates of imlib is scary. :-)
[08:23] <jdub> zul: haven't been running it on the laptop
[08:24] <zul> jdub: ah ok
[08:25] <Gloubiboulga> jdub, you seem to know imlib very well, it'll be easy for you to fix everything is broken then ;)
[08:25] <QuestionMarkCoun> Kamion: We did it :) the first iso fell out... thank you
[08:27] <bddebian> Gloubiboulga: :-)
[08:41] <jdub> Gloubiboulga: noooooooo--*choke*!
[08:42] <pygi> sivang, poke again :)
[08:48] <HiddenWolf> jdub: that image you just blogged, is that real or gimped?
[09:09] <sivang>  /msg pygi pong
[09:09] <sivang> pygi: pong
[09:09] <thom> jdub: fixing imlib is very easy... ssh container, rm -rf /cvs/gnome/imlib
[09:11] <tseng> thom: hah!
[09:12] <tseng> thom: i've sent your patch to iain but he has already skipped town i think
[09:12] <tseng> thom: if i get frustrated enough ill host a bzr branch
[09:12] <thom> garn.
[09:13] <pygi> sivang, pm :)
[09:16] <Chipzz> any reason why security.ubuntu.com is slow today?
[09:17] <pygi> Chipzz, servers are reaching bandwith limits
[09:17] <Nafallo> why btw? :-)
[09:17] <tseng> Nafallo: more users?
[09:17] <Nafallo> but why haven't I seen this problem before?
[09:18] <Chipzz> pygi: it's not bandwidth, it's response time
[09:18] <Chipzz> takes 10sec or more to get a connection
[09:19] <pitti> Hello
[09:19] <pygi> Chipzz, poke elmo if you don't trust me, it's bandwith :)
[09:19] <pygi> hey pitti, I was looking for you before
[09:19] <Nafallo> we can't have THAT many new users, can we?
[09:20] <pygi> pitti, you have O_EXCL patch for cdrecord? I need to do same thing to upstream source of libburn
[09:20] <pygi> (apply patch)
[09:24] <pitti> pygi: yes, we have it for ages
[09:26] <pygi> pitti, asking because of this: http://libburn.pykix.org/ticket/18
[09:26] <pygi> if it's just a stream that needs to be opened with O_EXCL, then it's 30 seconds patch :)
[09:27] <pitti> pygi: oh, you meant I shall give you the patch?
[09:28] <pygi> pitti, right, just to see if I am thinking about the correct thingy :)
[09:29] <pitti> pygi: http://people.ubuntu.com/~pitti/patches/cdrecord.O_EXCL.patch
[09:29] <pygi> thanks pitti :)
[09:29] <pitti> pygi: I'm not sure whether the timeout is the right thing to do in the library
[09:30] <pitti> pygi: maybe the library should just fail with a particular 'busy' error and the timeout should be in the app
[09:30] <pitti> pygi: if you take this timeout stuff away, it's indeed just adding O_EXCL to the open() call
[09:31] <pygi> right, busy error it might be then or something more verbose :)
[09:33] <pygi> so this patch replaced open() with sg_open_excl()
[09:34] <pygi> ah, right
[09:34] <pygi> thanks once again pitti :)
[09:34] <pitti> pygi: yes, because sg_open_excl() implements the timeout
[09:35] <pitti> pygi: but as I said, that's a bit evil in a library, since the app would be blocked during that time
[09:35] <pygi> pitti, yes, but  in my case it could implement error message
[09:35] <pitti> pygi: you should just pass the EBUSY to the app IMHO
[09:35] <pitti> pygi: how is libburn coming along, btw?
[09:35] <pygi> pitti, quite good I would say
[09:35] <pitti> it's something that has been necessary for a looong time :)
[09:35] <pitti> cool
[09:35] <pygi> I an working on complete libisofs rewrite right now
[09:36] <pygi> we aim for -tao like writing for 0.3, and for dvd and multi-session I am not yet sure
[09:36] <pygi> 0.2.1 should be out in a month
[09:36] <pitti> pygi: so, something non-crackful GPL with a sane consistent interface?
[09:36] <pitti> pygi: will it handle DVDs, too?
[09:36] <pygi> pitti, it should, but not just yet :)
[09:36] <pitti> sure, I mean if it's plannec
[09:36] <pitti> s/c$/d/
[09:36] <pygi> ofcourse :)
[09:37] <pitti> the API should be designed accordingly, I mean
[09:37] <pitti> yay
[09:37] <pygi> I think I'll have most issues with multi-session stuff
[09:38] <pygi> I'll need to do some serious thinking about that
[09:38] <pitti> pygi: I found the 'write down all use cases and check whether the API has a straightforward way of implementing them' a good approach
[09:40] <pygi> pitti, indeed :)
[09:41] <pygi> I just had talk with "someone" offering me to implement conversion of most proptietarity image formats to iso into libisofs :)
[09:41] <pygi> which I'll most probably decline :)
[09:42] <pitti> 'proprietary image formats' -- like the ones from Nero etc.?
[09:42] <pitti> well, I haven't seen a non-Linux box in a long time
[09:42] <pygi> pitti, hehe :)
[09:42] <pygi> right, alcholol 120%, nero, bla, bla :)
[09:42] <pygi> alcohol*
[09:43] <HiddenWolf> where is the catch?
[09:43] <pitti> pygi: what's the problem with that conversion? the knowledge about the format is NDAed?
[09:43] <HiddenWolf> pitti: of course not, that'd be sane, wouldn't it?
[09:44] <pygi> pitti, indeed, he obtained knowledge by doing reverse engeenering :)
[09:44] <pygi> or whatever the spelling is :p
[09:44] <pitti> HiddenWolf: erm, you mean NDA'ing file formats would be sane?
[09:44] <pitti> pygi: but reverse engineering is fine - where's the problem then?
[09:45] <pygi> pitti, how can it be fine? :P
[09:45] <HiddenWolf> pitti: I mean that wrapping some metadata around iso would've been sane, which is why they didn't do that for $bunchofotherformats
[09:45] <pitti> pygi: fine legally, not from the point of efficiency, of course :)
[09:45] <pitti> HiddenWolf: ah, heh
[09:46] <pygi> pitti, hm, right, but...ah anyway, care to discuss this later? I am kinda in a hurry :)
[09:46] <pitti> oh, I didn't mean to stall you
[09:46] <pygi> no, no, ofcourse you didn't, don't worry :)
[09:46] <pitti> pygi: have a good day!
[09:46] <pygi> pitti, or night :) thanks :)
[09:47] <pitti> pygi: right, you're approx. my time zone, too :)
[09:47] <crimsun> pitti: hi, if you have a sec, is there plans for pulseaudio in edgy?
[09:48] <crimsun> s/is/are/
[09:48] <pitti> crimsun: not from my side
[09:48] <crimsun> ok
[09:48] <pitti> if someone wants to package it, sure
[09:48] <pitti> but I don't intend to reintroduce a mixing daemon by default
[09:48] <icecrash> hi
[09:48] <crimsun> pitti: oh, so esd is out completely?
[09:49] <pitti> crimsun: not yet, due to libgnome
[09:49] <pitti> it's still used for sound events
[09:49] <crimsun> right. Ok, thanks.
[09:58] <bluefoxicy> btw I'm pseudo-banned from offtopic again
[09:58] <bluefoxicy> nailoth got mad that I !ops'd when someone was looking for ops
[09:59] <tseng> you aren't going to appeal his decision here
[09:59] <tseng> sorry.
[09:59] <bluefoxicy> well I can't do it in there, I can't talk :P
[10:00] <tseng> nailoth is not here
[10:00] <bluefoxicy> He's not there anymore either.
[10:02] <tseng> I think you'll live.
[10:07] <Seveas> bluefoxicy, -devel is not an escalation channel
[10:08] <Seveas> try -ops
[10:08] <bluefoxicy> ah
[10:09] <desrt> is the archive down?
[10:09] <Seveas> bw problems in london
[10:09] <desrt> i see
 Security is in London hosted by us.  It's slow because we're presently having bandwidth issues.
 We hope to have our bandwidth issues resolved in about a weeks time.
[10:12] <desrt> ow.
[10:13] <Toadstool> doko: ok, thanks
[10:20] <pitti> does anyone have a minute to help me testing something? (requirements: removable USB device)
[10:21] <crimsun> pitti: sure.
[10:21] <pitti> like an USB stick, hard drive, or so
[10:21] <Kamion> QuestionMarkCoun: glad to hear it
[10:21] <Toadstool> pitti: I can but it depends on whether an up-to-date edgy box is required or not, my laptop is kinda broken :/
[10:22] <pitti> Toadstool: no, dapper will do fine, too
[10:22] <Toadstool> ok
[10:22] <Nafallo> pitti: I can :-)
[10:22] <pitti> Toadstool, crimsun: if you have this device mounted, and do 'eject /dev/sda1' (or whatever the device is), does /dev/sda1 still exist after eject?
[10:22] <pitti> Nafallo: great, see ^
[10:22] <pitti> I need someone where the device doesn't exist any more
[10:22] <pitti> for me it still exists, and I tested this case
[10:23] <pitti> but the other case is more interesting
[10:23] <crimsun> yes, it does still exist.
[10:23] <pitti> crimsun: hm, same like here then; thanks anyway!
[10:23] <Nafallo> still exist...
[10:24] <Toadstool> still exits too
[10:24] <Nafallo> until I remove the card from the slot...
[10:24] <Toadstool> *exists even
[10:24] <pitti> I got some bug reports where users confirmed that ejecting a device will remove the /dev node
[10:24] <pitti> hm, ok, thanks, guys
[10:25] <Nafallo> maybe they "ejected" by removing? :-)
[10:25] <pitti> Nafallo: no, I'm pretty sure they did it right (I checked that with several different users)
[10:25] <pitti> too bad, now I need such a case to verify my auto-unmount-notifications spec approach :/
[10:25] <Toadstool> now, /me away, I really need to find a place to live in San Diego for the beginning of September and when you live in France it's not that easy :/
[11:18] <bddebian> OK, who the hell is Patrick McFarland?
[11:27] <crimsun> bddebian: 'diablo3d' or some variant on oftc
[11:27] <bddebian> Hmm, OK
[11:29] <Seveas> diablod3, one of lilos worst enemies
[11:30] <LaserJock> really?
[11:30] <Spads> What did he do to earn this position?
[11:30] <LaserJock> he's annoying for sure
[11:43] <Surak> There's a bug which happens on dapper only if you have a intel chipset (with a intel integrated graphics) IF, and only if there's a nvidia video card inserted into the agp slot. What would be the correct component to file a bug against? The kernel, the module-init-tools (as the module intel_agp is not blacklisted in this case) or perhaps the linux-restricted-modules?
[11:43] <Surak> Oh, this is amd64
[11:45] <Kamion> mjg59: please make setup_usplash_config have a fallback if 'db_get xserver-xorg/config/display/modes' fails
[11:45] <Kamion> mjg59: the current code is breaking all fresh installs of edgy
[11:49] <Kamion> hm, I should file a bug instead. done.
[11:50] <gnomefreak> Kamion: already did
[11:50] <gnomefreak> if you mean the wont boot with usplash type bug
[11:50] <Kamion> no, I don't
[11:50] <gnomefreak> oh ok
[11:59] <mjg59> Kamion: Ah.
[12:00] <mjg59> Kamion: What's the precise failure mechanism?
[12:00] <mjg59> Kamion: If it's hitting all of them, then presumably we need some mechanism to enforce configuration occuring after X
[12:01] <mjg59> (iff X is being installed)
[12:01] <LaserJock> is there any person in particular that takes care of -updates or is just like any other of the repos?