[02:04] <bddebian> Heya
[02:05] <Keybuk> heyheyhey
[02:06] <bddebian> Hi Keybuk
[02:06] <Keybuk> how goes?
[02:06] <bddebian> You are speaking to me? :-)
[02:07] <Keybuk> why should I not?
[02:08] <bddebian> Because I am a pain in the butt? :-)
[02:08] <whiprush_> keeeeeeeybuk!
[02:08] <bddebian> Anyways, OK, thanks.  You?
[02:08] <bddebian> Hello whiprush_
[02:08] <whiprush_> hi bddebian 
[02:09] <Keybuk> *shrug* I've never noticed if you are :p
[02:09] <Keybuk> I'm a pain in the neck, myself
[02:10] <bddebian> heh
[02:10] <Keybuk> or possibly a pain in the testicles
[02:11] <bddebian> hmm
[02:13] <dieman> bah, bastards.
[02:14] <dieman> some company is renting gps units in paris for walking tours now
[02:14] <dieman> figures i finally break down and get a gps
[02:14] <zul> hmm...lets go break grub
[02:14] <Keybuk> I've still yet to succum
[02:14] <dieman> heh
[02:14] <dieman> picked up an etrex vista
[02:14] <dieman> it also works on the bicycle
[03:19] <whiprush_> jdub: any word on that ubucon thing post-LWE? the wiki/list are dead.
[03:21] <jdub> i subbed
[03:21] <jdub> totally quiet
[03:21] <jdub> i think i will contact the dude, see what i can help with, before saying anything on list
[03:31] <BenC> so when will the edgy buildd's start actually building stuff?
[03:32] <bddebian> Uh oh
[03:32] <bddebian> You just delayed it another 2 weeks :-)
[03:33] <BenC> heh
[03:45] <Keybuk> woohoo!
[03:45] <Keybuk> this actually does something when I ring it
[03:47] <bddebian> ??
[03:49] <whiprush_> jdub: fyi, I sent him a few mails, no response. One of my friends in the googleplex is asking on their internal list about what the deal with the event is.
[03:49] <jdub> whiprush_: hrm, ok
[03:50] <whiprush_> jdub: I am bringing lots of people from my lug, and some other ubuntu guys from ars are planning to attend, so if google is willing to host, we could probably do something sweet.
[03:51] <jsgotangco> good morning
[03:51] <Keybuk> bddebian: trying to get VoIP working
[03:52] <Keybuk> so Asterisk playing nice with a SIP provider
[03:52] <bddebian> Cool
[03:52] <bddebian> Heya jsgotangco
[03:55] <whiprush_> jdub: mostly, I'm concerned that if google is going to commit to hosting the thing, that we can get a good amount of community folks involved. (I'm worried about it because some of us need to get employers to sponsor us, buy plane tickets, etc.)
[03:55] <Keybuk> jdub: 4,000 dollars, eh?
[03:55] <Keybuk> oh, you didn't get cc'd on that one
[03:56] <jsgotangco> whiprush_: ubuntucon?
[03:56] <ajmitch> whiprush_: sneak in a plane ticket for me, will you?
[03:56] <whiprush_> jsgotangco: http://www.linuxpip.org/ubuconwiki
[03:57] <jsgotangco> 18-19
[04:33] <LaserJock> whiprush_: I was planing to go, but I email the list and never saw my email
[04:33] <LaserJock> whiprush_: I'm still interested if something turns out
[04:35] <whiprush_> LaserJock: you seem to be in the same boat as the rest of us. :D
[04:35] <LaserJock> whiprush_: where are you located?
[04:35] <whiprush_> LaserJock: Michigan
[04:35] <LaserJock> oh, that's some distance to go, I'm only 4 hrs drive away in NV
[04:36] <whiprush_> LaserJock: can't afford to go to paris, so I do what I can. :)
[04:37] <LaserJock> whiprush_: yeah, that's pretty good coming from Michigan
[04:41] <ajmitch> whiprush_: unless there's some miracle, I doubt I can make it either :)
[04:41] <stuNNed> is there way to install glibc 2.4 alongside ubuntu glib2 2.3 so that i can get the latest gnomad2 working with this blasted zen microphoto?
[04:41] <whiprush_> ajmitch: we need to win our respective lotteries...
[04:41] <stuNNed> :D
[04:41] <stuNNed> i'll pay very large bounty :D
[04:42] <ajmitch> whiprush_: yeah, but that means I need to buy a ticket or something
[04:42] <whiprush_> ajmitch: funny, I have the same problem
[04:56] <bddebian> Haha, take that Attal,  you POS
[04:58] <stuNNed> so there is no way to congruently run glibc2.4 alongside 2.3 so that i can install this dastardly bleeding edge package for my creative zen to work?  i lost the receipt
[04:58] <stuNNed> :D
[04:59] <Lathiat> ajmitch, whiprush_: i got a winnign notification in my e-mail just now, would you like some? :)
[04:59] <bddebian> hehe
[04:59] <bddebian> stuNNed: I don't know, sorry :-(
[04:59] <jsgotangco> haha
[04:59] <ajmitch> Lathiat: sure, send me your bank account details
[05:00] <Lathiat> only one catch you need to put $1500 up front so they can ship the money to you..
[05:00] <bddebian> Oh, you won the Nigerian Lottery? ;-)
[05:00] <Lathiat> howd you know!
[05:00] <jsgotangco> he won too
[05:01] <stuNNed> bddebian: that is ok, i'll figure it out :)
[05:02] <ajmitch> stuNNed: are you sure you're not mixing up glibc & glib?
[05:02] <bddebian> Oh, hmm
[05:02] <Keybuk> bleh, now it's stopped working again
[05:06] <bddebian> ajmitch: Wanna look at some packages for me? :-)
[05:07] <ajmitch> bddebian: not really, I'm doing stuff :)
[05:07] <bddebian> What a surprise
[05:09] <ajmitch> yes, some things have to be worked on now, rather than next week
[05:09] <bddebian> Hi Hobbsee
[05:09] <ajmitch> Hobbsee will do it for you
[05:10] <Hobbsee> heya
[05:10] <Hobbsee> what's this/
[05:10] <ajmitch> bddebian wants me to look at packages he's working on
[05:11] <bddebian> Hobbsee: I have packaged Attal 0.10 and I want it as clean as possible before sending over to Debian BTS :_)
[05:11] <Hobbsee> ah, i see..
[05:12] <bddebian> And ajmitch doesn't love me anymore
[05:13] <Hobbsee> poor bddebian :P
[05:23] <Hobbsee> bddebian: do you really expect me to be able to clean it up?
[05:24] <LaserJock> he expects perfection Hobbsee, nothing less :-)
[05:24] <Hobbsee> LaserJock: well, i'm far from perfect :P
[05:24] <bddebian> Hobbsee: No, but thanks
[05:24] <Hobbsee> :)
[05:29] <Keybuk> I can get it to accept calls and route them to the demo thing
[05:29] <Keybuk> I can register a softphone with it, and make outgoing calls from that
[05:29] <Keybuk> but if I try to connect the incoming calls to the softphone, *bam*
[05:31] <Keybuk> oh, and if I try and have the config that works for accepting calls, and the config that works for outgoing calls, at the same time *bam*
[05:31] <Keybuk> la la la
[05:32] <bddebian> You must enable bi-directional.. ;-P
[05:34] <Keybuk> I think I need to enable "read the docs and stop cargo-culting" :p
[05:35] <Hobbsee> Keybuk: reading documentation?  surely not!
[05:35] <Keybuk> it does appear that the authentication options that allow incoming prevent outgoing
[05:35] <Keybuk> and vice-versa
[05:35] <Hobbsee> very useufl
[05:39] <bddebian> "Your lack of faith disturbs me.." :-)
[06:31] <dieman> heh
[06:31] <dieman> theres a whole bunch of us at the comfort inn
[06:32] <dieman> down the street from the radisson
[06:32] <dieman> that will be a ragtag group on the street walking over
[07:08] <Keybuk> woohoo, I now have dialling in and dialling out allllmost working
[07:08] <Keybuk> just the sound is a bit one-way
[07:13] <Hobbsee> Keybuk: yay!
[07:15] <Keybuk> and I'm sure I've seen that in the tech-support area
[07:34] <wasabi_> Wonder what ever happened to dpkg file class support
[07:55] <womble> What packages need to be installed to verify Release signatures?  I've got a custom Dapper installer that's pitching a fit about unverified packages.
[08:57] <pitti> Good morning
[08:57] <jsgotangco> good morning pitti
[08:57] <Hobbsee> hey pitti 
[09:03] <jsgotangco> the teamspeak server is smoking hah
[09:04] <crimsun_> 'morning, pitti 
[09:06] <Keybuk> woohoo!  I rock
[09:06] <zyga> hello
[09:06] <zyga> :)
[09:06] <mvo> Keybuk: wooohhoooo! you rock!
[09:07] <pitti> hey crimsun_ 
[09:07] <pitti> jsgotangco: oh, how many people have played with it by now? :)
[09:07] <jsgotangco> pitti: 4
[09:08] <zyga> Keybuk: whoa! :)
[09:08] <pitti> Keybuk: did you get a proper voip phone?
[09:08] <Keybuk> and there's only one "remove this and the magic goes away" config option
[09:08] <jsgotangco> at the moment, me, imbrandon_ and TheMuso are in
[09:08] <Keybuk> pitti: no, that's the next step
[09:08] <Keybuk> pitti: for now I have ekiga on the laptop
[09:08] <imbrandon_> very nice
[09:08] <pitti> jsgotangco: yesterday it was quite fun
[09:08] <Keybuk> but I do have a proper UK phone number for it <g>
[09:09] <pitti> Keybuk: ever looked at http://www.sipgate.co.uk?
[09:09] <Keybuk> pitti: I tried sipgate, but didn't have much luck with them
[09:09] <pitti> Keybuk: I registered at sipgate.de the other day and now have a free .de number
[09:09] <Keybuk> so I was pointed at http://www.voip.co.uk/ which seems to work rather better
[09:09] <pitti> great
[09:09] <imbrandon_> vent is nice too for group 
[09:09] <imbrandon_> VoIP
[09:10] <Hobbsee> jsgotangco: pitti:  jsgotangco cant count - at least 5, so far
[09:11] <Hobbsee> this is fun :)
[09:11] <Keybuk> I guess the next step as well is to figure out how to support IP dialling
[09:13] <sivang> morning all
[09:13] <imbrandon_> moins
[09:14] <crimsun_> pitti: I have a quick question RE: mozilla-thunderbird's effect on thunderbird-quickfile (bug 49707). I wasn't sure whether a simple rebuild, which is confirmed to resolve the dependency issue, should be targetted for -security, but following the example for mozilla-thunderbird-enigmail, it seemed logical. Is that reasoning sound?
[09:14] <Ubugtu> Malone bug 49707 in thunderbird-quickfile "Latest Thunderbird update in dapper-security forces deinstallation of thunderbird-quickfile" [Medium,In progress]  http://launchpad.net/bugs/49707
[09:14] <Hobbsee> hey sivang 
[09:16] <pitti> crimsun_: yes, now that the archive is working again, I'll care for the extensions today
[09:16] <crimsun_> pitti: ah, ok. Thanks much.
[09:16] <pitti> crimsun_: enigmail is done, the rest is universe and thus doesn't need USNs
[09:16] <crimsun_> was just trawling LP and spotted that one
[09:21] <sivang> hey Hobbsee 
[09:21] <Hobbsee> heya
[09:22] <imbrandon_> come join the party 
[09:22] <imbrandon_> lol
[09:22] <sivang> party?
[09:22] <imbrandon_> was a /bad/ joke about TS
[09:28] <TheMuso> heh
[09:36] <pitti> jsgotangco: whoa, yesterday teamspeak.uds.ubuntu.com still worked, now it says 'host not found'
[09:37] <sivang> that's our teamspeak server to connect to?
[09:37] <sivang> (Doh)
[09:37] <TheMuso> People are still on here.
[09:37] <imbrandon_> i'm connected to teamspeak.uds.canonical.com
[09:37] <pitti> $ host teamspeak.uds.ubuntu.com
[09:37] <pitti> Host teamspeak.uds.ubuntu.com not found: 3(NXDOMAIN)
[09:37] <pitti> WTF???
[09:37] <imbrandon_> not ubuntu.com
[09:38] <imbrandon_>  teamspeak.uds.canonical.com
[09:38] <pitti> ah
[09:38] <pitti> yesterday it was u.c., thanks
[09:38] <imbrandon_> ;)
[09:38] <pitti> still doesn't work, the woman's voice shouts 'Error' into my ears
[09:38] <imbrandon_> ouch
[09:39] <imbrandon_> me and TheMuso are connected atm
[09:39] <imbrandon_> and jsgotangco
[09:39] <pitti> ah, now it works
[09:39] <imbrandon_> ;)
[09:39] <imbrandon_> he go on
[09:41] <mvo> doko: around?
[09:47] <jsgotangco> yeah
[09:47] <Hobbsee> sivang: it does.  ick
[09:47] <sivang> Hobbsee: porbably using installshield or something, they try to maintain consistant look
[09:48] <Hobbsee> must be
[09:50] <sivang> hmm, what do I run after installation?
[09:53] <Hobbsee> sivang: cd TeamSpeak2RC2/ && ./TeamSpeak
[09:58] <sivang> Hobbsee: yep, was in elmo 's instructions :p
[09:58] <Hobbsee> ah okay
[10:01] <infinity> wasabi_: Around?
[10:03] <jsgotangco> "German Ubuntu Mafia"
[10:06] <sivang> hrm, my teamspeak insists on retreiving a server list from the web and does not let me add canonical's one
[10:06] <TheMuso> sivang: Are you using the address book?
[10:07] <sivang> TheMuso: ah, thanks. terrible , terrible UI
[10:09] <sivang> seems I am connected, but why does that computer lady needs to shout in my ear "connection established" or something :p
[10:09] <jsgotangco> well its a game thing
[10:09] <TheMuso> I turned all sounds off.
[10:10] <Hobbsee> sivang: going to talk to us?
[10:10] <sivang> erm, I'm a bit shy ;-)
[10:10] <Hobbsee> sivang: arent we all?
[10:11] <sivang> we probably need to have a channel dedicated for text convo betwen the voip participants
[10:11] <kane_> Mithrandir: hello ... are you around ?
[10:12] <Hobbsee> sivang: that's true...
[10:12] <sivang> let's move over to #uds-paris-voip
[10:12] <imbrandon_>  /join #ubuntu-ts
[10:12] <imbrandon_> err ok
[10:12] <sivang> imbrandon_: you'd rather that one?
[10:12] <imbrandon_> dosent matter
[10:12] <imbrandon_> ;)
[10:13] <TheMuso> What is the channel?
[10:13] <Hobbsee> TheMuso: #uds-paris-voip
[10:13] <TheMuso> Thanks.
[10:19] <Mithrandir> kane_: hi
[10:20] <sivang> pitti: so don't use push to talk key? :)
[10:20] <pitti> sivang: I do use it
[10:20] <kane_> Mithrandir: i did what you suggested ... i.e., using debian-installer/framebuffer=false (if you don't remember this was for bug #48164)
[10:20] <Ubugtu> Malone bug 48164 in xorg "Video corruption at installation of xserver-xorg" [Medium,Confirmed]  http://launchpad.net/bugs/48164
[10:21] <Mithrandir> kane_: did it help?
[10:21] <kane_> Mithrandir: the installation works now, without any video corruption ... however, there is no boot splash with the new installation ... i'm guessing this is because the framebuffer is disabled ?
[10:21] <sivang> pitti: ah, so what were you proposing to me to do in order to make my stream sound better?
[10:21] <Mithrandir> kane_: probably, yes.
[10:21] <sivang> pitti: (I couldn't hear it well)
[10:21] <pitti> sivang: use PTT
[10:21] <kane_> Mithrandir: pity ... but atleast it works now
[10:22] <Mithrandir> kane_: what does "cat /proc/cmdline" give you?
[10:22] <kane_> one second ... the problem is on another machine, in another room ...
[10:25] <kane_> Mithrandir: root=/dev/hda2 ro quiet
[10:25] <Mithrandir> kane_: if you add "splash" to that list, you should get the bootsplash.  That you don't have it is a feature.
[10:26] <kane_> Mithrandir: how do I add splash to that list ?
[10:26] <kane_> Mithrandir: modify menu.lst ?
[10:26] <Mithrandir> yes
[10:26] <Mithrandir> change the defoptions line
[10:26] <kane_> Mithrandir: the fact that it isn't there is a good thing right ?
[10:27] <Mithrandir> yes, it's correct.  I was just thinking if you actually want usplash. :-)
[10:27] <kane_> Mithrandir: my users might find it more comforting if the usplash was actually working ... but in this case, wouldn't it cause video corruption ?
[10:28] <Mithrandir> kane_: maybe.  Which is why it's not there by default.  It might just be the Xorg probe function which messes it up and if so, it might work fine.
[10:28] <Mithrandir> we disable it to be on the safe side when you're using d-i/fb=false.
[10:29] <kane_> Mithrandir: ok ... so where does the Xorg probe function get called ?
[10:29] <Mithrandir> when Xorg is reconfigured.
[10:29] <Mithrandir> so not on normal boots.
[10:29] <kane_> aha ..
[10:29] <pitti> crimsun_: ping
[10:30] <kane_> so, if I do ... dpkg-reconfigure xserver-xorg ... then it should cause video corruption ?
[10:30] <Mithrandir> kane_: maybe, yes.  If you're using a framebuffer and not a text console.
[10:31] <kane_> hmm ok ..
[10:31] <kane_> Mithrandir: funny thing is, i tried pretty much all the kubuntu dapper flight versions (except 7) ... and they all worked
[10:39] <kane_> Mithrandir: ok, thanks a lot ... i've added the comment to the bug ... hopefully someone will notice and fix the probe function
[10:39] <kane_> Mithrandir: ciao
[11:04] <michele> hello
[11:05] <michele> I think I have this problem: https://launchpad.net/distros/ubuntu/+bug/22336/
[11:05] <Ubugtu> Malone bug 22336 in Ubuntu "laptop overheats when performing CPU intensive tasks." [High,Needs info]  
[11:05] <michele> and I think Dapper just fried my CPU
[11:06] <fabbione> if the CPU fried, you better change laptop brands. The CPU is supposed to go in protection if it overheats and shut down everything automatically
[11:07] <imbrandon> ^^ no matter the OS ( its a hardware thing )
[11:08] <michele> yes, I supposed that, I'm waiting for it to cool down and see if it powers on again
[11:08] <michele> it's a desktop, by the way
[11:08] <michele> a P4
[11:18] <michele> oh well... I'll wait for an answer to the bug by mdz...
[11:21] <Keybuk> why would mdz answer the bug?
[11:21] <Keybuk> it's assigned to mjg59 
[11:22] <michele> oh, didn't notice that, the last comment was from mdz
[11:22] <michele> well, somebody will answer, I guess and hopt :)
[11:43] <HiddenWolf> Is something wrong with dapper-security?
[11:46] <fabbione> HiddenWolf: why?
[11:46] <pitti> HiddenWolf: what?
[11:46] <HiddenWolf> I haven't seen any updates this week, while there have been quite a lot.
[11:46] <pitti> HiddenWolf: hm, works here
[11:47] <lifeless> cvd: you found it
[11:51] <HiddenWolf> pitti: I have dapper-updates and dapper-security enabled, yet gdm for instance is at 2.14.6-0ubuntu2.1, while 2.14.7-0ubuntu1 was uploaded to dapper june 6th
[11:51] <pitti>        gdm | 2.14.6-0ubuntu2.1 | http://security.ubuntu.com dapper-security/main Sources
[11:51] <pitti>        gdm | 2.14.7-0ubuntu1 | http://archive.ubuntu.com dapper-updates/main Sources
[11:52] <pitti> HiddenWolf: so you have the -security version
[11:52] <HiddenWolf> ah
[11:53] <HiddenWolf> then excuse me. :)
[11:54] <pitti> HiddenWolf: -updates are not built automatically; I guess seb128 didn't poke infinity hard enough
[11:54] <pitti> infinity: btw, what's the reason that every -updates upload needs to be built manually?
[11:54] <seb128> pitti: actually dholbach did that one while I was on VAC, but I didn't know we need manual pocking for every upload we do
[11:55] <seb128> I don't get the use for that
[11:55] <seb128> infinity: please build everything dholbach and I uploaded, thank you :
[11:55] <seb128> :p
[11:55] <pitti> infinity: please build libgnomeprint as well
[11:58] <pitti> brb, testing kernel security updates
[12:21] <infinity> pitti: How do you feel about caring about cdbs?
[12:21] <pitti> infinity: I would, what in particular?
[12:21] <infinity> pitti: I'm watching the build in progress right now, and it looks like the whole testsuite is failing.
[12:21] <pitti> infinity: uh, I'll have a look at the buildd output
[12:22] <pitti> infinity: I tested it carefully locally and it worked fine
[12:22] <infinity> pitti: Do you have an edgy choot (or a dapper chroot you can upgrade to edgy)?
[12:22] <pitti> infinity: my desktop runs latest edgy
[12:22] <infinity> pitti: Note that we now have a new debhelper and dpkg (as of a few hours ago), so the world may have broken for cdbs..
[12:22] <pitti> infinity: alright, I'll have a look as soon as this kernel security update is settled
[12:24] <fabbione> infinity, pitti: do we have an ETA for it?
[12:24] <fabbione> -security that's it)
[12:24] <pitti> fabbione: yes; current kernels will go into archive in 65 minutes, then l-r-m should build
[12:25] <pitti> fabbione: ideally, I can push l-r-m by the lp_archive run in 90 minutes
[12:25] <infinity> pitti: Oh, unless you really have to do staggered -security uploads, due toa bit of a bug in soyuz's handling of binary uploads from security, can you try to release source+allarches at the same time for a bit?
[12:25] <pitti> fabbione: then everything should be ready in 2 hours
[12:25] <infinity> pitti: Oh, or never mind.. :)
[12:25] <fabbione> pitti: that would be great.
[12:25] <infinity> (Since ia64's kernel still needs NEW... Feh)
[12:25] <pitti> infinity: oh, right
[12:25] <fabbione> oh meh. didn't elmo fix that yesterday?
[12:26] <pitti> infinity: can anyone NEW the ia64 kernel?
[12:26] <pitti> fabbione: ia64 wasn't yet built when elmo NEWed
[12:26] <infinity> pitti: Kamion (on VAC), mdz (asleep), and elmo.
[12:26] <fabbione> mdz/Kamion/elmo afaik
[12:26] <pitti> right
[12:26] <infinity> No other ftpmasters on jackass.
[12:27] <pitti> infinity: however, pushing ia64-only uploads out with amber seemed to have worked yesterday (I didn't check the archive, though)
[12:27] <fabbione> we will also need to new LRM once it's built
[12:27] <infinity> pitti: It broke soyuz's build queues, but nothing we can't beg cprov and Kinnison to work around.
[12:27] <pitti> so, ok for me to push all but ia64 out now?
[12:27] <fabbione> Kinnison: ping?
[12:27] <seb128> do we need approval before uploading to dapper-updates? Who need to be pinged for that?
[12:27] <Kinnison> fabbione: yes?
[12:27] <pitti> seb128: mdz
[12:28] <seb128> ok
[12:28] <infinity> pitti: Yeah, go ahead.  If we need it, we need it.
[12:28] <fabbione> Kinnison: are you still in charge of soyuz/publisher?
[12:28] <Kinnison> fabbione: Depends what you mean
[12:28] <infinity> pitti: I told the soyuz posse that we'd TRY to do releases of all arches at once, but -security on primary arches takes precedence sometimes (like now)
[12:28] <fabbione> Kinnison: after this kernel -security will go in, there will be a d-i upload to dapper-updates. We need to make sure that one is published properly
[12:28] <infinity> Kinnison: We're about to break ia64/security build records again, BTW.
[12:29] <fabbione> Kinnison: but afaik we did never tested d-i on a pocket that's not main distro
[12:29] <Kinnison> fabbione: Let me see if my patch is live on drescher
[12:29] <Kinnison> infinity: urgh
[12:29] <infinity> Kinnison: Can't really be helped. :/
[12:29] <infinity> Kinnison: At least I can tell you which build will break. :P
[12:30] <infinity> Kinnison: (linux-source-2.6.15 in dapper-security)
[12:30] <Kinnison> infinity: *nod* We need DB superpowah-man to clean up :-(
[12:30] <infinity> Kinnison: Really?  Mistress Fiera isn't l33t enough to clean up?
[12:30] <fabbione> Kinnison: while we publish -security please make sure that what you need is there because we will need to start preparing dapper sparc iso immediatly after d-i is tehre
[12:31] <Kinnison> infinity: Noone but the postgres superuser can DELETE FROM Build
[12:31] <infinity> Kinnison: She had enough access to change distro details, BTW (the -changes mailing list, specifically, though she had write access to that whole table)... I suspect that's a mistake, if you want to make a note of it.
[12:31] <Kinnison> fabbione: Erm if the code isn't there you're going to have to wait. Kiko won't let us have unreviewed code in the codeline
[12:31] <infinity> Kinnison: Though it was handy in a pinch when we needed to fix it. ;)
[12:32] <fabbione> Kinnison: i will take care of that.
[12:32] <ivoks> pitti: hplip is broken, not cups :)
[12:32] <pitti> ivoks: :/
[12:32] <Kinnison> fabbione: Right, my code fix is not live currently, so an upload of d-i to dapper-security would break horribly an I'd prefer you didn't do it yet
[12:33] <fabbione> Kinnison: dapper-updates
[12:33] <fabbione> Kinnison: not security
[12:33] <infinity> pitti: I'll pay you to look at cdbs and fix it for me, so the buildds can happily go back into full-auto mode (which will make -updates much happier..)
[12:33] <Kinnison> fabbione: dapper-updates, dapper-security, whatever, it's not dapper
[12:33] <ivoks> pitti: i can't print from fresh dapper install on HPLIP, and I can't print from breezy->dapper upgrade on HPLIP (but i can't print on USB either here)
[12:33] <fabbione> Kinnison: ok. can you please mail me the details about it and CC kiko, stevea and sab ?
[12:33] <fabbione> (and mdz please)
[12:33] <pitti> infinity: no need to pay me, I like it enough to care for it :)
[12:33] <Kinnison> fabbione: yep, give me a few mins
[12:34] <fabbione> Kinnison: thanks
[12:35] <infinity> pitti: That's perverse.
[12:36] <doko> pitti: GssSsp, firefox should build with the recent gcc-4.1 version in edgy
[12:36] <infinity> pitti: https://launchpad.net/+builds/+build/202163
[12:36] <pitti> fabbione, infinity: linux-source-* uploaded to drescher
[12:36] <infinity> pitti: Keep in mind that gcc-opt is dead (yay), so to reproduce the chroot exactly, just make sure it's up to date and make sure pkgstriptranslations is installed and enabled.
[12:37] <infinity> (Perhaps you missed that bit before?)
[12:37] <pitti> infinity: indeed I didn't try with pkgstriptranslations
[12:37] <fabbione> pitti: thanks
[12:38] <infinity> pitti: Could just be that a big NO_PKG_MANGLE around the testsuite will make it happy.
[12:38] <pitti> infinity: yep, will try in a minute
[12:38] <infinity> pitti: But I didn't actually look at it, just watched the log as it failed.
[12:39] <Harti> hello
[12:39] <Harti> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/49832
[12:39] <Ubugtu> Malone bug 49832 in firefox "firefox doesnt show website correctly" [Untriaged,Unconfirmed]  
[12:40] <fabbione> Harti: wrong channel #ubuntu-bugs please
[12:40] <Harti> fabbione: oh sorry
[12:40] <pitti> ok, so cdbs tests all pass right now, dist-upgrading to latest dpkg/gcc crack
[12:41] <pitti> doko: great, will try again
[12:41] <infinity> pitti: default gcc isn't changed yet (will in an hour).
[12:41] <infinity> pitti: So it's probably just dpkg/debhelper/perl.
[12:41] <infinity> (and most likely just debhelper that's breaking it..)
[12:41] <pitti> yes, I also revert to the archive perl, instead of my SSP-enabled crack
[12:42] <pitti> give my download pipe some minutes to finish the dist-upgrade
[12:44] <ivoks> pitti: ummm... i just did upgrade from breezy to dapper, and hplip package conflicts with hplip-base, but hplip-base stayed installed on the system
[12:48] <pitti> infinity: still works with latest edgy packages
[12:49] <jeroenvrp> https://launchpad.net/distros/ubuntu/+bug/49779
[12:49] <pitti> still works - WTF???
[12:49] <Ubugtu> Malone bug 49779 in Ubuntu "Keyboard locks up" [Untriaged,Unconfirmed]  
[12:52] <infinity> pitti: Ergh.  That's not what I wanted to hear...
[12:53] <infinity> pitti: When you enabled it, you also enabled "fail on invalid CB", right?
[12:53] <pitti> oops
[12:54] <pitti> infinity: since I don't have that file, it shouldn't matter
[12:54] <pitti> trying again, though
[12:55] <pitti> infinity: seems to work (first four tests passed)
[12:55] <infinity> pitti: I'm dist-upgrading to test here, but I assume that if you have a /CurrentlyBuilding that claims to be building Package: cdbs / Component: main, the world may explode...?
[12:55] <pitti> infinity: yes, indeed; trying that now
[12:56] <pitti> FAIL: autotools-1.sh
[12:56] <pitti> \o/
[12:56] <pitti> infinity: I wonder why we didn't have a problem with this in dapper
[12:56] <infinity> I think I may have added some NO_PKG_MANGLEs in the testsuite in dapper...
[12:56] <infinity> Maybe they fell out of your merge?
[12:57] <infinity> (base)adconrad@cthulhu:~/cdbs/cdbs-0.4.34ubuntu4$ rgrep NO_PKG *
[12:57] <infinity> debian/changelog:  * Set NO_PKG_MANGLE during the testsuite run, so we don't fail when
[12:57] <infinity> test/testsuite_functions:export NO_PKG_MANGLE=1
[12:57] <pitti> probably, yes
[12:57] <pitti> infinity: sorry for that
[12:59] <pitti> infinity: that was it, thanks
[01:00] <pitti> infinity: uploading a fixed version, maybe it'll still catch this cron.daily
[01:00] <infinity> pitti: I'm publishing manually right now.  It'll make it. :)
[01:02] <pitti> All 21 tests passed \o/
[01:02] <infinity> Huzzah.
[01:02] <infinity> pitti: You have the honour of being the very last package I'm building manually before I turn the buildds back on.  Aren't you lucky? :)
[01:03] <HiddenWolf> pitti is a package?
[01:03] <HiddenWolf> ;)
[01:04] <pitti> HiddenWolf: sometimes I feel like it
[01:05] <infinity> pitti's one hot package indeed, yes.
[01:06] <pitti> configure: error: installation or configuration problem: C++ compiler cannot create executables.
[01:06] <infinity> pitti: You realise that if you want to collect the binaries from jackass and upload to drescher later, you could have just ambered to jackass, then answered "no" to "upload to main archive"?
[01:07] <infinity> pitti: Since the -security buildds pull from jackass's archive, not from drescher.
[01:07] <pitti> infinity: oh, I thought they use the main archive
[01:07] <infinity> pitti: (A neat trick to remember if you need to do a staged release, but don't want to release stuff silently to the world)
[01:07] <pitti> infinity: then that's indeed a nice trick
[01:07] <pitti> thanks
[01:07] <pitti> /tmp/ccmU1H83.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
[01:07] <pitti> doko: ^ hmm? g++-4.1
[01:10] <pitti> strange
[01:11] <pitti> doko: ^ that's from firefox build
[01:12] <doko> :)
[01:12] <pitti> doko: 'CXX=gcc-4.1' ... 
[01:12] <doko> pitti: this is not #ubuntu ;-)
[01:19] <\sh> ok...today is bank holiday...we are sitting in the office, preparing a braai now...what a life
[01:21] <pitti> \sh: what is a braai?
[01:21] <pitti> \sh: and which bank holiday?
[01:21] <pitti> \sh: today is "Corpus Christi" (Fronleichnam)
[01:31] <Hobbsee> If there's a bug of a keyboard locking up on starting a DM, where should it be assigned to?
[01:32] <Mithrandir> as in, the keyboard stops working when a kdm/gdm starts?
[01:32] <Mithrandir> does it happen if you start X with startx?
[01:33] <pitti> infinity: so is l-r-m building already?
[01:33] <\sh> pitti: braai is a barbecue
[01:33] <\sh> pitti: ZA english
[01:34] <pitti> ah
[01:34] <\sh> pitti: and for us it's a bank holiday, no one is catholic ;)
[01:34] <Hobbsee> Mithrandir: i dont know - it only happens randomly, that's the trouble.
[01:35] <zul> heylo
[01:35] <Hobbsee> Mithrandir: and i couldnt get to a VT to try it out, as i didnt remember that that was possible with a mouse.
[01:35] <Mithrandir> Hobbsee: I'd probably say it's and xorg bug, but it's hard to say.
[01:36] <Hobbsee> Mithrandir: okay, thanks
[01:43] <pitti> fabbione, infinity: l-r-m is there, now we need elmo to NEW the stuff
[01:43] <fabbione> pitti: thanks
[01:47] <pitti> doko, iwj: yay, firefox builds with latest gcc-4.1 (even with ssp)
[01:47] <HiddenWolf> pitti: you're already working on proactive security for edgy?
[01:47] <pitti> HiddenWolf: I tested a couple of packages with SSP, yes
[01:47] <HiddenWolf> sweet
[01:49] <RicardoPerez> pitti: hi, martin, i would like to ask you something: i just uploaded an updated .po file into Rosetta. this template generates a .mo file which is in a -base langpack. will this update be applied into the langpacks?
[01:49] <pitti> RicardoPerez: the -base langpacks won't change any more
[01:49] <pitti> RicardoPerez: but if the po file changed since the dapper release, it'll go into the update pack
[01:50] <pitti> RicardoPerez: i. e. language-pack-[gnome-] es
[01:51] <RicardoPerez> pitti: ok, so the .po updates will go into langpacks, right? although the -base langpacks don't changes, but this is not a problem
[01:51] <pitti> RicardoPerez: yes, to keep the update packs small, they contain only actual changes
[01:51] <RicardoPerez> pitti: how can a package replace a file which is into another package?
[01:52] <pitti> RicardoPerez:
[01:52] <pitti> Package: foo
[01:52] <RicardoPerez> pitti: if a .mo file is in -base, and the updated .mo file is in -es... how can it?
[01:52] <pitti> Replaces: bar
[01:53] <RicardoPerez> pitti: oh, ok. and dpkg doesn't complains about that?
[01:53] <pitti> Kinnison: new dapper kernel source is on the archive, but not the binaries; does this need another NEW step?
[01:53] <pitti> RicardoPerez: no, Replaces: is for exactly this purpose
[01:53] <Hobbsee> pitti: that's a package replacing another package isnt it?  not a file in a package being replaced by another package
[01:53] <RicardoPerez> Hobbsee: yes, this is exactly my question
[01:53] <Kinnison> pitti: probably. check with keybuk or someone with archive admin powers
[01:54] <Kinnison> pitti: remember, I'm not actually an ubuntu ftpmaster
[01:54] <pitti> Hobbsee: not exactly; Replaces:/Conflicts: is for replacing a whole package
[01:54] <pitti> Keybuk: can you please invoke your megapowers to new the linux-source-2.6.15 binaries in dapper-security?
[01:54] <Hobbsee> pitti: yes, that's what i thought.  but what do you do if file in package A needs to be updated by file in package B?
[01:55] <pitti> Hobbsee: then B Replaces: A
[01:55] <\sh> Hobbsee: you need Replaces: 
[01:55] <RicardoPerez> and then A is removed?
[01:55] <\sh> Hobbsee: you do think about this strange kopete package?
[01:55] <pitti> Hobbsee, RicardoPerez: http://www.de.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
[01:55] <Hobbsee> mmm okay, i wasnt sure you would do it that way
[01:55] <Hobbsee> *if you could
[01:55] <Hobbsee> \sh: i'm not really thinking much at all really, but yeah
[01:56] <RicardoPerez> if package B replaces A, then A is removed when B is installed?
[01:56] <RicardoPerez> pitti: oh, ok, I see in the URL you post
[01:58] <Seveas> pitti, SuperKeybuk, in blue tights with a big K on his chest :) 
[01:59] <\sh> Seveas: no, SuperKeybuk can't wear the same clothes as SuperSabdfl
[01:59] <Hobbsee> Superkeybuk will have to wear red tights with the big K on his chest then?
[02:00] <RicardoPerez> pitti: thanks a lot :)
[02:00] <Seveas> \sh, SuperSabdfl has orange-beown-ish tights with the ubuntu logo :) 
[02:01] <\sh> Seveas: not when he is on KDE business tour ;)
[02:01] <Seveas> true
[02:01] <Seveas> then he has a blue mask and a dragon tail 
[02:03] <\sh> Seveas: hmmm..a very difficult situation
[02:03] <Seveas> \sh, heh, you're picturing it?
[02:08] <\sh> Seveas: yes ... but I found something better then that....testing linux kernel EDAC functionality ...http://bluesmoke.sourceforge.net/heat_gun.html 
[02:10] <Seveas> \sh, omfg
[02:11] <Keybuk> pitti: ABI change in -updates?! :p
[02:12] <pitti> Keybuk: in -security
[02:12] <pitti> Keybuk: yes, it happens
[02:12] <Keybuk> I can't see what's new?
[02:13] <infinity> The NEWness is on jackass.
[02:13] <Keybuk> I don't have access to jackass
[02:13] <infinity> Exactly.
[02:13] <fabbione> infinity:
[02:13] <Keybuk> there's nothing I can do here then, right?
[02:14] <fabbione> no
[02:14] <fabbione> nevermind
[02:14] <infinity> Oh, wait.  It's NEW on drescher too.
[02:14] <fabbione> yeah
[02:14] <infinity> queue -R dapper info
[02:14] <fabbione> that's what pitti meant
[02:14] <fabbione> 2 NEW queue?
[02:14] <Keybuk> right
[02:14] <infinity> want me to NEW it?  I'm in there anyway.
[02:14] <Keybuk> but there's nothing obviously new there
[02:14] <Keybuk> the overrides are all correct
[02:14] <pitti> Keybuk: no, I mean NEW on drescher
[02:14] <infinity> It's all new, it's a new ABI.
[02:15] <infinity> And the components aren't right.
[02:15] <pitti> Keybuk: it already passed through NEW on jackass (all but ia64, that is
[02:15] <pitti> )
[02:15] <Keybuk> infinity: I'll let you do it :p
[02:15] <Keybuk> you know the kernel components better than I
[02:15] <fabbione> can't we disable the NEW check on jackass?
[02:15] <fabbione> i see very very little point of 2 NEW queue
[02:15] <infinity> fabbione: The archive on jackass is a real, live, in use archive, so it needs the protection.
[02:16] <fabbione> infinity: is use for what?
[02:16] <infinity> fabbione: The security buildds build from jackass, not from drescher.  It's the authoritiative archive for security internally until we move to soyuz.
[02:16] <fabbione> ahh ok
[02:17] <Keybuk> infinity: so, what pressure do you think we can get through the firehose?
[02:18] <pitti> WOOO, firefox with ssp
[02:18] <Keybuk> pitti: so, I'm curious
[02:18] <Keybuk> does gdb work with ssp binaries?
[02:19] <pitti> Keybuk: seems so
[02:19] <pitti> *** stack smashing detected ***: /home/martin/download/ssp-test-0.2/cmd-safe terminated
[02:19] <pitti> 
[02:19] <pitti> #2  0x00002aaaaac2eea6 in __fsetlocking () from /lib/libc.so.6
[02:19] <pitti> #3  0x00002aaaaaca901f in __stack_chk_fail () from /lib/libc.so.6
[02:19] <pitti> #4  0x0000000000400628 in badFunction ()
[02:20] <Keybuk> pitti: even the wacky function and expression injection stuff?
[02:20] <pitti> Keybuk: right now I only activated -fstack-protector, which just inserts canaries
[02:20] <pitti> and reorders stack variables
[02:20] <Keybuk> *nods*
[02:20] <pitti> Keybuk: function injection?
[02:21] <pitti> Keybuk: you mean replacing malloc() calls and such?
[02:21] <Keybuk> yeah, that kind of thing
[02:21] <pitti> that's heap protection, not sure whether it is in gcc
[02:21] <Keybuk> or running random functions in the code
[02:21] <infinity> Keybuk: Any particular reason you're +o?
[02:21] <Keybuk> infinity: oh, was kicking idiots earlier
[02:21] <pitti> -fstack-protection is very limited, but relatively unintrusive
[02:22] <Keybuk> (I don't get to be on top that often)
[02:22] <infinity> TMFI.
[02:22] <infinity> pitti: binaries overridden and NEWed.
[02:22] <pitti> doko: the stack trace above also explains why stuff is not linked to /usr/lib/libssp.so in edgy
[02:22] <pitti> infinity: rock
[02:29] <pitti> Kinnison: so, will anything break if I release only the missing ia64 kernel debs without source?
[02:29] <Kinnison> I don't know. I don't think so
[02:35] <asac> iwj: ping
[02:39] <iwj> asac: Hello.
[02:39] <pitti> hello asac, welcome in #u-d
[02:39] <iwj> Ah, hi Alexander.
[02:41] <asac> iwj: hi
[02:41] <asac> I just sent a mail
[02:41] <asac> for me the assertion disappears with your patch
[02:41] <asac> no crash
[02:41] <asac> looks indeed good
[02:42] <asac> iwj: do you have a trace?
[02:43] <iwj> Yes, it's in nsHTMLSelectElement::DoneAddingChildren, RestoreFormControlState, ..., ContainsOption.
[02:43] <iwj> The crash happens when you leave the test page.
[02:44] <asac> iwj: ok ... I will try again
[02:45] <asac> iwj: how do you leave?
[02:45] <asac> back button?
[02:45] <iwj> Yes.
[02:45] <iwj> Start, visit bug report, left-click on `testcase', back button.
[02:46] <iwj> I was going to eyeball the whole patch to see if I could spot a mistake.
[02:46] <asac> iwj: so you have all other patches applied too?
[02:46] <asac> s/so/do/
[02:47] <Keybuk> http://www.flickr.com/photos/23558147@N00/110129102/
[02:47] <iwj> asac: No.
[02:47] <iwj> Are they supposed to be relevant to this one ?
[02:48] <iwj> They're in my other build.  I was doing them in parallel to try to spend less time waiting for the computer.
[02:48] <pitti> Keybuk: cuddly
[02:48] <asac> hmmm ... maybe do a quick check if this bug is still there if you add just your patch
[02:48] <pitti> Keybuk: from your activity report it seems that the debian/edgy MoM will work soon?
[02:48] <iwj> It could be something else in our build that makes it different.
[02:49] <Keybuk> yes
[02:49] <asac> iwj ... i am patching against vanilla 1.0.8
[02:49] <pitti> \o/
[02:49] <iwj> asac: Ah.
[02:49] <Keybuk> there will be a boat load of syncs for everyone after Paris
[02:49] <Keybuk> and as it assigns to the last person who touched the package now, NO ESCAPING THEM!
[02:49] <Keybuk> HAHAHAHAHA AMAUAHAHAHAHAHA
[02:50] <iwj> asac: I'm starting with the version of 1.0.8 in Breezy.
[02:50] <pitti> Keybuk: oh god, I touched loads of packages for .pot file stuff *arrgh*
[02:50] <pitti> Keybuk: at least this makes it easy to retitle the bug and cc ubuntu-archve for syncs
[02:51] <Keybuk> heh
[02:51] <asac> iwj: ok ... I can reproduce with leaving page :/
[02:51] <Keybuk> talking of syncs
[02:51] <Keybuk> where are they?
[02:51] <Keybuk> ...f...
[02:51] <Keybuk> MORE PONIES ON THE FIRE!
[02:52] <iwj> asac: Ah.  Right.  On the build you had with all the patches ?
[02:52] <asac> asac: yes
[02:52] <asac> iwj: yes
[02:52] <iwj> asac: You're talking to yourself :-).
[02:53] <Keybuk> StevenK: I had to eat the sugar
[02:53] <Keybuk> the ants were after it
[02:53] <iwj> asac: Why don't you leave this one with me and I'll stare hard at this diff for a while.
[02:55] <asac> iwj: ok :) ... feel free to ping me
[02:55] <iwj> Willdo.
[02:55] <iwj> I'm assuming you don't know how this code is supposed to work any better than I do.  If you do then say so now :-).
[02:58] <asac> guess you are right ... though, I have looked at mozilla code so much for the last few security updates, that I finally begin to understand :). Anyway, I have to do some suite backporting too. So go ahead :)
[03:00] <iwj> Have fun.
[03:01] <fabbione> Keybuk: i will make sure you get all my merges if all of a sudden i will become father :)
[03:02] <zul> heh
[03:03] <Keybuk> fabbione: and how are the twins doing? :)
[03:03] <fabbione> Keybuk: fine thanks :)))
[03:09] <doko> Kamion: is there something like a spec/session for reducing the size of CD images, i.e. finding duplicates and other stuff?
[03:11] <Mithrandir> doko: Kamion's on vac.
[03:11] <doko> ahh, remember that now ...
[03:12] <Mithrandir> so unless you want to wait three or four days for your answer.. :-P
[03:13] <Keybuk> there is a spec for that
[03:14] <Keybuk> though there's not much to gain from reducing duplicate files in a squashfs
[03:14] <Keybuk> as they only take up the space of one anyway
[03:14] <ogra> just drop firefox :)
[03:14] <ogra> and its langpacks
[03:14] <Keybuk> and openoffice
[03:15] <_ion> And GNU
[03:15] <Keybuk> _ion: no, we need gcc
[03:15] <ogra> (in fact we'll likely do that for edubuntu)
[03:16] <_ion> keybuk: Well, perhaps we also need GNU core utils. ;-)
[03:16] <Keybuk> _ion: we could use the BSD ones
[03:20] <doko> Keybuk: still makes sense for the alternate CD's?
[03:23] <ogra> doko, using BSD utils o_O
[03:32] <Keybuk> WE'RE INTO L!!
[03:32] <zul> Keybuk: lay off the crack :)
[03:33] <siretart> L?
[03:33] <Keybuk> siretart: a lot of packages in L...
[03:34] <siretart> any chances that edgy will be ready for buisness before paris?
[03:34] <ogra> like the L-kernel :)
[03:34] <Keybuk> no, no
[03:34] <Keybuk> dapper is the one for business
[03:34] <Keybuk> edgy is the one for play
[03:34] <siretart> err, open for play as in uploading latest crack and starting with merging from sid
[03:34] <infinity> siretart: You can do that now.
[03:35] <Keybuk> starting merging from sid?
[03:35] <Keybuk> DIDN'T YOU HEAR, MAN?
[03:35] <Keybuk> we're up to l!!
[03:35] <infinity> *L*
[03:35] <zul> ahhhh....duh...
[03:35] <pitti_laptop> infinity: now, cdbs build log looks just fine now
[03:35] <siretart> Keybuk: I didn't really get what you are meaning with l. you started the mom machinery?
[03:35] <Keybuk> siretart: sync machinery
[03:36] <seb128> infinity: I though Keybuk was rejecting uploads when you do that though :p
[03:36] <siretart> Keybuk: great news! I assume I must have missed some announcement about that..
[03:36] <seb128> infinity: that's what dholbach told me yesterday ;)
[03:36] <Keybuk> seb128: not now
[03:36] <Keybuk> siretart: no, there's no announcement yet
[03:37] <Keybuk> infinity: is the gatekeeper
[03:37] <Keybuk> he's still floating above his sheets though
[03:37] <infinity> seb128: I just installed the final buildd chroots, the world is open for business.
[03:37] <seb128> infinity: ah ok, nice
[03:37] <Keybuk> infinity: you have to un-click the "MANUAL" bit :p
[03:37] <infinity> Well, it'll be open for business after we handhold a security build through, but shhh.
[03:38] <infinity> Keybuk: Yeah, queue-builder isn't running until I'm sure I didn't just break soyuz with the ia64 kernel. :)
[03:38] <Keybuk> bah, Soyuz is a resilient piece of software
[03:38] <Keybuk> it can cope with anything with through at it
[03:38] <seb128> infinity: BTW should I ping you to get GNOME 2.14.n uploads to dapper-updates built or are you in some automatic mode and notice them? :)
[03:39] <seb128> siretart: there is a lib named like that
[03:39] <siretart> seb128: hrhr
[03:39] <Keybuk> -larry -Wall
[03:39] <Keybuk> or is it -Larry -Wall ?
[03:39] <siretart> lol
[03:40] <ogra> the big -L
[03:40] <infinity> seb128: They'll get build later today magically.
[03:40] <seb128> infinity: ok, thank you
[03:46] <mdke> is henrik on hols today?
[03:49] <bddebian> Heya folks
[03:59] <lamont__> Keybuk: ping
[03:59] <pitti_laptop> hi lamont__ 
[03:59] <lamont__> hi pitti_laptop 
[03:59] <lamont__> breaking ones router is fun
[03:59] <ogra> hey lamont__ 
[04:00] <Keybuk> lamont__: 
[04:01] <lamont__> Keybuk: I was grumbling at udev, but it appears that it may just be missing modules in the initramfs, my bad...  but I do have a question...
[04:01] <Keybuk> what is your question?
[04:02] <bddebian> What is the velocity of an unladen swallow? ;-)
[04:03] <bddebian> lamont__: Bah, come on, I do it constantly :-)
[04:03] <lifeless> eurpoean or african ?
[04:03] <ogra> flying forwards or backwards ?
[04:04] <bddebian> Uh, I don't know.. aaaaaaahhhh
[04:04] <_ion> I'm not a pean, you're a pean.
[04:04] <lifeless> http://arago4.tnw.utwente.nl/stonedead/movies/holy-grail/scene-01.html
[04:04] <bddebian> _ion: :-)
[04:05] <lifeless> and then
[04:05] <lifeless> http://arago4.tnw.utwente.nl/stonedead/movies/holy-grail/scene-23.html
[04:05] <Keybuk> lifeless: it worries me that you clearly had those bookmarked
[04:05] <bddebian> Real audio?  Ugh
[04:05] <bddebian> hehe
[04:05] <lifeless> Keybuk: nah, just good google foo
[04:07] <Keybuk> holy christ, that was a musical jar
[04:07] <Keybuk> in alphabetical order, what comes immediately after Marilyn Manson is not of the same genre
[04:08] <siretart> This upload awaits approval by a distro manager
[04:08] <siretart> do I need to ping someone, or will the 'distro manager' notice this himself?
[04:08] <Keybuk> siretart: who approved the upload?
[04:08] <siretart> Keybuk: you (and mdz)
[04:08] <Keybuk> I did?
[04:08] <Keybuk> oh, right
[04:08] <siretart> jupp
[04:08] <Keybuk> wpasuppository
[04:09] <Keybuk> seb128: would you like miscellaneous gnome stuff approved too
[04:10] <seb128> Keybuk: yeah, everything that got uploaded to dapper-updates by example ;)
[04:10] <Keybuk> was libsoup yours?
[04:11] <seb128> yep
[04:12] <siretart> Keybuk: thnx
[04:12] <lamont__> found the cdrom this time... still have to find /dev/sda
[04:12] <seb128> Keybuk: http://people.ubuntu.com/~seb128/desktop-file-utils.debdiff too (I didn't upload that one yet)
[04:18] <bddebian> wpasuppository? Haha
[04:18] <Keybuk> seb128: ok
[04:18] <Keybuk> bddebian: yeah, it's a pain in the arse
[04:18] <seb128> Keybuk: thank you ;)
[04:18] <bddebian> hehe
[04:18] <ogra> lamont__, modprobe sg ? 
[04:20] <Keybuk> ogra: that would be sd_mod not sg
[04:21] <ogra> why not sg ? 
[04:21] <ogra> (usually works for me)
[04:21] <Keybuk> sg is the scsi generic devices
[04:21] <Keybuk> lamont wants a scsi disk device
[04:22] <Keybuk> (that won't help him either ... his problem is the scsi driver itself is missing from the initramfs)
[04:23] <ogra> ah
[04:23] <ogra> ok
[04:23] <bddebian> modprobe wpasuppository sounds too darn funny :-)
[04:24] <jsgotangco> wahahaha
[04:27] <Keybuk> ... r ...
[04:27] <lamont__> Keybuk: actually, it doesn't seem to be... sigh
[04:27] <lamont__> lrwxrwxrwx 1 root root 0 Jun 15 08:25 ./parisc/8/8:0/pci0000:00/0000:00:13.0/driver -> ../../../../../../bus/pci/drivers/sym53c8xx
[04:27] <lamont__> (that's not in the ramfs)
[04:27] <lamont__> rather, not booted there
[04:28] <Keybuk> check /etc/mkinitramfs/initramfs.conf
[04:28] <lamont__> lib/modules/2.6.15-23-hppa32/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko
[04:28] <lamont__> is in the initramfs
[04:28] <Keybuk> oh, that's kinda interesting then
[04:28] <Keybuk> modinfo sym53c8xx
[04:28] <Keybuk> compare with the modalias attribute in /sys/blah/blah
[04:29] <lamont__> in the booted system, or in the b0rked system?
[04:29] <Keybuk> uh, which is the booted and which is the b0rked?
[04:30] <lamont__> choices are a d-i boot to partitioning, then chroot into /target, or boot like it should work, and stop in busybox in the initramfs.
[04:30] <lamont__> == "booted", "b0rked"
[04:30] <lamont__> how long does it wait for the root filesystem before it bails out to the shell, I wonder
[04:31] <Keybuk> 3 minutes
[04:31] <Keybuk> boot with break=mount
[04:31] <Keybuk> then you can look yourself :p
[04:32] <lamont__> it's continuing from the busybox prompt that currently stumps me
[04:32] <Keybuk> lamont: continuing from?
[04:32] <Keybuk> "exit" :p
[04:33] <lamont__> doh
[04:33] <Keybuk> the shell is a spawned copy, so you can fix things, and resume the boot
[04:33] <Keybuk> it's amazing just how neat initramfs-tools is
[04:33] <Keybuk> mostly because of the things we needed to debug the bugger
[04:33] <lamont__> modinfo sym58cxx
[04:33] <lamont__> /bin/sh: modinfo: not found
[04:34] <Keybuk> oh, yeah, you can't do that in initramfs
[04:34] <Keybuk> grep sym58cxx /lib/modules/*/modules.alias
[04:34] <lamont__> grep sym58cxx /lib/modules/*/modules.alias
[04:34] <lamont__> #
[04:34] <Keybuk> hmm
[04:34] <lamont__> that looks kinda like a winner, no?
[04:35] <Keybuk> it does
[04:35] <Keybuk> (I don't even have that module on amd64)
[04:35] <Keybuk> oh
[04:35] <Keybuk> duh
[04:35] <lamont__> grep sym53c8xx /lib/modules/*/modules.alias
[04:35] <lamont__> alias pci:v00001000d0000008Fsv*sd*bc*sc*i* sym53c8xx
[04:35] <lamont__> ...
[04:35] <Keybuk> grep sym53c8xx /lib/modules/*/modules.alias
[04:35] <Keybuk> :p
[04:35] <lamont__> having the right module name helps...
[04:35] <lamont__> alias pci:v00001000d00000013sv*sd*bc*sc*i* sym53c8xx
[04:35] <lamont__> that's the one we care abou8t
[04:36] <Keybuk> ok, find the device, should be: cat /sys/bus/pci/devices/0000:00:13.0/modalias
[04:36] <lamont__> pci:v00001000d0000000Fsv00000000sd00000000bc01sc00i00
[04:36] <Keybuk> alias:          pci:v00001000d0000000Fsv*sd*bc*sc*i*
[04:36] <Keybuk> those would appaer to match
[04:37] <Keybuk> where did you break in the initramfs, btw?
[04:37] <lamont__> after the mount failed
[04:37] <Keybuk> ok
[04:37] <lamont__> want me to wind it back up, or are we good?
[04:37] <Keybuk> grep sym /proc/modules
[04:37] <Keybuk> see if the module actually got loaded
[04:38] <lamont__> nope
[04:38] <Keybuk> right
[04:38] <pitti> infinity: you already NEWed all the l-r-m stuff, right?
[04:38] <Keybuk> /sbin/udevplug -v -s -Bpci -Iclass=0x01*
[04:38] <Keybuk> what output does that print?
[04:38] <lamont__>  /bin/sh: /sbin/udevplug: not found
[04:39] <Keybuk> oh, sweet
[04:39] <lamont__> ls /sbin
[04:39] <lamont__> modprobe  depmod    rmmod
[04:39] <lamont__> # 
[04:39] <Keybuk> well, at least I know what the problem is
[04:39] <Keybuk> ok
[04:39] <lamont__> oh, do share, do share...
[04:39] <Keybuk> modprobe sym53c8xx
[04:39] <Keybuk> modprobe sd_mod
[04:39] <Keybuk> you may need to mknod /dev/sda? as well
[04:39] <Keybuk> then exit -- that should get you into the root filesystem
[04:40] <infinity> pitti: Yes.
[04:40] <Keybuk> did you actually finish the upgrade?
[04:40] <lamont__> b 8 $partition, yes?
[04:40] <lamont__> I _thought_ I did...
[04:40] <Keybuk> lamont: yup
[04:40] <doko> infinity: should we start with db4.4 in edgy from the start?
[04:40] <Keybuk> once booted, check that udev is installed and is the latest version (079-0ubuntuXX)
[04:41] <Keybuk> and update-initramfs -u
[04:41] <lamont__>   * Checking root file system...
[04:41] <lamont__> /dev/sda5 was not cleanly unmounted, check forced.
[04:41] <Keybuk> yeah, this boot won't be "clean"
[04:42] <infinity> doko: I'd like to, but it can wait for a few days. :)
[04:44] <lamont__> firecall
[04:50] <Keybuk> you're going to valgrind firefox ?!?!
[04:50] <bddebian> eeks
[04:51] <iwj> Keybuk: it's not as bad as you would think.  But it is _extremely slow_.
[04:52] <iwj> It's the UMR in ld.so that's really annoying.
[04:54] <mdke> jdub: whiprush_: the fridge has the docteam meeting down one day early, if you can fix that
[04:55] <iwj> Come back, my 1200/75 modem.  All is forgiven.
[04:55] <bddebian> hehe
[04:57] <iwj> not as bad> I've obviously never tried it with SSL before.  Never trust code written by a cryptographer.
[04:58] <iwj> Hmm, that's wholly impractical.  I'll have to copy the page to a non-SSL location.
[05:20] <iwj> Excellent, lovely controlled conditions and of course the bug disappears !
[05:24] <lamont__> Keybuk: for the next question...  how do I force particular interfaces to have particular names now?
[05:26] <lamont__> Keybuk: ubuntu-standard (or equiv) wasn't installed before --> no udev on upgrade.
[05:26] <Keybuk> /etc/iftab
[05:26] <Keybuk> eth0 mac xx:xx:xx:xx:xx:xx arp 1
[05:26] <Keybuk> eth1 mac xx:xx:xx:xx:xx:xx arp 1
[05:26] <Keybuk> etc.
[05:29] <lamont__> ah, that's alive again? cool
[05:30] <Keybuk> yeah, it's handled by udev itself now
[05:33] <Keybuk> Up-to-date:               150 (1.33%)
[05:33] <Keybuk> holy crap
[05:34] <fabbione> Keybuk: sit back and relax :)
[05:34] <bddebian> heh
[05:34] <fabbione> tomorrow's update to edgy will be fun :)
[05:35] <Keybuk> hmmm
[05:35] <Keybuk> I can't get these into the sync directory :p
[05:35] <bddebian> Hmm, still no Xorg 7.1 in Experimental eh..
[05:37] <ogra> bddebian, pfft, fabbione will package it ahead of debain for us 
[05:37] <zul> ogra: hehe
[05:38] <bddebian> ogra: fabbione said he wasn't going near X this go-round?? ;-)
[05:38] <bddebian> hahaha
[05:38] <ogra> LOL
[05:38] <seb128> apparently ogra likes it
[05:38] <lamont__> what is it about X people and sodomizers?
[05:38] <seb128> fabbione: you will need something else to point on him
[05:38] <ogra> bddebian, i know why do you think i'm hiding behind this concrete block
[05:39] <zul> lamont__: its the in thing
[05:39] <bddebian> ogra: :-)
[05:39] <fabbione> lamont__: maintain X for a while and you will understand
[05:40] <lamont__>  * Starting kernel event manager...
[05:40] <lamont__> udevd[1908] : nss_ldap: could not connect to any LDAP server as cn=admin,dc=mmjgroup,dc=com - Can't contact LDAP server
[05:40] <lamont__> hrm... clearly there are ordering issues there...
[05:41] <lamont__> ip6tables v1.3.3: can't initialize ip6tables table `nat': Table does not exist (do you need to insmod?)
[05:41] <lamont__> hehe
[05:42] <fabbione> lamont__: check dmesg?
[05:42] <fabbione> are we hitting the usual 17bit thingy there?
[05:42] <lamont__> 'twas more the whole ipv6 nat thing...
[05:42] <fabbione> i didn't do it..
[05:42] <fabbione> i swear..
[05:42] <Keybuk> lamont: you should at least have the users and groups < 1000 in files, right? :p
[05:42] <lamont__> no, my iptables rules do...
[05:43] <lamont__> apparently
[05:43] <fabbione> hmmm
[05:43] <lamont__> Keybuk: yes
[05:43] <lamont__> actually, they're duplicated in ldap, which makes things occasionally interesting...
[05:43] <lamont__> (that is, the groups that users >=1000 are in leads to some humor)
[05:43] <lamont__> and that led to a script to validate the stupid lists against each other
[05:44] <Keybuk> BOMBS AWAY!
[05:44] <fabbione> FIRE IN THE HOLE!
[05:44] <ogra> COVER !
[05:45] <_ion>  Duck and Cover
[05:45] <ogra> :)
[05:45] <mdke> i love that the check and double checks took between 8 and 20 seconds
[05:45] <HiddenWolf> Keybuk: Happy dapper day?
[05:45] <fabbione> Keybuk: did you remember to switch malone to readonly?
[05:46] <fabbione> Keybuk: before we will get 103283984 duplicates of edgy being uninstallable
[05:46] <Keybuk> fabbione: I couldn't do that even if we had to <g>
[05:46] <Keybuk> mdke: the checking was mostly "makesureIput-MmakesureIput-MmakesureIput-M"
[05:46] <fabbione> Keybuk: you are becoming too soft :)
[05:47] <HiddenWolf> fabbione: "we have already recieved the maximum number of bugs, please try to file one again when the current batch is fixed" ;)
[05:47] <fabbione> HiddenWolf: that sounds list a good excuse
[05:47] <ogra> yeah
[05:47] <bddebian> HiddenWolf: :-)
[05:48] <bddebian> Keybuk: Would there be any point in me trying to help with/look at merges for main?
[05:48] <Keybuk> bddebian: in which sense?
[05:48] <lamont__> Error 101: maximum error count exceeded
[05:48] <Keybuk> Error 666: file has bad magic
[05:49] <lamont__> Driver 'sd' needs updating - please use bus_type methods
[05:49] <lamont__> SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
[05:49] <lamont__> SCSI device sda: drive cache: write back
[05:49] <lamont__> SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
[05:49] <lamont__> SCSI device sda: drive cache: write back
[05:49] <lamont__>  sda: sda1 sda2 sda3 < sda5 sda6 >
[05:49] <lamont__> why does it print that twice???
[05:49] <Keybuk> to scare you
[05:50] <bddebian> Keybuk: Well since I couldn't upload them anyway would there even be any point?
[05:51] <lamont__> Starting Name Service Cache Daemon: nscdnscd: 3873 /var/run/nscd/nscd.pid: No such file or directory
[05:52] <Keybuk> bddebian: you can upload to universe?
[05:52] <Keybuk> oh "for main"
[05:52] <Keybuk> there's always help -- when they get filed, if you prepare the packages and check the diffs, it's useful work :)
[05:54] <bddebian> Keybuk: OK, will do, thanks
[05:57] <dieman> lamont__: heh, im not using it right now, but i could load it up and see
[05:58] <dieman> lamont__: it definately starts right up on amd64
[05:59] <lamont__> dieman: it has an illegal fixup in dapper/hppa, so I still have breezy's loaded on that machine
[06:00] <dieman> nice
[06:00] <dieman> i think i still ahve an hppa machine
[06:00] <dieman> in the basement
[06:00] <dieman> somewhere
[06:00] <dieman> i also recently got a newer one out of someone but disposed of it
[06:00] <lamont__> the current issue of import is that I can't get the aironet card to sync with the hilltop
[06:00] <dieman> suck
[06:01] <dieman> is it dead?
[06:01] <dieman> you getting those exciting rid errors or whatever they are when the MAC layer of that card goes out to lunch?
[06:03] <lamont__> nah - it helps when all the cables are connected... :0(
[06:03] <lamont__> brb
[06:03] <dieman> haha
[06:04] <lamont> much better
[06:04] <dieman> heh
[06:04] <dieman> at least it wasn't a kinked cable
[06:04] <dieman> or something like outdoor pests eating it
[06:04] <dieman> im guessing its some form of lrm?
[06:04] <dieman> lmr?
[06:04] <fabbione> lamont: got time now?
[06:04] <bddebian> Keybuk: You act surprised that they even trust me with Universe??? :-)
[06:04] <lamont> fabbione: sure
[06:13] <KaiL> hmm... vmware-player-kernel-modules-2.6.15-23... I guess, there's no -25 Version of that?
[06:14] <fabbione> KaiL: good point...
[06:14] <KaiL> just found that while installing the player ;)
[06:14] <fabbione> KaiL: yes.. agreed..
[06:15] <fabbione> BenC: ^^
[06:15] <fabbione> BenC: i guess we need to add vmware-player-kernel-modules-2.6.15-23 to the ABI bump list of pkgs that needs love
[06:15] <fabbione> and i am already on edgy here
[06:15] <KaiL> btw. there was some patch for forcedeth to make that working if you directly boot from windows to ubun tu, is that in the -25 image?
[06:16] <fabbione> ogra: dapper-security
[06:16] <KaiL> installing updates could sometimes be a good idea
[06:16] <ogra> hmm, shouldnt that be enabled by default on fresh installs ? 
[06:16] <BenC> I think in breezy it was a question
[06:17] <fabbione> KaiL: bug number?
[06:17] <BenC> so if you updated from breezy, it may not be
[06:17] <KaiL> fabbione, don't know, if there is one...
[06:17] <KaiL> found that in the nvidia support forum
[06:17] <fabbione> KaiL: no bug number, no patch..
[06:17] <BenC> no patch, no answer :)
[06:17] <ogra> hmm, i have 2 updtaed systems and on new installed around me currently ... none has a update-manager notification
[06:17] <BenC> KaiL: forcedeth is pretty close to the newest version, so maybe it does
[06:18] <BenC> KaiL: if -23 didn't have it, then -25 doesn't either
[06:18] <KaiL> http://www.nvnews.net/vbulletin/showthread.php?t=71148&highlight=forcedeth
[06:18] <KaiL> there we have more than enough details..
[06:19] <fabbione> KaiL: if you don't file a bug it might never happen
[06:19] <KaiL> as always, people cry everywhere, but file no bugs..
[06:19] <KaiL> I guess, you also have no bug for some Marvell gbit eth controller? ;)
[06:21] <ogra> if you dont file it ...
[06:22] <bddebian> "If you file it, they will come.."
[06:22] <KaiL> they are not my bugs, only found them in the forum...
[06:23] <fabbione> KaiL: forum is not a bug tracking system
[06:23] <fabbione> if forum users don't report bug they can go to complain to /dev/null if they are not fixed
[06:23] <KaiL> I know, but looks like many problem don't :(
[06:24] <fabbione> after a certain level it becomes (and i am sorry to say) their problem
[06:27] <KaiL> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/49870
[06:27] <Ubugtu> Malone bug 49870 in linux-source-2.6.15 "forcedeth dislikes dualboot systems" [Untriaged,Unconfirmed]  
[06:27] <KaiL> ..now we have a bug ;)
[06:27] <zul> yay!
[06:27] <fabbione> KaiL: now take it to the right forum -> #ubuntu-bugs or #ubuntu-kernel , kthxbye
[06:28] <zul> you  almost always win
[06:32] <AlinuxOS> pitti, hello, have 2 minutes for me ?
[06:36] <iwj> OK, the crash is heap corruption.  Niiice.
[06:51] <mdz> pitti: is the ia64 kernel taken care of?
[06:51] <pitti_laptop> mdz: should all be well now
[06:52] <siretart> Keybuk: syncs are at the same place as for dapper, right?
[06:52] <mdz> ok
[06:53] <Keybuk> "at the same place" ?
[06:53] <siretart> http://people.ubuntu.com/~scott/ongoing-merge/, I persume
[06:53] <Keybuk> those would be "merges"
[06:53] <Keybuk> these are syncs
[06:53] <Keybuk> syncs = updating packages we didn't change
[06:53] <siretart> aah. ok. how can I confuse this?
[06:53] <Keybuk> merges = updating packages we changed
[06:54] <siretart> right.. 
[06:54] <siretart> are syncs announced somewhere? is there perhaps even an rss feed for that?
[06:54] <pitti> AlinuxOS: yes
[06:55] <pitti> so, can we upload to edgy now?
[06:55] <pitti> it seems like the toolchain is settled and buildds working
[06:55] <fabbione> pitti: yes, it's green light
[06:55] <pitti> yay
[06:55] <ogra> YAY
[06:56] <bddebian> Bunch of children waiting for Santa.. ;)
[06:56] <Keybuk> heh
[06:56] <Keybuk> publisher is off atm though :p
[06:57] <fabbione> Keybuk: what have you done? ;)
[06:57] <bddebian> How long before merges start?
[06:57] <Keybuk> bddebian: merges will be timed to start in the week back from Paris
[06:57] <fabbione> bddebian: merges are manual. you can start now
[06:57] <Keybuk> (the auto-generated ones, that is)
[06:57] <bddebian> fabbione: Well I can't since I can't upload to main :-)
[06:57] <fabbione> bddebian: you can still merge and get a sponsor to upload.. also merges apply to universe too
[06:57] <bddebian> Though maybe I'll look at some old ones hanging around there
[06:57] <Keybuk> fabbione: nothing, we didn't know what launchpad would do if packages were being force-sync'd into edgy while the publisher was running
[06:58] <Keybuk> it's safer to just not run it while the sync runs :p
[06:58] <fabbione> oh ok :)
[06:58] <fabbione> Keybuk: wise choise
[06:58] <bddebian> fabbione: Oh I know about Universe, I did a lot of merges for Breezy
[06:58] <bddebian> So Universe will open too or will that come after Paris?
[06:59] <Keybuk> universe is just as open as main
[06:59] <fabbione> bddebian: you can start taking over all the X ones that i got *erroneously* assigned by Keybuk script
[06:59] <Keybuk> fabbione: I don't touch X :p
[06:59] <Keybuk> I'd be forced to nih it, or something
[06:59] <fabbione> Keybuk: you sync it and i don't touch it :)
[06:59] <bddebian> fabbione: X what, merges?
[06:59] <Keybuk> if we want to sync X from Debian, we can do that
[06:59] <Keybuk> but after the big sync, please :)
[06:59] <fabbione> Keybuk: this merge is too small for both of us.. since i am a gentlemen, you can have it :P
[07:00] <bddebian> heh
[07:00] <fabbione> Keybuk: i dunno really.. 
[07:01] <pitti> Keybuk: do you want bugs for sync requests, or will an IRC note work as well?
[07:04] <Keybuk> pitti: bugs with ubuntu-arch subscribed will suffice
[07:05] <pitti> ok
[07:05] <fabbione> Keybuk: wouldn't be easier to reassing the merge requests to something you can parse almost automatically?
[07:05] <fabbione> Keybuk: we get rid of the bug and you take the sync request
[07:05] <fabbione> (at least from the merging stage)
[07:06] <mxpxpod> is there a place I can go to see what is in the buildd's cache?
[07:06] <Keybuk> fabbione: can we not confuse merge and sync requests here
[07:06] <fabbione> Keybuk: ok
[07:06] <Keybuk> which do you mean?
[07:07] <Keybuk> if you mean sync requests (overriding ubuntu changes) just use pitti's script
[07:07] <fabbione> Keybuk: i mean. we get bugs to do merges.. right? let's assume one of this can be a straight sync from Debian.. what do you prefer us to do? make a duplicate asking for a sync?
[07:07] <Keybuk> if there's a group of syncs, put them in the same bug
[07:07] <fabbione> pitti's script where teh what?
[07:07] <bddebian> Change descript, request sync and subscribe archive-team?
[07:07] <pitti> fabbione: http://people.ubuntu.com/~pitti/scripts/requestsync
[07:07] <Keybuk> merge bugs => if it needs syncing, subscribe ubuntu-archive
[07:07] <bddebian> s/descript/description/
[07:07] <fabbione> pitti: ok!
[07:08] <pitti> fabbione: it's as easy as 'requestsync foo edgy' and it'll create a bug for you
[07:08] <Keybuk>  subscribe ubuntu-archive
[07:08] <pitti> fabbione: it uses debsign, so gnome-gpg etc. will work
[07:08] <Keybuk> Please sync this from debian, overriding Ubuntu changes.
[07:08] <Keybuk> etc.
[07:09] <fabbione> oh i see
[07:09] <fabbione> nice
[07:09] <bddebian> I asked this of elmo before but why is it bad if say I am building foo that has a depends on bar and I know I can sync from Debian.  Why not just pull it, and upload rather than bugging the archive admins?
[07:09] <fabbione> pitti: time to add these scripts to ubuntu-utils? ;)
[07:10] <pitti> fabbione: I have tons of scripts like that :)
[07:10] <fabbione> pitti: and why don't you make a deb for them?
[07:10] <pitti> fabbione: in fact I also have a 'syncpackage' script :)
[07:10] <pitti> fabbione: I put them on people, that has to suffice
[07:10] <ogra> fabbione, oh, thats a new fashion ? 
[07:11] <fabbione> ;)
[07:11] <Keybuk> bddebian: because it wouldn't be identical to the debian source package
[07:11] <pitti> fabbione: for every bug I get from you you'll get three back!!!11!!one!!1!
[07:11] <fabbione> pitti: :)
[07:12] <bddebian> Keybuk: OK, thanks
[07:12] <pitti> fabbione: I regret that you won't be in Paris, dude
[07:12] <fabbione> pitti:  i am going to miss all of you guys
[07:12] <fabbione> but i will be there with VoIP.. probably
[07:13] <pitti> bddebian: did I miss a ping from you?
[07:13] <bddebian> pitti: No, the edgy-changes post already :-)
[07:13] <pitti> ah
[07:13] <Keybuk> pitti: we both got LWN'd
[07:13] <pitti> Keybuk: I don't have an account, what does it say?
[07:13] <Keybuk> pitti: just links to your langpacks u-d-a point
[07:14] <pitti> one of my 9243409234320 security updates from last week?
[07:14] <pitti> ah
[07:14] <pitti> nice
[07:14] <bddebian> Gads, there are soo many freakin bugs already
[07:15] <Keybuk> woohoo!
[07:15] <Keybuk> pitti has to merge dhcdbd
[07:15] <Keybuk> he too can learn how to say it!
[07:15] <pitti> dhcdbdbdbd
[07:15] <pitti> Keybuk: I don't mind merging things I can test myself
[07:15] <fabbione> Keybuk: where have you been Lwn'ed?
[07:16] <Keybuk> fabbione: distro page
[07:16] <mxpxpod> I just downloaded the latest kernel and vmware-player hasn't been rebuilt for it... how would I go about requesting that build?
[07:16] <bluefoxicy> You know what would be awesome?
[07:16] <Keybuk> grr. I've been reading this u-d-a announce of Ben's all frakking afternoon
[07:16] <fabbione> mxpxpod: it will be addressed later today or tomorrow
[07:16] <pitti> and since n-m is finally working quite well for me, chdbdh, erm, dhchdnbd, no, bddbecd, this bloody dhcp daemon is fine
[07:16] <siretart> pitti: care to put http://people.ubuntu.com/~pitti/scripts/ into a bzr archive? 
[07:16] <bluefoxicy> If the dapper installer was able to install security updates during install
[07:16] <mxpxpod> fabbione: ok, so I don't need to report a bug
[07:16] <fabbione> mxpxpod: no
[07:16] <mxpxpod> fabbione: thanks
[07:16] <pitti> siretart: oh dear
[07:16] <Keybuk> bluefoxicy: it does
[07:17] <bluefoxicy> like set sources.list to be cd + http:// ... then again I haven't really tried ;)
[07:17] <fabbione> mxpxpod: also because it is in multiverse and not supported anyway
[07:17] <bluefoxicy> Keybuk:  it does that now?
[07:17] <pitti> siretart: yes, at one point I shall collect, clean up and revisit my heap of tool scripts
[07:17] <Keybuk> (at least, the text-mode one does -- it always has)
[07:17] <mxpxpod> fabbione: any way to see if it's in the build queue yet?
[07:17] <Keybuk> not sure whether the Live one does, even if it doesn't, they'll get prompted within a day anyway
[07:17] <bluefoxicy> Keybuk:  it didn't in breezy, I brought it up and someone said if I wanted it I'd have to code it :P
[07:17] <fabbione> mxpxpod: it has not been done yet. the real kernal has precedence
[07:17] <mxpxpod> fabbione: ah, ok
[07:17] <fabbione> mxpxpod: as i said it will be addressed today or tomorrow.
[07:17] <mxpxpod> fabbione: ok, thanks
[07:18] <ogra> bluefoxicy, that must have been a heavy regression against warty and hoary then, it always did that
[07:18] <bluefoxicy> ogra:  I never noticed it.
[07:18] <ogra> it explicitly tells you that it scans the security server even
[07:18] <bluefoxicy> ogra:  I always noticed it installing PURELY from CD, then when you boot you have the security updates repo in sources.list
[07:18] <bluefoxicy> and update-manager goes "HI HEY LOOK CLICK ME"
[07:19] <bddebian> How do the Debian bugs get auto-imported to LP?
[07:19] <fabbione> bddebian: manually. that's why elmo is always so busy
[07:20] <bddebian> Well a lot of them appear to be "fixed" and never get closed
[07:20] <fabbione> bddebian: that's why we are looking for another sysadmin on our hiring page..
[07:21] <bddebian> Oh, hmm
[07:21] <LaserJock> fabbione: we can't automatically track the status?
[07:21] <lifeless> LaserJock: YHBTHANDHTH
[07:22] <bluefoxicy> Keybuk:  trying in qemu
[07:22] <jbailey> lifeless: Congrats.  A string of letters that google doesn't match ;)
[07:22] <jbailey> Pretty hard to do, really./
[07:22] <lifeless> lol
[07:22] <LaserJock> lifeless: hmm, can I get that in english?
[07:22] <LaserJock> ;-)
[07:22] <lifeless> YHBT HAND HTH might match better
[07:22] <bluefoxicy> does that involve some kind of jelly?
[07:23] <_ion> bluefoxicy: Yes.
[07:23] <jjesse> am i allowed to google that at work?
[07:23] <jbailey> lifeless: Much better ;)
[07:23] <Keybuk> lifeless: you forgot "kthxbye"
[07:23] <Keybuk> HTH HAND KTHXBYE
[07:23] <bddebian> Am I going to get yelled at for closing them?
[07:23] <jbailey> lifeless: Brad and I were talking about an hour ago about your collecting of acronyms.
[07:24] <bddebian> heh
[07:24] <jbailey> lifeless: I appliede YAGNI to someone here for something, and was trying to remember some of your other favourites.
[07:24] <jbailey> s/collecting/collection/
[07:25] <lifeless> jbailey: why thanks, I think.
[07:36] <pitti> mdz: would you violently object if we reenable the web interface by default for cups in edgy? we get tons of complaints about this...
[07:37] <fabbione> pitti: isn't against policy to have open ports?
[07:37] <pitti> fabbione: that's not the issue here
[07:38] <pitti> fabbione: it is about putting the cupsys user into the 'shadow' group so that it can verify passwords with PAM
[07:38] <fabbione> oh i see
[07:38] <pitti> shadow allows you to read /etc/shadow, nothing else
[07:38] <fabbione> yeps
[07:38] <jbailey> pitti: I thought the cups web interface required root to do anything significant?  Can it be hacked to do a sudo-type trick?
[07:38] <pitti> so potentially you can get encrypted passwords through cups vulns
[07:38] <pitti> jbailey: LIES
[07:38] <pitti> jbailey: no, it just requires the privilege to read /etc/shadow
[07:38] <fabbione> i think you can still manage the queue
[07:39] <pitti> jbailey: the rest is configuration rewriting with works perfectly as normal user cupsys
[07:39] <pitti> fabbione: yes, you can do normal user stuff, but no printer administration
[07:39] <fabbione> yeah that would do
 fabbione: it is about putting the cupsys user into the 'shadow' group so that it can verify passwords with PAM
