[12:03] <Lure> KaiL: you mean kde-guidance?
[12:03] <KaiL> ah, yes
[12:03] <Riddell> KaiL: displayconfig in kde-guidance
[12:04] <Riddell> Pygi: not yet, it needs to pass NEW and compile first :)
[12:04] <KaiL> somebody should port that to GNOME ;)
[12:04] <Pygi> Riddell: ah ;P
[12:05] <Pygi> infinity: so you volunteer for doing some uploads for me if needed? ;)
[12:06] <infinity> Pygi: Forward me patches.. adconrad@ubuntu.com
[12:07] <Pygi> infinity: as soon as they are done :)
[12:07] <Pygi> and thanks ^_^
[12:09] <infinity> Kamion: Any idea where Mithrandir left off with Flight-6 testing?
[12:11] <Pygi> I'll be back in a sec
[12:14] <Pygi> back
[12:14] <KaiL> the kernel only supports 16bit FB?
[12:14] <Pygi> KaiL: you in a mood for another round of bugs against n-m? ;)
[12:15] <KaiL> Riddell, you want network-manager-kde?
[12:15] <KaiL> the "it's missing" bug?
[12:15] <infinity> KaiL: 4-bit, you mean (via vga16fb, which is 16 colours, not 16-bit)?
[12:15] <Pygi> Riddell: he uploaded it ;)
[12:15] <Pygi> KaiL: hm, number of that bug? lemme close it...
[12:15] <KaiL> Pygi, 37190
[12:15] <KaiL> bug 27190
[12:15] <Ubugtu> Malone bug 27190 in linux-source-2.6.15 "general protection fault" [Normal,Needs info]  http://launchpad.net/bugs/27190
[12:16] <KaiL> aaaaghr
[12:16] <KaiL> bug 37190
[12:16] <Ubugtu> Malone bug 37190 in network-manager "network-manager-kde missing" [Wishlist,Confirmed]  http://launchpad.net/bugs/37190
[12:16] <KaiL> infinity, as color depth for the splash
[12:16] <Pygi> will do now...next todo: let's go, and confirm/reject/whatever to nm bugs
[12:16] <infinity> KaiL: Yes, that's 4-bit.
[12:16] <KaiL> vga=773 (1024, 256 colors) seams to fail
[12:16] <infinity> KaiL: And intentional, since vga16fb is the only framebuffer guaranteed to be sane.
[12:16] <KaiL> 791 (1024, 16bit) works
[12:17] <sistpoty> infinity: happen to know why sbcl didn't get scheduled for building on ppc yet? https://launchpad.net/distros/ubuntu/dapper/+source/sbcl/1:0.9.8.0-1ubuntu3
[12:17] <infinity> KaiL: Oh, if you're using vesafb, I'm not sure.. I use vesafb at 16 and 32 bit, and have never had issues.  I may have to look into using it at 8-bit (like you're trying to do).
[12:18] <KaiL> well, that's what the installer writes into the settings, if I select 1024 and 16bit at startup, afair ;)
[12:21] <infinity> sistpoty: It keeps getting given-back, due to my overly-clever regexes finding an "Illegal Instruction" in the log.
[12:21] <infinity> sistpoty: I may need to tweak that.
[12:21] <KaiL> hmm, 0x341 is what? 1024, 32bit?
[12:21] <sistpoty> infinity: ah, k :)... not sure if this will even compile on ppc, but I thought it might be worth a try
[12:22] <infinity> KaiL: Err, what?  The installer doesn't do any vesafb setup.
[12:24] <KaiL> on the CD menu you can select a screen resolution with F4. This one get's used for X and for into /boot/grub/menu.lst as vga=-Line
[12:24] <infinity> Oh, ick.  Not sure that's sane...
[12:25] <infinity> That's just begging for a bunch of people to complain to us later that hibernate/suspend don't work properly, because people are using vesafb instead of vga16fb...
[12:26] <KaiL> that could explain some things here ;)
[12:26] <Amaranth> are those codes computer/gfx card specific?
[12:26] <KaiL> Amaranth, nop
[12:26] <Amaranth> ooh
[12:26] <Amaranth> you learn something new every day :)
[12:26] <KaiL> infinity, vga16fb is always 4bit, 640x480, as the name says?
[12:26] <infinity> KaiL: 4-bit, 640x400
[12:27] <KaiL> or that
[12:27] <infinity> KaiL: Boot with no vga= at all, and you get vga16fb (assuming you have usplash installed)
[12:27] <KaiL> vga= something is a good way to break suspend :/
[12:28] <KaiL> now I understand, why we had so much fails on the last test round
[12:31] <KaiL> infinity, should I create a bug (or 2)?
[12:31] <KaiL> ..and which package is that then? ;)
[12:31] <infinity> Not positive about how we should deal with it yet (which means I'm not sure where the bug should be filed)
[12:32] <infinity> KaiL: I'll discuss it with Kamion and we'll come up with something we agree is sane.
[12:32] <Pygi> KaiL: can you please go on an "exploring mission"? ;)
[12:32] <KaiL> Pygi, ?
[12:32] <Pygi> We need to find out if wpasupplicant is needed for proper working on N-M
[12:32] <Pygi> and if it is needed for regular WEP
[12:33] <infinity> It is, the way things are done right now.
[12:33] <KaiL> if you can find somebody, who can at least use WEP :)
[12:33] <Pygi> infinity: oh, joy :-/
[12:34] <Pygi> we'll see how it is handled in 0.6.2 ... but I guess it will be the same
[12:34] <Pygi> KaiL: bah ;)
[12:34] <KaiL> I'd like to test, if it works without wpasupplicant, but I'd be happy, if it would work WITH here :)
[12:34] <KaiL> btw. I could try 0.6.2
[12:35] <KaiL> that ubuntu1-Package from yesterday still the lastest?
[12:35] <Pygi> KaiL: hm ?
[12:35] <KaiL> of nm-0.6.2
[12:35] <Pygi> KaiL: please wait with testing 0.6.2
[12:35] <KaiL> hm, ok ;)
[12:35] <infinity> Pygi: The current way it's set up, NOTHING works without wpasupplicant, not even unencrypted wireless.
[12:35] <Pygi> we'll release patches & things soon, so it should be in repos...
[12:36] <Pygi> infinity: yes, I am aware of that...
[12:36] <Pygi> infinity: that is NO GOOD
[12:36] <Pygi> :P
[12:36] <infinity> Pygi: I see no technical reason why this couldn't be resolved.
[12:36] <Pygi> infinity: it can be resolved ...
[12:37] <Pygi> that means more patches,and I think this one doesn't exist, so we have to write it if we want it...
[12:37] <infinity> Yup.
[12:37] <infinity> I'm all for helping on that front, just not today.
[12:37] <KaiL> bug 37223 - that seams to be some VERY VERY annoying bug of gnome-vfs, I also know (and hate)
[12:37] <Ubugtu> Malone bug 37223 in network-manager "NetworkManager is trying to access my LAN's Samba share." [Normal,Unconfirmed]  http://launchpad.net/bugs/37223
[12:37] <infinity> (Flight releases take precedence over NM hacking)
[12:38] <KaiL> here in addition with an also rather common "I'd like to connect to everything"-bug ;)
[12:38] <KaiL> infinity, flight6 on 2006-04-20, or?
[12:38] <Pygi> infinity: agreed ... so, will you be able to help me there once we release flight?
[12:40] <infinity> KaiL: Or 2006-03-30...
[12:40] <infinity> Pygi: No promises, but I will help look into it.
[12:40] <KaiL> that would be cool - but only with that ATI-fix :p
[12:40] <Pygi> k, thanks
[12:40] <infinity> Pygi: It bugs me, cause I really don't want to pull in wpasupplicant as an unconditional dependency.
[12:41] <Pygi> infinity: agreed
[12:41] <infinity> RSYNC, YOU FESTERING HEAP OF POO, GO FASTER.
[12:41] <Pygi> it would be really great if we could pull that patch
[12:42] <Pygi> And I am still unable to see reason why is wpasupplicant needed for anything but WPA
[12:42] <infinity> Pygi: Likely because it was simpler to implement it that way, with only one codepath followed for all wireless networks.
[12:42] <Mithrandir> Riddell: for kubuntu?  Unsure, you haven't given me any feedback.. You most likely want new live images, though.
[12:42] <Pygi> infinity: o joy, let's all start following "the simple path" and I don't want to see where we will end...
[12:43] <infinity> Pygi: It makes sense, in a way, but it's also an unneeded dependency on a known-sketchy product.
[12:43] <Riddell> Mithrandir: well what's the status for ubuntu?
[12:43] <Pygi> infinity: ah
[12:44] <Mithrandir> Riddell: amd64 install cd were having problems booting, something I think we worked out, but since my test machine is downtown, I can't get to it to test.
[12:44] <Pygi> perhaps I could hack in a static IP support into NM as patch as well, and post it to their list, if it wouldn't take too much time for me
[12:44] <infinity> Pygi: If wpasupplicant were more robust, I probably wouldn't have a problem with them unconditionally using it as a backend for all wireless.
[12:44] <Pygi> infinity: agreed
[12:44] <Riddell> Mithrandir: so tomorrow then?
[12:45] <infinity> When rsync and I have done battling, the amd64 install CD will get tested.
[12:45] <Mithrandir> Riddell: yeah
[12:46] <Riddell> Mithrandir: ok, thanks
[12:49] <KaiL> eigher I need a new power supply for my Test-PC or I need a bigger audio system (and new neighbours...) ;)
[12:53] <Pygi> talk to you later people
[01:00] <Kinnison> Mithrandir: is main free again yet?
[01:01] <Mithrandir> Kinnison: no.
[01:01] <Mithrandir> Kinnison: tomorrow, sometime.
[01:03] <Mithrandir> Kinnison: sorry. :-/
[01:04] <Kinnison> Mithrandir: s'okay
[01:04] <Kinnison> Mithrandir: how's f6 going?
[01:04] <Kinnison> If it's not gonna be opened any time soon I may go shopping before the meeting
[01:05] <Mithrandir> Kinnison: please go shopping.  It'll be tomorrow, as in, in about 12-16 hours.
[01:05] <Kinnison> Mithrandir: fair enough :-)
[01:08] <sivang> Kinnison: you're planning to stay awake until the status meeting? :)
[01:08] <Kinnison> sivang: if I go to bed I'll never get up in time
[01:08] <sivang> Kinnison: heh :)
[01:09] <sivang> Kinnison: How are you btw?
[01:09] <Kinnison> mvo: Feh, we only have the second largest supermarket in the UK
[01:09] <Kinnison> mvo: oh, and four or five smaller branches
[01:09] <Kinnison> within 30 minutes of here :-)
[01:09] <sivang> Kinnison: is UK a sort of "non resting" place?
[01:09] <mvo> Kinnison: shops close at 8 in germany
[01:09] <sivang> that is, shops open 24/7
[01:09] <Kinnison> mvo: yeah that sucks
[01:10] <Kinnison> sivang: some shops are open 24/7
[01:10] <sivang> mvo: that's like in .IL
[01:10] <mvo> and I would love to get some caffeine and chocolate
[01:10] <mvo> sivang: will you stay up to talk about HUB?
[01:11] <Kinnison> mvo: I think I shall have a pot of green tea upon my return
[01:11] <Kinnison> mmm tea
[01:11] <sivang> mvo: I might, I actually worked today both on something with martin, and in the backgorund on HUB 
[01:11] <sivang> mvo: I turned up to be more productive then when I concentrate on one of them ..I guess I'm having a good muse day
[01:13] <sivang> mvo: I happen to like those status meeting very much, feels good to know exactly where we stand in real time :)
[01:14] <mvo> Kinnison: green tea is on my agenda as well :)
[01:14] <mvo> sivang: I'm not too happy about the one at 4am though :)
[01:14] <sivang> (fruit tea, lipton's brand)
[01:17] <sivang> mvo: I can understand you, I have work tomorrow so I can symphatize greatly :)
[01:17] <mvo> sivang: after the 4am meeting I'm jetlaged the next day 
[01:17] <mvo> feels like a trip through serveral timezones 
[01:18] <infinity> mvo: I tend to just not sleep after the wonky-hour meetings.
[01:18] <infinity> mvo: Or, stay up for a few days before, then sleep for a day after.  Or whatever. :)
[01:18] <infinity> mvo: Of course, I'm not all that sane, nor rational, so I'm not sure if my advice should be followed.
[01:19] <mvo> infinity: I find it hard to keep productive without any sleep
[01:19] <mvo> I tend to not concentrate that well then
[01:19] <infinity> mvo: See, I'm most productive at the tail end of a really (really) long stretch.
[01:19] <mvo> woah
[01:19] <mvo> maybe I never stretched far enough :) ?
[01:20] <sivang> mvo: I'm like you on this :)
[01:20] <infinity> mvo: Well, when I'm wide awake and alert, my mind's on 1000 things at once, and I sort of multitask all over... As I get further on in the day, I get more focussed on individual tasks, until the evening is spent banging my head on ONE FRIGGIN' THING UNTIL IT WORKS OR ELSE.  Those last two hours always produce the best solutions.
[01:20] <infinity> Again, I'm aware that I'm neither sane, nor rational.
[01:21] <mvo> heh :) stop pointing that out all the time. we know ;)
[01:21] <infinity> Yes, Sven.
[01:21] <mvo> "sven"
[01:21] <sivang> infinity: it worked the other way around for me, I couldn't really solve a couple of bus in my code until I started working on another thing in the backgorund. weird
[01:21] <mvo> he isn't even german (or is he?)
[01:21] <sivang> infinity: Sven ?
[01:21] <sivang> as in, Luther ?
[01:21] <infinity> mvo: Frerman.
[01:22] <mvo> IIRC he is on the seb128 side of germany ;)
[01:22] <Amaranth> infinity: Hey, I do that too.
[01:22] <infinity> mvo: French, with a German name.  I assume a border case, like seb. :)
[01:22] <mvo> sivang: sort of a insider joke
[01:22] <Amaranth> My best code gets written between 10pm and 4am
[01:22] <sivang> ah :)
[01:22] <Amaranth> after that i'm usually too wiped out to type coherent things
[01:22] <KaiL> Amaranth, so you live at the wrong continent ;)
[01:22] <KaiL> life
[01:23] <Amaranth> KaiL: Doesn't matter where I am, the times listed only work because I normally go to bed at midnight.
[01:23] <Amaranth> When I was sleeping during the day it was 4am-8am or so
[01:27] <sivang> infinity: do you have any experience with ATI V3200 on a T43p ? :-)
[01:28] <infinity> sivang: Nope.  I avoided the 'p' series specifically because of that card. :)
[01:28] <sivang> infinity: is it known to be squashing your brain to dust to make it work with Xorg?
[01:29] <sivang> infinity: I'm going to buy a T43 , and since I want 14" with 1400x1050 as you so rightfully recommended, they can offer my only p's. with that card :)
[01:29] <sivang> infinity: the one I had over UBZ was returend due to an exccesive amount of dead pixels
[01:29] <mvo> sivang: what about waiting for a t60?
[01:30] <infinity> mvo: That's even worse, we don't support any of the video in any T60, at all.
[01:30] <infinity> Not even with fglrx.
[01:30] <KaiL> ATi V3200? Never heared of that.. FireGL?
[01:30] <mvo> infinity: isn't there a model with intel graphics? or am I confusing things?
[01:30] <infinity> sivang: fglrx will drive the V3200 fine, the free driver SHOULD (it's an RV380, which we have some support for), but I won't guarantee it.
[01:31] <infinity> mvo: There's one or two models of T60 with Intel graphics, but they're a lot lower down on the spiffy scale (ie: they come with slower CPUs, 1024x768 displays, etc)
[01:31] <infinity> mvo: If you want a T60 with a 1400x1050 or 1600x1200 display, you get ATI video.
[01:31] <sivang> mvo: I could wait, but then the price range I suppose will be much higher then what I'm offered currently from within .IL, including TAX and intl. warranty...
[01:31] <mvo> *grumpf* we don't do even 2d ? a shame
[01:32] <KaiL> thought about an FSC Lifebook S? That's available with 1440x1050 and intel graphics ;)
[01:32] <sivang> hehe
[01:32] <infinity> mvo: We don't support anything in the Radeon X1xxx range yet (and neither fores fglrx), so you get stuck with vesa.  Woo.
[01:32] <infinity> s/fores/does/
[01:32] <KaiL> infinity, not even fglrx supports them?
[01:32] <infinity> KaiL: Nope.
[01:33] <infinity> KaiL: Not really sure WHY, but I know they don't.  ATI's Linux customers aren't very happy with them.
[01:33] <KaiL> ...I love ATi....
[01:33] <KaiL> (everybody saw the ironie-tags?)
[01:34] <infinity> I would be much happier if Thinkpads shipped with nVidia stuff, but I get what I get, and I like the rest of the machine too much to go shopping for another based on the video.
[01:34] <sivang> mvo: plus, the T43p's all come with 7200RPM sata hd, 1GB ram , 1.86GHz proc, 128MB video ram, seems like a decent nice machine, and with a 9cell 5hr batt, it weight 2.62Kg only.
[01:35] <mvo> sivang: sounds pretty nice. I wonder how much the duo core helps in real life (for the t60)
[01:35] <infinity> mvo: I'll let you know when I get one. :)
[01:35] <sivang> infinity: do you recall that my batt was drained quikly then in regular models? it appears it wasn't new. The dealer really tried to rip me off, thanks god I mananged to get a full refund.
[01:35] <mvo> infinity: what model do you plan to get :) ?
[01:35] <sivang> infinity: so with a brand new batt should have no impact on uptime
[01:35] <infinity> sivang: I'm shocked.
[01:36] <sivang> infinity: yes, things like that happen..was shocked myself.
[01:36] <sivang> mvo: x60 is also with duo core ?
[01:36] <KaiL> http://vilpublic.fujitsu-siemens.com/vil/pc/vil/datenblaetter/mobile/en/ds_lifebook_s7020.pdf ;)
[01:36] <mvo> yes
[01:36] <infinity> mvo: Basically the same as what I have now (1400x1050 display, 2GHz CPU, 2GB RAM), but with a dual core CPU and a 7200RPM disk (cause I'm sick of slow disk)
[01:36] <sivang> mvo: (that is like two procs in one?)
[01:36] <KaiL> ..or S7110, if you need 2 CPUs
[01:36] <mvo> KaiL: you have one of them? the specs looks nice
[01:37] <sivang> infinity: is this the big 15" machine that you wanted to switch HDs with ?
[01:37] <KaiL> mvo, a friend has a 15" version (E7010)
[01:37] <infinity> sivang: Yeah, I think I'll downgrade from 15in to 14in when I go T60...
[01:37] <infinity> sivang: The 15in is nice (and very wonderful for movie watching), but a tad bulky for my tastes.
[01:37] <sivang> infinity: but you just said you will be stuck with vesa :-)
[01:38] <mvo> KaiL: what is the overal quality of it? especially the keyboard?
[01:38] <sivang> infinity: yes, after seeing lots of people with 15" I decided I Wanted something powerful and mobile. 
[01:38] <infinity> sivang: Sure, and I'll be forced to help implement proper support for my laptop. :)
[01:38] <sivang> infinity: ah, I see :-) the unbeaten path
[01:38] <KaiL> mvo, very good, but FSC seams to have some "monday production problem" sometimes
[01:38] <mvo> infinity: the t60 with 14" was the alternative that I'm considering. a bit bigger/heavier than the x60 though
[01:38] <infinity> mvo: Nothing beats IBM keyboards.  Period.  If that's your purchasing criteria (it's certainly one of mine), you're owned by IBM for life.
[01:38] <KaiL> so out of 10 laptops, 9 work very good and the 10th is full of bugs
[01:39] <mvo> infinity: I thought so. every keyboard I tried so far lost against my x30 
[01:39] <KaiL> ...this is totally random, not related to any series
[01:39] <mvo> heh
[01:39] <mvo> interessting
[01:39] <infinity> mvo: Tosihba comes a distant second, but IBM still wins hands-down for most hardcore hackers.
[01:40] <mvo> both x60/t60 is not really availble here yet :/
[01:40] <infinity> mvo: And you'll be happy to know that (according to many people online, I haven't yet been able to test one myself :/), the X60 and T60 still have lovely keyboards.
[01:40] <KaiL> his book only has an issue with the mouse (something, several FSCs seams to have): you need to "awaken" the touchpad to get detected as synaptics
[01:40] <infinity> mvo: (Though the jerks have added a Windows key, so the Ctrl key is a bit smaller)
[01:40] <infinity> mvo: But the feel is still the same.
[01:40] <mvo> infinity: *groumpf*
[01:40] <sivang> mvo: I think here as well, but I'll have to check. I suddenly feel suicidal wanting to hack X code to help support more cards :-)
[01:40] <mvo> KaiL: hm, no track-point?
[01:41] <Burgwork> Seveas, wx 2.6.3 released
[01:41] <KaiL> that one is also hit by this bug :/
[01:41] <mvo> sivang: that sounds like famous last words ;)
[01:41] <sivang> hehe
[01:41] <KaiL> if you awaken the touchpad while booting, everything is ok
[01:41] <sivang> mvo: really, it sounds like a religious experience :-)
[01:41] <KaiL> else you only have a standard PS/2 touchpad
[01:41] <KaiL> strange: on a 99% identical Lifebook C, this doesn't happen
[01:42] <mvo> infinity: is this whole not-support-ati stuff a PCIe issue? or is the chipset so different?
[01:42] <mvo> s/chipset/graphicchip/
[01:43] <KaiL> X850 PCIe works, so...
[01:43] <mvo> 'k
[01:43] <KaiL> looks like ATi stopped to care about Linux :/
[01:44] <KaiL> as creative did - or is there a solution for X-Fi arround?
[01:45] <sivang> nope, T/X 60's haven't arrive here yet.
[01:46] <mvo> some are available here, but hardly with the specs I want (i.g. x60s with smalest battery is available, but not with a decent one)
[01:47] <KaiL> the cheap versions are always easy to get ;)
[01:47] <mvo> heh :) yeah!
[01:47] <KaiL> to be exact, biggest CPU, everything else cheapest
[01:47] <sivang> mvo: why not sticking to T43p ? :)
[01:47] <sivang> mvo: I wonder who really needs dual core processing on a laptop :)
[01:48] <mvo> sivang: I'm facinated by the idea to have a dual-core processor in my notebook. it's so *cute*
[01:48] <KaiL> lol
[01:48] <sivang> mvo: not to metnion what that does to your batt life :)
[01:48] <mvo> sivang: don't be rational on such a issue! 
[01:48] <sivang> hehehe!
[01:48] <sivang> you're so right,
[01:48] <KaiL> btw. having an SMP live CD would be cool ;)
[01:48] <mvo> sivang: think about it, to processors to drain your battery ...
[01:48] <sivang> but since this things are SO expansive in .IL
[01:48] <sivang> I can only dream about it probably :-)
[01:48] <mvo> KaiL: yes, this gets more and more important 
[01:49] <sivang> mvo: well, the only thought if having an SMP kernel on my laptop working as expected , is rather arosing
[01:49] <sivang> ;-)
[01:49] <Kamion> KaiL: the kernel automatically switches to SMP if detected
[01:49] <KaiL> Kamion, the one on the live CD?
[01:50] <Kamion> oh, it might only be the -686 and -k7 ones
[01:50] <mvo> Kamion: that was the change from benc a while ago (some weeks)?
[01:50] <KaiL> yes - and the live CD is 386 
[01:50] <Kamion> there's no special "live CD kernel", but the live CD does use the -386 kernel
[01:50] <Kamion> mvo: yeah
[01:50] <KaiL> and the -386 is still needed for AMD K6 and for systems which dislike SMP kernels
[01:51] <Kamion> the problem with using e.g. -686 on the live CD is that, AIUI, you de-optimise for AMD
[01:51] <KaiL> huh? I always thought, the optimisations for Athlon and P4 are very similar at the end?
[01:51] <Kamion> KaiL: not particularly the latter, since it *is* a UP kernel - it just knows how to rewrite itself dynamically to become an SMP kernel if it needs to
[01:51] <Kamion> KaiL: earlier AMDs anyway
[01:52] <KaiL> the -686 requires an i686, or?
[01:52] <elmo> Kamion: technically, it rewrites itself to remove some of the pessmiastions that SMP locking introduces on a UP machine
[01:52] <elmo> Kamion: and more than just de-optimizing for AMD, you drop support for < 686 :P
[01:52] <Kamion> elmo: right
[01:52] <Kamion> elmo: right, but I'm not actually bothered about the live CD on real Pentiums; I *am* bothered about it on Via C3
[01:53] <KaiL> elmo, which is more or less the same - the only really still alive 586 is AMD K6-2 and K6 III
[01:53] <elmo> *shrug* until binary-i386 becomes something other than i386, I think it'd be a mistake to change the kernel on the live CD
[01:53] <infinity> mvo: PCIe isn't an issue, my T43 is a PCIe X300.  It's just that the newer chips are completely different, and the free driver needs to play catchup.  Why ATI doesn't support them in fglrx (when they obviously do in their Windows drivers) is a mystery.
[01:54] <sivang> elmo: does it do that in memory or by removing parts of its image on disk before and relaods?
[01:54] <elmo> sivang: in memory
[01:54] <sivang> whooha
[01:54] <KaiL> infinity, who builds the graphics chips for the xbox360? 
[01:55] <Kamion> elmo: I'm not advocating that - I think -386 is the right choice
[01:55] <infinity> KaiL: ATI, I believe.
[01:56] <KaiL> there isn't enough space for a second (686) kernel on the live CD, or?
[01:56] <Kamion> KaiL: nope
[01:56] <Kamion> KaiL: and furthermore it'd need a different initrd too (different modules)
[01:57] <Kamion> and the interaction with the live installer would be hairy in the extreme
[01:57] <KaiL> and this SMP hack on the -386 is not possible?
[01:57] <Kamion> KaiL: no idea
[01:57] <KaiL> not to mention, that we would "win" dual-pentiums with that too
[01:58] <Kamion> I really don't care about dual Pentiums
[01:58] <Kamion> I doubt hardware like that will perform usefully with the live CD anyway
[01:58] <KaiL> I guess, not even with an installed xubuntu ;)
[01:59] <infinity> KaiL: -386 is kept UP-only intentionally, since some old sketchy ISA-only drivers will completely refuse to compile/work with an SMP kernel.
[01:59] <KaiL> hmm
[01:59] <Amaranth> what op is the Via C3 missing to be a real 686?
[02:00] <Kamion> Amaranth: cmov AIUI
[02:00] <infinity> Amaranth: None, but it's missing "cmov" to behave like everyone else's 686.
[02:00] <Amaranth> ah, that's right
[02:00] <infinity> (cmov isn't part of the 686 base spec, it just happens to be there on everything but the C3)
[02:00] <KaiL> next idea: create some "-586-smp", which gets the default kernel and create some "-386" real crappy hardware?
[02:00] <KaiL> +for
[02:01] <Amaranth> there is a spec? i thought back then it was just "do what intel does"
[02:01] <Kamion> aren't 586 optimisations hideously bad on 686?
[02:01] <infinity> KaiL: We don't want more kernel images.  Really.  We don't.
[02:01] <Kamion> and yeah. what infinity said - not happening, sorry
[02:01] <KaiL> I don't know, if we need to use the "compatible with >10 years old trash"-kernel as default..
[02:01] <infinity> Kamion: Some can be pretty bad, yes.  486 on 686 is saner.
[02:01] <Kamion> KaiL: you can get practically new 486 hardware, depending on what you're doing - mdz runs some
[02:01] <KaiL> Kamion, at least that kernel would work everywhere and support SMP
[02:02] <KaiL> Kamion, but you don't want to run ubuntu on that ;)
[02:02] <Kamion> KaiL: why not? perfectly good on a server
[02:03] <Amaranth> yeah, a 486 with good network cards would make a good router
[02:03] <infinity> The AMD 5x86 (which is a 486 with a really stupid name) keep getting die shrinks and keeps getting manufactured.  It's a really, really low power i386 solution for embedded and "tiny server" use that works well.
[02:03] <Kamion> anyway, if you're going to call things names, at least get it right
[02:03] <Kamion> the Pentium II was released in 1997
[02:04] <KaiL> so I guess, the only possible solution is to wipe out all arguments against SMP kernels...
[02:04] <KaiL> infinity, the X5 is still build? cool!
[02:04] <KaiL> how big is the latest version? 5x5mm? ;
[02:04] <KaiL> )
[02:05] <infinity> Pretty tiny.
[02:06] <sladen> KaiL: the kernels are now dual SMP and UP and patch themselves on bootup
[02:06] <infinity> sladen: Yes, except for the -386 kernel.  We've been over this. :)
[02:07] <KaiL> sladen, the kernels, you can install manually, yes...
[02:07] <Amaranth> that'd be like 0.2in
[02:07] <KaiL> but as you might remember, it's not the kernel installed as default ;)
[02:07] <KaiL> and not the one on the live-CD
[02:09] <Kamion> quite frankly I think there are worse performance issues on the live CD
[02:09] <Kamion> like, er, the way you're running everything off a CD
[02:09] <infinity> s/fapping/flapping/
[02:11] <Amaranth> Kamion: yeah, i don't think a different kernel is going to help much on the live cd :)
[02:18] <Burgwork> infinity, fapping is a decidedly different activity...;D
[02:26] <Kinnison> mvo: tea?
[02:26] <KaiL> lovely ATi, don't even have a support-forum for Linux
[02:26] <mvo> Kinnison: yes please
[02:27] <KaiL> but really, thet don#t have the time for X1k, they need to fix such important thinks like crashes with >=22 mode lines in the config file ;)
[02:29] <sivang> Kinnison: hehe
[02:29] <sivang> Kinnison: "right with the world" ? :-)
[02:30] <Kinnison> sivang: english expression meaning "all okay"
[02:36] <sivang> Kinnison: I know, it just sounds funny :)
[02:38] <Kinnison> :-)
[02:39] <Kinnison> sivang: sup on some jasmine tea and you'll understand
[02:41] <sivang> Kinnison: :-)
[02:45] <Kinnison> tsk
[02:45] <Kinnison> next time we're going to meet, remind me to bring you jasmine tea
[02:47] <sivang> Kinnison: I will! :-) let's hope it will happen sooner then later
[02:47] <Kinnison> :-)
[02:51] <sivang> Kinnison: oh , and that artificially colored lipton "fruit" tea
[02:51] <Kinnison> eww
[02:51] <Kinnison> nasty
[02:59] <YokoZar> Could someone on dapper do me a favor and do a quick apt-get update && apt-cache show xwine ?
[02:59] <YokoZar> I need to know if that package is still in the repos
[03:00] <seth> It appears to be
[03:00] <YokoZar> drat
[03:01] <YokoZar> ok I'm filing a bug against the package saying "package still exists" ;)
[03:01] <Kamion> YokoZar: please don't do that
[03:01] <Kamion> YokoZar: if you want something removed, ask me, and give a reason
[03:02] <YokoZar> Kamion: It's been on morguecandidates for like 4 months now ;)
[03:02] <YokoZar> Here let me link you
[03:02] <Kamion> yeah, 'cos anyone actually *looks* there
[03:02] <Kamion> no, don't link me
[03:02] <Kamion> I'm in a really inconvenient environment right now
[03:02] <Kinnison> ln -o a.out crts.o kamion.o crt1.o
[03:02] <Kamion> hint: ftpmasters don't actually look at MorgueCandidates, you need to make actual removal requests
[03:03] <YokoZar> ok
[03:03] <bddebian> But those tend to get ignored too :-)
[03:03] <YokoZar> I was told the way to do that WAS to put it in morgue ;)
[03:03] <jcole> dudes
[03:03] <Kamion> bddebian: I promise that they won't if you ask me
[03:03] <Kamion> YokoZar: I'm afraid you were told wrong, sorry
[03:03] <Kamion> or at least out-of-date
[03:04] <jcole> i just got the task to slim down dapper for a small net install
[03:04] <YokoZar> Anyway, thanks, and I'll ask you now: packages xwine and wine-doc are super-ancient and incompatible with current wine packages
[03:04] <Kamion> MorgueCandidates seems useful as a way to collect information before making a removal request
[03:04] <bddebian> Kamion: No worries, I was just being a smart-alec, sorry
[03:04] <Kamion> bddebian: (I'm also not aware of ever having got a removal request from you)
[03:05] <YokoZar> there very existence is also confusing some users (I've seen a few forum posts by newbies asking about xwine)
[03:05] <bddebian> Kamion: NO, I've been lame for Dapper.  I bugged the crap out of poor elmo for Breezy though :-(
[03:05] <jcole> with breezy, it was done with some debian-installer hacks... from what i understand, dapper doesn't use debian-installer anymore... has there been a method created for net installing dapper?
[03:05] <Kamion> YokoZar: are they superseded by anything (e.g. current wine packages)?
[03:06] <Kamion> jcole: debian-installer is still available in dapper and won't be removed.
[03:06] <Kamion> jcole: feel free to keep on using it
[03:06] <YokoZar> Yeah, by current Wine
[03:06] <YokoZar> wine-doc is (or should be) integrated, and xwine was superceded by wine about 2 years ago
[03:06] <jcole> Kamion: cool
[03:06] <Kinnison> Kamion: I've updated that page to include the message that it is *NOT* a removals queue
[03:06] <jcole> Kamion: ah, i see dists/dapper/main/debian-installer/binary-i386/Packages.gz
[03:07] <Kamion> Kinnison: thanks; any chance you could update DeveloperResources to say to ask me (for now anyway) for removal requests?
[03:07] <YokoZar> Thanks Kinnison. Is there a list of ftpmasters on the wiki?
[03:08] <Kinnison> Kamion: sure
[03:08] <Kamion> nope, for now direct removals to me, assuming other folks become active on that front then we'll add details to the wiki
[03:09] <Kamion> YokoZar: consider it done after this publisher run finishes (about 20 minutes)
[03:09] <YokoZar> Thanks again Kamion
[03:09] <bddebian> Kamion: Did we lose elmo?
[03:09] <Kinnison> Kamion: do you want to be "Colin Watson (Kamion on freenode)" or "Colin Watson (colin.watson@ubuntu.com)" ?
[03:10] <Kamion> bddebian: no, he's still around, just mostly busy writing tools for the new archive infrastructure
[03:10] <Kamion> Kinnison: the former
[03:10] <Kinnison> Kamion: noted
[03:10] <bddebian> Kamion: Ah, gotcha
[03:10] <Kinnison> Kamion: DeveloperResources updated
[03:11] <Kamion> ta
[03:11] <elmo> I just had a breezy netinstall reverse eth0 and eth1 on me :/
[03:12] <Kamion> let's hope Scott's udev/iftab magic will fix that in dapper
[03:12] <Kamion> for good
[03:12] <elmo> hmm, worth testing dapper on this laptop at some point?
[03:12] <elmo> (it's a CDless tablet horribleness)
[03:12] <Kamion> well, most things with >1 network card will probably exhibit swappage at some point in breezy
[03:13] <elmo> and note to self: 'apt-get install ubuntu-desktop' isn't a good substitute for running the second stage
[03:14] <sivang> elmo: why not?
[03:15] <elmo> xautodetection doesn't work for a start
[03:16] <sivang> well, that could be take care of manualyl with a dpkg-reconfigure xserver-xorg no?
[03:16] <elmo> yeah, but there's a bunch of other stuff
[03:16] <elmo> e.g. language packs, etc. - running base-config really is better
[03:17] <sivang> I see. well, it was meant that way so that makes sense :)
[03:24] <elmo> I've no idea, I'm not using it as a tablet ;-) it's just a spare laptop in the office
[03:25] <Kamion> YokoZar: removed
[03:25] <sivang> elmo: ah, always nice to have spares like this :)
[03:27] <sivang> elmo: are you in the London office? (I'd reckon everyboyd is asleep there)
[03:28] <elmo> argh, WTF
[03:28] <mvo> elmo: the toshia? very nice screen, very bad touchpad :P
[03:28] <elmo> it's now swapped BACK the NICs
[03:28] <elmo> DIE DIE DIE DIE DIE
[03:28] <sivang> lol
[03:28] <sivang> that happened to me for a while with breezy, and a while with dapper until scott did his magic
[03:29] <elmo> sivang: yeah, I am - I work strange hours
[03:29] <jcole> on the dapper install cdrom, is install/initrd.gz ext2 format?
[03:30] <sivang> elmo: heh, acutally it's probably cool, nobody on site to disturb etc
[03:30] <elmo> mvo: yeah, the one from the ui sprint
[03:31] <Kamion> jcole: no, it's an initramfs - gzipped cpio archive
[03:32] <elmo> man, this is retarded.  it's almost like the mapping of the interfaces happens after the hotplug.  is there a simple way out of this mess?
[03:32] <elmo> (dapper isn't an option)
[03:32] <jcole> thanks Kamion
[03:32] <Kinnison> elmo: if one of the modules supports it, add a module option to set the iface nr
[03:32] <Kinnison> ?
[03:33] <elmo> aha, 'auto eth0' was enough.  just bypass hotplug ;)
[03:33] <Kinnison> heh
[03:37] <sivang> Kamion: I don't have a /var/log/$pkg dir per this specific pacakge, where can I find what happend ?
[03:37] <sivang> Kamion: (talking about a postinst blowup)
[03:38] <Kamion> sivang: /var/lib/dpkg/info/foo.postinst
[03:38] <Kamion> not /var/log
[03:38] <sivang> err, it's really too late for me :-)
[03:38] <sivang> thanks
[03:39] <Kamion> no, it was my fault, I typoed earlier
[03:39] <bddebian> Later gang
[03:39] <sivang> later bddebian 
[03:42] <sivang> argh, I would have wanted to stay for the status meeting, but I can't make it. night guys, I wish you a short status meeting :-)
[03:42] <sivang> (shame I came so close..;-)
[03:51] <Burgundavia> does anybody have a firewire device they use to do ethernet over?
[03:54] <fabbione> morning
[03:54] <dholbach> hey fa
[03:55] <dholbach> fabbione :-)
[03:55] <fabbione> hey dh
[03:55] <fabbione> dholbach :-)
[03:57] <Kamion> distro team meeting in four minutes in #ubuntu-meeting
[04:21] <OgMaciel> jdub, ping
[04:21] <paolob> Hi guys! I want to execute a gnome program on a computer of my lan, but as another user. I'm the principal user (the one that can use sudo) on both my computer and the other, but I don't know the password of the user I want to run the program. I tried something like "ssh -Yf otherpc gksudo gksuexec nautilus", but I can't have it work. Any idea?
[04:23] <Burgundavia> paolob: please ask in #ubuntu , as this is not a support channel
[04:23] <Kamion> you might need -t to get ssh to give you a tty so that sudo can prompt for your password
[04:24] <OgMaciel> hi Kamion ... would you know how can I get a hold of Mark?
[04:24] <Kamion> his e-mail address isn't much of a secret ...
[04:25] <OgMaciel> Kamion, right-o... but he probably gets millions of emails every day
[04:25] <OgMaciel> Kamion, let me rephrase it then... would you know of a more direct way to get a hold of him by any chance?
[04:26] <Kamion> please don't put me in the position of having to tell you how to hassle my boss :)
[04:26] <OgMaciel> Kamion, hahahahaha
[04:27] <jamesh> OgMaciel: you can sometimes find him on the international space station, if you're up there.
[04:27] <OgMaciel> Kamion, don't worry...  hehehe
[04:27] <OgMaciel> jamesh, sometimes I do get there...
[04:27] <OgMaciel> jamesh, specially after a few cold ones
[04:28] <OgMaciel> Kamion, been trying to get a hold of jdub too but haven't had much luck
[04:34] <doko> Mithrandir, seb128: disabling pango in firefox makes firefox fly; should we disable it for the flight CD? (iwj is still in vacation)
[04:34] <seb128> "fly"?
[04:34] <doko> way faster
[04:34] <seb128> ask mvo
[04:34] <Mithrandir> doko: no.  Not for the next flight, I just want to get it out now.
[04:35] <mvo> ?
[04:35] <seb128> pango makes rendering better for some locales I think
[04:35] <doko> check MOZ_DISABLE_PANGO=1 firefox
[04:35] <seb128> mvo: didn't play with that during l10n sprint?
[04:35] <Mithrandir> the point of flights isn't to put in a large amount of last-minute fixes, but as a milestone of what's happened since the last flight and seeing that we're on track and schedule.
[04:36] <mvo> seb128: no, I don't think that is wise
[04:37] <mvo> let's first ask some CJK people if it still renders their text
[04:37] <Kamion> pitti: I'd advocate some other documented magic option for overriding X resolution
[04:38] <Kamion> pitti: vga= has sufficient other side-effects that it's an awkward one to use
[04:38] <Kamion> and it's limited in scope anyway
[04:38] <pitti> Kamion: if we could just add some more resolutions to the default xorg.conf, that would already help, I guess
[04:38] <pitti> so that people can change it with the gnome ui
[04:38] <Kamion> assuming they can see the GNOME UI ...
[04:39] <pitti> if they can't do 1024x768, they have a worse problem, right :)
[04:39] <infinity> If we have a graceful vesa fallback, anyone should be able to do vesa at 640x480 or 800x600, then hit the resolution applet to try higher.
[04:40] <infinity> It's only raw oldskool VGA that's limited to the scary 640x400 to work everywhere, not vesa.
[04:41] <fabbione> can we talk about it when we are all more awake?
[04:41] <fabbione> there are a bunch of issues with X and vesa that we need to take into account
[04:41] <fabbione> and i am really not awake enough to discuss them..
[04:41] <infinity> Sometime when Europe is awake is fine with me.
[04:41] <fabbione> kthx
[04:41] <Mithrandir> infinity: dexconf doesn't write all the possible values into xorg.conf, though, which makes it less useful.
[04:42] <fabbione> dexconf is instructed to write.. it doesn't have any idea of what it is writing
[04:42] <fabbione> and it needs to stay that way
[04:42] <infinity> Right.
[04:43] <infinity> It can be told to do things differently, however (especially in the livecd case, where you don't get a "second chance")
[04:43] <fabbione> there is never a second chance
[04:43] <fabbione> that's the whole point of discussing it in details later
[04:56] <Lathiat> so
[04:57] <Lathiat> it seems that in dapper, all programs try to looku ipv6 addresses first
[04:57] <Lathiat> 3 times, then goes for ipv4
[04:57] <Lathiat> i now understand why some people have issues with these
[04:57] <Lathiat> because djbdns' cache, for example, ignores IPv6 requests, because it has no idea what they are
[04:57] <Lathiat> bind otoh will send a rejection back, so you dont have to wait for it to timeout
[04:58] <fabbione> Lathiat: that's nothing new about it. It's called RFC
[04:58] <fabbione> and dapper like warty, etc.. complies to it
[04:58] <Lathiat> well why didnt i see this behavior in breezy?
[04:58] <Lathiat> where it takes a while for a dns lookup, when using such a server
[04:59] <fabbione> Lathiat: because libc6 in dapper is more posix compliant than the one in breezy
[04:59] <Lathiat> e.g. somethings changed
[04:59] <fabbione> there was a bug in the breezy version (or below)
[04:59] <fabbione> it's something i discussed the day after 2.3.6 did hit breezy
[04:59] <Lathiat> hrm
[04:59] <fabbione> because it did revert one ipv6 lookup method as well
[05:00] <fabbione> and we did look at the code
[05:00] <fabbione> that is correct what is doing now
[05:00] <fabbione> breezy was wrong..
[05:00] <fabbione> kthxbye
[05:00] <Lathiat> mmm, i still think it can be a potential issue, tho
[05:00] <Lathiat> as retarded as djbdns is
[05:00] <Lathiat> wonder if any other servers do it
[05:01] <Lathiat> fabbione: what did breezy do?
[05:01] <Lathiat> request both at once?
[05:01] <fabbione> no
[05:01] <fabbione> it was asking ipv6 first always and ipv4 later with one libc6 call
[05:01] <fabbione> now that call is changed
[05:01] <fabbione> and it is left to the app to call the right one
[05:01] <fabbione> i don't remember the details of the function names at 5am
[05:02] <fabbione> but i can dig them for you if you want
[05:02] <Lathiat> hehe 5am
[05:03] <fabbione> and i am babysitting a raid rebuild atm
[05:03] <fabbione> it was something on the way of gethostbyname and gethostbyname2
[05:11] <fabbione> mdz: for the wacom stuff i mentioned at the meeting
[05:11] <fabbione> mdz: i will need UVF exception and at least a new package in the archive
[05:11] <fabbione> there is nothing i can do.. it was spotted too late in the release process :/
[05:12] <fabbione> mdz: basically X upstream did obsoleted the wacom driver from their tree
[05:12] <fabbione> and made "official" the one outside
[05:12] <fabbione> that needs packaging and update
[05:12] <fabbione> and i got to see the bugs only a couple of days ago
[05:13] <fabbione> (well hidden in the other 480)
[05:14] <jcole> anyone heard of nubuntu?
[05:17] <jcole> the nubuntu livecd has apps that are not in the dapper repos... what's the process for the maintainer to add his stuff there?
[05:18] <fabbione> jcole: hmmm not sure...
[05:19] <jcole> http://www.nubuntu.org/
[05:19] <ajmitch> jcole: by talking to the MOTUs to get stuff reviewed & uploaded if possible
[05:19] <ajmitch> since most if not all will be for universe
[05:21] <ajmitch> afaik noone from nubuntu has yet tried getting their packages into universe, which is a shame
[05:23] <jcole> there he is :)
[05:24] <jcole> TomB_ is nubuntu maintainer
[05:25] <ajmitch> hi
[05:25] <TomB_> hi
[05:29] <ajmitch> specifically packages
[05:29] <jcole> TomB_: ajmitch says you need to go to https://wiki.ubuntu.com/MOTU once you have some debs
[05:30] <jcole> ajmitch: he's compiled some of the stuff into the livecd
[05:30] <TomB_> I haven't made any packages for nubuntu, I just compiled them and installed
[05:30] <ajmitch> ah, I see
[05:31] <ajmitch> packages would be appreciated if possible :)
[05:31] <TomB_> I can make packages soon, I'm just getting the mirrors sorted for my release tonight
[05:32] <jcole> i tried the livecd, it's quite nice :)
[05:34] <TomB_> thanks
[05:36] <jcole> TomB_: fyi, this looks like a thorough overview of how to make a debian/ubuntu package -> https://wiki.ubuntu.com/MOTU/Packages/Packaging/Kubuntu
[05:36] <TomB_> I know how to make deb packages hehe
[05:36] <TomB_> We thought about making our own repo back in January
[05:37] <jcole> TomB_: great! ;)
[05:38] <jcole> well, done my good deeds for the day
[05:38] <jcole> good night all!
[07:05] <Burgundavia> nifty. 2.6.17 is merging bcm43xx
[07:37] <Amaranth> cool
[07:38] <Amaranth> i should see if they have a version that doesn't report 100% signal strength on every essid
[08:49] <mdke> jdub, ping: start.ubuntu.com update?
[08:54] <mdke> Diziet, can you take a look at bug #
[08:54] <mdke> damn
[08:54] <mdke> Diziet, can you take a look at bug #33832
[08:54] <Ubugtu> Malone bug 33832 in ubuntu-docs "Get browser startpage translated" [Normal,Confirmed]  http://launchpad.net/bugs/33832
[09:43] <pitti> hi everyone
[09:48] <Keybuk> morning berpitti
[09:49] <dholbach> hey pitti, Keybuk
[09:51] <siretart> hey pitti, hi Keybuk, morning dholbach 
[09:51] <dholbach> hey siretart
[09:51] <siretart> Keybuk: I hope you don't mind that I updated wpasupplicant during your vacation. I updated it to our latest development in debian
[09:51] <Keybuk> siretart: no problem
[09:52] <Keybuk> can you send me a diff of the changes because I'm too lazy to do it myself? :p
[09:52] <siretart> Keybuk: svn up 
[09:52] <siretart> Keybuk: 
[09:52] <siretart> argl, paste terror
[09:53] <siretart> Keybuk: svn up svn://svn.debian.org/pkg-wpa/trunk/wpasupplicant
[09:53] <siretart> thats the right one
[09:54] <Keybuk> I don't have any svn
[09:54] <siretart> then look here: http://svn.debian.org/wsvn/pkg-wpa/trunk/wpasupplicant/debian/changelog?op=file&rev=0&sc=0
[09:54] <Keybuk> how do I see the changes with that?
[09:55] <siretart> you see the changelog. I don't expect the complete debdiff to be useful, because of the massive reintendations in the ifupdown script
[09:55] <Keybuk> I find changelogs very unhelpful in general
[09:55] <pitti> Hey Keybuk
[09:59] <Keybuk> siretart: for example your ubuntu changelog refers to the init script, which I explicitly made it not install
[09:59] <siretart> Keybuk: we removed the init script completely
[10:02] <siretart> since we support now action scripts in /e/n/interfaces, the init script is pretty useless now. and therefore /etc/default/wpasupplicant has gone as well
[10:02] <pitti> siretart: do we even have the option of removing wpasupplicant? I thought n-m even build-deps on it? (which sounds wrong, though)
[10:02] <Keybuk> siretart: yup; makes the world much more sane :)
[10:02] <siretart> pitti: I was very surprised about that as well. no idea why nm does that. 
[10:03] <Keybuk> siretart: silly sanity check in configure.in
[10:03] <siretart> pitti: nevertheless, I find having wpasupplicant around in ubuntu-minimal a good idea anyway
[10:03] <Keybuk> it doesn't do anything other than check you have it
[10:03] <Burgundavia> ogra: gpm or g-s is kicking g-s to life when the power cable is being unplugged
[10:03] <Keybuk> pitti: I don't see a problem with having wpa_supplicant in the default install as long as it's shipped in the state where it's not used unless you put wpa-* options in /etc/network/interfaces
[10:03] <pitti> siretart: so what did you mean with 'remove'?
[10:03] <Keybuk> it's then as useful as wireless-tools and stuff
[10:04] <pitti> Keybuk: hm, but n-m should be able to use it, right? that was the whole point...
[10:04] <Keybuk> pitti: right, and n-m starts/stops it itself
[10:05] <siretart> Keybuk: since there is no sane default configuration for wpasupplicant at all, there is really no point to start it up by default. we expect users to configure /etc/network/interfaces when they want to use wpa
[10:05] <siretart> pitti: the default script was only used my the init script, now both are no longer shipped in the package
[10:05] <Keybuk> siretart: yup, that was my conclusion too
[10:06] <pitti> siretart: ok, so as long as this logging issue is resolved soon, I'm fine with keeping it
[10:06] <Keybuk> logging issue?
[10:08] <siretart> Keybuk: I'd like to hear your opinion about the logging issue. it is described in malone bug 37070
[10:08] <Keybuk> if there's a bug filed, never mind, I'll get to it :)
[10:08] <Keybuk> I've not even opened my e-mail yet
[10:08] <Keybuk> today is ketchup day
[10:08] <pitti> siretart: whoa, I didn't find it any more, because it's now assigned to n-m
[10:09] <siretart> pitti: try http://launchpad.net/bugs/37070
[10:09] <Keybuk> Sorry, you don't have permission to access this page.
[10:09] <Keybuk> RKJSDKRFJI"UI($*U!"(_$*(_!*"$)ERIK
[10:09] <siretart> Keybuk: now you have
[10:09] <Keybuk> why is it private?!
[10:10] <pitti> siretart: it was public yesterday, so what's the point?
[10:10] <siretart> because it is 'security' related :/ (not my decision)
[10:10] <Keybuk> whose decision was it?
[10:10] <siretart> pitti: no, it was filed as private
[10:10] <siretart> it was Pygi's decision
[10:10] <pitti> oh, I see
[10:10] <siretart> yes, I agree
[10:10] <Keybuk> nothing security-related there
[10:10] <pitti> it was mentioned in wpasupplicant's changelog
[10:10] <siretart> it leaks passwords in the log
[10:10] <Keybuk> if you can read /var/log/syslog you're privileged enough
[10:10] <pitti> and the password disclosure is already fixed
[10:10] <pitti> siretart: didn't infinity's patch suppress the passwords?
[10:11] <Keybuk> in fact, if you can read /var/log/syslog you can read the password off the disk :p
[10:11] <siretart> pitti: yes, but I don't think that this is a good solution. I rather think we should revert that patch
[10:11] <pitti> Keybuk: how so? it's just group adm...
[10:11] <siretart> it gains us nothing than obscurity
[10:11] <Keybuk> pitti: so default user, or root
[10:12] <Keybuk> default user = sudo root
[10:12] <pitti> siretart: hm, ok, I thought it actually prevented passwords from being written on the disk; I saw a patch yesterday which attempted to do that
[10:12] <pitti> Keybuk: well, no defence against sudo anyway :)
[10:12] <pitti> anyway, breakfast time, bbl
[10:16] <siretart> hm. there is actually some functionality in wpasupplicant to hide keys, but obviously, the patch fixes some leaks for that.. hmm
[10:17] <siretart> I'll forward this bug to upstream and see what Joulien says about this..
[10:21] <siretart> forwarded
[10:41] <sivang> morning folks!
[10:45] <Fjodor> 'morning sivang 
[10:46] <sivang> hi Fjodor 
[11:01] <pitti> Kamion: hm, the clock question (UTC vs. local) dosen't show the current time. IIRC it did in the past, or am I wrong?
[11:01] <pitti> Kamion: ^ installer
[11:14] <pitti> Kamion: out of interest, what does actually happen during the very long 'Retrieving file n of 819' step?
[11:19] <mvo> pitti: that sounds like a message from apt that it gets the language-packs? is a http process runing in the background?
[11:19] <pitti> mvo: no, it's a networkless CD install
[11:19] <mvo> oh, ok.
[11:19] <pitti> mvo: and on console 4 I don't see any progress at all
[11:19] <giftnudel> I guess there are copied to the target
[11:19] <pitti> it just takes about 10 minutes, maybe it copies the debs from the CD
[11:19] <giftnudel> or this is what I thought would happen
[11:20] <pitti> yeah, but what is this good for?
[11:20] <pitti> and now it extracts templates and still accesses the CD
[11:20] <pitti> thus it doesn't seem to use the copied debs
[11:22] <pitti> mvo: right, it copies everything to /target/var/cache/apt/archives
[11:22] <janimo> mvo, did you have a look at the gconf/update-manager patch?
[11:24] <mvo> janimo: yes, it looks ok, but do you want it for xubuntu? I mean, not saving the settings is not that great (even when it only happens without gconf)
[11:27] <janimo> mvo, well if you think the idea is ok I can make it save the settings using some other mechanism
[11:27] <janimo> just wanted to make sure it's fine with you
[11:28] <mvo> janimo: oh, right. yes, the patch looks good
[11:29] <mvo> janimo: how to you plan to handle it for xuubntu? we would need to drop the python-gnome dependency for this to help you, right?
[11:29] <janimo> mvo, right. So if you could apply the patch as is and drop the gnome dep
[11:29] <janimo> I could already put it in xubuntu-desktop
[11:30] <janimo> then think about a clean way to save the settings in non-gconf case
[11:30] <Harti> on my dapper flight5 (server and only xfce. no dm ala gdm) with all updates the reboot and shutdown doesnt work
[11:31] <mvo> janimo: ok, please keep poking me if I forget :) I put it into my bzr now. can't upload because of flight-6 
[11:31] <Harti> https://launchpad.net/distros/ubuntu/+source/xfce4-session/+bug/35711
[11:31] <Ubugtu> Malone bug 35711 in xfce4-session "no xfsm-shutdown-helper" [Normal,Unconfirmed]  
[11:31] <janimo> mvo, thanks !
[11:31] <Harti> Ubugtu: yes, its me
[11:31] <mvo> janimo: thanks for the patch :)
[11:31] <janimo> :)
[11:32] <janimo> Harti, let's talk in #xubuntu
[11:39] <Keybuk> pitti: uh, dude ... why are language packs Arch: all ?!
[11:40] <pitti> Keybuk: why shouldn't they?
[11:40] <Keybuk> because .mo files are byte-order dependant?
[11:40] <pitti> Keybuk: we never had a problem with that
[11:40] <pitti> they work fine on powerpc
[11:40] <pitti> or did that change very recently?
[11:40] <Keybuk> they've always been
[11:40] <Keybuk> I don't know whether the powerpc gettext handles i386 .mo files though
[11:41] <Keybuk> mo = machine object, the non-portable form of a po = portable object
[11:41] <pitti> German works just fine on my ppc at least
[11:41] <pitti> with unicode
[11:41] <Keybuk> maybe gettext is designed to read them in either order then
[11:41] <Keybuk> would need to ask an expert I guess
[11:42] <pitti> yes, I think it is
[11:42] <pitti> .mo files have a magic
[11:42] <pitti> 0x950412de or 0xde120495
[11:43] <robtaylor> Keybuk: quick question, is /proc/bus/usb supposed to not get mounted any more in mountvirtfs?
[11:43] <Keybuk> robtaylor: correct
[11:43] <Keybuk> software should be changed to use /dev/bus/usb instead
[11:43] <robtaylor> Keybuk: that was what i though, good :)
[11:43] <Keybuk> /proc/bus/usb was a kernel psuedo-filesystem generated by a now-deprecated kernel module
[11:44] <robtaylor> Keybuk: (the n770 flasher program assumes its mounted, so just checking what the correct fix is..)
[11:44] <Keybuk> /dev/bus/usb is maintained by udev (along with the rest of /dev) in response to uevents from the kernel usb_device subsystem
[11:44] <robtaylor> yep, the correct way
[11:44] <Keybuk> the obvious advantage of the latter is we can set ownership and permissions when we create the devices :p
[11:45] <robtaylor> Keybuk: mind if i paste your reponse into a bug report?
[11:45] <Keybuk> go for it
[11:45] <robtaylor> cool, thanks :)
[11:45] <Keybuk> this is true for the upcoming SuSE and Fedora Core releases too, afaik
[11:48] <Kamion> pitti: deliberate, the clock setup bit of the installer was rewritten and doesn't attempt to do that any more
[11:48] <pitti> Kamion: ok (although I found that useful)
[11:49] <Kamion> pitti: dealing with the hardware clock in the first stage was very fragile and broke a lot
[11:56] <pitti> hi Mithrandir 
[11:56] <pitti> Mithrandir: ppc install is in progress (it just takes ages)
[12:05] <Mithrandir> Kamion: last night's amd64 image still fails to boot for me.
[12:06] <Kamion> bugger, well I have no idea I'm afraid :(
[12:07] <Mithrandir> I'll just download flight-5 and make sure that still works here, then go forward to the latest we have.
[12:13] <pitti_live> Mithrandir: both amd64 and ppc live drop out of usplash and show a large list of casper debug messages (sh -x like)
[12:13] <pitti_live> Mithrandir: I made a photo screenshot, do you need it?
[12:14] <pitti_live> seb128: xchat-gnome broke; it just loops connecting, and says something like "/USER: invalid parameters"; so I installed xchat...
[12:14] <pitti_live> doko: ping
[12:14] <seb128> pitti_live: gni?
[12:14] <pitti_live> seb128: what's gni?
[12:14] <seb128> nobody bugged about that
[12:14] <seb128> and xchat-gnome didn't change for weeks now
[12:15] <pitti_live> seb128: hm, it worked about a week ago, I'm sure
[12:15] <seb128> that's just weird
[12:15] <pitti_live> hm, odd
[12:15] <seb128>  -- Martin Pitt <martin.pitt@ubuntu.com>  Thu,  2 Mar 2006 16:42:38 +0100
[12:15] <Mithrandir> pitti_live: no, I see it myself.  I'm not sure what the reason is.
[12:15] <pitti_live> I only use xchat-gnome in the live session, since it's in main
[12:15] <seb128> is the current xchat-gnome upload
[12:15] <Mithrandir> pitti_live: I'm inclined to just stick it in the errata and ignore it for now.
[12:15] <pitti_live> Mithrandir: alright, if it's known; doesn't break anything as it seems
[12:16] <Mithrandir> pitti_live: it's just ugliness, nothing more.
[12:16] <pitti_live> ok
[12:16] <pitti_live> doko: OO.o spell checking works on ppc/live, but doesn't on amd64/live
[12:20] <doko> pitti_live: interesting ...
[12:20] <Mithrandir> Kamion: grr..  REALLY GRR.  20060326 works.
[12:20] <pitti_live> doko: currently filing a bug
[12:22] <pitti_live> doko: bug 37304
[12:22] <Ubugtu> Malone bug 37304 in openoffice.org-amd64 "spell checking  does not work on current amd64/live CD" [Normal,Unconfirmed]  http://launchpad.net/bugs/37304
[12:22] <Mithrandir> doko: also, we're still in freeze.  Don't upload anything to main until flight-6 is out.
[12:23] <pitti_live> Kamion: does the current ppc/install work for you? after rebooting after d-i, it panics with "unable to moutn root fs on unknown-block (0,0)"
[12:23] <pitti_live> Kamion: booting with "Linux root=/dev/hda4" does the same
[12:24] <Kamion> pitti_live: I can't do anything much on powerpc at the moment, sorry
[12:25] <pitti_live> Kamion: ok
[12:25] <Kamion> Mithrandir: boggle
[12:26] <Kamion> nothing meaningful has even changed on cdimage in that time
[12:26] <Mithrandir> Kamion: I'm wondering if me having !C LANG might influence stuff.
[12:27] <doko> Mithrandir: so we do have different OOo versions on i386 and amd64?
[12:27] <Mithrandir> Kamion: not that I understand why that would case the bootloader to not be put on the cd.  And just for me.
[12:27] <Mithrandir> doko: we shouldn't, no.
[12:28] <Mithrandir> Kamion: 20060328 works too.
[12:28] <pitti_live> Kamion: do you have a minute to debug this with me?
[12:28] <stub> Launchpad will be going down in 15 minutes for a code update. Estimated downtime is 10 minutes. Wikis will be in read only mode during this time.
[12:28] <pitti_live> Kamion: yaboot.conf looks fine, but ybin complains about "Failed to initialize HFS working directories: No such file or directory" (in chroot /mnt under live CD)
[12:29] <pitti_live> Kamion, and '/dev/hda2 appears to have never had a bootstrap installed, please run mkofboot'
[12:29] <pitti_live> Kamion: but mkofboot yields the same 'Failed to initialize..' message
[12:29] <Kamion> Mithrandir: it's possible, but then I built the most recent one
[12:30] <doko> Mithrandir: so the 2.0.2-2ubuntu1 packages won't make it on the CD?
[12:30] <Mithrandir> doko: if you wanted stuff onto flight-6 you should have uploaded it two days ago.
[12:30] <Mithrandir> Kamion: true.. and it would be really strange it just affects me, and just on amd64.
[12:31] <Kamion> pitti_live: that's a message from hfsutils
[12:31] <Kamion> pitti_live: put /var/log/installer/syslog somewhere for me?
[12:31] <pitti_live> shit, no my OF boot prom doesn't even want to boot any more
[12:31] <pitti_live> s/no/now/
[12:32] <Kamion> worst case, zap the PRAM ...
[12:32] <pitti_live> Kamion, as soon as I repaired booting
[12:32] <doko> Mithrandir: next time, please send a short notice for this date, plus one about the state of the archive.
[12:32] <Kamion> cmd-opt-p-r, keep a bootable CD handy
[12:32] <Kamion> doko: please just accept that if you don't get onto one flight cd you'll get onto the next
[12:32] <Mithrandir> doko: it's in the development status reports as well as in the topic here.
[12:32] <Kamion> you always seem rather stressed about getting things onto one particular milestone
[12:33] <Kamion> which makes life more difficult in turn for the people building the milestone
[12:33] <Kamion> these are not meant to be heavyweight releases
[12:33] <Kamion> they're meant to be snapshots of the state of the world, with a bit of tuning to try to make the state of the world sane
[12:33] <Kamion> but only sane insofar as "people can use the thing at all"
[12:34] <Kamion> if people have to be given several days' notice etc., then the release is too heavyweight
[12:36] <Keybuk> Kamion: "so I'm just doing clone-and-hack of netcfg's logic for writing the standard network configuration files, plus copying certain bits from the live filesystem (/etc/network/interfaces mainly)"
[12:36] <Keybuk> does that include /etc/iftab writing?
[12:36] <Kamion> Keybuk: yes
[12:36] <doko> Kamion: sorry, doesn't hinder you /somebody else about announcing it. crashing OOo with the atk is unfortunate, the fix was not released earlier. 
[12:37] <Kamion> Keybuk: any caveats about that?
[12:37] <Keybuk> ok, I know it's probably low on your priority list but it'd be better if that code was libraryfied rather than just C&P'd
[12:37] <Keybuk> it's got "logic" in it that may need fixing regularly
[12:37] <Keybuk> the bit that chooses not to write certain lines, or whether to add "arp X", etc.
[12:38] <Kamion> Keybuk: I agree, but I'd like to do that by calling netcfg from espresso the way I call all the other bits of the installer
[12:38] <Keybuk> ok
[12:39] <Kamion> Keybuk: unfortunately this turns out not to be entirely straightforward in the short term
[12:39] <`anthony> is there a way to find out what versions of packages are in Dapper, without installing it? want to find out what version of sqlite3 is there...
[12:39] <Keybuk> on NM WEP/WPA passwords ...
[12:39] <Kamion> Keybuk: the whole thing has a big TODO clone-and-hack comment at the top
[12:39] <Kamion> I don't just copy-and-paste without saying I've done so and leaving a todo :)
[12:39] <Keybuk> hehe, I didn't think you would
[12:39] <Kamion> `anthony: packages.ubuntu.com
[12:40] <Kamion> or launchpad.net/distros/ubuntu/dapper
[12:40] <Keybuk> (aside: is launchpad actually not lying about source package versions now?)
[12:40] <Kamion> https://launchpad.net/distros/ubuntu/+source/sqlite3
[12:40] <Kamion> I'd never noticed it lying in the first place ...
[12:41] <Keybuk> Kamion: it lied on the /ubuntu/dapper/+source/ URLs in the early days; seems to be fixed now
[12:41] <Keybuk> anyway, NM and WEP/WPA keys
[12:42] <Keybuk> afaik you just copy $HOME/.gnome2/keyrings onto the installed system
[12:42] <Keybuk> which I imagine gets taken care of along with the copying $HOME
[12:42] <Kamion> that would be true if we copied $HOME
[12:42] <Keybuk> we don't copy $HOME ?
[12:42] <Kamion> we explicitly decided not to, because stuff helpfully encodes the username in there
[12:42] <Kamion> which will not be the same
[12:42] <Keybuk> then I guess "the installer doesn't remember my WEP keys" is about equivalent to "the installer doesn't remember that I changed my background image" etc.
[12:42] <Kamion> right
[12:43] <Kamion> we can choose to copy individual bits
[12:43] <Kamion> any idea what that'd be with network-manager-kde?
[12:43] <Keybuk> I don't think you can copy the keyring without gconf data
[12:43] <Kamion> IIRC gconf was one of the offenders for remembering the username
[12:43] <Kamion> and why the heck is this applet-specific anyway?
[12:43] <Keybuk> I suspect we're buggered
[12:43] <Keybuk> because the GNOME applet uses the GNOME configuration and keyring infrastructure
[12:43] <Keybuk> the KDE one probably uses kconf and kde-keyring and stuff :p
[12:44] <Keybuk> instead of gconf and gnome-keyring <g>
[12:44] <Kamion> how extremely annoying
[12:44] <Kamion> we need /etc/network/interfaces.d/ or something :P
[12:44] <Keybuk> what would you key it on?
[12:44] <Kamion> I could gconftool out specific values and set them
[12:45] <Keybuk> the /system/networking/wireless tree seems "important"
[12:46] <infinity> I'm not sure how important this is, if you're blowing away $HOME in general anyway.
[12:46] <Keybuk> indeed
[12:47] <infinity> This is no different from the other irritating NM feature where "if I create a user for my mom and log out, when she logs in she won't have a network", cause NM has NO concept of central configuration at all.
[12:47] <Keybuk> yeah, I dislike that a lot
[12:47] <infinity> I suspect my mom would too. :)
[12:48] <Keybuk> I haven't decided yet whether to petition for replacement-init or replacement-networking for dapper+1 yet :o)  I imagine I'll only have time for one of them
[12:48] <infinity> Oh, has anyone bugged you about NM's icky segv yet?
[12:49] <Keybuk> nope
[12:49] <infinity> I didn't bother filing a bug, cause I didn't know when you were coming back, so was going to look into it myself.
[12:49] <Keybuk> bug me later this afternoon if you want
[12:50] <infinity> Take a working /e/n/interfaces file with an uncommented "iface eth1 inet dhcp" and add, say, "wireless_mode managed" to that stanza.
[12:50] <infinity> Not sure what you want to happen there (stanza ignored, NM says "I can do that!" and does it, whatever), but that currently causes a lovely segv. :)
[12:50] <Keybuk> nope, STILL not this afternoon :)
[12:50] <infinity> Yeah, I was already typing when you said that.  I'm groggy from an evening nap. :)_
[12:51] <doko> pitti_live: still checking the live CD? could you check if the the dictionary is shown as available in the preferences?
[12:51] <Keybuk> that SEGV could be anywhere from the /e/n/i parsing code to a general failure on NM's part to ignore interfaces
[12:51] <pitti_live> doko: sure
[12:54] <pitti_live> doko: btw, F7 doesn't do anything useful, too; it opens the dialog, but doesn't check anything
[12:54] <pitti_live> Kamion, is there any way to tell partman to reformat/recreate the bootstrap partition?
[01:08] <Kamion> pitti_live: sure, select it in the manual partitioner and say format
[01:08] <infinity> doko: How does conflicting with nvidia-glx magically fix 3 bugs about broken diversions in your package? :)
[01:10] <pitti_live> Kamion: there is no 'format' option for 'Apple NewWorld boot partition'
[01:10] <pitti_live> Kamion: btw, I have an idea what could have went wrong: I tried / on XFS for a change (usually I take reiserfs)
[01:10] <doko> infinity: the package doesn't have any diversions
[01:11] <infinity> doko: It uses dpkg-divert, obviously, even if it no longer ships diversions...
[01:11] <infinity> doko: https://launchpad.net/distros/ubuntu/+source/ia32-libs-gtk/+bug/34189 clearly has nothing to do with nvidia-glx, hence my confusion.
[01:11] <Ubugtu> Malone bug 34189 in ia32-libs-gtk "the package cannot be updated" [Normal,Confirmed]  
[01:12] <Kinnison> infinity: Can you keep an eye on failed/ for a bit, new codeline just went out to drescher
[01:13] <infinity> Kinnison: Ja.
[01:13] <Kinnison> I don't believe you were
[01:14] <Kamion> pitti_live: oh, that's right, there was no need for that option in the partitioner because yaboot-installer uses mkofboot, not ybin, and mkofboot automatically formats the partition
[01:14] <infinity> Kinnison: If I was, I clearly wouldn't remember them anyway. :)
[01:14] <Kinnison> :-)
[01:14] <Kamion> pitti_live: there was an initramfs-tools issue with the combination of yaboot and / on XFS ...
[01:14] <Kamion> I don't recall it being closed
[01:15] <infinity> Kinnison: Oh, I was waiting on the NEEDSBUILD/BUILDING unconfusion, but I'm betting that's still pending approval or something.
[01:15] <Kinnison> infinity: I know nothing about that, sorry
[01:15] <pitti_live> Kamion: alright, thank you (and sorry for pestering you)
[01:16] <infinity> Kinnison: Yeah, not a huge deal.  I'll get cprov to chase it up when he's back with a ring his finger and a spring in his step.
[01:16] <infinity> s/ring/ring on/
[01:17] <Kamion> pitti_live: np
[01:17] <Kamion> ok, so I'm copying /etc/network/interfaces and writing /etc/hostname, /etc/hosts, and /etc/iftab
[01:18] <Kamion> I wonder if I need to do anything with /etc/networks, /etc/resolv.conf, or the various dhclient.conf files
[01:18] <Kinnison> infinity: rings on his fingers and bells on his toes?
[01:18] <Kamion> Kinnison: they didn't give me the bells when *I* got married
[01:18] <Kamion> bloody discrimination
[01:18] <Kinnison> Kamion: then you shall not have music wherever you go
[01:18] <Kamion> that'd be the lack of speakers in the stufy
[01:18] <Kamion> study
[01:19] <Kinnison> :-)
[01:19] <Kinnison> Stufy is a good name for it too
[01:19] <Kinnison> it gets rather warm in there
[01:19] <Kamion> mm
[01:19] <Keybuk> I have that problem too
[01:19] <Keybuk> three computers a frosty office doth not make
[01:22] <_ion> Hi
[01:26] <`anthony> Kamion: Thanks! Yay, Dapper has a new enough version of sqlite, so I don't have to be sad.
[01:30] <Kinnison> Keybuk: aye
[01:32] <pitti> Mithrandir: just for the records, amd64/install doesn't boot for me either
[01:33] <Mithrandir> pitti: ok, so it's not just me.
[01:34] <Mithrandir> pitti: does i386/install work for you?
[01:36] <Kamion> might be worth trying to strip down the image (e.g. remove dists/ and pool/) and re-mkisofs, to see if it goes away
[01:36] <Kamion> mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-install-amd64-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
[01:36] <Kamion> something like that should work
[01:39] <infinity> "something like that"
[01:39] <Mithrandir> : tfheen@little ..tu/daily/tmp/dapper-amd64 > cat 1.mkisofs_opts ;echo
[01:39] <Mithrandir> -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -sort /srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-amd64/1.weights boot1
[01:39] <Ubugtu> Error: I tried to send you an empty message.
[01:39] <pitti> Mithrandir: I don't have the i386 CDs
[01:44] <Kamion> -sort shouldn't be a big deal
[01:44] <Kamion> the rest matches
[01:45] <Kamion> "shouldn't"
[01:46] <Mithrandir> Kamion: moving pool out seems to make it boot for me.
[01:47] <infinity> And since the contents of pool is meaningless to the boot process, we're left back at "image too big", or "too many files confusing the filesystem and breaking something"?
[01:48] <infinity> And mkisofs shouldn't allow the latter without loud warnings, I hope.
[01:48] <Mithrandir> "image too big" is not a problem when I'm putting this onto a DVD.
[01:49] <infinity> Not an overburn problem, but maybe isolinux hates it?
[01:50] <Kamion> Mithrandir: if you re-mkisofs the image without making *any* changes, does it still boot?
[01:50] <infinity> s/still boot/still not boot/?
[01:50] <Kamion> either :-)
[01:50] <Kamion> "still" relative to the hacked image, I guess
[01:51] <Mithrandir> Kamion: no
[01:51] <Mithrandir> Kamion: it doesn't boot if I just re-mkisofs it
[01:51] <Kamion> hm.
[01:51] <infinity> What if you just pull out one randomly large file?
[01:51] <Kamion> so I guess mkisofs hates us
[01:51] <Mithrandir> stuffing 5MB of 0s onto the image didn't fix it, so it's probably not a magic offset thing.
[01:52] <Kamion> Mithrandir: I think it might be worth grabbing /srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-amd64/1.weights and arranging for /isolinux/isolinux.bin and /isolinux/boot.cat to be sorted to the start
[01:57] <Keybuk> damn I want debmeld :p
[01:58] <siretart> should be rather easy to implement once hct is there ;)
[01:59] <Keybuk> nothing to do with hct or even vcs
[02:00] <Mithrandir> Kamion: yeah, checking that out.
[02:00] <Mithrandir> Kamion: removing a single file (ooo-writer) didn't help.  Maybe it was too small.
[02:02] <Mithrandir> Kamion: ok, adding:
[02:02] <Mithrandir> CD1/isolinux/isolinux.bin +2
[02:02] <Mithrandir> CD1/isolinux/boot.cat +1
[02:02] <Mithrandir> fixes it.
[02:03] <Mithrandir> I _really_ wonder why this bit us now, though
[02:03] <Kamion> Mithrandir: right, I'll commit a fix for that - writing the code now
[02:03] <Kamion> yeah, me too
[02:03] <Kamion> well
[02:03] <Mithrandir> Kamion: thanks.
[02:03] <Kamion> Mithrandir: we only relatively recently went up to 700MB CDs
[02:04] <Mithrandir> true.  Though, Tuesday's CDs work for me.
[02:04] <Kamion> yeah, but we haven't filled them yet on amd64
[02:04] <Kamion> it could be BIOS-dependent or something
[02:04] <Mithrandir> yeah.
[02:06] <Mithrandir> ok, I'll test the live cds now and then the install cds.
[02:08] <seb128> Mithrandir, infinity: I've a desktop-file-utils update setting nautilus as default app for folders on GNOME (fixes the issue that people having konqueror installed get it used from the panel places menu), is that ok to upload or should that wait?
[02:08] <Mithrandir> seb128: if you could hold it off for a few hours, I'd appreciate.
[02:08] <seb128> Mithrandir: no problem
[02:09] <seb128> it's not likely to break anything but your call :)
[02:10] <Mithrandir> seb128: it's more the "debug one thing at a time". :-)  I'm not very worried about the fix itself.
[02:10] <seb128> k
[02:14] <Kamion> Mithrandir: rebuilding
[02:15] <Mithrandir> Kamion: I guess we should rebuild edubuntu and kubuntu too if this fixes it.
[02:16] <Kamion> yeah
[02:17] <Keybuk> Kamion: I'm confused about a seed management thing ... I added wpasupplicant to minimal at the same time I added network-manager-gnome to desktop, but only the latter change has shown up in the meta-packages
[02:17] <Keybuk> was there something extra that needed to happen?
[02:17] <Mithrandir> Keybuk: it needed to be promoted too
[02:17] <Mithrandir> iirc
[02:18] <Kamion> Keybuk: all additions to minimal (specifically) are blocked on bug 37156
[02:18] <Ubugtu> Malone bug 37156 in launchpad-upload-and-queue "can't change sections or priorities with change-override.py" [Major,Confirmed]  http://launchpad.net/bugs/37156
[02:18] <Keybuk> ok, that's happened now
[02:18] <Keybuk> heh
[02:18] <Kamion> because minimal requires debootstrap to install it, which relies on priorities
[02:19] <Keybuk> k, was just checking I hadn't screwed something up :)
[02:19] <Kamion> if you want to put it in a different seed (standard? desktop?) for the time being, that might be a good idea
[02:19] <Kamion> I don't really fancy trying to talk to the launchpad database by hand to do this
[02:19] <Keybuk> it belongs next to wireless-tools really; it's just as useful, and in the fashion we're shipping it, doesn't hurt
[02:19] <Kamion> yeah, just for the time being
[02:19] <Keybuk> INSERT INTO kamion SELECT pain FROM launchpad;
[02:20] <Kamion> ooh, baby
[02:20] <Mithrandir> oh, shiny.  NM actually works on my desktop now and it detected the wireless network here.
[02:20] <Keybuk> quest dapper-seeds% bzr commit
[02:20] <Keybuk> modified/renamed/reparented standard
[02:20] <Keybuk> *blink*
[02:20] <Keybuk> can't the bzr guys pick a verb? :p
[02:20] <Mithrandir> Keybuk: "twiddled". :-P
[02:21] <Kamion> Keybuk: bug 36963
[02:21] <Ubugtu> Malone bug 36963 in bzr "modified/renamed/reparented is unnecessarily fuzzy" [Normal,Unconfirmed]  http://launchpad.net/bugs/36963
[02:21] <dredg> best verb as seen on a netapp: deswizzled.
[02:22] <sivang>  Keybuk is this ANSI SQL ?
[02:23] <Mithrandir> Kamion: espresso desperately needs to do busy-cursors etc.  It's very confusing.
[02:24] <sladen> INSERT TABLE INTO $person WHERE person = "pedantic" AND it = "fits";
[02:24] <Mithrandir> sladen: SQL generally uses ' for marking strings, not ".
[02:24] <sivang> Mithrandir: you can use both , no?
[02:25] <Kamion> Mithrandir: not so much busy cursors (although partly that) as disabling stuff until it's actually ready for you to use the page
[02:25] <Kamion> which requires figuring out when it's ready for you to use the page, which is not immediately obvious :-)
[02:25] <Kamion> but yes, I agree, it's something I want to sort out
[02:25] <Mithrandir> Kamion: showing a page and then taking a second and a half to pop up "starting partitioner" is confusing.
[02:25] <Kamion> Mithrandir: I agree.
[02:26] <sivang> I was asking becuase I used to be the tests developer for a middleware back in 2000, and the developers were proude that they middleware supports this clause while MS-SQL, MySQL and others did not at the time.
[02:26] <Kamion> I also think it shouldn't show the page until it's ready for you to use it.
[02:26] <Kamion> or at least somewhat closer to that state of affairs than at present
[02:26] <sivang> (and that it was rather out of standard)
[02:26] <Mithrandir> Kamion: yeah, that'd work too.
[02:26] <Mithrandir> live/amd64 seems good, installation ETA ~3M.
[02:27] <Kamion> Mithrandir: new install/amd64 up, if you hadn't noticed
[02:27] <Mithrandir> I haven't but rsyncing now
[02:27] <Kamion> somebody please tell me why *removing* language packs spends so long regenerating locales
[02:28] <Kamion> this causes annoyance in espresso
[02:28] <Robot101> 'cause the dpkg post-badger hook thing isn't done? :)
[02:28] <infinity> Will it ever be?
[02:29] <Kamion> it's got bog-all to do with hooks AFAIK
[02:29] <Robot101> well yes, regenerating the stuff thats left behind seems a little dumb :)
[02:29] <Kamion> the maintainer script would be just as daft if the same code were in a hook instead
[02:31] <doko> Kamion: removing locales: #34593
[02:32] <Kamion> thanks
[02:33] <Riddell> was the kubuntu live CD filesystem not remade last night?
[02:33] <Kamion> all the cron jobs are disabled
[02:33] <Kamion> as normal around Flight releases
[02:33] <Kamion> ask Mithrandir or infinity if you need a manual rebuild
[02:34] <Riddell> Mithrandir: could you do a kubuntu live cd filesystem build?  I'd like to get kde 3.5.2 into flight 6
[02:35] <Mithrandir> Riddell: running.
[02:36] <Mithrandir> Riddell: I'll start a live cd build too once it's done
[02:36] <Riddell> groovy, thanks
[02:39] <Mithrandir> Kamion: espresso install is very unhappy.  root= is blank
[02:39] <Mithrandir> pitti: did you have a chance to test espresso/amd64?
[02:42] <Kamion> Mithrandir: I just noticed the same thing
[02:42] <pitti> Mithrandir: yes, I did
[02:42] <Mithrandir> pitti: did it work?
[02:42] <pitti> Mithrandir: it suffers from the same bug I recently reported on ppc
[02:42] <pitti> Mithrandir: lemme dig it out
[02:42] <Mithrandir> pitti: ok.  root= is blank?
[02:43] <pitti> Mithrandir: bug 36458
[02:43] <Ubugtu> Malone bug 36458 in espresso "crashes after formatting partitions" [Normal,Unconfirmed]  http://launchpad.net/bugs/36458
[02:43] <pitti> Mithrandir: I don't get to the point of copying the system
[02:43] <pitti> Mithrandir: the amd64 install crashed exactly at the same point today (likewise today's ppc live)
[02:43] <Mithrandir> pitti: hmm, ok
[02:44] <pitti> Mithrandir: my last (and only) successful fs copying is about two or three weeks ago
[02:44] <Kamion> pitti: your last log in that bug was not in fact with ESPRESSO_DEBUG=1
[02:44] <Kamion> I can't make head nor tail of the previous log though - it looks like debconf got very confused before even starting
[02:44] <pitti> Kamion: oh? sorry for that;
[02:44] <Mithrandir> bad media?
[02:44] <pitti> Kamion: alright, I redo another one
[02:45] <Kamion> I wouldn't blame media here
[02:45] <pitti> I doubt that it's the media
[02:45] <Lure> Mithrandir: can I get test install/i386 image as I would like to verify is bug 34592 is addressed?
[02:45] <Ubugtu> Malone bug 34592 in gfxboot-theme-ubuntu "dapper flight 5: install menu never comes" [Critical,Confirmed]  http://launchpad.net/bugs/34592
[02:45] <pitti> phew, my ppc lives again and is happy
[02:45] <pitti> Mithrandir: ok, so ppc live and install work fine for me
[02:46] <Mithrandir> Lure: they're all on cdimage.ubuntu.com
[02:46] <Mithrandir> Lure: if you have an image already, I recommend using rsync to just copy over changes.
[02:46] <Kamion> Lure: well, I suppose it *could* have gone away as mystically as it arrived ... but I haven't done anything to address that bug
[02:46] <Lure> Mithrandir: ok will check (prefer Kubuntu, but Ubuntu will do)
[02:47] <Mithrandir> Lure: kubuntu live images are building, but won't be around for another 30 or so minutes.
[02:47] <Lure> Kamion: exactly - however there were in daily build just before F5 and F5, so it was there for some time
[02:47] <Lure> Mithrandir: ok, will wait for that
[02:47] <Kamion> Lure: sure, I've just never seen it myself which makes this kind of bug rather hard to attack
[02:48] <Kamion> I'm not doubting that other people are seeing it
[02:48] <Lure> Kamion: I know, I have seen how quickly you addressed 1GB hibernate issue when you got some RAM
[02:48] <infinity> ?
[02:48] <pitti> alright, I'll redo the amd64 espresso with full verbosity, brb
[02:49] <Kamion> Lure: I think you're confusing me with someone else.
[02:50] <infinity> Lure: That was mjg59.  Unless by "you", you meant "you guys". :)
[02:50] <Lure> infinity: correct - I am mixing people... ;-)
[02:52] <Pygi> siretart: wake up pls ^_^
[02:52] <siretart> Pygi: @work
[02:52] <Pygi> ah, k, siretart, will talk later then
[02:55] <JaneW> sivang: ping
[02:58] <desrt> infinity; i find that "y'all" is great for this purpose
[03:00] <sladen> infinity: out of interest, when you're rsync'ing CDs.  what %percentage of the iso are you ending up downloading?
[03:01] <sladen> Mithrandir: even ^^
[03:01] <robertj> desrt: I object, yall is a word all by itself not a contraction
[03:02] <Mithrandir> sladen: total size is 2736779264  speedup is 75.98
[03:02] <Mithrandir> is the last one.
[03:02] <Kamion> is Irvin Piraman here?
[03:02] <infinity> Of course, the last one may have had a new OpenOffice on it...
[03:03] <infinity> Okay, seriously, mksquashfs needs some visual feedback, even if it's just a bunch of dots...
[03:03] <Seveas> robertj, the plural of yall being 'all yall' ;)
[03:04] <robertj> s'right
[03:04] <sladen> robertj: /away...
[03:04] <Mithrandir> infinity: patches accepted, I'm sure.
[03:04] <Mithrandir> Kamion: iz grub-installer bug.  I'm trying to track it down.
[03:05] <Mithrandir> infinity: I might want you to ram stuff through LP in a little while.
[03:05] <infinity> Mithrandir: I might just patch the Ubuntu version, cause the lack of log output on livefs builds drive me nuts.
[03:05] <Kamion> damnit, grub stuff isn't in the copied log
[03:05] <Mithrandir> infinity: absolutely agreed.
[03:05] <infinity> Mithrandir: Mm, ramming.  I never did disable any cronjobs on drescher, but I can go do so.
[03:05] <Mithrandir> Kamion: it's the removabledevices code falling over, for some reason.
[03:05] <Mithrandir> infinity: please.
[03:07] <Kamion> Mithrandir: /proc or /sys not mounted, maybe? (although they should be)
[03:07] <pitti> Kamion: alright, I added two verbose amd64 espresso logs, once with and once without formatting partitions
[03:07] <Kamion> oh, they might not be actually
[03:07] <Keybuk> Mithrandir: any particular reason why you copied the udev local-top script to casper-premount and not casper-top ?
[03:07] <Kamion> at least, /sys might not be
[03:08] <infinity> Mithrandir: Okay, publisher disabled, so we can drive it at will.  It's, of course, in the middle of a run right now, so you don't get it again for ~20 mins.
[03:08] <Kamion> so udevinfo might well object
[03:08] <Mithrandir> Keybuk: there is no casper-top.
[03:08] <ajmitch> infinity: ah, so that's why universe uploads seem to disappear? publisher can only be turned off distro-wide?
[03:08] <infinity> ajmitch: Err, no... I /just/ turned it off.
[03:08] <Kamion> Mithrandir: want me to hit that?
[03:08] <Keybuk> Mithrandir: I see :)  then I now realise that it is not me that is bent, but casper <g>
[03:08] <infinity> ajmitch: If you're missing uploads, find another scapegoat. :)
[03:09] <ajmitch> infinity: goody, then it's another problem :)
[03:09] <infinity> ajmitch: Anything in particular?
[03:09] <ajmitch> aqsis, uploaded ~50min ago
[03:09] <Mithrandir> Keybuk: oh, why?
[03:09] <infinity> ajmitch: 50 mins isn't much time to wait..
[03:09] <ajmitch> no, I'd expected a mail at least in that time
[03:09] <Mithrandir> Kamion: it doesn't seem to be /proc at least.  It's trying to find out if /boot is removable, but the is_removable code is junk.
[03:09] <infinity> ajmitch: Oh, you got no ACCEPTED email?
[03:09] <Mithrandir> I have no idea how this ever worked.
[03:09] <ajmitch> nothing
[03:09] <Keybuk> Mithrandir: just that jbailey's "grand polymorphism" plan suggests having $BOOT-top <do something> $BOOT-premount <mount it> $BOOT-bottom
[03:10] <Kamion> oh, it's looking for /sys in the live CD root which should definitely be there
[03:10] <infinity> ajmitch: Version?
[03:10] <ajmitch> 1.1.0.20050815-2ubuntu4
[03:10] <Mithrandir> Keybuk: *shrug*; I could easily enough have casper-top.  Any particular reason except consistency?
[03:10] <Kamion> 12:20:04 DEBUG   Verifying signature on aqsis_1.1.0.20050815-2ubuntu4_source.changes
[03:10] <Kamion> 12:20:04 WARNING Exception during processing made it out of the main loop.
[03:10] <Kamion>  -> http://librarian.launchpad.net/1898038/9PXmGKoOEGo63OCzmi15rroJQp5.txt (ERROR:  column "familyname" does not exist
[03:11] <infinity> Yeah, found it.
[03:11] <Kamion> SOYUZ
[03:11] <ajmitch> nice
[03:11] <Keybuk> Mithrandir: purely consistency; not important at this point
[03:11] <infinity> Kinnison: Kiiiiiiiiinison!
[03:11] <Mithrandir> Riddell: livefs builds finished, but I think you might want new ones to have something that sensibly installs.
[03:13] <Mithrandir> Kamion: I'm wondering if your last merge of grub-installer was bad.
[03:13] <Kamion> Mithrandir: which, up to 1.14?
[03:13] <Mithrandir> either that, or this code has magically worked by accident in the past.
[03:13] <Mithrandir> Kamion: yeah
[03:13] <Kamion> it's in baz if that helps
[03:13] <Kamion> colin.watson@canonical.com--2005/grub-installer--ubuntu--0
[03:14] <Kinnison> infinity: yo?
[03:14] <infinity> Oh, hi! :)
[03:17] <Mithrandir> Kamion: uhm.  I think the reason is the fstab isn't configured.
[03:17] <Kamion> for mounting /proc?
[03:17] <Kamion> partman's supposed to write out fstab though
[03:17] <Mithrandir> the fstab in /target is not configured.  At all.
[03:18] <Mithrandir> "# UNCONFIGURED FSTAB FOR BASE SYSTEM".
[03:18] <Kamion> just noticed that, I wonder what partman has done ...
[03:18] <Kamion> oh.
[03:18] <Riddell> Mithrandir: why might these not sensibly install?
[03:18] <Kamion> I bet that partman configured it and then we copied over the top of it.
[03:18] <Mithrandir> Riddell: because espresso's broken.
[03:19] <Kamion> Mithrandir: ok, can fix that easily. I have a number of other changes in trunk, including some that require a new partman upload too; do you want me to branch, or just upload the lot?
[03:20] <Mithrandir> Kamion: how confident are you that the changes work?
[03:20] <Mithrandir> Kamion: as in, all the changes.
[03:20] <infinity> Never ask a programmer that.
[03:21] <Kamion> what infinity said :-)
[03:21] <Kamion> medium
[03:21] <infinity> Branch a bugfix-only release, s'il vous plait.
[03:21] <Kamion> ok
[03:21] <Mithrandir> yup
[03:22] <Kamion> I have to wait for bzr push to get its act together
[03:22] <Kamion> never used to be this slow
[03:22] <Mithrandir> and then get infinity to shove it through LP and we can spin new livefs-es.
[03:22] <Mithrandir> or do you want me to upgrade&test it first?
[03:23] <Mithrandir> oh well, I'll go and test the install cds, then
[03:24] <Kamion> the amd64/install CD first, ideally ...
[03:24] <Kamion> then I can respin kubuntu and edubuntu if it works
[03:24] <Mithrandir> yup
[03:24] <infinity> I'm a bit scared that this soyuz bug may kill our espresso upload, but Kinnison's on it, so we'll see.
[03:25] <infinity> Kamion: Upload anyway, under the assumption that soyuz likes you more than ajmitch and won't eat YOUR uploads. :)
[03:25] <infinity> Can run it back through process-upload from failed/ if it does fail.
[03:25] <ajmitch> maybe launchpad is just telling me it's time to go to bed
[03:30] <Seveas> urgh, bugmail format change bad
[03:31] <Seveas> relevant info is now at the bottom (aka a non-fixed location) and subject is repeated in sig
[03:31] <Mithrandir> Kamion: current amd64 doesn't boot for me.
[03:31] <infinity> Kamion / Mithrandir: Kinnison wins; soyuz is happy again.
[03:31] <Lathiat> dos it tell you the package name yet?
[03:32] <Kamion> Mithrandir: damnit
[03:32] <Kamion> Mithrandir: oh, I see the bug, sorry
[03:33] <ajmitch> Lathiat: nope
[03:33] <Mithrandir> Kamion: the cd bug or the espresso bug?
[03:33] <Kamion> Mithrandir: CD bug
[03:33] <Mithrandir> thanks
[03:40] <Kamion> doko: we're still respinning CDs for urgent problems. Could you *please* stop uploading to main so that we have a stable platform to work with? Thank you.
[03:42] <doko> Kamion: ??? sorry, I did not upload _anything_, after you told me 
[03:42] <Kinnison> Kamion: buildds are down anyway :-)
[03:42] <Keybuk> Kamion: I think Launchpad had a burp
[03:42] <infinity> Kamion: Note that the python2.4 upload there is probably a couple of hours old...
[03:42] <Kamion> ah, I see
[03:42] <Keybuk> it suddenly released a small flood of packages
[03:42] <infinity> (Though not THAT old)
[03:42] <Kamion> Kinnison: they'll have to come back up, since we need *some* new binaries
[03:43] <Kinnison> Kamion: I know, znarl is on it
[03:43] <Kinnison> Kamion: firewall change required after librarian changed IP
[03:44] <Kamion> amd64/install rebuilding again
[03:44] <Keybuk> siretart: uh, dude ...
[03:45] <siretart> Keybuk: uh?
[03:45] <Keybuk> siretart: you removed the postinst/preinst etc. from wpasupplicant
[03:46] <Keybuk> which prevents anyone from upgrading
[03:46] <Keybuk> and cancelling the upgrade
[03:47] <Keybuk> if wpasupplicant fails to unpack, they'll be left with a broken system, rather than it falling back nicely to what they had before
[03:47] <desrt> Keybuk; when i enter my WPA key the 'connect to network' (or whatever) button remains inactive
[03:47] <siretart> Keybuk: does this preinst look better to you? http://svn.debian.org/wsvn/pkg-wpa/trunk/wpasupplicant/debian/wpasupplicant.preinst?op=file&rev=0&sc=0
[03:47] <Keybuk> siretart: no, it has the same problem
[03:47] <desrt> Keybuk; wpa2 (aes) with a reasonably long passphrase
[03:48] <Keybuk> the preinst/postinst/postrm combo in my original package were right
[03:48] <Keybuk> yours doesn't cope with the abort-upgrade case
[03:49] <siretart> err, I just have your preinst open as well, it doesn't do anything for abort-upgrade as well
[03:50] <siretart>     abort-upgrade)
[03:50] <siretart>         ;;
[03:50] <Keybuk> preinst doesn't need to
[03:50] <Keybuk> postrm does
[03:50] <Keybuk> your preinst removes their config files
[03:50] <Keybuk> unpack fails
[03:50] <siretart> ah. I see..
[03:50] <Keybuk> they're left with the old wpasupplicant installed with no config files!
[03:51] <mjg59> sladen: Just add free_some_memory() after the call to prepare_processes() in software_resume() in kernel/power/disk.c
[03:52] <siretart> Keybuk: I'm sorry. I'll incorporate your maintainer scripts to our package and upload to dapper, okay?
[03:52] <Keybuk> siretart: I'm reviewing them anyway, and will do the dapper upload :)
[03:52] <HiddenWolf> hey, Keybuk, quick question. Every time I boot my desktop I get a "failed" message for pmcia-services, is that intended?
[03:52] <Keybuk> once Flight 6 is out
[03:52] <Keybuk> HiddenWolf: no
[03:52] <mjg59> HiddenWolf: Yes
[03:52] <Keybuk> mjg59: the "failed" is intended?
[03:53] <mjg59> Keybuk: According to kamion, yeah
[03:53] <Keybuk> fail should never be intended :)
[03:53] <siretart> Keybuk: would you mind basing your work on what we currently have in trunk?
[03:53] <Keybuk> if fail was expected, and occurs, then it should be "ok"
[03:53] <mjg59> pcmcia-cs does nothing useful on new kernels
[03:53] <Mithrandir> pitti: did install/ppc end up working for you?
[03:53] <Keybuk> siretart: yes.  Ubuntu != Debian
[03:53] <Keybuk> I'll look at the trunk changes from ubuntu4, of course
[03:53] <Keybuk> oh, pcmcia-cs
[03:53] <mjg59> Oh, hang on
[03:53] <Kamion> I'm going to merge up pcmcia-cs and pcmciautils from Debian at some point, which IIRC will silence those warnings
[03:53] <mjg59> No, I'm maligning Colin
[03:54] <Kamion> and pull in other stuff we want
[03:54] <siretart> Keybuk: Kel and me are working hard in unifying packaging effords for both debian and ubuntu. we try to not diverge
[03:54] <mjg59> There's code in pcmcia-cs's init script that's supposed to supress that on boot
[03:54] <Keybuk> siretart: right, but I can't answer the question until I've looked at the changes
[03:54] <pitti> Mithrandir: yes, see above :)
[03:54] <Keybuk> Debian frequently does things wrong ;)
[03:54] <HiddenWolf> Kamion: cool.
[03:54] <pitti> Mithrandir: apart from the espresso failure, of course
[03:54] <Mithrandir> pitti: thanks.
[03:54] <Mithrandir> pitti: I was thinking of the regular install cd, not the live cd.
[03:55] <pitti> Mithrandir: amd64/live is fine as well, it's just the unbootable amd64/install CD 
[03:55] <pitti> Mithrandir: yes, I tested both
[03:55] <siretart> Keybuk: in this case, the same person are working on that particular package. we intend to upload to unstable soon[tm] 
[03:55] <Mithrandir> pitti: amd64/live fails to install for me at least.
[03:55] <Kamion> Mithrandir: new amd64/install up
[03:55] <pitti> Mithrandir: s/install/boot/?
[03:55] <Keybuk> siretart: aye, like I said, ask me when I've looked at the changes :)
[03:56] <Mithrandir> pitti: no.  amd64/live, aka espresso, fails to install
[03:56] <siretart> Keybuk: sure
[03:56] <pitti> Mithrandir: ah, I see
[03:56] <pitti> anyway, jigdo'ing new amd64/install now for testing...
[03:56] <Keybuk> I'll make a correct preinst/postinst/postrm triad for the upgrade for you though, given I know how to do it in my sleep :p
[03:56] <Mithrandir> pitti: that is, it installs, but root= is empty so fails to mount /
[04:01] <Mithrandir> maswan: any chance I could get you to mirror flight-6 once we actually have good images?
[04:01] <sladen> mjg59: I've seen a few pointers that it needs to be called repeatedly, is that the case?
[04:02] <_ion> *krhm*BitTorrent*krhm*
[04:02] <mjg59> sladen: Calling it repeatedly may help in edge cases, but that's a bug really
[04:02] <mjg59> Just calling it once ought to fix this case
[04:02] <maswan> Mithrandir: Ping me on irc?
[04:02] <Mithrandir> maswan: sure, will do.  I can drop a copy on ravel, if that's fine?
[04:02] <maswan> Mithrandir: otherwise, the croned mirror goes at 09, CEST
[04:03] <maswan> Mithrandir: Well, sure, especially if cdimage is horribly slow. :)
[04:03] <Mithrandir> maswan: you don't mirror the full cdimage.u.c, do you?
[04:03] <Mithrandir> maswan: it tends to be. :-P
[04:03] <maswan> Mithrandir: the directories with "release" in them
[04:03] <Mithrandir> oh, cool
[04:03] <Mithrandir> I didn't know
[04:03] <Mithrandir> :-)
[04:03] <maswan> cdimage/releases/, cdimage/ports/releases/, cdimage/edubuntu/releases/, cdimage/kubuntu/releases/ to be exact
[04:06] <Kamion> infinity: espresso 0.99.36.1 uploaded; tested, works better for me
[04:06] <Kamion> probably hasn't quite hit accepted yet
[04:06] <infinity> Woo.
[04:07] <infinity> Will watch for it.
[04:09] <infinity> 14:09:19 DEBUG   Publishing source espresso/0.99.36.1 to ubuntu/dapper
[04:09] <infinity> And away we go.
[04:10] <fabbione> Keybuk: ping?
[04:10] <Keybuk> fabbione: hey
[04:10] <fabbione> Keybuk: hey dude...
[04:11] <fabbione> Keybuk: udev -> scsi_id
[04:11] <fabbione> is there any reason why we don't ship the /sbin/ versions?
[04:11] <fabbione> but only the lib/udev ?
[04:11] <Keybuk> because it's only used by udev
[04:11] <fabbione> no it's not :)
[04:11] <Keybuk> what else is it used by?
[04:11] <fabbione> multipath-tools does
[04:11] <Keybuk> never heard of that
[04:11] <Keybuk> and isn't in main
[04:12] <fabbione> it's in universe
[04:12] <fabbione> it will be in main soon
[04:12] <Keybuk> then it needs to be fixed
[04:12] <fabbione> udev needs to be fixed
[04:12] <Keybuk> no, udev doesn't
[04:12] <Keybuk> this is shipped this way upstream
[04:12] <Mithrandir> fabbione: just use udevinfo instead.
[04:12] <Keybuk> scsi_id is an internal tool to udev, nothing else should be trying to fiddle with it
[04:12] <fabbione> Keybuk: so why does Debian ship scsi_id in /sbin ?
[04:13] <fabbione> Mithrandir: i didn't write this tool and i don't plan to do so
[04:13] <Keybuk> because Debian ships all of the udev helpers in the wrong place
[04:13] <Keybuk> which results in people trying to use them
[04:13] <Keybuk> and then complaining when the interface chances
[04:13] <pitti> alright, let's try the latest amd64 install then, brb
[04:13] <Keybuk> uh, changes
[04:13] <Keybuk> where there is "useful functionality" in a udev helper, it should either be C&P'd into the other code or turned into a shared library
[04:14] <Keybuk> e.g. with the libvolume_id that's been split off recently
[04:14] <fabbione> Keybuk: multipath-tool has hardcoded it that way..
[04:14] <sladen> mjg59: as simple as:  http://www.paul.sladen.org/ubuntu/upload/fix-swsusp-alloc-failure.patch ?
[04:14] <Keybuk> then multipath-tool has a bug
[04:16] <Keybuk> urgh
[04:16] <Keybuk> yeah, this is just horrid
[04:18] <pitti> Kamion: still no amd64/install boot joy :/
[04:21] <mjg59> sladen: Precisely
[04:23] <sladen> mjg59: and would adding similar to  snapshot.c:swsusp_save()  on the way down help the "Not enough free memory" on the way down?
[04:24] <Keybuk> fabbione: this really just looks like it's doing fork/exec/read just to avoid an ioctl()
[04:25] <sladen> you could send morse-code messages to the kernel by doing that
[04:25] <mjg59> sladen: No, it's already done
[04:25] <mjg59> (Isn't it?)
[04:26] <Keybuk> sladen: people don't seem to like touching the kernel, afraid they'll catch something I guess
[04:27] <mjg59> sladen: Oh, hang on. prepare_processes() already calls free_some_memory.
[04:28] <sladen> mjg59: so it does.  hmmm
[04:32] <Mithrandir> ok, i386 install works fine.
[04:33] <Mithrandir> infinity: awty on espresso?
[04:33] <infinity> Mithrandir: Nope, but getting there.
[04:33] <infinity> Mithrandir: publisher is cleaning up, queuebuilder is running.
[04:33] <infinity> Mithrandir: Once the buildd turn around a binary or two, I'll re-run the publisher for you.
[04:33] <Mithrandir> ok, goodie
[04:33] <infinity> s/buildd/buildds/
[04:34] <Mithrandir> Kamion: amd64 cd still broken.
[04:35] <Mithrandir> Kamion: try with +1000 instead?
[04:36] <Mithrandir> Kamion: debian-cd/tools isn't writable by me so you need to do it yourself.
[04:40] <Mithrandir> Kamion: hmm, apparently, 1000 should work too.  According to the docs.
[04:40] <pitti> Mithrandir: amd64 boot still broken> confirmed
[04:40] <infinity> Mithrandir: publisher running, espresso in for amd64/powerpc/i386/ia64
[04:41] <infinity> Mithrandir: I didn't wait for the other two, since they're not building livefs anyway. :)
[04:41] <Mithrandir> infinity: great, I'll start the livefs builds now, then.
[04:41] <infinity> Mithrandir: And due to doing this so rapidly, nothing else slipped past the freeze. :)
[04:42] <infinity> (Though it'll all get in on the next publisher run, so hopefully this is the last)
[04:42] <infinity> Mithrandir: Err, don't start the builds yet, dude.  publisher needs a good 20 mins or more to do its thing.
[04:42] <Mithrandir> infinity: hm, ok.
[04:45] <Mithrandir> Kamion: can you try making isolinux.bin be +1001 and boot.cat be +1000 or something like that?
[04:48] <Pygi> siretart: we are probably going to switch to 0.5 branch for dapper+1 anyway
[04:48] <Pygi> if it will be stable enough
[04:56] <mjg59> sladen: I can't update arbitrary packages in Debian, no
[04:58] <Kamion> Mithrandir: ok (sorry, was out picking up Benedict from school)
[04:59] <Mithrandir> Kamion: mind doing a g+w on the debian-cd tree too?
[05:00] <Kamion> Mithrandir: awkward, baz bitches if I change permissions
[05:00] <Kamion> I'll see what I can do
[05:00] <Mithrandir> Kamion: grr, ok.
[05:00] <Kamion> main reason I want to switch cdimage to bzr
[05:00] <Mithrandir> is there a hold-up apart from "no time"?
[05:01] <Kamion> need to figure out how configs work with bzr
[05:03] <infinity> Mithrandir: Okay, should be published now.
[05:04] <Mithrandir> infinity: kthx, I'll build live fs-es, then.
[05:04] <Mithrandir> then go home and continue from there.
[05:04] <Kamion> Mithrandir: should have another go-around on amd64/install before you go home, if possible
[05:05] <Pygi> _ion: around?
[05:07] <infinity> It's 2am, and I'm being bugged to go to bed.
[05:07] <Mithrandir> Kamion: you're spinning ISOs?
[05:07] <infinity> Kamion: Should I re-enable the publisher's crontab, or do you want to do some by-hand driving as needed?
[05:09] <_ion> pygi: Somewhat.
[05:09] <Pygi> _ion: ah, can you at least tell me if you got my mail?
[05:10] <_ion> pygi: Yeah, i got the mail. I'm not feeling very well, i haven't had strength to do that. :-\
[05:11] <Pygi> _ion: no worries, once you feel better ^_^
[05:11] <Pygi> time is on our side now ^_^
[05:14] <infinity> Egads, does gutenprint's postinst need to be so friggin' verbose?
[05:15] <Kamion> Mithrandir: amd64/install up
[05:16] <Kamion> infinity: up to you
[05:16] <Mithrandir> Kamion: already 40% synced here
[05:16] <rob^^^> are there any plans for making Espresso less sparse looking?
[05:17] <Kamion> rob^^^: there's a plan to put images down the left-hand side of each page; waiting for artwork on that
[05:17] <infinity> Kamion: I'm not picky, it's really up to you (if you want to drive) and Mithrandir (if he feels the faster turnaround is worth the hassle)
[05:17] <Kamion> rob^^^: there's also a plan to have a flash animation (playable with free software) alongside the install progress bar; again, waiting on art
[05:17] <rob^^^> Kamion: we need You-Don't-Know-Jack style animation complete with voice-over
[05:18] <rob^^^> "Look sharp, here comes step number 1"
[05:18] <Mithrandir> infinity: I don't think we need it.  If this doesn't work, I'm inclined to try tomorrow instead.
[05:18] <infinity> Mithrandir: Fair enough.  I'll put soyuz back on full-auto, then.
[05:18] <Mithrandir> infinity: thanks.
[05:18] <Kamion> but if the art doesn't arrive, I'm happy with clean rather than full of badly-designed cruft (because if I have to do the art, you'll get the latter
[05:18] <Kamion> )
[05:19] <pitti> should the new amd64 image fix booting, i. e. shall I try it? or is it just the espresso update?
[05:20] <Mithrandir> pitti: it should fix booting.
[05:20] <Mithrandir> pitti: if you wait about one minute, I'll know if it does so for me.
[05:20] <pitti> Mithrandir: you can burn a CD in a minute?
[05:20] <Mithrandir> no, about three.
[05:20] <pitti> Mithrandir: my jigdo will finish in about one
[05:20] <Mithrandir> but it was halfway done
[05:21] <pitti> oh, wow
[05:21] <Kamion> pitti: it's an install CD, not a live CD, so no espresso update
[05:21] <pitti> ah, *slap me*, right
[05:21] <Mithrandir> livefs images are still building.
[05:21] <pitti> thanks :)
[05:21] <infinity> Mithrandir: i386 is into mksquash, at least.. We're getting there.
[05:21] <Kamion> for some reason it's taking a while to rsync here
[05:22] <Mithrandir> *sigh*.  Still doesn't work for me. on amd64. :-(
[05:22] <infinity> Waiting on these hurts.
[05:24] <Mithrandir> Kamion: I don't know what the issue is, but I need to go home now.  I'll see if I can get the live images tested there, at least.
[05:25] <Pygi> pitti: I'll inform people on the forum /testers/ about the bug, now that it's fixed
[05:25] <Pygi> pitti: do you agree?
[05:26] <pitti> yes, sure
[05:26] <infinity> pitti: Are you the printing go-to guy these days?
[05:26] <pitti> infinity: I don't like to be
[05:26] <pitti> but I am, as it seems
[05:26] <pitti> I didn't start the cupsys Mega Bug Triage From Hell yet
[05:26] <pitti> but it's high on my list now
[05:27] <seb128> Riddell: do you know about https://launchpad.net/distros/ubuntu/+source/totem/+bug/36315 ?
[05:27] <Ubugtu> Malone bug 36315 in totem "totem does not stop kscreensaver from starting" [Normal,Unconfirmed]  
[05:27] <infinity> pitti: Can you look at making cupsys-driver-gutenprint's postinst about 8000 times less verbose?
[05:28] <Kamion> Mithrandir: argh :(
[05:28] <sladen> mjg59: http://www.paul.sladen.org/debian/upload/hotkey-setup_0.1-16.debdiff -> Debian please
[05:28] <Riddell> seb128: I do not
[05:28] <seb128> Riddell: do apps need to call so kscreensaver --something to inactivate it?
[05:28] <infinity> pitti: http://people.ubuntu.com/~cjwatson/livefs-build-logs/dapper/ubuntu/20060329/livecd-20060329-i386.out <-- search for "Writing /usr" and cringe.
[05:28] <Kamion> CD1/isolinux/isolinux.bin +2
[05:28] <Kamion> CD1/isolinux/boot.cat +1
[05:28] <Kamion> Mithrandir: that's the weights file, FWIW ...
[05:29] <pitti> infinity: yay
[05:29] <pitti> infinity: added to my todo list
[05:29] <infinity> pitti: Danke.
[05:29] <Riddell> seb128: no, as far as I remember apps are expected to make false keyboard events to stop it
[05:30] <seb128> Riddell: ok, thank you
[05:30] <infinity> seb128: Same log, look for "gtk-update-icon-cache" and can you please make ubuntu-artwork's postinst shut up? :)
[05:31] <seb128> infinity: weird
[05:32] <seb128> infinity: the issue is rather to know why there is the warning rather than to mask it
[05:32] <infinity> seb128: Yes, I didn't ask you to /dev/null it, I asked you to shut it up. :)  If that involves fixing a real bug, all the better.
[05:41] <Mithrandir> pitti: does the amd64/install cd work for you?
[05:41] <mjg59> sladen: Done, feel free to upload to Ubuntu once flight is out
[05:41] <Mithrandir> Kamion: yeah, and that worked for me.
[05:41] <pitti> Mithrandir: I can try it
[05:41] <Mithrandir> Kamion: can we get debian-cd to log the exact mkisofs command line?
[05:42] <pitti> Mithrandir: burning
[05:42] <Kamion> Mithrandir: added to my to-do, although I don't think our problem is a wrong command line
[05:43] <Mithrandir> Kamion: well, I have something which works in my end and something which doesn't in little's end so trying to move those towards each other, one step at a time, is probably good.
[05:46] <rcaskey_> err :(
[05:46] <rcaskey_> Was working in breezy...
[05:53] <jcole> fyi, i did and apt-get dist upgrade to dapper from breezy and it hung on "starting PCMCIA services"... when i reboot, the system locks up right there on boot over and over again...
[05:53] <jcole> so, i'm going to chroot into it from the live cd and remove the PCMCIA service so it will finish the boot and the upgrade... this is not a laptop btw, it's a desktop...
[05:55] <Kamion> Mithrandir: try the mkisofs on little?
[05:55] <Kamion> Mithrandir: there's bsdtar and libarchive.so.1 in my home directory that you can use to unpack it, or just work off the temporary directory
[05:59] <wasabi__> So I'd like to not have a mta.
[06:03] <infinity> wasabi__: Then don't have one?
[06:04] <wasabi__> Not able to uninstall it. ;)
[06:04] <wasabi__> hmm actually it looks like it's because of mutt.
[06:04] <wasabi__> that's probably a dep that needs to be fixed
[06:06] <infinity> wasabi__: Or just "apt-get --purge install ssmtp" (or similar)
[06:07] <infinity> wasabi__: Some stuff really does want a /usr/bin/sendmail to be there, but there's no reason it needs to be a full MTA for most use cases.
[06:08] <Mithrandir> Kamion: yeah, I think I'll try that.  But I don't have my test setup here and pitti didn't call back yet.
[06:13] <doko> Riddell: gnome has a dialogue/preference to overwrite the default fontconfig selection. does KDE has something similiar?
[06:13] <Kamion> I've done chmod -R g+w cdimage/debian-cd/ for now
[06:13] <Kamion> baz is really upset by this though so I'll have to undo that later
[06:13] <Riddell> doko: don't think so no
[06:14] <doko> Riddell: then wich font does KDE use by default?
[06:15] <Kyral> DejaVu Sans
[06:15] <Kyral> IIRC :P
[06:15] <Riddell> doko: Dejavu
[06:16] <doko> Riddell, Kyral: you have no menu in KDE to specify the fonts you use for your applications?
[06:17] <Riddell> doko: sure, there's one for that, sorry didn't know what you ment by overwriting fontconfig selection
[06:21] <pitti> Mithrandir: sorry, I was off for dinner; I'll try booting now
[06:21] <doko> Riddell: and something for a "document font" as well?
[06:22] <Riddell> doko: what's that?
[06:22] <mdke> Diziet, ping?
[06:24] <doko> a font that is used to write documents with, i.e. in OOo the default font for documents
[06:24] <pitti> Mithrandir: still no luck
[06:25] <Mithrandir> pitti: can you remove /pool from the image and see if it boots for you then?
[06:28] <Riddell> doko: there's the General Font, which is set to Dejavu Sans 9
[06:31] <doko> Riddell: please could you move down the DejaVu preference for serif and sans-serif in /etc/fonts.conf to the end (about line 260, the prefer sections), and then see, if you can get KDE to default to DejaVu again?
[06:32] <pitti> Mithrandir: hm, how do I do that?
[06:32] <pitti> Mithrandir: it's ISO-9660, isn't it?
[06:33] <Mithrandir> pitti: loop-mount it, copy to another directory, run mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-install-amd64-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
[06:33] <Mithrandir> burn that and test it
[06:33] <pitti> Mithrandir: ah, thanks
[06:36] <Riddell> doko: do I need to restart something after editing that file to make it take effect?
[06:36] <Riddell> doko: we set the default font explicitly in kdeglobals
[06:38] <pitti> Mithrandir: with LANG=C? otherwise it rambles about UTF-8 encoded file names
[06:40] <pitti> Mithrandir: trying, brb
[06:44] <pitti> Mithrandir: indeed, boots
[06:44] <pitti> Mithrandir: now I'll just re-mkisofs the full CD and see whether it works
[06:44] <doko> Riddell: last question: can you set this explicitely for koffice as well? I serif and a sans-serif font for the document, which is different than the default serif/sans-serif fonts?
[06:46] <Riddell> doko: not that I know of, I think it just uses the default font
[07:16] <pitti> Mithrandir: AYT?
[07:19] <pitti> Mithrandir: so, if I unpack and re-mkisofs the full CD (with the command you gave me), it boots happily
[07:20] <pitti> Mithrandir: my image is 240 bytes smaller than the original one
[07:21] <pitti> Mithrandir: and there are some differences in the first few KBs: http://paste.ubuntu-nl.org/11108
[07:22] <pitti> Mithrandir: the first diff was just me getting the label wrong (sorry), but the rest might be relevant
[07:23] <pitti> Mithrandir: the second hunk looks harmless, too (just the date)
[07:24] <pitti> Mithrandir: I'll try to manually patch the first few bytes and check whether it works
[07:47] <pef> hello
[07:55] <jcole> fabbione: mark mentioned you regarding clustering in his speech to us...
[07:56] <zyga> hey
[08:05] <pitti> Mithrandir: hm, no luck with binary patching (I changed everything but the date from the patch I pastebin'ed)
[08:05] <pitti> need to go now
[08:06] <LeeJunFan> anyone here in charge of mirrors? Packages files are missing from them all. the zipped ones are there.
[08:06] <siretart> LeeJunFan: ask in #launchpad
[08:06] <LeeJunFan> siretart: thanks
[08:07] <sivang> re
[08:21] <fabbione> jcole: yes
[08:21] <sladen> mjg59: isn't #37365 a case of needing special twiddlage to toggle the bluetooth dongle?
[08:22] <jcole> my company uses apani netlock for their vpn solution, ubuntu and debian are the only 2 distros that do not work unless we recompile our kernels with these 2 flags enabled:
[08:22] <jcole> CONFIG_REGPARM=y
[08:22] <jcole> CONFIG_IRQBALANCE=y
[08:22] <sladen> mjg59: or are you punting it to kernel because the power/state should work
[08:23] <jcole> i'm not sure what they are, and was wondering what it would take, to request them to be enabled by default in ubuntu kernels
[08:24] <fabbione> jcole: can you please file a bug in malone against linux-source-2.6.15 exaplaning the problem?
[08:24] <jcole> fabbione: you got it
[08:25] <fabbione> jcole: no no.. benc will :)
[08:25] <fabbione> i am not kernel maintainer anylonger..
[08:25] <fabbione> i only take care of very few bits
[08:25] <pef> is someone working on a web based tool to help tracking laptops's bugs ?
[08:27] <sladen> pef: I've been thinking of extenting the hwdb tool, but haven't got anywhere
[08:28] <jcole> fabbione: don't file a bug?
[08:28] <sladen> pef: if you fancy doing it, that would probably be the place to start
[08:28] <siretart> are uploads to main allowed again?
[08:28] <fabbione> jcole: please file a bug.. i will not get it.. the kernel maintainer will
[08:28] <jcole> fabbione: oh ok
[08:28] <jcole> fabbione: btw, do you know what those flags do?
[08:28] <mjg59> sladen: The kernel should be able to do it
[08:29] <pef> sladen: will investigate hwdb, thanks for the tip ;)
[08:29] <sladen> jcole: REGPARM changes the call method to put the first X arguments into registers rather than on the stack
[08:29] <fabbione> jcole:  i could check.. but i am at almost 15 hours in the day...
[08:29] <sladen> pef: ask ogra for starting pointers, but it's python
[08:29] <fabbione> jcole: and i really need some relax now
[08:30] <pef> sladen: what a cool language, isn't it ?
[08:30] <sladen> pef: yes, goodness++
[08:32] <pef> sladen: I will keep you informated if I my idea goes further
[08:34] <jcole> fabbione: heh, dude "apt-get install workrave"
[08:35] <fabbione> jcole: i can't :) i got a new toy at home.. i can't stop playing: )
[08:37] <sladen> fabbione: does she mind?
[08:37] <sivang> fabbione: which toy? :)
[08:37] <fabbione> sladen: a bit :)
[08:37] <fabbione> sivang: a SAN
[08:49] <sabdfl> so how's flight 6 looking?
[08:49] <sabdfl> Kamion: any reason for me not just to charge ahead with a daily?
[08:51] <Mithrandir> sabdfl: we're having trouble booting the amd64 install images on some machines, for some reason.
[08:51] <sabdfl> ok
[08:51] <sabdfl> will hold off then
[08:51] <Mithrandir> it's very weird; it doesn't boot for me and pitti, but works for Kamion and others.
[08:51] <sabdfl> thanks
[08:51] <Mithrandir> (and it works on my other amd64).  
[08:52] <Mithrandir> It seems to be amd64 specific, somehow, and only affects some machines.
[09:15] <siretart> Mithrandir: I read above that buildds are stopped for flight-6. does this mean that it is safe to upload to main again?
[09:18] <Mithrandir> siretart: no.
[09:21] <jcole> fabbione: done. https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/37377
[09:21] <Ubugtu> Malone bug 37377 in linux-source-2.6.15 linux-image-2.6.15-19-386 "Apani Netlock VPN Compatibility" [Normal,Confirmed]  
[09:30] <Tonio_> slomo_: http://pastebin.com/631305
[09:30] <Tonio_> slomo_: I assume you will have to add a second beagled.desktop to debian folder then no ?
[09:30] <Tonio_> cause actually you where installing the same twice
[09:31] <slomo_> Tonio_: yes... beagled-kde.desktop is fine with you?
[09:31] <Tonio_> slomo_: as long as it autostarts :)
[09:31] <Tonio_> hehe
[09:31] <slomo_> damn, beagle is main already... another upload that has to wait :)
[09:34] <slomo_> Tonio_: i hope you can wait until flight6 release?
[09:34] <Tonio_> slomo_: well, of course :) the goal is 1st june
[09:34] <Tonio_> I have no expectation between now and then :)
[09:35] <slomo_> Tonio_: ok :)
[09:35] <Tonio_> slomo_: we are working on kde frontends for beagle, but that's not going to main actually (to many gtk deps)
[09:35] <Tonio_> so no pb ;)
[09:35] <pef> is system settings->wireless obsolete because of network manager ?
[09:36] <Riddell> slomo_: beagle looks like it's in universe to me
[09:37] <Riddell> pef: has that ever worked?
[09:38] <slomo_> Riddell: apt-cache showsrc beagle
[09:38] <slomo_> Riddell: pool/main/b/beagle
[09:38] <Tonio_> slomo_: I see it in universe also
[09:38] <slomo_> Riddell: but the beagle binary package is in universe, yes...
[09:39] <Tonio_> slomo_: ah ok
[09:39] <Riddell> slomo_: yes I see that now, libraries are but not app.  something to do with nautilus needing the libraries
[09:39] <pef> Riddell: works for me, but it lacks dhcp feature, running konsole to run dhclient is not very user friendly
[09:39] <slomo_> does someone have the anastacia url at hand? :)
[09:39] <Riddell> pef: wlassistant will obsolete it if knetworkmanager doesn't
[09:39] <Riddell> slomo_: KubuntuFiles
[09:39] <slomo_> found it, thanks
[09:40] <Tonio_> pef: did you manage to connect using kwifimanager ??
[09:40] <slomo_> no beagle on there... hm, probably only has to be promoted to main by something...
[09:40] <Tonio_> pef: I never got it to connect, even without dhcp...
[09:48] <HiddenWolf> slomo_ I thought beagle hit main already?
[09:48] <slomo_> HiddenWolf: beagle has (the source and libraries) but beagle itself hasn't
[09:48] <slomo_> i.e. the frontent
[09:48] <slomo_> and indexer
[09:48] <slomo_> etc
[09:49] <slomo_> something has to pull it in or it has to be added to the seeds afaik
[09:50] <enrico> infinity: you're welcome asking for help before declaring that debtags is the root of all evil
[09:50] <enrico> infinity: I'm not online often these days, but when I'm online I try to help.  In #ekhis on freenode you'll also find help
[10:45] <KaiL> slomo_, you mean, the next beagle will go into main automatically?
[10:46] <KaiL> ..as the current one still has universe as Filename-Value ;)
[10:46] <slomo_> KaiL: no... the source and libs are already in main but nothing in main depends on the beagle binary package and it's not forced to be in main yet ;)
[10:47] <KaiL> ah
[10:50] <mdz> Riddell: ping
[10:53] <Riddell> mdz: hi
[10:58] <rcaskey_> Are there any thoughts about hiding update manager after the dowload process starts?
[11:01] <HiddenWolf> rcaskey_ people will wonder where it went, do other stuff, be suprized, reboot their pc's halfway, or do all sorts of things.
[11:02] <HiddenWolf> or start filing bugs because it suddenly went away
[11:02] <rcaskey_> Hidden: it's still got the downloading window up
[11:02] <HiddenWolf> anyway, have to go, good night.
[11:14] <rcaskey_> where is the appopriate place to report update manager bugs? It blinks after transitioning from downloading to installing...
[11:15] <Burgwork> rcaskey_, lp
[11:15] <rcaskey_> Burgwork: I tried but must be in the wrong section or something
[11:17] <Burgwork> rcaskey_, www.launchpad.net/distros/ubuntu/+filebug
[11:19] <rcaskey_> Burgwork: ok, #37397
[11:19] <rcaskey_> *ahem* bug #37397
[11:19] <Ubugtu> Malone bug 37397 in update-manager "shouldn't blink after switch from downloading to installing" [Normal,Unconfirmed]  http://launchpad.net/bugs/37397
[11:28] <KaiL> where was the list of the ubuntu-server Packages?
[11:28] <Pygi> KaiL: we have some issues that need major action
[11:28] <KaiL> Pygi, huh?
[11:29] <Pygi> people started reporting some things that are not true, are obvious duplicates, etc
[11:29] <KaiL> huh?
[11:29] <Pygi> against n-m, huh? :P