[12:17] <sivang> hey slomo , long time :)
[12:45] <mdke> man, I was just going to do a breezy->edgy server upgrade
[12:46] <Keybuk> yeh, right :p
[12:47] <Keybuk> there's no such thing as edgy yet :p
[12:48] <zul> Keybuk: what is it september now
[12:48] <Keybuk> November
[12:52] <sivang> it's June, the last time I check :p
[12:53] <Keybuk> sivang: when we're opening edgy.
[12:53] <Keybuk> it delays an extra two days everyone asks
[12:53] <Keybuk> we're into November before it opens now
[12:54] <Keybuk> the cornet? :p
[12:54] <Keybuk> you like looking at ice cream vans?
[12:54] <sivang> erm,
[12:55] <sivang> you know what I meant ! :-)
[12:55] <sivang> s/cornet/corner
[01:06] <ogra> WOAH
[01:07] <ogra> Keybuk, do you still use your little fanboy applet ? 
[01:07] <Keybuk> no, why?
[01:07] <Keybuk> I never especially used it in the first place
[01:07] <Keybuk> I just wrote it because I wanted to play with pygtk for a few hours
[01:07] <sivang> Keybuk: what does the fanboy applet do?
[01:08] <Keybuk> sivang: shows how many fans in your laptop are running
[01:08] <ogra> i used it as a base for a cpu temp monitor and poorted that one to ppc when i boiught my ibook
[01:09] <ogra> if i start it witch a resen ppc kernel here i get:
[01:09] <ogra> [78143.253071]   <1>Unable to handle kernel paging request for data at address 0x00000000
[01:09] <ogra> [78182.632552]  Faulting instruction address: 0xc01cc450
[01:09] <ogra> [78182.632569]  Oops: Kernel access of bad area, sig: 11 [#4] 
[01:09] <ogra> reproducable with every start of the applet 
[01:10] <ogra> ugh, what did i type ? 
[01:10] <sivang> Keybuk: is it packaged somewhere? could be useful no?
[01:11] <ogra> if i start it with a recent ppc kernel here ...
[01:11] <Keybuk> sivang: it isn't
[01:11] <Keybuk> I don't even have the source
[01:11] <ogra> BenC, is opening /sys/devices/temperatures/sensor1_temperature from a python script supposed to produce oops on ppc ?
[01:12] <freeluna> exit
[01:16] <ogra> hmm, even a cat /sys/devices/temperatures/sensor1_temperature produces it
[01:20] <mjg59> ogra: As far as the kernel is concerned, reading from a file is reading from a file
[01:21] <ogra> hmm, then i wonder why i get oppses ... the temperature monitoring appears to be fine (fans work if the load is high)
[01:21] <ogra> *oopses too
[01:24] <mjg59> Because there's a bug in the kernel?
[01:26] <ogra> hmm, apparently ... but i'd expect the fan management to be broken as well if reading the temp doesnt work 
[01:26] <bddebian> Hello
[01:26] <ogra> unless thats not done in the kernel on ibooks ...
[01:27] <mjg59> ogra: Why?
[01:27] <mjg59> ogra: If you look at the backtrace, it's likely to be blowing up in a pathway specific to reading the sysfs attribute
[01:29] <ogra> yep, there is something with sysfs_read in there ...
[01:30] <Keybuk> urgh, libsysfs
[01:30] <Keybuk> kill it now!
[01:30] <Keybuk> oh, wait, kernel
[01:30] <ogra> heh
[01:34] <sladen> Keybuk / Kamion: the code to check for 64bit is already in gfxboot.  Use the primitive/keyword '64bit'   (yes, it's the only "keyword" that starts with a number.  *sigh*
[01:34] <Keybuk> oh, cool
[01:35] <sladen> so, now you want laptop-detect in there?
[01:36] <Keybuk> \o/
[01:43] <ogra> hmm, the oops is gone after a reboot
[02:07] <sivang> hmm, why can't I see ubuiguity in the dapper archive?
[02:08] <crimsun> (where are you looking?)
[02:09] <crimsun> [hopefully http://archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/] 
[02:10] <sivang> yes, thanks
[02:11] <sivang> should get to sleep
[02:11] <sivang> ;)
[02:11] <tseng> man
[02:11] <tseng> isnt it almost morning there now?
[02:11] <sivang> almost :)
[02:11] <sivang> 3:15am
[02:12] <tseng> you're sick
[02:12] <sivang> I know :p
[02:12] <sivang> I just can't stop .. writing specs can be adictive 
[02:13] <sivang> to be more precise, the investigation for them.
[02:13] <sivang> hmm, I need stratus. /me joins debian-devel
[02:16] <sivang> tseng: trying to gues when package wil lcome for python-notify
[02:19] <sivang> anywaym I'm oyut. some sleep is needed. urgently :)
[02:19] <sivang> night all!
[02:20] <ajmitch> afternoon
[02:21] <desrt> word.
[02:23] <mjg59> desrt: Managed to get any further?
[02:23] <desrt> mjg59; no.  i have new fish to fry
[02:24] <desrt> stuff is acting really really oddly
[02:24] <desrt> sometimes when i come back from sleep video isn't working properly (like vbestate doesn't restore properly or something)
[02:24] <desrt> i just came back to my machine after it running for a while and the keyboard (but not the mouse) had stopped working
[02:24] <desrt> and (possibly the cause of all of these things) the harddrive is seriously messed up
[02:25] <desrt> on resume i get
[02:25] <desrt> ata1: resume device
[02:25] <desrt> ata1: disabling port
[02:25] <desrt> then it fails this assertion:
[02:25] <desrt>         assert (ata_dev_present(master) || ata_dev_present(slave));
[02:25] <desrt> (twice)
[02:25] <desrt> then my harddrive is gone so anything not in the filesystem cache is not accessible
[02:25] <mjg59> Well, the assertion is unsurprising
[02:25] <desrt> and my filesystem remounts read-only
[02:26] <mjg59> Given the initial failure
[02:26] <desrt> not.
[02:26] <desrt> the 'disabling port' thing can come from only two possible failures
[02:26] <desrt> i googled it and found your name on an LKML posting
[02:26] <desrt> my problem seems to be that the bus reset that accompanies the resume is failing for some reason
[02:27] <mjg59> Hm
[02:27] <mjg59> Debug code a-go go
[02:27] <desrt> well
[02:27] <desrt> it doesn't always happen
[02:27] <desrt> plus...
[02:27] <desrt> sometimes the drive is flaky even before i sleep
[02:27] <desrt> like i'll boot into gnome
[02:27] <mjg59> Less fun
[02:27] <desrt> (first time)
[02:27] <desrt> and processes will randomly go into D-state
[02:27] <mjg59> Any dmesg errors?
[02:27] <desrt> which i (perhaps foolishly) assume is drive messup
[02:27] <desrt> no dmesg errors :(
[02:28] <desrt> do you know of flags i might be able to give to the kernel to make it run the sata controller in a slower-and-safer mode?
[02:29] <mjg59> Nope
[02:29] <mjg59> I don't think sata rally has that concept
[02:29] <desrt> 193:       7767          0   IO-APIC-level  libata, uhci_hcd:usb2, ohci1394
[02:29] <desrt> hmm.
[02:29] <desrt> libata shares IRQ with my usb port
[02:29] <mjg59> Should be fine
[02:29] <desrt> i wonder.....
[02:29] <desrt> well, maybe that's why my keyboard stops
[02:29] <mjg59> Though I wonder more if it's another irq issue
[02:29] <mjg59> Like your acpi one
[02:30] <desrt> 201:     296839          0   IO-APIC-level  uhci_hcd:usb1, ehci_hcd:usb5
[02:30] <desrt> keyboard appears to be on this usb though :
[02:30] <desrt> :/
[02:30] <desrt> (up-enter, up-enter repeatedly increments that counter)
[02:30] <mjg59> Wonder if the interrupt controller is being set up correctly
[02:30] <desrt> a valid wonder.
[02:30] <mjg59> Does it boot with noapic?
[02:30] <sladen> Keybuk: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.dapper/ is meant to be empty?
[02:31] <desrt> yes.  but with noapic it locks up on resume
[02:31] <Keybuk> it's not empty
[02:31] <desrt> (remember you had me try this)
[02:31] <Keybuk> celebrate the fantastic bzr archive format
[02:31] <Keybuk> (it has a .bzr)
[02:31] <Keybuk> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.dapper/.bzr/README
[02:31] <sladen> oh, you're right, there's a .bzr
[02:32] <desrt> mjg59; i hate laptops. :(
[02:32] <mjg59> desrt: Haha
[02:32] <desrt> why does linux have to have so many bugs in it?
[02:33] <HrdwrBoB> why do you have to buy an unsupported machine
[02:33] <desrt> it's so pretty
[02:33] <tseng> haha
[02:34] <bddebian> heh
[02:35] <desrt> anyway... i guess i'll instrument my kernel like crazy
[02:35] <desrt> figure out the exact source of this problem
[02:35] <desrt> the only problem is that at the time the kernel borks out i have no way of writing down the info from dmesg
[02:35] <desrt> other than to remember it in my head (or if i have paper close at hand)
[02:36] <desrt> wtf is libata-acpi.c?
[02:36] <mjg59> Binds acpi resume methods to libata
[02:36] <desrt> i see.
[02:37] <desrt> how interesting.
[02:37] <desrt> why doesn't it just have a normal suspend/resume function?
[02:38] <mjg59> Because laptops can be wired in strange and wonderful ways
[02:38] <desrt> i hate laptops.
[02:38] <mjg59> Bay devices may need powering up in fun ways, for instance
[02:47] <desrt> mjg59; think it might be caused by the drive not powering up fast enough?
[02:53] <desrt> ok.  just as a test i booted it up with the harddrive removed
[02:53] <mjg59> desrt: Doubt that
[02:53] <desrt> it behaves -exactly- like the error condition i described
[02:53] <desrt> like, sleep [remove hd]  resume
[02:53] <mjg59> Right
[02:53] <desrt> i'm ircing from it right now with the HD out :)
[02:53] <mjg59> Weird
[02:53] <desrt> well
[02:53] <desrt> it's got a gig of RAM
[02:54] <desrt> that's a lot of cache space
[02:54] <mjg59> I need to spend some time looking into libata suspend/resume stuff
[02:54] <desrt> would it be safe to sleep the kernel for 2-3 seconds inside the ata resume code?
[02:55] <mjg59> Should be
[02:58] <mgalvin> here we go
[02:58] <mgalvin> ok no more cheesy lines...
[02:58] <jsgotangco> ?
[02:58] <mgalvin> :)
[02:59] <mgalvin> is there any info about the *-proposed archives?
[02:59] <mgalvin> jsgotangco: edgy uploads started a little while ago :)
[02:59] <desrt> would i use a normal sleep or a spinning sleep?
[02:59] <jsgotangco> ZOMG
[02:59] <jsgotangco> heh
[02:59] <Keybuk> mgalvin: none, and we're the archive team
[03:00] <Keybuk> someone in Launchpad claimed to know something about them, but didn't want to talk about it
[03:00] <mgalvin> i mean there name is obvious but...
[03:00] <mgalvin> Keybuk: ah ok
[03:00] <ajmitch> mgalvin: patience, we have to wait for glibc & gcc to break everything
[03:00] <Keybuk> I believe they're a free-for-all upload place for things that might, one day, be uploaded to -updates
[03:00] <bddebian> ajmitch: :-)
[03:00] <Keybuk> ajmitch: I've been running both all evening, they're _fine_
[03:00] <mgalvin> sweet
[03:00] <Keybuk> that's not so fine
[03:00] <Keybuk> but we don't worry too much
[03:01] <ajmitch> I've been running the edgy kernel, but not the rest :)
[03:01] <bddebian> Got Xorg 7.1? :-)
[03:01] <ajmitch> Keybuk: it's no fun if *something* doesn't break in the first few hours
[03:01] <bddebian> To what?  Edgy-changes?
[03:01] <Keybuk> mgalvin: basically, afaiui, proposed is a place for people to upload bug fixes for a released release
[03:02] <Keybuk> but it's not mentioned in /etc/apt/sources.list, so is only available to people who really need to look for a package there
[03:02] <Keybuk> so there is less restriction than -updates, which is enabled by default
[03:03] <mgalvin> Keybuk: ah, great thanks :)
[03:03] <Keybuk> desrt: on your back
[03:06] <bddebian> heh
[03:08] <desrt> msec_delay_irq() appears correct
[03:25] <desrt> oi modules
[03:31] <desrt> mjg59; wanna know something funny?
[03:32] <desrt> mjg59; i think the excessive irq9 traffic was a good thing
[03:32] <desrt> mjg59; it slowed the box down on resume
[03:33] <desrt> mjg59; with my delay inserted i've done half a dozen suspend/resume cycles and i can't get the drive to fail to initialise
[03:39] <desrt> heh.  NetworkManager isn't liking all the suspend/resume action.
[03:39] <desrt> cpu -> 100%
[03:39] <Keybuk> yeah, it does that
[03:39] <Keybuk> see the 5th or 6th bug page
[03:40] <desrt> welp
[03:40] <desrt> 12th resume, no problems
[03:41] <desrt> i think that's the cause of this bug
[03:45] <desrt> now all that remains is the stupid D-state bug
[04:22] <stuNNed> what can i do to get my creative microphoto to work in latest stable ubuntu? i randomly picked it up at bestbuy and gnomad2 project says it is semi-functional but i can't seem to get the latest gnomad2 installed...i'd ask in the help chann but most of the those questions seem to be very install-relateed...maybe we need a #novice-ubuntu, #intermediate-ubuntu you guys think?
[04:22] <Burgundavia> stuNNed: if #ubuntu cannot help you, try the mailing list or the forums. This is not a suppor channel
[04:23] <stuNNed> burgundy: yeah yeah i'll try the lists i guess :\
[04:23] <stuNNed> it was the best best buy had to offer as far as linux compatability :(
[04:23] <stuNNed> fucking shame it is
[04:24] <Burgundavia> stuNNed: oh, and file a bug about it not working ootb
[04:25] <stuNNed> Burgundavia: i'm on it thanks
[04:25] <Burgundavia> stuNNed: cheers
[04:26] <stuNNed> burgundy: thanks, cheers
[04:26] <stuNNed> too bad i'm drinking coffee but i need it and it's a local blend :)
[04:35] <Chipzz> stuNNed: how is that install-related?
[04:36] <Chipzz> or are you trying to install ubuntu on this device? ;)
[04:38] <stuNNed> Chipzz: haha that would be the great and no.  i'm saying #ubuntu is too install-related as far as content and there should be #ubuntu-new, #ubuntu-mediate, and #ubuntu-expert or something...
[04:41] <Chipzz> I agree with you on #ubuntu-expert ; in fact I've made an argument for such a thing here in the past
[04:41] <Chipzz> but it's a 2 way cutting sword
[04:42] <Chipzz> 1) you split up support resources
[04:43] <Chipzz> 2) you'll always have newbies who feel that for some reason, the rules do not apply to them, and will join ubuntu-expert and start asking newbie questions there
[04:50] <stuNNed> if i want a bleeding edge ubuntu friendly kernel can i get this?
[04:50] <stuNNed> well...your support resources should not center on irc imho
[04:56] <mjg59> stuNNed: See https://wiki.ubuntu.com/KernelGitGuide
[04:57] <mjg59> Current git has 2.6.17 in
[04:58] <stuNNed> mj: thanks mate
[05:15] <stuNNed> this git thing looks nice, things have developed/moved forward since last time i touched linux/ubuntu, anyone know of a good general ppc linux download site?
[05:15] <Burgundavia> stuNNed: what sort?
[05:18] <stuNNed> burgundy: i found one thanks: http://penguinppc.org/
[05:20] <bddebian> stuNNed: Debian.  YellowDog.
[05:21] <bddebian> Ubuntu :-)
[05:21] <Burgundavia> bddebian: yellow dog is mostly big iron these days
[05:22] <bddebian> Burgundavia: Really?
[05:22] <bddebian> They used to have the best PPC thing going.. Hmm
[05:22] <Burgundavia> they still are, bigiron ppc
[05:22] <stuNNed> bddebian: i don't get it
[05:22] <stuNNed> bddebian: are you salesperson?
[05:22] <bddebian> Ah, like RS/6000 type?
[05:22] <jsgotangco> really?
[05:22] <bddebian> stuNNed: Don't get what?
[05:23] <stuNNed> bddebian: your words
[05:23] <Burgundavia> jsgotangco: one of the guys from our local lug works for them
[05:23] <jsgotangco> ahh
[05:23] <bddebian> stuNNed: Ah, just ignore me then :-)
[05:24] <Burgundavia> jsgotangco: he does desktop stuff for them, but he says he is the only one left
[05:24] <infinity> stuNNed: Ubuntu/PPC works well.
[05:24] <infinity> Oddly enough.
[05:24] <Burgundavia> infinity: no, really?
[05:25] <fabbione> hmmm
[05:25] <fabbione> jdub: ping?
[05:26] <stuNNed> infinity: i didn't ask that at all.  you drifted into what bddebian said.  i asked of a good url that has ppc software besides what is available in ubuntu but i probly don't need it so :P
[05:27] <bddebian> Ah, then I (we?) mis-understood your question
[05:27] <infinity> stuNNed: About the only thing some place like linuxppc would have that we don't ship is stuff built for MacOS (like, say, BootX)..
[05:28] <bddebian> infinity: OldWorld?
[05:29] <infinity> bddebian: Yeah, Beige G3.
[05:29] <bddebian> Ah
[05:29] <bddebian> Yeah, that's a bitch.  I still have an old WallStreet PowerBook laying around here somewhere
[05:35] <LaserJock> shesh
[05:36] <LaserJock> I just want an Ubuntu box available all day
[05:36] <bddebian> I got 9 PC's running here now, what's a few more? :-)
[05:36] <tritium> bddebian: why get a B&W G3?  Get a BMW M3 :)
[05:36] <LaserJock> 9?!?!?
[05:36] <LaserJock> tritium!
[05:37] <bddebian> tritium: I could go for that too :-)
[05:37] <tritium> LaserJock: :)
[05:37] <bddebian> LaserJock: +1 dead Debian StinkPad :-)
[05:38] <bddebian> +3 now 3 Ubuntu boxes at work :-)
[05:38] <LaserJock> :(
[05:39] <LaserJock> my 1.3GHz P4 (my only Ubuntu box at work) got stolen by an undergrad
[05:39] <bddebian> No kidding?  That sucks
[05:39] <LaserJock> and my Ubuntu computers at home are usually turned off
[05:40] <LaserJock> well, he wanted a mac, so it wasn't too bad
[05:40] <LaserJock> I can still ssh into a bit
[05:40] <bddebian> Mine should be.  My electricity bill is outrageous :-)
[05:40] <LaserJock> yeah
[05:40] <bddebian> Not as bad as when I had the Proliant 3000 running though :-)
[05:40] <bddebian> That thing was a pig
[05:42] <ajmitch> and I just have 2 machines that run at home...
[05:43] <bddebian> ajmitch: Well 4 of them are Hurd boxen so they aren't up much.. ;-P
[05:43] <LaserJock> lol
[05:43] <infinity> I don't generally believe in turning computers off...
[05:43] <ajmitch> neither do I, except for general hardware failure
[05:44] <infinity> I just don't like killing hard drives.
[05:44] <infinity> Which seems to happen every second time I hit a power switch.
[05:45] <infinity> (Interesting side note: If an old drive motor suddenly decides to stop spinning, feeding it 24 volts on the 12 volt line will sometimes get it spinning long enough to rescue the data... Before it seizes)
[05:46] <infinity> Don't try that at home, kids.
[05:46] <ajmitch> how long before it starts to smoke?
[05:46] <bddebian> Put it in the freezer :-)
[05:47] <dieman> infinity: crazy
[05:47] <dieman> freezer ive heard a lot too
[05:47] <infinity> ajmitch: The last time I did it, it started smoking a bit about halfway through the copy job.  No flames were seen, however.
[05:47] <ajmitch> I'd assume the drive controller would be running off the 5V line stil
[05:47] <infinity> Yes, generally.
[05:48] <infinity> The electronics are a bit delicate to overvolt.
[05:48] <infinity> The motor, though, has it comin' when it goes and stops spinning.
[05:48] <bddebian> heh
[05:50] <dieman> hahaha
[05:50] <mjg59> What could possibly go wrong?
[05:50] <dieman> amazon prime fucked up
[05:50] <dieman> and they shipped my package late
[05:50] <dieman> so they upgraded me to next day for free
[05:51] <ajmitch> it's also great to read what *must* be in edgy (or the world will end)
[05:51] <dieman> i think porn must be in edgy
[05:51] <dieman> or else
[05:51] <bddebian> heh
[05:52] <dieman> my coworkers took great enjoyment in the porn desktop
[05:53] <Burgundavia> must have initNG!!! must have Thunderbird!!
[05:54] <infinity> Thunderbird?
[05:54] <infinity> What, the minor bump from 1.5.0.2 to 1.5.0.4 is killing people?
[05:54] <bddebian> Oh yeah baby
[05:54] <dieman> i think i'll die if nm doesn't speak gprs by next tuesday, really.
[05:54] <ajmitch> must have xgl by default!
[05:55] <dieman> also, aiglx
[05:55] <dieman> at the same time
[05:55] <Burgundavia> no, thunderbird over evo
[05:55] <dieman> not surprising there
[05:55] <Burgundavia> and KDE and GNOME on the same cd, with a question in the installer
[05:55] <mjg59> And a pony
[05:55] <dieman> i can't even really endorse my wife using evo these days
[05:55] <Burgundavia> i suffer through it
[05:56] <Burgundavia> tb is just as bad, in different ways
[05:56] <bddebian> mjg59: :-)
[05:56] <dieman> yah
[05:56] <mjg59> Someone needs to stop evo from sucking, because in a lot of ways it's much nicer than Thunderbird
[05:56] <dieman> i get tb to crash like once a month
[05:56] <dieman> evo doesn't have sort by group, i think
[05:56] <Burgundavia> they just need some vision
[05:56] <mjg59> Little things. Like using evolution-data-server
[05:56] <dieman> does it have labels?
[05:56] <tritium> mjg59: agreed
[05:57] <Burgundavia> eeds looks exciting
[05:57] <dieman> it'd be nice if evo was a collection of seperate apps
[05:57] <bddebian> eeds?
[05:57] <dieman> eeds?
[05:57] <jsgotangco> lunch brb
[05:58] <Burgundavia> embedded eds, done by openedhand for maemo
[05:59] <bddebian> Yeah, clears that right up ;-P
[05:59] <Burgundavia> http://projects.o-hand.com/eds
[05:59] <Burgundavia> http://projects.o-hand.com/
[05:59] <Burgundavia> they are doing cool things there
[06:00] <dieman> nifty
[06:00] <mjg59> Why isn't evo showing me the guadec calander?
[06:00] <dieman> because you aren't using a mac? ;)
[06:02] <bddebian> Ah, that is some cool little apps
[06:03] <Burgundavia> bddebian: the dates and contacts stuff are rocking
[06:03] <Burgundavia> honestly we might want to consider them for edgy
[06:04] <Burgundavia> bddebian: can i make you package them for universe at least?
[06:05] <tritium> Where has bob2 been?
[06:10] <mjg59> That's better. Killing e-d-s has made it happier.
[06:10] <mjg59> tritium: An excellent question
[06:10] <mjg59> If you find out, can you let us know?
[06:11] <ajmitch> tritium: noone has seen him for quite awhile
[06:11] <tritium> If I find out, yes, but...
[06:12] <tritium> speaking of e-d-s, I finally figured out I _have_ to save my password in evo to get alarm notifications and appointments in calendar applet to work
[06:12] <Burgundavia> tritium: that is dumb
[06:12] <tritium> This is a security no-no where I work
[06:12] <tritium> Burgundavia: yep
[06:13] <bddebian> Burgundavia: Sure :-)
[06:13] <Burgundavia> bddebian: excellent
[06:13] <bddebian> OK, bedtime for this old man.  Gnight folks
[06:13] <LaserJock> tritium: what, they don't let you put your password on you monitor at Sandia? ;-)
[06:13] <tritium> good night, bddebian 
[06:13] <LaserJock> cya bddebian 
[06:14] <tritium> LaserJock: heck, why not?  In good news, they've finally allowed the MacBook, once they clip the wires to the iSight camera
[06:14] <tritium> since it's a tool of espionage
[06:14] <Burgundavia> tritium: where do you work?
[06:14] <LaserJock> tritium: bahahahaha
[06:14] <tritium> Burgundavia: Sandia National Labs
[06:14] <LaserJock> I never thought of that
[06:15] <LaserJock> The Jordanian guy in my lab just uses it to talk to his buddies back home
[06:15] <Burgundavia> tritium: wow, "Securing the free and peaceful world through technology"
[06:15] <tritium> yep
[06:16] <Burgundavia> means you have nothing to do with developing technology that makes the world more peaceful or free :)
[06:16] <tritium> Burgundavia: there are many research areas, so don't be so sure
[06:17] <Burgundavia> sorry, just a cynical Canuck speaking here
[06:17] <Rotund> anyone know if there is an extension to X to play with the mouse "on the fly" like the driver options (buttons, etc)
[06:17] <tritium> No problem.  All the same, that's why I don't like to talk about it much
[06:18] <Burgundavia> tritium: indeed
[06:18] <robitaille> Burgundavia,  National Labs in the US do all sort of stuff (I worked 2 years at Berkeley National Lab)
[06:19] <Burgundavia> robitaille: yep, I saw that. Some of it looks very cool (fresh water stuff)
[06:19] <robitaille> but LBL is a different beast from Sandia
[06:20] <LaserJock> my lab collaborates with Sandia lab in Livermore, CA
[06:20] <LaserJock> totally not related to anything to DOE, but they pay for it so whatever
[06:20] <LaserJock> hehe
[08:14] <pitti> Good morning
[08:15] <ajmitch> morning pitti 
[08:16] <pitti> hi ajmitch 
[08:40] <makko> any particular reason dapper (unlike breezy!) does not support a graphical grub menu *by default*?
[08:42] <makko> \sh: any particular reason dapper (unlike breezy!) does not support a graphical grub menu *by default*?
[08:43] <\sh> makko: right question, wrong person :) I have no clue, actually I don't like graphical grub menus
[08:46] <makko> \sh: you are the right person! you are the only person that seems to be awake... and you just came.
[08:47] <makko> \sh: i am thinking of newbyes. they are prejudiced against text envs, especially when they come from the suse or mandriva world.
[08:47] <ajmitch> hey \sh, mvo 
[08:47] <fabbione> makko: please stop flooding this channel
[08:47] <makko> ajmitch: what about me?
[08:47] <fabbione> asking the same question twice in 2 minutes IS annoying
[08:49] <makko> fabbione: do i look like i am not aware of that?
[08:49] <fabbione> makko: apparently you are not aware of it, otherwise you would not have done it
[08:49] <\sh> makko: I'm not the right person, because I don't have a clue about graphical screens in grub, not even in breezy...you can ask me about pyqt and pykde or njam or whatever, but not grub...kthx
[08:50] <pitti> iwj: dapper-security works again, please feel free to upload firefox 1.5.0.4
[08:50] <makko> fabbione: no, i was aware of it, it's just that immediately after i asked that i saw \sh joining and i wanted \sh to get it too
[08:50] <makko> fabbione: you can follow the log and you'll see what i mean
[08:51] <fabbione> makko: and what does let you think \sh is the right person to ask?
[08:51] <fabbione> and yes i read the log and i saw the timing too
[08:51] <makko> fabbione: i really thought everybody was asleep and, since \sh was just comming, i assumed \sh was not :)
[08:52] <makko> fabbione: but sorry anyway
[08:52] <makko> fabbione: i know how it looks
[08:54] <makko> fabbione: by the way, do you have any idea whom i should ask that?
[08:55] <fabbione> makko: zul
[08:56] <makko> fabbione: thanks
[09:42] <siretart> uuuh, first edgy uploads. nice! - are the chroots already set up?
[09:44] <dholbach> good morning
[09:46] <infinity> siretart: Still bootstrapping, but that shouldn't stop people from uploading sources.
[09:57] <Kamion> makko: we didn't do grub gfxboot because it would have been terrifyingly unsafe for dapper, especially as syslinux gfxboot was known to have problems on some machines. So I said no.
[10:02] <makko_> Kamion: maybe this is why mandriva uses a patched lilo?
[10:03] <Kamion> makko_: in general pulling in graphical patches for bootloaders was not appropriate for dapper. I'm not interested in discussing it more than that just now.
[10:07] <makko_> Kamion: thank you.
[10:19] <arejensen> Hi. I think I might have found a bug in the pythoncard-tools package in universe. Im not quite sure if I should submit it using the ordinary webinterface? Ive tried searching the wiki and documentation but couldnt find any info on it.
[10:22] <crimsun> arejensen: better addressed in -motu or -bugs, but yes, please file a bug in Malone against that package
[10:22] <Mithrandir> just file a bug using Launchpad.
[10:24] <arejensen> Thank you very much crimsun and Mithrandir. -bugs said "Channel for Bugdays" so I thought it was only for bugsquashingfests or similar and not for normal use. :)
[10:26] <arejensen> <-- A bit tired. It said so on the homepage.
[10:33] <mdke> morning all
[10:34] <jsgotangco> morning!
[10:34] <sfllaw> morn-ing.
[10:34] <sfllaw> very sleepy.
[10:35] <mdke> heh
[10:35] <jsgotangco> ahh yes
[10:35] <sfllaw> It's 4:35 right now.
[10:39] <Hobbsee> that's insane.  i really would stay asleep for that.
[10:42] <sfllaw> No good.  I'm immune.
[10:42] <Treenaks> -e
[10:42] <sfllaw> Nice.
[10:45] <Treenaks> those should keep you awake ;)
[10:45] <Treenaks> (and loving everyone)
[10:45] <ajmitch> heh
[10:45] <ajmitch> morning sfllaw :)
[10:45] <ajmitch> good to see you up & about at this fine hour
[10:46] <sfllaw> ajmitch: Thanks.
[10:48] <Kamion> infinity: any idea why I got a pile of rejects for those breezy-security uploads?
[10:48] <Kamion> from katie
[10:48] <pitti> Kamion: I think all of them have been recovered already
[10:49] <Kamion> oh, hey, I got accepts for them all as well, wasn't reading properly
[10:49] <Kamion> thanks
[10:50] <infinity> Kamion: elmo got into a rather heated debate with katie, that's all.
[10:50] <infinity> And now I'm going to go have a similar argument with glibc.
[10:58] <Kamion> iwj: do you think you'll be able to merge dpkg this morning?
[10:59] <Kamion> Keybuk: I know you're probably not starting the big sync yet, but eyeballing and manually syncing libselinux and libsepol would be helpful
[10:59] <sfllaw> Oh no.  The sun's coming up.
[11:00] <iwj> Kamion: I would have said yes but I'd underestimated the number of specs we were supposed to be proposing, so I'll be working on that first and on the breezy ff security update.
[11:00] <Keybuk> Kamion: any particular reason?
[11:00] <iwj> Kamion: Do we have MoM working for it or is it manual ?  (Not a big problem, but MoM would save a bit of faff.)
[11:00] <Kamion> Keybuk: build-deps of dpkg which is needed for debhelper which is needed for d-i
[11:00] <Keybuk> it needs the new ones?
[11:01] <Kamion> iwj: that's a Keybuk question, but I believe not yet
[11:01] <Keybuk> ok
[11:01] <Kamion> Build-Depends: debhelper (>= 4.1.81), pkg-config, po4a, libncurses5-dev | libncurses-dev, zlib1g-dev (>= 1:1.1.3-19.1), libbz2-dev, libselinux1-dev (>= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] 
[11:01] <Kamion> libselinux1-dev | 1.28-2ubuntu2 |          edgy | amd64, hppa, i386, ia64, powerpc, sparc
[11:02] <Kamion> iwj: I could have a look and run the result by you, if that's preferable
[11:02] <Keybuk> once we have working chroots I'll confer with infinity whether he wants the fire hose on trickle or "OMG! THE ASWAN DAM HAS BURST!"
[11:02] <iwj> I don't mind but that might save time if you're in a hurry.
[11:02] <Kamion> yeah, it's just because the stack for me is quite deep
[11:03] <Kamion> (and tottering)
[11:03] <iwj> Kamion: I don't _think_ there should be anything controversial and they've taken nearly all of the patches I sent I think.
[11:03] <Kamion> I eyeballed it earlier in the week and spotted just one thing that wasn't merged
[11:03] <Kamion> but I'll do a more detailed review
[11:04] <mdke> sfllaw: perhaps when your body clock is back to normal we can hook up and have a word about the WelcomeCenter project?
[11:04] <sfllaw> mdke: Yes.
[11:05] <sfllaw> mdke: What TZ are you on?
[11:05] <sfllaw> I'm UTC-4.
[11:05] <mdke> sfllaw: UTC+1
[11:05] <mdke> that would be great
[11:05] <sfllaw> mdke: I'll ping you when I wake up.
[11:06] <sfllaw> With any luck, I won't catch you during dinner.
[11:06] <mdke> sfllaw: that sounds great, I'll keep my ears open
[11:11] <jdub> Kamion: have you tried bound branches yet? rocks!
[11:13] <Kamion> that's what I'm trying ...
[11:14] <Keybuk> "Houston, we have achieved ... CVS!"
[11:14] <Kamion> haha
[11:15] <Kamion> woo, bound-branch commits to the seeds work
[11:15] <Kamion> I think we should recommend that mode of operation
[11:16] <Kamion> it's much less prone to weird-shit pull/merge confusion
[11:16] <Kamion> recommend> for the seeds that is
[11:24] <infinity> Is there any way to force that mode of operation?
[11:24] <infinity> ie: Mark the parent repository as one that can't be pushed to, or something equally draconian?
[11:25] <Kinnison> Unfortunately not
[11:25] <Kinnison> IIRC
[11:26] <Keybuk> infinity: all bound-mode means it that bzr remembers to push after you commit
[11:27] <Kinnison> Keybuk: It's all a transaction
[11:27] <infinity> Keybuk: Right, but a way to force a branch to behave in a "centralised repository" fashion would be useful for rare cases where distributed RC is not ideal.
[11:27] <Kinnison> Keybuk: if it can't push then it uncommits locally
[11:27] <Kinnison> Keybuk: IIRC
[11:28] <Kinnison> Keybuk: either that or it unbinds and then to rebind you need to pull/push/merge to get the lines in sync
[11:30] <Keybuk> Kinnison: I think the commit fails and it suggests that you can unbind if you want and try again
[11:30] <Keybuk> infinity: agree
[11:31] <Kamion> it says "unbind, update, or commit --local" I believe
[11:32] <Kamion> commit/push is a transaction, yes, or at least so the docs say
[11:36] <Keybuk> aah!
[11:36] <Keybuk> NOW I HAVE COFFEE!
[11:37] <ogra> mdz, already asleep ? i'm not sure what to do with the debian ltsp branch
[11:43] <bytee_> infinity: ping 
[11:45] <infinity> pong.
[11:48] <bytee_> had a question with package naming
[11:49] <jdub> Keybuk: you can bzr get, as long as you bzr bind (which i think is clearer than 15 ways of bzr get/pull/checkout/obtain/adopt/acquire/kidnap/etc)
[11:49] <ajmitch> jdub: at least it's not baz
[11:50] <jdub> in soviet russia, baz branches you (like basil fawlty's car)
[11:51] <mdz> ogra: I am sleeping in 4-hour shifts these days
[11:51] <mdz> ogra: I need about an hour to catch up on other things, though; can you send me email about this?
[11:51] <jdub> mdz: http://fedoraproject.org/wiki/StatelessLinuxCachedClient
[11:51] <Kinnison> mdz: trying that bizarre multi-nap sleepcycle thing?
[11:51] <Kinnison> polyphasic sleep or whatever it's called
[11:52] <mdz> Kinnison: not intentionally, it's just worked out that way
[11:52] <Kinnison> mdz: heh
[11:58] <sivang> morning all
[12:03] <sivang> Znarl, elmo : ping
[12:04] <Znarl> sivang : Pong?
[12:04] <sivang> Znarl: Don't want to be pushy, but can anything be done to help RT #10636 ? :-)
[12:06] <Znarl> sivang : I will have it done in a few hours for you.
[12:06] <sivang> Znarl: thank you!
[12:13] <ogra> mdz, mail sent
[12:14] <Kinnison> Hehe
[12:14] <infinity> The great irony, of course, is that it was a base-files upload that had s/dapper/edgy/ ALL OVER IT, except for the changelog.
[12:14] <Kinnison> Now if I could work out why the Packages files for dapper are seemingly being rewritten I'd be happy
[12:15] <jono> hey all
[12:15] <infinity> Kinnison: apt-ftparchive config is wrong?
[12:15] <Kinnison> infinity: Not afaict
[12:15] <Kinnison> infinity: check it out in .../ubuntu-misc/apt.conf
[12:16] <Kinnison> infinity: also the log from the last run didn't claim to have written them
[12:16] <Kinnison> it's most odd
[12:16] <infinity> They've definitely changed recently.
[12:16] <Kinnison> Indeed
[12:16] <Kinnison> I'm exceedingly confused
[12:32] <Kinnison> infinity: bloody typical, they didn't get updated this cycle while I was watching
[12:35] <infinity> Kinnison: Err, yes they did.
[12:35] <infinity> Kinnison: They're only 15 minutes old.
[12:35] <Kinnison> Hmm, then they didn't get updated in the apt-ftparchive stage
[12:35] <infinity> (Or, exactly an hour younger than they were the last time I looked)
[12:36] <Kinnison> since that's when I looked
[12:36] <Kinnison> So they're being touched during one of the post-publish phases
[12:36] <Kinnison> OMG I've got it
[12:36] <Kinnison> They're identical to edgy right now
[12:36] <infinity> dupe checking?
[12:36] <Kinnison> dsync is deduping them to the edgy ones
[12:37] <infinity> That theory holds up when we see that amd64 (which has new binaries in it) hasn't been updated, while i386 has been.
[12:37] <infinity> So, as soon as I push this base-files through, the problem (but not the bug) goes away.
[12:38] <Kinnison> Indeed
[12:39] <infinity> Well, that probably means you can follow up to the bug and reduce it from critical to major.
[12:40] <infinity> I still suspect that dupe-checking should be skipped entirely for {Packages,Sources}. :)
[12:40] <infinity> It means that any empty files are getting "re-generated" at each go too, right?
[12:40] <infinity> (So, say, and empty dapper-security would be re-downloaded every hour)
[12:41] <infinity> s/and/an/
[12:41] <Kinnison> Probably
[12:44] <Kamion> iwj: http://people.ubuntu.com/~cjwatson/tmp/dpkg_1.13.21ubuntu1_debian.diff (new diff vs. Debian)
[12:50] <Kamion> iwj: http://people.ubuntu.com/~cjwatson/tmp/dpkg_1.13.21ubuntu1_ubuntu.diff.gz (new diff vs. Ubuntu Dapper, but enormous; 14MB uncompressed)
[12:55] <Kamion> I'm amazed we apparently never remembered to add amd64 to archtable
[12:59] <Kamion> Keybuk: mind if I sync libsepol and libselinux? I've test-built them (albeit with the dapper toolchain) and they're fine
[01:00] <Keybuk> sure
[01:00] <Keybuk> infinity: how are those chroots?
[01:04] <Kamion> hmm, looking at Debian #317082, we ought to get dpkg in ASAP anyway due to the shlibdeps changes
[01:05] <Ubugtu> Debian bug 317082 in libc6-s390x "Subject: libc6-s390x: missing depends on lib64gcc1" [Serious,Closed]  http://bugs.debian.org/317082
[01:07] <Mithrandir> ogra: what do you think about adding thinclient-local-devices to paris?
[01:07] <ogra> Mithrandir, https://wiki.ubuntu.com/EdubuntuEdgyIdeas ;)
[01:08] <Mithrandir> ogra: it's not marked for discussion in Paris.
[01:09] <Mithrandir> ogra: also, ActiveDirectoryIntegration is covered by NetworkAuth which ajmitch is working on as part of SoC.
[01:09] <ogra> Mithrandir, i wont mark it before i have all specs written, i'll do that for the whole bunch on that wikipage tomorrow
[01:09] <Mithrandir> ogra: ok
[01:10] <ogra> Mithrandir, only the stuff above the "Additional suggestions" line will be paris stuff
[01:10] <ogra> i'm aware fo AD work in the network auth spec :)
[01:13] <zul> heylo
[01:14] <pitti> hi zul 
[01:15] <pitti> BenC, zul: gates for *-security uploads are open, so please feel free to upload (once the two missing patches are applied)
[01:15] <Kamion> sladen: I knew about gfxboot's 64bit operator - that wasn't what I was asking for a patch for ;-)
[01:15] <Daemon> the AD integration would be excellent, I just went through the manual process today and while it's not too difficult, full integration / wizard driven setup would appeal to a lot of people
[01:16] <ajmitch> Daemon: using winbind?
[01:16] <Daemon> yep
[01:18] <zul> pitti: ok, i have to boot the hoary with the two missing patches which i should be able to do tonight i should be able to upload for hoary at least
[01:19] <pitti> great
[01:19] <infinity> Keybuk: Coming along... glibc/base-files on amd64 upset me, but moving on.
[01:19] <Kamion> dpkg landing now
[01:19] <Kamion> will dep-wait for a while
[01:19] <zul> pitti: but now i have to go blow away redhat on our mail servers ;)
[01:21] <Kamion> now for coffee, then debhelper ...
[01:21] <Keybuk> infinity: we don't even have new gcc yet? :p
[01:22] <infinity> It's happening.  Meh.  Relax. :)
[01:22] <Keybuk> I'm very relaxed
[01:23] <tseng> were libselinux and libsepol meant to go to dapper?
[01:23] <tseng> dapper-changes seems to think so
[01:23] <jdub> Kamion: heh, closes line on dpkg is fun ;)
[01:23] <sladen> Kamion: ah, I think keybuk wants the 64bit one and you want the laptop-detect one.
[01:24] <Keybuk> that's ... err ... interesting
[01:24] <Keybuk> where did they go?
[01:25] <Kamion> tseng: the .changes said edgy
[01:25] <Kamion> sladen: nobody asked me or I'd have told them
[01:26] <Kamion> OH
[01:26] <Kamion> /srv/launchpad.net/codelines/current/scripts/process-upload.py -d ubuntu -r dapper -C sync $DRYRUN $NOMAILS -v .
[01:26] <Kamion> from sync-queue/process-incoming.sh
[01:26] <Keybuk> jdub: mostly translations I'd expect ... dpkg tradition has always been a new bug for every po file update requested
[01:26] <Keybuk> Kamion: oh, wow
[01:26] <makko> any special reason ubuntu's /etc/bash.bashrc doesn't include "export HISTCONTROL=ignoreboth"?
[01:26] <Keybuk> I wonder whether gcc-defaults went to the right place, then
[01:27] <Kamion> Listing ubuntu/dapper (ACCEPTED) 2/2
[01:27] <Kamion> ---------|----|----------------------|----------------------|---------------
[01:27] <Kamion>    40811 | S- | libsepol             | 1.12-1               | 19 minutes
[01:27] <Kamion>          | * libsepol/1.12-1 Component: main Section: misc
[01:27] <Kamion>    40810 | S- | libselinux           | 1.30-1               | 19 minutes
[01:27] <Kamion>          | * libselinux/1.30-1 Component: main Section: libs
[01:27] <makko> would anybody prefer duplicate lines in their bash's history?
[01:27] <Kamion> ---------|----|----------------------|----------------------|---------------
[01:27] <Kamion> fuck's SAKE
[01:28] <Kamion> makko: it's configurable because you can configure it. HTH
[01:28] <makko> Kamion: i am terribly sorry
[01:28] <Kamion> makko: I'm not swearing at you
[01:28] <Kamion> I'm swearing at the STUPID SYNC SCRIPTS
[01:28] <makko> Kamion: i know, but i damaged your table, right?
[01:28] <Keybuk> oh, I _really_ want to know where gcc-defaults went
[01:28] <Kamion> watch me not care
[01:28] <Keybuk> it's not in ACCEPTED
[01:28] <Keybuk> and it's not in UNAPPROVED
[01:29] <Kamion> makko: IRC is lossy and stuff gets interleaved, I deal with it, you should too
[01:29] <Kamion> Keybuk: version?
[01:29] <makko> right...
[01:29] <Keybuk> 1.36
[01:29] <Keybuk> I'm making damned, damned sure that didn't end up in dapper by accident
[01:30] <Kamion> tseng: thanks for the heads-up, rejected from dapper
[01:31] <Keybuk> it's ended up in the pool
[01:31] <Kamion> the publisher is running ...
[01:31] <Kamion> it may well be in limbo still, but will end up in dapper I suspect
[01:31] <Keybuk> Kamion: that would have gone in last night
[01:32] <Kamion> oh, ok
[01:32] <Keybuk> when we rammed it through LP with a sledgehammer
[01:32] <Kamion> what on earth did you do to get "Accepted (via black hackery):" anyway?
[01:32] <Keybuk> before infinity found a user who could update the distrorelease table
[01:32] <Keybuk> Kamion: ~lp_publish/mail-again.sh
[01:32] <Kamion> like we did last summer
[01:33] <Kamion> oh-kay
[01:33] <makko> Kamion: well, i agree i can configure it and so can everybody, but i think it would be nice for us to add that by default, do you agree?
[01:33] <Kamion> I'll just not look shall I
[01:33] <Kamion> makko: no, I don't
[01:33] <mdz> jdub: interesting; that's how I would have done it too
[01:33] <Keybuk> Kamion: would you like to mentally erase the last few seconds of conversation? :p
[01:33] <mdz> jdub: (the stateless update thing)
[01:33] <makko> Kamion: could you please briefly explain to me why?
[01:33] <mdz> jdub: I suggest pointing fabbione and jbailey to that for mubuntu
[01:33] <jdub> mdz: ok :)
[01:34] <jdub> mdz: what's that m for?
[01:34] <Kamion> makko: because in case of doubt it's least-surprise for people if we stay close to the default
[01:34] <jdub> micro?
[01:34] <fabbione> mdz: ?
[01:34] <dholbach> -buntu?
[01:34] <Keybuk> buntu
[01:34] <Kamion> and I can see why people might want it the other way
[01:35] <fabbione> jdub: mind to enlight me?
[01:35] <jdub> fabbione: mailng you now
[01:35] <fabbione> jdub: ok thanks
[01:38] <Keybuk>    id   | distrorelease | pocket | status
[01:38] <Keybuk> --------+---------------+--------+--------
[01:38] <Keybuk>   90205 |             6 |      0 |      2
[01:38] <Keybuk>  120614 |             7 |      0 |      2
[01:38] <Keybuk>  120643 |             6 |      0 |      2
[01:39] <Keybuk> so it thinks gcc-defaults 1.36 is in, err, dapper
[01:39] <Keybuk> HOLY CRAP
[01:40] <Keybuk> we're so damned lucky LP is not sure whether it's generating dapper Packages files today
[01:41] <Keybuk> Kamion, infinity: do you think we should shut down the publisher for a bit?
[01:41] <Kamion> hell yes
[01:41] <Kamion> we need to audit dapper now
[01:42] <pitti> oh, should I better stop publishing security updates then?
[01:42] <Keybuk> publisher is down
[01:42] <sladen> if it got as far as the mirror;  you might want to kill rsyncd to stop it spreading
[01:42] <Keybuk> and is not running
[01:42] <Keybuk> sladen: I don't mind if it's just the pool that has been mirrored
[01:43] <sladen> Keybuk: you might be concerned if it's the Release file
[01:43] <Keybuk> that's the kind of thing I'm just starting to look at
[01:44] <Keybuk> need to see how far this has spread
[01:45] <Keybuk>  120644 |               103625 |             6 |      0 |      2
[01:45] <Keybuk>  120643 |               103626 |             6 |      0 |      2
[01:45] <Keybuk>  120642 |               103627 |             6 |      0 |      2
[01:45] <siretart> http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-defaults/gcc-defaults_1.36.dsc does exist
[01:45] <Kinnison> Launchpad is *NOT* generating dapper packages files
[01:47] <Keybuk> ok
[01:47] <Keybuk> confirmed in the database, it's just those three syncs
[01:47] <Keybuk> gcc-defaults, java-gcj-compat and ecj-bootstrap
[01:48] <Keybuk> Kamion: looks like you rejected libselinux/libsepol in time
[01:48] <Kamion> yep, was fairly sure I had
[01:49] <sivang> hmm, I just got an edgy changes mail :)
[01:51] <infinity> Keybuk: You're going to fix those before I get around to wanting to build them, right? :)
[01:51] <Keybuk> infinity: first we fix the archive
[01:52] <infinity> Picky, picky.
[01:54] <Kamion> debhelper will be fun, it has new-X-in-Debian assumptions
[01:54] <mdz> Kamion: hmm?
[01:56] <Kamion>   * dh_installxfonts: /etc/X11/fonts/X11R7 is deprecated, back to looking in
[01:56] <Kamion>     old location, and not passing --x11r7-layout to update-fonts-alias and
[01:56] <Kamion>     update-fonts-scale (but still to update-fonts-dir). Closes: #366234
[01:56] <Kamion> that sort of thing
[01:57] <siretart> pitti: is dapper-security still via dak or via launchpad?
[01:57] <pitti> siretart: still the dak dance
[01:58] <siretart> pitti: anyway. congrats pitti :)
[01:58] <pitti> i. e. dak -> dak buildds -> special LP upload -> lp processing
[02:01] <infinity> Kamion: We only have one font location change to migrate to match with Debian, afaik.
[02:01] <infinity> Kamion: And that should be handled in our X packages, not in debhelper.
[02:03] <Kamion> infinity: right, the problem is that dh_installxfonts generates packages that call update-fonts-dir --x11r7-layout
[02:03] <Kamion> infinity: will we error out on that?
[02:03] <Kamion> or can we just assume that we'll update whatever provides update-fonts-dir before anything that calls dh_installxfonts?
[02:03] <infinity> Kamion: Err, the entry you quoted says that it DOESN'T call that.
[02:04] <Kamion> "but still to update-fonts-dir"
[02:04] <infinity> Oh, I missed that.
[02:04] <infinity> Feh.
[02:04] <infinity> Poke me about it tomorrow, and we'll make sure debhelper versus X won't explode?
[02:04] <Kamion> I could just merge xfonts-utils myself
[02:04] <infinity> Or do that. :)
[02:05] <Kamion> I want to get this sorted out in my current awake-cycle, if that's OK, because debhelper's needed for d-i
[02:08] <Mithrandir> does tasksel support debtags?
[02:08] <Kamion> dunno, what would be involved in that?
[02:09] <Mithrandir> I'm browsing spec suggestions to see if there are any interesting ones in there and came across https://launchpad.net/distros/ubuntu/+spec/debtags
[02:09] <Kamion> Keybuk: sometime that's not RIGHT NOW, you probably want to fix the new dh_installudev to match your policy
[02:10] <Keybuk> there's a dh_installudev?
[02:10] <Keybuk> ok
[02:10] <Keybuk> is it still chained to the wall of Marco's wrongness?
[02:10] <Kamion> Mithrandir: I don't think anyone's ever done that in Debian, no
[02:10] <Kamion> Mithrandir: but if we do tasksel, then I was intending for it to be linked to seeds
[02:11] <Kamion> Keybuk: yes, WRT /etc/udev/ and symlinks in rules.d
[02:11] <Mithrandir> Kamion: with each task being its own seed?
[02:11] <Kamion> Mithrandir: something like that; I haven't thought it out in depth yet
[02:11] <Keybuk> Kamion: ok, do you want me to fix it before you upload debhinderer?
[02:12] <Kamion> Keybuk: if you want to send me a patch against debhelper-in-Debian now, I can apply it to the thing I'm rolling together
[02:12] <Keybuk> Mithrandir: ooh, thanks for reminding me *add-to-meeting*
[02:12] <Keybuk> Kamion: I'll do it when the fires are out :p
[02:12] <Kamion> the problem with debhelper is that you have to coordinate with EVERYONE
[02:12] <Keybuk> so ~10 mins
[02:13] <\sh> so edgy will be only 4 months development time, right? 
[02:14] <Hobbsee> !!!  LP added "search by recently changed"  - AWESOME!
[02:14] <Kamion> \sh: 4.5 months, yes
[02:15] <\sh> rocking
[02:17] <jdub> smart doesn't seem to grok dpkg holds
[02:17] <kiko> niemeyer wants to hear about that.
[02:18] <mdz> sivang: there seem to be both home-user-backup and edgy-home-user-backup specs, with nearly identical summaries
[02:18] <mdz> sivang: both proposed for paris
[02:19] <enrico> Mithrandir: the idea to implement that was to add a post-hook to apt-get update that would mark as 'to install' all packages matching a given tag expression.  Then when you run the package manager, it would do conflict resolution and so on
[02:19] <sivang> mdz: yes, sorry, Keybuk was supposed to drop one of them for me. Please decline the edgy-*... , I eventually left it and made changes onto the original one, to allow for all the original subscribers to still track development
[02:19] <Keybuk> sivang: you never told me which one
[02:19] <Keybuk> you /quit
[02:19] <sivang> Keybuk: ah, sorry, network issues probably :( 
[02:19] <sivang> then my bad
[02:21] <Mithrandir> infinity: would discussing https://launchpad.net/distros/ubuntu/+spec/early-userspace/ in Paris make sense?
[02:25] <infinity> Mithrandir: I intend to do some initramfs work in edgy, especially dm-crypt and fakeraid stuff, but I'm not sure how much discussion it really needs.
[02:31] <tseng> Kamion: no problem.
[02:31] <pitti> ajmitch: still here?
[02:34] <ajmitch> yep
[02:35] <ajmitch> pitti: what's up?
[02:35] <pitti> ajmitch: will you be in Paris?
[02:35] <pitti> ajmitch: I wonder whether it makes sense to register an SSP spec
[02:36] <ajmitch> no, I won't be there, sorry
[02:36] <pitti> ajmitch: we should get some thorough tests going in edgy, and if it's successful, enable it by default in edgy+1
[02:36] <ajmitch> a spec still sounds like a good idea :)
[02:36] <ajmitch> yagisan has been doing a bit with that lately
[02:37] <pitti> ajmitch: we already have two proactive security related specs, but they are way too big and need to be split
[02:37] <mvo> hello enrico, I suppose you got my mail then :) ?
[02:37] <ajmitch> pitti: I'm going to try & rewrite the selinux spec at least
[02:37] <enrico> mvo: yes!  I was at work and I still haven't had the time to reply, but in short: YAY!!
[02:37] <pitti> ajmitch: we have proactive-security-stage-1 and proactive-security
[02:38] <enrico> mvo: I'm glad Dapper released and people got a bit of spare time ;)
[02:38] <ajmitch> fun
[02:38] <pitti> ajmitch: I'll create an ssp spec and register it for Paris
[02:38] <mvo> enrico: cool, thanks. I hope to be able to do some other smallish improvments too
[02:38] <ajmitch> ok, I'll try & participate by voip or irc :)
[02:38] <pitti> ajmitch: I'll talk about it with doko and jbailey (and infinity perhaps, for a parallel test archive)
[02:38] <pitti> ajmitch: that would be nice :)
[02:39] <enrico> mvo: mornfall has been having a look at the code
[02:39] <mvo> enrico: ah, nice. I'll be happy to hear his feedback
[02:40] <mvo> enrico: I'm not religious about the way it is done, any suggestions/feedback is welcome
[02:40] <zul> ajmitch: paris is going to have voip?
[02:40] <zul> doh..
[02:41] <ajmitch> zul: I heard that something may happen
[02:44] <mvo> Mithrandir: will there be a multiarch spec?
[02:44] <jdub> 'apt in universe' > 'smart in edgy' ;-)
[02:45] <mvo> jdub: be careful what you wish for ... it might get it ;)
[02:45] <jdub> mvo: 8)
[02:47] <mvo> mdz: the "smart-notifier" from you list is a update-notifier based on smart? or something else entirely?
[02:47] <Keybuk> ok
[02:47] <Keybuk> dapper crisis averted
[02:47] <Keybuk> the packages are now where they should be
[02:48] <Mithrandir> mvo: I'm not sure; 4.5 months is really not enough time to do it.
[02:48] <pitti> ajmitch: https://launchpad.net/distros/ubuntu/+spec/gcc-ssp, feel free to subscribe
[02:48] <pitti> ajmitch: btw, do you have any plans wrt. selinux?
[02:48] <ajmitch>  yes
[02:48] <Kamion> Keybuk: ok, dh_installudev reminder then :)
[02:49] <ajmitch> work with manoj, erich & rjc in debian, hopefully get stuff by feature freeze :)
[02:49] <Keybuk> Kamion: yup, just switching state
[02:52] <mvo> what was the consensus about SoC work? they should only be added if the person comes to paris, right?
[02:53] <mdz> mvo: no, it's something else entirely (apt-cache show smart-notifier)
[02:53] <jdub> mvo: "your disk is dying - stop upgrading all the time!"
[02:55] <ajmitch> mvo: hm, I added mine to the sprint anyway. I guess it could be removed
[02:55] <mvo> mdz, jdub: aha, that sounds useful
[02:55] <ajmitch> since the majority of it was agreed on at ubz
[02:59] <tseng> pitti: reading your ssp spec
[03:00] <pitti> it's not yet a spec :)
[03:00] <tseng> ok :)
[03:00] <tseng> do you have an idea of how to do it per package?
[03:00] <tseng> or the reverse
[03:01] <tseng> oh, subarch
[03:01] <tseng> ignore me
[03:05] <Keybuk> Kamion: cron is going down for a bit again
[03:05] <Keybuk> so unless you're particularly desperate, I'll do the dh_installudev bit after lunch
[03:06] <jsgotangco> good evening
[03:08] <mornfall> enrico: i'm in the right ubuntu-devel? :)
[03:08] <mornfall> mvo: i had a quick look at the code, nothing deep, my only concern is how can i point apt at ddtp.debian.org for translations and something else for Package indexes
[03:09] <Kamion> Keybuk: ok, I've been trying to figure out how packages actually use it
[03:09] <mvo> mornfall: this is currently not supported, the translations have to be at the same place as the other stuff. a anoying limitation
[03:09] <mornfall> but i suspect we are hitting sort of fundamental issues with sources.list
[03:09] <enrico> mornfall: right, you're in the right one
[03:10] <Kagou> hi
[03:10] <mvo> mornfall: does the other stuff (update moved into libapt) look useful to you?
[03:10] <mvo> i.e. will it help ?
[03:10] <mornfall> mvo: i have only fetched the ddtp branch for now (bzr takes *insane* amount of time to get branches)
[03:10] <mornfall> mvo: from your mail (enrico bounced it to me) i think it should be OK
[03:10] <jsgotangco> mvo: hi! any tip on where to start debugging on a segfault to apt on a fresh dapper kubuntu?
[03:11] <mvo> mornfall: yeah, it should be a bit better once I converted all my branches to the new bzr 0.8 format
[03:11] <mvo> jsgotangco: a gdb backtrace would be a good start :) put it on a pastebin please
[03:11] <jsgotangco> thanks
[03:12] <mvo> mornfall: cool, thanks
[03:12] <mvo> mornfall: I hope that the ddtp stuff gets up to some speed now that they have a working server again. that would be really good. I'm not religious about the implementation, the advantage is that it is here and seems to work reasonable well
[03:12] <mornfall> mvo: any plans to push all this into say debian experimental?
[03:13] <mvo> mornfall: it is in experimental already (the ddtp bits) - the update stuff is only a couple of days old, I wanted to wait for your/enricos feedback first :)
[03:13] <mornfall> mvo: hmm i must have missed it then, that's why i fetched from bzr
[03:14] <mornfall> mvo: well let me run bzr get for the update stuff and you can have more feedback when i get home in some half hour (which should be enough for bzr to finish :)
[03:15] <mornfall> mvo: the branch is ListUpdateMethod?
[03:15] <mvo> mornfall: yes, that is the branch. thanks, no rush :) 
[03:15] <Kamion> Keybuk: you'll need to tweak the default priority and the way it automatically adds "_" (we want "-")
[03:21] <sladen> Keybuk: would the udev bug also cause NIC to be renumbered.  at some point eth0 and eth1 swapped.
[03:21] <sladen> Keybuk: but I can't place when
[03:21] <mdz> pitti: are we going to try enabling SSP in edgy?  if so, during or after this initial round of toolchain updates?
[03:22] <pitti> mdz: incidentially I just added a spec for that :)
[03:22] <mdz> pitti: oh good, what's the name?  it's on my list and I'd like to link to it
[03:22] <pitti> mdz: my feeling is to selectively enable it for some packages in edgy and do a test-build of the archive, and if that works, switch over in edgy+1
[03:22] <pitti> mdz: https://launchpad.net/distros/ubuntu/+spec/gcc-ssp
[03:26] <tseng> it is unfortunate that people are insistant on turning any proactive security roadmap into a giant spagetti monster that pulls in every technology on the market
[03:26] <pitti> tseng: we should mark roadmaps as informational and split out the various things into separate specs
[03:26] <tseng> pitti: yes.
[03:26] <jdub> ROAR SPAGHETTI MONSTER!!!
[03:27] <tseng> turning on ssp on things like apache, postfix will give us alot of bang for our buck
[03:27] <pitti> right
[03:27] <pitti> and enabling it per-package is easier to test
[03:27] <ajmitch> tseng: but we have to HAVE IT ALL!!
[03:28] <tseng> ajmitch: you don't have the line quite right
[03:28] <thom> GOTTA CATCH EM ALL
[03:28] <ajmitch> sorry
[03:28] <tseng> ajmitch: if you dont do X, you leave your system wide open to attack!!
[03:28] <tseng> :)
[03:29] <ajmitch> it's part of the fun of the specs being linked to wiki pages. people can go & change around a spec quite nicely
[03:29] <tseng> pitti: i think ASLR will be cheap and easy
[03:30] <pitti> indeed
[03:30] <pitti> but my favourite one is the stack protection
[03:30] <tseng> they are very complimentary
[03:30] <mdz> Kamion: for edgy, I want to have a new kind of server seed which is actually a set of packages to install by default on servers.  how do you think we should arrange it?  the current server seed would be more aptly named server-ship or such
[03:31] <Kamion> mdz: ship-server, by analogy with ship-live
[03:31] <Kamion> mdz: but exactly that change would be fine by me
[03:31] <mdz> pitti: don't forget to propose gcc-ssp for paris
[03:31] <ogra> Kamion, oh, we should also find a new name for the edubuntu server seed, i'm tired of all the merge conflicts ...
[03:31] <pitti> mdz: I already did
[03:32] <Kamion> ogra: mdz's suggestion would bring server more into line with you
[03:32] <Kamion> in purpose if not quite in contents
[03:32] <ajmitch> mdz: what would be in this new seed? 
[03:32] <mdz> ajmitch: so far just evms/lvm/mdadm
[03:32] <mdz> and powernowd
[03:32] <jdub> and sshd?
[03:33] <tseng> jdub++
[03:33] <mdz> jdub: that's more debatable I think
[03:33] <jdub> mdz: yeah ;)
[03:33] <ogra> Kagou, well, as long as the contents still differ i dont really care about the naming ;) since the conflicts will persist
[03:33] <Kamion> ogra: not to the same extent
[03:33] <ogra> s/Kagou/Kamion indeed
[03:33] <Kagou> :)
[03:33] <Kamion> you have changes in several of the other seeds too - those aren't conflicts, they're intentional divergence
[03:33] <ogra> well, i'd like a solution without conflicts ;)
[03:33] <Keybuk> sladen: are they on different buses?
[03:33] <Kamion> you don't have conflicts
[03:33] <Kamion> you have divergence
[03:33] <ogra> hmm, k
[03:34] <Kamion> if the contents come more into line, then having to *resolve* conflicts during merges will be less frequent
[03:34] <Kamion> they do not have to be identical for this
[03:34] <ogra> ok
[03:34] <Kamion> I also think the way you're doing merges is fundamentally broken which is not helping you
[03:34] <mdz> Kamion: would you be fine with that change even if I made it right now?
[03:34] <sladen> Keybuk: 0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11)
[03:35] <ogra> Kamion, i can only cherrypick most merges ...
[03:35] <Kamion> ogra: there are a *lot* of instances in the Edubuntu seeds where bzr indicates that you just applied the diff, rather than doing 'bzr merge'
[03:35] <sladen> 0000:04:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
[03:35] <Kamion> ogra: that means you have to re-merge the changes later
[03:35] <Kamion> ogra: no, I'm not talking about cherry-picking here, but routine merges
[03:35] <Kamion> the evidence is in the seed archives
[03:35] <Keybuk> sladen: PCIe?
[03:35] <ogra> well, there is a lot in the ubuntu seeds that we cant ship in edubuntu
[03:35] <Kamion> ogra: yes, but you still MUST use 'bzr merge'
[03:35] <mdz> ogra: if that's true, then perhaps it's time to start fresh with edgy
[03:35] <sladen> Keybuk: yes
[03:35] <mdz> and do the merges correctly going forward
[03:35] <Kamion> ogra: otherwise the next merge will try to do the same things again ... and again ... and again
[03:35] <Keybuk> sladen: the udev bug could explain them getting swapped, but then there's no guarantee of order of those anyway -- taking a few extra seconds to load firmware would have the same effect
[03:36] <ogra> if i cherrypick something, i usually get a conflict, which causes the merged changelogs to disappear
[03:36] <Kamion> ogra: I have never seen that behaviour and I don't believe it
[03:36] <Kamion> seriously
[03:36] <Kamion> I merge stuff a lot
[03:36] <ogra> so there is no trace in the changelog about the merge once i resolved a conflict
[03:36] <Kamion> then you are doing something broken
[03:36] <mdz> I must agree with Kamion, I've done this loads of times
[03:36] <Kamion> this does not happen to anyone else doing merges
[03:36] <ogra> well, i get a bzr message that this ot that file have a conflict 
[03:37] <mdz> ogra: the next time that happens, ask for help
[03:37] <Kamion> ogra: yes, and then you do 'bzr resolved' once you've fixed it
[03:37] <ogra> i edit that file, type bzr resolved <file> and commit
[03:37] <Kamion> mdz: a single correct merge will sort it out
[03:37] <Kamion> (at the moment, due to a bzr bug, you have to 'rm .bzr/checkout/conflicts' after resolving everything)
[03:37] <ogra> s/ot/or/
[03:37] <Kamion> (bzr resolved is broken for knit branches)
[03:37] <ogra> oooh
[03:37] <Kamion> (or possibly for metadir checkouts, not sure)
[03:37] <Kamion> ogra: this is not your problem though.
[03:38] <Kamion> ogra: if this were your problem, you wouldn't be able to commit
[03:38] <ogra> hmm, i had that behavior before knits already i think
[03:38] <Kamion> you would get a message from commit saying that your tree was conflicted
[03:38] <Kamion> it would not cause merge records to disappear
[03:39] <Kamion> please also ensure you're using the version of bzr in dapper, in case you have a random snapshot from before it stabilised there
[03:39] <ogra> no no, i use the latest dapper version
[03:39] <Kamion> ok
[03:40] <ogra> but i dont get why resolving eats the merge logs
[03:40] <Kamion> please ask for help from #bzr next time that happens, and don't commit
[03:40] <Kamion> 'bzr status' should show the merge logs
[03:40] <Keybuk> how bad is ogra's tree at the moment?
[03:40] <ogra> it does until i change the conflicting file
[03:40] <Kamion> ogra: right, at that point, ask #bzr
[03:40] <ogra> ok
[03:41] <Kamion> Keybuk: I *think* I did a merge since ogra's last one, but I'll check
[03:41] <ogra> but as i understand you you mean i should always merge everything, then commit and revert what i dont need ? 
[03:41] <Kamion> s/commit and revert/revert and commit/
[03:41] <Kamion> yes
[03:42] <Keybuk> if it needs smashing, you can push --overwrite ubuntu.edgy, then copy his files over and commit again -- it'd throw away his history though, but at least give a consistent start point
[03:42] <Kamion> if you don't, the next bzr merge will offer you the same thing and you'll have to make the decision again
[03:42] <ogra> *commit and revert and commit ;)
[03:42] <Kamion> no
[03:42] <Kamion> absolutely not
[03:42] <Kamion> the process of resolving the merge should include making it look how you want it to look, at each commit step
[03:42] <ogra> well, that way i wont lose the merge logs at the moment :)
[03:43] <ogra> ok
[03:43] <Kamion> I'd rather you didn't commit any merges until you figure out what's wrong
[03:43] <ogra> yep, understood
[03:44] <Kamion> Keybuk: not too bad, there's a merge from me ten commits back
[03:44] <Kamion> and I had to re-merge a bunch of stuff in that
[03:44] <Kamion> hmm, perhaps something is wrong with the tree though
[03:45] <Kamion> because there's a commit from Keybuk saying "merge kernel ABI bump" with no merge log
[03:45] <mdz> mvo: what do you think about the idea of displaying urgency information directly in update-manager?
[03:46] <Keybuk> iwj: I don't suppose you can recall what substance you were consuming when you decided dpkg should exec("rm") rather than calling unlink()? :p
[03:47] <Kamion> in fairness it is rm -rf, but yeah ;)
[03:48] <mvo> mdz: by checking the origin? or parsing the changelog? I think its a good idea, but if it is changelog based, it would require to download all the changelogs heads
[03:48] <mdz> mvo: we'd have to either parse the changelog or maintain a new metafile
[03:48] <Kamion> Keybuk: am I ok to sync po-debconf? build-dep for world
[03:48] <mdz> mvo: (the metafile would basically pre-parse the changelog, I suppose)
[03:48] <Keybuk> Kamion: yeah, it won't go anywhere for a bit
[03:49] <Keybuk> except possibly into BREEZY!  </sarcasm>
[03:49] <Kamion> that'd be funny. once
[03:49] <mvo> mdz: fine with me, should I add a spec for this? or just make a note?
[03:50] <mdz> mvo: a spec would be appropriate, assuming it interests you...propose it for paris and send me the URL so I can mark it on my wishlist ;-)
[03:50] <mvo> mdz: ok, I'm on it :)
[03:51] <ogra> so are we free to upload new crack already ? or is still something broken ? 
[03:52] <Keybuk> ogra: hold off for now
[03:52] <ogra> *twiddle* *twiddle*
[03:53] <mdz> ogra: if you are bored, get your specs proposed for Paris as I asked :-P
[03:53] <ogra> mdz, they'll be ready for you tomorrow morning as promised :)
[03:58] <iwj> Keybuk: you think I should have used ftw ? :-)
[03:58] <iwj> Given that I had the fork-and-exec machinery, it was less code.  Less code => less bugs.
[03:58] <Keybuk> iwj: true, doesn't cope well with the dynamic-link loader vanishing during an upgrade though :p
[03:59] <iwj> Keybuk: the dynamic link loader is NEVER permitted to EVER EVER disappear.
[03:59] <iwj> Since (eg) dpkg does not trap ^C.
[03:59] <iwj> And lots of other reasons.
[03:59] <iwj> If your ld.so disappears then you are hosed.  DDTT.
[03:59] <Keybuk> iwj: it disappears
[04:00] <Keybuk> some bright spark moved the /lib64 symlink across two packages
[04:00] <iwj> Do we have a way of getting firefox_1.4.99+1.5rc3.dfsg-1ubuntu3.diff.gz given that I seem not to have kept a copy.
[04:00] <Keybuk> iwj: (context-switch) where was it published?
[04:00] <Kamion> should be in the librarian
[04:00] <iwj> Keybuk: that can be done with rename(2) I think.
[04:00] <Kamion> oh, predates the librarian ...
[04:00] <iwj> Keybuk: (1ubuntu3) early dapper.
[04:00] <Kamion> yes, I'll fetch it from jackass for you
[04:01] <iwj> Thanks a lot.
[04:01] <iwj> My research indicates :-) that that's the one I want ...
[04:01] <Keybuk> Kamion: while you're on jackass, could you tarball the morgue up for me and put it on rookery or chinstrap or some other machine I have access to
[04:01] <Kamion> iwj: it's in http://people.ubuntu.com/~cjwatson/tmp/ with the dsc
[04:01] <Kamion> Keybuk: urr, can't you get access? it's f'ing huge
[04:02] <Kamion> I'd rather not have it transferred across the network twice :)
[04:02] <iwj> Kamion: Thanks a lot.
[04:02] <Kamion> 261468476       /srv/ftp.no-name-yet.com/morgue/
[04:02] <Kamion> (KB)
[04:02] <Keybuk> Kamion: see if you can rsync to cjwatson@casey:
[04:02] <Keybuk> oh, 261KB ?
[04:02] <Keybuk> meh
[04:02] <Kamion> 261GB
[04:02] <Keybuk> GB even
[04:02] <iwj> Oh, damn, I've just remembered.  This breezy install mysteriously doesn't boot.
[04:02] <Keybuk> meh, I'll have to do that
[04:02] <Keybuk> seeing as I only want sources
[04:02] <Kamion> I have access to casey ...
[04:03] <Keybuk> Kamion: you should have yeah
[04:03] <Kamion> I could try to rsync just sources
[04:03] <Keybuk> Kamion: if you could that'd be great
[04:04] <Keybuk> Kamion: (c-s) http://people.ubuntu.com/~scott/debhelper.ubuntu-udev.patch
[04:04] <\sh> syncs to edgy are already running?
[04:04] <Kamion> \sh: very selectively
[04:04] <Kamion> we're bringing up the core first
[04:06] <Keybuk> Kamion: ^R ... just cleaned up an odd diff
[04:07] <\sh> Kamion: good to hear :) 
[04:07] <iwj> Is anyone interested in the fact that I have a machine I can't install breezy on ?  If not then I'll carry on using that install as a chroot ...
[04:07] <Keybuk> iwj: can you install dapper on it?
[04:07] <iwj> Yes.
[04:07] <Kamion> Keybuk: yup, looks like what I had in mind too
[04:08] <iwj> And I _used_ to be able to install breezy on it.
[04:08] <iwj> I suspect that it's something to do with the changes to the various other installs in the meantime.
[04:08] <iwj> It seems to go wrong sometime in update-grub.
[04:08] <Keybuk> XFS?
[04:08] <iwj> (I know this isn't a proper bug report etc.; I'm just asking to see if it's worth actually collecting the info.)
[04:08] <Keybuk> ah, no, you use real filesystems
[04:08] <Keybuk> hmm
[04:08] <iwj> No, no XFS.
[04:09] <iwj> real filesystems> Sometimes I use reiserfs.  I don't think that counts ...
[04:09] <Kamion> infinity: don't build debhelper until you've built dpkg
[04:09] <Kamion> infinity: given that, should I upload debhelper, or hold off?
[04:10] <iwj> Furthermore, this install doesn't have `ed' !
[04:10] <ogra> take anjuta then :P
[04:11] <iwj> Um, actually, this thing is clearly hosed; the sources.list has no network sources.
[04:11] <iwj> *sigh*
[04:11] <Kamion> that can happen if it couldn't talk to the network during installation
[04:11] <Kamion> (in breezy anyway)
[04:12] <iwj> But it could.
[04:12] <Kamion> Keybuk: thanks, will upload either after I hear from infinity, or a few hours after that, depending on the answer
[04:12] <infinity> Kamion: Go ahead, I have a running list in my head.  I'll do dpkg right after the toolchain mess.
[04:13] <Kamion> infinity: libsepol -> libselinux -> dpkg -> debhelper
[04:13] <Kamion> with publisher run between each
[04:13] <infinity> FUN.
[04:13] <Kamion> though dep-wait will enforce the first couple anyway
[04:13] <iwj> mutter mutter selinux mutter pointless mutter mutter
[04:13] <infinity> Guess that's my tomorrow. :)
[04:13] <ogra> iwj++
[04:14] <Kamion> I suppose I should test-build something with this debhelper; I have to go and play chauffeur now though, so it'll be an hour or so
[04:14] <Kamion> debhelper won't be restricted to dep-wait though - it just Depends: dpkg
[04:14] <Kamion> >= obviously
[04:15] <Kamion> and since dpkg Build-Depends: debhelper now, it would be rather bad to build debhelper before the version of dpkg on which it Depends
[04:15] <Kamion> (I thought that was kind of a silly move too, but ...)
[04:18] <Keybuk> Kamion: it was supposed to b-d only on stable debhelper
[04:18] <Keybuk> have the new guys broken that?
[04:18] <Kamion> no, it's only debhelper 4.1.81, but I suspect the buildds will still be rather unhappy if the debhelper in the archive is uninstallable while trying to build dpkg
[04:19] <Kamion> or while trying to build anything, for that matter
[04:19] <Kamion> stuff's syncing to casey, btw, I'll check when I get back and let you know if it's done
[04:20] <Kamion> it's up to 2005-09-27
[04:22] <Keybuk> iwj: ... *blink* ...
[04:22] <Keybuk> dpkg: error processing /home/buildd/build-202059-100120/chroot-autobuild/var/cache/apt/archives/lib32gcc1_1%3a4.0.3-1ubuntu5_amd64.deb (--unpack):
[04:22] <Keybuk>  trying to overwrite `/usr/lib32', which is also in package fakeroot
[04:22] <Keybuk> since when can directories conflict?
[04:23] <iwj> There must be symlinks involved.
[04:23] <iwj> Is it currently a symlink ?  And the new object is a symlink too ?
[04:23] <iwj> etc. (similar questions)
[04:24] <infinity> It's not a symlink, I just reproduced the same steps on an upacked copy of the same tarball.
[04:24] <infinity> Entertainingly, the package unpacked right before it (libc6-i386) also contains /usr/lib32 and had no problems.
[04:24] <iwj> It's not a symlink on the fs before, and not a symlink in the package ?
[04:25] <infinity> Right, and right.
[04:25] <iwj> And not diverted ?
[04:25] <infinity> Nope.
[04:25] <iwj> Freaky.
[04:25] <infinity> Can you even get away with trying to divert a directory?
[04:25] <iwj> That's definitely very wrong.
[04:25] <iwj> I really really wouldn't :-).
[04:25] <infinity> Well, not only is it wrong, but i can't reproduce it outside the buildd.
[04:26] <Keybuk> infinity: 
[04:26] <infinity> Which is even more wrong.
[04:26] <iwj> But it's the kind of thing someone will try.
[04:26] <Keybuk> lrwxrwxrwx root/root         0 2006-06-08 07:44:24 ./usr/lib32 -> /emul/ia32-linux/usr/lib
[04:26] <Keybuk> ^ in libc6-i386
[04:26] <iwj> And does that exist ?
[04:26] <ogra>  /emul ?
[04:26] <infinity> Oh, so is libc6-i386 overwriting the previous directory with a symlink?
[04:26] <iwj> It should be fine to install a directory where there's a link to a different directory; dpkg will follow the link.
[04:27] <iwj> ogra: does /emul/ia32-linux/usr/lib exist, I mean.
[04:27] <infinity> Keybuk: Erm, I can install libc6-i386 just fine with no such craziness when I do it on a local copy of the same chroot tarball.
[04:28] <iwj> If the symlink is in the same package you have to note that they're usually arranged to come last in the package fsys tarball.
[04:28] <ogra> iwj, yes, thats what i was wondering, i never heard of /emul ever
[04:28] <Keybuk> infinity: then try installing lib32gcc1
[04:28] <infinity> Keybuk: Goes fine.
[04:28] <Keybuk> infinity: ok, try it in the same run
[04:28] <Keybuk> just unpack them both
[04:28] <infinity> Keybuk: I did.  Went fine.
[04:28] <iwj> same run> shouldn't make a difference.
[04:29] <iwj> Order might make a difference.
[04:29] <iwj> Err, of course the maintscripts might mess with it too.
[04:29] <iwj> If you tell me exactly which files I should tar zvvtf and dpkg --contents I can attempt to predict the behaviour :-).
[04:29] <ivoks> hi all
[04:30] <pitti> hi ivoks
[04:30] <infinity> Keybuk: OTOH, I think the whole link to /emul thing is clearly a bug anyway.. Let me find a Jeff to poke.
[04:30] <iwj> Does this /emul symlink thing exist in the packages or just on the buildd ?
[04:31] <ivoks> hi pitti 
[04:33] <infinity> iwj: It's just in the package.  It's also not supposed to be there.  Getting that fixed.
[04:33] <iwj> Right.  OK :-).
[04:33] <infinity> iwj: I'm still curious as to why it works when I upgrade by hand, but not when the buildd does exactly the same thing, but whatever.
[04:34] <ivoks> pitti: do you need help with that printing spec? :)
[04:34] <pitti> ivoks: always :)
[04:34] <mornfall> mvo: hmm, i don't use pkgCacheFile at all in libept
[04:35] <ivoks> pitti: so, eggdrop will be or something else?
[04:36] <pitti> ivoks: not sure about the gnome part, but since g-cups-mgr is dead upstream, and we want hal/dbus love anyway, it'll certainly be eggcups
[04:36] <ivoks> eggcups, not eggdrop :)
[04:36] <iwj> infinity: if the link target doesn't exist, dpkg will consider the existing directory and the new symlink to clash (and vice versa).
[04:37] <iwj> I expect the buildd just does things in a slightly different order or something.
[04:37] <infinity> iwj: The target existed.
[04:37] <ivoks> (tired)
[04:37] <infinity> iwj: It's shipped in the same package.
[04:37] <iwj> No, _already_ existed.
[04:38] <iwj> I'm not sure of the exact sequence of events if it's in the same package but I wouldn't be surprised if some combinations of attempts to do things didn't work.
[04:40] <mdke> Znarl: here?
[04:40] <mdz> Kamion,*: http://people.ubuntu.com/~mdz/temp/ubuntu-server.diff
[04:43] <fabbione> mdz: why do you want to turn -server into a meta package?
[04:44] <fabbione> mdz: something on that diff is weird tho
[04:44] <fabbione> [04:44] <fabbione> --- /dev/null	
[04:44] <fabbione> +++ server	
[04:44] <pitti> *** stack smashing detected ***: cmd-safe terminated
[04:44] <mdz> fabbione: that's the normal way to show diffs for added files
[04:44] <fabbione> [04:44] <ajmitch> pitti: testing with SSP?
[04:44] <fabbione> bah yeah i know about added files
[04:44] <fabbione> but why is it added?
[04:45] <pitti> ajmitch: yep, in sid
[04:45] <ajmitch> yay :)
[04:45] <fabbione> there was already a server there
[04:45] <mdz> fabbione: the current 'server' is 'included on the server CD'
[04:45] <mdz> fabbione: so I rename that to ship-server
[04:45] <mdz> the new 'server' is things to install on servers by default (and in some cases remove from standard)
[04:46] <mdz> the inspiration was getting evms and lvm out of the desktop boot process, but I've been playing around with more
[04:46] <fabbione> mdz: but there is a spec in your suggested list to install on LVM by default?!?!?
[04:47] <mdz> fabbione: yes, that is not happening for edgy :-)
[04:47] <fabbione> *eeekkkk*Cl4sh d3t3ct10n*eeekkk*
[04:47] <mdz> and it's not clear that it's a good idea
[04:47] <fabbione> i still would like to have lvm on dekstop
[04:47] <fabbione> it's useful
[04:48] <fabbione> even on a laptop
[04:48] <fabbione> and yes i am WEIRD.. ok?
[04:48] <ajmitch> nah
[04:48] <dholbach> you're weird too
[04:48] <dholbach> :-p
[04:48] <ajmitch> heh
[04:48] <Hobbsee> dholbach: +1
[04:48] <Hobbsee> you beat me to it!
[04:48] <jdub> fabbione: could it go in ship-seed/live, and be available for the installer?
[04:49] <fabbione> jdub: i definetely want it on cd..
[04:49] <fabbione> jdub: i might agree not installed by default
[04:49] <fabbione> but it needs to be there
[04:50] <mdz> fabbione: this isn't about what some people might want, but about the default
[04:50] <mdz> for 99% of desktop users, evms and lvm just slow down the boot process and provide no benefit
[04:50] <mdz> they are only where they are because we want them on servers
[04:50] <fabbione> mdz: as i said.. i might agree on not installed by default, but i want them on cd.
[04:50] <fabbione> mdz: i want to be able to keep installing my desktop on LVM.. i
[04:51] <mdz> fabbione: sure, we can copy them to ship
[04:51] <fabbione> mdz: yeah that's whay i just said :)
[04:51] <fabbione> it's ok not installed by default
[04:51] <fabbione> but with the option to have it if somebody wants it
[04:51] <mdz> fabbione: do we need to add something to the lvm udeb to cause it to install lvm2?
[04:51] <mdz> or does it already do that?
[04:52] <mornfall> fabbione: no worries, i have lvm on laptop
[04:52] <fabbione> i will need to check that in the installer.. there are at least 2 packages to check
[04:52] <fabbione> mdz: probably an apt-install lvm2
[04:52] <fabbione> or it's equivalent
[04:52] <mdz> fabbione: I bet Debian already does it because lvm2 is not installed by default
[04:52] <mvo> mornfall: hm, what would be a better place for the code then?
[04:52] <fabbione> mdz: probably....
[04:53] <jdub> mdz: (would you include lvm/evms on the desktop/live CD?)
[04:53] <mornfall> mvo: it's not quite a problem for libept, i can add the hook call there easily
[04:53] <mvo> mornfall: ok
[04:53] <mornfall> mvo: i will eventually want to anyway, since i have very similar method there that throws exceptions on errors
[04:54] <mornfall> mvo: i'll check what aptitude does in that respect
[04:54] <mdz> fabbione: diff updated
[04:54] <mdz> jdub: no, I wouldn't (except perhaps if we added support for them to ubiquity)
[04:54] <jdub> mdz: (oh yeah, good point)
[04:54] <fabbione> mdz: yeps.. lvmcfg does it.. i will need to update partman-auto-lvm, but that's easy
[04:55] <fabbione> +[04:55] <fabbione> ROFL
[04:55] <jdub> heh
[04:55] <dieman> heh
[04:56] <mornfall> mvo: what i thought, aptitude has yet another version of that class embedded
[04:56] <mvo> mornfall: and synaptic has a different one too :/ but I should be able to fix both, usually daniel is pretty responsive to this kind of patches for aptitude
[04:58] <jdub> mdke: http://iquaid.livejournal.com/10898.html
[04:58] <mdke> jdub: yeah :)
[04:58] <jdub> mdke: how good is the moin markup -> docbook stuff?
[04:59] <mornfall> mvo: well, no matter, at least we have the hooks called which will mean that we should be able to get rid of apt-index-watcher
[04:59] <mdke> jdub: in moin 1.5, rubbish; at the moment in mikko's soc project, already very good and will get even better
[05:00] <Kamion> Keybuk: casey:~cjwatson/jackass-morgue/
[05:00] <mvo> mornfall: yes, thats a good thing!
[05:00] <jdub> mdke: tasty. :-)
[05:01] <mdke> jdub: yeah, pretty cool
[05:01] <jdub> mdke: not the steps towards solving this that i would've guessed/imagined 12 months ago
[05:02] <mdke> jdub: I took this off the wiki and put it through the converter: http://mdke.org/tmp/Moin2docbook.png
[05:02] <jdub> heh, nice
[05:02] <Kamion> mdz: any reason not to make ship just include ship-server, rather than copying bits of ship-server into ship?
[05:02] <Kamion> mdz: "include" => STRUCTURE plus cdimage changes, rather than putting ubuntu-server in the ship seed
[05:03] <Kamion> jdub: LVM in ubiquity> see ubiquity-advanced-partitioner
[05:03] <mdz> Kamion: they already had overlap, but you're right, it makes more sense that way
[05:03] <Kamion> jdub: (LVM in ubiquity isn't an essential part of that spec, but I think that spec is needed before we attempt it)
[05:03] <Kamion> mdz: but otherwise, looks ok
[05:04] <jsgotangco> mdke: that is NICE
[05:04] <mdke> yeah
[05:04] <mdke> just amd64?
[05:04] <ajmitch> infinity: yes, it's fun breakage too
[05:04] <mdke> meh
[05:04] <jdub> hooray, that means it works everywhere else!
[05:04] <ajmitch> mdke: /lib64 symlink
[05:04] <tseng> mdke++
[05:04] <ajmitch> (iirc)
[05:04] <infinity> ajmitch: Oh, I see you already tried. :)
[05:05] <ajmitch> infinity: of course
[05:05] <infinity> ajmitch: Foolish man. :)
[05:05] <mdke> can we have some broken i386 action too for those of us without this crazy hardware
[05:05] <jdub> Kamion: btw, gtk+ 2.10 is going to have 'assistants' (wizard/druid api)
[05:05] <ajmitch> infinity: I did it in vmware, no loss :)
[05:05] <mdz> Kamion: hmm, it would actually make more sense to have ship-common, ship-desktop, ship-server or similar
[05:05] <jsgotangco> nice!
[05:05] <infinity> mdke: I'll break i386 for you tomorrow.
[05:05] <mdz> Kamion: if we want to factor out the duplication
[05:05] <mdke> rock
[05:05] <mdke> infinity: one per day seems reasonable
[05:05] <jsgotangco> amd64 is hardly anything crazy :/
[05:05] <_ion> Will m68k not be broken?
[05:06] <pitti> doko: ping
[05:06] <infinity> _ion: I try not to break m68k, because unbreaking it takes too long.
[05:06] <Kamion> mdz: what would be in ship-common?
[05:06] <Kamion> mdz: but sure, that approach would work
[05:06] <mdz> Kamion: things we want in both which are not specifically server-oriented
[05:06] <mdz> Kamion: e.g., the Development section
[05:07] <mdz> and "Hardware and network access"
[05:07] <Kamion> mdz: mm, true
[05:07] <Kamion> fine by me as long as there's still a 'ship' there at the end of it with appropriate changes to STRUCTURE
[05:07] <Kamion> though cdimage might need some changes anyway
[05:07] <Kamion> but who cares, I'm going to ignore cdimage for a while until the installer is brought up
[05:08] <infinity> Kamion: Ignore away.  If I feel the urge to build a CD or two, it'll become my problem. :)
[05:08] <pitti> is there a possibility to specify a build dependency 'use package foo if it's available, but don't fail if not'?
[05:08] <Kamion> mdz: ship-server should be 'boot minimal standard' in STRUCTURE, I believe
[05:08] <infinity> pitti: No, if there was, I'd be using that in PHP (to avoid forking from Debian)
[05:08] <Kamion> though that's probably an existing bug
[05:08] <pitti> infinity: exactly; I want to keep postgresql backportable, but build-recommend libssp0-dev
[05:09] <mdz> Kamion: diff updated
[05:09] <infinity> pitti: Then you lose.
[05:09] <Kamion> nod
[05:09] <infinity> pitti: The hackish way to do it is to build-dep on something completely unrelated to your package as an OR.
[05:09] <infinity> pitti: libssp0-dev | moon-buggy
[05:09] <_ion> How beautiful. :-D
[05:09] <mdz> moved libxp6 back out to ship, since some folks are offended
[05:09] <mdz> by X libraries on servers
[05:09] <pitti> infinity: right, the first thing that came into my mind was libssp0 | gcc, but that obiously doesn't work
[05:10] <infinity> pitti: The trick is that the OR dep can't be something that would be pulled in anyway by the build-deps.
[05:10] <pitti> infinity: I thought about this bogus | too
[05:10] <mdz> infinity: any opinions on http://people.ubuntu.com/~mdz/temp/ubuntu-server.diff ?
[05:10] <pitti> but I hoped there was a better way
[05:10] <pitti> infinity: thanks
[05:10] <infinity> pitti: Anyhow, that would be really, really silly, so I wouldn't recommend it. :)
[05:10] <_ion> + * chkrootkit
[05:10] <_ion> rkhunter would be nice in addition to that.
[05:11] <jsgotangco> good night
[05:11] <pitti> infinity: if we go for adding this to many packages, we'll loose backportability
[05:11] <Kamion> infinity: oh, bugger, xfonts-utils is split out in Debian now
[05:11] <doko> pitti: pong
[05:11] <Kamion> but it's in xfonts-core in Dapper
[05:11] <pitti> doko: do you happen to plan to add libssp0-dev as gcc dependency?
[05:11] <ivoks> pitti: it's not like eggcups has active development :)
[05:11] <tseng> mdz: cricket, aide, nessus < really?
[05:11] <infinity> mdz: The structure looks backwards to me...
[05:12] <mdz> tseng: really what?  really continue to ship them on the server CD?
[05:12] <Kamion> I love this part of the cycle; it feels like playing with two giant subtly incompatible Meccano sets and trying to build something that stays up
[05:12] <tseng> mdz: ah
[05:12] <tseng> mdz: sure.
[05:12] <pitti> ivoks: no upstream developer is interested in printing, it seems... :(
[05:12] <mdz> I removed the bits from ship-server which I added to server
[05:13] <mdz> infinity: how so?
[05:14] <ivoks> pitti: yup, both in gnome and kde there is no development :/
[05:14] <infinity> mdz: Well, either I'm reading the diff wrong, or all the stuff in "server" is what you wanted to have in "ship-server" and vice versa...
[05:14] <infinity> mdz: I'm assuming you don't want nessus and cricket in regular ship...
[05:14] <mdz> infinity: 'server' is stuff installed by default on server installed, and 'ship-server' is only included on the CD
[05:14] <Kamion> server looks right to me ...
[05:14] <ivoks> hm... time to write something new?
[05:15] <Kamion> oh, but yes, nessus/cricket shouldn't be sucked into ship
[05:15] <Kamion> so we do need ship-common
[05:15] <Kamion> or to just duplicate for now
[05:15] <mdz> Kamion: why, space considerations?
[05:15] <mdz> Kamion: I'm inclined to do this in two steps, first repurposing server and then factoring out the common bits
[05:15] <Kamion> mdz: well, that and we'd never have put them in ship ordinarily
[05:15] <infinity> Yeah, ship just got bloated.
[05:15] <Kamion> mdz: factoring> fine by me
[05:15] <infinity> That was what was confusing me about this change.
[05:16] <mdz> to that end, I've reverted that bit
[05:16] <mdz> so ship-server and ship remain independent
[05:16] <mdz> and I'm ready to commit what's published there now unless someone screams
[05:17] <infinity> mdz: Okay, so "server" is meant to be a metapackage of "installed by default" stuff?
[05:17] <infinity> mdz: I'm still questioning it in that case. :)
[05:17] <mdz> infinity: at least a task, and presumably a metapackage too
[05:17] <mdz> infinity: what's your concern?
[05:17] <infinity> mdz: I see no reason to install lilo by default.  It'll be installed if they asked for it in the installer.  No reason to install the bloat of ia32-libs unless they need it, etc...
[05:18] <mdz> infinity: I'm happy to put those back in ship-server if you mind
[05:19] <Kamion> ok, apparently xfonts-utils (dapper) -> xfonts-{base,75dpi,100dpi,scalable,utils} (unstable)
[05:19] <Kamion> whee
[05:19] <infinity> mdz: I'm not sure how happy I am to make server installs go much beyond -minimal unless the user specifically requests certain tasks/metapackages.  I want a basic server install to be as bare-bones as possible to please the hardcore admins.
[05:19] <infinity> mdz: And then add the tasks (like the LAMP stuff) in to satisfy the less hardcore.
[05:19] <Kamion> er s/xfonts-utils/xfonts-core/
[05:20] <mdz> infinity: so you object to having a server seed at all?
[05:20] <infinity> mdz: Basically, yeah.
[05:20] <mdz> bah
[05:20] <Kamion> YM a server metapackage?
[05:20] <infinity> mdz: There's no one thing you can define as "a server".
[05:20] <mdz> it's pretty much all harmless command-line stuff
[05:20] <infinity> mdz: I'm more for a set of tasks for common server setups (looks at Kamion's revive-tasksel spec)
[05:21] <Kamion> what's miscfiles doing in server?
[05:21] <infinity> mdz: Sure, it's all harmless stuff, but I never use bc ever.  And I only use zip and unzip on my workstattion.  And and.  The more we bloat it out with what user A wants, the more we add for user B, and eventually we have a server install bigger than the desktop.
[05:21] <Kamion> why do I need the US Constitution, lists of postal codes, and a list of airport codes on my server?
[05:21] <mdz> infinity: what inspired this was that there are packages in standard which are only there because people might want them on servers
[05:22] <mdz> Kamion: reload
[05:22] <Kamion> better
[05:22] <infinity> mdz: I'm happy to slim down standard, I don't think that means they should be in a server seed.  Most server folk I talk to want their server setups as small as possible.
[05:22] <mdz> infinity: we're not giving them much that they weren't getting already
[05:23] <Kamion> we could just move them to ship-server and forget about creating a new server seed
[05:23] <infinity> Kamion: Yeah, I'd be happy about that.
[05:23] <Kamion> then we would have the 'server' name free for ogra again
[05:23] <infinity> mdz: True, but if we're refactoring ANYWAY, why keep the bloat?
[05:23] <mdz> infinity: because I didn't consider it bloat for server installs
[05:23] <mdz> a few megabytes of administration tools wouldn't hurt
[05:23] <infinity> mdz: Shall we schedule an "argue about server seeds" BoF? :)
[05:24] <mdz> most of them were in standard because we found ourselves installing them on servers as a matter of course
[05:24] <infinity> (Actually, I need to schedule something to discuss how we're going to do more server flavours)
[05:24] <mdz> infinity: sure, but first, lvm2 and evms out of desktop ;-)
[05:24] <infinity> And I think this falls into the flavour umbrella, as the "vanilla" flavour.
[05:24] <Kamion> I plan to write up and schedule revive-tasksel before tomorrow evening
[05:24] <infinity> mdz: I'm all for lvm and evms exiting desktop.
[05:24] <infinity> mdz: I don't care if you just remove them from standard and cripple -server for now.  I can recover -server later.
[05:24] <hunger> mdz: Noooo ! lvm is great to have on a desktop!
[05:25] <Kamion> hunger: what's stopping you installing it?
[05:25] <Keybuk> hunger: you can install them if you want them
[05:25] <Keybuk> most people don't
[05:25] <mdz> hunger: we already discussed this, with more or less the result that Kamion and Keybuk just explained
[05:25] <hunger> Keybuk: Use lvm by default:-)
[05:25] <iwj> Kamion: are you insterested in my Breezy woes or shall I just use debootstrap ?
[05:26] <iwj> (Or for that matter fix up sources.list and blunder on)
[05:26] <fabbione> mdz: did you slam lvm2 out of ship again?
[05:26] <infinity> mdz: I'd rather revisit the whole -server thing while discussing tasks and flavours, so if you want to yank stuff from desktop, just do it.  Don't worry too much about what happens to server.
[05:26] <Kamion> iwj: at this point, not so massively, if Dapper works ...
[05:26] <iwj> Right.
[05:26] <infinity> mdz: If you want to leave a note in the form of a mess of commented out crap in the server seed, that will be a fair hint. :)
[05:28] <infinity> mdz: Something like "# XXX: This is the junk I pulled out of standard, figure something out -- mdz" will be enough for me to sink my teeth into in Paris when I actually decide to care deeply about this.
[05:29] <mdz> infinity: that'd cause them to fall off of the CDs, of course
[05:30] <mdz> but if you're not bothered...
[05:31] <infinity> mdz: I don't much care what happens to the CDs in the next 2 weeks. :)
[05:31] <infinity> Kamion: Please do propose the tasksel thing, so I can make server-tasks (when I write it up) depend on it.
[05:32] <infinity> I don't want ubuntu-server to grow 10 boot options for different setup types.
[05:32] <Kamion> oh ye gods, debhelper vs. X is gonna be complicated
[05:33] <Kamion> I could just let anything that attempts to use dh_installxfonts FTBFS
[05:33] <Kamion> that might even be a good thing
[05:34] <infinity> Kamion: That sounds quite reasonable for the short term, until we sort the world.
[05:35] <Kamion> because otherwise an xfonts-encodings <-> xfonts-utils manual bootstrap has to happen first
[05:35] <Kamion> Source: xfonts-encodings
[05:35] <Kamion> Build-Depends-Indep: pkg-config, xfonts-utils
[05:35] <Kamion> Package: xfonts-utils
[05:35] <Kamion> Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common, xfonts-encodings
[05:35] <Kamion> whee
[05:36] <infinity> Kamion: We can do a manual bootstrap once the toolchain stuff is finally unbuggered.
[05:36] <fabbione> we should really be fixing imake before doing ANY X upload
[05:36] <infinity> Kamion: If you've got it more or less figured out in your head, put it to paper and email me the details.
[05:37] <mdz> and for my next controversial proposal
[05:37] <mdz> I want to install build-essential and linux-headers by default
[05:37] <dholbach> fabbione: you mean  bug 28707 ?
[05:37] <Ubugtu> Malone bug 28707 in imake "ProjectRoot set incorrectly" [Low,Confirmed]  http://launchpad.net/bugs/28707
[05:37] <Keybuk> mdz: weren't you the one who originally didn't want to?
[05:37] <Kamion> fabbione: is it fixed in Debian
[05:37] <Keybuk> or was it a jdubism?
[05:37] <Kamion> ?
[05:37] <fabbione> dholbach: yes
[05:37] <infinity> mdz: I thought the lack of gcc in desktop was intentional.
[05:37] <mdz> Keybuk: the latter
[05:37] <Kamion> Keybuk: was jdub
[05:37] <fabbione> Kamion: yes
[05:37] <Kamion> I always wanted to put the compiler and headers in desktop
[05:37] <Kamion> but I lost
[05:38] <mdz> Kamion: I'm undecided between standard and desktop+server
[05:38] <infinity> I'm in the "no compiler on desktops" camp.
[05:38] <Keybuk> I'd like them to be in desktop too ... the fact Linux came with a C compiler was the reason I discovered it
[05:38] <mdz> but if we don't have a server installation set, we have to do standard
[05:38] <wasabi> There needs to be a setting someplace to turn off this damned screen fading.
[05:38] <infinity> wasabi: gnome-power-manager
[05:38] <mdz> infinity: not on desktops or servers either?
[05:38] <Kamion> regardless of what I think personally about compiler-on-desktops, it comes up in nearly every damn review
[05:38] <wasabi> Naw, on the log out dialog and the gksudo dialog.
[05:38] <Kamion> both in the media and from friends
[05:39] <mdz> we live in a world where people need it *all the time* and expect to find it
[05:39] <dholbach> how much space would it take?
[05:39] <infinity> mdz: It's probably my buildd background (plus having people compile exploits remotely via random holes in CGI apps on webservers), but I've long been against having compilers installed by default anywhere.
[05:39] <Keybuk> Kamion: how did that sync go?
[05:39] <wasabi> infinity: Even the JIT that comes with Mono? :0
[05:39] <mdz> dholbach: it would cost no space on the CD, and a trivial amount in the installed system
[05:40] <Kamion> Keybuk: ?
[05:40] <Kamion> Keybuk: oh, right
[05:40] <Kamion> the r goes *there*
[05:40] <infinity> mdz: It's not a sticking point for me, mind you, it just means that I'll be removing ubuntu-standard on all my machines, then.
[05:40] <dholbach> It's just because I know a lot of people who would never use it, even if it was there.
[05:40] <Kamion> 16:00 < Kamion> Keybuk: casey:~cjwatson/jackass-morgue/
[05:40] <Keybuk> infinity: you don't have a compiler on any machine?
[05:40] <wasabi> What are some examples of desktop apps that require a compiler?
[05:40] <infinity> Keybuk: No, I do all my building in chroots.
[05:40] <dholbach> (and my feeling is that that's the majority of Ubuntu users.)
[05:41] <Keybuk> Kamion: it finished?>
[05:41] <Kamion> Keybuk: yes
[05:41] <Keybuk> ok, thanks
[05:41] <mdz> dholbach: that's true for a lot of what we ship; we have other reasons than "most people will use it"
[05:41] <Kamion> infinity: damnit. slot po4a in before debhelper in your build chain
[05:41] <mdz> wasabi: I don't know of any; what do you have in mind?
[05:41] <wasabi> I don't have any.
[05:41] <wasabi> =)
[05:41] <mdz> wasabi: then what's the rhetoric behind your question?
[05:42] <infinity> Kamion: I think it's high time for you to email me this dpkg/debhelper bootstrap recipe.  I'm too tired now to remember it when I wake up.
[05:42] <wasabi> Why's it under dicussion?
[05:42] <infinity> wasabi: I assume the reason it's wanted is for people to compile kernel drivers.
[05:42] <wasabi> Ahh. It just hit me.
[05:42] <wasabi> Vmware.
[05:42] <infinity> I suspect that if we're not shipping enough drivers, that's a failing on our part, but what do I know?
[05:42] <wasabi> The install process requires a compiler and headers.
[05:43] <\sh> wasabi:you had a document about ip tuning for ftp servers...is it still available and when where can I find it? I don't have my own bookmark library with me :(
[05:43] <Kamion> infinity: it is, but it's not always one we can correct
[05:43] <mdz> wasabi: no desktop app depends on hdparm, parted, man, file, at, cron...
[05:43] <infinity> vmware-player is now in the archive with pre-compiled modules.  People using vmware-server or vmware-workstation should, in theory, have enough clue to install a compiler.
[05:43] <wasabi> \sh: That doesn't ring a bell.
[05:43] <Kamion> infinity: ok, you'll have mail in a moment
[05:43] <mdz> wasabi: "a desktop app needs it" isn't how we decide what goes in the default install
[05:43] <wasabi> K. Well, my argument was swung when I thought of VMware. ;0
[05:43] <mdz> vmware requiring a compiler is a bug
[05:43] <\sh> wasabi: oh no...I mixed your nick with maswans
[05:45] <infinity> Can anyone come up with a "user needs a compiler" use case that doesn't also diredctly map to "user wants to install something blingtastic and should probably know how to install a compiler?"
[05:45] <\sh> just found it...gg: maswan ftp mirror
[05:45] <\sh> et voila
[05:45] <\sh> http://www.acc.umu.se/~maswan/linux-netperf.txt
[05:45] <infinity> ie: how many drivers are there that we don't (or can't) ship that they'd need to compile themselves?
[05:46] <mdz> infinity: it happens, and it happens a lot
[05:47] <infinity> mdz: Fair enough.  Then it doesn't hurt my feelings terribly to add it.  <shrug>
[05:47] <Keybuk> it should probably be only desktop though
[05:47] <Keybuk> not server
[05:47] <infinity> I do disagree with compilers on server for the previously-stated reason.
[05:47] <mdz> I'm not a fan of security-through-crippling
[05:47] <ogra> infinity, spca webcams, linmodems ...
[05:48] <infinity> (The "hey, let's use our unprivileged www-data access to pop some source in /tmp and compile it" rootkits which are very prevalent these days)
[05:48] <mdz> things which didn't have drivers when we released
[05:48] <infinity> mdz: I don't view a system without a compiler as terribly crippled.
[05:48] <mdz> infinity: you can solve that more effectively with chroot, or even noexec /tmp
[05:49] <infinity> mdz: servers (with the exception of mass shell servers) are becoming very specialised devices these days.
[05:49] <infinity> mdz: noexec /tmp and dpkg disagree.
[05:49] <mdz> I see a compiler as a system administration tool
[05:49] <mdz> infinity: all the better; you wouldn't want a rootkit using dpkg to install gcc ;-)
[05:49] <infinity> I see "being able to compile" as a system administration tool.  Why that should happen on your production server, I have no idea.
[05:50] <infinity> We do this whole binary distribution thing for a reason, IMO. :)
[05:50] <Keybuk> funnily enough I've had someone rootkit my server before (via samba) and "helpfully" upgrade it after
[05:50] <Keybuk> my inclination for not installing it on ubuntu-server isn't security-minded per se
[05:50] <infinity> Keybuk: Hah, I never had anyone upgrade my box for me. :)
[05:51] <Keybuk> it's that most sysadmins do care about not having compilers on there
[05:51] <Keybuk> and if we ship it by default on server, we'll get flak ... just like we get flak for _not_ shipping it on desktop
[05:51] <Keybuk> desktop people think it's "one thing they have to install"
[05:51] <Keybuk> server people would think it's "one thing they have to remove"
[05:51] <mdz> stories like this are very common:
[05:51] <mdz> "How do I install GCC to Ubuntu Linux. My PC does not have Internet connection and so I will be installing it from the CD. also plz let me know from where can I download GCC. I am new to Linux."
[05:51] <mdz> people who are new to Linux get help from people who use compilers
[05:51] <infinity> mdz: Right, but "I am new to Linux, help" so doesn't mech with our -server install.
[05:51] <Kamion> infinity: noexec /tmp and debconf disagree too
[05:52] <thom> Kamion: yes, that's quite unfortunate
[05:52] <infinity> Kamion: Arguably, this is a bug in both dpkg and debconf, who should be doing things differently.  Why a root-running process needs to use /tmp for random shell snippets, I have no idea.
[05:52] <Keybuk> Kamion: heh, forget debconf ... dpkg won't work with a noexec /tmp
[05:52] <Kamion> noexec /tmp is so screamingly pointless though
[05:52] <Keybuk> oh, wait, infinity said that
[05:52] <mdz> infinity: you're right there.  but what does mesh with our -server install is "new to ubuntu"
[05:52] <Kamion> /lib/ld.so /tmp/foo HELLO
[05:53] <mdz> and people coming from other distributions expect gcc
[05:53] <Keybuk> Kamion: I thought that was supposed to not work now?
[05:53] <thom> Kamion: the average script kiddy does not know you can do that; it fixes an awful lot esp if you're just doing web hosting
[05:53] <fabbione> mdz: that'd be ex-gentoo users...
[05:53] <mdz> fabbione: and ex-RHEL users
[05:53] <fabbione> mdz: we can cope with that ;)
[05:53] <mdz> and ex-SuSE users
[05:53] <infinity> mdz: Could we compromise by having it in a pkgsel hook, so removing it won't remove any of our precious metapackages? :)
[05:54] <wasabi> Curiously... how do people feel about the convergence between Desktop and Server?  MS/Apple style.
[05:54] <mdz> infinity: fixing metapackages to be less all-or-none is something we should do anyway
[05:54] <wasabi> are we ever going to be in a position to offer a GUI administration interface for our servers?
[05:54] <thom> Kamion: s/fixes/prevents/ rather
[05:54] <mdz> wasabi: yes
[05:54] <Keybuk> wasabi: what would you like to administer?
[05:54] <infinity> wasabi: I'm firmly against it for "real" servers.
[05:54] <wasabi> Me? I'm fine with text. I know 90% of small business out there EXPECT graphics.
[05:55] <wasabi> And we'll need it if we want their business.
[05:55] <infinity> wasabi: But I don't mind the idea of a small-business-server setup with a GUI frontend... If we ever had GUI admin tools that didn't suck (we don't)
[05:55] <Keybuk> I still want movibuntu
[05:55] <wasabi> Haha.
[05:55] <Keybuk> a derivative that looks like MovieOS
[05:55] <Kamion> Keybuk: hmm, yes, you're right, somebody hacked that into ld.so obviously
[05:55] <wasabi> Ubuntu Media Center Edition. ;)
[05:56] <HiddenWolf> Keybuk: fluendo should be presenting a new media center app at guadec, you might get it. :)
[05:56] <Keybuk> Kamion: actually it's just that access() says NO! now, and ld.so bothers to check that now
[05:56] <Keybuk> iirc
[05:56] <eXistenZ> hello ivoks 
[05:56] <eXistenZ> ivoks, how are you doing today?
[05:56] <infinity> wasabi: The line I walk with -server is that every time we want to add something for new users or small-business users, the people who make or break us (old UNIX hacks, mass hosting providers, corporate network admins) scream because our server install just got more moving parts.
[05:56] <Keybuk> (otherwise it's a back door for exec'ing anything that's -x :p)
[05:57] <infinity> wasabi: So, we need to be able to satisfy both groups with different setups.  Which I'm fine with.  But the GUI setup really isn't worthwhile yet anyway.
[05:58] <infinity> wasabi: Home users running "servers" who want to put "Linux Administrator, OMG!" on their resume complain about the lack of GUI, but they're not the people using the product in production on thousands of machines either.
[05:58] <bluefoxicy> bluefox@icebox:/tmp$ /lib/ld-linux.so.2 x/cat
[05:58] <bluefoxicy> x/cat: error while loading shared libraries: x/cat: failed to map segment from shared object: Operation not permitted
[05:58] <wasabi> You'd be suprised. :
[05:58] <infinity> wasabi: Until the GUIs improve, my target audience is people like elmo and thom.
[05:59] <wasabi> Yeah.
[05:59] <bluefoxicy> Keybuk: You cannot mmap() permissions not granted on the underlying object.
[05:59] <Kamion> bluefoxicy: yeah, I know that *now*, it used to work that's all
[05:59] <Kamion> last time I had the argument WRT debconf
[06:00] <bluefoxicy> Kamion: <Kamion> Keybuk: hmm, yes, you're right, somebody hacked that into ld.so obviously
[06:00] <bluefoxicy> Kamion:  it's in the kernel.  :)
[06:00] <Kamion> bluefoxicy: yes, you're repeating what others have said though :)
[06:00] <iwj> 1.5.dfsg+1.5.0.4-0ubuntu0.breezy0 ?
[06:00] <wasabi> Well, I'd probably agree then. Default server install is minimal, user has to install what he wants. Pretty much how MS does it now too.
[06:00] <bluefoxicy> Kamion:  nod.  I'll refrain from quoting posix standard then.
[06:01] <Kamion> bluefoxicy: I don't care :-)
[06:01] <Kamion> iwj: check existing package versions, they use 5.10 and 5.04 for better sorting
[06:01] <wasabi> Eventually UIs appear to make "install what he wants" friendly.
[06:01] <Kamion> since "breezy" < "hoary"
[06:01] <iwj> Kamion: Ah, that would help.  Yes, I was just thinking of ahoary and that way lies madness.
[06:01] <Kamion> mozilla-firefox | 1.0.8-0ubuntu4.10 | warty-security | source, amd64, i386, powerpc
[06:01] <Kamion> mozilla-firefox | 1.0.8-0ubuntu5.04 | hoary-security | source, amd64, i386, ia64, powerpc
[06:02] <Kamion> mozilla-firefox | 1.0.8-0ubuntu5.10 | breezy-security | all
[06:02] <iwj> Urr.  That's no good because we have a 1.5.0.4-0ubuntu1 already.
[06:02] <iwj> In dapper.
[06:02] <iwj> Well, dapper-security as soon as it comes out.
[06:03] <Kamion> 0ubuntu0.5.10
[06:03] <iwj> So 1.5.0.4-0ubuntu0.5.10 I suppose.
[06:03] <pitti> iwj: use 1.5.0.4-0ubuntu0.6.06 then :)
[06:03] <pitti> erm, yes, 0.5.10
[06:03] <iwj> These version numbers are practically cancerous.
[06:03] <pitti> iwj: btw, firefox is still not in the security queue
[06:03] <iwj> pitti: Oh.
[06:03] <pitti> iwj: so you can as well reupload the dapper update to be -0ubuntu6.06
[06:04] <Keybuk> bluefoxicy: posix doesn't say ld.so has to use mmap
[06:04] <iwj> s firefox_1.5.dfsg+1.5.0.4-0ubuntu1_source.changes security.upload.ubuntu.com Thu Jun  8 12:30:34 2006
[06:04] <pitti> iwj: you didn't get a rejection mail?
[06:04] <bluefoxicy> Keybuk:  true.  It just says mmap() has to obey underlying object permissions.
[06:04] <iwj> pitti: No.
[06:04] <pitti> iwj: maybe missing orig.tar.gz?
[06:05] <Kamion> pitti: katie should have mailed back about that even if soyuz doesn't
[06:05] <iwj> .orig.tar.gz> Duh, stupid if me.
[06:05] <iwj> s/if/of
[06:05] <pitti> firefox_1.5.dfsg+1.5.0.4-0ubuntu1_source.changes
[06:05] <pitti> REJECT
[06:05] <pitti> Rejected: firefox_1.5.dfsg+1.5.0.4-0ubuntu1.dsc refers to firefox_1.5.dfsg+1.5.0.4.orig.tar.gz, but I can't find it in the queue or in the pool.
[06:05] <infinity> iwj: Ideal time to change the version number then. :)
[06:05] <Kamion> that's a katie message ...
[06:05] <iwj> Yes :-/.
[06:05] <infinity> Kamion: Yes, security is katie..
[06:05] <bluefoxicy> pitti:  some extensions don't work with ubuntu firefox 1.5.0.3 but do with normal 1.5.0.3
[06:06] <Kamion> infinity: right. so why didn't it send mail to iwj?
[06:06] <bluefoxicy> pitti:  does the version string or anything in Firefox change?
[06:06] <infinity> Kamion: Cause elmo recently mangled jackass, and it's now confused? :)
[06:06] <Kamion> joy
[06:06] <infinity> Kamion: (Or, I have no idea)
[06:06] <pitti> bluefoxicy: firefox -> iwj
[06:06] <bluefoxicy> iwj:  same question.
[06:06] <infinity> Kamion: But that's as good an explanation as any, given the odd issues we've had with jackass in the last day.
[06:07] <iwj> You know that 6.06 == 6.6 according to dpkg ?  This is fine because we actually mean what dpkg thinks we mean, but I just wanted to check that no-one thinks that  1.20 < 1.3
[06:07] <Keybuk> bluefoxicy: reference?  it does not appear to
[06:07] <Keybuk> bluefoxicy: posix leaves it up to the implementation to define how the mmap flags map to the underlying file permissions
[06:07] <iwj> bluefoxicy: Yes, the version number is modified appropriate for the ubuntu version but doesn't contain the ubuntu revision.
[06:08] <infinity> iwj: Yes, we know that, but using 6.06 and 5.10 sorts better for human parsers.
[06:08] <bluefoxicy> iwj: have you noticed any extensions deciding they don't like it for some odd reason?
[06:08] <infinity> iwj: Like when scanning directory listings.
[06:08] <iwj> infinity: Right.
[06:09] <iwj> And also we definitely never want ever to say 6.6 at anyone because then they'll propagate it and deviant people will think 6.6 > 6.10.
[06:09] <iwj> bluefoxicy: No, but I don't normally really deal with extensions.
[06:10] <infinity> bluefoxicy: I have several 3rd-party extensions installed in my firefox, and they all get on fine.
[06:10] <Kamion> Package: udpkg
[06:10] <infinity> Well, okay, s/several/three/ it looks like... SessionSaver, PageRank, and Stylish.
[06:10] <Kamion> Depends: libc6 (>= 2.3.4-1), libdebian-installer4-udeb (>= 0.42)
[06:11] <Kamion> woo, working udeb shlibdeps
[06:11] <Keybuk> :p
[06:11] <infinity> Kamion: Oh, halleluja.
[06:11] <infinity> Kamion: I also heard rumblings about working bi-arch shlibs?
[06:11] <Kamion> although I need new libc6 before the shlibdeps work for that too
[06:11] <Kamion> infinity: so the changelog saith
[06:11] <Kamion> I haven't tried
[06:11] <infinity> Kamion: That would be awesome.
[06:12] <Kamion> right, I think this debhelper works well enough to upload
[06:12] <Kamion> infinity: also, go to bed
[06:12] <bluefoxicy> infinity:  I've had about 15, there was only ever 1 that bitched, it was a minor thing I don't remember what and it honestly isn't important.  *shrug*
[06:12] <infinity> Kamion: Err, yes, sorry -- stop being interesting.
[06:14] <jdub> mdz: gar re: compiler discussion. :-)
[06:16] <mdz> jdub: sometimes, banging rocks together is a legitimate problem-solving technique
[06:16] <mdz> especially if one of them is flint
[06:16] <jdub> mdz: ha ha
[06:16] <jdub> ha ha ha
[06:16] <jdub> for both meanings
[06:17] <mdz> I mean the mineral, not the gregarious American
[06:17] <highvoltage> lol
[06:17] <jdub> i was mostly laughing about the latter ;)
[06:17] <ogra> lol
[06:17] <ogra> me too :)
[06:19] <jdub> mdz: i know it sounds a bit fundamentalist, but i think the statement of not having a compiler because we don't expect to require one is 'good'
[06:20] <mdz> jdub: I think that our choice should be about meeting needs and not making statements
[06:20] <mdz> jdub: we could wrap gcc so that it prints a message intended to make the user feel guilty, if it would make you happy ;-)
[06:21] <mdz> jdub: I absolutely think we should maintain the attitude that it shouldn't be required for normal operation, but in the situations when it is useful, goddamn is it useful
[06:21] <jdub> mdz: right, but it's as much a statement and commitment to ourselves as to our users.
[06:21] <dholbach> I think Jeff was more implying that it should send a message to us, if a 'normal users' had to use it :-))
[06:22] <Kamion> dholbach: sometimes that message is "doesn't proprietary software suck", but there's not a lot we can do about that
[06:23] <jdub> mdz: we do make them very attainable, and we could make that much easier (by having sweet meta selections in g-a-i).
[06:23] <mdz> dholbach: we can make the effort to address those use cases in better ways, where possible, without sacrificing the user's capacity to solve them today, by known and well-documented methods
[06:25] <Kamion> somebody who knows it better than I do should merge cdbs after debhelper lands but before attempting to sync the rest of the world.
[06:25] <mdz> I don't think that denying them a compiler motivates them to learn why they don't have one, and work to make the world better
[06:25] <Keybuk> dholbach: can you do that?
[06:25] <dholbach> mdz: I absolutely see your point. I'm now just trying to find out, how useful it would be without all kinds of development libraries etc. and maybe I should just shut up, as I don't have a very strong opinion on it
[06:25] <Keybuk> I think it's mostly your diff, no?
[06:25] <mdz> I think it stops them in their tracks and frustrates them (and the linux-savvy person trying to help them)
[06:26] <dholbach> Keybuk: I can try
[06:26] <Kamion> if you want to test it now, build {(libsepol -> libselinux -> dpkg), po4a} -> debhelper
[06:26] <Kamion> from edgy
[06:26] <mdz> dholbach: the primary use case I'm interested in is building kernel modules
[06:26] <dholbach> Keybuk: dunno how much other diff we have - I guess pitti's langpack magic as well
[06:26] <iwj> How wrong would it be to solve my autoconf problem in this firefox backport by running `autoconf && automake' on dapper in the tree ?
[06:26] <Keybuk> ah, good point, there's that too
[06:26] <mdz> dholbach: my proposal is build-essential + linux-headers
[06:26] <pitti> dholbach: in which package? glibc?
[06:26] <dholbach> pitti: cdbs
[06:27] <pitti> ah
[06:27] <pitti> right, mine and xubuntu's
[06:27] <dholbach> mdz: I agree, that's quite useful
[06:27] <pitti> Keybuk: shall I merge cdbs?
[06:27] <Kamion> dholbach: most people who distribute semi-proprietary stuff for building on random people's systems go to large amounts of effort to avoid requiring extra development libraries
[06:27] <Keybuk> pitti: if you can, that'd be great
[06:27] <Kamion> dholbach: simply because doing so brings their own support costs down
[06:27] <pitti> Keybuk: Debian has a lot of bug fixes, I'd love to upgrade
[06:27] <pitti> Keybuk: ooooooorlright
[06:28] <mdz> jdub: they're attainable, but not discoverable
[06:28] <mdz> jdub: and g-a-i isn't a good answer on the live CD
[06:28] <Kamion> pitti: please let infinity know to add it to the end of his build-dep chain of doom after debhelper
[06:28] <pitti> Keybuk: in about an hour, need to do some RL stuff
[06:28] <pitti> Kamion: ok
[06:28] <jdub> mdz: that's why i said it ;) why isn't g-a-i a good answer? can't handle ship?
[06:28] <Kamion> although it doesn't actually build-depend or depend, it does use some features from newer debhelper
[06:28] <Kamion> e.g. dh_installudev
[06:29] <jdub> mdz: could be another one of those things that is installed on live but removed on desktop
[06:29] <Kamion> jdub: that process unfortunately slows the installer down quite a bit so it should be reserved for quite special cases
[06:29] <Kamion> and also drastically different user experience on live CD vs. installed system confuses the user
[06:29] <Kamion> so ubiquity tries only to remove stuff that really does only make sense on the live CD
[06:30] <mdz> jdub: Installed-Size
[06:30] <jdub> mdz: :)
[06:30] <mdz> the headers alone are like 25M
[06:30] <mdz> it's a lot of RAM to install enough stuff to build a kernel module on the live CD
[06:30] <jdub> (yeah, thus the next alternative)
[06:31] <mdz> jdub: then there's no way to get it on the installed system except downloading it
[06:31] <dholbach> Kamion: yeah, I can see that.
[06:31] <jdub> mdz: 'cos it won't fit in ship and in live?
[06:32] <Kamion> jdub: correct
[06:32] <Kamion> jdub: (well, ship-live and live)
[06:32] <Kamion> ship doesn't go on the live CD
[06:32] <jdub> yeah
[06:34] <jdub> whoa, rad smart patch from mvo
[06:34] <dholbach> What is the policy on -updates and -backports uploads? do they have to have satisfyable build-depends from ${stable_release} or can the build-deps be from -updates themselves?
[06:35] <_ion> jdub: What patch?
[06:37] <Kamion> right, I think I have to stop relying on dep-wait and wait for buildds now
[06:38] <Kamion> cdebconf's build-dep is such that it won't reliably dep-wait on libdebian-installer on Ubuntu buildds, and I don't want to make infinity's manual bootstrap chain any longer
[06:39] <Kamion> dholbach: I believe -updates allows build-depends: -updates, not sure about -backports
[06:39] <iwj> pitti: 3rd go at 1.5.0.4 uploading to security.upload now.
[06:40] <dholbach> Kamion: cool, so ekiga 2.0.2 would actually be possible for dapper-updates
[06:40] <Kamion> _ion: see edgy-changes
[06:41] <_ion> kamion: Thanks.
[06:41] <Kamion> dholbach: check with infinity if you want to be sure
[06:41] <dholbach> Kamion: yeah. thanks
[06:41] <_ion> A nice patch indeed.
[06:47] <dholbach> http://ftp.gnome.org/pub/GNOME/sources/ekiga/2.0/ekiga-2.0.2.news looks really good
[06:48] <jdub> oh rad
[06:48] <dholbach> but for that we'd need a new opal and new pwlib in -updates, it seems
[06:48] <jdub> - Does not drown children anymore
[06:48] <jdub> ^ great fix!
[06:49] <Kamion> mdz: oh, BTW, *-meta needs a bit of a fix before it works with new germinate, but I think instead of fixing that I'm going to work on moving the guts of the update script into germinate
[06:49] <Kamion> mdz: I might see if I can make it pull from bzr itself while I'm at it
[06:49] <Kamion> mdz: however, that's for tomorrow
[06:49] <Kamion> night all
[06:49] <mdz> sure
[06:50] <mdz> night
[06:50] <dholbach> night Kamion
[06:50] <ogra> night Kamion 
[06:52] <mdke> does logging out restart X? I'd like an authoritative answer for a docs question
[06:52] <mdz> mdke: it depends, but typically it only resets the X server
[06:52] <mdke> mdz: so changes to X configuration are not applied?
[06:54] <mdz> mdke: not reliably
[06:54] <mdz> mdke: there is an option in gdm for this, which I think defaults to false
[06:55] <mdz> mdke: dholbach can confirm for sure
[06:55] <sivang> mdz: doesn't it have something like a 'reload' target as in regular daemons ?
[06:55] <mdke> mdz: that is enough for my purposes, I think. Thanks
[06:56] <mdz> sivang: yes, it does
[06:56] <dholbach> It might be 'AlwaysRestartServer'
[06:57] <Keybuk> right, I'm gonna go put my feet up for a bit
[06:57] <Keybuk> may be back later
[06:57] <mdz> dholbach: that's the one I mean, yes
[06:57] <stuNNed> peaceful relaxing key
[06:58] <stuNNed> keybuk*
[06:58] <mdz> dholbach: if it's true, the server is always restarted, if false, it is usually reset
[06:58] <mdke> right, great
[06:58] <mdz> if reset, changes to the configuration file will not take effect
[07:00] <zul> Kamion: ping
[07:01] <tseng> mdz: did you have any special thoughts on beagle?
[07:01] <tseng> mdz: it made its own line item on EdgyIdeas
[07:03] <mdz> tseng: my only thought is "make it go and see what breaks"
[07:03] <dholbach> ogra: hm?
[07:03] <ogra> dholbach, Accepted eog 2.15.2-0ubuntu1 (source)
[07:04] <dholbach> ogra: Yeah :-)
[07:04] <ogra> your first edgy upload :)
[07:04] <dholbach> slowly.... :-)
[07:04] <dholbach> ogra: nah - did deskbar-applet yesterday :-)
[07:04] <dholbach> or this morning
[07:04] <ogra> heh, oh, i thought that was dapper-updates 
[07:04] <dholbach> there was one to dapper-updates as well
[07:05] <dholbach> YAY for two GNOME releases :-)
[07:05] <ogra> :)
[07:05] <dholbach> what will your first edgy upload be?
[07:05] <mdz> tseng: it deserves a spec detailing what will be necessary
[07:05] <mdz> tseng: especially as regards the installer
[07:05] <tseng> mdz: sure.
[07:06] <tseng> the only thing needed on the installer side is defaulting /home to user_xattr
[07:10] <pitti> dholbach: is dholbach_iconcache in Debian already?
[07:10] <ogra> HAHAHA
[07:10] <ogra> cool :)
[07:10] <dholbach> pitti: it's in discussion with the gtk-gnome-debian folks
[07:10] <pitti> dholbach: alright
[07:10] <dholbach> pitti: they will need to make changes to it, so they can take the transition a bit slower
[07:12] <sivang> ah, dhlobach_iconcache, what a snippet
[07:15] <jdub> http://fridge.ubuntu.com/node/412
[07:15] <jdub> ^ untz untz untz
[07:15] <tseng> jewel case!
[07:15] <tseng> snazy
[07:16] <dieman> rock
[07:16] <dieman> sold by amazon even
[07:16] <highvoltage> whohoo!
[07:16] <dieman> so my damn prime membership counts for something
[07:16] <desrt> $9.99?!
[07:16] <desrt> crikey.
[07:16] <tseng> its a dvd
[07:17] <highvoltage> jdub: does ubuntu get some of that money back, at least?
[07:17] <desrt> i'm sure it doesn't cost more than $1 to press a DVD and put it in a jewel case and wrap it
[07:17] <tseng> desrt: so whats your point?
[07:18] <dieman> is it the same as the dvd isos?
[07:18] <dieman> or does it have extra features?
[07:18] <tseng> i am sure it is
[07:18] <desrt> tseng; seems expensive
[07:18] <highvoltage> i'd be happy to py US$10 for ubuntu cd's if it means making ubuntu more sustainable.
[07:18] <HiddenWolf> me too
[07:18] <jdub> highvoltage: yeah, we do
[07:18] <highvoltage> (off-topic, sorry, i'll stop)
[07:19] <desrt> jdub; that's nice, at least
[07:19] <jdub> highvoltage: where did those ubuntu pc stickers come from?
[07:19] <dieman> one ad on google offers $.80 'retail ready' dvd stuff
[07:19] <highvoltage> just a sec...
[07:19] <desrt> jdub; have y'all considered an optional $1-per-cd donation type thing for shipit?
[07:19] <desrt> jdub; just paypal or whatever
[07:20] <jdub> desrt: remember that at some stage, ship it is going to go away :)
[07:20] <highvoltage> jdub: http://linux-schlepptops.de/product_info.php?cPath=22&products_id=28
[07:20] <desrt> jdub; sad :(
[07:20] <ogra> desrt, feel free :) http://www.ubuntu.com/donations
[07:20] <dieman> so for $12.05 more you get the book instead
[07:20] <pitti> thank god, Debian's cdbs dropped type-handling and ocaml
[07:20] <jdub> highvoltage: thanks
[07:27] <iwj> firefox_1.5.dfsg+1.5.0.4-0ubuntu6.06_source.changes ACCEPTED at last!
[07:30] <Burgwork> iwj,  I feel your pain
[07:32] <iwj> Burgwork: thanks :-).
[07:32] <pitti> iwj: yep, in my queue now :)
[07:32] <iwj> pitti: My attempt at a 1.5.0.4 backport for breezy has been building for an hour or two now.
[07:33] <pitti> that's a good sign already :) mine stopped after 10 minutes
[07:33] <iwj> I had to cheat and generate `configure' on dapper.
[07:33] <iwj> good sign> Quite.
[07:33] <tseng> does anyone know if jbailey is still planning on axeing linuxthreads from glibc
[07:33] <pitti> tseng: I thought that already happened?
[07:33] <iwj> With a bit of luck it will bomb out somewhere in the debian/rules install step, rather than in the middle of the compilation.
[07:33] <tseng> pitti: wow, i thought we skipped it for dapper
[07:34] <iwj> pitti: I'll keep you posted.
[07:34] <pitti>   * Drop LinuxThreads on all arches, require 2.6 on all architectures.
[07:34] <pitti> tseng: ^
[07:34] <tseng> cool
[07:34] <pitti> tseng: in edgy (first upload)
[07:34] <Burgwork> iwj, are you not going to have to backport 1.5.04 to hoary as well?
[07:34] <tseng> mm looked at the wrong one
[07:34] <tseng> cheers
[07:34] <crimsun> pitti: the odd thing is that if you read the line below, it's confusing
[07:35] <pitti> hey crimsun 
[07:35] <crimsun> 'lo pitti :)
[07:35] <pitti> crimsun: btw, shall we fix this alsa-lib path in dapper-updates?
[07:35] <crimsun> pitti: I want to test more rigorously before committing that fix
[07:36] <crimsun> pitti: as it stands now, we have a known workaround for the one corner case
[07:39] <crimsun> pitti: is that palatable by you?
[07:40] <pitti> sure
[07:40] <crimsun> pitti: ok
[07:47] <iwj> Burgwork: Yes, probably, but I think I'll start with breezy because I know how to do that.
[07:48] <iwj> I have no real idea about hoary; it was rather before my time.
[07:57] <Tonio_> hi
[07:59] <iwj> Right, that's it from me for today I think.
[08:00] <pitti> dholbach: do you think I can send the dh_iconcache stuff to Debian's cdbs? after all, it checks for its existence before calling it
[08:01] <dholbach> pitti: I'm not quite sure, if we shouldn't wait with that until it's at least available in Debian's debhelper.
[08:01] <pitti> dholbach: ok
[08:01] <dholbach> Thanks.
[08:01] <tseng> the Debian guys arent that crazy about iconcache iirc
[08:02] <dholbach> tseng: the transition is not as easy for them as it is for us
[08:02] <tseng> they don't have a dholbach 
[08:03] <dholbach> tseng: but the discussions I had with some of the debian gnome folks were quite good.
[08:03] <dholbach> . o O { he must be making fun of me... }
[08:03] <tseng> :(
[08:03] <tseng> hugs.
[08:03] <mdz> tseng: only /home?
[08:04] <jdub> mdz: arf, now you've hit the list with it! :)
[08:04] <tseng> mdz: unless otherwise prodded, beagled is autostarted per user, and indexes in the confines of /home
[08:04] <mdz> jdub: it seems the only sensible thing to do
[08:04] <tseng> mdz: other paths can be included or excluded
[08:04] <mdz> jdub: this channel isn't exactly representative ;-)
[08:05] <jdub> mdz: i've been thinking about it a bit, and i reckon i could do a rousing speech about why we shouldn't. ;-)
[08:05] <tseng> mdz: it would be sensible to do everywhere imo, I have yet to find an ill effect
[08:06] <mdz> jdub: please do it in the thread then :-)
[08:06] <dieman> the only thing i worry about beagle is if a pile of users start indexing about the same time
[08:06] <dieman> against an nfs mounted home
[08:07] <jdub> tseng: there's the system daemon for indexing everything else
[08:07] <dieman> does beagle throttle back pretty well if its not getting the IO it wants?
[08:07] <tseng> jdub: there isnt really such a thing
[08:07] <tseng> jdub: a cronjob spawns beagle-static-index to do /usr/share/app and /usr/share/doc
[08:07] <dsas> does beagle switch off when I'm using my laptop battery? Or will it just keep my hard drive spinning?
[08:08] <jdub> tseng: yeha
[08:08] <tseng> jdub: static indexes are loaded by beagled at start
[08:08] <tseng> when i say sensible to do everywhere, I was referring to mounting user_xattr
[08:08] <tseng> sorry that wasnt clear, there is alot of scrollback in between
[08:12] <dieman> oh creepy, they are working on shared beagle indexes with disvoery by avahi
[08:12] <dieman> discovery
[08:12] <tseng> that would require a rework of the webservice, first
[08:12] <dholbach> that's like wiki-ing porn! lovely
[08:13] <dieman> ahh, its an SoC project
[08:13] <dholbach> imagine it at an ubuntu conference! woohooo!
[08:13] <dieman> http://www.advogato.org/person/kwa/diary.html?start=4
[08:19] <pitti> dholbach: that gives 'Open Source' a fully new meaning -- 'open a source to all s3kr3t files of my wlan mates :-D
[08:20] <dholbach> yeah, that's what we all love about it
[08:21] <LaserJock> is edgy-changes open for business?
[08:21] <Burgwork> LaserJock, yes
[08:21] <dholbach> LaserJock: yes
[08:21] <pitti> LaserJock: yes, you have to sub yourself, though
[08:22] <LaserJock> pitti: ah, I wondered why I hadn't gotten anything yet, thx
[08:23] <LaserJock> pitti: are you comfortable with tex packages? I know you've uploaded a few but ar you in contact with the Debian TeX maintainers?
[08:23] <pitti> LaserJock: occasionally only, to forward security patches
[08:23] <pitti> LaserJock: I know LaTeX a fair bit, but actually only little about the packaging
[08:24] <LaserJock> pitti: is there  somebody in core-dev that does?
[08:24] <pitti> LaserJock: hm, I doubt it. Mithrandir maybe, but he might not be a guru either
[08:24] <LaserJock> I'm getting some pretty stern emails from the Debian TeX maintainers, but I can't find anybody in Ubuntu that really wants to touch it much ;-)
[08:25] <LaserJock> I use it but like you I know virtually nothing about packaging it
[08:26] <LaserJock> I can sort of keep track with the Universe side a bit but most the real bug action is in the Main pacakges
[08:26] <pitti> so, cdbs test suite passes now, a xfce, gnome, kde package and postgresql build fine without any debdiff. did I forget anything?
[08:26] <dieman> LaserJock: whats the stern emails about?
[08:27] <dieman> LaserJock: i actually ahve users that depend on tex a lot
[08:27] <LaserJock> dieman: that Ubuntu doesn't fix things fast enough, etc.
[08:27] <dieman> LaserJock: are there new bugs that ubuntu is introducing?
[08:28] <dieman> LaserJock: or is this just 'you dont grab our less buggy packages with new bugs often enough'?
[08:29] <LaserJock> dieman: more like we didn't get bug fixes incorporated from Debian fast enough
[08:29] <LaserJock> dieman: not really stuff we are introducing
[08:32] <LaserJock> anyway, I was just wondering if there was a core-dev contact for TeX packages, but it seems there really isn't
[09:08] <Kamion> zul: pong
[09:08] <Kamion> tseng: the installer change is actually not *entirely* trivial (not like seriously non-trivial, but needs a little code I think)
[09:09] <Kamion> tseng: what's the spec? I probably need to be allocated a bit of time to do it
[09:09] <tseng> i went to file one called ubuntu-integration
[09:09] <tseng> https://launchpad.net/distros/ubuntu/+spec/beagle-integration
[09:09] <tseng> but already here
[09:09] <tseng> https://wiki.ubuntu.com/BeagleIntegration
[09:09] <zul> Kamion: do you want me to take a run at grub for edgy?
[09:09] <tseng> I brain-dumped to the wiki
[09:10] <Kamion> zul: sure, if you like
[09:10] <Kamion> IIRC the Debian package now has a lot of improvements
[09:10] <Kamion> zul: but hold off a day or two
[09:11] <Kamion> zul: we're still putting the toolchain and the packaging toolchain together
[09:11] <zul> sure ill just get a jump on it though
[09:11] <Kamion> yeah
[09:14] <BenC> is dapper-security open yet?
[09:14] <tseng> yes
[09:14] <BenC> ok, thanks
[09:17] <mjg59> Given an object file, is there any reasonable way to split it back into its constituant objects?
[09:20] <sivang> mdz: do you know if the launchpad bug reporting tool would also serve as what I Have proposed in https://launchpad.net/distros/ubuntu/+spec/launchpad-login-app ? If not, I'd like to resuggest it for Paris, if it's not completely inappropriate.
[09:21] <sivang> mdz: (the one of the SoC, that is)
[09:24] <Kamion> LaserJock: yeah, we've never really had a TeX expert in core
[09:25] <dieman> im lucky when i can figure out what the problem is with tex
[09:37] <LaserJock> Kamion: well, I'm going to try to at least be a bit of a go-between. If I can at least forward bugs to Debian and get their opinion maybe I can at least poke somebody in core-dev to upload for me
[09:38] <LaserJock> hmm, I have a lot of "at least"s in there
[09:43] <Kamion> LaserJock: sounds good
[09:44] <LaserJock> somehow MOTU Science has become the TeX target ;-)
[09:46] <lucas> LaserJock: I packaged libgsl-ruby (ruby bindings for gnu sci lib), it will soon be in NEW in debian
[09:47] <lucas> a "bindings for GSL" action might be an idea for MOTU Science
[09:48] <LaserJock> cool
[10:14] <cge> Is there a way to get a specific slightly older version of linux-source-2.6.15?
[10:19] <ubijtsa> mdz: if you were after debate regarding installing gcc, I am sure you will get your wish :)
[10:20] <mdz> ubijtsa: I admit to stirring the pot
[10:21] <ubijtsa> mdz: but it is good to do so from time to time.. 
[10:21] <ubijtsa> like the libdvdcss issue
[10:26] <NuxTech> cge: see http://www.kernel.org/pub/linux/kernel/v2.6/
[10:27] <ubijtsa> mdz: a suggestion would be to install it in the LiveCD image, but leave it on the install media for the installer images, and including a System menu-option to pull in full development (read gcc) tool-chain from net or CD.
[10:28] <ubijtsa> the LiveCD environment is less vulnerable from a intrusion perspective.. 
[10:28] <Kamion> please follow up on the mailing list so that suggestions are archived
[10:29] <ubijtsa> Kamion: I can summarise and post later if you like, I'd like some opinion now if no-one mind contributing
[10:29] <cge> NuxTech: Err, I mean the Ubuntu-specific changes, like changes in configuration between 2.6.15-19 and 2.6.15-22.xx
[10:31] <bluefoxicy> guys, what exactly does ubuntu do when packages are built?
[10:31] <bluefoxicy> any special patches to i.e. gzip, or strange gcc flags?
[10:31] <NuxTech> oops - kernel, panic!
[10:32] <Kamion> bluefoxicy: no strange gcc flags any more (we used to use a gcc wrapper that made sure e.g. gcc optimisation options were within sane limits, but that's turned off for edgy now)
[10:33] <Kamion> bluefoxicy: pkgstriptranslations is installed on the buildds to do language pack munging on packages
[10:33] <Kamion> bluefoxicy: and that's about it
[10:33] <Kamion> everything else is in the package's debian/rules and descendant scripts
[10:33] <bluefoxicy> Kamion:  I am getting reports back that ubuntu is PARTICULARLY unhappy with the mprotect() from pax, which is generally sane to use aside from a very small set of very special cases.
[10:33] <Kamion> well if that's true then you can build it yourself with the regular packaging toolchain and find out
[10:34] <bluefoxicy> Kamion:  Looking at oprofile, I'm noticing a lot of strangeness, for example gzip briefly executes code from what seems to be anonymous mappings.
[10:34] <bluefoxicy> hmm.  I could yes.
[10:34] <bluefoxicy> Kamion:  I'm pretty sure things shouldn't be executing the stack or anonymous mappings, even python seems to be executing a fair bit that way (which indicates code generation at runtime)
[10:35] <bluefoxicy> I'll look into it.
[10:35] <bluefoxicy> Kamion:  You won't use -O3 or anything insane like that on Edgy will you?  -O2 should be quite fine... -O3 optimizations typically can make code faster, slower, bigger, or smaller
[10:35] <Kamion> we used to force -pipe and -mtune=pentium4 -march=i486
[10:35] <Kamion> but -mtune=pentium4 -march=i486 is gcc default now
[10:35] <bluefoxicy> that sounds sane.
[10:35] <Kamion> and who cares about -pipe
[10:36] <Kamion> bluefoxicy: -O3> it's up to the packages,.
[10:36] <bluefoxicy> -pipe is a non-issue.
[10:36] <bluefoxicy> Kamion:  on a side note, -funit-at-a-time should be sane (read a whole source file for processing, rather than going function by function.. makes optimizations work better)
[10:36] <netdur> I'm trying to master livecd... I used to /etc/skel for default settings but it doesn't work anymore with dapper... what going on?
[10:37] <bluefoxicy> but don't quote me on that, I heard of breakage back when it was first introduced ... I think in gcc 3.4
[10:37] <Kamion> bluefoxicy: if individual packages want to use that, that's great, but until it's the gcc default, I doubt we'll force it
[10:37] <Kamion> until/unless, that i
[10:37] <Kamion> is
[10:38] <Kamion> I imagine it only makes a difference on a small number of packages anyway
[10:39] <bluefoxicy> Kamion:  I used it with gentoo, I recall it having a non-noticible impact but making a visible difference on very close examination.  It's been a while though.
[10:39] <eXistenZ> any cups developer?
[10:44] <Kamion> bluefoxicy: "non-noticeable impact but ... visible difference"> be consistent man ;-)
[10:44] <Kamion> if it's not noticeable, it's not worth the risk of extra build failures we would have to spend developer time cleaning up.
[10:44] <Kamion> or runtime failures, even worse
[10:44] <bluefoxicy> Kamion:  not noticible i.e. it's not running faster, using less memory, etc.  The system is responsive and fast as is.
[10:44] <Kamion> well, not worth it then
[10:44] <bluefoxicy> Kamion:  visible difference i.e. glibc is 30k smaller or such.
[10:45] <bluefoxicy> Kamion:  using a profiler would be good if I was any good at it ;)
[10:45] <Kamion> if users can't tell the difference, it's not worth the risk to keep profilers happy
[10:46] <Kamion> not across the board, anyway. individual packages can use it after testing if they want.
[10:54] <bluefoxicy> umm
[10:54] <bluefoxicy> Kamion:  you're on dapper right?
[10:59] <mdke> EDGY
[11:00] <bluefoxicy> I thought the devs weren't going to boot edgy for 3 weeks
[11:01] <LaserJock> doko: ping?
[11:02] <bluefoxicy> Kamion:  one of the gentoo guys is telling me that gzip has a really easy fix and it's in gentoo; and that locale should NOT have that behavior and the fix for it comes from DEBIAN
[11:02] <doko> LaserJock: pong
[11:04] <LaserJock> doko: did you change anything to fix bug #45292 and #44891 ?
[11:04] <Ubugtu> Malone bug 45292 in sun-java5 "sun-dlj-v1-1 license could not be presented" [Low,In progress]  http://launchpad.net/bugs/45292
[11:04] <Ubugtu> Malone bug 44891 in sun-java5 "Installation Fails" [Medium,In progress]  http://launchpad.net/bugs/44891
 start with gzip <solar> when it's building enable --disable-asm <solar> or what have you. the problem there is it's hand written asm
[11:04] <sivang> don't we support bluetooth with some GUI ootb ?
[11:04] <bluefoxicy> easy enough.  *checks portage and files a bug*
[11:06] <doko> LaserJock: these are fixed, we are waiting for 1.5.0_07
[11:06] <LaserJock> doko: how were they fixed? in the java package itself?
[11:06] <LaserJock> preinst script?
[11:07] <bluefoxicy> wtf.
[11:07] <bluefoxicy> QUESTION:  Who is in charge of glibc so I can tag this bug appropriately ~_~
[11:07] <doko> LaserJock: yes
[11:08] <LaserJock> doko: could I get that preinst script from you? I'm basing a package off of your debconf scheme and I ran into the same problem
[11:12] <Burgwork> sivang, being worked on by mjg59 for gnome SoC
[11:13] <doko> LaserJock: see https://jdk-distros.dev.java.net/source/browse/jdk-distros/trunk/linux/ubuntu/
[11:14] <sivang> Burgwork: ah, cool
[11:14] <sivang> Burgwork: a new tool are help to gnome-bluetooth ?
[11:14] <bddebian> Heya
[11:15] <Burgwork> sivang, a new stack, afaik
[11:16] <LaserJock> doko: thank you very much
[11:20] <Kamion> bluefoxicy: file it on glibc in malone; don't worry about who's in charge of it
[11:20] <Kamion> LaserJock: if you installed off a pre-release live CD then 'dpkg-reconfigure debconf' and switch to dialog
[11:21] <Kamion> bluefoxicy: gzip> not my package, sorry, no idea; could easily be it was fixed post-dapper-UVF and we never noticed
[11:21] <LaserJock> Kamion: right, but I'm trying to create a package that handles that better
[11:21] <Kamion> bluefoxicy: dapper/edgy> I don't see why it matters, but I have one system on edgy to test bringing up the packaging toolchain
[11:22] <Kamion> LaserJock: the required fix is to handle db_input exiting with code 30 and print a nice message when it does so
[11:22] <bluefoxicy> Kamion:  I got an obscene picture by opening gnome-terminal, typing 'banner f', highlighting the output, and middle-click pasting it somewhere wider.
[11:22] <Kamion> assuming you're doing db_input critical
[11:22] <bluefoxicy> I just want to know if that's normal
[11:22] <LaserJock> Kamion: yeah, ok thanks.
[11:22] <Kamion> bluefoxicy: it's an f, sideways
[11:23] <bluefoxicy> http://rafb.net/paste/results/jkda4B98.html is what I got
[11:23] <bluefoxicy> but I didn't enlarge gnome-terminal before hand
[11:23] <Kamion> that's an f, sideways, with broken wrapping
[11:23] <bluefoxicy> ... yeah.
[11:24] <Kamion> nobody sensible has any time for you on that
[11:24] <bluefoxicy> Kamion:  nod.  I'm trying to figure out why ld.so is using old_mmap() right now instead of mmap()
[11:25] <bluefoxicy> Kamion:  just ignore me, I'm wasting air :)
[11:25] <Kamion> yes, you do appear to be. please do it on a different channel
[11:52] <bddebian> fabbione: ping?
[11:57] <zul> hes probably sleeping bddebian 
[11:57] <bddebian> Ah
[11:58] <mgalvin> hmm, i notices some security? updates (libtiff, etc...) but did not ever see any upload notification via dapper-changes, does anyone know where/if the upload emails are sent?
[12:00] <mgalvin> pitti: ^^^
[12:02] <Kamion> mgalvin: security updates don't go to dapper-updates, but dapper-security; there's no upload notification for them, only USNs
[12:02] <mgalvin> Kamion: ok thanks