[07:39] <bluefoxicy> wtf?
[07:40] <pitti> bluefoxicy: so?
[07:40] <bluefoxicy> pitti:  isn't there another way?
[07:40] <pitti> bluefoxicy: you can set a parallel user database of course
 mdz: would you violently object if we reenable the web interface by default for cups in edgy? we get tons of complaints about this...
[07:40] <pitti> but what would that change?
[07:41] <fabbione> bluefoxicy: yeah sure.. you can cups as root and allow it to do everything.. so there is no need to add it to the shadow group...
[07:41] <bluefoxicy> pitti:  does cups have to verify passwords?
[07:41] <bluefoxicy> pitti:  err. sorry.  Does it have to change its privilege level?
[07:41] <pitti> bluefoxicy: yes, for the web interface, if you want to do administrattive stuff
[07:41] <pitti> bluefoxicy: in ubuntu it already has no unnecessary privileges, no need to change anything
[07:42] <bluefoxicy> ok
[07:42] <pitti> bluefoxicy: and 'changing privilege level' can only happen downwards, and that doesn't work with the web interface
[07:42] <bluefoxicy> pitti:  is there any way to check passwords?
[07:42] <iwj> asac: ping
[07:42] <pitti> of course it could read /etc/shadow into memory and then drop shadow, but that's even more evil
[07:42] <iwj> I think I have found the (a?) problem.
[07:42] <bluefoxicy> pitti:  if [ su USER -c 'true' ] ; then echo Good password; fi
[07:43] <pitti> bluefoxicy: hahahahaha
[07:43] <bluefoxicy> err, () not [] 
[07:43] <bluefoxicy> pitti:  I know :)
[07:44] <pitti> shadow group membership is the least evil way of checking passwords IMHO
[07:44] <pitti> but how it's done is unimportant
[07:44] <Chipzz_> bluefoxicy: actually, no () either
[07:45] <bluefoxicy> pitti:  If you use a suid wrapper that ONLY checks passwords and tells you if your test is good or not (i.e. my idiotic script above), then an attacker can theoretically break cups and proceed to use the wrapper to test passwords..... .... which is a brute force attack, he could throw that straight at ssh or something anyway
[07:45] <bluefoxicy> pitti:  if you give cups shadow access, then someone exploiting cups can read the encrypted passwords, run john against them, and... well, john breaks my password in about 3.2 seconds.
[07:45] <bluefoxicy> (I've been meaning to fix that)
[07:46] <pitti> bluefoxicy: right, that would be slightly better
[07:46] <bluefoxicy> slightly, yes.
[07:46] <bluefoxicy> they'd have to break the wrapper password checker to get shadow access
[07:47] <pitti> bluefoxicy: I was more interested in the general yay or nay from mdz
[07:47] <bluefoxicy> which is a tiny, tiny codebase that can be severely audited
[07:47] <Keybuk> whhhhhhhhhhhhhhhhhhhhhheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
[07:48] <pitti> Keybuk: at z?
[07:48] <bluefoxicy> pitti:  nods.  I'd like the administration interface too, it's a little more full featured than the current crap we have for gnome-cups-thingy, but a typical user won't be able to find it.
[07:48] <bluefoxicy> pitti:  (unless you add it to the firefox bookmarks toolbar or something)
[07:48] <pitti> bluefoxicy: enough people and especially admins do know where to look
[07:48] <Keybuk> pitti: publishing
[07:49] <pitti> is anyone familiar with svn merge?
[07:49] <iwj> We should have a userv service to do this kind of password checking.  It's not performance critical and the service could rate-limit it trivially.
[07:49] <Keybuk> sources are in
[07:49] <jjesse> a little, you use it to merge a trunk into branch for exampel
[07:49] <Keybuk> pitti: it's just CVS merge, no?  -rX..Y branch
[07:49] <pitti> jjesse: so, we have a Debian and an ubuntu branch in cups svn on alioth
[07:49] <pitti> u$ svn merge ../cups-1.2@HEAD ../cups-1.2-ubuntu@HEAD .
[07:49] <pitti> is what I tried
[07:49] <pitti> in the ubuntu work dir
[07:50] <pitti> that merged some stuff, but skipped new files
[07:50] <jjesse> hmm try to remember when we merged ubuntu-docs from trunk to branch
[07:50] <pitti> Skipped missing target: 'debian/patches/00_r5643.dpatch'
[07:50] <pitti> Skipped missing target: 'debian/patches/56_dirsvc.dpatch'
[07:50] <pitti> A    debian/patches/svn5527_str1689_printeroptions.dpatch
[07:50] <pitti> and so on
[07:50] <pitti> Skipped missing target: 'debian/po/it.po'
[07:50] <pitti> ^ that file was added in Debian recently
[07:50] <pitti> and it's not in my ubuntu branch now
[07:50] <jjesse> i'm thinking as i don't remember how we merged in ubuntu-doc
[07:50] <crimsun_> pitti: pong (thanks for the correct thunderbird-quickfile fix!)
[07:50] <jjesse> hold on checking
[07:50] <pitti> hm, in fact nothing is changed at all
[07:51] <fabbione> pitti: i used to do svn merge -r$rev1:rev2 from to
[07:51] <pitti> crimsun_: oh, unping, I wanted to ask you if you are fine with doing a more general fix
[07:51] <pitti> fabbione: so svn can't figure out the common base version on its own?
[07:51] <fabbione> pitti: or something very similar to that
[07:51] <fabbione> pitti: not that i know off
[07:52] <jjesse> pitti: i ca't remember but i know mdke did the merge
[07:54] <Keybuk> pitti: absolutely not!
[07:54] <Keybuk> pitti: svn has no history of merges
[07:54] <Keybuk> svn merge is basically svn diff | patch
[07:54] <pitti> Keybuk: and it has a very weird idea of branches, too
[07:55] <pitti> fabbione: that worked, thanks mate
[07:55] <Keybuk> ok, accepted is processed
[07:55] <fabbione> pitti: no problem
[07:56] <Keybuk> now publishing the distro
[08:02] <bddebian> w00t, go Keybuk
[08:03] <Keybuk> judgejudy = Dominator(logging.getLogger("Dominator"))
[08:03] <jbailey> Keybuk: I can't see judgejudy as a logger.
[08:03] <zul> shes hilarious
[08:04] <jbailey> Or does that make her the dominator over the logger?
[08:04] <bddebian> heh
[08:04] <Keybuk> Domination commencing
[08:05] <highvoltage> there's really a judgejudy user?
[08:05] <Keybuk> s/user/variable/
[08:05] <Keybuk> well, object
[08:08] <Keybuk> Generating overrides...
[08:11] <Keybuk> and now the file lists...
[08:14] <mdz> pitti: we disabled it because it required granting cups (which sometimes listens on the network) privileges to read /etc/shadow, no?
[08:14] <pitti> grrrrrrr @ svn
[08:14] <pitti> mdz: right
[08:14] <pitti> svn: Commit item '/home/martin/debian/cupsys/branches/cups-1.2-ubuntu/debian/patches/55_ppd_okidata_name.dpatch' has copy flag but no copyfrom URL
[08:14] <pitti> THANKS, subversion!
[08:14] <mdz> pitti: perhaps we could work around that
[08:14] <Keybuk> pitti: how, err, Arch-like of it
[08:14] <Keybuk> ...apt-ftparchive now
[08:15] <mdz> pitti: client cert authentication?  a unix_chkpw sort of helper?
[08:15] <pitti> Keybuk: now I finally managed to merge everything and resolve conflicts ...
[08:15] <pitti> mdz: certificates work on the command line, but not through http
[08:15] <pitti> mdz: yes, bluefoxicy and I already discussed a suid password helper
[08:16] <mdz> pitti: is there a fundamental reason why certificates can't work through http?
[08:16] <mdz> it seems like we should be able to arrange for firefox to see the cert somehow
[08:16] <pitti> mdz: you have to teach the browser to read /var/run/cups/certs/ and submit it through http
[08:17] <pitti> mdz: oh, cups has its own idea and implementation of certificates
[08:17] <pitti> totally different from SSL ones
[08:17] <mdz> oh, I thought they were standard certs for some reason
[08:17] <pitti> it's basically just a file with a long random number, and if you have the file system privilege to read it, you have proved that you are in lpadmin
[08:18] <pitti> mdz: it offers other auth systems, too, but PAM is just easy because it avoids a second password database
[08:18] <pitti> mdz: if people should set up that, then they will likely use their normal login password anyway
[08:18] <pitti> so it doesn't help much
[08:18] <mdz> right
[08:18] <mdz> and it doesn't really help to restrict which users' passwords it will allow cups to check
[08:19] <mdz> because in almost every case it will be a user in both lpadmin and admin
[08:19] <mdz> i.e. root equivalent
[08:19] <pitti> at least an attacker has a good chance for that, right
[08:19] <mdz> this is why web authentication sucks
[08:19] <pitti> mdz: so, implementing something like, or even using unix_chkpwd doesn't seem bad for me
[08:19] <mdz> web authentication for system administration anyway
[08:20] <pitti> mdz: yes, it's just that the series of complaint emails and bug reports about it never stops
[08:20] <mdz> pitti: I don't think we can use unix_chkpwd; won't it only check the current user's password?
[08:20] <pitti> mdz: and indeed I must agree that gnome-cups-mgr is not the end of wisdom
[08:20] <pitti> mdz: yes
[08:20] <pitti> mdz: I mean a suid helper which just answers 'yes' or 'no', but this needs to be implemented carefully
[08:21] <mdz> we could disable authentication and allow anyone on localhost to administer cups :-D
[08:21] <bddebian> Best idea yet :)
[08:21] <mdz> security through insecurity
[08:21] <pitti> :)
[08:21] <pitti> security by redefinition
[08:21] <bluefoxicy> actually mdz
[08:21] <bluefoxicy> that can be done
[08:22] <mdz> pitti: perhaps we could create a way to launch the web interface from the menu which would authenticate with a cert or similar
[08:22] <bluefoxicy> iptables can drop packets based on the user or group the process they originate from is in
[08:22] <mdz> pitti: launching the browser with a special URL or something
[08:22] <mdz> pitti: then we could configure the web interface to tell the user to go there instead
[08:22] <pitti> mdz: hm, that wouldn't quite work for remote administration, though
[08:23] <ivoks> we should fix cups :/
[08:23] <mdz> bluefoxicy: I don't think it can distinguish between cups administration requests and ipp printig requests however
[08:23] <pitti> mdz: sure, submitting the certificate value through http post should work
[08:23] <ivoks> it's apache ripoff anyway :)
[08:23] <pitti> I'm not sure whether it's a good idea, though
[08:23] <bluefoxicy> mdz:  ah
[08:23] <mdz> pitti: but people who want remote administration must manually configure anyway, right?
[08:23] <pitti> ivoks: btw, I'm just merging to Debian, 1.2.1 will be in edgy soon
[08:23] <mdz> it doesn't listen remotely by default
[08:23] <pitti> mdz: right, they have to open the port
[08:24] <ivoks> pitti: nice, but we should do something about it in dapper too 
[08:24] <pitti> ivoks: yeah
[08:24] <mdz> pitti: I saw a message from michael sweet about this
[08:24] <mdz> pitti: debbugs #369015
[08:24] <ivoks> pitti: i packaged gutenprint rc3 for dapper, i'm waiting lexmark users to test it
[08:24] <pitti> debian bug 369015
[08:24] <mdz> Ubugtu: smarten up
[08:25] <pitti> mdz: ah, that one; yes, I answered
[08:25] <mdz> pitti: what does he have to say about our security concerns?
[08:25] <pitti> oh, door bell, brb
[08:26] <mdz> I suppose that it isn't much of a concern since the default config is to run as root
[08:26] <pitti> mdz: I'm still angry about him for removing RunAsUser
[08:26] <pitti> mdz: and he doesn't seem to care
[08:27] <pitti> I have to help my gf carry some stuff upstairs, brb
[08:28] <bluefoxicy> pitti:  this is why the security team needs to be a core and authorative part of distro management 8)
[08:28] <bluefoxicy> when people go "Uh whatever I don't care if it's root now it works" you need to be able to SMITE THEM
[08:29] <Keybuk> death row time
[08:29] <bluefoxicy> nah
[08:29] <bluefoxicy> I'm just more used to seeing the security teams on distros fight with the main distro maintainers
[08:29] <Keybuk> no, I mean the publisher's doing the death row
[08:30] <bluefoxicy> the mentality that "well we have a bug XXXX, we should fix it so it works; it opens a HUGE hole but nobody is going to exploit that right away so we can worry about that secondarily" seems semi-common to me
[08:30] <pitti> re
[08:30] <bluefoxicy> i.e. running random things as root
[08:32] <bluefoxicy> mdz:  is Xorg 7.1 going into dapper-backports in the future or is it reserved for edgy?
[08:33] <bluefoxicy> (I have a legitimately broken driver that Xorg 7.1 relnotes claim is FULLY SUPPORTED now)
[08:33] <mdz> that depends on the changes, but in general I wouldn't expect it to be a good backport candidate
[08:33] <mdz> it's infrastructure, and backporting such things complicates upgrades
[08:34] <bluefoxicy> mdz:  nods.  I'll probably steal it from edgy then.
[08:35] <Keybuk> and we're done
[08:36] <Keybuk> a few minutes for a.u.c to catch up
[08:39] <mdz> Keybuk: what's in this publisher run? first batch of syncs?
[08:39] <Keybuk> mdz: yup
[08:39] <mdz> Keybuk: how big is it?
[08:40] <Keybuk> about 3,500 sources
[08:40] <Keybuk> edgy will basically have to be entirely rebuilt once the merges are in too
[08:40] <Keybuk> there are about 150 "unchanged" packages
[08:41] <Keybuk> that should keep the buildds warm over the weekend
[08:42] <AlinuxOS> doko, ping
[08:43] <doko> AlinuxOS: pong
[08:45] <fabbione> mdz: U60/T1K/2xT2K/NetraT1 netboot/netinstall all GO. not a glitch.. all in different configs/setups/foos/bars
[08:45] <fabbione> i guess we only need the cdimages now
[08:45] <fabbione> (and d-i in)
[08:45] <fabbione> anyway i am going to take a nap
[08:45] <fabbione> and be back around 0 UTC in 6 hours
[08:46] <fabbione> make that 5
[08:47] <mdz> fabbione: hi-5
[08:48] <mdz> fabbione: get some rest and we will roll CD images once the soyuz fix lands
[08:49] <fabbione> mdz: the soyuz fix is already there. We need infinity to manual build d-i (hence we can't upload and test the fix without him)
[08:50] <fabbione> anyway..
[08:50] <AlinuxOS> fabbione, buona notte.
[08:50] <fabbione> mdz: "everything will be fine"
[08:50] <fabbione> AlinuxOS: notte
[08:50] <bddebian> Heh
[08:50] <bddebian> Gnight fabbione
[08:53] <bluefoxicy> keyboard layout?  wtf?
[08:53] <bluefoxicy> Keybuk:  if edgy is open does that mean #ubuntu+1 is back?
[08:54] <bluefoxicy> also why does the installer ask me keyboard layout?
[08:54] <bluefoxicy> And language!
[08:54] <bluefoxicy> The boot screen lets me adjust language and keymap, can't those be used to intuit language and keymap in the installer?
[08:54] <bluefoxicy> (I know this is a ridiculous prospect)
[08:58] <Keybuk> "#ubuntu+1" ?
[08:58] <ogra> edgy+1 ;)
[08:58] <Keybuk> it never left?
[08:59] <bluefoxicy> seveas cleared and closed it on June 1
[08:59] <Keybuk> eh?
[09:00] <zul> so i should be able to do a dist-upgrade?
[09:00] <Keybuk> if you were really silly
[09:00] <Keybuk> it's mostly just new source at this point
[09:00] <zul> but i am..:)
[09:01] <Keybuk> with some binaries that will stop your machine from booting
[09:01] <zul> ok maybe im not that silly
[09:01] <pitti> zul: I have up to date edgy, and the only breakage I noticed are locales
[09:01] <pitti> they don't work at all
[09:01] <pitti> rest is fine
[09:01] <Keybuk> pitti: did you reboot yet? :p
[09:02] <pitti> Keybuk: yes, several times (I always shutdown when I'm not on the box)
[09:02] <asac> iwj: pong
[09:02] <Keybuk> pitti: since the buildds were back on auto?
[09:02] <iwj> asac: Hi.  See email.
[09:03] <pitti> Keybuk: dunno, my last dist-upgrade was around 1400 UTC
[09:03] <Keybuk> do another <g>
[09:04] <pitti> Keybuk: what's breaking?
[09:04] <bddebian> pitti: You are running Edgy or do you mean a chroot?
[09:04] <pitti> bddebian: I run edgy
[09:04] <bddebian> Wow
[09:04] <pitti> I have stable chroots and crack of the day main system
[09:05] <bddebian> heh
[09:05] <pitti> I wanted to play with gcc 4.1 and ssp, and new glibc :)
[09:05] <Keybuk> pitti: new udev will cause excitement
[09:05] <Keybuk> at least, until the new kernel is in
[09:05] <Keybuk> which will also cause excitement
[09:05] <pitti> Keybuk: oh, I still have the dapper one
[09:05] <jbailey> bddebian: I suspect that those of us who play with core infrastrucutre are probably all running edgy already.
[09:05] <Keybuk> I like you like to live dangerously
[09:06] <bddebian> Seriously, what are "we" doing for X?  Is the intention to grab 7.1 from Debian when it comes in?
[09:06] <Keybuk> I have a stable machine on the end of an ssh seession with various chroots
[09:06] <Keybuk> my laptop I run on the bleeding edgy
[09:06] <bddebian> jbailey: Well you rock anywayz so.. :-)
[09:06] <jbailey> My wife's machine runs the current release until somewhat after feature freeze, usually.
[09:06] <jbailey> The rest of my machines all run current-development plus my testing glibc.
[09:07] <Keybuk> anyhoo, I'm gonna go crash
[09:08] <Keybuk> nite all
[09:08] <ogra> ciao Keybuk 
[09:08] <ogra> :)
 I wanted to play with gcc 4.1 and ssp, and new glibc :)
[09:08] <asac> iwj: what type is state ?
[09:09] <bluefoxicy> pitti:  did tseng tell you I'm prone to test any silly thing you throw at me, like i.e. fully built SSP bases with position independent executables and experimental hardened kernels and Xorg 7 security policies that force half of the desktop to cease function etc?  :>
[09:09] <iwj> nsSelectState*, ie not an nsRefPtr.
[09:09] <pitti> bluefoxicy: :)
[09:10] <pitti> bluefoxicy: crack away
[09:10] <iwj> asac: It's new'd, fiddled a bit, then shoved into a hash table with SetStatePropertyAsSupports, but none of these things add a ref.
[09:10] <bluefoxicy> pitti:  the gentoo guys did a pretty good job of getting me to run severely broken ebuilds on my production desktop :)
[09:10] <iwj> And then at the end of the function it's unconditionally RELEASE'd.
[09:10] <asac> iwj thats wrong
[09:10] <asac> apparently you missed it
[09:10] <asac> I found another
[09:11] <iwj> Another similar bug ?
[09:11] <asac> iwj:  its now: nsRefPtr<nsSelectState> state = new nsSelectState(); 
[09:11] <asac> iwj: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/content/html/content/src&command=DIFF_FRAMESET&file=nsHTMLSelectElement.cpp&rev1=1.232.2.2.2.1&rev2=1.232.2.2.2.2&root=/cvsroot
[09:11] <iwj> nsRefPtr> I considered doing that.
[09:11] <asac> iwj: thats what got checked in on MOZILLA_1_8_0 branch
[09:12] <asac> iwj: further you removed or kept?? NS_RELEASE(mRestoreState);
[09:12] <asac> iwj: this should be mRestoreState = nsnull;
[09:12] <iwj> I have no NS_RELEASE on mRestoreState.
[09:12] <asac> yes
[09:12] <asac> you removed it
[09:12] <asac> but did not add the
[09:12] <asac> mRestoreState = nsnull;
[09:13] <asac> iirc
[09:13] <iwj> That's in the destructor, right ?
[09:13] <asac> wait a second
[09:13] <asac> I will look
[09:13] <iwj> in nsHTMLSelectElement::~nsHTMLSelectElement
[09:13] <iwj> Oh, no, you mean in nsHTMLSelectElement::DoneAddingChildren
[09:14] <asac> yes you just removed it
[09:14] <asac> do you see?
[09:14] <asac> hunk 1773
[09:14] <iwj> Yes.
[09:14] <iwj> RestoreStateTo doesn't always add a reference.  Oh, just a mo, it does.
[09:15] <iwj> Sorry, I misread that.
[09:15] <bddebian> BenC: ping?
[09:16] <iwj> asac: How did you find that cvsweb diff, OOI ?  I mean, the version numbers.  Did you trawl the logs looking for mentions of 324918 ?
[09:16] <asac> iwj: and remove mRestoreState=nsnull in constructor ... its not needed anymore
[09:16] <asac> no its easy
[09:17] <iwj> asac: The patch I was working from was the one from the attachment in the 324918 report, which I had naively assumed was largely correct.
[09:17] <asac> i searched bonsai for all changes of nsHTMLSelectElement.cpp on MOZILLA_1_8_0_BRANCH
[09:17] <asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=&file=nsHTMLSelectElement.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
[09:17] <asac> iwj: I verify ... wait a second
[09:18] <iwj> The two attachments are the 2006-02-16 and 2006-03-01 ones.
[09:18] <asac> iwj: yes you are right
[09:18] <asac> iwj: apparently they really messed it up
[09:18] <iwj> Hrmf.
[09:18] <asac> iwj: other patches where quite right though ... so its just an accident I guess
[09:19] <asac> iwj: take the first patch for nsHTMLSelectElement.cpp too??
[09:19] <iwj> I'm not sure now whether to throw away the stuff from those attachments and start again with your actual cvs checkin.
[09:19] <asac> yes
[09:19] <asac> take both from bonsai
[09:19] <iwj> 2006-04-21 16:14, you mean ?
[09:19] <asac> there are two checkins
[09:19] <asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=&file=nsHTMLSelectElement.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
[09:19] <asac> they where even on the same day
[09:20] <asac> first sounds interesting
[09:20] <asac> Make elements deal better with various evil DOM mutations. Fixes bugs 325730, 330084, and 330925. Patches by me and bz. r/sr=me,bz,jst a=jst
[09:20] <asac> :)
[09:20] <iwj> asac: That other patch seems sensible, yes.
[09:20] <asac> and the second is our real checkin
[09:20] <neutrinomass> Is it a bad idea to write .desktops that put stuff under System->Administration instead of Applications->System ? Because I've heard that Ubuntu is moving away from the latter ...
[09:20] <iwj> Right.  I think we want both.
[09:20] <asac> iwj: but none of the bugs in the checkin are listed in any mfsa
[09:21] <asac> neither are dependents and blocked bugs
[09:21] <iwj> Yes, but we already know that they're not 100% at putting security stuff in mfsa's.
[09:21] <asac> please keep them separated
[09:21] <asac> maybe the first is part of adifferent, larger checkin we do no yet have
[09:21] <asac> maybe they forgot to issue an advisory or something
[09:21] <iwj> That's possible but it looks good in isolation to me.
[09:22] <asac> look here two then
[09:22] <asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=mozilla%2Fcontent%2Fhtml%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
[09:24] <iwj> That just shows no other bits of that checkin in that directory.
[09:25] <asac> hmmm
[09:25] <asac> there are three bugs in the comment
[09:25] <iwj> asac: 325730 is definitely security sensitive.
[09:26] <iwj> I think 330084 probably is but none of the commenters actually say so.
[09:26] <bluefoxicy> which bugzilla
[09:26] <iwj> Mozilla.
[09:26] <asac> iwj: I will clarify if they missed an advisory
[09:27] <iwj> Right, thanks.
[09:27] <iwj> I'm going to go off and have dinner now.  Good luck with things and maybe talk to you tomorrow.
[09:28] <iwj> Thanks a million for your effort.
[09:28] <asac> iwj: cu
[09:29] <bluefoxicy> iwj:  sometimes things don't get marked security sensitive by the reporter
[09:29] <bluefoxicy> I did that with mozilla's /tmp thing, I showed how to find out what another user was looking at by watching files owned by them appear in /tmp and googling the file name
[09:29] <asac> iwj: if you have the new patch, please send them. I would like to file it as done here in my TODO list :)
[09:29] <bluefoxicy> (they did tell me to mark it security sensitive, I just didn't)
[09:29] <bluefoxicy> (I never do{
[09:30] <asac> bluefoxicy: in this case the bug was security sensitive
[09:30] <bluefoxicy> asac:  yeah, I'm just saying, sometimes the reporter doesn't mark it that way.
[09:31] <asac> bluefoxicy: sure.
[09:31] <bluefoxicy> asac:  I never do because if I ever find anything it's either A) minor; or B) something I'm blogging about 2 minutes after the bug is posted.
[09:33] <bluefoxicy> asac:  it'd be neat to be able to see all the secret security issues in bugzillas ;)
[09:33] <bluefoxicy> asac:  For me that's recreational reading
[09:34] <BenC> bddebian: pong
[09:34] <bddebian> BenC: It looks like Bug #39315 is closeable.  Could you confirm?
[09:34] <Ubugtu> Malone bug 39315 in linux-source-2.6.15 "Keyboard random repeat " [High,Fix released]  http://launchpad.net/bugs/39315
[09:35] <BenC> bddebian: Yes, it is
[09:35] <JanC> hm, anybody know when vmware-player kernel modules will be updated to work with the new kernel ?
[09:35] <BenC> that's why it is closed :)
[09:35] <bluefoxicy> BenC:  oracle is doing things with ubuntu's patches
[09:35] <bddebian> BenC: No, it's Fix Commited, not released
[09:35] <ogra> JanC, likely tomorrow
[09:35] <BenC> bluefoxicy: Yeah, Randy emailed me that he was doing that
[09:35] <BenC> bddebian:  [High,Fix released] 
[09:36] <bddebian> BenC: For .17?
[09:36] <JanC> ogra: thanks, will answer that to the user who asked me that  :)
[09:36] <BenC> bddebian: It's not released for .17 yet
[09:36] <BenC> I need to upload .17-2
[09:36] <bddebian> OK, thanks, sorry to bug ya
[09:36] <BenC> np
[10:05] <bddebian> mdz: You around?
[10:07] <mdz> bddebian: yes
[10:07] <bddebian> mdz: Do you have any thoughts on bugs against Universe packages on older distros?
[10:08] <mdz> bddebian: packages which have since been removed, you mean?
[10:08] <bddebian> mdz: No.  Say bug was filed on foo in Warty or Breezy but was fixed in Dapper.  Close them?
[10:08] <mdz> bddebian: example?
[10:08] <bddebian> barring security and crash fixes of course
[10:08] <bddebian> Bug #1767
[10:09] <Ubugtu> Malone bug 1767 in gimp-print "Upgrades from gimp-print to to gutenprint" [Medium,Unconfirmed]  http://launchpad.net/bugs/1767
[10:09] <bddebian> Oh bad one, that's main, hang on
[10:09] <bddebian> Bug #1669
[10:09] <Ubugtu> Malone bug 1669 in gxmms "gxmms doesn't display the title of the song in the tooltip" [Medium,Unconfirmed]  http://launchpad.net/bugs/1669
[10:11] <RQ> Hi, could anyone help me with compiling alsa a bit?
[10:12] <RQ> i'm getting a bunch of errors while trying to make a deb with 1.0.11
[10:12] <bddebian> Damn upgrading to Edgy is puking on locales and locale-gen isn't fixing it?? :-(
[10:13] <RQ> there it is: http://pastebin.com/711459
[10:14] <BenC> so has hppa been dropped, or is it just not boot-strapped for edgy yet?
[10:17] <jbailey> BenC: hppa is broken for glibc in some fundamental ways.
[10:17] <jbailey> (no NPTL)
[10:18] <jbailey> Carlos has some stuff working, he needs to get another LWS integrated into their kernel.
[10:19] <jbailey> After that, remember all of the *really* ugly hacks that would never be integrated into LinuxThreads upstream?  All gone.  They'll get in perfectly.
[10:40] <bddebian> Anyone have a clue what I do about this locale issue when upgrading to Edgy?  http://pastebin.us/489   locale-gen isn't doing it :-(
[10:44] <bluefoxicy> Ran into a bump on dapper install.
[10:44] <bluefoxicy> FAT32 partition has a /!\ next to it, umounting it says "no such file or directory"
[10:44] <bluefoxicy> more importantly
[10:45] <bluefoxicy> I can't say, "Shrink existing partition"  "C: (guessed)"  "Allocate 3GiB for Ubuntu and autopartition"
[10:52] <bluefoxicy> I think
[10:53] <bluefoxicy> if anyone tries to install dapper on a machine with pre-existing Windows
[10:53] <bluefoxicy> they're going to have to jump through hoops.
[10:53] <bddebian> If they are installing Windows, what the hell would they need Windows for anymore? ;-)
[10:53] <bddebian> s/Windows/Dapper/
[10:54] <mdke> bluefoxicy: check the bug tracker
[11:04] <bddebian> Later folks
[11:10] <bluefoxicy> mdke:  this install app is written in python isn't it -.-
[11:10] <mdke> bluefoxicy: no idea, probably
[11:10] <mdke> bluefoxicy: the bug tracker
[11:11] <bluefoxicy> nothing I can see
[11:45] <bluefoxicy> wtcrap
[11:45] <bluefoxicy> hda1 isn't mounted
[11:46] <tseng> bluefoxicy: you really don't need to spam your random thoughts to this channel
[11:47] <bluefoxicy> tseng:  sorry, trying to figure out htf to tell dapper's installer to resize a vfat partition to make room for ubuntu.  Right now it seems to be "I can't do that," although on Breezy I had the d-i resize WinXP safely.
[11:48] <bluefoxicy> tseng:  i thought that was supposed to be something it did.. I'll just bug on it when done.
[11:48] <tseng> ok comeon
[11:49] <mdke> bluefoxicy: immagine if everyone talked about their bugs in the channel. There are a lot of bugs
[11:49] <bluefoxicy> mdke:  ok true :)
[11:49] <mdke> and anyway, the installer maintainer is away
[11:49] <tseng> mdke: its worse when you blurt out random ideas with no context
[11:49] <KaiL_> would it be possible to write a (userspace?) tool, which sends everything accessing /dev/dsp to esddsp or aoss..?
[11:49] <tseng> not that I would prefer him to spell it out, either
[11:49] <mdke> tseng: :)
[11:50] <bluefoxicy> tseng has heard me talk far too much in his lifetime
[11:50] <tseng> i think it is maybe 4 years now?
[11:50] <tseng> or 5
[11:50] <KaiL_> ..just to have dmix support also for oss apps
[11:58] <givre> Hi guys, don't know if it the good canal t ask this, but we need a new vmware-player-kernel-module to match the new kernel.
[11:58] <givre> Is it plan?
[12:00] <zul> givre: its in the works
[12:01] <givre> ok, thanks